date:20160621

[Xen-devel] [qemu-upstream-4.3-testing test] 96078: regressions - FAIL

2016-06-21 Thread osstest service owner

flight 96078 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96078/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 80927
 build-i386-libvirt5 libvirt-build fail REGR. vs. 80927

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  136 days
Failing since 93977  2016-05-10 11:09:16 Z   42 days  139 attempts
Testing same since95534  2016-06-11 00:59:46 Z   11 days   19 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   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


Not pushing.


commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15
Author: Ian Jackson 
Date:   Thu May 26 16:21:56 2016 +0100

main loop: Big hammer to fix logfile disk DoS in Xen setups

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread Juergen Gross

On 21/06/16 17:52, Boris Ostrovsky wrote:
> On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote:
>> Current overlap check is evaluating to false a case where a filter field
>> is fully contained (proper subset) of a r/w request.
>> This change applies classical overlap check instead to include
>> all the scenarios.
>>
>> Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
>>
>> Cc: Jan Beulich 
>> Cc: Boris Ostrovsky 
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Andrey Grodzovsky 
> 
> + David and Juergen (maintainers) and kernel list.
> 
> Reviewed-by: Boris Ostrovsky 

Acked-by: Juergen Gross 

> 
> 
>> ---
>>  drivers/xen/xen-pciback/conf_space.c | 6 ++
>>  1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/xen/xen-pciback/conf_space.c 
>> b/drivers/xen/xen-pciback/conf_space.c
>> index 8e67336..6a25533 100644
>> --- a/drivers/xen/xen-pciback/conf_space.c
>> +++ b/drivers/xen/xen-pciback/conf_space.c
>> @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int 
>> offset, int size,
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  err = conf_space_read(dev, cfg_entry, field_start,
>>_val);
>>  if (err)
>> @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
>> offset, int size, u32 value)
>>  field_start = OFFSET(cfg_entry);
>>  field_end = OFFSET(cfg_entry) + field->size;
>>  
>> -if ((req_start >= field_start && req_start < field_end)
>> -|| (req_end > field_start && req_end <= field_end)) {
>> + if (req_end > field_start && field_end > req_start) {
>>  tmp_val = 0;
>>  
>>  err = xen_pcibk_config_read(dev, field_start,
> 
> 
> 


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

[Xen-devel] sunxi U-boot Branch

2016-06-21 Thread Kamenee Arumugam

Hi All,

I am trying to build u-boot for cubieboards A20 with hypervisor support.
Eventually i will installing and loading xen in this board.

 I couldn't find *sunxi-next* branch that include hypervisor support in
current git repo ( git://github.com/jwrdegoede/u-boot-sunxi.git). Please
let me know if what is correct branch i need to use for creating uboot for
cubieboards A20 with hypervisor mode.

I am currently refering to this docs:
https://mirage.io/wiki/xen-on-cubieboard2 to build uboot here and below is
the description provided.
U-Boot

Xen needs to be started in non-secure HYP mode. Use this U-Boot Git
repository:

git clone git://github.com/jwrdegoede/u-boot-sunxi.git
cd u-boot-sunxi
git checkout -b sunxi-next origin/sunxi-next

*WARNING* This branch no longer exists.

Note: only the "sunxi-next" branch has the required hypervisor support; DO
NOT use the "sunxi" branch.


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

[Xen-devel] [xen-4.3-testing bisection] complete build-i386-libvirt

2016-06-21 Thread osstest service owner

branch xen-4.3-testing
xenbranch xen-4.3-testing
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt_gnulib git://git.sv.gnu.org/gnulib.git
  Bug introduced:  54615b95ff238e235e806855efc46a9abad09f2e
  Bug not present: e78f894d0bdc770101bc040613f4ea94e45f38f7
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/96090/


  commit 54615b95ff238e235e806855efc46a9abad09f2e
  Author: Paul Eggert 
  Date:   Sat Feb 6 18:11:48 2016 -0800
  
  misc: port better to gcc -fsanitize=address
  
  Without these patches, ./configure CFLAGS='-fsanitize=address'
  would compute incorrect values.  This patch fixes some (but not all)
  test failures with recent glibc, with this configuration.
  * m4/acl.m4 (gl_ACL_GET_FILE):
  * m4/calloc.m4 (_AC_FUNC_CALLOC_IF):
  * m4/canonicalize.m4 (gl_FUNC_REALPATH_WORKS):
  * m4/d-ino.m4 (gl_CHECK_TYPE_STRUCT_DIRENT_D_INO):
  * m4/duplocale.m4 (gl_FUNC_DUPLOCALE):
  * m4/getcwd.m4 (gl_FUNC_GETCWD_NULL):
  * m4/getdelim.m4 (gl_FUNC_GETDELIM):
  * m4/getgroups.m4 (gl_FUNC_GETGROUPS):
  * m4/getline.m4 (gl_FUNC_GETLINE):
  * m4/malloc.m4 (_AC_FUNC_MALLOC_IF):
  * m4/realloc.m4 (_AC_FUNC_REALLOC_IF):
  * m4/regex.m4 (gl_REGEX):
  * m4/strndup.m4 (gl_FUNC_STRNDUP):
  * tests/test-calloc-gnu.c (main):
  * tests/test-duplocale.c (main):
  * tests/test-getgroups.c (main):
  * tests/test-getline.c (main):
  * tests/test-inttostr.c (main):
  * tests/test-localename.c (test_locale_name)
  (test_locale_name_thread, test_locale_name_environ)
  (test_locale_name_default):
  * tests/test-regex.c (main):
  * tests/test-setlocale1.c (main):
  * tests/test-stat.h (test_stat_func):
  Free heap-allocated storage before exiting.
  * m4/asm-underscore.m4 (gl_ASM_SYMBOL_PREFIX):
  Don't match *_foo symbols inserted by AddressSanitizer.
  * tests/test-regex.c, tests/test-stat.c: Include stdlib.h, for 'free'.


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.3-testing/build-i386-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.3-testing/build-i386-libvirt.libvirt-build
 --summary-out=tmp/96090.bisection-summary --basis-template=87893 
--blessings=real,real-bisect xen-4.3-testing build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 96042 fail [host=huxelrebe0] / 87893 ok.
Failure / basis pass flights: 96042 / 87893
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest eac167e2610d3e59b32f7ec7ba78cbc8c420a425 
246b3b28808ee5f4664be674dce573af9497fc7a 
e8f93ac464eced5964393c543aa68382031b363a 
10c1b763c26feb645627a1639e722515f3e1e876 
0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
Basis pass b77cec09db67aff75313b53c931ad15c1aba27bd 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
b96625e17169a7958575c2fb41499bb9ea2c212e 
10c1b763c26feb645627a1639e722515f3e1e876 
8fa31952e2d08ef63897c43b5e8b33475ebf5d93
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#b77cec09db67aff75313b53c931ad15c1aba27bd-eac167e2610d3e59b32f7ec7ba78cbc8c420a425
 
git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-246b3b28808ee5f4664be674dce573af9497fc7a
 
git://xenbits.xen.org/qemu-xen-traditional.git#b96625e17169a7958575c2fb41499bb9ea2c212e-e8f93ac464eced5964393c543aa68382031b363a
 
git://xenbits.xen.org/qemu-xen.git#10c1b763c26feb645627a1639e722515f3e1e876-10c1b763c26feb645627a1639e722515f3e1e876
 
git://xenbits.xen.org/xen.git#8fa31952e2d08ef63897c43b5e8b33475ebf5d93-0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
adhoc-revtuple-generator: tree discontiguous: libvirt
Loaded 4744 nodes in revision graph
Searching for test results:
 87893 pass b77cec09db67aff75313b53c931ad15c1aba27bd 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
b96625e17169a7958575c2fb41499bb9ea2c212e 
10c1b763c26feb645627a1639e722515f3e1e876 
8fa31952e2d08ef63897c43b5e8b33475ebf5d93
 96017 fail eac167e2610d3e59b32f7ec7ba78cbc8c420a425 
246b3b28808ee5f4664be674dce573af9497fc7a 
e8f93ac464eced5964393c543aa68382031b363a 
10c1b763c26feb645627a1639e722515f3e1e876 
0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
 96088 pass b77cec09db67aff75313b53c931ad15c1aba27bd 
e78f894d0bdc770101bc040613f4ea94e45f38f7

Re: [Xen-devel] [PATCH RESEND 04/14] tools: add ACPI tables relevant definitions

2016-06-21 Thread Shannon Zhao



On 2016/6/6 20:16, Wei Liu wrote:
> On Mon, Jun 06, 2016 at 06:27:25PM +0800, Shannon Zhao wrote:
>> > 
>> > 
>> > On 2016/6/6 18:11, Julien Grall wrote:
>>> > > Hi Stefano,
>>> > > 
>>> > > On 06/06/2016 11:04, Stefano Stabellini wrote:
 > >> On Tue, 31 May 2016, Shannon Zhao wrote:
> > >>> From: Shannon Zhao 
> > >>>
> > >>> Add ACPI tables relevant definitions for generating ACPI tables for 
> > >>> ARM
> > >>> guest later. Currently RSDP, XSDT, GTDT, MADT, FADT and DSDT tables 
> > >>> will
> > >>> be used.
> > >>>
> > >>> Signed-off-by: Shannon Zhao 
> > >>> ---
> > >>>  tools/libxc/include/acpi_defs.h | 277
> > >>> 
> > >>>  1 file changed, 277 insertions(+)
> > >>>  create mode 100644 tools/libxc/include/acpi_defs.h
> > >>>
> > >>> diff --git a/tools/libxc/include/acpi_defs.h
> > >>> b/tools/libxc/include/acpi_defs.h
> > >>> new file mode 100644
> > >>> index 000..9389a96
> > >>> --- /dev/null
> > >>> +++ b/tools/libxc/include/acpi_defs.h
> > >>> @@ -0,0 +1,277 @@
> > >>> +#ifndef _ACPI_DEFS_H_
> > >>> +#define _ACPI_DEFS_H_
> > >>> +
> > >>> +#define ACPI_BUILD_APPNAME6 "XenARM"
> > >>> +#define ACPI_BUILD_APPNAME4 "Xen "
 > >>
 > >> This header is actually ARM specific (also see the gic stuff below). 
 > >> It
 > >> is probably best to rename it to acpi_arm_defs.h.
>>> > > 
>>> > > Should not just we re-use the ACPI headers from xen/include/acpi/ ?
>> > So how to include those headers in tools/libxl/libxl_arm.c ?
>> > 
> Is it public headers? If so, it might already be available in
> tools/include. If not, is it feasible to be made public?
> 
> If in the end the file you need can't end up as a public header, you
> need to manipulate CFLAGS. There is one example in libxc's Makefile.
> Search for libelf.
> 
> But please make sure the CFLAGS doesn't get modified when it is not
> necessary.  I would expect the CFLAGS is explicitly altered for a list
> of files.
I'm trying to do this. Make the libxl acpi codes compile like below in
Makefile:

+libxl_arm_acpi.o: libxl_arm_acpi.c
+   $(CC) -c $(CFLAGS) -I../../xen/include/ -o $@ libxl_arm_acpi.c

Add #include  which includes the tables definitions in
libxl_arm_acpi.c. But there are a lot of compiling errors like below:
error: unknown type name 'u8'
error: unknown type name 'u32'
Looks like these types are defined in xen/include/asm-arm/types.h. I add
#include  in libxl_arm_acpi.c but it still compiles failed.
In file included from ../../xen/include/asm-arm/types.h:6:0,
 from libxl_arm_acpi.c:30:
../../xen/include/xen/config.h:10:32: fatal error: generated/autoconf.h:
No such file or directory
 #include 

Looks like if we try to use the acpi headers under xen/include/acpi like
this way, tools compilation will depends on hypervisor compilation. I
think this is not what we want, right?

Any suggestion?

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v9 1/3] vt-d: fix the IOMMU flush issue

2016-06-21 Thread Xu, Quan

On June 21, 2016 9:25 PM, Jan Beulich  wrote:
> >>> On 17.06.16 at 05:37,  wrote:
> > @@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void)
> >  struct acpi_drhd_unit *drhd;
> >  struct iommu *iommu;
> >  int flush_dev_iotlb;
> > +int rc = 0;
> >
> >  flush_all_cache();
> >  for_each_drhd_unit ( drhd )
> >  {
> > +int context_rc, iotlb_rc;
> > +
> >  iommu = drhd->iommu;
> > -iommu_flush_context_global(iommu, 0);
> > +context_rc = iommu_flush_context_global(iommu, 0);
> >  flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> > -iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> > +iotlb_rc = iommu_flush_iotlb_global(iommu, 0,
> > + flush_dev_iotlb);
> > +
> > +/*
> > + * The current logic for returns:
> > + *   - positive  invoke iommu_flush_write_buffer to flush cache.
> > + *   - zero  on success.
> > + *   - negative  on failure. Continue to flush IOMMU IOTLB on a
> > + *   best effort basis.
> > + */
> > +if ( context_rc > 0 || iotlb_rc > 0 )
> > +iommu_flush_write_buffer(iommu);
> > +if ( context_rc >= 0 )
> 
> Wasn't this meant to be just "rc"? (I can't, btw, imagine Kevin's ack to be
> rightfully retained with a change like this.)
>
SORRY, it is 'rc'. It is really my mistake here, but Kevin's ack is right as 
the previous v8 was:

+if ( rc >= 0 )
+rc = iommu_rc;
+if ( rc >= 0 )
+rc = iommu_ret;

,, I will send it out again with this fix.

Quan

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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Jim Fehlig

On 06/21/2016 09:53 AM, George Dunlap wrote:
> On 21/06/16 16:11, Ian Jackson wrote:
>> Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"):
>>> Here is what we have gathered so far:
>> ...
>>> We can, however, just make recommendation that system administrators can
>>> easily set up and call it a day. There are suggestions that we can
>>> recommend conserver or sympathy, but I haven't seen a concrete viable
>>> proposal yet. What I hope is that we can have a document in tree in the
>>> end.
>> sympathy would need some extra engineering to become suitable.  It's
>> also not widely adopted.  (Not even in Debian, yet.  Sorry about that,
>> but in my defence it's not my project...)
>>
>>> Another way is to invent our own "virtlogd" -- it could be a new daemon,
>>> it could be xenconsoled. The major concern is that we're adding a
>>> critical component to the system and it may not scale well. We can make
>>> a compromise by using non-blocking fd to make the new component less
>>> critical and doesn't hinder scalability.
>> I think this is probably the best answer.  We already have most of
>> this in the form of xenconsoled.
>>
>>> Another way is to alter libxl API and ask the application to pass in a
>>> fd for logging. The major concern is that this is not suitable in the
>>> context of a security issue.
>> Any solution needs to work for xl as well as other users of libxl.  So
>> this is not a description of a solution option; rather it is a
>> proposal to move the functionality/glue/problem/whatever out of libxl
>> into xl.
> ...or libvirt, or xapi (should it ever be ported to libxl).
>
> I think that having the option to pass an fd in would be useful and will
> probably be wanted at some point; I think libvirt for instance should
> probably be modified to use such an interface once it's available to
> connect qemu to virtlogd.

It would be easy enough to do since the qemu driver is already doing this.

Regards,
Jim


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

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

2016-06-21 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 94748
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 94748

version targeted for testing:
 ovmf 5e32460d8050fbc088230183151865c671a4e2df
baseline version:
 ovmf dc99315b8732b6e3032d01319d3f534d440b43d0

Last test of basis94748  2016-05-24 22:43:25 Z   27 days
Failing since 94750  2016-05-25 03:43:08 Z   27 days   49 attempts
Testing same since96050  2016-06-21 08:32:38 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Chao Zhang 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Darbin Reyes 
  Eric Dong 
  Eugene Cohen 
  Evan Lloyd 
  Fu Siyuan 
  Fu, Siyuan 
  Gary Li 
  Gary Lin 
  Giri P Mudusuru 
  Hao Wu 
  Hegde Nagaraj P 
  hegdenag 
  Heyi Guo 
  Jeff Fan 
  Jiaxin Wu 
  Jiewen Yao 
  Katie Dellaquila 
  Laszlo Ersek 
  Liming Gao 
  Lu, ShifeiX A 
  lushifex 
  Marvin H?user 
  Marvin Haeuser 
  Maurice Ma 
  Michael Zimmermann 
  Ruiyu Ni 
  Ryan Harkin 
  Sami Mujawar 
  Satya Yarlagadda 
  Sriram Subramanian 
  Star Zeng 
  Tapan Shah 
  Thomas Palmer 
  Yonghong Zhu 
  Zhang, Chao B 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

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

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  c6f7d21747805b50123fc1b8d73518fea2aa9096
baseline version:
 xen  b49839ef4e6ba183503912d169df7635e1c6df54

Last test of basis96064  2016-06-21 15:05:01 Z0 days
Testing same since96071  2016-06-21 18:01:52 Z0 days2 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Julien Grall 

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



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

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

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

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


Pushing revision :

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

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

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  0630892fafe87ff5e3b65422d38158de46db3ed0
baseline version:
 xen  08754333892407f415045c05659783baeb8fc5d4

Last test of basis95980  2016-06-20 01:59:52 Z1 days
Failing since 96009  2016-06-20 13:12:31 Z1 days2 attempts
Testing same since96049  2016-06-21 07:57:44 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 
  Julien Grall 
  Shanker Donthineni 
  Stefano Stabellini 
  Wei Liu 

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

[Xen-devel] [qemu-upstream-4.3-testing test] 96052: regressions - FAIL

2016-06-21 Thread osstest service owner

flight 96052 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/96052/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 80927
 build-i386-libvirt5 libvirt-build fail REGR. vs. 80927

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  136 days
Failing since 93977  2016-05-10 11:09:16 Z   42 days  138 attempts
Testing same since95534  2016-06-11 00:59:46 Z   10 days   18 attempts


People who touched revisions under test:
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   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


Not pushing.


commit 12e8fccf5b5460be7aecddc71d27eceaba6e1f15
Author: Ian Jackson 
Date:   Thu May 26 16:21:56 2016 +0100

main loop: Big hammer to fix logfile disk DoS in Xen setups

Re: [Xen-devel] [PATCH v2] x86/HVM: use available linear->phys translations in REP MOVS/STOS handling

2016-06-21 Thread Andrew Cooper

On 20/06/16 12:29, Jan Beulich wrote:
> If we have the translation result available already, we should also use
> it here. In my tests with Linux guests this eliminates all calls to
> hvmemul_linear_to_phys() from the STOS path and most from the MOVS one.
>
> Also record the translation for re-use at least during response
> processing.
>
> Signed-off-by: Jan Beulich 

This patch is still broken.  All XenServer HVM guests (both windows and
linux) are dying, with Qemu citing

I/O request not read: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0


The domain still exists, but it looks like it never gets unpaused from
the device model request.

~Andrew

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

[Xen-devel] [xen-unstable-smoke test] 96071: regressions - FAIL

2016-06-21 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 96064

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

version targeted for testing:
 xen  c6f7d21747805b50123fc1b8d73518fea2aa9096
baseline version:
 xen  b49839ef4e6ba183503912d169df7635e1c6df54

Last test of basis96064  2016-06-21 15:05:01 Z0 days
Testing same since96071  2016-06-21 18:01:52 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Julien Grall 

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


Not pushing.


commit c6f7d21747805b50123fc1b8d73518fea2aa9096
Author: Daniel De Graaf 
Date:   Mon Jun 20 10:04:21 2016 -0400

xen/xsm: remove .xsm_initcall.init section

Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex.  Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and that can be placed in xsm_core.c.

Signed-off-by: Daniel De Graaf 
Reviewed-by: Doug Goldstein 
Reviewed-by: Andrew Cooper 
Acked-by: Julien Grall 

commit 56fef9e367b250a3c6ff16b6c4494c5103ac4871
Author: Daniel De Graaf 
Date:   Mon Jun 20 10:04:20 2016 -0400

flask: improve unknown permission handling

When an unknown domctl, sysctl, or other operation is encountered in the
FLASK security server, use the allow_unknown bit in the security policy
to decide if the permission should be allowed or denied.  This allows
new operations to be tested without needing to immediately add security
checks; however, it is not flexible enough to avoid adding the actual
permission checks.  An error message is printed to the hypervisor
console when this fallback is encountered.

This patch will allow operations that are not handled by the existing
hooks only if the policy was compiled with "checkpolicy -U allow".  In
previous releases, this bit did nothing, and the default remains to deny
the unknown operations.

Signed-off-by: Daniel De Graaf 
Reviewed-by: Doug Goldstein 

commit 559f439bfa3bf931414534ec0c46e5e8a21fa3ba
Author: Daniel De Graaf 
Date:   Mon Jun 20 10:04:19 2016 -0400

flask: remove xen_flask_userlist operation

This operation has no known users, and is primarily useful when an MLS
policy is in use (which has never been shipped with Xen).  In addition,
the information it provides does not actually depend on hypervisor
state (only on the XSM policy), so an application that needs it could
compute the results without needing to involve the hypervisor.

Signed-off-by: Daniel De Graaf 
Acked-by: Jan Beulich 
Reviewed-by: Doug Goldstein 

commit d18224766fa2e6e0746e8c9e759a8e0cc8c87129
Author: Daniel De Graaf 
Date:   Mon Jun 20 10:04:18 2016 -0400

flask: remove unused AVC callback functions

These callbacks are not used in Xen.

Signed-off-by: Daniel De Graaf

Re: [Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

2016-06-21 Thread Boris Ostrovsky

On 06/21/2016 12:09 PM, David Vrabel wrote:
> When page tables entries are set using xen_set_pte_init() during early
> boot there is no page fault handler that could handle a fault when
> performing an M2P lookup.
>
> In 64 guest (usually dom0) early_ioremap() would fault in
> xen_set_pte_init() because an M2P lookup faults because the MFN is in
> MMIO space and not mapped in the M2P.  This lookup is done to see if
> the PFN in in the range used for the initial page table pages, so that
> the PTE may be set as read-only.
>
> The M2P lookup can be avoided by moving the check (and clear of RW)
> earlier when the PFN is still available.
>
> Signed-off-by: David Vrabel 
> Tested-by: Keven Moraga 
> ---
> v2:
>
> - Remove __init annotation from xen_make_pte_init() since
>   PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.
>
> - mask_rw_pte() -> mask_rw_pteval() for x86-64.

I don't think you actually renamed the routine.

> ---
>  arch/x86/xen/mmu.c | 28 +---
>  1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
> index 478a2de..e47bc19 100644
> --- a/arch/x86/xen/mmu.c
> +++ b/arch/x86/xen/mmu.c
> @@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
>   return pte;
>  }
>  #else /* CONFIG_X86_64 */
> -static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
> +static pteval_t __init mask_rw_pte(pteval_t pte)
>  {
>   unsigned long pfn;
>  
> @@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t 
> pte)
>* page tables for mapping the p2m list, too, and page tables MUST be
>* mapped read-only.
>*/
> - pfn = pte_pfn(pte);
> + pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;

Is it obvious that we are holding valid PFN at this point? It wasn't
immediately obvious to me so I wonder whether a comment stating this
would be useful here (yes, you mention it in the commit messages).

-boris

>   if (pfn >= xen_start_info->first_p2m_pfn &&
>   pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
> - pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
> + pte &= ~_PAGE_RW;
>  
>   return pte;
>  }
> @@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t 
> pte)
>   * so always write the PTE directly and rely on Xen trapping and
>   * emulating any updates as necessary.
>   */
> +__visible pte_t xen_make_pte_init(pteval_t pte)
> +{
> +#ifdef CONFIG_X86_64
> + pte = mask_rw_pte(pte);
> +#endif
> + pte = pte_pfn_to_mfn(pte);
> +
> + if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
> + pte = 0;
> +
> + return native_make_pte(pte);
> +}
> +PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
> +
>  static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
>  {
> +#ifdef CONFIG_X86_32
>   if (pte_mfn(pte) != INVALID_P2M_ENTRY)
>   pte = mask_rw_pte(ptep, pte);
> - else
> - pte = __pte_ma(0);
> -
> +#endif
>   native_set_pte(ptep, pte);
>  }
>  
> @@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
>   pv_mmu_ops.alloc_pud = xen_alloc_pud;
>   pv_mmu_ops.release_pud = xen_release_pud;
>  #endif
> + pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
>  
>  #ifdef CONFIG_X86_64
>   pv_mmu_ops.write_cr3 = _write_cr3;
> @@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst 
> = {
>   .pte_val = PV_CALLEE_SAVE(xen_pte_val),
>   .pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
>  
> - .make_pte = PV_CALLEE_SAVE(xen_make_pte),
> + .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
>   .make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
>  
>  #ifdef CONFIG_X86_PAE



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

[Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread Andrey Grodzovsky

Current overlap check is evaluating to false a case where a filter field
is fully contained (proper subset) of a r/w request.
This change applies classical overlap check instead to include
all the scenarios.

More specifically, for (Hilscher GmbH CIFX 50E-DP(M/S)) device
driver the logic is such that the entire confspace  is read and
written in 4 byte chunks.In this case as an example, CACHE_LINE_SIZE,
LATENCY_TIMER and PCI_BIST are arriving together in one call to
xen_pcibk_config_write with offset == 0xc and size == 4.
With the exsisting overlap check LATENCY_TIMER field
(offset == 0xd, length == 1) is fully contained in the write request
and hence is excluded from write, which is incorrect.

Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html

Reviewed-by: Boris Ostrovsky 
Reviewed-by: David Vrabel 
Cc: Jan Beulich 
Cc: Boris Ostrovsky 
Cc: sta...@vger.kernel.org
Signed-off-by: Andrey Grodzovsky 
---
 drivers/xen/xen-pciback/conf_space.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/conf_space.c 
b/drivers/xen/xen-pciback/conf_space.c
index 8e67336..6a25533 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int offset, 
int size,
field_start = OFFSET(cfg_entry);
field_end = OFFSET(cfg_entry) + field->size;
 
-   if ((req_start >= field_start && req_start < field_end)
-   || (req_end > field_start && req_end <= field_end)) {
+if (req_end > field_start && field_end > req_start) {
err = conf_space_read(dev, cfg_entry, field_start,
  _val);
if (err)
@@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int offset, 
int size, u32 value)
field_start = OFFSET(cfg_entry);
field_end = OFFSET(cfg_entry) + field->size;
 
-   if ((req_start >= field_start && req_start < field_end)
-   || (req_end > field_start && req_end <= field_end)) {
+if (req_end > field_start && field_end > req_start) {
tmp_val = 0;
 
err = xen_pcibk_config_read(dev, field_start,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread Andrey Grodzovsky

On Tue, Jun 21, 2016 at 1:15 PM, David Vrabel 
wrote:

> On 21/06/16 15:37, Andrey Grodzovsky wrote:
> > Current overlap check is evaluating to false a case where a filter field
> > is fully contained (proper subset) of a r/w request.
> > This change applies classical overlap check instead to include
> > all the scenarios.
>
> Reviewed-by: David Vrabel 
>
> But the commit message could do with a concrete example of an access
> that failed.
>
> David


Thanks, will update the commit message and resubmit.

Andrey

>



>
> > Related to
> https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
> >
> > Cc: Jan Beulich 
> > Cc: Boris Ostrovsky 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Andrey Grodzovsky 
> > ---
> >  drivers/xen/xen-pciback/conf_space.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/xen/xen-pciback/conf_space.c
> b/drivers/xen/xen-pciback/conf_space.c
> > index 8e67336..6a25533 100644
> > --- a/drivers/xen/xen-pciback/conf_space.c
> > +++ b/drivers/xen/xen-pciback/conf_space.c
> > @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int
> offset, int size,
> >   field_start = OFFSET(cfg_entry);
> >   field_end = OFFSET(cfg_entry) + field->size;
> >
> > - if ((req_start >= field_start && req_start < field_end)
> > - || (req_end > field_start && req_end <= field_end)) {
> > +  if (req_end > field_start && field_end > req_start) {
> >   err = conf_space_read(dev, cfg_entry, field_start,
> > _val);
> >   if (err)
> > @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int
> offset, int size, u32 value)
> >   field_start = OFFSET(cfg_entry);
> >   field_end = OFFSET(cfg_entry) + field->size;
> >
> > - if ((req_start >= field_start && req_start < field_end)
> > - || (req_end > field_start && req_end <= field_end)) {
> > +  if (req_end > field_start && field_end > req_start) {
> >   tmp_val = 0;
> >
> >   err = xen_pcibk_config_read(dev, field_start,
> >
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] x86: compact supposedly unused entry point code

2016-06-21 Thread Andrew Cooper

On 20/06/16 15:04, Jan Beulich wrote:
 On 20.06.16 at 15:58,  wrote:
>> On 20/06/16 14:49, Jan Beulich wrote:
>> On 20.06.16 at 14:54,  wrote:
 On 20/06/16 13:48, Jan Beulich wrote:
 On 20.06.16 at 14:15,  wrote:
>> On 20/06/16 12:04, Jan Beulich wrote:
>>> No point in aligning entry points which aren't supposed to be used
>>> anyway.
>>>
>>> Signed-off-by: Jan Beulich 
>> Reviewed-by: Andrew Cooper 
> Thanks, but - any thoughts on this part:
>
> TBD: Might consider simply using "andq $-15,%rsp", delivering an
> uninitialized error code (which shouldn't matter).
 I was still considering that part.

 These are entries we never expect to actually take.  At that point, the
 small overhead of setting up the error code to 0 is probably better than
 leaving it uninitialised.
>>> I understand - it's really a matter of balancing the overhead on
>>> these paths (which will never have an effect if these entries indeed
>>> are unused, and which is of no interest if they are used by due some
>>> other flaw) with the (likely negligible, but non-zero) overhead they
>>> introduce on _other_ paths (due to cache and TLB consumption). I.e.
>>> my goal was to make these unused entries as small as possible. And
>>>
>>> andq$-15,%rsp
>>> movl$vector,4(%rsp)
>>>
>>> (obviously we can't use movb here) is smaller than the current
>>>
>>> testb   $8,%spl
>>> jz  1f
>>> pushq   $0
>>> movb$vector,4(%rsp)
>>>
>>> afaict.
>> All of them head to do_reserved_trap() and panic().
> Not sure I'm guessing right what you mean to say with that, so I
> can only reiterate that I don't care at all how long it takes for
> execution to get through this path. All I care about is that this
> code be as small as possible, to limit its impact on surrounding
> code. But for the few bytes to save here I guess there was
> already way to much talk.
>
>> An alternative would be to drop all this entry code, mark the vectors as
>> not present in the IDT, and handle #NP[IDT vector] with a slightly
>> different error message in do_trap().
> Would likely increase overall code size (i.e. the opposite of what
> I'd like to achieve here).

I find that hard to believe.

I have a number of other improvements pending in this area.  I will add
this to the list.

~Andrew

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

Re: [Xen-devel] [PATCH 4/4] x86/vMSI-X: use generic intercept handler in place of MMIO one

2016-06-21 Thread Andrew Cooper

On 08/06/16 13:54, Jan Beulich wrote:
> This allows us to see the full ioreq without having to peek into state
> which is supposedly private to the emulation framework.
>
> Suggested-by: Paul Durrant 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper , with two minor
style corrections.

> @@ -333,23 +332,29 @@ out:
>  return r;
>  }
>  
> -static int msixtbl_range(struct vcpu *v, unsigned long addr)
> +static int _msixtbl_write(const struct hvm_io_handler *handler,
> + uint64_t address, uint32_t len, uint64_t val)

Indentation.

> @@ -396,10 +401,10 @@ static int msixtbl_range(struct vcpu *v,
>  return 0;
>  }
>  
> -static const struct hvm_mmio_ops msixtbl_mmio_ops = {
> -.check = msixtbl_range,
> +static const struct hvm_io_ops msixtbl_mmio_ops = {
> +.accept = msixtbl_range,
>  .read = msixtbl_read,
> -.write = msixtbl_write
> +.write = _msixtbl_write

Trailing comma.

~Andrew

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

Re: [Xen-devel] [PATCH 3/4] x86/vMSI-X: drop pci_msix_get_table_len()

2016-06-21 Thread Andrew Cooper

On 08/06/16 13:54, Jan Beulich wrote:
> We can calculate the needed value at the single use site more easily.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/4] x86/vMSI-X: drop list lock

2016-06-21 Thread Andrew Cooper

On 08/06/16 13:53, Jan Beulich wrote:
> msixtbl_pt_{,un}register() already run with both the PCI devices lock
> and the domain event lock held, so there's no need for another lock.
> Just to be on the safe side, acquire the domain event lock in the
> cleanup function (albeit I don't think this is strictly necessary).
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

2016-06-21 Thread Andrew Cooper

On 21/06/16 18:19, Konrad Rzeszutek Wilk wrote:
> On Tue, Jun 21, 2016 at 05:59:04PM +0100, Andrew Cooper wrote:
>> Its contents is constant.
>>
> Could you mention why you don't need the ALIGN(32).

Because there is no content following it, before a larger alignment.

~Andrew

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

Re: [Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

2016-06-21 Thread Konrad Rzeszutek Wilk

On Tue, Jun 21, 2016 at 05:59:04PM +0100, Andrew Cooper wrote:
> Its contents is constant.
> 

Could you mention why you don't need the ALIGN(32).

Thanks.

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

Re: [Xen-devel] [PATCH v2 2/4] arm/init: Move .init.proc.info into .init.data

2016-06-21 Thread Konrad Rzeszutek Wilk

On Tue, Jun 21, 2016 at 05:59:03PM +0100, Andrew Cooper wrote:
> Its contents is constant, and only requires pointer alignment, so move it
> adacent to .init.setup.

adjacent

with that Reviewed-by: Konrad Rzeszutek Wilk 

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

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

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b49839ef4e6ba183503912d169df7635e1c6df54
baseline version:
 xen  57a57465daaf8fb66d192ff98b8477524091e82c

Last test of basis96055  2016-06-21 11:02:43 Z0 days
Testing same since96064  2016-06-21 15:05:01 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread David Vrabel

On 21/06/16 15:37, Andrey Grodzovsky wrote:
> Current overlap check is evaluating to false a case where a filter field
> is fully contained (proper subset) of a r/w request.
> This change applies classical overlap check instead to include
> all the scenarios.

Reviewed-by: David Vrabel 

But the commit message could do with a concrete example of an access
that failed.

David

> 
> Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
> 
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrey Grodzovsky 
> ---
>  drivers/xen/xen-pciback/conf_space.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/xen/xen-pciback/conf_space.c 
> b/drivers/xen/xen-pciback/conf_space.c
> index 8e67336..6a25533 100644
> --- a/drivers/xen/xen-pciback/conf_space.c
> +++ b/drivers/xen/xen-pciback/conf_space.c
> @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int 
> offset, int size,
>   field_start = OFFSET(cfg_entry);
>   field_end = OFFSET(cfg_entry) + field->size;
>  
> - if ((req_start >= field_start && req_start < field_end)
> - || (req_end > field_start && req_end <= field_end)) {
> +  if (req_end > field_start && field_end > req_start) {
>   err = conf_space_read(dev, cfg_entry, field_start,
> _val);
>   if (err)
> @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
> offset, int size, u32 value)
>   field_start = OFFSET(cfg_entry);
>   field_end = OFFSET(cfg_entry) + field->size;
>  
> - if ((req_start >= field_start && req_start < field_end)
> - || (req_end > field_start && req_end <= field_end)) {
> +  if (req_end > field_start && field_end > req_start) {
>   tmp_val = 0;
>  
>   err = xen_pcibk_config_read(dev, field_start,
> 


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

Re: [Xen-devel] [PATCH 1/4] x86/vMSI-X: defer intercept handler registration

2016-06-21 Thread Andrew Cooper

On 08/06/16 13:52, Jan Beulich wrote:
> There's no point in registering the internal MSI-X table intercept
> functions on all domains - it is sufficient to do so once a domain gets
> an MSI-X capable device assigned.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

[Xen-devel] [PATCH 13/17 v3] xen: move FLASK entry under XSM in Kconfig

2016-06-21 Thread Daniel De Graaf

Since enabling XSM is required to enable FLASK, place the option for
FLASK below the one for XSM.  In addition, since it does not make sense
to enable XSM without any XSM providers, and FLASK is the only XSM
provider, hide the option to disable FLASK under EXPERT.

Signed-off-by: Daniel De Graaf 
---

Changes from v2: use def_bool/prompt instead of def_bool/bool so that it
  matches the other "if EXPERT" items in this file

 xen/common/Kconfig | 37 +++--
 1 file changed, 19 insertions(+), 18 deletions(-)

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index cd59574..faee3ec 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -11,24 +11,6 @@ config COMPAT
 config CORE_PARKING
bool
 
-config FLASK
-   bool "FLux Advanced Security Kernel support"
-   default y
-   depends on XSM
-   ---help---
- Enables the FLASK (FLux Advanced Security Kernel) support which
- provides a mandatory access control framework by which security
- enforcement, isolation, and auditing can be achieved with fine
- granular control via a security policy.
-
- If unsure, say N.
-
-config FLASK_AVC_STATS
-   def_bool y
-   depends on FLASK
-   ---help---
- Maintain statistics on the access vector cache
-
 # Select HAS_DEVICE_TREE if device tree is supported
 config HAS_DEVICE_TREE
bool
@@ -137,6 +119,25 @@ config XSM
 
  If unsure, say N.
 
+config FLASK
+   def_bool y
+   prompt "FLux Advanced Security Kernel support" if EXPERT = "y"
+   depends on XSM
+   ---help---
+ Enables FLASK (FLux Advanced Security Kernel) as the access control
+ mechanism used by the XSM framework.  This provides a mandatory access
+ control framework by which security enforcement, isolation, and
+ auditing can be achieved with fine granular control via a security
+ policy.
+
+ If unsure, say Y.
+
+config FLASK_AVC_STATS
+   def_bool y
+   depends on FLASK
+   ---help---
+ Maintain statistics on the access vector cache
+
 # Enable schedulers
 menu "Schedulers"
visible if EXPERT = "y"
-- 
2.7.4


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

[Xen-devel] [PATCH v2 3/4] xen/init: Move initcall infrastructure into .init.data

2016-06-21 Thread Andrew Cooper

Its contents is constant.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

v2:
 * New
---
 xen/arch/arm/xen.lds.S | 14 ++
 xen/arch/x86/xen.lds.S | 14 ++
 xen/include/xen/init.h |  4 ++--
 3 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index b00ee81..b18c9c2 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -145,6 +145,12 @@ SECTIONS
*(.init.proc.info)
__proc_info_end = .;
 
+   __initcall_start = .;
+   *(.initcallpresmp.init)
+   __presmp_initcall_end = .;
+   *(.initcall1.init)
+   __initcall_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -154,14 +160,6 @@ SECTIONS
*(.init_array)
__ctors_end = .;
   } :text
-  . = ALIGN(32);
-  .initcall.init : {
-   __initcall_start = .;
-   *(.initcallpresmp.init)
-   __presmp_initcall_end = .;
-   *(.initcall1.init)
-   __initcall_end = .;
-  } :text
   __init_end_efi = .;
   . = ALIGN(STACK_SIZE);
   __init_end = .;
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 2443b93..a1678d8 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -158,6 +158,12 @@ SECTIONS
*(.init.setup)
__setup_end = .;
 
+   __initcall_start = .;
+   *(.initcallpresmp.init)
+   __presmp_initcall_end = .;
+   *(.initcall1.init)
+   __initcall_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -183,14 +189,6 @@ SECTIONS
*(.ctors)
__ctors_end = .;
   } :text
-  . = ALIGN(32);
-  .initcall.init : {
-   __initcall_start = .;
-   *(.initcallpresmp.init)
-   __presmp_initcall_end = .;
-   *(.initcall1.init)
-   __initcall_end = .;
-  } :text
   . = ALIGN(PAGE_SIZE);
   __init_end = .;
 
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index b04bcf9..0afc430 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -61,9 +61,9 @@ typedef int (*initcall_t)(void);
 typedef void (*exitcall_t)(void);
 
 #define presmp_initcall(fn) \
-static initcall_t __initcall_##fn __init_call("presmp") = fn
+const static initcall_t __initcall_##fn __init_call("presmp") = fn
 #define __initcall(fn) \
-static initcall_t __initcall_##fn __init_call("1") = fn
+const static initcall_t __initcall_##fn __init_call("1") = fn
 #define __exitcall(fn) \
 static exitcall_t __exitcall_##fn __exit_call = fn
 
-- 
2.1.4


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

[Xen-devel] [PATCH v2 2/4] arm/init: Move .init.proc.info into .init.data

2016-06-21 Thread Andrew Cooper

Its contents is constant, and only requires pointer alignment, so move it
adacent to .init.setup.

Signed-off-by: Andrew Cooper 
---
CC: Stefano Stabellini 
CC: Julien Grall 

v2:
 * New
---
 xen/arch/arm/xen.lds.S | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 2ed7dee..b00ee81 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -141,6 +141,10 @@ SECTIONS
*(.init.setup)
__setup_end = .;
 
+   __proc_info_start = .;
+   *(.init.proc.info)
+   __proc_info_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -151,11 +155,6 @@ SECTIONS
__ctors_end = .;
   } :text
   . = ALIGN(32);
-  .init.proc.info : {
-   __proc_info_start = .;
-   *(.init.proc.info)
-   __proc_info_end = .;
-  } :text
   .initcall.init : {
__initcall_start = .;
*(.initcallpresmp.init)
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/4] x86/boot: copy/clear sections more efficiently

2016-06-21 Thread Andrew Cooper

Both the trampoline copy and BSS initialise can be performed more
efficiently by using 4-byte variants of the string operations.

On Intel systems with ERMSB (efficient rep movsb), this is no practical
difference.  On all other systems, this is 4 times more efficient.

Signed-off-by: Andrew Cooper 
Reviewed-by: Jan Beulich 
---
v2:
 * Alter spacing after rep prefix
---
 xen/arch/x86/boot/head.S | 9 +
 xen/arch/x86/xen.lds.S   | 5 +
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
index 097..85770e8 100644
--- a/xen/arch/x86/boot/head.S
+++ b/xen/arch/x86/boot/head.S
@@ -128,7 +128,8 @@ __start:
 mov $sym_phys(__bss_end),%ecx
 sub %edi,%ecx
 xor %eax,%eax
-rep stosb
+shr $2,%ecx
+rep stosl
 
 /* Interrogate CPU extended features via CPUID. */
 mov $0x8000,%eax
@@ -192,8 +193,8 @@ __start:
 
 /* Copy bootstrap trampoline to low memory, below 1MB. */
 mov $sym_phys(trampoline_start),%esi
-mov $trampoline_end - trampoline_start,%ecx
-rep movsb
+mov $((trampoline_end - trampoline_start) / 4),%ecx
+rep movsl
 
 /* Jump into the relocated trampoline. */
 lret
@@ -205,6 +206,6 @@ reloc:
 
 ENTRY(trampoline_start)
 #include "trampoline.S"
-GLOBAL(trampoline_end)
+ENTRY(trampoline_end)
 
 #include "x86_64.S"
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index a1678d8..d620e7a 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -314,3 +314,8 @@ ASSERT(IS_ALIGNED(cpu0_stack, STACK_SIZE), "cpu0_stack 
misaligned")
 
 ASSERT(IS_ALIGNED(__init_begin, PAGE_SIZE), "__init_begin misaligned")
 ASSERT(IS_ALIGNED(__init_end,   PAGE_SIZE), "__init_end misaligned")
+
+ASSERT(IS_ALIGNED(trampoline_start, 4), "trampoline_start misaligned")
+ASSERT(IS_ALIGNED(trampoline_end,   4), "trampoline_end misaligned")
+ASSERT(IS_ALIGNED(__bss_start,  4), "__bss_start misaligned")
+ASSERT(IS_ALIGNED(__bss_end,4), "__bss_end misaligned")
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/4] xen/init: Annotate all command line parameter infrastructure as const

2016-06-21 Thread Andrew Cooper

There is no reason for any of it to be modified.  Additionally, link
.init.setup beside the other constant .init data.

While editing this area, correct the types used in the extern
declarations for __setup_start and __setup_end to match the types the
linker actually produces.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 

v2:
 * Extra const
---
 xen/arch/arm/xen.lds.S | 11 ++-
 xen/arch/x86/xen.lds.S | 11 ++-
 xen/common/kernel.c|  6 +++---
 xen/include/xen/init.h |  7 ---
 4 files changed, 19 insertions(+), 16 deletions(-)

diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 8320381..2ed7dee 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -135,6 +135,12 @@ SECTIONS
*(.init.rodata)
*(.init.rodata.rel)
*(.init.rodata.str*)
+
+   . = ALIGN(POINTER_ALIGN);
+   __setup_start = .;
+   *(.init.setup)
+   __setup_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -145,11 +151,6 @@ SECTIONS
__ctors_end = .;
   } :text
   . = ALIGN(32);
-  .init.setup : {
-   __setup_start = .;
-   *(.init.setup)
-   __setup_end = .;
-  } :text
   .init.proc.info : {
__proc_info_start = .;
*(.init.proc.info)
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index dcbb8fe..2443b93 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -152,6 +152,12 @@ SECTIONS
*(.init.rodata)
*(.init.rodata.rel)
*(.init.rodata.str*)
+
+   . = ALIGN(POINTER_ALIGN);
+   __setup_start = .;
+   *(.init.setup)
+   __setup_end = .;
+
*(.init.data)
*(.init.data.rel)
*(.init.data.rel.*)
@@ -178,11 +184,6 @@ SECTIONS
__ctors_end = .;
   } :text
   . = ALIGN(32);
-  .init.setup : {
-   __setup_start = .;
-   *(.init.setup)
-   __setup_end = .;
-  } :text
   .initcall.init : {
__initcall_start = .;
*(.initcallpresmp.init)
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index dae7e35..942b042 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -27,7 +27,7 @@ int tainted;
 xen_commandline_t saved_cmdline;
 
 static void __init assign_integer_param(
-struct kernel_param *param, uint64_t val)
+const struct kernel_param *param, uint64_t val)
 {
 switch ( param->len )
 {
@@ -52,7 +52,7 @@ void __init cmdline_parse(const char *cmdline)
 {
 char opt[100], *optval, *optkey, *q;
 const char *p = cmdline;
-struct kernel_param *param;
+const struct kernel_param *param;
 int bool_assert;
 
 if ( cmdline == NULL )
@@ -96,7 +96,7 @@ void __init cmdline_parse(const char *cmdline)
 if ( !bool_assert )
 optkey += 3;
 
-for ( param = &__setup_start; param < &__setup_end; param++ )
+for ( param = __setup_start; param < __setup_end; param++ )
 {
 if ( strcmp(param->name, optkey) )
 {
diff --git a/xen/include/xen/init.h b/xen/include/xen/init.h
index 671ac81..b04bcf9 100644
--- a/xen/include/xen/init.h
+++ b/xen/include/xen/init.h
@@ -86,10 +86,11 @@ struct kernel_param {
 void *var;
 };
 
-extern struct kernel_param __setup_start, __setup_end;
+extern const struct kernel_param __setup_start[], __setup_end[];
 
-#define __setup_str static __initdata __attribute__((__aligned__(1))) char
-#define __kparam static __initsetup \
+#define __setup_str static const  __initconstrel \
+__attribute__((__aligned__(1))) char
+#define __kparam static const __initsetup \
 __attribute__((__aligned__(sizeof(void * struct kernel_param
 
 #define custom_param(_name, _var) \
-- 
2.1.4


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

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

2016-06-21 Thread Paul Lai

Cleaning up altp2m code per request of xen-devel mailing list.

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

 xen/arch/x86/hvm/hvm.c| 41 ++--
 xen/arch/x86/hvm/vmx/vmx.c|  2 +-
 xen/arch/x86/mm/altp2m.c  | 43 +
 xen/arch/x86/mm/hap/hap.c | 35 ++
 xen/arch/x86/mm/mm-locks.h|  4 +-
 xen/arch/x86/mm/p2m-ept.c | 38 +++
 xen/arch/x86/mm/p2m.c | 98 +--
 xen/include/asm-x86/altp2m.h  | 10 +++-
 xen/include/asm-x86/domain.h  | 12 -
 xen/include/asm-x86/hvm/hvm.h | 19 ++--
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 ++
 xen/include/asm-x86/p2m.h | 11 ++---
 xen/include/public/hvm/hvm_op.h   |  2 +
 13 files changed, 178 insertions(+), 140 deletions(-)

-- 
1.9.1


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

Re: [Xen-devel] [PATCH 03/19] xen: credit2: insert and tickle don't need a cpu parameter

2016-06-21 Thread anshul makkar


On 18/06/16 00:11, Dario Faggioli wrote:

In fact, they always operate on the svc->processor of
the csched2_vcpu passed to them.

No functional change intended.

Signed-off-by: Dario Faggioli 


Reviewed-by: Anshul Makkar 

---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: David Vrabel 
---
  xen/common/sched_credit2.c |   19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 0246453..5881583 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -518,8 +518,9 @@ __runq_insert(struct list_head *runq, struct csched2_vcpu 
*svc)
  }

  static void
-runq_insert(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu 
*svc)
+runq_insert(const struct scheduler *ops, struct csched2_vcpu *svc)
  {
+unsigned int cpu = svc->vcpu->processor;
  struct list_head * runq = (ops, cpu)->runq;
  int pos = 0;

@@ -558,17 +559,17 @@ void burn_credits(struct csched2_runqueue_data *rqd, 
struct csched2_vcpu *, s_ti
  /* Check to see if the item on the runqueue is higher priority than what's
   * currently running; if so, wake up the processor */
  static /*inline*/ void
-runq_tickle(const struct scheduler *ops, unsigned int cpu, struct csched2_vcpu 
*new, s_time_t now)
+runq_tickle(const struct scheduler *ops, struct csched2_vcpu *new, s_time_t 
now)
  {
  int i, ipid=-1;
  s_time_t lowest=(1<<30);
+unsigned int cpu = new->vcpu->processor;
  struct csched2_runqueue_data *rqd = RQD(ops, cpu);
  cpumask_t mask;
  struct csched2_vcpu * cur;

  d2printk("rqt %pv curr %pv\n", new->vcpu, current);

-BUG_ON(new->vcpu->processor != cpu);
  BUG_ON(new->rqd != rqd);

  /* Look at the cpu it's running on first */
@@ -1071,8 +1072,8 @@ csched2_vcpu_wake(const struct scheduler *ops, struct 
vcpu *vc)
  update_load(ops, svc->rqd, svc, 1, now);

  /* Put the VCPU on the runq */
-runq_insert(ops, vc->processor, svc);
-runq_tickle(ops, vc->processor, svc, now);
+runq_insert(ops, svc);
+runq_tickle(ops, svc, now);

  out:
  d2printk("w-\n");
@@ -1104,8 +1105,8 @@ csched2_context_saved(const struct scheduler *ops, struct 
vcpu *vc)
  {
  BUG_ON(__vcpu_on_runq(svc));

-runq_insert(ops, vc->processor, svc);
-runq_tickle(ops, vc->processor, svc, now);
+runq_insert(ops, svc);
+runq_tickle(ops, svc, now);
  }
  else if ( !is_idle_vcpu(vc) )
  update_load(ops, svc->rqd, svc, -1, now);
@@ -1313,8 +1314,8 @@ static void migrate(const struct scheduler *ops,
  if ( on_runq )
  {
  update_load(ops, svc->rqd, NULL, 1, now);
-runq_insert(ops, svc->vcpu->processor, svc);
-runq_tickle(ops, svc->vcpu->processor, svc, now);
+runq_insert(ops, svc);
+runq_tickle(ops, svc, now);
  SCHED_STAT_CRANK(migrate_on_runq);
  }
  else




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

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

2016-06-21 Thread Paul Lai

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

Signed-off-by: Paul Lai 
---
 xen/arch/x86/mm/altp2m.c  | 43 +++
 xen/arch/x86/mm/hap/hap.c | 35 +--
 xen/arch/x86/mm/p2m-ept.c | 38 ++
 xen/arch/x86/mm/p2m.c | 41 +
 xen/include/asm-x86/altp2m.h  |  3 ++-
 xen/include/asm-x86/hvm/vmx/vmx.h |  3 +++
 xen/include/asm-x86/p2m.h |  9 +++-
 7 files changed, 95 insertions(+), 77 deletions(-)

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

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

2016-06-21 Thread Paul Lai

Ravi Sahita's dynamically allocated altp2m structs

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c   |  8 +++---
 xen/arch/x86/hvm/vmx/vmx.c   |  2 +-
 xen/arch/x86/mm/altp2m.c | 18 +++---
 xen/arch/x86/mm/mm-locks.h   |  4 +--
 xen/arch/x86/mm/p2m-ept.c|  8 +++---
 xen/arch/x86/mm/p2m.c| 59 
 xen/include/asm-x86/altp2m.h |  7 +-
 xen/include/asm-x86/domain.h | 12 -
 xen/include/asm-x86/p2m.h|  2 +-
 9 files changed, 70 insertions(+), 50 deletions(-)

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

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

2016-06-21 Thread Paul Lai

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

Signed-off-by: Paul Lai 
---
 xen/arch/x86/hvm/hvm.c  | 33 +
 xen/include/asm-x86/hvm/hvm.h   | 19 ---
 xen/include/public/hvm/hvm_op.h |  2 ++
 3 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 22f045e..1595b3e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1926,11 +1926,11 @@ int hvm_hap_nested_page_fault(paddr_t gpa, unsigned 
long gla,
  * Otherwise, this is an error condition. */
 rc = fall_through;
 
-out_put_gfn:
+ out_put_gfn:
 __put_gfn(p2m, gfn);
 if ( ap2m_active )
 __put_gfn(hostp2m, gfn);
-out:
+ out:
 /* All of these are delayed until we exit, since we might 
  * sleep on event ring wait queues, and we must not hold
  * locks in such circumstance */
@@ -5207,9 +5207,11 @@ static int do_altp2m_op(
 return -EFAULT;
 
 if ( a.pad1 || a.pad2 ||
- (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
- (a.cmd < HVMOP_altp2m_get_domain_state) ||
- (a.cmd > HVMOP_altp2m_change_gfn) )
+(a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+(a.cmd < HVMOP_cmd_min) || (a.cmd > HVMOP_cmd_max))
+return -EINVAL;
+
+if (a.cmd > HVMOP_cmd_max)
 return -EINVAL;
 
 d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
@@ -5329,6 +5331,8 @@ static int do_altp2m_op(
 rc = p2m_change_altp2m_gfn(d, a.u.change_gfn.view,
 _gfn(a.u.change_gfn.old_gfn),
 _gfn(a.u.change_gfn.new_gfn));
+default:
+return -EINVAL;
 }
 
  out:
@@ -5816,25 +5820,6 @@ void hvm_toggle_singlestep(struct vcpu *v)
 v->arch.hvm_vcpu.single_step = !v->arch.hvm_vcpu.single_step;
 }
 
-void altp2m_vcpu_update_p2m(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_p2m )
-hvm_funcs.altp2m_vcpu_update_p2m(v);
-}
-
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
-hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
-}
-
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
-{
-if ( hvm_funcs.altp2m_vcpu_emulate_ve )
-return hvm_funcs.altp2m_vcpu_emulate_ve(v);
-return 0;
-}
-
 int hvm_set_mode(struct vcpu *v, int mode)
 {
 
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index f486ee9..231c921 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -589,13 +589,26 @@ static inline bool_t hvm_altp2m_supported(void)
 }
 
 /* updates the current hardware p2m */
-void altp2m_vcpu_update_p2m(struct vcpu *v);
+static inline void altp2m_vcpu_update_p2m(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_p2m )
+hvm_funcs.altp2m_vcpu_update_p2m(v);
+}
 
 /* updates VMCS fields related to VMFUNC and #VE */
-void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v);
+static inline void altp2m_vcpu_update_vmfunc_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_update_vmfunc_ve )
+hvm_funcs.altp2m_vcpu_update_vmfunc_ve(v);
+}
 
 /* emulates #VE */
-bool_t altp2m_vcpu_emulate_ve(struct vcpu *v);
+static inline bool_t altp2m_vcpu_emulate_ve(struct vcpu *v)
+{
+if ( hvm_funcs.altp2m_vcpu_emulate_ve )
+return hvm_funcs.altp2m_vcpu_emulate_ve(v);
+return 0;
+}
 
 /* Check CR4/EFER values */
 const char *hvm_efer_valid(const struct vcpu *v, uint64_t value,
diff --git a/xen/include/public/hvm/hvm_op.h b/xen/include/public/hvm/hvm_op.h
index ebb907a..3350492 100644
--- a/xen/include/public/hvm/hvm_op.h
+++ b/xen/include/public/hvm/hvm_op.h
@@ -479,6 +479,8 @@ struct xen_hvm_altp2m_op {
 #define HVMOP_altp2m_set_mem_access   7
 /* Change a p2m entry to have a different gfn->mfn mapping */
 #define HVMOP_altp2m_change_gfn   8
+#define HVMOP_cmd_min HVMOP_altp2m_get_domain_state
+#define HVMOP_cmd_max HVMOP_altp2m_change_gfn
 domid_t domain;
 uint16_t pad1;
 uint32_t pad2;
-- 
1.9.1


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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread George Dunlap

On 21/06/16 17:04, Ian Jackson wrote:
> My point was that I think we should decide first what our proposed
> solution will look like, and _then_ whether it should be in libxlu or
> libxl.

Indeed.

I agree that direct consumers of xl are an important "market segment"
that we need to support.  I'd support adapting xenconsoled.

 -George

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

Re: [Xen-devel] [PATCH 01/19] xen: sched: leave CPUs doing tasklet work alone.

2016-06-21 Thread anshul makkar


On 18/06/16 00:11, Dario Faggioli wrote:

In both Credit1 and Credit2, stop considering a pCPU idle,
if the reason why the idle vCPU is being selected, is to
do tasklet work.

Not doing so means that the tickling and load balancing
logic, seeing the pCPU as idle, considers it a candidate
for picking up vCPUs. But the pCPU won't actually pick
up or schedule any vCPU, which would then remain in the
runqueue, which is bas, especially if there were other,
truly idle pCPUs, that could execute it.

The only drawback is that we can't assume that a pCPU is
in always marked as idle when being removed from an
instance of the Credit2 scheduler (csched2_deinit_pdata).
In fact, if we are in stop-machine (i.e., during suspend
or shutdown), the pCPUs are running the stopmachine_tasklet
and hence are actually marked as busy. On the other hand,
when removing a pCPU from a Credit2 pool, it will indeed
be idle. The only thing we can do, therefore, is to
remove the BUG_ON() check.

Signed-off-by: Dario Faggioli 


Reviewed-by: Anshul Makkar 

---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: David Vrabel 
---
  xen/common/sched_credit.c  |   12 ++--
  xen/common/sched_credit2.c |   14 ++
  2 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index a38a63d..a6645a2 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1819,24 +1819,24 @@ csched_schedule(
  else
  snext = csched_load_balance(prv, cpu, snext, );

+ out:
  /*
   * Update idlers mask if necessary. When we're idling, other CPUs
   * will tickle us when they get extra work.
   */
-if ( snext->pri == CSCHED_PRI_IDLE )
+if ( tasklet_work_scheduled || snext->pri != CSCHED_PRI_IDLE )
  {
-if ( !cpumask_test_cpu(cpu, prv->idlers) )
-cpumask_set_cpu(cpu, prv->idlers);
+if ( cpumask_test_cpu(cpu, prv->idlers) )
+cpumask_clear_cpu(cpu, prv->idlers);
  }
-else if ( cpumask_test_cpu(cpu, prv->idlers) )
+else if ( !cpumask_test_cpu(cpu, prv->idlers) )
  {
-cpumask_clear_cpu(cpu, prv->idlers);
+cpumask_set_cpu(cpu, prv->idlers);
  }

  if ( !is_idle_vcpu(snext->vcpu) )
  snext->start_time += now;

-out:
  /*
   * Return task to run next...
   */
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 1933ff1..cf8455c 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1910,8 +1910,16 @@ csched2_schedule(
  }
  else
  {
-/* Update the idle mask if necessary */
-if ( !cpumask_test_cpu(cpu, >idle) )
+/*
+ * Update the idle mask if necessary. Note that, if we're scheduling
+ * idle in order to carry on some tasklet work, we want to play busy!
+ */
+if ( tasklet_work_scheduled )
+{
+if ( cpumask_test_cpu(cpu, >idle) )
+cpumask_clear_cpu(cpu, >idle);
+}
+else if ( !cpumask_test_cpu(cpu, >idle) )
  cpumask_set_cpu(cpu, >idle);
  /* Make sure avgload gets updated periodically even
   * if there's no activity */
@@ -2291,8 +2299,6 @@ csched2_deinit_pdata(const struct scheduler *ops, void 
*pcpu, int cpu)
  /* No need to save IRQs here, they're already disabled */
  spin_lock(>lock);

-BUG_ON(!cpumask_test_cpu(cpu, >idle));
-
  printk("Removing cpu %d from runqueue %d\n", cpu, rqi);

  cpumask_clear_cpu(cpu, >idle);




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

[Xen-devel] [PATCHv2] x86/xen: avoid m2p lookup when setting early page table entries

2016-06-21 Thread David Vrabel

When page tables entries are set using xen_set_pte_init() during early
boot there is no page fault handler that could handle a fault when
performing an M2P lookup.

In 64 guest (usually dom0) early_ioremap() would fault in
xen_set_pte_init() because an M2P lookup faults because the MFN is in
MMIO space and not mapped in the M2P.  This lookup is done to see if
the PFN in in the range used for the initial page table pages, so that
the PTE may be set as read-only.

The M2P lookup can be avoided by moving the check (and clear of RW)
earlier when the PFN is still available.

Signed-off-by: David Vrabel 
Tested-by: Keven Moraga 
---
v2:

- Remove __init annotation from xen_make_pte_init() since
  PV_CALLEE_SAVE_REGS_THUNK always puts the thunk in .text.

- mask_rw_pte() -> mask_rw_pteval() for x86-64.
---
 arch/x86/xen/mmu.c | 28 +---
 1 file changed, 21 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 478a2de..e47bc19 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1562,7 +1562,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
return pte;
 }
 #else /* CONFIG_X86_64 */
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
+static pteval_t __init mask_rw_pte(pteval_t pte)
 {
unsigned long pfn;
 
@@ -1577,10 +1577,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
 * page tables for mapping the p2m list, too, and page tables MUST be
 * mapped read-only.
 */
-   pfn = pte_pfn(pte);
+   pfn = (pte & PTE_PFN_MASK) >> PAGE_SHIFT;
if (pfn >= xen_start_info->first_p2m_pfn &&
pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
-   pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
+   pte &= ~_PAGE_RW;
 
return pte;
 }
@@ -1600,13 +1600,26 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
  * so always write the PTE directly and rely on Xen trapping and
  * emulating any updates as necessary.
  */
+__visible pte_t xen_make_pte_init(pteval_t pte)
+{
+#ifdef CONFIG_X86_64
+   pte = mask_rw_pte(pte);
+#endif
+   pte = pte_pfn_to_mfn(pte);
+
+   if ((pte & PTE_PFN_MASK) >> PAGE_SHIFT == INVALID_P2M_ENTRY)
+   pte = 0;
+
+   return native_make_pte(pte);
+}
+PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte_init);
+
 static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 {
+#ifdef CONFIG_X86_32
if (pte_mfn(pte) != INVALID_P2M_ENTRY)
pte = mask_rw_pte(ptep, pte);
-   else
-   pte = __pte_ma(0);
-
+#endif
native_set_pte(ptep, pte);
 }
 
@@ -2407,6 +2420,7 @@ static void __init xen_post_allocator_init(void)
pv_mmu_ops.alloc_pud = xen_alloc_pud;
pv_mmu_ops.release_pud = xen_release_pud;
 #endif
+   pv_mmu_ops.make_pte = PV_CALLEE_SAVE(xen_make_pte);
 
 #ifdef CONFIG_X86_64
pv_mmu_ops.write_cr3 = _write_cr3;
@@ -2455,7 +2469,7 @@ static const struct pv_mmu_ops xen_mmu_ops __initconst = {
.pte_val = PV_CALLEE_SAVE(xen_pte_val),
.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),
 
-   .make_pte = PV_CALLEE_SAVE(xen_make_pte),
+   .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),
 
 #ifdef CONFIG_X86_PAE
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

2016-06-21 Thread Andrew Cooper

On 21/06/16 16:41, Julien Grall wrote:
> Hello,
>
> On 21/06/16 16:21, Andrew Cooper wrote:
>> On 20/06/16 15:04, Daniel De Graaf wrote:
>>> Since FLASK is the only implementation of XSM hooks in Xen, using an
>>> iterated initcall dispatch for setup is overly complex.  Change this to
>>> a direct function call to a globally visible function; if additional
>>> XSM
>>> hooks are added in the future, a switching mechanism will be needed
>>> regardless, and that can be placed in xsm_core.c.
>>>
>>> Signed-off-by: Daniel De Graaf 
>>
>> Reviewed-by: Andrew Cooper 
>>
>> (CC'ing ARM maintainers)
>
> For the ARM bits:
>
> Acked-by: Julien Grall 

And committed (as this patch unblocks one of my series).

I will leave the remainder of the series until a decision is taken about
patch 13.

~Andrew

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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Ian Jackson

George Dunlap writes ("Re: XSA-180 follow-up: repurpose xenconsoled for 
logging"):
> I think that having the option to pass an fd in would be useful and will
> probably be wanted at some point; I think libvirt for instance should
> probably be modified to use such an interface once it's available to
> connect qemu to virtlogd.

Quite possibly, yes.

> On 21/06/16 16:11, Ian Jackson wrote:
> > IMO it would be best to come up with a solution that is suitable for
> > all users of libxl, and put it in libxl.  If this is not possible then
> > whatever we implement could go in libxlu.
> 
> I wouldn't object to the functionality being in libxl, but it seems to
> me like libxlu might be a better fit.

My point was that I think we should decide first what our proposed
solution will look like, and _then_ whether it should be in libxlu or
libxl.

Ian.

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

[Xen-devel] [xen-4.3-testing test] 96042: regressions - FAIL

2016-06-21 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 87893
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 87893
 build-armhf   5 xen-build fail REGR. vs. 87893
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 87893

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  0a8c94fae993dd8f2b27fd4cc694f61c21de84bf
baseline version:
 xen  8fa31952e2d08ef63897c43b5e8b33475ebf5d93

Last test of basis87893  2016-03-29 13:49:52 Z   84 days
Failing since 92180  2016-04-20 17:49:21 Z   61 days   23 attempts
Testing same since96017  2016-06-20 17:22:27 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anthony Liguori 
  Anthony PERARD 
  Gerd Hoffmann 
  Ian Jackson 
  Jan Beulich 
  Jim Paris 
  Stefan Hajnoczi 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  fail
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  blocked 
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread George Dunlap

On 21/06/16 16:11, Ian Jackson wrote:
> Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"):
>> Here is what we have gathered so far:
> ...
>> We can, however, just make recommendation that system administrators can
>> easily set up and call it a day. There are suggestions that we can
>> recommend conserver or sympathy, but I haven't seen a concrete viable
>> proposal yet. What I hope is that we can have a document in tree in the
>> end.
> 
> sympathy would need some extra engineering to become suitable.  It's
> also not widely adopted.  (Not even in Debian, yet.  Sorry about that,
> but in my defence it's not my project...)
> 
>> Another way is to invent our own "virtlogd" -- it could be a new daemon,
>> it could be xenconsoled. The major concern is that we're adding a
>> critical component to the system and it may not scale well. We can make
>> a compromise by using non-blocking fd to make the new component less
>> critical and doesn't hinder scalability.
> 
> I think this is probably the best answer.  We already have most of
> this in the form of xenconsoled.
> 
>> Another way is to alter libxl API and ask the application to pass in a
>> fd for logging. The major concern is that this is not suitable in the
>> context of a security issue.
> 
> Any solution needs to work for xl as well as other users of libxl.  So
> this is not a description of a solution option; rather it is a
> proposal to move the functionality/glue/problem/whatever out of libxl
> into xl.

...or libvirt, or xapi (should it ever be ported to libxl).

I think that having the option to pass an fd in would be useful and will
probably be wanted at some point; I think libvirt for instance should
probably be modified to use such an interface once it's available to
connect qemu to virtlogd.

> IMO it would be best to come up with a solution that is suitable for
> all users of libxl, and put it in libxl.  If this is not possible then
> whatever we implement could go in libxlu.

I wouldn't object to the functionality being in libxl, but it seems to
me like libxlu might be a better fit.

 -George

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

Re: [Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread Boris Ostrovsky

On 06/21/2016 10:37 AM, Andrey Grodzovsky wrote:
> Current overlap check is evaluating to false a case where a filter field
> is fully contained (proper subset) of a r/w request.
> This change applies classical overlap check instead to include
> all the scenarios.
>
> Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html
>
> Cc: Jan Beulich 
> Cc: Boris Ostrovsky 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Andrey Grodzovsky 

+ David and Juergen (maintainers) and kernel list.

Reviewed-by: Boris Ostrovsky 


> ---
>  drivers/xen/xen-pciback/conf_space.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/xen/xen-pciback/conf_space.c 
> b/drivers/xen/xen-pciback/conf_space.c
> index 8e67336..6a25533 100644
> --- a/drivers/xen/xen-pciback/conf_space.c
> +++ b/drivers/xen/xen-pciback/conf_space.c
> @@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int 
> offset, int size,
>   field_start = OFFSET(cfg_entry);
>   field_end = OFFSET(cfg_entry) + field->size;
>  
> - if ((req_start >= field_start && req_start < field_end)
> - || (req_end > field_start && req_end <= field_end)) {
> +  if (req_end > field_start && field_end > req_start) {
>   err = conf_space_read(dev, cfg_entry, field_start,
> _val);
>   if (err)
> @@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int 
> offset, int size, u32 value)
>   field_start = OFFSET(cfg_entry);
>   field_end = OFFSET(cfg_entry) + field->size;
>  
> - if ((req_start >= field_start && req_start < field_end)
> - || (req_end > field_start && req_end <= field_end)) {
> +  if (req_end > field_start && field_end > req_start) {
>   tmp_val = 0;
>  
>   err = xen_pcibk_config_read(dev, field_start,



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

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

2016-06-21 Thread Julien Grall


Hello,

On 21/06/16 16:21, Andrew Cooper wrote:

On 20/06/16 15:04, Daniel De Graaf wrote:

Since FLASK is the only implementation of XSM hooks in Xen, using an
iterated initcall dispatch for setup is overly complex.  Change this to
a direct function call to a globally visible function; if additional XSM
hooks are added in the future, a switching mechanism will be needed
regardless, and that can be placed in xsm_core.c.

Signed-off-by: Daniel De Graaf 


Reviewed-by: Andrew Cooper 

(CC'ing ARM maintainers)


For the ARM bits:

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 00/17] XSM/FLASK updates for 4.8

2016-06-21 Thread Andrew Cooper

On 20/06/16 15:04, Daniel De Graaf wrote:
> Changes from v1:
>  - Change c->context and c->sid from arrays to fields when shrinking
>  - Keep struct xen_flask_userlist in headers, but guard it with #ifs
>  - Split off Kconfig changes into their own patches
>  - Add patch 16 (AVC_STATS in Kconfig)
>  - Prevent free() of static data in xsm_dt_init
>
> FLASK policy updates:
>  [PATCH 01/17] flask/policy: split into modules
>  [PATCH 02/17] flask/policy: split out rules for system_r
>  [PATCH 03/17] flask/policy: move user definitions and constraints
>  [PATCH 04/17] flask/policy: remove unused support for binary modules
>  [PATCH 05/17] flask/policy: xenstore stubdom policy
>  [PATCH 06/17] flask/policy: remove unused example
>
> Hypervisor updates to the FLASK security server:
>  [PATCH 07/17] flask: unify {get,set}vcpucontext permissions
>  [PATCH 08/17] flask: remove unused secondary context in ocontext
>  [PATCH 09/17] flask: remove unused AVC callback functions
>  [PATCH 10/17] flask: remove xen_flask_userlist operation
>  [PATCH 11/17] flask: improve unknown permission handling
>
> Hypervisor updates to the XSM framework (and its config):
>  [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section
>  [PATCH 13/17] xen: fix FLASK dependency in Kconfig
>  [PATCH 14/17] xsm: annotate setup functions with __init
>  [PATCH 15/17] xsm: clean up unregistration
>  [PATCH 16/17] xen: Make FLASK_AVC_STATS kconfig option visible
>  [PATCH 17/17] xsm: add a default policy to .init.data

I have committed the first two sections.  Patch 12 requires an ARM ack,
and patch 13 has some outstanding discussion.

~Andrew

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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Ian Jackson

Juergen Gross writes ("Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled 
for logging"):
> Huh? Excerpt from `man logrotate`:
> 
> Each log file may be handled daily, weekly, monthly, or when it grows
> too large.
> 
> So why is logrotate not suitable?

logrotate runs "off-path", ie it checks the logfile size, when it is
run.  It's not designed to be run frequently.

Ian.

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

Re: [Xen-devel] [PATCH 6/7] vm-event/arm: move hvm_event_cr->common vm_event_monitor_cr

2016-06-21 Thread Tamas K Lengyel

On Jun 21, 2016 01:20, "Jan Beulich"  wrote:
>
> >>> On 21.06.16 at 09:08,  wrote:
> > On 6/17/2016 11:25 AM, Corneliu ZUZU wrote:
> >> On 6/16/2016 6:16 PM, Jan Beulich wrote:
> >> On 16.06.16 at 16:12,  wrote:
>  Prepare for ARM implementation of control-register write vm-events
>  by moving
>  X86-specific hvm_event_cr to the common-side.
> 
>  Signed-off-by: Corneliu ZUZU 
>  ---
>    xen/arch/x86/hvm/event.c| 30 --
>    xen/arch/x86/hvm/hvm.c  |  2 +-
>    xen/arch/x86/monitor.c  | 37
>  -
>    xen/arch/x86/vm_event.c |  2 +-
>    xen/common/monitor.c| 40
>  
>    xen/common/vm_event.c   | 31
+++
>    xen/include/asm-x86/hvm/event.h | 13 -
>    xen/include/asm-x86/monitor.h   |  2 --
>    xen/include/xen/monitor.h   |  4 
>    xen/include/xen/vm_event.h  | 10 ++
>    10 files changed, 91 insertions(+), 80 deletions(-)
> >>> Considering that there's no ARM file getting altered here at all,
> >>> mentioning ARM in the subject is a little odd.
> >>
> >> This patch and the following one should be meld together.
> >> I only split them to ease reviewing, sorry I forgot to mention that in
> >> the cover letter.
> >>
> >>>
>  --- a/xen/common/monitor.c
>  +++ b/xen/common/monitor.c
>  @@ -62,6 +62,46 @@ int monitor_domctl(struct domain *d, struct
>  xen_domctl_monitor_op *mop)
>  switch ( mop->event )
>    {
>  +#if CONFIG_X86
> >>> #ifdef please.
> >> Ack.
>  +case XEN_DOMCTL_MONITOR_EVENT_WRITE_CTRLREG:
>  +{
>  +struct arch_domain *ad = >arch;
> >>> Peeking into the next patch I see that this stays there. Common code,
> >>> however, shouldn't access ->arch sub-structures - respective fields
> >>> should be moved out.
> >>
> >> Then we need to find a resolution that avoids code duplication.
> >> The code is the same, but those bits that are currently on the arch
> >> side (arch.monitor.write_ctrlreg_*) cannot be moved to common as they
> >> are, since their -number- might differ from arch-to-arch.
> >> But we could:
> >> - in public/vm_event.h, besides the VM_EVENT_X86_* and VM_EVENT_ARM_*
> >> defines (wcr index), also have
> >> #define VM_EVENT_X86_CR_COUNT4
> >> #define VM_EVENT_ARM_CR_COUNT  4
> >> - move the 3 write_ctrlreg_{enabled,sync,onchangeonly} fields from
> >> arch_domain to domain (common) and make them 8-bits wide each for now
> >> (widened more in the future if the need arises)
> >> - let monitor_ctrlreg_bitmask() macro to be architecture-dependent and
> >> use the introduced VM_EVENT__CR_COUNT
> >>
> >> Tamas, we also talked on this matter @ some point (when I sent the
> >> patches that moved vm-event parts to common). What do you think of the
> >> above?
>
> I don't really care about the specifics, my only request is what I
> already voiced: Common code should not access arch-specific
> fields. Having the field to hold the control register bits common,
> but the definitions for the individual bits arch-specific is perfectly
> fine for this (assuming that these per-arch definitions then again
> don't get used in common code).
>
> Jan

As Jan says it would be fine to have the holder field on the common struct
but IMHO it wouldn't be easier to follow the logic that way and the only
benefit is reducing code duplication a little bit. I think for now it is
acceptable to just rather have some code duplication.

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

Re: [Xen-devel] [PATCH 12/17] xen/xsm: remove .xsm_initcall.init section

2016-06-21 Thread Andrew Cooper

On 20/06/16 15:04, Daniel De Graaf wrote:
> Since FLASK is the only implementation of XSM hooks in Xen, using an
> iterated initcall dispatch for setup is overly complex.  Change this to
> a direct function call to a globally visible function; if additional XSM
> hooks are added in the future, a switching mechanism will be needed
> regardless, and that can be placed in xsm_core.c.
>
> Signed-off-by: Daniel De Graaf 

Reviewed-by: Andrew Cooper 

(CC'ing ARM maintainers)

> ---
>  xen/arch/arm/xen.lds.S |  5 -
>  xen/arch/x86/xen.lds.S |  5 -
>  xen/include/xsm/xsm.h  | 16 
>  xen/xsm/flask/hooks.c  |  4 +---
>  xen/xsm/xsm_core.c | 13 +
>  5 files changed, 10 insertions(+), 33 deletions(-)
>
> diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
> index 76982b2..8320381 100644
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -162,11 +162,6 @@ SECTIONS
> *(.initcall1.init)
> __initcall_end = .;
>} :text
> -  .xsm_initcall.init : {
> -   __xsm_initcall_start = .;
> -   *(.xsm_initcall.init)
> -   __xsm_initcall_end = .;
> -  } :text
>__init_end_efi = .;
>. = ALIGN(STACK_SIZE);
>__init_end = .;
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index a43b29d..dcbb8fe 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -190,11 +190,6 @@ SECTIONS
> *(.initcall1.init)
> __initcall_end = .;
>} :text
> -  .xsm_initcall.init : {
> -   __xsm_initcall_start = .;
> -   *(.xsm_initcall.init)
> -   __xsm_initcall_end = .;
> -  } :text
>. = ALIGN(PAGE_SIZE);
>__init_end = .;
>  
> diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> index 8ed8ee5..0d525ec 100644
> --- a/xen/include/xsm/xsm.h
> +++ b/xen/include/xsm/xsm.h
> @@ -46,14 +46,6 @@ typedef enum xsm_default xsm_default_t;
>  extern char *policy_buffer;
>  extern u32 policy_size;
>  
> -typedef void (*xsm_initcall_t)(void);
> -
> -extern xsm_initcall_t __xsm_initcall_start[], __xsm_initcall_end[];
> -
> -#define xsm_initcall(fn) \
> -static xsm_initcall_t __initcall_##fn \
> -__used_section(".xsm_initcall.init") = fn
> -
>  struct xsm_operations {
>  void (*security_domaininfo) (struct domain *d,
>  struct xen_domctl_getdomaininfo 
> *info);
> @@ -763,6 +755,14 @@ extern int unregister_xsm(struct xsm_operations *ops);
>  extern struct xsm_operations dummy_xsm_ops;
>  extern void xsm_fixup_ops(struct xsm_operations *ops);
>  
> +#ifdef CONFIG_FLASK
> +extern void flask_init(void);
> +#else
> +static inline void flask_init(void)
> +{
> +}
> +#endif
> +
>  #else /* CONFIG_XSM */
>  
>  #include 
> diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
> index 543406b..d632b0e 100644
> --- a/xen/xsm/flask/hooks.c
> +++ b/xen/xsm/flask/hooks.c
> @@ -1817,7 +1817,7 @@ static struct xsm_operations flask_ops = {
>  .xen_version = flask_xen_version,
>  };
>  
> -static __init void flask_init(void)
> +__init void flask_init(void)
>  {
>  int ret = -ENOENT;
>  
> @@ -1860,8 +1860,6 @@ static __init void flask_init(void)
>  printk(XENLOG_INFO "Flask:  Starting in permissive mode.\n");
>  }
>  
> -xsm_initcall(flask_init);
> -
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/xen/xsm/xsm_core.c b/xen/xsm/xsm_core.c
> index 634ec98..3487742 100644
> --- a/xen/xsm/xsm_core.c
> +++ b/xen/xsm/xsm_core.c
> @@ -36,17 +36,6 @@ static inline int verify(struct xsm_operations *ops)
>  return 0;
>  }
>  
> -static void __init do_xsm_initcalls(void)
> -{
> -xsm_initcall_t *call;
> -call = __xsm_initcall_start;
> -while ( call < __xsm_initcall_end )
> -{
> -(*call) ();
> -call++;
> -}
> -}
> -
>  static int __init xsm_core_init(void)
>  {
>  if ( verify(_xsm_ops) )
> @@ -57,7 +46,7 @@ static int __init xsm_core_init(void)
>  }
>  
>  xsm_ops = _xsm_ops;
> -do_xsm_initcalls();
> +flask_init();
>  
>  return 0;
>  }


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

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

2016-06-21 Thread David Vrabel

On 21/06/16 15:17, Boris Ostrovsky wrote:
> This will match how PMU errors are reported at check_hw_exists()'s
> msr_fail label, which is reached when VPMU initialzation fails.

Applied to for-linus-4.8, thanks.

David

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

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

2016-06-21 Thread Shanker Donthineni


Hi Julien,

On 06/21/2016 09:48 AM, Julien Grall wrote:



On 21/06/16 15:36, Shanker Donthineni wrote:



On 06/21/2016 05:49 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to 
defer

steps that registers vgic_v2/v3 mmio handlers.


Looking at this patch and the follow-up ones, I don't think this is
the right way to go. You differ the registration of the IO handlers
just because you are unable to find the size of the handlers array.


Is there any better approach?


Possibly using a different data structure.


I am wondering if the array for the handlers is the best solution
here. On another side, it would be possible to find the maximum of
handlers before hand.


The purpose of this change is to limit size of 'struct domain' less than
PAGE_SIZE. I can think of second approach split vgic_init() into two
stages, one for vgic registration and the second one for vgic_init().
This also requires a few lines of code changes to vgic_v2/v3_init() and
vgic_init().


I am fine as long as vgic_register_ does not do more than counting the 
number of IO handlers. You could re-use vgic_init_v{2,3} for this 
purpose.


The way we are doing vgic_init() initialization has to be cleaned-up and 
rearrange a few lines of code for retrieving the number mmio handlers 
that are required dom0/domU domain.



Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Ian Jackson

Wei Liu writes ("Re: XSA-180 follow-up: repurpose xenconsoled for logging"):
> Here is what we have gathered so far:
...
> We can, however, just make recommendation that system administrators can
> easily set up and call it a day. There are suggestions that we can
> recommend conserver or sympathy, but I haven't seen a concrete viable
> proposal yet. What I hope is that we can have a document in tree in the
> end.

sympathy would need some extra engineering to become suitable.  It's
also not widely adopted.  (Not even in Debian, yet.  Sorry about that,
but in my defence it's not my project...)

> Another way is to invent our own "virtlogd" -- it could be a new daemon,
> it could be xenconsoled. The major concern is that we're adding a
> critical component to the system and it may not scale well. We can make
> a compromise by using non-blocking fd to make the new component less
> critical and doesn't hinder scalability.

I think this is probably the best answer.  We already have most of
this in the form of xenconsoled.

> Another way is to alter libxl API and ask the application to pass in a
> fd for logging. The major concern is that this is not suitable in the
> context of a security issue.

Any solution needs to work for xl as well as other users of libxl.  So
this is not a description of a solution option; rather it is a
proposal to move the functionality/glue/problem/whatever out of libxl
into xl.

IMO it would be best to come up with a solution that is suitable for
all users of libxl, and put it in libxl.  If this is not possible then
whatever we implement could go in libxlu.

Ian.

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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Juergen Gross

On 21/06/16 16:46, Wei Liu wrote:
> Here is what we have gathered so far:
> 
> 1. Virtlogd is not the right answer to XSA-180 because it is inherently
>designed to work within libvirt.
> 2. Syslog is not suitable because it doesn't provide a fd for QEMU to
>write to.
> 3. Logrotate is not suitable because it only rotates periodically.

Huh? Excerpt from `man logrotate`:

Each log file may be handled daily, weekly, monthly, or when it grows
too large.

So why is logrotate not suitable?


Juergen

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

Re: [Xen-devel] [PATCH 2/7] vm-event: VM_EVENT_FLAG_DENY requires VM_EVENT_FLAG_VCPU_PAUSED

2016-06-21 Thread Tamas K Lengyel

On Jun 21, 2016 05:26, "Corneliu ZUZU"  wrote:
>
> On 6/16/2016 7:11 PM, Tamas K Lengyel wrote:
>>
>> On Thu, Jun 16, 2016 at 8:07 AM, Corneliu ZUZU 
wrote:
>>>
>>> For VM_EVENT_FLAG_DENY to work, the vcpu must be paused (sync = 1)
until the
>>> vm-event is handled. A vm-event response having VM_EVENT_FLAG_DENY flag
set
>>> should also set the VM_EVENT_FLAG_VCPU_PAUSED flag. Enforce that in
>>> vm_event_register_write_resume().
>>
>> Well, the problem with this is that the user can set the VCPU_PAUSED
>> flag any time it wants. It can happen that Xen hasn't paused the vCPU
>> but the user still sends that flag, in which case the unpause the flag
>> induces will not actually do anything. You should also check if the
>> vCPU is in fact paused rather then just relying on this flag.
>>
>> Tamas
>>
>
> Tamas,
>
> Isn't that also the case with the following block @ vm_event_resume:
>
> if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> {
> if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> vm_event_set_registers(v, );
>
> if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> vm_event_toggle_singlestep(d, v);
>
> vm_event_vcpu_unpause(v);
> }
>
> , i.e. shouldn't it be fixed to:
>
> /* check flags which apply only when the vCPU is paused */
> if ( atomic_read(>vm_event_pause_count) )
> {
> if ( rsp.flags & VM_EVENT_FLAG_SET_REGISTERS )
> vm_event_set_registers(v, );
> if ( rsp.flags & VM_EVENT_FLAG_TOGGLE_SINGLESTEP )
> vm_event_toggle_singlestep(d, v);
> if ( rsp.flags & VM_EVENT_FLAG_VCPU_PAUSED )
> vm_event_vcpu_unpause(v);
> }
> ?
>
> If this holds, the check for vCPU pause can also be removed from
vm_event_toggle_singlestep (maybe turned into an ASSERT which could also be
added to vm_event_set_registers).
>

Yes, reworking that whole part as you outlined above would be nice!

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

[Xen-devel] [xen-4.6-testing test] 96031: tolerable FAIL - PUSHED

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95849
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95849
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95849
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95849
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 95849

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

version targeted for testing:
 xen  285248d91b20bc8245f9241e21d3e7b23f67b550
baseline version:
 xen  c68f2364d54fb7c3707aa91882b54c9529a1d445

Last test of basis95849  2016-06-17 07:40:53 Z4 days
Testing same since96006  2016-06-20 12:42:11 Z1 days2 attempts


People who touched revisions under test:
  Ian Jackson 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen

Re: [Xen-devel] [PATCH] xen/pciback: Update data filter intersection logic.

2016-06-21 Thread Andrey Grodzovsky

On Tue, Jun 21, 2016 at 5:23 AM, Jan Beulich  wrote:

> >>> On 21.06.16 at 11:04,  wrote:
>  On 20.06.16 at 18:23,  wrote:
> >> Here is printouts with applying the new logic
> >>
> >> [  382.13] xen-pciback: :06:00.0: write request 4 bytes at 0xc =
> > 4000
> >> [  382.14] xen-pciback: :06:00.0: read 1 bytes at 0xc
> >> [  382.28] xen-pciback: :06:00.0: read 1 bytes at 0xc = 0
> >> [  382.38] xen-pciback: :06:00.0: read 1 bytes at 0xd
> >> [  382.81] xen-pciback: :06:00.0: read 1 bytes at 0xd = 0
> >> [  382.222313] xen-pciback: :06:00.0: read 1 bytes at 0xf
> >> [  382.222341] xen-pciback: :06:00.0: read 1 bytes at 0xf = 0
> >>
> >> So from prints the logic is not equivalent. 0xd is included in this
> case.
> >>
> >> In original logic field 0xd is excluded because
> >> Not if ((req_start >= field_start && req_start < field_end)
> >> Nor (req_end > field_start && req_end <= field_end))  evaluate to true.
> >> Where request would be 4b segment starting with 0xc
> >
> > Oh, I see - the current expression is screwed in two ways: For one
> > it has req_* and field_* the wrong way round (or should I better
> > say their uses are not symmetric, which for any kind of overlap
> > check they of course should be), and then it uses || instead of &&
> > (i.e. kind of, but not really checking that req is contained in field,
> > whereas for the purpose here we'd need the other direction). So
> > yes, your change is not just a simplification, but a correction.
> >
> > But then on top of the previously mentioned change to your patch
> > you should also fix the read path in a similar manner. And the
> > description should of course accurately reflect the change (i.e.
> > no talk of quirks and overlapping filters, and a proper explanation
> > of what's wrong with the current expression).
>
> Sent updated patch for review.


> Yet then what I don't understand: How does this change help you?
> There's still not going to be any actual write to the Latency Timer
> register, as conf_space_write() - even if now getting called - won't
> do anything for it.
>


>
> Jan
>
> Not sure, seems to me sometime the reset sequence in the net driver
doesn't
actually erase the conf space so it masks the issue
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4] xen: add steal_clock support on x86

2016-06-21 Thread David Vrabel

On 20/05/16 08:26, Juergen Gross wrote:
> The pv_time_ops structure contains a function pointer for the
> "steal_clock" functionality used only by KVM and Xen on ARM. Xen on x86
> uses its own mechanism to account for the "stolen" time a thread wasn't
> able to run due to hypervisor scheduling.
> 
> Add support in Xen arch independent time handling for this feature by
> moving it out of the arm arch into drivers/xen and remove the x86 Xen
> hack.

Applied for-linus-4.8, thanks.

David

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

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

2016-06-21 Thread Julien Grall




On 21/06/16 15:36, Shanker Donthineni wrote:



On 06/21/2016 05:49 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to defer
steps that registers vgic_v2/v3 mmio handlers.


Looking at this patch and the follow-up ones, I don't think this is
the right way to go. You differ the registration of the IO handlers
just because you are unable to find the size of the handlers array.


Is there any better approach?


Possibly using a different data structure.


I am wondering if the array for the handlers is the best solution
here. On another side, it would be possible to find the maximum of
handlers before hand.


The purpose of this change is to limit size of 'struct domain' less than
PAGE_SIZE. I can think of second approach split vgic_init() into two
stages, one for vgic registration and the second one for vgic_init().
This also requires a few lines of code changes to vgic_v2/v3_init() and
vgic_init().


I am fine as long as vgic_register_ does not do more than counting the 
number of IO handlers. You could re-use vgic_init_v{2,3} for this purpose.


Regards,

--
Julien Grall

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

Re: [Xen-devel] XSA-180 follow-up: repurpose xenconsoled for logging

2016-06-21 Thread Wei Liu

Here is what we have gathered so far:

1. Virtlogd is not the right answer to XSA-180 because it is inherently
   designed to work within libvirt.
2. Syslog is not suitable because it doesn't provide a fd for QEMU to
   write to.
3. Logrotate is not suitable because it only rotates periodically.
4. Syslog + logrotate combo is not suitable because (see above).

We can, however, just make recommendation that system administrators can
easily set up and call it a day. There are suggestions that we can
recommend conserver or sympathy, but I haven't seen a concrete viable
proposal yet. What I hope is that we can have a document in tree in the
end.

Another way is to invent our own "virtlogd" -- it could be a new daemon,
it could be xenconsoled. The major concern is that we're adding a
critical component to the system and it may not scale well. We can make
a compromise by using non-blocking fd to make the new component less
critical and doesn't hinder scalability.

Another way is to alter libxl API and ask the application to pass in a
fd for logging. The major concern is that this is not suitable in the
context of a security issue.

My ultimate goal is to remove the custom patch we have in QEMU tree so
that we don't create a problem for distro maintainers.  So I'm fine with
any solution really.

Wei.

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

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

2016-06-21 Thread Julien Grall




On 21/06/16 15:16, Shanker Donthineni wrote:

On 06/21/2016 08:50 AM, Julien Grall wrote:

On 21/06/16 14:37, Shanker Donthineni wrote:

On 06/21/2016 04:28 AM, Julien Grall wrote:

On 19/06/16 00:45, Shanker Donthineni wrote:

The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware should describe Redistributor base address
in the associated GIC CPU Interface (GICC) instead of GIC

Redistributor

(GICR) table.

The maximum number of mmio handlers and struct vgic_rdist_region
that holds Redistributor addresses are allocated through a static
array with hardcoded size. I don't think this is the right approach
and is not scalable for implementing features like this. I have
decided to convert static to dynamic allocation based on comments
from the below link.

https://patchwork.kernel.org/patch/9163435/


You addressed only one part of my comment. This series increases the
number of I/O handlers but the lookup is still linear (see handle_mmio
in arch/arm/io.c).


I agree with you, we need to bring binary search algorithm similar to
Linux KVM code. I want to keep it this change outside of this patchset.


This should be a prerequisite of this series then, not a follow-up.


For the  functionality and correctness purpose we don't need this change
immediately.
We are not able to boot XEN on Qualcomm Technologies because of not
supporting
GICC table parsing for GICR address.

I am okay to wait for my patchset if someone adding bseach look ups for
mmio handlers.


I am not aware of anyone planning to add bsearch.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/3] x86/ioreq server: Add HVMOP to map guest ram with p2m_ioreq_server to an ioreq server.

2016-06-21 Thread George Dunlap

On 21/06/16 10:47, Jan Beulich wrote:
> And then - didn't we mean to disable that part of XenGT during
> migration, i.e. temporarily accept the higher performance
> overhead without the p2m_ioreq_server entries? In which case
> flipping everything back to p2m_ram_rw after (completed or
> canceled) migration would be exactly what we want. The (new
> or previous) ioreq server should attach only afterwards, and
> can then freely re-establish any p2m_ioreq_server entries it
> deems necessary.
>
 Well, I agree this part of XenGT should be disabled during migration.
 But in such
 case I think it's device model's job to trigger the p2m type
 flipping(i.e. by calling
 HVMOP_set_mem_type).
>>> I agree - this would seem to be the simpler model here, despite (as
>>> George validly says) the more consistent model would be for the
>>> hypervisor to do the cleanup. Such cleanup would imo be reasonable
>>> only if there was an easy way for the hypervisor to enumerate all
>>> p2m_ioreq_server pages.
>>
>> Well, for me, the "easy way" means we should avoid traversing the whole ept
>> paging structure all at once, right?
> 
> Yes.

Does calling p2m_change_entry_type_global() not satisfy this requirement?

>> I have not figured out any clean 
>> solution
>> in hypervisor side, that's one reason I'd like to left this job to 
>> device model
>> side(another reason is that I do think device model should take this 
>> responsibility).
> 
> Let's see if we can get George to agree.

Well I had in principle already agreed to letting this be the interface
on the previous round of patches; we're having this discussion because
you (Jan) asked about what happens if an ioreq server is de-registered
while there are still outstanding p2m types. :-)

I do think having Xen change the type makes the most sense, but if
you're happy to leave that up to the ioreq server, I'm OK with things
being done that way as well.  I think we can probably change it later if
we want.

 -George

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

[Xen-devel] [PATCH] xen/pciback: Fix conf_space read/write overlap check.

2016-06-21 Thread Andrey Grodzovsky

Current overlap check is evaluating to false a case where a filter field
is fully contained (proper subset) of a r/w request.
This change applies classical overlap check instead to include
all the scenarios.

Related to https://www.mail-archive.com/xen-devel@lists.xen.org/msg72174.html

Cc: Jan Beulich 
Cc: Boris Ostrovsky 
Cc: sta...@vger.kernel.org
Signed-off-by: Andrey Grodzovsky 
---
 drivers/xen/xen-pciback/conf_space.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xen-pciback/conf_space.c 
b/drivers/xen/xen-pciback/conf_space.c
index 8e67336..6a25533 100644
--- a/drivers/xen/xen-pciback/conf_space.c
+++ b/drivers/xen/xen-pciback/conf_space.c
@@ -183,8 +183,7 @@ int xen_pcibk_config_read(struct pci_dev *dev, int offset, 
int size,
field_start = OFFSET(cfg_entry);
field_end = OFFSET(cfg_entry) + field->size;
 
-   if ((req_start >= field_start && req_start < field_end)
-   || (req_end > field_start && req_end <= field_end)) {
+if (req_end > field_start && field_end > req_start) {
err = conf_space_read(dev, cfg_entry, field_start,
  _val);
if (err)
@@ -230,8 +229,7 @@ int xen_pcibk_config_write(struct pci_dev *dev, int offset, 
int size, u32 value)
field_start = OFFSET(cfg_entry);
field_end = OFFSET(cfg_entry) + field->size;
 
-   if ((req_start >= field_start && req_start < field_end)
-   || (req_end > field_start && req_end <= field_end)) {
+if (req_end > field_start && field_end > req_start) {
tmp_val = 0;
 
err = xen_pcibk_config_read(dev, field_start,
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 6/8] arm: vgic: Split vgic_domain_init() functionality into two functions

2016-06-21 Thread Shanker Donthineni




On 06/21/2016 05:49 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

Split code that installs mmio handlers for GICD and Re-distributor
regions to a new function. The intension of this separation is to defer
steps that registers vgic_v2/v3 mmio handlers.


Looking at this patch and the follow-up ones, I don't think this is 
the right way to go. You differ the registration of the IO handlers 
just because you are unable to find the size of the handlers array.



Is there any better approach?

I am wondering if the array for the handlers is the best solution 
here. On another side, it would be possible to find the maximum of 
handlers before hand.


The purpose of this change is to limit size of 'struct domain' less than 
PAGE_SIZE. I can think of second approach split vgic_init() into two 
stages, one for vgic registration and the second one for vgic_init(). 
This also requires a few lines of code changes to vgic_v2/v3_init() and 
vgic_init().


int arch_domain_create(struct domain *d, unsigned int domcr_flags,
   struct xen_arch_domainconfig *config)
   ...
   domain_vgic_register(d));

   domain_io_init(d, mmio_count);

   domain_vgic_init(d, config->nr_spis));


diff --git a/xen/arch/arm/vgic.c b/xen/arch/arm/vgic.c
index 5df5f01..5b39e0d 100644
--- a/xen/arch/arm/vgic.c
+++ b/xen/arch/arm/vgic.c
@@ -151,9 +151,12 @@ int domain_vgic_init(struct domain *d, unsigned int

nr_spis)

  for ( i = 0; i < NR_GIC_SGI; i++ )
  set_bit(i, d->arch.vgic.allocated_irqs);

+d->arch.vgic.handler->domain_register_mmio(d);
+
  return 0;
  }

+


Spurious change.


  void register_vgic_ops(struct domain *d, const struct vgic_ops *ops)
  {
 d->arch.vgic.handler = ops;
diff --git a/xen/include/asm-arm/vgic.h b/xen/include/asm-arm/vgic.h
index fbb763a..8fe65b4 100644
--- a/xen/include/asm-arm/vgic.h
+++ b/xen/include/asm-arm/vgic.h
@@ -132,6 +132,8 @@ struct vgic_ops {
  void (*domain_free)(struct domain *d);
  /* vGIC sysreg emulation */
  int (*emulate_sysreg)(struct cpu_user_regs *regs, union hsr hsr);
+/* Register mmio handlers */
+void (*domain_register_mmio)(struct domain *d);
  /* Maximum number of vCPU supported */
  const unsigned int max_vcpus;
  };



Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

2016-06-21 Thread Juergen Gross

On 21/06/16 16:17, Boris Ostrovsky wrote:
> This will match how PMU errors are reported at check_hw_exists()'s
> msr_fail label, which is reached when VPMU initialzation fails.
> 
> Signed-off-by: Boris Ostrovsky 

Acked-by: Juergen Gross 

> ---
>  arch/x86/xen/pmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
> index 9466354..32bdc2c 100644
> --- a/arch/x86/xen/pmu.c
> +++ b/arch/x86/xen/pmu.c
> @@ -547,7 +547,7 @@ void xen_pmu_init(int cpu)
>   return;
>  
>  fail:
> - pr_warn_once("Could not initialize VPMU for cpu %d, error %d\n",
> + pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
>   cpu, err);
>   free_pages((unsigned long)xenpmu_data, 0);
>  }
> 


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

[Xen-devel] [PATCH 0/3] libxl: add framework for device types

2016-06-21 Thread Juergen Gross

Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.

I especially found it annoying that e.g. the vtpm callback issued the
error message for a failed attach of nic devices.

Juergen Gross (3):
  libxl: add framework for device types
  libxl: refactor domcreate_attach_pci() to use device type framework
  libxl: refactor domcreate_attach_dtdev() to use device type framework

 tools/libxl/libxl.c  |  12 ++
 tools/libxl/libxl_create.c   | 275 +--
 tools/libxl/libxl_internal.h |  14 +++
 tools/libxl/libxl_pci.c  |  36 ++
 tools/libxl/libxl_pvusb.c|  13 ++
 5 files changed, 159 insertions(+), 191 deletions(-)

-- 
2.6.6


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

[Xen-devel] [PATCH 1/3] libxl: add framework for device types

2016-06-21 Thread Juergen Gross

Instead of duplicate coding for each device type (vtpms, usbctrls, ...)
especially on domain creation introduce a framework for that purpose.

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl.c  |  12 
 tools/libxl/libxl_create.c   | 163 +--
 tools/libxl/libxl_internal.h |  13 
 tools/libxl/libxl_pvusb.c|  13 
 4 files changed, 87 insertions(+), 114 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 1c81239..df94f2e 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -7434,6 +7434,18 @@ out:
 return rc;
 }
 
+struct libxl_device_type libxl__nic_devtype = {
+.type   = "nic",
+.num_offset = offsetof(libxl_domain_config, num_nics),
+.add= libxl__add_nics,
+};
+
+struct libxl_device_type libxl__vtpm_devtype = {
+.type   = "vtpm",
+.num_offset = offsetof(libxl_domain_config, num_vtpms),
+.add= libxl__add_vtpms,
+};
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 1b99472..bb0f535 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -742,12 +742,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
 int ret);
 
-static void domcreate_attach_vtpms(libxl__egc *egc, libxl__multidev *multidev,
-   int ret);
-static void domcreate_attach_usbctrls(libxl__egc *egc,
-  libxl__multidev *multidev, int ret);
-static void domcreate_attach_usbdevs(libxl__egc *egc, libxl__multidev 
*multidev,
- int ret);
 static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
  int ret);
 static void domcreate_attach_dtdev(libxl__egc *egc,
@@ -1407,6 +1401,53 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 domcreate_complete(egc, dcs, ret);
 }
 
+static struct libxl_device_type *device_type_tbl[] = {
+__nic_devtype,
+__vtpm_devtype,
+__usbctrl_devtype,
+__usbdev_devtype,
+};
+
+static void domcreate_attach_devices(libxl__egc *egc,
+ libxl__multidev *multidev,
+ int ret)
+{
+libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
+STATE_AO_GC(dcs->ao);
+int domid = dcs->guest_domid;
+libxl_domain_config *const d_config = dcs->guest_config;
+struct libxl_device_type *dt;
+
+if (ret) {
+LOG(ERROR, "unable to add %s devices",
+device_type_tbl[dcs->device_type_idx]->type);
+goto error_out;
+}
+
+dcs->device_type_idx++;
+if (dcs->device_type_idx < ARRAY_SIZE(device_type_tbl)) {
+dt = device_type_tbl[dcs->device_type_idx];
+if (*(int *)((void *)d_config + dt->num_offset) > 0) {
+/* Attach devices */
+libxl__multidev_begin(ao, >multidev);
+dcs->multidev.callback = domcreate_attach_devices;
+dt->add(egc, ao, domid, d_config, >multidev);
+libxl__multidev_prepared(egc, >multidev, 0);
+return;
+}
+
+domcreate_attach_devices(egc, >multidev, 0);
+return;
+}
+
+domcreate_attach_pci(egc, multidev, 0);
+return;
+
+error_out:
+assert(ret);
+domcreate_complete(egc, dcs, ret);
+}
+
 static void domcreate_devmodel_started(libxl__egc *egc,
libxl__dm_spawn_state *dmss,
int ret)
@@ -1430,113 +1471,8 @@ static void domcreate_devmodel_started(libxl__egc *egc,
 }
 }
 
-/* Plug nic interfaces */
-if (d_config->num_nics > 0) {
-/* Attach nics */
-libxl__multidev_begin(ao, >multidev);
-dcs->multidev.callback = domcreate_attach_vtpms;
-libxl__add_nics(egc, ao, domid, d_config, >multidev);
-libxl__multidev_prepared(egc, >multidev, 0);
-return;
-}
-
-domcreate_attach_vtpms(egc, >multidev, 0);
-return;
-
-error_out:
-assert(ret);
-domcreate_complete(egc, dcs, ret);
-}
-
-static void domcreate_attach_vtpms(libxl__egc *egc,
-   libxl__multidev *multidev,
-   int ret)
-{
-   libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
-   STATE_AO_GC(dcs->ao);
-   int domid = dcs->guest_domid;
-
-   libxl_domain_config* const d_config = dcs->guest_config;
-
-   if(ret) {
-   LOG(ERROR, "unable to add nic devices");
-   goto error_out;
-   }
-
-/* Plug vtpm devices */
-   if (d_config->num_vtpms > 0) {
-   /* Attach vtpms */
-   libxl__multidev_begin(ao, >multidev);
-   dcs->multidev.callback = domcreate_attach_usbctrls;
-   libxl__add_vtpms(egc, ao, domid,

[Xen-devel] [PATCH 3/3] libxl: refactor domcreate_attach_dtdev() to use device type framework

2016-06-21 Thread Juergen Gross

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl_create.c | 72 ++
 1 file changed, 35 insertions(+), 37 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index c4e85f0..e93b880 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -742,9 +742,6 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
 int ret);
 
-static void domcreate_attach_dtdev(libxl__egc *egc, libxl__multidev *multidev,
-   int ret);
-
 static void domcreate_console_available(libxl__egc *egc,
 libxl__domain_create_state *dcs);
 
@@ -1399,12 +1396,43 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
 domcreate_complete(egc, dcs, ret);
 }
 
+static void libxl__add_dtdevs(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+  libxl_domain_config *d_config,
+  libxl__multidev *multidev)
+{
+AO_GC;
+libxl__ao_device *aodev = libxl__multidev_prepare(multidev);
+int i, rc = 0;
+
+for (i = 0; i < d_config->num_dtdevs; i++) {
+const libxl_device_dtdev *dtdev = _config->dtdevs[i];
+
+LOG(DEBUG, "Assign device \"%s\" to dom%u", dtdev->path, domid);
+rc = xc_assign_dt_device(CTX->xch, domid, dtdev->path);
+if (rc < 0) {
+LOG(ERROR, "xc_assign_dtdevice failed: %d", rc);
+goto out;
+}
+}
+
+out:
+aodev->rc = rc;
+aodev->callback(egc, aodev);
+}
+
+static struct libxl_device_type libxl__dtdev_devtype = {
+.type   = "dtdev",
+.num_offset = offsetof(libxl_domain_config, num_dtdevs),
+.add= libxl__add_dtdevs,
+};
+
 static struct libxl_device_type *device_type_tbl[] = {
 __nic_devtype,
 __vtpm_devtype,
 __usbctrl_devtype,
 __usbdev_devtype,
 __pci_devtype,
+__dtdev_devtype,
 };
 
 static void domcreate_attach_devices(libxl__egc *egc,
@@ -1439,7 +1467,10 @@ static void domcreate_attach_devices(libxl__egc *egc,
 return;
 }
 
-domcreate_attach_dtdev(egc, multidev, 0);
+domcreate_console_available(egc, dcs);
+
+domcreate_complete(egc, dcs, 0);
+
 return;
 
 error_out:
@@ -1479,39 +1510,6 @@ error_out:
 domcreate_complete(egc, dcs, ret);
 }
 
-static void domcreate_attach_dtdev(libxl__egc *egc,
-   libxl__multidev *multidev,
-   int ret)
-{
-libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
-STATE_AO_GC(dcs->ao);
-int i;
-int domid = dcs->guest_domid;
-
-/* convenience aliases */
-libxl_domain_config *const d_config = dcs->guest_config;
-
-for (i = 0; i < d_config->num_dtdevs; i++) {
-const libxl_device_dtdev *dtdev = _config->dtdevs[i];
-
-LOG(DEBUG, "Assign device \"%s\" to dom%u", dtdev->path, domid);
-ret = xc_assign_dt_device(CTX->xch, domid, dtdev->path);
-if (ret < 0) {
-LOG(ERROR, "xc_assign_dtdevice failed: %d", ret);
-goto error_out;
-}
-}
-
-domcreate_console_available(egc, dcs);
-
-domcreate_complete(egc, dcs, 0);
-return;
-
-error_out:
-assert(ret);
-domcreate_complete(egc, dcs, ret);
-}
-
 static void domcreate_complete(libxl__egc *egc,
libxl__domain_create_state *dcs,
int rc)
-- 
2.6.6


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

[Xen-devel] [PATCH 2/3] libxl: refactor domcreate_attach_pci() to use device type framework

2016-06-21 Thread Juergen Gross

Signed-off-by: Juergen Gross 
---
 tools/libxl/libxl_create.c   | 54 ++--
 tools/libxl/libxl_internal.h |  1 +
 tools/libxl/libxl_pci.c  | 36 +
 3 files changed, 44 insertions(+), 47 deletions(-)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index bb0f535..c4e85f0 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -742,10 +742,8 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *aodevs,
 int ret);
 
-static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *aodevs,
- int ret);
-static void domcreate_attach_dtdev(libxl__egc *egc,
-   libxl__domain_create_state *dcs);
+static void domcreate_attach_dtdev(libxl__egc *egc, libxl__multidev *multidev,
+   int ret);
 
 static void domcreate_console_available(libxl__egc *egc,
 libxl__domain_create_state *dcs);
@@ -1406,6 +1404,7 @@ static struct libxl_device_type *device_type_tbl[] = {
 __vtpm_devtype,
 __usbctrl_devtype,
 __usbdev_devtype,
+__pci_devtype,
 };
 
 static void domcreate_attach_devices(libxl__egc *egc,
@@ -1440,7 +1439,7 @@ static void domcreate_attach_devices(libxl__egc *egc,
 return;
 }
 
-domcreate_attach_pci(egc, multidev, 0);
+domcreate_attach_dtdev(egc, multidev, 0);
 return;
 
 error_out:
@@ -1480,52 +1479,13 @@ error_out:
 domcreate_complete(egc, dcs, ret);
 }
 
-static void domcreate_attach_pci(libxl__egc *egc, libxl__multidev *multidev,
- int ret)
-{
-libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
-STATE_AO_GC(dcs->ao);
-int i;
-int domid = dcs->guest_domid;
-
-/* convenience aliases */
-libxl_domain_config *const d_config = dcs->guest_config;
-
-if (ret) {
-goto error_out;
-}
-
-for (i = 0; i < d_config->num_pcidevs; i++) {
-ret = libxl__device_pci_add(gc, domid, _config->pcidevs[i], 1);
-if (ret < 0) {
-LOG(ERROR, "libxl_device_pci_add failed: %d", ret);
-goto error_out;
-}
-}
-
-if (d_config->num_pcidevs > 0) {
-ret = libxl__create_pci_backend(gc, domid, d_config->pcidevs,
-d_config->num_pcidevs);
-if (ret < 0) {
-LOG(ERROR, "libxl_create_pci_backend failed: %d", ret);
-goto error_out;
-}
-}
-
-domcreate_attach_dtdev(egc, dcs);
-return;
-
-error_out:
-assert(ret);
-domcreate_complete(egc, dcs, ret);
-}
-
 static void domcreate_attach_dtdev(libxl__egc *egc,
-   libxl__domain_create_state *dcs)
+   libxl__multidev *multidev,
+   int ret)
 {
+libxl__domain_create_state *dcs = CONTAINER_OF(multidev, *dcs, multidev);
 STATE_AO_GC(dcs->ao);
 int i;
-int ret;
 int domid = dcs->guest_domid;
 
 /* convenience aliases */
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 2603b33..547a78b 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3401,6 +3401,7 @@ extern struct libxl_device_type libxl__nic_devtype;
 extern struct libxl_device_type libxl__vtpm_devtype;
 extern struct libxl_device_type libxl__usbctrl_devtype;
 extern struct libxl_device_type libxl__usbdev_devtype;
+extern struct libxl_device_type libxl__pci_devtype;
 /*- Domain destruction -*/
 
 /* Domain destruction has been split into two functions:
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index 236bdd0..fd245ea 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -1291,6 +1291,36 @@ out:
 return rc;
 }
 
+static void libxl__add_pcis(libxl__egc *egc, libxl__ao *ao, uint32_t domid,
+libxl_domain_config *d_config,
+libxl__multidev *multidev)
+{
+AO_GC;
+libxl__ao_device *aodev = libxl__multidev_prepare(multidev);
+int i, rc = 0;
+
+for (i = 0; i < d_config->num_pcidevs; i++) {
+rc = libxl__device_pci_add(gc, domid, _config->pcidevs[i], 1);
+if (rc < 0) {
+LOG(ERROR, "libxl_device_pci_add failed: %d", rc);
+goto out;
+}
+}
+
+if (d_config->num_pcidevs > 0) {
+rc = libxl__create_pci_backend(gc, domid, d_config->pcidevs,
+d_config->num_pcidevs);
+if (rc < 0) {
+LOG(ERROR, "libxl_create_pci_backend failed: %d", rc);
+goto out;
+}
+}
+
+out:
+aodev->rc = rc;
+aodev->callback(egc, aodev);
+}
+
 static int qemu_pci_remove_xenstore(libxl__gc *gc, uint32_t domid,
 libxl_device_pci

Re: [Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

2016-06-21 Thread Konrad Rzeszutek Wilk

On Tue, Jun 21, 2016 at 10:17:33AM -0400, Boris Ostrovsky wrote:
> This will match how PMU errors are reported at check_hw_exists()'s
> msr_fail label, which is reached when VPMU initialzation fails.
> 
> Signed-off-by: Boris Ostrovsky 

Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  arch/x86/xen/pmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
> index 9466354..32bdc2c 100644
> --- a/arch/x86/xen/pmu.c
> +++ b/arch/x86/xen/pmu.c
> @@ -547,7 +547,7 @@ void xen_pmu_init(int cpu)
>   return;
>  
>  fail:
> - pr_warn_once("Could not initialize VPMU for cpu %d, error %d\n",
> + pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
>   cpu, err);
>   free_pages((unsigned long)xenpmu_data, 0);
>  }
> -- 
> 1.8.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH] xen/PMU: Log VPMU initialization error at lower level

2016-06-21 Thread Boris Ostrovsky

This will match how PMU errors are reported at check_hw_exists()'s
msr_fail label, which is reached when VPMU initialzation fails.

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

diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 9466354..32bdc2c 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -547,7 +547,7 @@ void xen_pmu_init(int cpu)
return;
 
 fail:
-   pr_warn_once("Could not initialize VPMU for cpu %d, error %d\n",
+   pr_info_once("Could not initialize VPMU for cpu %d, error %d\n",
cpu, err);
free_pages((unsigned long)xenpmu_data, 0);
 }
-- 
1.8.1.4


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

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

2016-06-21 Thread Shanker Donthineni




On 06/21/2016 08:50 AM, Julien Grall wrote:



On 21/06/16 14:37, Shanker Donthineni wrote:

On 06/21/2016 04:28 AM, Julien Grall wrote:

On 19/06/16 00:45, Shanker Donthineni wrote:

The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware should describe Redistributor base address
in the associated GIC CPU Interface (GICC) instead of GIC

Redistributor

(GICR) table.

The maximum number of mmio handlers and struct vgic_rdist_region
that holds Redistributor addresses are allocated through a static
array with hardcoded size. I don't think this is the right approach
and is not scalable for implementing features like this. I have
decided to convert static to dynamic allocation based on comments
from the below link.

https://patchwork.kernel.org/patch/9163435/


You addressed only one part of my comment. This series increases the
number of I/O handlers but the lookup is still linear (see handle_mmio
in arch/arm/io.c).


I agree with you, we need to bring binary search algorithm similar to
Linux KVM code. I want to keep it this change outside of this patchset.


This should be a prerequisite of this series then, not a follow-up.

For the  functionality and correctness purpose we don't need this change 
immediately.
We are not able to boot XEN on Qualcomm Technologies because of not 
supporting

GICC table parsing for GICR address.

I am okay to wait for my patchset if someone adding bseach look ups for 
mmio handlers.



Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH 2/8] arm/gic-v3: Fold GICR subtable parsing into a new function

2016-06-21 Thread Shanker Donthineni




On 06/21/2016 05:17 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

Add a new function for parsing GICR subtable and move the code
that is specific to GICR table to new function without changing
the function gicv3_acpi_init() behavior.

Signed-off-by: Shanker Donthineni 
---
  xen/arch/arm/gic-v3.c | 64

+--

  1 file changed, 42 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index ab1f380..af12ebc 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1387,6 +1387,36 @@ gic_acpi_parse_madt_distributor(struct

acpi_subtable_header *header,


  return 0;
  }
+
+static int __init
+gic_acpi_parse_madt_redistributor(struct acpi_subtable_header *header,
+  const unsigned long end)
+{
+struct acpi_madt_generic_redistributor *rdist;
+struct rdist_region *region;
+
+region = gicv3.rdist_regions + gicv3.rdist_count;
+rdist = (struct acpi_madt_generic_redistributor *)header;
+if ( BAD_MADT_ENTRY(rdist, end) )
+return -EINVAL;
+
+if ( !rdist->base_address || !rdist->length )
+return -EINVAL;
+
+region->base = rdist->base_address;
+region->size = rdist->length;
+
+region->map_base = ioremap_nocache(region->base, region->size);


In the commit message you said there is no functional change, however 
the remapping is not part of gicv3_acpi_init. So why did you add this 
line here?


Thanks for catching coding bug, it was my mistake and this code should 
not be here.

+if ( !region->map_base )
+{
+printk("Unable to map GICR registers\n");
+return -ENOMEM;
+}
+gicv3.rdist_count++;
+
+return 0;
+}
+


[...]

Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

Re: [Xen-devel] [PATCH 3/8] arm/gic-v3: Parse per-cpu redistributor entry in GICC subtable

2016-06-21 Thread Shanker Donthineni




On 06/21/2016 05:16 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

The redistributor address can be specified either as part of GICC or
GICR subtable depending on the power domain. The current driver
doesn't support parsing redistributor entry that is defined in GICC
subtable. The GIC CPU subtable entry holds the associated Redistributor
base address if it is not on always-on power domain.

This patch adds necessary code to handle both types of Redistributors
base addresses.

Signed-off-by: Shanker Donthineni 
---
  xen/arch/arm/gic-v3.c | 97

---

  xen/include/asm-arm/gic.h |  2 +
  xen/include/asm-arm/gic_v3_defs.h |  1 +
  3 files changed, 83 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index af12ebc..42cf848 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -659,6 +659,10 @@ static int __init gicv3_populate_rdist(void)
  smp_processor_id(), i, ptr);
  return 0;
  }
+
+if ( gicv3.rdist_regions[i].single_rdist )
+break;
+
  if ( gicv3.rdist_stride )
  ptr += gicv3.rdist_stride;
  else
@@ -1282,6 +1286,11 @@ static int gicv3_iomem_deny_access(const struct

domain *d)

  }

  #ifdef CONFIG_ACPI
+static bool gic_dist_supports_dvis(void)


static inline and please use bool_t here.


Still learning XEN coding style, I'll fix it.

+{
+return !!(readl_relaxed(GICD + GICD_TYPER) & GICD_TYPER_DVIS);
+}
+
  static int gicv3_make_hwdom_madt(const struct domain *d, u32 offset)
  {
  struct acpi_subtable_header *header;
@@ -1393,18 +1402,39 @@ gic_acpi_parse_madt_redistributor(struct

acpi_subtable_header *header,

const unsigned long end)
  {
  struct acpi_madt_generic_redistributor *rdist;
+struct acpi_madt_generic_interrupt *processor;
  struct rdist_region *region;

  region = gicv3.rdist_regions + gicv3.rdist_count;
-rdist = (struct acpi_madt_generic_redistributor *)header;
-if ( BAD_MADT_ENTRY(rdist, end) )
-return -EINVAL;
+if ( header->type == ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR )
+{
+rdist = (struct acpi_madt_generic_redistributor *)header;
+if ( BAD_MADT_ENTRY(rdist, end) )
+return -EINVAL;

-if ( !rdist->base_address || !rdist->length )
-return -EINVAL;
+if ( !rdist->base_address || !rdist->length )
+return -EINVAL;
+
+region->base = rdist->base_address;
+region->size = rdist->length;
+}
+else if ( header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT )
+{


Parsing the GICC and the redistributor is quite different. I would 
much prefer a function for parsing each table and an helper to add a 
new redistributor.



 I'll do.

+processor = (struct acpi_madt_generic_interrupt *)header;
+if ( BAD_MADT_ENTRY(processor, end) )
+return -EINVAL;
+
+if ( !(processor->flags & ACPI_MADT_ENABLED) )
+return 0;
+
+if ( !processor->gicr_base_address )
+return -EINVAL;
+
+region->base = processor->gicr_base_address;
+region->size = gic_dist_supports_dvis() ? SZ_256K : SZ_128K;


Please explain in the commit message how you find the size. I would 
also prefer if you use (4 x SZ_64K) and (2 * SZ_64K) as we do in

populate_rdist.


+region->single_rdist = true;


The indentation looks wrong.


+   }





-region->base = rdist->base_address;
-region->size = rdist->length;

  region->map_base = ioremap_nocache(region->base, region->size);
  if ( !region->map_base )
@@ -1412,6 +1442,7 @@ gic_acpi_parse_madt_redistributor(struct

acpi_subtable_header *header,

  printk("Unable to map GICR registers\n");
  return -ENOMEM;
  }
+


Spurious change.


  gicv3.rdist_count++;

  return 0;
@@ -1421,9 +1452,22 @@ static int __init
  gic_acpi_get_madt_redistributor_num(struct acpi_subtable_header

*header,

const unsigned long end)
  {
-/* Nothing to do here since it only wants to get the number of GIC
- * redistributors.
- */
+struct acpi_madt_generic_redistributor *rdist;
+struct acpi_madt_generic_interrupt *cpuif;
+
+if ( header->type == ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR )
+{
+ rdist = (struct acpi_madt_generic_redistributor *)header;
+ if ( BAD_MADT_ENTRY(rdist, end) || !rdist->base_address )
+ return -EINVAL;
+}
+else if ( header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT )
+{
+ cpuif = (struct acpi_madt_generic_interrupt *)header;
+ if ( BAD_MADT_ENTRY(cpuif, end) || !cpuif->gicr_base_address )
+ return -EINVAL;
+}
+


Ditto for the parsing.


  return 0;
  }



[...]


diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

2016-06-21 Thread Julien Grall




On 21/06/16 14:37, Shanker Donthineni wrote:

On 06/21/2016 04:28 AM, Julien Grall wrote:

On 19/06/16 00:45, Shanker Donthineni wrote:

The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware should describe Redistributor base address
in the associated GIC CPU Interface (GICC) instead of GIC Redistributor
(GICR) table.

The maximum number of mmio handlers and struct vgic_rdist_region
that holds Redistributor addresses are allocated through a static
array with hardcoded size. I don't think this is the right approach
and is not scalable for implementing features like this. I have
decided to convert static to dynamic allocation based on comments
from the below link.

https://patchwork.kernel.org/patch/9163435/


You addressed only one part of my comment. This series increases the
number of I/O handlers but the lookup is still linear (see handle_mmio
in arch/arm/io.c).


I agree with you, we need to bring binary search algorithm similar to
Linux KVM code. I want to keep it this change outside of this patchset.


This should be a prerequisite of this series then, not a follow-up.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/8] Add support for parsing per CPU Redistributor entry

2016-06-21 Thread Shanker Donthineni




On 06/21/2016 04:28 AM, Julien Grall wrote:

Hello Shanker,

On 19/06/16 00:45, Shanker Donthineni wrote:

The current driver doesn't support parsing Redistributor entries that
are described in the MADT GICC table. Not all the GIC implementors
places the Redistributor regions in the always-on power domain. On
systems, the UEFI firmware should describe Redistributor base address
in the associated GIC CPU Interface (GICC) instead of GIC Redistributor
(GICR) table.

The maximum number of mmio handlers and struct vgic_rdist_region
that holds Redistributor addresses are allocated through a static
array with hardcoded size. I don't think this is the right approach
and is not scalable for implementing features like this. I have
decided to convert static to dynamic allocation based on comments
from the below link.

https://patchwork.kernel.org/patch/9163435/


You addressed only one part of my comment. This series increases the 
number of I/O handlers but the lookup is still linear (see handle_mmio 
in arch/arm/io.c).


I agree with you, we need to bring binary search algorithm similar to 
Linux KVM code. I want to keep it this change outside of this patchset.
After this series, the maximum number of I/O handlers is 160. So in 
the worst case, we have to do 160 iterations before finding an handler 
or concluding the I/O cannot be emulated.


Regards,



--
Shanker Donthineni
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project


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

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

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  57a57465daaf8fb66d192ff98b8477524091e82c
baseline version:
 xen  0630892fafe87ff5e3b65422d38158de46db3ed0

Last test of basis96011  2016-06-20 14:02:02 Z0 days
Testing same since96055  2016-06-21 11:02:43 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [libvirt test] 96038: tolerable FAIL - PUSHED

2016-06-21 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  a1e1679c8aaa8256332954c20ec24dd938ef8a58
baseline version:
 libvirt  eac167e2610d3e59b32f7ec7ba78cbc8c420a425

Last test of basis95913  2016-06-19 04:21:33 Z2 days
Testing same since96038  2016-06-21 04:21:00 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Chen Hanxiao 
  Jaroslav Suchanek 
  JÃ¡n Tomko 
  Peter Krempa 
  Tomasz Flendrich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 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 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=libvirt
+ revision=a1e1679c8aaa8256332954c20ec24dd938ef8a58
+ . ./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 ']'
++

Re: [Xen-devel] [PATCH v9 1/3] vt-d: fix the IOMMU flush issue

2016-06-21 Thread Jan Beulich

>>> On 17.06.16 at 05:37,  wrote:
> @@ -546,17 +550,37 @@ static int __must_check iommu_flush_all(void)
>  struct acpi_drhd_unit *drhd;
>  struct iommu *iommu;
>  int flush_dev_iotlb;
> +int rc = 0;
>  
>  flush_all_cache();
>  for_each_drhd_unit ( drhd )
>  {
> +int context_rc, iotlb_rc;
> +
>  iommu = drhd->iommu;
> -iommu_flush_context_global(iommu, 0);
> +context_rc = iommu_flush_context_global(iommu, 0);
>  flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
> -iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> +iotlb_rc = iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
> +
> +/*
> + * The current logic for returns:
> + *   - positive  invoke iommu_flush_write_buffer to flush cache.
> + *   - zero  on success.
> + *   - negative  on failure. Continue to flush IOMMU IOTLB on a
> + *   best effort basis.
> + */
> +if ( context_rc > 0 || iotlb_rc > 0 )
> +iommu_flush_write_buffer(iommu);
> +if ( context_rc >= 0 )

Wasn't this meant to be just "rc"? (I can't, btw, imagine Kevin's ack
to be rightfully retained with a change like this.)

Jan


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

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Oleksandr Tyshchenko

On Tue, Jun 21, 2016 at 4:01 PM, Dirk Behme  wrote:
> Hello Oleksandr,
>
>
> On 21.06.2016 14:54, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall 
>> wrote:
>>>
>>>
>>>
>>> On 21/06/16 11:16, Oleksandr Tyshchenko wrote:


 Hi, Dirk.
>>>
>>>
>>>
>>> Hello Oleksandr,
>>
>>
>> Hello Julien.
>>>
>>>
>>>
 On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme 
 wrote:
>
>
> In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic
> error
> if this is different later. Detect this by an ASSERT, but remove the
> dead code normally never reached.
>
> Signed-off-by: Dirk Behme 
> ---
>   xen/drivers/char/scif-uart.c | 23 ++-
>   1 file changed, 6 insertions(+), 17 deletions(-)
>
> diff --git a/xen/drivers/char/scif-uart.c
> b/xen/drivers/char/scif-uart.c
> index 51a2233..ca88c0f 100644
> --- a/xen/drivers/char/scif-uart.c
> +++ b/xen/drivers/char/scif-uart.c
> @@ -143,23 +143,12 @@ static void __init scif_uart_init_preirq(struct
> serial_port *port)
>   scif_writew(uart, SCIF_SCSMR, val);
>
>   ASSERT( uart->clock_hz > 0 );
> -if ( uart->baud != BAUD_AUTO )
> -{
> -/* Setup desired Baud rate */
> -divisor = uart->clock_hz / (uart->baud << 4);
> -ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
> -scif_writew(uart, SCIF_DL, (uint16_t)divisor);
> -/* Selects the frequency divided clock (SC_CLK external input)
> */
> -scif_writew(uart, SCIF_CKS, 0);
> -udelay(100 / uart->baud + 1);



 This part of code might be used for people who are not satisfied with
 default baudrate which has been set in U-Boot.
>>>
>>>
>>>
>>> Can you elaborate? If the baud rate is different, it will not be possible
>>> to
>>> get output from U-boot.
>>>
 If we remove this we will take away the opportunity to just change
 uart->baud from BAUD_AUTO to desired one.
>>>
>>>
>>>
>>> I have some doubt that the current code is valid. The clock frequency is
>>> hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is
>>> always the same across all the platforms?
>>
>>
>> No.
>>
>> This driver has been initially written for Renesas Lager board based
>> on R-Car H2 SoC which
>> has SCIF compatible UART. And the current code is valid for it. I have
>> tested both auto and
>> variable (38400, 115200) baudrates.
>
>
>
> Could you help me a little to understand this?
>
> The driver has
>
> scif_uart_init()
> {
> ...
> struct scif_uart *uart;
> ...
> uart->baud  = BAUD_AUTO;
> ...
> }
>
> I checked the code for struct scif_uart but it isn't used anywhere outside
> this driver. So uart->baud is a driver local variable, which looks to me
> isn't used anywhere useful.
>
> What have I missed?

Unfortunately, I don't have recent Xen sources right now to be 100%
sure. But, it seems you are right: uart->baud is a driver local
variable.

>
> Best regards
>
> Dirk
>
>
>
>> But, I am afraid that current code won't be suitable for
>> all of the boards which have the same UART IP. It depends at least
>> from clock source
>> (external/internal) and clock frequency.
>>
>>>
>>> I would rather avoid to keep dead code (or not accessible without hacking
>>> Xen). For what is worth, we recently removed a similar code from the
>>> PL011
>>> driver as this should be correctly configured by the firmware.
>>>
> -}
> -else
> -{
> -/* Read current Baud rate */
> -divisor = scif_readw(uart, SCIF_DL);
> -ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
> -uart->baud = uart->clock_hz / (divisor << 4);
> -}
> +ASSERT( uart->baud == BAUD_AUTO );
> +
> +/* Read current Baud rate */
> +divisor = scif_readw(uart, SCIF_DL);
> +ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
> +uart->baud = uart->clock_hz / (divisor << 4);
>
>   /* Setup trigger level for TX/RX FIFOs */
>   scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
> --
> 2.8.0
>
>>>
>>> Regards,



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

[Xen-devel] [PATCH v3 5/8] xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the typesafe gfn

2016-06-21 Thread Julien Grall

The correct acronym for a guest physical frame is gfn. Also use
the typesafe gfn to ensure that a guest frame is effectively used.

Signed-off-by: Julien Grall 

---
Changes in v2:
- Remove extra pair of brackets.
---
 xen/arch/arm/domain.c | 4 ++--
 xen/arch/arm/mm.c | 2 +-
 xen/include/asm-arm/domain.h  | 2 +-
 xen/include/asm-arm/grant_table.h | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index d8a804c..6ce4645 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -464,13 +464,13 @@ struct domain *alloc_domain_struct(void)
 return NULL;
 
 clear_page(d);
-d->arch.grant_table_gpfn = xzalloc_array(xen_pfn_t, max_grant_frames);
+d->arch.grant_table_gfn = xzalloc_array(gfn_t, max_grant_frames);
 return d;
 }
 
 void free_domain_struct(struct domain *d)
 {
-xfree(d->arch.grant_table_gpfn);
+xfree(d->arch.grant_table_gfn);
 free_xenheap_page(d);
 }
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 6882d54..0e408f8 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1082,7 +1082,7 @@ int xenmem_add_to_physmap_one(
 return -EINVAL;
 }
 
-d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
+d->arch.grant_table_gfn[idx] = gfn;
 
 t = p2m_ram_rw;
 
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 370cdeb..979f7de 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -51,7 +51,7 @@ struct arch_domain
 uint64_t vttbr;
 
 struct hvm_domain hvm_domain;
-xen_pfn_t *grant_table_gpfn;
+gfn_t *grant_table_gfn;
 
 struct vmmio vmmio;
 
diff --git a/xen/include/asm-arm/grant_table.h 
b/xen/include/asm-arm/grant_table.h
index 5e076cc..eb02423 100644
--- a/xen/include/asm-arm/grant_table.h
+++ b/xen/include/asm-arm/grant_table.h
@@ -30,7 +30,7 @@ static inline int replace_grant_supported(void)
 
 #define gnttab_shared_gmfn(d, t, i)  \
 ( ((i >= nr_grant_frames(d->grant_table)) && \
- (i < max_grant_frames)) ? 0 : (d->arch.grant_table_gpfn[i]))
+ (i < max_grant_frames)) ? 0 : gfn_x(d->arch.grant_table_gfn[i]))
 
 #define gnttab_need_iommu_mapping(d)\
 (is_domain_direct_mapped(d) && need_iommu(d))
-- 
1.9.1


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

[Xen-devel] [PATCH v3 2/8] xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn

2016-06-21 Thread Julien Grall

Those helpers will be useful to do common operations without having to
unbox/box manually the GFNs/MFNs.

Signed-off-by: Julien Grall 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v3:
- Use inline functions rather than macros

Changes in v2:
- Rename min_gfn/max_gfn to gfn_min/gfn_max
- Add more helpers for gfn and mfn
---
 xen/include/xen/mm.h | 41 +
 1 file changed, 41 insertions(+)

diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3cf646a..13f706e 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 TYPE_SAFE(unsigned long, mfn);
@@ -61,6 +62,26 @@ TYPE_SAFE(unsigned long, mfn);
 #undef mfn_t
 #endif
 
+static inline mfn_t mfn_add(mfn_t mfn, unsigned long i)
+{
+return _mfn(mfn_x(mfn) + i);
+}
+
+static inline mfn_t mfn_max(mfn_t x, mfn_t y)
+{
+return _mfn(max(mfn_x(x), mfn_x(y)));
+}
+
+static inline mfn_t mfn_min(mfn_t x, mfn_t y)
+{
+return _mfn(min(mfn_x(x), mfn_x(y)));
+}
+
+static inline bool_t mfn_eq(mfn_t x, mfn_t y)
+{
+return mfn_x(x) == mfn_x(y);
+}
+
 TYPE_SAFE(unsigned long, gfn);
 #define PRI_gfn  "05lx"
 #define INVALID_GFN  (~0UL)
@@ -70,6 +91,26 @@ TYPE_SAFE(unsigned long, gfn);
 #undef gfn_t
 #endif
 
+static inline gfn_t gfn_add(gfn_t gfn, unsigned long i)
+{
+return _gfn(gfn_x(gfn) + i);
+}
+
+static inline gfn_t gfn_max(gfn_t x, gfn_t y)
+{
+return _gfn(max(gfn_x(x), gfn_x(y)));
+}
+
+static inline gfn_t gfn_min(gfn_t x, gfn_t y)
+{
+return _gfn(min(gfn_x(x), gfn_x(y)));
+}
+
+static inline bool_t gfn_eq(gfn_t x, gfn_t y)
+{
+return gfn_x(x) == gfn_x(y);
+}
+
 TYPE_SAFE(unsigned long, pfn);
 #define PRI_pfn  "05lx"
 #define INVALID_PFN  (~0UL)
-- 
1.9.1


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

[Xen-devel] [PATCH v3 1/8] xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe

2016-06-21 Thread Julien Grall

The correct acronym for a guest physical frame is gfn. Also use
the recently introduced typesafe gfn/mfn to avoid mixing the two
different kind of frame.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v2:
- Add Jan's acked-by
- CCed the relevant maintainers
---
 xen/arch/arm/p2m.c| 6 +++---
 xen/common/grant_table.c  | 4 ++--
 xen/common/memory.c   | 4 ++--
 xen/include/asm-arm/p2m.h | 2 +-
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 65d8f1a..ab0cb41 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1481,10 +1481,10 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
  d->arch.p2m.default_access);
 }
 
-unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn)
+mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
 {
-paddr_t p = p2m_lookup(d, pfn_to_paddr(gpfn), NULL);
-return p >> PAGE_SHIFT;
+paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
+return _mfn(p >> PAGE_SHIFT);
 }
 
 /*
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 8b22299..3c304f4 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -256,7 +256,7 @@ static int __get_paged_frame(unsigned long gfn, unsigned 
long *frame, struct pag
 }
 *frame = page_to_mfn(*page);
 #else
-*frame = gmfn_to_mfn(rd, gfn);
+*frame = mfn_x(gfn_to_mfn(rd, _gfn(gfn)));
 *page = mfn_valid(*frame) ? mfn_to_page(*frame) : NULL;
 if ( (!(*page)) || (!get_page(*page, rd)) )
 {
@@ -1788,7 +1788,7 @@ gnttab_transfer(
 mfn = INVALID_MFN;
 }
 #else
-mfn = gmfn_to_mfn(d, gop.mfn);
+mfn = mfn_x(gfn_to_mfn(d, _gfn(gop.mfn)));
 #endif
 
 /* Check the passed page frame for basic validity. */
diff --git a/xen/common/memory.c b/xen/common/memory.c
index 46b1d9f..b54b076 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -264,7 +264,7 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
 return 1;
 }
 #else
-mfn = gmfn_to_mfn(d, gmfn);
+mfn = mfn_x(gfn_to_mfn(d, _gfn(gmfn)));
 #endif
 if ( unlikely(!mfn_valid(mfn)) )
 {
@@ -488,7 +488,7 @@ static long 
memory_exchange(XEN_GUEST_HANDLE_PARAM(xen_memory_exchange_t) arg)
 goto fail; 
 }
 #else /* !CONFIG_X86 */
-mfn = gmfn_to_mfn(d, gmfn + k);
+mfn = mfn_x(gfn_to_mfn(d, _gfn(gmfn + k)));
 #endif
 if ( unlikely(!mfn_valid(mfn)) )
 {
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index d240d1e..75c65a8 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -178,7 +178,7 @@ void guest_physmap_remove_page(struct domain *d,
unsigned long gpfn,
unsigned long mfn, unsigned int page_order);
 
-unsigned long gmfn_to_mfn(struct domain *d, unsigned long gpfn);
+mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn);
 
 /*
  * Populate-on-demand
-- 
1.9.1


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

[Xen-devel] [PATCH v3 8/8] xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

2016-06-21 Thread Julien Grall

p2m_cache_flush is expecting GFNs in parameter and not MFNs. Rename
the variable to *gfn* and use typesafe to avoid possible misusage.

Note that the type of the parameters 'start' and 'end' is changed
from xen_pfn_t (aka uint64_t) to gfn_t (aka unsigned long). This
means that a truncation will occur for ARM32. It is fine because it
will always be encoded on 28 bits maximum (40 bits address).

Signed-off-by: Julien Grall 

---
Changes in v3:
- Add a word in the commit message about the truncation.

Changes in v2:
- Drop _gfn suffix
---
 xen/arch/arm/domctl.c |  2 +-
 xen/arch/arm/p2m.c| 10 +-
 xen/include/asm-arm/p2m.h |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 30453d8..b94e97c 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -30,7 +30,7 @@ long arch_do_domctl(struct xen_domctl *domctl, struct domain 
*d,
 if ( e < s )
 return -EINVAL;
 
-return p2m_cache_flush(d, s, e);
+return p2m_cache_flush(d, _gfn(s), _gfn(e));
 }
 case XEN_DOMCTL_bind_pt_irq:
 {
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index f3330dd..9149981 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1469,16 +1469,16 @@ int relinquish_p2m_mapping(struct domain *d)
   d->arch.p2m.default_access);
 }
 
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn)
+int p2m_cache_flush(struct domain *d, gfn_t start, gfn_t end)
 {
 struct p2m_domain *p2m = >arch.p2m;
 
-start_mfn = MAX(start_mfn, p2m->lowest_mapped_gfn);
-end_mfn = MIN(end_mfn, p2m->max_mapped_gfn);
+start = gfn_max(start, _gfn(p2m->lowest_mapped_gfn));
+end = gfn_min(end, _gfn(p2m->max_mapped_gfn));
 
 return apply_p2m_changes(d, CACHEFLUSH,
- pfn_to_paddr(start_mfn),
- pfn_to_paddr(end_mfn),
+ pfn_to_paddr(gfn_x(start)),
+ pfn_to_paddr(gfn_x(end)),
  pfn_to_paddr(INVALID_MFN),
  MATTR_MEM, 0, p2m_invalid,
  d->arch.p2m.default_access);
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index f204482..976e51e 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -139,7 +139,7 @@ void p2m_dump_info(struct domain *d);
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t);
 
 /* Clean & invalidate caches corresponding to a region of guest address space 
*/
-int p2m_cache_flush(struct domain *d, xen_pfn_t start_mfn, xen_pfn_t end_mfn);
+int p2m_cache_flush(struct domain *d, gfn_t start, gfn_t end);
 
 /* Setup p2m RAM mapping for domain d from start-end. */
 int p2m_populate_ram(struct domain *d, paddr_t start, paddr_t end);
-- 
1.9.1


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

[Xen-devel] [PATCH v3 3/8] xen: Use typesafe gfn/mfn in guest_physmap_* helpers

2016-06-21 Thread Julien Grall

Also rename some variables to gfn or mfn when it does not require much
rework.

Finally replace %hu with %d when printing the domain id in
guest_physmap_add_entry (arch/x86/mm/p2m.c).

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v3:
- Use %d to print the domain id rather than %hu
- Add Jan's Acked-by for non-ARM bits

Changes in v2:
- Don't use a wrapper for x86. Instead use mfn_* to make
the change simpler.
---
 xen/arch/arm/domain_build.c|  2 +-
 xen/arch/arm/mm.c  | 10 ++---
 xen/arch/arm/p2m.c | 20 +-
 xen/arch/x86/domain.c  |  5 ++-
 xen/arch/x86/domain_build.c|  6 +--
 xen/arch/x86/hvm/ioreq.c   |  8 ++--
 xen/arch/x86/mm.c  | 12 +++---
 xen/arch/x86/mm/p2m.c  | 78 --
 xen/common/grant_table.c   |  7 ++--
 xen/common/memory.c| 32 
 xen/drivers/passthrough/arm/smmu.c |  4 +-
 xen/include/asm-arm/p2m.h  | 12 +++---
 xen/include/asm-x86/p2m.h  | 11 +++---
 xen/include/xen/mm.h   |  2 +-
 14 files changed, 110 insertions(+), 99 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 410bb4f..9035486 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -117,7 +117,7 @@ static bool_t insert_11_bank(struct domain *d,
 goto fail;
 }
 
-res = guest_physmap_add_page(d, spfn, spfn, order);
+res = guest_physmap_add_page(d, _gfn(spfn), _mfn(spfn), order);
 if ( res )
 panic("Failed map pages to DOM0: %d", res);
 
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 2ec211b..5ab9b75 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, gpfn, mfn, 0, t);
+rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
@@ -1282,8 +1282,8 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 if ( flags & GNTMAP_readonly )
 t = p2m_grant_map_ro;
 
-rc = guest_physmap_add_entry(current->domain, addr >> PAGE_SHIFT,
- frame, 0, t);
+rc = guest_physmap_add_entry(current->domain, _gfn(addr >> PAGE_SHIFT),
+ _mfn(frame), 0, t);
 
 if ( rc )
 return GNTST_general_error;
@@ -1294,13 +1294,13 @@ int create_grant_host_mapping(unsigned long addr, 
unsigned long frame,
 int replace_grant_host_mapping(unsigned long addr, unsigned long mfn,
 unsigned long new_addr, unsigned int flags)
 {
-unsigned long gfn = (unsigned long)(addr >> PAGE_SHIFT);
+gfn_t gfn = _gfn(addr >> PAGE_SHIFT);
 struct domain *d = current->domain;
 
 if ( new_addr != 0 || (flags & GNTMAP_contains_pte) )
 return GNTST_general_error;
 
-guest_physmap_remove_page(d, gfn, mfn, 0);
+guest_physmap_remove_page(d, gfn, _mfn(mfn), 0);
 
 return GNTST_okay;
 }
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index ab0cb41..aa4e774 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1292,26 +1292,26 @@ int map_dev_mmio_region(struct domain *d,
 }
 
 int guest_physmap_add_entry(struct domain *d,
-unsigned long gpfn,
-unsigned long mfn,
+gfn_t gfn,
+mfn_t mfn,
 unsigned long page_order,
 p2m_type_t t)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(gpfn),
- pfn_to_paddr(gpfn + (1 << page_order)),
- pfn_to_paddr(mfn), MATTR_MEM, 0, t,
+ pfn_to_paddr(gfn_x(gfn)),
+ pfn_to_paddr(gfn_x(gfn) + (1 << page_order)),
+ pfn_to_paddr(mfn_x(mfn)), MATTR_MEM, 0, t,
  d->arch.p2m.default_access);
 }
 
 void guest_physmap_remove_page(struct domain *d,
-   unsigned long gpfn,
-   unsigned long mfn, unsigned int page_order)
+   gfn_t gfn,
+   mfn_t mfn, unsigned int page_order)
 {
 apply_p2m_changes(d, REMOVE,
-

[Xen-devel] [PATCH v3 0/8] xen/arm: Use the typesafes gfn and mfn

2016-06-21 Thread Julien Grall

Hello all,

Some of the ARM functions are mixing gfn vs mfn and even physical vs frame.

To avoid more confusion, this patch series makes use of the terminology
described in xen/include/xen/mm.h and the associated typesafe.

I pushed a branch with this series applied on xenbits:
git://xenbits.xen.org/people/julieng/xen-unstable.git branch typesafe-v3

Yours sincerely,

Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Paul Durrant 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Julien Grall (8):
  xen/arm: Rename gmfn_to_mfn to gfn_to_mfn and use gfn/mfn typesafe
  xen/mm: Introduce a bunch of helpers for the typesafes mfn and gfn
  xen: Use typesafe gfn/mfn in guest_physmap_* helpers
  xen: Use typesafe gfn in xenmem_add_to_physmap_one
  xen/arm: Rename grant_table_gfpn into grant_table_gfn and use the
typesafe gfn
  xen: Use the typesafe mfn and gfn in map_mmio_regions...
  xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and
mfn
  xen/arm: p2m_cache_flush: Use the correct terminology and typesafe gfn

 xen/arch/arm/domain.c  |  4 +-
 xen/arch/arm/domain_build.c|  6 +--
 xen/arch/arm/domctl.c  |  2 +-
 xen/arch/arm/gic-v2.c  |  4 +-
 xen/arch/arm/mm.c  | 18 +++
 xen/arch/arm/p2m.c | 91 +++-
 xen/arch/arm/platforms/exynos5.c   |  8 ++--
 xen/arch/arm/platforms/omap5.c | 16 +++
 xen/arch/arm/traps.c   | 21 +
 xen/arch/arm/vgic-v2.c |  4 +-
 xen/arch/x86/domain.c  |  5 +-
 xen/arch/x86/domain_build.c|  6 +--
 xen/arch/x86/hvm/ioreq.c   |  8 ++--
 xen/arch/x86/mm.c  | 21 +
 xen/arch/x86/mm/p2m.c  | 96 +-
 xen/common/domctl.c|  4 +-
 xen/common/grant_table.c   | 11 +++--
 xen/common/memory.c| 40 
 xen/drivers/passthrough/arm/smmu.c |  4 +-
 xen/include/asm-arm/domain.h   |  2 +-
 xen/include/asm-arm/grant_table.h  |  2 +-
 xen/include/asm-arm/p2m.h  | 23 +
 xen/include/asm-x86/p2m.h  | 11 ++---
 xen/include/xen/mm.h   | 45 +-
 xen/include/xen/p2m-common.h   |  8 ++--
 25 files changed, 258 insertions(+), 202 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH v3 7/8] xen/arm: Rework the interface of p2m_lookup and use typesafe gfn and mfn

2016-06-21 Thread Julien Grall

The prototype and the declaration of p2m_lookup disagree on how the
function should be used. One expect a frame number whilst the other
an address.

Thankfully, everyone is using with an address today. However, most of
the callers have to convert a guest frame to an address. Modify
the interface to take a guest physical frame in parameter and return
a machine frame.

Whilst modifying the interface, use typesafe gfn and mfn for clarity
and catching possible misusage.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/p2m.c| 37 -
 xen/arch/arm/traps.c  | 21 +++--
 xen/include/asm-arm/p2m.h |  7 +++
 3 files changed, 34 insertions(+), 31 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 47cb383..f3330dd 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -140,14 +140,15 @@ void flush_tlb_domain(struct domain *d)
 }
 
 /*
- * Lookup the MFN corresponding to a domain's PFN.
+ * Lookup the MFN corresponding to a domain's GFN.
  *
  * There are no processor functions to do a stage 2 only lookup therefore we
  * do a a software walk.
  */
-static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+static mfn_t __p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 struct p2m_domain *p2m = >arch.p2m;
+const paddr_t paddr = pfn_to_paddr(gfn_x(gfn));
 const unsigned int offsets[4] = {
 zeroeth_table_offset(paddr),
 first_table_offset(paddr),
@@ -158,7 +159,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 ZEROETH_MASK, FIRST_MASK, SECOND_MASK, THIRD_MASK
 };
 lpae_t pte, *map;
-paddr_t maddr = INVALID_PADDR;
+mfn_t mfn = _mfn(INVALID_MFN);
 paddr_t mask = 0;
 p2m_type_t _t;
 unsigned int level, root_table;
@@ -216,21 +217,22 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t 
paddr, p2m_type_t *t)
 {
 ASSERT(mask);
 ASSERT(pte.p2m.type != p2m_invalid);
-maddr = (pte.bits & PADDR_MASK & mask) | (paddr & ~mask);
+mfn = _mfn(paddr_to_pfn((pte.bits & PADDR_MASK & mask) |
+(paddr & ~mask)));
 *t = pte.p2m.type;
 }
 
 err:
-return maddr;
+return mfn;
 }
 
-paddr_t p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t)
+mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
-paddr_t ret;
+mfn_t ret;
 struct p2m_domain *p2m = >arch.p2m;
 
 spin_lock(>lock);
-ret = __p2m_lookup(d, paddr, t);
+ret = __p2m_lookup(d, gfn, t);
 spin_unlock(>lock);
 
 return ret;
@@ -493,8 +495,9 @@ static int __p2m_get_mem_access(struct domain *d, gfn_t gfn,
  * No setting was found in the Radix tree. Check if the
  * entry exists in the page-tables.
  */
-paddr_t maddr = __p2m_lookup(d, gfn_x(gfn) << PAGE_SHIFT, NULL);
-if ( INVALID_PADDR == maddr )
+mfn_t mfn = __p2m_lookup(d, gfn, NULL);
+
+if ( mfn_x(mfn) == INVALID_MFN )
 return -ESRCH;
 
 /* If entry exists then its rwx. */
@@ -1483,8 +1486,7 @@ int p2m_cache_flush(struct domain *d, xen_pfn_t 
start_mfn, xen_pfn_t end_mfn)
 
 mfn_t gfn_to_mfn(struct domain *d, gfn_t gfn)
 {
-paddr_t p = p2m_lookup(d, pfn_to_paddr(gfn_x(gfn)), NULL);
-return _mfn(p >> PAGE_SHIFT);
+return p2m_lookup(d, gfn, NULL);
 }
 
 /*
@@ -1498,7 +1500,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 {
 long rc;
 paddr_t ipa;
-unsigned long maddr;
+gfn_t gfn;
 unsigned long mfn;
 xenmem_access_t xma;
 p2m_type_t t;
@@ -1508,11 +1510,13 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
 if ( rc < 0 )
 goto err;
 
+gfn = _gfn(paddr_to_pfn(ipa));
+
 /*
  * We do this first as this is faster in the default case when no
  * permission is set on the page.
  */
-rc = __p2m_get_mem_access(current->domain, _gfn(paddr_to_pfn(ipa)), );
+rc = __p2m_get_mem_access(current->domain, gfn, );
 if ( rc < 0 )
 goto err;
 
@@ -1561,11 +1565,10 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag)
  * We had a mem_access permission limiting the access, but the page type
  * could also be limiting, so we need to check that as well.
  */
-maddr = __p2m_lookup(current->domain, ipa, );
-if ( maddr == INVALID_PADDR )
+mfn = mfn_x(__p2m_lookup(current->domain, gfn, ));
+if ( mfn == INVALID_MFN )
 goto err;
 
-mfn = maddr >> PAGE_SHIFT;
 if ( !mfn_valid(mfn) )
 goto err;
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 44926ca..02fe117 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2319,14 +2319,16 @@ void dump_guest_s1_walk(struct domain *d, vaddr_t addr)
 {
 register_t ttbcr = READ_SYSREG(TCR_EL1);
 uint64_t ttbr0 = READ_SYSREG64(TTBR0_EL1);
-paddr_t

[Xen-devel] [PATCH v3 4/8] xen: Use typesafe gfn in xenmem_add_to_physmap_one

2016-06-21 Thread Julien Grall

The x86 version of the function xenmem_add_to_physmap_one contains
variable name gpfn and gfn which make the code very confusing.
I have left unchanged for now.

Also, rename gpfn to gfn in the ARM version as the latter is the correct
acronym for a guest physical frame.

Finally, remove the trailing whitespace around the changes.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v3:
- Add Jan's acked-by for non-ARM bits
---
 xen/arch/arm/mm.c| 10 +-
 xen/arch/x86/mm.c| 15 +++
 xen/common/memory.c  |  6 +++---
 xen/include/xen/mm.h |  2 +-
 4 files changed, 16 insertions(+), 17 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 5ab9b75..6882d54 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -1046,7 +1046,7 @@ int xenmem_add_to_physmap_one(
 unsigned int space,
 union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
-xen_pfn_t gpfn)
+gfn_t gfn)
 {
 unsigned long mfn = 0;
 int rc;
@@ -1081,8 +1081,8 @@ int xenmem_add_to_physmap_one(
 else
 return -EINVAL;
 }
-
-d->arch.grant_table_gpfn[idx] = gpfn;
+
+d->arch.grant_table_gpfn[idx] = gfn_x(gfn);
 
 t = p2m_ram_rw;
 
@@ -1145,7 +1145,7 @@ int xenmem_add_to_physmap_one(
 if ( extra.res0 )
 return -EOPNOTSUPP;
 
-rc = map_dev_mmio_region(d, gpfn, 1, idx);
+rc = map_dev_mmio_region(d, gfn_x(gfn), 1, idx);
 return rc;
 
 default:
@@ -1153,7 +1153,7 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Map at new location. */
-rc = guest_physmap_add_entry(d, _gfn(gpfn), _mfn(mfn), 0, t);
+rc = guest_physmap_add_entry(d, gfn, _mfn(mfn), 0, t);
 
 /* If we fail to add the mapping, we need to drop the reference we
  * took earlier on foreign pages */
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 7fbc94e..dbcf6cb 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4775,7 +4775,7 @@ int xenmem_add_to_physmap_one(
 unsigned int space,
 union xen_add_to_physmap_batch_extra extra,
 unsigned long idx,
-xen_pfn_t gpfn)
+gfn_t gpfn)
 {
 struct page_info *page = NULL;
 unsigned long gfn = 0; /* gcc ... */
@@ -4834,7 +4834,7 @@ int xenmem_add_to_physmap_one(
 break;
 }
 case XENMAPSPACE_gmfn_foreign:
-return p2m_add_foreign(d, idx, gpfn, extra.foreign_domid);
+return p2m_add_foreign(d, idx, gfn_x(gpfn), extra.foreign_domid);
 default:
 break;
 }
@@ -4849,19 +4849,18 @@ int xenmem_add_to_physmap_one(
 }
 
 /* Remove previously mapped page if it was present. */
-prev_mfn = mfn_x(get_gfn(d, gpfn, ));
+prev_mfn = mfn_x(get_gfn(d, gfn_x(gpfn), ));
 if ( mfn_valid(prev_mfn) )
 {
 if ( is_xen_heap_mfn(prev_mfn) )
 /* Xen heap frames are simply unhooked from this phys slot. */
-guest_physmap_remove_page(d, _gfn(gpfn), _mfn(prev_mfn),
-  PAGE_ORDER_4K);
+guest_physmap_remove_page(d, gpfn, _mfn(prev_mfn), PAGE_ORDER_4K);
 else
 /* Normal domain memory is freed, to avoid leaking memory. */
-guest_remove_page(d, gpfn);
+guest_remove_page(d, gfn_x(gpfn));
 }
 /* In the XENMAPSPACE_gmfn case we still hold a ref on the old page. */
-put_gfn(d, gpfn);
+put_gfn(d, gfn_x(gpfn));
 
 /* Unmap from old location, if any. */
 old_gpfn = get_gpfn_from_mfn(mfn);
@@ -4872,7 +4871,7 @@ int xenmem_add_to_physmap_one(
 guest_physmap_remove_page(d, _gfn(old_gpfn), _mfn(mfn), PAGE_ORDER_4K);
 
 /* Map at new location. */
-rc = guest_physmap_add_page(d, _gfn(gpfn), _mfn(mfn), PAGE_ORDER_4K);
+rc = guest_physmap_add_page(d, gpfn, _mfn(mfn), PAGE_ORDER_4K);
 
 /* In the XENMAPSPACE_gmfn, we took a ref of the gfn at the top */
 if ( space == XENMAPSPACE_gmfn || space == XENMAPSPACE_gmfn_range )
diff --git a/xen/common/memory.c b/xen/common/memory.c
index a8a75e0..812334b 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -649,7 +649,7 @@ static int xenmem_add_to_physmap(struct domain *d,
 
 if ( xatp->space != XENMAPSPACE_gmfn_range )
 return xenmem_add_to_physmap_one(d, xatp->space, extra,
- xatp->idx, xatp->gpfn);
+ xatp->idx, _gfn(xatp->gpfn));
 
 if ( xatp->size < start )
 return -EILSEQ;
@@ -666,7 +666,7 @@ static int xenmem_add_to_physmap(struct domain

[Xen-devel] [PATCH v3 6/8] xen: Use the typesafe mfn and gfn in map_mmio_regions...

2016-06-21 Thread Julien Grall

to avoid mixing machine frame with guest frame.

Signed-off-by: Julien Grall 
Acked-by: Jan Beulich 

---
Cc: Stefano Stabellini 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Tim Deegan 
Cc: Wei Liu 

Changes in v3:
- Use mfn_add when it is possible
- Add Jan's acked-by
---
 xen/arch/arm/domain_build.c  |  4 ++--
 xen/arch/arm/gic-v2.c|  4 ++--
 xen/arch/arm/p2m.c   | 22 +++---
 xen/arch/arm/platforms/exynos5.c |  8 
 xen/arch/arm/platforms/omap5.c   | 16 
 xen/arch/arm/vgic-v2.c   |  4 ++--
 xen/arch/x86/mm/p2m.c| 18 ++
 xen/common/domctl.c  |  4 ++--
 xen/include/xen/p2m-common.h |  8 
 9 files changed, 45 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 9035486..49185f0 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1036,9 +1036,9 @@ static int map_range_to_domain(const struct 
dt_device_node *dev,
 if ( need_mapping )
 {
 res = map_mmio_regions(d,
-   paddr_to_pfn(addr),
+   _gfn(paddr_to_pfn(addr)),
DIV_ROUND_UP(len, PAGE_SIZE),
-   paddr_to_pfn(addr));
+   _mfn(paddr_to_pfn(addr)));
 if ( res < 0 )
 {
 printk(XENLOG_ERR "Unable to map 0x%"PRIx64
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 4e2f4c7..3893ece 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -601,9 +601,9 @@ static int gicv2_map_hwdown_extra_mappings(struct domain *d)
d->domain_id, v2m_data->addr, v2m_data->size,
v2m_data->spi_start, v2m_data->nr_spis);
 
-ret = map_mmio_regions(d, paddr_to_pfn(v2m_data->addr),
+ret = map_mmio_regions(d, _gfn(paddr_to_pfn(v2m_data->addr)),
 DIV_ROUND_UP(v2m_data->size, PAGE_SIZE),
-paddr_to_pfn(v2m_data->addr));
+_mfn(paddr_to_pfn(v2m_data->addr)));
 if ( ret )
 {
 printk(XENLOG_ERR "GICv2: Map v2m frame to d%d failed.\n",
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index aa4e774..47cb383 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1245,27 +1245,27 @@ int unmap_regions_rw_cache(struct domain *d,
 }
 
 int map_mmio_regions(struct domain *d,
- unsigned long start_gfn,
+ gfn_t start_gfn,
  unsigned long nr,
- unsigned long mfn)
+ mfn_t mfn)
 {
 return apply_p2m_changes(d, INSERT,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_mmio_direct,
  d->arch.p2m.default_access);
 }
 
 int unmap_mmio_regions(struct domain *d,
-   unsigned long start_gfn,
+   gfn_t start_gfn,
unsigned long nr,
-   unsigned long mfn)
+   mfn_t mfn)
 {
 return apply_p2m_changes(d, REMOVE,
- pfn_to_paddr(start_gfn),
- pfn_to_paddr(start_gfn + nr),
- pfn_to_paddr(mfn),
+ pfn_to_paddr(gfn_x(start_gfn)),
+ pfn_to_paddr(gfn_x(start_gfn) + nr),
+ pfn_to_paddr(mfn_x(mfn)),
  MATTR_DEV, 0, p2m_invalid,
  d->arch.p2m.default_access);
 }
@@ -1280,7 +1280,7 @@ int map_dev_mmio_region(struct domain *d,
 if ( !(nr && iomem_access_permitted(d, start_gfn, start_gfn + nr - 1)) )
 return 0;
 
-res = map_mmio_regions(d, start_gfn, nr, mfn);
+res = map_mmio_regions(d, _gfn(start_gfn), nr, _mfn(mfn));
 if ( res < 0 )
 {
 printk(XENLOG_G_ERR "Unable to map [%#lx - %#lx] in Dom%d\n",
diff --git a/xen/arch/arm/platforms/exynos5.c b/xen/arch/arm/platforms/exynos5.c
index bf4964d..c43934f 100644
--- a/xen/arch/arm/platforms/exynos5.c
+++ b/xen/arch/arm/platforms/exynos5.c
@@ -83,12 +83,12 @@ static int exynos5_init_time(void)
 static int exynos5250_specific_mapping(struct domain *d)
 {
 /* Map the chip ID

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Oleksandr Tyshchenko

On Tue, Jun 21, 2016 at 4:07 PM, Julien Grall  wrote:
>
>
> On 21/06/16 13:54, Oleksandr Tyshchenko wrote:
>>
>> On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall 
>> wrote:

 On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme 
 wrote:
>>>
>>> I have some doubt that the current code is valid. The clock frequency is
>>> hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is
>>> always the same across all the platforms?
>>
>>
>> No.
>>
>> This driver has been initially written for Renesas Lager board based
>> on R-Car H2 SoC which
>> has SCIF compatible UART. And the current code is valid for it. I have
>> tested both auto and
>> variable (38400, 115200) baudrates.
>> But, I am afraid that current code won't be suitable for
>> all of the boards which have the same UART IP. It depends at least
>> from clock source
>> (external/internal) and clock frequency.
>
>
> In this case, the code should either be fixed by reading the clock frequency
> from the firmware tables or be dropped.
>
> I would lean towards the later because the user cannot specify the baud rate
> to Xen.
Agree.

>
> Regards,
>
> --
> Julien Grall



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Julien Grall




On 21/06/16 13:54, Oleksandr Tyshchenko wrote:

On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall  wrote:

On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme 
wrote:

I have some doubt that the current code is valid. The clock frequency is
hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is
always the same across all the platforms?


No.

This driver has been initially written for Renesas Lager board based
on R-Car H2 SoC which
has SCIF compatible UART. And the current code is valid for it. I have
tested both auto and
variable (38400, 115200) baudrates.
But, I am afraid that current code won't be suitable for
all of the boards which have the same UART IP. It depends at least
from clock source
(external/internal) and clock frequency.


In this case, the code should either be fixed by reading the clock 
frequency from the firmware tables or be dropped.


I would lean towards the later because the user cannot specify the baud 
rate to Xen.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Dirk Behme


Hello Oleksandr,

On 21.06.2016 14:54, Oleksandr Tyshchenko wrote:

On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall  wrote:



On 21/06/16 11:16, Oleksandr Tyshchenko wrote:


Hi, Dirk.



Hello Oleksandr,


Hello Julien.




On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme 
wrote:


In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
if this is different later. Detect this by an ASSERT, but remove the
dead code normally never reached.

Signed-off-by: Dirk Behme 
---
  xen/drivers/char/scif-uart.c | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 51a2233..ca88c0f 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -143,23 +143,12 @@ static void __init scif_uart_init_preirq(struct
serial_port *port)
  scif_writew(uart, SCIF_SCSMR, val);

  ASSERT( uart->clock_hz > 0 );
-if ( uart->baud != BAUD_AUTO )
-{
-/* Setup desired Baud rate */
-divisor = uart->clock_hz / (uart->baud << 4);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-scif_writew(uart, SCIF_DL, (uint16_t)divisor);
-/* Selects the frequency divided clock (SC_CLK external input)
*/
-scif_writew(uart, SCIF_CKS, 0);
-udelay(100 / uart->baud + 1);



This part of code might be used for people who are not satisfied with
default baudrate which has been set in U-Boot.



Can you elaborate? If the baud rate is different, it will not be possible to
get output from U-boot.


If we remove this we will take away the opportunity to just change
uart->baud from BAUD_AUTO to desired one.



I have some doubt that the current code is valid. The clock frequency is
hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is
always the same across all the platforms?


No.

This driver has been initially written for Renesas Lager board based
on R-Car H2 SoC which
has SCIF compatible UART. And the current code is valid for it. I have
tested both auto and
variable (38400, 115200) baudrates.



Could you help me a little to understand this?

The driver has

scif_uart_init()
{
...
struct scif_uart *uart;
...
uart->baud  = BAUD_AUTO;
...
}

I checked the code for struct scif_uart but it isn't used anywhere 
outside this driver. So uart->baud is a driver local variable, which 
looks to me isn't used anywhere useful.


What have I missed?

Best regards

Dirk



But, I am afraid that current code won't be suitable for
all of the boards which have the same UART IP. It depends at least
from clock source
(external/internal) and clock frequency.



I would rather avoid to keep dead code (or not accessible without hacking
Xen). For what is worth, we recently removed a similar code from the PL011
driver as this should be correctly configured by the firmware.


-}
-else
-{
-/* Read current Baud rate */
-divisor = scif_readw(uart, SCIF_DL);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-uart->baud = uart->clock_hz / (divisor << 4);
-}
+ASSERT( uart->baud == BAUD_AUTO );
+
+/* Read current Baud rate */
+divisor = scif_readw(uart, SCIF_DL);
+ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
+uart->baud = uart->clock_hz / (divisor << 4);

  /* Setup trigger level for TX/RX FIFOs */
  scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
--
2.8.0



Regards,


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

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Oleksandr Tyshchenko

On Tue, Jun 21, 2016 at 3:15 PM, Julien Grall  wrote:
>
>
> On 21/06/16 11:16, Oleksandr Tyshchenko wrote:
>>
>> Hi, Dirk.
>
>
> Hello Oleksandr,

Hello Julien.
>
>
>> On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme 
>> wrote:
>>>
>>> In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
>>> if this is different later. Detect this by an ASSERT, but remove the
>>> dead code normally never reached.
>>>
>>> Signed-off-by: Dirk Behme 
>>> ---
>>>   xen/drivers/char/scif-uart.c | 23 ++-
>>>   1 file changed, 6 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
>>> index 51a2233..ca88c0f 100644
>>> --- a/xen/drivers/char/scif-uart.c
>>> +++ b/xen/drivers/char/scif-uart.c
>>> @@ -143,23 +143,12 @@ static void __init scif_uart_init_preirq(struct
>>> serial_port *port)
>>>   scif_writew(uart, SCIF_SCSMR, val);
>>>
>>>   ASSERT( uart->clock_hz > 0 );
>>> -if ( uart->baud != BAUD_AUTO )
>>> -{
>>> -/* Setup desired Baud rate */
>>> -divisor = uart->clock_hz / (uart->baud << 4);
>>> -ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
>>> -scif_writew(uart, SCIF_DL, (uint16_t)divisor);
>>> -/* Selects the frequency divided clock (SC_CLK external input)
>>> */
>>> -scif_writew(uart, SCIF_CKS, 0);
>>> -udelay(100 / uart->baud + 1);
>>
>>
>> This part of code might be used for people who are not satisfied with
>> default baudrate which has been set in U-Boot.
>
>
> Can you elaborate? If the baud rate is different, it will not be possible to
> get output from U-boot.
>
>> If we remove this we will take away the opportunity to just change
>> uart->baud from BAUD_AUTO to desired one.
>
>
> I have some doubt that the current code is valid. The clock frequency is
> hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is
> always the same across all the platforms?

No.

This driver has been initially written for Renesas Lager board based
on R-Car H2 SoC which
has SCIF compatible UART. And the current code is valid for it. I have
tested both auto and
variable (38400, 115200) baudrates.
But, I am afraid that current code won't be suitable for
all of the boards which have the same UART IP. It depends at least
from clock source
(external/internal) and clock frequency.

>
> I would rather avoid to keep dead code (or not accessible without hacking
> Xen). For what is worth, we recently removed a similar code from the PL011
> driver as this should be correctly configured by the firmware.
>
>>> -}
>>> -else
>>> -{
>>> -/* Read current Baud rate */
>>> -divisor = scif_readw(uart, SCIF_DL);
>>> -ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
>>> -uart->baud = uart->clock_hz / (divisor << 4);
>>> -}
>>> +ASSERT( uart->baud == BAUD_AUTO );
>>> +
>>> +/* Read current Baud rate */
>>> +divisor = scif_readw(uart, SCIF_DL);
>>> +ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
>>> +uart->baud = uart->clock_hz / (divisor << 4);
>>>
>>>   /* Setup trigger level for TX/RX FIFOs */
>>>   scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
>>> --
>>> 2.8.0
>>>
>
> Regards,
>
> --
> Julien Grall



-- 

Oleksandr Tyshchenko | Embedded Dev
GlobalLogic
www.globallogic.com

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

Re: [Xen-devel] [PATCH 10/11] hvmctl: convert HVMOP_ioreq_server

2016-06-21 Thread Paul Durrant

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 20 June 2016 13:58
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Wei Liu; George Dunlap; Ian Jackson;
> Stefano Stabellini; dgde...@tycho.nsa.gov; Tim (Xen.org)
> Subject: [PATCH 10/11] hvmctl: convert HVMOP_*ioreq_server*
> 
> Note that we can't adjust HVM_IOREQSRV_BUFIOREQ_* to properly obey
> name space rules, as these constants as in use by callers of the libxc
> interface.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1416,23 +1416,14 @@ int xc_hvm_create_ioreq_server(xc_interf
> int handle_bufioreq,
> ioservid_t *id)
>  {
> -DECLARE_HYPERCALL_BUFFER(xen_hvm_create_ioreq_server_t, arg);
> +DECLARE_HVMCTL(create_ioreq_server, domid,
> +   .handle_bufioreq = handle_bufioreq);
>  int rc;
> 
> -arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> -if ( arg == NULL )
> -return -1;
> -
> -arg->domid = domid;
> -arg->handle_bufioreq = handle_bufioreq;
> -
> -rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
> -  HVMOP_create_ioreq_server,
> -  HYPERCALL_BUFFER_AS_ARG(arg));
> +rc = do_hvmctl(xch, );
> 
> -*id = arg->id;
> +*id = hvmctl.u.create_ioreq_server.id;
> 
> -xc_hypercall_buffer_free(xch, arg);
>  return rc;
>  }
> 
> @@ -1443,84 +1434,52 @@ int xc_hvm_get_ioreq_server_info(xc_inte
>   xen_pfn_t *bufioreq_pfn,
>   evtchn_port_t *bufioreq_port)
>  {
> -DECLARE_HYPERCALL_BUFFER(xen_hvm_get_ioreq_server_info_t, arg);
> +DECLARE_HVMCTL(get_ioreq_server_info, domid,
> +   .id = id);
>  int rc;
> 
> -arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> -if ( arg == NULL )
> -return -1;
> -
> -arg->domid = domid;
> -arg->id = id;
> -
> -rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
> -  HVMOP_get_ioreq_server_info,
> -  HYPERCALL_BUFFER_AS_ARG(arg));
> +rc = do_hvmctl(xch, );
>  if ( rc != 0 )
> -goto done;
> +return rc;
> 
>  if ( ioreq_pfn )
> -*ioreq_pfn = arg->ioreq_pfn;
> +*ioreq_pfn = hvmctl.u.get_ioreq_server_info.ioreq_pfn;
> 
>  if ( bufioreq_pfn )
> -*bufioreq_pfn = arg->bufioreq_pfn;
> +*bufioreq_pfn = hvmctl.u.get_ioreq_server_info.bufioreq_pfn;
> 
>  if ( bufioreq_port )
> -*bufioreq_port = arg->bufioreq_port;
> +*bufioreq_port = hvmctl.u.get_ioreq_server_info.bufioreq_port;
> 
> -done:
> -xc_hypercall_buffer_free(xch, arg);
> -return rc;
> +return 0;
>  }
> 
>  int xc_hvm_map_io_range_to_ioreq_server(xc_interface *xch, domid_t
> domid,
>  ioservid_t id, int is_mmio,
>  uint64_t start, uint64_t end)
>  {
> -DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
> -int rc;
> -
> -arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> -if ( arg == NULL )
> -return -1;
> -
> -arg->domid = domid;
> -arg->id = id;
> -arg->type = is_mmio ? HVMOP_IO_RANGE_MEMORY :
> HVMOP_IO_RANGE_PORT;
> -arg->start = start;
> -arg->end = end;
> -
> -rc = xencall2(xch->xcall, __HYPERVISOR_hvm_op,
> -  HVMOP_map_io_range_to_ioreq_server,
> -  HYPERCALL_BUFFER_AS_ARG(arg));
> +DECLARE_HVMCTL(map_io_range_to_ioreq_server, domid,
> +   .id = id,
> +   .type = is_mmio ? XEN_HVMCTL_IO_RANGE_MEMORY
> +   : XEN_HVMCTL_IO_RANGE_PORT,
> +   .start = start,
> +   .end = end);
> 
> -xc_hypercall_buffer_free(xch, arg);
> -return rc;
> +return do_hvmctl(xch, );
>  }
> 
>  int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch,
> domid_t domid,
>  ioservid_t id, int is_mmio,
>  uint64_t start, uint64_t end)
>  {
> -DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
> -int rc;
> -
> -arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> -if ( arg == NULL )
> -return -1;
> +DECLARE_HVMCTL(unmap_io_range_from_ioreq_server, domid,
> +   .id = id,
> +   .type = is_mmio ? XEN_HVMCTL_IO_RANGE_MEMORY
> +   : XEN_HVMCTL_IO_RANGE_PORT,
> +   .start = start,
> +   .end = end);
> 
> -arg->domid = domid;
> -arg->id = id;
> -

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

2016-06-21 Thread Julien Grall


On 21/06/16 13:30, Dirk Behme wrote:

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index bc157fe..678f46b 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -107,8 +107,19 @@ static void __init scif_uart_init_preirq(struct
serial_port *port)
  scif_readw(uart, SCIF_SCLSR);
  scif_writew(uart, SCIF_SCLSR, 0);

-/* Select Baud rate generator output as a clock source */
-scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+/*
+ * Select Baud rate generator output as a clock source
+ * The clock source can be an internal or external clock.
+ * Depending on this the DL register is either 0 or contains
+ * the divisor. I.e. we can use this to detect the clock
+ * source and based on this can configure the CKE[1:0] bits
+ * of the SCSCR register.
+ */
+if ( scif_readw(uart, SCIF_DL) )
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10); /* External clk */
+else
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE00); /* Internal clk */


Why would we need to select the baud rate generator if the baud has been
configured by the firmware?



Just to get the correct understanding: The proposal is to just remove
the code which (wrongly) overwrites the correct settings done by the
firmware?

I.e. instead of doing the same thing the firmware is already doing,
again (the if .. else ), the proposal is simply dropping the


  -/* Select Baud rate generator output as a clock source */
  -scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);

?


Yes. However I don't have any spec in hand so I am not sure if it is 
correct.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

2016-06-21 Thread Dirk Behme


Hi Julien,

On 21.06.2016 14:20, Julien Grall wrote:

Hello Dirk,

On 21/06/16 10:15, Dirk Behme wrote:

Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. Detect this clock based on the SCIF_DL register
being 0 (internal clock) or != 0 (external clock).


Do you have a public link to the specification?



I have to check this ;)



Signed-off-by: Dirk Behme 
---
  xen/drivers/char/scif-uart.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index bc157fe..678f46b 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -107,8 +107,19 @@ static void __init scif_uart_init_preirq(struct
serial_port *port)
  scif_readw(uart, SCIF_SCLSR);
  scif_writew(uart, SCIF_SCLSR, 0);

-/* Select Baud rate generator output as a clock source */
-scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+/*
+ * Select Baud rate generator output as a clock source
+ * The clock source can be an internal or external clock.
+ * Depending on this the DL register is either 0 or contains
+ * the divisor. I.e. we can use this to detect the clock
+ * source and based on this can configure the CKE[1:0] bits
+ * of the SCSCR register.
+ */
+if ( scif_readw(uart, SCIF_DL) )
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10); /* External clk */
+else
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE00); /* Internal clk */


Why would we need to select the baud rate generator if the baud has been
configured by the firmware?



Just to get the correct understanding: The proposal is to just remove 
the code which (wrongly) overwrites the correct settings done by the 
firmware?


I.e. instead of doing the same thing the firmware is already doing, 
again (the if .. else ), the proposal is simply dropping the



 -/* Select Baud rate generator output as a clock source */
 -scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);

?


Best regards

Dirk



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

Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)

2016-06-21 Thread Jan Beulich

>>> On 21.06.16 at 14:05,  wrote:

> 
> On 06/17/2016 08:32 AM, Jan Beulich wrote:
> On 16.06.16 at 22:27,  wrote:
 I.e. my plan was, once the backwards moves are small enough, to maybe
 indeed compensate them by maintaining a global variable tracking
 the most recently returned value. There are issues with such an
 approach too, though: HT effects can result in one hyperthread
 making it just past that check of the global, then hardware
 switching to the other hyperthread, NOW() producing a slightly
 larger value there, and hardware switching back to the first
 hyperthread only after the second one consumed the result of
 NOW(). Dario's use would be unaffected by this aiui, as his NOW()
 invocations are globally serialized through a spinlock, but arbitrary
 NOW() invocations on two hyperthreads can't be made such that
 the invoking party can be guaranteed to see strictly montonic
 values.

 And btw., similar considerations apply for two fully independent
 CPUs, if one runs at a much higher P-state than the other (i.e.
 the faster one could overtake the slower one between the
 montonicity check in NOW() and the callers consuming the returned
 values). So in the end I'm not sure it's worth the performance hit
 such a global montonicity check would incur, and therefore I didn't
 make a respective patch part of this series.

>>>
>>> Hm, guests pvclock should have faced similar issues too as their
>>> local stamps for each vcpu diverge. Linux commit 489fb49 ("x86, paravirt: 
>>> Add a
>>> global synchronization point for pvclock") depicts a fix to similar 
>>> situations to the
>>> scenarios you just described - which lead to have a global variable to keep 
>>> track of
>>> most recent timestamp. One important chunk of that commit is pasted below 
>>> for
>>> convenience:
>>>
>>> --
>>> /*
>>>  * Assumption here is that last_value, a global accumulator, always goes
>>>  * forward. If we are less than that, we should not be much smaller.
>>>  * We assume there is an error marging we're inside, and then the correction
>>>  * does not sacrifice accuracy.
>>>  *
>>>  * For reads: global may have changed between test and return,
>>>  * but this means someone else updated poked the clock at a later time.
>>>  * We just need to make sure we are not seeing a backwards event.
>>>  *
>>>  * For updates: last_value = ret is not enough, since two vcpus could be
>>>  * updating at the same time, and one of them could be slightly behind,
>>>  * making the assumption that last_value always go forward fail to hold.
>>>  */
>>>  last = atomic64_read(_value);
>>>  do {
>>>  if (ret < last)
>>>  return last;
>>>  last = atomic64_cmpxchg(_value, last, ret);
>>>  } while (unlikely(last != ret));
>>> --
>> 
>> Meaning they decided it's worth the overhead. But (having read
>> through the entire description) they don't even discuss whether this
>> indeed eliminates _all_ apparent backward moves due to effects
>> like the ones named above.
>>
>> Plus, the contention they're facing is limited to a single VM, i.e. likely
>> much more narrow than that on an entire physical system. So for
>> us to do the same in the hypervisor, quite a bit more of win would
>> be needed to outweigh the cost.
>> 
> Experimental details look very unclear too - likely running the time
> warp test for 5 days would get some of these cases cleared out. But
> as you say it should be much more narrow that of an entire system.
> 
> BTW It was implicit in the discussion but my apologies for not
> formally/explicitly stating. So FWIW:
> 
> Tested-by: Joao Martins 

Thanks, but this ...

> This series is certainly a way forward into improving cross-CPU monotonicity,
> and I am seeing indeed less occurrences of time going backwards on my 
> systems.

... leaves me guessing whether the above was meant for just this
patch, or the entire series.

Jan

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

Re: [Xen-devel] [PATCH 3/3] xen/arm: drivers: scif: Add clock auto detection

2016-06-21 Thread Julien Grall


Hello Dirk,

On 21/06/16 10:15, Dirk Behme wrote:

Besides the 14MHz external clock, the SCIF might be clocked by an
internal 66MHz clock. Detect this clock based on the SCIF_DL register
being 0 (internal clock) or != 0 (external clock).


Do you have a public link to the specification?


Signed-off-by: Dirk Behme 
---
  xen/drivers/char/scif-uart.c | 15 +--
  1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index bc157fe..678f46b 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -107,8 +107,19 @@ static void __init scif_uart_init_preirq(struct 
serial_port *port)
  scif_readw(uart, SCIF_SCLSR);
  scif_writew(uart, SCIF_SCLSR, 0);

-/* Select Baud rate generator output as a clock source */
-scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10);
+/*
+ * Select Baud rate generator output as a clock source
+ * The clock source can be an internal or external clock.
+ * Depending on this the DL register is either 0 or contains
+ * the divisor. I.e. we can use this to detect the clock
+ * source and based on this can configure the CKE[1:0] bits
+ * of the SCSCR register.
+ */
+if ( scif_readw(uart, SCIF_DL) )
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE10); /* External clk */
+else
+scif_writew(uart, SCIF_SCSCR, SCSCR_CKE00); /* Internal clk */


Why would we need to select the baud rate generator if the baud has been 
configured by the firmware?



+


Please drop this newline.



  /* Setup protocol format and Baud rate, select Asynchronous mode */
  val = 0;



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/3] xen/arm: drivers: scif: Remove unused variables

2016-06-21 Thread Julien Grall


Hello Dirk,

On 21/06/16 10:15, Dirk Behme wrote:

The two struct members baud and clock_hz are in the end read only
variables nowhere used for anything useful. Removing them makes
the code much simpler without changing any functionality.


From my understanding, this patch is removing code you just added on 
the previous patch. I would prefer if you squash this patch into #1.


Regards,



Signed-off-by: Dirk Behme 
---
  xen/drivers/char/scif-uart.c| 13 +
  xen/include/asm-arm/scif-uart.h |  1 -
  2 files changed, 1 insertion(+), 13 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index ca88c0f..bc157fe 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -41,7 +41,7 @@
  #define scif_writew(uart, off, val)writew((val), (uart)->regs + (off))

  static struct scif_uart {
-unsigned int baud, clock_hz, data_bits, parity, stop_bits;
+unsigned int data_bits, parity, stop_bits;
  unsigned int irq;
  char __iomem *regs;
  struct irqaction irqaction;
@@ -87,7 +87,6 @@ static void scif_uart_interrupt(int irq, void *data, struct 
cpu_user_regs *regs)
  static void __init scif_uart_init_preirq(struct serial_port *port)
  {
  struct scif_uart *uart = port->uart;
-unsigned int divisor;
  uint16_t val;

  /*
@@ -142,14 +141,6 @@ static void __init scif_uart_init_preirq(struct 
serial_port *port)
  }
  scif_writew(uart, SCIF_SCSMR, val);

-ASSERT( uart->clock_hz > 0 );
-ASSERT( uart->baud == BAUD_AUTO );
-
-/* Read current Baud rate */
-divisor = scif_readw(uart, SCIF_DL);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-uart->baud = uart->clock_hz / (divisor << 4);
-
  /* Setup trigger level for TX/RX FIFOs */
  scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);

@@ -292,8 +283,6 @@ static int __init scif_uart_init(struct dt_device_node *dev,

  uart = _com;

-uart->clock_hz  = SCIF_CLK_FREQ;
-uart->baud  = BAUD_AUTO;
  uart->data_bits = 8;
  uart->parity= PARITY_NONE;
  uart->stop_bits = 1;
diff --git a/xen/include/asm-arm/scif-uart.h b/xen/include/asm-arm/scif-uart.h
index 7a9f639..d030b26 100644
--- a/xen/include/asm-arm/scif-uart.h
+++ b/xen/include/asm-arm/scif-uart.h
@@ -22,7 +22,6 @@
  #define __ASM_ARM_SCIF_UART_H

  #define SCIF_FIFO_MAX_SIZE16
-#define SCIF_CLK_FREQ 14745600

  /* Register offsets */
  #define SCIF_SCSMR (0x00)/* Serial mode register   */



--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/3] xen/arm: drivers: scif: Remove dead code

2016-06-21 Thread Julien Grall




On 21/06/16 11:16, Oleksandr Tyshchenko wrote:

Hi, Dirk.


Hello Oleksandr,


On Tue, Jun 21, 2016 at 12:15 PM, Dirk Behme  wrote:

In scif_uart_init() uart->baud is set to BAUD_AUTO. So its a basic error
if this is different later. Detect this by an ASSERT, but remove the
dead code normally never reached.

Signed-off-by: Dirk Behme 
---
  xen/drivers/char/scif-uart.c | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/xen/drivers/char/scif-uart.c b/xen/drivers/char/scif-uart.c
index 51a2233..ca88c0f 100644
--- a/xen/drivers/char/scif-uart.c
+++ b/xen/drivers/char/scif-uart.c
@@ -143,23 +143,12 @@ static void __init scif_uart_init_preirq(struct 
serial_port *port)
  scif_writew(uart, SCIF_SCSMR, val);

  ASSERT( uart->clock_hz > 0 );
-if ( uart->baud != BAUD_AUTO )
-{
-/* Setup desired Baud rate */
-divisor = uart->clock_hz / (uart->baud << 4);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-scif_writew(uart, SCIF_DL, (uint16_t)divisor);
-/* Selects the frequency divided clock (SC_CLK external input) */
-scif_writew(uart, SCIF_CKS, 0);
-udelay(100 / uart->baud + 1);


This part of code might be used for people who are not satisfied with
default baudrate which has been set in U-Boot.


Can you elaborate? If the baud rate is different, it will not be 
possible to get output from U-boot.



If we remove this we will take away the opportunity to just change
uart->baud from BAUD_AUTO to desired one.


I have some doubt that the current code is valid. The clock frequency is 
hardcoded (see SCIF_CLK_FREQ), so are you saying that the frequency is 
always the same across all the platforms?


I would rather avoid to keep dead code (or not accessible without 
hacking Xen). For what is worth, we recently removed a similar code from 
the PL011 driver as this should be correctly configured by the firmware.



-}
-else
-{
-/* Read current Baud rate */
-divisor = scif_readw(uart, SCIF_DL);
-ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
-uart->baud = uart->clock_hz / (divisor << 4);
-}
+ASSERT( uart->baud == BAUD_AUTO );
+
+/* Read current Baud rate */
+divisor = scif_readw(uart, SCIF_DL);
+ASSERT( divisor >= 1 && divisor <= (uint16_t)UINT_MAX );
+uart->baud = uart->clock_hz / (divisor << 4);

  /* Setup trigger level for TX/RX FIFOs */
  scif_writew(uart, SCIF_SCFCR, SCFCR_RTRG11 | SCFCR_TTRG11);
--
2.8.0



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 1/8] x86/time: improve cross-CPU clock monotonicity (and more)

2016-06-21 Thread Joao Martins



On 06/17/2016 08:32 AM, Jan Beulich wrote:
 On 16.06.16 at 22:27,  wrote:
>>> I.e. my plan was, once the backwards moves are small enough, to maybe
>>> indeed compensate them by maintaining a global variable tracking
>>> the most recently returned value. There are issues with such an
>>> approach too, though: HT effects can result in one hyperthread
>>> making it just past that check of the global, then hardware
>>> switching to the other hyperthread, NOW() producing a slightly
>>> larger value there, and hardware switching back to the first
>>> hyperthread only after the second one consumed the result of
>>> NOW(). Dario's use would be unaffected by this aiui, as his NOW()
>>> invocations are globally serialized through a spinlock, but arbitrary
>>> NOW() invocations on two hyperthreads can't be made such that
>>> the invoking party can be guaranteed to see strictly montonic
>>> values.
>>>
>>> And btw., similar considerations apply for two fully independent
>>> CPUs, if one runs at a much higher P-state than the other (i.e.
>>> the faster one could overtake the slower one between the
>>> montonicity check in NOW() and the callers consuming the returned
>>> values). So in the end I'm not sure it's worth the performance hit
>>> such a global montonicity check would incur, and therefore I didn't
>>> make a respective patch part of this series.
>>>
>>
>> Hm, guests pvclock should have faced similar issues too as their
>> local stamps for each vcpu diverge. Linux commit 489fb49 ("x86, paravirt: 
>> Add a
>> global synchronization point for pvclock") depicts a fix to similar 
>> situations to the
>> scenarios you just described - which lead to have a global variable to keep 
>> track of
>> most recent timestamp. One important chunk of that commit is pasted below 
>> for
>> convenience:
>>
>> --
>> /*
>>  * Assumption here is that last_value, a global accumulator, always goes
>>  * forward. If we are less than that, we should not be much smaller.
>>  * We assume there is an error marging we're inside, and then the correction
>>  * does not sacrifice accuracy.
>>  *
>>  * For reads: global may have changed between test and return,
>>  * but this means someone else updated poked the clock at a later time.
>>  * We just need to make sure we are not seeing a backwards event.
>>  *
>>  * For updates: last_value = ret is not enough, since two vcpus could be
>>  * updating at the same time, and one of them could be slightly behind,
>>  * making the assumption that last_value always go forward fail to hold.
>>  */
>>  last = atomic64_read(_value);
>>  do {
>>  if (ret < last)
>>  return last;
>>  last = atomic64_cmpxchg(_value, last, ret);
>>  } while (unlikely(last != ret));
>> --
> 
> Meaning they decided it's worth the overhead. But (having read
> through the entire description) they don't even discuss whether this
> indeed eliminates _all_ apparent backward moves due to effects
> like the ones named above.
>
> Plus, the contention they're facing is limited to a single VM, i.e. likely
> much more narrow than that on an entire physical system. So for
> us to do the same in the hypervisor, quite a bit more of win would
> be needed to outweigh the cost.
> 
Experimental details look very unclear too - likely running the time
warp test for 5 days would get some of these cases cleared out. But
as you say it should be much more narrow that of an entire system.

BTW It was implicit in the discussion but my apologies for not
formally/explicitly stating. So FWIW:

Tested-by: Joao Martins 

This series is certainly a way forward into improving cross-CPU monotonicity,
and I am seeing indeed less occurrences of time going backwards on my systems.

Joao

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

1 2 >

1 - 100 of 150 matches

Mail list logo