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

2017-08-28 Thread osstest service owner 
flight 112910 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112910/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 112900 
pass in 112910
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail in 
112900 pass in 112910
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore.2 fail in 112900 pass 
in 112910
 test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail pass in 
112900
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 112900

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112891

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 112891
 build-arm64-pvops 3 capture-logsbroken like 112891
 build-arm64-xsm   2 hosts-allocate  broken like 112891
 build-arm64-xsm   3 capture-logsbroken like 112891
 build-arm64   2 hosts-allocate  broken like 112891
 build-arm64   3 capture-logsbroken like 112891
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 112900 blocked 
in 112891
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 112900 blocked in 
112891
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 112900 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 112900 never pass
 test-armhf-armhf-xl-rtds 12 guest-start  fail  like 112891
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112891
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112891
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112891
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-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-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-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never

Re: [Xen-devel] [RFC PATCH 3/5] Tool/ACPI: DSDT extension to support more vcpus

2017-08-28 Thread Lan Tianyu 
On 2017年08月25日 18:36, Roger Pau Monné wrote:
> On Thu, Aug 24, 2017 at 10:52:18PM -0400, Lan Tianyu wrote:
>> This patch is to change DSDT table for processor object to support >255 
>> vcpus.
> 
> The note in ACPI 6.1A spec section 5.2.12.12 contains the following:
> 
> [Compatibility note] On some legacy OSes, Logical processors with APIC
> ID values less than 255 (whether in XAPIC or X2APIC mode) must use the
> Processor Local APIC structure to convey their APIC information to
> OSPM, and those processors must be declared in the DSDT using the
> Processor() keyword. Logical processors with APIC ID values 255 and
> greater must use the Processor Local x2APIC structure and be declared
> using the Device() keyword. See Section 19.6.102 "Processor (Declare
> Processor)" for more information.
> 
> So you cannot unconditionally switch to using the Device for all
> processors.
> 
> vCPUs <= 128 need to use the Processor keyword, while vCPUs > 128 need
> to use the Device keyword.

Yes, that's right and will fix.
-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [RFC PATCH 3/5] Tool/ACPI: DSDT extension to support more vcpus

2017-08-28 Thread Lan Tianyu 
On 2017年08月25日 20:01, Jan Beulich wrote:
 On 25.08.17 at 12:36,  wrote:
>> On Thu, Aug 24, 2017 at 10:52:18PM -0400, Lan Tianyu wrote:
>>> This patch is to change DSDT table for processor object to support >255 
>> vcpus.
>>
>> The note in ACPI 6.1A spec section 5.2.12.12 contains the following:
>>
>> [Compatibility note] On some legacy OSes, Logical processors with APIC
>> ID values less than 255 (whether in XAPIC or X2APIC mode) must use the
>> Processor Local APIC structure to convey their APIC information to
>> OSPM, and those processors must be declared in the DSDT using the
>> Processor() keyword. Logical processors with APIC ID values 255 and
>> greater must use the Processor Local x2APIC structure and be declared
>> using the Device() keyword. See Section 19.6.102 "Processor (Declare
>> Processor)" for more information.
>>
>> So you cannot unconditionally switch to using the Device for all
>> processors.
>>
>> vCPUs <= 128 need to use the Processor keyword, while vCPUs > 128 need
>> to use the Device keyword.
> 
> While changing this code, may I suggest to stop referring to the
> 128 vCPU boundary? The decision should be solely based on
> LAPIC ID, such that the only place to change later on will end up
> being the one where it gets set to double the vCPU number.
> 

OK. Got it.

-- 
Best regards
Tianyu Lan

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

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

2017-08-28 Thread osstest service owner 
flight 112911 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112911/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 51ce27fd8c583845480858eda503f38e8b42d619
baseline version:
 ovmf ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671

Last test of basis   112903  2017-08-28 07:17:30 Z0 days
Testing same since   112911  2017-08-28 13:47:46 Z0 days1 attempts


People who touched revisions under test:
  Brijesh Singh 
  Eric Dong 
  Jiewen Yao 
  Ruiyu Ni 
  Star Zeng 

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=51ce27fd8c583845480858eda503f38e8b42d619
+ . ./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 
51ce27fd8c583845480858eda503f38e8b42d619
+ branch=ovmf
+ revision=51ce27fd8c583845480858eda503f38e8b42d619
+ . ./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
+ '[' x51ce27fd8c583845480858eda503f38e8b42d619 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ :

Re: [Xen-devel] [RFC PATCH 0/5] Extend resources to support more vcpus in single VM

2017-08-28 Thread Lan Tianyu 
On 2017年08月25日 22:10, Meng Xu wrote:
> Hi Tianyu,
> 
> On Thu, Aug 24, 2017 at 10:52 PM, Lan Tianyu  wrote:
>>
>> 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 (4):
>>   xen/hap: Increase hap size for more vcpus support
>>   XL: Increase event channels to support more vcpus
>>   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   | 61 
>> +
>>  tools/libacpi/libacpi.h |  2 +-
>>  tools/libacpi/mk_dsdt.c | 11 
>>  tools/libxl/libxl_create.c  |  2 +-
>>  tools/libxl/libxl_x86_acpi.c|  2 +-
>>  xen/arch/x86/mm/hap/hap.c   |  2 +-
>>  8 files changed, 63 insertions(+), 29 deletions(-)
> 
> 
> How many VCPUs for a single VM do you want to support with this patch set?

Hi Meng:
Sorry for later response. We hope to increase max vcpu number to 512.
This also have dependency on other jobs(i.e, cpu topology, mult page
support for ioreq server and virtual IOMMU).

-- 
Best regards
Tianyu Lan

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

Re: [Xen-devel] [Qemu-devel] [PATCH 4/5] pci: Add INTERFACE_LEGACY_PCI_DEVICE to legacy PCI devices

2017-08-28 Thread Eduardo Habkost 
On Mon, Aug 28, 2017 at 06:58:37PM -0400, John Snow wrote:
> 
> 
> On 08/25/2017 03:39 PM, Eduardo Habkost wrote:
> > CCing maintainers of affected devices (sorry for not CCing you
> > before).
> > 
> > On Wed, Aug 23, 2017 at 07:14:44PM -0300, Eduardo Habkost wrote:
> >> Add INTERFACE_LEGACY_PCI_DEVICE to all direct subtypes of
> >> TYPE_PCI_DEVICE, except:
> >>
> >> 1) The ones that already have INTERFACE_PCIE_DEVICE set:
> >>
> >> * base-xhci
> >> * e1000e
> >> * nvme
> >> * pvscsi
> >> * vfio-pci
> >> * virtio-pci
> >> * vmxnet3
> >>
> >> 2) base-pci-bridge
> >>
> >> Not all PCI bridges are legacy PCI devices, so
> >> INTERFACE_LEGACY_PCI_DEVICE is added only to the subtypes that
> >> are actually legacy PCI devices:
> >>
> >> * dec-21154-p2p-bridge
> >> * i82801b11-bridge
> >> * pbm-bridge
> >> * pci-bridge
> >>
> >> The direct subtypes of base-pci-bridge not touched by this patch
> >> are:
> >>
> >> * xilinx-pcie-root: Already marked as PCIe-only device.
> >> * pcie-port: all non-abstract subtypes of pcie-port are already
> >>   marked as PCIe-only devices.
> >>
> >> 3) megasas-base
> >>
> >> Not all megasas devices are legacy PCI devices, so the interface
> >> names are added to the subclasses registered by
> >> megasas_register_types(), according to information in the
> >> megasas_devices[] array.
> >>
> >> "megasas-gen2" already implements INTERFACE_PCIE_DEVICE, so add
> >> INTERFACE_LEGACY_PCI_DEVICE only to "megasas".
> >>
> >> Signed-off-by: Eduardo Habkost 
> >> ---
> 
> [...]
> 
> >>  hw/ide/ich.c|  4 
> >>  hw/ide/pci.c|  4 
> 
> Acked-by: John Snow 
> 
> 
> (Random fly-by comment without looking at the other patches: I assume
> there are reasons it's not appropriate or good to add a legacy PCI
> device parent that we inherit from, and it's instead better to manually
> add the property to all children?)

Yes, the reason I'm using interfaces instead of regular
inheritance is the existence of hybrid devices (see patch 2/5).

-- 
Eduardo

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

[Xen-devel] [xen-4.7-testing test] 112909: regressions - trouble: blocked/broken/fail/pass

2017-08-28 Thread osstest service owner 
flight 112909 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112909/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-2 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112851
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112851
 test-xtf-amd64-amd64-3 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112851
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail REGR. vs. 112851

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate fail REGR. vs. 
112851

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-xsm   2 hosts-allocate  broken like 112851
 build-arm64-xsm   3 capture-logsbroken like 112851
 build-arm64-pvops 2 hosts-allocate  broken like 112851
 build-arm64   2 hosts-allocate  broken like 112851
 build-arm64-pvops 3 capture-logsbroken like 112851
 build-arm64   3 capture-logsbroken like 112851
 test-xtf-amd64-amd64-1  48 xtf/test-hvm64-lbr-tsx-vmentry fail like 112851
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112851
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112851
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112851
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112851
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112851
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112851
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112851
 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-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-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-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-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-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

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

2017-08-28 Thread Lan Tianyu 
On 2017年08月25日 18:11, Roger Pau Monné wrote:
> On Thu, Aug 24, 2017 at 10:52:19PM -0400, Lan Tianyu wrote:
>> This patch is to add x2apic entry support for ACPI MADT table.
>>
>> Signed-off-by: Lan Tianyu 
>> Signed-off-by: Chao Gao 
>> ---
>>  tools/libacpi/acpi2_0.h | 10 
>>  tools/libacpi/build.c   | 61 
>> ++---
>>  2 files changed, 53 insertions(+), 18 deletions(-)
>>
>> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
>> index 758a823..ff18b3e 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 */
> 
> There's a mix of tabs and spaces above.
> 
>> +};
>> +
>>  /*
>>   * 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..36e582a 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,11 @@ 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 < 256)
>> +sz += sizeof(struct acpi_20_madt_lapic) * hvminfo->nr_vcpus;
>> +else
>> +sz += sizeof(struct acpi_20_madt_x2apic) * hvminfo->nr_vcpus;
> 
> This is wrong, APIC ID is cpu id * 2, so the limit here needs to be
> 128, not 256. Also this should be set as a constant somewhere.

Sorry. We made APIC ID was vcpu id in our internal repo and didn't send
out. Will change this in next version.

> 
> Apart from that, although this is technically correct, I would rather
> prefer the first 128 vCPUs to have xAPIC entries, and APIC IDs > 254
> to use x2APIC entries. This will allow a guest without x2APIC support
> to still boot on VMs > 128 vCPUs, although they won't be able to use
> the extra CPUs. IIRC this is in line with what bare metal does.

OK. Will update.

> 
> Roger.
> 


-- 
Best regards
Tianyu Lan

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

[Xen-devel] [xen-4.8-testing test] 112908: regressions - trouble: blocked/broken/fail/pass

2017-08-28 Thread osstest service owner 
flight 112908 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112908/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112871
 test-amd64-i386-xl-xsm   18 guest-localmigrate/x10   fail REGR. vs. 112871
 test-xtf-amd64-amd64-5 48 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 112871

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-pvops 2 hosts-allocate  broken like 112871
 build-arm64-xsm   2 hosts-allocate  broken like 112871
 build-arm64   2 hosts-allocate  broken like 112871
 build-arm64-xsm   3 capture-logsbroken like 112871
 build-arm64-pvops 3 capture-logsbroken like 112871
 build-arm64   3 capture-logsbroken like 112871
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112860
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112871
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112871
 test-amd64-amd64-xl-pvh-intel 15 guest-saverestorefail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   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-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-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 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-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-armhf-armhf-libvirt-raw 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-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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   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
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for

Re: [Xen-devel] [Qemu-devel] [PATCH 4/5] pci: Add INTERFACE_LEGACY_PCI_DEVICE to legacy PCI devices

2017-08-28 Thread John Snow 


On 08/25/2017 03:39 PM, Eduardo Habkost wrote:
> CCing maintainers of affected devices (sorry for not CCing you
> before).
> 
> On Wed, Aug 23, 2017 at 07:14:44PM -0300, Eduardo Habkost wrote:
>> Add INTERFACE_LEGACY_PCI_DEVICE to all direct subtypes of
>> TYPE_PCI_DEVICE, except:
>>
>> 1) The ones that already have INTERFACE_PCIE_DEVICE set:
>>
>> * base-xhci
>> * e1000e
>> * nvme
>> * pvscsi
>> * vfio-pci
>> * virtio-pci
>> * vmxnet3
>>
>> 2) base-pci-bridge
>>
>> Not all PCI bridges are legacy PCI devices, so
>> INTERFACE_LEGACY_PCI_DEVICE is added only to the subtypes that
>> are actually legacy PCI devices:
>>
>> * dec-21154-p2p-bridge
>> * i82801b11-bridge
>> * pbm-bridge
>> * pci-bridge
>>
>> The direct subtypes of base-pci-bridge not touched by this patch
>> are:
>>
>> * xilinx-pcie-root: Already marked as PCIe-only device.
>> * pcie-port: all non-abstract subtypes of pcie-port are already
>>   marked as PCIe-only devices.
>>
>> 3) megasas-base
>>
>> Not all megasas devices are legacy PCI devices, so the interface
>> names are added to the subclasses registered by
>> megasas_register_types(), according to information in the
>> megasas_devices[] array.
>>
>> "megasas-gen2" already implements INTERFACE_PCIE_DEVICE, so add
>> INTERFACE_LEGACY_PCI_DEVICE only to "megasas".
>>
>> Signed-off-by: Eduardo Habkost 
>> ---

[...]

>>  hw/ide/ich.c|  4 
>>  hw/ide/pci.c|  4 

Acked-by: John Snow 


(Random fly-by comment without looking at the other patches: I assume
there are reasons it's not appropriate or good to add a legacy PCI
device parent that we inherit from, and it's instead better to manually
add the property to all children?)

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

[Xen-devel] [xen-4.9-testing test] 112907: regressions - trouble: blocked/broken/fail/pass

2017-08-28 Thread osstest service owner 
flight 112907 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112907/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64 16 guest-localmigrate/x10 fail REGR. 
vs. 112872
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112872
 build-armhf-pvops 6 kernel-build fail REGR. vs. 112872

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 10 debian-install   fail REGR. vs. 112872

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
 test-armhf-armhf-libvirt-raw  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-armhf-armhf-xl-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 112872
 build-arm64-pvops 2 hosts-allocate  broken like 112872
 build-arm64   2 hosts-allocate  broken like 112872
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112872
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112862
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112872
 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-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-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

version targeted for testing:
 xen  d23bcc5ae7342a6c369200cda46cf95bcf854dd0
baseline version:
 xen  5ff1de3e4f56b2dd7c5c7dae8b008f6ee6dc2081

Last test of basis   112872  2017-08-25 12:28:35 Z3 days
Testing same since   112907  2017-08-28 10:14:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chao Gao 
  Christopher Clark 
  Gregory Herrero 
  Ian Jackson 
  Jan Beulich 
  Kevin Tian 
  Olaf Hering 
  Rusty Bird 
  Wei Liu 

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

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

2017-08-28 Thread Goel, Sameer 


On 6/12/2017 7:24 AM, Julien Grall wrote:
> Hi Sameer,
> 
> On 08/06/17 20:30, Sameer Goel wrote:
>> Add limited support for parsing IORT table to initialize SMMU devices.
> 
> It would be nice to explain what you actually support in the commit message.
> 
> [...]
> 
>>
>>  #define IORT_TYPE_MASK(type)    (1 << (type))
>>  #define IORT_MSI_TYPE    (1 << ACPI_IORT_NODE_ITS_GROUP)
>>  #define IORT_IOMMU_TYPE    ((1 << ACPI_IORT_NODE_SMMU) |    \
>>  (1 << ACPI_IORT_NODE_SMMU_V3))
>>
>> +#if 0
>>  struct iort_its_msi_chip {
>>  struct list_head    list;
>>  struct fwnode_handle    *fw_node;
>>  u32    translation_id;
>>  };
>>
>> +#endif
>> +
> 
> Why cannot you enable MSI now? Actually this would allow us to know whether 
> we should import the code from Linux or reimplement or own.
Well was not too sure about how this will fit in, so was leaving this for next 
iteration. I will try to enable this.
> 
>>  struct iort_fwnode {
>>  struct list_head list;
>>  struct acpi_iort_node *iort_node;
>> @@ -60,7 +71,7 @@ static inline int iort_set_fwnode(struct acpi_iort_node 
>> *iort_node,
>>  {
>>  struct iort_fwnode *np;
>>
>> -    np = kzalloc(sizeof(struct iort_fwnode), GFP_ATOMIC);
>> +    np = xzalloc(struct iort_fwnode);
> 
> If we decide to keep this code close to Linux you need to:
> - avoid replacing Linux name by Xen name as much as possible. Instead use 
> macro
> - explain above each change why you need then
> 
> See what I did for the ARM SMMU.
Agreed
> 
>>
>>  if (WARN_ON(!np))
>>  return -ENOMEM;
>> @@ -114,7 +125,7 @@ static inline void iort_delete_fwnode(struct 
>> acpi_iort_node *node)
>>  list_for_each_entry_safe(curr, tmp, _fwnode_list, list) {
>>  if (curr->iort_node == node) {
>>  list_del(>list);
>> -    kfree(curr);
>> +    xfree(curr);
>>  break;
>>  }
>>  }
>> @@ -127,6 +138,7 @@ typedef acpi_status (*iort_find_node_callback)
>>  /* Root pointer to the mapped IORT table */
>>  static struct acpi_table_header *iort_table;
>>
>> +#if 0
>>  static LIST_HEAD(iort_msi_chip_list);
>>  static DEFINE_SPINLOCK(iort_msi_chip_lock);
>>
>> @@ -199,7 +211,7 @@ struct fwnode_handle *iort_find_domain_token(int 
>> trans_id)
>>
>>  return fw_node;
>>  }
>> -
>> +#endif
> 
> Please avoid dropping newline.
> 
>>  static struct acpi_iort_node *iort_scan_node(enum acpi_iort_node_type type,
>>   iort_find_node_callback callback,
>>   void *context)
>> @@ -219,9 +231,10 @@ static struct acpi_iort_node *iort_scan_node(enum 
>> acpi_iort_node_type type,
>>  iort_table->length);
>>
>>  for (i = 0; i < iort->node_count; i++) {
>> -    if (WARN_TAINT(iort_node >= iort_end, TAINT_FIRMWARE_WORKAROUND,
>> -   "IORT node pointer overflows, bad table!\n"))
>> +    if (iort_node >= iort_end) {
>> +    printk(XENLOG_ERR "IORT node pointer overflows, bad table!\n");
>>  return NULL;
>> +    }
>>
>>  if (iort_node->type == type &&
>>  ACPI_SUCCESS(callback(iort_node, context)))
>> @@ -249,6 +262,14 @@ bool iort_node_match(u8 type)
>>  return node != NULL;
>>  }
>>
>> +/*
>> + * Following 2 definies should come from the PCI passthrough implementation.
>> + * Based on the current pci_dev define the bus number and seg number come
>> + * from pci_dev so making an API assumption
>> + */
>> +#define to_pci_dev(p) container_of(p, struct pci_dev,dev)
>> +#define pci_domain_nr(dev) dev->seg
> 
> This should go in pci.h.
> 
>> +
>>  static acpi_status iort_match_node_callback(struct acpi_iort_node *node,
>>  void *context)
>>  {
>> @@ -256,6 +277,11 @@ static acpi_status iort_match_node_callback(struct 
>> acpi_iort_node *node,
>>  acpi_status status;
>>
>>  if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {
>> +    status = AE_NOT_IMPLEMENTED;
>> +/*
>> + * Named components not supported yet.
> 
> Can you expand?
Were not needed for now, but I agree we can enable the code.
> 
> [...]
> 
>> +/*
>> + * RID is the same as PCI_DEVID(BDF) for QDF2400
> 
> Xen is meant to be agnostic to the platform. Rather than making assumption, 
> we should discuss on way to get the RID. I will answer on Robin's mail about 
> it.
> 
>> + */
>>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>  {
>>  u32 *rid = data;
>> @@ -510,7 +550,7 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 
>> alias, void *data)
>>  *rid = alias;
>>  return 0;
>>  }
>> -
>> +#endif
> 
> Please avoid dropping newline
> 
>>  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
>>     struct fwnode_handle *fwnode,
>>     const struct iommu_ops *ops)
>> @@ -523,29 +563,24 @@ static int arm_smmu_iort_xlate(struct device *dev, u32 
>> streamid,
>>  return ret;
>>  }
>>
>>

Re: [Xen-devel] [RFC 6/6] acpi:arm64: Add support for parsing IORT table

2017-08-28 Thread Goel, Sameer 


On 6/9/2017 5:15 AM, Robin Murphy wrote:
> On 08/06/17 20:30, Sameer Goel wrote:
> [...]
>>  /**
>> - * iort_iommu_configure - Set-up IOMMU configuration for a device.
>> + * iort_iommu_configure - Set-up IOMMU configuration for a device. This
>> + * function sets up the fwspec as needed for a given device. Only PCI
>> + * devices are supported for now.
>>   *
>>   * @dev: device to configure
>>   *
>> - * Returns: iommu_ops pointer on configuration success
>> - *  NULL on configuration failure
>> + * Returns: Appropriate acpi_status
>>   */
>> -const struct iommu_ops *iort_iommu_configure(struct device *dev)
>> +acpi_status iort_iommu_configure(struct device *dev)
>>  {
>>  struct acpi_iort_node *node, *parent;
>> -const struct iommu_ops *ops = NULL;
>>  u32 streamid = 0;
>> +acpi_status status = AE_OK;
>>  
>>  if (dev_is_pci(dev)) {
>> -struct pci_bus *bus = to_pci_dev(dev)->bus;
>> +struct pci_dev *pci_device = to_pci_dev(dev);
>>  u32 rid;
>>  
>> -pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,
>> -   );
>> +rid = PCI_BDF2(pci_device->bus,pci_device->devfn);
> 
> Beware that the Linux code isn't actually correct to begin with[1]. I
> don't know how much Xen deals with PCI bridges and quirks, but as it
> stands you should be able to trivially expose the flaw here by plugging
> in a Marvell 88SE912x-based SATA card and watching either DMA or MSIs
> (or even both) kick up stream table faults.
> 
Appreciate the feedback Robin. I will try to incorporate the new IORT changes 
when I release the first patch set.  
> Robin.
> 
> [1]:http://www.spinics.net/lists/linux-acpi/msg74844.html
> 
>>  
>>  node = iort_scan_node(ACPI_IORT_NODE_PCI_ROOT_COMPLEX,
>> -  iort_match_node_callback, >dev);
>> +  iort_match_node_callback, dev);
>>  if (!node)
>> -return NULL;
>> +return AE_NOT_FOUND;
>>  
>>  parent = iort_node_map_rid(node, rid, ,
>> IORT_IOMMU_TYPE);
>>  
>> -ops = iort_iommu_xlate(dev, parent, streamid);
>> +status = iort_iommu_xlate(dev, parent, streamid);
>> +
>> +status = status ? AE_ERROR : AE_OK;
>>  
>>  } else {
>> +status = AE_NOT_IMPLEMENTED;
>> +#if 0
>>  int i = 0;
>>  
>>  node = iort_scan_node(ACPI_IORT_NODE_NAMED_COMPONENT,
>> @@ -616,11 +655,17 @@ const struct iommu_ops *iort_iommu_configure(struct 
>> device *dev)
>>  parent = iort_node_get_id(node, ,
>>IORT_IOMMU_TYPE, i++);
>>  }
>> +#endif
>>  }
>>  
>> -return ops;
>> +return status;
>>  }
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

2017-08-28 Thread Goel, Sameer 


On 6/12/2017 6:40 AM, Julien Grall wrote:
> Hi,
> 
> On 08/06/17 22:57, Stefano Stabellini wrote:
>> On Thu, 8 Jun 2017, Goel, Sameer wrote:
> diff --git a/xen/include/xen/fwnode.h b/xen/include/xen/fwnode.h
> new file mode 100644
> index 000..db65b15
> --- /dev/null
> +++ b/xen/include/xen/fwnode.h
> @@ -0,0 +1,35 @@
> +/*
> + * fwnode.h - Firmware device node object handle type definition.
> + *
> + * Copyright (C) 2015, Intel Corporation
> + * Author: Rafael J. Wysocki 
> + *
> + * 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.
> + *
> + * Ported from Linux include/linux/fwnode.h
> + *  => commit ce793486e23e0162a732c605189c8028e0910e86
> + *
> + * No functional Xen modifications.
> + */
> +
> +#ifndef __XEN_FWNODE_H_
> +#define __XEN_FWNODE_H_
> +
> +enum fwnode_type {
> +    FWNODE_INVALID = 0,
> +    FWNODE_OF,
> +    FWNODE_ACPI,
> +    FWNODE_ACPI_DATA,
> +    FWNODE_ACPI_STATIC,
> +    FWNODE_PDATA,
> +    FWNODE_IRQCHIP

 Do you really need to introduce all of them?

>>> Not really. We are interested in OF and ACPI_STATIC for now. Since the 
>>> verbatim file from Linux applied ok, I did not remove the other entries.
>>> What's your recommendation?
>>
>> Usually we keep the imported Linux definitions as-is.
> 
> If we keep as-is, the coding style should stay exactly the same. Even
> 
> Otherwise there is no point to import a verbatim copy of Linux as it would be 
> difficult to keep track of the changes.
> 
> In this case, I am not convinced we have a benefits to keep this code close 
> to Linux. It is small enough and we don't need 80% of it.
Ok. I will go ahead and remove whatever is not needed.
> 
> Cheers,
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [RFC 2/6] arm64: Add definitions for fwnode_handle

2017-08-28 Thread Goel, Sameer 


On 6/12/2017 6:51 AM, Julien Grall wrote:
> Hi Sameer,
> 
> On 08/06/17 22:42, Goel, Sameer wrote:
>> On 6/8/2017 1:59 PM, Julien Grall wrote:
>>>
>>>
>>> On 08/06/2017 20:30, Sameer Goel wrote:
 This will be used as a device property to match the DMA capable devices
 with the associated SMMU. The header file is a port from linux.

 Linux ChangeId:ce793486e23e: driver core / ACPI: Represent ACPI
 companions using fwnode_handle

 Signed-off-by: Sameer Goel 
 ---
  xen/include/asm-arm/device.h |  2 ++
  xen/include/xen/fwnode.h | 35 +++
  2 files changed, 37 insertions(+)
  create mode 100644 xen/include/xen/fwnode.h

 diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
 index 6734ae8..78c38fe 100644
 --- a/xen/include/asm-arm/device.h
 +++ b/xen/include/asm-arm/device.h
 @@ -2,6 +2,7 @@
  #define __ASM_ARM_DEVICE_H

  #include 
 +#include 

  enum device_type
  {
 @@ -19,6 +20,7 @@ struct device
  #ifdef CONFIG_HAS_DEVICE_TREE
  struct dt_device_node *of_node; /* Used by drivers imported from 
 Linux */
  #endif
 +    struct fwnode_handle *fwnode; /*fw device node identifier */
>>>
>>> I am a bit surprised you don't rework struct dev. As of_node is now 
>>> redundant with fwnode.
>>
>> I agree that this will eventually be removed. I have kept this in now just 
>> to maintain compatibility
>> (compilation and otherwise) with smmuv2 driver. I will add a comment to 
>> indicate this. So that it can
>> be easily identified and remove when we do a final cleanup. Can I prefix the 
>> comment with with XEN:TODO:?
> 
> A TODO would be nice, but who is going to do the rework?
I will still be on the hook to complete this cleanup. I was hoping to get the 
basic code in place and then 
start the rework on older drivers.
> 
> Cheers,
> 

-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

Re: [Xen-devel] [RFC 3/6] Introduce _xrealloc

2017-08-28 Thread Goel, Sameer 


On 6/9/2017 3:44 AM, Wei Liu wrote:
> On Thu, Jun 08, 2017 at 08:49:01PM +0100, Julien Grall wrote:
>> CC the REST maintainers
>>
>> On 08/06/2017 20:30, Sameer Goel wrote:
>>> Introduce a memory realloc function.
>>>
>>> Signed-off-by: Sameer Goel 
>>> ---
>>>  xen/common/xmalloc_tlsf.c | 13 +
>>>  xen/include/xen/xmalloc.h |  1 +
>>>  2 files changed, 14 insertions(+)
>>>
>>> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
>>> index b256dc5..52385a8 100644
>>> --- a/xen/common/xmalloc_tlsf.c
>>> +++ b/xen/common/xmalloc_tlsf.c
>>> @@ -612,6 +612,19 @@ void *_xzalloc(unsigned long size, unsigned long align)
>>>  return p ? memset(p, 0, size) : p;
>>>  }
>>>
>>> +void *_xrealloc(void *p, unsigned long new_size, unsigned long align)
>>> +{
>>> +void *new_p = _xmalloc(new_size, align);
>>> +
>>> +if(new_p && p)
>>
>> Coding style: if ( ... )
>>
>>> +{
>>> +memcpy(new_p, p, new_size);
> 
> This is wrong. How can you know if the area pointed to by p is at least
> new_size bytes long?
> 
Agreed, I revisited the code and will remove _xrealloc and use xfree and 
_xmalloc instead.

Thanks,
Sameer
-- 
 Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, 
Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.

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

[Xen-devel] [linux-next test] 112906: regressions - trouble: blocked/broken/fail/pass

2017-08-28 Thread osstest service owner 
flight 112906 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112906/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 112853
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 112853
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 112853
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 112853
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112853
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 112853
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 112853
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 112853
 build-amd64-pvops 6 kernel-build fail REGR. vs. 112853
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 112853
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 112853
 build-armhf-pvops 6 kernel-build fail REGR. vs. 112853

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 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-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1

Re: [Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

2017-08-28 Thread Boris Ostrovsky 
On 08/28/2017 11:41 AM, Jan Beulich wrote:
 On 28.08.17 at 16:35,  wrote:
>> On 08/28/2017 03:38 AM, Jan Beulich wrote:
> And finally I continue to be not really happy about the change as
> a whole. Despite what was discussed on v1, I'm concerned of the
> effects of this on hosts _not_ suffering from vector shortage.
> Could you live with the new behavior requiring a command line
> option to enable?
 I can add something like 'apic_share_vectors', defaulting to true,
 although it will not be useful in case of a hotplug. Defaulting to false?
>>> Along the lines of the above plus our desire to limit the number
>>> of top level options, how about "apic=isolate-vectors"?
>>>
>>> Also I don't understand your reference to hotplug, nor why you
>>> suggest two opposite default values.
>> Not two, just one --- not share vectors by default.
>>
>> As for hotplug, I was thinking of a case where a system is successfully
>> booted with shared vectors but then a device is added and we fail to
>> find enough free vectors. So the administrator would need to know in
>> advance whether a new card might be coming in.
>>
>> When defaulting to false (as in apic_share_vectors=false) if the
>> administrator decides to set it to true then he would be in some sense
>> explicitly agreeing to never plug anything in (or at least to tolerate
>> such a failure).
> Ah, I see. But imo the default ought to be current behavior.
>
>>> But finally, you agreeing to a command line option here makes
>>> me come back to an earlier suggestion: Didn't we agree that
>>> "x2apic_phys" would be sufficient to eliminate the issue? In which
>>> case no patch would be needed at all.
>> x2apic_phys means that we never share vectors. With 'isolate-vectors'
>> option we are still able to share them if the mask is explicitly specified.
> Well, aiui your primary goal is to address the vector shortage. For
> that you don't need the new option, you can get away with the
> existing one.


I don't have any numbers to prove (or disprove) that not sharing vectors
during boot but possibly sharing them later improves performance so yes,
x2apic_phys is a possible solution. Especially if with this (modified)
patch we'd default to original cluster mode behavior as you are suggesting.

-boris

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

[Xen-devel] [PATCH 2/4] mm: Don't poison a page if boot-time scrubbing is off

2017-08-28 Thread Boris Ostrovsky 
If boot-time scrubbing is turned off we don't check pages in
check_one_page(). Thus there is no reason to ever poison them.

Signed-off-by: Boris Ostrovsky 
---
 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 7d56e92..34a7992 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -712,6 +712,9 @@ static void poison_one_page(struct page_info *pg)
 mfn_t mfn = _mfn(page_to_mfn(pg));
 uint64_t *ptr;
 
+if ( !boot_scrub_done )
+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 4/4] mm: Don't hold heap lock in alloc_heap_pages() longer than necessary

2017-08-28 Thread Boris Ostrovsky 
Once pages are removed from the heap we don't need to hold the heap
lock. It is especially useful to drop it for an unscrubbed buddy since
we will be scrubbing it.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/page_alloc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b93dae9..1ec788e 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -858,6 +858,7 @@ static struct page_info *alloc_heap_pages(
 struct page_info *pg;
 bool need_tlbflush = false;
 uint32_t tlbflush_timestamp = 0;
+unsigned int dirty_cnt = 0;
 
 /* Make sure there are enough bits in memflags for nodeID. */
 BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
@@ -943,6 +944,8 @@ static struct page_info *alloc_heap_pages(
 
 check_low_mem_virq();
 
+spin_unlock(_lock);
+
 if ( d != NULL )
 d->last_alloc_node = node;
 
@@ -955,7 +958,7 @@ static struct page_info *alloc_heap_pages(
 {
 if ( !(memflags & MEMF_no_scrub) )
 scrub_one_page([i]);
-node_need_scrub[node]--;
+dirty_cnt++;
 }
 
 pg[i].count_info = PGC_state_inuse;
@@ -977,6 +980,8 @@ static struct page_info *alloc_heap_pages(
 check_one_page([i]);
 }
 
+spin_lock(_lock);
+node_need_scrub[node] -= dirty_cnt;
 spin_unlock(_lock);
 
 if ( need_tlbflush )
-- 
1.8.3.1


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

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

2017-08-28 Thread Boris Ostrovsky 
scrub_heap_pages() does early return if boot-time scrubbing is
disabled, neglecting to initialize lowmem VIRQ.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/page_alloc.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 9fa62d2..7d56e92 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1849,6 +1849,14 @@ void __init scrub_heap_pages(void)
 int last_distance, best_node;
 int cpus;
 
+/*
+ * Set bounds for the low mem virq algorithm.
+ * Not the most logical place for this but it needs to be done
+ * after dom0 has been constructed and this seems to be a
+ * convenient location.
+ */
+setup_low_mem_virq();
+
 if ( !opt_bootscrub )
 return;
 
@@ -1970,10 +1978,6 @@ 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. */
-setup_low_mem_virq();
 }
 
 
-- 
1.8.3.1


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

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

2017-08-28 Thread Boris Ostrovsky 
There is no need to scrub pages freed during dom0 construction
since heap will be scrubbed once dom0 is ready (by scrub_heap_pages()).

Since boot_scrub_done will not be set if boot-time scrubbing is off we
also check for domain state.

Signed-off-by: Boris Ostrovsky 
---
 xen/common/page_alloc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 34a7992..b93dae9 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2259,7 +2259,7 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
  */
 scrub = !!d->is_dying;
 #else
-scrub = true;
+scrub = boot_scrub_done || !!d->is_dying;
 #endif
 }
 else
-- 
1.8.3.1


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

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

2017-08-28 Thread Boris Ostrovsky 
First patch fixes a long-standing bug where a low memory monitor is
not initializes if boottime scrubbing is turned off.

The other threee patches are performace optimizations.

Boris Ostrovsky (4):
  mm: Initialize lowmem virq when boot-time scrubbing is disabled
  mm: Don't poison a page if boot-time scrubbing is off
  mm: Don't request scrubbing until dom0 is running
  mm: Don't hold heap lock in alloc_heap_pages() longer than necessary

 xen/common/page_alloc.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

-- 
1.8.3.1


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

Re: [Xen-devel] [PATCH v4 05/11] arm: add SMCCC protocol definitions.

2017-08-28 Thread Volodymyr Babchuk 

Hi Julien,

On 24.08.17 18:00, Julien Grall wrote:

Hi Volodymyr,

Title: No need for the full stop.

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

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.

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 
---
 xen/include/asm-arm/smccc.h | 92 
+

 1 file changed, 92 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..67da3fb
--- /dev/null
+++ b/xen/include/asm-arm/smccc.h
@@ -0,0 +1,92 @@
+/*
+ * Copyright (c) 2015, Linaro Limited


Linaro? Where does this code come from?

From the linux kernel. I think, I mentioned that in previous comments.
But this code was extended by me. And now there will be more changes.
Should I add remark about code origin somewhere?


+ * 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_SMC_320U
+#define ARM_SMCCC_SMC_641U


I am not sure to understand why you embed SMC in the name? The 
convention is SMC32/HVC32. So I would name


ARM_SMCCC_CONV_{32,64}


+#define ARM_SMCCC_CALL_CONV_SHIFT   30


Also, I would rename to ARM_SMCCC_CONV to fit with the value above.


+
+#define ARM_SMCCC_OWNER_MASK0x3F


Missing U.


+#define ARM_SMCCC_OWNER_SHIFT   24
+
+#define ARM_SMCCC_FUNC_MASK 0x
+
+/* Check if this is fast call */
+#define ARM_SMCCC_IS_FAST_CALL(smc_val) \
+((smc_val) & (ARM_SMCCC_FAST_CALL << ARM_SMCCC_TYPE_SHIFT))
+
+/* Check if this is 64 bit call  */
+#define 
ARM_SMCCC_IS_64(smc_val)\

+((smc_val) & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT))
+
+/* Get function number from function identifier */
+#define ARM_SMCCC_FUNC_NUM(smc_val) ((smc_val) & 
ARM_SMCCC_FUNC_MASK)

+
+/* Get service owner number from function identifier */
+#define 
ARM_SMCCC_OWNER_NUM(smc_val)\

+(((smc_val) >> ARM_SMCCC_OWNER_SHIFT) & ARM_SMCCC_OWNER_MASK)


Can we please use static inline helper for the 4 macros above?


+
+/*
+ * 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_CALL_CONV_SHIFT) 
|  \
+ (((owner) & ARM_SMCCC_OWNER_MASK) << ARM_SMCCC_OWNER_SHIFT) 
|  \

+ ((func_num) & ARM_SMCCC_FUNC_MASK))


The indentation looks wrong here. Also I think the (& *MASK) is not 
necessary here. It would be wrong by the user to pass a wrong value and 
even with the masking you would end up to wrong result.


If you are really worry of wrong result, then you should use 
BUILD_BUG_ON()/BUG_ON().



+
+/* 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)
+
+#endif  /* __ASM_ARM_SMCCC_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:b
+ */



Cheers,

[Xen-devel] [GIT PULL] (xen) stable/for-jens-4.13.. for 4.13-rc7 or 4.14-rc1 if you would like

2017-08-28 Thread Konrad Rzeszutek Wilk 

Hey Jens,

Please git pull the following branch:

git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
stable/for-jens-4.13

.. which as a bug-fix when shutting down xen block backend driver with
multiple queues and the driver not clearing all of them.

Thank you!

If you pull it in your 'for-linus' you will see this diff:

drivers/block/xen-blkback/xenbus.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

Annie Li (1):
  xen-blkback: stop blkback thread of every queue in xen_blkif_disconnect

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

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

2017-08-28 Thread osstest service owner 
flight 112912 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112912/

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 112905
 build-arm64   2 hosts-allocate  broken like 112905
 build-arm64-pvops 3 capture-logsbroken like 112905
 build-arm64   3 capture-logsbroken like 112905
 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  f0c1fc7b4c86af9a8de585b4cb2f7792817f404d
baseline version:
 xen  650310c51316c0c967d34a37022d8bda0b1133ea

Last test of basis   112905  2017-08-28 09:02:15 Z0 days
Testing same since   112912  2017-08-28 17:02:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 

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 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=f0c1fc7b4c86af9a8de585b4cb2f7792817f404d
+ . ./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 
f0c1fc7b4c86af9a8de585b4cb2f7792817f404d
+ branch=xen-unstable-smoke
+ revision=f0c1fc7b4c86af9a8de585b4cb2f7792817f404d
+ . ./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
+ '[' xf0c1fc7b4c86af9a8de585b4cb2f7792817f404d = 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
++ :

Re: [Xen-devel] [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

2017-08-28 Thread Konrad Rzeszutek Wilk 
On Mon, Aug 28, 2017 at 02:40:14PM -0400, Konrad Rzeszutek Wilk wrote:
> Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
> the support for this, but it does not work under x86 (as it stops
> 20_linux_xen from running).
> 
> The 20_linux_xen is run under a shell and any exits from within it:
> 
> (For example on x86):
> + /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
> [root@tst063 grub]# echo $?
> 1
> 
> will result in 20_linux_xen exciting without continuing
> and also causing grub2-mkconfig to stop processing.
> 
> As in:

git format-patch decided to eat this relevant part:

[root@tst063 grub]# ./grub-mkconfig | tail
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.13.0-0.rc5.git1.1.fc27.x86_64
Found initrd image: /boot/initramfs-4.13.0-0.rc5.git1.1.fc27.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2
Found initrd image: 
/boot/initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
echo'Loading Linux 
0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 ...'
linux   /vmlinuz-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2 
root=/dev/mapper/fedora_tst063-root ro single 
echo'Loading initial ramdisk ...'
initrd  /initramfs-0-rescue-ec082ee24aea41b9b16aca52a6d10cc2.img
}
}

### END /usr/local/etc/grub.d/10_linux ###

### BEGIN /usr/local/etc/grub.d/20_linux_xen ###

root@tst063 grub]# 

> 
> [root@tst063 ~]#
> 
> And no more.
> 
> This patch wraps the invocation of grub-file to be a in subshell
> and to process the return value in a conditional. That fixes
> the issue.
> 
> RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
> CC: Fu Wei 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  util/grub.d/20_linux_xen.in | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
> 
> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
> index c002fc9..083bcef 100644
> --- a/util/grub.d/20_linux_xen.in
> +++ b/util/grub.d/20_linux_xen.in
> @@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
>  if [ "x$is_top_level" != xtrue ]; then
>   echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
> "${xen_version}" | grub_quote)' \$menuentry_id_option 
> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>  fi
> -$grub_file --is-arm64-efi $current_xen
> -if [ $? -ne 0 ]; then
> - xen_loader="multiboot"
> - module_loader="module"
> -else
> +if ($grub_file --is-arm64-efi $current_xen); then
>   xen_loader="xen_hypervisor"
>   module_loader="xen_module"
> +else
> + xen_loader="multiboot"
> + module_loader="module"
>  fi
>  while [ "x$list" != "x" ] ; do
>   linux=`version_find_latest $list`
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64

2017-08-28 Thread Konrad Rzeszutek Wilk 
Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
the support for this, but it does not work under x86 (as it stops
20_linux_xen from running).

The 20_linux_xen is run under a shell and any exits from within it:

(For example on x86):
+ /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
[root@tst063 grub]# echo $?
1

will result in 20_linux_xen exciting without continuing
and also causing grub2-mkconfig to stop processing.

As in:

[root@tst063 ~]#

And no more.

This patch wraps the invocation of grub-file to be a in subshell
and to process the return value in a conditional. That fixes
the issue.

RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
CC: Fu Wei 
Signed-off-by: Konrad Rzeszutek Wilk 
---
 util/grub.d/20_linux_xen.in | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c002fc9..083bcef 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
 if [ "x$is_top_level" != xtrue ]; then
echo "  submenu '$(gettext_printf "Xen hypervisor, version %s" 
"${xen_version}" | grub_quote)' \$menuentry_id_option 
'xen-hypervisor-$xen_version-$boot_device_id' {"
 fi
-$grub_file --is-arm64-efi $current_xen
-if [ $? -ne 0 ]; then
-   xen_loader="multiboot"
-   module_loader="module"
-else
+if ($grub_file --is-arm64-efi $current_xen); then
xen_loader="xen_hypervisor"
module_loader="xen_module"
+else
+   xen_loader="multiboot"
+   module_loader="module"
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] Use grub-file to figure out whether multiboot2 should be used for Xen.gz

2017-08-28 Thread Konrad Rzeszutek Wilk 
The multiboot2 is much more preferable than multiboot. Especiall
if booting under EFI where multiboot does not have the functionality
to pass ImageHandler.

Signed-off-by: Konrad Rzeszutek Wilk 
---
v2: Rebase on top of  d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe
---
 util/grub.d/20_linux_xen.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 083bcef..29e015b 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -212,6 +212,10 @@ while [ "x${xen_list}" != "x" ] ; do
 else
xen_loader="multiboot"
module_loader="module"
+   if ($grub_file --is-x86-multiboot2 $current_xen); then
+   xen_loader="multiboot2"
+   module_loader="module2"
+   fi
 fi
 while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
-- 
2.1.4


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

[Xen-devel] [PATCH] Fix ARM multiboot2 breaking Fedora.

2017-08-28 Thread Konrad Rzeszutek Wilk 
Hey,

The first patch:
 [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command

is a fix discovered on Fedora rawhide where I was surprised to see that
grub2-mkconfig would not create a configuration file anymore.
See https://bugzilla.redhat.com/show_bug.cgi?id=1486002 for details.


The second patch has been posted in the past
(https://lists.xen.org/archives/html/xen-devel/2017-03/txtCeHTNmz1hZ.txt)

 [PATCH 2/2] Use grub-file to figure out whether multiboot2 should be

and just allows us to multiboot2 instead of multiboot if the binary
supports it.


 util/grub.d/20_linux_xen.in | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

Konrad Rzeszutek Wilk (2):
  Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
  Use grub-file to figure out whether multiboot2 should be used for Xen.gz


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

Re: [Xen-devel] [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu()

2017-08-28 Thread Dario Faggioli 
Il 28 Ago 2017 16:49, George Dunlap  ha scritto:
On 07/27/2017 01:05 PM, Dario Faggioli wrote:
> By, basically, moving all the logic of the function
> inside the usual two steps (soft-affinity step and
> hard-affinity step) loop.
>
> While there, add two performance counters (in cpu_pick
> and in get_fallback_cpu() itself), in order to be able
> to tell how frequently it happens that we need to look
> for a fallback cpu.
>
> Signed-off-by: Dario Faggioli 
> Signed-off-by: Justin T. Weaver 
> ---
> Cc: Anshul Makkar 
> Cc: George Dunlap 
> ---
> Changes from v1:
> - as discussed during review, only consider hard-affinity for the last stand.
>   The idea is not moving the vcpu to a diffrent runqueue because of
>   soft-affinity, as a part of finding a fallback cpu;
> - as discussed during review, added the performance counters;
> - BUG_ON(1) turned into ASSERT_UNREACHABLE(), as suggested during review;
> - return something same and random enough, at the end of the function (in
>   case we somehow manage to get there).
> ---
>  xen/common/sched_credit2.c   |  101 
> +-
>  xen/include/xen/perfc_defn.h |2 +
>  2 files changed, 82 insertions(+), 21 deletions(-)
>
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 57e77df..aa8f169 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -549,36 +549,93 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t 
> *mask)
>  }
>
>  /*
> - * When a hard affinity change occurs, we may not be able to check some
> - * (any!) of the other runqueues, when looking for the best new processor
> - * for svc (as trylock-s in csched2_cpu_pick() can fail). If that happens, we
> - * pick, in order of decreasing preference:
> - *  - svc's current pcpu;
> - *  - another pcpu from svc's current runq;
> - *  - any cpu.
> + * In csched2_cpu_pick(), it may not be possible to actually look at remote
> + * runqueues (the trylock-s on their spinlocks can fail!). If that happens,
> + * we pick, in order of decreasing preference:
> + *  1) svc's current pcpu, if it is part of svc's soft affinity;
> + *  2) a pcpu in svc's current runqueue that is also in svc's soft affinity;
> + *  3) svc's current pcpu, if it is part of svc's hard affinity;
> + *  4) a pcpu in svc's current runqueue that is also in svc's hard affinity;
> + *  5) just one valid pcpu from svc's hard affinity
> + *
> + * Of course, 1, 2 and 3 makes sense only if svc has a soft affinity. Also
> + * note that at least 6 is guaranteed to _always_ return at least one pcpu.

s/6/5/; ?

>   */
>  static int get_fallback_cpu(struct csched2_vcpu *svc)
>  {
>  struct vcpu *v = svc->vcpu;
> -int cpu = v->processor;
> +unsigned int bs;
>
> -cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> -cpupool_domain_cpumask(v->domain));
> +SCHED_STAT_CRANK(need_fallback_cpu);
>
> -if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> -return cpu;
> -
> -if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> -   >rqd->active)) )
> +for_each_affinity_balance_step( bs )
>  {
> -cpumask_and(cpumask_scratch_cpu(cpu), >rqd->active,
> -cpumask_scratch_cpu(cpu));
> -return cpumask_first(cpumask_scratch_cpu(cpu));
> -}
> +int cpu = v->processor;
>
> -ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
> +if ( bs == BALANCE_SOFT_AFFINITY &&
> + !has_soft_affinity(v, v->cpu_hard_affinity) )
> +continue;
>
> -return cpumask_first(cpumask_scratch_cpu(cpu));
> +affinity_balance_cpumask(v, bs, cpumask_scratch_cpu(cpu));
> +cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +cpupool_domain_cpumask(v->domain));
> +
> +/*
> + * This is cases 1 or 3 (depending on bs): if v->processor is (still)
> + * in our affinity, go for it, for cache betterness.
> + */
> +if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> +return cpu;
> +
> +/*
> + * This is cases 2 or 4 (depending on bs): v->processor isn't there
> + * any longer, check if we at least can stay in our current runq.
> + */
> +if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> +   >rqd->active)) )
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +>rqd->active);
> +return cpumask_first(cpumask_scratch_cpu(cpu));
> +}
> +
> +/*
> + * We may well pick any valid pcpu from our soft-affinity, outside
> + * of our current runqueue, but we decide not to. In fact, changing
> + * runqueue

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

2017-08-28 Thread osstest service owner 
flight 112904 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112904/

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-raw  4 host-install(4)  broken pass in 112897
 test-armhf-armhf-xl   7 xen-boot   fail pass in 112897

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-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112897 
blocked in 112102
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112897 
blocked in 112102
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 112897 like 112085
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 112897 like 
112102
 test-armhf-armhf-xl 13 migrate-support-check fail in 112897 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112897 never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 112897 never pass
 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-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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-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 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-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-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-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-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 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

[Xen-devel] [PATCH] xen/build: Nuke include/{config, generated} during clean

2017-08-28 Thread Andrew Cooper 
Otherwise a stale generated Kconfig may still be used after a tree-wide clean.

Signed-off-by: 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/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/Makefile b/xen/include/Makefile
index 3a6fa0f..ba36fe5 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -144,5 +144,5 @@ all: $(BASEDIR)/include/asm-x86/cpuid-autogen.h
 endif
 
 clean::
-   rm -rf compat headers*.chk
+   rm -rf compat headers*.chk config generated
rm -f $(BASEDIR)/include/asm-x86/cpuid-autogen.h
-- 
2.1.4


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

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

2017-08-28 Thread osstest service owner 
flight 112902 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112902/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
112809
 test-amd64-amd64-xl-qemut-win7-amd64 10 windows-install  fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install   fail REGR. vs. 112809
 test-amd64-i386-xl-qemut-win7-amd64 10 windows-install   fail REGR. vs. 112809

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt  6 xen-install  fail in 112893 pass in 112902
 test-armhf-armhf-libvirt-raw  7 xen-boot fail in 112893 pass in 112902
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 14 guest-localmigrate fail in 
112893 pass in 112902
 test-amd64-i386-examine   7 reboot   fail in 112896 pass in 112902
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 112896 pass in 112902
 test-amd64-amd64-xl-qcow2 7 xen-boot   fail pass in 112893
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail pass 
in 112893
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
112896
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 112896
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat  fail pass in 112896

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   2 hosts-allocate  broken like 112809
 build-arm64-xsm   2 hosts-allocate  broken like 112809
 build-arm64-xsm   3 capture-logsbroken like 112809
 build-arm64   3 capture-logsbroken like 112809
 build-arm64-pvops 2 hosts-allocate  broken like 112809
 build-arm64-pvops 3 capture-logsbroken like 112809
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112809
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112809
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112809
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112809
 test-armhf-armhf-libvirt-raw 13 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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-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-libvirt 13 migrate-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

Re: [Xen-devel] [PATCH v2 1/6] xen/tools: credit2: soft-affinity awareness in runq_tickle()

2017-08-28 Thread Dario Faggioli 
Il 28 Ago 2017 16:40, George Dunlap  ha scritto:
On 07/27/2017 01:05 PM, Dario Faggioli wrote:
> Soft-affinity support is usually implemented by means
> of a two step "balancing loop", where:
> - during the first step, we consider soft-affinity
>   (if the vcpu has one);
> - during the second (if we get to it), we consider
>   hard-affinity.
>
> In runq_tickle(), we need to do that for checking
> whether we can execute the waking vCPU on an pCPU
> that is idle. In fact, we want to be sure that, if
> there is an idle pCPU in the vCPU's soft affinity,
> we'll use it.
>
> If there are no such idle pCPUs, though, and we
> have to check non-idle ones, we can avoid the loop
> and to both hard and soft-affinity in one pass.
>
> In fact, we can we scan runqueue and compute a
> "score" for each vCPU which is running on each pCPU.
> The idea is, since we may have to preempt someone:
> - try to make sure that the waking vCPU will run
>   inside its soft-affinity,
> - try to preempt someone that is running outside
>   of its own soft-affinity.
>
> The value of the score is added to a trace record,
> so xenalyze's code and tools/xentrace/formats are
> updated accordingly.
>
> Suggested-by: George Dunlap 
> Signed-off-by: Dario Faggioli 
> Reviewed-by: George Dunlap 

The primary focus of this patch is credit2, so the title should probably
be xen/credit2, right?

It touches the tools (xenalyze), so I put tools in the rag, but I'm fine with 
just 'xen/credit2'.


I can change that on checkin.

Sure, go ahead.

Thanks, Dario

PS. Sorry for the (most likely) bad format of this email (semt from my phone)

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

[Xen-devel] [PATCH v1 0/2] Misc fixes regarding releasing resources on ARM

2017-08-28 Thread Oleksandr Tyshchenko 
From: Oleksandr Tyshchenko 

Oleksandr Tyshchenko (2):
  xen/arm: vgic: Check for vgic handler to be initialized before
dereferencing it
  xen/arm: p2m: Check for p2m->domain to be initialized before releasing
resources

 xen/arch/arm/p2m.c  | 13 -
 xen/arch/arm/vgic.c |  3 ++-
 2 files changed, 14 insertions(+), 2 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v1 1/2] xen/arm: vgic: Check for vgic handler to be initialized before dereferencing it

2017-08-28 Thread Oleksandr Tyshchenko 
From: Oleksandr Tyshchenko 

Since domain_vgic_free() can be called when the vgic_ops haven't been
initialised yet, always check that d->arch.vgic.handler is not a null.

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/vgic.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 7a4e3cd..6cf947c 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -187,7 +187,8 @@ void domain_vgic_free(struct domain *d)
 }
 }
 
-d->arch.vgic.handler->domain_free(d);
+if ( d->arch.vgic.handler )
+   d->arch.vgic.handler->domain_free(d);
 xfree(d->arch.vgic.shared_irqs);
 xfree(d->arch.vgic.pending_irqs);
 xfree(d->arch.vgic.allocated_irqs);
-- 
2.7.4


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

[Xen-devel] [PATCH v1 2/2] xen/arm: p2m: Check for p2m->domain to be initialized before releasing resources

2017-08-28 Thread Oleksandr Tyshchenko 
From: Oleksandr Tyshchenko 

Since p2m_teardown() can be called when p2m_init() haven't executed yet
we might deal with unitialized list "p2m->pages" which leads to crash.
To avoid this use back pointer to domain as end-of-initialization indicator.

Signed-off-by: Oleksandr Tyshchenko 
---
 xen/arch/arm/p2m.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index c484469..141ae7e 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1219,6 +1219,9 @@ void p2m_teardown(struct domain *d)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct page_info *pg;
 
+if ( !p2m->domain )
+return;
+
 while ( (pg = page_list_remove_head(>pages)) )
 free_domheap_page(pg);
 
@@ -1230,6 +1233,8 @@ void p2m_teardown(struct domain *d)
 p2m_free_vmid(d);
 
 radix_tree_destroy(>mem_access_settings, NULL);
+
+p2m->domain = NULL;
 }
 
 int p2m_init(struct domain *d)
@@ -1247,7 +1252,6 @@ int p2m_init(struct domain *d)
 if ( rc != 0 )
 return rc;
 
-p2m->domain = d;
 p2m->max_mapped_gfn = _gfn(0);
 p2m->lowest_mapped_gfn = _gfn(ULONG_MAX);
 
@@ -1276,6 +1280,13 @@ int p2m_init(struct domain *d)
 for_each_possible_cpu(cpu)
p2m->last_vcpu_ran[cpu] = INVALID_VCPU_ID;
 
+/*
+ * Besides getting a domain when we only have the p2m in hand,
+ * the back pointer to domain is also used in p2m_teardown()
+ * as an end-of-initialization indicator.
+ */
+p2m->domain = d;
+
 return rc;
 }
 
-- 
2.7.4


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

Re: [Xen-devel] [RFC PATCH v1 2/7] iommu/arm: ipmmu-vmsa: Add Xen changes for main driver

2017-08-28 Thread Oleksandr Tyshchenko 
Hi, Stefano, Julien.

On Fri, Aug 25, 2017 at 11:06 PM, Stefano Stabellini
 wrote:
> On Wed, 23 Aug 2017, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> On 21/08/17 16:53, Oleksandr Tyshchenko wrote:
>> > On Thu, Aug 10, 2017 at 6:13 PM, Julien Grall  wrote:
>> > > On 10/08/17 15:27, Oleksandr Tyshchenko wrote:
>> > > > I would like to clarify what need to be done from my side.
>> > > > Should I wait for the missing things reach upsteam and then rebase on
>> > > > the mainline driver?
>> > > > Or should I rewrite this driver without following Linux?
>> > >
>> > >
>> > > I don't have a clear answer here. As I said, we need to weight pros and
>> > > cons
>> > > to use Linux driver over our own.
>> > >
>> > > At the moment, you are using a BSP driver which has more features but
>> > > modified quite a lot. We don't even know when this is going to be merged
>> > > in
>> > > Linux.
>> > >
>> > > Keeping code close to Linux requires some hacks that are acceptable if 
>> > > you
>> > > can benefits from the community (bug fix, review...). As the driver is
>> > > taken
>> > > from the BSP, we don't know if the code will stay in the current form nor
>> > > be
>> > > able to get bug fix.
>> >
>> > I got it. Completely agree with you.
>> > But, we need to choose which direction we should follow. We have 3
>> > options at the moment
>> > and I am OK with each of them:
>> > 1. direct port from BSP (current implementation).
>> > 2. direct port from mainline Linux (when it has required support).
>> > 3. new driver based on BSP/Linux and contains only relevant to Xen things.
>> >
>> > I am starting to think that options 2 or 3 (+) would be more suitable.
>> > What do you think?
>>
>> The option 2 rely on the changes to be merged in Linux. If I understand
>> correctly, we don't have any timeline for this.
>>
>> So I would lean towards option 3 to get a support in Xen.
>>
>> Stefano, do you have any opinion?
>
> I agree with Julien. Option 3 is the way to go. There is only a benefit
> in staying close to Linux if their driver is in good state, fully
> featured, and well-maintained. And we certainly don't want to block your
> work on waiting for somebody else who might or might nor merge his
> changes in Linux. In this case, option 3 is best.
Thank you for your suggestions.

> I warn you, you might
> have to maintain this driver in Xen going forward though :-)
Why not :-)

-- 
Regards,

Oleksandr Tyshchenko

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

Re: [Xen-devel] [PATCH] libxl/arm: Fix build on arm64 + acpi

2017-08-28 Thread Wei Liu 
On Fri, Aug 25, 2017 at 05:35:47PM -0400, Daniel Sabogal wrote:
> With musl, the build fails with the following errors:
> 
>   actypes.h:202:2: error: #error unknown ACPI_MACHINE_WIDTH
>#error unknown ACPI_MACHINE_WIDTH
> ^
>   actypes.h:207:9: error: unknown type name ‘acpi_native_uint’
>typedef acpi_native_uint acpi_size;
>^~~~
>   actypes.h:617:3: error: unknown type name ‘acpi_io_address’
>  acpi_io_address pblk_address;
>  ^~~
> 
> This likely went undetected with glibc builds since glibc
> indirectly pulls __BITS_PER_LONG from the linux headers
> through a standard header. For musl, this is not the case.
> 
> Instead, use BITS_PER_LONG to fix the build.
> 
> Signed-off-by: Daniel Sabogal 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH RFC 00/12] Nested p2m: allow sharing between vCPUs

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> Nested p2m (shadow EPT) is an object that stores memory address
> translations from L2 GPA directly to L0 HPA. This is achieved by
> combining together L1 EPT tables with L0 EPT during L2 EPT violations.
> 
> In the usual case, L1 uses the same EPTP value in VMCS12 for all vCPUs
> of a L2 guest. But unfortunately, in current Xen's implementation, each
> vCPU has its own n2pm object which cannot be shared with other vCPUs.
> This leads to the following issues if a nested guest has SMP:
> 
> 1. There will be multiple np2m objects (1 per nested vCPU) with
>the same np2m_base (L1 EPTP value in VMCS12).
> 
> 2. Same EPT violations will be processed independently by each vCPU.
> 
> 3. Since MAX_NESTEDP2M is defined as 10, if a domain has more than
>10 nested vCPUs, performance will be extremely degraded due to
>constant np2m LRU list thrashing and np2m flushing.
> 
> This patch series makes it possible to share one np2m object between
> different vCPUs that have the same np2m_base. Sharing of np2m objects
> improves scalability of a domain from 10 nested vCPUs to 10 nested
> guests (with arbitrary number of vCPUs per guest).

On the whole this looks like a decent approach.

Were you planning on re-sending it with the RFC removed, or would you
like me to do a detailed review of this series as it is?

 -George

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

Re: [Xen-devel] [PATCH RFC 10/12] x86/np2m: implement sharing of np2m between vCPUs

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> Modify p2m_get_nestedp2m() to allow sharing a np2m between multiple
> vcpus with the same np2m_base (L1 EPTP value in VMCS12).
> 
> np2m_schedule_in/out() callbacks are added to context_switch() as well
> as pseudo schedule-out is performed during virtual_vmexit().
> 
> Signed-off-by: Sergey Dyasli 
> ---
>  xen/arch/x86/domain.c   |  2 ++
>  xen/arch/x86/hvm/vmx/vvmx.c |  4 
>  xen/arch/x86/mm/p2m.c   | 29 +++--
>  3 files changed, 33 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index dd8bf1302f..38c86a5ded 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -1642,6 +1642,7 @@ void context_switch(struct vcpu *prev, struct vcpu 
> *next)
>  {
>  _update_runstate_area(prev);
>  vpmu_switch_from(prev);
> +np2m_schedule_out();
>  }
>  
>  if ( is_hvm_domain(prevd) && !list_empty(>arch.hvm_vcpu.tm_list) )
> @@ -1690,6 +1691,7 @@ void context_switch(struct vcpu *prev, struct vcpu 
> *next)
>  
>  /* Must be done with interrupts enabled */
>  vpmu_switch_to(next);
> +np2m_schedule_in();
>  }
>  
>  /* Ensure that the vcpu has an up-to-date time base. */
> diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
> index 7b193767cd..2203d541ea 100644
> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1187,6 +1187,7 @@ static void virtual_vmentry(struct cpu_user_regs *regs)
>  
>  /* Setup virtual ETP for L2 guest*/
>  if ( nestedhvm_paging_mode_hap(v) )
> +/* This will setup the initial np2m for the nested vCPU */
>  __vmwrite(EPT_POINTER, get_shadow_eptp(v));
>  else
>  __vmwrite(EPT_POINTER, get_host_eptp(v));
> @@ -1353,6 +1354,9 @@ static void virtual_vmexit(struct cpu_user_regs *regs)
>   !(v->arch.hvm_vcpu.guest_efer & EFER_LMA) )
>  shadow_to_vvmcs_bulk(v, ARRAY_SIZE(gpdpte_fields), gpdpte_fields);
>  
> +/* This will clear current pCPU bit in p2m->dirty_cpumask */
> +np2m_schedule_out();
> +
>  vmx_vmcs_switch(v->arch.hvm_vmx.vmcs_pa, nvcpu->nv_n1vmcx_pa);
>  
>  nestedhvm_vcpu_exit_guestmode(v);
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 364fdd8c13..480459ae51 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1830,6 +1830,7 @@ p2m_get_nestedp2m_locked(struct vcpu *v)
>  struct domain *d = v->domain;
>  struct p2m_domain *p2m;
>  uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
> +unsigned int i;
>  
>  /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */
>  np2m_base &= ~(0xfffull);
> @@ -1843,10 +1844,34 @@ p2m_get_nestedp2m_locked(struct vcpu *v)
>  if ( p2m ) 
>  {
>  p2m_lock(p2m);
> -if ( p2m->np2m_base == np2m_base || p2m->np2m_base == P2M_BASE_EADDR 
> )
> +if ( p2m->np2m_base == np2m_base )
>  {
> -if ( p2m->np2m_base == P2M_BASE_EADDR )
> +/* Check if np2m was flushed just before the lock */
> +if ( nv->np2m_generation != p2m->np2m_generation )
>  nvcpu_flush(v);
> +/* np2m is up-to-date */
> +p2m->np2m_base = np2m_base;
> +assign_np2m(v, p2m);
> +nestedp2m_unlock(d);

This function now has three copies of the above four lines.  What about
folding in something like the attached?

 -George
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 480459ae51..5804a8819b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1831,6 +1831,7 @@ p2m_get_nestedp2m_locked(struct vcpu *v)
 struct p2m_domain *p2m;
 uint64_t np2m_base = nhvm_vcpu_p2m_base(v);
 unsigned int i;
+bool vcpu_flush = true;
 
 /* Mask out low bits; this avoids collisions with P2M_BASE_EADDR */
 np2m_base &= ~(0xfffull);
@@ -1847,14 +1848,9 @@ p2m_get_nestedp2m_locked(struct vcpu *v)
 if ( p2m->np2m_base == np2m_base )
 {
 /* Check if np2m was flushed just before the lock */
-if ( nv->np2m_generation != p2m->np2m_generation )
-nvcpu_flush(v);
-/* np2m is up-to-date */
-p2m->np2m_base = np2m_base;
-assign_np2m(v, p2m);
-nestedp2m_unlock(d);
-
-return p2m;
+if ( nv->np2m_generation == p2m->np2m_generation )
+needs_flush = false;
+goto found;
 }
 else if ( p2m->np2m_base != P2M_BASE_EADDR )
 {
@@ -1869,15 +1865,10 @@ p2m_get_nestedp2m_locked(struct vcpu *v)
 {
 p2m = d->arch.nested_p2m[i];
 p2m_lock(p2m);
+
 if ( p2m->np2m_base == np2m_base )
-{
-nvcpu_flush(v);
-p2m->np2m_base = np2m_base;
-assign_np2m(v, p2m);
-nestedp2m_unlock(d);
+goto found;
 
-

Re: [Xen-devel] [PATCH 06/27 v8] xen/arm: vpl011: Add a new domctl API to initialize vpl011

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 02:25:49PM +0530, Bhupinder Thakur wrote:
> Add a new domctl API to initialize vpl011. It takes the GFN and console
> backend domid as input and returns an event channel to be used for
> sending and receiving events from Xen.
> 
> Xen will communicate with xenconsole using GFN as the ring buffer and
> the event channel to transmit and receive pl011 data on the guest domain's
> behalf.
> 
> Signed-off-by: Bhupinder Thakur 

Given this is the only patch in this series that is unacked, you can
just resend this one after addressing the comments (assuming later
patches won't need to change).

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

Re: [Xen-devel] [PATCH 21/27 v8] xen/arm: vpl011: Add support for multiple consoles in xenconsole

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 02:26:04PM +0530, Bhupinder Thakur wrote:
> This patch adds the support for multiple consoles and introduces the
> iterator functions to operate on multiple consoles.
> 
> The functions called by the iterators check that they are operating
> on valid I/O parameters. This ensures that if a particular console is
> not initialized then the functions will not do anything for that
> console type.
> 
> This patch is in preparation to support a new vuart console.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH RFC 07/12] x86/np2m: add np2m_schedule_in/out()

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> np2m maintenance is required for a nested vcpu during scheduling:
> 
> 1. On schedule-out: clear pCPU's bit in p2m->dirty_cpumask
> to prevent useless IPIs.
> 
> 2. On schedule-in: check if np2m is up to date and wasn't flushed.
> 
> Signed-off-by: Sergey Dyasli 
> ---
>  xen/arch/x86/mm/p2m.c | 52 
> +++
>  xen/include/asm-x86/p2m.h |  3 +++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 3d65899b05..4b83d4a4f1 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1880,6 +1880,58 @@ p2m_get_p2m(struct vcpu *v)
>  return p2m_get_nestedp2m(v);
>  }
>  
> +static void np2m_schedule(bool sched_out)
> +{
> +struct nestedvcpu *nv = _nestedhvm(current);
> +struct p2m_domain *p2m;
> +bool sched_in = !sched_out;
> +
> +if ( !nestedhvm_enabled(current->domain) ||
> + !nestedhvm_vcpu_in_guestmode(current) ||
> + !nestedhvm_paging_mode_hap(current) )
> +return;
> +
> +p2m = nv->nv_p2m;
> +if ( p2m )
> +{
> +bool np2m_valid;
> +
> +p2m_lock(p2m);
> +np2m_valid = p2m->np2m_base == nhvm_vcpu_p2m_base(current) &&
> + nv->np2m_generation == p2m->np2m_generation;
> +if ( sched_out && np2m_valid )
> +{
> +/*
> + * The np2m is up to date but this vCPU will no longer use it,
> + * which means there are no reasons to send a flush IPI.
> + */
> +cpumask_clear_cpu(current->processor, p2m->dirty_cpumask);
> +}
> +else if ( sched_in )
> +{
> +if ( !np2m_valid )
> +{
> +/* This vCPU's np2m was flushed while it was not runnable */
> +hvm_asid_flush_core();
> +vcpu_nestedhvm(current).nv_p2m = NULL;
> +}
> +else
> +cpumask_set_cpu(current->processor, p2m->dirty_cpumask);
> +}
> +p2m_unlock(p2m);
> +}
> +}

This level of sharing seems a tad excessive to me; but if we're going to
do it, I think it would be more clear if the callers called a function
called np2m_schedule() with `dir`, then define things something like this:

#define NP2M_SCHEDLE_IN  0
#define NP2M_SCHEDLE_OUT 1

 -George

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

Re: [Xen-devel] [PATCH 11/27 v8] xen/arm: vpl011: Add a new console_init function in xenconsole

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 02:25:54PM +0530, Bhupinder Thakur wrote:
> This patch introduces a new console_init function. This function
> initializes the console structure.
> 
> Signed-off-by: Bhupinder Thakur 

It appears that you forgot to collect my ack:

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 06/27 v8] xen/arm: vpl011: Add a new domctl API to initialize vpl011

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 02:25:49PM +0530, Bhupinder Thakur wrote:
> Add a new domctl API to initialize vpl011. It takes the GFN and console
> backend domid as input and returns an event channel to be used for
> sending and receiving events from Xen.
> 
> Xen will communicate with xenconsole using GFN as the ring buffer and
> the event channel to transmit and receive pl011 data on the guest domain's
> behalf.
> 
> Signed-off-by: Bhupinder Thakur 
[...]
> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> index d842d88..b8147f0 100644
> --- a/tools/libxl/libxl_arm.c
> +++ b/tools/libxl/libxl_arm.c
> @@ -1038,6 +1038,28 @@ int 
> libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>  return 0;
>  }
>  
> +int libxl__arch_build_dom_finish(libxl__gc *gc,
> + libxl_domain_build_info *info,
> + struct xc_dom_image *dom,
> + libxl__domain_build_state *state)
> +{
> +int rc = 0;

int rc, ret;

> +
> +if (info->arch_arm.vuart != LIBXL_VUART_TYPE_SBSA_UART)
> +return rc;

if ( ... ) {
rc = 0;
goto out;
}

> +
> +rc = xc_dom_vuart_init(CTX->xch,
> +   XEN_DOMCTL_VUART_TYPE_VPL011,
> +   dom->guest_domid,
> +   dom->console_domid,
> +   dom->vuart_gfn,
> +   >vuart_port);

ret = xc_dom_vuart_init(...);

if (ret < 0) {
rc = ERROR_FAIL;
goto out;
}

> +if (rc < 0)
> +LOG(ERROR, "xc_dom_vuart_init failed\n");

out:

> +
> +return rc;
> +}
> +

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

Re: [Xen-devel] [PATCH RFC 06/12] x86/vvmx: add stale_eptp flag

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> The new variable will indicate if update of a shadow EPTP is needed

*element

> prior to vmentry. Update is required if a nested vcpu gets a new np2m
> or if its np2m was flushed by an IPI.
> 
> Helper function nvcpu_flush() is added.

Passive voice in this situation is to be avoided. :-)

We normally say something like, "Add nvcpu_flush() helper function."

> Signed-off-by: Sergey Dyasli 
> ---
>  xen/arch/x86/hvm/nestedhvm.c   |  1 +
>  xen/arch/x86/hvm/vmx/entry.S   |  6 ++
>  xen/arch/x86/hvm/vmx/vmx.c |  8 +++-
>  xen/arch/x86/hvm/vmx/vvmx.c| 15 +++
>  xen/arch/x86/mm/p2m.c  | 10 --
>  xen/include/asm-x86/hvm/vmx/vvmx.h |  2 ++
>  6 files changed, 39 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/nestedhvm.c b/xen/arch/x86/hvm/nestedhvm.c
> index 32b8acca6a..e9b1d8e628 100644
> --- a/xen/arch/x86/hvm/nestedhvm.c
> +++ b/xen/arch/x86/hvm/nestedhvm.c
> @@ -108,6 +108,7 @@ nestedhvm_flushtlb_ipi(void *info)
>   */
>  hvm_asid_flush_core();
>  vcpu_nestedhvm(v).nv_p2m = NULL;
> +vcpu_2_nvmx(v).stale_eptp = true;

Looks like a vmx-specific function in common code?

 -George


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

Re: [Xen-devel] [PATCH RFC 05/12] x86/np2m: add np2m_generation

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> Add np2m_generation variable to both p2m_domain and nestedvcpu.

s/variable/element;

BTW still trying to get a feel for the whole series.  Patches w/o
comments (or with minor comments like this) look plausible but I won't
know what I think of the whole series until the end.

 -George

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

Re: [Xen-devel] [PATCH RFC 02/12] x86/np2m: add np2m_flush_eptp()

2017-08-28 Thread George Dunlap 
On 07/18/2017 11:34 AM, Sergey Dyasli wrote:
> The new function finds all np2m objects with the specified eptp and
> flushes them. p2m_flush_table_locked() is added in order not to release
> the p2m lock after np2m_base check.
> 
> Signed-off-by: Sergey Dyasli 

This patch looks plausible except for...

> ---
>  xen/arch/x86/mm/p2m.c | 34 +++---
>  xen/include/asm-x86/p2m.h |  2 ++
>  2 files changed, 33 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index b8c8bba421..bc330d8f52 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1708,15 +1708,14 @@ p2m_getlru_nestedp2m(struct domain *d, struct 
> p2m_domain *p2m)
>  return p2m;
>  }
>  
> -/* Reset this p2m table to be empty */
>  static void
> -p2m_flush_table(struct p2m_domain *p2m)
> +p2m_flush_table_locked(struct p2m_domain *p2m)
>  {
>  struct page_info *top, *pg;
>  struct domain *d = p2m->domain;
>  mfn_t mfn;
>  
> -p2m_lock(p2m);
> +ASSERT(p2m_locked_by_me(p2m));
>  
>  /*
>   * "Host" p2m tables can have shared entries  that need a bit more care
> @@ -1756,6 +1755,14 @@ p2m_flush_table(struct p2m_domain *p2m)
>  p2m_unlock(p2m);

...this.  Why on earth would we unlock this at the end of the function,
instead of letting the caller do it?

If we were to do that, at very least it should be called
"p2m_flush_and_unlock_table()".  But I think we just want to leave the
unlock out, because...

>  }
>  
> +/* Reset this p2m table to be empty */
> +static void
> +p2m_flush_table(struct p2m_domain *p2m)
> +{
> +p2m_lock(p2m);
> +p2m_flush_table_locked(p2m);

..this looks wrong -- a balanced lock/unlock is easier to verify, and...

> +}
> +
>  void
>  p2m_flush(struct vcpu *v, struct p2m_domain *p2m)
>  {
> @@ -1773,6 +1780,27 @@ p2m_flush_nestedp2m(struct domain *d)
>  p2m_flush_table(d->arch.nested_p2m[i]);
>  }
>  
> +void np2m_flush_eptp(struct vcpu *v, unsigned long eptp)
> +{
> +struct domain *d = v->domain;
> +struct p2m_domain *p2m;
> +unsigned int i;
> +
> +eptp &= ~(0xfffull);
> +
> +nestedp2m_lock(d);
> +for ( i = 0; i < MAX_NESTEDP2M; i++ )
> +{
> +p2m = d->arch.nested_p2m[i];
> +p2m_lock(p2m);
> +if ( p2m->np2m_base == eptp )
> +p2m_flush_table_locked(p2m);
> +else
> +p2m_unlock(p2m);

...here we have essentially a pointless 'else'.  Lock/unlock around the
whole conditional would make much more sense.

 -George

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

Re: [Xen-devel] [PATCH] xen: fix boolean parameter handling

2017-08-28 Thread Andrew Cooper 
On 28/08/17 16:02, Jan Beulich wrote:
 On 28.08.17 at 16:49,  wrote:
>> Commit 63e8a1e5ffa7a7fdbde887805f673fea7e8d2e94 ("xen: check parameter
>> validity when parsing command line") introduced a bug for the case
>> when a boolean parameter was specified by its keyword only (no value).
>> It would set just the wrong boolean value for that parameter.
>>
>> Signed-off-by: Juergen Gross 
> Acked-by: Jan Beulich 
>
>

Reviewed, tested and queued.  Thanks.

~Andrew

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

Re: [Xen-devel] [PATCH v8] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Tamas K Lengyel 
On Mon, Aug 28, 2017 at 7:29 AM, Jan Beulich  wrote:
 On 28.08.17 at 14:51,  wrote:
>> --- a/xen/include/asm-arm/monitor.h
>> +++ b/xen/include/asm-arm/monitor.h
>> @@ -26,6 +26,12 @@
>>  #include 
>>
>>  static inline
>> +void arch_allow_userspace(struct domain *d, uint8_t allow_userspace)
>> +{
>> +return;
>> +}
>
> I'm sorry for noticing this only now, but the name of the hook really
> ought to have vm_event or monitor in it - it's way too generic the
> way it is now.
>

+1 I've just stated that too on apparently the previous version of the patch =)

Tamas

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

Re: [Xen-devel] [PATCH v7] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Tamas K Lengyel 
On Mon, Aug 28, 2017 at 5:10 AM, Jan Beulich  wrote:
 On 28.08.17 at 11:38,  wrote:
>> In some introspection usecases, an in-guest agent needs to communicate
>> with the external introspection agent.  An existing mechanism is
>> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
>> like all other hypercalls.
>>
>> Introduce a mechanism whereby the introspection agent can whitelist the
>> use of HVMOP_guest_request_vm_event directly from userspace.
>>
>> Signed-off-by: Alexandru Isaila 
>
> For the parts it is applicable to:
> Acked-by: Jan Beulich 
>
> I'd like to note though that I find it a little odd for >arch to be
> passed to a hook, instead of just d. But it'll be the maintainers of
> that code to approve (or not) of that.
>

Indeed, I don't see d->arch being passed like this anywhere else
either. I don't think it breaks anything but for stylistic reasons it
might be better to conform here too.

Tamas

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

Re: [Xen-devel] [PATCH v7] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Tamas K Lengyel 
> diff --git a/xen/common/monitor.c b/xen/common/monitor.c
> index 451f42f..0c3e645 100644
> --- a/xen/common/monitor.c
> +++ b/xen/common/monitor.c
> @@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct 
> xen_domctl_monitor_op *mop)
>  domain_pause(d);
>  d->monitor.guest_request_sync = mop->u.guest_request.sync;
>  d->monitor.guest_request_enabled = requested_status;
> +arch_allow_userspace(>arch, mop->u.guest_request.allow_userspace);

Please use the appropriate prefix with this function, ie.
arch_monitor_allow_userspace.

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 16:35,  wrote:
> On 08/28/2017 03:38 AM, Jan Beulich wrote:
>>
 And finally I continue to be not really happy about the change as
 a whole. Despite what was discussed on v1, I'm concerned of the
 effects of this on hosts _not_ suffering from vector shortage.
 Could you live with the new behavior requiring a command line
 option to enable?
>>> I can add something like 'apic_share_vectors', defaulting to true,
>>> although it will not be useful in case of a hotplug. Defaulting to false?
>> Along the lines of the above plus our desire to limit the number
>> of top level options, how about "apic=isolate-vectors"?
>>
>> Also I don't understand your reference to hotplug, nor why you
>> suggest two opposite default values.
> 
> Not two, just one --- not share vectors by default.
> 
> As for hotplug, I was thinking of a case where a system is successfully
> booted with shared vectors but then a device is added and we fail to
> find enough free vectors. So the administrator would need to know in
> advance whether a new card might be coming in.
> 
> When defaulting to false (as in apic_share_vectors=false) if the
> administrator decides to set it to true then he would be in some sense
> explicitly agreeing to never plug anything in (or at least to tolerate
> such a failure).

Ah, I see. But imo the default ought to be current behavior.

>> But finally, you agreeing to a command line option here makes
>> me come back to an earlier suggestion: Didn't we agree that
>> "x2apic_phys" would be sufficient to eliminate the issue? In which
>> case no patch would be needed at all.
> 
> x2apic_phys means that we never share vectors. With 'isolate-vectors'
> option we are still able to share them if the mask is explicitly specified.

Well, aiui your primary goal is to address the vector shortage. For
that you don't need the new option, you can get away with the
existing one.

Jan


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

Re: [Xen-devel] [PATCH v3] passthrough: give XEN_DOMCTL_test_assign_device more sane semantics (and 1 more message)

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 01:27:46AM -0600, Jan Beulich wrote:
> >>> On 25.08.17 at 18:05,  wrote:
> > On Fri, Aug 25, 2017 at 09:54:18AM -0600, Jan Beulich wrote:
> >> >>> On 25.08.17 at 17:25,  wrote:
> >> > On Wed, Aug 16, 2017 at 06:20:01AM -0600, Jan Beulich wrote:
> >> >> So far callers of the libxc interface passed in a domain ID which was
> >> >> then ignored in the hypervisor. Instead, make the hypervisor honor it
> >> >> (accepting DOMID_INVALID to obtain original behavior), allowing to
> >> >> query whether a device can be assigned to a particular domain.
> >> >> 
> >> >> Drop XSM's test_assign_{,dt}device hooks as no longer being
> >> >> individually useful.
> >> > 
> >> > Can you also say in the commit message that you consolidate some code as
> >> > well?
> >> 
> >> Am I consolidating code beyond what is reasonable to achieve
> >> the intended effect? I don't view the merging of the two case
> >> blocks 
> >> Oops, didn't finish here: "... as anything going beyond the main   
> >>   
> > 
> >   
> >
> >> purpose of the patch. In fact if someone submitted a patch 
> >>   
> > 
> >   
> >
> >> without doing that folding, I'd ask for it to be done."  
> > 
> > It took more effort for reviewers to figure out the reason to delete
> > those two blocks just from looking at the diff, which distracted me a
> > bit. Of course I eventually figured out why they were deleted by looking
> > at the actual files, but had that been stated in commit message I could
> > have finished the review sooner because I would have a list of things to
> > look for in my mind and go through them faster.
> 
> Okay, I've added "Do this by folding the assign and test-assign paths"
> to the first paragraph. I hope that's enough to address your concern.
> 

Thanks, that sounds good.

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

Re: [Xen-devel] [PATCH v7] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 12:38:46PM +0300, Alexandru Isaila wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
> 
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
> 
> Signed-off-by: Alexandru Isaila 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/mm: Drop is_guest_l3_slot() and simply callers

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 03:50:59PM +0100, Andrew Cooper wrote:
> With a 64bit hypervisor there are no conditional l3 slots, and this is
> unlikely to change moving forwards.
> 
> No functional change (as confirmed by diffing the disassembly.  GCC obviously
> already optimised this code away.)
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

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

2017-08-28 Thread Boris Ostrovsky 
On 08/28/2017 10:52 AM, Jan Beulich wrote:
 On 28.08.17 at 16:24,  wrote:
 As for periodically testing process_pending_softirqs() we may still want
 to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.
>>> For my taste, alloc_heap_pages() is the wrong place for such
>>> calls.
>> But the loop is in alloc_heap_pages() --- where else would you be testing?
> It can only reasonably be the callers of alloc_heap_pages() imo.
> A single call to it should never trigger the watchdog, 

check_one_page() is rather slow so for a large order allocation even
with clean heap the 'for' loop may take quite some time. Whether it
could trip the watchdog -- I don't know.

-boris

> only calls
> themselves sitting in a loop should be potential candidates for
> causing such.


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

Re: [Xen-devel] [PATCH v4] common/vm_event: Initialize vm_event lists on domain creation

2017-08-28 Thread Tamas K Lengyel 
On Mon, Aug 28, 2017 at 4:54 AM, Alexandru Isaila
 wrote:
> The patch splits the vm_event into three structures:vm_event_share,
> vm_event_paging, vm_event_monitor. The allocation for the
> structure is moved to vm_event_enable so that it can be
> allocated/init when needed and freed in vm_event_disable.
>
> Signed-off-by: Alexandru Isaila 
>
> ---
> Changes since V3:
> - Moved the d->vm_event_paging to the if below in the
> assign_device function
>
> Note: Did not test on arm, compliled on arm and x86.
> ---
>  xen/arch/arm/mem_access.c |   2 +-
>  xen/arch/x86/mm/mem_access.c  |   2 +-
>  xen/arch/x86/mm/mem_paging.c  |   2 +-
>  xen/arch/x86/mm/mem_sharing.c |   4 +-
>  xen/arch/x86/mm/p2m.c |  10 +--
>  xen/common/domain.c   |  13 ++--
>  xen/common/mem_access.c   |   2 +-
>  xen/common/monitor.c  |   4 +-
>  xen/common/vm_event.c | 156 
> +-
>  xen/drivers/passthrough/pci.c |   2 +-
>  xen/include/xen/sched.h   |  18 ++---
>  11 files changed, 124 insertions(+), 91 deletions(-)
>
> diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
> index e0888bb..a7f0cae 100644
> --- a/xen/arch/arm/mem_access.c
> +++ b/xen/arch/arm/mem_access.c
> @@ -256,7 +256,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, 
> const struct npfec npfec)
>  }
>
>  /* Otherwise, check if there is a vm_event monitor subscriber */
> -if ( !vm_event_check_ring(>domain->vm_event->monitor) )
> +if ( !vm_event_check_ring(v->domain->vm_event_monitor) )
>  {
>  /* No listener */
>  if ( p2m->access_required )
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index 5adaf6d..414e38f 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -179,7 +179,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
> gla,
>  gfn_unlock(p2m, gfn, 0);
>
>  /* Otherwise, check if there is a memory event listener, and send the 
> message along */
> -if ( !vm_event_check_ring(>vm_event->monitor) || !req_ptr )
> +if ( !vm_event_check_ring(d->vm_event_monitor) || !req_ptr )
>  {
>  /* No listener */
>  if ( p2m->access_required )
> diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
> index a049e0d..20214ac 100644
> --- a/xen/arch/x86/mm/mem_paging.c
> +++ b/xen/arch/x86/mm/mem_paging.c
> @@ -43,7 +43,7 @@ int 
> mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
>  goto out;
>
>  rc = -ENODEV;
> -if ( unlikely(!d->vm_event->paging.ring_page) )
> +if ( !d->vm_event_paging || unlikely(!d->vm_event_paging->ring_page) )

So you are adding an extra NULL check here for d->vm_event_paging.
Perhaps now we should have that NULL check used in all cases by adding
it to vm_event_check_ring and we should use that across all cases..

> diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c
> index 19f63bb..10ea4ae 100644
> --- a/xen/common/mem_access.c
> +++ b/xen/common/mem_access.c
> @@ -52,7 +52,7 @@ int mem_access_memop(unsigned long cmd,
>  goto out;
>
>  rc = -ENODEV;
> -if ( unlikely(!d->vm_event->monitor.ring_page) )
> +if ( !d->vm_event_monitor || unlikely(!d->vm_event_monitor->ring_page) )

... like here ^ ...

> @@ -187,41 +194,44 @@ void vm_event_wake(struct domain *d, struct 
> vm_event_domain *ved)
>  vm_event_wake_blocked(d, ved);
>  }
>
> -static int vm_event_disable(struct domain *d, struct vm_event_domain *ved)
> +static int vm_event_disable(struct domain *d, struct vm_event_domain **ved)
>  {
> -if ( ved->ring_page )
> +if ( *ved && (*ved)->ring_page )

... and here ^ ...


> @@ -267,6 +277,9 @@ void vm_event_put_request(struct domain *d,
>  RING_IDX req_prod;
>  struct vcpu *curr = current;
>
> +if( !ved )

... and here ^ ...

> +return;
> +
>  if ( curr->domain != d )
>  {
>  req->flags |= VM_EVENT_FLAG_FOREIGN;
> @@ -434,6 +447,9 @@ void vm_event_resume(struct domain *d, struct 
> vm_event_domain *ved)
>
>  void vm_event_cancel_slot(struct domain *d, struct vm_event_domain *ved)
>  {
> +if( !ved )

... and here ^ ...

> +return;
> +
>  vm_event_ring_lock(ved);
>  vm_event_release_slot(d, ved);
>  vm_event_ring_unlock(ved);
> @@ -500,6 +516,9 @@ bool_t vm_event_check_ring(struct vm_event_domain *ved)
>  int __vm_event_claim_slot(struct domain *d, struct vm_event_domain *ved,
>bool_t allow_sleep)
>  {
> +if ( !ved )

... and here ^ ...

> +return -EOPNOTSUPP;
> +
>  if ( (current->domain == d) && allow_sleep )
>  return vm_event_wait_slot(ved);
>  else
> @@ -510,24 +529,30 @@ int __vm_event_claim_slot(struct domain *d, struct 
> vm_event_domain *ved,
>  /* Registered with Xen-bound event channel for incoming notifications. */
>  static

Re: [Xen-devel] [PATCH v3 02/21] x86/mm: carve out replace_grant_pv_mapping

2017-08-28 Thread George Dunlap 
On 07/20/2017 05:04 PM, Wei Liu wrote:
> And at once make it an inline function. Add declarations of

at the same time

Other than that:

Acked-by: George Dunlap 

> replace_grant_{hvm,pv}_mapping to respective header files.
> 
> The code movement will be done later.
> 
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/mm.c |  9 +++--
>  xen/include/asm-x86/grant_table.h | 10 --
>  xen/include/asm-x86/hvm/grant_table.h |  8 
>  xen/include/asm-x86/pv/grant_table.h  |  8 
>  4 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index 532b1ee7e7..defc2c9bcc 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4296,7 +4296,7 @@ int create_grant_pv_mapping(uint64_t addr, unsigned 
> long frame,
>  return create_grant_va_mapping(addr, pte, current);
>  }
>  
> -static int replace_grant_p2m_mapping(
> +int replace_grant_p2m_mapping(
>  uint64_t addr, unsigned long frame, uint64_t new_addr, unsigned int 
> flags)
>  {
>  unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
> @@ -4326,8 +4326,8 @@ static int replace_grant_p2m_mapping(
>  return GNTST_okay;
>  }
>  
> -int replace_grant_host_mapping(
> -uint64_t addr, unsigned long frame, uint64_t new_addr, unsigned int 
> flags)
> +int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
> + uint64_t new_addr, unsigned int flags)
>  {
>  struct vcpu *curr = current;
>  l1_pgentry_t *pl1e, ol1e;
> @@ -4335,9 +4335,6 @@ int replace_grant_host_mapping(
>  struct page_info *l1pg;
>  int rc;
>  
> -if ( paging_mode_external(current->domain) )
> -return replace_grant_p2m_mapping(addr, frame, new_addr, flags);
> -
>  if ( flags & GNTMAP_contains_pte )
>  {
>  if ( !new_addr )
> diff --git a/xen/include/asm-x86/grant_table.h 
> b/xen/include/asm-x86/grant_table.h
> index 4aa22126d3..6c98672a4d 100644
> --- a/xen/include/asm-x86/grant_table.h
> +++ b/xen/include/asm-x86/grant_table.h
> @@ -27,8 +27,14 @@ static inline int create_grant_host_mapping(uint64_t addr, 
> unsigned long frame,
>  return create_grant_pv_mapping(addr, frame, flags, cache_flags);
>  }
>  
> -int replace_grant_host_mapping(
> -uint64_t addr, unsigned long frame, uint64_t new_addr, unsigned int 
> flags);
> +static inline int replace_grant_host_mapping(uint64_t addr, unsigned long 
> frame,
> + uint64_t new_addr,
> + unsigned int flags)
> +{
> +if ( paging_mode_external(current->domain) )
> +return replace_grant_p2m_mapping(addr, frame, new_addr, flags);
> +return replace_grant_pv_mapping(addr, frame, new_addr, flags);
> +}
>  
>  #define gnttab_create_shared_page(d, t, i)   \
>  do { \
> diff --git a/xen/include/asm-x86/hvm/grant_table.h 
> b/xen/include/asm-x86/hvm/grant_table.h
> index 83202c219c..4b1afa179b 100644
> --- a/xen/include/asm-x86/hvm/grant_table.h
> +++ b/xen/include/asm-x86/hvm/grant_table.h
> @@ -26,6 +26,8 @@
>  int create_grant_p2m_mapping(uint64_t addr, unsigned long frame,
>   unsigned int flags,
>   unsigned int cache_flags);
> +int replace_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> +  uint64_t new_addr, unsigned int flags);
>  
>  #else
>  
> @@ -38,6 +40,12 @@ static inline int create_grant_p2m_mapping(uint64_t addr, 
> unsigned long frame,
>  return GNTST_general_error;
>  }
>  
> +int replace_grant_p2m_mapping(uint64_t addr, unsigned long frame,
> +  uint64_t new_addr, unsigned int flags)
> +{
> +return GNTST_general_error;
> +}
> +
>  #endif
>  
>  #endif /* __X86_HVM_GRANT_TABLE_H__ */
> diff --git a/xen/include/asm-x86/pv/grant_table.h 
> b/xen/include/asm-x86/pv/grant_table.h
> index 165ebce22f..c6474973cd 100644
> --- a/xen/include/asm-x86/pv/grant_table.h
> +++ b/xen/include/asm-x86/pv/grant_table.h
> @@ -25,6 +25,8 @@
>  
>  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>  unsigned int flags, unsigned int cache_flags);
> +int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
> + uint64_t new_addr, unsigned int flags);
>  
>  #else
>  
> @@ -37,6 +39,12 @@ static inline int create_grant_pv_mapping(uint64_t addr, 
> unsigned long frame,
>  return GNTST_general_error;
>  }
>  
> +int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
> + uint64_t new_addr, unsigned int flags)
> +{
> +return GNTST_general_error;
> +}
> +
>  #endif
>  
>  #endif /* __X86_PV_GRANT_TABLE_H__ */
> 


___
Xen-devel mailing

Re: [Xen-devel] [PATCH v3 01/21] x86/mm: carve out create_grant_pv_mapping

2017-08-28 Thread George Dunlap 
On 07/20/2017 05:04 PM, Wei Liu wrote:
> And at once make create_grant_host_mapping an inline function.  This

"At once" means "immediately" or "without any delay between this event
and the preceding event", which doesn't make sense here.  I think you
want, "At the same time."

Other than that, looks good:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v2 REPOST 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

2017-08-28 Thread Wei Liu 
On Tue, Aug 22, 2017 at 03:51:05PM +0100, Paul Durrant wrote:
[...]
> diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
> b/tools/libs/devicemodel/include/xendevicemodel.h
> index 13216db04a..da6b253cfd 100644
> --- a/tools/libs/devicemodel/include/xendevicemodel.h
> +++ b/tools/libs/devicemodel/include/xendevicemodel.h
> @@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
>   * @parm domid the domain id to be serviced
>   * @parm id the IOREQ Server id.
>   * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
> - *  gfn
> + *  gmfn. (May be NULL if not required)
>   * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
> - *gfn
> + *gmfn. (May be NULL if not required)

Should be gfn here.

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

Re: [Xen-devel] [PATCH] x86/mm: Drop is_guest_l3_slot() and simply callers

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 16:50,  wrote:
> With a 64bit hypervisor there are no conditional l3 slots, and this is
> unlikely to change moving forwards.
> 
> No functional change (as confirmed by diffing the disassembly.  GCC obviously
> already optimised this code away.)
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

But I think you mean "simplify" in the title.

Jan


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

Re: [Xen-devel] [PATCH v2 REPOST 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

2017-08-28 Thread Wei Liu 
On Thu, Aug 24, 2017 at 05:09:35PM +0100, Paul Durrant wrote:
> > 
> > Could be written as:
> > 
> > return (is_hvm ? compat_gnttab_hvm_seed : compat_gnttab_seed)
> >(xch, guest_domid, console_gmfn, xenstore_gmfn, console_domid,
> > xenstore_domid);
> 
> Is that preferable?
> 

I don't think I care either way.

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

Re: [Xen-devel] [PATCH] xen: fix boolean parameter handling

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 16:49,  wrote:
> Commit 63e8a1e5ffa7a7fdbde887805f673fea7e8d2e94 ("xen: check parameter
> validity when parsing command line") introduced a bug for the case
> when a boolean parameter was specified by its keyword only (no value).
> It would set just the wrong boolean value for that parameter.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 REPOST 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

2017-08-28 Thread Wei Liu 
On Tue, Aug 22, 2017 at 03:51:00PM +0100, Paul Durrant wrote:
> Since IOREQ servers are only relevant to HVM guests and all the names in
> question unequivocally refer to guest frame numbers, name them all .*gfn
> to avoid any confusion.
> 
> This patch is purely cosmetic. No semantic or functional change.
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 REPOST 03/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

2017-08-28 Thread Wei Liu 
On Tue, Aug 22, 2017 at 03:50:57PM +0100, Paul Durrant wrote:
> +
> +/*
> + * Get the pages for a particular guest resource, so that they can be
> + * mapped directly by a tools domain.
> + */
> +#define XENMEM_acquire_resource 28
> +struct xen_mem_acquire_resource {
> +/* IN - the domain whose resource is to be mapped */
> +domid_t domid;
> +/* IN - the type of resource (defined below) */
> +uint16_t type;
> +
> +#define XENMEM_resource_grant_table 0
> +
> +/*
> + * IN - a type-specific resource identifier, which must be zero
> + *  unless stated otherwise.
> + */
> +uint32_t id;
> +/* IN - number of (4K) frames of the resource to be mapped */
> +uint32_t nr_frames;
> +/* IN - the index of the initial frame to be mapped */
> +uint64_aligned_t frame;
> +/* IN/OUT - If the tools domain is PV then, upon return, gmfn_list
> + *  will be populated with the MFNs of the resource.
> + *  If the tools domain is HVM then it is expected that, on
> + *  entry, gmfn_list will be populated with a list of GFNs
> + *  that will be mapped to the MFNs of the resource.
> + */
> +XEN_GUEST_HANDLE(xen_pfn_t) gmfn_list;

Why is it not possible to make PV does the same thing as HVM?

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

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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
baseline version:
 ovmf 714c2603018a99a514c42c2b511c821f30ba9cdf

Last test of basis72032  2017-08-28 06:47:48 Z0 days
Testing same since72033  2017-08-28 13:16:57 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Dandan Bi 
  Eric Dong 

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 ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
Author: Bi, Dandan 
Date:   Fri Aug 25 10:58:36 2017 +0800

IntelFrameworkModulePkg/LegacyBootMaintUiLib: Add NULL pointer check

mLegacyBootOptionPrivate pointer is initialized in Constructor function
with if condition check, but it's used in Destructor function directly
without any check. Now add the NULL pointer check.

Cc: Eric Dong 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
Reviewed-by: Eric Dong 

commit 34b6a0e22210b825ca5ea8447ac8bc513c0c96c5
Author: Eric Dong 
Date:   Wed Aug 23 10:28:55 2017 +0800

UefiCpuPkg: Update default for 
PcdCpuProcTraceMemSize/PcdCpuProcTraceOutputScheme.

These two definitions have redundant definition which can be handle by code.
This patch update them to follow new code definitions.

V2: Add more comments for the PCDs and keep consistent in .dec and .uni 
files.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
Reviewed-by: Michael Kinney 

commit 330021fa41e41ef4b4aafc20e853d91179fd1b80
Author: Eric Dong 
Date:   Wed Aug 23 10:24:58 2017 +0800

UefiCpuPkg/CpuCommonFeaturesLib: Remove redundant definition.

The EnumProcTraceMemDisable/OutputSchemeInvalid are redundant
definitions. These definitions can be handled by other code,
so remove them.

V2: Change enum members name.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
Reviewed-by: Michael Kinney 

commit b2b0ffc9b7720bf97b8f9390f77e7399e4e96596
Author: Eric Dong 
Date:   Fri Aug 18 11:19:03 2017 +0800

UefiCpuPkg/CpuCommonFeaturesLib: Use MSR data structure when change MSR 
value.

When update MSR values, current code use BITxx to modify it. Enhance the 
code
to use corresponding MSR's data structures to make it more user friendly.

V2: Move architecturalMsr.h file. definition to architecturalMsr.h file.
Use structure members to do value assignment.

Cc: Michael Kinney 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
Reviewed-by: Michael Kinney 

commit a2e24a2a012349f9233f0eb83ad71006e1c4989e
Author: Eric Dong 
Date:   Fri Aug 18 11:17:23 2017 +0800

UefiCpuPkg/ArchitecturalMsr.h: Add RTIT TOPA table entry definition.

Add RTIT TOPA table entry definition to architecturalMsr.h file.

V2: Add

Re: [Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 16:24,  wrote:
> On 08/28/2017 09:29 AM, Jan Beulich wrote:
> On 27.08.17 at 10:36,  wrote:
>>> --- a/xen/arch/arm/mm.c
>>> +++ b/xen/arch/arm/mm.c
>>> @@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
>>>  return -EINVAL;
>>>  }
>>>  
>>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
>>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
>>>  if ( rc )
>>>  {
>>>  rcu_unlock_domain(od);
>>> --- a/xen/arch/x86/mm/p2m.c
>>> +++ b/xen/arch/x86/mm/p2m.c
>>> @@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned 
>>> long fgfn,
>>>  if ( tdom == fdom )
>>>  goto out;
>>>  
>>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
>>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
>> 
>> I continue to dislike the added arguments here, as being pointless
>> to pass. I'm not the maintainer of either of the modified files, so I
>> won't (and can't) veto the change though.
> 
> You mean, you think xsm_map_gmfn_foreign() can look up 'current' itself?

Yes, that's what I had suggested before (in more detail than I
have given here); I also don't think it would be
xsm_map_gmfn_foreign(), but rather whatever functions back
it.

Jan


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

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

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 16:24,  wrote:
>>> As for periodically testing process_pending_softirqs() we may still want
>>> to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.
>> For my taste, alloc_heap_pages() is the wrong place for such
>> calls.
> 
> But the loop is in alloc_heap_pages() --- where else would you be testing?

It can only reasonably be the callers of alloc_heap_pages() imo.
A single call to it should never trigger the watchdog, only calls
themselves sitting in a loop should be potential candidates for
causing such.

Jan


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

[Xen-devel] [PATCH] x86/mm: Drop is_guest_l3_slot() and simply callers

2017-08-28 Thread Andrew Cooper 
With a 64bit hypervisor there are no conditional l3 slots, and this is
unlikely to change moving forwards.

No functional change (as confirmed by diffing the disassembly.  GCC obviously
already optimised this code away.)

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/mm.c | 31 ---
 xen/include/asm-x86/x86_64/page.h |  1 -
 2 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index bdba94a..b6d6ae3 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1557,8 +1557,7 @@ static int alloc_l3_table(struct page_info *page)
 l3e_get_mfn(pl3e[i]),
 PGT_l2_page_table | PGT_pae_xen_l2, d, partial, 1);
 }
-else if ( !is_guest_l3_slot(i) ||
-  (rc = get_page_from_l3e(pl3e[i], pfn, d, partial)) > 0 )
+else if ( (rc = get_page_from_l3e(pl3e[i], pfn, d, partial)) > 0 )
 continue;
 
 if ( rc == -ERESTART )
@@ -1590,11 +1589,7 @@ static int alloc_l3_table(struct page_info *page)
 current->arch.old_guest_table = page;
 }
 while ( i-- > 0 )
-{
-if ( !is_guest_l3_slot(i) )
-continue;
 unadjust_guest_l3e(pl3e[i], d);
-}
 }
 
 unmap_domain_page(pl3e);
@@ -1759,16 +1754,13 @@ static int free_l3_table(struct page_info *page)
 pl3e = map_domain_page(_mfn(pfn));
 
 do {
-if ( is_guest_l3_slot(i) )
-{
-rc = put_page_from_l3e(pl3e[i], pfn, partial, 0);
-if ( rc < 0 )
-break;
-partial = 0;
-if ( rc > 0 )
-continue;
-unadjust_guest_l3e(pl3e[i], d);
-}
+rc = put_page_from_l3e(pl3e[i], pfn, partial, 0);
+if ( rc < 0 )
+break;
+partial = 0;
+if ( rc > 0 )
+continue;
+unadjust_guest_l3e(pl3e[i], d);
 } while ( i-- );
 
 unmap_domain_page(pl3e);
@@ -2072,13 +2064,6 @@ static int mod_l3_entry(l3_pgentry_t *pl3e,
 struct domain *d = vcpu->domain;
 int rc = 0;
 
-if ( unlikely(!is_guest_l3_slot(pgentry_ptr_to_slot(pl3e))) )
-{
-gdprintk(XENLOG_WARNING, "L3 update in Xen-private area, slot %#lx\n",
- pgentry_ptr_to_slot(pl3e));
-return -EINVAL;
-}
-
 /*
  * Disallow updates to final L3 slot. It contains Xen mappings, and it
  * would be a pain to ensure they remain continuously valid throughout.
diff --git a/xen/include/asm-x86/x86_64/page.h 
b/xen/include/asm-x86/x86_64/page.h
index a9ba6f0..1151ce9 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -101,7 +101,6 @@ typedef l4_pgentry_t root_pgentry_t;
 ( !is_pv_32bit_domain(_d) ||   \
   !((_t) & PGT_pae_xen_l2) ||  \
   ((_s) < COMPAT_L2_PAGETABLE_FIRST_XEN_SLOT(_d)) )
-#define is_guest_l3_slot(_s) (1)
 #define is_guest_l4_slot(_d, _s)\
 ( is_pv_32bit_domain(_d)\
   ? ((_s) == 0) \
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 2/6] xen: credit2: soft-affinity awareness in gat_fallback_cpu()

2017-08-28 Thread George Dunlap 
On 07/27/2017 01:05 PM, Dario Faggioli wrote:
> By, basically, moving all the logic of the function
> inside the usual two steps (soft-affinity step and
> hard-affinity step) loop.
> 
> While there, add two performance counters (in cpu_pick
> and in get_fallback_cpu() itself), in order to be able
> to tell how frequently it happens that we need to look
> for a fallback cpu.
> 
> Signed-off-by: Dario Faggioli 
> Signed-off-by: Justin T. Weaver 
> ---
> Cc: Anshul Makkar 
> Cc: George Dunlap 
> ---
> Changes from v1:
> - as discussed during review, only consider hard-affinity for the last stand.
>   The idea is not moving the vcpu to a diffrent runqueue because of
>   soft-affinity, as a part of finding a fallback cpu;
> - as discussed during review, added the performance counters;
> - BUG_ON(1) turned into ASSERT_UNREACHABLE(), as suggested during review;
> - return something same and random enough, at the end of the function (in
>   case we somehow manage to get there).
> ---
>  xen/common/sched_credit2.c   |  101 
> +-
>  xen/include/xen/perfc_defn.h |2 +
>  2 files changed, 82 insertions(+), 21 deletions(-)
> 
> diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
> index 57e77df..aa8f169 100644
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -549,36 +549,93 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t 
> *mask)
>  }
>  
>  /*
> - * When a hard affinity change occurs, we may not be able to check some
> - * (any!) of the other runqueues, when looking for the best new processor
> - * for svc (as trylock-s in csched2_cpu_pick() can fail). If that happens, we
> - * pick, in order of decreasing preference:
> - *  - svc's current pcpu;
> - *  - another pcpu from svc's current runq;
> - *  - any cpu.
> + * In csched2_cpu_pick(), it may not be possible to actually look at remote
> + * runqueues (the trylock-s on their spinlocks can fail!). If that happens,
> + * we pick, in order of decreasing preference:
> + *  1) svc's current pcpu, if it is part of svc's soft affinity;
> + *  2) a pcpu in svc's current runqueue that is also in svc's soft affinity;
> + *  3) svc's current pcpu, if it is part of svc's hard affinity;
> + *  4) a pcpu in svc's current runqueue that is also in svc's hard affinity;
> + *  5) just one valid pcpu from svc's hard affinity
> + *
> + * Of course, 1, 2 and 3 makes sense only if svc has a soft affinity. Also
> + * note that at least 6 is guaranteed to _always_ return at least one pcpu.

s/6/5/; ?

>   */
>  static int get_fallback_cpu(struct csched2_vcpu *svc)
>  {
>  struct vcpu *v = svc->vcpu;
> -int cpu = v->processor;
> +unsigned int bs;
>  
> -cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
> -cpupool_domain_cpumask(v->domain));
> +SCHED_STAT_CRANK(need_fallback_cpu);
>  
> -if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> -return cpu;
> -
> -if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> -   >rqd->active)) )
> +for_each_affinity_balance_step( bs )
>  {
> -cpumask_and(cpumask_scratch_cpu(cpu), >rqd->active,
> -cpumask_scratch_cpu(cpu));
> -return cpumask_first(cpumask_scratch_cpu(cpu));
> -}
> +int cpu = v->processor;
>  
> -ASSERT(!cpumask_empty(cpumask_scratch_cpu(cpu)));
> +if ( bs == BALANCE_SOFT_AFFINITY &&
> + !has_soft_affinity(v, v->cpu_hard_affinity) )
> +continue;
>  
> -return cpumask_first(cpumask_scratch_cpu(cpu));
> +affinity_balance_cpumask(v, bs, cpumask_scratch_cpu(cpu));
> +cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +cpupool_domain_cpumask(v->domain));
> +
> +/*
> + * This is cases 1 or 3 (depending on bs): if v->processor is (still)
> + * in our affinity, go for it, for cache betterness.
> + */
> +if ( likely(cpumask_test_cpu(cpu, cpumask_scratch_cpu(cpu))) )
> +return cpu;
> +
> +/*
> + * This is cases 2 or 4 (depending on bs): v->processor isn't there
> + * any longer, check if we at least can stay in our current runq.
> + */
> +if ( likely(cpumask_intersects(cpumask_scratch_cpu(cpu),
> +   >rqd->active)) )
> +{
> +cpumask_and(cpumask_scratch_cpu(cpu), cpumask_scratch_cpu(cpu),
> +>rqd->active);
> +return cpumask_first(cpumask_scratch_cpu(cpu));
> +}
> +
> +/*
> + * We may well pick any valid pcpu from our soft-affinity, outside
> + * of our current runqueue, but we decide not to. In fact, changing
> + * runqueue is slow, affects load distribution, and is a source of
> +

[Xen-devel] [PATCH] xen: fix boolean parameter handling

2017-08-28 Thread Juergen Gross 
Commit 63e8a1e5ffa7a7fdbde887805f673fea7e8d2e94 ("xen: check parameter
validity when parsing command line") introduced a bug for the case
when a boolean parameter was specified by its keyword only (no value).
It would set just the wrong boolean value for that parameter.

Signed-off-by: Juergen Gross 
---
 xen/common/kernel.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index f96e402515..94fdf5c60a 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -136,7 +136,7 @@ static int parse_params(const char *cmdline, const struct 
kernel_param *start,
 rctmp = -EINVAL;
 break;
 case OPT_BOOL:
-rctmp = *optval ? parse_bool(optval, NULL) : 0;
+rctmp = *optval ? parse_bool(optval, NULL) : 1;
 if ( rctmp < 0 )
 break;
 if ( !rctmp )
-- 
2.12.3


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

Re: [Xen-devel] [PATCH v2 1/6] xen/tools: credit2: soft-affinity awareness in runq_tickle()

2017-08-28 Thread George Dunlap 
On 07/27/2017 01:05 PM, Dario Faggioli wrote:
> Soft-affinity support is usually implemented by means
> of a two step "balancing loop", where:
> - during the first step, we consider soft-affinity
>   (if the vcpu has one);
> - during the second (if we get to it), we consider
>   hard-affinity.
> 
> In runq_tickle(), we need to do that for checking
> whether we can execute the waking vCPU on an pCPU
> that is idle. In fact, we want to be sure that, if
> there is an idle pCPU in the vCPU's soft affinity,
> we'll use it.
> 
> If there are no such idle pCPUs, though, and we
> have to check non-idle ones, we can avoid the loop
> and to both hard and soft-affinity in one pass.
> 
> In fact, we can we scan runqueue and compute a
> "score" for each vCPU which is running on each pCPU.
> The idea is, since we may have to preempt someone:
> - try to make sure that the waking vCPU will run
>   inside its soft-affinity,
> - try to preempt someone that is running outside
>   of its own soft-affinity.
> 
> The value of the score is added to a trace record,
> so xenalyze's code and tools/xentrace/formats are
> updated accordingly.
> 
> Suggested-by: George Dunlap 
> Signed-off-by: Dario Faggioli 
> Reviewed-by: George Dunlap 

The primary focus of this patch is credit2, so the title should probably
be xen/credit2, right?

I can change that on checkin.

 -George

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

Re: [Xen-devel] [PATCH v2 REPOST 02/12] x86/mm: allow a privileged PV domain to map guest mfns

2017-08-28 Thread Wei Liu 
On Fri, Aug 25, 2017 at 11:05:54AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 24 August 2017 17:33
> > To: Paul Durrant 
> > Cc: xen-de...@lists.xenproject.org; Andrew Cooper
> > ; Jan Beulich ; Wei Liu
> > 
> > Subject: Re: [Xen-devel] [PATCH v2 REPOST 02/12] x86/mm: allow a
> > privileged PV domain to map guest mfns
> > 
> > On Tue, Aug 22, 2017 at 03:50:56PM +0100, Paul Durrant wrote:
> > > In the case where a PV domain is mapping guest resources then it needs
> > make
> > > the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the
> > guest
> > > domid, so that the passed in gmfn values are correctly treated as mfns
> > > rather than gfns present in the guest p2m.
> > >
> > 
> > What would be the callchain like in this case?

> 
> It's exactly like foreign mapping but passing DOMID_SELF. I.e. in
> privcmd (in a PV domain) you have an mfn in your hand that already
> belongs to you rather than the gmfn of a foreign domain.
> 
> > 
> > I don't quite understand how this fits with the resource mapping
> > code in this series.
> > 
> 
> Because (for a PV caller) mapping a resource gives you back mfns that
> are assigned to the calling domain, and the most convenient way of
> using them is to use the existing code that normally deals with priv
> mapping from a foreign domain, but just allow it to use DOMID_SELF.
> This patch is all that's required to make that work.
> 

So the use case is as followed for PV guests:

1. A guest calls acquire_resource to obtain a list of mfns
2. The guest calls the foreign map API to map those mfns into its own
   address space via HYPERVISOR_mmu_update

The mfns belong to the guest itself.

In get_page_from_l1e, l1e contains a valid mfn, real_pg_owner is the
real owner of the page, pg_owner is the nominally owner of the page.
Shouldn't they be the same domain? I'm still quite baffled how you
manage to hit that place.

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

Re: [Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

2017-08-28 Thread Boris Ostrovsky 
On 08/28/2017 03:38 AM, Jan Beulich wrote:
>
>>> And finally I continue to be not really happy about the change as
>>> a whole. Despite what was discussed on v1, I'm concerned of the
>>> effects of this on hosts _not_ suffering from vector shortage.
>>> Could you live with the new behavior requiring a command line
>>> option to enable?
>> I can add something like 'apic_share_vectors', defaulting to true,
>> although it will not be useful in case of a hotplug. Defaulting to false?
> Along the lines of the above plus our desire to limit the number
> of top level options, how about "apic=isolate-vectors"?
>
> Also I don't understand your reference to hotplug, nor why you
> suggest two opposite default values.

Not two, just one --- not share vectors by default.

As for hotplug, I was thinking of a case where a system is successfully
booted with shared vectors but then a device is added and we fail to
find enough free vectors. So the administrator would need to know in
advance whether a new card might be coming in.

When defaulting to false (as in apic_share_vectors=false) if the
administrator decides to set it to true then he would be in some sense
explicitly agreeing to never plug anything in (or at least to tolerate
such a failure).

>
> But finally, you agreeing to a command line option here makes
> me come back to an earlier suggestion: Didn't we agree that
> "x2apic_phys" would be sufficient to eliminate the issue? In which
> case no patch would be needed at all.

x2apic_phys means that we never share vectors. With 'isolate-vectors'
option we are still able to share them if the mask is explicitly specified.


-boris


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

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

2017-08-28 Thread Boris Ostrovsky 

>> As for periodically testing process_pending_softirqs() we may still want
>> to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.
> For my taste, alloc_heap_pages() is the wrong place for such
> calls.

But the loop is in alloc_heap_pages() --- where else would you be testing?

-boris



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

Re: [Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

2017-08-28 Thread George Dunlap 
On 08/28/2017 09:29 AM, Jan Beulich wrote:
 On 27.08.17 at 10:36,  wrote:
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
>>  return -EINVAL;
>>  }
>>  
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
>>  if ( rc )
>>  {
>>  rcu_unlock_domain(od);
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
>> fgfn,
>>  if ( tdom == fdom )
>>  goto out;
>>  
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
> 
> I continue to dislike the added arguments here, as being pointless
> to pass. I'm not the maintainer of either of the modified files, so I
> won't (and can't) veto the change though.

You mean, you think xsm_map_gmfn_foreign() can look up 'current' itself?

If not can you be more explicit what you'd prefer?

  -George

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

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

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 15:57,  wrote:
> On 08/28/2017 03:25 AM, Jan Beulich wrote:
> On 25.08.17 at 19:14,  wrote:
>>> On 08/25/2017 09:40 AM, Jan Beulich wrote:
>>> On 25.08.17 at 05:15,  wrote:
> flight 112855 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/112855/ 
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-examine   7 reboot   fail REGR. vs. 
> 112809
>  test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 
> 112809
 These two are watchdog NMIs during the loading of Dom0. Most
 likely candidate for introducing the issue is Boris' scrub series.
>>>
>>> I haven't been able to reproduce this but perhaps adding
>>> process_pending_softirqs() in alloc_heap_pages() and free_heap_pages()
>>> loops if CONFIG_SCRUB_DEBUG is set might help?
>> That's possible, but might as well only be papering over a deeper
>> issue, e.g. ...
>>
>>> One other thing that also comes to mind is that there is probably no
>>> reason to scrub (and in some cases poison) pages during dom0 creation.
>> ... this one: Iirc before your series Dom0 pages weren't being
>> scrubbed, and imo this property ought to be retained (also if
>> any other boot time allocations now suddenly got scrubbed).
> 
> It is scrubbed if CONFIG_SCRUB_DEBUG in free_domheap_pages:
> 
> #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
> 
> so the question is whether we need to do this (at least for dom0).

We should start doing this only once Dom0 started running, imo.

> As for periodically testing process_pending_softirqs() we may still want
> to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG.

For my taste, alloc_heap_pages() is the wrong place for such
calls.

> And
> while at it, also think we can execute the 'for' loop without holding
> heap lock since the pages are now removed from the heap (or do we need
> to modify count_info/type_info/owner under the lock?)

I don't think these fields need updating with the heap lock held.

Jan


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

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

2017-08-28 Thread Boris Ostrovsky 
On 08/28/2017 03:25 AM, Jan Beulich wrote:
 On 25.08.17 at 19:14,  wrote:
>> On 08/25/2017 09:40 AM, Jan Beulich wrote:
>> On 25.08.17 at 05:15,  wrote:
 flight 112855 xen-unstable real [real]
 http://logs.test-lab.xenproject.org/osstest/logs/112855/ 

 Regressions :-(

 Tests which did not succeed and are blocking,
 including tests which could not be run:
  test-amd64-i386-examine   7 reboot   fail REGR. vs. 
 112809
  test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 
 112809
>>> These two are watchdog NMIs during the loading of Dom0. Most
>>> likely candidate for introducing the issue is Boris' scrub series.
>>
>> I haven't been able to reproduce this but perhaps adding
>> process_pending_softirqs() in alloc_heap_pages() and free_heap_pages()
>> loops if CONFIG_SCRUB_DEBUG is set might help?
> That's possible, but might as well only be papering over a deeper
> issue, e.g. ...
>
>> One other thing that also comes to mind is that there is probably no
>> reason to scrub (and in some cases poison) pages during dom0 creation.
> ... this one: Iirc before your series Dom0 pages weren't being
> scrubbed, and imo this property ought to be retained (also if
> any other boot time allocations now suddenly got scrubbed).

It is scrubbed if CONFIG_SCRUB_DEBUG in free_domheap_pages:

#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

so the question is whether we need to do this (at least for dom0).

As for periodically testing process_pending_softirqs() we may still want
to do this in alloc_heap_pages(), even without CONFIG_SCRUB_DEBUG. And
while at it, also think we can execute the 'for' loop without holding
heap lock since the pages are now removed from the heap (or do we need
to modify count_info/type_info/owner under the lock?)

-boris

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

Re: [Xen-devel] [PATCH v8] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 14:51,  wrote:
> --- a/xen/include/asm-arm/monitor.h
> +++ b/xen/include/asm-arm/monitor.h
> @@ -26,6 +26,12 @@
>  #include 
>  
>  static inline
> +void arch_allow_userspace(struct domain *d, uint8_t allow_userspace)
> +{
> +return;
> +}

I'm sorry for noticing this only now, but the name of the hook really
ought to have vm_event or monitor in it - it's way too generic the
way it is now.

Jan


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

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

2017-08-28 Thread osstest service owner 
flight 112903 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112903/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
baseline version:
 ovmf 714c2603018a99a514c42c2b511c821f30ba9cdf

Last test of basis   112899  2017-08-28 01:56:16 Z0 days
Testing same since   112903  2017-08-28 07:17:30 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Dandan Bi 
  Eric Dong 

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=ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
+ . ./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 
ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
+ branch=ovmf
+ revision=ef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671
+ . ./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
+ '[' xef5e0db22cdd73e9727afcaa5c7fe8e55b7b3671 = 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
++ :

[Xen-devel] [PATCH v8] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Alexandru Isaila 
In some introspection usecases, an in-guest agent needs to communicate
with the external introspection agent.  An existing mechanism is
HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
like all other hypercalls.

Introduce a mechanism whereby the introspection agent can whitelist the
use of HVMOP_guest_request_vm_event directly from userspace.

Signed-off-by: Alexandru Isaila 
Acked-by: Jan Beulich 
Acked-by: Wei Liu 

---
Changes since V7:
- Passed domain* instead of arch* for the new arch specific
function
- Added Wei Liu's ack from v5
- Added Jan's ack from v7

Note: Could not test on ARM, compiled both on arm and x86
---
 tools/libxc/include/xenctrl.h |  2 +-
 tools/libxc/xc_monitor.c  |  3 ++-
 xen/arch/x86/hvm/hypercall.c  |  5 +
 xen/common/monitor.c  |  1 +
 xen/include/asm-arm/monitor.h |  6 ++
 xen/include/asm-x86/domain.h  | 19 ++-
 xen/include/asm-x86/monitor.h |  6 ++
 xen/include/public/domctl.h   |  1 +
 8 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index bde8313..a3d0929 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2021,7 +2021,7 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_descriptor_access(xc_interface *xch, domid_t domain_id,
  bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
- bool enable, bool sync);
+ bool enable, bool sync, bool allow_userspace);
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..a677820 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -147,7 +147,7 @@ int xc_monitor_descriptor_access(xc_interface *xch, domid_t 
domain_id,
 }
 
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync)
+ bool sync, bool allow_userspace)
 {
 DECLARE_DOMCTL;
 
@@ -157,6 +157,7 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id, bool enable,
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST;
 domctl.u.monitor_op.u.guest_request.sync = sync;
+domctl.u.monitor_op.u.guest_request.allow_userspace = enable ? 
allow_userspace : false;
 
 return do_domctl(xch, );
 }
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index e7238ce..5742dd1 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 /* Fallthrough to permission check. */
 case 4:
 case 2:
+if ( currd->arch.monitor.guest_request_userspace_enabled &&
+eax == __HYPERVISOR_hvm_op &&
+(mode == 8 ? regs->rdi : regs->ebx) == 
HVMOP_guest_request_vm_event )
+break;
+
 if ( unlikely(hvm_get_cpl(curr)) )
 {
 default:
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 451f42f..59f2cf3 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 domain_pause(d);
 d->monitor.guest_request_sync = mop->u.guest_request.sync;
 d->monitor.guest_request_enabled = requested_status;
+arch_allow_userspace(d, mop->u.guest_request.allow_userspace);
 domain_unpause(d);
 break;
 }
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 1c4fea3..9f352be 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -26,6 +26,12 @@
 #include 
 
 static inline
+void arch_allow_userspace(struct domain *d, uint8_t allow_userspace)
+{
+return;
+}
+
+static inline
 int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
 /* No arch-specific monitor ops on ARM. */
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index c10522b..de02507 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -396,15 +396,16 @@ struct arch_domain
 
 /* Arch-specific monitor options */
 struct {
-unsigned int write_ctrlreg_enabled   : 4;
-unsigned int write_ctrlreg_sync  : 4;
-unsigned int write_ctrlreg_onchangeonly  : 4;
-unsigned int singlestep_enabled  : 1;
-unsigned int software_breakpoint_enabled : 1;
-unsigned int debug_exception_enabled

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

2017-08-28 Thread osstest service owner 
flight 112905 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112905/

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 112879
 build-arm64   2 hosts-allocate  broken like 112879
 build-arm64-pvops 3 capture-logsbroken like 112879
 build-arm64   3 capture-logsbroken like 112879
 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  650310c51316c0c967d34a37022d8bda0b1133ea
baseline version:
 xen  803c5a2a42e7c72a4c848e0f0106a941b758a91f

Last test of basis   112879  2017-08-25 23:03:20 Z2 days
Testing same since   112905  2017-08-28 09:02:15 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Daniel De Graaf 
  Dario Faggioli 
  Jan Beulich 
  Juergen Gross 
  Wei Liu 
  Xiong Zhang 

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 hosts-allocate
broken-step build-arm64-pvops capture-logs
broken-step build-arm64 capture-logs

Pushing revision :

+ branch=xen-unstable-smoke
+ revision=650310c51316c0c967d34a37022d8bda0b1133ea
+ . ./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 
650310c51316c0c967d34a37022d8bda0b1133ea
+ branch=xen-unstable-smoke
+ revision=650310c51316c0c967d34a37022d8bda0b1133ea
+ . ./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
+ '[' x650310c51316c0c967d34a37022d8bda0b1133ea = 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
++ :

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

2017-08-28 Thread osstest service owner 
flight 112900 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112900/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112891
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-saverestore.2 fail REGR. vs. 
112891
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR. 
vs. 112891

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 112891
 build-arm64-pvops 3 capture-logsbroken like 112891
 build-arm64-xsm   2 hosts-allocate  broken like 112891
 build-arm64-xsm   3 capture-logsbroken like 112891
 build-arm64   2 hosts-allocate  broken like 112891
 build-arm64   3 capture-logsbroken like 112891
 test-armhf-armhf-xl-rtds   16 guest-start/debian.repeat fail blocked in 112891
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 112891
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112891
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112891
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112891
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112891
 test-amd64-amd64-xl-qemut-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-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-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-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-libvirt 13 migrate-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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-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:
 linuxcc4a41fe5541a73019a864883297bd5043aa6d98
baseline version:
 linux

Re: [Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 13:01,  wrote:
> 2017-08-28 16:29 GMT+08:00 Jan Beulich :
> On 27.08.17 at 10:36,  wrote:
>>> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>>> *d, struct domain *t)
>>> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>>> *cd,
>>> +   struct domain *d, struct domain 
>>> *t)
>>>  {
>>> +int rc;
>>>  XSM_ASSERT_ACTION(XSM_TARGET);
>>
>> Missing blank line between declaration and statements.
> 
> Sorry. Will fix this.
> 
>>
>>> -return xsm_default_action(action, d, t);
>>> +rc = xsm_default_action(action, cd, d);
>>> +if (rc) return rc;
>>
>> Coding style. In any event, as suggested before the whole thing is
>> easier to write as
>>
>>> +return xsm_default_action(action, cd, t);
>>
>> return xsm_default_action(action, cd, d) ?: xsm_default_action(action, 
>> cd, t);
> 
> But aren't we going to preserve the error code here?

I don't understand the question - if the first function invocation
returns an error, that is what the function here will return. Else
it returns what the second xsm_default_action() invocation
hands back.

Jan


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

Re: [Xen-devel] crashdump on PVM Dom0

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 12:45,  wrote:
> Oh!! I'm so sorry Jan Beulich.
> It is my first time to use this mailing list.
> Please understand my fault, this time only.
> 
> Anyway, as you mentioned, I added below line in '/etc/default/grub' file
> and reboot:
>> GRUB_CMDLINE_XEN="crashkernel=384M-:256M@64M"
> Then,
> 1. I cannot see anything when I type "grep -i crash /proc/iomem"
> 2. I can see kernel log of Xen hypervisor when I type "sudo xl dmesg | grep
> -i crash":
> (XEN) Command line: placeholder crashkernel=384M-:256M@64M
> 
> I suppose a 'crashkernel' cmdline option of either Xen hypervisor or Dom0
> kernel can be enabled.
> I know it is quite difficult to advise some problems online but, could you
> give me a piece of hint?

I'm not sure what else hint you're after. You can check the log
so see whether the option was accepted. I'm not sure /proc/iomem
is supposed to have any indication of the crash area.

Jan


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

Re: [Xen-devel] [PATCH v7] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 11:38,  wrote:
> In some introspection usecases, an in-guest agent needs to communicate
> with the external introspection agent.  An existing mechanism is
> HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
> like all other hypercalls.
> 
> Introduce a mechanism whereby the introspection agent can whitelist the
> use of HVMOP_guest_request_vm_event directly from userspace.
> 
> Signed-off-by: Alexandru Isaila 

For the parts it is applicable to:
Acked-by: Jan Beulich 

I'd like to note though that I find it a little odd for >arch to be
passed to a hook, instead of just d. But it'll be the maintainers of
that code to approve (or not) of that.

Jan


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

Re: [Xen-devel] [PATCH v2 4/6] xsm: flask: change the dummy xsm policy and flask hook for map_gmfn_foregin

2017-08-28 Thread Zhongze Liu 
Hi Jan,

Thanks for having a look at the patch.

2017-08-28 16:29 GMT+08:00 Jan Beulich :
 On 27.08.17 at 10:36,  wrote:
>> --- a/xen/arch/arm/mm.c
>> +++ b/xen/arch/arm/mm.c
>> @@ -1284,7 +1284,7 @@ int xenmem_add_to_physmap_one(
>>  return -EINVAL;
>>  }
>>
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, d, od);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, d, od);
>>  if ( rc )
>>  {
>>  rcu_unlock_domain(od);
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2545,7 +2545,7 @@ int p2m_add_foreign(struct domain *tdom, unsigned long 
>> fgfn,
>>  if ( tdom == fdom )
>>  goto out;
>>
>> -rc = xsm_map_gmfn_foreign(XSM_TARGET, tdom, fdom);
>> +rc = xsm_map_gmfn_foreign(XSM_TARGET, current->domain, tdom, fdom);
>
> I continue to dislike the added arguments here, as being pointless
> to pass. I'm not the maintainer of either of the modified files, so I
> won't (and can't) veto the change though.
>
>> --- a/xen/include/xsm/dummy.h
>> +++ b/xen/include/xsm/dummy.h
>> @@ -525,10 +525,14 @@ static XSM_INLINE int 
>> xsm_remove_from_physmap(XSM_DEFAULT_ARG struct domain *d1,
>>  return xsm_default_action(action, d1, d2);
>>  }
>>
>> -static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *d, struct domain *t)
>> +static XSM_INLINE int xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain 
>> *cd,
>> +   struct domain *d, struct domain 
>> *t)
>>  {
>> +int rc;
>>  XSM_ASSERT_ACTION(XSM_TARGET);
>
> Missing blank line between declaration and statements.

Sorry. Will fix this.

>
>> -return xsm_default_action(action, d, t);
>> +rc = xsm_default_action(action, cd, d);
>> +if (rc) return rc;
>
> Coding style. In any event, as suggested before the whole thing is
> easier to write as
>
>> +return xsm_default_action(action, cd, t);
>
> return xsm_default_action(action, cd, d) ?: xsm_default_action(action, 
> cd, t);

But aren't we going to preserve the error code here?

Cheers,

Zhongze Liu

>
> anyway imo (suitably split across lines if needed, of course).
>
>> --- a/xen/xsm/flask/hooks.c
>> +++ b/xen/xsm/flask/hooks.c
>> @@ -1165,9 +1165,15 @@ static int flask_remove_from_physmap(struct domain 
>> *d1, struct domain *d2)
>>  return domain_has_perm(d1, d2, SECCLASS_MMU, MMU__PHYSMAP);
>>  }
>>
>> -static int flask_map_gmfn_foreign(struct domain *d, struct domain *t)
>> +static int flask_map_gmfn_foreign(struct domain *cd,
>> +  struct domain *d, struct domain *t)
>>  {
>> -return domain_has_perm(d, t, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE);
>> +int rc;
>> +rc = domain_has_perm(cd, d, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE);
>> +if (rc) return rc;
>> +rc = domain_has_perm(cd, t, SECCLASS_MMU, MMU__MAP_READ | 
>> MMU__MAP_WRITE);
>> +if (rc) return rc;
>> +return domain_has_perm(d, t, SECCLASS_MMU, MMU__SHARE_MEM);
>>  }
>
> At least the style problems mentioned above apply here too.
>
> Jan
>

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

[Xen-devel] [PATCH v4] common/vm_event: Initialize vm_event lists on domain creation

2017-08-28 Thread Alexandru Isaila 
The patch splits the vm_event into three structures:vm_event_share,
vm_event_paging, vm_event_monitor. The allocation for the
structure is moved to vm_event_enable so that it can be
allocated/init when needed and freed in vm_event_disable.

Signed-off-by: Alexandru Isaila 

---
Changes since V3:
- Moved the d->vm_event_paging to the if below in the
assign_device function

Note: Did not test on arm, compliled on arm and x86.
---
 xen/arch/arm/mem_access.c |   2 +-
 xen/arch/x86/mm/mem_access.c  |   2 +-
 xen/arch/x86/mm/mem_paging.c  |   2 +-
 xen/arch/x86/mm/mem_sharing.c |   4 +-
 xen/arch/x86/mm/p2m.c |  10 +--
 xen/common/domain.c   |  13 ++--
 xen/common/mem_access.c   |   2 +-
 xen/common/monitor.c  |   4 +-
 xen/common/vm_event.c | 156 +-
 xen/drivers/passthrough/pci.c |   2 +-
 xen/include/xen/sched.h   |  18 ++---
 11 files changed, 124 insertions(+), 91 deletions(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index e0888bb..a7f0cae 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -256,7 +256,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, vaddr_t gla, const 
struct npfec npfec)
 }
 
 /* Otherwise, check if there is a vm_event monitor subscriber */
-if ( !vm_event_check_ring(>domain->vm_event->monitor) )
+if ( !vm_event_check_ring(v->domain->vm_event_monitor) )
 {
 /* No listener */
 if ( p2m->access_required )
diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index 5adaf6d..414e38f 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -179,7 +179,7 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long gla,
 gfn_unlock(p2m, gfn, 0);
 
 /* Otherwise, check if there is a memory event listener, and send the 
message along */
-if ( !vm_event_check_ring(>vm_event->monitor) || !req_ptr )
+if ( !vm_event_check_ring(d->vm_event_monitor) || !req_ptr )
 {
 /* No listener */
 if ( p2m->access_required )
diff --git a/xen/arch/x86/mm/mem_paging.c b/xen/arch/x86/mm/mem_paging.c
index a049e0d..20214ac 100644
--- a/xen/arch/x86/mm/mem_paging.c
+++ b/xen/arch/x86/mm/mem_paging.c
@@ -43,7 +43,7 @@ int 
mem_paging_memop(XEN_GUEST_HANDLE_PARAM(xen_mem_paging_op_t) arg)
 goto out;
 
 rc = -ENODEV;
-if ( unlikely(!d->vm_event->paging.ring_page) )
+if ( !d->vm_event_paging || unlikely(!d->vm_event_paging->ring_page) )
 goto out;
 
 switch( mpo.op )
diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c
index 1f20ce7..12fb9cc 100644
--- a/xen/arch/x86/mm/mem_sharing.c
+++ b/xen/arch/x86/mm/mem_sharing.c
@@ -563,7 +563,7 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned 
long gfn,
 };
 
 if ( (rc = __vm_event_claim_slot(d, 
->vm_event->share, allow_sleep)) < 0 )
+d->vm_event_share, allow_sleep)) < 0 )
 return rc;
 
 if ( v->domain == d )
@@ -572,7 +572,7 @@ int mem_sharing_notify_enomem(struct domain *d, unsigned 
long gfn,
 vm_event_vcpu_pause(v);
 }
 
-vm_event_put_request(d, >vm_event->share, );
+vm_event_put_request(d, d->vm_event_share, );
 
 return 0;
 }
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index e8a57d1..6ae23be 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1454,7 +1454,7 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned 
long gfn,
  * correctness of the guest execution at this point.  If this is the only
  * page that happens to be paged-out, we'll be okay..  but it's likely the
  * guest will crash shortly anyways. */
-int rc = vm_event_claim_slot(d, >vm_event->paging);
+int rc = vm_event_claim_slot(d, d->vm_event_paging);
 if ( rc < 0 )
 return;
 
@@ -1468,7 +1468,7 @@ void p2m_mem_paging_drop_page(struct domain *d, unsigned 
long gfn,
 /* Evict will fail now, tag this request for pager */
 req.u.mem_paging.flags |= MEM_PAGING_EVICT_FAIL;
 
-vm_event_put_request(d, >vm_event->paging, );
+vm_event_put_request(d, d->vm_event_paging, );
 }
 
 /**
@@ -1505,7 +1505,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
long gfn)
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 /* We're paging. There should be a ring */
-int rc = vm_event_claim_slot(d, >vm_event->paging);
+int rc = vm_event_claim_slot(d, d->vm_event_paging);
 if ( rc == -ENOSYS )
 {
 gdprintk(XENLOG_ERR, "Domain %hu paging gfn %lx yet no ring "
@@ -1543,7 +1543,7 @@ void p2m_mem_paging_populate(struct domain *d, unsigned 
long gfn)
 else if ( p2mt != p2m_ram_paging_out && p2mt != p2m_ram_paged )
 {
 /* gfn is already on its way back and vcpu is not paused */
-vm_event_cancel_slot(d, >vm_event->paging);
+vm_event_cancel_slot(d,

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

2017-08-28 Thread osstest service owner 
flight 112901 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/112901/

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-xsm   2 hosts-allocate  broken like 112890
 build-arm64   2 hosts-allocate  broken like 112890
 build-arm64-pvops 2 hosts-allocate  broken like 112890
 build-arm64-xsm   3 capture-logsbroken like 112890
 build-arm64   3 capture-logsbroken like 112890
 build-arm64-pvops 3 capture-logsbroken like 112890
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112890
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112890
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112890
 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 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  ac87932ee3776a5c7540b4626cbcccfefb8f8307
baseline version:
 libvirt  b7e779c1a51793ee63a52889440361d8ba019781

Last test of basis   112890  2017-08-27 04:20:12 Z1 days
Testing same since   112901  2017-08-28 04:21:15 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 

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



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

Re: [Xen-devel] crashdump on PVM Dom0

2017-08-28 Thread Minjun Hong 
Oh!! I'm so sorry Jan Beulich.
It is my first time to use this mailing list.
Please understand my fault, this time only.

Anyway, as you mentioned, I added below line in '/etc/default/grub' file
and reboot:
> GRUB_CMDLINE_XEN="crashkernel=384M-:256M@64M"
Then,
1. I cannot see anything when I type "grep -i crash /proc/iomem"
2. I can see kernel log of Xen hypervisor when I type "sudo xl dmesg | grep
-i crash":
(XEN) Command line: placeholder crashkernel=384M-:256M@64M

I suppose a 'crashkernel' cmdline option of either Xen hypervisor or Dom0
kernel can be enabled.
I know it is quite difficult to advise some problems online but, could you
give me a piece of hint?

Sincerely,

On Mon, Aug 28, 2017 at 6:13 PM, Jan Beulich  wrote:

> >>> On 28.08.17 at 11:04,  wrote:
> > Thank you for your reply.
> > I checked what you mentioned(Xen command line).
> > But I could not find where the Xen command line configuration.
> > As I think, it would be in /etc/default/grub file because Dom0 is used
> for
> > booting like native system.
> > Is it wrong? I didn't get your point?
>
> First of all - please avoid private mails. Keep the list Cc-ed.
>
> And then - I can't tell you how to configure your variant of grub.
> All I can tell you is that the option you're after needs to be
> passed to Xen.
>
> Jan
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 01/14] fuzz/x86_emulate: Remove redundant AFL hook

2017-08-28 Thread George Dunlap 
On 08/25/2017 06:37 PM, Andrew Cooper wrote:
> On 25/08/17 17:43, George Dunlap wrote:
>> You don't need __AFL_INIT if you have __AFL_LOOP.
>>
>> Signed-off-by: George Dunlap 
> 
> Really?  Is that covered in any documentation?
> 
> I got the contrary impression from whichever version of AFL I was using
> when I put this in, and a quick look over the afl-fuzz source doesn't
> appear to equate them in any way.

The documentation does seem a bit hazy on the subject.  However:

1. It clear from the documentation [1] that both of them work *only* in
llvm mode (i.e., when compiled with afl-clang-fast).  In particular the
last paragraph of section 4: "afl-gcc or afl-clang will
*not* generate a deferred-initialization binary".

2. The documentation does seem to speak of them as separate 'modes'
(Section 5, "Note that as with the previous mode, ...")

3. Empirically speaking, persistent mode works fine with __AFL_LOOP()
and no __AFL_INIT() (for me anyway).

 -George

[1] https://github.com/mirrorer/afl/tree/master/llvm_mode

> 
> ~Andrew
> 
>> ---
>> CC: Ian Jackson 
>> CC: Wei Liu 
>> CC: Andrew Cooper 
>> CC: Jan Beulich 
>> ---
>>  tools/fuzz/x86_instruction_emulator/afl-harness.c | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/tools/fuzz/x86_instruction_emulator/afl-harness.c 
>> b/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> index 154869336a..1a79ff228e 100644
>> --- a/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> +++ b/tools/fuzz/x86_instruction_emulator/afl-harness.c
>> @@ -63,8 +63,6 @@ int main(int argc, char **argv)
>>  exit(-1);
>>  
>>  #ifdef __AFL_HAVE_MANUAL_CONTROL
>> -__AFL_INIT();
>> -
>>  while ( __AFL_LOOP(1000) )
>>  #endif
>>  {
> 


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

Re: [Xen-devel] [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

2017-08-28 Thread Pavel Machek 
Hi!

> > + The kernel and modules will generate slightly more assembly (1 to 
> > 2%
> > + increase on the .text sections). The vmlinux binary will be
> > + significantly smaller due to less relocations.
> >
> > ... but describing a 1-2% kernel text size increase as "slightly more 
> > assembly"
> > shows a gratituous disregard to kernel code generation quality! In reality 
> > that's
> > a huge size increase that in most cases will almost directly transfer to a 
> > 1-2%
> > slowdown for kernel intense workloads.
> >
> > Where does that size increase come from, if PIE is capable of using relative
> > instructins well? Does it come from the loss of a generic register and the
> > resulting increase in register pressure, stack spills, etc.?
> >
> > So I'm still unhappy about this all, and about the attitude surrounding it.
> 
> Is the expectation then to have security functions also decrease size
> and operational latency? Seems a bit unrealistic if so.
> 1-2% performance hit on systems which have become at least several
> hundred % faster over recent years is not a significant performance
> regression compared to the baseline before.

We are probably willing to trade security for 2% performance impact...
if you can show that same security advantage can't be achieved without
the impact (and it is opt-in and documented and so on).

Kernel is not really a bottleneck for many people. For me, even CPUs
are not bottleneck, disk is.

But what is not okay is "hey, this is security, I can slow things
down. Merge it, because... security!".

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH v7] x86/hvm: Allow guest_request vm_events coming from userspace

2017-08-28 Thread Alexandru Isaila 
In some introspection usecases, an in-guest agent needs to communicate
with the external introspection agent.  An existing mechanism is
HVMOP_guest_request_vm_event, but this is restricted to kernel usecases
like all other hypercalls.

Introduce a mechanism whereby the introspection agent can whitelist the
use of HVMOP_guest_request_vm_event directly from userspace.

Signed-off-by: Alexandru Isaila 

---
Changes since V6:
- Added arch specific function in both x86 monitor and arm
  monitor to replace the assignment from common monitor

Note: Could not test on ARN, compiled both on arm and x86
---
 tools/libxc/include/xenctrl.h |  2 +-
 tools/libxc/xc_monitor.c  |  3 ++-
 xen/arch/x86/hvm/hypercall.c  |  5 +
 xen/common/monitor.c  |  1 +
 xen/include/asm-arm/monitor.h |  6 ++
 xen/include/asm-x86/domain.h  | 19 ++-
 xen/include/asm-x86/monitor.h |  6 ++
 xen/include/public/domctl.h   |  1 +
 8 files changed, 32 insertions(+), 11 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index bde8313..a3d0929 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2021,7 +2021,7 @@ int xc_monitor_software_breakpoint(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_descriptor_access(xc_interface *xch, domid_t domain_id,
  bool enable);
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id,
- bool enable, bool sync);
+ bool enable, bool sync, bool allow_userspace);
 int xc_monitor_debug_exceptions(xc_interface *xch, domid_t domain_id,
 bool enable, bool sync);
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..a677820 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -147,7 +147,7 @@ int xc_monitor_descriptor_access(xc_interface *xch, domid_t 
domain_id,
 }
 
 int xc_monitor_guest_request(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync)
+ bool sync, bool allow_userspace)
 {
 DECLARE_DOMCTL;
 
@@ -157,6 +157,7 @@ int xc_monitor_guest_request(xc_interface *xch, domid_t 
domain_id, bool enable,
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_GUEST_REQUEST;
 domctl.u.monitor_op.u.guest_request.sync = sync;
+domctl.u.monitor_op.u.guest_request.allow_userspace = enable ? 
allow_userspace : false;
 
 return do_domctl(xch, );
 }
diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
index e7238ce..5742dd1 100644
--- a/xen/arch/x86/hvm/hypercall.c
+++ b/xen/arch/x86/hvm/hypercall.c
@@ -155,6 +155,11 @@ int hvm_hypercall(struct cpu_user_regs *regs)
 /* Fallthrough to permission check. */
 case 4:
 case 2:
+if ( currd->arch.monitor.guest_request_userspace_enabled &&
+eax == __HYPERVISOR_hvm_op &&
+(mode == 8 ? regs->rdi : regs->ebx) == 
HVMOP_guest_request_vm_event )
+break;
+
 if ( unlikely(hvm_get_cpl(curr)) )
 {
 default:
diff --git a/xen/common/monitor.c b/xen/common/monitor.c
index 451f42f..0c3e645 100644
--- a/xen/common/monitor.c
+++ b/xen/common/monitor.c
@@ -75,6 +75,7 @@ int monitor_domctl(struct domain *d, struct 
xen_domctl_monitor_op *mop)
 domain_pause(d);
 d->monitor.guest_request_sync = mop->u.guest_request.sync;
 d->monitor.guest_request_enabled = requested_status;
+arch_allow_userspace(>arch, mop->u.guest_request.allow_userspace);
 domain_unpause(d);
 break;
 }
diff --git a/xen/include/asm-arm/monitor.h b/xen/include/asm-arm/monitor.h
index 1c4fea3..a2eec52 100644
--- a/xen/include/asm-arm/monitor.h
+++ b/xen/include/asm-arm/monitor.h
@@ -26,6 +26,12 @@
 #include 
 
 static inline
+void arch_allow_userspace(struct arch_domain *arch, uint8_t allow_userspace)
+{
+return;
+}
+
+static inline
 int arch_monitor_domctl_op(struct domain *d, struct xen_domctl_monitor_op *mop)
 {
 /* No arch-specific monitor ops on ARM. */
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index c10522b..de02507 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -396,15 +396,16 @@ struct arch_domain
 
 /* Arch-specific monitor options */
 struct {
-unsigned int write_ctrlreg_enabled   : 4;
-unsigned int write_ctrlreg_sync  : 4;
-unsigned int write_ctrlreg_onchangeonly  : 4;
-unsigned int singlestep_enabled  : 1;
-unsigned int software_breakpoint_enabled : 1;
-unsigned int debug_exception_enabled : 1;
-unsigned int debug_exception_sync: 1;
-unsigned int

Re: [Xen-devel] [RFC PATCH 2/5] XL: Increase event channels to support more vcpus

2017-08-28 Thread Jan Beulich 
>>> On 28.08.17 at 11:11,  wrote:
> On 8/25/2017 6:04 PM, Wei Liu wrote:
>> On Fri, Aug 25, 2017 at 10:57:26AM +0100, Roger Pau Monné wrote:
>>> On Fri, Aug 25, 2017 at 10:18:24AM +0100, Wei Liu wrote:
 On Thu, Aug 24, 2017 at 10:52:17PM -0400, Lan Tianyu wrote:
> This patch is to increase event channels to support more vcpus in single 
> VM.
>
> Signed-off-by: Lan Tianyu 

 There is no need to bump the default. There is already a configuration
 option called max_event_channel.
>>>
>>> Maybe make this somehow based on the number of vCPUs assigned to the
>>> domain?
>>>
>>> It's not very used-friendly to allow the creation of a domain with 256
>>> vCPUs for example that would then get stuck during boot.
>>>
>>> Or at least check max_event_channel and the number of vCPUs and print
>>> a warning message to alert the user that things might go wrong with
>>> this configuration.
>>>
>> 
>> The problem is number of vcpu is only one factor that would affect the
>> number of event channels needed.
> 
> How about producing a warning about event channel maybe not enough when 
> vcpu number is >128 and still uses default max event channel number?

There would be nothing wrong with that for a guest not using
PV drivers, or not requiring multiple channels per vCPU. Hence
I'm not convinced a warning is appropriate here.

Jan

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

Re: [Xen-devel] [RFC PATCH 2/5] XL: Increase event channels to support more vcpus

2017-08-28 Thread Wei Liu 
On Mon, Aug 28, 2017 at 05:11:27PM +0800, Lan, Tianyu wrote:
> On 8/25/2017 6:04 PM, Wei Liu wrote:
> > On Fri, Aug 25, 2017 at 10:57:26AM +0100, Roger Pau Monné wrote:
> > > On Fri, Aug 25, 2017 at 10:18:24AM +0100, Wei Liu wrote:
> > > > On Thu, Aug 24, 2017 at 10:52:17PM -0400, Lan Tianyu wrote:
> > > > > This patch is to increase event channels to support more vcpus in 
> > > > > single VM.
> > > > > 
> > > > > Signed-off-by: Lan Tianyu 
> > > > 
> > > > There is no need to bump the default. There is already a configuration
> > > > option called max_event_channel.
> > > 
> > > Maybe make this somehow based on the number of vCPUs assigned to the
> > > domain?
> > > 
> > > It's not very used-friendly to allow the creation of a domain with 256
> > > vCPUs for example that would then get stuck during boot.
> > > 
> > > Or at least check max_event_channel and the number of vCPUs and print
> > > a warning message to alert the user that things might go wrong with
> > > this configuration.
> > > 
> > 
> > The problem is number of vcpu is only one factor that would affect the
> > number of event channels needed.
> 
> How about producing a warning about event channel maybe not enough when vcpu
> number is >128 and still uses default max event channel number?
> 

Maybe. If you're going to do that, please:

1. provide the heuristic in a function so that it can be expand later.
2. make the message system administrator friendly, point them to the
   max_event_channels option.

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

[Xen-devel] [distros-debian-sid test] 72031: tolerable trouble: blocked/broken/fail/pass

2017-08-28 Thread Platform Team regression test user 
flight 72031 distros-debian-sid real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72031/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken like 71997
 build-arm64   2 hosts-allocate   broken like 71997
 build-arm64-pvops 3 capture-logs broken like 71997
 build-arm64   3 capture-logs broken like 71997
 test-amd64-i386-i386-sid-netboot-pvgrub 11 guest-start fail like 71997
 test-amd64-amd64-amd64-sid-netboot-pvgrub 11 guest-start   fail like 71997
 test-armhf-armhf-armhf-sid-netboot-pygrub 10 debian-di-install fail like 71997

baseline version:
 flight   71997

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub pass
 test-arm64-arm64-armhf-sid-netboot-pygrubblocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubfail
 test-amd64-amd64-i386-sid-netboot-pygrub pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [RFC PATCH 3/5] Tool/ACPI: DSDT extension to support more vcpus

2017-08-28 Thread Lan, Tianyu 

On 8/25/2017 5:25 PM, Wei Liu wrote:

On Thu, Aug 24, 2017 at 10:52:18PM -0400, Lan Tianyu wrote:

This patch is to change DSDT table for processor object to support >255 vcpus.



Can you provide a link to the spec so people can check if you
modification is correct?



OK. Will add in the next version.


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

  1   2   >