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

[osstest service owner]

d-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  fail
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-armhf-armhf-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-amd64-amd64-xl-qcow2pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-i386-xl-raw   pass
 test-amd64-amd64-xl-rtds fail
 test-armhf-armhf-xl-rtds pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-armhf-armhf-xl-vhd  pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

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

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

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


Not pushing.


commit 6eac5f7bad6cd8f56b3514ac485dd35d79abff66
Merge: 0cb34ff 0e39bb0
Author: Peter Maydell <peter.mayd...@linaro.org>
Date:   Wed Aug 3 14:25:09 2016 +0100

Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20160803

[Xen-devel] [Design RFC] Towards work-conserving RTDS scheduler

[Meng Xu]

Hi Dario,

I'm thinking about changing the current RTDS scheduler to
work-conserving version as we briefly discussed before.
Below is a design of the work-conserving RTDS.
I'm hoping to get your feedback about the design ideas first before I
start writing it in code.

I think the code change should not be a lot as long as we don't
provide the functionality of switching between work-conserving and
non-work-conserving. Because the following design will keep the
real-time property of the current RTDS scheduler, I don't see the
reason why we should let users switch to non-work-conserving version.
:-)

Thank you very much and looking forward to your comments!

--- Below is the design ---

*** Motivation ***
A scheduler is working-conserving if the scheduler always pick a
"task" (i.e., VCPU in RTDS scheduler case) as long as there still
exists a pending "task" that has not finished.

The current RTDS scheduler is not work-conserving. The
non-work-conserving property of the current RTDS scheduler prevents
the scheduler from utilizing the system's *idle* resource.

For example, when there is only one VCPU with period = 10ms and budget
= 4ms, on one CPU, scheduled by the RTDS scheduler, the VCPU can only
get 4ms for every 10ms. This leaves the CPU idle for 6ms in every
10ms. This is OK/safe because we assume the system administrator has
already known the workload on the VCPU and believes the VCPU (period =
10ms, budget = 4ms) is enough to provide real-time guarantee to the
workload on the VCPU.

However, we can further improve the system's average performance
without breaking the real-time property of the RTDS scheduler by
utilizing the idle resource.

*** Current RTDS scheduler in Xen ***
1) VCPU model: Each VCPU has period and budget
2) Scheduling policy: gEDF
3) Server mechanism: Deferrable server
4) Behavior: When VCPUs are schedulable on M cores, each VCPU is
guaranteed to be able to provide budget time in each period. Each VCPU
can run for * at most * budget time in each period

*** Observations of current RTDS scheduler ***

1) gEDF is work-conserving algorithm, but
2) Deferrable server is not “work-conserving”: When system has idle
resource, the deferrable server is not allowed to over-run. This
property of deferrable server prevent the RTDS scheduler from using
the idle resource in the system to improve the average response time
of VCPUs.

*** Requirement of the work-conserving RTDS scheduler ***
1) The new RTDS scheduler should be work-conserving, of course.
2) The new RTDS scheduler should not break any real-time guarantee
provided by the current RTDS scheduler.

*** Design of  Work-Conserving RTDS Scheduler ***
VCPU model
1) (Period, Budget): Guaranteed  time for each 
2) Priority index: It indicates the current  priority level of the
VCPU. When a VCPU’s budget is depleted in the current period, its
priority index will increase by 1 and its budget will be replenished.
3) A VCPU’s budget and priority index will be reset at the beginning
of each period

Scheduling policy: modified gEDF
1) Priority comparison:
   a) VCPUs with lower priority index has higher priority than VCPUs
with higher priority index
   b) VCPUs with same priority index uses gEDF policy to decide the
priority order
2) Scheduling point
   a) VCPU’s budget is depleted for the current priority index
   b) VCPU starts a new period
   c) VCPU is blocked or waked up
3) Scheduling decision is made when scheduler is invoked
a) Always pick the current M highest-priority VCPUs to run on the M cores.

---
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
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 99917

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

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

version targeted for testing:
 xen  45a348ebaba3f6e0a26455a3ff181a41722943a0
baseline version:
 xen  e9522e4932aaa7f083688b6612b5897839409260

Last test of basis99917  2016-08-03 08:27:27 Z0 days
Testing same since99928  2016-08-03 16:14:26 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 
  Wei Liu 

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
 

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

[osstest service owner]

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

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

Last test of basis99931  2016-08-03 19:22:27 Z0 days
Testing same since99933  2016-08-04 01:15:36 Z0 days1 attempts


People who touched revisions under test:
  Ma, Maurice 
  Maurice Ma 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=365a3aab857a2820d36d2ae9b3b62f06230b295a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
365a3aab857a2820d36d2ae9b3b62f06230b295a
+ branch=ovmf
+ revision=365a3aab857a2820d36d2ae9b3b62f06230b295a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x365a3aab857a2820d36d2ae9b3b62f06230b295a = 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] [RFC Design Doc v2] Add vNVDIMM support for Xen

[Haozhong Zhang]

On 08/03/16 19:16, Konrad Rzeszutek Wilk wrote:
> > > 1.4 clwb/clflushopt
> > > 
> > >  Writes to NVDIMM may be cached by caches, so certain flushing
> > >  operations should be performed to make them persistent on
> > >  NVDIMM. clwb is used in favor of clflushopt and clflush to flush
> > >  writes from caches to memory.
> > > 
> > >  Details of clwb/clflushopt can be found in Chapter 10 of [6].
> > 
> > Didn't that opcode get dropped in favour of poking in some register?
> 
> Nevermind. I got this confused with pcommit which was deprecated.
> 
> But looking at chapter 10.2.2 it mentions that to commit to
> persistent memory you need to use pcommit. So what is the story here?

The document has not been updated yet, though patches to revert
pcommit support for both Linux and Xen had been merged.

> .. snip...
> > >  A part not put in above figure is enabling guest clwb/clflushopt
> > >  which exposes those instructions to guest via guest cpuid.
> > 
> > And aren't those deprecated?
> 
> And again. Ignore that comment.
> .. snip..
> > > 4. Design of vNVDIMM in Xen
> > > 
> > >  As KVM/QEMU, our design currently only provides pmem vNVDIMM.
> > > 
> > >  Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> > >  three parts:
> > >  (1) Guest clwb/clflushopt enabling,
> > >  (2) pmem address management, and
> > >  (3) Guest ACPI emulation.
> > > 
> > >  The rest of this section present the design of each part
> > >  respectively. The basic design principle to reuse existing code in
> > >  Linux NVDIMM driver, QEMU and Xen as much as possible.
> > > 
> > > 
> > > 4.1 Guest clwb/clflushopt Enabling
> > > 
> > >  The instruction enabling is simple and we do the same work as in 
> > > KVM/QEMU:
> > >  - clwb/clflushopt are exposed to guest via guest cpuid.
> > > 
> > 
> > Again, isn't that deprecated and the new mechanism (pokng at some register)
> > has to be used?
> 
> So clflushopt can be used for flushing out a cacheline. But what
> to do about store in the non-volatile memory? I recall that you could
> do an sfence and then pcommit, which would be aking to an SCSI SYNC
> command.
> 
> But with pcommit being deprecated (albeit the URL you pointed too
> still lists pcommit) - at least in Xen and Linux - how do you
> enforce this wholesale flush?
>

After deprecating pcommit, at least one of following two approaches
should be provided by HW to guarantee persistent:

1) Asynchronous DRAM refresh (ADR)
   If the platform supports ADR, flush CPU cache lines (e.g. by
   clwb/clflushopt/clflush) will result result in flush write pending
   queues in memory controller to NVDIMM.
   
2) ACPI Flush Hint Address Structure
   If ACPI flush hint address structure is available for a NVDIMM
   region, software can write to that structure to flush any preceding
   stores to that NVDIMM region. (Section 5.2.25.8 of ACPI Spec 6.1)

ADR is preferred, as guest clwb/clflushopt/clflush do not introduce
VMEXITs.

However, I'm also going to emulate ACPI flush hint address structure
in case of the lack of ADR. Basically, guest writes to ACPI flush hint
address structure will be trapped to QEMU which will submit them to
the host ACPI flush hint address structure via Dom0 NVDIMM driver.

If neither ADR nor ACPI flush hint address structure is available,
persistent can not be guaranteed.

Thanks,
Haozhong

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

Re: [Xen-devel] [PATCH RESEND] MAINTAINERS: update email

[George Dunlap]

On Mon, Aug 1, 2016 at 11:53 AM, Xuquan (Euler)  wrote:
> Wei, thanks!!
> This email is sent out from outlook (the Linux can't send out email). the 
> format may be not correct.

If you aren't able to use a tool like 'git send-email' to send out
patches, then what most people do is to both paste the patch inline,
and attach a copy of the patch.  That way people can easily quote the
patch when replying, but can also apply it easily when they want to do
so.  (One of the core developers, Jan Beulich, is in a similar
situation, and this is what he does.)

Thanks,
 -George

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

Re: [Xen-devel] Some interesting results from schedbench

[George Dunlap]

On Mon, Aug 1, 2016 at 5:26 PM, George Dunlap  wrote:
> This is due to the difference between credit1 and credit2's load
> balancing.  Credit1 randomly shifts stuff around based on what it sees
> at this instant.  Which means that much of the time, it has {A,B} {A,B},
> but it frequently ends up with {A,A} {B,B}.
>
> Credit2 measures the load average for runqueues over the long haul and
> tries to make the *runqueue* average the same; and since our default now
> is one runqueue per core, that means that it will almost immedeately go
> to {A,B} {A,B} and never change it.
>
> The aggregate throughput for the system seems to be slightly higher
> under credit1 (645Mops credit1 vs 639Mops credit2).
>
> It's actually somewhat arguable what the optimal thing to do here is --
> one could argue that "fairness" in the case of hyperthreads should mean
> that if you leave space for someone else to run at 'boost', that you
> should be given space for someone else to be run at 'boost'.
>
> But that's probably an optimization for another day: on the whole I
> think credit2's rational approach to balancing load is much better.

BTW, Dario asked me if I could run the same test with
credit2_runqueue=socket (i.e., one runqueue per socket rather than one
runqueue per core, which is currently the default).

This would mean that all vcpus would share the same socket.  credit2
has some mechanisms in place to make sure that vcpus don't migrate
between processors too frequently; but all the vcpus would be sharing
the same credit mechanism.

Strangely enough, this setup tilted things *very much* in favor of workload A:

credit (run 1):
  A: 292Mops
  B: 353Mops
credit (run 2):
 A: 255Mops
 B: 386Mops
credit2, core:
  A: 241Mops
  B: 396Mops
credit2, socket:
  A: 335Mops
  B: 304Mops

In the credit2 socket case, workload A vcpus got even less -about 50%
each -- while workload B got even more: about 100% each.

It makes me wonder if in this case the *lack* of balancing is actually
the issue: we have resistance to migrating things between cpus even
within one runqueue, so if the initial placement put things on {A,A}
{B,B}, without the overloading to prompt migration, they might never
migrate away.  This needs some more looking into.

FWIW as things get more overloaded this effect goes away -- the
throughput is similar but the variance gets even lower.

 -George

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

[Xen-devel] [PATCH v2] libxl: return any serial tty path in libxl_console_get_tty

[Bob Liu]

When specifying a serial list in domain config, users of
libxl_console_get_tty cannot get the tty path of a second specified pty serial,
since right now it always returns the tty path of serial 0.

Signed-off-by: Bob Liu 
---
v2: Rename the patch title.
---
 tools/libxl/libxl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 2cf7451..00af286 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1795,7 +1795,7 @@ int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, 
int cons_num,
 
 switch (type) {
 case LIBXL_CONSOLE_TYPE_SERIAL:
-tty_path = GCSPRINTF("%s/serial/0/tty", dom_path);
+tty_path = GCSPRINTF("%s/serial/%d/tty", dom_path, cons_num);
 break;
 case LIBXL_CONSOLE_TYPE_PV:
 if (cons_num == 0)
-- 
1.7.10.4


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 478f50990a9a3b76524fd14f2085b9f1127fa41a
baseline version:
 ovmf 87ee6390cbeb2d15490943bca2978f166f213c13

Last test of basis99923  2016-08-03 14:15:11 Z0 days
Testing same since99931  2016-08-03 19:22:27 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-unstable baseline-only test] 66907: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66907 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66907/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 14 guest-saverestorefail blocked in 66891
 build-i386-rumpuserxen6 xen-buildfail   like 66891
 build-amd64-rumpuserxen   6 xen-buildfail   like 66891
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66891
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 66891
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66891

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 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 xen  e9522e4932aaa7f083688b6612b5897839409260
baseline version:
 xen  2eee1c746af6f683247700642786b7c21c991234

Last test of basis66891  2016-08-03 00:17:21 Z0 days
Testing same since66907  2016-08-03 16:14:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Juergen Gross 
  Kevin Tian 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 87ee6390cbeb2d15490943bca2978f166f213c13
baseline version:
 ovmf e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d

Last test of basis66904  2016-08-03 13:16:29 Z0 days
Testing same since66909  2016-08-03 19:20:04 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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


Push not applicable.


commit 87ee6390cbeb2d15490943bca2978f166f213c13
Author: Ard Biesheuvel 
Date:   Wed Aug 3 10:11:29 2016 +0200

ArmVirtPkg ARM: make relocatable PrePi users build with CLANG35

The clang developers have made a backward incompatible change to the
command line arguments, and have replaced '-mllvm -arm-use-movt=0'
with '-mno-movt'. This does not matter for most ARM platforms, and
therefore it has been removed from the default CLANG35/ARM CC flags
in patch 1c63516075b3 ("BaseTools CLANG35: drop problematic use-movt
and save-temps options"), but as it turns out, the relocatable PrePi
implementation used by ArmVirtQemuKernel and ArmVirtXen will fail to
build if it contains MOVT/MOVW pairs, due to the fact that these are
not runtime relocatable under ELF.

Since they are runtime relocatable under PE/COFF, and GenFw does the
right thing when encountering them, selectively controlling their
use is more appropriate than disabling them altogether. Therefore,
this patch adds the -mno-movt argument only for the platforms that
use the relocatable PrePi, and only for the module types that may
be pulled into its build.

In addition, switch to the SEC type version of ArmLib, so that
the relocatable PrePi only depends on BASE and SEC type libraries.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Leif Lindholm 

commit f846969796d311d01e8ba7527a6f50b5a246a9e8
Author: Ard Biesheuvel 
Date:   Wed Aug 3 10:10:17 2016 +0200

EmbeddedPkg: make PrePiMemoryAllocationLib a SEC type library

This library is only used by the various PrePi implementations, all of
which are of type SEC. So make this library SEC as well. This may affect
the build options used by the platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
Reviewed-by: Leif Lindholm 

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

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

[Konrad Rzeszutek Wilk]

> > 1.4 clwb/clflushopt
> > 
> >  Writes to NVDIMM may be cached by caches, so certain flushing
> >  operations should be performed to make them persistent on
> >  NVDIMM. clwb is used in favor of clflushopt and clflush to flush
> >  writes from caches to memory.
> > 
> >  Details of clwb/clflushopt can be found in Chapter 10 of [6].
> 
> Didn't that opcode get dropped in favour of poking in some register?

Nevermind. I got this confused with pcommit which was deprecated.

But looking at chapter 10.2.2 it mentions that to commit to
persistent memory you need to use pcommit. So what is the story here?
.. snip...
> >  A part not put in above figure is enabling guest clwb/clflushopt
> >  which exposes those instructions to guest via guest cpuid.
> 
> And aren't those deprecated?

And again. Ignore that comment.
.. snip..
> > 4. Design of vNVDIMM in Xen
> > 
> >  As KVM/QEMU, our design currently only provides pmem vNVDIMM.
> > 
> >  Similarly to that in KVM/QEMU, enabling vNVDIMM in Xen is composed of
> >  three parts:
> >  (1) Guest clwb/clflushopt enabling,
> >  (2) pmem address management, and
> >  (3) Guest ACPI emulation.
> > 
> >  The rest of this section present the design of each part
> >  respectively. The basic design principle to reuse existing code in
> >  Linux NVDIMM driver, QEMU and Xen as much as possible.
> > 
> > 
> > 4.1 Guest clwb/clflushopt Enabling
> > 
> >  The instruction enabling is simple and we do the same work as in KVM/QEMU:
> >  - clwb/clflushopt are exposed to guest via guest cpuid.
> > 
> 
> Again, isn't that deprecated and the new mechanism (pokng at some register)
> has to be used?

So clflushopt can be used for flushing out a cacheline. But what
to do about store in the non-volatile memory? I recall that you could
do an sfence and then pcommit, which would be aking to an SCSI SYNC
command.

But with pcommit being deprecated (albeit the URL you pointed too
still lists pcommit) - at least in Xen and Linux - how do you
enforce this wholesale flush?

Thanks!

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  730ee51d36a6b2902c01cd39bc0a6156bb5ac4ea
baseline version:
 xen  ab8fc3937eeb9332b83d7e14d81e37f0b0ef1841

Last test of basis99929  2016-08-03 18:03:06 Z0 days
Testing same since99932  2016-08-03 21:02:18 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[George Dunlap]

On Wed, Aug 3, 2016 at 4:37 PM, Jan Beulich  wrote:
 On 03.08.16 at 17:28,  wrote:
>> On 03/08/16 16:25, Jan Beulich wrote:
>> On 03.08.16 at 17:11,  wrote:
 On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
 On 02.08.16 at 17:49,  wrote:
>> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
>>> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
 As this is for the construction of dom0, it would be better to take a
 preemptible pointer, loop in construct_dom0(), with a
 process_pending_softirqs() call in between.
>>>
>>> Now fixed.
>>
>> Hm, I have to stand corrected, using hypercall_preempt_check (as
>> any of the *_set_allocation function use), is not safe at this point:
>>
>> (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
>> (XEN) CPU:0
>> (XEN) RIP:e008:[]
 hap.c#local_events_need_delivery+0x27/0x40
>> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
>> (XEN) rax:    rbx: 83023f5a5000   rcx: 
>> 82d080312900
>> (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 
>> 8300b213d000
>> (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  
>> 0180
>> (XEN) r9:     r10: 00247000   r11: 
>> 82d08029a5b0
>> (XEN) r12: 0011   r13: 23ac   r14: 
>> 82d080307d4c
>> (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 
>> 001526e0
>> (XEN) cr3: b20fc000   cr2: 
>> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>> (XEN) Xen code around 
 (hap.c#local_events_need_delivery+0x27/0x40):
>> (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 
>> 02 31
 c0
>> (XEN) Xen stack trace from rsp=82d080307cc8:
>> (XEN)82d080307d08 82d08022fc47  
>> 83023f5a5000
>> (XEN)83023f5a5648  82d080307d4c 
>> 2400
>> (XEN)82d080307d38 82d08020008c 000d 
>> 8300b1efd000
>> (XEN)83023f5a5000 82d080307d4c 82d080307d78 
>> 82d0802cad30
>> (XEN)00203000 83023f5a5000 82d0802bf860 
>> 
>> (XEN)0001 8308bef0 82d080307de8 
>> 82d0802c91e0
>> (XEN)82d080307de8 82d080143900 82d080307de8 
>> 
>> (XEN)8308bf00 82d0802eb480 82d080307dc4 
>> 82d08028b1cd
>> (XEN)8308bf00  0001 
>> 83023f5a5000
>> (XEN)82d080307f08 82d0802bf0c9  
>> 
>> (XEN) 82d080307f18 8308bee0 
>> 0001
>> (XEN)0001 0001  
>> 0010
>> (XEN)0001 00247000 8308bef4 
>> 0010
>> (XEN)8301 00247001 0014 
>> 0001
>> (XEN)8300ffec 8308bef0 82d0802e0640 
>> 8308bfb0
>> (XEN)  0111 
>> 0008
>> (XEN)0001006e 0003 02f8 
>> 
>> (XEN)ad5c0bd0  0001 
>> 0008
>> (XEN) 82d080100073  
>> 
>> (XEN)   
>> 
>> (XEN) Xen call trace:
>> (XEN)[] hap.c#local_events_need_delivery+0x27/0x40
>> (XEN)[] hap_set_allocation+0x107/0x130
>> (XEN)[] paging_set_allocation+0x4c/0x80
>> (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
>> (XEN)[] 
>> domain_build.c#construct_dom0_hvm+0x60/0x120
>> (XEN)[] __start_xen+0x1ea9/0x23a0
>> (XEN)[] __high_start+0x53/0x60
>> (XEN)
>> (XEN) Pagetable walk from :
>
> Sadly you don't make clear what pointer it is that is NULL at that point.

 It sounds from what he says in the following paragraph like current is 
 NULL.
>>>
>>> I don't recall us re-setting current to this late in the boot process.
>>> Even during early boot we set it to a bogus non-NULL value rather
>>> than NULL.
>>>
>> I've tried setting current to d->vcpu[0], but that just makes the call to
>> hypercall_preempt_check crash in some scheduler assert. In any case, I've
>> added the preempt parameter to the paging_set_allocation function, but I
>> don't plan to use it in the 

Re: [Xen-devel] [RFC Design Doc v2] Add vNVDIMM support for Xen

[Konrad Rzeszutek Wilk]

On Mon, Jul 18, 2016 at 08:29:12AM +0800, Haozhong Zhang wrote:
> Hi,
> 

Hey!

Thanks for posting! Sorry for the late review. Below are some of my
comment.

> Following is version 2 of the design doc for supporting vNVDIMM in
> Xen. It's basically the summary of discussion on previous v1 design
> (https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg6.html).
> Any comments are welcome. The corresponding patches are WIP.
> 
> Thanks,
> Haozhong
> 
> 
> 
> vNVDIMM Design v2
> 
> Changes in v2:
>  - Rewrite the the design details based on previous discussion [7].
>  - Add Section 3 Usage Example of vNVDIMM in Xen.
>  - Remove content about pcommit instruction which has been deprecated [8].
> 
> Content
> ===
> 1. Background
>  1.1 Access Mechanisms: Persistent Memory and Block Window
>  1.2 ACPI Support
>   1.2.1 NFIT
>   1.2.2 _DSM and _FIT
>  1.3 Namespace
>  1.4 clwb/clflushopt
> 2. NVDIMM/vNVDIMM Support in Linux Kernel/KVM/QEMU
>  2.1 NVDIMM Driver in Linux Kernel
>  2.2 vNVDIMM Implementation in KVM/QEMU
> 3. Usage Example of vNVDIMM in Xen
> 4. Design of vNVDIMM in Xen
>  4.1 Guest clwb/clflushopt Enabling
>  4.2 pmem Address Management
>   4.2.1 Reserve Storage for Management Structures
>   4.2.2 Detection of Host pmem Devices
>   4.2.3 Get Host Machine Address (SPA) of Host pmem Files
>   4.2.4 Map Host pmem to Guests
>   4.2.5 Misc 1: RAS
>   4.2.6 Misc 2: hotplug
>  4.3 Guest ACPI Emulation
>   4.3.1 Building Guest ACPI Tables
>   4.3.2 Emulating Guest _DSM
> References
> 
> 
> Non-Volatile DIMM or NVDIMM is a type of RAM device that provides
> persistent storage and retains data across reboot and even power
> failures. This document describes the design to provide virtual NVDIMM
> devices or vNVDIMM in Xen.
> 
> The rest of this document is organized as below.
>  - Section 1 introduces the background knowledge of NVDIMM hardware,
>which is used by other parts of this document.
> 
>  - Section 2 briefly introduces the current/future NVDIMM/vNVDIMM
>support in Linux kernel/KVM/QEMU. They will affect the vNVDIMM
>design in Xen.
> 
>  - Section 3 shows the basic usage example of vNVDIMM in Xen.
> 
>  - Section 4 proposes design details of vNVDIMM in Xen.
> 
> 
> 
> 1. Background
> 
> 1.1 Access Mechanisms: Persistent Memory and Block Window
> 
>  NVDIMM provides two access mechanisms: byte-addressable persistent
>  memory (pmem) and block window (pblk). An NVDIMM can contain multiple
>  ranges and each range can be accessed through either pmem or pblk
>  (but not both).
> 
>  Byte-addressable persistent memory mechanism (pmem) maps NVDIMM or
>  ranges of NVDIMM into the system physical address (SPA) space, so
>  that software can access NVDIMM via normal memory loads and
>  stores. If the virtual address is used, then MMU will translate it to
>  the physical address.
> 
>  In the virtualization circumstance, we can pass through a pmem range
>  or partial of it to a guest by mapping it in EPT (i.e. mapping guest
>  vNVDIMM physical address to host NVDIMM physical address), so that
>  guest accesses are applied directly to the host NVDIMM device without
>  hypervisor's interceptions.
> 
>  Block window mechanism (pblk) provides one or multiple block windows
>  (BW).  Each BW is composed of a command register, a status register
>  and a 8 Kbytes aperture register. Software fills the direction of the
>  transfer (read/write), the start address (LBA) and size on NVDIMM it
>  is going to transfer. If nothing goes wrong, the transferred data can
>  be read/write via the aperture register. The status and errors of the
>  transfer can be got from the status register. Other vendor-specific
>  commands and status can be implemented for BW as well. Details of the
>  block window access mechanism can be found in [3].
> 
>  In the virtualization circumstance, different pblk regions on a
>  single NVDIMM device may be accessed by different guests, so the
>  hypervisor needs to emulate BW, which would introduce a high overhead
>  for I/O intensive workload.
> 
>  Therefore, we are going to only implement pmem for vNVDIMM. The rest
>  of this document will mostly concentrate on pmem.
> 
> 
> 1.2 ACPI Support
> 
>  ACPI provides two factors of support for NVDIMM. First, NVDIMM
>  devices are described by firmware (BIOS/EFI) to OS via ACPI-defined
>  NVDIMM Firmware Interface Table (NFIT). Second, several functions of
>  NVDIMM, including operations on namespace labels, S.M.A.R.T and
>  hotplug, are provided by ACPI methods (_DSM and _FIT).
> 
> 1.2.1 NFIT
> 
>  NFIT is a new system description table added in ACPI v6 with
>  signature "NFIT". It contains a set of structures.
> 
>  - System Physical Address Range Structure
>(SPA Range Structure)
> 
>SPA range structure describes system physical address ranges
>occupied by NVDIMMs and types of regions.
> 
>If Address Range Type GUID field of a SPA range structure is "Byte
>Addressable Persistent Memory (PM) Region", 

Re: [Xen-devel] [PATCH v2 Altp2m cleanup 0/3] Cleaning up altp2m code

[Lai, Paul C]

Please disregard this submission for review.
I forgot to rebase to current master and this patch is against a code base that 
is out of date.

Apologies for the noise.

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Paul Lai
Sent: Wednesday, August 3, 2016 12:17 PM
To: xen-de...@lists.xensource.com
Cc: dunl...@gmail.com; Sahita, Ravi ; jbeul...@suse.com
Subject: [Xen-devel] [PATCH v2 Altp2m cleanup 0/3] Cleaning up altp2m code

Incorporating comments from v1 altp2m clean code URLs:
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03223.html
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03465.html
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03467.html

Older comments, reason for the code clean effort, are the following URLs:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04530.html

Paul Lai (3):
  altp2m cleanup work
  Move altp2m specific functions to altp2m files.
  Making altp2m struct dynamically allocated.


 xen/arch/x86/hvm/hvm.c|  54 +---
 xen/arch/x86/hvm/vmx/vmx.c|   2 +-
 xen/arch/x86/mm/altp2m.c  |  45 +
 xen/arch/x86/mm/hap/hap.c |  35 ++---
 xen/arch/x86/mm/mm-locks.h|   4 +-
 xen/arch/x86/mm/p2m-ept.c |  39 ++
 xen/arch/x86/mm/p2m.c | 104 +-
 xen/include/asm-x86/altp2m.h  |  11 +++-
 xen/include/asm-x86/domain.h  |   5 +-
 xen/include/asm-x86/hvm/hvm.h |  19 +--
 xen/include/asm-x86/hvm/vmx/vmx.h |   3 ++
 xen/include/asm-x86/p2m.h |  18 ---
 12 files changed, 193 insertions(+), 146 deletions(-)

-- 
2.7.4


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

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

[Andrew Cooper]

On 03/08/2016 22:00, Razvan Cojocaru wrote:
> On 08/03/16 23:44, Andrew Cooper wrote:
>> On 03/08/2016 21:37, Bread Cutter wrote:
>>> Hello all,
>>>
>>> I'm writing an executable that runs inside of a guest, and I planned
>>> to use vmcall to talk to a tool running in Dom0, using the vm_event
>>> API. It didn't work, and looking through the code, the first thing
>>> hvm_do_hypercall() does is check if the guest is in ring0. If not, it
>>> returns EPERM and exits.
>>>
>>> In the case of HVMOP_guest_request_vm_event, I'd rather it be up to my
>>> code if a call can be made from CPL>0. Is this done intentionally?
>> In general, allowing hypercalls from user context is unsafe, and the
>> subject of several arguments in the past.
>>
>> However, in this specific case there are plenty of ways for userspace to
>> get the attention of an introspection agent, although in inefficient
>> ways.  As such, blocking access is pointless.  In XenServer, we have
>> whitelisted that specific hypercall.
>>
>> You want something like:
>>
>> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
>> index c1b8392..c7a2cdf 100644
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -5194,8 +5194,14 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>>  switch ( mode )
>>  {
>>  case 8:   
>> +if ( eax == __HYPERVISOR_hvm_op &&
>> + regs->rdi == HVMOP_guest_request_vm_event )
>> +break;
>>  case 4:
>>  case 2:
>> +if ( eax == __HYPERVISOR_hvm_op &&
>> + regs->ebx == HVMOP_guest_request_vm_event )
>> +break;
>>  hvm_get_segment_register(curr, x86_seg_ss, );
>>  if ( unlikely(sreg.attr.fields.dpl) )
>> {
> Indeed, if everyone agrees that the patch is acceptable I'm happy to
> send it to xen-devel. It'd obviously be great if this ends up upstream.

A +1 from me, but there is substantial resistance from others, which is
what stopped my previous attempt to allow a kernel to opt in to allowing
userspace hypercalls.

~Andrew

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

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

[Razvan Cojocaru]

On 08/03/16 23:44, Andrew Cooper wrote:
> On 03/08/2016 21:37, Bread Cutter wrote:
>> Hello all,
>>
>> I'm writing an executable that runs inside of a guest, and I planned
>> to use vmcall to talk to a tool running in Dom0, using the vm_event
>> API. It didn't work, and looking through the code, the first thing
>> hvm_do_hypercall() does is check if the guest is in ring0. If not, it
>> returns EPERM and exits.
>>
>> In the case of HVMOP_guest_request_vm_event, I'd rather it be up to my
>> code if a call can be made from CPL>0. Is this done intentionally?
> 
> In general, allowing hypercalls from user context is unsafe, and the
> subject of several arguments in the past.
> 
> However, in this specific case there are plenty of ways for userspace to
> get the attention of an introspection agent, although in inefficient
> ways.  As such, blocking access is pointless.  In XenServer, we have
> whitelisted that specific hypercall.
> 
> You want something like:
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index c1b8392..c7a2cdf 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -5194,8 +5194,14 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
>  switch ( mode )
>  {
>  case 8:   
> +if ( eax == __HYPERVISOR_hvm_op &&
> + regs->rdi == HVMOP_guest_request_vm_event )
> +break;
>  case 4:
>  case 2:
> +if ( eax == __HYPERVISOR_hvm_op &&
> + regs->ebx == HVMOP_guest_request_vm_event )
> +break;
>  hvm_get_segment_register(curr, x86_seg_ss, );
>  if ( unlikely(sreg.attr.fields.dpl) )
> {

Indeed, if everyone agrees that the patch is acceptable I'm happy to
send it to xen-devel. It'd obviously be great if this ends up upstream.


Thanks,
Razvan

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

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

[Andrew Cooper]

On 03/08/2016 21:37, Bread Cutter wrote:
> Hello all,
>
> I'm writing an executable that runs inside of a guest, and I planned
> to use vmcall to talk to a tool running in Dom0, using the vm_event
> API. It didn't work, and looking through the code, the first thing
> hvm_do_hypercall() does is check if the guest is in ring0. If not, it
> returns EPERM and exits.
>
> In the case of HVMOP_guest_request_vm_event, I'd rather it be up to my
> code if a call can be made from CPL>0. Is this done intentionally?

In general, allowing hypercalls from user context is unsafe, and the
subject of several arguments in the past.

However, in this specific case there are plenty of ways for userspace to
get the attention of an introspection agent, although in inefficient
ways.  As such, blocking access is pointless.  In XenServer, we have
whitelisted that specific hypercall.

You want something like:

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index c1b8392..c7a2cdf 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5194,8 +5194,14 @@ int hvm_do_hypercall(struct cpu_user_regs *regs)
 switch ( mode )
 {
 case 8:   
+if ( eax == __HYPERVISOR_hvm_op &&
+ regs->rdi == HVMOP_guest_request_vm_event )
+break;
 case 4:
 case 2:
+if ( eax == __HYPERVISOR_hvm_op &&
+ regs->ebx == HVMOP_guest_request_vm_event )
+break;
 hvm_get_segment_register(curr, x86_seg_ss, );
 if ( unlikely(sreg.attr.fields.dpl) )
{

~Andrew

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

Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

[Stefano Stabellini]

On Wed, 3 Aug 2016, Stefano Stabellini wrote:
> On Wed, 3 Aug 2016, Wei Liu wrote:
> > > # PV Calls Protocol
> > > 
> > > ## Rationale
> > > 
> > > PV Calls is a paravirtualized protocol for the POSIX socket API.
> > > 
> > > The purpose of PV Calls is to allow the implementation of a specific set
> > > of POSIX functions to be done in a domain other than your own. It allows
> > > connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be
> > > implemented in another domain.
> > > 
> > 
> > The wording isn't really clear here. This design document as-is would
> > inevitably make people start to compare PV Calls to various HV socks I'm
> > afraid.
> 
> You are right, thanks for the feedback. I'll clarify it.

Actually there are quite a few things I should change to make this
document more generic. They'll be in the next version.
 
 
> > Is PV Calls going to cover other stuff other than socket API? If it
> > targets POSIX interfaces, maybe call it PV POSIX?
> > 
> > But then, if you extend the scope to cover POSIX APIs, I think you might
> > want some discovery mechanism to see what APIs are paravirtualised?
> 
> Yes, it can potentially cover other interfaces -- I have a couple of
> ideas in that area but I need to do some experiments first.
> 
> I fully agree that we need a discovery mechanism. What it is briefly
> covered by this document, is that if a cmd is not supported by the
> backend, ret is ENOTSUPP. But maybe we could also add a version node to
> xenstore, that could be used to version the protocol supported by the
> backend.


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

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

[Bread Cutter]

Hello all,

I'm writing an executable that runs inside of a guest, and I planned
to use vmcall to talk to a tool running in Dom0, using the vm_event
API. It didn't work, and looking through the code, the first thing
hvm_do_hypercall() does is check if the guest is in ring0. If not, it
returns EPERM and exits.

In the case of HVMOP_guest_request_vm_event, I'd rather it be up to my
code if a call can be made from CPL>0. Is this done intentionally?

Thanks!

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

[Xen-devel] [PATCH v2 Altp2m cleanup 1/3] altp2m cleanup work

[Paul Lai]

Indent goto labels by one space
Inline (header) altp2m functions
Define default behavior in switch
Define max and min for range of altp2m macroed values

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c| 46 ---
 xen/include/asm-x86/hvm/hvm.h | 19 +++---
 2 files changed, 37 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 22f045e..69daa29 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1926,11 +1926,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  * Otherwise, this is an error condition. */
 rc = fall_through;
 
-out_put_gfn:
+ out_put_gfn:
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
 __put_gfn(hostp2m, gfn);
-out:
+ out:
 /* All of these are delayed until we exit, since we might 
  * sleep on event ring wait queues, and we must not hold
  * locks in such circumstance */
@@ -5207,12 +5207,25 @@ static int do_altp2m_op(
 return -EFAULT;
 
 if ( a.pad1 || a.pad2 ||
- (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
- (a.cmd < HVMOP_altp2m_get_domain_state) ||
- (a.cmd > HVMOP_altp2m_change_gfn) )
+(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) )
 return -EINVAL;
 
-d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+switch( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+case HVMOP_altp2m_set_domain_state:
+case HVMOP_altp2m_vcpu_enable_notify:
+case HVMOP_altp2m_create_p2m:
+case HVMOP_altp2m_destroy_p2m:
+case HVMOP_altp2m_switch_p2m:
+case HVMOP_altp2m_set_mem_access:
+case HVMOP_altp2m_change_gfn:
+break;
+default:
+return -ENOSYS;
+}
+
+d = ( a.cmd != HVMOP_altp2m_vcpu_enable_notify ) ?
 rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
 
 if ( d == NULL )
@@ -5329,6 +5342,8 @@ static int do_altp2m_op(
 rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
 _gfn(a.u.change_gfn.old_gfn),
 _gfn(a.u.change_gfn.new_gfn));
+default:
+return -EINVAL;
 }
 
  out:
@@ -5816,25 +5831,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
 v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step;
 }
 
-void altp2m_vcpu_update_p2m(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_p2m )
-hvm_funcs.altp2m_vcpu_update_p2m(v);
-}
-
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
-hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
-}
-
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_emulate_ve )
-return hvm_funcs.altp2m_vcpu_emulate_ve(v);
-return 0;
-}
-
 int hvm_set_mode(struct vcpu *v, int mode)
 {
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index f486ee9..231c921 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -589,13 +589,26 @@ static inline bool_t hvm_altp2m_supported(void)
 }
 
 /* updates the current hardware p2m */
-void altp2m_vcpu_update_p2m(struct vcpu *v);
+static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_p2m )
+hvm_funcs.altp2m_vcpu_update_p2m(v);
+}
 
 /* updates VMCS fields related to VMFUNC and #VE */
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v);
+static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
+hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+}
 
 /* emulates #VE */
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
+static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_emulate_ve )
+return hvm_funcs.altp2m_vcpu_emulate_ve(v);
+return 0;
+}
 
 /* Check CR4/EFER values */
 const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
-- 
2.7.4


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

[Xen-devel] [PATCH v2 Altp2m cleanup 3/3] Making altp2m struct dynamically allocated.

[Paul Lai]

Ravi Sahita's dynamically allocated altp2m structs

Signed-off-by: Paul Lai 
Reviewed-by: Ravi Sahita 
---
 xen/arch/x86/hvm/hvm.c   |  8 +++---
 xen/arch/x86/hvm/vmx/vmx.c   |  2 +-
 xen/arch/x86/mm/altp2m.c | 18 ++---
 xen/arch/x86/mm/mm-locks.h   |  4 +--
 xen/arch/x86/mm/p2m-ept.c|  8 +++---
 xen/arch/x86/mm/p2m.c| 61 
 xen/include/asm-x86/altp2m.h |  7 -
 xen/include/asm-x86/domain.h |  5 +---
 xen/include/asm-x86/p2m.h|  9 ++-
 9 files changed, 69 insertions(+), 53 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 69daa29..8a824f9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5239,7 +5239,7 @@ static int do_altp2m_op(
 
 if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
  (a.cmd != HVMOP_altp2m_set_domain_state) &&
- !d->arch.altp2m_active )
+ !altp2m_active(d) )
 {
 rc = -EOPNOTSUPP;
 goto out;
@@ -5273,11 +5273,11 @@ static int do_altp2m_op(
 break;
 }
 
-ostate = d->arch.altp2m_active;
-d->arch.altp2m_active = !!a.u.domain_state.state;
+ostate = altp2m_active(d);
+set_altp2m_active(d, !!a.u.domain_state.state);
 
 /* If the alternate p2m state has changed, handle appropriately */
-if ( d->arch.altp2m_active != ostate &&
+if ( altp2m_active(d) != ostate &&
  (ostate || !(rc = p2m_init_altp2m_by_id(d, 0))) )
 {
 for_each_vcpu( d, v )
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index 670d7dc..b522578 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2017,7 +2017,7 @@ static void vmx_vcpu_update_vmfunc_ve(struct vcpu *v)
 {
 v->arch.hvm_vmx.secondary_exec_control |= mask;
 __vmwrite(VM_FUNCTION_CONTROL, VMX_VMFUNC_EPTP_SWITCHING);
-__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m_eptp));
+__vmwrite(EPTP_LIST_ADDR, virt_to_maddr(d->arch.altp2m->altp2m_eptp));
 
 if ( cpu_has_vmx_virt_exceptions )
 {
diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index ec812dd..23f995c 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -73,23 +73,23 @@ hvm_altp2m_init( struct domain *d)
 unsigned int i = 0;
 
 /* Init alternate p2m data. */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+if ( (d->arch.altp2m->altp2m_eptp = alloc_xenheap_page()) == NULL )
 {
 rc = -ENOMEM;
 goto out;
 }
 
 for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = INVALID_MFN;
+d->arch.altp2m->altp2m_eptp[i] = INVALID_MFN;
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
 {
-rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+rc = p2m_alloc_table(d->arch.altp2m->altp2m_p2m[i]);
 if ( rc != 0 )
goto out;
 }
 
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, 0);
  out:
 return rc;
 }
@@ -98,16 +98,16 @@ void
 hvm_altp2m_teardown( struct domain *d)
 {
 unsigned int i = 0;
-d->arch.altp2m_active = 0;
+set_altp2m_active(d, 0);
 
-if ( d->arch.altp2m_eptp )
+if ( d->arch.altp2m->altp2m_eptp )
 {
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
+free_xenheap_page(d->arch.altp2m->altp2m_eptp);
+d->arch.altp2m->altp2m_eptp = NULL;
 }
 
 for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
+p2m_teardown(d->arch.altp2m->altp2m_p2m[i]);
 }
 
 /*
diff --git a/xen/arch/x86/mm/mm-locks.h b/xen/arch/x86/mm/mm-locks.h
index 086c8bb..4d17b0a 100644
--- a/xen/arch/x86/mm/mm-locks.h
+++ b/xen/arch/x86/mm/mm-locks.h
@@ -251,8 +251,8 @@ declare_mm_rwlock(p2m);
  */
 
 declare_mm_lock(altp2mlist)
-#define altp2m_list_lock(d)   mm_lock(altp2mlist, &(d)->arch.altp2m_list_lock)
-#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m_list_lock)
+#define altp2m_list_lock(d)   mm_lock(altp2mlist, 
&(d)->arch.altp2m->altp2m_list_lock)
+#define altp2m_list_unlock(d) mm_unlock(&(d)->arch.altp2m->altp2m_list_lock)
 
 /* P2M lock (per-altp2m-table)
  *
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index b68806d..3fa4923 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1331,14 +1331,14 @@ void setup_ept_dump(void)
 
 void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)
 {
-struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct p2m_domain *p2m = d->arch.altp2m->altp2m_p2m[i];
 struct ept_data *ept;
 
 p2m->min_remapped_gfn = INVALID_GFN;
 p2m->max_remapped_gfn = 0;
 ept = >ept;
 ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
-d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+d->arch.altp2m->altp2m_eptp[i] = ept_get_eptp(ept);
 }
 
 unsigned int 

[Xen-devel] [PATCH v2 Altp2m cleanup 2/3] Move altp2m specific functions to altp2m files.

[Paul Lai]

Move altp2m specific functions to altp2m files.  This makes the code
a little easier to read.

Also moving ept code to ept specific files as requested in:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html

Signed-off-by: Paul Lai 
---
 xen/arch/x86/mm/altp2m.c  | 45 +++
 xen/arch/x86/mm/hap/hap.c | 35 +-
 xen/arch/x86/mm/p2m-ept.c | 39 +
 xen/arch/x86/mm/p2m.c | 45 +++
 xen/include/asm-x86/altp2m.h  |  4 +++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 +++
 xen/include/asm-x86/p2m.h |  9 +++-
 7 files changed, 101 insertions(+), 79 deletions(-)

diff --git a/xen/arch/x86/mm/altp2m.c b/xen/arch/x86/mm/altp2m.c
index 10605c8..ec812dd 100644
--- a/xen/arch/x86/mm/altp2m.c
+++ b/xen/arch/x86/mm/altp2m.c
@@ -17,6 +17,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -65,6 +66,50 @@ altp2m_vcpu_destroy(struct vcpu *v)
 vcpu_unpause(v);
 }
 
+int
+hvm_altp2m_init( struct domain *d)
+{
+int rc = 0;
+unsigned int i = 0;
+
+/* Init alternate p2m data. */
+if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
+{
+rc = -ENOMEM;
+goto out;
+}
+
+for ( i = 0; i < MAX_EPTP; i++ )
+d->arch.altp2m_eptp[i] = INVALID_MFN;
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
+if ( rc != 0 )
+   goto out;
+}
+
+d->arch.altp2m_active = 0;
+ out:
+return rc;
+}
+
+void
+hvm_altp2m_teardown( struct domain *d)
+{
+unsigned int i = 0;
+d->arch.altp2m_active = 0;
+
+if ( d->arch.altp2m_eptp )
+{
+free_xenheap_page(d->arch.altp2m_eptp);
+d->arch.altp2m_eptp = NULL;
+}
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+p2m_teardown(d->arch.altp2m_p2m[i]);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index 9c2cd49..07833b7 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -501,24 +502,9 @@ int hap_enable(struct domain *d, u32 mode)
 
 if ( hvm_altp2m_supported() )
 {
-/* Init alternate p2m data */
-if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
-{
-rv = -ENOMEM;
-goto out;
-}
-
-for ( i = 0; i < MAX_EPTP; i++ )
-d->arch.altp2m_eptp[i] = INVALID_MFN;
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-{
-rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
-if ( rv != 0 )
-   goto out;
-}
-
-d->arch.altp2m_active = 0;
+rv = hvm_altp2m_init(d);
+if ( rv != 0 )
+   goto out;
 }
 
 /* Now let other users see the new mode */
@@ -534,18 +520,7 @@ void hap_final_teardown(struct domain *d)
 unsigned int i;
 
 if ( hvm_altp2m_supported() )
-{
-d->arch.altp2m_active = 0;
-
-if ( d->arch.altp2m_eptp )
-{
-free_xenheap_page(d->arch.altp2m_eptp);
-d->arch.altp2m_eptp = NULL;
-}
-
-for ( i = 0; i < MAX_ALTP2M; i++ )
-p2m_teardown(d->arch.altp2m_p2m[i]);
-}
+hvm_altp2m_teardown(d);
 
 /* Destroy nestedp2m's first */
 for (i = 0; i < MAX_NESTEDP2M; i++) {
diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
index 7166c71..b68806d 100644
--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -1329,6 +1329,45 @@ void setup_ept_dump(void)
 register_keyhandler('D', ept_dump_p2m_table, "dump VT-x EPT tables", 0);
 }
 
+void p2m_init_altp2m_ept_helper( struct domain *d, unsigned int i)
+{
+struct p2m_domain *p2m = d->arch.altp2m_p2m[i];
+struct ept_data *ept;
+
+p2m->min_remapped_gfn = INVALID_GFN;
+p2m->max_remapped_gfn = 0;
+ept = >ept;
+ept->asr = pagetable_get_pfn(p2m_get_pagetable(p2m));
+d->arch.altp2m_eptp[i] = ept_get_eptp(ept);
+}
+
+unsigned int p2m_find_altp2m_by_eptp(struct domain *d, uint64_t eptp)
+{
+struct p2m_domain *p2m;
+struct ept_data *ept;
+unsigned int i;
+
+altp2m_list_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_eptp[i] == INVALID_MFN )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+ept = >ept;
+
+if ( eptp == ept_get_eptp(ept) )
+goto out;
+}
+
+i = INVALID_ALTP2M;
+
+ out:
+altp2m_list_unlock(d);
+return i;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 89462b2..b48cf4b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -196,8 +196,8 @@ static void p2m_teardown_altp2m(struct domain *d)
 if ( 

[Xen-devel] [PATCH v2 Altp2m cleanup 0/3] Cleaning up altp2m code

[Paul Lai]

Incorporating comments from v1 altp2m clean code URLs:
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03223.html
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03465.html
  https://lists.xenproject.org/archives/html/xen-devel/2016-06/msg03467.html

Older comments, reason for the code clean effort, are the following URLs:
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04323.html
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04454.html
  https://lists.xenproject.org/archives/html/xen-devel/2015-07/msg04530.html

Paul Lai (3):
  altp2m cleanup work
  Move altp2m specific functions to altp2m files.
  Making altp2m struct dynamically allocated.


 xen/arch/x86/hvm/hvm.c|  54 +---
 xen/arch/x86/hvm/vmx/vmx.c|   2 +-
 xen/arch/x86/mm/altp2m.c  |  45 +
 xen/arch/x86/mm/hap/hap.c |  35 ++---
 xen/arch/x86/mm/mm-locks.h|   4 +-
 xen/arch/x86/mm/p2m-ept.c |  39 ++
 xen/arch/x86/mm/p2m.c | 104 +-
 xen/include/asm-x86/altp2m.h  |  11 +++-
 xen/include/asm-x86/domain.h  |   5 +-
 xen/include/asm-x86/hvm/hvm.h |  19 +--
 xen/include/asm-x86/hvm/vmx/vmx.h |   3 ++
 xen/include/asm-x86/p2m.h |  18 ---
 12 files changed, 193 insertions(+), 146 deletions(-)

-- 
2.7.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ab8fc3937eeb9332b83d7e14d81e37f0b0ef1841
baseline version:
 xen  2615485905a34da095a2453b3991c5adba7f33da

Last test of basis99926  2016-08-03 15:01:40 Z0 days
Testing same since99929  2016-08-03 18:03:06 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  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=ab8fc3937eeb9332b83d7e14d81e37f0b0ef1841
+ . ./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 
ab8fc3937eeb9332b83d7e14d81e37f0b0ef1841
+ branch=xen-unstable-smoke
+ revision=ab8fc3937eeb9332b83d7e14d81e37f0b0ef1841
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xab8fc3937eeb9332b83d7e14d81e37f0b0ef1841 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

Re: [Xen-devel] [PATCH v6 1/7] xen/arm: Introduce alternative runtime patching

[Konrad Rzeszutek Wilk]

On Wed, Jul 27, 2016 at 05:37:05PM +0100, Julien Grall wrote:
> Some of the processor erratum will require to modify code sequence.
> As those modifications may impact the performance, they should only
> be enabled on affected cores. Furthermore, Xen may also want to take
> advantage of new hardware features coming up with v8.1 and v8.2.
> 
> This patch adds an infrastructure to patch Xen during boot time
> depending on the "features" available on the platform.
> 
> This code is based on the file arch/arm64/kernel/alternative.c in
> Linux 4.6-rc3. Any references to arm64 have been dropped to make the
> code as generic as possible.
> 
> When Xen is creating the page tables, all the executable sections
> (.text and .init.text) will be marked read-only and then enforced by
> setting SCTLR.WNX.
> 
> Whilst it might be possible to mark those entries read-only after
> Xen has been patched, we would need extra care to avoid possible
> TLBs conflicts (see D4-1732 in ARM DDI 0487A.i) as all
> physical CPUs will be running.
> 
> All the physical CPUs have to be brought up before patching Xen because
> each cores may have different errata/features which require code
> patching. The only way to find them is to probe system registers on
> each CPU.
> 
> To avoid extra complexity, it is possible to create a temporary
> writeable mapping with vmap. This mapping will be used to write the
> new instructions.
> 
> Lastly, runtime patching is currently not necessary for ARM32. So the
> code is only enabled for ARM64.
> 
> Note that the header asm-arm/alternative.h is a verbatim copy for the
> Linux one (arch/arm64/include/asm/alternative.h). It may contain
> innacurate comments, but I did not touch them for now.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> Changes in v6:
> - Update some messages
> - Constify some structure
> - Add an ASSERT in apply_alternatives

apply_alternatives_all actually.
> - Mention in the commit message that alternative is a verbatim
> copy of the Linux headers.

Thank you.

With that Reviewed-by: Konrad Rzeszutek Wilk 
> 
> Changes in v5:
> - Rebase on the latest staging
> 
> Changes in v4:
> - Fix build when ALTERNATIVE is not enabled
> - Fix typo
> - Move .altinstructions in init.data
> 
> Changes in v3:
> - .altinstr_replacement should live in init.text
> - Add a comment to explain when apply_alternatives_all should be
> called.
> 
> Changes in v2:
> - Use hard tabs in Kconfig
> - Update the copyright year
> - Update the commit message to explain the extra mapping
> ---
>  xen/arch/arm/Kconfig  |   5 +
>  xen/arch/arm/Makefile |   1 +
>  xen/arch/arm/alternative.c| 224 
> ++
>  xen/arch/arm/setup.c  |   7 ++
>  xen/arch/arm/xen.lds.S|   9 ++
>  xen/include/asm-arm/alternative.h | 165 
>  xen/include/asm-arm/arm64/insn.h  |  16 +++
>  7 files changed, 427 insertions(+)
>  create mode 100644 xen/arch/arm/alternative.c
>  create mode 100644 xen/include/asm-arm/alternative.h
> 
> diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
> index 6231cd5..0141bd9 100644
> --- a/xen/arch/arm/Kconfig
> +++ b/xen/arch/arm/Kconfig
> @@ -14,6 +14,7 @@ config ARM_64
>   def_bool y
>   depends on 64BIT
>   select HAS_GICV3
> + select ALTERNATIVE
>  
>  config ARM
>   def_bool y
> @@ -46,6 +47,10 @@ config ACPI
>  config HAS_GICV3
>   bool
>  
> +# Select ALTERNATIVE if the architecture supports runtime patching
> +config ALTERNATIVE
> + bool
> +
>  endmenu
>  
>  source "common/Kconfig"
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index b264ed4..74bd7b8 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -4,6 +4,7 @@ subdir-y += platforms
>  subdir-$(CONFIG_ARM_64) += efi
>  subdir-$(CONFIG_ACPI) += acpi
>  
> +obj-$(CONFIG_ALTERNATIVE) += alternative.o
>  obj-y += bootfdt.o
>  obj-y += cpu.o
>  obj-y += cpufeature.o
> diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
> new file mode 100644
> index 000..8ee5a11
> --- /dev/null
> +++ b/xen/arch/arm/alternative.c
> @@ -0,0 +1,224 @@
> +/*
> + * alternative runtime patching
> + * inspired by the x86 version
> + *
> + * Copyright (C) 2014-2016 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General 

Re: [Xen-devel] [PATCH v2 16/17] libxc/xc_dom_arm: Copy ACPI tables to guest space

[Julien Grall]

Hi Wei,

On 02/08/16 12:01, Wei Liu wrote:

On Thu, Jul 28, 2016 at 08:42:05PM +0800, Shannon Zhao wrote:

On 2016年07月28日 19:06, Julien Grall wrote:

On 26/07/16 02:17, Boris Ostrovsky wrote:

On 07/25/2016 07:40 PM, Stefano Stabellini wrote:

On Mon, 25 Jul 2016, Boris Ostrovsky wrote:

On 07/25/2016 06:06 PM, Stefano Stabellini wrote:

On Mon, 25 Jul 2016, George Dunlap wrote:

On Thu, Jul 21, 2016 at 10:15 PM, Stefano Stabellini
 wrote:

Going back to the discussion about how to account for the ACPI blob in
maxmem, let's make this simple, if we increase maxmem by the size of
the
ACPI blob:

- the toolstack allocates more RAM than expected (bad)
- when the admin specifies 1GB of RAM, the guest actually gets 1GB of
   usable RAM (good)
- things are faster as Xen and the guest can exploit superpage
mappings
   more easily at stage-1 and stage-2 (good)

Let's call this option A.

If we do not increase maxmem:

- the toolstack allocates less RAM, closer to the size specified in
the
   VM config file (good)
- the guest gets less usable memory than expected, less than what was
   specified in the VM config file (bad)


Not sure I agree with this, at least for x86/Linux: guest gets 1GB of
usable RAM and part of that RAM stores ACPI stuff. Guest is free to
stash ACPI tables somewhere else or ignore them altogether and use that
memory for whatever it wants.

On ARM it will be a ROM (from guest POV)



In which case I don't see why we should take it from maxmem allocation.
I somehow thought that there was a choice of whether to put it in ROM or
RAM on ARM but if it's ROM only then I don't think there is an option.


We have option to do the both on ARM. I just feel that the ROM option is
a cleaner interface because the ACPI tables are not supposed be modified
by the guest, so we can prevent to be overridden (+ all the advantages
mentioned by Stefano with option A).


IIUIC the toolstack pretends that the blob goes to memory because that's
how its interfaces work but that space is not really what we think about
when we set memory/maxmem in the configuration file. Unlike x86.


I think we need to draw a conclusion for Shannon to continue to do the
work and I would like to see this series in Xen 4.8. From my
understanding you are for option B, so does George.

Stefano votes for option A, but find B acceptable. Any other opinions?

I agree with Stefano, both are fine.



Sorry for the late reply.

Are you now unblocked? If not, what is not yet decided or needed
clarification?


I don't think there was a strict consensus. I think this is something we 
can revisit later if necessary as the guest interface does not tie up to 
a specific physical address (The UEFI firmware should retrieve the 
information from the device tree).


So, Shannon could continue towards solution A. I.e the ACPI blob is 
loaded outside of the guest RAM?


If someone disagree please speak up. But we should unblock Shannon to 
get this series in Xen 4.8.


Regards,

--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 99922: trouble: broken/fail/pass

[osstest service owner]

  broken  
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  pass
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-amd64-xl-pvh-intelfail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-armhf-armhf-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-amd64-amd64-xl-qcow2pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-i386-xl-raw   pass
 test-amd64-amd64-xl-rtds fail
 test-armhf-armhf-xl-rtds fail
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-armhf-armhf-xl-vhd  pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



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

broken-step test-armhf-armhf-xl host-install(3)

Not pushing.


commit 90f54472f407f1d0ad0ccab6f59d65b286f269b2
Merge: 8b54a6a 7005f7f
Author: Peter Maydell <peter.mayd...@linaro.org>
Date:   Wed Aug 3 11:52:53 2016 +0100

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-2.7-20160803' 
into staging

qemu-2.7: ppc patch queue 2016-08-03

Here's the current set of patches (only 2) for spapr, ppc and related
things.  These are important bugfixes for the stabilizing 2.7 tree.

One is for a regression where confusion between x86 only and generic
KVM irq handling resulted in breakage on KVM/Power.  The other is
fixing (yet another) problem in 

Re: [Xen-devel] [DRAFT v4] PV Calls protocol design document (former XenSock)

[Stefano Stabellini]

On Wed, 3 Aug 2016, Wei Liu wrote:
> > # PV Calls Protocol
> > 
> > ## Rationale
> > 
> > PV Calls is a paravirtualized protocol for the POSIX socket API.
> > 
> > The purpose of PV Calls is to allow the implementation of a specific set
> > of POSIX functions to be done in a domain other than your own. It allows
> > connect, accept, bind, release, listen, poll, recvmsg and sendmsg to be
> > implemented in another domain.
> > 
> 
> The wording isn't really clear here. This design document as-is would
> inevitably make people start to compare PV Calls to various HV socks I'm
> afraid.

You are right, thanks for the feedback. I'll clarify it.


> Is PV Calls going to cover other stuff other than socket API? If it
> targets POSIX interfaces, maybe call it PV POSIX?
> 
> But then, if you extend the scope to cover POSIX APIs, I think you might
> want some discovery mechanism to see what APIs are paravirtualised?

Yes, it can potentially cover other interfaces -- I have a couple of
ideas in that area but I need to do some experiments first.

I fully agree that we need a discovery mechanism. What it is briefly
covered by this document, is that if a cmd is not supported by the
backend, ret is ENOTSUPP. But maybe we could also add a version node to
xenstore, that could be used to version the protocol supported by the
backend.

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 87ee6390cbeb2d15490943bca2978f166f213c13
baseline version:
 ovmf e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d

Last test of basis99919  2016-08-03 10:15:14 Z0 days
Testing same since99923  2016-08-03 14:15:11 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=87ee6390cbeb2d15490943bca2978f166f213c13
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
87ee6390cbeb2d15490943bca2978f166f213c13
+ branch=ovmf
+ revision=87ee6390cbeb2d15490943bca2978f166f213c13
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x87ee6390cbeb2d15490943bca2978f166f213c13 = 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 v2 10/25] arm/altp2m: Add HVMOP_altp2m_create_p2m.

[Julien Grall]

Hello Sergej,

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

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Cosmetic fixes.
---
 xen/arch/arm/altp2m.c| 23 +++
 xen/arch/arm/hvm.c   |  3 ++-
 xen/include/asm-arm/altp2m.h |  4 
 3 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
index e73424c..c22d2e4 100644
--- a/xen/arch/arm/altp2m.c
+++ b/xen/arch/arm/altp2m.c
@@ -136,6 +136,29 @@ int altp2m_init_by_id(struct domain *d, unsigned int idx)
 return rc;
 }

+int altp2m_init_next(struct domain *d, uint16_t *idx)
+{
+int rc = -EINVAL;
+unsigned int i;
+
+altp2m_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_vttbr[i] != INVALID_VTTBR )
+continue;
+
+rc = altp2m_init_helper(d, i);
+*idx = (uint16_t) i;


The cast is not necessary. You could make i uint16_t.


+
+break;
+}
+
+altp2m_unlock(d);
+
+return rc;
+}
+
 int altp2m_init(struct domain *d)
 {
 unsigned int i;
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 78370c6..063a06b 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -120,7 +120,8 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
 break;

 case HVMOP_altp2m_create_p2m:
-rc = -EOPNOTSUPP;
+if ( !(rc = altp2m_init_next(d, )) )
+rc = __copy_to_guest(arg, , 1) ? -EFAULT : 0;
 break;

 case HVMOP_altp2m_destroy_p2m:
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index 3ba82a8..3ecae27 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -53,6 +53,10 @@ void altp2m_vcpu_destroy(struct vcpu *v);
 int altp2m_init_by_id(struct domain *d,
   unsigned int idx);

+/* Find an available alternate p2m and make it valid */


The comment and the implementation don't match the name of the function. 
I would rename the function altp2m_find_available or something similar.



+int altp2m_init_next(struct domain *d,
+ uint16_t *idx);
+
 /* Flush all the alternate p2m's for a domain */
 void altp2m_flush(struct domain *d);




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 09/25] arm/altp2m: Add altp2m table flushing routine.

[Julien Grall]

Hello Sergej,

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

The current implementation differentiates between flushing and
destroying altp2m views. This commit adds the function altp2m_flush,
which allows to flush all or individual altp2m views without destroying
the entire table. In this way, altp2m views can be reused at a later
point in time.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Pages in p2m->pages are not cleared in p2m_flush_table anymore.
VMID is freed in p2m_free_one.
Cosmetic fixes.
---
 xen/arch/arm/altp2m.c| 38 ++
 xen/include/asm-arm/altp2m.h |  5 +
 xen/include/asm-arm/p2m.h|  3 +++
 3 files changed, 42 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
index 767f233..e73424c 100644
--- a/xen/arch/arm/altp2m.c
+++ b/xen/arch/arm/altp2m.c
@@ -151,6 +151,44 @@ int altp2m_init(struct domain *d)
 return 0;
 }

+void altp2m_flush(struct domain *d)
+{
+unsigned int i;
+struct p2m_domain *p2m;
+
+/*
+ * If altp2m is active, we are not allowed to flush altp2m[0]. This special
+ * view is considered as the hostp2m as long as altp2m is active.
+ */
+ASSERT(!altp2m_active(d));


Because of the race condition I mentioned in the previous patch (#8), 
this ASSERT may be hit randomly.



+
+altp2m_lock(d);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( d->arch.altp2m_vttbr[i] == INVALID_VTTBR )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+
+read_lock(>lock);


You should use p2m_lock rather than re-inventing your own. If p2m_*lock 
helpers need to be exposed, then expose them.


Also, this should be a write_lock otherwise someone else could access at 
the same time.



+
+p2m_flush_table(p2m);
+
+/*
+ * Reset VTTBR.
+ *
+ * Note that VMID is not freed so that it can be reused later.
+ */
+p2m->vttbr.vttbr = INVALID_VTTBR;
+d->arch.altp2m_vttbr[i] = INVALID_VTTBR;
+
+read_unlock(>lock);


I would much prefer if the p2m is fully destroyed rather than 
re-initialized.



+}
+
+altp2m_unlock(d);
+}
+
 void altp2m_teardown(struct domain *d)
 {
 unsigned int i;
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index a33c740..3ba82a8 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -54,9 +54,6 @@ int altp2m_init_by_id(struct domain *d,
   unsigned int idx);

 /* Flush all the alternate p2m's for a domain */
-static inline void altp2m_flush(struct domain *d)
-{
-/* Not yet implemented. */
-}
+void altp2m_flush(struct domain *d);

 #endif /* __ASM_ARM_ALTP2M_H */
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index f13f285..32326cb 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -222,6 +222,9 @@ mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn);
 /* Allocates page table for a p2m. */
 int p2m_alloc_table(struct p2m_domain *p2m);

+/* Flushes the page table held by the p2m. */
+void p2m_flush_table(struct p2m_domain *p2m);
+
 /* Initialize the p2m structure. */
 int p2m_init_one(struct domain *d, struct p2m_domain *p2m);




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 08/25] arm/altp2m: Add HVMOP_altp2m_set_domain_state.

[Julien Grall]

Hello Sergej,

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

The HVMOP_altp2m_set_domain_state allows to activate altp2m on a
specific domain. This commit adopts the x86
HVMOP_altp2m_set_domain_state implementation. Note that the function
altp2m_flush is currently implemented in form of a stub.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Dynamically allocate memory for altp2m views only when needed.
Move altp2m related helpers to altp2m.c.
p2m_flush_tlb is made publicly accessible.
---
 xen/arch/arm/altp2m.c  | 116 +
 xen/arch/arm/hvm.c |  34 +++-
 xen/arch/arm/p2m.c |   2 +-
 xen/include/asm-arm/altp2m.h   |  15 ++
 xen/include/asm-arm/domain.h   |   9 
 xen/include/asm-arm/flushtlb.h |   4 ++
 xen/include/asm-arm/p2m.h  |  11 
 7 files changed, 189 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
index abbd39a..767f233 100644
--- a/xen/arch/arm/altp2m.c
+++ b/xen/arch/arm/altp2m.c
@@ -19,6 +19,122 @@

 #include 
 #include 
+#include 
+
+struct p2m_domain *altp2m_get_altp2m(struct vcpu *v)
+{
+unsigned int index = vcpu_altp2m(v).p2midx;
+
+if ( index == INVALID_ALTP2M )
+return NULL;
+
+BUG_ON(index >= MAX_ALTP2M);
+
+return v->domain->arch.altp2m_p2m[index];
+}
+
+static void altp2m_vcpu_reset(struct vcpu *v)
+{
+struct altp2mvcpu *av = _altp2m(v);
+
+av->p2midx = INVALID_ALTP2M;
+}
+
+void altp2m_vcpu_initialise(struct vcpu *v)
+{
+if ( v != current )
+vcpu_pause(v);
+
+altp2m_vcpu_reset(v);


I don't understand why you call altp2m_vcpu_reset which will set p2midx 
to INVALID_ALTP2M but a line after you set to 0.



+vcpu_altp2m(v).p2midx = 0;
+atomic_inc(_get_altp2m(v)->active_vcpus);
+
+if ( v != current )
+vcpu_unpause(v);
+}
+
+void altp2m_vcpu_destroy(struct vcpu *v)
+{
+struct p2m_domain *p2m;
+
+if ( v != current )
+vcpu_pause(v);
+
+if ( (p2m = altp2m_get_altp2m(v)) )
+atomic_dec(>active_vcpus);
+
+altp2m_vcpu_reset(v);
+
+if ( v != current )
+vcpu_unpause(v);
+}
+
+static int altp2m_init_helper(struct domain *d, unsigned int idx)
+{
+int rc;
+struct p2m_domain *p2m = d->arch.altp2m_p2m[idx];
+
+if ( p2m == NULL )
+{
+/* Allocate a new, zeroed altp2m view. */
+p2m = xzalloc(struct p2m_domain);
+if ( p2m == NULL)
+{
+rc = -ENOMEM;
+goto err;
+}
+}


Why don't you re-allocate the p2m from scratch?


+
+/* Initialize the new altp2m view. */
+rc = p2m_init_one(d, p2m);
+if ( rc )
+goto err;
+
+/* Allocate a root table for the altp2m view. */
+rc = p2m_alloc_table(p2m);
+if ( rc )
+goto err;
+
+p2m->p2m_class = p2m_alternate;
+p2m->access_required = 1;


Please use true here. Although, I am not sure why you want to enable the 
access by default.



+_atomic_set(>active_vcpus, 0);
+
+d->arch.altp2m_p2m[idx] = p2m;
+d->arch.altp2m_vttbr[idx] = p2m->vttbr.vttbr;
+
+/*
+ * Make sure that all TLBs corresponding to the current VMID are flushed
+ * before using it.
+ */
+p2m_flush_tlb(p2m);
+
+return rc;
+
+err:
+if ( p2m )
+xfree(p2m);
+
+d->arch.altp2m_p2m[idx] = NULL;
+
+return rc;
+}
+
+int altp2m_init_by_id(struct domain *d, unsigned int idx)
+{
+int rc = -EINVAL;
+
+if ( idx >= MAX_ALTP2M )
+return rc;
+
+altp2m_lock(d);
+
+if ( d->arch.altp2m_vttbr[idx] == INVALID_VTTBR )
+rc = altp2m_init_helper(d, idx);
+
+altp2m_unlock(d);
+
+return rc;
+}

 int altp2m_init(struct domain *d)
 {
diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index 01a3243..78370c6 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -80,8 +80,40 @@ static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
 break;

 case HVMOP_altp2m_set_domain_state:
-rc = -EOPNOTSUPP;
+{
+struct vcpu *v;
+bool_t ostate;
+
+if ( !altp2m_enabled(d) )
+{
+rc = -EINVAL;
+break;
+}
+
+ostate = d->arch.altp2m_active;
+d->arch.altp2m_active = !!a.u.domain_state.state;
+
+/* If the alternate p2m state has changed, handle appropriately */
+if ( (d->arch.altp2m_active != ostate) &&
+ (ostate || !(rc = altp2m_init_by_id(d, 0))) )
+{
+for_each_vcpu( d, v )
+{
+if ( !ostate )
+altp2m_vcpu_initialise(v);
+else
+altp2m_vcpu_destroy(v);
+}


The implementation of this hvmop param looks racy to me. What does 
prevent to CPU running in this function at the same time? One will 
destroy, whilst the other one will 

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

[Tamas K Lengyel]

The two functions monitor_traps and mem_access_send_req duplicate some of the
same functionality. The mem_access_send_req however leaves a lot of the
standard vm_event fields to be filled by other functions.

Remove mem_access_send_req() completely, making use of monitor_traps() to put
requests into the monitor ring.  This in turn causes some cleanup around the
old callsites of mem_access_send_req(). We also update monitor_traps to now
include setting the common vcpu_id field so that all other call-sites can ommit
this step.

Finally, this change identifies that errors from mem_access_send_req() were
never checked.  As errors constitute a problem with the monitor ring,
crashing the domain is the most appropriate action to take.

Signed-off-by: Tamas K Lengyel 
Reviewed-by: Andrew Cooper 
Acked-by: Razvan Cojocaru 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: George Dunlap 

v3: reduce the code movement and sanitization performed to a minimum
---
 xen/arch/arm/p2m.c   | 15 ---
 xen/arch/x86/hvm/hvm.c   | 18 --
 xen/arch/x86/hvm/monitor.c   |  5 -
 xen/arch/x86/mm/p2m.c| 26 +-
 xen/common/mem_access.c  | 11 ---
 xen/common/monitor.c |  2 ++
 xen/include/asm-x86/p2m.h| 13 -
 xen/include/xen/mem_access.h |  7 ---
 8 files changed, 31 insertions(+), 66 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 40a0b80..a3f05b4 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -5,7 +5,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -1740,10 +1740,6 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
const struct npfec npfec)
 {
 req->reason = VM_EVENT_REASON_MEM_ACCESS;
 
-/* Pause the current VCPU */
-if ( xma != XENMEM_access_n2rwx )
-req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
-
 /* Send request to mem access subscriber */
 req->u.mem_access.gfn = gpa >> PAGE_SHIFT;
 req->u.mem_access.offset =  gpa & ((1 << PAGE_SHIFT) - 1);
@@ -1760,16 +1756,13 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
const struct npfec npfec)
 req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
 req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
 req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
-req->vcpu_id = v->vcpu_id;
 
-mem_access_send_req(v->domain, req);
+if ( monitor_traps(v, (xma != XENMEM_access_n2rwx), req) < 0 )
+domain_crash(v->domain);
+
 xfree(req);
 }
 
-/* Pause the current VCPU */
-if ( xma != XENMEM_access_n2rwx )
-vm_event_vcpu_pause(v);
-
 return false;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index daaee1d..42f163e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1707,7 +1707,7 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned long 
gla,
 int rc, fall_through = 0, paged = 0;
 int sharing_enomem = 0;
 vm_event_request_t *req_ptr = NULL;
-bool_t ap2m_active;
+bool_t ap2m_active, sync = 0;
 
 /* On Nested Virtualization, walk the guest page table.
  * If this succeeds, all is fine.
@@ -1846,11 +1846,15 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
 }
 }
 
-if ( p2m_mem_access_check(gpa, gla, npfec, _ptr) )
-{
+sync = p2m_mem_access_check(gpa, gla, npfec, _ptr);
+
+if ( !sync )
 fall_through = 1;
-} else {
-/* Rights not promoted, vcpu paused, work here is done */
+else
+{
+/*
+ * Rights not promoted (aka. sync event), work here is done
+ */
 rc = 1;
 goto out_put_gfn;
 }
@@ -1956,7 +1960,9 @@ out:
 }
 if ( req_ptr )
 {
-mem_access_send_req(currd, req_ptr);
+if ( monitor_traps(curr, sync, req_ptr) < 0 )
+rc = 0;
+
 xfree(req_ptr);
 }
 return rc;
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index 7277c12..0f6ef96 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -44,7 +44,6 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 
 vm_event_request_t req = {
 .reason = VM_EVENT_REASON_WRITE_CTRLREG,
-.vcpu_id = curr->vcpu_id,
 .u.write_ctrlreg.index = index,
 .u.write_ctrlreg.new_value = value,
 .u.write_ctrlreg.old_value = old
@@ -65,7 +64,6 @@ void hvm_monitor_msr(unsigned int msr, uint64_t 

[Xen-devel] [PATCH] x86/hvm: Drop the info level HVM save/restore messages

[Andrew Cooper]

These are not very useful at all, and overly voluminous since the domain
builder switched to using XEN_DOMCTL_{get,set}hvmcontext to construct HVM
domains.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/common/hvm/save.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/xen/common/hvm/save.c b/xen/common/hvm/save.c
index dd2c547..26b7a4b 100644
--- a/xen/common/hvm/save.c
+++ b/xen/common/hvm/save.c
@@ -173,8 +173,6 @@ int hvm_save(struct domain *d, hvm_domain_context_t *h)
 handler = hvm_sr_handlers[i].save;
 if ( handler != NULL ) 
 {
-printk(XENLOG_G_INFO "HVM%d save: %s\n",
-   d->domain_id, hvm_sr_handlers[i].name);
 if ( handler(d, h) != 0 ) 
 {
 printk(XENLOG_G_ERR
@@ -247,8 +245,6 @@ int hvm_load(struct domain *d, hvm_domain_context_t *h)
 }
 
 /* Load the entry */
-printk(XENLOG_G_INFO "HVM%d restore: %s %"PRIu16"\n", d->domain_id,
-   hvm_sr_handlers[desc->typecode].name, desc->instance);
 if ( handler(d, h) != 0 ) 
 {
 printk(XENLOG_G_ERR "HVM%d restore: failed to load entry %u/%u\n",
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 12:16 PM, Julien Grall  wrote:
>
>
> On 03/08/16 19:11, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall 
>> wrote:
>>>
>>>
>>>
>>> On 03/08/16 18:51, Tamas K Lengyel wrote:


 On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall 
 wrote:
>
>
> The whole discussion of this series was to defer the exposition of
> altp2m
> HVMOP to the guest until we find a usage. I.e a simple:
>
> xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);
>
> So why do you want to re-invent a new interface here?



 I guess I misinterpreted your request of not having this interface
 exposed to the guest. If we are fine with exposing the interface to
 the guest but having XSM manage whether it's allowed by default I'm
 certainly OK with that.
>>>
>>>
>>>
>>> By default the interface will not be exposed to the guest.
>>> XSM_PRIV/XSM_DM_PRIV only allow a privileged domain or a device model
>>> domain
>>> to use the interface. The guest will not be enabled to access it.
>>
>>
>> Yes. I guess our terminology differs about what we mean by "exposed".
>> In my book if the interface is available to the guest but access
>> attempts are denied by XSM that means the interface is exposed but
>> restricted.
>
>
> Although the behavior is very different compare to what x86 does. By default
> the guest will be able to play with altp2m.

Personally my life would be a lot easier on x86 too if the default XSM
behavior was external-use only for altp2m. Or if at last XSM was
turned on by default..

Tamas

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

Re: [Xen-devel] [PATCH 1/9] x86/hypercall: Move some of the hvm hypercall infrastructure into hypercall.h

[Stefano Stabellini]

On Wed, 3 Aug 2016, Julien Grall wrote:
> Hi Jan,
> 
> On 03/08/16 09:53, Jan Beulich wrote:
> > > > > On 02.08.16 at 20:43,  wrote:
> > > On Tue, 2 Aug 2016, Jan Beulich wrote:
> > > > > > > On 02.08.16 at 16:59,  wrote:
> > > > > On 02/08/16 15:54, Jan Beulich wrote:
> > > > > > > > > On 02.08.16 at 16:26,  wrote:
> > > > > > > On 02/08/16 15:17, Jan Beulich wrote:
> > > > > > > > Well, I find it quite odd for hypercall argument counts to
> > > > > > > > differ
> > > > > > > > between arches. I.e. I'd conclude the ABI was mis-specified.
> > > > > > > Is it documented somewhere for the x86 code? Looking at Linux, the
> > > > > > > privcmd call is only passing 5 arguments on both ARM and x86.
> > > > > > arch-x86/xen-x86_32.h has
> > > > > > 
> > > > > >  * Hypercall interface:
> > > > > >  *  Input:  %ebx, %ecx, %edx, %esi, %edi, %ebp (arguments 1-6)
> > > > > >  *  Output: %eax
> > > > > > 
> > > > > > while arch-x86/xen-x86_64.h has
> > > > > > 
> > > > > >  * Hypercall interface:
> > > > > >  *  Input:  %rdi, %rsi, %rdx, %r10, %r8, %r9 (arguments 1-6)
> > > > > >  *  Output: %rax
> > > > > 
> > > > > The only actual 6 argument hypercall is the v4v hypercall, better
> > > > > known
> > > > > as __HYPERVISOR_xc_reserved_op at index 39, but that isn't implemented
> > > > > anywhere upstream.
> > > > 
> > > > But it serves as an example what now wouldn't work on ARM.
> > > 
> > > At the time the arm hypercall ABI was published, it matched the x86
> > > hypercall ABI, which had only 5 hypercall arguments.
> > > 
> > > The issue is that the x86 hypercall ABI changed, and now is out of sync
> > > with ARM. The faulty commit being:
> > 
> > That's one way of viewing it, but I don't think an appropriate one.
> > 6-argument hypercalls had always been possible on x86, just that
> > they might not have been documented in the public headers (but
> > instead only in the actual hypercall implementation).
> 
> I would tend to say that anything not documented in the public header is not
> part of the ABI regardless how it has been implemented before hand.

I agree. What is documented (or not documented) in the public headers
is the golden standard.


> Anyway, I looked at the hypercall implementation on ARM and it seems that we
> half support the 6th argument. For instance hypercall_create_continuation is
> clobbering r5/x5 which is not part of the ABI.
> 
> However do_trap_hypercall is only supporting up to 5 argument.
> 
> I don't think it would be an issue to support 6 arguments on ARM. Stefano,
> what do you think?

I am OK with supporting 6 arguments hypercalls and it would be good to
have both architectures match. The 32bit guest-side implementation needs
special caring, but it should be OK (see HYPERCALL5 in Linux).
Fortunately xen/include/public/arch-arm.h states that only arguments
used by an hypercall can be clobbered.

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

Re: [Xen-devel] [PATCH v2 06/25] arm/altp2m: Cosmetic fixes - function prototypes.

[Julien Grall]

Hello Sergej,

Title: s/altp2m/p2m/ and please remove the full stop.

Also this is not really a cosmetic change.

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

This commit changes the prototype of the following functions:
- p2m_alloc_vmid
- p2m_free_vmid

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
 xen/arch/arm/p2m.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 63fe3d9..ff9c0d1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1337,11 +1337,10 @@ void p2m_vmid_allocator_init(void)
 set_bit(INVALID_VMID, vmid_mask);
 }

-static int p2m_alloc_vmid(struct domain *d)
+static int p2m_alloc_vmid(struct p2m_domain *p2m)


I am not a big fan of this interface change. I would much prefer if the 
VMID was returned and set to p2m->vmid by the caller.


So this would return either the VMID or INVALID_VMID.


 {
-struct p2m_domain *p2m = >arch.p2m;
-
 int rc, nr;
+struct domain *d = p2m->domain;

 spin_lock(_alloc_lock);

@@ -1367,9 +1366,8 @@ out:
 return rc;
 }

-static void p2m_free_vmid(struct domain *d)
+static void p2m_free_vmid(struct p2m_domain *p2m)


Likewise here. It would be better if the function is taking a vmid in 
parameter.



 {
-struct p2m_domain *p2m = >arch.p2m;
 spin_lock(_alloc_lock);
 if ( p2m->vmid != INVALID_VMID )
 clear_bit(p2m->vmid, vmid_mask);
@@ -1399,7 +1397,7 @@ static inline void p2m_free_one(struct p2m_domain *p2m)
 p2m_flush_table(p2m);

 /* Free VMID and reset VTTBR */
-p2m_free_vmid(p2m->domain);
+p2m_free_vmid(p2m);
 p2m->vttbr.vttbr = INVALID_VTTBR;

 if ( p2m->root )
@@ -1417,7 +1415,7 @@ int p2m_init_one(struct domain *d, struct p2m_domain *p2m)
 rwlock_init(>lock);
 INIT_PAGE_LIST_HEAD(>pages);

-rc = p2m_alloc_vmid(d);
+rc = p2m_alloc_vmid(p2m);
 if ( rc != 0 )
 return rc;




Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall]

On 03/08/16 19:11, Tamas K Lengyel wrote:

On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall  wrote:



On 03/08/16 18:51, Tamas K Lengyel wrote:


On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall 
wrote:


The whole discussion of this series was to defer the exposition of altp2m
HVMOP to the guest until we find a usage. I.e a simple:

xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);

So why do you want to re-invent a new interface here?



I guess I misinterpreted your request of not having this interface
exposed to the guest. If we are fine with exposing the interface to
the guest but having XSM manage whether it's allowed by default I'm
certainly OK with that.



By default the interface will not be exposed to the guest.
XSM_PRIV/XSM_DM_PRIV only allow a privileged domain or a device model domain
to use the interface. The guest will not be enabled to access it.


Yes. I guess our terminology differs about what we mean by "exposed".
In my book if the interface is available to the guest but access
attempts are denied by XSM that means the interface is exposed but
restricted.


Although the behavior is very different compare to what x86 does. By 
default the guest will be able to play with altp2m.


That was always my point, hence why I said there will be no issue to 
allow a guest accessing altp2m later on.


Andrew, is that what you had in mind?

Regards,

--
Julien Grall

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

[Xen-devel] unable start xen in hikey

[Kamenee Arumugam]

Hi all,

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


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

*> Unable to create new FDT*


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

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

[Xen-devel] [PATCH v2] arm/mem_access: don't reinject stage 2 access exceptions

[Tamas K Lengyel]

The only way a guest may trip with stage 2 access violation is if mem_access is
or was in-use, so reinjecting these exceptions to the guest is never required.

Requested-by: Julien Grall 
Signed-off-by: Tamas K Lengyel 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 

v2: simplify the patch by never reinjecting the exception
---
 xen/arch/arm/traps.c | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f509a00..da951c0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2415,11 +2415,12 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 goto bad_insn_abort;
 }
 
-rc = p2m_mem_access_check(gpa, gva, npfec);
-
-/* Trap was triggered by mem_access, work here is done */
-if ( !rc )
-return;
+p2m_mem_access_check(gpa, gva, npfec);
+/*
+ * The only way to get here right now is because of mem_access,
+ * thus reinjecting the exception to the guest is never required.
+ */
+return;
 }
 break;
 }
@@ -2462,11 +2463,12 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 .kind = dabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };
 
-rc = p2m_mem_access_check(info.gpa, info.gva, npfec);
-
-/* Trap was triggered by mem_access, work here is done */
-if ( !rc )
-return;
+p2m_mem_access_check(info.gpa, info.gva, npfec);
+/*
+ * The only way to get here right now is because of mem_access,
+ * thus reinjecting the exception to the guest is never required.
+ */
+return;
 }
 break;
 }
-- 
2.8.1


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

Re: [Xen-devel] [PATCH v2 07/25] arm/altp2m: Add altp2m init/teardown routines.

[Julien Grall]

Hello Sergej,

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

The p2m initialization now invokes initialization routines responsible
for the allocation and initialization of altp2m structures. The same
applies to teardown routines. The functionality has been adopted from
the x86 altp2m implementation.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Shared code between host/altp2m init/teardown functions.
Added conditional init/teardown of altp2m.
Altp2m related functions are moved to altp2m.c
---
 xen/arch/arm/Makefile|  1 +
 xen/arch/arm/altp2m.c| 71 
 xen/arch/arm/p2m.c   | 28 +
 xen/include/asm-arm/altp2m.h |  6 
 xen/include/asm-arm/domain.h |  4 +++
 xen/include/asm-arm/p2m.h|  5 
 6 files changed, 110 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/arm/altp2m.c

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 23aaf52..4a7f660 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -5,6 +5,7 @@ subdir-$(CONFIG_ARM_64) += efi
 subdir-$(CONFIG_ACPI) += acpi

 obj-$(CONFIG_ALTERNATIVE) += alternative.o
+obj-y += altp2m.o
 obj-y += bootfdt.o
 obj-y += cpu.o
 obj-y += cpuerrata.o
diff --git a/xen/arch/arm/altp2m.c b/xen/arch/arm/altp2m.c
new file mode 100644
index 000..abbd39a
--- /dev/null
+++ b/xen/arch/arm/altp2m.c
@@ -0,0 +1,71 @@
+/*
+ * arch/arm/altp2m.c
+ *
+ * Alternate p2m
+ * Copyright (c) 2016 Sergej Proskurin 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License, version 2,
+ * as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT ANY
+ * WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
+ * FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; If not, see .
+ */
+
+#include 
+#include 
+
+int altp2m_init(struct domain *d)
+{
+unsigned int i;
+
+spin_lock_init(>arch.altp2m_lock);
+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+d->arch.altp2m_p2m[i] = NULL;
+d->arch.altp2m_vttbr[i] = INVALID_VTTBR;


I don't think altp2m_vttbr is useful. There is no real performance 
impact to free the whole altp2m if the altp2m is destroyed (see 
altp2m_destroy_by_id) and re-allocated afterwards.


The code will actually much simpler. With this solution you will be able 
to detect if an altp2m is available by testin altp2m_p2m[i] is NULL.



+}
+
+return 0;
+}
+
+void altp2m_teardown(struct domain *d)
+{
+unsigned int i;
+struct p2m_domain *p2m;
+
+altp2m_lock(d);


The lock is not necessary here.


+
+for ( i = 0; i < MAX_ALTP2M; i++ )
+{
+if ( !d->arch.altp2m_p2m[i] )
+continue;
+
+p2m = d->arch.altp2m_p2m[i];
+p2m_free_one(p2m);
+xfree(p2m);
+
+d->arch.altp2m_vttbr[i] = INVALID_VTTBR;
+d->arch.altp2m_p2m[i] = NULL;


The domain will never be used afterward, so there is no point to set 
altp2m_vttbr and altp2m_p2m.



+}
+
+d->arch.altp2m_active = false;


Ditto.


+
+altp2m_unlock(d);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ff9c0d1..29ec5e5 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -14,6 +14,8 @@
 #include 
 #include 

+#include 
+
 #ifdef CONFIG_ARM_64
 static unsigned int __read_mostly p2m_root_order;
 static unsigned int __read_mostly p2m_root_level;
@@ -1392,7 +1394,7 @@ void p2m_flush_table(struct p2m_domain *p2m)
 free_domheap_page(pg);
 }

-static inline void p2m_free_one(struct p2m_domain *p2m)
+void p2m_free_one(struct p2m_domain *p2m)


Please expose p2m_free_one in patch #4.


 {
 p2m_flush_table(p2m);

@@ -1415,9 +1417,13 @@ int p2m_init_one(struct domain *d, struct p2m_domain 
*p2m)
 rwlock_init(>lock);
 INIT_PAGE_LIST_HEAD(>pages);

-rc = p2m_alloc_vmid(p2m);
-if ( rc != 0 )
-return rc;
+/* Reused altp2m views keep their VMID. */
+if ( p2m->vmid == INVALID_VMID )
+{
+rc = p2m_alloc_vmid(p2m);
+if ( rc != 0 )
+return rc;
+}


My suggestion above will avoid this kind of hack.



 p2m->domain = d;
 p2m->access_required = false;
@@ -1441,6 +1447,9 @@ static void p2m_teardown_hostp2m(struct domain *d)

 void p2m_teardown(struct domain *d)
 {
+if ( altp2m_enabled(d) )
+altp2m_teardown(d);
+
 p2m_teardown_hostp2m(d);
 }

@@ -1460,7 +1469,16 @@ static int 

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 11:56 AM, Julien Grall  wrote:
>
>
> On 03/08/16 18:51, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall 
>> wrote:
>>>
>>> The whole discussion of this series was to defer the exposition of altp2m
>>> HVMOP to the guest until we find a usage. I.e a simple:
>>>
>>> xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);
>>>
>>> So why do you want to re-invent a new interface here?
>>
>>
>> I guess I misinterpreted your request of not having this interface
>> exposed to the guest. If we are fine with exposing the interface to
>> the guest but having XSM manage whether it's allowed by default I'm
>> certainly OK with that.
>
>
> By default the interface will not be exposed to the guest.
> XSM_PRIV/XSM_DM_PRIV only allow a privileged domain or a device model domain
> to use the interface. The guest will not be enabled to access it.

Yes. I guess our terminology differs about what we mean by "exposed".
In my book if the interface is available to the guest but access
attempts are denied by XSM that means the interface is exposed but
restricted.

>
> If the user decide to allow a guest accessing altp2m op with XSM, then I
> don't think it our business if a security issue is exposed.
>

I agree.

Tamas

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

Re: [Xen-devel] [PATCH v2 05/25] arm/altp2m: Rename and extend p2m_alloc_table.

[Julien Grall]

Hello Sergej,

Title: s/altp2m/p2m/

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

The initially named function "p2m_alloc_table" allocated pages solely
required for the host's p2m. The new implementation leaves p2m
allocation related parts inside of this function to generally initialize
p2m/altp2m tables. This is done generically, as the host's p2m and
altp2m tables are allocated similarly. Since this function will be used
by the altp2m initialization routines, it is not made static. In
addition, this commit provides the overlay function "p2m_table_init"
that is used for the host's p2m allocation/initialization.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Removed altp2m table initialization from "p2m_table_init".
---
 xen/arch/arm/p2m.c | 29 +++--
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 17f3299..63fe3d9 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1277,11 +1277,11 @@ void guest_physmap_remove_page(struct domain *d,
 p2m_remove_mapping(d, gfn, (1 << page_order), mfn);
 }

-static int p2m_alloc_table(struct domain *d)
+int p2m_alloc_table(struct p2m_domain *p2m)


The function p2m_alloc_table should not be exposed outside of the p2m. I 
explained it why in the previous patch.



 {
-struct p2m_domain *p2m = >arch.p2m;
-struct page_info *page;
 unsigned int i;
+struct page_info *page;
+struct vttbr *vttbr = >vttbr;

 page = alloc_domheap_pages(NULL, P2M_ROOT_ORDER, 0);
 if ( page == NULL )
@@ -1293,11 +1293,28 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-p2m->vttbr.vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) 
<< 48;
+/* Initialize the VTTBR associated with the allocated p2m table. */
+vttbr->vttbr = 0;
+vttbr->vmid = p2m->vmid & 0xff;
+vttbr->baddr = page_to_maddr(p2m->root);


This change does not belong to this patch. If we want to use VTTBR, it 
should be in patch #3.



+
+return 0;
+}
+
+static int p2m_table_init(struct domain *d)
+{
+int rc;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+rc = p2m_alloc_table(p2m);
+if ( rc != 0 )
+return -ENOMEM;
+
+d->arch.altp2m_active = false;


Please avoid to spread the change for altp2m everywhere. The addition of 
altp2m in the p2m code should really be a single patch.




 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
- * before using it
+ * before using it.
  */
 p2m_flush_tlb(p2m);

@@ -1440,7 +1457,7 @@ static int p2m_init_hostp2m(struct domain *d)
 if ( rc )
 return rc;

-return p2m_alloc_table(d);
+return p2m_table_init(d);
 }

 int p2m_init(struct domain *d)



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall]

On 03/08/16 18:51, Tamas K Lengyel wrote:

On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall  wrote:

The whole discussion of this series was to defer the exposition of altp2m
HVMOP to the guest until we find a usage. I.e a simple:

xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);

So why do you want to re-invent a new interface here?


I guess I misinterpreted your request of not having this interface
exposed to the guest. If we are fine with exposing the interface to
the guest but having XSM manage whether it's allowed by default I'm
certainly OK with that.


By default the interface will not be exposed to the guest. 
XSM_PRIV/XSM_DM_PRIV only allow a privileged domain or a device model 
domain to use the interface. The guest will not be enabled to access it.


If the user decide to allow a guest accessing altp2m op with XSM, then I 
don't think it our business if a security issue is exposed.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/2] Allow kdump with crash_kexec_post_notifiers

[Daniel Kiper]

On Mon, Aug 01, 2016 at 10:25:22AM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Aug 01, 2016 at 04:15:10PM +0200, Petr Tesarik wrote:
> > On Mon, 1 Aug 2016 15:47:58 +0200

[...]

> I wonder if Xen should do that - as in 'fix' the bootparams to not have it.
> Or perhaps Linux code during bootup can sanitze this..

It should but I am not sure it does. Or at least it should display warning
that dom0 crashkernel argument does not make sense and is not supported.

> > > And then trying to invoke a locally loaded crash kernel which won't
> > > work is bad
> >
> > Without actually knowing whether a PV kernel can kexec another PV
> > kernel, this discussion is somewhat moot...
> >
> > But let me repeat: if PV kexec works, then it has always had priority
> > over the hypercall. If it doesn't work, then it has always been broken.
> > For the latter case, I agree that the kernel should not even allow to
> > load the kexec image, but that's unrelated to my patch.
> >
> > Has anyone here tried booting up a PV domain and performing kexec(2)?
>
> Yes. Daniel (CC-ed) did it. He had it working but only for one CPU
> and then Greg KH picked up the patchset .. and not sure what happend.

Greg had it in https://git.kernel.org/ some time ago, however, it looks
that it vanished. Anyway, IIRC, the problem was that kdump must be started
with one processor and this is not easy due to various constraints. Later,
PV guest have to be restarted to regain full functionality.

> The underlaying issue was the PV guest could not re-initialize the grants,
> events, etc - but now with Vitaly's 'reset' hypercall it would be possible.
> Except the 'reset' hypercall is only for HVM guests.

I think that it is for PVHVM. Hence, making it work on PV should not be
very difficult. I hope...

Daniel

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 11:45 AM, Julien Grall  wrote:
>
>
> On 03/08/16 18:43, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper
>>  wrote:
>>>
>>> On 03/08/16 17:51, Julien Grall wrote:



 On 03/08/16 17:42, Tamas K Lengyel wrote:
>
> On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall 
> wrote:
>>
>> Hi Tamas,
>>
>>
>> On 03/08/16 17:01, Tamas K Lengyel wrote:
>>>
>>>
>>> On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall 
>>> wrote:


 Hello Sergej,

 Please try to reply to all when answering on the ML. Otherwise the
 answer
 may be delayed/lost.

 On 03/08/16 13:45, Sergej Proskurin wrote:
>
>
>
> The interesting part about #VE is that it allows to handle certain
> violations (currently limited to EPT violations -- future
> implementations might introduce also further violations) inside
> of the
> guest, without the need to explicitly trap into the VMM. Thus,
> #VE allow
> switching of different memory views in-guest. Because of this, I
> also
> agree that event channels would suffice in our case, since we do
> not
> have sufficient hardware support on ARM and would need to trap
> into the
> VMM anyway.




 The cost of doing an hypercall on ARM is very small compare to x86
 (~1/3
 of
 the number of x86 cycles) because we don't have to save all the
 state
 every
 time. So I am not convinced by the argument of limiting the number
 of
 trap
 to the hypervisor and allow a guest to play with altp2m on ARM.

 I will have to see a concrete example before going forward with
 the event
 channel.
>>>
>>>
>>>
>>> It is out-of-scope for what we are trying to achieve with this series
>>> at this point. The question at hand is really whether the atp2m
>>> switch
>>> and gfn remapping ops should be exposed to the guest. Without #VE -
>>> which we are not implementing - setting the mem_access settings from
>>> within the guest doesn't make sense so restricting access there is
>>> reasonable.
>>>
>>> As I outlined, the switch and gfn remapping can have legitimate
>>> use-cases by themselves without any mem_access bits involved.
>>> However,
>>> it is not our use-case so we have no problem restricting access there
>>> either. So the question is whether that's the right path to take
>>> here.
>>> At this point I'm not sure there is agreement about it or not.
>>
>>
>>
>> Could you give a legitimate use case of gfn remapping from the
>> guest? And
>> explain how it would work with only this patch series.
>>
>> From my perspective, and after the numerous exchange in this thread,
>> I do
>> not think it is wise to expose this interface to the guest on ARM.
>> The usage
>> is very limited but increase the surface attack. So I will not ack a
>> such
>> choice, however I will not nack it.
>>
>
> Since the interface would be available only for domains where they
> were explicitly created with altp2m=1 flag set I think the exposure is
> minimal.
>
> As for a use-case, I don't have a real world example as it's not how
> we use the system. But as I pointed out eairlier I could imagine the
> gfn remapping be used to protect kernel memory areas against
> information disclosure by only switching to the accessible altp2m view
> when certain conditions are met. What I mean is that a certain gfn
> could be remapped to a dummy mfn by default and only switched to the
> accessible view when necessary. How much extra protection that would
> add and under what condition is up for debate but IMHO it is a
> legitimate experimental use - and altp2m is an experimental system.


 A such solution may give you a lots of headache with the cache.

>
> Whether it's worth to have such an interface or not I'm not sure, I'm
> OK with going either way on this, but since it's available on x86 I
> think it would make sense to have feature parity - even if only
> partially for now.


 As I mentioned a couple of times, we do not introduce features on ARM
 just because they exists on x86. We introduce them after careful think
 about how they could benefits ARM and the usage.

 Nothing prevents a follow-up series to allow the guest accessing
 altp2m operation by default because the interface is already there.

 Stefano, do you have any opinions on this?
>>>
>>>
>>> From my point of view, feature 

Re: [Xen-devel] [PATCH] xen: use a common function for pv and hvm guest backend register calls

[Stefano Stabellini]

On Wed, 3 Aug 2016, Juergen Gross wrote:
> On 02/08/16 20:27, Stefano Stabellini wrote:
> > On Tue, 2 Aug 2016, Juergen Gross wrote:
> >> Instead of calling xen_be_register() for each supported backend type
> >> for hvm and pv guests in their machine init functions use a common
> >> function in order not to have to add new backends twice.
> >>
> >> This at once fixes the error that hvm domains couldn't use the qusb
> >> backend.
> >>
> >> Signed-off-by: Juergen Gross 
> >> ---
> >> Is it on purpose the qnic and vfb backends are not registered for HVM?
> > 
> > Yes, it is on purpose: there is no code in any toolstacks to use qnic,
> > and the presence of vfb can cause problems to Linux HVM guests (or at
> > least it used to), additionally vfb for HVM guests is also disabled in
> > libxl.
> > 
> > In general, it is a good idea to disable code that is not supposed to be
> > used.
> > 
> > Can qusb be used with HVM guests with libxl/xl?
> 
> Yes. You have to specify "type=qusb" for usbctrl, then it will work.
> I have verified that.

Good, thanks.

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall]

On 03/08/16 18:43, Tamas K Lengyel wrote:

On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper
 wrote:

On 03/08/16 17:51, Julien Grall wrote:



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

On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall 
wrote:

Hi Tamas,


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


On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall 
wrote:


Hello Sergej,

Please try to reply to all when answering on the ML. Otherwise the
answer
may be delayed/lost.

On 03/08/16 13:45, Sergej Proskurin wrote:



The interesting part about #VE is that it allows to handle certain
violations (currently limited to EPT violations -- future
implementations might introduce also further violations) inside
of the
guest, without the need to explicitly trap into the VMM. Thus,
#VE allow
switching of different memory views in-guest. Because of this, I
also
agree that event channels would suffice in our case, since we do not
have sufficient hardware support on ARM and would need to trap
into the
VMM anyway.




The cost of doing an hypercall on ARM is very small compare to x86
(~1/3
of
the number of x86 cycles) because we don't have to save all the state
every
time. So I am not convinced by the argument of limiting the number of
trap
to the hypervisor and allow a guest to play with altp2m on ARM.

I will have to see a concrete example before going forward with
the event
channel.



It is out-of-scope for what we are trying to achieve with this series
at this point. The question at hand is really whether the atp2m switch
and gfn remapping ops should be exposed to the guest. Without #VE -
which we are not implementing - setting the mem_access settings from
within the guest doesn't make sense so restricting access there is
reasonable.

As I outlined, the switch and gfn remapping can have legitimate
use-cases by themselves without any mem_access bits involved. However,
it is not our use-case so we have no problem restricting access there
either. So the question is whether that's the right path to take here.
At this point I'm not sure there is agreement about it or not.



Could you give a legitimate use case of gfn remapping from the
guest? And
explain how it would work with only this patch series.

From my perspective, and after the numerous exchange in this thread,
I do
not think it is wise to expose this interface to the guest on ARM.
The usage
is very limited but increase the surface attack. So I will not ack a
such
choice, however I will not nack it.



Since the interface would be available only for domains where they
were explicitly created with altp2m=1 flag set I think the exposure is
minimal.

As for a use-case, I don't have a real world example as it's not how
we use the system. But as I pointed out eairlier I could imagine the
gfn remapping be used to protect kernel memory areas against
information disclosure by only switching to the accessible altp2m view
when certain conditions are met. What I mean is that a certain gfn
could be remapped to a dummy mfn by default and only switched to the
accessible view when necessary. How much extra protection that would
add and under what condition is up for debate but IMHO it is a
legitimate experimental use - and altp2m is an experimental system.


A such solution may give you a lots of headache with the cache.



Whether it's worth to have such an interface or not I'm not sure, I'm
OK with going either way on this, but since it's available on x86 I
think it would make sense to have feature parity - even if only
partially for now.


As I mentioned a couple of times, we do not introduce features on ARM
just because they exists on x86. We introduce them after careful think
about how they could benefits ARM and the usage.

Nothing prevents a follow-up series to allow the guest accessing
altp2m operation by default because the interface is already there.

Stefano, do you have any opinions on this?


From my point of view, feature parity with x86 is only important if the
feature is equally capable, and this thread has shown that this is not
the case.

IMO, the choice is between:

1) Don't expose altp2m to guests, or
2) Make a para-virtual version of #VE for ARM guests, and expose the
full guest interface.

I am not fussed either way, but with my Security Team hat on, exposing
half an interface which can't usefully be used had has no current
usecase is a recipe for bugs with an XSA/CVE attached to them, and
therefore extra paperwork for me or someone else to do.



Well, if there are latent XSA/CVE issues with just half the interface
I don't see how doing the full interface would avoid that. But fair
enough, if Stefano agrees we can close this issue and just introduce a
new set of domctl's.


The whole discussion of this series was to defer the exposition of 
altp2m HVMOP to the guest until we find a usage. I.e a simple:


xsm_hvm_altp2m_op(XSM_PRIV/XSM_DM_PRIV, d);

So why do you want to re-invent a new interface 

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 11:30 AM, Andrew Cooper
 wrote:
> On 03/08/16 17:51, Julien Grall wrote:
>>
>>
>> On 03/08/16 17:42, Tamas K Lengyel wrote:
>>> On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall 
>>> wrote:
 Hi Tamas,


 On 03/08/16 17:01, Tamas K Lengyel wrote:
>
> On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall 
> wrote:
>>
>> Hello Sergej,
>>
>> Please try to reply to all when answering on the ML. Otherwise the
>> answer
>> may be delayed/lost.
>>
>> On 03/08/16 13:45, Sergej Proskurin wrote:
>>>
>>>
>>> The interesting part about #VE is that it allows to handle certain
>>> violations (currently limited to EPT violations -- future
>>> implementations might introduce also further violations) inside
>>> of the
>>> guest, without the need to explicitly trap into the VMM. Thus,
>>> #VE allow
>>> switching of different memory views in-guest. Because of this, I
>>> also
>>> agree that event channels would suffice in our case, since we do not
>>> have sufficient hardware support on ARM and would need to trap
>>> into the
>>> VMM anyway.
>>
>>
>>
>> The cost of doing an hypercall on ARM is very small compare to x86
>> (~1/3
>> of
>> the number of x86 cycles) because we don't have to save all the state
>> every
>> time. So I am not convinced by the argument of limiting the number of
>> trap
>> to the hypervisor and allow a guest to play with altp2m on ARM.
>>
>> I will have to see a concrete example before going forward with
>> the event
>> channel.
>
>
> It is out-of-scope for what we are trying to achieve with this series
> at this point. The question at hand is really whether the atp2m switch
> and gfn remapping ops should be exposed to the guest. Without #VE -
> which we are not implementing - setting the mem_access settings from
> within the guest doesn't make sense so restricting access there is
> reasonable.
>
> As I outlined, the switch and gfn remapping can have legitimate
> use-cases by themselves without any mem_access bits involved. However,
> it is not our use-case so we have no problem restricting access there
> either. So the question is whether that's the right path to take here.
> At this point I'm not sure there is agreement about it or not.


 Could you give a legitimate use case of gfn remapping from the
 guest? And
 explain how it would work with only this patch series.

 From my perspective, and after the numerous exchange in this thread,
 I do
 not think it is wise to expose this interface to the guest on ARM.
 The usage
 is very limited but increase the surface attack. So I will not ack a
 such
 choice, however I will not nack it.

>>>
>>> Since the interface would be available only for domains where they
>>> were explicitly created with altp2m=1 flag set I think the exposure is
>>> minimal.
>>>
>>> As for a use-case, I don't have a real world example as it's not how
>>> we use the system. But as I pointed out eairlier I could imagine the
>>> gfn remapping be used to protect kernel memory areas against
>>> information disclosure by only switching to the accessible altp2m view
>>> when certain conditions are met. What I mean is that a certain gfn
>>> could be remapped to a dummy mfn by default and only switched to the
>>> accessible view when necessary. How much extra protection that would
>>> add and under what condition is up for debate but IMHO it is a
>>> legitimate experimental use - and altp2m is an experimental system.
>>
>> A such solution may give you a lots of headache with the cache.
>>
>>>
>>> Whether it's worth to have such an interface or not I'm not sure, I'm
>>> OK with going either way on this, but since it's available on x86 I
>>> think it would make sense to have feature parity - even if only
>>> partially for now.
>>
>> As I mentioned a couple of times, we do not introduce features on ARM
>> just because they exists on x86. We introduce them after careful think
>> about how they could benefits ARM and the usage.
>>
>> Nothing prevents a follow-up series to allow the guest accessing
>> altp2m operation by default because the interface is already there.
>>
>> Stefano, do you have any opinions on this?
>
> From my point of view, feature parity with x86 is only important if the
> feature is equally capable, and this thread has shown that this is not
> the case.
>
> IMO, the choice is between:
>
> 1) Don't expose altp2m to guests, or
> 2) Make a para-virtual version of #VE for ARM guests, and expose the
> full guest interface.
>
> I am not fussed either way, but with my Security Team hat on, exposing
> half an interface which can't usefully be used had has no current
> usecase is a recipe for bugs with an XSA/CVE attached 

Re: [Xen-devel] [PATCH v2 04/25] arm/altp2m: Move hostp2m init/teardown to individual functions.

[Julien Grall]

Hello Sergej,

Title: s/altp2m/p2m/ and please drop the full stop.

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

This commit pulls out generic init/teardown functionality out of
p2m_init and p2m_teardown into p2m_init_one, p2m_free_one, and
p2m_flush_table functions.  This allows our future implementation to
reuse existing code for the initialization/teardown of altp2m views.


Please avoid to mix-up code movement and new additions. This makes the 
code more difficult to review.


Also, you don't mention the new changes in the commit message.

After reading the patch, it should really be divided and explain why you 
split like that.




Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Added the function p2m_flush_table to the previous version.
---
 xen/arch/arm/p2m.c| 74 +--
 xen/include/asm-arm/p2m.h | 11 +++
 2 files changed, 70 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index cbc64a1..17f3299 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1360,50 +1360,94 @@ static void p2m_free_vmid(struct domain *d)
 spin_unlock(_alloc_lock);
 }

-void p2m_teardown(struct domain *d)
+/* Reset this p2m table to be empty */
+void p2m_flush_table(struct p2m_domain *p2m)


Any function exported should have its prototype in an header within the 
same patch.



 {
-struct p2m_domain *p2m = >arch.p2m;
-struct page_info *pg;
+struct page_info *page, *pg;
+unsigned int i;
+
+page = p2m->root;



This function can be called with p2m->root equal to NULL. (see the check 
in p2m_free_one.



+
+/* Clear all concatenated first level pages */
+for ( i = 0; i < P2M_ROOT_PAGES; i++ )
+clear_and_clean_page(page + i);

+/* Free the rest of the trie pages back to the paging pool */
 while ( (pg = page_list_remove_head(>pages)) )
 free_domheap_page(pg);
+}
+
+static inline void p2m_free_one(struct p2m_domain *p2m)


Why inline here? Also, it seems that you export the function later. Why 
don't you do it here?


Finally, I think this function should be rename p2m_teardown_one to 
match the callers' name.



+{
+p2m_flush_table(p2m);
+
+/* Free VMID and reset VTTBR */
+p2m_free_vmid(p2m->domain);


Why do you move the call to p2m_free_vmid?


+p2m->vttbr.vttbr = INVALID_VTTBR;


Why do you reset vttbr, the p2m will never be used afterwards.



 if ( p2m->root )
 free_domheap_pages(p2m->root, P2M_ROOT_ORDER);

 p2m->root = NULL;

-p2m_free_vmid(d);
-
 radix_tree_destroy(>mem_access_settings, NULL);
 }

-int p2m_init(struct domain *d)
+int p2m_init_one(struct domain *d, struct p2m_domain *p2m)


Any function exported should have its prototype in an header within the 
same patch.



 {
-struct p2m_domain *p2m = >arch.p2m;
 int rc = 0;

 rwlock_init(>lock);
 INIT_PAGE_LIST_HEAD(>pages);

-p2m->vmid = INVALID_VMID;
-


Why this is dropped?


 rc = p2m_alloc_vmid(d);
 if ( rc != 0 )
 return rc;

-p2m->max_mapped_gfn = _gfn(0);
-p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
-
-p2m->default_access = p2m_access_rwx;
+p2m->domain = d;
+p2m->access_required = false;
 p2m->mem_access_enabled = false;
+p2m->default_access = p2m_access_rwx;
+p2m->root = NULL;
+p2m->max_mapped_gfn = _gfn(0);
+p2m->lowest_mapped_gfn = INVALID_GFN;


Please don't move code when it is not necessary. This make the code 
review more difficult to read.



+p2m->vttbr.vttbr = INVALID_VTTBR;
 radix_tree_init(>mem_access_settings);

-rc = p2m_alloc_table(d);
-


The function p2m_init_one should fully initialize the p2m (i.e allocate 
the table).


Why altp2m_destroy_by_id don't free the p2m entirely?
This would simply a lot this series and avoid to spread p2m 
initialization everywhere.



 return rc;
 }

+static void p2m_teardown_hostp2m(struct domain *d)
+{
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+p2m_free_one(p2m);
+}
+
+void p2m_teardown(struct domain *d)
+{
+p2m_teardown_hostp2m(d);
+}
+
+static int p2m_init_hostp2m(struct domain *d)
+{
+int rc;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
+
+p2m->p2m_class = p2m_host;
+
+rc = p2m_init_one(d, p2m);
+if ( rc )
+return rc;
+
+return p2m_alloc_table(d);
+}
+
+int p2m_init(struct domain *d)
+{
+return p2m_init_hostp2m(d);
+}
+
 int relinquish_p2m_mapping(struct domain *d)
 {
 struct p2m_domain *p2m = >arch.p2m;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 5c7cd1a..1f9c370 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -18,6 +18,11 @@ struct domain;

 extern void memory_type_changed(struct domain *);

+typedef enum {
+p2m_host,
+p2m_alternate,
+} p2m_class_t;
+


This addition should really be in a separate 

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Andrew Cooper]

On 03/08/16 17:51, Julien Grall wrote:
>
>
> On 03/08/16 17:42, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall 
>> wrote:
>>> Hi Tamas,
>>>
>>>
>>> On 03/08/16 17:01, Tamas K Lengyel wrote:

 On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall 
 wrote:
>
> Hello Sergej,
>
> Please try to reply to all when answering on the ML. Otherwise the
> answer
> may be delayed/lost.
>
> On 03/08/16 13:45, Sergej Proskurin wrote:
>>
>>
>> The interesting part about #VE is that it allows to handle certain
>> violations (currently limited to EPT violations -- future
>> implementations might introduce also further violations) inside
>> of the
>> guest, without the need to explicitly trap into the VMM. Thus,
>> #VE allow
>> switching of different memory views in-guest. Because of this, I
>> also
>> agree that event channels would suffice in our case, since we do not
>> have sufficient hardware support on ARM and would need to trap
>> into the
>> VMM anyway.
>
>
>
> The cost of doing an hypercall on ARM is very small compare to x86
> (~1/3
> of
> the number of x86 cycles) because we don't have to save all the state
> every
> time. So I am not convinced by the argument of limiting the number of
> trap
> to the hypervisor and allow a guest to play with altp2m on ARM.
>
> I will have to see a concrete example before going forward with
> the event
> channel.


 It is out-of-scope for what we are trying to achieve with this series
 at this point. The question at hand is really whether the atp2m switch
 and gfn remapping ops should be exposed to the guest. Without #VE -
 which we are not implementing - setting the mem_access settings from
 within the guest doesn't make sense so restricting access there is
 reasonable.

 As I outlined, the switch and gfn remapping can have legitimate
 use-cases by themselves without any mem_access bits involved. However,
 it is not our use-case so we have no problem restricting access there
 either. So the question is whether that's the right path to take here.
 At this point I'm not sure there is agreement about it or not.
>>>
>>>
>>> Could you give a legitimate use case of gfn remapping from the
>>> guest? And
>>> explain how it would work with only this patch series.
>>>
>>> From my perspective, and after the numerous exchange in this thread,
>>> I do
>>> not think it is wise to expose this interface to the guest on ARM.
>>> The usage
>>> is very limited but increase the surface attack. So I will not ack a
>>> such
>>> choice, however I will not nack it.
>>>
>>
>> Since the interface would be available only for domains where they
>> were explicitly created with altp2m=1 flag set I think the exposure is
>> minimal.
>>
>> As for a use-case, I don't have a real world example as it's not how
>> we use the system. But as I pointed out eairlier I could imagine the
>> gfn remapping be used to protect kernel memory areas against
>> information disclosure by only switching to the accessible altp2m view
>> when certain conditions are met. What I mean is that a certain gfn
>> could be remapped to a dummy mfn by default and only switched to the
>> accessible view when necessary. How much extra protection that would
>> add and under what condition is up for debate but IMHO it is a
>> legitimate experimental use - and altp2m is an experimental system.
>
> A such solution may give you a lots of headache with the cache.
>
>>
>> Whether it's worth to have such an interface or not I'm not sure, I'm
>> OK with going either way on this, but since it's available on x86 I
>> think it would make sense to have feature parity - even if only
>> partially for now.
>
> As I mentioned a couple of times, we do not introduce features on ARM
> just because they exists on x86. We introduce them after careful think
> about how they could benefits ARM and the usage.
>
> Nothing prevents a follow-up series to allow the guest accessing
> altp2m operation by default because the interface is already there.
>
> Stefano, do you have any opinions on this?

From my point of view, feature parity with x86 is only important if the
feature is equally capable, and this thread has shown that this is not
the case.

IMO, the choice is between:

1) Don't expose altp2m to guests, or
2) Make a para-virtual version of #VE for ARM guests, and expose the
full guest interface.

I am not fussed either way, but with my Security Team hat on, exposing
half an interface which can't usefully be used had has no current
usecase is a recipe for bugs with an XSA/CVE attached to them, and
therefore extra paperwork for me or someone else to do.

~Andrew

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

[Xen-devel] [PATCHv1 2/2] libxencall: release the buffer cache before closing the fd

[David Vrabel]

Freeing a buffer may now call the IOCTL_PRIVCMD_HCALL_BUF_UNLOCK ioctl
on the fd, so the fd should only be closed after the buffer cache is
released.

Signed-off-by: David Vrabel 
---
 tools/libs/call/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libs/call/core.c b/tools/libs/call/core.c
index 5ca0372..578815a 100644
--- a/tools/libs/call/core.c
+++ b/tools/libs/call/core.c
@@ -65,8 +65,8 @@ int xencall_close(xencall_handle *xcall)
 if ( !xcall )
 return 0;
 
-rc = osdep_xencall_close(xcall);
 buffer_release_cache(xcall);
+rc = osdep_xencall_close(xcall);
 xtl_logger_destroy(xcall->logger_tofree);
 free(xcall);
 return rc;
-- 
2.1.4


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

[Xen-devel] [PATCHv1 1/2] libxencall/linux: use LOCK/UNLOCK ioctls for hypercall buffers

[David Vrabel]

Using just mlock'd buffers for hypercalls is not sufficient as these
are still subject to compaction and page migration.  Use the new
IOCTL_PRIVCMD_HCALL_BUF_LOCK and IOCTL_PRIVCMD_HCALL_BUF_UNLOCK ioctls
provided by the privcmd driver to prevent this.

Since not all kernels support these ioctls, don't repeatedly try these
ioctls if they are unsupported.

MAP_LOCKED is still used as this places the pages on the unevictable
list avoiding the need for the VM subsystem to scan them.

madvise(.., MADV_DONTFORK) is still required since we still need to
prevent children getting CoW mappings of the hypercall buffers.

Signed-off-by: David Vrabel 
---
 tools/include/xen-sys/Linux/privcmd.h | 37 +++
 tools/libs/call/linux.c   | 47 ---
 2 files changed, 81 insertions(+), 3 deletions(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index e4e666a..4afb399 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -75,6 +75,11 @@ typedef struct privcmd_mmapbatch_v2 {
int __user *err;  /* array of error codes */
 } privcmd_mmapbatch_v2_t;
 
+struct privcmd_hcall_buf {
+   void *start;
+   size_t len;
+};
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: _hypercall_t
@@ -89,4 +94,36 @@ typedef struct privcmd_mmapbatch_v2 {
 #define IOCTL_PRIVCMD_MMAPBATCH_V2 \
_IOC(_IOC_NONE, 'P', 4, sizeof(privcmd_mmapbatch_v2_t))
 
+/*
+ * @cmd: IOCTL_PRIVCMD_HCALL_BUF_LOCK
+ * @arg: struct privcmd hcall_buf *
+ * Return: 0 on success. On an error, -1 is returned and errno is set
+ * to EINVAL, ENOMEM, or EFAULT.
+ *
+ * Locks a memory buffer so it may be used in a hypercall.  This is
+ * similar to mlock(2) but also prevents compaction/page migration.
+ *
+ * The buffers may have any alignment and size and may overlap other
+ * buffers.
+ *
+ * Locked buffers are unlocked with IOCTL_PRIVCMD_HCALL_BUF_UNLOCK or
+ * by closing the file handle.
+ */
+#define IOCTL_PRIVCMD_HCALL_BUF_LOCK   \
+   _IOC(_IOC_NONE, 'P', 5, sizeof(struct privcmd_hcall_buf))
+
+/*
+ * @cmd: IOCTL_PRIVCMD_HCALL_BUF_UNLOCK
+ * @arg: struct privcmd hcall_buf *
+ * Return: Always 0.
+ *
+ * Unlocks a memory buffer previously locked with
+ * IOCTL_PRIVCMD_HCALL_BUF_LOCK.
+ *
+ * It is not possible to partially unlock a buffer.  i.e., the
+ * LOCK/UNLOCK must be exactly paired.
+ */
+#define IOCTL_PRIVCMD_HCALL_BUF_UNLOCK \
+   _IOC(_IOC_NONE, 'P', 6, sizeof(struct privcmd_hcall_buf))
+
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index e8e0311..54ddd23 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -68,6 +68,8 @@ int osdep_hypercall(xencall_handle *xcall, 
privcmd_hypercall_t *hypercall)
 return ioctl(xcall->fd, IOCTL_PRIVCMD_HYPERCALL, hypercall);
 }
 
+static int have_hbuf_lock = 1;
+
 void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
 {
 size_t size = npages * PAGE_SIZE;
@@ -84,7 +86,7 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t npages)
 
 /* Do not copy the VMA to child process on fork. Avoid the page being COW
 on hypercall. */
-rc = madvise(p, npages * PAGE_SIZE, MADV_DONTFORK);
+rc = madvise(p, size, MADV_DONTFORK);
 if ( rc < 0 )
 {
 PERROR("alloc_pages: madvise failed");
@@ -103,6 +105,33 @@ void *osdep_alloc_pages(xencall_handle *xcall, size_t 
npages)
 *c = 0;
 }
 
+if ( have_hbuf_lock )
+{
+struct privcmd_hcall_buf hbuf;
+
+hbuf.start = p;
+hbuf.len = size;
+
+rc = ioctl(xcall->fd, IOCTL_PRIVCMD_HCALL_BUF_LOCK, );
+if ( rc < 0 )
+{
+/*
+ * Older drivers return EINVAL if the ioctl was not
+ * supported.
+ */
+if ( errno == ENOTTY || errno == EINVAL )
+{
+have_hbuf_lock = 0;
+errno = 0;
+}
+else
+{
+PERROR("alloc_pages: lock failed");
+goto out;
+}
+}
+}
+
 return p;
 
 out:
@@ -114,11 +143,23 @@ out:
 
 void osdep_free_pages(xencall_handle *xcall, void *ptr, size_t npages)
 {
+size_t size = npages * PAGE_SIZE;
 int saved_errno = errno;
+
+if ( have_hbuf_lock )
+{
+struct privcmd_hcall_buf hbuf;
+
+hbuf.start = ptr;
+hbuf.len = size;
+
+ioctl(xcall->fd, IOCTL_PRIVCMD_HCALL_BUF_UNLOCK, );
+}
+
 /* Recover the VMA flags. Maybe it's not necessary */
-madvise(ptr, npages * PAGE_SIZE, MADV_DOFORK);
+madvise(ptr, size, MADV_DOFORK);
 
-munmap(ptr, npages * PAGE_SIZE);
+munmap(ptr, size);
 /* We MUST propagate the hypercall errno, not unmap call's. */
 errno = saved_errno;
 }
-- 
2.1.4

[Xen-devel] libxencall/linux: prevent page migration for hypercall buffers

[David Vrabel]

This is the libxencall side of the "xen/privcmd: prevent page
migration for hypercall buffers​" series for Linux.  It calls the
necessary LOCK/UNLOCK ioctls.

This should not be applied until after the Linux series is applied.

David


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

[Xen-devel] [PATCH v2 0/2] Reinstate irq alloc/dealloc locking patch

[Boris Ostrovsky]

Original version of that patch (commit a89941816726) had to be reverted
due to Xen allocating irqs in its cpu_up ops.

The first patch moves allocations into hotplug notifiers and the second
one restores the original patch (with minor adjustments to new hotplug
framework)

This originally went through tip tree but after a couple of failures
reportedby kbuild robot (due to various combinations of CONFIG_SMP and
CONFIG_XEN_PVH) I decided to take it through Xen tree (with config problems
hopefully finally fixed).

Boris Ostrovsky (2):
  xen/x86: Move irq allocation from Xen smp_op.cpu_up()
  hotplug: Prevent alloc/free of irq descriptors during cpu up/down
(again)

 arch/x86/kernel/smpboot.c | 11 -
 arch/x86/xen/enlighten.c  | 61 +--
 arch/x86/xen/smp.c| 45 ++
 arch/x86/xen/smp.h| 13 ++
 kernel/cpu.c  |  8 +++
 5 files changed, 71 insertions(+), 67 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v2 1/2] xen/x86: Move irq allocation from Xen smp_op.cpu_up()

[Boris Ostrovsky]

Commit ce0d3c0a6fb1 ("genirq: Revert sparse irq locking around
__cpu_up() and move it to x86 for now") reverted irq locking
introduced by commit a89941816726 ("hotplug: Prevent alloc/free
of irq descriptors during cpu up/down") because of Xen allocating
irqs in both of its cpu_up ops.

We can move those allocations into CPU notifiers so that original
patch can be reinstated.

Signed-off-by: Boris Ostrovsky 
---

v2: Add ifdef CONFIG_SMP to smp.h

 arch/x86/xen/enlighten.c | 61 +---
 arch/x86/xen/smp.c   | 45 ++-
 arch/x86/xen/smp.h   | 13 +++
 3 files changed, 63 insertions(+), 56 deletions(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 8ffb089..c7f6b1f9 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -140,6 +140,8 @@ RESERVE_BRK(shared_info_page_brk, PAGE_SIZE);
 __read_mostly int xen_have_vector_callback;
 EXPORT_SYMBOL_GPL(xen_have_vector_callback);
 
+static struct notifier_block xen_cpu_notifier;
+
 /*
  * Point at some empty memory to start with. We map the real shared_info
  * page as soon as fixmap is up and running.
@@ -1627,6 +1629,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
xen_initial_gdt = _cpu(gdt_page, 0);
 
xen_smp_init();
+   register_cpu_notifier(_cpu_notifier);
 
 #ifdef CONFIG_ACPI_NUMA
/*
@@ -1820,21 +1823,53 @@ static void __init init_hvm_pv_info(void)
xen_domain_type = XEN_HVM_DOMAIN;
 }
 
-static int xen_hvm_cpu_notify(struct notifier_block *self, unsigned long 
action,
- void *hcpu)
+static int xen_cpu_notify(struct notifier_block *self, unsigned long action,
+void *hcpu)
 {
int cpu = (long)hcpu;
+   int rc;
+
switch (action) {
case CPU_UP_PREPARE:
-   if (cpu_acpi_id(cpu) != U32_MAX)
-   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
-   else
-   per_cpu(xen_vcpu_id, cpu) = cpu;
-   xen_vcpu_setup(cpu);
-   if (xen_have_vector_callback) {
-   if (xen_feature(XENFEAT_hvm_safe_pvclock))
-   xen_setup_timer(cpu);
+   if (xen_hvm_domain()) {
+   /*
+* This can happen if CPU was offlined earlier and
+* offlining timed out in common_cpu_die().
+*/
+   if (cpu_report_state(cpu) == CPU_DEAD_FROZEN) {
+   xen_smp_intr_free(cpu);
+   xen_uninit_lock_cpu(cpu);
+   }
+
+   if (cpu_acpi_id(cpu) != U32_MAX)
+   per_cpu(xen_vcpu_id, cpu) = cpu_acpi_id(cpu);
+   else
+   per_cpu(xen_vcpu_id, cpu) = cpu;
+   xen_vcpu_setup(cpu);
}
+
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
+   xen_setup_timer(cpu);
+
+   rc = xen_smp_intr_init(cpu);
+   if (rc) {
+   WARN(1, "xen_smp_intr_init() for CPU %d failed: %d\n",
+cpu, rc);
+   return NOTIFY_BAD;
+   }
+
+   break;
+   case CPU_ONLINE:
+   xen_init_lock_cpu(cpu);
+   break;
+   case CPU_UP_CANCELED:
+   xen_smp_intr_free(cpu);
+   if (xen_pv_domain() ||
+   (xen_have_vector_callback &&
+xen_feature(XENFEAT_hvm_safe_pvclock)))
+   xen_teardown_timer(cpu);
break;
default:
break;
@@ -1842,8 +1877,8 @@ static int xen_hvm_cpu_notify(struct notifier_block 
*self, unsigned long action,
return NOTIFY_OK;
 }
 
-static struct notifier_block xen_hvm_cpu_notifier = {
-   .notifier_call  = xen_hvm_cpu_notify,
+static struct notifier_block xen_cpu_notifier = {
+   .notifier_call  = xen_cpu_notify,
 };
 
 #ifdef CONFIG_KEXEC_CORE
@@ -1875,7 +1910,7 @@ static void __init xen_hvm_guest_init(void)
if (xen_feature(XENFEAT_hvm_callback_vector))
xen_have_vector_callback = 1;
xen_hvm_smp_init();
-   register_cpu_notifier(_hvm_cpu_notifier);
+   register_cpu_notifier(_cpu_notifier);
xen_unplug_emulated_devices();
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 0b4d04c..137afbb 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -115,7 +115,7 @@ asmlinkage __visible void cpu_bringup_and_idle(int cpu)
cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);
 }
 
-static void 

[Xen-devel] [PATCH v2 2/2] hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)

[Boris Ostrovsky]

Now that Xen no longer allocates irqs in _cpu_up() we can restore
commit a89941816726 ("hotplug: Prevent alloc/free of irq descriptors
during cpu up/down")

Signed-off-by: Boris Ostrovsky 
Acked-by: Thomas Gleixner 
CC: x...@kernel.org
CC: Thomas Gleixner 
---
 arch/x86/kernel/smpboot.c | 11 ---
 kernel/cpu.c  |  8 
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 2a6e84a..067de61 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1108,17 +1108,8 @@ int native_cpu_up(unsigned int cpu, struct task_struct 
*tidle)
 
common_cpu_up(cpu, tidle);
 
-   /*
-* We have to walk the irq descriptors to setup the vector
-* space for the cpu which comes online.  Prevent irq
-* alloc/free across the bringup.
-*/
-   irq_lock_sparse();
-
err = do_boot_cpu(apicid, cpu, tidle);
-
if (err) {
-   irq_unlock_sparse();
pr_err("do_boot_cpu failed(%d) to wakeup CPU#%u\n", err, cpu);
return -EIO;
}
@@ -1136,8 +1127,6 @@ int native_cpu_up(unsigned int cpu, struct task_struct 
*tidle)
touch_nmi_watchdog();
}
 
-   irq_unlock_sparse();
-
return 0;
 }
 
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 341bf80..ec12b72 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -349,8 +349,16 @@ static int bringup_cpu(unsigned int cpu)
struct task_struct *idle = idle_thread_get(cpu);
int ret;
 
+   /*
+* Some architectures have to walk the irq descriptors to
+* setup the vector space for the cpu which comes online.
+* Prevent irq alloc/free across the bringup.
+*/
+   irq_lock_sparse();
+
/* Arch-specific enabling code. */
ret = __cpu_up(cpu, idle);
+   irq_unlock_sparse();
if (ret) {
cpu_notify(CPU_UP_CANCELED, cpu);
return ret;
-- 
2.7.4


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

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

[Julien Grall]

(CC Stefano)

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

Hello Sergej,

Title: s/altp2m/p2m/

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

The struct vttbr introduces a simple way to precisely access the
individual fields of the vttbr.


I am not sure whether this is really helpful. You don't seem to take
often advantage of those fields and the actual accesses don't seem
necessary (I will comment on the usage).


---
 xen/arch/arm/p2m.c  |  8 
 xen/arch/arm/traps.c|  2 +-
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 16 
 4 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 40a0b80..cbc64a1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -122,7 +122,7 @@ void p2m_restore_state(struct vcpu *n)
 WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
 isb();

-WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
+WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
 isb();

 if ( is_32bit_domain(n->domain) )
@@ -147,10 +147,10 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
  * VMID. So switch to the VTTBR of a given P2M if different.
  */
 ovttbr = READ_SYSREG64(VTTBR_EL2);
-if ( ovttbr != p2m->vttbr )
+if ( ovttbr != p2m->vttbr.vttbr )
 {
 local_irq_save(flags);
-WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
+WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
 isb();
 }

@@ -1293,7 +1293,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid &
0xff) << 48;
+p2m->vttbr.vttbr = page_to_maddr(p2m->root) |
((uint64_t)p2m->vmid & 0xff) << 48;

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 06f06e3..12be7c9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -881,7 +881,7 @@ void vcpu_show_registers(const struct vcpu *v)
 ctxt.ifsr32_el2 = v->arch.ifsr;
 #endif

-ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr;
+ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr.vttbr;

 _show_registers(>arch.cpu_info->guest_cpu_user_regs, , 1,
v);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 53c4d78..5c7cd1a 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -33,7 +33,7 @@ struct p2m_domain {
 uint8_t vmid;

 /* Current Translation Table Base Register for the p2m */
-uint64_t vttbr;
+struct vttbr vttbr;

 /*
  * Highest guest frame that's ever been mapped in the p2m
diff --git a/xen/include/asm-arm/processor.h
b/xen/include/asm-arm/processor.h
index 15bf890..f8ca18c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -529,6 +529,22 @@ union hsr {


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


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


+res1  :8,
+vmid  :8,
+res2  :8;
+};
+u64 vttbr;
+};
+};
+
+#define INVALID_VTTBR (0UL)
+
 #endif

 /* HSR.EC == HSR_CP{15,14,10}_32 */



Regards,



--
Julien Grall

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

[Xen-devel] [PATCH] x86/debug: Avoid crashing in early boot because of debugger_trap_entry()

[Andrew Cooper]

debugger_trap_entry() is not safe to use during early boot, as it follows
current before it is necesserily safe to do so.  Futhermore it does this
unconditionally, despite most callsites turning into no-ops because of the
vector test.

Inline debugger_trap_entry() into the two callers where doesn't become a
no-op, and reposition the guest_kernel_mode() test to be after the
guest_mode() test, avoiding the reference to current if the exception occured
from hypervisor context.  This makes the exception handlers safe in early
boot.  The repositioning also has bugfix in the TRAP_debug case, where dr6
will be correct in the debuggers view of state.

This causes the deletion of DEBUGGER_trap_entry(), which is a good thing as
hiding a return statement in a function-like macro is very antisocial
programming.

While cleaning this area up, drop the DEBUGGER_trap_fatal() wrapper as well,
making the code flow more apparent, and switch debugger_trap_fatal()'s return
type to boolean to match its semantics.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/traps.c   | 54 --
 xen/include/asm-x86/debugger.h | 29 +++
 2 files changed, 39 insertions(+), 44 deletions(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 767d0b0..933435d 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -736,7 +736,9 @@ void do_reserved_trap(struct cpu_user_regs *regs)
 {
 unsigned int trapnr = regs->entry_vector;
 
-DEBUGGER_trap_fatal(trapnr, regs);
+if ( debugger_trap_fatal(trapnr, regs) )
+return;
+
 show_execution_state(regs);
 panic("FATAL RESERVED TRAP %#x: %s", trapnr, trapstr(trapnr));
 }
@@ -750,8 +752,6 @@ static void do_trap(struct cpu_user_regs *regs, int 
use_error_code)
 if ( regs->error_code & X86_XEC_EXT )
 goto hardware_trap;
 
-DEBUGGER_trap_entry(trapnr, regs);
-
 if ( guest_mode(regs) )
 {
 do_guest_trap(trapnr, regs, use_error_code);
@@ -777,7 +777,8 @@ static void do_trap(struct cpu_user_regs *regs, int 
use_error_code)
 }
 
  hardware_trap:
-DEBUGGER_trap_fatal(trapnr, regs);
+if ( debugger_trap_fatal(trapnr, regs) )
+return;
 
 show_execution_state(regs);
 panic("FATAL TRAP: vector = %d (%s)\n"
@@ -1307,8 +1308,6 @@ void do_invalid_op(struct cpu_user_regs *regs)
 int id = -1, lineno;
 const struct virtual_region *region;
 
-DEBUGGER_trap_entry(TRAP_invalid_op, regs);
-
 if ( likely(guest_mode(regs)) )
 {
 if ( !emulate_invalid_rdtscp(regs) &&
@@ -1377,7 +1376,10 @@ void do_invalid_op(struct cpu_user_regs *regs)
 
 case BUGFRAME_bug:
 printk("Xen BUG at %s%s:%d\n", prefix, filename, lineno);
-DEBUGGER_trap_fatal(TRAP_invalid_op, regs);
+
+if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
+return;
+
 show_execution_state(regs);
 panic("Xen BUG at %s%s:%d", prefix, filename, lineno);
 
@@ -1389,7 +1391,10 @@ void do_invalid_op(struct cpu_user_regs *regs)
 
 printk("Assertion '%s' failed at %s%s:%d\n",
predicate, prefix, filename, lineno);
-DEBUGGER_trap_fatal(TRAP_invalid_op, regs);
+
+if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
+return;
+
 show_execution_state(regs);
 panic("Assertion '%s' failed at %s%s:%d",
   predicate, prefix, filename, lineno);
@@ -1402,14 +1407,17 @@ void do_invalid_op(struct cpu_user_regs *regs)
 regs->eip = fixup;
 return;
 }
-DEBUGGER_trap_fatal(TRAP_invalid_op, regs);
+
+if ( debugger_trap_fatal(TRAP_invalid_op, regs) )
+return;
+
 show_execution_state(regs);
 panic("FATAL TRAP: vector = %d (invalid opcode)", TRAP_invalid_op);
 }
 
 void do_int3(struct cpu_user_regs *regs)
 {
-DEBUGGER_trap_entry(TRAP_int3, regs);
+struct vcpu *curr = current;
 
 if ( !guest_mode(regs) )
 {
@@ -1417,6 +1425,13 @@ void do_int3(struct cpu_user_regs *regs)
 return;
 } 
 
+if ( guest_kernel_mode(curr, regs) && curr->domain->debugger_attached )
+{
+curr->arch.gdbsx_vcpu_event = TRAP_int3;
+domain_pause_for_debugger();
+return;
+}
+
 do_guest_trap(TRAP_int3, regs, 0);
 }
 
@@ -1744,8 +1759,6 @@ void do_page_fault(struct cpu_user_regs *regs)
 /* fixup_page_fault() might change regs->error_code, so cache it here. */
 error_code = regs->error_code;
 
-DEBUGGER_trap_entry(TRAP_page_fault, regs);
-
 perfc_incr(page_faults);
 
 if ( unlikely(fixup_page_fault(addr, regs) != 0) )
@@ -1774,7 +1787,8 @@ void do_page_fault(struct cpu_user_regs *regs)
 return;
 }
 
-DEBUGGER_trap_fatal(TRAP_page_fault, regs);
+if ( debugger_trap_fatal(TRAP_page_fault, regs) )
+return;
 
 show_execution_state(regs);
 show_page_walk(addr);
@@ 

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

[Julien Grall]

Hello Sergej,

Title: s/altp2m/p2m/

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

The struct vttbr introduces a simple way to precisely access the
individual fields of the vttbr.


I am not sure whether this is really helpful. You don't seem to take 
often advantage of those fields and the actual accesses don't seem 
necessary (I will comment on the usage).



---
 xen/arch/arm/p2m.c  |  8 
 xen/arch/arm/traps.c|  2 +-
 xen/include/asm-arm/p2m.h   |  2 +-
 xen/include/asm-arm/processor.h | 16 
 4 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 40a0b80..cbc64a1 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -122,7 +122,7 @@ void p2m_restore_state(struct vcpu *n)
 WRITE_SYSREG(hcr & ~HCR_VM, HCR_EL2);
 isb();

-WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
+WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
 isb();

 if ( is_32bit_domain(n->domain) )
@@ -147,10 +147,10 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
  * VMID. So switch to the VTTBR of a given P2M if different.
  */
 ovttbr = READ_SYSREG64(VTTBR_EL2);
-if ( ovttbr != p2m->vttbr )
+if ( ovttbr != p2m->vttbr.vttbr )
 {
 local_irq_save(flags);
-WRITE_SYSREG64(p2m->vttbr, VTTBR_EL2);
+WRITE_SYSREG64(p2m->vttbr.vttbr, VTTBR_EL2);
 isb();
 }

@@ -1293,7 +1293,7 @@ static int p2m_alloc_table(struct domain *d)

 p2m->root = page;

-p2m->vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) << 48;
+p2m->vttbr.vttbr = page_to_maddr(p2m->root) | ((uint64_t)p2m->vmid & 0xff) 
<< 48;

 /*
  * Make sure that all TLBs corresponding to the new VMID are flushed
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 06f06e3..12be7c9 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -881,7 +881,7 @@ void vcpu_show_registers(const struct vcpu *v)
 ctxt.ifsr32_el2 = v->arch.ifsr;
 #endif

-ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr;
+ctxt.vttbr_el2 = v->domain->arch.p2m.vttbr.vttbr;

 _show_registers(>arch.cpu_info->guest_cpu_user_regs, , 1, v);
 }
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 53c4d78..5c7cd1a 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -33,7 +33,7 @@ struct p2m_domain {
 uint8_t vmid;

 /* Current Translation Table Base Register for the p2m */
-uint64_t vttbr;
+struct vttbr vttbr;

 /*
  * Highest guest frame that's ever been mapped in the p2m
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 15bf890..f8ca18c 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -529,6 +529,22 @@ union hsr {


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


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



+res1  :8,
+vmid  :8,
+res2  :8;
+};
+u64 vttbr;
+};
+};
+
+#define INVALID_VTTBR (0UL)
+
 #endif

 /* HSR.EC == HSR_CP{15,14,10}_32 */



Regards,

--
Julien Grall

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

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

[David Vrabel]

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

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

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

Locked buffers are stored in a rbtree for faster lookup during UNLOCK,
and stored in a list so all buffers can be unlocked when the file
descriptor is closed.

Signed-off-by: David Vrabel 
---
 drivers/xen/privcmd.c  | 208 +
 include/uapi/xen/privcmd.h |  37 
 2 files changed, 245 insertions(+)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index ac76bc4..7fc9db8 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -43,6 +44,21 @@ MODULE_LICENSE("GPL");
 
 #define PRIV_VMA_LOCKED ((void *)1)
 
+struct privcmd_data {
+   struct rb_root hbuf_root;
+   struct list_head hbuf_list;
+   struct mutex hbuf_mutex;
+};
+
+struct privcmd_hbuf {
+   struct rb_node node;
+   struct list_head release_node;
+   struct privcmd_hcall_buf buf;
+   unsigned int nr_pages;
+   struct page **pages;
+   unsigned int count;
+};
+
 static int privcmd_vma_range_is_mapped(
struct vm_area_struct *vma,
unsigned long addr,
@@ -548,9 +564,164 @@ out_unlock:
goto out;
 }
 
+static int privcmd_hbuf_compare(struct privcmd_hcall_buf *a,
+   struct privcmd_hcall_buf *b)
+{
+   if (b->start == a->start)
+   return b->len - a->len;
+   return b->start - a->start;
+}
+
+static void privcmd_hbuf_insert(struct privcmd_data *priv,
+   struct privcmd_hbuf *hbuf)
+{
+   struct rb_node **new = >hbuf_root.rb_node, *parent = NULL;
+
+   /* Figure out where to put new node */
+   while (*new) {
+   struct privcmd_hbuf *this = container_of(*new, struct 
privcmd_hbuf, node);
+   int result = privcmd_hbuf_compare(>buf, >buf);
+
+   parent = *new;
+   if (result < 0)
+   new = &(*new)->rb_left;
+   else if (result > 0)
+   new = &(*new)->rb_right;
+   else {
+   this->count++;
+   kfree(hbuf->pages);
+   kfree(hbuf);
+   return;
+   }
+   }
+
+   /* Add new node and rebalance tree. */
+   rb_link_node(>node, parent, new);
+   rb_insert_color(>node, >hbuf_root);
+
+   list_add_tail(>release_node, >hbuf_list);
+
+   hbuf->count = 1;
+}
+
+static struct privcmd_hbuf *privcmd_hbuf_lookup(struct privcmd_data *priv,
+   struct privcmd_hcall_buf *key)
+{
+   struct rb_node *node = priv->hbuf_root.rb_node;
+
+   while (node) {
+   struct privcmd_hbuf *hbuf = container_of(node, struct 
privcmd_hbuf, node);
+   int result;
+
+   result = privcmd_hbuf_compare(key, >buf);
+
+   if (result < 0)
+   node = node->rb_left;
+   else if (result > 0)
+   node = node->rb_right;
+   else
+   return hbuf;
+   }
+   return NULL;
+}
+
+static void privcmd_hbuf_unlock(struct privcmd_data *priv,
+   struct privcmd_hbuf *hbuf)
+{
+   unsigned int i;
+
+   for (i = 0; i < hbuf->nr_pages; i++)
+   put_page(hbuf->pages[i]);
+
+   if (--hbuf->count == 0) {
+   rb_erase(>node, >hbuf_root);
+   list_del(>release_node);
+   kfree(hbuf->pages);
+   kfree(hbuf);
+   }
+}
+
+static int privcmd_ioctl_hcall_buf_lock(struct privcmd_data *priv,
+   void __user *udata)
+{
+   struct privcmd_hbuf *hbuf;
+   unsigned long start, end;
+   int ret;
+
+   hbuf = kzalloc(sizeof(*hbuf), GFP_KERNEL);
+   if (!hbuf)
+   return -ENOMEM;
+
+   if (copy_from_user(>buf, udata, sizeof(hbuf->buf))) {
+   ret = -EFAULT;
+ 

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

[David Vrabel]

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

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

There are three possible ways to do this:

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

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

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

Any thoughts on which is the best approach?

David


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

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

[David Vrabel]

The standard return value for ioctl(2) where the cmd is not supported
is ENOTTY, not EINVAL.

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

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


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

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

[Julien Grall]

Hello Sergej,

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

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

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

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

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

 #include 

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


Why not using altp2m_active(d) here?

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


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall]

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

On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall  wrote:

Hi Tamas,


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


On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall  wrote:


Hello Sergej,

Please try to reply to all when answering on the ML. Otherwise the answer
may be delayed/lost.

On 03/08/16 13:45, Sergej Proskurin wrote:



The interesting part about #VE is that it allows to handle certain
violations (currently limited to EPT violations -- future
implementations might introduce also further violations) inside of the
guest, without the need to explicitly trap into the VMM. Thus, #VE allow
switching of different memory views in-guest. Because of this, I also
agree that event channels would suffice in our case, since we do not
have sufficient hardware support on ARM and would need to trap into the
VMM anyway.




The cost of doing an hypercall on ARM is very small compare to x86 (~1/3
of
the number of x86 cycles) because we don't have to save all the state
every
time. So I am not convinced by the argument of limiting the number of
trap
to the hypervisor and allow a guest to play with altp2m on ARM.

I will have to see a concrete example before going forward with the event
channel.



It is out-of-scope for what we are trying to achieve with this series
at this point. The question at hand is really whether the atp2m switch
and gfn remapping ops should be exposed to the guest. Without #VE -
which we are not implementing - setting the mem_access settings from
within the guest doesn't make sense so restricting access there is
reasonable.

As I outlined, the switch and gfn remapping can have legitimate
use-cases by themselves without any mem_access bits involved. However,
it is not our use-case so we have no problem restricting access there
either. So the question is whether that's the right path to take here.
At this point I'm not sure there is agreement about it or not.



Could you give a legitimate use case of gfn remapping from the guest? And
explain how it would work with only this patch series.

From my perspective, and after the numerous exchange in this thread, I do
not think it is wise to expose this interface to the guest on ARM. The usage
is very limited but increase the surface attack. So I will not ack a such
choice, however I will not nack it.



Since the interface would be available only for domains where they
were explicitly created with altp2m=1 flag set I think the exposure is
minimal.

As for a use-case, I don't have a real world example as it's not how
we use the system. But as I pointed out eairlier I could imagine the
gfn remapping be used to protect kernel memory areas against
information disclosure by only switching to the accessible altp2m view
when certain conditions are met. What I mean is that a certain gfn
could be remapped to a dummy mfn by default and only switched to the
accessible view when necessary. How much extra protection that would
add and under what condition is up for debate but IMHO it is a
legitimate experimental use - and altp2m is an experimental system.


A such solution may give you a lots of headache with the cache.



Whether it's worth to have such an interface or not I'm not sure, I'm
OK with going either way on this, but since it's available on x86 I
think it would make sense to have feature parity - even if only
partially for now.


As I mentioned a couple of times, we do not introduce features on ARM 
just because they exists on x86. We introduce them after careful think 
about how they could benefits ARM and the usage.


Nothing prevents a follow-up series to allow the guest accessing altp2m 
operation by default because the interface is already there.


Stefano, do you have any opinions on this?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 10:24 AM, Julien Grall  wrote:
> Hi Tamas,
>
>
> On 03/08/16 17:01, Tamas K Lengyel wrote:
>>
>> On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall  wrote:
>>>
>>> Hello Sergej,
>>>
>>> Please try to reply to all when answering on the ML. Otherwise the answer
>>> may be delayed/lost.
>>>
>>> On 03/08/16 13:45, Sergej Proskurin wrote:


 The interesting part about #VE is that it allows to handle certain
 violations (currently limited to EPT violations -- future
 implementations might introduce also further violations) inside of the
 guest, without the need to explicitly trap into the VMM. Thus, #VE allow
 switching of different memory views in-guest. Because of this, I also
 agree that event channels would suffice in our case, since we do not
 have sufficient hardware support on ARM and would need to trap into the
 VMM anyway.
>>>
>>>
>>>
>>> The cost of doing an hypercall on ARM is very small compare to x86 (~1/3
>>> of
>>> the number of x86 cycles) because we don't have to save all the state
>>> every
>>> time. So I am not convinced by the argument of limiting the number of
>>> trap
>>> to the hypervisor and allow a guest to play with altp2m on ARM.
>>>
>>> I will have to see a concrete example before going forward with the event
>>> channel.
>>
>>
>> It is out-of-scope for what we are trying to achieve with this series
>> at this point. The question at hand is really whether the atp2m switch
>> and gfn remapping ops should be exposed to the guest. Without #VE -
>> which we are not implementing - setting the mem_access settings from
>> within the guest doesn't make sense so restricting access there is
>> reasonable.
>>
>> As I outlined, the switch and gfn remapping can have legitimate
>> use-cases by themselves without any mem_access bits involved. However,
>> it is not our use-case so we have no problem restricting access there
>> either. So the question is whether that's the right path to take here.
>> At this point I'm not sure there is agreement about it or not.
>
>
> Could you give a legitimate use case of gfn remapping from the guest? And
> explain how it would work with only this patch series.
>
> From my perspective, and after the numerous exchange in this thread, I do
> not think it is wise to expose this interface to the guest on ARM. The usage
> is very limited but increase the surface attack. So I will not ack a such
> choice, however I will not nack it.
>

Since the interface would be available only for domains where they
were explicitly created with altp2m=1 flag set I think the exposure is
minimal.

As for a use-case, I don't have a real world example as it's not how
we use the system. But as I pointed out eairlier I could imagine the
gfn remapping be used to protect kernel memory areas against
information disclosure by only switching to the accessible altp2m view
when certain conditions are met. What I mean is that a certain gfn
could be remapped to a dummy mfn by default and only switched to the
accessible view when necessary. How much extra protection that would
add and under what condition is up for debate but IMHO it is a
legitimate experimental use - and altp2m is an experimental system.

Whether it's worth to have such an interface or not I'm not sure, I'm
OK with going either way on this, but since it's available on x86 I
think it would make sense to have feature parity - even if only
partially for now.

Thanks,
Tamas

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

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

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 10:10 AM, George Dunlap  wrote:
> On 03/08/16 16:58, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap  
>> wrote:
>>> On 03/08/16 16:40, Tamas K Lengyel wrote:
 On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap  
 wrote:
> On 03/08/16 16:18, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap  
>> wrote:
>>> On 01/08/16 17:52, Tamas K Lengyel wrote:
 The two functions monitor_traps and mem_access_send_req duplicate some 
 of the
 same functionality. The mem_access_send_req however leaves a lot of the
 standard vm_event fields to be filled by other functions.

 Remove mem_access_send_req() completely, making use of monitor_traps() 
 to put
 requests into the monitor ring.  This in turn causes some cleanup 
 around the
 old callsites of mem_access_send_req(), and on ARM, the introduction 
 of the
 __p2m_mem_access_send_req() helper to fill in common mem_access 
 information.
 We also update monitor_traps to now include setting the common vcpu_id 
 field
 so that all other call-sites can ommit this step.

 Finally, this change identifies that errors from mem_access_send_req() 
 were
 never checked.  As errors constitute a problem with the monitor ring,
 crashing the domain is the most appropriate action to take.

 Signed-off-by: Tamas K Lengyel 
 Reviewed-by: Andrew Cooper 
>>>
>>> This appears to be v3, not v2?
>>
>> No, it's still just v2.
>>
>>>
 diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
 index 812dbf6..27f9d26 100644
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
 unsigned long gla,
  if ( req )
  {
  *req_ptr = req;
 -req->reason = VM_EVENT_REASON_MEM_ACCESS;
 -
 -/* Pause the current VCPU */
 -if ( p2ma != p2m_access_n2rwx )
 -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;

 -/* Send request to mem event */
 +req->reason = VM_EVENT_REASON_MEM_ACCESS;
  req->u.mem_access.gfn = gfn;
  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
  if ( npfec.gla_valid )
 @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
 unsigned long gla,
  req->u.mem_access.flags |= npfec.read_access? 
 MEM_ACCESS_R : 0;
  req->u.mem_access.flags |= npfec.write_access   ? 
 MEM_ACCESS_W : 0;
  req->u.mem_access.flags |= npfec.insn_fetch ? 
 MEM_ACCESS_X : 0;
 -req->vcpu_id = v->vcpu_id;
 -
 -vm_event_fill_regs(req);
 -
 -if ( altp2m_active(v->domain) )
 -{
 -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
 -req->altp2m_idx = vcpu_altp2m(v).p2midx;
 -}
  }

 -/* Pause the current VCPU */
 -if ( p2ma != p2m_access_n2rwx )
 -vm_event_vcpu_pause(v);
 -
 -/* VCPU may be paused, return whether we promoted automatically */
 -return (p2ma == p2m_access_n2rwx);
 +/* Return whether vCPU pause is required (aka. sync event) */
 +return (p2ma != p2m_access_n2rwx);
  }

  static inline
>>>
>>> p2m-bits:
>>>
>>> Acked-by: George Dunlap 
>>>
>>> But I agree with Julien -- this patch has several independent changes
>>> which makes it quite difficult to tell what's going on.  I'm sure it's
>>> taken the two of us a lot more time together to figure out what is and
>>> is not happening than it would have for you to break it down into
>>> several little chunks.
>>>
>>> If you're not already familiar with it, I would recommend looking into
>>> stackgit.  My modus operandi for things like this is to get things
>>> working in one big patch, then pop it off the stack and apply bits of it
>>> at a time to make a series.
>>>
>>> It's not only more considerate of your reviewers, but it's also a
>>> helpful exercise for yourself.
>>>
>>
>> The extra work doesn't just come from splitting the code itself
>> (although I don't know which bits would really make sense to split
>> here that would worth the effort) but testing a series on various
>> platforms.
>
> I 

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Julien Grall]

Hi Tamas,

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

On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall  wrote:

Hello Sergej,

Please try to reply to all when answering on the ML. Otherwise the answer
may be delayed/lost.

On 03/08/16 13:45, Sergej Proskurin wrote:


The interesting part about #VE is that it allows to handle certain
violations (currently limited to EPT violations -- future
implementations might introduce also further violations) inside of the
guest, without the need to explicitly trap into the VMM. Thus, #VE allow
switching of different memory views in-guest. Because of this, I also
agree that event channels would suffice in our case, since we do not
have sufficient hardware support on ARM and would need to trap into the
VMM anyway.



The cost of doing an hypercall on ARM is very small compare to x86 (~1/3 of
the number of x86 cycles) because we don't have to save all the state every
time. So I am not convinced by the argument of limiting the number of trap
to the hypervisor and allow a guest to play with altp2m on ARM.

I will have to see a concrete example before going forward with the event
channel.


It is out-of-scope for what we are trying to achieve with this series
at this point. The question at hand is really whether the atp2m switch
and gfn remapping ops should be exposed to the guest. Without #VE -
which we are not implementing - setting the mem_access settings from
within the guest doesn't make sense so restricting access there is
reasonable.

As I outlined, the switch and gfn remapping can have legitimate
use-cases by themselves without any mem_access bits involved. However,
it is not our use-case so we have no problem restricting access there
either. So the question is whether that's the right path to take here.
At this point I'm not sure there is agreement about it or not.


Could you give a legitimate use case of gfn remapping from the guest? 
And explain how it would work with only this patch series.


From my perspective, and after the numerous exchange in this thread, I 
do not think it is wise to expose this interface to the guest on ARM. 
The usage is very limited but increase the surface attack. So I will not 
ack a such choice, however I will not nack it.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[Roger Pau Monne]

On Wed, Aug 03, 2016 at 10:15:51AM -0600, Jan Beulich wrote:
> >>> On 03.08.16 at 18:00,  wrote:
> > On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote:
> >> >>> On 03.08.16 at 17:28,  wrote:
> >> > On 03/08/16 16:25, Jan Beulich wrote:
> >> > On 03.08.16 at 17:11,  wrote:
> >> >>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
> >> >>> On 02.08.16 at 17:49,  wrote:
> >> > On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
> >> >> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> >> >>> As this is for the construction of dom0, it would be better to 
> >> >>> take a
> >> >>> preemptible pointer, loop in construct_dom0(), with a
> >> >>> process_pending_softirqs() call in between.
> >> >>
> >> >> Now fixed.
> >> >
> >> > Hm, I have to stand corrected, using hypercall_preempt_check (as
> >> > any of the *_set_allocation function use), is not safe at this point:
> >> >
> >> > (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
> >> > (XEN) CPU:0
> >> > (XEN) RIP:e008:[] 
> >> >>> hap.c#local_events_need_delivery+0x27/0x40
> >> > (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> >> > (XEN) rax:    rbx: 83023f5a5000   rcx: 
> >> > 82d080312900
> >> > (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 
> >> > 8300b213d000
> >> > (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  
> >> > 0180
> >> > (XEN) r9:     r10: 00247000   r11: 
> >> > 82d08029a5b0
> >> > (XEN) r12: 0011   r13: 23ac   r14: 
> >> > 82d080307d4c
> >> > (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 
> >> > 001526e0
> >> > (XEN) cr3: b20fc000   cr2: 
> >> > (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> >> > (XEN) Xen code around  
> >> >>> (hap.c#local_events_need_delivery+0x27/0x40):
> >> > (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 
> >> > eb 02 31 
> > 
> >> >>> c0
> >> > (XEN) Xen stack trace from rsp=82d080307cc8:
> >> > (XEN)82d080307d08 82d08022fc47  
> > 83023f5a5000
> >> > (XEN)83023f5a5648  82d080307d4c 
> > 2400
> >> > (XEN)82d080307d38 82d08020008c 000d 
> > 8300b1efd000
> >> > (XEN)83023f5a5000 82d080307d4c 82d080307d78 
> > 82d0802cad30
> >> > (XEN)00203000 83023f5a5000 82d0802bf860 
> > 
> >> > (XEN)0001 8308bef0 82d080307de8 
> > 82d0802c91e0
> >> > (XEN)82d080307de8 82d080143900 82d080307de8 
> > 
> >> > (XEN)8308bf00 82d0802eb480 82d080307dc4 
> > 82d08028b1cd
> >> > (XEN)8308bf00  0001 
> > 83023f5a5000
> >> > (XEN)82d080307f08 82d0802bf0c9  
> > 
> >> > (XEN) 82d080307f18 8308bee0 
> > 0001
> >> > (XEN)0001 0001  
> > 0010
> >> > (XEN)0001 00247000 8308bef4 
> > 0010
> >> > (XEN)8301 00247001 0014 
> > 0001
> >> > (XEN)8300ffec 8308bef0 82d0802e0640 
> > 8308bfb0
> >> > (XEN)  0111 
> > 0008
> >> > (XEN)0001006e 0003 02f8 
> > 
> >> > (XEN)ad5c0bd0  0001 
> > 0008
> >> > (XEN) 82d080100073  
> > 
> >> > (XEN)   
> > 
> >> > (XEN) Xen call trace:
> >> > (XEN)[] 
> >> > hap.c#local_events_need_delivery+0x27/0x40
> >> > (XEN)[] hap_set_allocation+0x107/0x130
> >> > (XEN)[] paging_set_allocation+0x4c/0x80
> >> > (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
> >> > (XEN)[] 
> >> > domain_build.c#construct_dom0_hvm+0x60/0x120
> >> > (XEN)[] __start_xen+0x1ea9/0x23a0
> >> > (XEN)[] __high_start+0x53/0x60
> >> > (XEN)
> >> > (XEN) Pagetable walk from :
> >> 
> >>  Sadly you don't make clear what pointer it is that is NULL at that 
> >>  point.
> >> >>>
> >> >>> It sounds from what he says in the following paragraph like current is 
> > NULL.
> >> >> 
> >> >> I don't recall us re-setting 

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Jan Beulich]

>>> On 03.08.16 at 18:10,  wrote:
> George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu 
> depriv)"):
>> So before qemu devpriv can be usable, *all* the HVMCTL operations would
>> need to be audited, and those that were deemed insecure would need to be
>> either fixed or removed.
> 
> Even worse, the bad HVMCTLs would be retrospectively turned into
> security-bugs-in-old-hypervisors.  I don't think this is tenable.

How would a bug in the respective current hvmop then not be a
security issue as well?

Jan


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

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

[Julien Grall]

On 03/08/16 16:58, Tamas K Lengyel wrote:

Well, you never know when your series gets split up and have only bits
of it merged. So having each patch tested individually is a necessity
to ensure nothing gets broken midway through. Especially since
mem_access/monitor/vm_event is not tested automatically in the Xen
test system.


It might be worth to add test for mem_access/monitor/vm_event in Osstest.

Regards,

--
Julien Grall

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  2615485905a34da095a2453b3991c5adba7f33da
baseline version:
 xen  45a348ebaba3f6e0a26455a3ff181a41722943a0

Last test of basis99921  2016-08-03 12:02:09 Z0 days
Testing same since99926  2016-08-03 15:01:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Dario Faggioli 
  George Dunlap 
  Jacob Pan 
  Jan Beulich 
  Joao Martins 
  Juergen Gross 
  Len Brown 
  Rafael J. Wysocki 

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=2615485905a34da095a2453b3991c5adba7f33da
+ . ./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 
2615485905a34da095a2453b3991c5adba7f33da
+ branch=xen-unstable-smoke
+ revision=2615485905a34da095a2453b3991c5adba7f33da
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x2615485905a34da095a2453b3991c5adba7f33da = 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 

Re: [Xen-devel] [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests

[Andrew Cooper]

On 03/08/16 17:11, Jan Beulich wrote:
 On 05.07.16 at 21:05,  wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
>> domcr_flags,
>>  }
>>  else
>>  {
>> -if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
>> +uint32_t emflags;
>> +
>> +if ( is_hardware_domain(d) )
>> +config->emulation_flags |= XEN_X86_EMU_PIT;
>> +
>> +emflags = config->emulation_flags;
>> +if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )
> In cases like this please consider dropping the pointless != 0.
>
>>  {
>>  printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
>> -   d->domain_id, config->emulation_flags);
>> +   d->domain_id, emflags);
>>  return -EINVAL;
>>  }
>> -if ( is_hardware_domain(d) )
>> -config->emulation_flags |= XEN_X86_EMU_PIT;
>> -if ( config->emulation_flags != 0 &&
>> - (config->emulation_flags !=
>> -  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
>> +
>> +/* PVHv2 guests can request emulated APIC */
> Comment style. With at least this one fixed
> Reviewed-by: Jan Beulich 
>
>> +if ( emflags &&
>> +(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
>> + (emflags != XEN_X86_EMU_LAPIC)) :
>> +(emflags != XEN_X86_EMU_PIT)) )
> I guess sooner or later this will need re-arranging so that it's easier
> to maintain when more variations are permitted for HVM, but for
> now I think it's fine.

Roger already did this at my request on a different thread.

Message: <20160801112343.7ndtre6tfzxk3xjd@mac>, subject "[PATCH RFC
03/12] xen/x86: allow the emulated APICs to be enbled for the hardware
domain"

And on that note, Roger: you have a typo in your patch subject.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[Jan Beulich]

>>> On 03.08.16 at 18:00,  wrote:
> On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote:
>> >>> On 03.08.16 at 17:28,  wrote:
>> > On 03/08/16 16:25, Jan Beulich wrote:
>> > On 03.08.16 at 17:11,  wrote:
>> >>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
>> >>> On 02.08.16 at 17:49,  wrote:
>> > On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
>> >> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
>> >>> As this is for the construction of dom0, it would be better to take a
>> >>> preemptible pointer, loop in construct_dom0(), with a
>> >>> process_pending_softirqs() call in between.
>> >>
>> >> Now fixed.
>> >
>> > Hm, I have to stand corrected, using hypercall_preempt_check (as
>> > any of the *_set_allocation function use), is not safe at this point:
>> >
>> > (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
>> > (XEN) CPU:0
>> > (XEN) RIP:e008:[] 
>> >>> hap.c#local_events_need_delivery+0x27/0x40
>> > (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
>> > (XEN) rax:    rbx: 83023f5a5000   rcx: 
>> > 82d080312900
>> > (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 
>> > 8300b213d000
>> > (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  
>> > 0180
>> > (XEN) r9:     r10: 00247000   r11: 
>> > 82d08029a5b0
>> > (XEN) r12: 0011   r13: 23ac   r14: 
>> > 82d080307d4c
>> > (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 
>> > 001526e0
>> > (XEN) cr3: b20fc000   cr2: 
>> > (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>> > (XEN) Xen code around  
>> >>> (hap.c#local_events_need_delivery+0x27/0x40):
>> > (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 
>> > eb 02 31 
> 
>> >>> c0
>> > (XEN) Xen stack trace from rsp=82d080307cc8:
>> > (XEN)82d080307d08 82d08022fc47  
> 83023f5a5000
>> > (XEN)83023f5a5648  82d080307d4c 
> 2400
>> > (XEN)82d080307d38 82d08020008c 000d 
> 8300b1efd000
>> > (XEN)83023f5a5000 82d080307d4c 82d080307d78 
> 82d0802cad30
>> > (XEN)00203000 83023f5a5000 82d0802bf860 
> 
>> > (XEN)0001 8308bef0 82d080307de8 
> 82d0802c91e0
>> > (XEN)82d080307de8 82d080143900 82d080307de8 
> 
>> > (XEN)8308bf00 82d0802eb480 82d080307dc4 
> 82d08028b1cd
>> > (XEN)8308bf00  0001 
> 83023f5a5000
>> > (XEN)82d080307f08 82d0802bf0c9  
> 
>> > (XEN) 82d080307f18 8308bee0 
> 0001
>> > (XEN)0001 0001  
> 0010
>> > (XEN)0001 00247000 8308bef4 
> 0010
>> > (XEN)8301 00247001 0014 
> 0001
>> > (XEN)8300ffec 8308bef0 82d0802e0640 
> 8308bfb0
>> > (XEN)  0111 
> 0008
>> > (XEN)0001006e 0003 02f8 
> 
>> > (XEN)ad5c0bd0  0001 
> 0008
>> > (XEN) 82d080100073  
> 
>> > (XEN)   
> 
>> > (XEN) Xen call trace:
>> > (XEN)[] 
>> > hap.c#local_events_need_delivery+0x27/0x40
>> > (XEN)[] hap_set_allocation+0x107/0x130
>> > (XEN)[] paging_set_allocation+0x4c/0x80
>> > (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
>> > (XEN)[] 
>> > domain_build.c#construct_dom0_hvm+0x60/0x120
>> > (XEN)[] __start_xen+0x1ea9/0x23a0
>> > (XEN)[] __high_start+0x53/0x60
>> > (XEN)
>> > (XEN) Pagetable walk from :
>> 
>>  Sadly you don't make clear what pointer it is that is NULL at that 
>>  point.
>> >>>
>> >>> It sounds from what he says in the following paragraph like current is 
> NULL.
>> >> 
>> >> I don't recall us re-setting current to this late in the boot process.
>> >> Even during early boot we set it to a bogus non-NULL value rather
>> >> than NULL.
>> >> 
>> > I've tried setting current to d->vcpu[0], but that just makes the call 
>> > to
>> > hypercall_preempt_check crash in some 

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Ian Jackson]

George Dunlap writes ("Re: Device model operation hypercall (DMOP, re qemu 
depriv)"):
> So before qemu devpriv can be usable, *all* the HVMCTL operations would
> need to be audited, and those that were deemed insecure would need to be
> either fixed or removed.

Even worse, the bad HVMCTLs would be retrospectively turned into
security-bugs-in-old-hypervisors.  I don't think this is tenable.

Ian.

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

Re: [Xen-devel] [PATCH v1 16/20] x86: Allow LAPIC-only emulation_flags for HVM guests

[Jan Beulich]

>>> On 05.07.16 at 21:05,  wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -545,25 +545,31 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  }
>  else
>  {
> -if ( (config->emulation_flags & ~XEN_X86_EMU_ALL) != 0 )
> +uint32_t emflags;
> +
> +if ( is_hardware_domain(d) )
> +config->emulation_flags |= XEN_X86_EMU_PIT;
> +
> +emflags = config->emulation_flags;
> +if ( (emflags & ~XEN_X86_EMU_ALL) != 0 )

In cases like this please consider dropping the pointless != 0.

>  {
>  printk(XENLOG_G_ERR "d%d: Invalid emulation bitmap: %#x\n",
> -   d->domain_id, config->emulation_flags);
> +   d->domain_id, emflags);
>  return -EINVAL;
>  }
> -if ( is_hardware_domain(d) )
> -config->emulation_flags |= XEN_X86_EMU_PIT;
> -if ( config->emulation_flags != 0 &&
> - (config->emulation_flags !=
> -  (is_hvm_domain(d) ? XEN_X86_EMU_ALL : XEN_X86_EMU_PIT)) )
> +
> +/* PVHv2 guests can request emulated APIC */

Comment style. With at least this one fixed
Reviewed-by: Jan Beulich 

> +if ( emflags &&
> +(is_hvm_domain(d) ? ((emflags != XEN_X86_EMU_ALL) &&
> + (emflags != XEN_X86_EMU_LAPIC)) :
> +(emflags != XEN_X86_EMU_PIT)) )

I guess sooner or later this will need re-arranging so that it's easier
to maintain when more variations are permitted for HVM, but for
now I think it's fine.

Jan


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

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

[George Dunlap]

On 03/08/16 16:58, Tamas K Lengyel wrote:
> On Wed, Aug 3, 2016 at 9:44 AM, George Dunlap  
> wrote:
>> On 03/08/16 16:40, Tamas K Lengyel wrote:
>>> On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap  
>>> wrote:
 On 03/08/16 16:18, Tamas K Lengyel wrote:
> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap  
> wrote:
>> On 01/08/16 17:52, Tamas K Lengyel wrote:
>>> The two functions monitor_traps and mem_access_send_req duplicate some 
>>> of the
>>> same functionality. The mem_access_send_req however leaves a lot of the
>>> standard vm_event fields to be filled by other functions.
>>>
>>> Remove mem_access_send_req() completely, making use of monitor_traps() 
>>> to put
>>> requests into the monitor ring.  This in turn causes some cleanup 
>>> around the
>>> old callsites of mem_access_send_req(), and on ARM, the introduction of 
>>> the
>>> __p2m_mem_access_send_req() helper to fill in common mem_access 
>>> information.
>>> We also update monitor_traps to now include setting the common vcpu_id 
>>> field
>>> so that all other call-sites can ommit this step.
>>>
>>> Finally, this change identifies that errors from mem_access_send_req() 
>>> were
>>> never checked.  As errors constitute a problem with the monitor ring,
>>> crashing the domain is the most appropriate action to take.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>>
>> This appears to be v3, not v2?
>
> No, it's still just v2.
>
>>
>>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>>> index 812dbf6..27f9d26 100644
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
>>> unsigned long gla,
>>>  if ( req )
>>>  {
>>>  *req_ptr = req;
>>> -req->reason = VM_EVENT_REASON_MEM_ACCESS;
>>> -
>>> -/* Pause the current VCPU */
>>> -if ( p2ma != p2m_access_n2rwx )
>>> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
>>>
>>> -/* Send request to mem event */
>>> +req->reason = VM_EVENT_REASON_MEM_ACCESS;
>>>  req->u.mem_access.gfn = gfn;
>>>  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
>>>  if ( npfec.gla_valid )
>>> @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, 
>>> unsigned long gla,
>>>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R 
>>> : 0;
>>>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W 
>>> : 0;
>>>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X 
>>> : 0;
>>> -req->vcpu_id = v->vcpu_id;
>>> -
>>> -vm_event_fill_regs(req);
>>> -
>>> -if ( altp2m_active(v->domain) )
>>> -{
>>> -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>>> -req->altp2m_idx = vcpu_altp2m(v).p2midx;
>>> -}
>>>  }
>>>
>>> -/* Pause the current VCPU */
>>> -if ( p2ma != p2m_access_n2rwx )
>>> -vm_event_vcpu_pause(v);
>>> -
>>> -/* VCPU may be paused, return whether we promoted automatically */
>>> -return (p2ma == p2m_access_n2rwx);
>>> +/* Return whether vCPU pause is required (aka. sync event) */
>>> +return (p2ma != p2m_access_n2rwx);
>>>  }
>>>
>>>  static inline
>>
>> p2m-bits:
>>
>> Acked-by: George Dunlap 
>>
>> But I agree with Julien -- this patch has several independent changes
>> which makes it quite difficult to tell what's going on.  I'm sure it's
>> taken the two of us a lot more time together to figure out what is and
>> is not happening than it would have for you to break it down into
>> several little chunks.
>>
>> If you're not already familiar with it, I would recommend looking into
>> stackgit.  My modus operandi for things like this is to get things
>> working in one big patch, then pop it off the stack and apply bits of it
>> at a time to make a series.
>>
>> It's not only more considerate of your reviewers, but it's also a
>> helpful exercise for yourself.
>>
>
> The extra work doesn't just come from splitting the code itself
> (although I don't know which bits would really make sense to split
> here that would worth the effort) but testing a series on various
> platforms.

 I don't understand this statement -- why is testing a 3-patch series
 more difficult than testing a one-patch series?  Are you testing each
 individual patch?

>>>
>>> Yes, I do. And when a 

Re: [Xen-devel] [PATCH v1 14/20] acpi: Move ACPI code to tools/libacpi

[Jan Beulich]

>>> On 05.07.16 at 21:05,  wrote:
> Signed-off-by: Boris Ostrovsky 

Acked-by: Jan Beulich 
with a suggestion and a minor remark:

> @@ -90,16 +87,20 @@ ROMS += $(SEABIOS_ROM)
>  endif
>  
>  .PHONY: all
> -all: subdirs-all
> +all: acpi subdirs-all
>   $(MAKE) hvmloader
>  
> +.PHONY: acpi
> +acpi:
> + $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(shell pwd)

$(CURDIR) ?

> @@ -153,6 +154,7 @@ endif
>  clean: subdirs-clean
>   rm -f roms.inc roms.inc.new acpi.h
>   rm -f hvmloader hvmloader.tmp *.o $(DEPS)
> + $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(shell pwd) clean

Again.

> --- a/tools/firmware/hvmloader/acpi/Makefile
> +++ b/tools/libacpi/Makefile
> @@ -14,7 +14,7 @@
>  # this program; If not, see .
>  #
>  
> -XEN_ROOT = $(CURDIR)/../../../..
> +XEN_ROOT = $(CURDIR)/../../

Not how the original does not end in a slash.

Jan


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

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

[Jan Beulich]

>>> On 05.07.16 at 21:05,  wrote:
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -1115,7 +1115,12 @@ static int __vlapic_accept_pic_intr(struct vcpu *v)
>  struct domain *d = v->domain;
>  struct vlapic *vlapic = vcpu_vlapic(v);
>  uint32_t lvt0 = vlapic_get_reg(vlapic, APIC_LVT0);
> -union vioapic_redir_entry redir0 = domain_vioapic(d)->redirtbl[0];
> +union vioapic_redir_entry redir0;
> +
> +if ( !has_vioapic(d) || !has_vpic(d) )

The has_vpic() part should really be an ASSERT(), as both callers
already do that check afaics. With that adjusted
Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

[Ian Jackson]

Andrew Cooper writes ("Re: [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so 
_everything_ uses git cache"):
> On 03/08/16 16:47, Ian Jackson wrote:
> Note that the git config url insteadOf feature is backwards: one
> configures the config variable "url.NEW-URL.insteadOf.OLD-URL".  So
> the key is the value, and the value is the key.
...
> FWIW, LGTM.

Thanks.  It passed my adhoc test.  I have pushed it to osstest
pretest.

I expected that without more, this job would still fail because the
new firewall would prevent the upload talking to the Coverity server.

I have added a firewall rule to the colo which permits the controller
(`osstest' VM) to talk to port 443 on what is currently the apparent
IP address of scan.coverity.com.

If this IP address changes in future, this will break.  But this
approach will do if that doesn't happen too often.

Let's see if the whole thing works again now.

Thanks,
Ian.

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

[Xen-devel] [xen-unstable test] 99917: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  9 debian-di-install  fail in 99911 pass in 99917
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 99911

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 99911 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 99911 never pass
 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-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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-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-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  e9522e4932aaa7f083688b6612b5897839409260
baseline version:
 xen  2eee1c746af6f683247700642786b7c21c991234

Last test of basis99906  2016-08-02 15:19:48 Z1 days
Testing same since99911  2016-08-03 00:44:31 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Juergen Gross 
  Kevin Tian 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 
  Tamas K Lengyel 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 00/25] arm/altp2m: Introducing altp2m to ARM.

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 8:08 AM, Julien Grall  wrote:
> Hello Sergej,
>
> Please try to reply to all when answering on the ML. Otherwise the answer
> may be delayed/lost.
>
> On 03/08/16 13:45, Sergej Proskurin wrote:
>>
>> The interesting part about #VE is that it allows to handle certain
>> violations (currently limited to EPT violations -- future
>> implementations might introduce also further violations) inside of the
>> guest, without the need to explicitly trap into the VMM. Thus, #VE allow
>> switching of different memory views in-guest. Because of this, I also
>> agree that event channels would suffice in our case, since we do not
>> have sufficient hardware support on ARM and would need to trap into the
>> VMM anyway.
>
>
> The cost of doing an hypercall on ARM is very small compare to x86 (~1/3 of
> the number of x86 cycles) because we don't have to save all the state every
> time. So I am not convinced by the argument of limiting the number of trap
> to the hypervisor and allow a guest to play with altp2m on ARM.
>
> I will have to see a concrete example before going forward with the event
> channel.

It is out-of-scope for what we are trying to achieve with this series
at this point. The question at hand is really whether the atp2m switch
and gfn remapping ops should be exposed to the guest. Without #VE -
which we are not implementing - setting the mem_access settings from
within the guest doesn't make sense so restricting access there is
reasonable.

As I outlined, the switch and gfn remapping can have legitimate
use-cases by themselves without any mem_access bits involved. However,
it is not our use-case so we have no problem restricting access there
either. So the question is whether that's the right path to take here.
At this point I'm not sure there is agreement about it or not.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[Roger Pau Monne]

On Wed, Aug 03, 2016 at 09:37:41AM -0600, Jan Beulich wrote:
> >>> On 03.08.16 at 17:28,  wrote:
> > On 03/08/16 16:25, Jan Beulich wrote:
> > On 03.08.16 at 17:11,  wrote:
> >>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
> >>> On 02.08.16 at 17:49,  wrote:
> > On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
> >> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
> >>> As this is for the construction of dom0, it would be better to take a
> >>> preemptible pointer, loop in construct_dom0(), with a
> >>> process_pending_softirqs() call in between.
> >>
> >> Now fixed.
> >
> > Hm, I have to stand corrected, using hypercall_preempt_check (as
> > any of the *_set_allocation function use), is not safe at this point:
> >
> > (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
> > (XEN) CPU:0
> > (XEN) RIP:e008:[] 
> >>> hap.c#local_events_need_delivery+0x27/0x40
> > (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> > (XEN) rax:    rbx: 83023f5a5000   rcx: 
> > 82d080312900
> > (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 
> > 8300b213d000
> > (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  
> > 0180
> > (XEN) r9:     r10: 00247000   r11: 
> > 82d08029a5b0
> > (XEN) r12: 0011   r13: 23ac   r14: 
> > 82d080307d4c
> > (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 
> > 001526e0
> > (XEN) cr3: b20fc000   cr2: 
> > (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> > (XEN) Xen code around  
> >>> (hap.c#local_events_need_delivery+0x27/0x40):
> > (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 
> > 02 31 
> >>> c0
> > (XEN) Xen stack trace from rsp=82d080307cc8:
> > (XEN)82d080307d08 82d08022fc47  
> > 83023f5a5000
> > (XEN)83023f5a5648  82d080307d4c 
> > 2400
> > (XEN)82d080307d38 82d08020008c 000d 
> > 8300b1efd000
> > (XEN)83023f5a5000 82d080307d4c 82d080307d78 
> > 82d0802cad30
> > (XEN)00203000 83023f5a5000 82d0802bf860 
> > 
> > (XEN)0001 8308bef0 82d080307de8 
> > 82d0802c91e0
> > (XEN)82d080307de8 82d080143900 82d080307de8 
> > 
> > (XEN)8308bf00 82d0802eb480 82d080307dc4 
> > 82d08028b1cd
> > (XEN)8308bf00  0001 
> > 83023f5a5000
> > (XEN)82d080307f08 82d0802bf0c9  
> > 
> > (XEN) 82d080307f18 8308bee0 
> > 0001
> > (XEN)0001 0001  
> > 0010
> > (XEN)0001 00247000 8308bef4 
> > 0010
> > (XEN)8301 00247001 0014 
> > 0001
> > (XEN)8300ffec 8308bef0 82d0802e0640 
> > 8308bfb0
> > (XEN)  0111 
> > 0008
> > (XEN)0001006e 0003 02f8 
> > 
> > (XEN)ad5c0bd0  0001 
> > 0008
> > (XEN) 82d080100073  
> > 
> > (XEN)   
> > 
> > (XEN) Xen call trace:
> > (XEN)[] hap.c#local_events_need_delivery+0x27/0x40
> > (XEN)[] hap_set_allocation+0x107/0x130
> > (XEN)[] paging_set_allocation+0x4c/0x80
> > (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
> > (XEN)[] 
> > domain_build.c#construct_dom0_hvm+0x60/0x120
> > (XEN)[] __start_xen+0x1ea9/0x23a0
> > (XEN)[] __high_start+0x53/0x60
> > (XEN)
> > (XEN) Pagetable walk from :
> 
>  Sadly you don't make clear what pointer it is that is NULL at that point.
> >>>
> >>> It sounds from what he says in the following paragraph like current is 
> >>> NULL.
> >> 
> >> I don't recall us re-setting current to this late in the boot process.
> >> Even during early boot we set it to a bogus non-NULL value rather
> >> than NULL.
> >> 
> > I've tried setting current to d->vcpu[0], but that just makes the call 
> > to
> > hypercall_preempt_check crash in some scheduler assert. In any case, 
> > I've

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

[Tamas K Lengyel]

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

 No, it's still just v2.

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

 The extra work doesn't just come from splitting the code itself
 (although I don't know which bits would really make sense to split
 here that would worth the effort) but testing a series on various
 platforms.
>>>
>>> I don't understand this statement -- why is testing a 3-patch series
>>> more difficult than testing a one-patch series?  Are you testing each
>>> individual patch?
>>>
>>
>> Yes, I do. And when a patch touches multiple archs it adds up quite fast.
>
> Yes, I can imagine it does. :-)
>
> But the next question is, why do you feel the need to test every patch
> of 

[Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

[Ian Jackson]

In particular, when xen.git clones a subtrees, whose url we didn't
specify in the runvars, we end up using the url from xen.git's
Config.mk.

Arrange to use the git cache for all git urls, via the insteadOf
feature.

Note that the git config url insteadOf feature is backwards: one
configures the config variable "url.NEW-URL.insteadOf.OLD-URL".  So
the key is the value, and the value is the key.

Signed-off-by: Ian Jackson 
---
 ts-xen-build-prep | 20 
 1 file changed, 20 insertions(+)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 0450811..4dd10c4 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -243,6 +243,25 @@ sub ccache_setup () {
 }
 }
 
+sub gitcache_setup () {
+my $proxy = $c{GitCacheProxy};
+return unless $proxy;
+
+logm("setting up git cacheing proxy $proxy");
+
+my $gitcfg = '';
+foreach my $urlprefix (qw(git:// http:// https://)) {
+   $gitcfg .= <{Flags}{'no-reinstall'}) {
 determine_vg_lv();
 lvcreate();
@@ -251,6 +270,7 @@ if (!$ho->{Flags}{'no-reinstall'}) {
 lvextend_stage2();
 replace_home();
 ccache_setup();
+gitcache_setup();
 }
 $mjobdb->jobdb_resource_shared_mark_ready
($ho->{Ident}, $ho->{Name}, "build-".$ho->{Suite}."-".$r{arch});
-- 
2.1.4


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

Re: [Xen-devel] [OSSTEST PATCH] ts-xen-build-prep: Use .gitconfig so _everything_ uses git cache

[Andrew Cooper]

On 03/08/16 16:47, Ian Jackson wrote:
> In particular, when xen.git clones a subtrees, whose url we didn't
> specify in the runvars, we end up using the url from xen.git's
> Config.mk.
>
> Arrange to use the git cache for all git urls, via the insteadOf
> feature.
>
> Note that the git config url insteadOf feature is backwards: one
> configures the config variable "url.NEW-URL.insteadOf.OLD-URL".  So
> the key is the value, and the value is the key.
>
> Signed-off-by: Ian Jackson 

FWIW, LGTM.

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

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

[George Dunlap]

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

 This appears to be v3, not v2?
>>>
>>> No, it's still just v2.
>>>

> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 812dbf6..27f9d26 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
> long gla,
>  if ( req )
>  {
>  *req_ptr = req;
> -req->reason = VM_EVENT_REASON_MEM_ACCESS;
> -
> -/* Pause the current VCPU */
> -if ( p2ma != p2m_access_n2rwx )
> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
>
> -/* Send request to mem event */
> +req->reason = VM_EVENT_REASON_MEM_ACCESS;
>  req->u.mem_access.gfn = gfn;
>  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
>  if ( npfec.gla_valid )
> @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
> long gla,
>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 
> 0;
>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 
> 0;
>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 
> 0;
> -req->vcpu_id = v->vcpu_id;
> -
> -vm_event_fill_regs(req);
> -
> -if ( altp2m_active(v->domain) )
> -{
> -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> -req->altp2m_idx = vcpu_altp2m(v).p2midx;
> -}
>  }
>
> -/* Pause the current VCPU */
> -if ( p2ma != p2m_access_n2rwx )
> -vm_event_vcpu_pause(v);
> -
> -/* VCPU may be paused, return whether we promoted automatically */
> -return (p2ma == p2m_access_n2rwx);
> +/* Return whether vCPU pause is required (aka. sync event) */
> +return (p2ma != p2m_access_n2rwx);
>  }
>
>  static inline

 p2m-bits:

 Acked-by: George Dunlap 

 But I agree with Julien -- this patch has several independent changes
 which makes it quite difficult to tell what's going on.  I'm sure it's
 taken the two of us a lot more time together to figure out what is and
 is not happening than it would have for you to break it down into
 several little chunks.

 If you're not already familiar with it, I would recommend looking into
 stackgit.  My modus operandi for things like this is to get things
 working in one big patch, then pop it off the stack and apply bits of it
 at a time to make a series.

 It's not only more considerate of your reviewers, but it's also a
 helpful exercise for yourself.

>>>
>>> The extra work doesn't just come from splitting the code itself
>>> (although I don't know which bits would really make sense to split
>>> here that would worth the effort) but testing a series on various
>>> platforms.
>>
>> I don't understand this statement -- why is testing a 3-patch series
>> more difficult than testing a one-patch series?  Are you testing each
>> individual patch?
>>
> 
> Yes, I do. And when a patch touches multiple archs it adds up quite fast.

Yes, I can imagine it does. :-)

But the next question is, why do you feel the need to test every patch
of a series individually, rather than just testing the whole series?

 -George



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

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

[lists]

On Wed, Aug 3, 2016, at 07:50 AM, li...@ssl-mail.com wrote:
> So *today's* simplest working combination seems to be 

After the sytem is booted with

+ patched kernel
- /mapbs
+ efi=no-rs

I now get tons of these at serial console

(XEN) [2016-08-03 15:23:25] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:23:39] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:23:57] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:24:11] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:24:30] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:24:43] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:25:02] d1v0 Over-allocation for domain 1: 524545 > 
524544
(XEN) [2016-08-03 15:25:15] d2v2 Over-allocation for domain 2: 524545 > 
524544
(XEN) [2016-08-03 15:25:34] d1v0 Over-allocation for domain 1: 524545 > 
524544

That's with logging set to

loglvl=warning guest_loglvl=none/warning

Not sure it matters other than being useless noise.

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

Re: [Xen-devel] [PATCH v7 06/15] xen: Move the hvm_start_info C representation to the public headers

[Jan Beulich]

>>> On 28.07.16 at 12:50,  wrote:
> Instead of having several representation of hvm_start_info in C, define
> it in public/arch-x86/hvm/start_info.h so both libxc and hvmloader can
> use it.
> 
> Also move the comment describing the binary format to be alongside the
> C struct.
> 
> Signed-off-by: Anthony PERARD 

Acked-by: Jan Beulich 

with a couple of cosmetic notes (which could be addressed while
committing if no other need for re-sending arises):

> +/*
> + * C representation of the x86/HVM start info layout.
> + *
> + * The canonical definition of this layout is abrove, this is just a way to

above

> + * represent the layout described there using C types.
> + *

Stray blank comment line.

Jan


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

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

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 9:30 AM, George Dunlap  wrote:
> On 03/08/16 16:18, Tamas K Lengyel wrote:
>> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap  
>> wrote:
>>> On 01/08/16 17:52, Tamas K Lengyel wrote:
 The two functions monitor_traps and mem_access_send_req duplicate some of 
 the
 same functionality. The mem_access_send_req however leaves a lot of the
 standard vm_event fields to be filled by other functions.

 Remove mem_access_send_req() completely, making use of monitor_traps() to 
 put
 requests into the monitor ring.  This in turn causes some cleanup around 
 the
 old callsites of mem_access_send_req(), and on ARM, the introduction of the
 __p2m_mem_access_send_req() helper to fill in common mem_access 
 information.
 We also update monitor_traps to now include setting the common vcpu_id 
 field
 so that all other call-sites can ommit this step.

 Finally, this change identifies that errors from mem_access_send_req() were
 never checked.  As errors constitute a problem with the monitor ring,
 crashing the domain is the most appropriate action to take.

 Signed-off-by: Tamas K Lengyel 
 Reviewed-by: Andrew Cooper 
>>>
>>> This appears to be v3, not v2?
>>
>> No, it's still just v2.
>>
>>>
 diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
 index 812dbf6..27f9d26 100644
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
 @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
 long gla,
  if ( req )
  {
  *req_ptr = req;
 -req->reason = VM_EVENT_REASON_MEM_ACCESS;
 -
 -/* Pause the current VCPU */
 -if ( p2ma != p2m_access_n2rwx )
 -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;

 -/* Send request to mem event */
 +req->reason = VM_EVENT_REASON_MEM_ACCESS;
  req->u.mem_access.gfn = gfn;
  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
  if ( npfec.gla_valid )
 @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
 long gla,
  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 
 0;
  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 
 0;
  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 
 0;
 -req->vcpu_id = v->vcpu_id;
 -
 -vm_event_fill_regs(req);
 -
 -if ( altp2m_active(v->domain) )
 -{
 -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
 -req->altp2m_idx = vcpu_altp2m(v).p2midx;
 -}
  }

 -/* Pause the current VCPU */
 -if ( p2ma != p2m_access_n2rwx )
 -vm_event_vcpu_pause(v);
 -
 -/* VCPU may be paused, return whether we promoted automatically */
 -return (p2ma == p2m_access_n2rwx);
 +/* Return whether vCPU pause is required (aka. sync event) */
 +return (p2ma != p2m_access_n2rwx);
  }

  static inline
>>>
>>> p2m-bits:
>>>
>>> Acked-by: George Dunlap 
>>>
>>> But I agree with Julien -- this patch has several independent changes
>>> which makes it quite difficult to tell what's going on.  I'm sure it's
>>> taken the two of us a lot more time together to figure out what is and
>>> is not happening than it would have for you to break it down into
>>> several little chunks.
>>>
>>> If you're not already familiar with it, I would recommend looking into
>>> stackgit.  My modus operandi for things like this is to get things
>>> working in one big patch, then pop it off the stack and apply bits of it
>>> at a time to make a series.
>>>
>>> It's not only more considerate of your reviewers, but it's also a
>>> helpful exercise for yourself.
>>>
>>
>> The extra work doesn't just come from splitting the code itself
>> (although I don't know which bits would really make sense to split
>> here that would worth the effort) but testing a series on various
>> platforms.
>
> I don't understand this statement -- why is testing a 3-patch series
> more difficult than testing a one-patch series?  Are you testing each
> individual patch?
>

Yes, I do. And when a patch touches multiple archs it adds up quite fast.

Tamas

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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[Jan Beulich]

>>> On 03.08.16 at 17:28,  wrote:
> On 03/08/16 16:25, Jan Beulich wrote:
> On 03.08.16 at 17:11,  wrote:
>>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
>>> On 02.08.16 at 17:49,  wrote:
> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
>> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
>>> As this is for the construction of dom0, it would be better to take a
>>> preemptible pointer, loop in construct_dom0(), with a
>>> process_pending_softirqs() call in between.
>>
>> Now fixed.
>
> Hm, I have to stand corrected, using hypercall_preempt_check (as
> any of the *_set_allocation function use), is not safe at this point:
>
> (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
> (XEN) CPU:0
> (XEN) RIP:e008:[] 
>>> hap.c#local_events_need_delivery+0x27/0x40
> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
> (XEN) rax:    rbx: 83023f5a5000   rcx: 
> 82d080312900
> (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 
> 8300b213d000
> (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  
> 0180
> (XEN) r9:     r10: 00247000   r11: 
> 82d08029a5b0
> (XEN) r12: 0011   r13: 23ac   r14: 
> 82d080307d4c
> (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 
> 001526e0
> (XEN) cr3: b20fc000   cr2: 
> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
> (XEN) Xen code around  
>>> (hap.c#local_events_need_delivery+0x27/0x40):
> (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 
> 02 31 
>>> c0
> (XEN) Xen stack trace from rsp=82d080307cc8:
> (XEN)82d080307d08 82d08022fc47  
> 83023f5a5000
> (XEN)83023f5a5648  82d080307d4c 
> 2400
> (XEN)82d080307d38 82d08020008c 000d 
> 8300b1efd000
> (XEN)83023f5a5000 82d080307d4c 82d080307d78 
> 82d0802cad30
> (XEN)00203000 83023f5a5000 82d0802bf860 
> 
> (XEN)0001 8308bef0 82d080307de8 
> 82d0802c91e0
> (XEN)82d080307de8 82d080143900 82d080307de8 
> 
> (XEN)8308bf00 82d0802eb480 82d080307dc4 
> 82d08028b1cd
> (XEN)8308bf00  0001 
> 83023f5a5000
> (XEN)82d080307f08 82d0802bf0c9  
> 
> (XEN) 82d080307f18 8308bee0 
> 0001
> (XEN)0001 0001  
> 0010
> (XEN)0001 00247000 8308bef4 
> 0010
> (XEN)8301 00247001 0014 
> 0001
> (XEN)8300ffec 8308bef0 82d0802e0640 
> 8308bfb0
> (XEN)  0111 
> 0008
> (XEN)0001006e 0003 02f8 
> 
> (XEN)ad5c0bd0  0001 
> 0008
> (XEN) 82d080100073  
> 
> (XEN)   
> 
> (XEN) Xen call trace:
> (XEN)[] hap.c#local_events_need_delivery+0x27/0x40
> (XEN)[] hap_set_allocation+0x107/0x130
> (XEN)[] paging_set_allocation+0x4c/0x80
> (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
> (XEN)[] domain_build.c#construct_dom0_hvm+0x60/0x120
> (XEN)[] __start_xen+0x1ea9/0x23a0
> (XEN)[] __high_start+0x53/0x60
> (XEN)
> (XEN) Pagetable walk from :

 Sadly you don't make clear what pointer it is that is NULL at that point.
>>>
>>> It sounds from what he says in the following paragraph like current is NULL.
>> 
>> I don't recall us re-setting current to this late in the boot process.
>> Even during early boot we set it to a bogus non-NULL value rather
>> than NULL.
>> 
> I've tried setting current to d->vcpu[0], but that just makes the call to
> hypercall_preempt_check crash in some scheduler assert. In any case, I've
> added the preempt parameter to the paging_set_allocation function, but I
> don't plan to use it in the domain builder for the time being. Does that
> sound right?

 Not really, new huge latency issues like this shouldn't be reintroduced;
 we've been fighting hard to get 

Re: [Xen-devel] [PATCH] arm/mem_access: properly handle traps caused by no-longer current settings

[Tamas K Lengyel]

On Wed, Aug 3, 2016 at 5:43 AM, Julien Grall  wrote:
> Hi Tamas,
>
> On 02/08/16 23:47, Tamas K Lengyel wrote:
>>
>> On Tue, Aug 2, 2016 at 4:05 PM, Julien Grall  wrote:
>>>
>>> On 02/08/2016 22:34, Tamas K Lengyel wrote:

 On Tue, Aug 2, 2016 at 2:02 PM, Julien Grall 
 wrote:
>
> On 02/08/2016 19:53, Tamas K Lengyel wrote:
>>>
>>> Well, the data abort can only be a permission fault if memaccess is inuse
>>> so
>>> far. Unless there is another race condition in the memaccess code and in
>>> this case this is not the fault of the guest. So sending a data abort to
>>> the
>>> guest will not really help to know what's going on.
>>
>>
>> From my perspective it doesn't matter whether the fault is injected
>> into the guest or not when mem_access is not in use. Since that's the
>> default behavior right now, my opinion is that it should get
>> reinjected but that's beyond the scope of mem_access itself so it's up
>> to you to decide. If you really prefer to have the mem_access check
>> just be a void function and not inject a fault to the guest, I'm
>> certainly fine with that.
>
>
> I would prefer to see the function p2m_mem_access_check unchanged. The
> current behavior of the function is to return either "the fault is not for
> me" or "I handled the fault".
>
> With this patch, this function could also return "this might be a race
> condition, try again".
>
> The function p2m_mem_access_check is returning a boolean. You cannot encode
> 3 states in a boolean. So you could not hand over the fault to another
> helper.
>
>>
>>> Also, you are assuming that it will never be possible in the future to
>>> have
>>> another usage of the permission fault. By returning false you say "I
>>> handled
>>> the fault, it is not necessary to hand over to someone else".
>>
>>
>> I only return false here if mem_access is enabled.
>
>
> But this code can never be reached when mem_access is not enabled. And once
> mem_access is turned on, it is never possible to turned off back.
>
> If you think that in the future mem_access can be turned off, then the code
> could be racy. IHMO it is already kind of racy because the code assumes that
> p2m->mem_access_enabled will be seen well before the P2M was changed.

Doing a p2m locking around setting it should be fine though.

>
>> If any other system
>> in the future is going to make use of these permissions then it needs
>> to be carefully evaluated what the handover setup should be when the
>> mem_access state doesn't seem to be the reason for the violation. I
>> can forsee some issues if one system would like the instruction to be
>> reexecuted while the other to do something else. As this all being
>> hypothetical at this point I don't really know what to do with this
>> right now.
>
>
> IHMO, right now, the best solution is to re-execute the instruction in any
> case and keep p2m_mem_access_check unchanged.
>

Sure, that works for me.

Tamas

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

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

[George Dunlap]

On 03/08/16 16:18, Tamas K Lengyel wrote:
> On Wed, Aug 3, 2016 at 8:41 AM, George Dunlap  
> wrote:
>> On 01/08/16 17:52, Tamas K Lengyel wrote:
>>> The two functions monitor_traps and mem_access_send_req duplicate some of 
>>> the
>>> same functionality. The mem_access_send_req however leaves a lot of the
>>> standard vm_event fields to be filled by other functions.
>>>
>>> Remove mem_access_send_req() completely, making use of monitor_traps() to 
>>> put
>>> requests into the monitor ring.  This in turn causes some cleanup around the
>>> old callsites of mem_access_send_req(), and on ARM, the introduction of the
>>> __p2m_mem_access_send_req() helper to fill in common mem_access information.
>>> We also update monitor_traps to now include setting the common vcpu_id field
>>> so that all other call-sites can ommit this step.
>>>
>>> Finally, this change identifies that errors from mem_access_send_req() were
>>> never checked.  As errors constitute a problem with the monitor ring,
>>> crashing the domain is the most appropriate action to take.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> Reviewed-by: Andrew Cooper 
>>
>> This appears to be v3, not v2?
> 
> No, it's still just v2.
> 
>>
>>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>>> index 812dbf6..27f9d26 100644
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -1728,13 +1728,8 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
>>> long gla,
>>>  if ( req )
>>>  {
>>>  *req_ptr = req;
>>> -req->reason = VM_EVENT_REASON_MEM_ACCESS;
>>> -
>>> -/* Pause the current VCPU */
>>> -if ( p2ma != p2m_access_n2rwx )
>>> -req->flags |= VM_EVENT_FLAG_VCPU_PAUSED;
>>>
>>> -/* Send request to mem event */
>>> +req->reason = VM_EVENT_REASON_MEM_ACCESS;
>>>  req->u.mem_access.gfn = gfn;
>>>  req->u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
>>>  if ( npfec.gla_valid )
>>> @@ -1750,23 +1745,10 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned 
>>> long gla,
>>>  req->u.mem_access.flags |= npfec.read_access? MEM_ACCESS_R : 0;
>>>  req->u.mem_access.flags |= npfec.write_access   ? MEM_ACCESS_W : 0;
>>>  req->u.mem_access.flags |= npfec.insn_fetch ? MEM_ACCESS_X : 0;
>>> -req->vcpu_id = v->vcpu_id;
>>> -
>>> -vm_event_fill_regs(req);
>>> -
>>> -if ( altp2m_active(v->domain) )
>>> -{
>>> -req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>>> -req->altp2m_idx = vcpu_altp2m(v).p2midx;
>>> -}
>>>  }
>>>
>>> -/* Pause the current VCPU */
>>> -if ( p2ma != p2m_access_n2rwx )
>>> -vm_event_vcpu_pause(v);
>>> -
>>> -/* VCPU may be paused, return whether we promoted automatically */
>>> -return (p2ma == p2m_access_n2rwx);
>>> +/* Return whether vCPU pause is required (aka. sync event) */
>>> +return (p2ma != p2m_access_n2rwx);
>>>  }
>>>
>>>  static inline
>>
>> p2m-bits:
>>
>> Acked-by: George Dunlap 
>>
>> But I agree with Julien -- this patch has several independent changes
>> which makes it quite difficult to tell what's going on.  I'm sure it's
>> taken the two of us a lot more time together to figure out what is and
>> is not happening than it would have for you to break it down into
>> several little chunks.
>>
>> If you're not already familiar with it, I would recommend looking into
>> stackgit.  My modus operandi for things like this is to get things
>> working in one big patch, then pop it off the stack and apply bits of it
>> at a time to make a series.
>>
>> It's not only more considerate of your reviewers, but it's also a
>> helpful exercise for yourself.
>>
> 
> The extra work doesn't just come from splitting the code itself
> (although I don't know which bits would really make sense to split
> here that would worth the effort) but testing a series on various
> platforms.

I don't understand this statement -- why is testing a 3-patch series
more difficult than testing a one-patch series?  Are you testing each
individual patch?

 -George

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d
baseline version:
 ovmf deaacda3b2740477733564066eb69d5c94b41bba

Last test of basis66896  2016-08-03 10:18:33 Z0 days
Testing same since66904  2016-08-03 13:16:29 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 

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



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

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

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


Push not applicable.


commit e80cb37ee7b507b6cfe4e4b0f23dc4c5cb2c1d5d
Author: Gary Lin 
Date:   Fri Jul 22 17:47:12 2016 +0800

Vlv2TbltDevicePkg/FvbRuntimeDxe: Remove unused variables

Fix the following errors from gcc:

Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c: In function 
‘FvbWriteBlock’:
Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c:368:44: error: variable 
‘FwhInstance’ set but not used [-Werror=unused-but-set-variable]

Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c: In function 
‘FvbEraseBlock’:
Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c:448:44: error: variable 
‘FwhInstance’ set but not used [-Werror=unused-but-set-variable]

Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c: In function 
‘FvbInitialize’:
Vlv2TbltDevicePkg/FvbRuntimeDxe/FvbService.c:1028:41: error: variable 
‘FvHeaderValid’ set but not used [-Werror=unused-but-set-variable]

Cc: David Wei 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin 

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

Re: [Xen-devel] [PATCH 8/9] x86/hypercall: Merge the hypercall arg tables

[Jan Beulich]

>>> On 03.08.16 at 17:15,  wrote:
> On 03/08/16 16:12, Jan Beulich wrote:
> On 18.07.16 at 11:51,  wrote:
>>> For the same reason as c/s 33a231e3f "x86/HVM: fold hypercall tables" and
>>> (TODO - changeset) "x86/pv: Merge the pv hypercall tables", this removes the
>>> risk of accidentally updating only one of the tables.
>> Based on this argument perhaps hypercall and args tables should
>> get folded too, but I guess that's a work item for another day.
> 
> That is rather harder to do.  I thought about it, but couldn't find a
> neat way of doing it.
> 
> The call table is an array of pointers, while the args table is an array
> of bytes.  Merging them would result in excessive padding for alignment
> purposes, unless it was packed, at which point we are calling
> non-aligned function pointers, and taking that associated performance hit.

If we folded everything together (pv, hvm, args), there would be
6 bytes padding per 34 or actual data, so I wouldn't be worried
too much. But I admit that merging hvm and pv tables wouldn't be
entirely trivial.

Jan


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

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[George Dunlap]

On 03/08/16 16:25, Jan Beulich wrote:
 On 03.08.16 at 17:11,  wrote:
>> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
>> On 02.08.16 at 17:49,  wrote:
 On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
> On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
>> As this is for the construction of dom0, it would be better to take a
>> preemptible pointer, loop in construct_dom0(), with a
>> process_pending_softirqs() call in between.
>
> Now fixed.

 Hm, I have to stand corrected, using hypercall_preempt_check (as
 any of the *_set_allocation function use), is not safe at this point:

 (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
 (XEN) CPU:0
 (XEN) RIP:e008:[] 
>> hap.c#local_events_need_delivery+0x27/0x40
 (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
 (XEN) rax:    rbx: 83023f5a5000   rcx: 82d080312900
 (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 8300b213d000
 (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  0180
 (XEN) r9:     r10: 00247000   r11: 82d08029a5b0
 (XEN) r12: 0011   r13: 23ac   r14: 82d080307d4c
 (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 001526e0
 (XEN) cr3: b20fc000   cr2: 
 (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
 (XEN) Xen code around  
>> (hap.c#local_events_need_delivery+0x27/0x40):
 (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 02 
 31 
>> c0
 (XEN) Xen stack trace from rsp=82d080307cc8:
 (XEN)82d080307d08 82d08022fc47  
 83023f5a5000
 (XEN)83023f5a5648  82d080307d4c 
 2400
 (XEN)82d080307d38 82d08020008c 000d 
 8300b1efd000
 (XEN)83023f5a5000 82d080307d4c 82d080307d78 
 82d0802cad30
 (XEN)00203000 83023f5a5000 82d0802bf860 
 
 (XEN)0001 8308bef0 82d080307de8 
 82d0802c91e0
 (XEN)82d080307de8 82d080143900 82d080307de8 
 
 (XEN)8308bf00 82d0802eb480 82d080307dc4 
 82d08028b1cd
 (XEN)8308bf00  0001 
 83023f5a5000
 (XEN)82d080307f08 82d0802bf0c9  
 
 (XEN) 82d080307f18 8308bee0 
 0001
 (XEN)0001 0001  
 0010
 (XEN)0001 00247000 8308bef4 
 0010
 (XEN)8301 00247001 0014 
 0001
 (XEN)8300ffec 8308bef0 82d0802e0640 
 8308bfb0
 (XEN)  0111 
 0008
 (XEN)0001006e 0003 02f8 
 
 (XEN)ad5c0bd0  0001 
 0008
 (XEN) 82d080100073  
 
 (XEN)   
 
 (XEN) Xen call trace:
 (XEN)[] hap.c#local_events_need_delivery+0x27/0x40
 (XEN)[] hap_set_allocation+0x107/0x130
 (XEN)[] paging_set_allocation+0x4c/0x80
 (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
 (XEN)[] domain_build.c#construct_dom0_hvm+0x60/0x120
 (XEN)[] __start_xen+0x1ea9/0x23a0
 (XEN)[] __high_start+0x53/0x60
 (XEN)
 (XEN) Pagetable walk from :
>>>
>>> Sadly you don't make clear what pointer it is that is NULL at that point.
>>
>> It sounds from what he says in the following paragraph like current is NULL.
> 
> I don't recall us re-setting current to this late in the boot process.
> Even during early boot we set it to a bogus non-NULL value rather
> than NULL.
> 
 I've tried setting current to d->vcpu[0], but that just makes the call to
 hypercall_preempt_check crash in some scheduler assert. In any case, I've
 added the preempt parameter to the paging_set_allocation function, but I
 don't plan to use it in the domain builder for the time being. Does that
 sound right?
>>>
>>> Not really, new huge latency issues like this shouldn't be reintroduced;
>>> we've been fighting hard to get rid of those (and we still occasionally
>>> find some no-one had noticed before).
>>
>> You mean latency in processing softirqs?
>>
>> Maybe what we need to do is to make local_events_need_delivery() safe

Re: [Xen-devel] [PATCH RFC 01/12] x86/paging: introduce paging_set_allocation

[Jan Beulich]

>>> On 03.08.16 at 17:11,  wrote:
> On Tue, Aug 2, 2016 at 5:12 PM, Jan Beulich  wrote:
> On 02.08.16 at 17:49,  wrote:
>>> On Tue, Aug 02, 2016 at 11:47:22AM +0200, Roger Pau Monne wrote:
 On Fri, Jul 29, 2016 at 05:47:24PM +0100, Andrew Cooper wrote:
 > As this is for the construction of dom0, it would be better to take a
 > preemptible pointer, loop in construct_dom0(), with a
 > process_pending_softirqs() call in between.

 Now fixed.
>>>
>>> Hm, I have to stand corrected, using hypercall_preempt_check (as
>>> any of the *_set_allocation function use), is not safe at this point:
>>>
>>> (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Tainted:C  ]
>>> (XEN) CPU:0
>>> (XEN) RIP:e008:[] 
> hap.c#local_events_need_delivery+0x27/0x40
>>> (XEN) RFLAGS: 00010246   CONTEXT: hypervisor
>>> (XEN) rax:    rbx: 83023f5a5000   rcx: 82d080312900
>>> (XEN) rdx: 0001   rsi: 83023f5a56c8   rdi: 8300b213d000
>>> (XEN) rbp: 82d080307cc8   rsp: 82d080307cc8   r8:  0180
>>> (XEN) r9:     r10: 00247000   r11: 82d08029a5b0
>>> (XEN) r12: 0011   r13: 23ac   r14: 82d080307d4c
>>> (XEN) r15: 83023f5a56c8   cr0: 8005003b   cr4: 001526e0
>>> (XEN) cr3: b20fc000   cr2: 
>>> (XEN) ds:    es:    fs:    gs:    ss:    cs: e008
>>> (XEN) Xen code around  
> (hap.c#local_events_need_delivery+0x27/0x40):
>>> (XEN)  0d ad fa ff 48 8b 47 08 <80> 38 00 74 09 80 78 01 00 0f 94 c0 eb 02 
>>> 31 
> c0
>>> (XEN) Xen stack trace from rsp=82d080307cc8:
>>> (XEN)82d080307d08 82d08022fc47  83023f5a5000
>>> (XEN)83023f5a5648  82d080307d4c 2400
>>> (XEN)82d080307d38 82d08020008c 000d 8300b1efd000
>>> (XEN)83023f5a5000 82d080307d4c 82d080307d78 82d0802cad30
>>> (XEN)00203000 83023f5a5000 82d0802bf860 
>>> (XEN)0001 8308bef0 82d080307de8 82d0802c91e0
>>> (XEN)82d080307de8 82d080143900 82d080307de8 
>>> (XEN)8308bf00 82d0802eb480 82d080307dc4 82d08028b1cd
>>> (XEN)8308bf00  0001 83023f5a5000
>>> (XEN)82d080307f08 82d0802bf0c9  
>>> (XEN) 82d080307f18 8308bee0 0001
>>> (XEN)0001 0001  0010
>>> (XEN)0001 00247000 8308bef4 0010
>>> (XEN)8301 00247001 0014 0001
>>> (XEN)8300ffec 8308bef0 82d0802e0640 8308bfb0
>>> (XEN)  0111 0008
>>> (XEN)0001006e 0003 02f8 
>>> (XEN)ad5c0bd0  0001 0008
>>> (XEN) 82d080100073  
>>> (XEN)   
>>> (XEN) Xen call trace:
>>> (XEN)[] hap.c#local_events_need_delivery+0x27/0x40
>>> (XEN)[] hap_set_allocation+0x107/0x130
>>> (XEN)[] paging_set_allocation+0x4c/0x80
>>> (XEN)[] domain_build.c#hvm_setup_p2m+0x70/0x1a0
>>> (XEN)[] domain_build.c#construct_dom0_hvm+0x60/0x120
>>> (XEN)[] __start_xen+0x1ea9/0x23a0
>>> (XEN)[] __high_start+0x53/0x60
>>> (XEN)
>>> (XEN) Pagetable walk from :
>>
>> Sadly you don't make clear what pointer it is that is NULL at that point.
> 
> It sounds from what he says in the following paragraph like current is NULL.

I don't recall us re-setting current to this late in the boot process.
Even during early boot we set it to a bogus non-NULL value rather
than NULL.

>>> I've tried setting current to d->vcpu[0], but that just makes the call to
>>> hypercall_preempt_check crash in some scheduler assert. In any case, I've
>>> added the preempt parameter to the paging_set_allocation function, but I
>>> don't plan to use it in the domain builder for the time being. Does that
>>> sound right?
>>
>> Not really, new huge latency issues like this shouldn't be reintroduced;
>> we've been fighting hard to get rid of those (and we still occasionally
>> find some no-one had noticed before).
> 
> You mean latency in processing softirqs?
> 
> Maybe what we need to do is to make local_events_need_delivery() safe
> to call at this point by having it return 0 if current is NULL rather
> than crashing?

That would have the same effect - no softirq processing, and hence
possible time issues on huge systems.

Jan

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

[Tamas K Lengyel]

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

No, it's still just v2.

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

The extra work doesn't just come from splitting the code itself
(although I don't know which bits would really make sense to split
here that would worth the effort) but testing a series on various
platforms. As you are in the same boat that this should be multiple
patches (so it's 3v2) I have no problem just postponing the ARM
sanitization beside what's absolutely required at the moment. I'm
already looking at how to move the mem_accss code out of p2m on both
platforms so we don't have to end up in this loop in the future.

Thanks,
Tamas

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