Re: [Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Kyle Huey]

On Thu, Sep 15, 2016 at 5:07 PM, Andy Lutomirski  wrote:
> On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey  wrote:
>> +int get_cpuid_mode(unsigned long adr)
>> +{
>> +   unsigned int val;
>> +
>> +   if (test_thread_flag(TIF_NOCPUID))
>> +   val = ARCH_CPUID_SIGSEGV;
>> +   else
>> +   val = ARCH_CPUID_ENABLE;
>> +
>> +   return put_user(val, (unsigned int __user *)adr);
>> +}
>
> Can we just do:
>
> if (arg2 != 0)
>   return -EINVAL;
> else
>  return test_thread_flag(TIF_NOCPUID) ? ARCH_CPUID_SIGSEGBV : 
> ARCH_CPUID_ENABLE;

We could.  I copied the pattern of PR_GET_TSC here, but I don't feel
strongly about it.

>> diff --git a/tools/testing/selftests/x86/cpuid-fault.c 
>> b/tools/testing/selftests/x86/cpuid-fault.c
>> new file mode 100644
>> index 000..a9f3f68
>> --- /dev/null
>> +++ b/tools/testing/selftests/x86/cpuid-fault.c
>> @@ -0,0 +1,234 @@
>> +
>> +/*
>> + * Tests for arch_prctl(ARCH_GET_CPUID, ...) / prctl(ARCH_SET_CPUID, ...)
>> + *
>> + * Basic test to test behaviour of ARCH_GET_CPUID and ARCH_SET_CPUID
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +#include 
>> +
>> +const char *cpuid_names[] = {
>> +   [0] = "[not set]",
>
> Is 0 even possible?

Only if the call fails.

- Kyle

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

[Xen-devel] [xen-unstable baseline-only test] 67718: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 67714
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 67714
 test-armhf-armhf-xl-vhd  14 guest-start/debian.repeat fail REGR. vs. 67714
 test-amd64-amd64-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 
67714

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67714
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67714
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67714
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67714
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67714
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67714
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67714
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67714
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67714
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67714
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67714
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67714
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67714
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67714

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

version 

[Xen-devel] [qemu-mainline baseline-only test] 67719: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 67712
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot fail REGR. vs. 67712
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
REGR. vs. 67712

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

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

version targeted for testing:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842
baseline version:
 qemuu507e4ddc3abf67391bcbc9624fd60b969c159b78

Last test of basis67712  2016-09-14 19:16:26 Z1 days
Testing same since67719  2016-09-15 17:19:47 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Cao jin 
  Colin Lord 
  Cornelia Huck 
  Daniel P. Berrange 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Fam Zheng 
  Hervé Poussineau 
  Hervé Poussineau 
  Igor Mammedov 
  Lin Ma 
  Lluís Vilanova 
  Markus Armbruster 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  Prasad J Pandit 
  Richard Henderson 
  Rony Weng 
  Sergey Fedorov 
  Sergey Fedorov 
  Thomas Huth 

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

Re: [Xen-devel] [Help] Trigger Watchdog when adding an IPI in vcpu_wake

[Wei Yang]

On Wed, Sep 14, 2016 at 06:18:48PM +0200, Dario Faggioli wrote:
>On Wed, 2016-09-14 at 18:44 +0800, Wei Yang wrote:
>> On Tue, Sep 13, 2016 at 01:30:17PM +0200, Dario Faggioli wrote:
>> > 
>> > Do you mind sharing just a bit more, such as:
>> >  - number of pcpus
>> >  - number of vcpus of the various VMs
>> 160 pcpus
>> 16 vcpus in VM and 8 VMs
>> 
>So, 16x8=128, which means you're not even oversubscribing. Maybe some
>of the pcpus are hyperthreads and not full cores (are they?), but
>still, this is not something I'd describe "super intensive cpu load".
>
>Oh, well, there's dom0 of course. So, if dom0 has more than 160-128=32
>vcpus (is this the case?), you technically are oversubscribing. But
>then, what does dom0 do? Is it very busy doing some stuff on its own,
>or running the backends/etc for the VMs? Can you check that with top,
>xentop, and alike?
>
>If the system is not overbooked, it's a bit strange that the scheduler
>is the bottleneck.

I looked at the original data again. I don't see detailed data to describe the
dom0 configuration.

The exact user model is not accessible from our client. We guess their model
looks like this.


 ++ +---+ +-+
 |Timer   | --->|Coordinator| ---+--->|Worker   |
 ++ +---+|+-+
 |
 |+-+
 +--->|Worker   |
 |+-+
 |
 |+-+
 +--->|Worker   |
  +-+

One Coordinator would driver several workers based on a high resolution timer.
Periodically, workers would be waked up by the coordinator. So at one moment,
many workers would be waked up and would triggers the vcpu_wake() in xen.

Not sure this would be a possible reason for the burst vcpu_wake()?

>
>> Yes, the "Blue Screen" is what we want to mimic the behavior from
>> client.
>> 
>> The "Blue Screen" will force the hypervisor to do load balance in my
>> mind.
>> 
>I've no idea what this means (but I don't know much of Windows and of
>what happens when it crashes with a blue screen).
>
>> > I'll have a quick look at how __runq_tickle() looks like in Xen
>> > 4.1,
>> > but there's very few chances I'll be available to provide detailed
>> > review, advice, testing, etc., on such an old codebase. :-(
>> > 
>> > > 
>> > > By looking at the code, what I missed may be in __runq_tickle(),
>> > > which in case
>> > > there are idle pcpu, schedule_softirq is also raised on them. By
>> > > doing so,
>> > > those idle pcpus would steal other busy tasks and may in chance
>> > > get
>> > > d2v2?
>> > > 
>> > Yes, it looks like, in Xen 4.1, this is more or less what happens.
>> > The
>> > idea is to always tickle pcpu 6, if the priority of the waking vcpu
>> > is
>> > higher than what is running there. 
>> > 
>> Hmm... in case there are idle pcpus and the priority of the waking
>> vcpu is
>> higher than what is running on pcpu 6, would pcpu 6 have more chance
>> to run it?
>> or other idle pcup would steal it from pcpu6? or they have equal
>> chance?
>> 
>No, it works like this:
>
> - pcpu 6 is eithe idle or it is running someone already (say d3v4)
>   + if pcpu 6 is idle, we tickle (i.e., we raise SCHEDULE_SOFTIRQ)
>     pcpu 6 itself, and we're done

Ok, it looks the behavior differs from 4.1 and current upstream. The upstream
just raise the softirq to pcpu6 when it is idle, while 4.1 would raise softirq
to both pcpu6 and other idlers even pcpu6 is idle.

I think current upstream is more cleaver.

>   + if pcpu 6 is running d3v4 and there is no other idle pcpu:
>     * if prio(d2v2) > prio(d3v4) we tickle pcpu 6 and we're done
>     * if prio(d2v2) < prio(d3v4) we just don't tickle anyone
>   + if pcpu 6 is running d3v4 and there are some idle pcpus:
>     * if prio(d2v2) > prio(d3v4) we tickle pcpu 6 _AND_ one or  [1]
>       more of the idle pcpus
>     * if prio(d2v2) < prio(d3v4) we _ONLY_ tickle one or more   [2]
>       of the idle pcpus
>
>Idea behind [1] is that d2v2 should preempt d3v4 on pcpu 6, and that's
>why we tickle pcpu 6. However, that would mean that d3v4 would be put
>back in pcpu's 6 runqueue. So, if there are idle pcpus, we tickle them
>so that one can come and steam d3v4.
>
>Idea behind [2] is that d3v4 should continue to run on pcpu 6, while
>d2v2 will be put in pcpu's 6 runqueue. However, if there are idle
>pcpus, we tickle them so that one can come and steal d2v2.
>
>What really happens is not always what is expected, because it's
>possible that, even if prio(d2v2)>prio(d3v4), an idler is quicker in
>waking up and stealing d2v2 from pcpu's 6 runqueue where it was stashed
>while pcpu 6 itself reschedules and enacts the preemption... But that's
>unlikely and, all in 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42
baseline version:
 ovmf f8db6527da8678f1480f08ba99b745279e8d104a

Last test of basis67717  2016-09-15 10:49:16 Z0 days
Testing same since67720  2016-09-15 17:19:47 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 490acf8908f797982f367bfeb4bdf3ebe0764e42
Author: Ard Biesheuvel 
Date:   Thu Sep 15 14:23:11 2016 +0100

ArmVirtPkg/HighMemDxe: move to FDT client protocol

Use the FDT client protocol rather than parsing the DT directly using
fdtlib. While we're at it, update the code so it deals correctly with
memory nodes that describe multiple disjoint regions in their "reg"
properties, and make the code work with #address-cells/#size-cells
properties of <1> as well as <2>.

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

commit 969d2eb3875a700a223840d7ea415e78de4f8cbe
Author: Ard Biesheuvel 
Date:   Thu Sep 15 13:33:23 2016 +0100

ArmVirtPkg/FdtClientDxe: add methods to iterate over memory nodes

Add high level methods to iterate over all 'reg' properties of all DT
nodes whose device_type properties have the value "memory". Since we are
modifying the FdtClient protocol, update the protocol and the only existing
implementation at the same time.

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

commit cfc8d51c0cbf97b5e71cfd92dcc6c5760940214f
Author: Ard Biesheuvel 
Date:   Thu Sep 15 14:15:14 2016 +0100

ArmVirtPkg/FdtClientDxe: report address and size cell count directly

The FDT client protocol methods dealing with "reg" properties return
the size of a "reg" element. Currently, we have hardcoded this as '8',
since #address-cells == #size-cells == 2 in most cases. However, for
different values, have a single 'reg' element size is not unambiguous,
since - however unlikely - if #address-cells != #size-cells, we do not
know which is which.

So before adding more methods to the protocol, fix up this oversight.

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

commit 38ed4a9e3a65185e7e7b3c891feab1ddc865fdb5
Author: Ard Biesheuvel 
Date:   Thu Sep 15 13:48:15 2016 +0100

ArmVirtPkg/FdtClientDxe: fix check for size of "reg" properties

Currently, the code in FdtClientDxe assumes #address-cells/#size-cells
values of <2>. Since DT "reg" properties always consist of 
tuples, this means the size of the entire property should always be a
multiple of 16 bytes (i.e, 4 * sizeof(UINT32), not 8. So fix this.

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

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

Re: [Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Andy Lutomirski]

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey  wrote:
> Intel supports faulting on the CPUID instruction in newer processors. Bit
> 31 of MSR_PLATFORM_INFO advertises support for this feature. It is
> documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf
>
> Support for this is implemented as a new pair of arch_prctls, available on 
> both x86-32 and x86-64.  The structure mirrors PR_[GET|SET]_TSC.  Like the 
> TSC flag, CPUID faulting is propagated across forks.  Unlike the TSC flag, it 
> is reset (to CPUID enabled) on exec.
>
> Signed-off-by: Kyle Huey 
> ---
>  arch/x86/include/asm/msr-index.h  |   1 +
>  arch/x86/include/asm/thread_info.h|   5 +-
>  arch/x86/include/uapi/asm/prctl.h |   6 +
>  arch/x86/kernel/process.c |  98 -
>  fs/exec.c |   6 +
>  tools/testing/selftests/x86/Makefile  |   2 +-
>  tools/testing/selftests/x86/cpuid-fault.c | 234 
> ++
>  7 files changed, 349 insertions(+), 3 deletions(-)
>  create mode 100644 tools/testing/selftests/x86/cpuid-fault.c
>
> diff --git a/arch/x86/include/asm/msr-index.h 
> b/arch/x86/include/asm/msr-index.h
> index 83908d5..4aebec2 100644
> --- a/arch/x86/include/asm/msr-index.h
> +++ b/arch/x86/include/asm/msr-index.h
> @@ -53,6 +53,7 @@
>  #define MSR_MTRRcap0x00fe
>  #define MSR_IA32_BBL_CR_CTL0x0119
>  #define MSR_IA32_BBL_CR_CTL3   0x011e
> +#define MSR_MISC_FEATURES_ENABLES  0x0140
>
>  #define MSR_IA32_SYSENTER_CS   0x0174
>  #define MSR_IA32_SYSENTER_ESP  0x0175
> diff --git a/arch/x86/include/asm/thread_info.h 
> b/arch/x86/include/asm/thread_info.h
> index 8b7c8d8..e3c40c6 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -93,6 +93,7 @@ struct thread_info {
>  #define TIF_SECCOMP8   /* secure computing */
>  #define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return 
> */
>  #define TIF_UPROBE 12  /* breakpointed or singlestepping */
> +#define TIF_NOCPUID15  /* CPUID is not accessible in 
> userland */
>  #define TIF_NOTSC  16  /* TSC is not accessible in userland 
> */
>  #define TIF_IA32   17  /* IA32 compatibility process */
>  #define TIF_FORK   18  /* ret_from_fork */
> @@ -117,6 +118,7 @@ struct thread_info {
>  #define _TIF_SECCOMP   (1 << TIF_SECCOMP)
>  #define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
>  #define _TIF_UPROBE(1 << TIF_UPROBE)
> +#define _TIF_NOCPUID   (1 << TIF_NOCPUID)
>  #define _TIF_NOTSC (1 << TIF_NOTSC)
>  #define _TIF_IA32  (1 << TIF_IA32)
>  #define _TIF_FORK  (1 << TIF_FORK)
> @@ -146,7 +148,7 @@ struct thread_info {
>
>  /* flags to check in __switch_to() */
>  #define _TIF_WORK_CTXSW  
>   \
> -   (_TIF_IO_BITMAP|_TIF_NOTSC|_TIF_BLOCKSTEP)
> +   (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP)
>
>  #define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
>  #define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
> @@ -293,6 +295,7 @@ static inline bool in_ia32_syscall(void)
>  extern void arch_task_cache_init(void);
>  extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct 
> *src);
>  extern void arch_release_task_struct(struct task_struct *tsk);
> +extern void arch_post_exec(void);
>  #endif /* !__ASSEMBLY__ */
>
>  #endif /* _ASM_X86_THREAD_INFO_H */
> diff --git a/arch/x86/include/uapi/asm/prctl.h 
> b/arch/x86/include/uapi/asm/prctl.h
> index 3ac5032..c087e55 100644
> --- a/arch/x86/include/uapi/asm/prctl.h
> +++ b/arch/x86/include/uapi/asm/prctl.h
> @@ -6,4 +6,10 @@
>  #define ARCH_GET_FS 0x1003
>  #define ARCH_GET_GS 0x1004
>
> +/* Get/set the process' ability to use the CPUID instruction */
> +#define ARCH_GET_CPUID 0x1005
> +#define ARCH_SET_CPUID 0x1006
> +# define ARCH_CPUID_ENABLE 1   /* allow the use of the CPUID 
> instruction */
> +# define ARCH_CPUID_SIGSEGV2   /* throw a SIGSEGV instead of 
> reading the CPUID */
> +
>  #endif /* _ASM_X86_PRCTL_H */
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 1421451..f307d5c 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   * per-CPU TSS segments. Threads are completely 'soft' on Linux,
> @@ -191,6 +192,75 @@ int set_tsc_mode(unsigned int val)
> return 0;
>  }
>
> +static void switch_cpuid_faulting(bool on)
> +{
> +   if (on)
> +   msr_set_bit(MSR_MISC_FEATURES_ENABLES, 0);
> 

Re: [Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

[Andy Lutomirski]

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey  wrote:
> arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
> now. Rename the second arg to a more generic name.
>
> Signed-off-by: Kyle Huey 
> ---
>  arch/x86/entry/syscalls/syscall_32.tbl |  1 +
>  arch/x86/include/asm/proto.h   |  5 -
>  arch/x86/kernel/process.c  | 10 ++
>  arch/x86/kernel/process_64.c   | 33 +
>  arch/x86/kernel/ptrace.c   |  8 
>  arch/x86/um/Makefile   |  2 +-
>  arch/x86/um/syscalls_32.c  |  7 +++
>  arch/x86/um/syscalls_64.c  |  4 ++--
>  include/linux/compat.h |  2 ++
>  9 files changed, 52 insertions(+), 20 deletions(-)
>  create mode 100644 arch/x86/um/syscalls_32.c
>
> diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
> b/arch/x86/entry/syscalls/syscall_32.tbl
> index f848572..666fa61 100644
> --- a/arch/x86/entry/syscalls/syscall_32.tbl
> +++ b/arch/x86/entry/syscalls/syscall_32.tbl
> @@ -386,3 +386,4 @@
>  377i386copy_file_range sys_copy_file_range
>  378i386preadv2 sys_preadv2 
> compat_sys_preadv2
>  379i386pwritev2sys_pwritev2
> compat_sys_pwritev2
> +380i386arch_prctl  compat_sys_arch_prctl   
> compat_sys_arch_prctl

Let's call this sys_arch_prctl_32, even if it's unconventional.  See below.

> diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
> index 9b9b30b..f0e86aa 100644
> --- a/arch/x86/include/asm/proto.h
> +++ b/arch/x86/include/asm/proto.h
> @@ -30,6 +30,9 @@ void x86_report_nx(void);
>
>  extern int reboot_force;
>
> -long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
> +long do_arch_prctl_common(struct task_struct *task, int code, unsigned long 
> addr);
> +#ifdef CONFIG_X86_64
> +long do_arch_prctl_64(struct task_struct *task, int code, unsigned long 
> addr);
> +#endif
>
>  #endif /* _ASM_X86_PROTO_H */
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 62c0b0e..1421451 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -567,3 +567,13 @@ unsigned long get_wchan(struct task_struct *p)
> } while (count++ < 16 && p->state != TASK_RUNNING);
> return 0;
>  }
> +
> +long do_arch_prctl_common(struct task_struct *task, int code, unsigned long 
> arg2)
> +{
> +   return -EINVAL;
> +}
> +
> +asmlinkage long compat_sys_arch_prctl(int code, unsigned long arg2)

I believe you mean COMPAT_SYSCALL_DEFINE2 here.

But I see what you're doing here.  Could you instead do:

#if defined(CONFIG_IA32_EMULATION) || defined(CONFIG_X86_32)
#ifdef CONFIG_X86_32
COMPAT_SYSCALL_DEFINE2(...)
#else
SYSCALL_DEFINE2(...)
#endif

... body here ...
#endif

and name the thing do_arch_prctl_32?

It's too bad we don't have a SYSCALL_DEFINE_32 macro.  But you could add one...


> diff --git a/arch/x86/um/syscalls_32.c b/arch/x86/um/syscalls_32.c
> new file mode 100644
> index 000..c6812c1
> --- /dev/null
> +++ b/arch/x86/um/syscalls_32.c
> @@ -0,0 +1,7 @@
> +#include 
> +#include 
> +
> +long compat_sys_arch_prctl(int code, unsigned long arg2)

COMPAT_SYSCALL_DEFINE2

Also, does this really need a new file?

> -long sys_arch_prctl(int code, unsigned long addr)
> +long sys_arch_prctl(int code, unsigned long arg2)

SYSCALL_DEFINE2

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

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

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 100966
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100966
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 100966
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100966

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

version targeted for testing:
 qemuu9f16390cd3cdd85fa20739f07120f4d697c11837
baseline version:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842

Last test of basis   100966  2016-09-15 10:45:30 Z0 days
Testing same since   100971  2016-09-15 17:22:22 Z0 days1 attempts


People who touched revisions under test:
  Andrew Dutcher 
  Gerd Hoffmann 
  Hans Petter Selasky 
  Isaac Lozano <109loza...@gmail.com>
  John Arbuckle 
  Li Qiang 
  Peter Maydell 
  Programmingkid 

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

Re: [Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Andy Lutomirski]

On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey  wrote:

Reviewed-by: Andy Lutomirski 

although this is really Borislav's domain.

OTOH, if you're planning on changing Linux's Xen MSR helpers to mask
the feature out, that should be in the same patch or an earlier patch.

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Kyle Huey]

On Thu, Sep 15, 2016 at 12:37 PM, Andy Lutomirski  wrote:
> On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey  wrote:
>> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich  wrote:
>> On 15.09.16 at 12:05,  wrote:
 On 14/09/16 22:01, Kyle Huey wrote:
> Xen advertises the underlying support for CPUID faulting but not does pass
> through writes to the relevant MSR, nor does it virtualize it, so it does
> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.

 Could you clarify in the commit message that it is PV guests that are
 affected.
>>>
>>> What makes you think HVM ones aren't?
>>
>> Testing on EC2, HVM guests are affected as well.  Not sure what to do
>> about that.
>>
>
> It's kind of nasty, but it shouldn't be *too* hard to probe for this
> thing during early boot.  Allocate a page somewhere that has the user
> bit set, put something like this in it:
>
> cpuid
> inc %eax  /* return 1 */
> movw %ax, %ss /* force %GP to get out of here */
>
> Call it like this from asm (real asm, not inline):
>
> FRAME_BEGIN
> pushq %rbx
>
> xorl %eax, %eax
>
> /* Push return frame */
> pushq %ss
> pushq %rsp
> addq $8, (%rsp)
> pushfq
> pushq %cs
> pushq $end_of_cpuid_faulting_test
>
> /* Call it! */
> pushq $__USER_DS
> pushq $0
> pushq $X86_EFLAGS_FIXED  /* leave IF off when running the CPL3 stub */
> pushq $__USER_CS
> pushq [address of userspace stub]
> INTERRUPT_RETURN
>
> end_of_cpuid_faulting_test:
> pop %rbx
>
> FRAME_END
>
> Run this after the main GDT is loaded but while the #GP vector is
> temporarily pointing to:
>
> movq SS-RIP(%rsp), %rsp  /* pop the real return frame */
> INTERRUPT_RETURN
>
> and with interrupts off.  The function should return 0 if CPUID
> faulting works and 1 if it doesn't.
>
> Yeah, this is gross, but it should work.  I'm not sure how okay I am
> with putting this crap in the kernel...

This is rather heroic :)

I think it's more trouble than it's worth though.  The latest series I
submitted doesn't try to handle this.  Instead I'll patch Xen to fix
the bug.

- Kyle

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

[Xen-devel] [PATCH v3] arch_prctl, x86 Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Kyle Huey]

rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by providing constant results.

The following changes have been made since v2.

Patch 1:
- Use of compat_sys_arch_prctl and separate do_arch_prctl_[common|64]
  functions to separate generic and 64-bit only arch_prctls.

Patch 2:
- The hack to suppress the mistakenly advertised CPUID faulting support in
  Xen guests is removed. Doing this for both PV and HVM guests is quite
  tricky, and likely more trouble than it's worth. Instead I'll submit a
  patch to Xen.

Patch 3:
- TIF_NOCPUID is now droppped on exec. I added the arch_post_exec hook
  as I didn't see any existing place to run arch-specific code during
  exec. The test is updated for the new exec behavior.



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

[Xen-devel] [PATCH v3 3/3] x86, arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction

[Kyle Huey]

Intel supports faulting on the CPUID instruction in newer processors. Bit
31 of MSR_PLATFORM_INFO advertises support for this feature. It is
documented in detail in Section 2.3.2 of
http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf

Support for this is implemented as a new pair of arch_prctls, available on both 
x86-32 and x86-64.  The structure mirrors PR_[GET|SET]_TSC.  Like the TSC flag, 
CPUID faulting is propagated across forks.  Unlike the TSC flag, it is reset 
(to CPUID enabled) on exec.

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/msr-index.h  |   1 +
 arch/x86/include/asm/thread_info.h|   5 +-
 arch/x86/include/uapi/asm/prctl.h |   6 +
 arch/x86/kernel/process.c |  98 -
 fs/exec.c |   6 +
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/cpuid-fault.c | 234 ++
 7 files changed, 349 insertions(+), 3 deletions(-)
 create mode 100644 tools/testing/selftests/x86/cpuid-fault.c

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 83908d5..4aebec2 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -53,6 +53,7 @@
 #define MSR_MTRRcap0x00fe
 #define MSR_IA32_BBL_CR_CTL0x0119
 #define MSR_IA32_BBL_CR_CTL3   0x011e
+#define MSR_MISC_FEATURES_ENABLES  0x0140
 
 #define MSR_IA32_SYSENTER_CS   0x0174
 #define MSR_IA32_SYSENTER_ESP  0x0175
diff --git a/arch/x86/include/asm/thread_info.h 
b/arch/x86/include/asm/thread_info.h
index 8b7c8d8..e3c40c6 100644
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -93,6 +93,7 @@ struct thread_info {
 #define TIF_SECCOMP8   /* secure computing */
 #define TIF_USER_RETURN_NOTIFY 11  /* notify kernel of userspace return */
 #define TIF_UPROBE 12  /* breakpointed or singlestepping */
+#define TIF_NOCPUID15  /* CPUID is not accessible in userland 
*/
 #define TIF_NOTSC  16  /* TSC is not accessible in userland */
 #define TIF_IA32   17  /* IA32 compatibility process */
 #define TIF_FORK   18  /* ret_from_fork */
@@ -117,6 +118,7 @@ struct thread_info {
 #define _TIF_SECCOMP   (1 << TIF_SECCOMP)
 #define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
 #define _TIF_UPROBE(1 << TIF_UPROBE)
+#define _TIF_NOCPUID   (1 << TIF_NOCPUID)
 #define _TIF_NOTSC (1 << TIF_NOTSC)
 #define _TIF_IA32  (1 << TIF_IA32)
 #define _TIF_FORK  (1 << TIF_FORK)
@@ -146,7 +148,7 @@ struct thread_info {
 
 /* flags to check in __switch_to() */
 #define _TIF_WORK_CTXSW
\
-   (_TIF_IO_BITMAP|_TIF_NOTSC|_TIF_BLOCKSTEP)
+   (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP)
 
 #define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
 #define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
@@ -293,6 +295,7 @@ static inline bool in_ia32_syscall(void)
 extern void arch_task_cache_init(void);
 extern int arch_dup_task_struct(struct task_struct *dst, struct task_struct 
*src);
 extern void arch_release_task_struct(struct task_struct *tsk);
+extern void arch_post_exec(void);
 #endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_X86_THREAD_INFO_H */
diff --git a/arch/x86/include/uapi/asm/prctl.h 
b/arch/x86/include/uapi/asm/prctl.h
index 3ac5032..c087e55 100644
--- a/arch/x86/include/uapi/asm/prctl.h
+++ b/arch/x86/include/uapi/asm/prctl.h
@@ -6,4 +6,10 @@
 #define ARCH_GET_FS 0x1003
 #define ARCH_GET_GS 0x1004
 
+/* Get/set the process' ability to use the CPUID instruction */
+#define ARCH_GET_CPUID 0x1005
+#define ARCH_SET_CPUID 0x1006
+# define ARCH_CPUID_ENABLE 1   /* allow the use of the CPUID 
instruction */
+# define ARCH_CPUID_SIGSEGV2   /* throw a SIGSEGV instead of 
reading the CPUID */
+
 #endif /* _ASM_X86_PRCTL_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 1421451..f307d5c 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * per-CPU TSS segments. Threads are completely 'soft' on Linux,
@@ -191,6 +192,75 @@ int set_tsc_mode(unsigned int val)
return 0;
 }
 
+static void switch_cpuid_faulting(bool on)
+{
+   if (on)
+   msr_set_bit(MSR_MISC_FEATURES_ENABLES, 0);
+   else
+   msr_clear_bit(MSR_MISC_FEATURES_ENABLES, 0);
+}
+
+static void disable_cpuid(void)
+{
+   preempt_disable();
+   if (!test_and_set_thread_flag(TIF_NOCPUID))
+   /*
+* Must flip the CPU state synchronously with
+

[Xen-devel] [PATCH v3 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Kyle Huey]

Signed-off-by: Kyle Huey 
---
 arch/x86/include/asm/cpufeatures.h |  1 +
 arch/x86/include/asm/msr-index.h   |  1 +
 arch/x86/kernel/cpu/scattered.c| 14 ++
 3 files changed, 16 insertions(+)

diff --git a/arch/x86/include/asm/cpufeatures.h 
b/arch/x86/include/asm/cpufeatures.h
index 92a8308..78b9d06 100644
--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -190,6 +190,7 @@
 
 #define X86_FEATURE_CPB( 7*32+ 2) /* AMD Core Performance 
Boost */
 #define X86_FEATURE_EPB( 7*32+ 3) /* IA32_ENERGY_PERF_BIAS 
support */
+#define X86_FEATURE_CPUID_FAULT ( 7*32+ 4) /* Intel CPUID faulting */
 
 #define X86_FEATURE_HW_PSTATE  ( 7*32+ 8) /* AMD HW-PState */
 #define X86_FEATURE_PROC_FEEDBACK ( 7*32+ 9) /* AMD ProcFeedbackInterface */
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 56f4c66..83908d5 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,6 +41,7 @@
 #define MSR_IA32_PERFCTR1  0x00c2
 #define MSR_FSB_FREQ   0x00cd
 #define MSR_PLATFORM_INFO  0x00ce
+#define CPUID_FAULTING_SUPPORT (1UL << 31)
 
 #define MSR_NHM_SNB_PKG_CST_CFG_CTL0x00e2
 #define NHM_C3_AUTO_DEMOTE (1UL << 25)
diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index 8cb57df..d502da1 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -24,6 +24,17 @@ enum cpuid_regs {
CR_EBX
 };
 
+static int supports_cpuid_faulting(void)
+{
+   unsigned int lo, hi;
+
+   if (rdmsr_safe(MSR_PLATFORM_INFO, , ) == 0 &&
+   (lo & CPUID_FAULTING_SUPPORT))
+   return 1;
+   else
+   return 0;
+}
+
 void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
 {
u32 max_level;
@@ -54,4 +65,7 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
if (regs[cb->reg] & (1 << cb->bit))
set_cpu_cap(c, cb->feature);
}
+
+   if (supports_cpuid_faulting())
+   set_cpu_cap(c, X86_FEATURE_CPUID_FAULT);
 }
-- 
2.9.3


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

[Xen-devel] [PATCH v3 1/3] syscalls, x86 Expose arch_prctl on x86-32.

[Kyle Huey]

arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
now. Rename the second arg to a more generic name.

Signed-off-by: Kyle Huey 
---
 arch/x86/entry/syscalls/syscall_32.tbl |  1 +
 arch/x86/include/asm/proto.h   |  5 -
 arch/x86/kernel/process.c  | 10 ++
 arch/x86/kernel/process_64.c   | 33 +
 arch/x86/kernel/ptrace.c   |  8 
 arch/x86/um/Makefile   |  2 +-
 arch/x86/um/syscalls_32.c  |  7 +++
 arch/x86/um/syscalls_64.c  |  4 ++--
 include/linux/compat.h |  2 ++
 9 files changed, 52 insertions(+), 20 deletions(-)
 create mode 100644 arch/x86/um/syscalls_32.c

diff --git a/arch/x86/entry/syscalls/syscall_32.tbl 
b/arch/x86/entry/syscalls/syscall_32.tbl
index f848572..666fa61 100644
--- a/arch/x86/entry/syscalls/syscall_32.tbl
+++ b/arch/x86/entry/syscalls/syscall_32.tbl
@@ -386,3 +386,4 @@
 377i386copy_file_range sys_copy_file_range
 378i386preadv2 sys_preadv2 
compat_sys_preadv2
 379i386pwritev2sys_pwritev2
compat_sys_pwritev2
+380i386arch_prctl  compat_sys_arch_prctl   
compat_sys_arch_prctl
diff --git a/arch/x86/include/asm/proto.h b/arch/x86/include/asm/proto.h
index 9b9b30b..f0e86aa 100644
--- a/arch/x86/include/asm/proto.h
+++ b/arch/x86/include/asm/proto.h
@@ -30,6 +30,9 @@ void x86_report_nx(void);
 
 extern int reboot_force;
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr);
+long do_arch_prctl_common(struct task_struct *task, int code, unsigned long 
addr);
+#ifdef CONFIG_X86_64
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long addr);
+#endif
 
 #endif /* _ASM_X86_PROTO_H */
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 62c0b0e..1421451 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -567,3 +567,13 @@ unsigned long get_wchan(struct task_struct *p)
} while (count++ < 16 && p->state != TASK_RUNNING);
return 0;
 }
+
+long do_arch_prctl_common(struct task_struct *task, int code, unsigned long 
arg2)
+{
+   return -EINVAL;
+}
+
+asmlinkage long compat_sys_arch_prctl(int code, unsigned long arg2)
+{
+   return do_arch_prctl_common(current, code, arg2);
+}
diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 63236d8..0e44608 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -196,7 +197,7 @@ int copy_thread_tls(unsigned long clone_flags, unsigned 
long sp,
(struct user_desc __user *)tls, 0);
else
 #endif
-   err = do_arch_prctl(p, ARCH_SET_FS, tls);
+   err = do_arch_prctl_64(p, ARCH_SET_FS, tls);
if (err)
goto out;
}
@@ -524,7 +525,7 @@ void set_personality_ia32(bool x32)
 }
 EXPORT_SYMBOL_GPL(set_personality_ia32);
 
-long do_arch_prctl(struct task_struct *task, int code, unsigned long addr)
+long do_arch_prctl_64(struct task_struct *task, int code, unsigned long arg2)
 {
int ret = 0;
int doit = task == current;
@@ -532,48 +533,50 @@ long do_arch_prctl(struct task_struct *task, int code, 
unsigned long addr)
 
switch (code) {
case ARCH_SET_GS:
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.gsindex = 0;
-   task->thread.gsbase = addr;
+   task->thread.gsbase = arg2;
if (doit) {
load_gs_index(0);
-   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, addr);
+   ret = wrmsrl_safe(MSR_KERNEL_GS_BASE, arg2);
}
put_cpu();
break;
case ARCH_SET_FS:
/* Not strictly needed for fs, but do it for symmetry
   with gs */
-   if (addr >= TASK_SIZE_MAX)
+   if (arg2 >= TASK_SIZE_MAX)
return -EPERM;
cpu = get_cpu();
task->thread.fsindex = 0;
-   task->thread.fsbase = addr;
+   task->thread.fsbase = arg2;
if (doit) {
/* set the selector to 0 to not confuse __switch_to */
loadsegment(fs, 0);
-   ret = wrmsrl_safe(MSR_FS_BASE, addr);
+   ret = wrmsrl_safe(MSR_FS_BASE, arg2);
}
put_cpu();
break;
case ARCH_GET_FS: {
unsigned long base;
+
if (doit)
  

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Andy Lutomirski]

On Thu, Sep 15, 2016 at 1:38 PM, H. Peter Anvin  wrote:
> On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski  
> wrote:
>>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey  wrote:
>>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>>>  wrote:
 On 09/14/2016 02:01 PM, Kyle Huey wrote:
>>
 Is any of this useful to optimize away at compile-time?  We have
>>config
 options for when we're running as a guest, and this seems like a
>>feature
 that isn't available when running on bare metal.
>>>
>>> On the contrary, this is only available when we're on bare metal.
>>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>>> suppresses MSR_PLATFORM_INFO's report of support for it).
>>
>>KVM could easily support this.  If rr starts using it, I think KVM
>>*should* add support, possibly even for older CPUs that don't support
>>the feature in hardware.
>>
>>It's too bad that x86 doesn't give us the instruction bytes on a
>>fault.  Otherwise we could lazily switch this feature.
>>
>>--Andy
>
> You can "always" examine the instruction bytes in memory... have to make sure 
> you properly consider the impact of race conditions though.

I'd rather avoid needing to worry about those race conditions if at
all possible, though.  Intel and AMD both have fancy "decode assists"
and such -- it would be quite nice IMO if we could get the same data
exposed in the handlers of synchronous faults.

If Intel or AMD were to do this for real, presumably the rule would be
that any fault-class exception caused by a validly-decoded instruction
at CPL3 (so #PF and #GP would count but #DB probably wouldn't, and #DF
wouldn't either unless the initial fault did) would stash away the
faulting instruction and other entries would instead stash away
"nothing here".  Some pair of MSRs or new instruction would read out
information.  Then we could accurately emulate CPUID, we could
accurately emulate page-faulting instructions if we cared, etc.  All
of the relevant hardware must already mostly exist because VMX and SVM
both have this capability.

--Andy

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 100965
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail REGR. vs. 100965
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 100965

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

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

version targeted for testing:
 xen  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
baseline version:
 xen  3ab5fb9a9eeb2b610d5d74419e0b1ffaf18484f2

Last test of basis   100965  2016-09-15 09:14:21 Z0 days
Testing same since   100970  2016-09-15 16:14:46 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[H. Peter Anvin]

On September 14, 2016 6:17:51 PM PDT, Andy Lutomirski  
wrote:
>On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey  wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>>  wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize away at compile-time?  We have
>config
>>> options for when we're running as a guest, and this seems like a
>feature
>>> that isn't available when running on bare metal.
>>
>> On the contrary, this is only available when we're on bare metal.
>> Neither Xen nor KVM virtualize CPUID faulting (although KVM correctly
>> suppresses MSR_PLATFORM_INFO's report of support for it).
>
>KVM could easily support this.  If rr starts using it, I think KVM
>*should* add support, possibly even for older CPUs that don't support
>the feature in hardware.
>
>It's too bad that x86 doesn't give us the instruction bytes on a
>fault.  Otherwise we could lazily switch this feature.
>
>--Andy

You can "always" examine the instruction bytes in memory... have to make sure 
you properly consider the impact of race conditions though.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Boris Ostrovsky]

On 09/15/2016 03:11 PM, Kyle Huey wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich  wrote:
> On 15.09.16 at 12:05,  wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
 Xen advertises the underlying support for CPUID faulting but not does pass
 through writes to the relevant MSR, nor does it virtualize it, so it does
 not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>> Could you clarify in the commit message that it is PV guests that are
>>> affected.
>> What makes you think HVM ones aren't?
> Testing on EC2, HVM guests are affected as well.  Not sure what to do
> about that.

You could clear capability bit in xen_set_cpu_features() but of course
this assumes you will never again read MSR_PLATFORM_INFO.

-boris

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Andy Lutomirski]

On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey  wrote:
> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich  wrote:
> On 15.09.16 at 12:05,  wrote:
>>> On 14/09/16 22:01, Kyle Huey wrote:
 Xen advertises the underlying support for CPUID faulting but not does pass
 through writes to the relevant MSR, nor does it virtualize it, so it does
 not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>>
>>> Could you clarify in the commit message that it is PV guests that are
>>> affected.
>>
>> What makes you think HVM ones aren't?
>
> Testing on EC2, HVM guests are affected as well.  Not sure what to do
> about that.
>

It's kind of nasty, but it shouldn't be *too* hard to probe for this
thing during early boot.  Allocate a page somewhere that has the user
bit set, put something like this in it:

cpuid
inc %eax  /* return 1 */
movw %ax, %ss /* force %GP to get out of here */

Call it like this from asm (real asm, not inline):

FRAME_BEGIN
pushq %rbx

xorl %eax, %eax

/* Push return frame */
pushq %ss
pushq %rsp
addq $8, (%rsp)
pushfq
pushq %cs
pushq $end_of_cpuid_faulting_test

/* Call it! */
pushq $__USER_DS
pushq $0
pushq $X86_EFLAGS_FIXED  /* leave IF off when running the CPL3 stub */
pushq $__USER_CS
pushq [address of userspace stub]
INTERRUPT_RETURN

end_of_cpuid_faulting_test:
pop %rbx

FRAME_END

Run this after the main GDT is loaded but while the #GP vector is
temporarily pointing to:

movq SS-RIP(%rsp), %rsp  /* pop the real return frame */
INTERRUPT_RETURN

and with interrupts off.  The function should return 0 if CPUID
faulting works and 1 if it doesn't.

Yeah, this is gross, but it should work.  I'm not sure how okay I am
with putting this crap in the kernel...

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

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Kyle Huey]

On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich  wrote:
 On 15.09.16 at 12:05,  wrote:
>> On 14/09/16 22:01, Kyle Huey wrote:
>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>> through writes to the relevant MSR, nor does it virtualize it, so it does
>>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
>>
>> Could you clarify in the commit message that it is PV guests that are
>> affected.
>
> What makes you think HVM ones aren't?

Testing on EC2, HVM guests are affected as well.  Not sure what to do
about that.

- Kyle

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

[Xen-devel] [PATCH v3] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

The ARM SMC instructions are already configured to trap to Xen by default. In
this patch we allow a user-space process in a privileged domain to receive
notification of when such event happens through the vm_event subsystem by
introducing the PRIVILEGED_CALL type.

The intended use-case for this feature is for a monitor application to be able
insert tap-points into the domU kernel-code. For this task only unconditional
SMC instruction should be used.

Signed-off-by: Tamas K Lengyel 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v3: Rebase on latest master

Note: previous discussion around this patch proposed filtering SMCs with failed
  condition checks. As that patch is yet-to-be implemented and the 4.8
  code-freeze rapidly approaching I would like this patch to get included.
  In this patch a proper warning is placed in the public header for
  potential users not to rely on SMCs with failed condition checks being
  trapped. As the intended use-case for this feature doesn't use
  conditional SMCs this warning should be sufficient. Hardware that does
  issue events for SMCs with failed condition checks doesn't pose a problem
  for a monitor application in any way. The xen-access test tool illustrates
  how SMCs issued by the guest can be safely handled for all cases.
---
 tools/libxc/include/xenctrl.h   |  2 +
 tools/libxc/xc_monitor.c| 14 +++
 tools/tests/xen-access/xen-access.c | 32 ++-
 xen/arch/arm/Makefile   |  1 +
 xen/arch/arm/monitor.c  | 79 +
 xen/arch/arm/traps.c| 15 ++-
 xen/include/asm-arm/domain.h|  5 +++
 xen/include/asm-arm/monitor.h   | 18 +++--
 xen/include/public/domctl.h |  1 +
 xen/include/public/vm_event.h   |  7 
 10 files changed, 158 insertions(+), 16 deletions(-)
 create mode 100644 xen/arch/arm/monitor.c

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..eb53172 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2168,6 +2168,8 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id,
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 4298813..15a7c32 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -185,6 +185,20 @@ int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, 
bool enable)
 return do_domctl(xch, );
 }
 
+int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
+   bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_PRIVILEGED_CALL;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/tests/xen-access/xen-access.c 
b/tools/tests/xen-access/xen-access.c
index ed18c71..6eefe0c 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -338,6 +338,8 @@ void usage(char* progname)
 fprintf(stderr, "Usage: %s [-m]  write|exec", progname);
 #if defined(__i386__) || defined(__x86_64__)
 fprintf(stderr, 
"|breakpoint|altp2m_write|altp2m_exec|debug|cpuid");
+#elif defined(__arm__) || defined(__aarch64__)
+fprintf(stderr, "|privcall");
 #endif
 fprintf(stderr,
 "\n"
@@ -362,6 +364,7 @@ int main(int argc, char *argv[])
 int required = 0;
 int breakpoint = 0;
 int shutting_down = 0;
+int privcall = 0;
 int altp2m = 0;
 int debug = 0;
 int cpuid = 0;
@@ -431,6 +434,11 @@ int main(int argc, char *argv[])
 {
 cpuid = 1;
 }
+#elif defined(__arm__) || defined(__aarch64__)
+else if ( !strcmp(argv[0], "privcall") )
+{
+privcall = 1;
+}
 #endif
 else
 {
@@ -563,6 +571,16 @@ int main(int argc, char *argv[])
 }
 }
 
+if ( privcall )
+{
+rc = xc_monitor_privileged_call(xch, domain_id, 1);
+if ( rc < 0 )
+{
+ERROR("Error %d setting privileged call trapping with vm_event\n", 
rc);
+goto exit;
+}
+}
+
 /* 

Re: [Xen-devel] [for-4.8][PATCH v2 00/23] xen/arm: Rework the P2M code to follow break-before-make sequence

[Tamas K Lengyel]

On Thu, Sep 15, 2016 at 5:28 AM, Julien Grall  wrote:

> Hello all,
>
> The ARM architecture mandates the use of a break-before-make sequence when
> changing translation entries if the page table is shared between multiple
> CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1
> in ARM DDI 0487A.j for more details).
>
> The current P2M code does not respect this sequence and may result to
> break coherency on some processors.
>
> Adapting the current implementation to use break-before-make sequence would
> imply some code duplication and more TLBs invalidations than necessary.
> For instance, if we are replacing a 4KB page and the current mapping in
> the P2M is using a 1GB superpage, the following steps will happen:
> 1) Shatter the 1GB superpage into a series of 2MB superpages
> 2) Shatter the 2MB superpage into a series of 4KB superpages
> 3) Replace the 4KB page
>
> As the current implementation is shattering while descending and install
> the mapping before continuing to the next level, Xen would need to issue 3
> TLB invalidation instructions which is clearly inefficient.
>
> Furthermore, all the operations which modify the page table are using the
> same skeleton. It is more complicated to maintain different code paths than
> having a generic function that set an entry and take care of the
> break-before-
> make sequence.
>
> The new implementation is based on the x86 EPT one which, I think, fits
> quite well for the break-before-make sequence whilst keeping the code
> simple.
>
> For all the changes see in each patch.
>
> I have provided a branch based on upstream here:
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch p2m-v2
>
>
Tested-by: Tamas K Lengyel 

Works without any issue on both the Cubietruck and the HiKey LeMaker with
the xen-access test-cases.

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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Razvan Cojocaru]

On 09/15/16 19:36, Tamas K Lengyel wrote:
> On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
>  wrote:
>> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
>>> When emulating instructions the emulator maintains a small i-cache fetched
>>> from the guest memory. This patch extends the vm_event interface to allow
>>> returning this i-cache via the vm_event response instead.
>>>
>>> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
>>> normally has to remove the INT3 from memory - singlestep - place back INT3
>>> to allow the guest to continue execution. This routine however is 
>>> susceptible
>>> to a race-condition on multi-vCPU guests. By allowing the subscriber to 
>>> return
>>> the i-cache to be used for emulation it can side-step the problem by 
>>> returning
>>> a clean buffer without the INT3 present.
>>>
>>> As part of this patch we rename hvm_mem_access_emulate_one to
>>> hvm_emulate_one_vm_event to better reflect that it is used in various 
>>> vm_event
>>> scenarios now, not just in response to mem_access events.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>> ---
>>> Cc: Paul Durrant 
>>> Cc: Jan Beulich 
>>> Cc: Andrew Cooper 
>>> Cc: Jun Nakajima 
>>> Cc: Kevin Tian 
>>> Cc: George Dunlap 
>>> Cc: Razvan Cojocaru 
>>> Cc: Stefano Stabellini 
>>> Cc: Julien Grall 
>>>
>>> Note: This patch only has been compile-tested.
>>> ---
>>>  xen/arch/x86/hvm/emulate.c| 44 
>>> ++-
>>>  xen/arch/x86/hvm/hvm.c|  9 +---
>>>  xen/arch/x86/hvm/vmx/vmx.c|  1 +
>>>  xen/arch/x86/vm_event.c   |  9 +++-
>>>  xen/common/vm_event.c |  1 -
>>>  xen/include/asm-x86/hvm/emulate.h |  8 ---
>>>  xen/include/asm-x86/vm_event.h|  3 ++-
>>>  xen/include/public/vm_event.h | 16 +-
>>>  8 files changed, 67 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>>> index cc25676..504ed35 100644
>>> --- a/xen/arch/x86/hvm/emulate.c
>>> +++ b/xen/arch/x86/hvm/emulate.c
>>> @@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int 
>>> size)
>>>  if ( curr->arch.vm_event )
>>>  {
>>>  unsigned int safe_size =
>>> -min(size, curr->arch.vm_event->emul_read_data.size);
>>> +min(size, curr->arch.vm_event->emul_read.size);
>>>
>>> -memcpy(buffer, curr->arch.vm_event->emul_read_data.data, 
>>> safe_size);
>>> +memcpy(buffer, curr->arch.vm_event->emul_read.data, safe_size);
>>>  memset(buffer + safe_size, 0, size - safe_size);
>>>  return X86EMUL_OKAY;
>>>  }
>>> @@ -827,7 +827,7 @@ static int hvmemul_read(
>>>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>>>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>>
>>> -if ( unlikely(hvmemul_ctxt->set_context) )
>>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>>  return set_context_data(p_data, bytes);
>>>
>>>  return __hvmemul_read(
>>> @@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
>>>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>>>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>>
>>> -if ( unlikely(hvmemul_ctxt->set_context) )
>>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>>  {
>>>  int rc = set_context_data(p_new, bytes);
>>>
>>> @@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
>>>  p2m_type_t p2mt;
>>>  int rc;
>>>
>>> -if ( unlikely(hvmemul_ctxt->set_context) )
>>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>>  return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
>>>  bytes_per_rep, reps, ctxt);
>>>
>>> @@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
>>>  if ( buf == NULL )
>>>  return X86EMUL_UNHANDLEABLE;
>>>
>>> -if ( unlikely(hvmemul_ctxt->set_context) )
>>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>>  {
>>>  rc = set_context_data(buf, bytes);
>>>
>>> @@ -1470,7 +1470,7 @@ static int hvmemul_read_io(
>>>
>>>  *val = 0;
>>>
>>> -if ( unlikely(hvmemul_ctxt->set_context) )
>>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>>  return set_context_data(val, bytes);
>>>
>>>  return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
>>> @@ -1793,7 +1793,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
>>> *hvmemul_ctxt,
>>>  pfec |= PFEC_user_mode;
>>>
>>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>>> -if ( !vio->mmio_insn_bytes )
>>> +
>>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>>> +{
>>> +hvmemul_ctxt->insn_buf_bytes = 
>>> 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 490acf8908f797982f367bfeb4bdf3ebe0764e42
baseline version:
 ovmf f8db6527da8678f1480f08ba99b745279e8d104a

Last test of basis   100963  2016-09-15 08:14:53 Z0 days
Testing same since   100969  2016-09-15 14:44:47 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=490acf8908f797982f367bfeb4bdf3ebe0764e42
+ . ./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 
490acf8908f797982f367bfeb4bdf3ebe0764e42
+ branch=ovmf
+ revision=490acf8908f797982f367bfeb4bdf3ebe0764e42
+ . ./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
+ '[' x490acf8908f797982f367bfeb4bdf3ebe0764e42 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu8212ff86f4405b6128d89dd1d97ff2d6cfcf9842
baseline version:
 qemuu507e4ddc3abf67391bcbc9624fd60b969c159b78

Last test of basis   100951  2016-09-14 09:22:13 Z1 days
Testing same since   100966  2016-09-15 10:45:30 Z0 days1 attempts


People who touched revisions under test:
  Alex Bennée 
  Cao jin 
  Colin Lord 
  Cornelia Huck 
  Daniel P. Berrange 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Fam Zheng 
  Hervé Poussineau 
  Hervé Poussineau 
  Igor Mammedov 
  Lin Ma 
  Lluís Vilanova 
  Markus Armbruster 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  Prasad J Pandit 
  Richard Henderson 
  Rony Weng 
  Sergey Fedorov 
  Sergey Fedorov 
  Thomas Huth 

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

[Xen-devel] [PATCH v2 1/2] vm_event: Sanitize vm_event response handling

[Tamas K Lengyel]

Setting response flags in vm_event are only ever safe if the vCPUs are paused.
To reflect this we move all checks within the if block that already checks
whether this is the case. Checks that are only supported on one architecture
we relocate the bitmask operations to the arch-specific handlers to avoid
the overhead on architectures that don't support it.

Furthermore, we clean-up the emulation checks so it more clearly represents the
decision-logic when emulation should take place. As part of this we also
set the stage to allow emulation in response to other types of events, not just
mem_access violations.

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

v2: use bool instead of bool_t
---
 xen/arch/x86/mm/p2m.c  | 79 +++---
 xen/arch/x86/vm_event.c| 35 ++-
 xen/common/vm_event.c  | 53 ++--
 xen/include/asm-arm/p2m.h  |  3 +-
 xen/include/asm-arm/vm_event.h |  9 -
 xen/include/asm-x86/p2m.h  |  2 +-
 xen/include/asm-x86/vm_event.h |  5 ++-
 xen/include/xen/mem_access.h   | 12 ---
 8 files changed, 111 insertions(+), 87 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 7d14c3b..faffc2a 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1588,62 +1588,55 @@ void p2m_mem_paging_resume(struct domain *d, 
vm_event_response_t *rsp)
 }
 }
 
-void p2m_mem_access_emulate_check(struct vcpu *v,
+bool p2m_mem_access_emulate_check(struct vcpu *v,
   const vm_event_response_t *rsp)
 {
-/* Mark vcpu for skipping one instruction upon rescheduling. */
-if ( rsp->flags & VM_EVENT_FLAG_EMULATE )
-{
-xenmem_access_t access;
-bool_t violation = 1;
-const struct vm_event_mem_access *data = >u.mem_access;
+xenmem_access_t access;
+bool violation = 1;
+const struct vm_event_mem_access *data = >u.mem_access;
 
-if ( p2m_get_mem_access(v->domain, _gfn(data->gfn), ) == 0 )
+if ( p2m_get_mem_access(v->domain, _gfn(data->gfn), ) == 0 )
+{
+switch ( access )
 {
-switch ( access )
-{
-case XENMEM_access_n:
-case XENMEM_access_n2rwx:
-default:
-violation = data->flags & MEM_ACCESS_RWX;
-break;
+case XENMEM_access_n:
+case XENMEM_access_n2rwx:
+default:
+violation = data->flags & MEM_ACCESS_RWX;
+break;
 
-case XENMEM_access_r:
-violation = data->flags & MEM_ACCESS_WX;
-break;
+case XENMEM_access_r:
+violation = data->flags & MEM_ACCESS_WX;
+break;
 
-case XENMEM_access_w:
-violation = data->flags & MEM_ACCESS_RX;
-break;
+case XENMEM_access_w:
+violation = data->flags & MEM_ACCESS_RX;
+break;
 
-case XENMEM_access_x:
-violation = data->flags & MEM_ACCESS_RW;
-break;
+case XENMEM_access_x:
+violation = data->flags & MEM_ACCESS_RW;
+break;
 
-case XENMEM_access_rx:
-case XENMEM_access_rx2rw:
-violation = data->flags & MEM_ACCESS_W;
-break;
+case XENMEM_access_rx:
+case XENMEM_access_rx2rw:
+violation = data->flags & MEM_ACCESS_W;
+break;
 
-case XENMEM_access_wx:
-violation = data->flags & MEM_ACCESS_R;
-break;
+case XENMEM_access_wx:
+violation = data->flags & MEM_ACCESS_R;
+break;
 
-case XENMEM_access_rw:
-violation = data->flags & MEM_ACCESS_X;
-break;
+case XENMEM_access_rw:
+violation = data->flags & MEM_ACCESS_X;
+break;
 
-case XENMEM_access_rwx:
-violation = 0;
-break;
-}
+case XENMEM_access_rwx:
+violation = 0;
+break;
 }
-
-v->arch.vm_event->emulate_flags = violation ? rsp->flags : 0;
-
-if ( (rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA) )
-v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
 }
+
+return violation;
 }
 
 void p2m_altp2m_check(struct vcpu *v, uint16_t idx)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
index e938ca3..343b9c8 100644
--- a/xen/arch/x86/vm_event.c
+++ b/xen/arch/x86/vm_event.c
@@ -18,6 +18,7 @@
  * License along with this program; If not, see .
  */
 

[Xen-devel] [PATCH v2 2/2] x86/vm_event: Allow overwriting Xen's i-cache used for emulation

[Tamas K Lengyel]

When emulating instructions Xen's emulator maintains a small i-cache fetched
from the guest memory. This patch extends the vm_event interface to allow
overwriting this i-cache via a buffer returned in the vm_event response.

When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
normally has to remove the INT3 from memory - singlestep - place back INT3
to allow the guest to continue execution. This routine however is susceptible
to a race-condition on multi-vCPU guests. By allowing the subscriber to return
the i-cache to be used for emulation it can side-step the problem by returning
a clean buffer without the INT3 present.

As part of this patch we rename hvm_mem_access_emulate_one to
hvm_emulate_one_vm_event to better reflect that it is used in various vm_event
scenarios now, not just in response to mem_access events.

Signed-off-by: Tamas K Lengyel 
---
Cc: Paul Durrant 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
Cc: George Dunlap 
Cc: Razvan Cojocaru 
Cc: Stefano Stabellini 
Cc: Julien Grall 

v2: rework hvm_mem_access_emulate_one switch statement
add BUILD_BUG_ON to ensure internal and vm_event buffer sizes match

Note: this patch has now been fully tested and works as intended
---
 xen/arch/x86/hvm/emulate.c| 37 -
 xen/arch/x86/hvm/hvm.c|  9 ++---
 xen/arch/x86/hvm/vmx/vmx.c|  1 +
 xen/arch/x86/vm_event.c   |  9 -
 xen/common/vm_event.c |  1 -
 xen/include/asm-x86/hvm/emulate.h |  8 +---
 xen/include/asm-x86/vm_event.h|  5 -
 xen/include/public/vm_event.h | 16 +++-
 8 files changed, 63 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index cc25676..acae998 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int size)
 if ( curr->arch.vm_event )
 {
 unsigned int safe_size =
-min(size, curr->arch.vm_event->emul_read_data.size);
+min(size, curr->arch.vm_event->emul.read.size);
 
-memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
+memcpy(buffer, curr->arch.vm_event->emul.read.data, safe_size);
 memset(buffer + safe_size, 0, size - safe_size);
 return X86EMUL_OKAY;
 }
@@ -827,7 +827,7 @@ static int hvmemul_read(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(p_data, bytes);
 
 return __hvmemul_read(
@@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
 struct hvm_emulate_ctxt *hvmemul_ctxt =
 container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 int rc = set_context_data(p_new, bytes);
 
@@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
 p2m_type_t p2mt;
 int rc;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
 bytes_per_rep, reps, ctxt);
 
@@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
 if ( buf == NULL )
 return X86EMUL_UNHANDLEABLE;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 {
 rc = set_context_data(buf, bytes);
 
@@ -1470,7 +1470,7 @@ static int hvmemul_read_io(
 
 *val = 0;
 
-if ( unlikely(hvmemul_ctxt->set_context) )
+if ( unlikely(hvmemul_ctxt->set_context_data) )
 return set_context_data(val, bytes);
 
 return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
@@ -1793,7 +1793,17 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt,
 pfec |= PFEC_user_mode;
 
 hvmemul_ctxt->insn_buf_eip = regs->eip;
-if ( !vio->mmio_insn_bytes )
+
+if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
+{
+BUILD_BUG_ON(sizeof(hvmemul_ctxt->insn_buf_bytes) ==
+ sizeof(curr->arch.vm_event->emul.insn));
+
+hvmemul_ctxt->insn_buf_bytes = sizeof(curr->arch.vm_event->emul.insn);
+memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul.insn,
+   hvmemul_ctxt->insn_buf_bytes);
+}
+else if ( !vio->mmio_insn_bytes )
 {
 hvmemul_ctxt->insn_buf_bytes =
 hvm_get_insn_bytes(curr, hvmemul_ctxt->insn_buf) ?:
@@ -1931,7 +1941,7 @@ 

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Tamas K Lengyel]

On Wed, Sep 14, 2016 at 1:58 AM, Razvan Cojocaru
 wrote:
> On 09/13/2016 09:12 PM, Tamas K Lengyel wrote:
>> When emulating instructions the emulator maintains a small i-cache fetched
>> from the guest memory. This patch extends the vm_event interface to allow
>> returning this i-cache via the vm_event response instead.
>>
>> When responding to a SOFTWARE_BREAKPOINT event (INT3) the monitor subscriber
>> normally has to remove the INT3 from memory - singlestep - place back INT3
>> to allow the guest to continue execution. This routine however is susceptible
>> to a race-condition on multi-vCPU guests. By allowing the subscriber to 
>> return
>> the i-cache to be used for emulation it can side-step the problem by 
>> returning
>> a clean buffer without the INT3 present.
>>
>> As part of this patch we rename hvm_mem_access_emulate_one to
>> hvm_emulate_one_vm_event to better reflect that it is used in various 
>> vm_event
>> scenarios now, not just in response to mem_access events.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Paul Durrant 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Jun Nakajima 
>> Cc: Kevin Tian 
>> Cc: George Dunlap 
>> Cc: Razvan Cojocaru 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>>
>> Note: This patch only has been compile-tested.
>> ---
>>  xen/arch/x86/hvm/emulate.c| 44 
>> ++-
>>  xen/arch/x86/hvm/hvm.c|  9 +---
>>  xen/arch/x86/hvm/vmx/vmx.c|  1 +
>>  xen/arch/x86/vm_event.c   |  9 +++-
>>  xen/common/vm_event.c |  1 -
>>  xen/include/asm-x86/hvm/emulate.h |  8 ---
>>  xen/include/asm-x86/vm_event.h|  3 ++-
>>  xen/include/public/vm_event.h | 16 +-
>>  8 files changed, 67 insertions(+), 24 deletions(-)
>>
>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>> index cc25676..504ed35 100644
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulate.c
>> @@ -76,9 +76,9 @@ static int set_context_data(void *buffer, unsigned int 
>> size)
>>  if ( curr->arch.vm_event )
>>  {
>>  unsigned int safe_size =
>> -min(size, curr->arch.vm_event->emul_read_data.size);
>> +min(size, curr->arch.vm_event->emul_read.size);
>>
>> -memcpy(buffer, curr->arch.vm_event->emul_read_data.data, safe_size);
>> +memcpy(buffer, curr->arch.vm_event->emul_read.data, safe_size);
>>  memset(buffer + safe_size, 0, size - safe_size);
>>  return X86EMUL_OKAY;
>>  }
>> @@ -827,7 +827,7 @@ static int hvmemul_read(
>>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>
>> -if ( unlikely(hvmemul_ctxt->set_context) )
>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>  return set_context_data(p_data, bytes);
>>
>>  return __hvmemul_read(
>> @@ -1029,7 +1029,7 @@ static int hvmemul_cmpxchg(
>>  struct hvm_emulate_ctxt *hvmemul_ctxt =
>>  container_of(ctxt, struct hvm_emulate_ctxt, ctxt);
>>
>> -if ( unlikely(hvmemul_ctxt->set_context) )
>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>  {
>>  int rc = set_context_data(p_new, bytes);
>>
>> @@ -1122,7 +1122,7 @@ static int hvmemul_rep_outs(
>>  p2m_type_t p2mt;
>>  int rc;
>>
>> -if ( unlikely(hvmemul_ctxt->set_context) )
>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>  return hvmemul_rep_outs_set_context(src_seg, src_offset, dst_port,
>>  bytes_per_rep, reps, ctxt);
>>
>> @@ -1264,7 +1264,7 @@ static int hvmemul_rep_movs(
>>  if ( buf == NULL )
>>  return X86EMUL_UNHANDLEABLE;
>>
>> -if ( unlikely(hvmemul_ctxt->set_context) )
>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>  {
>>  rc = set_context_data(buf, bytes);
>>
>> @@ -1470,7 +1470,7 @@ static int hvmemul_read_io(
>>
>>  *val = 0;
>>
>> -if ( unlikely(hvmemul_ctxt->set_context) )
>> +if ( unlikely(hvmemul_ctxt->set_context_data) )
>>  return set_context_data(val, bytes);
>>
>>  return hvmemul_do_pio_buffer(port, bytes, IOREQ_READ, val);
>> @@ -1793,7 +1793,14 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt 
>> *hvmemul_ctxt,
>>  pfec |= PFEC_user_mode;
>>
>>  hvmemul_ctxt->insn_buf_eip = regs->eip;
>> -if ( !vio->mmio_insn_bytes )
>> +
>> +if ( unlikely(hvmemul_ctxt->set_context_insn) && curr->arch.vm_event )
>> +{
>> +hvmemul_ctxt->insn_buf_bytes = 
>> sizeof(curr->arch.vm_event->emul_insn);
>> +memcpy(hvmemul_ctxt->insn_buf, >arch.vm_event->emul_insn,
>> +   hvmemul_ctxt->insn_buf_bytes);
>> +}
>> + 

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/15/2016 12:05 PM, Jan Beulich wrote

>> Maybe even without changes to mk_dsdt.c
> But isn't that the critical part? 

Not necessarily since we'd use --gpl option only for
dsdt_anycpu_qemu_xen, dsdt_anycpu and dsdt_15cpu and these files are not
used by the non-GPL caller, which is libxl (it only wants dsdt_pvh).

Of course, this is what we have currently.

> And - what functionality do we lose
> without that code? There's no point in generating something that's
> of no practical use.

We don't lose any functionality (again, currently). In fact, this
indirectly prevents us from generating unnecessary files listed above.

> And then there's the question of whether excluding things from the
> build, but having them present in the sources actually helps.

The main reason for this whole relicensing debacle is to prevent non-GPL
binaries from linking against GPL objects, and this patch allows us to
do that. Yes, there will be be two non-LGPL files (dsdt.asl amd
mk_dsdt.c, which I will revert back to GPL) in an otherwise LGPL
directory but that's an in-convenience and not a license violation.



-boris




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

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Jan Beulich]

>>> On 15.09.16 at 17:27,  wrote:
> On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich  wrote:
> On 14.09.16 at 18:20,  wrote:
>>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich  wrote:
>>> On 13.09.16 at 20:12,  wrote:
> When emulating instructions the emulator maintains a small i-cache fetched
> from the guest memory. This patch extends the vm_event interface to allow
> returning this i-cache via the vm_event response instead.

 I guess I'm sightly confused: Isn't the purpose to have the monitoring
 app _write_ to the cache maintained in Xen? Or else, who is
 "emulator" here? If that's the app, then I think subject and description
 for hypervisor patches would better be written taking the perspective
 of the hypervisor, especially when using potentially ambiguous terms.
>>>
>>> Well, I thought it was obvious that the built-in emulator in Xen is
>>> what this patch is referring to. Otherwise none of this makes sense.
>>
>> It would have been if the sentence didn't say "returning". The
>> internal emulator's cache gets effectively overwritten, not
>> returned to anything (unless I'm still misunderstanding something).
> 
> It's "returning" the i-cache in the sense that it's part of a vm_event 
> response.

Well, I can only express my desire for this to get expressed in a less
confusing way. Maybe it's just me ...

> @@ -1944,11 +1951,19 @@ void hvm_mem_access_emulate_one(enum emul_kind 
> kind, unsigned int trapnr,
>  case EMUL_KIND_NOWRITE:
>  rc = hvm_emulate_one_no_write();
>  break;
> -case EMUL_KIND_SET_CONTEXT:
> -ctx.set_context = 1;
> -/* Intentional fall-through. */
> -default:
> +case EMUL_KIND_SET_CONTEXT_DATA:
> +ctx.set_context_data = 1;
> +rc = hvm_emulate_one();
> +break;
> +case EMUL_KIND_SET_CONTEXT_INSN:
> +ctx.set_context_insn = 1;
>  rc = hvm_emulate_one();
> +break;
> +case EMUL_KIND_NORMAL:
> +rc = hvm_emulate_one();
> +break;
> +default:
> +return;

 Why don't you retain the previous default handling?
>>>
>>> The default label is unused and this makes it more apparent when
>>> reading the code.
>>
>> Just like before, imo there shouldn't be any EMUL_KIND_NORMAL
>> case; that should be the default label instead.
> 
> But there is EMUL_KIND_NORMAL case. All calls to this function must
> specify a pre-defined kind. There is no calling this function with
> non-defined kinds so the default label is really just
> EMUL_KIND_NORMAL. Why is it better to keep it under the default label
> then instead of explicitly showing that it's actually just that one
> case?

Because changing that aspect is not the subject of your patch.

And btw - blank lines between non-fall-through cases please.

Jan


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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Jan Beulich]

>>> On 15.09.16 at 17:28,  wrote:
> Something along the lines of this (attached as well to prevent line
> wrapping)

Looks reasonable with some polishing (GPL=y on the make lines and
using C_SRC-$(GPL) and CSRC-y).

> Maybe even without changes to mk_dsdt.c

But isn't that the critical part? And - what functionality do we lose
without that code? There's no point in generating something that's
of no practical use.

And then there's the question of whether excluding things from the
build, but having them present in the sources actually helps.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  3ab5fb9a9eeb2b610d5d74419e0b1ffaf18484f2
baseline version:
 xen  773522000cc17f6f4323a4d97423790138ea98f2

Last test of basis   100960  2016-09-15 02:00:42 Z0 days
Testing same since   100965  2016-09-15 09:14:21 Z0 days1 attempts


People who touched revisions under test:
  Julien Grall 
  Peng Fan 
  Peng Fan 
  Stefano Stabellini 

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

Re: [Xen-devel] per-domain logging

[Cedric Bosdonnat]

On Thu, 2016-09-15 at 16:11 +0100, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote:
> > 
> > CC Ian who might have some ideas on this.
> > 
> > On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> > > 
> > > Hi all,
> > > 
> > > I wanted to get libvirt's libxl driver have per-domain logs like all 
> > > other drivers. After
> > > looking at the libxl and XenToolLogger it seems I'll need to add the 
> > > feature in either libxl
> > > XenToolLogger. Would anyone already have an idea how best to add API to 
> > > allow this?
> > > 
> 
> Can you briefly describe how other drivers do per-domain logging?

For example, the qemu driver is storing all logging of domain X in 
/var/log/libvirt/qemu/X.log file.
So far all libxl logs are going to /var/log/libvirt/libxl/libxl-driver.log.

> Basically one libxl_ctx corresponds to one logger. I guess you don't
> want multiple libxl_ctx, right?

Indeed, we have on libxl_ctx for the driver, not one per domain.

> IIRC there is already logfile abstraction inside libvirt -- can you just
> pass in a libvirt logfile fd and try to demux there?

The abstraction we have is something similar to the XenToolLogger, not
something abstracting the log files. Even if we had that, how could we demux 
since there is
no domain name in the libxl messages.

--
Cedric

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

Re: [Xen-devel] [PATCH 6/6] docs: add HVM USB passthrough documentation

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:26AM +0200, Juergen Gross wrote:
> Update the man page regarding passthrough of USB devices to HVM
> domains via qemu USB emulation.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
> Add HVM usb passthrough support to libxl by using qemu's capability
> to emulate standard USB controllers.
> 
> A USB controller is added via qmp command to the emulated hardware
> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> the requested speed the appropriate hardware type is selected. A host
> USB device can then be added to the emulated USB controller via qmp
> command.
> 
> Removing of the devices is done via qmp commands, too.

Overall the code looks plausible. But the code seems to do more than
what is stated in commit message. Some comments below.

> 
> Signed-off-by: Juergen Gross 
> ---
>  tools/libxl/libxl_device.c |   3 +-
>  tools/libxl/libxl_usb.c| 417 
> +++--
>  tools/libxl/xl_cmdimpl.c   |   4 +-
>  3 files changed, 331 insertions(+), 93 deletions(-)
> 
> diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
> index 5211f20..c6f15db 100644
> --- a/tools/libxl/libxl_device.c
> +++ b/tools/libxl/libxl_device.c
> @@ -782,8 +782,7 @@ void libxl__devices_destroy(libxl__egc *egc, 
> libxl__devices_remove_state *drs)
>  aodev->action = LIBXL__DEVICE_ACTION_REMOVE;
>  aodev->dev = dev;
>  aodev->force = drs->force;
> -if (dev->backend_kind == LIBXL__DEVICE_KIND_VUSB ||
> -dev->backend_kind == LIBXL__DEVICE_KIND_QUSB)
> +if (dev->kind == LIBXL__DEVICE_KIND_VUSB)

This looks a bit suspicious to me. This could be rather obvious but I'm
not sure because I didn't follow closely on the overall design of PV /
HVM USB passthrough.

AIUI:

VUSB -> PV USB with in-kernel backend
QUSB -> PV USB with QEMU backend

Why is QUSB deleted here?

If there is refactoring involved, can that be separated out?

>  libxl__initiate_device_usbctrl_remove(egc, aodev);
>  else
>  libxl__initiate_device_generic_remove(egc, aodev);
> diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
> index 6b30e0f..40c5a84 100644
> --- a/tools/libxl/libxl_usb.c
> +++ b/tools/libxl/libxl_usb.c
> @@ -17,6 +17,7 @@
>  
>  #include "libxl_internal.h"
>  #include 
> +#include 
>  
>  #define USBBACK_INFO_PATH "/libxl/usbback"
>  
> @@ -43,12 +44,6 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
> uint32_t domid,
>  int rc;
>  libxl_domain_type domtype = libxl__domain_type(gc, domid);
>  
> -if (!usbctrl->version)
> -usbctrl->version = 2;
> -
> -if (!usbctrl->ports)
> -usbctrl->ports = 8;
> -
>  if (usbctrl->type == LIBXL_USBCTRL_TYPE_AUTO) {
>  if (domtype == LIBXL_DOMAIN_TYPE_PV) {
>  rc = usbback_is_loaded(gc);
> @@ -62,6 +57,67 @@ static int libxl__device_usbctrl_setdefault(libxl__gc *gc, 
> uint32_t domid,
>  }
>  }
>  
> +switch (usbctrl->type) {
> +case LIBXL_USBCTRL_TYPE_PV:
> +case LIBXL_USBCTRL_TYPE_QUSB:
> +if (!usbctrl->version)
> +usbctrl->version = 2;
> +if (usbctrl->version < 1 || usbctrl->version > 2) {
> +LOG(ERROR, "USB version for paravirtualized devices must be 1 or 
> 2");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +if (!usbctrl->ports)
> +usbctrl->ports = 8;
> +if (usbctrl->ports < 1 || usbctrl->ports > USBIF_MAX_PORTNR) {
> +LOG(ERROR, "Number of ports for USB controller is limited to %u",
> +USBIF_MAX_PORTNR);
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +break;
> +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> +if (!usbctrl->version)
> +usbctrl->version = 2;
> +switch (usbctrl->version) {
> +case 1:
> +/* uhci controller in qemu has fixed number of ports. */
> +if (usbctrl->ports && usbctrl->ports != 2) {
> +LOG(ERROR, "Number of ports for USB controller of version 1 
> is always 2");

Please wrap long line if possible.

> +rc = ERROR_INVAL;
> +goto out;
> +}
> +usbctrl->ports = 2;
> +break;
> +case 2:
> +/* ehci controller in qemu has fixed number of ports. */
> +if (usbctrl->ports && usbctrl->ports != 6) {
> +LOG(ERROR, "Number of ports for USB controller of version 2 
> is always 6");
> +rc = ERROR_INVAL;
> +goto out;
> +}
> +usbctrl->ports = 6;
> +break;
> +case 3:
> +if (!usbctrl->ports)
> +usbctrl->ports = 8;
> +/* xhci controller in qemu supports up to 15 ports. */
> +if (usbctrl->ports > 15) {
> +LOG(ERROR, "Number of ports for USB controller of version 3 
> is limited to 15");
> +rc = 

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/15/2016 10:21 AM, Jan Beulich wrote:
 On 15.09.16 at 16:07,  wrote:
>> On 09/15/2016 09:48 AM, Julien Grall wrote:
>>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
 One option could be to provide a 'gpl_all' (or some such) target in
 libacpi in addition to 'all' and that target will be careful about not
 including these small un-ACKed portions of the code.

 It will be ugly though.
>>>
>>> I agree that it is not nice, but it would help us to get this features
>>> (and the other ones that depend on it) in Xen 4.8. Otherwise we would
>>> have to wait another 6 months to get those features.
>>
>>
>> If Jan (who is/will be libacpi maintainer) agrees to this it can be
>> easily added.
> 
> I'd like to make this dependent on how ugly it ends up being.
> 
> Jan
> 

Something along the lines of this (attached as well to prevent line
wrapping)

Maybe even without changes to mk_dsdt.c

-boris


>From 15149f5d6ac15d7e7da650259dfcfaf4097b03ae Mon Sep 17 00:00:00 2001
From: Boris Ostrovsky 
Date: Thu, 15 Sep 2016 11:15:31 -0400
Subject: [PATCH] libacpi: Prevent GPL-only code from seeping into non-GPL
 binaries

Some code (specifically, introduced by commit 801d469ad ("[HVM] ACPI
support patch 3 of 4: ACPI _PRT table.")) has only been licensed by
GPLv2.1

We want to prevent this code from showing up in non-GPL binaries.

Signed-off-by: Boris Ostrovsky 
---
 tools/firmware/hvmloader/Makefile |  4 ++--
 tools/libacpi/Makefile|  9 ++---
 tools/libacpi/mk_dsdt.c   | 10 ++
 3 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/tools/firmware/hvmloader/Makefile
b/tools/firmware/hvmloader/Makefile
index 9fa9bcc..dc21cdf 100644
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -69,7 +69,7 @@ all: acpi subdirs-all

 .PHONY: acpi
 acpi:
-   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR)
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) GPL=true

 rombios.o: roms.inc
 smbios.o: CFLAGS += -D__SMBIOS_DATE__="\"$(SMBIOS_REL_DATE)\""
@@ -119,7 +119,7 @@ endif
 clean: subdirs-clean
rm -f roms.inc roms.inc.new acpi.h
rm -f hvmloader hvmloader.tmp *.o $(DEPS)
-   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) clean
+   $(MAKE) -C $(ACPI_PATH)  ACPI_BUILD_DIR=$(CURDIR) GPL=true clean

 .PHONY: distclean
 distclean: clean
diff --git a/tools/libacpi/Makefile b/tools/libacpi/Makefile
index 2d8a954..2fe14d4 100644
--- a/tools/libacpi/Makefile
+++ b/tools/libacpi/Makefile
@@ -18,7 +18,10 @@ include $(XEN_ROOT)/tools/firmware/Rules.mk
 MK_DSDT = $(ACPI_BUILD_DIR)/mk_dsdt

 # Sources to be generated
-C_SRC = $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c
dsdt_anycpu_qemu_xen.c dsdt_pvh.c)
+C_SRC = $(ACPI_BUILD_DIR)/dsdt_pvh.c
+ifeq ($(GPL),true)
+C_SRC += $(addprefix $(ACPI_BUILD_DIR)/, dsdt_anycpu.c dsdt_15cpu.c
dsdt_anycpu_qemu_xen.c)
+endif
 H_SRC = $(addprefix $(ACPI_BUILD_DIR)/, ssdt_s3.h ssdt_s4.h ssdt_pm.h
ssdt_tpm.h)

 ifeq ($(subst all,,$(MAKECMDGOALS)),)
@@ -39,14 +42,14 @@ $(MK_DSDT): mk_dsdt.c
 $(ACPI_BUILD_DIR)/dsdt_anycpu_qemu_xen.asl: dsdt.asl dsdt_acpi_info.asl
$(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $(TDIR)/$(@F)
cat dsdt_acpi_info.asl >> $(TDIR)/$(@F)
-   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen >> $(TDIR)/$(@F)
+   $(MK_DSDT) --debug=$(debug) --dm-version qemu-xen --gpl >> $(TDIR)/$(@F)
cp $(TDIR)/$(@F) $@

 # NB. awk invocation is a portable alternative to 'head -n -1'
 $(ACPI_BUILD_DIR)/dsdt_%cpu.asl: dsdt.asl dsdt_acpi_info.asl $(MK_DSDT)
awk 'NR > 1 {print s} {s=$$0}' $< > $(TDIR)/$(@F)
cat dsdt_acpi_info.asl >> $(TDIR)/$(@F)
-   $(MK_DSDT) --debug=$(debug) --maxcpu $*  >> $(TDIR)/$(@F)
+   $(MK_DSDT) --debug=$(debug) --maxcpu $* --gpl >> $(TDIR)/$(@F)
cp $(TDIR)/$(@F) $@

 $(ACPI_BUILD_DIR)/dsdt_pvh.asl: dsdt_acpi_info.asl $(MK_DSDT)
diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 30477fd..c79e95f 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -99,6 +99,7 @@ static struct option options[] = {
 { "maxcpu", 1, 0, 'c' },
 { "dm-version", 1, 0, 'q' },
 { "debug", 1, 0, 'd' },
+{ "gpl", 0,0,'g' },
 { 0, 0, 0, 0 }
 };

@@ -106,6 +107,7 @@ int main(int argc, char **argv)
 {
 unsigned int slot, dev, intx, link, cpu, max_cpus = HVM_MAX_VCPUS;
 dm_version dm_version = QEMU_XEN_TRADITIONAL;
+bool gpl = false;

 for ( ; ; )
 {
@@ -147,6 +149,9 @@ int main(int argc, char **argv)
 if (*optarg == 'y')
 debug = true;
 break;
+case 'g':
+gpl = true;
+break;
 default:
 return -1;
 }
@@ -293,6 +298,9 @@ int main(int argc, char **argv)
 }
 } pop_block();

+if (!gpl)
+goto cont; // Should be "if (gpl) {...}", 'goto' is 

Re: [Xen-devel] [PATCH 2/2] x86/vm_event: Allow returning i-cache for emulation

[Tamas K Lengyel]

On Wed, Sep 14, 2016 at 11:58 PM, Jan Beulich  wrote:
 On 14.09.16 at 18:20,  wrote:
>> On Wed, Sep 14, 2016 at 9:55 AM, Jan Beulich  wrote:
>> On 13.09.16 at 20:12,  wrote:
 When emulating instructions the emulator maintains a small i-cache fetched
 from the guest memory. This patch extends the vm_event interface to allow
 returning this i-cache via the vm_event response instead.
>>>
>>> I guess I'm sightly confused: Isn't the purpose to have the monitoring
>>> app _write_ to the cache maintained in Xen? Or else, who is
>>> "emulator" here? If that's the app, then I think subject and description
>>> for hypervisor patches would better be written taking the perspective
>>> of the hypervisor, especially when using potentially ambiguous terms.
>>
>> Well, I thought it was obvious that the built-in emulator in Xen is
>> what this patch is referring to. Otherwise none of this makes sense.
>
> It would have been if the sentence didn't say "returning". The
> internal emulator's cache gets effectively overwritten, not
> returned to anything (unless I'm still misunderstanding something).

It's "returning" the i-cache in the sense that it's part of a vm_event response.

>
 @@ -1944,11 +1951,19 @@ void hvm_mem_access_emulate_one(enum emul_kind 
 kind, unsigned int trapnr,
  case EMUL_KIND_NOWRITE:
  rc = hvm_emulate_one_no_write();
  break;
 -case EMUL_KIND_SET_CONTEXT:
 -ctx.set_context = 1;
 -/* Intentional fall-through. */
 -default:
 +case EMUL_KIND_SET_CONTEXT_DATA:
 +ctx.set_context_data = 1;
 +rc = hvm_emulate_one();
 +break;
 +case EMUL_KIND_SET_CONTEXT_INSN:
 +ctx.set_context_insn = 1;
  rc = hvm_emulate_one();
 +break;
 +case EMUL_KIND_NORMAL:
 +rc = hvm_emulate_one();
 +break;
>>>
>>> One of the former two surely can be made fall through into the latter?
>>
>> That's what I did before by turning this into if-else's and you
>> requested to go back to a switch. With a switch though I'll rather
>> make the cases explicit as a fall-through just makes it harder to read
>> for no real benefit.
>
> I disagree.

OK, I don't really care about it too much so if you feel that strongly
about it then fine.

>
 +default:
 +return;
>>>
>>> Why don't you retain the previous default handling?
>>
>> The default label is unused and this makes it more apparent when
>> reading the code.
>
> Just like before, imo there shouldn't be any EMUL_KIND_NORMAL
> case; that should be the default label instead.

But there is EMUL_KIND_NORMAL case. All calls to this function must
specify a pre-defined kind. There is no calling this function with
non-defined kinds so the default label is really just
EMUL_KIND_NORMAL. Why is it better to keep it under the default label
then instead of explicitly showing that it's actually just that one
case?

>
 @@ -265,6 +272,10 @@ struct vm_event_emul_read_data {
  uint8_t  data[sizeof(struct vm_event_regs_x86) - sizeof(uint32_t)];
  };

 +struct vm_event_emul_insn_data {
 +uint8_t data[16]; /* Has to be completely filled */
 +};
>>>
>>> Any reason for the 16 (rather than the architectural 15) here?
>>
>> Yes, see the definition in include/asm-x86/hvm/emulate.h:
>>
>> struct hvm_emulate_ctxt {
>> struct x86_emulate_ctxt ctxt;
>>
>> /* Cache of 16 bytes of instruction. */
>> uint8_t insn_buf[16];
>
> Ah, I didn't recall we have an oversized cache there too. But such a
> connection would better be documented by a BUILD_BUG_ON()
> comparing the two sizeof()s.

Sure.

Thanks,
Tamas

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

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

[osstest service owner]

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

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  115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
baseline version:
 xen  c496f489f02515b8f687dc4effe259180a49a279

Last test of basis   100967  2016-09-15 11:01:46 Z0 days
Testing same since   100968  2016-09-15 13:02:22 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 

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=115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
+ . ./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 
115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
+ branch=xen-unstable-smoke
+ revision=115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8
+ . ./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
+ '[' x115e4c5e52c14c126cd8ae0dfe0322c95b65e3c8 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH 4/6] libxl: add basic support for devices without backend

[Wei Liu]

On Thu, Sep 08, 2016 at 09:20:24AM +0200, Juergen Gross wrote:
> With the planned support of HVM USB passthrough via the USB emulation
> capabilities of qemu libxl has to support guest devices which have no
> back- and frontend. Information about those devices will live in the
> libxl part of Xenstore only.
> 
> Add some basic support to libxl to be able to cope with this scenario.
> 
> Signed-off-by: Juergen Gross 

Code-wise, this patch looks good:

Acked-by: Wei Liu 


>  /*
>   * We make a copy of everything for the backend in the libxl
> @@ -194,6 +205,9 @@ retry_transaction:
>   * instead.  But there are still places in libxl that try to
>   * reconstruct a config from xenstore.
>   *
> + * For devices without backend (e.g. USB devices emulated via qemu)
> + * only the libxl path is written.
> + *

Without PV backend.

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

[Xen-devel] [PATCH v2] xen-netback: fix error handling on netback_probe()

[Filipe Manco]

In case of error during netback_probe() (e.g. an entry missing on the
xenstore) netback_remove() is called on the new device, which will set
the device backend state to XenbusStateClosed by calling
set_backend_state(). However, the backend state wasn't initialized by
netback_probe() at this point, which will cause and invalid transaction
and set_backend_state() to BUG().

Initialize the backend state at the beginning of netback_probe() to
XenbusStateInitialising, and create two new valid state transitions on
set_backend_state(), from XenbusStateInitialising to XenbusStateClosed,
and from XenbusStateInitialising to XenbusStateInitWait.

Signed-off-by: Filipe Manco 
---
 drivers/net/xen-netback/xenbus.c | 46 ++--
 1 file changed, 30 insertions(+), 16 deletions(-)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6a31f2610c23..daf4c7867102 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -271,6 +271,11 @@ static int netback_probe(struct xenbus_device *dev,
be->dev = dev;
dev_set_drvdata(>dev, be);
 
+   be->state = XenbusStateInitialising;
+   err = xenbus_switch_state(dev, XenbusStateInitialising);
+   if (err)
+   goto fail;
+
sg = 1;
 
do {
@@ -383,11 +388,6 @@ static int netback_probe(struct xenbus_device *dev,
 
be->hotplug_script = script;
 
-   err = xenbus_switch_state(dev, XenbusStateInitWait);
-   if (err)
-   goto fail;
-
-   be->state = XenbusStateInitWait;
 
/* This kicks hotplug scripts, so do it immediately. */
err = backend_create_xenvif(be);
@@ -492,20 +492,20 @@ static inline void backend_switch_state(struct 
backend_info *be,
 
 /* Handle backend state transitions:
  *
- * The backend state starts in InitWait and the following transitions are
+ * The backend state starts in Initialising and the following transitions are
  * allowed.
  *
- * InitWait -> Connected
- *
- *^\ |
- *| \|
- *|  \   |
- *|   \  |
- *|\ |
- *| \|
- *|  V   V
+ * Initialising -> InitWait -> Connected
+ *  \
+ *   \^\ |
+ *\   | \|
+ * \  |  \   |
+ *  \ |   \  |
+ *   \|\ |
+ *\   | \|
+ * V  |  V   V
  *
- *  Closed  <-> Closing
+ *  Closed  <-> Closing
  *
  * The state argument specifies the eventual state of the backend and the
  * function transitions to that state via the shortest path.
@@ -515,6 +515,20 @@ static void set_backend_state(struct backend_info *be,
 {
while (be->state != state) {
switch (be->state) {
+   case XenbusStateInitialising:
+   switch (state) {
+   case XenbusStateInitWait:
+   case XenbusStateConnected:
+   case XenbusStateClosing:
+   backend_switch_state(be, XenbusStateInitWait);
+   break;
+   case XenbusStateClosed:
+   backend_switch_state(be, XenbusStateClosed);
+   break;
+   default:
+   BUG();
+   }
+   break;
case XenbusStateClosed:
switch (state) {
case XenbusStateInitWait:
-- 
2.7.4


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

Re: [Xen-devel] per-domain logging

[Wei Liu]

On Thu, Sep 15, 2016 at 03:50:25PM +0100, Wei Liu wrote:
> CC Ian who might have some ideas on this.
> 
> On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> > Hi all,
> > 
> > I wanted to get libvirt's libxl driver have per-domain logs like all other 
> > drivers. After
> > looking at the libxl and XenToolLogger it seems I'll need to add the 
> > feature in either libxl
> > XenToolLogger. Would anyone already have an idea how best to add API to 
> > allow this?
> > 

Can you briefly describe how other drivers do per-domain logging?

Basically one libxl_ctx corresponds to one logger. I guess you don't
want multiple libxl_ctx, right?

IIRC there is already logfile abstraction inside libvirt -- can you just
pass in a libvirt logfile fd and try to demux there?

Wei.

> > Thanks for your help
> > --
> > Cedric
> > 
> > ___
> > 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] per-domain logging

[Wei Liu]

CC Ian who might have some ideas on this.

On Wed, Sep 14, 2016 at 04:22:24PM +0200, Cedric Bosdonnat wrote:
> Hi all,
> 
> I wanted to get libvirt's libxl driver have per-domain logs like all other 
> drivers. After
> looking at the libxl and XenToolLogger it seems I'll need to add the feature 
> in either libxl
> XenToolLogger. Would anyone already have an idea how best to add API to allow 
> this?
> 
> Thanks for your help
> --
> Cedric
> 
> ___
> 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] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Jan Beulich]

>>> On 15.09.16 at 16:16,  wrote:
> On 9/13/2016 11:25 PM, Jan Beulich wrote:
>> Wait - what is do_invalid_op() doing on the stack? I don't think it
>> belongs there, and hence I wonder whether the keypress
>> happened after some already fatal event (in which case all bets
>> are off anyway).
> 
> Not clear why do_invalid_op() on the stack. There is no other fatal
> event. The issue disappears when set watchdog_timeout to 10s.
> 
>>> > Another solution is to schedule a tasklet to run keyhandler in timer
>>> > handler and invoke process_pending_softirqs() in the dump_timerq().
>>> > This also works but it requires to rework keyhandler mechanism.
>>> >
>>> > Disable watchdog seems to be simpler and I found dump_registers() also
>>> > used the same way to deal with the issue.
>> That's true. Just that on large machines it defaults to the
>> alternative model, for which I'm not sure it actually needs the
>> watchdog disabled (as data for a single CPU shouldn't exceed
>> the threshold).
>>
> 
> It seems not to be necessary to disable watchdog in alternative model
> since dumping a single cpu's status will not last a long time.
> 
> 
> For the issue in the dump timer info handler, disabling watchdog is ok
> for you or you have other suggestions to resolve the issue?

Well, without a clear understanding of why the issue occurs (for
which I need to refer you back to the questionable stack dump)
I'm hesitant to agree to this step, yet ...

> I also found other places where dump a lot of logs disable watchdog.
> (E,G run_all_keyhandlers(), debugtrace_dump() debugtrace_toggle() and so
> on). This seems a common solution.

... I'm also not entirely against it considering the various other
examples. I.e. as almost always: As long as the need for the
change can be properly explained, I won't stand in the way of
getting it in.

Jan


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

Re: [Xen-devel] [PATCH 5/6] libxl: add HVM usb passthrough support

[Wei Liu]

On Fri, Sep 09, 2016 at 12:13:46PM +0200, Juergen Gross wrote:
> On 09/09/16 12:00, Wei Liu wrote:
> > On Thu, Sep 08, 2016 at 09:20:25AM +0200, Juergen Gross wrote:
> >> Add HVM usb passthrough support to libxl by using qemu's capability
> >> to emulate standard USB controllers.
> >>
> >> A USB controller is added via qmp command to the emulated hardware
> >> when a usbctrl device of type DEVICEMODEL is requested. Depending on
> >> the requested speed the appropriate hardware type is selected. A host
> >> USB device can then be added to the emulated USB controller via qmp
> >> command.
> >>
> >> Removing of the devices is done via qmp commands, too.
> >>
> >> Signed-off-by: Juergen Gross 
> > [...]
> >>  
> >> @@ -75,9 +131,19 @@ static int libxl__device_from_usbctrl(libxl__gc *gc, 
> >> uint32_t domid,
> >>  {
> >>  device->backend_devid   = usbctrl->devid;
> >>  device->backend_domid   = usbctrl->backend_domid;
> >> -device->backend_kind= (usbctrl->type == LIBXL_USBCTRL_TYPE_PV)
> >> -  ? LIBXL__DEVICE_KIND_VUSB
> >> -  : LIBXL__DEVICE_KIND_QUSB;
> >> +switch (usbctrl->type) {
> >> +case LIBXL_USBCTRL_TYPE_PV:
> >> +device->backend_kind = LIBXL__DEVICE_KIND_VUSB;
> >> +break;
> >> +case LIBXL_USBCTRL_TYPE_QUSB:
> >> +device->backend_kind = LIBXL__DEVICE_KIND_QUSB;
> >> +break;
> >> +case LIBXL_USBCTRL_TYPE_DEVICEMODEL:
> >> +device->backend_kind = LIBXL__DEVICE_KIND_NONE;
> > 
> > I'm not quite sure if I follow this. Shouldn't we need a new kind of
> > backend for this?
> 
> Depends on what do you call a backend.
> 
> I'd say a backend is something which corresponds to a frontend in the
> guest. As long as you don't want to call a normal hardware driver a
> "frontend" we don't need a backend.
> 
> At least the "backend" (qemu, requiring no update for this) won't use
> Xenstore for detecting addition/removal of devices: all is done via
> explicit qmp commands issued from libxl to qemu.
> 

After having a closer look, this is internal detail of libxl so I don't
think I care that much.

I will review this patch in detail later.

Wei.

> 
> Juergen

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Lan, Tianyu]

Hi Andrew:
Sorry to bother you. To make sure we are on the right direction, it's
better to get feedback from you before we go further step. Could you
have a look? Thanks.

On 8/17/2016 8:05 PM, Lan, Tianyu wrote:

Hi All:
 The following is our Xen vIOMMU high level design for detail
discussion. Please have a look. Very appreciate for your comments.
This design doesn't cover changes when root port is moved to hypervisor.
We may design it later.


Content:
===

1. Motivation of vIOMMU
1.1 Enable more than 255 vcpus
1.2 Support VFIO-based user space driver
1.3 Support guest Shared Virtual Memory (SVM)
2. Xen vIOMMU Architecture
2.1 2th level translation overview
2.2 Interrupt remapping overview
3. Xen hypervisor
3.1 New vIOMMU hypercall interface
3.2 2nd level translation
3.3 Interrupt remapping
3.4 1st level translation
3.5 Implementation consideration
4. Qemu
4.1 Qemu vIOMMU framework
4.2 Dummy xen-vIOMMU driver
4.3 Q35 vs. i440x
4.4 Report vIOMMU to hvmloader


1 Motivation for Xen vIOMMU
===

1.1 Enable more than 255 vcpu support
HPC virtualization requires more than 255 vcpus support in a single VM
to meet parallel computing requirement. More than 255 vcpus support
requires interrupt remapping capability present on vIOMMU to deliver
interrupt to #vcpu >255 Otherwise Linux guest fails to boot up with >255
vcpus if interrupt remapping is absent.


1.2 Support VFIO-based user space driver (e.g. DPDK) in the guest
It relies on the 2nd level translation capability (IOVA->GPA) on
vIOMMU. pIOMMU 2nd level becomes a shadowing structure of
vIOMMU to isolate DMA requests initiated by user space driver.


1.3 Support guest SVM (Shared Virtual Memory)
It relies on the 1st level translation table capability (GVA->GPA) on
vIOMMU. pIOMMU needs to enable both 1st level and 2nd level translation
in nested mode (GVA->GPA->HPA) for passthrough device. IGD passthrough
is the main usage today (to support OpenCL 2.0 SVM feature). In the
future SVM might be used by other I/O devices too.

2. Xen vIOMMU Architecture



* vIOMMU will be inside Xen hypervisor for following factors
1) Avoid round trips between Qemu and Xen hypervisor
2) Ease of integration with the rest of the hypervisor
3) HVMlite/PVH doesn't use Qemu
* Dummy xen-vIOMMU in Qemu as a wrapper of new hypercall to create
/destory vIOMMU in hypervisor and deal with virtual PCI device's 2th
level translation.

2.1 2th level translation overview
For Virtual PCI device, dummy xen-vIOMMU does translation in the
Qemu via new hypercall.

For physical PCI device, vIOMMU in hypervisor shadows IO page table from
IOVA->GPA to IOVA->HPA and load page table to physical IOMMU.

The following diagram shows 2th level translation architecture.
+-+
|Qemu++   |
|| Virtual|   |
||   PCI device   |   |
|||   |
|++   |
||DMA |
|V|
|  ++   Request  ++   |
|  |+<---+|   |
|  |  Dummy xen vIOMMU  | Target GPA |  Memory region |   |
|  |+--->+|   |
|  +-+--++---++   |
||   ||
||Hypercall  ||
+++
|Hypervisor  |   ||
||   ||
|v   ||
| +--+--+||
| |   vIOMMU|||
| +--+--+||
||   ||
|v   ||
| +--+--+||
| | IOMMU driver|||
| +--+--+||
||   ||
+++
|HW  v   V|
| +--+--+ +-+ |
| |   IOMMU +>+  Memory | |
| +--+--+ +-+ 

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Jan Beulich]

>>> On 15.09.16 at 16:07,  wrote:
> On 09/15/2016 09:48 AM, Julien Grall wrote:
>> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>>> One option could be to provide a 'gpl_all' (or some such) target in
>>> libacpi in addition to 'all' and that target will be careful about not
>>> including these small un-ACKed portions of the code.
>>>
>>> It will be ugly though.
>>
>> I agree that it is not nice, but it would help us to get this features
>> (and the other ones that depend on it) in Xen 4.8. Otherwise we would
>> have to wait another 6 months to get those features.
> 
> 
> If Jan (who is/will be libacpi maintainer) agrees to this it can be
> easily added.

I'd like to make this dependent on how ugly it ends up being.

Jan


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

Re: [Xen-devel] [PATCH] Xen/timer: Disable watchdog during dumping timer queues

[Lan, Tianyu]

On 9/13/2016 11:25 PM, Jan Beulich wrote:

Wait - what is do_invalid_op() doing on the stack? I don't think it
belongs there, and hence I wonder whether the keypress
happened after some already fatal event (in which case all bets
are off anyway).


Not clear why do_invalid_op() on the stack. There is no other fatal
event. The issue disappears when set watchdog_timeout to 10s.


> Another solution is to schedule a tasklet to run keyhandler in timer
> handler and invoke process_pending_softirqs() in the dump_timerq().
> This also works but it requires to rework keyhandler mechanism.
>
> Disable watchdog seems to be simpler and I found dump_registers() also
> used the same way to deal with the issue.

That's true. Just that on large machines it defaults to the
alternative model, for which I'm not sure it actually needs the
watchdog disabled (as data for a single CPU shouldn't exceed
the threshold).



It seems not to be necessary to disable watchdog in alternative model
since dumping a single cpu's status will not last a long time.


For the issue in the dump timer info handler, disabling watchdog is ok
for you or you have other suggestions to resolve the issue?

I also found other places where dump a lot of logs disable watchdog.
(E,G run_all_keyhandlers(), debugtrace_dump() debugtrace_toggle() and so
on). This seems a common solution.







Jan


> Here is my draft patch of reworking keyhandler.


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

Re: [Xen-devel] [RFC PATCH] xen-netback: fix error handling on netback_probe()

[Wei Liu]

On Thu, Sep 15, 2016 at 04:05:17PM +0200, Filipe Manco wrote:
> On 14-09-2016 12:10, Wei Liu wrote:
> >CC xen-devel as well.
> >
> >On Tue, Sep 13, 2016 at 02:11:27PM +0200, Filipe Manco wrote:
> >>In case of error during netback_probe() (e.g. an entry missing on the
> >>xenstore) netback_remove() is called on the new device, which will set
> >>the device backend state to XenbusStateClosed by calling
> >>set_backend_state(). However, the backend state wasn't initialized by
> >>netback_probe() at this point, which will cause and invalid transaction
> >>and set_backend_state() to BUG().
> >>
> >>Initialize the backend state at the beginning of netback_probe() to
> >>XenbusStateInitialising, and create a new valid state transaction on
> >>set_backend_state(), from XenbusStateInitialising to XenbusStateClosed.
> >>
> >>Signed-off-by: Filipe Manco 
> >There is a state machine right before set_backend_state. You would also
> >need to update that.
> Good point I'll update the diagram.
> 
> After looking at the diagram and for consistency, shouldn't the transition
> Initialising -> InitWait be handled using set_backend_state()? Currently it
> is done directly in netback_probe() code. If you agree I'll submit a v2 with
> these two changes.

That's fine with me.

Wei.

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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/15/2016 09:48 AM, Julien Grall wrote:
> Hi Boris,
>
> On 15/09/2016 13:39, Boris Ostrovsky wrote:
>> On 09/15/2016 06:22 AM, Wei Liu wrote:
>>> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
 Hi Wei,

 On 15/09/2016 11:18, Wei Liu wrote:
> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:
>> On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
>>> The goal here is to build ACPI tables for PVHv2/HVMlite guests
>>> while reusing existing
>>> hvmloader's ACPI builder code. The builder is provided as a
>>> library in tools/libacpi.
>>>
>>> This is version 3 of the series, see individual patches for
>>> changes. It can
>>> be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3
>> Wei, Ian --- are there any comments from the toolstack perspective?
>>
>>> The series is probably still gated by lack of an ACK from Lenovo
>>> for the
>>> relicensing patch (included here as patch 1).
>>>
>> So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
>> (which is the patch from Lenovo) and it only does 2 things
>> (assuming I
>> parsed ASL correctly):
>> * Adds _PIC method
>> * Controls and describes legacy PCI interrupt routing. This
>> functionality has actually been moved into mk_dsdt.c and so this ASL
>> code is now generated.
>>
>> Neither of these two things is used by libxl so technically we
>> may not
>> need the ACK from Lenovo. OTOH, we may forget about this
>> restriction in
>> the future and accidentally include those two later.
>>
> This is a risk I would rather not take. As you said, we may forget
> about
> the restriction in the future.
 Does it mean this series may not be in Xen 4.8? If so, this will
 also delay
 other series such as the ACPI guest support for ARM.

>>> I would like to see this and the subsequent ARM series in 4.8 -- it is
>>> still possible we get an ack from Lenovo any time, but the issue is out
>>> of our control at the moment. It's just one unfortunate incident in
>>> open
>>> source software development. Sigh.
>>
>> One option could be to provide a 'gpl_all' (or some such) target in
>> libacpi in addition to 'all' and that target will be careful about not
>> including these small un-ACKed portions of the code.
>>
>> It will be ugly though.
>
> I agree that it is not nice, but it would help us to get this features
> (and the other ones that depend on it) in Xen 4.8. Otherwise we would
> have to wait another 6 months to get those features.


If Jan (who is/will be libacpi maintainer) agrees to this it can be
easily added.

-boris


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

Re: [Xen-devel] [RFC PATCH] xen-netback: fix error handling on netback_probe()

[Filipe Manco]

On 14-09-2016 12:10, Wei Liu wrote:

CC xen-devel as well.

On Tue, Sep 13, 2016 at 02:11:27PM +0200, Filipe Manco wrote:

In case of error during netback_probe() (e.g. an entry missing on the
xenstore) netback_remove() is called on the new device, which will set
the device backend state to XenbusStateClosed by calling
set_backend_state(). However, the backend state wasn't initialized by
netback_probe() at this point, which will cause and invalid transaction
and set_backend_state() to BUG().

Initialize the backend state at the beginning of netback_probe() to
XenbusStateInitialising, and create a new valid state transaction on
set_backend_state(), from XenbusStateInitialising to XenbusStateClosed.

Signed-off-by: Filipe Manco 

There is a state machine right before set_backend_state. You would also
need to update that.

Good point I'll update the diagram.

After looking at the diagram and for consistency, shouldn't the transition
Initialising -> InitWait be handled using set_backend_state()? Currently it
is done directly in netback_probe() code. If you agree I'll submit a v2 with
these two changes.

According to the definition of XenbusStateInitialising, this patch looks
plausible to me.

Wei.


Filipe

---
  drivers/net/xen-netback/xenbus.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6a31f2610c23..c0e5f6994d01 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -270,6 +270,7 @@ static int netback_probe(struct xenbus_device *dev,
  
  	be->dev = dev;

dev_set_drvdata(>dev, be);
+   be->state = XenbusStateInitialising;
  
  	sg = 1;
  
@@ -515,6 +516,15 @@ static void set_backend_state(struct backend_info *be,

  {
while (be->state != state) {
switch (be->state) {
+   case XenbusStateInitialising:
+   switch (state) {
+   case XenbusStateClosed:
+   backend_switch_state(be, XenbusStateClosed);
+   break;
+   default:
+   BUG();
+   }
+   break;
case XenbusStateClosed:
switch (state) {
case XenbusStateInitWait:
--
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] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/15/2016 04:55 PM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote:
>> On 09/15/2016 04:49 PM, Wei Liu wrote:
>>> On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
 On 09/07/2016 07:01 PM, Jan Beulich wrote:
 On 07.09.16 at 11:12,  wrote:
>> Currently it is only possible to set mem_access restrictions only for
>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>> This patch introduces a new libxc function taking an array of GFNs.
>> The alternative would be to set each page in turn, using a userspace-HV
>> roundtrip for each call, and triggering a TLB flush per page set.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Acked-by: Wei Liu 
>
> Hypervisor parts (without ARM and x86/mm)
> Acked-by: Jan Beulich 
>
> albeit I spotted one more cosmetic issue (which I guess could be
> fixed up during commit, if no other reason for a v5 arises):
>
>> @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>  }
>>  
>>  case XENMEM_access_op:
>> -return mem_access_memop(cmd,
>> -guest_handle_cast(compat,
>> -  
>> xen_mem_access_op_t));
>> +{
>> +if ( copy_from_guest(, compat, 1) )
>> +return -EFAULT;
>> +
>> +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
>> +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
>> +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
>> +guest_from_compat_handle((_d_)->access_list, 
>> (_s_)->access_list)
>> +
>> +XLAT_mem_access_op(nat.mao, );
>> +
>> +#undef XLAT_mem_access_op_HNDL_pfn_list
>> +#undef XLAT_mem_access_op_HNDL_access_list
>> +
>> +break;
>> +}
>
> There are no local variables declared here, so I don't see the need
> for the braces.

 There have only been Acked-by replies so far, but if you'd prefer I have
 no problem sending a V5 removing the braces.

>>>
>>> Does this patch have all the necessary acks? If so I don't mind fixing
>>> it up and committing it.
>>
>> In addition to your ack, it's:
>>
>> Acked-by: Jan Beulich 
>> Acked-by: Tamas K Lengyel 
>> Acked-by: Julien Grall 
>>
>> for the hypervisor parts (without ARM and x86/mm), vm_event and ARM
>> respectively.
>>
> 
> I think it still needs an ack from George for x86/mm changes.

Fair enough.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Wei Liu]

On Thu, Sep 15, 2016 at 04:52:32PM +0300, Razvan Cojocaru wrote:
> On 09/15/2016 04:49 PM, Wei Liu wrote:
> > On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
> >> On 09/07/2016 07:01 PM, Jan Beulich wrote:
> >> On 07.09.16 at 11:12,  wrote:
>  Currently it is only possible to set mem_access restrictions only for
>  a contiguous range of GFNs (or, as a particular case, for a single GFN).
>  This patch introduces a new libxc function taking an array of GFNs.
>  The alternative would be to set each page in turn, using a userspace-HV
>  roundtrip for each call, and triggering a TLB flush per page set.
> 
>  Signed-off-by: Razvan Cojocaru 
>  Acked-by: Wei Liu 
> >>>
> >>> Hypervisor parts (without ARM and x86/mm)
> >>> Acked-by: Jan Beulich 
> >>>
> >>> albeit I spotted one more cosmetic issue (which I guess could be
> >>> fixed up during commit, if no other reason for a v5 arises):
> >>>
>  @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
>  XEN_GUEST_HANDLE_PARAM(void) compat)
>   }
>   
>   case XENMEM_access_op:
>  -return mem_access_memop(cmd,
>  -guest_handle_cast(compat,
>  -  
>  xen_mem_access_op_t));
>  +{
>  +if ( copy_from_guest(, compat, 1) )
>  +return -EFAULT;
>  +
>  +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
>  +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
>  +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
>  +guest_from_compat_handle((_d_)->access_list, 
>  (_s_)->access_list)
>  +
>  +XLAT_mem_access_op(nat.mao, );
>  +
>  +#undef XLAT_mem_access_op_HNDL_pfn_list
>  +#undef XLAT_mem_access_op_HNDL_access_list
>  +
>  +break;
>  +}
> >>>
> >>> There are no local variables declared here, so I don't see the need
> >>> for the braces.
> >>
> >> There have only been Acked-by replies so far, but if you'd prefer I have
> >> no problem sending a V5 removing the braces.
> >>
> > 
> > Does this patch have all the necessary acks? If so I don't mind fixing
> > it up and committing it.
> 
> In addition to your ack, it's:
> 
> Acked-by: Jan Beulich 
> Acked-by: Tamas K Lengyel 
> Acked-by: Julien Grall 
> 
> for the hypervisor parts (without ARM and x86/mm), vm_event and ARM
> respectively.
> 

I think it still needs an ack from George for x86/mm changes.

Wei.

> 
> Thanks,
> Razvan

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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/15/2016 04:49 PM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
>> On 09/07/2016 07:01 PM, Jan Beulich wrote:
>> On 07.09.16 at 11:12,  wrote:
 Currently it is only possible to set mem_access restrictions only for
 a contiguous range of GFNs (or, as a particular case, for a single GFN).
 This patch introduces a new libxc function taking an array of GFNs.
 The alternative would be to set each page in turn, using a userspace-HV
 roundtrip for each call, and triggering a TLB flush per page set.

 Signed-off-by: Razvan Cojocaru 
 Acked-by: Wei Liu 
>>>
>>> Hypervisor parts (without ARM and x86/mm)
>>> Acked-by: Jan Beulich 
>>>
>>> albeit I spotted one more cosmetic issue (which I guess could be
>>> fixed up during commit, if no other reason for a v5 arises):
>>>
 @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
 XEN_GUEST_HANDLE_PARAM(void) compat)
  }
  
  case XENMEM_access_op:
 -return mem_access_memop(cmd,
 -guest_handle_cast(compat,
 -  
 xen_mem_access_op_t));
 +{
 +if ( copy_from_guest(, compat, 1) )
 +return -EFAULT;
 +
 +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
 +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
 +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
 +guest_from_compat_handle((_d_)->access_list, 
 (_s_)->access_list)
 +
 +XLAT_mem_access_op(nat.mao, );
 +
 +#undef XLAT_mem_access_op_HNDL_pfn_list
 +#undef XLAT_mem_access_op_HNDL_access_list
 +
 +break;
 +}
>>>
>>> There are no local variables declared here, so I don't see the need
>>> for the braces.
>>
>> There have only been Acked-by replies so far, but if you'd prefer I have
>> no problem sending a V5 removing the braces.
>>
> 
> Does this patch have all the necessary acks? If so I don't mind fixing
> it up and committing it.

In addition to your ack, it's:

Acked-by: Jan Beulich 
Acked-by: Tamas K Lengyel 
Acked-by: Julien Grall 

for the hypervisor parts (without ARM and x86/mm), vm_event and ARM
respectively.


Thanks,
Razvan

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

Re: [Xen-devel] [for-4.8][PATCH v2 22/23] xen/arm: p2m: Do not handle shattering in p2m_create_table

[Julien Grall]

Hi,

On 15/09/2016 12:28, Julien Grall wrote:

The helper p2m_create_table is only called to create a brand new table.

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


I made 2 typoes here. It should be:

Reviewed-by: Stefano Stabellini 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Wei Liu]

On Thu, Sep 15, 2016 at 04:39:47PM +0300, Razvan Cojocaru wrote:
> On 09/07/2016 07:01 PM, Jan Beulich wrote:
>  On 07.09.16 at 11:12,  wrote:
> >> Currently it is only possible to set mem_access restrictions only for
> >> a contiguous range of GFNs (or, as a particular case, for a single GFN).
> >> This patch introduces a new libxc function taking an array of GFNs.
> >> The alternative would be to set each page in turn, using a userspace-HV
> >> roundtrip for each call, and triggering a TLB flush per page set.
> >>
> >> Signed-off-by: Razvan Cojocaru 
> >> Acked-by: Wei Liu 
> > 
> > Hypervisor parts (without ARM and x86/mm)
> > Acked-by: Jan Beulich 
> > 
> > albeit I spotted one more cosmetic issue (which I guess could be
> > fixed up during commit, if no other reason for a v5 arises):
> > 
> >> @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
> >> XEN_GUEST_HANDLE_PARAM(void) compat)
> >>  }
> >>  
> >>  case XENMEM_access_op:
> >> -return mem_access_memop(cmd,
> >> -guest_handle_cast(compat,
> >> -  
> >> xen_mem_access_op_t));
> >> +{
> >> +if ( copy_from_guest(, compat, 1) )
> >> +return -EFAULT;
> >> +
> >> +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
> >> +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
> >> +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
> >> +guest_from_compat_handle((_d_)->access_list, 
> >> (_s_)->access_list)
> >> +
> >> +XLAT_mem_access_op(nat.mao, );
> >> +
> >> +#undef XLAT_mem_access_op_HNDL_pfn_list
> >> +#undef XLAT_mem_access_op_HNDL_access_list
> >> +
> >> +break;
> >> +}
> > 
> > There are no local variables declared here, so I don't see the need
> > for the braces.
> 
> There have only been Acked-by replies so far, but if you'd prefer I have
> no problem sending a V5 removing the braces.
> 

Does this patch have all the necessary acks? If so I don't mind fixing
it up and committing it.

Wei.

> 
> Thanks,
> Razvan

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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Julien Grall]

Hi Boris,

On 15/09/2016 13:39, Boris Ostrovsky wrote:

On 09/15/2016 06:22 AM, Wei Liu wrote:

On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:

Hi Wei,

On 15/09/2016 11:18, Wei Liu wrote:

On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:

On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:

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

This is version 3 of the series, see individual patches for changes. It can
be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3

Wei, Ian --- are there any comments from the toolstack perspective?


The series is probably still gated by lack of an ACK from Lenovo for the
relicensing patch (included here as patch 1).


So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
(which is the patch from Lenovo) and it only does 2 things (assuming I
parsed ASL correctly):
* Adds _PIC method
* Controls and describes legacy PCI interrupt routing. This
functionality has actually been moved into mk_dsdt.c and so this ASL
code is now generated.

Neither of these two things is used by libxl so technically we may not
need the ACK from Lenovo. OTOH, we may forget about this restriction in
the future and accidentally include those two later.


This is a risk I would rather not take. As you said, we may forget about
the restriction in the future.

Does it mean this series may not be in Xen 4.8? If so, this will also delay
other series such as the ACPI guest support for ARM.


I would like to see this and the subsequent ARM series in 4.8 -- it is
still possible we get an ack from Lenovo any time, but the issue is out
of our control at the moment. It's just one unfortunate incident in open
source software development. Sigh.


One option could be to provide a 'gpl_all' (or some such) target in
libacpi in addition to 'all' and that target will be careful about not
including these small un-ACKed portions of the code.

It will be ugly though.


I agree that it is not nice, but it would help us to get this features 
(and the other ones that depend on it) in Xen 4.8. Otherwise we would 
have to wait another 6 months to get those features.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Julien Grall]

On 15/09/2016 13:35, Boris Ostrovsky wrote:

On 09/15/2016 04:58 AM, Julien Grall wrote:
I think Jan mentioned at some point that certain versions of Windows
require an early revision although IIRC it was 2.0. So perhaps at some
point we could drop support for pre-2.0 versions, but this was never
going to be part of my series --- the goal was only to make it available
to libxl.


Thank you for the information!

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V4] tools/libxc, xen/x86: Added xc_set_mem_access_multi()

[Razvan Cojocaru]

On 09/07/2016 07:01 PM, Jan Beulich wrote:
 On 07.09.16 at 11:12,  wrote:
>> Currently it is only possible to set mem_access restrictions only for
>> a contiguous range of GFNs (or, as a particular case, for a single GFN).
>> This patch introduces a new libxc function taking an array of GFNs.
>> The alternative would be to set each page in turn, using a userspace-HV
>> roundtrip for each call, and triggering a TLB flush per page set.
>>
>> Signed-off-by: Razvan Cojocaru 
>> Acked-by: Wei Liu 
> 
> Hypervisor parts (without ARM and x86/mm)
> Acked-by: Jan Beulich 
> 
> albeit I spotted one more cosmetic issue (which I guess could be
> fixed up during commit, if no other reason for a v5 arises):
> 
>> @@ -321,9 +322,22 @@ int compat_memory_op(unsigned int cmd, 
>> XEN_GUEST_HANDLE_PARAM(void) compat)
>>  }
>>  
>>  case XENMEM_access_op:
>> -return mem_access_memop(cmd,
>> -guest_handle_cast(compat,
>> -  xen_mem_access_op_t));
>> +{
>> +if ( copy_from_guest(, compat, 1) )
>> +return -EFAULT;
>> +
>> +#define XLAT_mem_access_op_HNDL_pfn_list(_d_, _s_) \
>> +guest_from_compat_handle((_d_)->pfn_list, (_s_)->pfn_list)
>> +#define XLAT_mem_access_op_HNDL_access_list(_d_, _s_) \
>> +guest_from_compat_handle((_d_)->access_list, (_s_)->access_list)
>> +
>> +XLAT_mem_access_op(nat.mao, );
>> +
>> +#undef XLAT_mem_access_op_HNDL_pfn_list
>> +#undef XLAT_mem_access_op_HNDL_access_list
>> +
>> +break;
>> +}
> 
> There are no local variables declared here, so I don't see the need
> for the braces.

There have only been Acked-by replies so far, but if you'd prefer I have
no problem sending a V5 removing the braces.


Thanks,
Razvan

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   like 67705
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67705
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail like 67705
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail like 67705
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 67705
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67705
 test-amd64-i386-xl-qemut-debianhvm-amd64  9 debian-hvm-install fail like 67705
 test-amd64-i386-qemut-rhel6hvm-intel  9 redhat-install fail like 67705
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67705
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67705
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail like 
67705
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67705
 test-amd64-i386-xl-qemut-winxpsp3  9 windows-install   fail like 67705
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 67705

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

version targeted for testing:
 xen  773522000cc17f6f4323a4d97423790138ea98f2
baseline version:
 xen  d45fae589b8d8b6d36c211dcc46d767dda730b61

Last test of basis67705  2016-09-13 13:14:20 Z1 days
Testing same since67714  2016-09-14 23:44:47 Z0 days1 attempts


People who touched revisions under 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8db6527da8678f1480f08ba99b745279e8d104a
baseline version:
 ovmf 062f9fd2cfaad09f6dd0e302094bc030827eb706

Last test of basis67713  2016-09-14 21:50:50 Z0 days
Testing same since67717  2016-09-15 10:49:16 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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 f8db6527da8678f1480f08ba99b745279e8d104a
Author: Yonghong Zhu 
Date:   Wed Sep 14 13:59:01 2016 +0800

BaseTools: Fix the bug to handle the read-only file

change the 'r+b' to 'rb' for some file's open, since these files we only
read it and no need to write. It can fix the bug that the file's attribute
had been set to read-only.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit 04b1d73a0dac00f5a394db89f928a18a6ce5ec15
Author: Yonghong Zhu 
Date:   Wed Sep 14 13:36:07 2016 +0800

IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

Update the URL since http://edk2.tianocore.org is not valid

Cc: Liming Gao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 
Reviewed-by: Jeff Fan 

commit 445bfd921462d50a226a833f5b1c3e375efdd434
Author: Yonghong Zhu 
Date:   Wed Sep 14 13:27:06 2016 +0800

edksetup.sh: update the URL in edksetup.sh

Update the URL since http://edk2.tianocore.org is not valid

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

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

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

[osstest service owner]

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

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  c496f489f02515b8f687dc4effe259180a49a279
baseline version:
 xen  167291f0d6b87ccb1f1f4c4f73e9231b811ead03

Last test of basis   100964  2016-09-15 09:02:49 Z0 days
Testing same since   100967  2016-09-15 11:01:46 Z0 days1 attempts


People who touched revisions under test:
  Juergen Gross 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=c496f489f02515b8f687dc4effe259180a49a279
+ . ./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 
c496f489f02515b8f687dc4effe259180a49a279
+ branch=xen-unstable-smoke
+ revision=c496f489f02515b8f687dc4effe259180a49a279
+ . ./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
+ '[' xc496f489f02515b8f687dc4effe259180a49a279 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [Qemu-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

[Denis V. Lunev]

On 09/15/2016 03:22 PM, Ed Swierk wrote:
> On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev  wrote:
>> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
>>> On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
 Windows 8, 10 and Server 2012 guests hang intermittently while booting
 on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs, shortly after the Windows
 logo appears and the little dots start spinning.

 Running strace on qemu shows its main thread doing the following every
 couple of milliseconds:

  ppoll([..., {fd=30, events=POLLIN|POLLERR|POLLHUP},
 ...], ...) = 1 ([{fd=30, revents=POLLIN}], ...)
  read(30, "^\0\0\0", 4) = 4
  write(30, "^\0\0\0", 4) = 4
  ioctl(30, IOCTL_EVTCHN_NOTIFY, 0x7f1f9449d310) = 0
  clock_gettime(CLOCK_MONOTONIC, {6937, 449468262}) = 0
  clock_gettime(CLOCK_MONOTONIC, {6937, 449582903}) = 0
  gettimeofday({1472251376, 673434}, NULL) = 0
  clock_gettime(CLOCK_MONOTONIC, {6937, 449856205}) = 0
  gettimeofday({1472251376, 673679}, NULL) = 0

 The event channel (identified by '^' or 94 in this example) is always
 the third of the domain's four channels.

 Two recent qemu patches (http://git.qemu.org/?p=qemu.git;h=9596ef7c and
 http://git.qemu.org/?p=qemu.git;h=74004e8c) seem to address similar
 issues, but don't help in this case.

 The proposed fix from
 https://bugzilla.redhat.com/show_bug.cgi?id=874406#c78 makes the hang
 go away. It's not clear to me why it works, or if it's just papering
 over a bug elsewhere, or if there are any possible side effects.
>>> CC-ing Denis.
>>>
>>>
>>> Is the fix below based on reading the spec or more of instrumenting?
>>>
>>> Thanks.
>> hmm. I have looked in our older code (completely separate
>> from QEMU). It does not have this trick.
>>
>> 2012r2 (as far as I remember) has a bug in the driver
>> when LSC interrupt was raised unexpectedly during driver
>> initialization. The original bug was about TXQE. Can you
>> pls confirm which interrupt causes the storm?
> How can I tell which interrupt is firing? Instrument the QEMU e1000 code?
>
> --Ed
>
connect with gdb to qemu, set break into set_interrupt_cause
and dump value of  s->mac_reg[ICS], s->mac_reg[IMS] and s->mac_reg[ICR]

Bits are defined here hw/net/e1000_regs.h

/* Interrupt Cause Read */
#define E1000_ICR_TXDW  0x0001 /* Transmit desc written back */
#define E1000_ICR_TXQE  0x0002 /* Transmit Queue empty */

Den

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

Re: [Xen-devel] [PATCH v3 00/19] Make ACPI builder available to components other than hvmloader

[Boris Ostrovsky]

On 09/15/2016 06:22 AM, Wei Liu wrote:
> On Thu, Sep 15, 2016 at 11:20:08AM +0100, Julien Grall wrote:
>> Hi Wei,
>>
>> On 15/09/2016 11:18, Wei Liu wrote:
>>> On Wed, Sep 14, 2016 at 11:21:39AM -0400, Boris Ostrovsky wrote:
 On 09/07/2016 02:59 PM, Boris Ostrovsky wrote:
> The goal here is to build ACPI tables for PVHv2/HVMlite guests while 
> reusing existing
> hvmloader's ACPI builder code. The builder is provided as a library in 
> tools/libacpi.
>
> This is version 3 of the series, see individual patches for changes. It 
> can
> be fetched from git://oss.oracle.com/git/bostrovs/xen.git:acpi_v3
 Wei, Ian --- are there any comments from the toolstack perspective?

> The series is probably still gated by lack of an ACK from Lenovo for the
> relicensing patch (included here as patch 1).
>
 So I looked again at commit 801d469ad8b2b88f669326327df03d03200efbfb
 (which is the patch from Lenovo) and it only does 2 things (assuming I
 parsed ASL correctly):
 * Adds _PIC method
 * Controls and describes legacy PCI interrupt routing. This
 functionality has actually been moved into mk_dsdt.c and so this ASL
 code is now generated.

 Neither of these two things is used by libxl so technically we may not
 need the ACK from Lenovo. OTOH, we may forget about this restriction in
 the future and accidentally include those two later.

>>> This is a risk I would rather not take. As you said, we may forget about
>>> the restriction in the future.
>> Does it mean this series may not be in Xen 4.8? If so, this will also delay
>> other series such as the ACPI guest support for ARM.
>>
> I would like to see this and the subsequent ARM series in 4.8 -- it is
> still possible we get an ack from Lenovo any time, but the issue is out
> of our control at the moment. It's just one unfortunate incident in open
> source software development. Sigh.

One option could be to provide a 'gpl_all' (or some such) target in
libacpi in addition to 'all' and that target will be careful about not
including these small un-ACKed portions of the code.

It will be ugly though.

-boris

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

Re: [Xen-devel] [PATCH v5 00/16] Xen ARM DomU ACPI support

[Boris Ostrovsky]

On 09/15/2016 04:58 AM, Julien Grall wrote:
> Hi Boris,
>
> On 15/09/2016 03:17, Boris Ostrovsky wrote:
>>
>> - julien.gr...@arm.com wrote:
>>
>>> Hi Stefano,
>>>
>>> On 14/09/2016 21:48, Stefano Stabellini wrote:
 On Wed, 14 Sep 2016, Julien Grall wrote:
> On 14/09/2016 02:06, Stefano Stabellini wrote:
>> On Wed, 14 Sep 2016, Shannon Zhao wrote:
>>> On 2016/9/13 23:17, Julien Grall wrote:


 On 13/09/16 14:06, Shannon Zhao wrote:
> Hi Julien,

 Hello Shannon,

> On 2016/9/13 19:56, Julien Grall wrote:
>> Hi Shannon,
>>
>> On 02/09/16 03:55, Shannon Zhao wrote:
>>> From: Shannon Zhao 
>>>
>>> The design of this feature is described as below.
>>> Firstly, the toolstack (libxl) generates the ACPI tables
>>> according
>>> the
>>> number of vcpus and gic controller.
>>>
>>> Then, it copies these ACPI tables to DomU non-RAM memory map
>>> space
>>> and
>>> passes them to UEFI firmware through the "ARM multiboot"
>>> protocol.
>>>
>>> At last, UEFI gets the ACPI tables through the "ARM
>>> multiboot"
>>> protocol
>>> and installs these tables like the usual way and passes both
>>> ACPI
>>> and DT
>>> information to the Xen DomU.
>>>
>>> Currently libxl only generates RSDP, XSDT, GTDT, MADT, FADT,
>>> DSDT
>>> tables
>>> since it's enough now.
>>>
>>> This has been tested using guest kernel with the Dom0 ACPI
>>> support
>>> patches which could be fetched from linux master or:
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
>>>
>>>
>>>
>>>
>>> The UEFI binary could be fetched from or built from edk2
>>> master
>>> branch:
>>> http://people.linaro.org/~shannon.zhao/DomU_ACPI/XEN_EFI.fd
>>
>> On which commit this EFI binary is based? I am trying to
>>> rebuild
>> myself,
>> and go no luck to boot it so far.
>>
> I forgot the exact commit. But I just tried below commit which
>>> adds
> the
> support to edk2 and the guest can boot up successfully with
>>> ACPI.
>
> 402dde6 ArmVirtPkg/ArmVirtXen: Add ACPI support for Virt Xen
>>> ARM

 Thanks, the commit does not build on my platform. After some
>>> help for
 Ard I managed to boot UEFI with the patch [1] applied.

 However Linux does not boot when passing acpi=on and abort with
>>> the
 following message:

 (d86) 6RCU: Adjusting geometry for rcu_fanout_leaf=64,
>>> nr_cpu_ids=1
 (d86) 6NR_IRQS:64 nr_irqs:64 0
 (d86) 3No valid GICC entries exist
 (d86) 0Kernel panic - not syncing: No interrupt controller
>>> found.
 (d86) dCPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.0-rc6+ #420
 (d86) dHardware name: XENVM-4.8 (DT)
 (d86) Call trace:
 (d86) [] dump_backtrace+0x0/0x1a8
 (d86) [] show_stack+0x14/0x20
 (d86) [] dump_stack+0x94/0xb8
 (d86) [] panic+0x10c/0x250
 (d86) [] init_IRQ+0x24/0x2c
 (d86) [] start_kernel+0x238/0x394
 (d86) [] __primary_switched+0x30/0x74
 (d86) 0---[ end Kernel panic - not syncing: No interrupt
>>> controller
 found.

 This is because the header.length for GICC is not valid for ACPI
>>> 5.1
 (see BAD_MADT_GICC_ENTRY). So please check all the size of each
>>> table
 against ACPI 5.1.

>>> Oops. The reason is that acpi_madt_generic_interrupt in Xen is
>>> already
>>> updated to ACPI 6.0 and the length is 80 not 76 of ACPI 5.1.
>>> One solution is that we still use ACPI 5.1 and make
>>> gicc->header.length
>>> 76. Other one is that we update to ACPI 6.0 since the Xen ARM
>>> ACPI
>>> support in Linux was introduced after ACPI 6.0.
>>>
>>> Which one do you prefer?
>>
>> Certainly the versions of all tables need to be consistent. I
>>> would
>> prefer to have ACPI 6.0 but 5.1 is acceptable too (especially if
>> upgrading to 6.0 causes a large amount of changes to your
>>> patches).
>
> I disagree on this, we should use the first version of ACPI that is
>>> fully
> supporting ARM because a guest operating system may choose to
>>> support the
> first one (there is a lot hardware platform out which only provides
>>> ACPI 5.1).

 And I thought that compatibility was supposed to be ACPI's strong
>>> suit.
 I mistakenly had the impression that new ACPI releases weren't
>>> suppose
 to break old OSes. I take back my comment, you are right that we
>>> should
 stay on 5.1 (including all the erratas, many are important for ARM).

>>>
>>> IIRC, early version of ACPI used to 

Re: [Xen-devel] [RFC] e1000: Don't save writes to ICS/ICR masked by IMS

[Ed Swierk]

On Thu, Sep 15, 2016 at 2:15 AM, Denis V. Lunev  wrote:
> On 09/13/2016 11:59 PM, Konrad Rzeszutek Wilk wrote:
> > On Thu, Sep 01, 2016 at 10:57:48AM -0700, Ed Swierk wrote:
> >> Windows 8, 10 and Server 2012 guests hang intermittently while booting
> >> on Xen 4.5.3 with 1 vCPU and 4 e1000 vNICs, shortly after the Windows
> >> logo appears and the little dots start spinning.
> >>
> >> Running strace on qemu shows its main thread doing the following every
> >> couple of milliseconds:
> >>
> >>  ppoll([..., {fd=30, events=POLLIN|POLLERR|POLLHUP},
> >> ...], ...) = 1 ([{fd=30, revents=POLLIN}], ...)
> >>  read(30, "^\0\0\0", 4) = 4
> >>  write(30, "^\0\0\0", 4) = 4
> >>  ioctl(30, IOCTL_EVTCHN_NOTIFY, 0x7f1f9449d310) = 0
> >>  clock_gettime(CLOCK_MONOTONIC, {6937, 449468262}) = 0
> >>  clock_gettime(CLOCK_MONOTONIC, {6937, 449582903}) = 0
> >>  gettimeofday({1472251376, 673434}, NULL) = 0
> >>  clock_gettime(CLOCK_MONOTONIC, {6937, 449856205}) = 0
> >>  gettimeofday({1472251376, 673679}, NULL) = 0
> >>
> >> The event channel (identified by '^' or 94 in this example) is always
> >> the third of the domain's four channels.
> >>
> >> Two recent qemu patches (http://git.qemu.org/?p=qemu.git;h=9596ef7c and
> >> http://git.qemu.org/?p=qemu.git;h=74004e8c) seem to address similar
> >> issues, but don't help in this case.
> >>
> >> The proposed fix from
> >> https://bugzilla.redhat.com/show_bug.cgi?id=874406#c78 makes the hang
> >> go away. It's not clear to me why it works, or if it's just papering
> >> over a bug elsewhere, or if there are any possible side effects.
> > CC-ing Denis.
> >
> >
> > Is the fix below based on reading the spec or more of instrumenting?
> >
> > Thanks.
>
> hmm. I have looked in our older code (completely separate
> from QEMU). It does not have this trick.
>
> 2012r2 (as far as I remember) has a bug in the driver
> when LSC interrupt was raised unexpectedly during driver
> initialization. The original bug was about TXQE. Can you
> pls confirm which interrupt causes the storm?

How can I tell which interrupt is firing? Instrument the QEMU e1000 code?

--Ed

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

Re: [Xen-devel] [for-4.8][PATCH v2 21/23] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

[Razvan Cojocaru]

On 09/15/2016 02:28 PM, Julien Grall wrote:
> The function p2m_set_mem_access can be re-implemented using the generic
> functions p2m_get_entry and __p2m_set_entry.
> 
> Also the function apply_p2m_changes is dropped completely as it is not
> used anymore.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 
> Cc: Razvan Cojocaru 
> Cc: Tamas K Lengyel 
> 
> ---
> Changes in v2:
> - Remove level_shifts as it is not used anymore
> - Fix multiple bugs in the code
> - Use gfn_next_boundary
> - Drop the paragraph about performance issue as
> Break-Before-Make is not required when only the permission are
> changed.
> ---
>  xen/arch/arm/p2m.c | 327 
> +
>  1 file changed, 29 insertions(+), 298 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 734923b..aa740c2 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -34,8 +34,6 @@ static const paddr_t level_sizes[] =
>  { ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
>  static const paddr_t level_masks[] =
>  { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
> -static const uint8_t level_shifts[] =
> -{ ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
>  static const uint8_t level_orders[] =
>  { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>  
> @@ -1154,295 +1152,6 @@ int p2m_set_entry(struct p2m_domain *p2m,
>  return rc;
>  }
>  
> -#define P2M_ONE_DESCEND0
> -#define P2M_ONE_PROGRESS_NOP   0x1
> -#define P2M_ONE_PROGRESS   0x10
> -
> -static int p2m_shatter_page(struct p2m_domain *p2m,
> -lpae_t *entry,
> -unsigned int level)
> -{
> -const uint8_t level_shift = level_shifts[level];
> -int rc = p2m_create_table(p2m, entry, level_shift - PAGE_SHIFT);
> -
> -if ( !rc )
> -{
> -p2m->stats.shattered[level]++;
> -p2m->stats.mappings[level]--;
> -p2m->stats.mappings[level+1] += LPAE_ENTRIES;
> -}
> -
> -return rc;
> -}
> -
> -/*
> - * 0   == (P2M_ONE_DESCEND) continue to descend the tree
> - * +ve == (P2M_ONE_PROGRESS_*) handled at this level, continue, flush,
> - *entry, addr and maddr updated.  Return value is an
> - *indication of the amount of work done (for preemption).
> - * -ve == (-Exxx) error.
> - */
> -static int apply_one_level(struct domain *d,
> -   lpae_t *entry,
> -   unsigned int level,
> -   enum p2m_operation op,
> -   paddr_t start_gpaddr,
> -   paddr_t end_gpaddr,
> -   paddr_t *addr,
> -   paddr_t *maddr,
> -   bool_t *flush,
> -   p2m_type_t t,
> -   p2m_access_t a)
> -{
> -const paddr_t level_size = level_sizes[level];
> -
> -struct p2m_domain *p2m = >arch.p2m;
> -lpae_t pte;
> -const lpae_t orig_pte = *entry;
> -int rc;
> -
> -BUG_ON(level > 3);
> -
> -switch ( op )
> -{
> -case MEMACCESS:
> -if ( level < 3 )
> -{
> -if ( !p2m_valid(orig_pte) )
> -{
> -*addr += level_size;
> -return P2M_ONE_PROGRESS_NOP;
> -}
> -
> -/* Shatter large pages as we descend */
> -if ( p2m_mapping(orig_pte) )
> -{
> -rc = p2m_shatter_page(p2m, entry, level);
> -if ( rc < 0 )
> -return rc;
> -} /* else: an existing table mapping -> descend */
> -
> -return P2M_ONE_DESCEND;
> -}
> -else
> -{
> -pte = orig_pte;
> -
> -if ( p2m_valid(pte) )
> -{
> -rc = p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)),
> -  a);
> -if ( rc < 0 )
> -return rc;
> -
> -p2m_set_permission(, pte.p2m.type, a);
> -p2m_write_pte(entry, pte, p2m->clean_pte);
> -}
> -
> -*addr += level_size;
> -*flush = true;
> -return P2M_ONE_PROGRESS;
> -}
> -}
> -
> -BUG(); /* Should never get here */
> -}
> -
> -/*
> - * The page is only used by the P2M code which is protected by the p2m->lock.
> - * So we can avoid to use atomic helpers.
> - */
> -static void update_reference_mapping(struct page_info *page,
> - lpae_t old_entry,
> - lpae_t new_entry)
> -{
> -if ( p2m_valid(old_entry) && !p2m_valid(new_entry) )
> -page->u.inuse.p2m_refcount--;
> -else if ( 

[Xen-devel] [for-4.8][PATCH v2 22/23] xen/arm: p2m: Do not handle shattering in p2m_create_table

[Julien Grall]

The helper p2m_create_table is only called to create a brand new table.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c | 56 ++
 1 file changed, 6 insertions(+), 50 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa740c2..c1dac09 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -278,8 +278,7 @@ static p2m_access_t p2m_mem_access_radix_get(struct 
p2m_domain *p2m, gfn_t gfn)
 #define GUEST_TABLE_SUPER_PAGE 1
 #define GUEST_TABLE_NORMAL_PAGE 2
 
-static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry,
-int level_shift);
+static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry);
 
 /*
  * Take the currently mapped table, find the corresponding GFN entry,
@@ -310,7 +309,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
read_only,
 if ( read_only )
 return GUEST_TABLE_MAP_FAILED;
 
-ret = p2m_create_table(p2m, entry, /* not used */ ~0);
+ret = p2m_create_table(p2m, entry);
 if ( ret )
 return GUEST_TABLE_MAP_FAILED;
 }
@@ -575,25 +574,14 @@ static inline void p2m_remove_pte(lpae_t *p, bool 
clean_pte)
 p2m_write_pte(p, pte, clean_pte);
 }
 
-/*
- * Allocate a new page table page and hook it in via the given entry.
- * apply_one_level relies on this returning 0 on success
- * and -ve on failure.
- *
- * If the existing entry is present then it must be a mapping and not
- * a table and it will be shattered into the next level down.
- *
- * level_shift is the number of bits at the level we want to create.
- */
-static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry,
-int level_shift)
+/* Allocate a new page table page and hook it in via the given entry. */
+static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry)
 {
 struct page_info *page;
 lpae_t *p;
 lpae_t pte;
-int splitting = p2m_valid(*entry);
 
-BUG_ON(p2m_table(*entry));
+ASSERT(!p2m_valid(*entry));
 
 page = alloc_domheap_page(NULL, 0);
 if ( page == NULL )
@@ -602,39 +590,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t 
*entry,
 page_list_add(page, >pages);
 
 p = __map_domain_page(page);
-if ( splitting )
-{
-mfn_t mfn = _mfn(entry->p2m.base);
-int i;
-
-/*
- * We are either splitting a first level 1G page into 512 second level
- * 2M pages, or a second level 2M page into 512 third level 4K pages.
- */
- for ( i=0 ; i < LPAE_ENTRIES; i++ )
- {
- /*
-  * Use the content of the superpage entry and override
-  * the necessary fields. So the correct permissions are
-  * kept.
-  */
- pte = *entry;
- pte.p2m.base = mfn_x(mfn_add(mfn,
-  i << (level_shift - LPAE_SHIFT)));
-
- /*
-  * First and second level super pages set p2m.table = 0, but
-  * third level entries set table = 1.
-  */
- pte.p2m.table = !(level_shift - LPAE_SHIFT);
-
- write_pte([i], pte);
- }
-
- page->u.inuse.p2m_refcount = LPAE_ENTRIES;
-}
-else
-clear_page(p);
+clear_page(p);
 
 if ( p2m->clean_pte )
 clean_dcache_va_range(p, PAGE_SIZE);
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 05/23] xen/arm: p2m: Add a back pointer to domain in p2m_domain

[Julien Grall]

The back pointer will be usefult later to get the domain when we only
have the p2m in hand.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/p2m.c| 1 +
 xen/include/asm-arm/p2m.h | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 950a607..5cf136f 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1391,6 +1391,7 @@ int p2m_init(struct domain *d)
 if ( rc != 0 )
 return rc;
 
+p2m->domain = d;
 p2m->max_mapped_gfn = _gfn(0);
 p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index b9269e4..b27a3a1 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -81,6 +81,9 @@ struct p2m_domain {
  * enough available bits to store this information.
  */
 struct radix_tree_root mem_access_settings;
+
+/* back pointer to domain */
+struct domain *domain;
 };
 
 /*
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 20/23] xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry

[Julien Grall]

The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.

Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to ensure the MMIO are not kept half-mapped
in case of failure and to follow the x86 counterpart. This was removed
on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
mappings" and I think we should let the caller taking care of it.

Finally drop the operation INSERT in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at the
end, however I find easier to drop the operations one by one avoiding a
big deletion in the patch that convert the last operation.

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

---
Changes in v2:
- Drop todo about safety checks (similar as x86) as we are not
mandate to protect a guest from his own dumbess as long as it
does not impact Xen internal reference counting (e.g foreign).
- Add Stefano's Reviewed-by
- Fix typo
---
 xen/arch/arm/p2m.c | 143 +++--
 1 file changed, 8 insertions(+), 135 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6c9a6b2..734923b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -752,7 +752,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m, 
gfn_t gfn,
 }
 
 enum p2m_operation {
-INSERT,
 MEMACCESS,
 };
 
@@ -1155,41 +1154,6 @@ int p2m_set_entry(struct p2m_domain *p2m,
 return rc;
 }
 
-/*
- * Returns true if start_gpaddr..end_gpaddr contains at least one
- * suitably aligned level_size mappping of maddr.
- *
- * So long as the range is large enough the end_gpaddr need not be
- * aligned (callers should create one superpage mapping based on this
- * result and then call this again on the new range, eventually the
- * slop at the end will cause this function to return false).
- */
-static bool_t is_mapping_aligned(const paddr_t start_gpaddr,
- const paddr_t end_gpaddr,
- const paddr_t maddr,
- const paddr_t level_size)
-{
-const paddr_t level_mask = level_size - 1;
-
-/* No hardware superpages at level 0 */
-if ( level_size == ZEROETH_SIZE )
-return false;
-
-/*
- * A range smaller than the size of a superpage at this level
- * cannot be superpage aligned.
- */
-if ( ( end_gpaddr - start_gpaddr ) < level_size - 1 )
-return false;
-
-/* Both the gpaddr and maddr must be aligned */
-if ( start_gpaddr & level_mask )
-return false;
-if ( maddr & level_mask )
-return false;
-return true;
-}
-
 #define P2M_ONE_DESCEND0
 #define P2M_ONE_PROGRESS_NOP   0x1
 #define P2M_ONE_PROGRESS   0x10
@@ -1241,80 +1205,6 @@ static int apply_one_level(struct domain *d,
 
 switch ( op )
 {
-case INSERT:
-if ( is_mapping_aligned(*addr, end_gpaddr, *maddr, level_size) &&
-   /*
-* We do not handle replacing an existing table with a superpage
-* or when mem_access is in use.
-*/
- (level == 3 || (!p2m_table(orig_pte) && 
!p2m->mem_access_enabled)) )
-{
-rc = p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)), a);
-if ( rc < 0 )
-return rc;
-
-/* New mapping is superpage aligned, make it */
-pte = mfn_to_p2m_entry(_mfn(*maddr >> PAGE_SHIFT), t, a);
-if ( level < 3 )
-pte.p2m.table = 0; /* Superpage entry */
-
-p2m_write_pte(entry, pte, p2m->clean_pte);
-
-*flush |= p2m_valid(orig_pte);
-
-*addr += level_size;
-*maddr += level_size;
-
-if ( p2m_valid(orig_pte) )
-{
-/*
- * We can't currently get here for an existing table
- * mapping, since we don't handle replacing an
- * existing table with a superpage. If we did we would
- * need to handle freeing (and accounting) for the bit
- * of the p2m tree which we would be about to lop off.
- */
-BUG_ON(level < 3 && p2m_table(orig_pte));
-if ( level == 3 )
-p2m_put_l3_page(orig_pte);
-}
-else /* New mapping */
-p2m->stats.mappings[level]++;
-
-return P2M_ONE_PROGRESS;
-}
-else
-{
-/* New mapping is not superpage aligned, create a new table entry 
*/
-
-/* L3 is always suitably aligned for mapping (handled, above) */
-BUG_ON(level == 3);
-
-/* Not present -> create table entry and descend */
-if ( !p2m_valid(orig_pte) )
-{
-

[Xen-devel] [for-4.8][PATCH v2 02/23] xen/arm: p2m: Store in p2m_domain whether we need to clean the entry

[Julien Grall]

Each entry in the page table has to be cleaned when the IOMMU does not
support coherent walk. Rather than querying every time the page table is
updated, it is possible to do it only once when the p2m is initialized.

This is because this value can never change, Xen would be in big trouble
otherwise.

With this change, the initialization of the IOMMU for a given domain has
to be done earlier in order to know whether the page table entries need
to be cleaned. It is fine to move the call earlier because it has no
dependency.

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

---
Changes in v2:
- Fix typoes in the commit message
- Add Stefano's reviewed-by
- Use bool instead of bool_t
---
 xen/arch/arm/domain.c |  8 +---
 xen/arch/arm/p2m.c| 47 ++-
 xen/include/asm-arm/p2m.h |  3 +++
 3 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 20bb2ba..48f04c8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -555,6 +555,11 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 return 0;
 
 ASSERT(config != NULL);
+
+/* p2m_init relies on some value initialized by the IOMMU subsystem */
+if ( (rc = iommu_domain_init(d)) != 0 )
+goto fail;
+
 if ( (rc = p2m_init(d)) != 0 )
 goto fail;
 
@@ -637,9 +642,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( is_hardware_domain(d) && (rc = domain_vuart_init(d)) )
 goto fail;
 
-if ( (rc = iommu_domain_init(d)) != 0 )
-goto fail;
-
 return 0;
 
 fail:
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b648a9d..f482cfd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -416,7 +416,7 @@ static inline void p2m_remove_pte(lpae_t *p, bool_t 
flush_cache)
  * level_shift is the number of bits at the level we want to create.
  */
 static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry,
-int level_shift, bool_t flush_cache)
+int level_shift)
 {
 struct page_info *page;
 lpae_t *p;
@@ -466,7 +466,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t 
*entry,
 else
 clear_page(p);
 
-if ( flush_cache )
+if ( p2m->clean_pte )
 clean_dcache_va_range(p, PAGE_SIZE);
 
 unmap_domain_page(p);
@@ -478,7 +478,7 @@ static int p2m_create_table(struct p2m_domain *p2m, lpae_t 
*entry,
 pte = mfn_to_p2m_entry(_mfn(page_to_mfn(page)), p2m_invalid,
p2m->default_access);
 
-p2m_write_pte(entry, pte, flush_cache);
+p2m_write_pte(entry, pte, p2m->clean_pte);
 
 return 0;
 }
@@ -661,12 +661,10 @@ static const paddr_t level_shifts[] =
 
 static int p2m_shatter_page(struct p2m_domain *p2m,
 lpae_t *entry,
-unsigned int level,
-bool_t flush_cache)
+unsigned int level)
 {
 const paddr_t level_shift = level_shifts[level];
-int rc = p2m_create_table(p2m, entry,
-  level_shift - PAGE_SHIFT, flush_cache);
+int rc = p2m_create_table(p2m, entry, level_shift - PAGE_SHIFT);
 
 if ( !rc )
 {
@@ -688,7 +686,6 @@ static int p2m_shatter_page(struct p2m_domain *p2m,
 static int apply_one_level(struct domain *d,
lpae_t *entry,
unsigned int level,
-   bool_t flush_cache,
enum p2m_operation op,
paddr_t start_gpaddr,
paddr_t end_gpaddr,
@@ -727,7 +724,7 @@ static int apply_one_level(struct domain *d,
 if ( level < 3 )
 pte.p2m.table = 0; /* Superpage entry */
 
-p2m_write_pte(entry, pte, flush_cache);
+p2m_write_pte(entry, pte, p2m->clean_pte);
 
 *flush |= p2m_valid(orig_pte);
 
@@ -762,7 +759,7 @@ static int apply_one_level(struct domain *d,
 /* Not present -> create table entry and descend */
 if ( !p2m_valid(orig_pte) )
 {
-rc = p2m_create_table(p2m, entry, 0, flush_cache);
+rc = p2m_create_table(p2m, entry, 0);
 if ( rc < 0 )
 return rc;
 return P2M_ONE_DESCEND;
@@ -772,7 +769,7 @@ static int apply_one_level(struct domain *d,
 if ( p2m_mapping(orig_pte) )
 {
 *flush = true;
-rc = p2m_shatter_page(p2m, entry, level, flush_cache);
+rc = p2m_shatter_page(p2m, entry, level);
 if ( rc < 0 )
 return rc;
 } /* else: an existing table mapping -> descend */
@@ -809,7 +806,7 @@ static int 

[Xen-devel] [for-4.8][PATCH v2 13/23] xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry

[Julien Grall]

__p2m_lookup is just a wrapper to p2m_get_entry.

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

---
It might be possible to rework the memaccess code to take advantage
of all the parameters. I will defer this to the memaccess folks.

Changes in v2:
- Add Stefano's acked-by
---
 xen/arch/arm/p2m.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 6e56b97..ddee258 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -402,24 +402,13 @@ out:
 return mfn;
 }
 
-/*
- * Lookup the MFN corresponding to a domain's GFN.
- *
- * There are no processor functions to do a stage 2 only lookup therefore we
- * do a a software walk.
- */
-static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
-{
-return p2m_get_entry(>arch.p2m, gfn, t, NULL, NULL);
-}
-
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 mfn_t ret;
 struct p2m_domain *p2m = >arch.p2m;
 
 p2m_read_lock(p2m);
-ret = __p2m_lookup(d, gfn, t);
+ret = p2m_get_entry(p2m, gfn, t, NULL, NULL);
 p2m_read_unlock(p2m);
 
 return ret;
@@ -691,7 +680,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-mfn_t mfn = __p2m_lookup(d, gfn, NULL);
+mfn_t mfn = p2m_get_entry(p2m, gfn, NULL, NULL, NULL);
 
 if ( mfn_eq(mfn, INVALID_MFN) )
 return -ESRCH;
@@ -1611,6 +1600,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 xenmem_access_t xma;
 p2m_type_t t;
 struct page_info *page = NULL;
+struct p2m_domain *p2m = >domain->arch.p2m;
 
 rc = gva_to_ipa(gva, , flag);
 if ( rc < 0 )
@@ -1671,7 +1661,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
  * We had a mem_access permission limiting the access, but the page type
  * could also be limiting, so we need to check that as well.
  */
-mfn = __p2m_lookup(current->domain, gfn, );
+mfn = p2m_get_entry(p2m, gfn, , NULL, NULL);
 if ( mfn_eq(mfn, INVALID_MFN) )
 goto err;
 
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 01/23] xen/arm: do_trap_instr_abort_guest: Move the IPA computation out of the switch

[Julien Grall]

A follow-up patch will add more case to the switch that will require the
IPA. So move the computation out of the switch.

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

---
Changes in v2:
- Add Stefano's acked-by
---
 xen/arch/arm/traps.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 39a05fd..a5a5384 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2404,35 +2404,35 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 int rc;
 register_t gva = READ_SYSREG(FAR_EL2);
 uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
+paddr_t gpa;
+
+if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
+gpa = get_faulting_ipa(gva);
+else
+{
+/*
+ * Flush the TLB to make sure the DTLB is clear before
+ * doing GVA->IPA translation. If we got here because of
+ * an entry only present in the ITLB, this translation may
+ * still be inaccurate.
+ */
+flush_tlb_local();
+
+rc = gva_to_ipa(gva, , GV2M_READ);
+if ( rc == -EFAULT )
+return; /* Try again */
+}
 
 switch ( fsc )
 {
 case FSC_FLT_PERM:
 {
-paddr_t gpa;
 const struct npfec npfec = {
 .insn_fetch = 1,
 .gla_valid = 1,
 .kind = hsr.iabt.s1ptw ? npfec_kind_in_gpt : npfec_kind_with_gla
 };
 
-if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
-gpa = get_faulting_ipa(gva);
-else
-{
-/*
- * Flush the TLB to make sure the DTLB is clear before
- * doing GVA->IPA translation. If we got here because of
- * an entry only present in the ITLB, this translation may
- * still be inaccurate.
- */
-flush_tlb_local();
-
-rc = gva_to_ipa(gva, , GV2M_READ);
-if ( rc == -EFAULT )
-return; /* Try again */
-}
-
 rc = p2m_mem_access_check(gpa, gva, npfec);
 
 /* Trap was triggered by mem_access, work here is done */
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 09/23] xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t

[Julien Grall]

The level shift can be encoded with 8-bit. So it is not necessary to
use paddr_t (i.e 64-bit).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use uint8_t rather than unsigned int
- Replaced paddr_t by uint8_t in p2m_shatter_page
---
 xen/arch/arm/p2m.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b53d4cf..b4f75e8 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -687,14 +687,14 @@ static const paddr_t level_sizes[] =
 { ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
 static const paddr_t level_masks[] =
 { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
-static const paddr_t level_shifts[] =
+static const uint8_t level_shifts[] =
 { ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
 
 static int p2m_shatter_page(struct p2m_domain *p2m,
 lpae_t *entry,
 unsigned int level)
 {
-const paddr_t level_shift = level_shifts[level];
+const uint8_t level_shift = level_shifts[level];
 int rc = p2m_create_table(p2m, entry, level_shift - PAGE_SHIFT);
 
 if ( !rc )
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 08/23] xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m

[Julien Grall]

Sometimes the invalidation of the TLBs can be deferred until the p2m is
unlocked. This is for instance the case when multiple mappings are
removed. In other case, such as shattering a superpage, an immediate
flush is required.

Keep track whether a flush is needed directly in the p2m_domain structure
to allow serializing multiple changes. The TLBs will be invalidated when
write unlocking the p2m if necessary.

Also a new helper, p2m_flush_sync, has been introduced to force a
synchronous TLB invalidation.

Finally, replace the call to p2m_flush_tlb by p2m_flush_tlb_sync in
apply_p2m_changes.

Note this patch is not useful today, however follow-up patches will make
advantage of it.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c| 33 -
 xen/include/asm-arm/p2m.h | 11 +++
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5cf136f..b53d4cf 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -52,8 +52,21 @@ static inline void p2m_write_lock(struct p2m_domain *p2m)
 write_lock(>lock);
 }
 
+static void p2m_flush_tlb(struct p2m_domain *p2m);
+
 static inline void p2m_write_unlock(struct p2m_domain *p2m)
 {
+if ( p2m->need_flush )
+{
+p2m->need_flush = false;
+/*
+ * The final flush is done with the P2M write lock taken to
+ * to avoid someone else modify the P2M before the TLB
+ * invalidation has completed.
+ */
+p2m_flush_tlb(p2m);
+}
+
 write_unlock(>lock);
 }
 
@@ -72,6 +85,11 @@ static inline int p2m_is_locked(struct p2m_domain *p2m)
 return rw_is_locked(>lock);
 }
 
+static inline int p2m_is_write_locked(struct p2m_domain *p2m)
+{
+return rw_is_write_locked(>lock);
+}
+
 void p2m_dump_info(struct domain *d)
 {
 struct p2m_domain *p2m = >arch.p2m;
@@ -165,6 +183,19 @@ static void p2m_flush_tlb(struct p2m_domain *p2m)
 }
 
 /*
+ * Force a synchronous P2M TLB flush.
+ *
+ * Must be called with the p2m lock held.
+ */
+static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
+{
+ASSERT(p2m_is_write_locked(p2m));
+
+p2m_flush_tlb(p2m);
+p2m->need_flush = false;
+}
+
+/*
  * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
@@ -1153,7 +1184,7 @@ static int apply_p2m_changes(struct domain *d,
 out:
 if ( flush )
 {
-p2m_flush_tlb(>arch.p2m);
+p2m_flush_tlb_sync(>arch.p2m);
 ret = iommu_iotlb_flush(d, gfn_x(sgfn), nr);
 if ( !rc )
 rc = ret;
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index b27a3a1..156df5e 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -51,6 +51,17 @@ struct p2m_domain {
 /* Indicate if it is required to clean the cache when writing an entry */
 bool clean_pte;
 
+/*
+ * P2M updates may required TLBs to be flushed (invalidated).
+ *
+ * Flushes may be deferred by setting 'need_flush' and then flushing
+ * when the p2m write lock is released.
+ *
+ * If an immediate flush is required (e.g, if a super page is
+ * shattered), call p2m_tlb_flush_sync().
+ */
+bool need_flush;
+
 /* Gather some statistics for information purposes only */
 struct {
 /* Number of mappings at each p2m tree level */
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 06/23] xen/arm: traps: Move MMIO emulation code in a separate helper

[Julien Grall]

Currently, a stage-2 fault translation will likely access an emulated
region. All the checks are pre-sanitity check for MMIO emulation.

A follow-up patch will handle a new case that could lead to a stage-2
translation. To improve the clarity of the code and the changes, the
current implementation is move in a separate helper.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Keep the break in FSC_FLT_TRANS
- Use bool instead of bool_t
---
 xen/arch/arm/traps.c | 57 ++--
 1 file changed, 33 insertions(+), 24 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index a5a5384..76e4152 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2445,6 +2445,38 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 inject_iabt_exception(regs, gva, hsr.len);
 }
 
+static bool try_handle_mmio(struct cpu_user_regs *regs,
+mmio_info_t *info)
+{
+const struct hsr_dabt dabt = info->dabt;
+int rc;
+
+/* stage-1 page table should never live in an emulated MMIO region */
+if ( dabt.s1ptw )
+return false;
+
+/* All the instructions used on emulated MMIO region should be valid */
+if ( !dabt.valid )
+return false;
+
+/*
+ * Erratum 766422: Thumb store translation fault to Hypervisor may
+ * not have correct HSR Rt value.
+ */
+if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
+ dabt.write )
+{
+rc = decode_instruction(regs, >dabt);
+if ( rc )
+{
+gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
+return false;
+}
+}
+
+return !!handle_mmio(info);
+}
+
 static void do_trap_data_abort_guest(struct cpu_user_regs *regs,
  const union hsr hsr)
 {
@@ -2488,29 +2520,7 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 break;
 }
 case FSC_FLT_TRANS:
-if ( dabt.s1ptw )
-goto bad_data_abort;
-
-/* XXX: Decode the instruction if ISS is not valid */
-if ( !dabt.valid )
-goto bad_data_abort;
-
-/*
- * Erratum 766422: Thumb store translation fault to Hypervisor may
- * not have correct HSR Rt value.
- */
-if ( check_workaround_766422() && (regs->cpsr & PSR_THUMB) &&
- dabt.write )
-{
-rc = decode_instruction(regs, );
-if ( rc )
-{
-gprintk(XENLOG_DEBUG, "Unable to decode instruction\n");
-goto bad_data_abort;
-}
-}
-
-if ( handle_mmio() )
+if ( try_handle_mmio(regs, ) )
 {
 advance_pc(regs, hsr);
 return;
@@ -2521,7 +2531,6 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 hsr.bits, dabt.dfsc);
 }
 
-bad_data_abort:
 gdprintk(XENLOG_DEBUG, "HSR=0x%x pc=%#"PRIregister" gva=%#"PRIvaddr
  " gpa=%#"PRIpaddr"\n", hsr.bits, regs->pc, info.gva, info.gpa);
 inject_dabt_exception(regs, info.gva, hsr.len);
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 19/23] xen/arm: p2m: Re-implement p2m_remove_using using p2m_set_entry

[Julien Grall]

The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.

Also drop the operation REMOVE in apply_* as nobody is using it anymore.
Note that the functions could have been dropped in one go at the end,
however I find easier to drop the operations one by one avoiding a big
deletion in the patch that converts the last operation.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c | 125 ++---
 1 file changed, 13 insertions(+), 112 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ce09c4c..6c9a6b2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -753,7 +753,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m, 
gfn_t gfn,
 
 enum p2m_operation {
 INSERT,
-REMOVE,
 MEMACCESS,
 };
 
@@ -1232,7 +1231,6 @@ static int apply_one_level(struct domain *d,
p2m_access_t a)
 {
 const paddr_t level_size = level_sizes[level];
-const paddr_t level_mask = level_masks[level];
 
 struct p2m_domain *p2m = >arch.p2m;
 lpae_t pte;
@@ -1317,74 +1315,6 @@ static int apply_one_level(struct domain *d,
 
 break;
 
-case REMOVE:
-if ( !p2m_valid(orig_pte) )
-{
-/* Progress up to next boundary */
-*addr = (*addr + level_size) & level_mask;
-*maddr = (*maddr + level_size) & level_mask;
-return P2M_ONE_PROGRESS_NOP;
-}
-
-if ( level < 3 )
-{
-if ( p2m_table(orig_pte) )
-return P2M_ONE_DESCEND;
-
-if ( op == REMOVE &&
- !is_mapping_aligned(*addr, end_gpaddr,
- 0, /* maddr doesn't matter for remove */
- level_size) )
-{
-/*
- * Removing a mapping from the middle of a superpage. Shatter
- * and descend.
- */
-*flush = true;
-rc = p2m_shatter_page(p2m, entry, level);
-if ( rc < 0 )
-return rc;
-
-return P2M_ONE_DESCEND;
-}
-}
-
-/*
- * Ensure that the guest address addr currently being
- * handled (that is in the range given as argument to
- * this function) is actually mapped to the corresponding
- * machine address in the specified range. maddr here is
- * the machine address given to the function, while
- * orig_pte.p2m.base is the machine frame number actually
- * mapped to the guest address: check if the two correspond.
- */
- if ( op == REMOVE &&
-  pfn_to_paddr(orig_pte.p2m.base) != *maddr )
- printk(XENLOG_G_WARNING
-"p2m_remove dom%d: mapping at %"PRIpaddr" is of maddr 
%"PRIpaddr" not %"PRIpaddr" as expected\n",
-d->domain_id, *addr, pfn_to_paddr(orig_pte.p2m.base),
-*maddr);
-
-*flush = true;
-
-p2m_remove_pte(entry, p2m->clean_pte);
-p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)),
- p2m_access_rwx);
-
-*addr += level_size;
-*maddr += level_size;
-
-p2m->stats.mappings[level]--;
-
-if ( level == 3 )
-p2m_put_l3_page(orig_pte);
-
-/*
- * This is still a single pte write, no matter the level, so no need to
- * scale.
- */
-return P2M_ONE_PROGRESS;
-
 case MEMACCESS:
 if ( level < 3 )
 {
@@ -1596,43 +1526,6 @@ static int apply_p2m_changes(struct domain *d,
 }
 
 BUG_ON(level > 3);
-
-if ( op == REMOVE )
-{
-for ( ; level > P2M_ROOT_LEVEL; level-- )
-{
-lpae_t old_entry;
-lpae_t *entry;
-unsigned int offset;
-
-pg = pages[level];
-
-/*
- * No need to try the previous level if the current one
- * still contains some mappings.
- */
-if ( pg->u.inuse.p2m_refcount )
-break;
-
-offset = offsets[level - 1];
-entry = [level - 1][offset];
-old_entry = *entry;
-
-page_list_del(pg, >pages);
-
-p2m_remove_pte(entry, p2m->clean_pte);
-
-p2m->stats.mappings[level - 1]--;
-update_reference_mapping(pages[level - 1], old_entry, *entry);
-
-/*
- * We can't free the page now because it may be present
- * in the guest TLB. Queue it and free it after the TLB
- * has been flushed.
- */
-

[Xen-devel] [for-4.8][PATCH v2 00/23] xen/arm: Rework the P2M code to follow break-before-make sequence

[Julien Grall]

Hello all,

The ARM architecture mandates the use of a break-before-make sequence when
changing translation entries if the page table is shared between multiple
CPUs whenever a valid entry is replaced by another valid entry (see D4.7.1
in ARM DDI 0487A.j for more details).

The current P2M code does not respect this sequence and may result to
break coherency on some processors.

Adapting the current implementation to use break-before-make sequence would
imply some code duplication and more TLBs invalidations than necessary.
For instance, if we are replacing a 4KB page and the current mapping in
the P2M is using a 1GB superpage, the following steps will happen:
1) Shatter the 1GB superpage into a series of 2MB superpages
2) Shatter the 2MB superpage into a series of 4KB superpages
3) Replace the 4KB page

As the current implementation is shattering while descending and install
the mapping before continuing to the next level, Xen would need to issue 3
TLB invalidation instructions which is clearly inefficient.

Furthermore, all the operations which modify the page table are using the
same skeleton. It is more complicated to maintain different code paths than
having a generic function that set an entry and take care of the break-before-
make sequence.

The new implementation is based on the x86 EPT one which, I think, fits
quite well for the break-before-make sequence whilst keeping the code
simple.

For all the changes see in each patch.

I have provided a branch based on upstream here:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch p2m-v2

Comments are welcome.

Yours sincerely,

Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 
Cc: Shanker Donthineni 
Cc: Dirk Behme 
Cc: Edgar E. Iglesias 

Julien Grall (23):
  xen/arm: do_trap_instr_abort_guest: Move the IPA computation out of
the switch
  xen/arm: p2m: Store in p2m_domain whether we need to clean the entry
  xen/arm: p2m: Rename parameter in p2m_{remove,write}_pte...
  xen/arm: p2m: Use typesafe gfn in p2m_mem_access_radix_set
  xen/arm: p2m: Add a back pointer to domain in p2m_domain
  xen/arm: traps: Move MMIO emulation code in a separate helper
  xen/arm: traps: Check the P2M before injecting a data/instruction
abort
  xen/arm: p2m: Invalidate the TLBs when write unlocking the p2m
  xen/arm: p2m: Change the type of level_shifts from paddr_t to uint8_t
  xen/arm: p2m: Move the lookup helpers at the top of the file
  xen/arm: p2m: Introduce p2m_get_root_pointer and use it in
__p2m_lookup
  xen/arm: p2m: Introduce p2m_get_entry and use it to implement
__p2m_lookup
  xen/arm: p2m: Replace all usage of __p2m_lookup with p2m_get_entry
  xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry
  xen/arm: p2m: Make p2m_{valid,table,mapping} helpers inline
  xen/arm: p2m: Introduce a helper to check if an entry is a superpage
  xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry
  xen/arm: p2m: Re-implement relinquish_p2m_mapping using
p2m_{get,set}_entry
  xen/arm: p2m: Re-implement p2m_remove_using using p2m_set_entry
  xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry
  xen/arm: p2m: Re-implement p2m_set_mem_access using
p2m_{set,get}_entry
  xen/arm: p2m: Do not handle shattering in p2m_create_table
  xen/arm: p2m: Export p2m_*_lock helpers

 xen/arch/arm/domain.c  |8 +-
 xen/arch/arm/p2m.c | 1316 ++--
 xen/arch/arm/traps.c   |  126 +++--
 xen/include/asm-arm/p2m.h  |   63 +++
 xen/include/asm-arm/page.h |8 +
 5 files changed, 828 insertions(+), 693 deletions(-)

-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 15/23] xen/arm: p2m: Make p2m_{valid, table, mapping} helpers inline

[Julien Grall]

Those helpers are very small and often used. Let know the compiler they
can be inlined.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index fa58f1a..9f0f896 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -39,7 +39,7 @@ static const uint8_t level_shifts[] =
 static const uint8_t level_orders[] =
 { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
 
-static bool_t p2m_valid(lpae_t pte)
+static inline bool_t p2m_valid(lpae_t pte)
 {
 return pte.p2m.valid;
 }
@@ -48,11 +48,11 @@ static bool_t p2m_valid(lpae_t pte)
  * the table bit and therefore these would return the opposite to what
  * you would expect.
  */
-static bool_t p2m_table(lpae_t pte)
+static inline bool_t p2m_table(lpae_t pte)
 {
 return p2m_valid(pte) && pte.p2m.table;
 }
-static bool_t p2m_mapping(lpae_t pte)
+static inline bool_t p2m_mapping(lpae_t pte)
 {
 return p2m_valid(pte) && !pte.p2m.table;
 }
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 23/23] xen/arm: p2m: Export p2m_*_lock helpers

[Julien Grall]

Earlier patches exported the p2m interface (p2m_get_entry and
p2m_set_entry) to allow splitting xen/arch/arm/p2m.c. Those functions
require the callers to lock the p2m, so we need to export p2m_*_lock
helpers.

All helpers but p2m_write_unlock but p2m_write_unlock are moved in
xen/include/asm-arm/p2m.h to allow inlining. The helpers
p2m_write_unlock is kept in p2m.c because it depends on a static
function.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Patch added
---
 xen/arch/arm/p2m.c| 28 ++--
 xen/include/asm-arm/p2m.h | 27 +++
 2 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c1dac09..fa08e06 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -60,11 +60,6 @@ static inline bool p2m_is_superpage(lpae_t pte, unsigned int 
level)
 return (level < 3) && p2m_mapping(pte);
 }
 
-static inline void p2m_write_lock(struct p2m_domain *p2m)
-{
-write_lock(>lock);
-}
-
 /*
  * Return the start of the next mapping based on the order of the
  * current one.
@@ -83,7 +78,8 @@ static inline gfn_t gfn_next_boundary(gfn_t gfn, unsigned int 
order)
 
 static void p2m_flush_tlb(struct p2m_domain *p2m);
 
-static inline void p2m_write_unlock(struct p2m_domain *p2m)
+/* Unlock the flush and do a P2M TLB flush if necessary */
+void p2m_write_unlock(struct p2m_domain *p2m)
 {
 if ( p2m->need_flush )
 {
@@ -99,26 +95,6 @@ static inline void p2m_write_unlock(struct p2m_domain *p2m)
 write_unlock(>lock);
 }
 
-static inline void p2m_read_lock(struct p2m_domain *p2m)
-{
-read_lock(>lock);
-}
-
-static inline void p2m_read_unlock(struct p2m_domain *p2m)
-{
-read_unlock(>lock);
-}
-
-static inline int p2m_is_locked(struct p2m_domain *p2m)
-{
-return rw_is_locked(>lock);
-}
-
-static inline int p2m_is_write_locked(struct p2m_domain *p2m)
-{
-return rw_is_write_locked(>lock);
-}
-
 void p2m_dump_info(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 cca86ef..1480c5b 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -176,6 +176,33 @@ void p2m_restore_state(struct vcpu *n);
 /* Print debugging/statistial info about a domain's p2m */
 void p2m_dump_info(struct domain *d);
 
+static inline void p2m_write_lock(struct p2m_domain *p2m)
+{
+write_lock(>lock);
+}
+
+void p2m_write_unlock(struct p2m_domain *p2m);
+
+static inline void p2m_read_lock(struct p2m_domain *p2m)
+{
+read_lock(>lock);
+}
+
+static inline void p2m_read_unlock(struct p2m_domain *p2m)
+{
+read_unlock(>lock);
+}
+
+static inline int p2m_is_locked(struct p2m_domain *p2m)
+{
+return rw_is_locked(>lock);
+}
+
+static inline int p2m_is_write_locked(struct p2m_domain *p2m)
+{
+return rw_is_write_locked(>lock);
+}
+
 /* Look up the MFN corresponding to a domain's GFN. */
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
 
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 07/23] xen/arm: traps: Check the P2M before injecting a data/instruction abort

[Julien Grall]

A data/instruction abort may have occurred if another CPU was playing
with the stage-2 page table when following the break-before-make
sequence (see D4.7.1 in ARM DDI 0487A.j). Rather than injecting directly
the fault to the guest, we need to check whether the mapping exists. If
it exists, return to the guest to replay the instruction.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Remove spurious change
- Fix typoes
---
 xen/arch/arm/traps.c | 37 -
 1 file changed, 36 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 76e4152..d73d29a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2405,6 +2405,7 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 register_t gva = READ_SYSREG(FAR_EL2);
 uint8_t fsc = hsr.iabt.ifsc & ~FSC_LL_MASK;
 paddr_t gpa;
+mfn_t mfn;
 
 if ( hpfar_is_valid(hsr.iabt.s1ptw, fsc) )
 gpa = get_faulting_ipa(gva);
@@ -2418,6 +2419,11 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
  */
 flush_tlb_local();
 
+/*
+ * We may not be able to translate because someone is
+ * playing with the Stage-2 page table of the domain.
+ * Return to the guest.
+ */
 rc = gva_to_ipa(gva, , GV2M_READ);
 if ( rc == -EFAULT )
 return; /* Try again */
@@ -2438,8 +2444,17 @@ static void do_trap_instr_abort_guest(struct 
cpu_user_regs *regs,
 /* Trap was triggered by mem_access, work here is done */
 if ( !rc )
 return;
+break;
 }
-break;
+case FSC_FLT_TRANS:
+/*
+ * The PT walk may have failed because someone was playing
+ * with the Stage-2 page table. Walk the Stage-2 PT to check
+ * if the entry exists. If it's the case, return to the guest
+ */
+mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(gpa)), NULL);
+if ( !mfn_eq(mfn, INVALID_MFN) )
+return;
 }
 
 inject_iabt_exception(regs, gva, hsr.len);
@@ -2484,6 +2499,7 @@ static void do_trap_data_abort_guest(struct cpu_user_regs 
*regs,
 int rc;
 mmio_info_t info;
 uint8_t fsc = hsr.dabt.dfsc & ~FSC_LL_MASK;
+mfn_t mfn;
 
 info.dabt = dabt;
 #ifdef CONFIG_ARM_32
@@ -2497,6 +2513,11 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 else
 {
 rc = gva_to_ipa(info.gva, , GV2M_READ);
+/*
+ * We may not be able to translate because someone is
+ * playing with the Stage-2 page table of the domain.
+ * Return to the guest.
+ */
 if ( rc == -EFAULT )
 return; /* Try again */
 }
@@ -2520,11 +2541,25 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 break;
 }
 case FSC_FLT_TRANS:
+/*
+ * Attempt first to emulate the MMIO as the data abort will
+ * likely happen in an emulated region.
+ */
 if ( try_handle_mmio(regs, ) )
 {
 advance_pc(regs, hsr);
 return;
 }
+
+/*
+ * The PT walk may have failed because someone was playing
+ * with the Stage-2 page table. Walk the Stage-2 PT to check
+ * if the entry exists. If it's the case, return to the guest
+ */
+mfn = p2m_lookup(current->domain, _gfn(paddr_to_pfn(info.gpa)), NULL);
+if ( !mfn_eq(mfn, INVALID_MFN) )
+return;
+
 break;
 default:
 gprintk(XENLOG_WARNING, "Unsupported DFSC: HSR=%#x DFSC=%#x\n",
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 21/23] xen/arm: p2m: Re-implement p2m_set_mem_access using p2m_{set, get}_entry

[Julien Grall]

The function p2m_set_mem_access can be re-implemented using the generic
functions p2m_get_entry and __p2m_set_entry.

Also the function apply_p2m_changes is dropped completely as it is not
used anymore.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Cc: Razvan Cojocaru 
Cc: Tamas K Lengyel 

---
Changes in v2:
- Remove level_shifts as it is not used anymore
- Fix multiple bugs in the code
- Use gfn_next_boundary
- Drop the paragraph about performance issue as
Break-Before-Make is not required when only the permission are
changed.
---
 xen/arch/arm/p2m.c | 327 +
 1 file changed, 29 insertions(+), 298 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 734923b..aa740c2 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -34,8 +34,6 @@ static const paddr_t level_sizes[] =
 { ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
 static const paddr_t level_masks[] =
 { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
-static const uint8_t level_shifts[] =
-{ ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
 static const uint8_t level_orders[] =
 { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
 
@@ -1154,295 +1152,6 @@ int p2m_set_entry(struct p2m_domain *p2m,
 return rc;
 }
 
-#define P2M_ONE_DESCEND0
-#define P2M_ONE_PROGRESS_NOP   0x1
-#define P2M_ONE_PROGRESS   0x10
-
-static int p2m_shatter_page(struct p2m_domain *p2m,
-lpae_t *entry,
-unsigned int level)
-{
-const uint8_t level_shift = level_shifts[level];
-int rc = p2m_create_table(p2m, entry, level_shift - PAGE_SHIFT);
-
-if ( !rc )
-{
-p2m->stats.shattered[level]++;
-p2m->stats.mappings[level]--;
-p2m->stats.mappings[level+1] += LPAE_ENTRIES;
-}
-
-return rc;
-}
-
-/*
- * 0   == (P2M_ONE_DESCEND) continue to descend the tree
- * +ve == (P2M_ONE_PROGRESS_*) handled at this level, continue, flush,
- *entry, addr and maddr updated.  Return value is an
- *indication of the amount of work done (for preemption).
- * -ve == (-Exxx) error.
- */
-static int apply_one_level(struct domain *d,
-   lpae_t *entry,
-   unsigned int level,
-   enum p2m_operation op,
-   paddr_t start_gpaddr,
-   paddr_t end_gpaddr,
-   paddr_t *addr,
-   paddr_t *maddr,
-   bool_t *flush,
-   p2m_type_t t,
-   p2m_access_t a)
-{
-const paddr_t level_size = level_sizes[level];
-
-struct p2m_domain *p2m = >arch.p2m;
-lpae_t pte;
-const lpae_t orig_pte = *entry;
-int rc;
-
-BUG_ON(level > 3);
-
-switch ( op )
-{
-case MEMACCESS:
-if ( level < 3 )
-{
-if ( !p2m_valid(orig_pte) )
-{
-*addr += level_size;
-return P2M_ONE_PROGRESS_NOP;
-}
-
-/* Shatter large pages as we descend */
-if ( p2m_mapping(orig_pte) )
-{
-rc = p2m_shatter_page(p2m, entry, level);
-if ( rc < 0 )
-return rc;
-} /* else: an existing table mapping -> descend */
-
-return P2M_ONE_DESCEND;
-}
-else
-{
-pte = orig_pte;
-
-if ( p2m_valid(pte) )
-{
-rc = p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)),
-  a);
-if ( rc < 0 )
-return rc;
-
-p2m_set_permission(, pte.p2m.type, a);
-p2m_write_pte(entry, pte, p2m->clean_pte);
-}
-
-*addr += level_size;
-*flush = true;
-return P2M_ONE_PROGRESS;
-}
-}
-
-BUG(); /* Should never get here */
-}
-
-/*
- * The page is only used by the P2M code which is protected by the p2m->lock.
- * So we can avoid to use atomic helpers.
- */
-static void update_reference_mapping(struct page_info *page,
- lpae_t old_entry,
- lpae_t new_entry)
-{
-if ( p2m_valid(old_entry) && !p2m_valid(new_entry) )
-page->u.inuse.p2m_refcount--;
-else if ( !p2m_valid(old_entry) && p2m_valid(new_entry) )
-page->u.inuse.p2m_refcount++;
-}
-
-static int apply_p2m_changes(struct domain *d,
- enum p2m_operation op,
- gfn_t sgfn,
- unsigned long nr,
- mfn_t smfn,
- uint32_t mask,
- 

[Xen-devel] [for-4.8][PATCH v2 10/23] xen/arm: p2m: Move the lookup helpers at the top of the file

[Julien Grall]

This will be used later in functions that will be defined earlier in the
file.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b4f75e8..413780b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -29,6 +29,14 @@ static unsigned int __read_mostly p2m_root_level;
 
 unsigned int __read_mostly p2m_ipa_bits;
 
+/* Helpers to lookup the properties of each level */
+static const paddr_t level_sizes[] =
+{ ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
+static const paddr_t level_masks[] =
+{ ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
+static const uint8_t level_shifts[] =
+{ ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
+
 static bool_t p2m_valid(lpae_t pte)
 {
 return pte.p2m.valid;
@@ -682,14 +690,6 @@ static bool_t is_mapping_aligned(const paddr_t 
start_gpaddr,
 #define P2M_ONE_PROGRESS_NOP   0x1
 #define P2M_ONE_PROGRESS   0x10
 
-/* Helpers to lookup the properties of each level */
-static const paddr_t level_sizes[] =
-{ ZEROETH_SIZE, FIRST_SIZE, SECOND_SIZE, THIRD_SIZE };
-static const paddr_t level_masks[] =
-{ ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
-static const uint8_t level_shifts[] =
-{ ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
-
 static int p2m_shatter_page(struct p2m_domain *p2m,
 lpae_t *entry,
 unsigned int level)
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 12/23] xen/arm: p2m: Introduce p2m_get_entry and use it to implement __p2m_lookup

[Julien Grall]

Currently, for a given GFN, the function __p2m_lookup will only return
the associated MFN and the p2m type of the mapping.

In some case we need the order of the mapping and the memaccess
permission. Rather than providing a separate function for this purpose,
it is better to implement a generic function to return all the
information.

To avoid passing dummy parameter, a caller that does not need a
specific information can use NULL instead.

The list of the informations retrieved is based on the x86 version. All
of them will be used in follow-up patches.

It might have been possible to extend __p2m_lookup, however I choose to
reimplement it from scratch to allow sharing some helpers with the
function that will update the P2M (will be added in a follow-up patch).

Signed-off-by: Julien Grall 

---
Changes in v2:
- Export p2m_get_entry
- Fix the computation of the order when there is no mapping
- Use level_orders rather than level_shifts - PAGE_SHIFT
- Update documentation
- Fix typoes
- The definition of level_orders has been moved in an earlier
patch
---
 xen/arch/arm/p2m.c| 188 +++---
 xen/include/asm-arm/p2m.h |   8 ++
 2 files changed, 154 insertions(+), 42 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index b2a29ad..6e56b97 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -238,28 +238,104 @@ static lpae_t *p2m_get_root_pointer(struct p2m_domain 
*p2m,
 
 /*
  * Lookup the MFN corresponding to a domain's GFN.
+ * Lookup mem access in the ratrix tree.
+ * The entries associated to the GFN is considered valid.
+ */
+static p2m_access_t p2m_mem_access_radix_get(struct p2m_domain *p2m, gfn_t gfn)
+{
+void *ptr;
+
+if ( !p2m->mem_access_enabled )
+return p2m->default_access;
+
+ptr = radix_tree_lookup(>mem_access_settings, gfn_x(gfn));
+if ( !ptr )
+return p2m_access_rwx;
+else
+return radix_tree_ptr_to_int(ptr);
+}
+
+#define GUEST_TABLE_MAP_FAILED 0
+#define GUEST_TABLE_SUPER_PAGE 1
+#define GUEST_TABLE_NORMAL_PAGE 2
+
+static int p2m_create_table(struct p2m_domain *p2m, lpae_t *entry,
+int level_shift);
+
+/*
+ * Take the currently mapped table, find the corresponding GFN entry,
+ * and map the next table, if available. The previous table will be
+ * unmapped if the next level was mapped (e.g GUEST_TABLE_NORMAL_PAGE
+ * returned).
  *
- * There are no processor functions to do a stage 2 only lookup therefore we
- * do a a software walk.
+ * The read_only parameters indicates whether intermediate tables should
+ * be allocated when not present.
+ *
+ * Return values:
+ *  GUEST_TABLE_MAP_FAILED: Either read_only was set and the entry
+ *  was empty, or allocating a new page failed.
+ *  GUEST_TABLE_NORMAL_PAGE: next level mapped normally
+ *  GUEST_TABLE_SUPER_PAGE: The next entry points to a superpage.
  */
-static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
+static int p2m_next_level(struct p2m_domain *p2m, bool read_only,
+  lpae_t **table, unsigned int offset)
 {
-struct p2m_domain *p2m = >arch.p2m;
-const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
-const unsigned int offsets[4] = {
-zeroeth_table_offset(paddr),
-first_table_offset(paddr),
-second_table_offset(paddr),
-third_table_offset(paddr)
-};
-const paddr_t masks[4] = {
-ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
-};
-lpae_t pte, *map;
+lpae_t *entry;
+int ret;
+mfn_t mfn;
+
+entry = *table + offset;
+
+if ( !p2m_valid(*entry) )
+{
+if ( read_only )
+return GUEST_TABLE_MAP_FAILED;
+
+ret = p2m_create_table(p2m, entry, /* not used */ ~0);
+if ( ret )
+return GUEST_TABLE_MAP_FAILED;
+}
+
+/* The function p2m_next_level is never called at the 3rd level */
+if ( p2m_mapping(*entry) )
+return GUEST_TABLE_SUPER_PAGE;
+
+mfn = _mfn(entry->p2m.base);
+
+unmap_domain_page(*table);
+*table = map_domain_page(mfn);
+
+return GUEST_TABLE_NORMAL_PAGE;
+}
+
+/*
+ * Get the details of a given gfn.
+ *
+ * If the entry is present, the associated MFN will be returned and the
+ * access and type filled up. The page_order will correspond to the
+ * order of the mapping in the page table (i.e it could be a superpage).
+ *
+ * If the entry is not present, INVALID_MFN will be returned and the
+ * page_order will be set according to the order of the invalid range.
+ */
+mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
+p2m_type_t *t, p2m_access_t *a,
+unsigned int *page_order)
+{
+paddr_t addr = pfn_to_paddr(gfn_x(gfn));
+unsigned int level = 0;
+lpae_t entry, *table;
+int rc;
 mfn_t mfn = INVALID_MFN;
-paddr_t mask = 0;
 p2m_type_t _t;
-

[Xen-devel] [for-4.8][PATCH v2 17/23] xen/arm: p2m: Introduce p2m_set_entry and __p2m_set_entry

[Julien Grall]

The ARM architecture mandates to use of a break-before-make sequence
when changing translation entries if the page table is shared between
multiple CPUs whenever a valid entry is replaced by another valid entry
(see D4.7.1 in ARM DDI 0487A.j for more details).

The break-before-make sequence can be divided in the following steps:
1) Invalidate the old entry in the page table
2) Issue a TLB invalidation instruction for the address associated
to this entry
3) Write the new entry

The current P2M code implemented in apply_one_level does not respect
this sequence and may result to break coherency on some processors.

Adapting the current implementation to use the break-before-make
sequence would imply some code duplication and more TLBs invalidation
than necessary. For instance, if we are replacing a 4KB page and the
current mapping in the P2M is using a 1GB superpage, the following steps
will happen:
1) Shatter the 1GB superpage into a series of 2MB superpages
2) Shatter the 2MB superpage into a series of 4KB pages
3) Replace the 4KB page

As the current implementation is shattering while descending and install
the mapping, Xen would need to issue 3 TLB invalidation instructions
which is clearly inefficient.

Furthermore, all the operations which modify the page table are using
the same skeleton. It is more complicated to maintain different code paths
than having a generic function that set an entry and take care of the
break-before-make sequence.

The new implementation is based on the x86 EPT one which, I think,
fits quite well for the break-before-make sequence whilst keeping
the code simple.

The main function of the new implementation is __p2m_set_entry. It will
only work on mapping that are aligned to a block entry in the page table
(i.e 1GB, 2MB, 4KB when using a 4KB granularity).

Another function, p2m_set_entry, is provided to break down is region
into mapping that is aligned to a block entry or 4KB when memaccess is
enabled.

Signed-off-by: Julien Grall 

---
Changes in v2:
- fix typoes in the commit message
- don't use the default access when shattering the superpage
- remove duplicated comment
- export p2m_set_entry
- s/todo/nr/
- iommu flush
- update the stats when removing/adding a mapping
- update doc
- fix p2m_split_superpage
- don't try to allocate intermediate page table when removing an
entry
- the TLB flush is not necessary when only permission are
changed (e.g memaccess).
---
 xen/arch/arm/p2m.c | 374 +
 xen/include/asm-arm/p2m.h  |  11 ++
 xen/include/asm-arm/page.h |   4 +
 3 files changed, 389 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 3ca2e90..5f7aef0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -783,6 +783,380 @@ static void p2m_put_l3_page(const lpae_t pte)
 }
 }
 
+/* Free lpae sub-tree behind an entry */
+static void p2m_free_entry(struct p2m_domain *p2m,
+   lpae_t entry, unsigned int level)
+{
+unsigned int i;
+lpae_t *table;
+mfn_t mfn;
+
+/* Nothing to do if the entry is invalid. */
+if ( !p2m_valid(entry) )
+return;
+
+/* Nothing to do but updating the states if the entry is a super-page. */
+if ( p2m_is_superpage(entry, level) )
+{
+p2m->stats.mappings[level]--;
+return;
+}
+
+if ( level == 3 )
+{
+p2m->stats.mappings[level]--;
+p2m_put_l3_page(entry);
+return;
+}
+
+table = map_domain_page(_mfn(entry.p2m.base));
+for ( i = 0; i < LPAE_ENTRIES; i++ )
+p2m_free_entry(p2m, *(table + i), level + 1);
+
+unmap_domain_page(table);
+
+/*
+ * Make sure all the references in the TLB have been removed before
+ * freing the intermediate page table.
+ * XXX: Should we defer the free of the page table to avoid the
+ * flush?
+ */
+if ( p2m->need_flush )
+p2m_flush_tlb_sync(p2m);
+
+mfn = _mfn(entry.p2m.base);
+ASSERT(mfn_valid(mfn_x(mfn)));
+
+free_domheap_page(mfn_to_page(mfn_x(mfn)));
+}
+
+static bool p2m_split_superpage(struct p2m_domain *p2m, lpae_t *entry,
+unsigned int level, unsigned int target,
+const unsigned int *offsets)
+{
+struct page_info *page;
+unsigned int i;
+lpae_t pte, *table;
+bool rv = true;
+
+/* Convenience aliases */
+mfn_t mfn = _mfn(entry->p2m.base);
+unsigned int next_level = level + 1;
+unsigned int level_order = level_orders[next_level];
+
+/*
+ * This should only be called with target != level and the entry is
+ * a superpage.
+ */
+ASSERT(level < target);
+ASSERT(p2m_is_superpage(*entry, level));
+
+page = alloc_domheap_page(NULL, 0);
+if ( !page )
+return false;
+
+

[Xen-devel] [for-4.8][PATCH v2 18/23] xen/arm: p2m: Re-implement relinquish_p2m_mapping using p2m_{get, set}_entry

[Julien Grall]

The function relinquish_p2m_mapping can be re-implemented using
p2m_{get,set}_entry by iterating over the range mapped and using the
mapping order given by the callee.

Given that the preemption was chosen arbitrarily, it is now done on every
512 iterations. Meaning that Xen may check more often if the function is
preempted when there are no mappings.

Finally drop the operation RELINQUISH in apply_* as nobody is using it
anymore. Note that the functions could have been dropped in one go at
the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that remove the last operation.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Erase entry one by one as I have not time so far to check
whether it is possible to avoid removing entry in the p2m.
- Use gfn_next_boundary
---
 xen/arch/arm/p2m.c | 77 +-
 1 file changed, 59 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5f7aef0..ce09c4c 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -754,7 +754,6 @@ static int p2m_mem_access_radix_set(struct p2m_domain *p2m, 
gfn_t gfn,
 enum p2m_operation {
 INSERT,
 REMOVE,
-RELINQUISH,
 MEMACCESS,
 };
 
@@ -1318,7 +1317,6 @@ static int apply_one_level(struct domain *d,
 
 break;
 
-case RELINQUISH:
 case REMOVE:
 if ( !p2m_valid(orig_pte) )
 {
@@ -1502,17 +1500,6 @@ static int apply_p2m_changes(struct domain *d,
 {
 switch ( op )
 {
-case RELINQUISH:
-/*
- * Arbitrarily, preempt every 512 operations or 8192 nops.
- * 512*P2M_ONE_PROGRESS == 8192*P2M_ONE_PROGRESS_NOP == 0x2000
- * This is set in preempt_count_limit.
- *
- */
-p2m->lowest_mapped_gfn = _gfn(addr >> PAGE_SHIFT);
-rc = -ERESTART;
-goto out;
-
 case MEMACCESS:
 {
 /*
@@ -1919,16 +1906,70 @@ int p2m_init(struct domain *d)
 return rc;
 }
 
+/*
+ * The function will go through the p2m and remove page reference when it
+ * is required. The mapping will be removed from the p2m.
+ *
+ * XXX: See whether the mapping can be left intact in the p2m.
+ */
 int relinquish_p2m_mapping(struct domain *d)
 {
 struct p2m_domain *p2m = >arch.p2m;
-unsigned long nr;
+unsigned long count = 0;
+p2m_type_t t;
+int rc = 0;
+unsigned int order;
+
+/* Convenience alias */
+gfn_t start = p2m->lowest_mapped_gfn;
+gfn_t end = p2m->max_mapped_gfn;
+
+p2m_write_lock(p2m);
+
+for ( ; gfn_x(start) < gfn_x(end);
+  start = gfn_next_boundary(start, order) )
+{
+mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
+
+count++;
+/*
+ * Arbitrarily preempt every 512 iterations.
+ */
+if ( !(count % 512) && hypercall_preempt_check() )
+{
+rc = -ERESTART;
+break;
+}
 
-nr = gfn_x(p2m->max_mapped_gfn) - gfn_x(p2m->lowest_mapped_gfn);
+/*
+ * p2m_set_entry will take care of removing reference on page
+ * when it is necessary and removing the mapping in the p2m.
+ */
+if ( !mfn_eq(mfn, INVALID_MFN) )
+{
+/*
+ * For valid mapping, the start will always be aligned as
+ * entry will be removed whilst relinquishing.
+ */
+rc = __p2m_set_entry(p2m, start, order, INVALID_MFN,
+ p2m_invalid, p2m_access_rwx);
+if ( unlikely(rc) )
+{
+printk(XENLOG_G_ERR "Unable to remove mapping gfn=%#"PRI_gfn" 
order=%u from the p2m of domain %d\n", gfn_x(start), order, d->domain_id);
+break;
+}
+}
+}
 
-return apply_p2m_changes(d, RELINQUISH, p2m->lowest_mapped_gfn, nr,
- INVALID_MFN, 0, p2m_invalid,
- d->arch.p2m.default_access);
+/*
+ * Update lowest_mapped_gfn so on the next call we still start where
+ * we stopped.
+ */
+p2m->lowest_mapped_gfn = start;
+
+p2m_write_unlock(p2m);
+
+return rc;
 }
 
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 16/23] xen/arm: p2m: Introduce a helper to check if an entry is a superpage

[Julien Grall]

Use the level and the entry to know whether an entry is a superpage.
A superpage can only happen below level 3.

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

---
Changes in v2:
- Use bool instead of bool_t
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9f0f896..3ca2e90 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -57,6 +57,11 @@ static inline bool_t p2m_mapping(lpae_t pte)
 return p2m_valid(pte) && !pte.p2m.table;
 }
 
+static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
+{
+return (level < 3) && p2m_mapping(pte);
+}
+
 static inline void p2m_write_lock(struct p2m_domain *p2m)
 {
 write_lock(>lock);
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 14/23] xen/arm: p2m: Re-implement p2m_cache_flush using p2m_get_entry

[Julien Grall]

The function p2m_cache_flush can be re-implemented using the generic
function p2m_get_entry by iterating over the range and using the mapping
order given by the callee.

As the current implementation, no preemption is implemented, although
the comment in the current code claimed it. As the function is called by
a DOMCTL with a region of 1GB maximum, I think the preemption can be
left unimplemented for now.

Finally drop the operation CACHEFLUSH in apply_one_level as nobody is
using it anymore. Note that the function could have been dropped in one
go at the end, however I find easier to drop the operations one by one
avoiding a big deletion in the patch that convert the last operation.

Signed-off-by: Julien Grall 

---
The loop pattern will be very similar for the reliquish function.
It might be possible to extract it in a separate function.

Changes in v2:
- Introduce and use gfn_next_boundary
- Flush all the mapping in a superpage rather than page by page.
- Update doc
---
 xen/arch/arm/p2m.c | 83 --
 1 file changed, 50 insertions(+), 33 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ddee258..fa58f1a 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -62,6 +62,22 @@ static inline void p2m_write_lock(struct p2m_domain *p2m)
 write_lock(>lock);
 }
 
+/*
+ * Return the start of the next mapping based on the order of the
+ * current one.
+ */
+static inline gfn_t gfn_next_boundary(gfn_t gfn, unsigned int order)
+{
+/*
+ * The order corresponds to the order of the mapping (or invalid
+ * range) in the page table. So we need to align the GFN before
+ * incrementing.
+ */
+gfn = _gfn(gfn_x(gfn) & ~((1UL << order) - 1));
+
+return gfn_add(gfn, 1UL << order);
+}
+
 static void p2m_flush_tlb(struct p2m_domain *p2m);
 
 static inline void p2m_write_unlock(struct p2m_domain *p2m)
@@ -734,7 +750,6 @@ enum p2m_operation {
 INSERT,
 REMOVE,
 RELINQUISH,
-CACHEFLUSH,
 MEMACCESS,
 };
 
@@ -993,36 +1008,6 @@ static int apply_one_level(struct domain *d,
  */
 return P2M_ONE_PROGRESS;
 
-case CACHEFLUSH:
-if ( !p2m_valid(orig_pte) )
-{
-*addr = (*addr + level_size) & level_mask;
-return P2M_ONE_PROGRESS_NOP;
-}
-
-if ( level < 3 && p2m_table(orig_pte) )
-return P2M_ONE_DESCEND;
-
-/*
- * could flush up to the next superpage boundary, but would
- * need to be careful about preemption, so just do one 4K page
- * now and return P2M_ONE_PROGRESS{,_NOP} so that the caller will
- * continue to loop over the rest of the range.
- */
-if ( p2m_is_ram(orig_pte.p2m.type) )
-{
-unsigned long offset = paddr_to_pfn(*addr & ~level_mask);
-flush_page_to_ram(orig_pte.p2m.base + offset);
-
-*addr += PAGE_SIZE;
-return P2M_ONE_PROGRESS;
-}
-else
-{
-*addr += PAGE_SIZE;
-return P2M_ONE_PROGRESS_NOP;
-}
-
 case MEMACCESS:
 if ( level < 3 )
 {
@@ -1571,12 +1556,44 @@ int p2m_cache_flush(struct domain *d, gfn_t start, 
unsigned long nr)
 {
 struct p2m_domain *p2m = >arch.p2m;
 gfn_t end = gfn_add(start, nr);
+gfn_t next_gfn;
+p2m_type_t t;
+unsigned int order;
 
 start = gfn_max(start, p2m->lowest_mapped_gfn);
 end = gfn_min(end, p2m->max_mapped_gfn);
 
-return apply_p2m_changes(d, CACHEFLUSH, start, nr, INVALID_MFN,
- 0, p2m_invalid, d->arch.p2m.default_access);
+/*
+ * The operation cache flush will invalidate the RAM assigned to the
+ * guest in a given range. It will not modify the page table and
+ * flushing the cache whilst the page is used by another CPU is
+ * fine. So using read-lock is fine here.
+ */
+p2m_read_lock(p2m);
+
+for ( ; gfn_x(start) < gfn_x(end); start = next_gfn )
+{
+mfn_t mfn = p2m_get_entry(p2m, start, , NULL, );
+
+next_gfn = gfn_next_boundary(start, order);
+
+/* Skip hole and non-RAM page */
+if ( mfn_eq(mfn, INVALID_MFN) || !p2m_is_ram(t) )
+continue;
+
+/* XXX: Implement preemption */
+while ( gfn_x(start) < gfn_x(next_gfn) )
+{
+flush_page_to_ram(mfn_x(mfn));
+
+start = gfn_add(start, 1);
+mfn = mfn_add(mfn, 1);
+}
+}
+
+p2m_read_unlock(p2m);
+
+return 0;
 }
 
 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 03/23] xen/arm: p2m: Rename parameter in p2m_{remove, write}_pte...

[Julien Grall]

to make clear of the usage. I.e it is used to inform whether Xen needs
to clean the entry after writing in the page table.

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

---
Changes in v2:
- Add Stefano's acked-by
---
 xen/arch/arm/p2m.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f482cfd..5a1d45b 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -390,19 +390,19 @@ static lpae_t mfn_to_p2m_entry(mfn_t mfn, p2m_type_t t, 
p2m_access_t a)
 return e;
 }
 
-static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool_t flush_cache)
+static inline void p2m_write_pte(lpae_t *p, lpae_t pte, bool clean_pte)
 {
 write_pte(p, pte);
-if ( flush_cache )
+if ( clean_pte )
 clean_dcache(*p);
 }
 
-static inline void p2m_remove_pte(lpae_t *p, bool_t flush_cache)
+static inline void p2m_remove_pte(lpae_t *p, bool clean_pte)
 {
 lpae_t pte;
 
 memset(, 0x00, sizeof(pte));
-p2m_write_pte(p, pte, flush_cache);
+p2m_write_pte(p, pte, clean_pte);
 }
 
 /*
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 11/23] xen/arm: p2m: Introduce p2m_get_root_pointer and use it in __p2m_lookup

[Julien Grall]

Mapping the root table is always done the same way. To avoid duplicating
the code in a later patch, move the code in a separate helper.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Use level_orders rather than level_shifts - PAGE_SHIFT
- Move the definition of level_orders in this patch
* use uint8_t rather than unsigned
* define *_ORDER in term of *_SHIFT
---
 xen/arch/arm/p2m.c | 55 +++---
 xen/include/asm-arm/page.h |  4 
 2 files changed, 41 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 413780b..b2a29ad 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -36,6 +36,8 @@ static const paddr_t level_masks[] =
 { ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK };
 static const uint8_t level_shifts[] =
 { ZEROETH_SHIFT, FIRST_SHIFT, SECOND_SHIFT, THIRD_SHIFT };
+static const uint8_t level_orders[] =
+{ ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
 
 static bool_t p2m_valid(lpae_t pte)
 {
@@ -204,6 +206,37 @@ static void p2m_flush_tlb_sync(struct p2m_domain *p2m)
 }
 
 /*
+ * Find and map the root page table. The caller is responsible for
+ * unmapping the table.
+ *
+ * The function will return NULL if the offset of the root table is
+ * invalid.
+ */
+static lpae_t *p2m_get_root_pointer(struct p2m_domain *p2m,
+gfn_t gfn)
+{
+unsigned int root_table;
+
+if ( P2M_ROOT_PAGES == 1 )
+return __map_domain_page(p2m->root);
+
+/*
+ * Concatenated root-level tables. The table number will be the
+ * offset at the previous level. It is not possible to
+ * concatenate a level-0 root.
+ */
+ASSERT(P2M_ROOT_LEVEL > 0);
+
+root_table = gfn_x(gfn) >> (level_orders[P2M_ROOT_LEVEL - 1]);
+root_table &= LPAE_ENTRY_MASK;
+
+if ( root_table >= P2M_ROOT_PAGES )
+return NULL;
+
+return __map_domain_page(p2m->root + root_table);
+}
+
+/*
  * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
@@ -226,7 +259,7 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
p2m_type_t *t)
 mfn_t mfn = INVALID_MFN;
 paddr_t mask = 0;
 p2m_type_t _t;
-unsigned int level, root_table;
+unsigned int level;
 
 ASSERT(p2m_is_locked(p2m));
 BUILD_BUG_ON(THIRD_MASK != PAGE_MASK);
@@ -236,22 +269,9 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
p2m_type_t *t)
 
 *t = p2m_invalid;
 
-if ( P2M_ROOT_PAGES > 1 )
-{
-/*
- * Concatenated root-level tables. The table number will be
- * the offset at the previous level. It is not possible to
- * concatenate a level-0 root.
- */
-ASSERT(P2M_ROOT_LEVEL > 0);
-root_table = offsets[P2M_ROOT_LEVEL - 1];
-if ( root_table >= P2M_ROOT_PAGES )
-goto err;
-}
-else
-root_table = 0;
-
-map = __map_domain_page(p2m->root + root_table);
+map = p2m_get_root_pointer(p2m, gfn);
+if ( !map )
+return INVALID_MFN;
 
 ASSERT(P2M_ROOT_LEVEL < 4);
 
@@ -286,7 +306,6 @@ static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, 
p2m_type_t *t)
 *t = pte.p2m.type;
 }
 
-err:
 return mfn;
 }
 
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..a43b0fa 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -457,15 +457,19 @@ static inline int gva_to_ipa(vaddr_t va, paddr_t *paddr, 
unsigned int flags)
 #define LPAE_ENTRY_MASK (LPAE_ENTRIES - 1)
 
 #define THIRD_SHIFT(PAGE_SHIFT)
+#define THIRD_ORDER(THIRD_SHIFT - PAGE_SHIFT)
 #define THIRD_SIZE ((paddr_t)1 << THIRD_SHIFT)
 #define THIRD_MASK (~(THIRD_SIZE - 1))
 #define SECOND_SHIFT   (THIRD_SHIFT + LPAE_SHIFT)
+#define SECOND_ORDER   (SECOND_SHIFT - PAGE_SHIFT)
 #define SECOND_SIZE((paddr_t)1 << SECOND_SHIFT)
 #define SECOND_MASK(~(SECOND_SIZE - 1))
 #define FIRST_SHIFT(SECOND_SHIFT + LPAE_SHIFT)
+#define FIRST_ORDER(FIRST_SHIFT - PAGE_SHIFT)
 #define FIRST_SIZE ((paddr_t)1 << FIRST_SHIFT)
 #define FIRST_MASK (~(FIRST_SIZE - 1))
 #define ZEROETH_SHIFT  (FIRST_SHIFT + LPAE_SHIFT)
+#define ZEROETH_ORDER  (ZEROETH_SHIFT - PAGE_SHIFT)
 #define ZEROETH_SIZE   ((paddr_t)1 << ZEROETH_SHIFT)
 #define ZEROETH_MASK   (~(ZEROETH_SIZE - 1))
 
-- 
1.9.1


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

[Xen-devel] [for-4.8][PATCH v2 04/23] xen/arm: p2m: Use typesafe gfn in p2m_mem_access_radix_set

[Julien Grall]

p2m_mem_access_radix_set is expecting a gfn in a parameter. Rename the
parameter 'pfn' to 'gfn' to match its content and use the typesafe gfn
to avoid possible misusage.

Also rename the parameter to gfn to match its content.

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

---
Changes in v2:
- Add Stefano's reviewed-by
---
 xen/arch/arm/p2m.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 5a1d45b..950a607 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -550,7 +550,7 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
 return 0;
 }
 
-static int p2m_mem_access_radix_set(struct p2m_domain *p2m, unsigned long pfn,
+static int p2m_mem_access_radix_set(struct p2m_domain *p2m, gfn_t gfn,
 p2m_access_t a)
 {
 int rc;
@@ -560,18 +560,18 @@ static int p2m_mem_access_radix_set(struct p2m_domain 
*p2m, unsigned long pfn,
 
 if ( p2m_access_rwx == a )
 {
-radix_tree_delete(>mem_access_settings, pfn);
+radix_tree_delete(>mem_access_settings, gfn_x(gfn));
 return 0;
 }
 
-rc = radix_tree_insert(>mem_access_settings, pfn,
+rc = radix_tree_insert(>mem_access_settings, gfn_x(gfn),
radix_tree_int_to_ptr(a));
 if ( rc == -EEXIST )
 {
 /* If a setting already exists, change it to the new one */
 radix_tree_replace_slot(
 radix_tree_lookup_slot(
->mem_access_settings, pfn),
+>mem_access_settings, gfn_x(gfn)),
 radix_tree_int_to_ptr(a));
 rc = 0;
 }
@@ -715,7 +715,7 @@ static int apply_one_level(struct domain *d,
 */
  (level == 3 || (!p2m_table(orig_pte) && 
!p2m->mem_access_enabled)) )
 {
-rc = p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), a);
+rc = p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)), a);
 if ( rc < 0 )
 return rc;
 
@@ -833,7 +833,8 @@ static int apply_one_level(struct domain *d,
 *flush = true;
 
 p2m_remove_pte(entry, p2m->clean_pte);
-p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), p2m_access_rwx);
+p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)),
+ p2m_access_rwx);
 
 *addr += level_size;
 *maddr += level_size;
@@ -904,7 +905,8 @@ static int apply_one_level(struct domain *d,
 
 if ( p2m_valid(pte) )
 {
-rc = p2m_mem_access_radix_set(p2m, paddr_to_pfn(*addr), a);
+rc = p2m_mem_access_radix_set(p2m, _gfn(paddr_to_pfn(*addr)),
+  a);
 if ( rc < 0 )
 return rc;
 
-- 
1.9.1


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

[Xen-devel] [xen-4.6-testing baseline-only test] 67715: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67715 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67715/

Regressions :-(

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

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 build-i386-rumprun5 rumprun-buildfail   never pass
 build-amd64-rumprun   5 rumprun-buildfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH V1] xen/arm: domain_build: introduce dom0_lowmem bootargs

[Peng Fan]

Hi Edgar,
On Thu, Sep 15, 2016 at 10:26:46AM +0200, Edgar E. Iglesias wrote:
>On Thu, Sep 15, 2016 at 08:20:33AM +0800, Peng Fan wrote:
>> Hi Edgar,
>> On Wed, Sep 14, 2016 at 04:16:58PM +0200, Edgar E. Iglesias wrote:
>> >On Wed, Sep 14, 2016 at 08:40:09PM +0800, Peng Fan wrote:
>> >> On Wed, Sep 14, 2016 at 01:34:10PM +0100, Julien Grall wrote:
>> >> >
>> >> >
>> >> >On 14/09/16 13:18, Peng Fan wrote:
>> >> >>Hello Julien,
>> >> >>
>> >> >>On Wed, Sep 14, 2016 at 01:06:01PM +0100, Julien Grall wrote:
>> >> >>>
>> >> >>>
>> >> >>>On 14/09/16 13:03, Peng Fan wrote:
>> >> Hello Julien,
>> >> >>>
>> >> >>>Hello Peng,
>> >> >>>
>> >> On Wed, Sep 14, 2016 at 11:47:10AM +0100, Julien Grall wrote:
>> >> >Hello,
>> >> >
>> >> >On 14/09/16 08:41, Peng Fan wrote:
>> >> >>On Wed, Sep 14, 2016 at 08:23:24AM +0100, Julien Grall wrote:
>> >> >>diff --git a/xen/arch/arm/domain_build.c 
>> >> >>b/xen/arch/arm/domain_build.c
>> >> >>index 35ab08d..cc71e6f 100644
>> >> >>--- a/xen/arch/arm/domain_build.c
>> >> >>+++ b/xen/arch/arm/domain_build.c
>> >> >>@@ -28,6 +28,8 @@
>> >> >>
>> >> >>static unsigned int __initdata opt_dom0_max_vcpus;
>> >> >>integer_param("dom0_max_vcpus", opt_dom0_max_vcpus);
>> >> >>+static bool_t __initdata opt_dom0_use_lowmem;
>> >> >>+boolean_param("dom0_use_lowmem", opt_dom0_use_lowmem);
>> >> >>
>> >> >>int dom0_11_mapping = 1;
>> >> >>
>> >> >>@@ -244,7 +246,7 @@ static void allocate_memory(struct domain *d, 
>> >> >>struct
>> >> >>kernel_info *kinfo)
>> >> >>   unsigned int order = 
>> >> >> get_11_allocation_size(kinfo->unassigned_mem);
>> >> >>   int i;
>> >> >>
>> >> >>-bool_t lowmem = is_32bit_domain(d);
>> >> >>+bool_t lowmem = is_32bit_domain(d) || opt_dom0_use_lowmem;
>> >> >>   unsigned int bits;
>> >> >>
>> >> >>
>> >> >>Pass "dom0_use_lowmem=1" to xen to allocate lowmem as much as 
>> >> >>possible.
>> >> >
>> >> >Again, what is the benefit to have a command line option for that?
>> >> 
>> >> Then you prefer directly change "bool_t lowmem = is_32bit_domain(d);" 
>> >> to "bool_t lowmem = true" ?
>> >> I just want to give user a choice.
>> >> >>>
>> >> >>>We don't add new command line parameter just because they look cool to 
>> >> >>>have.
>> >> >>>So far, you did not explain why it would be good to let the choice to 
>> >> >>>the
>> >> >>>user and how it could be used.
>> >> >>
>> >> >>I have not try, if there is no lowmem.
>> >> >>
>> >> >>I have not look into alloc_domheap_pages.
>> >> >>I am not sure whether there is such a platform or not,
>> >> >>just thinking if there is soc that dram memory starts from 4GB, and 
>> >> >>there is no dram
>> >> >>below 4GB. If we still can get memory when lowmem is true, I am ok to 
>> >> >>change directly assign
>> >> >>lowmem with value true. Anyway I have not look into the internals of 
>> >> >>domheap and
>> >> >>not sure whether there is such a platform that no lowmem (:-
>> >> >
>> >> >We cannot exclude this possibility. However, the only reason that Xen is
>> >> >requiring to allocate a bank below 4GB for 32-bit domain is to handle
>> >> >non-LPAE kernel.
>> >> 
>> >> Now also need to handle device that have DMA limitation -:)
>> >
>> >Hi Peng,
>> >
>> >Doesn't your platform have an IOMMU/SMMU?
>> 
>> We have SMMU. This is not related to SMMU. Dom0 use 1:1 mapping and no SMMU 
>> involved,
>> the physical memory assigned to Dom0 maybe higher than 4GB, but Some IPs only
>> supports 32bits DMA in Dom0. Then assign a 64bits dma address to a device 
>> only supports 32
>> bits device in Linux will hang the device or else.
>
>Well, I think it is somewhat related to the IOMMU.
>
>If your SMMU supports S1 + S2 translations, allthough not supported
>by Xen/ARM today, we could support nested SMMU's so that Dom0 could
>get it's own private S1 portion of the SMMU.

For DomU or hardware domain, I think supporting SMMU with Linux S1 + XEN S2 is 
a good feature to have.
For Dom0, I think no need to use S1 + S2 for SMMU, It is control domain.

>
>Another option is to perhaps join into the efforts of PV-IOMMU
>and try to see if it would work for Xen on ARM:
>https://lists.xen.org/archives/html/xen-devel/2016-02/msg01428.html

This is new to me -:) Will get back to you when I know more about this.

>
>For platforms that have an IOMMU, I think both of these options may
>solve the use-case of dom0 using 32bit DMA devs without any lowmem.
>In addition to that, these features would be very nice as they also
>enable DMA API isolation and VFIO user-space drivers in dom0.
>Spending time on these kind of options seems worthwhile to me.

If SMMU S1 is supported, we could use VFIO. This's good feature to have.
If you have any progress or new update, please kindly CC me. I am happy
to see this.

>
>With 32bit DMA devs, without an IOMMU, lowmem becomes critical but
>such systems are not really 

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

[osstest service owner]

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

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  167291f0d6b87ccb1f1f4c4f73e9231b811ead03
baseline version:
 xen  3ab5fb9a9eeb2b610d5d74419e0b1ffaf18484f2

Last test of basis   100961  2016-09-15 02:02:06 Z0 days
Testing same since   100964  2016-09-15 09:02:49 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=167291f0d6b87ccb1f1f4c4f73e9231b811ead03
+ . ./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 
167291f0d6b87ccb1f1f4c4f73e9231b811ead03
+ branch=xen-unstable-smoke
+ revision=167291f0d6b87ccb1f1f4c4f73e9231b811ead03
+ . ./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
+ '[' x167291f0d6b87ccb1f1f4c4f73e9231b811ead03 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v5 16/16] libxl/arm: Add the size of ACPI tables to maxmem

[Wei Liu]

On Tue, Sep 13, 2016 at 11:38:35AM +0100, Julien Grall wrote:
> Hi Shannon,
> 
> On 13/09/16 08:03, Shannon Zhao wrote:
> >
> >
> >On 2016/9/12 23:18, Julien Grall wrote:
> >>Hi Shannon,
> >>
> >>On 02/09/16 03:55, Shannon Zhao wrote:
> >>>From: Shannon Zhao 
> >>>
> >>>Here it adds the ACPI tables size to set the target maxmem to avoid
> >>>providing less available memory for guest.
> >>>
> >>>Signed-off-by: Shannon Zhao 
> >>>---
> >>> tools/libxl/libxl_arch.h|  2 +-
> >>> tools/libxl/libxl_arm.c | 18 +-
> >>> tools/libxl/libxl_arm.h |  4 
> >>> tools/libxl/libxl_arm_acpi.c| 20 
> >>> tools/libxl/libxl_arm_no_acpi.c |  6 ++
> >>> tools/libxl/libxl_dom.c |  2 +-
> >>> tools/libxl/libxl_x86.c |  2 +-
> >>> 7 files changed, 50 insertions(+), 4 deletions(-)
> >>>
> >>>diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
> >>>index 337061f..d62fa4c 100644
> >>>--- a/tools/libxl/libxl_arch.h
> >>>+++ b/tools/libxl/libxl_arch.h
> >>>@@ -30,7 +30,7 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
> >>> /* arch specific internal domain creation function */
> >>> _hidden
> >>> int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config
> >>>*d_config,
> >>>-   uint32_t domid);
> >>>+  libxl__domain_build_state *state,
> >>>uint32_t domid);
> >>>
> >>> /* setup arch specific hardware description, i.e. DTB on ARM */
> >>> _hidden
> >>>diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> >>>index e73d65e..c7d4f65 100644
> >>>--- a/tools/libxl/libxl_arm.c
> >>>+++ b/tools/libxl/libxl_arm.c
> >>>@@ -101,8 +101,24 @@ int libxl__arch_domain_save_config(libxl__gc *gc,
> >>> }
> >>>
> >>> int libxl__arch_domain_create(libxl__gc *gc, libxl_domain_config
> >>>*d_config,
> >>>-  uint32_t domid)
> >>>+  libxl__domain_build_state *state,
> >>>uint32_t domid)
> >>> {
> >>>+libxl_domain_build_info *const info = _config->b_info;
> >>>+libxl_ctx *ctx = libxl__gc_owner(gc);
> >>>+int size;
> >>>+
> >>>+/* Add the size of ACPI tables to maxmem if ACPI is enabled for
> >>>guest. */
> >>>+if (libxl_defbool_val(info->acpi)) {
> >>>+size = libxl__get_acpi_size(gc, info, state);
> >>>+if (size < 0)
> >>>+return ERROR_FAIL;
> >>>+if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> >>>+LIBXL_MAXMEM_CONSTANT + (size + 1023)
> >>>/ 1024)) {
> >>
> >>I still have some concern about use info->target_memkb +
> >>LIBXL_MAXMEM_CONSTANT here. What if the generic code decide to change
> >>the computation?
> >>
> >>We may forgot to replicate here. My suggestion on the previous version
> >>was to have in the common code
> >>
> >>xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> >>LIBXL_MAXMEM_CONSTANT + libxl__arch_memory_constant());
> >>
> >>Or a similar name.
> >>
> >Just to confirm, do you mean that having a arch function to get the size
> >each arch needs and adding the size in libxl__build_pre()?
> 
> That's correct. Wei, Ian, do you have any opinions on this?
> 

I'm fine with that.

Wei.

> Regards,
> 
> -- 
> Julien Grall

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

[Xen-devel] [distros-debian-wheezy test] 67716: all pass

[Platform Team regression test user]

flight 67716 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67716/

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   67673

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  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.


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

Re: [Xen-devel] [RFC 20/22] xen/arm: p2m: Re-implement p2m_insert_mapping using p2m_set_entry

[Julien Grall]

Hi Stefano,

On 06/09/2016 19:57, Stefano Stabellini wrote:

On Thu, 28 Jul 2016, Julien Grall wrote:

The function p2m_insert_mapping can be re-implemented using the generic
function p2m_set_entry.

Note that the mapping is not reverted anymore if Xen fails to insert a
mapping. This was added to ensure the MMIO are not kept half-mapped
in case of failure and to follow the x86 counterpart. This was removed
on the x86 part by commit c3c756bd "x86/p2m: use large pages for MMIO
mappings" and I think we should let the caller taking care of it.

Finally drop the operation INSERT in apply_* as nobody is using it
anymore. Note that the functios could have been dropped in one go at the

   ^ functions


end, however I find easier to drop the operations one by one avoiding a
big deletion in the patch that convert the last operation.

Signed-off-by: Julien Grall 

---
Whilst there is no safety checks on what is replaced in the P2M
(such as foreign/grant mapping as x86 does), we may want to add it
ensuring the guest is not doing something dumb. Any opinions?


We don't necessarily need to protect a guest from its own dumbness, as
long as we can correctly deal with it (account for grant and foreign
mappings replaced this way).


I think this could be a good improvement for the future and help 
debugging potential bug in the guest.


Anyway, it is not strictly necessary today given that all the reference 
counting should be done properly. I will add it in my todo list.




Given that the old code doesn't do it anyway:

Reviewed-by: Stefano Stabellini 


Thank you!

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/2] vm_event: Sanitize vm_event response handling

[George Dunlap]

On 14/09/16 16:11, Tamas K Lengyel wrote:
> On Wed, Sep 14, 2016 at 7:38 AM, George Dunlap  
> wrote:
>> On 13/09/16 19:12, Tamas K Lengyel wrote:
>>> Setting response flags in vm_event are only ever safe if the vCPUs are 
>>> paused.
>>> To reflect this we move all checks within the if block that already checks
>>> whether this is the case. Checks that are only supported on one architecture
>>> we relocate the bitmask operations to the arch-specific handlers to avoid
>>> the overhead on architectures that don't support it.
>>>
>>> Furthermore, we clean-up the emulation checks so it more clearly represents 
>>> the
>>> decision-logic when emulation should take place. As part of this we also
>>> set the stage to allow emulation in response to other types of events, not 
>>> just
>>> mem_access violations.
>>>
>>> Signed-off-by: Tamas K Lengyel 
>>
>> Tamas,
>>
>> Would you like a detailed review from me for this?  I'm happy to ack the
>> p2m bits on the basis that they're only touching mem_access code.  A
>> full review may get stuck behind a pretty long review backlog. :-(
>>
>>  -George
> 
> Hi George,
> acking just the p2m bits should suffice!

I should have given that in the first e-mail really. :-)

p2m bits:

Acked-by: George Dunlap 


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf f8db6527da8678f1480f08ba99b745279e8d104a
baseline version:
 ovmf 062f9fd2cfaad09f6dd0e302094bc030827eb706

Last test of basis   100955  2016-09-14 14:14:52 Z0 days
Testing same since   100963  2016-09-15 08:14:53 Z0 days1 attempts


People who touched revisions under test:
  Yonghong Zhu 

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=f8db6527da8678f1480f08ba99b745279e8d104a
+ . ./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 
f8db6527da8678f1480f08ba99b745279e8d104a
+ branch=ovmf
+ revision=f8db6527da8678f1480f08ba99b745279e8d104a
+ . ./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
+ '[' xf8db6527da8678f1480f08ba99b745279e8d104a = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH v2 2/3] x86 Test and expose CPUID faulting capabilities in /proc/cpuinfo

[Jan Beulich]

>>> On 15.09.16 at 12:05,  wrote:
> On 14/09/16 22:01, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
> 
> Could you clarify in the commit message that it is PV guests that are
> affected.

What makes you think HVM ones aren't?

Jan


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

Re: [Xen-devel] [PATCH v3] libxl: add "xl qemu-monitor-command"

[Wei Liu]

On Fri, Sep 09, 2016 at 11:05:19AM +0100, Wei Liu wrote:
> On Tue, Sep 06, 2016 at 02:16:30PM +0200, Dario Faggioli wrote:
> > On Tue, 2016-09-06 at 12:51 +0200, Juergen Gross wrote:
> > > Add a new xl command "qemu-monitor-command" to issue arbitrary
> > > commands
> > > to a domain's device model. Syntax is:
> > > 
> > > xl qemu-monitor-command  
> > > 
> > > The command is issued via qmp human-monitor-command command. Any
> > > information returned by the command is printed to stdout.
> > > 
> > > Signed-off-by: Juergen Gross 
> > > ---
> > > V3: - add GC_FREE as requested by Dario Faggioli
> > > - return with EXIT_FAILURE/SUCCESS as requested by Dario Faggioli
> > >
> > I think you missed one...
> > 
> > > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > > index 7540fb1..d1a2a14 100644
> > > --- a/tools/libxl/xl_cmdimpl.c
> > > +++ b/tools/libxl/xl_cmdimpl.c
> > > @@ -9536,6 +9536,35 @@ int main_psr_hwinfo(int argc, char **argv)
> > >  
> > >  #endif
> > >  
> > > +int main_qemu_monitor_command(int argc, char **argv)
> > > +{
> > > +int opt;
> > > +uint32_t domid;
> > > +char *cmd;
> > > +char *output;
> > > +int ret;
> > > +
> > > +SWITCH_FOREACH_OPT(opt, "", NULL, "qemu-monitor-command", 2) {
> > > +/* No options */
> > > +}
> > > +
> > > +domid = find_domain(argv[optind]);
> > > +cmd = argv[optind + 1];
> > > +
> > > +if (argc - optind > 2) {
> > > +fprintf(stderr, "Invalid arguments.\n");
> > > +return 1;
> > >
> > ...here.
> > 
> > Anyway, this is
> > 
> > Reviewed-by: Dario Faggioli 
> 
> Thanks for reviewing.
> 
> Acked-by: Wei Liu 
> 
> > 
> > if possible, with the above 'return 1' converted to 'return
> > EXIT_FAILURE' (either by resending or done upon commit).
> > 
> 
> I can fix that up, no need to resend.
> 
 
Fixed up the patch and pushed.

Wei.

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