date:20170831

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat fail in 112970 pass 
in 112987
 test-armhf-armhf-xl-multivcpu 8 host-ping-check-xen fail in 112970 pass in 
112987
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
112970

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 112102
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112970 
like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112085
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

On 2017年08月31日 23:38, Roger Pau Monné wrote:
> On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote:
>> This patch is to change DSDT table for processor object to support >128 vcpus
>> accroding to ACPI spec 8.4 Declaring Processors
>>
>> Signed-off-by: Lan Tianyu 
>> ---
>>  tools/libacpi/mk_dsdt.c | 18 --
>>  1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
>> index 2daf32c..6c4c325 100644
>> --- a/tools/libacpi/mk_dsdt.c
>> +++ b/tools/libacpi/mk_dsdt.c
>> @@ -24,6 +24,8 @@
>>  #include 
>>  #endif
>>  
>> +#define CPU_NAME_FMT  "P%.03X"
>> +
>>  static unsigned int indent_level;
>>  static bool debug = false;
>>  
>> @@ -196,10 +198,14 @@ int main(int argc, char **argv)
>>  /* Define processor objects and control methods. */
>>  for ( cpu = 0; cpu < max_cpus; cpu++)
>>  {
>> -push_block("Processor", "PR%02X, %d, 0xb010, 0x06", cpu, cpu);
>> +unsigned int apic_id = cpu * 2;
> 
> This is fragile, ideally there should be a single point where the APIC
> ID is calculated. Although there are already two places where the APIC
> ID is calculated, in hvmloader and libxl.
> 
> And I'm not sure how to use any of those here in order to avoid
> introducing a third one.

The mk_dsdt is independent tool to build dsdt table. It wasn't linked
with libxl and hvmloader. We can't reuse old function to do that.

But I think we may introduce a new LAPIC_ID(vcpu) in the arch head
file(i.e, #include ) and replace old ones.

> 
>>  
>> -stmt("Name", "_HID, \"ACPI0007\"");
>> +if ( apic_id > 255 )
> 
> We need to be careful with this. This is not a problem ATM because the
> ACPI ID is the CPU ID, but care should be taken to not create a
> Processor object with ACPI ID 255, because that's the broadcast ACPI
> ID...

Yes.

> 
>> +push_block("Device", CPU_NAME_FMT, cpu);
>> +else
> 
> ... IMHO an assert(cpu < 255); should be added here.

OK.

> 
>> +push_block("Processor", CPU_NAME_FMT", %d, 0xb010, 0x06", 
>> cpu, cpu);
>^ space (here and below)
> 
> Please leave a space between the string literals and the defines, it
> makes it easier to read. And this line needs to be split.
> 

OK. Will update.


-- 
Best regards
Tianyu Lan

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

[Xen-devel] [linux-linus test] 112983: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 112968 pass in 112983
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail in 112968 
pass in 112983
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112968 
pass in 112983
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
112968

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112948
 build-arm64-xsm   2 hosts-allocate  broken like 112948
 build-arm64-xsm   3 capture-logsbroken like 112948
 build-arm64-pvops 3 capture-logsbroken like 112948
 build-arm64   2 hosts-allocate  broken like 112948
 build-arm64   3 capture-logsbroken like 112948
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 112968 like 112948
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112948
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112948
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112948
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112948
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112948
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux42ff72cf27027fa28dd79acabe01d9196f1480a7
baseline version:
 linux

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

2017-08-31 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

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

Last test of basis72045  2017-08-31 14:17:29 Z0 days
Testing same since72047  2017-09-01 00:48:06 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Eric Dong 
  Laszlo Ersek 
  Liming Gao 

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 f29ca8e8b96adc2539f44d41ed8521ef6d29c14c
Author: Ard Biesheuvel 
Date:   Tue Aug 29 14:21:02 2017 +0100

BaseTools/Gcc ARM AARCH64: add support for building device tree binaries

While modern AARCH64 server systems use ACPI for describing the platform
topology to the OS, ARM systems and AARCH64 outside of the server space
mostly use device tree binaries, which are compiled from device tree
source files using the device tree compiler.

Currently, such source files and binaries may be kept in the EDK2 platform
trees, but are not integrated with the build, which means they need to be
kept in sync and recompiled manually, which is cumbersome.

So let's wire up BaseTools support for them: add tool definitions for the
DTC compiler and preprocessor flags that allow these source files to use
FixedPcd expressions and other macros defined by AutoGen.h

This way, a device tree binary can be built from source and emitted into
a FFS file automatically using something like:

  DeviceTree.inf:
[Defines]
  INF_VERSION= 0x00010019
  BASE_NAME  = SomePlatformDeviceTree
  FILE_GUID  = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # 
gDtPlatformDefaultDtbFileGuid
  MODULE_TYPE= USER_DEFINED
  VERSION_STRING = 1.0

[Sources]
  SomePlatform.dts

[Packages]
  MdePkg/MdePkg.dec

  SomePlatform.fdf:
INF RuleOverride = DTB xxx/yyy/DeviceTree.inf

[Rule.Common.USER_DEFINED.DTB]
  FILE FREEFORM = $(NAMED_GUID) {
RAW BIN|.dtb
  }

where it can be picked at runtime by the DTB loader that may refer to it
using gDtPlatformDefaultDtbFileGuid.

Note that this is very similar to how ACPI tables may be emitted into a
FFS file with a known GUID and picked up by AcpiTableDxe at runtime.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
Reviewed-by: Leif Lindholm 
Reviewed-by: Liming Gao 

commit f3f0bd168f816b1315ebf0a3fe4522cf6f5b6883
Author: Liming Gao 
Date:   Thu Aug 24 14:28:45 2017 +0800

BaseTools: Enable --whole-archive in GCC tool chain as the default option

https://bugzilla.tianocore.org/show_bug.cgi?id=581

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

commit d5fdae96e2fc88c4efee2af12da1dbaa47d161a3
Author: Eric Dong 
Date:   Mon Aug 28 11:05:00 2017 +0800

UefiCpuPkg/Mplib.c: Perform complete initialization when enable AP.

PI has description said If an AP is enabled, then the implementation must
guarantee that a complete initialization sequence is performed on the AP,
so the

Re: [Xen-devel] [PATCH v5 1/4] VT-d PI: track the number of vcpus on pi blocking list

2017-08-31 Thread Chao Gao

On Thu, Aug 31, 2017 at 02:33:57AM -0600, Jan Beulich wrote:
 On 31.08.17 at 09:15,  wrote:
>> On Thu, Aug 31, 2017 at 01:42:53AM -0600, Jan Beulich wrote:
>> On 31.08.17 at 00:57,  wrote:
 On Wed, Aug 30, 2017 at 10:00:49AM -0600, Jan Beulich wrote:
 On 16.08.17 at 07:14,  wrote:
>> @@ -100,6 +101,24 @@ void vmx_pi_per_cpu_init(unsigned int cpu)
>>  spin_lock_init(_cpu(vmx_pi_blocking, cpu).lock);
>>  }
>>  
>> +static void vmx_pi_add_vcpu(struct pi_blocking_vcpu *pbv,
>> +struct vmx_pi_blocking_vcpu *vpbv)
>> +{
>> +ASSERT(spin_is_locked(>lock));
>
>You realize this is only a very weak check for a non-recursive lock?
 
 I just thought the lock should be held when adding one entry to the
 blocking list. Do you think we should remove this check or make it
 stricter?
>>>
>>>Well, the primary purpose of my comment was to make you aware
>>>of the fact. If the weak check is good enough for you, then fine.
>> 
>> To be honest, I don't know the difference between weak check and tight
>> check.
>
>For non-recursive locks spin_is_locked() only tells you if _any_
>CPU in the system currently holds the lock. For recursive ones it
>checks whether it's the local CPU that owns the lock.
>
>>>Removing the check would be a bad idea imo (but see also below);
>>>tightening might be worthwhile, but might also go too far (depending
>>>mainly on how clearly provable it is that all callers actually hold the
>>>lock).
>> 
>> IMO, the lock was introduced (not by me) to protect the blocking list.
>> list_add() and list_del() should be performed with the lock held. So I
>> think it is clear that all callers should hold the lock.
>
>Good.
>
>> +add_sized(>counter, 1);
>> +ASSERT(read_atomic(>counter));
>
>Why add_sized() and read_atomic() when you hold the lock?
>
 
 In patch 3, frequent reading the counter is used to find a suitable
 vcpu and we can use add_sized() and read_atomic() to avoid acquiring the
 lock. In one word, the lock doesn't protect the counter.
>>>
>>>In that case it would be more natural to switch to the atomic
>>>accesses there. Plus you still wouldn't need read_atomic()
>>>here, with the lock held. Furthermore I would then wonder
>>>whether it wasn't better to use atomic_t for the counter at
>> 
>> Is there some basic guide on when it is better to use read_atomic()
>> and add_sized() and when it is better to define a atomic variable
>> directly?
>
>If an atomic_t variable fits your needs, I think it should always
>be preferred. add_sized() was introduced for a case where an
>atomic_t variable would not have been usable. Please also
>consult older commits for understanding the background.
>
>>>that point. Also with a lock-less readers the requirement to
>>>hold a lock here (rather than using suitable LOCKed accesses)
>>>becomes questionable too.
>> 
>> As I said above, I think the lock is used to protect the list.
>> 
>> I think this patch has two parts:
>> 1. Move all list operations to two inline functions. (with this, adding
>> a counter is easier and don't need add code in several places.)
>> 
>> 2. Add a counter.
>
>With it being left unclear whether the counter is meant to
>also be protected by the lock: In the patch here you claim it
>is, yet by later introducing lock-less readers you weaken
>that model. Hence the request to bring things into a
>consistent state right away, and ideally also into the final
>state.
>

Hi, Jan.

After thinking it again, I want to define the counter as
a unsigned int variable for the following reasion:
1. It is definite that the counter is closely related with
list_add() and list_del(). If the list is protected by the
lock, it is straightforward that the counter is also protected
by the lock.
2. In patch 3, althought there are some lock-less readers, we
will check the counter still meets our requirement with the lock
held. Thus, I don't think there is a racing issue.

Thanks
Chao

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

[Xen-devel] [xen-unstable test] 112981: tolerable trouble: blocked/broken/fail/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112809
 build-arm64-xsm   3 capture-logsbroken like 112809
 build-arm64-pvops 2 hosts-allocate  broken like 112809
 build-arm64-pvops 3 capture-logsbroken like 112809
 build-arm64   2 hosts-allocate  broken like 112809
 build-arm64   3 capture-logsbroken like 112809
 test-armhf-armhf-xl-rtds 17 guest-start.2   fail blocked in 112809
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112809
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112809
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112809
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112809
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112809
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112809
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112809
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  dab6a84aadab11f31332030a1e9f0b9282d76156
baseline version:
 xen  9053a74c08fd6abf43bb45ff932b4386de7e8510

Last test of basis   112809  2017-08-22 04:57:01 Z9 days
Failing since112841  2017-08-23 06:00:13 Z8 days   14 attempts
Testing same since   112965  2017-08-30 20:48:59 Z1 days2 attempts

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

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

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

Last test of basis   112971  2017-08-31 01:48:04 Z0 days
Testing same since   112986  2017-08-31 13:52:09 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Eric Dong 
  Laszlo Ersek 
  Liming Gao 

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=f29ca8e8b96adc2539f44d41ed8521ef6d29c14c
+ . ./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 
f29ca8e8b96adc2539f44d41ed8521ef6d29c14c
+ branch=ovmf
+ revision=f29ca8e8b96adc2539f44d41ed8521ef6d29c14c
+ . ./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.9-testing
+ '[' xf29ca8e8b96adc2539f44d41ed8521ef6d29c14c = 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
++ :

[Xen-devel] [seabios baseline-only test] 72046: regressions - FAIL

2017-08-31 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 72046 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72046/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
72037

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 72037
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 72037
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72037
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass

version targeted for testing:
 seabios  ef5fdc99b771349264b4ba0aac1c654c8789386f
baseline version:
 seabios  b404a5f417cbe5593f89c79954569b0e245fb80c

Last test of basis72037  2017-08-30 04:46:51 Z1 days
Testing same since72046  2017-08-31 19:17:16 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel 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 ef5fdc99b771349264b4ba0aac1c654c8789386f
Author: Kevin O'Connor 
Date:   Tue Aug 29 14:38:19 2017 -0400

vga: Fix bug in stdvga_get_linesize()

Add required GET_GLOBAL() macro to vmode_g access.

Signed-off-by: Kevin O'Connor 

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

[Xen-devel] [PATCH v5] xen: get rid of paravirt op adjust_exception_frame

2017-08-31 Thread Juergen Gross

When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.

Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just use the exception entry with prepended instructions,
otherwise use the entry without the Xen specific code.

Signed-off-by: Juergen Gross 
---
 arch/x86/entry/entry_64.S | 23 ++--
 arch/x86/entry/entry_64_compat.S  |  1 -
 arch/x86/include/asm/paravirt.h   |  5 --
 arch/x86/include/asm/paravirt_types.h |  3 --
 arch/x86/include/asm/proto.h  |  3 ++
 arch/x86/include/asm/traps.h  | 28 --
 arch/x86/kernel/asm-offsets_64.c  |  1 -
 arch/x86/kernel/paravirt.c|  3 --
 arch/x86/xen/enlighten_pv.c   | 98 +++
 arch/x86/xen/irq.c|  3 --
 arch/x86/xen/xen-asm_64.S | 41 +--
 arch/x86/xen/xen-ops.h|  1 -
 12 files changed, 133 insertions(+), 77 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 7a1d383c2192..bdd024a9afc9 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -821,7 +821,6 @@ ENTRY(\sym)
.endif
 
ASM_CLAC
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
 
.ifeq \has_error_code
pushq   $-1 /* ORIG_RAX: no syscall to 
restart */
@@ -967,7 +966,7 @@ ENTRY(do_softirq_own_stack)
 ENDPROC(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
-idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
 
 /*
  * A note on the "critical region" in our callback handler.
@@ -1034,8 +1033,6 @@ ENTRY(xen_failsafe_callback)
movq8(%rsp), %r11
addq$0x30, %rsp
pushq   $0  /* RIP */
-   pushq   %r11
-   pushq   %rcx
UNWIND_HINT_IRET_REGS offset=8
jmp general_protection
 1: /* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
@@ -1066,9 +1063,8 @@ idtentry int3 do_int3 
has_error_code=0paranoid=1 shift_ist=DEBUG_STACK
 idtentry stack_segment do_stack_segmenthas_error_code=1
 
 #ifdef CONFIG_XEN
-idtentry xen_debug do_debughas_error_code=0
-idtentry xen_int3  do_int3 has_error_code=0
-idtentry xen_stack_segment do_stack_segmenthas_error_code=1
+idtentry xendebug  do_debughas_error_code=0
+idtentry xenint3   do_int3 has_error_code=0
 #endif
 
 idtentry general_protectiondo_general_protection   has_error_code=1
@@ -1232,21 +1228,10 @@ ENTRY(error_exit)
 END(error_exit)
 
 /* Runs on exception stack */
+/* XXX: broken on Xen PV */
 ENTRY(nmi)
UNWIND_HINT_IRET_REGS
/*
-* Fix up the exception frame if we're on Xen.
-* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
-* one value to the stack on native, so it may clobber the rdx
-* scratch slot, but it won't clobber any of the important
-* slots past it.
-*
-* Xen is a different story, because the Xen frame itself overlaps
-* the "NMI executing" variable.
-*/
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
-
-   /*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.
 * This means that we can have nested NMIs where the next
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 5314d7b8e5ad..d8468ba24be0 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -293,7 +293,6 @@ ENTRY(entry_INT80_compat)
/*
 * Interrupts are off on entry.
 */
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
ASM_CLAC/* Do this early to minimize exposure */
SWAPGS
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 9ccac1926587..c25dd22f7c70 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -960,11 +960,6 @@ extern void default_banner(void);
 #define GET_CR2_INTO_RAX   \
call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2)
 
-#define PARAVIRT_ADJUST_EXCEPTION_FRAME
\
-   PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
- CLBR_NONE,\
- call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
-
 #define USERGS_SYSRET64
\
PARA_SITE(PARA_PATCH(pv_cpu_ops,

[Xen-devel] [PATCH 11/13] xen/gntdev: update to new mmu_notifier semantic

2017-08-31 Thread jglisse

From: Jérôme Glisse 

Call to mmu_notifier_invalidate_page() are replaced by call to
mmu_notifier_invalidate_range() and thus call are bracketed by
call to mmu_notifier_invalidate_range_start()/end()

Remove now useless invalidate_page callback.

Signed-off-by: Jérôme Glisse 
Reviewed-by: Boris Ostrovsky 
Cc: Konrad Rzeszutek Wilk 
Cc: Roger Pau Monné 
Cc: xen-de...@lists.xenproject.org (moderated for non-subscribers)
Cc: Kirill A. Shutemov 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Andrea Arcangeli 
---
 drivers/xen/gntdev.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
index f3bf8f4e2d6c..82360594fa8e 100644
--- a/drivers/xen/gntdev.c
+++ b/drivers/xen/gntdev.c
@@ -484,13 +484,6 @@ static void mn_invl_range_start(struct mmu_notifier *mn,
mutex_unlock(>lock);
 }
 
-static void mn_invl_page(struct mmu_notifier *mn,
-struct mm_struct *mm,
-unsigned long address)
-{
-   mn_invl_range_start(mn, mm, address, address + PAGE_SIZE);
-}
-
 static void mn_release(struct mmu_notifier *mn,
   struct mm_struct *mm)
 {
@@ -522,7 +515,6 @@ static void mn_release(struct mmu_notifier *mn,
 
 static const struct mmu_notifier_ops gntdev_mmu_ops = {
.release= mn_release,
-   .invalidate_page= mn_invl_page,
.invalidate_range_start = mn_invl_range_start,
 };
 
-- 
2.13.5


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

[Xen-devel] [PATCH 00/13] mmu_notifier kill invalidate_page callback v2

2017-08-31 Thread jglisse

From: Jérôme Glisse 

(Sorry for so many list cross-posting and big cc)

Changes since v1:
  - remove more dead code in kvm (no testing impact)
  - more accurate end address computation (patch 2)
in page_mkclean_one and try_to_unmap_one
  - added tested-by/reviewed-by gotten so far

Tested as both host and guest kernel with KVM nothing is burning yet.

Previous cover letter:


Please help testing !

The invalidate_page callback suffered from 2 pitfalls. First it used to
happen after page table lock was release and thus a new page might have
been setup for the virtual address before the call to invalidate_page().

This is in a weird way fixed by c7ab0d2fdc840266b39db94538f74207ec2afbf6
which moved the callback under the page table lock. Which also broke
several existing user of the mmu_notifier API that assumed they could
sleep inside this callback.

The second pitfall was invalidate_page being the only callback not taking
a range of address in respect to invalidation but was giving an address
and a page. Lot of the callback implementer assumed this could never be
THP and thus failed to invalidate the appropriate range for THP pages.

By killing this callback we unify the mmu_notifier callback API to always
take a virtual address range as input.

There is now 2 clear API (I am not mentioning the youngess API which is
seldomly used):
  - invalidate_range_start()/end() callback (which allow you to sleep)
  - invalidate_range() where you can not sleep but happen right after
page table update under page table lock


Note that a lot of existing user feels broken in respect to range_start/
range_end. Many user only have range_start() callback but there is nothing
preventing them to undo what was invalidated in their range_start() callback
after it returns but before any CPU page table update take place.

The code pattern use in kvm or umem odp is an example on how to properly
avoid such race. In a nutshell use some kind of sequence number and active
range invalidation counter to block anything that might undo what the
range_start() callback did.

If you do not care about keeping fully in sync with CPU page table (ie
you can live with CPU page table pointing to new different page for a
given virtual address) then you can take a reference on the pages inside
the range_start callback and drop it in range_end or when your driver
is done with those pages.

Last alternative is to use invalidate_range() if you can do invalidation
without sleeping as invalidate_range() callback happens under the CPU
page table spinlock right after the page table is updated.


Note this is barely tested. I intend to do more testing of next few days
but i do not have access to all hardware that make use of the mmu_notifier
API.


First 2 patches convert existing call of mmu_notifier_invalidate_page()
to mmu_notifier_invalidate_range() and bracket those call with call to
mmu_notifier_invalidate_range_start()/end().

The next 10 patches remove existing invalidate_page() callback as it can
no longer happen.

Finaly the last page remove it completely so it can RIP.

Jérôme Glisse (13):
  dax: update to new mmu_notifier semantic
  mm/rmap: update to new mmu_notifier semantic
  powerpc/powernv: update to new mmu_notifier semantic
  drm/amdgpu: update to new mmu_notifier semantic
  IB/umem: update to new mmu_notifier semantic
  IB/hfi1: update to new mmu_notifier semantic
  iommu/amd: update to new mmu_notifier semantic
  iommu/intel: update to new mmu_notifier semantic
  misc/mic/scif: update to new mmu_notifier semantic
  sgi-gru: update to new mmu_notifier semantic
  xen/gntdev: update to new mmu_notifier semantic
  KVM: update to new mmu_notifier semantic
  mm/mmu_notifier: kill invalidate_page

Cc: Kirill A. Shutemov 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Andrea Arcangeli 
Cc: Joerg Roedel 
Cc: Dan Williams 
Cc: Sudeep Dutt 
Cc: Ashutosh Dixit 
Cc: Dimitri Sivanich 
Cc: Jack Steiner 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 

Cc: linuxppc-...@lists.ozlabs.org
Cc: dri-de...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Cc: linux-r...@vger.kernel.org
Cc: io...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
Cc: k...@vger.kernel.org

Jérôme Glisse (13):
  dax: update to new mmu_notifier semantic
  mm/rmap: update to new mmu_notifier semantic v2
  powerpc/powernv: update to new mmu_notifier semantic
  drm/amdgpu: update to new mmu_notifier semantic
  IB/umem: update to new mmu_notifier semantic
  IB/hfi1: update to new mmu_notifier semantic
  iommu/amd: update to new mmu_notifier semantic
  iommu/intel: update to new mmu_notifier semantic
  misc/mic/scif: update to new mmu_notifier semantic
  sgi-gru: update to new

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

2017-08-31 Thread Juergen Gross

On 31/08/17 16:01, Boris Ostrovsky wrote:
> On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
>> On Thu, 31 Aug 2017, Juergen Gross wrote:
 I've applied it on top of tip:x86/apic and fixed up the merge conflicts
 mindlessly. Patch below.

 Juergen, can you please check the result?
>>> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
>>> of the xen specific trap entries in arch/x86/include/asm/traps.h
>> I'll try that again later today, unless you beat me to it.
>>
> 
> https://marc.info/?l=linux-kernel=150296063131595=2 should also be
> picked up by the tip tree then since it applies on top of the
> adjust_exception_frame patch. I will revert it from Xen tree as well.

I have included this patch in my rebase on top of the tip tree, so it is
no longer needed.


Juergen

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

[Xen-devel] [qemu-mainline test] 112979: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt 10 debian-install   fail REGR. vs. 112869
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail REGR. vs. 
112869

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 112869

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate  broken like 112869
 build-arm64-xsm   2 hosts-allocate  broken like 112869
 build-arm64-pvops 2 hosts-allocate  broken like 112869
 build-arm64   3 capture-logsbroken like 112869
 build-arm64-xsm   3 capture-logsbroken like 112869
 build-arm64-pvops 3 capture-logsbroken like 112869
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112869
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112869
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112869
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112869
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112869
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112869
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuu29c8564a7da63cf427a90213cdd86e99310bb7bf
baseline version:
 qemuu248b23735645f7cbb503d9be6f5bf825f2a603ab

Last test of basis   112869  2017-08-25 06:55:43 Z6 days
Failing since112961  2017-08-30 16:16:31 Z1 days2 attempts
Testing same since   112979  2017-08-31 08:03:35 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm

Re: [Xen-devel] Mailing List Broken? Unsubscribed?

2017-08-31 Thread Gary R Hook


On 08/29/2017 04:53 PM, Gary R Hook wrote:

Hm. For some odd reason I stopped receiving xen-devel mail a while ago.
I never
unsubscribed, never turned anything off (to the best of my knowledge). Now
a co-worker is unable to subscribe.

What's up with that? Any ideas?


Looks like we may have a problem on our end...


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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr,


On 08/31/2017 04:58 PM, Volodymyr Babchuk wrote:
> Hi Sergej
>
> On 31.08.17 16:51, Sergej Proskurin wrote:
>> Hi Volodymyr,
>>
>>
>> On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote:
>>> Hello Sergej,
>>>
>>> On 31.08.17 15:20, Sergej Proskurin wrote:
 Hi Volodymyr, hi Julien,


 On 08/24/2017 07:25 PM, Julien Grall wrote:
>
>
> On 21/08/17 21:27, Volodymyr Babchuk wrote:
>> This feature indicates that hypervisor is compatible with ARM
>> SMC calling convention. Hypervisor will not inject an undefined
>> instruction exception if an invalid SMC function were called and
>> will not crash a domain if an invlalid HVC functions were called.
>
> s/invlalid/invalid/
>
> The last sentence is misleading. Xen will still inject and undefined
> instruction for some SMC/HVC. You may want to rework it to make it
> clear.
>

 Now that you say that Xen will still inject an undefined instruction
 exception for some SMCs, I have a to ask for which exactly?
>>> For ones that are compatible with ARM SMCCC [1]. E.g if you are
>>> running SMCCC-compatible system and you are calling SMC/HVC with
>>> immediate value 0, then you are safe.
>>>
>>
>> Alright, as far as I understand this is exactly what I do right now. I
>> inject an SMC that is encoded as 0xD403.
> Actually, this patch series are not merged yet, so no SMCCC support
> right. But this should not a problem in your case.
>
 I might be off topic here, so please tell me if you believe this is
 not
 the right place for this question. In this case I will open an new
 thread. Right now, I am working with the previous implementation of
 do_trap_smc that was extended in this patch. Yet, as far as I
 understand, the behavior should not change, which is why I am asking
 this quesiton in this thread.
>>> If you are talking about forwarding SMC exception to VM monitor, then
>>> yes, that should not change.
>>
>> Yes, exactly. Sorry, I forgot to mention that I have a modified
>> xen-access version running in dom0 that registers an SMC monitor and
>> also increases the PC by 4 (or dependent on the case, simply leaves it
>> as it is) on every SMC trap.
> Aha, I see. I never was able to test this feature fully. I played with
> my own VM monitor, when I tried to offload SMC handling to another
> domain. But I had to comment out most of the VM monitor code in XEN.
>
>>>
 Currently, I am working on SMC guest injections and trying to
 understand
 the resulting behavior. Every time, right after the execution of an
 injected SMC instruction, the guest traps into the undefined
 instruction
 exception handler in EL1 and I simply don't understand why. As far
 as I
 understand, as soon an injected SMC instruction gets executed, it
 should
 _transparently_ trap into the hypervisor (assuming MDCR_EL2.TDE is
 set).
 As soon as the hypervisor returns (e.g. to PC+4 or to the trapping PC
 that now contains the original instruction instead of the injected
 SMC),
 the guest should simply continue its execution.
>>> Hm. What do you mean under "SMC instruction injection?".
>>
>> My code runs in dom0 and "injects" an SMC instruction to predefined
>> addresses inside the guest as to simulate software breakpoints. By this,
>> I mean that the code replaces the original guest instruction at a
>> certain address with an SMC. Think of a debugger that uses software
>> breakpoints. The idea is to put back the original instruction right
>> after the SMC gets called, so that the guest can continue with its
>> execution. You can find more information about that in [0], yet please
>> consider that I try to trap the SMC directly in Xen instead of
>> TrustZone.
> Yep, I see. Immediate question: do you flush icache after you put
> original instruction back? 

Yeap. But the current behavior does not let me to go this far, as I the
system jumps into the interrupt handler and single-steps the handler
instead of the instruction of interest.

> Then I can't see, why this should not work. If only VM monitor core in
> XEN is not broken. I don't know any users of this.
> I'm just curious, why are you using SMC, not BRK instruction?
>

I use SMC instructions as the guest can register for BRK events. The
guest cannot register for SMC events. So, in order stay stealthy towards
the guest and also not to cope with BRK re-injections, SMC's seemed to
be the right choice :)

>>> Current code in hypervisor will always inject undefined instruction
>>> exception when you  call SMC (unless you installed VM monitor for the
>>> guest). Also, it will not increase PC. So, if you'll try to remove
>>> inject_undef_exception() call, you'll get into an infinite loop.
>>>
>>
>> I have a registered SMC monitor running in dom0 that does not reinject
>> the undefined instruction exception in do_trap_smc(). So there is no
>> indefinite loop at this point. What I

[Xen-devel] [PATCH v5 10/10] public: add and enable XENFEAT_ARM_SMCCC_supported feature

This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Previously hypervisor would inject an
undefined instruction exception if an invalid SMC function were
called or would crash a domain if an invalid HVC function
were invoked.
XENFEAT_ARM_SMCCC_supported feature means that it safe to invoke
SMC/HVC calls that are compatible with SMC calling convention.

Signed-off-by: Volodymyr Babchuk 
---
 xen/common/kernel.c   | 3 +++
 xen/include/public/features.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index ce7cb8a..18c4d51 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -332,6 +332,9 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 (1U << XENFEAT_auto_translated_physmap);
 if ( is_hardware_domain(d) )
 fi.submap |= 1U << XENFEAT_dom0;
+#ifdef CONFIG_ARM
+fi.submap |= (1U << XENFEAT_ARM_SMCCC_supported);
+#endif
 #ifdef CONFIG_X86
 switch ( d->guest_type )
 {
diff --git a/xen/include/public/features.h b/xen/include/public/features.h
index 2110b04..1a989b8 100644
--- a/xen/include/public/features.h
+++ b/xen/include/public/features.h
@@ -102,6 +102,9 @@
 /* Guest can use XENMEMF_vnode to specify virtual node for memory op. */
 #define XENFEAT_memory_op_vnode_supported 13
 
+/* arm: Hypervisor supports ARM SMC calling convention. */
+#define XENFEAT_ARM_SMCCC_supported   14
+
 #define XENFEAT_NR_SUBMAPS 1
 
 #endif /* __XEN_PUBLIC_FEATURES_H__ */
-- 
2.7.4


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

[Xen-devel] [PATCH v5 09/10] arm: vsmc: remove 64 bit mode check in PSCI handler

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

 - Generic handler checks that 64 bit calls can be made only by
   64 bit guests.

 - SMCCC requires that 64-bit handler should support both 32 and 64 bit
   calls even if they originate from 64 bit caller.

This patch removes that extra check.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Stefano Stabellini 
---
 xen/arch/arm/vsmc.c | 62 ++---
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 5421bd2..e778173 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -111,12 +111,6 @@ static bool handle_existing_apis(struct cpu_user_regs 
*regs)
 }
 }
 
-/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return is_64bit_domain(d) || !smccc_is_conv_64(fid);
-}
-
 /* PSCI 0.2 interface and other Standard Secure Calls */
 static bool handle_sssc(struct cpu_user_regs *regs)
 {
@@ -141,8 +135,7 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 
 case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 return true;
 
 case PSCI_0_2_FN_SYSTEM_OFF:
@@ -158,48 +151,45 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 return true;
 
 case PSCI_0_2_FN_CPU_ON:
-perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t vcpuid = PSCI_ARG(regs, 1);
-register_t epoint = PSCI_ARG(regs, 2);
-register_t cid = PSCI_ARG(regs, 3);
+{
+register_t vcpuid = PSCI_ARG(regs, 1);
+register_t epoint = PSCI_ARG(regs, 2);
+register_t cid = PSCI_ARG(regs, 3);
 
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
-}
+perfc_incr(vpsci_cpu_on);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
 return true;
+}
 
 case PSCI_0_2_FN_CPU_SUSPEND:
-perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t pstate = PSCI_ARG32(regs, 1);
-register_t epoint = PSCI_ARG(regs, 2);
-register_t cid = PSCI_ARG(regs, 3);
+{
+uint32_t pstate = PSCI_ARG32(regs, 1);
+register_t epoint = PSCI_ARG(regs, 2);
+register_t cid = PSCI_ARG(regs, 3);
 
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
-}
+perfc_incr(vpsci_cpu_suspend);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, cid));
 return true;
+}
 
 case PSCI_0_2_FN_AFFINITY_INFO:
+{
+register_t taff = PSCI_ARG(regs, 1);
+uint32_t laff = PSCI_ARG32(regs, 2);
+
 perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t taff = PSCI_ARG(regs, 1);
-uint32_t laff = PSCI_ARG32(regs, 2);
-PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
-}
+PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
 return true;
+}
 
 case PSCI_0_2_FN_MIGRATE:
-perfc_incr(vpsci_cpu_migrate);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t tcpu = PSCI_ARG32(regs, 1);
+{
+uint32_t tcpu = PSCI_ARG32(regs, 1);
 
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
-}
+perfc_incr(vpsci_cpu_migrate);
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
 return true;
+}
 
 case ARM_SMCCC_FUNC_CALL_COUNT:
 set_user_reg(regs, 0, SSSC_SMCCC_FUNCTION_COUNT);
-- 
2.7.4


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

[Xen-devel] [PATCH v5 06/10] arm: smccc: handle SMCs according to SMCCC

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to different
firmware functions. Thus, for example, PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UUID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMCCC. At this moment it implements only one
service: Standard Hypervisor Service.

At this time Standard Hypervisor Service only supports query calls,
so caller can ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---

 * reworked fill_uuid() function
 * dropped vsmc.h header. Function prototypes moved to traps.h
 * public/arch-arm/smc.h header renamed to smccc.h
 * introduced `register_t funcid` in vsmccc_handle_call()x
 * spelling fixes
 * coding style fixes

---
xen/arch/arm/Makefile   |   1 +
 xen/arch/arm/traps.c|  17 
 xen/arch/arm/vsmc.c | 168 
 xen/include/asm-arm/traps.h |   3 +
 xen/include/public/arch-arm/smccc.h |  58 +
 5 files changed, 230 insertions(+), 17 deletions(-)
 create mode 100644 xen/arch/arm/vsmc.c
 create mode 100644 xen/include/public/arch-arm/smccc.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index de00c5e..3d7dde9 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -51,6 +51,7 @@ obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
+obj-y += vsmc.o
 obj-y += vpsci.o
 obj-y += vuart.o
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9132fe1..f3b64b4 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2155,23 +2155,6 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 inject_dabt_exception(regs, info.gva, hsr.len);
 }
 
-static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
-{
-int rc = 0;
-
-if ( !check_conditional_instr(regs, hsr) )
-{
-advance_pc(regs, hsr);
-return;
-}
-
-if ( current->domain->arch.monitor.privileged_call_enabled )
-rc = monitor_smc();
-
-if ( rc != 1 )
-inject_undef_exception(regs, hsr);
-}
-
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
new file mode 100644
index 000..97a6be3
--- /dev/null
+++ b/xen/arch/arm/vsmc.c
@@ -0,0 +1,168 @@
+/*
+ * xen/arch/arm/vsmc.c
+ *
+ * Generic handler for SMC and HVC calls according to
+ * ARM SMC calling convention
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Number of functions currently supported by Hypervisor Service. */
+#define XEN_SMCCC_FUNCTION_COUNT 3
+
+static void fill_uuid(struct cpu_user_regs *regs, const xen_uuid_t *u)
+{
+int n;
+
+/*
+ * UUIDs are returned in registers r0..r3, four bytes per register,
+ * first byte is stored in low-order bits of a register.
+ * (ARM DEN 0028B page 14)
+ */
+for (n = 0; n < 4; n++)
+{
+const uint8_t *bytes = u->a + n * 4;
+uint32_t r;
+
+r = bytes[0];
+r |= bytes[1] << 8;
+r |= bytes[2] << 16;
+r |= bytes[3] << 24;
+
+set_user_reg(regs, n, r);
+}
+}
+
+/* SMCCC interface for hypervisor. Tell about itself. */
+static bool handle_hypervisor(struct cpu_user_regs *regs)
+{
+static const xen_uuid_t xen_uuid = XEN_SMCCC_UID;
+
+switch ( smccc_get_fn(get_user_reg(regs, 0)) )
+{
+case ARM_SMCCC_FUNC_CALL_COUNT:
+set_user_reg(regs, 0, XEN_SMCCC_FUNCTION_COUNT);
+return true;
+case ARM_SMCCC_FUNC_CALL_UID:
+fill_uuid(regs, _uuid);
+return true;
+case ARM_SMCCC_FUNC_CALL_REVISION:
+set_user_reg(regs, 0, XEN_SMCCC_MAJOR_REVISION);
+

[Xen-devel] [PATCH v5 07/10] arm: traps: handle PSCI calls inside `vsmc.c`

PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `vsmc.c`. This patch moves PSCI handler
calls from `traps.c` to `vsmc.c`. Also it corrects coding
style of the PSCI handler functions.

Older PSCI 0.1 uses SMC function identifiers in range that is
reserved for existing APIs (ARM DEN 0028B, page 16), while newer
PSCI 0.2 and later is defined as "standard secure service" with its
own ranges (ARM DEN 0028B, page 18).

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---

 * handle_psci_0_x() renamed to handle_existing_apis()
 * spelling fixes
 * fixed coding style for moved PSCI code
 * previously introduced `funcid` moved to previous patch

---
 xen/arch/arm/traps.c| 117 +-
 xen/arch/arm/vsmc.c | 189 +++-
 xen/include/asm-arm/traps.h |   1 +
 xen/include/public/arch-arm/smccc.h |   8 ++
 4 files changed, 196 insertions(+), 119 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index f3b64b4..d00ff36 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1450,119 +1450,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 }
 #endif
 
-#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
-#define PSCI_ARG(reg,n) get_user_reg(reg, n)
-
-#ifdef CONFIG_ARM_64
-#define PSCI_ARG32(reg,n) (uint32_t)get_user_reg(reg,n)
-#else
-#define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
-#endif
-
-/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
-static void do_trap_psci(struct cpu_user_regs *regs)
-{
-register_t fid = PSCI_ARG(regs,0);
-
-/* preloading in case psci_mode_check fails */
-PSCI_SET_RESULT(regs, PSCI_INVALID_PARAMETERS);
-switch( fid )
-{
-case PSCI_cpu_off:
-{
-uint32_t pstate = PSCI_ARG32(regs,1);
-perfc_incr(vpsci_cpu_off);
-PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
-}
-break;
-case PSCI_cpu_on:
-{
-uint32_t vcpuid = PSCI_ARG32(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-perfc_incr(vpsci_cpu_on);
-PSCI_SET_RESULT(regs, do_psci_cpu_on(vcpuid, epoint));
-}
-break;
-case PSCI_0_2_FN_PSCI_VERSION:
-perfc_incr(vpsci_version);
-PSCI_SET_RESULT(regs, do_psci_0_2_version());
-break;
-case PSCI_0_2_FN_CPU_OFF:
-perfc_incr(vpsci_cpu_off);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
-break;
-case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
-perfc_incr(vpsci_migrate_info_type);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
-break;
-case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
-case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
-perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
-break;
-case PSCI_0_2_FN_SYSTEM_OFF:
-perfc_incr(vpsci_system_off);
-do_psci_0_2_system_off();
-PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
-break;
-case PSCI_0_2_FN_SYSTEM_RESET:
-perfc_incr(vpsci_system_reset);
-do_psci_0_2_system_reset();
-PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
-break;
-case PSCI_0_2_FN_CPU_ON:
-case PSCI_0_2_FN64_CPU_ON:
-perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t vcpuid = PSCI_ARG(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
-}
-break;
-case PSCI_0_2_FN_CPU_SUSPEND:
-case PSCI_0_2_FN64_CPU_SUSPEND:
-perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t pstate = PSCI_ARG32(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
-}
-break;
-case PSCI_0_2_FN_AFFINITY_INFO:
-case PSCI_0_2_FN64_AFFINITY_INFO:
-perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t taff = PSCI_ARG(regs,1);
-uint32_t laff = PSCI_ARG32(regs,2);
-PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
-}
-break;
-case PSCI_0_2_FN_MIGRATE:
-case PSCI_0_2_FN64_MIGRATE:
-perfc_incr(vpsci_cpu_migrate);
-if (

[Xen-devel] [PATCH v5 08/10] arm: PSCI: use definitions provided by asm/smccc.h

smccc.h provides definitions to construct SMC call function number according
to SMCCC. We don't need multiple definitions for one thing, and definitions
in smccc.h are more generic than ones used in psci.h.

So psci.h will only provide function codes, while whole SMC function
identifier will be constructed using generic macros from smccc.h.

Function psci_mode_check() in vsmc.c will be removed in a next patch,
so there are no need to review it. I had to rework it, because
PSCI_0_2_64BIT definition is dropped now.

Signed-off-by: Volodymyr Babchuk 
---

 * removed #include  from seattle.c
 * PSCI_0_2_FUNC_xxx renamed back to PSCI_0_2_FN_xxx
 * mentioned psci_mode_check() in the commit message

---
xen/arch/arm/platforms/seattle.c |  4 ++--
 xen/arch/arm/psci.c  | 10 -
 xen/arch/arm/vsmc.c  | 22 ++--
 xen/include/asm-arm/psci.h   | 44 ++--
 4 files changed, 38 insertions(+), 42 deletions(-)

diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 86dce91..22c0622 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -33,12 +33,12 @@ static const char * const seattle_dt_compat[] __initconst =
  */
 static void seattle_system_reset(void)
 {
-call_smc(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
 }
 
 static void seattle_system_off(void)
 {
-call_smc(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
 }
 
 PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 34ee97e..be4e8e6 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -31,9 +31,9 @@
  * (native-width) function ID.
  */
 #ifdef CONFIG_ARM_64
-#define PSCI_0_2_FN_NATIVE(name)   PSCI_0_2_FN64_##name
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN64(name)
 #else
-#define PSCI_0_2_FN_NATIVE(name)   PSCI_0_2_FN_##name
+#define PSCI_0_2_FN_NATIVE(name)PSCI_0_2_FN32(name)
 #endif
 
 uint32_t psci_ver;
@@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(SYSTEM_OFF), 0, 0, 0);
 }
 
 void call_psci_system_reset(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(SYSTEM_RESET), 0, 0, 0);
 }
 
 int __init psci_is_smc_method(const struct dt_device_node *psci)
@@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
 }
 }
 
-psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
+psci_ver = call_smc(PSCI_0_2_FN32(PSCI_VERSION), 0, 0, 0);
 
 /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
 if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index d3120a5..5421bd2 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -114,7 +114,7 @@ static bool handle_existing_apis(struct cpu_user_regs *regs)
 /* helper function for checking arm mode 32/64 bit */
 static inline int psci_mode_check(struct domain *d, register_t fid)
 {
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
+return is_64bit_domain(d) || !smccc_is_conv_64(fid);
 }
 
 /* PSCI 0.2 interface and other Standard Secure Calls */
@@ -124,40 +124,40 @@ static bool handle_sssc(struct cpu_user_regs *regs)
 
 switch ( smccc_get_fn(fid) )
 {
-case smccc_get_fn(PSCI_0_2_FN_PSCI_VERSION):
+case PSCI_0_2_FN_PSCI_VERSION:
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
 
-case smccc_get_fn(PSCI_0_2_FN_CPU_OFF):
+case PSCI_0_2_FN_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
 
-case smccc_get_fn(PSCI_0_2_FN_MIGRATE_INFO_TYPE):
+case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
 
-case smccc_get_fn(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
+case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
 if ( psci_mode_check(current->domain, fid) )
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 return true;
 
-case smccc_get_fn(PSCI_0_2_FN_SYSTEM_OFF):
+case PSCI_0_2_FN_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 return true;
 
-case smccc_get_fn(PSCI_0_2_FN_SYSTEM_RESET):
+case PSCI_0_2_FN_SYSTEM_RESET:
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
 PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);

[Xen-devel] [PATCH v5 02/10] arm: traps: check if SMC was conditional before handling it

Trapped SMC instruction can fail condition check on ARMv8 architecture
(ARM DDI 0487B.a page D7-2271). So we need to check if condition was meet.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Julien Grall 
---

 * added Julien's R-b tag
---
xen/arch/arm/traps.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 4569c62..9132fe1 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2159,6 +2159,12 @@ static void do_trap_smc(struct cpu_user_regs *regs, 
const union hsr hsr)
 {
 int rc = 0;
 
+if ( !check_conditional_instr(regs, hsr) )
+{
+advance_pc(regs, hsr);
+return;
+}
+
 if ( current->domain->arch.monitor.privileged_call_enabled )
 rc = monitor_smc();
 
-- 
2.7.4


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

[Xen-devel] [PATCH v5 03/10] public: xen.h: add definitions for UUID handling

Added type xen_uuid_t. This type represents UUID as an array of 16
bytes in big endian format.

Added macro XEN_DEFINE_UUID that constructs UUID in the usual way:

 XEN_DEFINE_UUID(00112233, 4455, 6677, 8899, aabbccddeeff)

will construct UUID 00112233-4455-6677-8899-aabbccddeeff presented as
 {0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
  0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff}

NB: This is compatible with Linux kernel and with libuuid, but it is not
compatible with Microsoft, as they use mixed-endian encoding (some
components are little-endian, some are big-endian).

Signed-off-by: Volodymyr Babchuk 
---

 * Array was wrapped into a structure

---
xen/include/public/xen.h | 13 +
 1 file changed, 13 insertions(+)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 2ac6b1e..3dc81e3 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -930,6 +930,19 @@ __DEFINE_XEN_GUEST_HANDLE(uint16, uint16_t);
 __DEFINE_XEN_GUEST_HANDLE(uint32, uint32_t);
 __DEFINE_XEN_GUEST_HANDLE(uint64, uint64_t);
 
+typedef struct
+{
+uint8_t a[16];
+} xen_uuid_t;
+
+#define XEN_DEFINE_UUID(a, b, c, d, e1, e2, e3, e4, e5, e6) \
+{{((a) >> 24) & 0xFF, ((a) >> 16) & 0xFF,   \
+  ((a) >>  8) & 0xFF, ((a) >>  0) & 0xFF,   \
+  ((b) >>  8) & 0xFF, ((b) >>  0) & 0xFF,   \
+  ((c) >>  8) & 0xFF, ((c) >>  0) & 0xFF,   \
+  ((d) >>  8) & 0xFF, ((d) >>  0) & 0xFF,   \
+e1, e2, e3, e4, e5, e6}}
+
 #endif /* !__ASSEMBLY__ */
 
 /* Default definitions for macros used by domctl/sysctl. */
-- 
2.7.4


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

[Xen-devel] [PATCH v5 04/10] arm: processor.h: add definition for immediate value mask

This patch define HSR_XXC_IMM_MASK. It can be used to extract
immediate value for trapped HVC32, HVC64, SMC64, SVC32, SVC64
instructions, as described in the ARM ARM
(ARM DDI 0487B.a pages D7-2270, D7-2272).

Signed-off-by: Volodymyr Babchuk 
---

 * spelling fixes

---
 xen/include/asm-arm/processor.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 51ce802..89752a7 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -580,6 +580,9 @@ union hsr {
   HSR_SYSREG_CRN_MASK|HSR_SYSREG_CRM_MASK|\
   HSR_SYSREG_OP2_MASK)
 
+/* HSR.EC == HSR_{HVC32, HVC64, SMC64, SVC32, SVC64} */
+#define HSR_XXC_IMM_MASK (0x)
+
 /* Physical Address Register */
 #define PAR_F   (_AC(1,U)<<0)
 
-- 
2.7.4


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

[Xen-devel] [PATCH v5 01/10] arm: traps: use generic register accessors in the PSCI code

There are standard functions set_user_reg() and get_user_reg(). We can
use them in PSCI_SET_RESULT()/PSCI_ARG() macros instead of relying on
CONFIG_ARM_64 definition.

Signed-off-by: Volodymyr Babchuk 
---
 * removed 0x mask
 * coding style left unchanged, because it will be fixed in next patches
 * spelling fixes
---
xen/arch/arm/traps.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 13efb58..4569c62 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1450,13 +1450,12 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 }
 #endif
 
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg,n) get_user_reg(reg, n)
+
 #ifdef CONFIG_ARM_64
-#define PSCI_RESULT_REG(reg) (reg)->x0
-#define PSCI_ARG(reg,n) (reg)->x##n
-#define PSCI_ARG32(reg,n) (uint32_t)( (reg)->x##n & 0x )
+#define PSCI_ARG32(reg,n) (uint32_t)get_user_reg(reg,n)
 #else
-#define PSCI_RESULT_REG(reg) (reg)->r0
-#define PSCI_ARG(reg,n) (reg)->r##n
 #define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
 #endif
 
@@ -1471,14 +1470,14 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 register_t fid = PSCI_ARG(regs,0);
 
 /* preloading in case psci_mode_check fails */
-PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
+PSCI_SET_RESULT(regs, PSCI_INVALID_PARAMETERS);
 switch( fid )
 {
 case PSCI_cpu_off:
 {
 uint32_t pstate = PSCI_ARG32(regs,1);
 perfc_incr(vpsci_cpu_off);
-PSCI_RESULT_REG(regs) = do_psci_cpu_off(pstate);
+PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
 }
 break;
 case PSCI_cpu_on:
@@ -1486,36 +1485,36 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 uint32_t vcpuid = PSCI_ARG32(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 perfc_incr(vpsci_cpu_on);
-PSCI_RESULT_REG(regs) = do_psci_cpu_on(vcpuid, epoint);
+PSCI_SET_RESULT(regs, do_psci_cpu_on(vcpuid, epoint));
 }
 break;
 case PSCI_0_2_FN_PSCI_VERSION:
 perfc_incr(vpsci_version);
-PSCI_RESULT_REG(regs) = do_psci_0_2_version();
+PSCI_SET_RESULT(regs, do_psci_0_2_version());
 break;
 case PSCI_0_2_FN_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
-PSCI_RESULT_REG(regs) = do_psci_0_2_cpu_off();
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 break;
 case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
-PSCI_RESULT_REG(regs) = do_psci_0_2_migrate_info_type();
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 break;
 case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
 case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
 if ( psci_mode_check(current->domain, fid) )
-PSCI_RESULT_REG(regs) = do_psci_0_2_migrate_info_up_cpu();
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 break;
 case PSCI_0_2_FN_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
-PSCI_RESULT_REG(regs) = PSCI_INTERNAL_FAILURE;
+PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 break;
 case PSCI_0_2_FN_SYSTEM_RESET:
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
-PSCI_RESULT_REG(regs) = PSCI_INTERNAL_FAILURE;
+PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 break;
 case PSCI_0_2_FN_CPU_ON:
 case PSCI_0_2_FN64_CPU_ON:
@@ -1525,8 +1524,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 register_t vcpuid = PSCI_ARG(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 register_t cid = PSCI_ARG(regs,3);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_cpu_on(vcpuid, epoint, cid);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
 }
 break;
 case PSCI_0_2_FN_CPU_SUSPEND:
@@ -1537,8 +1535,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 uint32_t pstate = PSCI_ARG32(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 register_t cid = PSCI_ARG(regs,3);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_cpu_suspend(pstate, epoint, cid);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
 }
 break;
 case PSCI_0_2_FN_AFFINITY_INFO:
@@ -1548,8 +1545,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 {
 register_t taff = PSCI_ARG(regs,1);
 uint32_t laff = PSCI_ARG32(regs,2);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_affinity_info(taff, laff);
+PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
 }

[Xen-devel] [PATCH v5 00/10] Handle SMCs and HVCs in conformance with SMCCC

Hello all,

v5:
 * Patches that add end enable XENFEAT_ARM_SMCCC_supported were
   squashed together
 * All other chages are described in corresponding patches

This patch series still depend on Julien's patches for traps.c cleanup ([1]).

---
v4:

 * Added patch with public definitiod for xen_uuid_t
 * Added patch with immediate value mask for SMC, HVC and SVC
 * Added patch with header smccc.h (generic SMCCC definitions)
 * Added patches that add and enable XENFEAT_ARM_SMCCC_supported
 * Removed patch that added inject_undef_exception() and friends
   to the processor.h

This patch series depends on Julien's patches for traps.c cleanup ([1]).

There was discussion about SMCCC bindings (e.g. how to tell guest, that
it can safelly call SMCCC routines). As temporary solution, we'll
provide XENFEAT_ARM_SMCCC_supported feature. More generic solution
is still under discussion.

[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg117839.html

---
v3:

This is third version. Instead of 4 patches, there are 7 now.
As part of the series, I make some functions in traps.c
available globally, moved SMC conditional check into
separate patch, changed how PSCI functiond numbers are defined.

---
v2:

This is second version. Instead of 2 patches, there are 4 now.
I have divided PSCI patch into two: one changes how PSCI
code accesses registers and second one moves PSCI code with
new accessors to vsmc.c.

Also I had removed redundant 64 bit mode check in PSCI code, as it
does not conforms with SMCCC.

---
v1:

This patch series adds a generic way to handle standard calls
that are defined in ARM SMC calling convention (SMCCC).

First patch adds generic handler and second one moves PSCI
handling code to that generic handler.

With this patch series guest can query hypervisor in a standard
way to determine which virtualization system is used.
The same applies to PSCI calls. Now guest can tell if PSCI calls
are handled by hypervisor or by, say, ARM TF.

Also those patches are needed for upcoming TEE support.
---


Volodymyr Babchuk (10):
  arm: traps: use generic register accessors in the PSCI code
  arm: traps: check if SMC was conditional before handling it
  public: xen.h: add definitions for UUID handling
  arm: processor.h: add definition for immediate value mask
  arm: add SMCCC protocol definitions
  arm: smccc: handle SMCs according to SMCCC
  arm: traps: handle PSCI calls inside `vsmc.c`
  arm: PSCI: use definitions provided by asm/smccc.h
  arm: vsmc: remove 64 bit mode check in PSCI handler
  public: add and enable XENFEAT_ARM_SMCCC_supported feature

 xen/arch/arm/Makefile   |   1 +
 xen/arch/arm/platforms/seattle.c|   4 +-
 xen/arch/arm/psci.c |  10 +-
 xen/arch/arm/traps.c| 132 +-
 xen/arch/arm/vsmc.c | 339 
 xen/common/kernel.c |   3 +
 xen/include/asm-arm/processor.h |   3 +
 xen/include/asm-arm/psci.h  |  44 +++--
 xen/include/asm-arm/smccc.h | 105 +++
 xen/include/asm-arm/traps.h |   4 +
 xen/include/public/arch-arm/smccc.h |  66 +++
 xen/include/public/features.h   |   3 +
 xen/include/public/xen.h|  13 ++
 13 files changed, 566 insertions(+), 161 deletions(-)
 create mode 100644 xen/arch/arm/vsmc.c
 create mode 100644 xen/include/asm-arm/smccc.h
 create mode 100644 xen/include/public/arch-arm/smccc.h

-- 
2.7.4


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

[Xen-devel] [PATCH v5 05/10] arm: add SMCCC protocol definitions

This patch adds generic definitions used in ARM SMC call convention.
Those definitions was taken from linux header arm-smccc.h, extended
and formatted according to XEN coding style. Some of the macros were
converted to inlined functions to ease parsing.

They can be used by both SMCCC clients (like PSCI) and by SMCCC
servers (like vPSCI or upcoming generic SMCCC handler).

Signed-off-by: Volodymyr Babchuk 
---

 * Accessor macros were converted to inlined functions
 * ARM_SMCCC_SMC_{32,64} renamed to  ARM_SMCCC_CONV_{32,64}
 * Fixed indentation for ARM_SMCCC_CALL_VAL

---

xen/include/asm-arm/smccc.h | 105 
 1 file changed, 105 insertions(+)
 create mode 100644 xen/include/asm-arm/smccc.h

diff --git a/xen/include/asm-arm/smccc.h b/xen/include/asm-arm/smccc.h
new file mode 100644
index 000..f543dea
--- /dev/null
+++ b/xen/include/asm-arm/smccc.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ * Copyright (c) 2017, EPAM Systems
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __ASM_ARM_SMCCC_H__
+#define __ASM_ARM_SMCCC_H__
+
+/*
+ * This file provides common defines for ARM SMC Calling Convention as
+ * specified in
+ * http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+ */
+
+#define ARM_SMCCC_STD_CALL  0U
+#define ARM_SMCCC_FAST_CALL 1U
+#define ARM_SMCCC_TYPE_SHIFT31
+
+#define ARM_SMCCC_CONV_32   0U
+#define ARM_SMCCC_CONV_64   1U
+#define ARM_SMCCC_CONV_SHIFT30
+
+#define ARM_SMCCC_OWNER_MASK0x3FU
+#define ARM_SMCCC_OWNER_SHIFT   24
+
+#define ARM_SMCCC_FUNC_MASK 0xU
+
+/* Check if this is fast call. */
+static inline bool smccc_is_fast_call(register_t funcid)
+{
+return funcid & (ARM_SMCCC_FAST_CALL << ARM_SMCCC_TYPE_SHIFT);
+}
+
+/* Chek if this is 64-bit call. */
+static inline bool smccc_is_conv_64(register_t funcid)
+{
+return funcid & (ARM_SMCCC_CONV_64 << ARM_SMCCC_CONV_SHIFT);
+}
+
+/* Get function number from function identifier. */
+static inline uint32_t smccc_get_fn(register_t funcid)
+{
+return funcid & ARM_SMCCC_FUNC_MASK;
+}
+
+/* Get service owner number from function identifier. */
+static inline uint32_t smccc_get_owner(register_t funcid)
+{
+return (funcid >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK;
+}
+
+/*
+ * Construct function identifier from call type (fast or standard),
+ * calling convention (32 or 64 bit), service owner and function number.
+ */
+#define ARM_SMCCC_CALL_VAL(type, calling_convention, owner, func_num)  
 \
+(((type) << ARM_SMCCC_TYPE_SHIFT) |
 \
+ ((calling_convention) << ARM_SMCCC_CONV_SHIFT) |  
 \
+ (((owner) & ARM_SMCCC_OWNER_MASK) << ARM_SMCCC_OWNER_SHIFT) | 
 \
+ (func_num))
+
+/* List of known service owners */
+#define ARM_SMCCC_OWNER_ARCH0
+#define ARM_SMCCC_OWNER_CPU 1
+#define ARM_SMCCC_OWNER_SIP 2
+#define ARM_SMCCC_OWNER_OEM 3
+#define ARM_SMCCC_OWNER_STANDARD4
+#define ARM_SMCCC_OWNER_HYPERVISOR  5
+#define ARM_SMCCC_OWNER_TRUSTED_APP 48
+#define ARM_SMCCC_OWNER_TRUSTED_APP_END 49
+#define ARM_SMCCC_OWNER_TRUSTED_OS  50
+#define ARM_SMCCC_OWNER_TRUSTED_OS_END  63
+
+/* List of generic function numbers */
+#define ARM_SMCCC_FUNC_CALL_COUNT   0xFF00
+#define ARM_SMCCC_FUNC_CALL_UID 0xFF01
+#define ARM_SMCCC_FUNC_CALL_REVISION0xFF03
+
+/* Only one error code defined in SMCCC */
+#define ARM_SMCCC_ERR_UNKNOWN_FUNCTION  (-1)
+
+/* SMCCC function identifier range which is reserved for existing APIs */
+#define ARM_SMCCC_RESERVED_RANGE_START  0x0
+#define ARM_SMCCC_RESERVED_RANGE_END0x0100
+
+#endif  /* __ASM_ARM_SMCCC_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:b
+ */
-- 
2.7.4


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

[Xen-devel] [seabios test] 112978: tolerable FAIL - PUSHED

flight 112978 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112978/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112966 
pass in 112978
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail pass in 112966

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112938
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  ef5fdc99b771349264b4ba0aac1c654c8789386f
baseline version:
 seabios  b404a5f417cbe5593f89c79954569b0e245fb80c

Last test of basis   112938  2017-08-29 10:18:13 Z2 days
Testing same since   112951  2017-08-30 04:29:33 Z1 days3 attempts


People who touched revisions under test:
  Kevin O'Connor 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel 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=seabios
+ revision=ef5fdc99b771349264b4ba0aac1c654c8789386f
+ . ./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 seabios 
ef5fdc99b771349264b4ba0aac1c654c8789386f
+ branch=seabios
+ revision=ef5fdc99b771349264b4ba0aac1c654c8789386f
+ . ./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

[Xen-devel] [xtf test] 112985: all pass - PUSHED

flight 112985 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112985/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  295eeb7e3cd8c506c5ade03865a0e440a5cd8b22
baseline version:
 xtf  b369b8f9cc89f906deba9ae1b1a6d27ac745cf2d

Last test of basis   112790  2017-08-21 17:14:56 Z   10 days
Testing same since   112985  2017-08-31 13:15:43 Z0 days1 attempts


People who touched revisions under test:
  Petre Pircalabu 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=295eeb7e3cd8c506c5ade03865a0e440a5cd8b22
+ . ./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 xtf 
295eeb7e3cd8c506c5ade03865a0e440a5cd8b22
+ branch=xtf
+ revision=295eeb7e3cd8c506c5ade03865a0e440a5cd8b22
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.9-testing
+ '[' x295eeb7e3cd8c506c5ade03865a0e440a5cd8b22 = 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
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-4.9
++ : tested/linux-arm-xen
++ '['

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

2017-08-31 Thread Thomas Gleixner

On Thu, 31 Aug 2017, Boris Ostrovsky wrote:

> On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
> > On Thu, 31 Aug 2017, Juergen Gross wrote:
> >>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> >>> mindlessly. Patch below.
> >>>
> >>> Juergen, can you please check the result?
> >> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
> >> of the xen specific trap entries in arch/x86/include/asm/traps.h
> > I'll try that again later today, unless you beat me to it.
> >
> 
> https://marc.info/?l=linux-kernel=150296063131595=2 should also be
> picked up by the tip tree then since it applies on top of the
> adjust_exception_frame patch. I will revert it from Xen tree as well.

Juergen folded that fix in and posted a version against tip:x86/apic. It's
applied and pushed out now.

Thanks to everyone helping with this.

   tglx

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

[Xen-devel] [linux-4.9 test] 112973: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   5 host-build-prep  fail REGR. vs. 112863
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112953 
REGR. vs. 112863

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-localmigrate  fail pass in 112953

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112863
 build-arm64   2 hosts-allocate  broken like 112863
 build-arm64-pvops 2 hosts-allocate  broken like 112863
 build-arm64   3 capture-logsbroken like 112863
 build-arm64-pvops 3 capture-logsbroken like 112863
 build-arm64-xsm   3 capture-logs broken never pass
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
112863
 test-armhf-armhf-xl-rtds 12 guest-start fail in 112953 like 112863
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 112953 
like 112863
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 112953 never 
pass
 test-armhf-armhf-xl-credit2 13 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-xl-credit2 14 saverestore-support-check fail in 112953 never 
pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail in 112953 never 
pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 112953 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 112953 
never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 112953 
never pass
 test-armhf-armhf-xl 13 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112953 never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail in 112953 never 
pass
 test-armhf-armhf-libvirt13 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-check fail in 112953 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112953 never 
pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 112953 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 112953 never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112863
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112863
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112863
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass

[Xen-devel] [PATCH v5] xen: get rid of paravirt op adjust_exception_frame

2017-08-31 Thread Juergen Gross

From: Juergen Gross 

When running as Xen pv-guest the exception frame on the stack contains
%r11 and %rcx additional to the other data pushed by the processor.

Instead of having a paravirt op being called for each exception type
prepend the Xen specific code to each exception entry. When running as
Xen pv-guest just use the exception entry with prepended instructions,
otherwise use the entry without the Xen specific code.

Signed-off-by: Juergen Gross 
---
 arch/x86/entry/entry_64.S | 23 ++--
 arch/x86/entry/entry_64_compat.S  |  1 -
 arch/x86/include/asm/paravirt.h   |  5 --
 arch/x86/include/asm/paravirt_types.h |  3 --
 arch/x86/include/asm/proto.h  |  3 ++
 arch/x86/include/asm/traps.h  | 28 --
 arch/x86/kernel/asm-offsets_64.c  |  1 -
 arch/x86/kernel/paravirt.c|  3 --
 arch/x86/xen/enlighten_pv.c   | 98 +++
 arch/x86/xen/irq.c|  3 --
 arch/x86/xen/xen-asm_64.S | 41 +--
 arch/x86/xen/xen-ops.h|  1 -
 12 files changed, 133 insertions(+), 77 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 7a1d383c2192..bdd024a9afc9 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -821,7 +821,6 @@ ENTRY(\sym)
.endif
 
ASM_CLAC
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
 
.ifeq \has_error_code
pushq   $-1 /* ORIG_RAX: no syscall to 
restart */
@@ -967,7 +966,7 @@ ENTRY(do_softirq_own_stack)
 ENDPROC(do_softirq_own_stack)
 
 #ifdef CONFIG_XEN
-idtentry xen_hypervisor_callback xen_do_hypervisor_callback has_error_code=0
+idtentry hypervisor_callback xen_do_hypervisor_callback has_error_code=0
 
 /*
  * A note on the "critical region" in our callback handler.
@@ -1034,8 +1033,6 @@ ENTRY(xen_failsafe_callback)
movq8(%rsp), %r11
addq$0x30, %rsp
pushq   $0  /* RIP */
-   pushq   %r11
-   pushq   %rcx
UNWIND_HINT_IRET_REGS offset=8
jmp general_protection
 1: /* Segment mismatch => Category 1 (Bad segment). Retry the IRET. */
@@ -1066,9 +1063,8 @@ idtentry int3 do_int3 
has_error_code=0paranoid=1 shift_ist=DEBUG_STACK
 idtentry stack_segment do_stack_segmenthas_error_code=1
 
 #ifdef CONFIG_XEN
-idtentry xen_debug do_debughas_error_code=0
-idtentry xen_int3  do_int3 has_error_code=0
-idtentry xen_stack_segment do_stack_segmenthas_error_code=1
+idtentry xendebug  do_debughas_error_code=0
+idtentry xenint3   do_int3 has_error_code=0
 #endif
 
 idtentry general_protectiondo_general_protection   has_error_code=1
@@ -1232,21 +1228,10 @@ ENTRY(error_exit)
 END(error_exit)
 
 /* Runs on exception stack */
+/* XXX: broken on Xen PV */
 ENTRY(nmi)
UNWIND_HINT_IRET_REGS
/*
-* Fix up the exception frame if we're on Xen.
-* PARAVIRT_ADJUST_EXCEPTION_FRAME is guaranteed to push at most
-* one value to the stack on native, so it may clobber the rdx
-* scratch slot, but it won't clobber any of the important
-* slots past it.
-*
-* Xen is a different story, because the Xen frame itself overlaps
-* the "NMI executing" variable.
-*/
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
-
-   /*
 * We allow breakpoints in NMIs. If a breakpoint occurs, then
 * the iretq it performs will take us out of NMI context.
 * This means that we can have nested NMIs where the next
diff --git a/arch/x86/entry/entry_64_compat.S b/arch/x86/entry/entry_64_compat.S
index 5314d7b8e5ad..d8468ba24be0 100644
--- a/arch/x86/entry/entry_64_compat.S
+++ b/arch/x86/entry/entry_64_compat.S
@@ -293,7 +293,6 @@ ENTRY(entry_INT80_compat)
/*
 * Interrupts are off on entry.
 */
-   PARAVIRT_ADJUST_EXCEPTION_FRAME
ASM_CLAC/* Do this early to minimize exposure */
SWAPGS
 
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 9ccac1926587..c25dd22f7c70 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -960,11 +960,6 @@ extern void default_banner(void);
 #define GET_CR2_INTO_RAX   \
call PARA_INDIRECT(pv_mmu_ops+PV_MMU_read_cr2)
 
-#define PARAVIRT_ADJUST_EXCEPTION_FRAME
\
-   PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_adjust_exception_frame), \
- CLBR_NONE,\
- call PARA_INDIRECT(pv_irq_ops+PV_IRQ_adjust_exception_frame))
-
 #define USERGS_SYSRET64
\

[Xen-devel] [xen-unstable-smoke test] 112988: tolerable trouble: broken/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112956
 build-arm64-pvops 3 capture-logsbroken like 112956
 build-arm64   2 hosts-allocate  broken like 112956
 build-arm64   3 capture-logsbroken like 112956
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  e1c10ecdf7f0a4437e631bdbf887ce4af4c03a1b
baseline version:
 xen  dab6a84aadab11f31332030a1e9f0b9282d76156

Last test of basis   112956  2017-08-30 09:56:56 Z1 days
Failing since112957  2017-08-30 12:02:17 Z1 days   14 attempts
Testing same since   112988  2017-08-31 16:01:21 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Razvan Cojocaru 
  Sergej Proskurin 
  Tim Deegan 
  Wei Liu 
  Yi Sun 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=e1c10ecdf7f0a4437e631bdbf887ce4af4c03a1b
+ . ./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 
e1c10ecdf7f0a4437e631bdbf887ce4af4c03a1b
+ branch=xen-unstable-smoke
+ revision=e1c10ecdf7f0a4437e631bdbf887ce4af4c03a1b
+ . ./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.9-testing
+ '[' xe1c10ecdf7f0a4437e631bdbf887ce4af4c03a1b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();

[Xen-devel] [PATCH] x86/pv: Prohibit attempts to initialise a vcpu with EFLAGS.{NT, VM} set

Luckily, this isn't a security issue, because the fix for XSA-202 (c/s
0e47f92b072) took a proactive aproach and clobbered these flags on the
exit-to-guest path.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/domain.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index dbddc53..ced1d2e 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -765,7 +765,8 @@ int arch_set_info_guest(
  !is_canonical_address(c.nat->gs_base_user) ||
  !is_canonical_address(c.nat->event_callback_eip) ||
  !is_canonical_address(c.nat->syscall_callback_eip) ||
- !is_canonical_address(c.nat->failsafe_callback_eip) )
+ !is_canonical_address(c.nat->failsafe_callback_eip) ||
+ (c.nat->user_regs.rflags & (X86_EFLAGS_NT|X86_EFLAGS_VM)) )
 return -EINVAL;
 
 fixup_guest_stack_selector(d, c.nat->user_regs.ss);
@@ -784,6 +785,9 @@ int arch_set_info_guest(
 }
 else
 {
+if ( c.nat->user_regs.eflags & (X86_EFLAGS_NT|X86_EFLAGS_VM) )
+return -EINVAL;
+
 fixup_guest_stack_selector(d, c.cmp->user_regs.ss);
 fixup_guest_stack_selector(d, c.cmp->kernel_ss);
 fixup_guest_code_selector(d, c.cmp->user_regs.cs);
-- 
2.1.4


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

[Xen-devel] [libvirt test] 112974: tolerable trouble: blocked/broken/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112918
 build-arm64-xsm   2 hosts-allocate  broken like 112918
 build-arm64   2 hosts-allocate  broken like 112918
 build-arm64-pvops 3 capture-logsbroken like 112918
 build-arm64-xsm   3 capture-logsbroken like 112918
 build-arm64   3 capture-logsbroken like 112918
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112918
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112918
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112918
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  d16f803d780f63b8899df04b624d5acfd6939541
baseline version:
 libvirt  5aaa304f8dbc5ddf0b0ca56f7551bdb9e554db0a

Last test of basis   112918  2017-08-29 04:20:17 Z2 days
Failing since112950  2017-08-30 04:20:16 Z1 days2 attempts
Testing same since   112974  2017-08-31 04:24:55 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  John Ferlan 
  Kothapally Madhu Pavan 
  Martin Kletzander 
  Michal Privoznik 
  Pavel Hrdina 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass

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

2017-08-31 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ea8314e4402f6c385b6e41e4f7803853e64e421b
baseline version:
 ovmf 5202e6c907e5769ac8ecb024b7a07509bdba6181

Last test of basis72043  2017-08-31 01:49:04 Z0 days
Testing same since72045  2017-08-31 14:17:29 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Brijesh Singh 
  Laszlo Ersek 

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 ea8314e4402f6c385b6e41e4f7803853e64e421b
Author: Brijesh Singh 
Date:   Wed Aug 30 12:28:29 2017 -0400

OvmfPkg/VirtioBlkDxe: Check the return status of unmap data buffer

when "RequestIsWrite" is FALSE -- i.e., the CPU wants data from
the device, we map "Buffer" for VirtioOperationBusMasterWrite. In
this case, checking the return status of

Dev->VirtIo->UnmapSharedBuffer (Dev->VirtIo, BufferMapping);

is must. If the unmapping fails, then "Buffer" will not contain the
actual data from the device, and we must fail the request with
EFI_DEVICE_ERROR.

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Tom Lendacky 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh 
[ler...@redhat.com: fix typos in subject]
Reviewed-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

commit 877f4460b3e37064f37fe85375024dce04f5e05e
Author: Ard Biesheuvel 
Date:   Wed Aug 30 09:10:25 2017 +0100

BeagleBoardPkg: switch to generic non-coherent DmaLib

Replace the reference to the ARM specific ArmDmaLib with a reference
to the generic NonCoherentDmaLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit c878cd95e1327abf6f1b59687afd8bc4585cc9f8
Author: Ard Biesheuvel 
Date:   Wed Aug 30 08:51:23 2017 +0100

Omap35xxPkg: switch to EmbeddedPkg's NonCoherentDmaLib

Replace the reference to the ARM specific ArmDmaLib with a reference
to the generic NonCoherentDmaLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 723102c72fb0aefe88ea74fa096b0dc2f4e7
Author: Ard Biesheuvel 
Date:   Wed Aug 30 08:21:59 2017 +0100

EmbeddedPkg: implement NonCoherentDmaLib based on ArmDmaLib

The non-coherent DmaLib implementation in ArmDmaLib no longer relies on
anything in ArmPkg. So clone it into EmbeddedPkg, and rename it to
NonCoherentDmaLib.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Leif Lindholm 

commit 0bcb80106762c65463b1eac4009a59980a65b351
Author: Ard Biesheuvel 
Date:   Wed Aug 30 08:02:15 2017 +0100

EmbeddedPkg/CoherentDmaLib: add support for non-1:1 DMA translation

Bring CoherentDmaLib in line with ArmDmaLib, and add support for
defining a static offset between the host's and the bus master's
view of memory.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by:

Re: [Xen-devel] [PATCH] x86: mark the entire directmap NX

On 31/08/17 16:55, Jan Beulich wrote:
> There's no reason for the first Mb to be excluded here. Enforce the
> restriction right in the top level page table entries.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v5 3/4] VT-d PI: restrict the number of vcpus in a given pcpu's PI blocking list

>>> On 16.08.17 at 07:14,  wrote:
> +static inline bool pi_over_limit(unsigned int cpu)
> +{
> +/* Compare w/ constant first to save a division and an add */
> +if ( likely(read_atomic(_cpu(vmx_pi_blocking, cpu).counter) <=
> +PI_LIST_FIXED_LIMIT) )
> +return 0;

false

> +else

Pointless else.

> +static unsigned int pi_get_blocking_cpu(unsigned int cpu, unsigned long 
> *flags)
> +{
> +spinlock_t *pi_blocking_list_lock;
> +
> +for ( ; ; )
> +{
> +while ( unlikely(pi_over_limit(cpu)) )
> +cpu = cpumask_cycle(cpu, _online_map);
> +
> +pi_blocking_list_lock = _cpu(vmx_pi_blocking, cpu).lock;
> +if ( flags )
> +spin_lock_irqsave(pi_blocking_list_lock, *flags);
> +else
> +spin_lock(pi_blocking_list_lock);

This is ugly, but I think I see why you want it this way. Let's see
what the maintainers think.

Jan


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

Re: [Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

2017-08-31 Thread Roger Pau Monné

On Thu, Aug 31, 2017 at 09:07:59AM -0600, Jan Beulich wrote:
> >>> On 31.08.17 at 16:58,  wrote:
> > --- a/xen/include/public/arch-x86/xen.h
> > +++ b/xen/include/public/arch-x86/xen.h
> > @@ -162,14 +162,10 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp 
> > */
> >   * The following is all CPU context. Note that the fpu_ctxt block is filled
> >   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
> >   *
> > - * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
> > - * for HVM and PVH guests, not all information in this structure is 
> > updated:
> > - *
> > - * - For HVM guests, the structures read include: fpu_ctxt (if
> > - * VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
> > - *
> > - * - PVH guests are the same as HVM guests, but additionally use 
> > ctrlreg[3] to
> > - * set cr3. All other fields not used should be set to 0.
> > + * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise 
> > for
> > + * HVM guests, not all information in this structure is updated, the 
> > structure
> > + * read include: fpu_ctxt (if VGCT_I387_VALID is set), flags, user_regs and
> > + * debugreg[*].
> 
> Instead of "the structure read" (where you've lost the plural),
> how about "the fields read" or "the pieces read"? With either of
> these (easily doable while committing)

I guess "the fields read"? (sounds better than pieces)

> Acked-by: Jan Beulich 

Thanks, Roger.

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

[Xen-devel] [PATCH] x86: mark the entire directmap NX

There's no reason for the first Mb to be excluded here. Enforce the
restriction right in the top level page table entries.

Suggested-by: Andrew Cooper 
Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -887,32 +887,21 @@ void __init subarch_init_memory(void)
 }
 }
 
-/* Mark low 16Mb of direct map NX if hardware supports it. */
+/* Mark all of direct map NX if hardware supports it. */
 if ( !cpu_has_nx )
 return;
 
-v = DIRECTMAP_VIRT_START + (1UL << 20);
-l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[l3_table_offset(v)];
-ASSERT(l3e_get_flags(l3e) & _PAGE_PRESENT);
-do {
-l2e = l3e_to_l2e(l3e)[l2_table_offset(v)];
-ASSERT(l2e_get_flags(l2e) & _PAGE_PRESENT);
-if ( l2e_get_flags(l2e) & _PAGE_PSE )
-{
-l2e_add_flags(l2e, _PAGE_NX_BIT);
-l3e_to_l2e(l3e)[l2_table_offset(v)] = l2e;
-v += 1 << L2_PAGETABLE_SHIFT;
-}
-else
-{
-l1_pgentry_t l1e = l2e_to_l1e(l2e)[l1_table_offset(v)];
+for ( i = l4_table_offset(DIRECTMAP_VIRT_START);
+  i < l4_table_offset(DIRECTMAP_VIRT_END); ++i )
+{
+l4_pgentry_t l4e = idle_pg_table[i];
 
-ASSERT(l1e_get_flags(l1e) & _PAGE_PRESENT);
-l1e_add_flags(l1e, _PAGE_NX_BIT);
-l2e_to_l1e(l2e)[l1_table_offset(v)] = l1e;
-v += 1 << L1_PAGETABLE_SHIFT;
+if ( l4e_get_flags(l4e) & _PAGE_PRESENT )
+{
+l4e_add_flags(l4e, _PAGE_NX_BIT);
+idle_pg_table[i] = l4e;
 }
-} while ( v < DIRECTMAP_VIRT_START + (16UL << 20) );
+}
 }
 
 long subarch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)




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

Re: [Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

2017-08-31 Thread Roger Pau Monné

On Thu, Aug 31, 2017 at 09:16:35AM -0600, Jan Beulich wrote:
> >>> On 31.08.17 at 17:10,  wrote:
> > Changes since v1:
> >  - Completely remove the comment, HVM guests also use
> >vcpu_hvm_context instead of vcpu_guest_context.
> 
> Are you sure? Specifically for ...
> 
> > --- a/xen/include/public/arch-x86/xen.h
> > +++ b/xen/include/public/arch-x86/xen.h
> > @@ -161,15 +161,6 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
> >  /*
> >   * The following is all CPU context. Note that the fpu_ctxt block is filled
> >   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
> > - *
> > - * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
> 
> ... the DOMCTL_setvcpucontext part.

Right, I couldn't change DOMCTL_setvcpucontext to use the new struct
because it was already in use by gdbsx.

So v1 is the right version.

Thanks, Roger.

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

Re: [Xen-devel] [xen-unstable-smoke test] 112957: regressions - trouble: broken/fail/pass

On Wed, Aug 30, 2017 at 03:15:09PM +0100, George Dunlap wrote:
> On 08/30/2017 02:54 PM, Andrew Cooper wrote:
> > On 30/08/17 14:49, osstest service owner wrote:
> >> flight 112957 xen-unstable-smoke real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/112957/
> >>
> >> Regressions :-(
> >>
> >> Tests which did not succeed and are blocking,
> >> including tests which could not be run:
> >>  test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 
> >> 112956
> > 
> > (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35
> > (XEN) [ Xen-4.10-unstable  arm32  debug=y   Not tainted ]
> > (XEN) CPU:1
> > (XEN) PC: 0023b710 softirq.c#__do_softirq+0x3c/0x134
> > (XEN) CPSR:   805a MODE:Hypervisor
> > (XEN)  R0: 4003d000 R1: 0001 R2: 3fcffd00 R3: 0001
> > (XEN)  R4: 002e5f74 R5:  R6: 0031d694 R7: 0031a224
> > (XEN)  R8: 002e1f80 R9: 0029b880 R10:0001 R11:40037f3c R12:
> > (XEN) HYP: SP: 40037f04 LR: 0025826c
> > (XEN) 
> > (XEN)   VTCR_EL2: 80003558
> > (XEN)  VTTBR_EL2: 0001bff1e000
> > (XEN) 
> > (XEN)  SCTLR_EL2: 30cd187f
> > (XEN)HCR_EL2: 0038663f
> > (XEN)  TTBR0_EL2: ba016000
> > (XEN) 
> > (XEN)ESR_EL2: 
> > (XEN)  HPFAR_EL2: 00104810
> > (XEN)  HDFAR: df000f00
> > (XEN)  HIFAR: 
> > (XEN) 
> > (XEN) Xen stack trace from sp=40037f04:
> > (XEN) 0004 002e1f80   002e1f80 0031d694 
> > 002e1f80
> > (XEN)c1203098 0001   c11151a8 40037f44 0023b87c 
> > 40037f54
> > (XEN)0026b320 c120 c1203034 40037f58 0026ef40 0001  
> > 0001
> > (XEN)c031c520 c120 c1203034 c1203098 0001   
> > c11151a8
> > (XEN)c12030a0 192b8000  7f5706d3 c031c528 6093 07e0 
> > bebcd108
> > (XEN)c1318ac0 c030d0a0 c1201fa0 c030928c c1318acc c030d420 c1318ad8 
> > c030d4e0
> > (XEN)     c1318ae4 c1318ae4 
> > 6013
> > (XEN)60010193 2093 6193    
> > (XEN) Xen call trace:
> > (XEN)[<0023b710>] softirq.c#__do_softirq+0x3c/0x134 (PC)
> > (XEN)[<0025826c>] domain.c#schedule_tail+0x2f4/0x308 (LR)
> > (XEN)[<0023b87c>] do_softirq+0x18/0x28
> > (XEN)[<0026b320>] leave_hypervisor_tail+0x84/0xb8
> > (XEN)[<0026ef40>] entry.o#return_to_guest+0xc/0xb8
> > (XEN) 
> > (XEN) 
> > (XEN) 
> > (XEN) Panic on CPU 1:
> > (XEN) Assertion 'cpu == smp_processor_id()' failed at softirq.c:35
> > (XEN) 
> > (XEN) 
> > (XEN) Manual reset required ('noreboot' specified)
> > 
> > At a guess, I'd say the reasoning behind
> > http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=57450cfe48b56db90166c52d45a411a9279a12e1
> > is false.
> 
> Wow -- I actually rather doubt that the reasoning is wrong; I can't see
> anywhere in the context switch path that could possibly move the
> hypervisor stack to another processor.  I'd be more inclined to suspect
> that smp_processor_id() returns the wrong value under certain conditions
> -- e.g., between a schedule() softirq and the next VMENTER (whatever
> it's called on ARM).
> 
> Stefano, any ideas?
> 
>  -George
> 

In the mean time I have just reverted the offending patch to unblock
pushgate.

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

Re: [Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

2017-08-31 Thread Roger Pau Monné

On Thu, Aug 31, 2017 at 01:01:47AM -0400, Lan Tianyu wrote:
> This patch is to change DSDT table for processor object to support >128 vcpus
> accroding to ACPI spec 8.4 Declaring Processors
> 
> Signed-off-by: Lan Tianyu 
> ---
>  tools/libacpi/mk_dsdt.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
> index 2daf32c..6c4c325 100644
> --- a/tools/libacpi/mk_dsdt.c
> +++ b/tools/libacpi/mk_dsdt.c
> @@ -24,6 +24,8 @@
>  #include 
>  #endif
>  
> +#define CPU_NAME_FMT  "P%.03X"
> +
>  static unsigned int indent_level;
>  static bool debug = false;
>  
> @@ -196,10 +198,14 @@ int main(int argc, char **argv)
>  /* Define processor objects and control methods. */
>  for ( cpu = 0; cpu < max_cpus; cpu++)
>  {
> -push_block("Processor", "PR%02X, %d, 0xb010, 0x06", cpu, cpu);
> +unsigned int apic_id = cpu * 2;

This is fragile, ideally there should be a single point where the APIC
ID is calculated. Although there are already two places where the APIC
ID is calculated, in hvmloader and libxl.

And I'm not sure how to use any of those here in order to avoid
introducing a third one.

>  
> -stmt("Name", "_HID, \"ACPI0007\"");
> +if ( apic_id > 255 )

We need to be careful with this. This is not a problem ATM because the
ACPI ID is the CPU ID, but care should be taken to not create a
Processor object with ACPI ID 255, because that's the broadcast ACPI
ID...

> +push_block("Device", CPU_NAME_FMT, cpu);
> +else

... IMHO an assert(cpu < 255); should be added here.

> +push_block("Processor", CPU_NAME_FMT", %d, 0xb010, 0x06", 
> cpu, cpu);
   ^ space (here and below)

Please leave a space between the string literals and the defines, it
makes it easier to read. And this line needs to be split.

>  
> +stmt("Name", "_HID, \"ACPI0007\"");
>  stmt("Name", "_UID, %d", cpu);
>  #ifdef CONFIG_ARM_64
>  pop_block();
> @@ -268,15 +274,15 @@ int main(int argc, char **argv)
>  /* Extract current CPU's status: 0=offline; 1=online. */
>  stmt("And", "Local1, 1, Local2");
>  /* Check if status is up-to-date in the relevant MADT LAPIC entry... 
> */
> -push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
> +push_block("If", "LNotEqual(Local2, \\_SB."CPU_NAME_FMT ".FLG)", 
> cpu);
>  /* ...If not, update it and the MADT checksum, and notify OSPM. */
> -stmt("Store", "Local2, \\_SB.PR%02X.FLG", cpu);
> +stmt("Store", "Local2, \\_SB."CPU_NAME_FMT".FLG", cpu);
>  push_block("If", "LEqual(Local2, 1)");
> -stmt("Notify", "PR%02X, 1", cpu); /* Notify: Device Check */
> +stmt("Notify", CPU_NAME_FMT", 1", cpu); /* Notify: Device Check */
>  stmt("Subtract", "\\_SB.MSU, 1, \\_SB.MSU"); /* Adjust MADT csum */
>  pop_block();
>  push_block("Else", NULL);
> -stmt("Notify", "PR%02X, 3", cpu); /* Notify: Eject Request */
> +stmt("Notify", CPU_NAME_FMT", 3", cpu); /* Notify: Eject Request */
>  stmt("Add", "\\_SB.MSU, 1, \\_SB.MSU"); /* Adjust MADT csum */
>  pop_block();
>  pop_block();
> -- 
> 1.8.3.1
> 

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

Re: [Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

>>> On 31.08.17 at 17:10,  wrote:
> Changes since v1:
>  - Completely remove the comment, HVM guests also use
>vcpu_hvm_context instead of vcpu_guest_context.

Are you sure? Specifically for ...

> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -161,15 +161,6 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
>  /*
>   * The following is all CPU context. Note that the fpu_ctxt block is filled
>   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
> - *
> - * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise

... the DOMCTL_setvcpucontext part.

Jan


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

[Xen-devel] [xen-unstable-smoke test] 112984: regressions - trouble: broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 112956

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112956
 build-arm64-pvops 3 capture-logsbroken like 112956
 build-arm64   2 hosts-allocate  broken like 112956
 build-arm64   3 capture-logsbroken like 112956
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  38ac6fa969a43ca993e610deae8976f9f2877fbb
baseline version:
 xen  dab6a84aadab11f31332030a1e9f0b9282d76156

Last test of basis   112956  2017-08-30 09:56:56 Z1 days
Failing since112957  2017-08-30 12:02:17 Z1 days   13 attempts
Testing same since   112980  2017-08-31 09:02:13 Z0 days3 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 385 lines long.)

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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

>>> On 31.08.17 at 15:21,  wrote:
> So, will it be acceptable to use my approach with that union?

As per Ian's reply, go with just the containerized uint8_t[].

Jan


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

[Xen-devel] [linux-3.18 test] 112970: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 112102
 test-armhf-armhf-xl-multivcpu  8 host-ping-check-xen fail REGR. vs. 112102

Regressions which are regarded as allowable (not blocking):
 build-arm64   2 hosts-allocate broken REGR. vs. 112102
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   3 capture-logs  broken blocked in 112102
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux2713f9f39b8fd713d914c0051b8dc5acf1bc2c6d
baseline version:
 linuxdd8b674caeef9381345a6369fba29d425ff433f3

Last test of basis   112102  2017-07-21 17:53:24 Z   40 days
Failing since112351  2017-07-27 22:26:55 Z   34 days   52 attempts
Testing same since   112970  2017-08-31 01:17:57 Z0

[Xen-devel] [PATCH v2] x86/pvh: remove stale HVM/PVHv1 comment from public headers

2017-08-31 Thread Roger Pau Monne

From the vcpu_guest_context structure. PVHv2/HVM uses a completely
different structure (vcpu_hvm_context), that's described in
hvm_vpcu.h.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
Changes since v1:
 - Completely remove the comment, HVM guests also use
   vcpu_hvm_context instead of vcpu_guest_context.
---
 xen/include/public/arch-x86/xen.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index f21332e897..ba40b97e97 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -161,15 +161,6 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 /*
  * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
- *
- * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
- * for HVM and PVH guests, not all information in this structure is updated:
- *
- * - For HVM guests, the structures read include: fpu_ctxt (if
- * VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
- *
- * - PVH guests are the same as HVM guests, but additionally use ctrlreg[3] to
- * set cr3. All other fields not used should be set to 0.
  */
 struct vcpu_guest_context {
 /* FPU registers come first so they can be aligned for FXSAVE/FXRSTOR. */
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

>>> On 31.08.17 at 16:58,  wrote:
> --- a/xen/include/public/arch-x86/xen.h
> +++ b/xen/include/public/arch-x86/xen.h
> @@ -162,14 +162,10 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp 
> */
>   * The following is all CPU context. Note that the fpu_ctxt block is filled
>   * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
>   *
> - * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
> - * for HVM and PVH guests, not all information in this structure is updated:
> - *
> - * - For HVM guests, the structures read include: fpu_ctxt (if
> - * VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
> - *
> - * - PVH guests are the same as HVM guests, but additionally use ctrlreg[3] 
> to
> - * set cr3. All other fields not used should be set to 0.
> + * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise 
> for
> + * HVM guests, not all information in this structure is updated, the 
> structure
> + * read include: fpu_ctxt (if VGCT_I387_VALID is set), flags, user_regs and
> + * debugreg[*].

Instead of "the structure read" (where you've lost the plural),
how about "the fields read" or "the pieces read"? With either of
these (easily doable while committing)
Acked-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

On Thu, Aug 31, 2017 at 01:36:13PM +0100, Andrew Cooper wrote:
> On 31/08/17 13:03, Jan Beulich wrote:
>  On 31.08.17 at 13:45,  wrote:
> >> There is only one function gate_op_read that needs to be modified.
> > I'm fine with it just being read() here, but I can see this being possibly
> > controversial. Please double check that Andrew isn't entirely opposed
> > to it. An alternative suggestion would then be read_mem().
> 
> I'm not opposed generally, but simply 'read' has a chance of angering
> Coverity, because it has inbuilt models for most functions specified by
> core standards like POSIX.
> 
> read_mem() would be better.
> 

read_mem it is.

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

Re: [Xen-devel] [PATCH v2 4/4] mm: Don't request scrubbing until dom0 is running

On Thu, Aug 31, 2017 at 09:16:14AM -0400, Boris Ostrovsky wrote:
> There is no need to scrub pages freed during dom0 construction since
> once dom0 is ready the heap will be scrubbed by scrub_heap_pages() anyway,
> setting scrub_debug at the end.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature


Hi Sergej

On 31.08.17 16:51, Sergej Proskurin wrote:

Hi Volodymyr,


On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote:

Hello Sergej,

On 31.08.17 15:20, Sergej Proskurin wrote:

Hi Volodymyr, hi Julien,


On 08/24/2017 07:25 PM, Julien Grall wrote:



On 21/08/17 21:27, Volodymyr Babchuk wrote:

This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Hypervisor will not inject an undefined
instruction exception if an invalid SMC function were called and
will not crash a domain if an invlalid HVC functions were called.


s/invlalid/invalid/

The last sentence is misleading. Xen will still inject and undefined
instruction for some SMC/HVC. You may want to rework it to make it
clear.



Now that you say that Xen will still inject an undefined instruction
exception for some SMCs, I have a to ask for which exactly?

For ones that are compatible with ARM SMCCC [1]. E.g if you are
running SMCCC-compatible system and you are calling SMC/HVC with
immediate value 0, then you are safe.



Alright, as far as I understand this is exactly what I do right now. I
inject an SMC that is encoded as 0xD403.
Actually, this patch series are not merged yet, so no SMCCC support 
right. But this should not a problem in your case.



I might be off topic here, so please tell me if you believe this is not
the right place for this question. In this case I will open an new
thread. Right now, I am working with the previous implementation of
do_trap_smc that was extended in this patch. Yet, as far as I
understand, the behavior should not change, which is why I am asking
this quesiton in this thread.

If you are talking about forwarding SMC exception to VM monitor, then
yes, that should not change.


Yes, exactly. Sorry, I forgot to mention that I have a modified
xen-access version running in dom0 that registers an SMC monitor and
also increases the PC by 4 (or dependent on the case, simply leaves it
as it is) on every SMC trap.

Aha, I see. I never was able to test this feature fully. I played with
my own VM monitor, when I tried to offload SMC handling to another 
domain. But I had to comment out most of the VM monitor code in XEN.





Currently, I am working on SMC guest injections and trying to understand
the resulting behavior. Every time, right after the execution of an
injected SMC instruction, the guest traps into the undefined instruction
exception handler in EL1 and I simply don't understand why. As far as I
understand, as soon an injected SMC instruction gets executed, it should
_transparently_ trap into the hypervisor (assuming MDCR_EL2.TDE is set).
As soon as the hypervisor returns (e.g. to PC+4 or to the trapping PC
that now contains the original instruction instead of the injected SMC),
the guest should simply continue its execution.

Hm. What do you mean under "SMC instruction injection?".


My code runs in dom0 and "injects" an SMC instruction to predefined
addresses inside the guest as to simulate software breakpoints. By this,
I mean that the code replaces the original guest instruction at a
certain address with an SMC. Think of a debugger that uses software
breakpoints. The idea is to put back the original instruction right
after the SMC gets called, so that the guest can continue with its
execution. You can find more information about that in [0], yet please
consider that I try to trap the SMC directly in Xen instead of TrustZone.
Yep, I see. Immediate question: do you flush icache after you put 
original instruction back? Then I can't see, why this should not work. 
If only VM monitor core in XEN is not broken. I don't know any users of 
this.

I'm just curious, why are you using SMC, not BRK instruction?


Current code in hypervisor will always inject undefined instruction
exception when you  call SMC (unless you installed VM monitor for the
guest). Also, it will not increase PC. So, if you'll try to remove
inject_undef_exception() call, you'll get into an infinite loop.



I have a registered SMC monitor running in dom0 that does not reinject
the undefined instruction exception in do_trap_smc(). So there is no
indefinite loop at this point. What I see is that as soon as my code in
xen-access (dom0) increments the trapped guest PC by 4 (and also if it
doesn't) the next instruction inside the guest will be inside the undef
instruction handler (I can see that because I have implemented a single
stepping mechanism for AArch64 in Xen that gets activated right after
the guest executes the injected SMC instruction).
That's strange. Can you print whole vCPU state to determine that PC 
points to the right place? Also you can check DFAR. Probably you can 
even dump memory pointed by DFAR to make sure that you written back 
correct instruction.



Now, according to ARM DDI0487B.a D1-1873, the following holds: "If
HCR_EL2.TSC or HCR.TSC traps attempted EL1 execution of SMC instructions
to EL2, that trap has priority over this disable". So this means that if
SMCs are disabled for NS EL1,

[Xen-devel] [PATCH] x86/pvh: remove stale PVHv1 comment from public headers

2017-08-31 Thread Roger Pau Monne

From the vcpu_guest_context structure. PVHv2 uses it in the same exact
way as HVM guests, and from the hypervisor point of view PVHv2 is not
even a different guest type, so only mention HVM in the public
headers.

Reported-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/include/public/arch-x86/xen.h | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index f21332e897..8732c875f2 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -162,14 +162,10 @@ typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
  * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
  *
- * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
- * for HVM and PVH guests, not all information in this structure is updated:
- *
- * - For HVM guests, the structures read include: fpu_ctxt (if
- * VGCT_I387_VALID is set), flags, user_regs, debugreg[*]
- *
- * - PVH guests are the same as HVM guests, but additionally use ctrlreg[3] to
- * set cr3. All other fields not used should be set to 0.
+ * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise for
+ * HVM guests, not all information in this structure is updated, the structure
+ * read include: fpu_ctxt (if VGCT_I387_VALID is set), flags, user_regs and
+ * debugreg[*].
  */
 struct vcpu_guest_context {
 /* FPU registers come first so they can be aligned for FXSAVE/FXRSTOR. */
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

2017-08-31 Thread Ian Jackson

Volodymyr Babchuk writes ("Re: [PATCH v4 03/11] public: xen.h: add definitions 
for UUID handling"):
> Do you have any ideas how to indicate endianess of the fields, then? I 
> can just write it in the comments. But I fear of misuse.

I definitely prefer your approach of providing only an array.  (It
needs to be in a struct for typesafety, as discussed.)  At least that
way the semantics are clear.

No-one is likely to want to access these individual fields.  If they
do so they are doing something very wrong.

Ian.

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

Re: [Xen-devel] [PATCH v4 11/39] altp2m: Move (MAX|INVALID)_ALTP2M to xen/p2m-common.h

Hi Jan,


On 08/31/2017 12:19 PM, Jan Beulich wrote:
 On 31.08.17 at 11:49,  wrote:
>> On 08/31/2017 10:04 AM, Jan Beulich wrote:
>> On 30.08.17 at 20:32,  wrote:
 We move the macros (MAX|INVALID)_ALTP2M out of x86-related code to
 common code, as the following patches will make use of them on ARM.
>>> But both seem not impossible to be require arch-specific values.
>> Right. The general idea at this point is to move as much of altp2m
>> functionality/configuration as possible into a common place. Yet, if you
>> believe that, e.g., the number of altp2m views could/should diverge
>> between both architectures, I will gladly move the defines back into
>> arch-related parts. However, we need to consider that while x86/Intel
>> supports up to 512 entries for EPT pointers as part of the VMCS, we are
>> quite flexible on ARM: we manage the views entirely in software and
>> hence on ARM we can easily keep up with Intel's specification. This
>> allows us to hold parts of the altp2m configuration in a unified place.
>> Or do you believe this is not the right way to go?
> Well, you've basically answered this yourself: Why would you
> want to constrain ARM just because of VMX restrictions? Requiring
> all architectures to surface the same constants (regardless of
> actual values) is all you need to be able to commonize code.

Alright, I will remove the upper constants from common code in v5.

Thanks,
~Sergej

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

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

On 08/31/2017 08:00 AM, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Juergen Gross wrote:
>>> I've applied it on top of tip:x86/apic and fixed up the merge conflicts
>>> mindlessly. Patch below.
>>>
>>> Juergen, can you please check the result?
>> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
>> of the xen specific trap entries in arch/x86/include/asm/traps.h
> I'll try that again later today, unless you beat me to it.
>

https://marc.info/?l=linux-kernel=150296063131595=2 should also be
picked up by the tip tree then since it applies on top of the
adjust_exception_frame patch. I will revert it from Xen tree as well.

-boris

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

Re: [Xen-devel] [RFC PATCH V2 4/4] xl/libacpi: extend lapic_id() to uint32_t

On 31/08/17 06:01, Lan Tianyu wrote:
> From: Chao Gao 
>
> This patch is to extend lapic_id() to support more vcpus.
>
> Signed-off-by: Chao Gao 
> Signed-off-by: Lan Tianyu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [RFC PATCH V2 1/4] xen/hap: Increase hap page pool size for more vcpus support

On 31/08/17 06:01, Lan Tianyu wrote:
> This patch is to increase hap page pool size to support more vcpus in single 
> VM.
>
> Signed-off-by: Lan Tianyu 
> ---
>  xen/arch/x86/mm/hap/hap.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> index cdc77a9..96a7ed0 100644
> --- a/xen/arch/x86/mm/hap/hap.c
> +++ b/xen/arch/x86/mm/hap/hap.c
> @@ -464,6 +464,7 @@ void hap_domain_init(struct domain *d)
>  int hap_enable(struct domain *d, u32 mode)
>  {
>  unsigned int old_pages;
> +unsigned int pages;
>  unsigned int i;
>  int rv = 0;
>  
> @@ -473,7 +474,14 @@ int hap_enable(struct domain *d, u32 mode)
>  if ( old_pages == 0 )
>  {
>  paging_lock(d);
> -rv = hap_set_allocation(d, 256, NULL);
> +
> +/* Increase hap page pool with max vcpu number. */
> +if ( d->max_vcpus > 128 )
> +pages = 256;
> +else
> +pages = 512;
> +
> +rv = hap_set_allocation(d, pages, NULL);

What effect is this intended to have?  hap_enable() is always called
when d->max_vcpus is 0.

d->max_vcpus isn't chosen until a subsequent hypercall.  (This is one of
many unexpected surprised from multi-vcpu support having been hacked on
the side of existing Xen support, rather than being built in to the
createdomain hypercall).

~Andrew

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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr,


On 08/31/2017 02:44 PM, Volodymyr Babchuk wrote:
> Hello Sergej,
>
> On 31.08.17 15:20, Sergej Proskurin wrote:
>> Hi Volodymyr, hi Julien,
>>
>>
>> On 08/24/2017 07:25 PM, Julien Grall wrote:
>>>
>>>
>>> On 21/08/17 21:27, Volodymyr Babchuk wrote:
 This feature indicates that hypervisor is compatible with ARM
 SMC calling convention. Hypervisor will not inject an undefined
 instruction exception if an invalid SMC function were called and
 will not crash a domain if an invlalid HVC functions were called.
>>>
>>> s/invlalid/invalid/
>>>
>>> The last sentence is misleading. Xen will still inject and undefined
>>> instruction for some SMC/HVC. You may want to rework it to make it
>>> clear.
>>>
>>
>> Now that you say that Xen will still inject an undefined instruction
>> exception for some SMCs, I have a to ask for which exactly?
> For ones that are compatible with ARM SMCCC [1]. E.g if you are
> running SMCCC-compatible system and you are calling SMC/HVC with
> immediate value 0, then you are safe.
>

Alright, as far as I understand this is exactly what I do right now. I
inject an SMC that is encoded as 0xD403.

>> I might be off topic here, so please tell me if you believe this is not
>> the right place for this question. In this case I will open an new
>> thread. Right now, I am working with the previous implementation of
>> do_trap_smc that was extended in this patch. Yet, as far as I
>> understand, the behavior should not change, which is why I am asking
>> this quesiton in this thread.
> If you are talking about forwarding SMC exception to VM monitor, then
> yes, that should not change.

Yes, exactly. Sorry, I forgot to mention that I have a modified
xen-access version running in dom0 that registers an SMC monitor and
also increases the PC by 4 (or dependent on the case, simply leaves it
as it is) on every SMC trap.

>
>> Currently, I am working on SMC guest injections and trying to understand
>> the resulting behavior. Every time, right after the execution of an
>> injected SMC instruction, the guest traps into the undefined instruction
>> exception handler in EL1 and I simply don't understand why. As far as I
>> understand, as soon an injected SMC instruction gets executed, it should
>> _transparently_ trap into the hypervisor (assuming MDCR_EL2.TDE is set).
>> As soon as the hypervisor returns (e.g. to PC+4 or to the trapping PC
>> that now contains the original instruction instead of the injected SMC),
>> the guest should simply continue its execution.
> Hm. What do you mean under "SMC instruction injection?".

My code runs in dom0 and "injects" an SMC instruction to predefined
addresses inside the guest as to simulate software breakpoints. By this,
I mean that the code replaces the original guest instruction at a
certain address with an SMC. Think of a debugger that uses software
breakpoints. The idea is to put back the original instruction right
after the SMC gets called, so that the guest can continue with its
execution. You can find more information about that in [0], yet please
consider that I try to trap the SMC directly in Xen instead of TrustZone.

> Current code in hypervisor will always inject undefined instruction
> exception when you  call SMC (unless you installed VM monitor for the
> guest). Also, it will not increase PC. So, if you'll try to remove
> inject_undef_exception() call, you'll get into an infinite loop.
>

I have a registered SMC monitor running in dom0 that does not reinject
the undefined instruction exception in do_trap_smc(). So there is no
indefinite loop at this point. What I see is that as soon as my code in
xen-access (dom0) increments the trapped guest PC by 4 (and also if it
doesn't) the next instruction inside the guest will be inside the undef
instruction handler (I can see that because I have implemented a single
stepping mechanism for AArch64 in Xen that gets activated right after
the guest executes the injected SMC instruction).

>> Now, according to ARM DDI0487B.a D1-1873, the following holds: "If
>> HCR_EL2.TSC or HCR.TSC traps attempted EL1 execution of SMC instructions
>> to EL2, that trap has priority over this disable". So this means that if
>> SMCs are disabled for NS EL1, the guest will trap into the hypervisor on
>> SMC execution. Yet, since SMCs are disabled from NS EL1, the guest will
>> execute an undefined instrcution exception. Which is what I was thinking
>> about is currently happening on my ARMv8 dev board (Lemaker Hikey). On
>> the other hand I believe that it is highly unlikely that the EFI loader
>> explicitly disables SMC's for NS EL1. However, since I don't have access
>> to SCR_EL3.SMD from EL2, I can't tell whether this is the reason for the
>> behavior I am experiencing on my board or not.
> According to ARM ARM, hypervisor should trap SMC even if was disabled
> by EL3. I think, that in your case the problem is in current
> implementation of do_trap_smc()
>

Unfortunately, I don't think that this is

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ea8314e4402f6c385b6e41e4f7803853e64e421b
baseline version:
 ovmf 5202e6c907e5769ac8ecb024b7a07509bdba6181

Last test of basis   112958  2017-08-30 12:17:39 Z1 days
Testing same since   112971  2017-08-31 01:48:04 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Brijesh Singh 
  Laszlo Ersek 

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=ea8314e4402f6c385b6e41e4f7803853e64e421b
+ . ./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 
ea8314e4402f6c385b6e41e4f7803853e64e421b
+ branch=ovmf
+ revision=ea8314e4402f6c385b6e41e4f7803853e64e421b
+ . ./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.9-testing
+ '[' xea8314e4402f6c385b6e41e4f7803853e64e421b = 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 v4 03/11] public: xen.h: add definitions for UUID handling




On 31.08.17 15:53, Jan Beulich wrote:

On 31.08.17 at 14:24,  wrote:

Hi Jan,

On 31.08.17 10:34, Jan Beulich wrote:

On 30.08.17 at 18:20,  wrote:

My first intention was to declare union with all possible
representations, so it would be possible to access the same UUID as an
array of bytes or, for example, as Microsoft GUID. Like this:

typedef union {
   /* UUID represented as a 128-bit object */
   uint8_t obj[16];

   /* Representation according to RFC 4122 */
   struct {
   __be32  time_low;
   __be16  time_mid;
   __be16  time_hi_and_version;
   __u8clock_seq_hi_and_reserved;
   __u8clock_seq_low;
   __u8node[6];
   } rfc4122;

   /* Microsoft/Intel style GUID representation */
   struct {
   __le32  Data1;
   __le16  Data2;
   __le16  Data3;
   __u8Data4[8];
   } guid;

   /* SMCCC compatible format */
   struct {
   __le32 r0;
   __le32 r1;
   __le32 r2;
   __le32 r3;
   } smccc;
} xen_uuid_t;


But looks like we can't use something like __packed or
__attribute__((__packed__)) in the public header. This means that we
can't rely on right overlapping and users of this union should take care
to read and write only to one chosen substructure.


I don't see any use of that attribute in the structure definition
above, nor any need to add one - all fields are suitably aligned
anyway. You can't use __be* and __le* types in the public
headers, though - these will need to be uint*_t.

This is a public header. As I understand it can be used by different
compilers (gcc, icc, msvc, llvm, etc...). C89 have no restrictions to
padding or alignment of fields in structures. No one can guarantee that

sizeof(xen_uuid_t.rfc422) == sizeof(xen_uuid_t.guid) ==
sizeof(xen_uuid_t.smccc)  == 16

On all platforms. Using any compiler. With any compiler options.

This is implementation defined ([1]). Standard says "This should present
no problem unless binary data written by one implementation are read by
another.". But in case of public headers, this structures can be written
by one implementation and read by another.


My reference to C89 was to tell you what language constructs
you're allowed to use. For binary layout, conventions also
matter (like gABI and processor specific ABIs). Without that we
wouldn't be able to write any C header in compatible manner.
What helps us greatly is that we're not needing interfaces for
cross-host communication - the entire public interface assumes
that producer and consumer run on the same physical system
(or, for the parts concerning migration, on similar ones).


So, will it be acceptable to use my approach with that union?

Do you have any ideas how to indicate endianess of the fields, then? I 
can just write it in the comments. But I fear of misuse.



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

[Xen-devel] [PATCH v2 2/4] mm: Change boot_scrub_done definition

Rename it to the more appropriate scrub_debug and define as a macro
for !CONFIG_SCRUB_DEBUG. This will allow us to get rid of some
ifdefs (here and in the subsequent patch).

Signed-off-by: Boris Ostrovsky 
Suggested-by: Jan Beulich 
Reviewed-by: Wei Liu 
---
 xen/common/page_alloc.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 43f5a38..2c7675b 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -171,7 +171,9 @@ static unsigned long __initdata opt_bootscrub_chunk = 
MB(128);
 size_param("bootscrub_chunk", opt_bootscrub_chunk);
 
 #ifdef CONFIG_SCRUB_DEBUG
-static bool __read_mostly boot_scrub_done;
+static bool __read_mostly scrub_debug;
+#else
+#define scrub_debugfalse
 #endif
 
 /*
@@ -725,7 +727,7 @@ static void check_one_page(struct page_info *pg)
 const uint64_t *ptr;
 unsigned int i;
 
-if ( !boot_scrub_done )
+if ( !scrub_debug )
 return;
 
 ptr = map_domain_page(mfn);
@@ -1696,12 +1698,7 @@ static void init_heap_pages(
 nr_pages -= n;
 }
 
-#ifndef CONFIG_SCRUB_DEBUG
-free_heap_pages(pg + i, 0, false);
-#else
-free_heap_pages(pg + i, 0, boot_scrub_done);
-#endif
-   
+free_heap_pages(pg + i, 0, scrub_debug);
 }
 }
 
@@ -1965,7 +1962,7 @@ static void __init scrub_heap_pages(void)
 printk("done.\n");
 
 #ifdef CONFIG_SCRUB_DEBUG
-boot_scrub_done = true;
+scrub_debug = true;
 #endif
 }
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 0/4] Scrubbing updates

First patch fixes a long-standing bug where a low memory monitor is
not initialized if boottime scrubbing is turned off.

The other threee patches are performace and readability optimizations.

I will send the last patch from previous posting (the one that broke the
tree) later. I have a couple of variants and want to test both of them longer 

Boris Ostrovsky (4):
  mm: Initialize lowmem virq when boot-time scrubbing is disabled
  mm: Change boot_scrub_done definition
  mm: Don't poison a page if scrub_debug is off
  mm: Don't request scrubbing until dom0 is running

 xen/arch/arm/setup.c|  3 +--
 xen/arch/x86/setup.c|  3 +--
 xen/common/page_alloc.c | 42 +-
 xen/include/xen/mm.h|  2 +-
 4 files changed, 24 insertions(+), 26 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 1/4] mm: Initialize lowmem virq when boot-time scrubbing is disabled

scrub_heap_pages() does early return if boot-time scrubbing is
disabled, neglecting to initialize lowmem VIRQ.

Because setup_low_mem_virq() doesn't logically belong in
scrub_heap_pages() we put them both into the newly added
heap_init_late().

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
---
CC: Julien Grall 
---
Changes in v2:
* Dropped unnecessary opt_bootscrub test in scrub_heap_pages()
* Restored comment for setup_low_mem_virq().

 xen/arch/arm/setup.c|  3 +--
 xen/arch/x86/setup.c|  3 +--
 xen/common/page_alloc.c | 18 +++---
 xen/include/xen/mm.h|  2 +-
 4 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 3b34855..92f173b 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -861,8 +861,7 @@ void __init start_xen(unsigned long boot_phys_offset,
 if ( construct_dom0(dom0) != 0)
 panic("Could not set up DOM0 guest OS");
 
-/* Scrub RAM that is still free and so may go to an unprivileged domain. */
-scrub_heap_pages();
+heap_init_late();
 
 init_constructors();
 
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index ec96287..bc466e8 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1662,8 +1662,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 cr4_pv32_mask |= X86_CR4_SMAP;
 }
 
-/* Scrub RAM that is still free and so may go to an unprivileged domain. */
-scrub_heap_pages();
+heap_init_late();
 
 init_trace_bufs();
 
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9fa62d2..43f5a38 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1839,7 +1839,7 @@ static int __init find_non_smt(unsigned int node, 
cpumask_t *dest)
  * Scrub all unallocated pages in all heap zones. This function uses all
  * online cpu's to scrub the memory in parallel.
  */
-void __init scrub_heap_pages(void)
+static void __init scrub_heap_pages(void)
 {
 cpumask_t node_cpus, all_worker_cpus;
 unsigned int i, j;
@@ -1849,9 +1849,6 @@ void __init scrub_heap_pages(void)
 int last_distance, best_node;
 int cpus;
 
-if ( !opt_bootscrub )
-return;
-
 cpumask_clear(_worker_cpus);
 /* Scrub block size. */
 chunk_size = opt_bootscrub_chunk >> PAGE_SHIFT;
@@ -1970,12 +1967,19 @@ void __init scrub_heap_pages(void)
 #ifdef CONFIG_SCRUB_DEBUG
 boot_scrub_done = true;
 #endif
+}
 
-/* Now that the heap is initialized, run checks and set bounds
- * for the low mem virq algorithm. */
+void __init heap_init_late(void)
+{
+/*
+ * Now that the heap is initialized set bounds
+ * for the low mem virq algorithm.
+ */
 setup_low_mem_virq();
-}
 
+if ( opt_bootscrub )
+scrub_heap_pages();
+}
 
 
 /*
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index ddc3fb3..c2f5a08 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -199,7 +199,7 @@ int offline_page(unsigned long mfn, int broken, uint32_t 
*status);
 int query_page_offline(unsigned long mfn, uint32_t *status);
 unsigned long total_free_pages(void);
 
-void scrub_heap_pages(void);
+void heap_init_late(void);
 
 int assign_pages(
 struct domain *d,
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 3/4] mm: Don't poison a page if scrub_debug is off

If scrub_debug is off we don't check pages in check_one_page().
Thus there is no reason to ever poison them.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
---
 xen/common/page_alloc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2c7675b..2b8bb95 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -714,6 +714,9 @@ static void poison_one_page(struct page_info *pg)
 mfn_t mfn = _mfn(page_to_mfn(pg));
 uint64_t *ptr;
 
+if ( !scrub_debug )
+return;
+
 ptr = map_domain_page(mfn);
 *ptr = ~SCRUB_PATTERN;
 unmap_domain_page(ptr);
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2 4/4] mm: Don't request scrubbing until dom0 is running

There is no need to scrub pages freed during dom0 construction since
once dom0 is ready the heap will be scrubbed by scrub_heap_pages() anyway,
setting scrub_debug at the end.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Use '||' instead of '|'. Drop '!!'
* Clarified commit message.

 xen/common/page_alloc.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 2b8bb95..dbad1e1 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2248,16 +2248,12 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 
 spin_unlock_recursive(>page_alloc_lock);
 
-#ifndef CONFIG_SCRUB_DEBUG
 /*
  * Normally we expect a domain to clear pages before freeing them,
  * if it cares about the secrecy of their contents. However, after
  * a domain has died we assume responsibility for erasure.
  */
-scrub = !!d->is_dying;
-#else
-scrub = true;
-#endif
+scrub = d->is_dying || scrub_debug;
 }
 else
 {
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling

>>> On 31.08.17 at 14:24,  wrote:
> Hi Jan,
> 
> On 31.08.17 10:34, Jan Beulich wrote:
> On 30.08.17 at 18:20,  wrote:
>>> My first intention was to declare union with all possible
>>> representations, so it would be possible to access the same UUID as an
>>> array of bytes or, for example, as Microsoft GUID. Like this:
>>>
>>> typedef union {
>>>   /* UUID represented as a 128-bit object */
>>>   uint8_t obj[16];
>>>
>>>   /* Representation according to RFC 4122 */
>>>   struct {
>>>   __be32  time_low;
>>>   __be16  time_mid;
>>>   __be16  time_hi_and_version;
>>>   __u8clock_seq_hi_and_reserved;
>>>   __u8clock_seq_low;
>>>   __u8node[6];
>>>   } rfc4122;
>>>
>>>   /* Microsoft/Intel style GUID representation */
>>>   struct {
>>>   __le32  Data1;
>>>   __le16  Data2;
>>>   __le16  Data3;
>>>   __u8Data4[8];
>>>   } guid;
>>>
>>>   /* SMCCC compatible format */
>>>   struct {
>>>   __le32 r0;
>>>   __le32 r1;
>>>   __le32 r2;
>>>   __le32 r3;
>>>   } smccc;
>>> } xen_uuid_t;
>>>
>>>
>>> But looks like we can't use something like __packed or
>>> __attribute__((__packed__)) in the public header. This means that we
>>> can't rely on right overlapping and users of this union should take care
>>> to read and write only to one chosen substructure.
>> 
>> I don't see any use of that attribute in the structure definition
>> above, nor any need to add one - all fields are suitably aligned
>> anyway. You can't use __be* and __le* types in the public
>> headers, though - these will need to be uint*_t.
> This is a public header. As I understand it can be used by different 
> compilers (gcc, icc, msvc, llvm, etc...). C89 have no restrictions to 
> padding or alignment of fields in structures. No one can guarantee that
> 
> sizeof(xen_uuid_t.rfc422) == sizeof(xen_uuid_t.guid) == 
> sizeof(xen_uuid_t.smccc)  == 16
> 
> On all platforms. Using any compiler. With any compiler options.
> 
> This is implementation defined ([1]). Standard says "This should present 
> no problem unless binary data written by one implementation are read by 
> another.". But in case of public headers, this structures can be written 
> by one implementation and read by another.

My reference to C89 was to tell you what language constructs
you're allowed to use. For binary layout, conventions also
matter (like gABI and processor specific ABIs). Without that we
wouldn't be able to write any C header in compatible manner.
What helps us greatly is that we're not needing interfaces for
cross-host communication - the entire public interface assumes
that producer and consumer run on the same physical system
(or, for the parts concerning migration, on similar ones).

Jan



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

[Xen-devel] [xen-unstable-smoke test] 112982: regressions - trouble: broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 112956

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112956
 build-arm64-pvops 3 capture-logsbroken like 112956
 build-arm64   2 hosts-allocate  broken like 112956
 build-arm64   3 capture-logsbroken like 112956
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  38ac6fa969a43ca993e610deae8976f9f2877fbb
baseline version:
 xen  dab6a84aadab11f31332030a1e9f0b9282d76156

Last test of basis   112956  2017-08-30 09:56:56 Z1 days
Failing since112957  2017-08-30 12:02:17 Z1 days   12 attempts
Testing same since   112980  2017-08-31 09:02:13 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsbroken  
 test-armhf-armhf-xl  fail
 test-arm64-arm64-xl-xsm  broken  
 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

broken-step build-arm64-pvops hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 hosts-allocate
broken-step build-arm64 capture-logs

Not pushing.

(No revision log; it would be 385 lines long.)

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

[Xen-devel] [linux-linus test] 112968: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  4 host-install(4)   broken REGR. vs. 112948
 test-amd64-i386-xl-qemuu-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs. 
112948
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112948

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112948
 build-arm64-pvops 3 capture-logsbroken like 112948
 build-arm64-xsm   2 hosts-allocate  broken like 112948
 build-arm64-xsm   3 capture-logsbroken like 112948
 build-arm64   2 hosts-allocate  broken like 112948
 build-arm64   3 capture-logsbroken like 112948
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112948
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112948
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112948
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112948
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112948
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112948
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux42ff72cf27027fa28dd79acabe01d9196f1480a7
baseline version:
 linux36fde05f3fb51edea879636db590d70e11f16c82

Last test of basis   112948  2017-08-29 23:51:46 Z1 days
Testing same since   112968  2017-08-30 22:50:04 Z0 days1 attempts


People who touched revisions under test:

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

>>> On 31.08.17 at 12:27,  wrote:
> vMCE: Is MCE an x86-only thing, or could this conceivably by extended
> to ARM?

I think this can't be reasonably extended beyond x86 (and,
considering their similar origin, ia64).

> +## Tooling
> +
> +### gdbsx
> +
> +Status, x86: Supported
> +
> +Debugger to debug ELF guests
> +
> +### vPMU
> +
> +Status, x86: Supported, Not security supported
> +
> +Virtual Performance Management Unit for HVM guests

Why is this under Tooling?

> +## Scalability
> +
> +### 1GB/2MB super page support
> +
> +Status: Supported

Is this a host, guest, CPU, and/or IOMMU capability? Do the same
superpage sizes apply to 16k/64k-page-size ARM? If host, here as
well as ...

> +### Fair locks (ticket-locks)
> +
> +Status: Supported

... here I wonder whether these are legitimately on this list in the
first place. Admins have no way to avoid their use.

> +### Live Patching
> +
> +Status: Supported, x86 only
> +
> +Compile time disabled

Bu we're settled to change that, aren't we? It was even meant to be
so in 4.9, but then didn't make it.

> +### Virtual Machine Introspection
> +
> +Status: Supported, x86 only

Including security support?

> +### x86/PCI Passthrough PV
> +
> +Status: Supported, Not security supported
> +
> +PV passthrough cannot be done safely.
> +
> +[XXX Not even with an IOMMU?]

It depends who you ask. I think it would be okay to use ...

> +### x86/PCI Passthrough HVM
> +
> +Status: Supported, with caveats
> +
> +Many hardware device and motherboard combinations are not possible to use 
> safely.
> +The XenProject will support bugs in PCI passthrough for Xen,
> +but the user is responsible to ensure that the hardware combination they use
> +is sufficiently secure for their needs,
> +and should assume that any combination is insecure
> +unless they have reason to believe otherwise.

... this for PV+IOMMU too.

> +### x86/Advanced Vector eXtension
> +
> +Status: Supported

How fine-grained do we want this document to be? If this one is a
valid entry, then many other CPUID bits will need to have entries
too.

Having reached the end of the list I further wonder whether we
shouldn't add information on various hypercalls and their subops.
I.e. a full walk through include/public/ may be needed to see
what additional entries may be necessary or desirable.

> +# Format and definitions
> +
> +This file contains prose, and machine-readable fragments.
> +The data in a machine-readable fragment relate to
> +the section and subection in which it is fine.

"subsection" and s/fine/found/ ?

> +## Definition of Status labels
> +
> +Each Status value corresponds to levels of security support,
> +testing, stability, etc., as follows:
> +
> +### Experimental
> +
> +Functional completeness: No
> +Functional stability: Here be dragons
> +Interface stability: Not stable
> +Security supported: No
> +
> +### Tech Preview

I think most if not all entries using this say just "Preview" - I think
the terms would better fully match.

Jan

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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hello Sergej,

On 31.08.17 15:20, Sergej Proskurin wrote:

Hi Volodymyr, hi Julien,

On 08/24/2017 07:25 PM, Julien Grall wrote:

On 21/08/17 21:27, Volodymyr Babchuk wrote:

This feature indicates that hypervisor is compatible with ARM
SMC calling convention. Hypervisor will not inject an undefined
instruction exception if an invalid SMC function were called and
will not crash a domain if an invlalid HVC functions were called.

s/invlalid/invalid/

The last sentence is misleading. Xen will still inject and undefined
instruction for some SMC/HVC. You may want to rework it to make it clear.

Now that you say that Xen will still inject an undefined instruction
exception for some SMCs, I have a to ask for which exactly?
For ones that are compatible with ARM SMCCC [1]. E.g if you are running
SMCCC-compatible system and you are calling SMC/HVC with immediate value
0, then you are safe.

I might be off topic here, so please tell me if you believe this is not
the right place for this question. In this case I will open an new
thread. Right now, I am working with the previous implementation of
do_trap_smc that was extended in this patch. Yet, as far as I
understand, the behavior should not change, which is why I am asking
this quesiton in this thread.
If you are talking about forwarding SMC exception to VM monitor, then
yes, that should not change.

Currently, I am working on SMC guest injections and trying to understand
the resulting behavior. Every time, right after the execution of an
injected SMC instruction, the guest traps into the undefined instruction
exception handler in EL1 and I simply don't understand why. As far as I
understand, as soon an injected SMC instruction gets executed, it should
_transparently_ trap into the hypervisor (assuming MDCR_EL2.TDE is set).
As soon as the hypervisor returns (e.g. to PC+4 or to the trapping PC
that now contains the original instruction instead of the injected SMC),
the guest should simply continue its execution.

Hm. What do you mean under "SMC instruction injection?".
Current code in hypervisor will always inject undefined instruction
exception when you call SMC (unless you installed VM monitor for the
guest). Also, it will not increase PC. So, if you'll try to remove
inject_undef_exception() call, you'll get into an infinite loop.

Now, according to ARM DDI0487B.a D1-1873, the following holds: "If
HCR_EL2.TSC or HCR.TSC traps attempted EL1 execution of SMC instructions
to EL2, that trap has priority over this disable". So this means that if
SMCs are disabled for NS EL1, the guest will trap into the hypervisor on
SMC execution. Yet, since SMCs are disabled from NS EL1, the guest will
execute an undefined instrcution exception. Which is what I was thinking
about is currently happening on my ARMv8 dev board (Lemaker Hikey). On
the other hand I believe that it is highly unlikely that the EFI loader
explicitly disables SMC's for NS EL1. However, since I don't have access
to SCR_EL3.SMD from EL2, I can't tell whether this is the reason for the
behavior I am experiencing on my board or not.
According to ARM ARM, hypervisor should trap SMC even if was disabled by
EL3. I think, that in your case the problem is in current implementation
of do_trap_smc()

It would be of great help if you would provide me with some more clarity
on my case. I am sure that I have missed something that simply needs
clarification. Thank you very much in advance.
I don't quite understood, what you are trying to achieve. But I think
that pair of printk()s in do_trap_smc() will reveal much.

[1]
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

>>> On 31.08.17 at 13:25,  wrote:
> On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
>> +## Limits/Guest
>> +
>> +### Virtual CPUs
>> +
>> +Limit, x86 PV: 512
>> +Limit, x86 HVM: 128
> 
> There has already been some discussion about the HVM vCPU limit due to
> other topics, is Xen really compromised on providing security support
> for this case?
> 
> I would very much like to have a host in osstest capable of creating
> such a guest, plus maybe some XTF tests to stress it.

The problem is that it working well depends on the workload you put
inside the guest. Simply booting such a guest is quite likely going to
be fine (I've tried it a long while ago without seeing any issues).

Jan


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

Re: [Xen-devel] [PATCH v2 1/2] x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt

On 31/08/17 12:22, Wei Liu wrote:
> Rewrite the code so that it has the same structure as
> mmio_ro_emualte_ctxt. x86_emulate_ctxt now points to ptwr_emulate_ctxt
> via its data pointer.
>
> This patch will help unify mmio_ro and ptwr code paths later.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

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

2017-08-31 Thread Joe Perches

On Thu, 2017-08-31 at 11:16 +0200, Ingo Molnar wrote:
> * Thomas Gleixner  wrote:
> Low prio nitpicking, could we please write such table based initializers in a 
> vertically organized, tabular fashion:
> 
> > +   { debug,xen_xendebug,   
> > true },
> > +   { int3, xen_xenint3,
> > true },
> > +   { double_fault, xen_double_fault,   
> > true },
> > +#ifdef CONFIG_X86_MCE
> > +   { machine_check,xen_machine_check,  
> > true },
> > +#endif
> > +   { nmi,  xen_nmi,
> > true },
> > +   { overflow, xen_overflow,   
> > false },
> > +#ifdef CONFIG_IA32_EMULATION
> > +   { entry_INT80_compat,   xen_entry_INT80_compat, 
> > false },
> > +#endif
> > +   { page_fault,   xen_page_fault, 
> > false },
> > +   { divide_error, xen_divide_error,   
> > false },
> > +   { bounds,   xen_bounds, 
> > false },
> > +   { invalid_op,   xen_invalid_op, 
> > false },
> > +   { device_not_available, xen_device_not_available,   
> > false },
> > +   { coprocessor_segment_overrun,  xen_coprocessor_segment_overrun,
> > false },
> > +   { invalid_TSS,  xen_invalid_TSS,
> > false },
> > +   { segment_not_present,  xen_segment_not_present,
> > false },
> > +   { stack_segment,xen_stack_segment,  
> > false },
> > +   { general_protection,   xen_general_protection, 
> > false },
> > +   { spurious_interrupt_bug,   xen_spurious_interrupt_bug, 
> > false },
> > +   { coprocessor_error,xen_coprocessor_error,  
> > false },
> > +   { alignment_check,  xen_alignment_check,
> > false },
> > +   { simd_coprocessor_error,   xen_simd_coprocessor_error, 
> > false },
> > +#ifdef CONFIG_TRACING
> > +   { trace_page_fault, xen_trace_page_fault,   
> > false },
> > +#endif
> ,,
> ... as to me such a table is 100 times more readable - YMMV.

Yeah, kinda.

It's a lot of whitespace and eyeball left/right scanning.
And these tables require whitespace updating if a longer
name is ever used.

Given the near 1:1 mapping of  to xen_
perhaps adding a macro would be nice.

#define xen_trap(trap, ist_ok) \
{ trap, xen_##trap, ist_ok }

{ debug,xen_xendebug,   true },
{ int3, xen_xenint3,true },
#ifdef CONFIG_X86_MCE
xen_trap(machine_check, true),
#endif
xen_trap(double_fault, true),
xen_trap(nmi, true),
xen_trap(overflow, false),
...

ymmv. 


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

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

On 31/08/17 13:03, Jan Beulich wrote:
 On 31.08.17 at 13:45,  wrote:
>> There is only one function gate_op_read that needs to be modified.
> I'm fine with it just being read() here, but I can see this being possibly
> controversial. Please double check that Andrew isn't entirely opposed
> to it. An alternative suggestion would then be read_mem().

I'm not opposed generally, but simply 'read' has a chance of angering
Coverity, because it has inbuilt models for most functions specified by
core standards like POSIX.

read_mem() would be better.

~Andrew

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

Re: [Xen-devel] [PATCH v4 03/11] public: xen.h: add definitions for UUID handling


Hi Jan,

On 31.08.17 10:34, Jan Beulich wrote:

On 30.08.17 at 18:20,  wrote:

My first intention was to declare union with all possible
representations, so it would be possible to access the same UUID as an
array of bytes or, for example, as Microsoft GUID. Like this:

typedef union {
  /* UUID represented as a 128-bit object */
  uint8_t obj[16];

  /* Representation according to RFC 4122 */
  struct {
  __be32  time_low;
  __be16  time_mid;
  __be16  time_hi_and_version;
  __u8clock_seq_hi_and_reserved;
  __u8clock_seq_low;
  __u8node[6];
  } rfc4122;

  /* Microsoft/Intel style GUID representation */
  struct {
  __le32  Data1;
  __le16  Data2;
  __le16  Data3;
  __u8Data4[8];
  } guid;

  /* SMCCC compatible format */
  struct {
  __le32 r0;
  __le32 r1;
  __le32 r2;
  __le32 r3;
  } smccc;
} xen_uuid_t;


But looks like we can't use something like __packed or
__attribute__((__packed__)) in the public header. This means that we
can't rely on right overlapping and users of this union should take care
to read and write only to one chosen substructure.


I don't see any use of that attribute in the structure definition
above, nor any need to add one - all fields are suitably aligned
anyway. You can't use __be* and __le* types in the public
headers, though - these will need to be uint*_t.
This is a public header. As I understand it can be used by different 
compilers (gcc, icc, msvc, llvm, etc...). C89 have no restrictions to 
padding or alignment of fields in structures. No one can guarantee that


sizeof(xen_uuid_t.rfc422) == sizeof(xen_uuid_t.guid) == 
sizeof(xen_uuid_t.smccc)  == 16


On all platforms. Using any compiler. With any compiler options.

This is implementation defined ([1]). Standard says "This should present 
no problem unless binary data written by one implementation are read by 
another.". But in case of public headers, this structures can be written 
by one implementation and read by another.



BTW, I'm very interested how it can be guaranteed that structures
defined in xen.h will have the same size and alignment on both sides of
communication channel, taking into account, then we rely only on C89
standard.


I don't understand this comment.
See my reply above. There absolutely no guarantees, that MSVC compiler 
will not add extra padding somewhere. This will impair interoperability.
I think, this is why (amongst other reasons) WinAPI structures has 
dwSize as the first field. And this is why _IO* macros in Linux kernel 
use sizeof() to create ioctl number.

But, as I can see, XEN code checks only magic or version.

[1] http://port70.net/~nsz/c/c89/c89-draft.html#A.6.3.8

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

Re: [Xen-devel] [PATCH v4 10/11] public: add XENFEAT_ARM_SMCCC_supported feature

Hi Volodymyr, hi Julien,

On 08/24/2017 07:25 PM, Julien Grall wrote:
>
>
> On 21/08/17 21:27, Volodymyr Babchuk wrote:
>> This feature indicates that hypervisor is compatible with ARM
>> SMC calling convention. Hypervisor will not inject an undefined
>> instruction exception if an invalid SMC function were called and
>> will not crash a domain if an invlalid HVC functions were called.
>
> s/invlalid/invalid/
>
> The last sentence is misleading. Xen will still inject and undefined
> instruction for some SMC/HVC. You may want to rework it to make it clear.
>

Now that you say that Xen will still inject an undefined instruction
exception for some SMCs, I have a to ask for which exactly?
I might be off topic here, so please tell me if you believe this is not
the right place for this question. In this case I will open an new
thread. Right now, I am working with the previous implementation of
do_trap_smc that was extended in this patch. Yet, as far as I
understand, the behavior should not change, which is why I am asking
this quesiton in this thread.

Currently, I am working on SMC guest injections and trying to understand
the resulting behavior. Every time, right after the execution of an
injected SMC instruction, the guest traps into the undefined instruction
exception handler in EL1 and I simply don't understand why. As far as I
understand, as soon an injected SMC instruction gets executed, it should
_transparently_ trap into the hypervisor (assuming MDCR_EL2.TDE is set).
As soon as the hypervisor returns (e.g. to PC+4 or to the trapping PC
that now contains the original instruction instead of the injected SMC),
the guest should simply continue its execution.

Now, according to ARM DDI0487B.a D1-1873, the following holds: "If
HCR_EL2.TSC or HCR.TSC traps attempted EL1 execution of SMC instructions
to EL2, that trap has priority over this disable". So this means that if
SMCs are disabled for NS EL1, the guest will trap into the hypervisor on
SMC execution. Yet, since SMCs are disabled from NS EL1, the guest will
execute an undefined instrcution exception. Which is what I was thinking
about is currently happening on my ARMv8 dev board (Lemaker Hikey). On
the other hand I believe that it is highly unlikely that the EFI loader
explicitly disables SMC's for NS EL1. However, since I don't have access
to SCR_EL3.SMD from EL2, I can't tell whether this is the reason for the
behavior I am experiencing on my board or not.

It would be of great help if you would provide me with some more clarity
on my case. I am sure that I have missed something that simply needs
clarification. Thank you very much in advance.

Thanks,
~Sergej

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

Re: [Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

>>> On 31.08.17 at 13:45,  wrote:
> There is only one function gate_op_read that needs to be modified.

I'm fine with it just being read() here, but I can see this being possibly
controversial. Please double check that Andrew isn't entirely opposed
to it. An alternative suggestion would then be read_mem().

> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 

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

Re: [Xen-devel] [PATCH 1/2] x86/pv: drop priv_op prefix in emul-priv-op.c

>>> On 31.08.17 at 13:45,  wrote:
> Drop the prefix because they live in their own file now. One exception
> is wbinvd handler because drpooing the prefix will clash with the
> actual wbinvd function.

How about _wbinvd() (single underscores as prefix are okay for
static functions) or do_wbinvd()? With either of these ...

> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 

... and thanks for doing this!

Jan

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

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

2017-08-31 Thread Thomas Gleixner

On Thu, 31 Aug 2017, Juergen Gross wrote:
> > I've applied it on top of tip:x86/apic and fixed up the merge conflicts
> > mindlessly. Patch below.
> > 
> > Juergen, can you please check the result?
> 
> You missed the updates to arch/x86/xen/xen-asm_64.S and the declarations
> of the xen specific trap entries in arch/x86/include/asm/traps.h

I'll try that again later today, unless you beat me to it.

Thanks,

tglx

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

Re: [Xen-devel] ARM64:Porting xen to new hardware

2017-08-31 Thread Oleksandr Tyshchenko

On Thu, Aug 31, 2017 at 2:13 PM, bharat gohil  wrote:
> Hello Oleksandr,
Hi Bharat

>
> I had removed A72 cluster and tried to boot only two A35 but I got same
> error.
>
> Is anything added or missing in A35 compare to A53?
Unfortunately, I don't know.

BTW, did you check your GIC settings in the device-tree?

>
> Regards,
> Bharat
>
> On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil  wrote:
>>
>> Hello Oleksandr,
>> Thank you very much for your input.
>>
>> Yes. agree. I will check by removing A72 core from DT.
>>
>> Thanks,
>> Bharat
>>
>> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko
>>  wrote:
>>>
>>> Hi,
>>>
>>> Not sure that I am a competent person, just my assumptions.
>>>
>>> CCed ARM guys.
>>>
>>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil  wrote:
>>> > Hello All
>>> >
>>> > I am trying to run Xen on new hardware which has two A35 and one A72
>>> > core.
>>> > Xen booted intially but it hangs at
>>> > smp_call_function(setup_virt_paging_one,
>>> > (void *)val, 1) function call.
>>>
>>> It might be a consequence of that CPU cores are different. And they
>>> might have different set of features, or even settings.
>>> And these features/settings the boot CPU has don't compatible with
>>> other (non-boot) CPUs.
>>> Can you try not to bringup A72 core (remove it from DT or another
>>> way), leave only two A35 and see what will happen.
>>>
>>> > Find following log of Xen booting,same set of features.
>>> >
>>> > - UART enabled -
>>> > - CPU  booting -
>>> > - Current EL 0008 -
>>> > - Xen starting at EL2 -
>>> > - Zero BSS -
>>> > - Setting up control registers -
>>> > - Turning on paging -
>>> > - Ready -
>>> > (XEN) Checking for initrd in /chosen
>>> > (XEN) RAM: 4000 - bfff
>>> > (XEN)
>>> > (XEN) MODULE[0]: 4400 - 4400fd5a Device Tree
>>> > (XEN)
>>> > (XEN) Command line: 
>>> Why? Does your device-tree have bootargs?
>>>
>>> > (XEN) Placing Xen at 0xbfe0-0xc000
>>> > (XEN) Update BOOTMOD_XEN from 4008-40194e01 =>
>>> > bfe01
>>> > (XEN) Domain heap initialised
>>> > (XEN) Booting using Device Tree
>>> > (XEN) Platform: Generic System
>>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>>> > (XEN) Looking for dtuart at "serial0", options ""
>>> >  __  ___  __  ___ __ _
>>> >  \ \/ /___ _ __   | || |  / |/ _ \_   _ _ __  ___| |_ __ _| |__ | |
>>> > ___
>>> >   \  // _ \ '_ \  | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \|
>>> > |/ _ \
>>> >   /  \  __/ | | | |__   _|| | |_| |__| |_| | | | \__ \ || (_| | |_) | |
>>> > __/
>>> >  /_/\_\___|_| |_||_|(_)_|\___/\__,_|_|
>>> > |_|___/\__\__,_|_.__/|_|\___|
>>> >
>>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>>> > (Ubuntu/Linaro7
>>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100
>>> > git:9053a74-dirty
>>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev
>>> > 0x1
>>> > (XEN) 64-bit Execution:
>>> > (XEN)   Processor Features:  
>>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>>> > (XEN)   Debug Features: 10305106 
>>> > (XEN)   Auxiliary Features:  
>>> > (XEN)   Memory Model Features: 00101122 
>>> > (XEN)   ISA Features:  00011120 
>>> > (XEN) 32-bit Execution:
>>> > (XEN)   Processor Features: 0131:00011011
>>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>>> > (XEN) Extensions: GenericTimer Security
>>> > (XEN)   Debug Features: 03010066
>>> > (XEN)   Auxiliary Features: 
>>> > (XEN)   Memory Model Features: 10201105 4000 0126 02102211
>>> > (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142
>>> > 00011121
>>> > (XEN) Using PSCI-1.0 for SMP bringup
>>> > (XEN) SMP: Allowing 3 CPUs
>>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected
>>> > 0x2000
>>> Sounds like GIC settings are not completely correct.
>>> Wrong GIC settings might lead to that IPIs won't work as expected. And
>>> boot CPU will
>>> get stuck waiting for another CPU.
>>> Just double check.
>>>
>>> > (XEN) GICv2 initialization:
>>> > (XEN) gic_dist_addr=1051
>>> > (XEN) gic_cpu_addr=1052
>>> > (XEN) gic_hyp_addr=1054
>>> > (XEN) gic_vcpu_addr=1056
>>> > (XEN) gic_maintenance_irq=25
>>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>>> > (XEN) Allocated console ring of 32 KiB.
>>> > (XEN) Bringing up CPU1
>>> > - CPU 0001 booting -
>>> > -

[Xen-devel] [PATCH 2/2] x86/pv: drop gate_op prefix in emul-gate-op.c

There is only one function gate_op_read that needs to be modified.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/emul-gate-op.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/xen/arch/x86/pv/emul-gate-op.c b/xen/arch/x86/pv/emul-gate-op.c
index 0a7381a094..002fb782f2 100644
--- a/xen/arch/x86/pv/emul-gate-op.c
+++ b/xen/arch/x86/pv/emul-gate-op.c
@@ -117,12 +117,8 @@ struct gate_op_ctxt {
 bool insn_fetch;
 };
 
-static int gate_op_read(
-enum x86_segment seg,
-unsigned long offset,
-void *p_data,
-unsigned int bytes,
-struct x86_emulate_ctxt *ctxt)
+static int read(enum x86_segment seg, unsigned long offset, void *p_data,
+unsigned int bytes, struct x86_emulate_ctxt *ctxt)
 {
 const struct gate_op_ctxt *goc =
 container_of(ctxt, struct gate_op_ctxt, ctxt);
@@ -230,7 +226,7 @@ void pv_emulate_gate_op(struct cpu_user_regs *regs)
 
 ctxt.ctxt.addr_size = ar & _SEGMENT_DB ? 32 : 16;
 /* Leave zero in ctxt.ctxt.sp_size, as it's not needed for decoding. */
-state = x86_decode_insn(, gate_op_read);
+state = x86_decode_insn(, read);
 ctxt.insn_fetch = false;
 if ( IS_ERR_OR_NULL(state) )
 {
@@ -265,9 +261,8 @@ void pv_emulate_gate_op(struct cpu_user_regs *regs)
 case 3:
 ++jump;
 base = x86_insn_operand_ea(state, );
-rc = gate_op_read(seg,
-  base + (x86_insn_opsize(state) >> 3),
-  _sel, sizeof(opnd_sel), );
+rc = read(seg, base + (x86_insn_opsize(state) >> 3),
+  _sel, sizeof(opnd_sel), );
 break;
 }
 break;
-- 
2.11.0


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

[Xen-devel] [PATCH 0/2] x86/pv: drop unnecessary prefixes

Wei Liu (2):
  x86/pv: drop priv_op prefix in emul-priv-op.c
  x86/pv: drop gate_op prefix in emul-gate-op.c

 xen/arch/x86/pv/emul-gate-op.c | 15 +++
 xen/arch/x86/pv/emul-priv-op.c | 99 +-
 2 files changed, 55 insertions(+), 59 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 1/2] x86/pv: drop priv_op prefix in emul-priv-op.c

Drop the prefix because they live in their own file now. One exception
is wbinvd handler because drpooing the prefix will clash with the
actual wbinvd function.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/pv/emul-priv-op.c | 99 +-
 1 file changed, 50 insertions(+), 49 deletions(-)

diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
index 54a63c27f8..1f3e24b169 100644
--- a/xen/arch/x86/pv/emul-priv-op.c
+++ b/xen/arch/x86/pv/emul-priv-op.c
@@ -316,8 +316,8 @@ static unsigned int check_guest_io_breakpoint(struct vcpu 
*v,
 return match;
 }
 
-static int priv_op_read_io(unsigned int port, unsigned int bytes,
-   unsigned long *val, struct x86_emulate_ctxt *ctxt)
+static int read_io(unsigned int port, unsigned int bytes,
+   unsigned long *val, struct x86_emulate_ctxt *ctxt)
 {
 struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
 struct vcpu *curr = current;
@@ -415,8 +415,8 @@ void guest_io_write(unsigned int port, unsigned int bytes, 
uint32_t data,
 }
 }
 
-static int priv_op_write_io(unsigned int port, unsigned int bytes,
-unsigned long val, struct x86_emulate_ctxt *ctxt)
+static int write_io(unsigned int port, unsigned int bytes,
+unsigned long val, struct x86_emulate_ctxt *ctxt)
 {
 struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
 struct vcpu *curr = current;
@@ -447,9 +447,9 @@ static int priv_op_write_io(unsigned int port, unsigned int 
bytes,
 return X86EMUL_OKAY;
 }
 
-static int priv_op_read_segment(enum x86_segment seg,
-struct segment_register *reg,
-struct x86_emulate_ctxt *ctxt)
+static int read_segment(enum x86_segment seg,
+struct segment_register *reg,
+struct x86_emulate_ctxt *ctxt)
 {
 /* Check if this is an attempt to access the I/O bitmap. */
 if ( seg == x86_seg_tr )
@@ -561,10 +561,10 @@ static int pv_emul_virt_to_linear(unsigned long base, 
unsigned long offset,
 return rc;
 }
 
-static int priv_op_rep_ins(uint16_t port,
-   enum x86_segment seg, unsigned long offset,
-   unsigned int bytes_per_rep, unsigned long *reps,
-   struct x86_emulate_ctxt *ctxt)
+static int rep_ins(uint16_t port,
+   enum x86_segment seg, unsigned long offset,
+   unsigned int bytes_per_rep, unsigned long *reps,
+   struct x86_emulate_ctxt *ctxt)
 {
 struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
 struct vcpu *curr = current;
@@ -580,7 +580,7 @@ static int priv_op_rep_ins(uint16_t port,
 if ( !guest_io_okay(port, bytes_per_rep, curr, ctxt->regs) )
 return X86EMUL_UNHANDLEABLE;
 
-rc = priv_op_read_segment(x86_seg_es, , ctxt);
+rc = read_segment(x86_seg_es, , ctxt);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -628,10 +628,10 @@ static int priv_op_rep_ins(uint16_t port,
 return X86EMUL_OKAY;
 }
 
-static int priv_op_rep_outs(enum x86_segment seg, unsigned long offset,
-uint16_t port,
-unsigned int bytes_per_rep, unsigned long *reps,
-struct x86_emulate_ctxt *ctxt)
+static int rep_outs(enum x86_segment seg, unsigned long offset,
+uint16_t port,
+unsigned int bytes_per_rep, unsigned long *reps,
+struct x86_emulate_ctxt *ctxt)
 {
 struct priv_op_ctxt *poc = container_of(ctxt, struct priv_op_ctxt, ctxt);
 struct vcpu *curr = current;
@@ -645,7 +645,7 @@ static int priv_op_rep_outs(enum x86_segment seg, unsigned 
long offset,
 if ( !guest_io_okay(port, bytes_per_rep, curr, ctxt->regs) )
 return X86EMUL_UNHANDLEABLE;
 
-rc = priv_op_read_segment(seg, , ctxt);
+rc = read_segment(seg, , ctxt);
 if ( rc != X86EMUL_OKAY )
 return rc;
 
@@ -696,8 +696,8 @@ static int priv_op_rep_outs(enum x86_segment seg, unsigned 
long offset,
 return X86EMUL_OKAY;
 }
 
-static int priv_op_read_cr(unsigned int reg, unsigned long *val,
-   struct x86_emulate_ctxt *ctxt)
+static int read_cr(unsigned int reg, unsigned long *val,
+   struct x86_emulate_ctxt *ctxt)
 {
 const struct vcpu *curr = current;
 
@@ -740,8 +740,8 @@ static int priv_op_read_cr(unsigned int reg, unsigned long 
*val,
 return X86EMUL_UNHANDLEABLE;
 }
 
-static int priv_op_write_cr(unsigned int reg, unsigned long val,
-struct x86_emulate_ctxt *ctxt)
+static int write_cr(unsigned int reg, unsigned long val,
+struct x86_emulate_ctxt *ctxt)
 {
 struct vcpu *curr = current;
 
@@ -797,8 +797,8 @@ static int priv_op_write_cr(unsigned int

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

2017-08-31 Thread Roger Pau Monne

On Thu, Aug 31, 2017 at 11:27:19AM +0100, George Dunlap wrote:
> Add a machine-readable file to describe what features are in what
> state of being 'supported', as well as information about how long this
> release will be supported, and so on.
> 
> The document should be formatted using "semantic newlines" [1], to make
> changes easier.
> 
> Signed-off-by: Ian Jackson 
> Signed-off-by: George Dunlap 
> 
> [1] http://rhodesmill.org/brandon/2012/one-sentence-per-line/
> ---
> 
> Definitely meant to be a draft; if you disagree with the status of one
> of these features, now is the time to suggest something else.
> 
> I've made a number of stylistic decisions that people may have opinions on:
> 
> * When dealing with multiple implementations of the same feature (for
>   instance, x86/PV x86/HVM and ARM guest types, or Linux / FreeBSD /
>   QEMU backends), I decided in general to combine the feature itself
>   into a single stanza, and break the 'Status' line up by specifying
>   the implementation.
> 
>   For example, if a feature is supported on x86 but tech preview on
>   ARM, there would be two status lines, thus:
> 
> Status, x86: Supported
> Status, ARM: Tech preview
> 
>   If a feature is not implemented for a specific implementation, it
>   will simply not be listed:
> 
> Status, x86: Supported
> 
> * I've added common 'Support variations' to the bottom of the document
> 
> Thinking on support status of specific features:
> 
> gdbsx security support: Someone may want to debug an untrusted guest,
> so I think we should say 'yes' here.
> 
> xentrace: Users may want to trace guests in production environments,
> so I think we should say 'yes'.
> 
> gcov: No good reason to run a gcov hypervisor in a production
> environment.  May be ways for a rogue guest to DoS.
> 
> memory paging: Changed to experimental -- are we testing it at all?
> 
> alternative p2m: No security support until better testing in place
> 
> ARINC653 scheduler: Not sure we have the expertise to properly fix
> bugs.  Can switch to 'supported' if we get commitment from
> maintainers.
> 
> vMCE: Is MCE an x86-only thing, or could this conceivably by extended
> to ARM?
> 
> PVHv2: Not sure why we'd downgrade guest support to 'experimental'.
> 
> ARM/Virtual RAM: Not sure what the note 'Limited by supported host
> memory' was supposed to mean
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Andrew Cooper 
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Dario Faggioli 
> CC: Tamas K Lengyel 
> CC: Roger Pau Monne 
> CC: Stefano Stabellini 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: Konrad Wilk 
> ---
>  SUPPORT.md | 770 
> +
>  1 file changed, 770 insertions(+)
>  create mode 100644 SUPPORT.md
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> new file mode 100644
> index 00..283cbeb725
> --- /dev/null
> +++ b/SUPPORT.md
> @@ -0,0 +1,770 @@
> +# Support statement for this release
> +
> +This document describes the support status and in particular the
> +security support status of the Xen branch within which you find it.
> +
> +See the bottom of the file for the definitions of the support status
> +levels etc.
> +
> +# Release Support
> +
> +Xen-Version: 4.10-unstable
> +Initial-Release: n/a
> +Supported-Until: TBD
> +Security-Support-Until: Unreleased - not yet security-supported
> +
> +# Feature Support
> +
> +## Host Architecture
> +
> +### x86-64
> +
> +Status: Supported
> +
> +### ARM v7 + Virtualization Extensions
> +
> +Status: Supported
> +
> +### ARM v8
> +
> +Status: Supported
> +
> +## Guest Type
> +
> +### x86/PV
> +
> +Status: Supported
> +
> +Traditional Xen Project PV guest
> +
> +### x86/HVM
> +
> +Status: Supported
> +
> +Fully virtualised guest using hardware virtualisation extensions
> +
> +Requires hardware virtualisation support
> +
> +### x86/PV-on-HVM

Do we really consider this a guest type? From both Xen and the
toolstack PoV this is just a HVM guest. What's more, I'm not really
sure xl/libxl has the right options to create a HVM guest _without_
exposing any PV interfaces.

Ie: can a HMV guest without PV timers and PV event channels
actually be created? Or even without having the MSR to initialize the
hypercall page.

> +
> +Status: Supported
> +
> +Fully virtualised guest using PV extensions/drivers for improved performance
> +
> +Requires hardware virtualisation support
> +
> +### x86/PVH guest
> +
> +Status: Preview
> +
> +PVHv2 guest support
> +
> +Requires hardware virtualisation support
> +
> +### x86/PVH dom0
  ^ v2
> +
> +Status: Experimental

The status of this

[Xen-devel] [PATCH v2 0/2] x86/mm: merge ptwr and mmio_ro page fault handlers

Address Andrew's comments and rebased on top of staging.

Wei Liu (2):
  x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt
  x86/mm: merge ptwr and mmio_ro page fault handlers

 xen/arch/x86/mm.c| 302 +--
 xen/arch/x86/traps.c |  20 ++--
 xen/include/asm-x86/mm.h |   5 +-
 3 files changed, 145 insertions(+), 182 deletions(-)

-- 
2.11.0


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

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

2017-08-31 Thread Paul Durrant

> -Original Message-
> From: Michael Schinzel [mailto:schin...@ip-projects.de]
> Sent: 31 August 2017 12:12
> To: Paul Durrant ; xen-devel@lists.xen.org
> Cc: Thomas Toka 
> Subject: AW: Memory Issue HVM guest after Upgrade from 4.4 to 4.8
> 
> Hello,
> 

Again Don't top post!

> with traditional i get the information
> 
> root@v34:/etc/xen# xl create vmanager1866.cfg
> Parsing config from vmanager1866.cfg
> libxl: error: libxl_dm.c:2024:libxl__spawn_local_dm: device model
> /usr/lib/xen-4.8/bin/qemu-dm is not executable: No such file or directory
> libxl: error: libxl_dm.c:2189:device_model_spawn_outcome: (null): spawn
> failed (rc=-3)
> libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device model
> did not start: -3
> libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 67
> libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest
> with domid 67
> libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 67 failed
> 
> when i try to start the VM.
> 

That suggests that you did not build/install qemu trad. How did you install 
Xen? If you are not building yourself then you need to take this thread to 
xen-users.

  Paul

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

[Xen-devel] [PATCH v2 1/2] x86/mm: don't wrap x86_emulate_ctxt in ptwr_emulate_ctxt

Rewrite the code so that it has the same structure as
mmio_ro_emualte_ctxt. x86_emulate_ctxt now points to ptwr_emulate_ctxt
via its data pointer.

This patch will help unify mmio_ro and ptwr code paths later.

Signed-off-by: Wei Liu 
---
v2: do away with pointer in ptwr_emulate_ctxt
---
 xen/arch/x86/mm.c | 48 +++-
 1 file changed, 23 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f4b9747aba..3306088255 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4964,7 +4964,6 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
  */
 
 struct ptwr_emulate_ctxt {
-struct x86_emulate_ctxt ctxt;
 unsigned long cr2;
 l1_pgentry_t  pte;
 };
@@ -4995,7 +4994,7 @@ static int ptwr_emulated_update(
 paddr_t val,
 unsigned int bytes,
 unsigned int do_cmpxchg,
-struct ptwr_emulate_ctxt *ptwr_ctxt)
+struct x86_emulate_ctxt *ctxt)
 {
 unsigned long mfn;
 unsigned long unaligned_addr = addr;
@@ -5003,6 +5002,7 @@ static int ptwr_emulated_update(
 l1_pgentry_t pte, ol1e, nl1e, *pl1e;
 struct vcpu *v = current;
 struct domain *d = v->domain;
+struct ptwr_emulate_ctxt *ptwr_ctxt = ctxt->data;
 int ret;
 
 /* Only allow naturally-aligned stores within the original %cr2 page. */
@@ -5026,7 +5026,7 @@ static int ptwr_emulated_update(
 {
 x86_emul_pagefault(0, /* Read fault. */
addr + sizeof(paddr_t) - rc,
-   _ctxt->ctxt);
+   ctxt);
 return X86EMUL_EXCEPTION;
 }
 /* Mask out bits provided by caller. */
@@ -5141,9 +5141,7 @@ static int ptwr_emulated_write(
 
 memcpy(, p_data, bytes);
 
-return ptwr_emulated_update(
-offset, 0, val, bytes, 0,
-container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
+return ptwr_emulated_update(offset, 0, val, bytes, 0, ctxt);
 }
 
 static int ptwr_emulated_cmpxchg(
@@ -5166,9 +5164,7 @@ static int ptwr_emulated_cmpxchg(
 memcpy(, p_old, bytes);
 memcpy(, p_new, bytes);
 
-return ptwr_emulated_update(
-offset, old, new, bytes, 1,
-container_of(ctxt, struct ptwr_emulate_ctxt, ctxt));
+return ptwr_emulated_update(offset, old, new, bytes, 1, ctxt);
 }
 
 static const struct x86_emulate_ops ptwr_emulate_ops = {
@@ -5187,14 +5183,14 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long 
addr,
 struct domain *d = v->domain;
 struct page_info *page;
 l1_pgentry_t  pte;
-struct ptwr_emulate_ctxt ptwr_ctxt = {
-.ctxt = {
-.regs = regs,
-.vendor = d->arch.cpuid->x86_vendor,
-.addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
-.sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
-.lma   = !is_pv_32bit_domain(d),
-},
+struct ptwr_emulate_ctxt ptwr_ctxt;
+struct x86_emulate_ctxt ctxt = {
+   .regs = regs,
+   .vendor = d->arch.cpuid->x86_vendor,
+   .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
+   .sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
+   .lma   = !is_pv_32bit_domain(d),
+   .data  = _ctxt,
 };
 int rc;
 
@@ -5221,10 +5217,12 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long 
addr,
 goto bail;
 }
 
-ptwr_ctxt.cr2 = addr;
-ptwr_ctxt.pte = pte;
+ptwr_ctxt = (struct ptwr_emulate_ctxt) {
+.cr2 = addr,
+.pte = pte,
+};
 
-rc = x86_emulate(_ctxt.ctxt, _emulate_ops);
+rc = x86_emulate(, _emulate_ops);
 
 page_unlock(page);
 put_page(page);
@@ -5239,18 +5237,18 @@ int ptwr_do_page_fault(struct vcpu *v, unsigned long 
addr,
  * emulation bug, or a guest playing with the instruction stream under
  * Xen's feet.
  */
-if ( ptwr_ctxt.ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
- ptwr_ctxt.ctxt.event.vector == TRAP_page_fault )
-pv_inject_event(_ctxt.ctxt.event);
+if ( ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
+ ctxt.event.vector == TRAP_page_fault )
+pv_inject_event();
 else
 gdprintk(XENLOG_WARNING,
  "Unexpected event (type %u, vector %#x) from emulation\n",
- ptwr_ctxt.ctxt.event.type, ptwr_ctxt.ctxt.event.vector);
+ ctxt.event.type, ctxt.event.vector);
 
 /* Fallthrough */
 case X86EMUL_OKAY:
 
-if ( ptwr_ctxt.ctxt.retire.singlestep )
+if ( ctxt.retire.singlestep )
 pv_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 
 /* Fallthrough */
-- 
2.11.0


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

[Xen-devel] [PATCH v2 2/2] x86/mm: merge ptwr and mmio_ro page fault handlers

Provide a unified entry to avoid going through pte look-up, decode and
emulation cycle more than necessary. The path taken is determined by
the faulting address.

Note that the order of checks is changed in the new function, but the
order of the checks is performed shouldn't matter.

The sole caller is changed to use the new function.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v2: rebase and (sorta) merge Andrew's changes

Dom0 boots fine.  XTF is happy with this change. Let me know if more
tests can be done.
---
 xen/arch/x86/mm.c| 290 +--
 xen/arch/x86/traps.c |  20 ++--
 xen/include/asm-x86/mm.h |   5 +-
 3 files changed, 140 insertions(+), 175 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 3306088255..429442aa1d 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5176,91 +5176,6 @@ static const struct x86_emulate_ops ptwr_emulate_ops = {
 .cpuid  = pv_emul_cpuid,
 };
 
-/* Write page fault handler: check if guest is trying to modify a PTE. */
-int ptwr_do_page_fault(struct vcpu *v, unsigned long addr,
-   struct cpu_user_regs *regs)
-{
-struct domain *d = v->domain;
-struct page_info *page;
-l1_pgentry_t  pte;
-struct ptwr_emulate_ctxt ptwr_ctxt;
-struct x86_emulate_ctxt ctxt = {
-   .regs = regs,
-   .vendor = d->arch.cpuid->x86_vendor,
-   .addr_size = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
-   .sp_size   = is_pv_32bit_domain(d) ? 32 : BITS_PER_LONG,
-   .lma   = !is_pv_32bit_domain(d),
-   .data  = _ctxt,
-};
-int rc;
-
-/* Attempt to read the PTE that maps the VA being accessed. */
-pte = guest_get_eff_l1e(addr);
-
-/* We are looking only for read-only mappings of p.t. pages. */
-if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) ||
- rangeset_contains_singleton(mmio_ro_ranges, l1e_get_pfn(pte)) ||
- !get_page_from_mfn(l1e_get_mfn(pte), d) )
-goto bail;
-
-page = l1e_get_page(pte);
-if ( !page_lock(page) )
-{
-put_page(page);
-goto bail;
-}
-
-if ( (page->u.inuse.type_info & PGT_type_mask) != PGT_l1_page_table )
-{
-page_unlock(page);
-put_page(page);
-goto bail;
-}
-
-ptwr_ctxt = (struct ptwr_emulate_ctxt) {
-.cr2 = addr,
-.pte = pte,
-};
-
-rc = x86_emulate(, _emulate_ops);
-
-page_unlock(page);
-put_page(page);
-
-switch ( rc )
-{
-case X86EMUL_EXCEPTION:
-/*
- * This emulation only covers writes to pagetables which are marked
- * read-only by Xen.  We tolerate #PF (in case a concurrent pagetable
- * update has succeeded on a different vcpu).  Anything else is an
- * emulation bug, or a guest playing with the instruction stream under
- * Xen's feet.
- */
-if ( ctxt.event.type == X86_EVENTTYPE_HW_EXCEPTION &&
- ctxt.event.vector == TRAP_page_fault )
-pv_inject_event();
-else
-gdprintk(XENLOG_WARNING,
- "Unexpected event (type %u, vector %#x) from emulation\n",
- ctxt.event.type, ctxt.event.vector);
-
-/* Fallthrough */
-case X86EMUL_OKAY:
-
-if ( ctxt.retire.singlestep )
-pv_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
-
-/* Fallthrough */
-case X86EMUL_RETRY:
-perfc_incr(ptwr_emulations);
-return EXCRET_fault_fixed;
-}
-
- bail:
-return 0;
-}
-
 /*
  * fault handling for read-only MMIO pages
  */
@@ -5333,83 +5248,6 @@ static const struct x86_emulate_ops mmcfg_intercept_ops 
= {
 .cpuid  = pv_emul_cpuid,
 };
 
-/* Check if guest is trying to modify a r/o MMIO page. */
-int mmio_ro_do_page_fault(struct vcpu *v, unsigned long addr,
-  struct cpu_user_regs *regs)
-{
-l1_pgentry_t pte;
-unsigned long mfn;
-unsigned int addr_size = is_pv_32bit_vcpu(v) ? 32 : BITS_PER_LONG;
-struct mmio_ro_emulate_ctxt mmio_ro_ctxt = { .cr2 = addr };
-struct x86_emulate_ctxt ctxt = {
-.regs = regs,
-.vendor = v->domain->arch.cpuid->x86_vendor,
-.addr_size = addr_size,
-.sp_size = addr_size,
-.lma = !is_pv_32bit_vcpu(v),
-.data = _ro_ctxt,
-};
-int rc;
-
-/* Attempt to read the PTE that maps the VA being accessed. */
-pte = guest_get_eff_l1e(addr);
-
-/* We are looking only for read-only mappings of MMIO pages. */
-if ( ((l1e_get_flags(pte) & (_PAGE_PRESENT|_PAGE_RW)) != _PAGE_PRESENT) )
-return 0;
-
-mfn = l1e_get_pfn(pte);
-if ( mfn_valid(_mfn(mfn)) )
-{
-struct page_info *page = mfn_to_page(_mfn(mfn));
-struct domain *owner =

Re: [Xen-devel] ARM64:Porting xen to new hardware

2017-08-31 Thread bharat gohil

Hello Oleksandr,

I had removed A72 cluster and tried to boot only two A35 but I got same
error.

Is anything added or missing in A35 compare to A53?

Regards,
Bharat

On Wed, Aug 30, 2017 at 8:00 PM, bharat gohil  wrote:

> Hello Oleksandr,
> Thank you very much for your input.
>
> Yes. agree. I will check by removing A72 core from DT.
>
> Thanks,
> Bharat
>
> On Wed, Aug 30, 2017 at 7:44 PM, Oleksandr Tyshchenko  > wrote:
>
>> Hi,
>>
>> Not sure that I am a competent person, just my assumptions.
>>
>> CCed ARM guys.
>>
>> On Tue, Aug 29, 2017 at 5:21 PM, bharat gohil  wrote:
>> > Hello All
>> >
>> > I am trying to run Xen on new hardware which has two A35 and one A72
>> core.
>> > Xen booted intially but it hangs at smp_call_function(setup_virt_p
>> aging_one,
>> > (void *)val, 1) function call.
>>
>> It might be a consequence of that CPU cores are different. And they
>> might have different set of features, or even settings.
>> And these features/settings the boot CPU has don't compatible with
>> other (non-boot) CPUs.
>> Can you try not to bringup A72 core (remove it from DT or another
>> way), leave only two A35 and see what will happen.
>>
>> > Find following log of Xen booting,same set of features.
>> >
>> > - UART enabled -
>> > - CPU  booting -
>> > - Current EL 0008 -
>> > - Xen starting at EL2 -
>> > - Zero BSS -
>> > - Setting up control registers -
>> > - Turning on paging -
>> > - Ready -
>> > (XEN) Checking for initrd in /chosen
>> > (XEN) RAM: 4000 - bfff
>> > (XEN)
>> > (XEN) MODULE[0]: 4400 - 4400fd5a Device Tree
>> > (XEN)
>> > (XEN) Command line: 
>> Why? Does your device-tree have bootargs?
>>
>> > (XEN) Placing Xen at 0xbfe0-0xc000
>> > (XEN) Update BOOTMOD_XEN from 4008-40194e01 =>
>> > bfe01
>> > (XEN) Domain heap initialised
>> > (XEN) Booting using Device Tree
>> > (XEN) Platform: Generic System
>> > (XEN) Taking dtuart configuration from /chosen/stdout-path
>> > (XEN) Looking for dtuart at "serial0", options ""
>> >  __  ___  __  ___ __ _
>> >  \ \/ /___ _ __   | || |  / |/ _ \_   _ _ __  ___| |_ __ _| |__ | |
>> ___
>> >   \  // _ \ '_ \  | || |_ | | | | |__| | | | '_ \/ __| __/ _` | '_ \|
>> |/ _ \
>> >   /  \  __/ | | | |__   _|| | |_| |__| |_| | | | \__ \ || (_| | |_) |
>> |  __/
>> >  /_/\_\___|_| |_||_|(_)_|\___/\__,_|_|
>> |_|___/\__\__,_|_.__/|_|\___|
>> >
>> > (XEN) Xen version 4.10-unstable (bgohil@) (aarch64-linux-gnu-gcc
>> > (Ubuntu/Linaro7
>> > (XEN) Latest ChangeSet: Fri Aug 11 19:02:51 2017 +0100 git:9053a74-dirty
>> > (XEN) Processor: 410fd041: "ARM Limited", variant: 0x0, part 0xd04, rev
>> 0x1
>> > (XEN) 64-bit Execution:
>> > (XEN)   Processor Features:  
>> > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>> > (XEN) Extensions: FloatingPoint AdvancedSIMD
>> > (XEN)   Debug Features: 10305106 
>> > (XEN)   Auxiliary Features:  
>> > (XEN)   Memory Model Features: 00101122 
>> > (XEN)   ISA Features:  00011120 
>> > (XEN) 32-bit Execution:
>> > (XEN)   Processor Features: 0131:00011011
>> > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> > (XEN) Extensions: GenericTimer Security
>> > (XEN)   Debug Features: 03010066
>> > (XEN)   Auxiliary Features: 
>> > (XEN)   Memory Model Features: 10201105 4000 0126 02102211
>> > (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142
>> 00011121
>> > (XEN) Using PSCI-1.0 for SMP bringup
>> > (XEN) SMP: Allowing 3 CPUs
>> > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 13000 KHz
>> > (XEN) GICv2: WARNING: The GICC size is too small: 0x1000 expected 0x2000
>> Sounds like GIC settings are not completely correct.
>> Wrong GIC settings might lead to that IPIs won't work as expected. And
>> boot CPU will
>> get stuck waiting for another CPU.
>> Just double check.
>>
>> > (XEN) GICv2 initialization:
>> > (XEN) gic_dist_addr=1051
>> > (XEN) gic_cpu_addr=1052
>> > (XEN) gic_hyp_addr=1054
>> > (XEN) gic_vcpu_addr=1056
>> > (XEN) gic_maintenance_irq=25
>> > (XEN) GICv2: 384 lines, 6 cpus, secure (IID 0200143b).
>> > (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> > (XEN) Allocated console ring of 32 KiB.
>> > (XEN) Bringing up CPU1
>> > - CPU 0001 booting -
>> > - Current EL 0008 -
>> > - Xen starting at EL2 -
>> > - Setting up control registers -
>> > - Turning on paging -
>> > - Ready -
>> > (XEN) CPU 1 booted.
>> > (XEN) Bringing up CPU2
>> > - CPU 0200 booting -
>> > - Current EL 0008 -
>> > - Xen starting at EL2 -
>> > - Setting up control registers -
>> > - Turning on paging

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

2017-08-31 Thread Michael Schinzel

Hello,

with traditional i get the information

root@v34:/etc/xen# xl create vmanager1866.cfg
Parsing config from vmanager1866.cfg
libxl: error: libxl_dm.c:2024:libxl__spawn_local_dm: device model 
/usr/lib/xen-4.8/bin/qemu-dm is not executable: No such file or directory
libxl: error: libxl_dm.c:2189:device_model_spawn_outcome: (null): spawn failed 
(rc=-3)
libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device model did 
not start: -3
libxl: error: libxl.c:1575:libxl__destroy_domid: non-existant domain 67
libxl: error: libxl.c:1534:domain_destroy_callback: unable to destroy guest 
with domid 67
libxl: error: libxl.c:1463:domain_destroy_cb: destruction of domain 67 failed

when i try to start the VM.




Mit freundlichen Grüßen

Michael Schinzel
- Geschäftsführer -


IP-Projects GmbH & Co. KG
Am Vogelherd 14
D - 97295 Waldbrunn 
Telefon: 09306 - 76499-0
FAX: 09306 - 76499-15
E-Mail: i...@ip-projects.de
Geschäftsführer: Michael Schinzel
Registergericht Würzburg: HRA 6798
Komplementär: IP-Projects Verwaltungs GmbH



-Ursprüngliche Nachricht-
Von: Paul Durrant [mailto:paul.durr...@citrix.com] 
Gesendet: Donnerstag, 31. August 2017 13:06
An: Michael Schinzel ; xen-devel@lists.xen.org
Cc: Thomas Toka 
Betreff: RE: Memory Issue HVM guest after Upgrade from 4.4 to 4.8

> -Original Message-
> From: Michael Schinzel [mailto:schin...@ip-projects.de]
> Sent: 31 August 2017 12:02
> To: Paul Durrant ; xen-devel@lists.xen.org
> Cc: Thomas Toka 
> Subject: AW: Memory Issue HVM guest after Upgrade from 4.4 to 4.8
> 
> Hello,
> 
> sry for HTML Mail, it is auto configuration of Outlook.
> 

I know... it's annoying. Also, please don't top-post on this list.

> We have testet adding
> 
> device_model_version="qemu-xen"
> 
> to the config and rebooting the VMs. With this configuration, no 
> change at memory usage.
> 

You need

device_model_version="qemu-xen-traditional"

  Paul

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

[Xen-devel] [RFC PATCH V2 4/4] xl/libacpi: extend lapic_id() to uint32_t

From: Chao Gao 

This patch is to extend lapic_id() to support more vcpus.

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/firmware/hvmloader/util.c | 2 +-
 tools/libacpi/libacpi.h | 2 +-
 tools/libxl/libxl_x86_acpi.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/firmware/hvmloader/util.c b/tools/firmware/hvmloader/util.c
index db5f240..814ac2e 100644
--- a/tools/firmware/hvmloader/util.c
+++ b/tools/firmware/hvmloader/util.c
@@ -883,7 +883,7 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
 /* ACPI builder currently doesn't free memory so this is just a stub */
 }
 
-static uint8_t acpi_lapic_id(unsigned cpu)
+static uint32_t acpi_lapic_id(unsigned cpu)
 {
 return LAPIC_ID(cpu);
 }
diff --git a/tools/libacpi/libacpi.h b/tools/libacpi/libacpi.h
index 74778a5..0b04cbc 100644
--- a/tools/libacpi/libacpi.h
+++ b/tools/libacpi/libacpi.h
@@ -93,7 +93,7 @@ struct acpi_config {
 unsigned long rsdp;
 
 /* x86-specific parameters */
-uint8_t (*lapic_id)(unsigned cpu);
+uint32_t (*lapic_id)(unsigned cpu);
 uint32_t lapic_base_address;
 uint32_t ioapic_base_address;
 uint16_t pci_isa_irq_mask;
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index 1fa97ff..8fe084d 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -85,7 +85,7 @@ static void acpi_mem_free(struct acpi_ctxt *ctxt,
 {
 }
 
-static uint8_t acpi_lapic_id(unsigned cpu)
+static uint32_t acpi_lapic_id(unsigned cpu)
 {
 return cpu * 2;
 }
-- 
1.8.3.1


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

[Xen-devel] [RFC PATCH V2 0/4] Extend resources to support more vcpus in single VM

Change since v1:
1) Increase hap page pool according vcpu number
2) Use "Processor" syntax to define vcpus with APIC id < 255
in dsdt and use "Device" syntax for other vcpus in ACPI DSDT table.
3) Use XAPIC structure for vcpus with APIC id < 255
in dsdt and use x2APIC structure for other vcpus in the ACPI MADT table.

This patchset is to extend some resources(i.e, event channel,
hap and so) to support more vcpus for single VM.


Chao Gao (1):
  xl/libacpi: extend lapic_id() to uint32_t

Lan Tianyu (3):
  xen/hap: Increase hap size for more vcpus support
  Tool/ACPI: DSDT extension to support more vcpus
  hvmload: Add x2apic entry support in the MADT build

 tools/firmware/hvmloader/util.c |  2 +-
 tools/libacpi/acpi2_0.h | 10 +++
 tools/libacpi/build.c   | 59 +
 tools/libacpi/libacpi.h |  2 +-
 tools/libacpi/mk_dsdt.c | 18 -
 tools/libxl/libxl_x86_acpi.c|  2 +-
 xen/arch/x86/mm/hap/hap.c   | 10 ++-
 7 files changed, 76 insertions(+), 27 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [RFC PATCH V2 1/4] xen/hap: Increase hap page pool size for more vcpus support

This patch is to increase hap page pool size to support more vcpus in single VM.

Signed-off-by: Lan Tianyu 
---
 xen/arch/x86/mm/hap/hap.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index cdc77a9..96a7ed0 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -464,6 +464,7 @@ void hap_domain_init(struct domain *d)
 int hap_enable(struct domain *d, u32 mode)
 {
 unsigned int old_pages;
+unsigned int pages;
 unsigned int i;
 int rv = 0;
 
@@ -473,7 +474,14 @@ int hap_enable(struct domain *d, u32 mode)
 if ( old_pages == 0 )
 {
 paging_lock(d);
-rv = hap_set_allocation(d, 256, NULL);
+
+/* Increase hap page pool with max vcpu number. */
+if ( d->max_vcpus > 128 )
+pages = 256;
+else
+pages = 512;
+
+rv = hap_set_allocation(d, pages, NULL);
 if ( rv != 0 )
 {
 hap_set_allocation(d, 0, NULL);
-- 
1.8.3.1


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

[Xen-devel] [RFC PATCH V2 3/4] hvmload: Add x2apic entry support in the MADT build

This patch is to add x2apic entry support for ACPI MADT table
according to ACPI spec 5.2.12.12 Processor Local x2APIC Structure

Signed-off-by: Chao Gao 
Signed-off-by: Lan Tianyu 
---
 tools/libacpi/acpi2_0.h | 10 +
 tools/libacpi/build.c   | 59 +++--
 2 files changed, 52 insertions(+), 17 deletions(-)

diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
index 758a823..caa3682 100644
--- a/tools/libacpi/acpi2_0.h
+++ b/tools/libacpi/acpi2_0.h
@@ -322,6 +322,7 @@ struct acpi_20_waet {
 #define ACPI_IO_SAPIC   0x06
 #define ACPI_PROCESSOR_LOCAL_SAPIC  0x07
 #define ACPI_PLATFORM_INTERRUPT_SOURCES 0x08
+#define ACPI_PROCESSOR_LOCAL_X2APIC 0x09
 
 /*
  * APIC Structure Definitions.
@@ -338,6 +339,15 @@ struct acpi_20_madt_lapic {
 uint32_t flags;
 };
 
+struct acpi_20_madt_x2apic {
+uint8_t  type;
+uint8_t  length;
+uint16_t reserved;  /* reserved - must be zero */
+uint32_t apic_id;   /* Processor x2APIC ID  */
+uint32_t flags;
+uint32_t acpi_processor_id; /* ACPI processor UID */
+};
+
 /*
  * Local APIC Flags.  All other bits are reserved and must be 0.
  */
diff --git a/tools/libacpi/build.c b/tools/libacpi/build.c
index c7cc784..0c95850 100644
--- a/tools/libacpi/build.c
+++ b/tools/libacpi/build.c
@@ -82,9 +82,9 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 struct acpi_20_madt   *madt;
 struct acpi_20_madt_intsrcovr *intsrcovr;
 struct acpi_20_madt_ioapic*io_apic;
-struct acpi_20_madt_lapic *lapic;
 const struct hvm_info_table   *hvminfo = config->hvminfo;
 int i, sz;
+void *end;
 
 if ( config->lapic_id == NULL )
 return NULL;
@@ -92,7 +92,12 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 sz  = sizeof(struct acpi_20_madt);
 sz += sizeof(struct acpi_20_madt_intsrcovr) * 16;
 sz += sizeof(struct acpi_20_madt_ioapic);
-sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
+
+if (hvminfo->nr_vcpus < 128)
+sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
+else
+sz += sizeof(struct acpi_20_madt_lapic) * 128 +
+  sizeof(struct acpi_20_madt_x2apic) * (hvminfo->nr_vcpus - 128);
 
 madt = ctxt->mem_ops.alloc(ctxt, sz, 16);
 if (!madt) return NULL;
@@ -109,7 +114,7 @@ static struct acpi_20_madt *construct_madt(struct acpi_ctxt 
*ctxt,
 madt->flags  = ACPI_PCAT_COMPAT;
 
 if ( config->table_flags & ACPI_HAS_IOAPIC )
-{ 
+{
 intsrcovr = (struct acpi_20_madt_intsrcovr *)(madt + 1);
 for ( i = 0; i < 16; i++ )
 {
@@ -146,27 +151,47 @@ static struct acpi_20_madt *construct_madt(struct 
acpi_ctxt *ctxt,
 io_apic->ioapic_id   = config->ioapic_id;
 io_apic->ioapic_addr = config->ioapic_base_address;
 
-lapic = (struct acpi_20_madt_lapic *)(io_apic + 1);
+end = (struct acpi_20_madt_lapic *)(io_apic + 1);
 }
 else
-lapic = (struct acpi_20_madt_lapic *)(madt + 1);
+end = (struct acpi_20_madt_lapic *)(madt + 1);
+
+info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, end);
 
-info->nr_cpus = hvminfo->nr_vcpus;
-info->madt_lapic0_addr = ctxt->mem_ops.v2p(ctxt, lapic);
 for ( i = 0; i < hvminfo->nr_vcpus; i++ )
 {
-memset(lapic, 0, sizeof(*lapic));
-lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
-lapic->length  = sizeof(*lapic);
-/* Processor ID must match processor-object IDs in the DSDT. */
-lapic->acpi_processor_id = i;
-lapic->apic_id = config->lapic_id(i);
-lapic->flags = (test_bit(i, hvminfo->vcpu_online)
-? ACPI_LOCAL_APIC_ENABLED : 0);
-lapic++;
+unsigned int apic_id = config->lapic_id(i);
+
+if ( apic_id < 255 ) {
+struct acpi_20_madt_lapic *lapic = end;
+
+memset(lapic, 0, sizeof(*lapic));
+lapic->type= ACPI_PROCESSOR_LOCAL_APIC;
+lapic->length  = sizeof(*lapic);
+/* Processor ID must match processor-object IDs in the DSDT. */
+lapic->acpi_processor_id = i;
+lapic->apic_id = config->lapic_id(i);
+lapic->flags = ((i < hvminfo->nr_vcpus) &&
+test_bit(i, hvminfo->vcpu_online)
+? ACPI_LOCAL_APIC_ENABLED : 0);
+end = ++lapic;
+} else {
+struct acpi_20_madt_x2apic *lapic = end;
+
+memset(lapic, 0, sizeof(*lapic));
+lapic->type= ACPI_PROCESSOR_LOCAL_X2APIC;
+lapic->length  = sizeof(*lapic);
+/* Processor ID must match processor-object IDs in the DSDT. */
+lapic->acpi_processor_id = i;
+lapic->apic_id = config->lapic_id(i);
+lapic->flags =  test_bit(i,

[Xen-devel] [RFC PATCH V2 2/4] Tool/ACPI: DSDT extension to support more vcpus

This patch is to change DSDT table for processor object to support >128 vcpus
accroding to ACPI spec 8.4 Declaring Processors

Signed-off-by: Lan Tianyu 
---
 tools/libacpi/mk_dsdt.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/tools/libacpi/mk_dsdt.c b/tools/libacpi/mk_dsdt.c
index 2daf32c..6c4c325 100644
--- a/tools/libacpi/mk_dsdt.c
+++ b/tools/libacpi/mk_dsdt.c
@@ -24,6 +24,8 @@
 #include 
 #endif
 
+#define CPU_NAME_FMT  "P%.03X"
+
 static unsigned int indent_level;
 static bool debug = false;
 
@@ -196,10 +198,14 @@ int main(int argc, char **argv)
 /* Define processor objects and control methods. */
 for ( cpu = 0; cpu < max_cpus; cpu++)
 {
-push_block("Processor", "PR%02X, %d, 0xb010, 0x06", cpu, cpu);
+unsigned int apic_id = cpu * 2;
 
-stmt("Name", "_HID, \"ACPI0007\"");
+if ( apic_id > 255 )
+push_block("Device", CPU_NAME_FMT, cpu);
+else
+push_block("Processor", CPU_NAME_FMT", %d, 0xb010, 0x06", cpu, 
cpu);
 
+stmt("Name", "_HID, \"ACPI0007\"");
 stmt("Name", "_UID, %d", cpu);
 #ifdef CONFIG_ARM_64
 pop_block();
@@ -268,15 +274,15 @@ int main(int argc, char **argv)
 /* Extract current CPU's status: 0=offline; 1=online. */
 stmt("And", "Local1, 1, Local2");
 /* Check if status is up-to-date in the relevant MADT LAPIC entry... */
-push_block("If", "LNotEqual(Local2, \\_SB.PR%02X.FLG)", cpu);
+push_block("If", "LNotEqual(Local2, \\_SB."CPU_NAME_FMT ".FLG)", cpu);
 /* ...If not, update it and the MADT checksum, and notify OSPM. */
-stmt("Store", "Local2, \\_SB.PR%02X.FLG", cpu);
+stmt("Store", "Local2, \\_SB."CPU_NAME_FMT".FLG", cpu);
 push_block("If", "LEqual(Local2, 1)");
-stmt("Notify", "PR%02X, 1", cpu); /* Notify: Device Check */
+stmt("Notify", CPU_NAME_FMT", 1", cpu); /* Notify: Device Check */
 stmt("Subtract", "\\_SB.MSU, 1, \\_SB.MSU"); /* Adjust MADT csum */
 pop_block();
 push_block("Else", NULL);
-stmt("Notify", "PR%02X, 3", cpu); /* Notify: Eject Request */
+stmt("Notify", CPU_NAME_FMT", 3", cpu); /* Notify: Eject Request */
 stmt("Add", "\\_SB.MSU, 1, \\_SB.MSU"); /* Adjust MADT csum */
 pop_block();
 pop_block();
-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

2017-08-31 Thread George Dunlap

On 08/31/2017 12:03 PM, Paul Durrant wrote:
>> -Original Message-
>> From: George Dunlap [mailto:george.dun...@citrix.com]
>> Sent: 31 August 2017 11:56
>> To: Paul Durrant ; xen-de...@lists.xenproject.org
>> Cc: Ian Jackson ; Wei Liu ;
>> Andrew Cooper ; Jan Beulich
>> ; Tim (Xen.org) ; Dario Faggioli
>> ; Tamas K Lengyel ;
>> Roger Pau Monne ; Stefano Stabellini
>> ; Anthony Perard ;
>> Konrad Wilk 
>> Subject: Re: [PATCH RFC] Add SUPPORT.md
>>
>> On 08/31/2017 11:46 AM, Paul Durrant wrote:
 -Original Message-
 +
 +### Blkfront
 +
 +Status, Linux: Supported
 +Status, FreeBSD: Supported, Security support external
 +Status, Windows: Supported [XXX]
 +
 +Guest-side driver capable of speaking the Xen PV block protocol
 +
 +### Netfront
 +
 +Status, Linux: Supported
 +Status, FreeBSD: Supported, Security support external
 +States, Windows: Supported [XXX]
 +
>>>
>>> The Windows PV drivers are a sub-project of Xen so I guess they should
>> have the same level of support as Linux and FreeBSD frontends, but I'm
>> unclear as to what 'Supported' means in context of guest-side code. E.g. if
>> someone finds a way of crashing a network frontend using a specially crafted
>> packet, does that mean that an XSA should be issued?
>>
>> I would think so, yes.
>>
 +Guest-side driver capable of speaking the Xen PV networking protocol
 +
 +### Xen Framebuffer
 +
 +Status, Linux (xen-fbfront): Supported
 +
 +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
 +
 +[XXX FreeBSD? NetBSD?]
 +
 +### Xen Console
 +
 +Status, Linux (hvc_xen): Supported
 +
 +Guest-side driver capable of speaking the Xen PV console protocol
 +
 +[XXX FreeBSD? NetBSD? Windows?]
 +
>>>
>>> There is one for Windows too.
>>
>> OK, I'll add that in.
>>
 +### Xen PV keyboard
 +
 +Status, Linux (xen-kbdfront): Supported
 +
 +Guest-side driver capable of speaking the Xen PV keyboard protocol
>>>
>>> There is one for Windows too. It's not been officially announced as it
>> needed some fixes in QEMU allow frontends running in HVM guests to
>> function correctly.
>>
>> OK; would you describe its expected reliability in 4.10 as closer to
>> "Here be dragons", or "Quirky"?
> 
> I've lost track of the state of the QEMU patches but, if they go in, then it 
> should be completely reliable. If not then it will be non-functional... but 
> the same would be true of the Linux frontend running in an HVM guest. (The 
> patches fix a bug where xenvkbd and xenfb are interdependent... but the xenfb 
> backend is only created in the xenpv machine type).

OK -- well we should state here the status of the version(s) of qemu
that will ship in the xen release tarball; and we if the Linux frontend
is broken under HVM, we should specify that as well.

 -George

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

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

2017-08-31 Thread Paul Durrant

> -Original Message-
> From: Michael Schinzel [mailto:schin...@ip-projects.de]
> Sent: 31 August 2017 12:02
> To: Paul Durrant ; xen-devel@lists.xen.org
> Cc: Thomas Toka 
> Subject: AW: Memory Issue HVM guest after Upgrade from 4.4 to 4.8
> 
> Hello,
> 
> sry for HTML Mail, it is auto configuration of Outlook.
> 

I know... it's annoying. Also, please don't top-post on this list.

> We have testet adding
> 
> device_model_version="qemu-xen"
> 
> to the config and rebooting the VMs. With this configuration, no change at
> memory usage.
> 

You need

device_model_version="qemu-xen-traditional"

  Paul

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

Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

2017-08-31 Thread Paul Durrant

> -Original Message-
> From: George Dunlap [mailto:george.dun...@citrix.com]
> Sent: 31 August 2017 11:56
> To: Paul Durrant ; xen-de...@lists.xenproject.org
> Cc: Ian Jackson ; Wei Liu ;
> Andrew Cooper ; Jan Beulich
> ; Tim (Xen.org) ; Dario Faggioli
> ; Tamas K Lengyel ;
> Roger Pau Monne ; Stefano Stabellini
> ; Anthony Perard ;
> Konrad Wilk 
> Subject: Re: [PATCH RFC] Add SUPPORT.md
> 
> On 08/31/2017 11:46 AM, Paul Durrant wrote:
> >> -Original Message-
> >> +
> >> +### Blkfront
> >> +
> >> +Status, Linux: Supported
> >> +Status, FreeBSD: Supported, Security support external
> >> +Status, Windows: Supported [XXX]
> >> +
> >> +Guest-side driver capable of speaking the Xen PV block protocol
> >> +
> >> +### Netfront
> >> +
> >> +Status, Linux: Supported
> >> +Status, FreeBSD: Supported, Security support external
> >> +States, Windows: Supported [XXX]
> >> +
> >
> > The Windows PV drivers are a sub-project of Xen so I guess they should
> have the same level of support as Linux and FreeBSD frontends, but I'm
> unclear as to what 'Supported' means in context of guest-side code. E.g. if
> someone finds a way of crashing a network frontend using a specially crafted
> packet, does that mean that an XSA should be issued?
> 
> I would think so, yes.
> 
> >> +Guest-side driver capable of speaking the Xen PV networking protocol
> >> +
> >> +### Xen Framebuffer
> >> +
> >> +Status, Linux (xen-fbfront): Supported
> >> +
> >> +Guest-side driver capable of speaking the Xen PV Framebuffer protocol
> >> +
> >> +[XXX FreeBSD? NetBSD?]
> >> +
> >> +### Xen Console
> >> +
> >> +Status, Linux (hvc_xen): Supported
> >> +
> >> +Guest-side driver capable of speaking the Xen PV console protocol
> >> +
> >> +[XXX FreeBSD? NetBSD? Windows?]
> >> +
> >
> > There is one for Windows too.
> 
> OK, I'll add that in.
> 
> >> +### Xen PV keyboard
> >> +
> >> +Status, Linux (xen-kbdfront): Supported
> >> +
> >> +Guest-side driver capable of speaking the Xen PV keyboard protocol
> >
> > There is one for Windows too. It's not been officially announced as it
> needed some fixes in QEMU allow frontends running in HVM guests to
> function correctly.
> 
> OK; would you describe its expected reliability in 4.10 as closer to
> "Here be dragons", or "Quirky"?

I've lost track of the state of the QEMU patches but, if they go in, then it 
should be completely reliable. If not then it will be non-functional... but the 
same would be true of the Linux frontend running in an HVM guest. (The patches 
fix a bug where xenvkbd and xenfb are interdependent... but the xenfb backend 
is only created in the xenpv machine type).

  Paul

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

Re: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

2017-08-31 Thread Michael Schinzel

Hello,

sry for HTML Mail, it is auto configuration of Outlook. 

We have testet adding

device_model_version="qemu-xen"

to the config and rebooting the VMs. With this configuration, no change at 
memory usage.



Mit freundlichen Grüßen

Michael Schinzel
- Geschäftsführer -


IP-Projects GmbH & Co. KG
Am Vogelherd 14
D - 97295 Waldbrunn 
Telefon: 09306 - 76499-0
FAX: 09306 - 76499-15
E-Mail: i...@ip-projects.de
Geschäftsführer: Michael Schinzel
Registergericht Würzburg: HRA 6798
Komplementär: IP-Projects Verwaltungs GmbH



-Ursprüngliche Nachricht-
Von: Paul Durrant [mailto:paul.durr...@citrix.com] 
Gesendet: Donnerstag, 31. August 2017 10:44
An: Michael Schinzel ; xen-devel@lists.xen.org
Cc: Thomas Toka 
Betreff: RE: Memory Issue HVM guest after Upgrade from 4.4 to 4.8

De-htmling... My response indented...

From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of Michael 
Schinzel
Sent: 31 August 2017 08:43
To: xen-devel@lists.xen.org
Cc: Thomas Toka 
Subject: [Xen-devel] Memory Issue HVM guest after Upgrade from 4.4 to 4.8

Hello,

cause of the not longer support of xen 4.4 hypervisor, we actually upgrade all 
of our xen hosts from 4.4 - debian 8 to 4.8 - debian 9. 

Till this update, we run a host for example with 16 GB memory for dom0 with 
about 93 VMs. Till the upgrade, all memory usage was fine. The Host use about 
1.4 - 3 GB memory of the allocated 16 GB.

At each host, we mix HVM and Para VMs. After the Upgrade, the HVM VMs 
constantly use more and more memory. About 100 MB more each 2-3 Minutes until 
the Host swaps. The Problem is only with HVM VMs, Para is all fine.



top - 09:40:43 up 1 day,  2:28,  1 user,  load average: 0,94, 1,03, 1,27
Tasks: 1313 total,   5 running, 1308 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,2 us,  0,8 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,3 si,  0,5 st 
KiB Mem : 30315388 total, 10791316 free, 18483368 used,  1040704 buff/cache KiB 
Swap: 15998972 total, 15919092 free,    79880 used. 11492116 avail Mem

  PID USER  PR  NI    VIRT    RES    SHR S  %CPU %MEM TIME+ COMMAND
17962 root  20   0 1202580 680040  17356 R   5,2  2,2   1:20.06 
qemu-system-i38
21679 root  20   0 1454316 922580  17760 R   5,2  3,0   1:26.99 
qemu-system-i38
27772 root  20   0 1635108 1,082g  17524 S   5,2  3,7   1:27.50 
qemu-system-i38
29731 root  20   0 1374844 896052  17016 S   5,2  3,0   1:17.82 
qemu-system-i38
14209 root  20   0 1130476 597120  17724 S   4,9  2,0   1:17.24 
qemu-system-i38
19846 root  20   0 1417076 921928  16952 S   4,6  3,0   1:31.96 
qemu-system-i38
4830 root  20   0 2092624 1,496g  17640 S   3,9  5,2   1:53.88 
qemu-system-i38
18897 root  20   0 2013120 1,353g  17932 S   3,9  4,7   1:30.63 
qemu-system-i38
7832 root  20   0   46296   5160   3176 R   2,3  0,0   0:00.38 top
31832 root  20   0 1373044 835140  17688 S   2,3  2,8   0:48.82 
qemu-system-i38
28744 root  20   0 1053868 530680  17944 S   2,0  1,8   0:34.11 
qemu-system-i38
13307 root  20   0  913684 424984  17168 S   1,6  1,4   0:27.57 
qemu-system-i38
15248 root  20   0 1411316 887892  17608 S   1,6  2,9   0:43.97 
qemu-system-i38
16135 root  20   0 1204240 640644  17776 S   1,6  2,1   0:37.28 
qemu-system-i38
20763 root  20   0 1036288 513848  17484 S   1,6  1,7   0:35.76 
qemu-system-i38
22663 root  20   0  851712 301236  17588 S   1,6  1,0   0:28.24 
qemu-system-i38
24849 root  20   0 1164908 644736  17824 S   1,6  2,1   0:39.93 
qemu-system-i38
25871 root  20   0 1113684 571548  17616 S   1,6  1,9   0:37.14 
qemu-system-i38
26840 root  20   0 1045604 515216  17888 S   1,6  1,7   0:35.42 
qemu-system-i38
30693 root  20   0 2329944 1,734g  17644 S   1,6  6,0   1:32.11 
qemu-system-i38
23743 root  20   0 1470544 929708  17500 S   1,3  3,1   0:47.23 
qemu-system-i38


The config file of one HVM guest:

#kernel = "hvmloader"
builder='hvm'
memory = 512
maxmem = 512
shadow_memory = 8
name = "vmanager1157"
vif = [ 'vifname=vmanager1157, rate=100Mb/s, bridge=xenbr0.240, mac=xxx, ip=xxx 
 2001:1608:10:3:0:0:c:1' ] vif_other_config = [ 'xxx, 'tbf', 'rate=100Mb/s', 
'bps_read=150Mb/s', 'bps_write=150Mb/s', 'iops_read=15IOPS', 
'iops_write=15IOPS' ] disk = [ 'phy:/dev/vm/vmanager1157-root,xvda,w', 
'file:/root/vmanager/iso/CentOS-7.0-1406-x86_64-NetInstall.iso,xvdc:cdrom,r' ] 
boot="cd"
vcpus = 1
sdl=0
vnc=1
vnclisten="0.0.0.0"
vncdisplay=69
vncpasswd='3s2Xwv65'
vncunused=0
stdvga=0
serial='pty'
usbdevice='tablet'
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'destroy'


Is this normal with the new Xen Hypervisor? Actually we use Kernel Version 
4.12.10. So the newest Kernel with Xen Support.

> The default choice for QEMU changed between 4.4 and 4.8. In 4.4 is was trad 
> and in 4.8 it is upstream. If you force use of trad in your config, do you 
> still see the apparent leak?
>
>Paul

Yours

[Xen-devel] [xen-unstable-smoke test] 112980: regressions - trouble: broken/fail/pass