Re: [Xen-devel] [PATCH for-next 5/9] coverage: introduce generic file

[Jan Beulich]

>>> On 30.10.17 at 17:57,  wrote:
> On Mon, Oct 30, 2017 at 04:48:21PM +, Wei Liu wrote:
>> On Thu, Oct 26, 2017 at 10:19:34AM +0100, Roger Pau Monne wrote:
>> > --- /dev/null
>> > +++ b/xen/common/coverage/coverage.c
>> > @@ -0,0 +1,71 @@
>> > +/*
>> > + * Generic functionality for coverage analysis.
>> > + *
>> > + * Copyright (C) 2017 Citrix Systems R&D
>> > + *
>> > + * This program is free software; you can redistribute it and/or
>> > + * modify it under the terms and conditions of the GNU General Public
>> > + * License, version 2, as published by the Free Software Foundation.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> > + * General Public License for more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public
>> > + * License along with this program; If not, see 
>> > .
>> > + */
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include 
>> 
>> Please sort this.
> 
> OK, I will have to include type.h in coverage.h then.

But that's not something depending on the ordering request: No
matter that we have many examples to the contrary, headers
(at least non-private ones) shouldn't really rely on other things
to have been included up front.

Jan


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

Re: [Xen-devel] [PATCH for-next 5/9] coverage: introduce generic file

[Jan Beulich]

>>> On 26.10.17 at 11:19,  wrote:
> --- a/xen/common/coverage/Makefile
> +++ b/xen/common/coverage/Makefile
> @@ -1,4 +1,4 @@
> -obj-y += gcov_base.o gcov.o
> +obj-y += gcov_base.o gcov.o coverage.o

These would better be sorted, too.

> --- a/xen/include/xen/coverage.h
> +++ b/xen/include/xen/coverage.h
> @@ -9,6 +9,7 @@ struct cov_sysctl_ops {
>  void (*reset_counters)(void);
>  int  (*dump)(XEN_GUEST_HANDLE_PARAM(char), uint32_t *);
>  };
> +extern struct cov_sysctl_ops cov_ops;

I don't think this is the right place to put this declaration (and
perhaps also the struct one) - it's not part of the outside
visible interface of the coverage code, but an internal aspect.
Such should live in a private header, unless they need to be
exposed to e.g. arch specific code (which doesn't appear to
be the case here).

Jan


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

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Jan Beulich]

>>> On 26.10.17 at 12:24,  wrote:
> On 26/10/17 10:19, Roger Pau Monne wrote:
>> diff --git a/xen/common/coverage/Makefile b/xen/common/coverage/Makefile
>> index 0e0510679e..e4541a1233 100644
>> --- a/xen/common/coverage/Makefile
>> +++ b/xen/common/coverage/Makefile
>> @@ -1,3 +1,4 @@
>> +ifeq ($(CONFIG_GCOV),y)
>>  obj-y += gcov_base.o gcov.o coverage.o
>>  obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
>>  obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
>> @@ -9,3 +10,6 @@ obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call 
> cc-ifversion,lt,0x040700, \
>>  gcc_4_7.o, $(call 
>> cc-ifversion,lt,0x05, \
>>  gcc_4_9.o, $(call 
>> cc-ifversion,lt,0x07, \
>>  gcc_5.o, gcc_7.o
>> +else
>> +obj-y += coverage.o
>> +endif
> 
> How about
> 
> obj-y += coverage.o
> 
> ifeq ($(CONFIG_GCOV),y)
> ...
> endif

Except please obj-$(CONFIG_GCOV) instead of ifeq.

Jan


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

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Jan Beulich]

>>> On 26.10.17 at 12:10,  wrote:
> On Thu, Oct 26, 2017 at 11:08:21AM +0100, Roger Pau Monné wrote:
>> On Thu, Oct 26, 2017 at 11:03:13AM +0100, Wei Liu wrote:
>> > On Thu, Oct 26, 2017 at 10:19:35AM +0100, Roger Pau Monne wrote:
>> > >  config GCOV
>> > >  bool "Gcov Support"
>> > >  depends on !LIVEPATCH
>> > 
>> > && !LLVM_COVERAGE
>> 
>> That was my idea, but sadly that's not possible because you generate a
>> circular dependency. The best solution that I found is to only mark
>> one as exclusive (ie: have depends !GCOV in the LLVM_COVERAGE option
>> below).
> 
> In that case, why not just use "choice" to let user pick the
> implementation?

Plus then this choice should probably have an auto-detect option
just like gcov's gcc version one - at least I assume that it should
be pretty straightforward to tell at build time which variant to use.
In fact - what would happen if one enabled the wrong option for
the compiler in use? IOW I wonder whether auto-detection (and
then also for the gcc version) should be the only valid mode).

Jan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114507
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
114507

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub0fbe46ad82982b289a44ee2495b59b0bad8a842
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   24 days
Failing since114546  2017-10-16 12:16:28 Z   22 days   60 attempts
Testing same since   115657  2017-11-08 01:28:35 Z0 days1 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo Marcelo Arenas Belón 
  Chen Hanxiao 
  Christian Borntraeger 
  Collin L. Walling 
  Cornelia Huck 
  Cornelia Huck 
  Cornelia Huck 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Dong Jia Shi 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eduardo Otubo 
  Emilio G. Cota 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Felipe Franciosi 
  Gerd Hoffmann 
  Greg Kurz 
  Halil Pasic 
  Igor Mammedov 
  James Hogan 
  Jason J. Herne 
  Jason Wang 
  Joe Clifford 
  John Arbuckle 
  John Snow 
  Juan Quintela 
  Juergen Gross 
  Kamil Rytarowski 
  Kevin Wolf 
  Knut Omang 
  Lan Tianyu 
  Laszlo

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Jan Beulich]

>>> On 26.10.17 at 11:19,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -28,10 +28,17 @@ config FRAME_POINTER
> maybe slower, but it gives very useful debugging information
> in case of any Xen bugs.
>  
> +# Hidden option enabled when either GCOV or LLVM coverage support is enabled.
> +# This allows to enable the shared coverage bits in Xen without having to
> +# check for each possible coverage implementation.
> +config COVERAGE
> + bool

In case this is still needed after the conversion to "choice", the
comment should be dropped - it is the very purpose of
prompt-less options that is being described there.

> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -119,6 +119,10 @@ ifeq ($(CONFIG_GCOV),y)
>  $(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS 
> += -fprofile-arcs -ftest-coverage
>  endif
>  
> +ifeq ($(CONFIG_LLVM_COVERAGE),y)
> +$(filter-out %.init.o $(nogcov-y),$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS 
> += -fprofile-instr-generate -fcoverage-mapping
> +endif

The use of nogcov-y here suggests that the earlier patch abstracting
away the "g" should be extended to remove that letter here, too.

> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -396,7 +396,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> u_sysctl)
>  }
>  break;
>  
> -#ifdef CONFIG_GCOV
> +#ifdef CONFIG_COVERAGE
>  case XEN_SYSCTL_cov_op:
>  ret = sysctl_cov_op(&op->u.cov_op);
>  copyback = 1;

Couldn't you better do away with the #ifdef altogether, by
introducing a suitable inline function for the coverage-disabled
case (returning -EOPNOTSUPP)?

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
115526
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 115526

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 115526

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeatfail  like 115496
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115526
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115526
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115526
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115526
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115526
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115526
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115526
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115526
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115526
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115526
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  92f0d4392e73727819c5a83fcce447515efaf2f5
baseline version:
 xen  ff93dc55431517ed29c70dbff6721c6b0803acf9

Last test of basis   115526  2017-11-03 13:51:00 Z4 days
Failing since11  2017-11-04 09:34:51 Z3 days7 attempts
Testing same since   115654  2017-11-07 22:51:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Julien Grall 
  Wei Liu 

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

Re: [Xen-devel] [PATCH for-next 7/9] coverage: introduce support for llvm profiling

[Jan Beulich]

>>> On 26.10.17 at 11:19,  wrote:
> --- /dev/null
> +++ b/xen/common/coverage/llvm.c
> @@ -0,0 +1,148 @@
> +/*
> + * Copyright (C) 2017 Citrix Systems R&D
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#ifndef __clang__
> +#error "LLVM coverage selected without clang compiler"
> +#endif
> +
> +#define LLVM_PROFILE_MAGIC_64 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
> +   (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
> +(uint64_t)'f' << 16 | (uint64_t)'r' << 8 | (uint64_t)129
> +#define LLVM_PROFILE_MAGIC_32 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
> +   (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
> +(uint64_t)'f' << 16 | (uint64_t)'R' << 8 | (uint64_t)129

Judging by the file having Xen style, I imply this isn't intended to
very closely match some other original. With that, parentheses
should be added around all the shift operations above.

> +#if __clang_major__ >= 4 || (__clang_major__ == 3 && __clang_minor__ == 9)

Is it certain that there's never going to be a 3.10? Otherwise
>= might be more suitable for the minor version check.

> +int __llvm_profile_runtime;

This isn't used anywhere - please add a brief comment explaining
the need for it (the more that its type being plain int is also
suspicious).

> +extern struct llvm_profile_data __start___llvm_prf_data;
> +extern struct llvm_profile_data __stop___llvm_prf_data;
> +extern uint64_t __start___llvm_prf_cnts;
> +extern uint64_t __stop___llvm_prf_cnts;
> +extern char __start___llvm_prf_names;
> +extern char __stop___llvm_prf_names;

I guess all of these really want to have [] added, making ...

> +static void *start_data = &__start___llvm_prf_data;
> +static void *end_data = &__stop___llvm_prf_data;
> +static void *start_counters = &__start___llvm_prf_cnts;
> +static void *end_counters = &__stop___llvm_prf_cnts;
> +static void *start_names = &__start___llvm_prf_names;
> +static void *end_names = &__stop___llvm_prf_names;

... the &s here unnecessary. But then - do these really need to
be statics (rather than #define-s)?

I would also guess that at least the names ones could be const.

> +static int dump(XEN_GUEST_HANDLE_PARAM(char) buffer, uint32_t *buf_size)
> +{
> +struct llvm_profile_header header = {
> +#if BITS_PER_LONG == 64
> +.magic = LLVM_PROFILE_MAGIC_64,
> +#else
> +.magic = LLVM_PROFILE_MAGIC_32,
> +#endif

I think this should just be LLVM_PROFILE_MAGIC, with the #ifdef
moved to the #define-s.

> +.version = LLVM_PROFILE_VERSION,
> +.data_size = (end_data - start_data) / sizeof(struct 
> llvm_profile_data),
> +.counters_size = (end_counters - start_counters) / sizeof(uint64_t),
> +.names_size = end_names - start_names,
> +.counters_delta = (uintptr_t)start_counters,
> +.names_delta = (uintptr_t)start_names,
> +.value_kind_last = LLVM_PROFILE_NUM_KINDS - 1,
> +};
> +unsigned int off = 0;
> +
> +#define APPEND_TO_BUFFER(src, size) \
> +({  \
> +if ( off + size > *buf_size )   \

(size)

> +return -ENOMEM; \
> +copy_to_guest_offset(buffer, off, src, size);   \
> +off += size;\

Ideally here too, albeit only the comma operator has lower
precedence, and that would require parenthesizing in the macro
invocation already (which is also why the arguments to
copy_to_guest_offset() explicitly do not need extra parentheses
added).

> 

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Roger Pau Monné]

On Wed, Nov 08, 2017 at 01:13:29AM -0700, Jan Beulich wrote:
> >>> On 26.10.17 at 12:10,  wrote:
> > On Thu, Oct 26, 2017 at 11:08:21AM +0100, Roger Pau Monné wrote:
> >> On Thu, Oct 26, 2017 at 11:03:13AM +0100, Wei Liu wrote:
> >> > On Thu, Oct 26, 2017 at 10:19:35AM +0100, Roger Pau Monne wrote:
> >> > >  config GCOV
> >> > >bool "Gcov Support"
> >> > >depends on !LIVEPATCH
> >> > 
> >> > && !LLVM_COVERAGE
> >> 
> >> That was my idea, but sadly that's not possible because you generate a
> >> circular dependency. The best solution that I found is to only mark
> >> one as exclusive (ie: have depends !GCOV in the LLVM_COVERAGE option
> >> below).
> > 
> > In that case, why not just use "choice" to let user pick the
> > implementation?
> 
> Plus then this choice should probably have an auto-detect option
> just like gcov's gcc version one - at least I assume that it should
> be pretty straightforward to tell at build time which variant to use.
> In fact - what would happen if one enabled the wrong option for
> the compiler in use? IOW I wonder whether auto-detection (and
> then also for the gcc version) should be the only valid mode).

I don't plan to introduce llvm/clang version choices here, I think
autodetection should be fine.

I can remove the gcc ones also, leaving this as a boolean choice (ie:
enable code coverage support), but I would like to have some
confirmation from the gcc side.

Thanks, Roger.

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

[Xen-devel] [distros-debian-squeeze test] 72431: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
72403
 test-amd64-i386-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like 
72403
 test-amd64-i386-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
72403
 test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like 
72403

baseline version:
 flight   72403

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH for-next 7/9] coverage: introduce support for llvm profiling

[Roger Pau Monné]

On Wed, Nov 08, 2017 at 01:38:59AM -0700, Jan Beulich wrote:
> >>> On 26.10.17 at 11:19,  wrote:
> > --- /dev/null
> > +++ b/xen/common/coverage/llvm.c
> > +#define LLVM_PROFILE_MAGIC_64 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
> > +   (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
> > +(uint64_t)'f' << 16 | (uint64_t)'r' << 8 | (uint64_t)129
> > +#define LLVM_PROFILE_MAGIC_32 (uint64_t)255 << 56 | (uint64_t)'l' << 48 | \
> > +   (uint64_t)'p' << 40 | (uint64_t)'r' << 32 | (uint64_t)'o' << 24 |  \
> > +(uint64_t)'f' << 16 | (uint64_t)'R' << 8 | (uint64_t)129
> 
> Judging by the file having Xen style, I imply this isn't intended to
> very closely match some other original. With that, parentheses
> should be added around all the shift operations above.
> 
> > +#if __clang_major__ >= 4 || (__clang_major__ == 3 && __clang_minor__ == 9)
> 
> Is it certain that there's never going to be a 3.10? Otherwise
> >= might be more suitable for the minor version check.

No, there's not going to be a clang 3.10.

> > +int __llvm_profile_runtime;
> 
> This isn't used anywhere - please add a brief comment explaining
> the need for it (the more that its type being plain int is also
> suspicious).

This is an internal symbol that must be present because Xen is not
linked against the run-time coverage library. It's described as an int
here:

https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#using-the-profiling-runtime-without-static-initializers

Without this symbol linkage fails.

> > +extern struct llvm_profile_data __start___llvm_prf_data;
> > +extern struct llvm_profile_data __stop___llvm_prf_data;
> > +extern uint64_t __start___llvm_prf_cnts;
> > +extern uint64_t __stop___llvm_prf_cnts;
> > +extern char __start___llvm_prf_names;
> > +extern char __stop___llvm_prf_names;
> 
> I guess all of these really want to have [] added, making ...
> 
> > +static void *start_data = &__start___llvm_prf_data;
> > +static void *end_data = &__stop___llvm_prf_data;
> > +static void *start_counters = &__start___llvm_prf_cnts;
> > +static void *end_counters = &__stop___llvm_prf_cnts;
> > +static void *start_names = &__start___llvm_prf_names;
> > +static void *end_names = &__stop___llvm_prf_names;
> 
> ... the &s here unnecessary. But then - do these really need to
> be statics (rather than #define-s)?
> 
> I would also guess that at least the names ones could be const.

Could make them defines indeed.

> > +APPEND_TO_BUFFER((char *)start_data, end_data - start_data);
> > +APPEND_TO_BUFFER((char *)start_counters, end_counters - 
> > start_counters);
> > +APPEND_TO_BUFFER((char *)start_names, end_names - start_names);
> 
> The casts should all be to const char*, and perhaps that would
> better be done inside the macro anyway.

Seems better indeed.

> > --- a/xen/include/public/sysctl.h
> > +++ b/xen/include/public/sysctl.h
> > @@ -646,6 +646,12 @@ struct xen_sysctl_scheduler_op {
> >  
> >  #define XEN_GCOV_FORMAT_MAGIC0x58434f56 /* XCOV */
> 
> Hmm, shouldn't the private magic #define-s actually be put here
> (in which case you'd indeed need to retain both 32- and 64-bit
> variants)?

I don't think so, here XEN_GCOV_FORMAT_MAGIC is a Xen specific gcov
magic number.

OTOH LLVM_PROFILE_MAGIC_{64/32} is an llvm defined magic number,
that's not under our control. Hence I don't think it should be
exported in Xen public headers.

Roger.

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

[Xen-devel] [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

[Juergen Gross]

Booting a Xen PVH guest requires a special boot entry as it is
mandatory to setup some Xen-specific interfaces rather early. When grub
or OVMF are used as boot loaders, however, those will fill the boot
parameters in zeropage and there is no longer a need to do something
PVH specific in the early boot path.

This patch series adds support for that scenario by identifying PVH
environment and doing the required init steps via Xen hooks instead of
using a dedicated boot entry.

The dedicated entry is still needed for support of Dom0 running in PVH
mode as in this case there is no grub or OVMF involved for filling in
the boot parameters.

Juergen Gross (3):
  x86/acpi: add test for ACPI_FADT_NO_VGA
  x86: add guest_late_init hook to hypervisor_x86 structure
  x86/xen: use guest_late_init to detect Xen PVH guest

 arch/x86/include/asm/hypervisor.h | 11 +++
 arch/x86/include/asm/kvm_para.h   |  2 --
 arch/x86/include/asm/x86_init.h   |  1 +
 arch/x86/kernel/acpi/boot.c   |  5 +
 arch/x86/kernel/kvm.c |  3 ++-
 arch/x86/kernel/setup.c   |  2 +-
 arch/x86/xen/enlighten_hvm.c  | 24 ++--
 arch/x86/xen/enlighten_pvh.c  |  9 -
 8 files changed, 42 insertions(+), 15 deletions(-)

-- 
2.12.3


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

[Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Juergen Gross]

Add a new guest_late_init hook to the hypervisor_x86 structure. It
will replace the current kvm_guest_init() call which is changed to
make use of the new hook.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/hypervisor.h | 11 +++
 arch/x86/include/asm/kvm_para.h   |  2 --
 arch/x86/kernel/kvm.c |  3 ++-
 arch/x86/kernel/setup.c   |  2 +-
 4 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 0ead9dbb9130..37320687b8cb 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -38,6 +38,9 @@ struct hypervisor_x86 {
/* Platform setup (run once per boot) */
void(*init_platform)(void);
 
+   /* Guest late init */
+   void(*guest_late_init)(void);
+
/* X2APIC detection (run once per boot) */
bool(*x2apic_available)(void);
 
@@ -66,9 +69,17 @@ static inline void hypervisor_init_mem_mapping(void)
if (x86_hyper && x86_hyper->init_mem_mapping)
x86_hyper->init_mem_mapping();
 }
+
+static inline void hypervisor_guest_late_init(void)
+{
+   if (x86_hyper && x86_hyper->guest_late_init)
+   x86_hyper->guest_late_init();
+}
+
 #else
 static inline void init_hypervisor_platform(void) { }
 static inline bool hypervisor_x2apic_available(void) { return false; }
 static inline void hypervisor_init_mem_mapping(void) { }
+static inline void hypervisor_guest_late_init(void) { }
 #endif /* CONFIG_HYPERVISOR_GUEST */
 #endif /* _ASM_X86_HYPERVISOR_H */
diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
index c373e44049b1..7b407dda2bd7 100644
--- a/arch/x86/include/asm/kvm_para.h
+++ b/arch/x86/include/asm/kvm_para.h
@@ -88,7 +88,6 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned 
long p1,
 #ifdef CONFIG_KVM_GUEST
 bool kvm_para_available(void);
 unsigned int kvm_arch_para_features(void);
-void __init kvm_guest_init(void);
 void kvm_async_pf_task_wait(u32 token, int interrupt_kernel);
 void kvm_async_pf_task_wake(u32 token);
 u32 kvm_read_and_reset_pf_reason(void);
@@ -103,7 +102,6 @@ static inline void kvm_spinlock_init(void)
 #endif /* CONFIG_PARAVIRT_SPINLOCKS */
 
 #else /* CONFIG_KVM_GUEST */
-#define kvm_guest_init() do {} while (0)
 #define kvm_async_pf_task_wait(T, I) do {} while(0)
 #define kvm_async_pf_task_wake(T) do {} while(0)
 
diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 8bb9594d0761..d331b5060aa9 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -465,7 +465,7 @@ static void __init kvm_apf_trap_init(void)
update_intr_gate(X86_TRAP_PF, async_page_fault);
 }
 
-void __init kvm_guest_init(void)
+static void __init kvm_guest_init(void)
 {
int i;
 
@@ -548,6 +548,7 @@ const struct hypervisor_x86 x86_hyper_kvm __refconst = {
.name   = "KVM",
.detect = kvm_detect,
.x2apic_available   = kvm_para_available,
+   .guest_late_init= kvm_guest_init,
 };
 EXPORT_SYMBOL_GPL(x86_hyper_kvm);
 
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0957dd73d127..578569481d87 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1294,7 +1294,7 @@ void __init setup_arch(char **cmdline_p)
 
io_apic_init_mappings();
 
-   kvm_guest_init();
+   hypervisor_guest_late_init();
 
e820__reserve_resources();
e820__register_nosave_regions(max_low_pfn);
-- 
2.12.3


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

[Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

In case we are booted via the default boot entry by a generic loader
like grub or OVMF it is necessary to distinguish between a HVM guest
with a device model supporting legacy devices and a PVH guest without
device model.

PVH guests will always have x86_platform.legacy.no_vga set and
x86_platform.legacy.rtc cleared, while both won't be true for HVM
guests.

Test for both conditions in the guest_late_init hook and set xen_pvh
to true if they are met.

Move some of the early PVH initializations to the new hook in order
to avoid duplicated code.

Signed-off-by: Juergen Gross 
---
 arch/x86/xen/enlighten_hvm.c | 24 ++--
 arch/x86/xen/enlighten_pvh.c |  9 -
 2 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index de503c225ae1..d7d68a39073a 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -1,3 +1,4 @@
+#include 
 #include 
 #include 
 #include 
@@ -188,8 +189,6 @@ static void __init xen_hvm_guest_init(void)
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
 
-   if (xen_pvh_domain())
-   machine_ops.emergency_restart = xen_emergency_restart;
 #ifdef CONFIG_KEXEC_CORE
machine_ops.shutdown = xen_hvm_shutdown;
machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
@@ -226,6 +225,26 @@ static uint32_t __init xen_platform_hvm(void)
return xen_cpuid_base();
 }
 
+static __init void xen_hvm_guest_late_init(void)
+{
+#ifdef CONFIG_XEN_PVH
+   /* Test for PVH domain (PVH boot path taken overrides ACPI flags). */
+   if (!xen_pvh &&
+   (x86_platform.legacy.rtc || !x86_platform.legacy.no_vga))
+   return;
+
+   /* PVH detected. */
+   xen_pvh = true;
+
+   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
+   if (!nr_ioapics && acpi_irq_model == ACPI_IRQ_MODEL_PIC)
+   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
+
+   machine_ops.emergency_restart = xen_emergency_restart;
+   pv_info.name = "Xen PVH";
+#endif
+}
+
 const struct hypervisor_x86 x86_hyper_xen_hvm = {
.name   = "Xen HVM",
.detect = xen_platform_hvm,
@@ -233,5 +252,6 @@ const struct hypervisor_x86 x86_hyper_xen_hvm = {
.pin_vcpu   = xen_pin_vcpu,
.x2apic_available   = xen_x2apic_para_available,
.init_mem_mapping   = xen_hvm_init_mem_mapping,
+   .guest_late_init= xen_hvm_guest_late_init,
 };
 EXPORT_SYMBOL(x86_hyper_xen_hvm);
diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 7bd3ee08393e..436c4f003e17 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -25,13 +25,6 @@ struct boot_params pvh_bootparams 
__attribute__((section(".data")));
 struct hvm_start_info pvh_start_info;
 unsigned int pvh_start_info_sz = sizeof(pvh_start_info);
 
-static void xen_pvh_arch_setup(void)
-{
-   /* Make sure we don't fall back to (default) ACPI_IRQ_MODEL_PIC. */
-   if (nr_ioapics == 0)
-   acpi_irq_model = ACPI_IRQ_MODEL_PLATFORM;
-}
-
 static void __init init_pvh_bootparams(void)
 {
struct xen_memory_map memmap;
@@ -102,6 +95,4 @@ void __init xen_prepare_pvh(void)
wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
 
init_pvh_bootparams();
-
-   x86_init.oem.arch_setup = xen_pvh_arch_setup;
 }
-- 
2.12.3


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

[Xen-devel] [PATCH 1/3] x86/acpi: add test for ACPI_FADT_NO_VGA

[Juergen Gross]

Add a test for ACPI_FADT_NO_VGA when scanning the FADT and set the new
flag x86_platform.legacy.no_vga accordingly.

Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/x86_init.h | 1 +
 arch/x86/kernel/acpi/boot.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/x86_init.h b/arch/x86/include/asm/x86_init.h
index 8a1ebf9540dd..75a60fa52a8a 100644
--- a/arch/x86/include/asm/x86_init.h
+++ b/arch/x86/include/asm/x86_init.h
@@ -195,6 +195,7 @@ enum x86_legacy_i8042_state {
 struct x86_legacy_features {
enum x86_legacy_i8042_state i8042;
int rtc;
+   int no_vga;
int reserve_bios_regions;
struct x86_legacy_devices devices;
 };
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 079535e53e2a..ef9e02e614d0 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -961,6 +961,11 @@ static int __init acpi_parse_fadt(struct acpi_table_header 
*table)
x86_platform.legacy.rtc = 0;
}
 
+   if (acpi_gbl_FADT.boot_flags & ACPI_FADT_NO_VGA) {
+   pr_debug("ACPI: probing for VGA not safe\n");
+   x86_platform.legacy.no_vga = 1;
+   }
+
 #ifdef CONFIG_X86_PM_TIMER
/* detect the location of the ACPI PM Timer */
if (acpi_gbl_FADT.header.revision >= FADT2_REVISION_ID) {
-- 
2.12.3


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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Ingo Molnar]

* Juergen Gross  wrote:

> Add a new guest_late_init hook to the hypervisor_x86 structure. It
> will replace the current kvm_guest_init() call which is changed to
> make use of the new hook.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/include/asm/hypervisor.h | 11 +++
>  arch/x86/include/asm/kvm_para.h   |  2 --
>  arch/x86/kernel/kvm.c |  3 ++-
>  arch/x86/kernel/setup.c   |  2 +-
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/hypervisor.h 
> b/arch/x86/include/asm/hypervisor.h
> index 0ead9dbb9130..37320687b8cb 100644
> --- a/arch/x86/include/asm/hypervisor.h
> +++ b/arch/x86/include/asm/hypervisor.h
> @@ -38,6 +38,9 @@ struct hypervisor_x86 {
>   /* Platform setup (run once per boot) */
>   void(*init_platform)(void);
>  
> + /* Guest late init */
> + void(*guest_late_init)(void);
> +
>   /* X2APIC detection (run once per boot) */
>   bool(*x2apic_available)(void);
>  
> @@ -66,9 +69,17 @@ static inline void hypervisor_init_mem_mapping(void)
>   if (x86_hyper && x86_hyper->init_mem_mapping)
>   x86_hyper->init_mem_mapping();
>  }
> +
> +static inline void hypervisor_guest_late_init(void)
> +{
> + if (x86_hyper && x86_hyper->guest_late_init)
> + x86_hyper->guest_late_init();
> +}
> +
>  #else
>  static inline void init_hypervisor_platform(void) { }
>  static inline bool hypervisor_x2apic_available(void) { return false; }
>  static inline void hypervisor_init_mem_mapping(void) { }
> +static inline void hypervisor_guest_late_init(void) { }
>  #endif /* CONFIG_HYPERVISOR_GUEST */
>  #endif /* _ASM_X86_HYPERVISOR_H */
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index c373e44049b1..7b407dda2bd7 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -88,7 +88,6 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned 
> long p1,
>  #ifdef CONFIG_KVM_GUEST
>  bool kvm_para_available(void);
>  unsigned int kvm_arch_para_features(void);
> -void __init kvm_guest_init(void);
>  void kvm_async_pf_task_wait(u32 token, int interrupt_kernel);
>  void kvm_async_pf_task_wake(u32 token);
>  u32 kvm_read_and_reset_pf_reason(void);
> @@ -103,7 +102,6 @@ static inline void kvm_spinlock_init(void)
>  #endif /* CONFIG_PARAVIRT_SPINLOCKS */
>  
>  #else /* CONFIG_KVM_GUEST */
> -#define kvm_guest_init() do {} while (0)
>  #define kvm_async_pf_task_wait(T, I) do {} while(0)
>  #define kvm_async_pf_task_wake(T) do {} while(0)
>  
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 8bb9594d0761..d331b5060aa9 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -465,7 +465,7 @@ static void __init kvm_apf_trap_init(void)
>   update_intr_gate(X86_TRAP_PF, async_page_fault);
>  }
>  
> -void __init kvm_guest_init(void)
> +static void __init kvm_guest_init(void)
>  {
>   int i;
>  
> @@ -548,6 +548,7 @@ const struct hypervisor_x86 x86_hyper_kvm __refconst = {
>   .name   = "KVM",
>   .detect = kvm_detect,
>   .x2apic_available   = kvm_para_available,
> + .guest_late_init= kvm_guest_init,
>  };
>  EXPORT_SYMBOL_GPL(x86_hyper_kvm);
>  
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 0957dd73d127..578569481d87 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1294,7 +1294,7 @@ void __init setup_arch(char **cmdline_p)
>  
>   io_apic_init_mappings();
>  
> - kvm_guest_init();
> + hypervisor_guest_late_init();

No principal objections, but could we please use a more obvious pattern showing 
that this is a callback, by calling it directly:

x86_hyper->guest_late_init();

Plus add a default empty function (which hypervisors can override). This avoids 
all the hidden conditions and wrappery.

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Juergen Gross]

On 08/11/17 10:13, Ingo Molnar wrote:
> 
> * Juergen Gross  wrote:
> 
>> Add a new guest_late_init hook to the hypervisor_x86 structure. It
>> will replace the current kvm_guest_init() call which is changed to
>> make use of the new hook.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  arch/x86/include/asm/hypervisor.h | 11 +++
>>  arch/x86/include/asm/kvm_para.h   |  2 --
>>  arch/x86/kernel/kvm.c |  3 ++-
>>  arch/x86/kernel/setup.c   |  2 +-
>>  4 files changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/hypervisor.h 
>> b/arch/x86/include/asm/hypervisor.h
>> index 0ead9dbb9130..37320687b8cb 100644
>> --- a/arch/x86/include/asm/hypervisor.h
>> +++ b/arch/x86/include/asm/hypervisor.h
>> @@ -38,6 +38,9 @@ struct hypervisor_x86 {
>>  /* Platform setup (run once per boot) */
>>  void(*init_platform)(void);
>>  
>> +/* Guest late init */
>> +void(*guest_late_init)(void);
>> +
>>  /* X2APIC detection (run once per boot) */
>>  bool(*x2apic_available)(void);
>>  
>> @@ -66,9 +69,17 @@ static inline void hypervisor_init_mem_mapping(void)
>>  if (x86_hyper && x86_hyper->init_mem_mapping)
>>  x86_hyper->init_mem_mapping();
>>  }
>> +
>> +static inline void hypervisor_guest_late_init(void)
>> +{
>> +if (x86_hyper && x86_hyper->guest_late_init)
>> +x86_hyper->guest_late_init();
>> +}
>> +
>>  #else
>>  static inline void init_hypervisor_platform(void) { }
>>  static inline bool hypervisor_x2apic_available(void) { return false; }
>>  static inline void hypervisor_init_mem_mapping(void) { }
>> +static inline void hypervisor_guest_late_init(void) { }
>>  #endif /* CONFIG_HYPERVISOR_GUEST */
>>  #endif /* _ASM_X86_HYPERVISOR_H */
>> diff --git a/arch/x86/include/asm/kvm_para.h 
>> b/arch/x86/include/asm/kvm_para.h
>> index c373e44049b1..7b407dda2bd7 100644
>> --- a/arch/x86/include/asm/kvm_para.h
>> +++ b/arch/x86/include/asm/kvm_para.h
>> @@ -88,7 +88,6 @@ static inline long kvm_hypercall4(unsigned int nr, 
>> unsigned long p1,
>>  #ifdef CONFIG_KVM_GUEST
>>  bool kvm_para_available(void);
>>  unsigned int kvm_arch_para_features(void);
>> -void __init kvm_guest_init(void);
>>  void kvm_async_pf_task_wait(u32 token, int interrupt_kernel);
>>  void kvm_async_pf_task_wake(u32 token);
>>  u32 kvm_read_and_reset_pf_reason(void);
>> @@ -103,7 +102,6 @@ static inline void kvm_spinlock_init(void)
>>  #endif /* CONFIG_PARAVIRT_SPINLOCKS */
>>  
>>  #else /* CONFIG_KVM_GUEST */
>> -#define kvm_guest_init() do {} while (0)
>>  #define kvm_async_pf_task_wait(T, I) do {} while(0)
>>  #define kvm_async_pf_task_wake(T) do {} while(0)
>>  
>> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
>> index 8bb9594d0761..d331b5060aa9 100644
>> --- a/arch/x86/kernel/kvm.c
>> +++ b/arch/x86/kernel/kvm.c
>> @@ -465,7 +465,7 @@ static void __init kvm_apf_trap_init(void)
>>  update_intr_gate(X86_TRAP_PF, async_page_fault);
>>  }
>>  
>> -void __init kvm_guest_init(void)
>> +static void __init kvm_guest_init(void)
>>  {
>>  int i;
>>  
>> @@ -548,6 +548,7 @@ const struct hypervisor_x86 x86_hyper_kvm __refconst = {
>>  .name   = "KVM",
>>  .detect = kvm_detect,
>>  .x2apic_available   = kvm_para_available,
>> +.guest_late_init= kvm_guest_init,
>>  };
>>  EXPORT_SYMBOL_GPL(x86_hyper_kvm);
>>  
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index 0957dd73d127..578569481d87 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -1294,7 +1294,7 @@ void __init setup_arch(char **cmdline_p)
>>  
>>  io_apic_init_mappings();
>>  
>> -kvm_guest_init();
>> +hypervisor_guest_late_init();
> 
> No principal objections, but could we please use a more obvious pattern 
> showing 
> that this is a callback, by calling it directly:
>   
>   x86_hyper->guest_late_init();
> 
> Plus add a default empty function (which hypervisors can override). This 
> avoids 
> all the hidden conditions and wrappery.

Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
have to add a pre-filled struct with dummy functions and in case a
hypervisor is detected we'd need to copy all non-NULL pointers of the
hypervisor specific struct to the pre-filled one.

In case there are no objections I can add a patch to modify the current
way x86_hyper is used to the pre-filled variant.


Juergen


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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Ingo Molnar]

* Juergen Gross  wrote:

> > Plus add a default empty function (which hypervisors can override). This 
> > avoids 
> > all the hidden conditions and wrappery.
> 
> Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
> have to add a pre-filled struct with dummy functions and in case a
> hypervisor is detected we'd need to copy all non-NULL pointers of the
> hypervisor specific struct to the pre-filled one.

Ok, I missed that detail - but yeah, since this is mostly about boot code,
where readability is king, I still think it would be an overall improvement.

This is the pattern we are trying to use with x86_platform ops for example, and 
doing:

  git grep -w x86_platform arch/x86

gives a pretty clear idea about how it's used - while if it was all within 
wrappers it would be a lot more difficult to discover all the callsites.

Admittedly it's not done totally consistently:

 arch/x86/kernel/apic/probe_32.c:if (x86_platform.apic_post_init)
 arch/x86/kernel/apic/probe_64.c:if (x86_platform.apic_post_init)
 arch/x86/kernel/ebda.c: if (!x86_platform.legacy.reserve_bios_regions)
 arch/x86/kernel/platform-quirks.c:  if (x86_platform.set_legacy_features)
 arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c:   if 
(!x86_platform.legacy.rtc)

... but the _idea_ behind it is consistent ;-)

> In case there are no objections I can add a patch to modify the current
> way x86_hyper is used to the pre-filled variant.

Yeah, sounds good to me!

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Juergen Gross]

On 08/11/17 10:40, Ingo Molnar wrote:
> 
> * Juergen Gross  wrote:
> 
>>> Plus add a default empty function (which hypervisors can override). This 
>>> avoids 
>>> all the hidden conditions and wrappery.
>>
>> Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
>> have to add a pre-filled struct with dummy functions and in case a
>> hypervisor is detected we'd need to copy all non-NULL pointers of the
>> hypervisor specific struct to the pre-filled one.
> 
> Ok, I missed that detail - but yeah, since this is mostly about boot code,
> where readability is king, I still think it would be an overall improvement.
> 
> This is the pattern we are trying to use with x86_platform ops for example, 
> and 
> doing:
> 
>   git grep -w x86_platform arch/x86
> 
> gives a pretty clear idea about how it's used - while if it was all within 
> wrappers it would be a lot more difficult to discover all the callsites.
> 
> Admittedly it's not done totally consistently:
> 
>  arch/x86/kernel/apic/probe_32.c:if (x86_platform.apic_post_init)
>  arch/x86/kernel/apic/probe_64.c:if (x86_platform.apic_post_init)
>  arch/x86/kernel/ebda.c: if (!x86_platform.legacy.reserve_bios_regions)
>  arch/x86/kernel/platform-quirks.c:  if (x86_platform.set_legacy_features)
>  arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c:   if 
> (!x86_platform.legacy.rtc)
> 
> ... but the _idea_ behind it is consistent ;-)
> 
>> In case there are no objections I can add a patch to modify the current
>> way x86_hyper is used to the pre-filled variant.
> 
> Yeah, sounds good to me!

Okay. With you mentioning x86_platform: should I make x86_hyper a member
of x86_platform (e.g. x86_platform.hyper.) ?

I think this would fit quite nice.


Juergen

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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Paolo Bonzini]

On 08/11/2017 10:07, Juergen Gross wrote:
> Add a new guest_late_init hook to the hypervisor_x86 structure. It
> will replace the current kvm_guest_init() call which is changed to
> make use of the new hook.
> 
> Signed-off-by: Juergen Gross 

The trivial KVM changes are of course

Acked-by: Paolo Bonzini 

Paolo

> ---
>  arch/x86/include/asm/hypervisor.h | 11 +++
>  arch/x86/include/asm/kvm_para.h   |  2 --
>  arch/x86/kernel/kvm.c |  3 ++-
>  arch/x86/kernel/setup.c   |  2 +-
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/include/asm/hypervisor.h 
> b/arch/x86/include/asm/hypervisor.h
> index 0ead9dbb9130..37320687b8cb 100644
> --- a/arch/x86/include/asm/hypervisor.h
> +++ b/arch/x86/include/asm/hypervisor.h
> @@ -38,6 +38,9 @@ struct hypervisor_x86 {
>   /* Platform setup (run once per boot) */
>   void(*init_platform)(void);
>  
> + /* Guest late init */
> + void(*guest_late_init)(void);
> +
>   /* X2APIC detection (run once per boot) */
>   bool(*x2apic_available)(void);
>  
> @@ -66,9 +69,17 @@ static inline void hypervisor_init_mem_mapping(void)
>   if (x86_hyper && x86_hyper->init_mem_mapping)
>   x86_hyper->init_mem_mapping();
>  }
> +
> +static inline void hypervisor_guest_late_init(void)
> +{
> + if (x86_hyper && x86_hyper->guest_late_init)
> + x86_hyper->guest_late_init();
> +}
> +
>  #else
>  static inline void init_hypervisor_platform(void) { }
>  static inline bool hypervisor_x2apic_available(void) { return false; }
>  static inline void hypervisor_init_mem_mapping(void) { }
> +static inline void hypervisor_guest_late_init(void) { }
>  #endif /* CONFIG_HYPERVISOR_GUEST */
>  #endif /* _ASM_X86_HYPERVISOR_H */
> diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h
> index c373e44049b1..7b407dda2bd7 100644
> --- a/arch/x86/include/asm/kvm_para.h
> +++ b/arch/x86/include/asm/kvm_para.h
> @@ -88,7 +88,6 @@ static inline long kvm_hypercall4(unsigned int nr, unsigned 
> long p1,
>  #ifdef CONFIG_KVM_GUEST
>  bool kvm_para_available(void);
>  unsigned int kvm_arch_para_features(void);
> -void __init kvm_guest_init(void);
>  void kvm_async_pf_task_wait(u32 token, int interrupt_kernel);
>  void kvm_async_pf_task_wake(u32 token);
>  u32 kvm_read_and_reset_pf_reason(void);
> @@ -103,7 +102,6 @@ static inline void kvm_spinlock_init(void)
>  #endif /* CONFIG_PARAVIRT_SPINLOCKS */
>  
>  #else /* CONFIG_KVM_GUEST */
> -#define kvm_guest_init() do {} while (0)
>  #define kvm_async_pf_task_wait(T, I) do {} while(0)
>  #define kvm_async_pf_task_wake(T) do {} while(0)
>  
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 8bb9594d0761..d331b5060aa9 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -465,7 +465,7 @@ static void __init kvm_apf_trap_init(void)
>   update_intr_gate(X86_TRAP_PF, async_page_fault);
>  }
>  
> -void __init kvm_guest_init(void)
> +static void __init kvm_guest_init(void)
>  {
>   int i;
>  
> @@ -548,6 +548,7 @@ const struct hypervisor_x86 x86_hyper_kvm __refconst = {
>   .name   = "KVM",
>   .detect = kvm_detect,
>   .x2apic_available   = kvm_para_available,
> + .guest_late_init= kvm_guest_init,
>  };
>  EXPORT_SYMBOL_GPL(x86_hyper_kvm);
>  
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index 0957dd73d127..578569481d87 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -1294,7 +1294,7 @@ void __init setup_arch(char **cmdline_p)
>  
>   io_apic_init_mappings();
>  
> - kvm_guest_init();
> + hypervisor_guest_late_init();
>  
>   e820__reserve_resources();
>   e820__register_nosave_regions(max_low_pfn);
> 


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

Re: [Xen-devel] [PATCH 2/3] x86: add guest_late_init hook to hypervisor_x86 structure

[Ingo Molnar]

* Juergen Gross  wrote:

> On 08/11/17 10:40, Ingo Molnar wrote:
> > 
> > * Juergen Gross  wrote:
> > 
> >>> Plus add a default empty function (which hypervisors can override). This 
> >>> avoids 
> >>> all the hidden conditions and wrappery.
> >>
> >> Hmm, x86_hyper is just a pointer being NULL on bare metal. So we would
> >> have to add a pre-filled struct with dummy functions and in case a
> >> hypervisor is detected we'd need to copy all non-NULL pointers of the
> >> hypervisor specific struct to the pre-filled one.
> > 
> > Ok, I missed that detail - but yeah, since this is mostly about boot code,
> > where readability is king, I still think it would be an overall improvement.
> > 
> > This is the pattern we are trying to use with x86_platform ops for example, 
> > and 
> > doing:
> > 
> >   git grep -w x86_platform arch/x86
> > 
> > gives a pretty clear idea about how it's used - while if it was all within 
> > wrappers it would be a lot more difficult to discover all the callsites.
> > 
> > Admittedly it's not done totally consistently:
> > 
> >  arch/x86/kernel/apic/probe_32.c:if (x86_platform.apic_post_init)
> >  arch/x86/kernel/apic/probe_64.c:if (x86_platform.apic_post_init)
> >  arch/x86/kernel/ebda.c: if (!x86_platform.legacy.reserve_bios_regions)
> >  arch/x86/kernel/platform-quirks.c:  if 
> > (x86_platform.set_legacy_features)
> >  arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c:   if 
> > (!x86_platform.legacy.rtc)
> > 
> > ... but the _idea_ behind it is consistent ;-)
> > 
> >> In case there are no objections I can add a patch to modify the current
> >> way x86_hyper is used to the pre-filled variant.
> > 
> > Yeah, sounds good to me!
> 
> Okay. With you mentioning x86_platform: should I make x86_hyper a member
> of x86_platform (e.g. x86_platform.hyper.) ?
> 
> I think this would fit quite nice.

Yeah, seems like a good idea!

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH v5 0/4] xenfb: Enablement for Windows PV HID frontend

[Gerd Hoffmann]

On Fri, Nov 03, 2017 at 11:56:27AM +, Owen Smith wrote:
> Improve the input device model in xenfb, by updating the
> Qemu input handlers and adding a feature to allow for
> raw (unscaled) absolute coordinates to be represented.

Reviewed-by: Gerd Hoffmann 

Will this be merged via xen queue?

If not I can queue it up in my input queue, but I'd like to have a
review from the xen folks then.

cheers,
  Gerd


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

[Xen-devel] [xen-unstable-coverity test] 115672: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  92f0d4392e73727819c5a83fcce447515efaf2f5
baseline version:
 xen  e07ebab86595df29838f0960693df84f34528833

Last test of basis   115589  2017-11-05 09:23:06 Z3 days
Testing same since   115672  2017-11-08 09:42:28 Z0 days1 attempts


People who touched revisions under test:
  Dario Faggioli 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   e07ebab..92f0d43  92f0d4392e73727819c5a83fcce447515efaf2f5 -> 
coverity-tested/smoke

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

[Xen-devel] [libvirt test] 115660: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
115476
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 115476

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

version targeted for testing:
 libvirt  ef7e6ee281e49d7132b85c0e5bc1cb2e0a5a5f99
baseline version:
 libvirt  1bf893406637e852daeaafec6617d3ee3716de25

Last test of basis   115476  2017-11-02 04:22:37 Z6 days
Failing since115509  2017-11-03 04:20:26 Z5 days6 attempts
Testing same since   115660  2017-11-08 04:20:19 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Christian Ehrhardt 
  Daniel Veillard 
  Dawid Zamirski 
  Jiri Denemark 
  John Ferlan 
  Michal Privoznik 
  Nikolay Shirokovskiy 
  Peter Krempa 

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 pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2fail
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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 1035 lines long.)

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

Re: [Xen-devel] [PATCH v5 0/4] xenfb: Enablement for Windows PV HID frontend

[Owen Smith]

I'd imagine this would be merged via the Xen queue, as it primarily deals with 
the xen backend

Owen

> -Original Message-
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: 08 November 2017 10:21
> To: Owen Smith 
> Cc: sstabell...@kernel.org; Anthony Perard ;
> qemu-de...@nongnu.org; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v5 0/4] xenfb: Enablement for Windows PV HID
> frontend
> 
> On Fri, Nov 03, 2017 at 11:56:27AM +, Owen Smith wrote:
> > Improve the input device model in xenfb, by updating the Qemu input
> > handlers and adding a feature to allow for raw (unscaled) absolute
> > coordinates to be represented.
> 
> Reviewed-by: Gerd Hoffmann 
> 
> Will this be merged via xen queue?
> 
> If not I can queue it up in my input queue, but I'd like to have a review from
> the xen folks then.
> 
> cheers,
>   Gerd


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

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Thomas Gleixner]

On Tue, 7 Nov 2017, Joao Martins wrote:
> On 11/06/2017 04:09 PM, Paolo Bonzini wrote:
> > On 19/10/2017 15:39, Joao Martins wrote:
> >> Right now there is only a pvclock_pvti_cpu0_va() which is defined
> >> on kvmclock since:
> >>
> >> commit dac16fba6fc5
> >> ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")
> >>
> >> The only user of this interface so far is kvm. This commit adds a
> >> setter function for the pvti page and moves pvclock_pvti_cpu0_va
> >> to pvclock, which is a more generic place to have it; and would
> >> allow other PV clocksources to use it, such as Xen.
> >>
> >> Signed-off-by: Joao Martins 
> >> Acked-by: Andy Lutomirski 
> > 
> > Acked-by: Paolo Bonzini 
> > 
> > IOW, the Xen folks are free to pick up the whole series. :)
> > 
> Thank you!
> 
> I guess only x86 maintainers Ack is left - any comments?

The only nit-pick I have are the convoluted function names:

pvclock_set_pvti_cpu0_va() pvclock_pvti_cpu0_va()

What on earth does that mean?

Aside of that can you please make it at least symetric, i.e. _set_ and
_get_ ?

Other than that:

  Acked-by: Thomas Gleixner 

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

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Jan Beulich]

>>> On 08.11.17 at 09:49,  wrote:
> On Wed, Nov 08, 2017 at 01:13:29AM -0700, Jan Beulich wrote:
>> >>> On 26.10.17 at 12:10,  wrote:
>> > On Thu, Oct 26, 2017 at 11:08:21AM +0100, Roger Pau Monné wrote:
>> >> On Thu, Oct 26, 2017 at 11:03:13AM +0100, Wei Liu wrote:
>> >> > On Thu, Oct 26, 2017 at 10:19:35AM +0100, Roger Pau Monne wrote:
>> >> > >  config GCOV
>> >> > >   bool "Gcov Support"
>> >> > >   depends on !LIVEPATCH
>> >> > 
>> >> > && !LLVM_COVERAGE
>> >> 
>> >> That was my idea, but sadly that's not possible because you generate a
>> >> circular dependency. The best solution that I found is to only mark
>> >> one as exclusive (ie: have depends !GCOV in the LLVM_COVERAGE option
>> >> below).
>> > 
>> > In that case, why not just use "choice" to let user pick the
>> > implementation?
>> 
>> Plus then this choice should probably have an auto-detect option
>> just like gcov's gcc version one - at least I assume that it should
>> be pretty straightforward to tell at build time which variant to use.
>> In fact - what would happen if one enabled the wrong option for
>> the compiler in use? IOW I wonder whether auto-detection (and
>> then also for the gcc version) should be the only valid mode).
> 
> I don't plan to introduce llvm/clang version choices here, I think
> autodetection should be fine.

And I didn't think about version choices for clang here anyway -
the point really was just about gcc vs clang.

> I can remove the gcc ones also, leaving this as a boolean choice (ie:
> enable code coverage support), but I would like to have some
> confirmation from the gcc side.

So let's ask Wei: What was the reason for the Kconfig level
version choice here in the first place? After all, if the wrong one
is being selected, the build will fail afaict due to the #error
directives in the version specific files.

Jan

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

Re: [Xen-devel] [PATCH for-next 7/9] coverage: introduce support for llvm profiling

[Jan Beulich]

>>> On 08.11.17 at 09:56,  wrote:
> On Wed, Nov 08, 2017 at 01:38:59AM -0700, Jan Beulich wrote:
>> >>> On 26.10.17 at 11:19,  wrote:
>> > --- a/xen/include/public/sysctl.h
>> > +++ b/xen/include/public/sysctl.h
>> > @@ -646,6 +646,12 @@ struct xen_sysctl_scheduler_op {
>> >  
>> >  #define XEN_GCOV_FORMAT_MAGIC0x58434f56 /* XCOV */
>> 
>> Hmm, shouldn't the private magic #define-s actually be put here
>> (in which case you'd indeed need to retain both 32- and 64-bit
>> variants)?
> 
> I don't think so, here XEN_GCOV_FORMAT_MAGIC is a Xen specific gcov
> magic number.
> 
> OTOH LLVM_PROFILE_MAGIC_{64/32} is an llvm defined magic number,
> that's not under our control. Hence I don't think it should be
> exported in Xen public headers.

Okay.

Jan


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

Re: [Xen-devel] [Qemu-devel] [PATCH 7/8] os-posix: Provide new -runasid option

[Ian Jackson]

Markus Armbruster writes ("Re: [Qemu-devel] [PATCH 7/8] os-posix: Provide new 
-runasid option"):
> Ian Jackson  writes:
> > qemu_strtoul fails (returns an error) if the delimiter (that is, the
> > first character which is not processed as digit by strtoul) is not
> > '\0'.
> 
> It does that *only* when its @endptr argument is null.  Since you pass
> &ep, it should work fine here.

I have just read it again and you are right.  Sorry.  I will fix this
then.

> > Does that all make sense ?
> 
> Your code makes sense to me.  It's just the comment that confuses me.
> Does ID mean "implementation-defined behavior"?  That would be wrong:

Yes, that's what I meant by ID.

>6.3.1.3  Signed and unsigned integers
> 
>[#1] When a value with integer type is converted to  another
>integer   type  other  than  _Bool,  if  the  value  can  be
>represented by the new type, it is unchanged.
> 
>[#2] Otherwise, if the new type is unsigned,  the  value  is
>converted  by repeatedly adding or subtracting one more than
>the maximum value that can be represented in  the  new  type
>until the value is in the range of the new type.

That applies if the new type (uid_t, here) is unsigned.  But I think
uid_t's signedness is not specified, so it might be signed.  (SuS
says, in the section on types.h, only

  Additionally:
 * nlink_t, uid_t, gid_t, and id_t shall be integer types.

C99 6.3.1.3 continues:

 Otherwise, the new type is signed and the value cannot be
 represented in it; either the result is
 implementation-defined or an implementation-defined signal is
 raised.

So the type of uid_t is ID too.

> One more thing: please report errors with error_report().  Here:

> error_report("Could not obtain uid");
> 
> No need to quote optarg back at the user, because error_report() already
> does.

Ah, I will do that.  Thanks.

Regards,
Ian.

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Jan Beulich]

>>> On 08.11.17 at 10:07,  wrote:
> In case we are booted via the default boot entry by a generic loader
> like grub or OVMF it is necessary to distinguish between a HVM guest
> with a device model supporting legacy devices and a PVH guest without
> device model.
> 
> PVH guests will always have x86_platform.legacy.no_vga set and
> x86_platform.legacy.rtc cleared, while both won't be true for HVM
> guests.
> 
> Test for both conditions in the guest_late_init hook and set xen_pvh
> to true if they are met.

This sounds pretty fragile to me: I can't see a reason why a proper
HVM guest couldn't come without VGA and RTC. That's not possible
today, agreed, but certainly an option down the road if virtualization
follows bare metal's road towards being legacy free.

Jan


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

Re: [Xen-devel] [PATCH for-next 6/9] kconfig: add llvm coverage option

[Wei Liu]

On Wed, Nov 08, 2017 at 04:07:35AM -0700, Jan Beulich wrote:
> >>> On 08.11.17 at 09:49,  wrote:
> > On Wed, Nov 08, 2017 at 01:13:29AM -0700, Jan Beulich wrote:
> >> >>> On 26.10.17 at 12:10,  wrote:
> >> > On Thu, Oct 26, 2017 at 11:08:21AM +0100, Roger Pau Monné wrote:
> >> >> On Thu, Oct 26, 2017 at 11:03:13AM +0100, Wei Liu wrote:
> >> >> > On Thu, Oct 26, 2017 at 10:19:35AM +0100, Roger Pau Monne wrote:
> >> >> > >  config GCOV
> >> >> > > bool "Gcov Support"
> >> >> > > depends on !LIVEPATCH
> >> >> > 
> >> >> > && !LLVM_COVERAGE
> >> >> 
> >> >> That was my idea, but sadly that's not possible because you generate a
> >> >> circular dependency. The best solution that I found is to only mark
> >> >> one as exclusive (ie: have depends !GCOV in the LLVM_COVERAGE option
> >> >> below).
> >> > 
> >> > In that case, why not just use "choice" to let user pick the
> >> > implementation?
> >> 
> >> Plus then this choice should probably have an auto-detect option
> >> just like gcov's gcc version one - at least I assume that it should
> >> be pretty straightforward to tell at build time which variant to use.
> >> In fact - what would happen if one enabled the wrong option for
> >> the compiler in use? IOW I wonder whether auto-detection (and
> >> then also for the gcc version) should be the only valid mode).
> > 
> > I don't plan to introduce llvm/clang version choices here, I think
> > autodetection should be fine.
> 
> And I didn't think about version choices for clang here anyway -
> the point really was just about gcc vs clang.
> 
> > I can remove the gcc ones also, leaving this as a boolean choice (ie:
> > enable code coverage support), but I would like to have some
> > confirmation from the gcc side.
> 
> So let's ask Wei: What was the reason for the Kconfig level
> version choice here in the first place? After all, if the wrong one
> is being selected, the build will fail afaict due to the #error
> directives in the version specific files.
> 

The #error on versions was added in later iterations IIRC. Looking back
I think it would make sense to just have autodetect.

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-i386-pvgrub

[Wei Liu]

On Tue, Nov 07, 2017 at 05:24:32PM +, Julien Grall wrote:
> Hi Wei,
> 
> On 07/11/17 15:13, Wei Liu wrote:
> > On Tue, Nov 07, 2017 at 03:09:07PM +, Julien Grall wrote:
> >> Hi Wei,
> >>
> >> On 06/11/17 14:55, Wei Liu wrote:
> >>> On Mon, Nov 06, 2017 at 01:47:56PM +, osstest service owner wrote:
>  branch xen-unstable
>  xenbranch xen-unstable
>  job test-amd64-amd64-i386-pvgrub
>  testid guest-start
> 
>  Tree: linux git://xenbits.xen.org/linux-pvops.git
>  Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  xen git://xenbits.xen.org/xen.git
>  Bug introduced:  f48b5449dabc770acdde6d25cfbd265cfb71034d
>  Bug not present: 86cf189a957129ea1ad6468fe9a0887b9e2819f3
>  Last fail repro: 
>  http://logs.test-lab.xenproject.org/osstest/logs/115612/
> 
> 
>  commit f48b5449dabc770acdde6d25cfbd265cfb71034d
>  Author: Wei Liu 
>  Date:   Thu Oct 12 20:19:07 2017 +0100
>  tools/dombuilder: Switch to using gfn terminology for console 
>  and xenstore rings
>  The sole use of xc_dom_translated() and xc_dom_p2m() outside of 
>  the domain
>  builder is for libxl_dom() to translate the console and xenstore 
>  pfns back
>  into useful values.  PV guest pfns are only interesting to the 
>  domain builder,
>  and gfns are the address space used by all other hypercalls.
>  Renaming the fields in xc_dom_image is deliberate, as it will 
>  cause
>  out-of-tree users of the dombuilder to notice the different 
>  semantics.
>  Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), 
>  which are all
>  using gfns despite the existing variable names.
>  Signed-off-by: Andrew Cooper 
>  Reviewed-by: Roger Pau Monn?? 
>  Acked-by: Wei Liu 
>  Tested-by: Julien Grall 
>  Release-acked-by: Julien Grall 
>  [ wei: fix stubdom build ]
>  Signed-off-by: Wei Liu 
> >>>
> >>> This has broken pvgrub. The problem is more than just the name of the
> >>> variables. I have reverted this and its successor patch.
> >>
> >> It looks like osstest is still broken after the patches you reverted (see
> >> [1] and [2]).
> >>
> >> AFAICT, the only series between the two flights is the dombuilder, there 
> >> are
> >> 2 patches not reverted.
> >>
> >> Do you have an idea of what's going on?
> >>
> >> Cheers,
> >>
> >> [1] http://logs.test-lab.xenproject.org/osstest/logs/115624/
> >> [2]
> >> https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg00391.html
> >>
> > 
> > test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. 
> > vs.  115526
> > test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs.  
> > 115526
> 
> The log for the xl-vhd contains ([1])
> 
> libxl: error: libxl_bootloader.c:283:bootloader_local_detached_cb: Domain 
> 11:unable to detach locally attached disk
> libxl: error: libxl_create.c:1246:domcreate_rebuild_done: Domain 11:cannot 
> (re-)build domain: -3
> libxl: debug: libxl_domain.c:1138:devices_destroy_cb: Domain 11:Forked pid 
> 5103 for destroy of domain
> libxl: debug: libxl_create.c:1683:do_domain_create: Domain 0:ao 0x5d6e8: 
> inprogress: poller=0x56ad8, flags=i
> libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x5d6e8: complete, 
> rc=-3
> libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x5d6e8: destroy
> libxl: debug: libxl_domain.c:868:libxl_domain_destroy: Domain 11:ao 0x5a170: 
> create: how=(nil) callback=(nil) poller=0x56ad8
> libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 
> 11:Non-existant domain
> libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 11:Unable to 
> destroy guest
> libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 11:Destruction of 
> domain failed
> libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x5a170: complete, 
> rc=-21
> libxl: debug: libxl_domain.c:877:libxl_domain_destroy: Domain 11:ao 0x5a170: 
> inprogress: poller=0x56ad8, flags=ic
> libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x5a170: destroy
> 
> It is in guest repeat and has succeed few times before.
> 
> Looking at the success/failure ([2]), the same configuration passed on the 
> Arndale
> (see 115580) but fails reliably on the cubietruck.
> 

The same test failed on Arndale as well in 115314 and 115526, with the
same error messages.

http://logs.test-lab.xenproject.org/osstest/logs/115526/test-armhf-armhf-xl-vhd/16.ts-guest-start.log

So the failure isn't related to Andrew's series.

> My guess would be the disk is no

Re: [Xen-devel] Bringing up OSS test framework on moonshot(aarch64) systems

[Ian Jackson]

Bhupinder Thakur writes ("Bringing up OSS test framework on moonshot(aarch64) 
systems"):
> While going through [1], I have some queries/doubts on the configuration.
> 
> 1. The following configuration:
> 
> DnsDomain uk.xensource.com
> NetNameservers 10.80.248.2 10.80.16.28 10.80.16.67
> HostProp_DhcpWatchMethod leases dhcp3 dhcp.uk.xensource.com:5556
> TftpPath /usr/groups/netboot/
> 
> DebianNonfreeFirmware firmware-bnx2
> DebianSuite squeeze
> DebianMirrorHost debian.uk.xensource.com
> DebianPreseed= < <‘END’
> d-i clock-setup/ntp-server string ntp.uk.xensource.com
> END
> 
> 1. In this configuration, where would the DNS server be running? Does
> it expect that a DNS server is already configured in the network and
> it has mapping of name <--> IP address for all test hosts? Or do we
> need to setup it up on the OSS controller?

The information about the nameservers, the tftp server, and the ntp
server, is supposed to refer to infrastructure that already exists.
I think your test hosts should be in the DNS, yes.  It may be possible
to get it to work without doing that but I wouldn't recommend it.

osstest does not need a dedicated network.  Specifically, it can
share its broadcast domain, and its dhcp and tftp servers (and web
proxies, Debian mirrors, ntp servers, and so on), with other uses.

When running osstest in production ("Executive") mode the individual
test boxes must be configured to be available to osstest only if they
are not being used for something else, of course.

See INSTALL.production.

> 2. What is the DhcpWatchMethod option used for?

See under DHCP in INSTALL.production, and please let me know if that's
not clear.

> 3. How are the debian related options mentioned above used? Does OSS
> fetches the installers/preseed files from DEbianMirrorHost and place
> them in the required tftp folders?

mg-debian-installer-update downloads d-i installation information and
puts it in the tftp area.

But the tftp area is also updated at runtime, obviously, in order to
control the booting of each host.  And the mirror host is accessed
separately, too.

> I may have more doubts as I try to set things up.

I'm happy to answer more questions, of course :-).

> [1] 
> https://blog.xenproject.org/2013/09/30/osstest-standalone-mode-step-by-step/

That blog post may be rather out of date, I'm afraid.  But the in-tree
documentation is somewhat better since then.

> I am trying to bring up OSS test framework on a couple of moonshot
> systems which are accessible to me remotely.

I'm not familiar with the referent of "moonshot" in this context.  IME
"moonshot" is a project name chosen multiple times, for different
projects, by people who want to give an impression that the project is
ambitious.

Regards,
Ian.

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

Re: [Xen-devel] [linux-4.9 test] 115504: regressions - FAIL

[Ian Jackson]

Roger Pau Monné writes ("Re: [Xen-devel] [linux-4.9 test] 115504: regressions - 
FAIL"):
> On Fri, Nov 03, 2017 at 08:21:31PM +, osstest service owner wrote:
> > flight 115504 linux-4.9 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/115504/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 
> > 114814
> 
> AFAICT this tree should also be force-pushed, the windows 16 issue is
> the same as the one seen on xen-unstable.

Yes, I did that on Monday.  This flight was already in progress by
then.

Ian.

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

Re: [Xen-devel] Bringing up OSS test framework on moonshot(aarch64) systems

[Julien Grall]

Hi Ian,

On 08/11/17 11:39, Ian Jackson wrote:

Bhupinder Thakur writes ("Bringing up OSS test framework on moonshot(aarch64) 
systems"):

I am trying to bring up OSS test framework on a couple of moonshot
systems which are accessible to me remotely.


I'm not familiar with the referent of "moonshot" in this context.  IME
"moonshot" is a project name chosen multiple times, for different
projects, by people who want to give an impression that the project is
ambitious.


In that context, this is an moonshot brand from HP. It is a 4.3U that 
accepts up to 45 cartridges (see [1]).


They have x86 cartridges but also provides Arm64 one based on X-Gene 1 
(APM).


Bhupinder is looking at bring up Osstest on the Arm64 cartridges.

Cheers,

[1] 
https://www.anandtech.com/show/8357/exploring-the-low-end-and-micro-server-platforms/2


--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 12:18, Jan Beulich wrote:
 On 08.11.17 at 10:07,  wrote:
>> In case we are booted via the default boot entry by a generic loader
>> like grub or OVMF it is necessary to distinguish between a HVM guest
>> with a device model supporting legacy devices and a PVH guest without
>> device model.
>>
>> PVH guests will always have x86_platform.legacy.no_vga set and
>> x86_platform.legacy.rtc cleared, while both won't be true for HVM
>> guests.
>>
>> Test for both conditions in the guest_late_init hook and set xen_pvh
>> to true if they are met.
> 
> This sounds pretty fragile to me: I can't see a reason why a proper
> HVM guest couldn't come without VGA and RTC. That's not possible
> today, agreed, but certainly an option down the road if virtualization
> follows bare metal's road towards being legacy free.

From guest's perspective: what is the difference between a legacy free
HVM domain and PVH? In the end the need for differentiating is to avoid
access to legacy features in PVH as those would require a device model.


Juergen


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Paolo Bonzini]

On 08/11/2017 12:55, Juergen Gross wrote:
> On 08/11/17 12:18, Jan Beulich wrote:
> On 08.11.17 at 10:07,  wrote:
>>> In case we are booted via the default boot entry by a generic loader
>>> like grub or OVMF it is necessary to distinguish between a HVM guest
>>> with a device model supporting legacy devices and a PVH guest without
>>> device model.
>>>
>>> PVH guests will always have x86_platform.legacy.no_vga set and
>>> x86_platform.legacy.rtc cleared, while both won't be true for HVM
>>> guests.
>>>
>>> Test for both conditions in the guest_late_init hook and set xen_pvh
>>> to true if they are met.
>>
>> This sounds pretty fragile to me: I can't see a reason why a proper
>> HVM guest couldn't come without VGA and RTC. That's not possible
>> today, agreed, but certainly an option down the road if virtualization
>> follows bare metal's road towards being legacy free.
> 
> From guest's perspective: what is the difference between a legacy free
> HVM domain and PVH? In the end the need for differentiating is to avoid
> access to legacy features in PVH as those would require a device model.

My understanding of Xen is very rusty at this point, but I think a
"completely" legacy-free HVM domain will still have a PCI bus and the
Xen platform device on that bus.

A PVH domain just knows how to access the Xen PV features.

Paolo

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

Re: [Xen-devel] [linux-linus test] 115643: regressions - FAIL

[Ian Jackson]

osstest service owner writes ("[linux-linus test] 115643: regressions - FAIL"):
> flight 115643 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115643/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 
> 114682
...
> version targeted for testing:
>  linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf

Forced.

Ian.

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

Re: [Xen-devel] [xen-unstable bisection] complete test-amd64-amd64-i386-pvgrub

[Julien Grall]

Hi Wei,

On 08/11/17 11:36, Wei Liu wrote:

On Tue, Nov 07, 2017 at 05:24:32PM +, Julien Grall wrote:

Hi Wei,

On 07/11/17 15:13, Wei Liu wrote:

On Tue, Nov 07, 2017 at 03:09:07PM +, Julien Grall wrote:

Hi Wei,

On 06/11/17 14:55, Wei Liu wrote:

On Mon, Nov 06, 2017 at 01:47:56PM +, osstest service owner wrote:

branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-i386-pvgrub
testid guest-start

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.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:  xen git://xenbits.xen.org/xen.git
 Bug introduced:  f48b5449dabc770acdde6d25cfbd265cfb71034d
 Bug not present: 86cf189a957129ea1ad6468fe9a0887b9e2819f3
 Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/115612/


 commit f48b5449dabc770acdde6d25cfbd265cfb71034d
 Author: Wei Liu 
 Date:   Thu Oct 12 20:19:07 2017 +0100
 tools/dombuilder: Switch to using gfn terminology for console and 
xenstore rings
 The sole use of xc_dom_translated() and xc_dom_p2m() outside of the 
domain
 builder is for libxl_dom() to translate the console and xenstore pfns 
back
 into useful values.  PV guest pfns are only interesting to the domain 
builder,
 and gfns are the address space used by all other hypercalls.
 Renaming the fields in xc_dom_image is deliberate, as it will cause
 out-of-tree users of the dombuilder to notice the different semantics.
 Correct the terminology throughout xc_dom_gnttab{_hvm,}_seed(), which 
are all
 using gfns despite the existing variable names.
 Signed-off-by: Andrew Cooper 
 Reviewed-by: Roger Pau Monn?? 
 Acked-by: Wei Liu 
 Tested-by: Julien Grall 
 Release-acked-by: Julien Grall 
 [ wei: fix stubdom build ]
 Signed-off-by: Wei Liu 


This has broken pvgrub. The problem is more than just the name of the
variables. I have reverted this and its successor patch.


It looks like osstest is still broken after the patches you reverted (see
[1] and [2]).

AFAICT, the only series between the two flights is the dombuilder, there are
2 patches not reverted.

Do you have an idea of what's going on?

Cheers,

[1] http://logs.test-lab.xenproject.org/osstest/logs/115624/
[2]
https://lists.xenproject.org/archives/html/xen-devel/2017-11/msg00391.html



test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.  
115526


Looking at the osstest result today, this one seem to be intermittent as 
it passed during the night but failed this morning.



test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs.  115526


The log for the xl-vhd contains ([1])

libxl: error: libxl_bootloader.c:283:bootloader_local_detached_cb: Domain 
11:unable to detach locally attached disk
libxl: error: libxl_create.c:1246:domcreate_rebuild_done: Domain 11:cannot 
(re-)build domain: -3
libxl: debug: libxl_domain.c:1138:devices_destroy_cb: Domain 11:Forked pid 5103 
for destroy of domain
libxl: debug: libxl_create.c:1683:do_domain_create: Domain 0:ao 0x5d6e8: 
inprogress: poller=0x56ad8, flags=i
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x5d6e8: complete, rc=-3
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x5d6e8: destroy
libxl: debug: libxl_domain.c:868:libxl_domain_destroy: Domain 11:ao 0x5a170: 
create: how=(nil) callback=(nil) poller=0x56ad8
libxl: error: libxl_domain.c:1000:libxl__destroy_domid: Domain 11:Non-existant 
domain
libxl: error: libxl_domain.c:959:domain_destroy_callback: Domain 11:Unable to 
destroy guest
libxl: error: libxl_domain.c:886:domain_destroy_cb: Domain 11:Destruction of 
domain failed
libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x5a170: complete, 
rc=-21
libxl: debug: libxl_domain.c:877:libxl_domain_destroy: Domain 11:ao 0x5a170: 
inprogress: poller=0x56ad8, flags=ic
libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x5a170: destroy

It is in guest repeat and has succeed few times before.

Looking at the success/failure ([2]), the same configuration passed on the 
Arndale
(see 115580) but fails reliably on the cubietruck.



The same test failed on Arndale as well in 115314 and 115526, with the
same error messages.

http://logs.test-lab.xenproject.org/osstest/logs/115526/test-armhf-armhf-xl-vhd/16.ts-guest-start.log

So the failure isn't related to Andrew's series.


My guess would be the disk is not detached by the previous guest in time.
Now the question is why? I am not familiar with this area, any ideas?



I don't have immediate idea either. I've set up a repro flight so that
we can have something to play with.


Thanks! Let me know when it is ready.

Cheers,

--
Julien Grall

___

Re: [Xen-devel] Bringing up OSS test framework on moonshot(aarch64) systems

[Ian Jackson]

Julien Grall writes ("Re: Bringing up OSS test framework on moonshot(aarch64) 
systems"):
> On 08/11/17 11:39, Ian Jackson wrote:
> > I'm not familiar with the referent of "moonshot" in this context.  IME
> > "moonshot" is a project name chosen multiple times, for different
> > projects, by people who want to give an impression that the project is
> > ambitious.
> 
> In that context, this is an moonshot brand from HP. It is a 4.3U that 
> accepts up to 45 cartridges (see [1]).

Aha.

> They have x86 cartridges but also provides Arm64 one based on X-Gene 1 
> (APM).
> 
> Bhupinder is looking at bring up Osstest on the Arm64 cartridges.

Thanks for the explanation.  I'm happy to help.

Ian.

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

[Anthony PERARD]

On Thu, Nov 02, 2017 at 01:49:54PM +, Julien Grall wrote:
> On 27/10/17 21:16, Stefano Stabellini wrote:
> > On Fri, 27 Oct 2017, Julien Grall wrote:
> > > On 27/10/17 08:27, Hao, Xudong wrote:
> > > > This bug exist much long time, there are many discussion last year but 
> > > > not a
> > > > solution then. I call out it now because there is a fix in qemu 
> > > > upstream:
> > > > commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
> > > > Author: Roger Pau Monne 
> > > > Date:   Thu Aug 24 16:07:03 2017 +0100
> > > > 
> > > >   xen/pt: allow QEMU to request MSI unmasking at bind time
> > > > 
> > > > The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? 
> > > > Is it
> > > > possible to catch Xen 4.10's qemu-xen?
> > > 
> > > I will let Stefano and Anthony providing feedback before giving a 
> > > release-ack
> > > here.
> > 
> > Yes, I think we should backport the commit as it fixes a genuine bug.
> > The backport is not risk-free but it only affects PCI Passthrough. Also
> > the commit has been in QEMU for 2 months now.
> 
> Does anyone actually tested it with QEMU Xen tree?

Yes.  I've tested qemu-xen with this patch and PCI passthrough still
works.

Can I get a release-ack?

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov

[Julien Grall]

Hi Anthony,

On 08/11/17 12:13, Anthony PERARD wrote:

On Thu, Nov 02, 2017 at 01:49:54PM +, Julien Grall wrote:

On 27/10/17 21:16, Stefano Stabellini wrote:

On Fri, 27 Oct 2017, Julien Grall wrote:

On 27/10/17 08:27, Hao, Xudong wrote:

This bug exist much long time, there are many discussion last year but not a
solution then. I call out it now because there is a fix in qemu upstream:
commit a8036336609d2e184fc3543a4c439c0ba7d7f3a2
Author: Roger Pau Monne 
Date:   Thu Aug 24 16:07:03 2017 +0100

   xen/pt: allow QEMU to request MSI unmasking at bind time

The fix is not in qemu-xen tree yet, when will qemu-xen sync this fix? Is it
possible to catch Xen 4.10's qemu-xen?


I will let Stefano and Anthony providing feedback before giving a release-ack
here.


Yes, I think we should backport the commit as it fixes a genuine bug.
The backport is not risk-free but it only affects PCI Passthrough. Also
the commit has been in QEMU for 2 months now.


Does anyone actually tested it with QEMU Xen tree?


Yes.  I've tested qemu-xen with this patch and PCI passthrough still
works.

Can I get a release-ack?


I'd still like an answer on Roger's question whether this patch fixes 
the issue they met.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 13:03, Paolo Bonzini wrote:
> On 08/11/2017 12:55, Juergen Gross wrote:
>> On 08/11/17 12:18, Jan Beulich wrote:
>> On 08.11.17 at 10:07,  wrote:
 In case we are booted via the default boot entry by a generic loader
 like grub or OVMF it is necessary to distinguish between a HVM guest
 with a device model supporting legacy devices and a PVH guest without
 device model.

 PVH guests will always have x86_platform.legacy.no_vga set and
 x86_platform.legacy.rtc cleared, while both won't be true for HVM
 guests.

 Test for both conditions in the guest_late_init hook and set xen_pvh
 to true if they are met.
>>>
>>> This sounds pretty fragile to me: I can't see a reason why a proper
>>> HVM guest couldn't come without VGA and RTC. That's not possible
>>> today, agreed, but certainly an option down the road if virtualization
>>> follows bare metal's road towards being legacy free.
>>
>> From guest's perspective: what is the difference between a legacy free
>> HVM domain and PVH? In the end the need for differentiating is to avoid
>> access to legacy features in PVH as those would require a device model.
> 
> My understanding of Xen is very rusty at this point, but I think a
> "completely" legacy-free HVM domain will still have a PCI bus and the
> Xen platform device on that bus.
> 
> A PVH domain just knows how to access the Xen PV features.

A HVM domain does so, too. Today maybe only partially, but e.g. event
channels work in a HVM domain even without the Xen platform device.
Grant tables can be made working without the platform device, too,
and I'm already preparing a patch to do exactly that.

The only need for the platform device will then be to have an
interface for unplugging emulated boot devices in favor of the pv
devices. And without the platform device we can just skip that
step without doing any harm, as this can happen only for PVH where
we have no need to do the unplug, or for HVM explicitly configured
to work without platform device needing to continue using the
emulated devices as it is doing today in this case.


Juergen

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

Re: [Xen-devel] [PATCH for-4.10] gcov: return EOPNOTSUPP for unimplemented gcov domctl

[Julien Grall]

Hi,

On 07/11/17 14:20, Jan Beulich wrote:

On 07.11.17 at 13:31,  wrote:

ENOSYS should only be used by unimplemented top-level syscalls. Use
EOPNOTSUPP instead.

Signed-off-by: Roger Pau Monné 
Reported-by: Jan Beulich 


Reviewed-by: Jan Beulich 


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Paolo Bonzini]

On 08/11/2017 13:24, Juergen Gross wrote:
>> My understanding of Xen is very rusty at this point, but I think a
>> "completely" legacy-free HVM domain will still have a PCI bus and the
>> Xen platform device on that bus.
>>
>> A PVH domain just knows how to access the Xen PV features.
>
> A HVM domain does so, too. Today maybe only partially, but e.g. event
> channels work in a HVM domain even without the Xen platform device.
> Grant tables can be made working without the platform device, too,
> and I'm already preparing a patch to do exactly that.

What about assigned PCI devices?  I think they are not PV pcifront for
HVM.  So the main difference in the end is the PCI bus.

Paolo

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

Re: [Xen-devel] [PATCH for-4.10] x86/cpuid: Minor fixups missed from previous work

[Julien Grall]

Hi,

On 03/11/17 17:35, Andrew Cooper wrote:

  * Add more feature names to ./xen-cpuid
  * Vertically align the magic comments in cpufeatureset.h

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Ian Jackson 
CC: Wei Liu 
CC: Julien Grall 

This is a nice-to-have for Xen 4.10.  It is very low risk, as the functional
changes are restricted to debug utilities only.


Release-acked-by: Julien Grall 

Cheers,


---
  tools/misc/xen-cpuid.c  | 15 ++-
  xen/include/public/arch-x86/cpufeatureset.h |  4 ++--
  2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
index 106be0f..0831f75 100644
--- a/tools/misc/xen-cpuid.c
+++ b/tools/misc/xen-cpuid.c
@@ -95,7 +95,7 @@ static const char *str_7b0[32] =
  [ 0] = "fsgsbase", [ 1] = "tsc-adj",
  [ 2] = "sgx",  [ 3] = "bmi1",
  [ 4] = "hle",  [ 5] = "avx2",
-[ 6] = "REZ",  [ 7] = "smep",
+[ 6] = "fdp_exn",  [ 7] = "smep",
  [ 8] = "bmi2", [ 9] = "erms",
  [10] = "invpcid",  [11] = "rtm",
  [12] = "pqm",  [13] = "depfpp",
@@ -121,23 +121,28 @@ static const char *str_Da1[32] =
  static const char *str_7c0[32] =
  {
  [ 0] = "prechwt1", [ 1] = "avx512vbmi",
-[ 2] = "REZ",  [ 3] = "pku",
+[ 2] = "umip", [ 3] = "pku",
  [ 4] = "ospke",
  
  [5 ... 13] = "REZ",
  
  [14] = "avx512_vpopcntdq",
  
-[15 ... 31] = "REZ",

+[15 ... 21] = "REZ",
+
+[22] = "rdpid",
+
+[23 ... 31] = "REZ",
  };
  
  static const char *str_e7d[32] =

  {
  [0 ... 7] = "REZ",
  
-[ 8] = "itsc",

+[ 8] = "itsc", [ 9] = "REZ",
+[10] = "efro",
  
-[9 ... 31] = "REZ",

+[11 ... 31] = "REZ",
  };
  
  static const char *str_e8b[32] =

diff --git a/xen/include/public/arch-x86/cpufeatureset.h 
b/xen/include/public/arch-x86/cpufeatureset.h
index 0ee3ea3..be6da8e 100644
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -239,8 +239,8 @@ XEN_CPUFEATURE(EFRO,  7*32+10) /*   APERF/MPERF 
Read Only interface */
  XEN_CPUFEATURE(CLZERO,8*32+ 0) /*A  CLZERO instruction */
  
  /* Intel-defined CPU features, CPUID level 0x0007:0.edx, word 9 */

-XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /*A AVX512 Neural Network Instructions 
*/
-XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A AVX512 Multiply Accumulation Single 
Precision */
+XEN_CPUFEATURE(AVX512_4VNNIW, 9*32+ 2) /*A  AVX512 Neural Network Instructions 
*/
+XEN_CPUFEATURE(AVX512_4FMAPS, 9*32+ 3) /*A  AVX512 Multiply Accumulation 
Single Precision */
  
  #endif /* XEN_CPUFEATURE */
  



--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Jan Beulich]

>>> On 08.11.17 at 12:55,  wrote:
> On 08/11/17 12:18, Jan Beulich wrote:
> On 08.11.17 at 10:07,  wrote:
>>> In case we are booted via the default boot entry by a generic loader
>>> like grub or OVMF it is necessary to distinguish between a HVM guest
>>> with a device model supporting legacy devices and a PVH guest without
>>> device model.
>>>
>>> PVH guests will always have x86_platform.legacy.no_vga set and
>>> x86_platform.legacy.rtc cleared, while both won't be true for HVM
>>> guests.
>>>
>>> Test for both conditions in the guest_late_init hook and set xen_pvh
>>> to true if they are met.
>> 
>> This sounds pretty fragile to me: I can't see a reason why a proper
>> HVM guest couldn't come without VGA and RTC. That's not possible
>> today, agreed, but certainly an option down the road if virtualization
>> follows bare metal's road towards being legacy free.
> 
> From guest's perspective: what is the difference between a legacy free
> HVM domain and PVH? In the end the need for differentiating is to avoid
> access to legacy features in PVH as those would require a device model.

My point is that "legacy free" would likely be reached over time (and
even once fully reached, hybrid configurations would be possible).
I.e. there could be a setup with PIC, but with neither VGA nor RTC.
That's still not PVH then. Nor do all legacy features require a device
model in the first place - some of them are being emulated entirely
in the hypervisor.

Furthermore, PVH absolutely requires guest awareness afaict, while
legacy-free pure HVM guests (with an OS only aware of the possible
absence of legacy devices) would still be possible.

Jan


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 13:26, Paolo Bonzini wrote:
> On 08/11/2017 13:24, Juergen Gross wrote:
>>> My understanding of Xen is very rusty at this point, but I think a
>>> "completely" legacy-free HVM domain will still have a PCI bus and the
>>> Xen platform device on that bus.
>>>
>>> A PVH domain just knows how to access the Xen PV features.
>>
>> A HVM domain does so, too. Today maybe only partially, but e.g. event
>> channels work in a HVM domain even without the Xen platform device.
>> Grant tables can be made working without the platform device, too,
>> and I'm already preparing a patch to do exactly that.
> 
> What about assigned PCI devices?  I think they are not PV pcifront for
> HVM.  So the main difference in the end is the PCI bus.

Sure, but this is easily detectable, isn't it?


Juergen


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

Re: [Xen-devel] [PATCH for-4.10] gcov: return EOPNOTSUPP for unimplemented gcov domctl

[Jan Beulich]

>>> On 07.11.17 at 13:31,  wrote:
> ENOSYS should only be used by unimplemented top-level syscalls. Use
> EOPNOTSUPP instead.
> 
> Signed-off-by: Roger Pau Monné 
> Reported-by: Jan Beulich 

Btw I've taken the liberty to make the title say "sysctl" instead of
"domctl".

Jan

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 13:31, Jan Beulich wrote:
 On 08.11.17 at 12:55,  wrote:
>> On 08/11/17 12:18, Jan Beulich wrote:
>> On 08.11.17 at 10:07,  wrote:
 In case we are booted via the default boot entry by a generic loader
 like grub or OVMF it is necessary to distinguish between a HVM guest
 with a device model supporting legacy devices and a PVH guest without
 device model.

 PVH guests will always have x86_platform.legacy.no_vga set and
 x86_platform.legacy.rtc cleared, while both won't be true for HVM
 guests.

 Test for both conditions in the guest_late_init hook and set xen_pvh
 to true if they are met.
>>>
>>> This sounds pretty fragile to me: I can't see a reason why a proper
>>> HVM guest couldn't come without VGA and RTC. That's not possible
>>> today, agreed, but certainly an option down the road if virtualization
>>> follows bare metal's road towards being legacy free.
>>
>> From guest's perspective: what is the difference between a legacy free
>> HVM domain and PVH? In the end the need for differentiating is to avoid
>> access to legacy features in PVH as those would require a device model.
> 
> My point is that "legacy free" would likely be reached over time (and
> even once fully reached, hybrid configurations would be possible).
> I.e. there could be a setup with PIC, but with neither VGA nor RTC.
> That's still not PVH then. Nor do all legacy features require a device
> model in the first place - some of them are being emulated entirely
> in the hypervisor.
> 
> Furthermore, PVH absolutely requires guest awareness afaict, while
> legacy-free pure HVM guests (with an OS only aware of the possible
> absence of legacy devices) would still be possible.

Hmm, where else do you expect PVH awareness to be required? Maybe for
vcpu hotplugging, but this could easily be solved by adding a Xenstore
entry containing the required information. Is there any other problem to
be expected before Xenstore access is possible?


Juergen

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

[Xen-devel] [PATCH for-4.10] libevtchn: fix build on non-Linux hosts

[Roger Pau Monne]

Non-Linux hosts (where osdep_evtchn_restrict is not yet supported)
made use of errno without including errno.h, fix this by including the
header.

Signed-off-by: Roger Pau Monné 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Julien Grall 
---
Build fix for 4.10: it only affects non-Linux, and without this fix
the tools cannot be build.
---
 tools/libs/evtchn/freebsd.c | 1 +
 tools/libs/evtchn/netbsd.c  | 1 +
 tools/libs/evtchn/solaris.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/tools/libs/evtchn/freebsd.c b/tools/libs/evtchn/freebsd.c
index ba82f06311..6564ed4c44 100644
--- a/tools/libs/evtchn/freebsd.c
+++ b/tools/libs/evtchn/freebsd.c
@@ -19,6 +19,7 @@
  * Split off from xc_freebsd_osdep.c
  */
 
+#include 
 #include 
 #include 
 
diff --git a/tools/libs/evtchn/netbsd.c b/tools/libs/evtchn/netbsd.c
index 5ce3a35f80..8b8545d2f9 100644
--- a/tools/libs/evtchn/netbsd.c
+++ b/tools/libs/evtchn/netbsd.c
@@ -19,6 +19,7 @@
  * Split out from xc_netbsd.c
  */
 
+#include 
 #include 
 #include 
 
diff --git a/tools/libs/evtchn/solaris.c b/tools/libs/evtchn/solaris.c
index f718989450..dd41f62a24 100644
--- a/tools/libs/evtchn/solaris.c
+++ b/tools/libs/evtchn/solaris.c
@@ -19,6 +19,7 @@
  * Split out from xc_solaris.c
  */
 
+#include 
 #include 
 #include 
 
-- 
2.13.6 (Apple Git-96)


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm broken
 test-armhf-armhf-libvirt-xsm  4 host-install(4)broken REGR. vs. 114682
 test-amd64-amd64-xl-qcow2   19 guest-start/debian.repeat fail REGR. vs. 114682
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114682
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 114682
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682
 test-armhf-armhf-xl-vhd 15 guest-start/debian.repeat fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxfbc3edf7d7731d7a22c483c679700589bab936a3
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z   21 days
Failing since114781  2017-10-20 01:00:47 Z   19 days   33 attempts
Testing same since   115658  2017-11-08 02:33:06 Z0 days1 attempts


523 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH for-4.10] libevtchn: fix build on non-Linux hosts

[Wei Liu]

On Wed, Nov 08, 2017 at 12:52:57PM +, Roger Pau Monne wrote:
> Non-Linux hosts (where osdep_evtchn_restrict is not yet supported)
> made use of errno without including errno.h, fix this by including the
> header.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Jan Beulich]

>>> On 08.11.17 at 13:45,  wrote:
> On 08/11/17 13:31, Jan Beulich wrote:
> On 08.11.17 at 12:55,  wrote:
>>> On 08/11/17 12:18, Jan Beulich wrote:
>>> On 08.11.17 at 10:07,  wrote:
> In case we are booted via the default boot entry by a generic loader
> like grub or OVMF it is necessary to distinguish between a HVM guest
> with a device model supporting legacy devices and a PVH guest without
> device model.
>
> PVH guests will always have x86_platform.legacy.no_vga set and
> x86_platform.legacy.rtc cleared, while both won't be true for HVM
> guests.
>
> Test for both conditions in the guest_late_init hook and set xen_pvh
> to true if they are met.

 This sounds pretty fragile to me: I can't see a reason why a proper
 HVM guest couldn't come without VGA and RTC. That's not possible
 today, agreed, but certainly an option down the road if virtualization
 follows bare metal's road towards being legacy free.
>>>
>>> From guest's perspective: what is the difference between a legacy free
>>> HVM domain and PVH? In the end the need for differentiating is to avoid
>>> access to legacy features in PVH as those would require a device model.
>> 
>> My point is that "legacy free" would likely be reached over time (and
>> even once fully reached, hybrid configurations would be possible).
>> I.e. there could be a setup with PIC, but with neither VGA nor RTC.
>> That's still not PVH then. Nor do all legacy features require a device
>> model in the first place - some of them are being emulated entirely
>> in the hypervisor.
>> 
>> Furthermore, PVH absolutely requires guest awareness afaict, while
>> legacy-free pure HVM guests (with an OS only aware of the possible
>> absence of legacy devices) would still be possible.
> 
> Hmm, where else do you expect PVH awareness to be required? Maybe for
> vcpu hotplugging, but this could easily be solved by adding a Xenstore
> entry containing the required information. Is there any other problem to
> be expected before Xenstore access is possible?

Let me ask the question the other way around: What's all the PVH
specific code for under arch/x86/xen/ if there's no difference? One
thing I seem to remember is that getting hold of the ACPI tables
is different between PVH and HVM. Iirc the distinct PVH entry point
is (in part) for that purpose. In the end - with that separate entry
point - it is not really clear to me why any "detection" needs to be
done in the first place: You'd know which mode you're in by knowing
which entry point path you've taken.

Jan


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

[Xen-devel] [PATCH] xen/privcmd: remove unused variable pageidx

[Colin King]

From: Colin Ian King 

Variable pageidx is assigned a value but it is never read, hence it
is redundant and can be removed. Cleans up clang warning:

drivers/xen/privcmd.c:199:2: warning: Value stored to 'pageidx'
is never read

Signed-off-by: Colin Ian King 
---
 drivers/xen/privcmd.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c
index feca75b07fdd..1c909183c42a 100644
--- a/drivers/xen/privcmd.c
+++ b/drivers/xen/privcmd.c
@@ -191,13 +191,10 @@ static int traverse_pages_block(unsigned nelem, size_t 
size,
void *state)
 {
void *pagedata;
-   unsigned pageidx;
int ret = 0;
 
BUG_ON(size > PAGE_SIZE);
 
-   pageidx = PAGE_SIZE;
-
while (nelem) {
int nr = (PAGE_SIZE/size);
struct page *page;
-- 
2.14.1


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

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Joao Martins]

On 11/08/2017 11:06 AM, Thomas Gleixner wrote:
> On Tue, 7 Nov 2017, Joao Martins wrote:
>> On 11/06/2017 04:09 PM, Paolo Bonzini wrote:
>>> On 19/10/2017 15:39, Joao Martins wrote:
 Right now there is only a pvclock_pvti_cpu0_va() which is defined
 on kvmclock since:

 commit dac16fba6fc5
 ("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")

 The only user of this interface so far is kvm. This commit adds a
 setter function for the pvti page and moves pvclock_pvti_cpu0_va
 to pvclock, which is a more generic place to have it; and would
 allow other PV clocksources to use it, such as Xen.

 Signed-off-by: Joao Martins 
 Acked-by: Andy Lutomirski 
>>>
>>> Acked-by: Paolo Bonzini 
>>>
>>> IOW, the Xen folks are free to pick up the whole series. :)
>>>
>> Thank you!
>>
>> I guess only x86 maintainers Ack is left - any comments?
> 
> The only nit-pick I have are the convoluted function names:
> 
> pvclock_set_pvti_cpu0_va() pvclock_pvti_cpu0_va()
> 
> What on earth does that mean?
>
Those two functions respectively set and get in pvclock common code the address
of a page for vCPU 0 containing time info (pvti, which is periodically updated
by hypervisor). This region is guest memory and registered with hypervisor by
guest PV clocksource and set in pvclock if certain conditions are met (i.e.
PVCLOCK_TSC_STABLE_BIT is supported by hypervisor), and the getter is afterwards
used by vdso and ptp_kvm.

FWIW I merely followed the current style/code of the existent function but there
could be a better name like "pvclock_set_data() pvclock_get_data()". Albeit the
current names are more explicit on what we should expect to set or return from
the functions.

> Aside of that can you please make it at least symetric, i.e. _set_ and
> _get_ ?
> 
OK - Provided this is changing an exported symbol (pvclock_pvti_cpu0_va in use
by ptp_kvm) and a non-functional change would you want me to address in a
separate patch or it is OK to have in this one?

> Other than that:
> 
>   Acked-by: Thomas Gleixner 
> 
Thanks!

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

Re: [Xen-devel] [PATCH v7 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Thomas Gleixner]

On Wed, 8 Nov 2017, Joao Martins wrote:
> On 11/08/2017 11:06 AM, Thomas Gleixner wrote:
> > The only nit-pick I have are the convoluted function names:
> > 
> > pvclock_set_pvti_cpu0_va() pvclock_pvti_cpu0_va()
> > 
> > What on earth does that mean?
> >
> Those two functions respectively set and get in pvclock common code the 
> address
> of a page for vCPU 0 containing time info (pvti, which is periodically updated
> by hypervisor). This region is guest memory and registered with hypervisor by
> guest PV clocksource and set in pvclock if certain conditions are met (i.e.
> PVCLOCK_TSC_STABLE_BIT is supported by hypervisor), and the getter is 
> afterwards
> used by vdso and ptp_kvm.
> 
> FWIW I merely followed the current style/code of the existent function but 
> there
> could be a better name like "pvclock_set_data() pvclock_get_data()". Albeit 
> the
> current names are more explicit on what we should expect to set or return from
> the functions.

Fair enough.

> 
> > Aside of that can you please make it at least symetric, i.e. _set_ and
> > _get_ ?
> > 
> OK - Provided this is changing an exported symbol (pvclock_pvti_cpu0_va in use
> by ptp_kvm) and a non-functional change would you want me to address in a
> separate patch or it is OK to have in this one?

Just fixup the ptp_kvm call site in the very same patch.

Thanks,

tglx

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

Re: [Xen-devel] [PATCH] xen/privcmd: remove unused variable pageidx

[Juergen Gross]

On 08/11/17 14:00, Colin King wrote:
> From: Colin Ian King 
> 
> Variable pageidx is assigned a value but it is never read, hence it
> is redundant and can be removed. Cleans up clang warning:
> 
> drivers/xen/privcmd.c:199:2: warning: Value stored to 'pageidx'
> is never read
> 
> Signed-off-by: Colin Ian King 

Reviewed-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

[Boris Ostrovsky]

On 11/08/2017 04:07 AM, Juergen Gross wrote:
> Booting a Xen PVH guest requires a special boot entry as it is
> mandatory to setup some Xen-specific interfaces rather early. When grub
> or OVMF are used as boot loaders, however, those will fill the boot
> parameters in zeropage and there is no longer a need to do something
> PVH specific in the early boot path.
>
> This patch series adds support for that scenario by identifying PVH
> environment and doing the required init steps via Xen hooks instead of
> using a dedicated boot entry.
>
> The dedicated entry is still needed for support of Dom0 running in PVH
> mode as in this case there is no grub or OVMF involved for filling in
> the boot parameters.

We are going to continue supporting direct boot of unprivileged guests
too so this entry point will be needed not for dom0 only.

-boris

>
> Juergen Gross (3):
>   x86/acpi: add test for ACPI_FADT_NO_VGA
>   x86: add guest_late_init hook to hypervisor_x86 structure
>   x86/xen: use guest_late_init to detect Xen PVH guest
>
>  arch/x86/include/asm/hypervisor.h | 11 +++
>  arch/x86/include/asm/kvm_para.h   |  2 --
>  arch/x86/include/asm/x86_init.h   |  1 +
>  arch/x86/kernel/acpi/boot.c   |  5 +
>  arch/x86/kernel/kvm.c |  3 ++-
>  arch/x86/kernel/setup.c   |  2 +-
>  arch/x86/xen/enlighten_hvm.c  | 24 ++--
>  arch/x86/xen/enlighten_pvh.c  |  9 -
>  8 files changed, 42 insertions(+), 15 deletions(-)
>


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 13:58, Jan Beulich wrote:
 On 08.11.17 at 13:45,  wrote:
>> On 08/11/17 13:31, Jan Beulich wrote:
>> On 08.11.17 at 12:55,  wrote:
 On 08/11/17 12:18, Jan Beulich wrote:
 On 08.11.17 at 10:07,  wrote:
>> In case we are booted via the default boot entry by a generic loader
>> like grub or OVMF it is necessary to distinguish between a HVM guest
>> with a device model supporting legacy devices and a PVH guest without
>> device model.
>>
>> PVH guests will always have x86_platform.legacy.no_vga set and
>> x86_platform.legacy.rtc cleared, while both won't be true for HVM
>> guests.
>>
>> Test for both conditions in the guest_late_init hook and set xen_pvh
>> to true if they are met.
>
> This sounds pretty fragile to me: I can't see a reason why a proper
> HVM guest couldn't come without VGA and RTC. That's not possible
> today, agreed, but certainly an option down the road if virtualization
> follows bare metal's road towards being legacy free.

 From guest's perspective: what is the difference between a legacy free
 HVM domain and PVH? In the end the need for differentiating is to avoid
 access to legacy features in PVH as those would require a device model.
>>>
>>> My point is that "legacy free" would likely be reached over time (and
>>> even once fully reached, hybrid configurations would be possible).
>>> I.e. there could be a setup with PIC, but with neither VGA nor RTC.
>>> That's still not PVH then. Nor do all legacy features require a device
>>> model in the first place - some of them are being emulated entirely
>>> in the hypervisor.
>>>
>>> Furthermore, PVH absolutely requires guest awareness afaict, while
>>> legacy-free pure HVM guests (with an OS only aware of the possible
>>> absence of legacy devices) would still be possible.
>>
>> Hmm, where else do you expect PVH awareness to be required? Maybe for
>> vcpu hotplugging, but this could easily be solved by adding a Xenstore
>> entry containing the required information. Is there any other problem to
>> be expected before Xenstore access is possible?
> 
> Let me ask the question the other way around: What's all the PVH
> specific code for under arch/x86/xen/ if there's no difference? One

Most of it is for early boot when coming through the PVH specific
boot entry.

> thing I seem to remember is that getting hold of the ACPI tables
> is different between PVH and HVM. Iirc the distinct PVH entry point
> is (in part) for that purpose. In the end - with that separate entry
> point - it is not really clear to me why any "detection" needs to be
> done in the first place: You'd know which mode you're in by knowing
> which entry point path you've taken.

Its all in the commit message: I am trying to enable a boot loader to
use the default kernel boot entry for PVH. This will reduce the needed
modifications in the loader.

Regarding ACPI tables: current PVH implementation in Linux kernel
seems not to make use of the special information presented in the boot
information block.


Juergen

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

Re: [Xen-devel] [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

[Juergen Gross]

On 08/11/17 14:37, Boris Ostrovsky wrote:
> On 11/08/2017 04:07 AM, Juergen Gross wrote:
>> Booting a Xen PVH guest requires a special boot entry as it is
>> mandatory to setup some Xen-specific interfaces rather early. When grub
>> or OVMF are used as boot loaders, however, those will fill the boot
>> parameters in zeropage and there is no longer a need to do something
>> PVH specific in the early boot path.
>>
>> This patch series adds support for that scenario by identifying PVH
>> environment and doing the required init steps via Xen hooks instead of
>> using a dedicated boot entry.
>>
>> The dedicated entry is still needed for support of Dom0 running in PVH
>> mode as in this case there is no grub or OVMF involved for filling in
>> the boot parameters.
> 
> We are going to continue supporting direct boot of unprivileged guests
> too so this entry point will be needed not for dom0 only.

Sure, but using e.g. grub in this case would be an alternative. For Dom0
this alternative isn't existing. So this entry is mandatory, not a "nice
to have".


Juergen


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

Re: [Xen-devel] [PATCH 0/3] x86/xen: support booting PVH guest via standard boot path

[Boris Ostrovsky]

On 11/08/2017 08:40 AM, Juergen Gross wrote:
> On 08/11/17 14:37, Boris Ostrovsky wrote:
>> On 11/08/2017 04:07 AM, Juergen Gross wrote:
>>> Booting a Xen PVH guest requires a special boot entry as it is
>>> mandatory to setup some Xen-specific interfaces rather early. When grub
>>> or OVMF are used as boot loaders, however, those will fill the boot
>>> parameters in zeropage and there is no longer a need to do something
>>> PVH specific in the early boot path.
>>>
>>> This patch series adds support for that scenario by identifying PVH
>>> environment and doing the required init steps via Xen hooks instead of
>>> using a dedicated boot entry.
>>>
>>> The dedicated entry is still needed for support of Dom0 running in PVH
>>> mode as in this case there is no grub or OVMF involved for filling in
>>> the boot parameters.
>> We are going to continue supporting direct boot of unprivileged guests
>> too so this entry point will be needed not for dom0 only.
> Sure, but using e.g. grub in this case would be an alternative. For Dom0
> this alternative isn't existing. So this entry is mandatory, not a "nice
> to have".

Right, I was just pointing out that the way the message is phrased makes
it sounds (to me at least) as if dom0 is the only reason for the
dedicated entry point.

-boris

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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Boris Ostrovsky]

On 11/08/2017 08:36 AM, Juergen Gross wrote:
>
> Regarding ACPI tables: current PVH implementation in Linux kernel
> seems not to make use of the special information presented in the boot
> information block.

It will need to do so for dom0 (and, then, for simplicity, for all PVH
guests).

-boris


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Juergen Gross]

On 08/11/17 15:10, Boris Ostrovsky wrote:
> On 11/08/2017 08:36 AM, Juergen Gross wrote:
>>
>> Regarding ACPI tables: current PVH implementation in Linux kernel
>> seems not to make use of the special information presented in the boot
>> information block.
> 
> It will need to do so for dom0 (and, then, for simplicity, for all PVH
> guests).

What about: for all PVH guests booted via the PVH specific boot entry?
A guest booted via the default boot entry won't know it is PVH until
ACPI tables have been scanned.


Juergen


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

Re: [Xen-devel] [PATCH 3/3] x86/xen: use guest_late_init to detect Xen PVH guest

[Boris Ostrovsky]

On 11/08/2017 09:17 AM, Juergen Gross wrote:
> On 08/11/17 15:10, Boris Ostrovsky wrote:
>> On 11/08/2017 08:36 AM, Juergen Gross wrote:
>>> Regarding ACPI tables: current PVH implementation in Linux kernel
>>> seems not to make use of the special information presented in the boot
>>> information block.
>> It will need to do so for dom0 (and, then, for simplicity, for all PVH
>> guests).
> What about: for all PVH guests booted via the PVH specific boot entry?
> A guest booted via the default boot entry won't know it is PVH until
> ACPI tables have been scanned.

Right. Guest booted from default entry will have to discover RSDP in the
usual way.

-boris

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

[Xen-devel] [RFC] [Draft Design v2] ACPI/IORT Support in Xen.

[Manish Jaggi]

ACPI/IORT Support in Xen.
--
Draft 2

Revision History:

Changes since v1-
- Modified IORT Parsing data structures.
- Added RID->StreamID and RID->DeviceID map as per Andre's suggestion.
- Added reference code which can be read along with this document.
- Removed domctl for DomU, it would be covered in PCI-PT design.

Introduction:
-

I had sent out patch series [0] to hide smmu from Dom0 IORT.
This document is a rework of the series as it:
(a) extends scope by adding parsing of IORT table once
and storing it in in-memory data structures, which can then be used
for querying. This would eliminate the need to parse complete iort
table multiple times.

(b) Generation of IORT for domains be independent using a set of
helper routines.

Index


1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Implementation Phases
8. References

1. IORT Structure ?

IORT refers to Input Output remapping table. It is essentially used to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships between
devices.

A general structure of IORT [1]:
It has nodes for PCI RC, SMMU, ITS and Platform devices. Using an IORT table
relationship between RID -> StreamID -> DeviceId can be obtained.
Which device is behind which SMMU and which interrupt controller, topology
is described in IORT Table.

Some PCI RC may be not behind an SMMU, and directly map RID->DeviceID.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

Each iort_node contains an ID map array to translate one ID into another.
IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is associated with PCI RC node, SMMU node, Named component node.
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---
IORT is proposed to be used by Xen to setup SMMU's and platform devices
and for translating RID->StreamID and RID->DeviceID.

It is proposed in this document to parse iort once and use the information
to translate RID without traversing IORT again and again.

Also Xen prepares an IORT table for dom0 based on host IORT.
For DomU IORT table proposed only in case of device passthrough.

3. IORT for Dom0
-
IORT for Dom0 is based on host iort. Few nodes could be removed or modified.
 For instance
- Host SMMU nodes should not be present as Xen should only touch it.
- platform nodes (named components) may be controlled by xen command line.

4. IORT for DomU
-
IORT for DomU should be generated by toolstack. IORT table is only present
in case of device passthrough.

At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
The exact structure of DomU IORT would be covered along with PCI PT design.

5. Parsing of IORT in Xen
--
IORT nodes can be saved in structures so that IORT table parsing can be done
once and is reused by all xen subsystems like ITS / SMMU etc, domain creation.
Proposed are the structures to hold IORT information. [4]

struct rid_map_struct {
void *pcirc_node;
u16 ib; /* Input base */
u32 ob; /* Output base */
u16 idc; /* Id Count */
struct list_head entry;
};

struct iort_ref
{
struct list_head rid_streamId_map;
struct list_head rid_deviceId_map;
}iortref;

5.1 Functions to query StreamID and DeviceID from RID.

void query_streamId(void *pcirc_node, u16 rid, u32 *streamId);
void query_deviceId(void *pcirc_node, u16 rid, u32 *deviceId);

Adding a mapping is done via helper functions

intadd_rid_streamId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) 
intadd_rid_deviceId_map(void*pcirc_node, u32 ib, u32 ob, u32 idc) - rid-streamId map is straight forward and is created using pci_rc's idmap

- rid-deviceId map is created by translating streamIds to deviceIds.
fixup_rid_deviceId_map function does that. (See [6])

It is proposed that query functions should replace functions like
iort_node_map_rid which is currently used in linux and is imported in Xen
in the patchset [2][5]

5.2 Proposed Flow of parsing
The flow is based on the patchset in [5]. I have added a reference code on
top of it which does IORT parsing as described in this section. The code
is available at [6].

The commit also describes the code flow and assumptions.

6. IORT Generation
---
It is proposed to have a common helper library to generate IORT for dom0/U.
Note: it is desired to have IORT generation code sharing between toolstack
and Xen.

a. For Dom0
 rid_deviceId_map can be used directly to generate dom0 IORT table.
 Exclusions of nodes is still open for suggestions.

b. For DomU
 Minimal structure is discussed in section 4. It will be further discussed
 in the context of PCI PT

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

[Manish Jaggi]

Hi Sameer

On 9/21/2017 6:07 AM, Sameer Goel wrote:

Add support for parsing IORT table to initialize SMMU devices.
* The code for creating an SMMU device has been modified, so that the SMMU
device can be initialized.
* The NAMED NODE code has been commented out as this will need DOM0 kernel
support.
* ITS code has been included but it has not been tested.

Signed-off-by: Sameer Goel 
Followup of the discussions we had on iort parsing and querying streamID 
and deviceId based on RID.

I have extended your patchset with a patch that provides an alternative
way of parsing iort into maps : {rid-streamid}, {rid-deviceID)
which can directly be looked up for searching streamId for a rid. This
will remove the need to traverse iort table again.

The test patch just describes the proposed flow and how the parsing and
query code might fit in. I have not tested it.
The code only compiles.

https://github.com/mjaggi-cavium/xen-wip/commit/df006d64bdbb5c8344de5a710da8bf64c9e8edd5
(This repo has all 7 of your patches + test code patch merged.

Note: The commit text of the patch describes the basic flow /assumptions 
/ usage of functions.

Please see the code along with the v2 design draft.
[RFC] [Draft Design v2] ACPI/IORT Support in Xen.
https://lists.xen.org/archives/html/xen-devel/2017-11/msg00512.html

I seek your advice on this. Please provide your feedback.

Thanks
Manish



---
  xen/arch/arm/setup.c   |   3 +
  xen/drivers/acpi/Makefile  |   1 +
  xen/drivers/acpi/arm/Makefile  |   1 +
  xen/drivers/acpi/arm/iort.c| 173 +
  xen/drivers/passthrough/arm/smmu.c |   1 +
  xen/include/acpi/acpi_iort.h   |  17 ++--
  xen/include/asm-arm/device.h   |   2 +
  xen/include/xen/acpi.h |  21 +
  xen/include/xen/pci.h  |   8 ++
  9 files changed, 146 insertions(+), 81 deletions(-)
  create mode 100644 xen/drivers/acpi/arm/Makefile

diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 92f173b..4ba09b2 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -49,6 +49,7 @@
  #include 
  #include 
  #include 
+#include 
  
  struct bootinfo __initdata bootinfo;
  
@@ -796,6 +797,8 @@ void __init start_xen(unsigned long boot_phys_offset,
  
  tasklet_subsys_init();
  
+/* Parse the ACPI iort data */

+acpi_iort_init();
  
  xsm_dt_init();
  
diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile

index 444b11d..e7ffd82 100644
--- a/xen/drivers/acpi/Makefile
+++ b/xen/drivers/acpi/Makefile
@@ -1,5 +1,6 @@
  subdir-y += tables
  subdir-y += utilities
+subdir-$(CONFIG_ARM) += arm
  subdir-$(CONFIG_X86) += apei
  
  obj-bin-y += tables.init.o

diff --git a/xen/drivers/acpi/arm/Makefile b/xen/drivers/acpi/arm/Makefile
new file mode 100644
index 000..7c039bb
--- /dev/null
+++ b/xen/drivers/acpi/arm/Makefile
@@ -0,0 +1 @@
+obj-y += iort.o
diff --git a/xen/drivers/acpi/arm/iort.c b/xen/drivers/acpi/arm/iort.c
index 2e368a6..7f54062 100644
--- a/xen/drivers/acpi/arm/iort.c
+++ b/xen/drivers/acpi/arm/iort.c
@@ -14,17 +14,47 @@
   * This file implements early detection/parsing of I/O mapping
   * reported to OS through firmware via I/O Remapping Table (IORT)
   * IORT document number: ARM DEN 0049A
+ *
+ * Based on Linux drivers/acpi/arm64/iort.c
+ * => commit ca78d3173cff3503bcd15723b049757f75762d15
+ *
+ * Xen modification:
+ * Sameer Goel 
+ * Copyright (C) 2017, The Linux Foundation, All rights reserved.
+ *
   */
  
-#define pr_fmt(fmt)	"ACPI: IORT: " fmt

-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Xen: Define compatibility functions */
+#define FW_BUG "[Firmware Bug]: "
+#define pr_err(fmt, ...) printk(XENLOG_ERR fmt, ## __VA_ARGS__)
+#define pr_warn(fmt, ...) printk(XENLOG_WARNING fmt, ## __VA_ARGS__)
+
+/* Alias to Xen allocation helpers */
+#define kfree xfree
+#define kmalloc(size, flags)_xmalloc(size, sizeof(void *))
+#define kzalloc(size, flags)_xzalloc(size, sizeof(void *))
+
+/* Redefine WARN macros */
+#undef WARN
+#undef WARN_ON
+#define WARN(condition, format...) ({  \
+   int __ret_warn_on = !!(condition);  \
+   if (unlikely(__ret_warn_on))\
+   printk(format); \
+   unlikely(__ret_warn_on);\
+})
+#define WARN_TAINT(cond, taint, format...) WARN(cond, format)
+#define WARN_ON(cond)  (!!cond)
  
  #define IORT_TYPE_MASK(type)	(1 << (type))

  #define IORT_MSI_TYPE (1 << ACPI_IORT_NODE_ITS_GROUP)
@@ -256,6 +286,13 @@ static acpi_status iort_match_node_callback(struct 
acpi_iort_node *node,
acpi_status status;
  
  	if (node->type == ACPI_IORT_NODE_NAMED_COMPONENT) {

+ 

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  9862926902ba035a3741afdf03da40a4d4b57a6f
baseline version:
 xen  92f0d4392e73727819c5a83fcce447515efaf2f5

Last test of basis   115645  2017-11-07 13:03:54 Z1 days
Testing same since   115676  2017-11-08 13:09:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 
  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 :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   92f0d43..9862926  9862926902ba035a3741afdf03da40a4d4b57a6f -> smoke

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

Re: [Xen-devel] Unable to create guest PV domain on OMAP5432

[Konrad Rzeszutek Wilk]

On Wed, Nov 08, 2017 at 10:47:20AM +0530, Jayadev Kumaran wrote:
> Hello all,
> 
> I'm trying to implement Xen hypervisor support on OMAP5432.I have followed
> the steps as in
> https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM
> for the initial setup. I'm able to see the domain 0 successfully up.
> 
> 
> 
> 
> 
> 
> 
> *root@omap5-evm:~# /etc/init.d/xencommons startStarting
> /usr/local/sbin/xenstored...Setting domain 0 name, domid and JSON
> config...Done setting up Dom0Starting xenconsoled...Starting QEMU as disk
> backend for dom0*
> 
> 
> 
> *root@omap5-evm:~# xl listNameID
> Mem VCPUs  State   Time(s)Domain-0
> 0   512 2 r-  11.5*

What does 'xl info' say? B/c:
..
> Expanding d4 grant table from 0 to 1 frames(XEN) memory.c:238:d0v0 Could
> not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error:

.. looks like it could not allocate memory?

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Alistair Francis]

On Tue, Nov 7, 2017 at 11:52 PM, Markus Armbruster  wrote:
> Eric Blake  writes:
>
>> On 11/07/2017 04:12 AM, Markus Armbruster wrote:
>>> Juan Quintela  writes:
>>>
 Alistair Francis  wrote:
> Replace all occurs of __FUNCTION__ except for the check in checkpatch
> with the non GCC specific __func__.
>
>>
> +++ b/audio/audio_int.h
> @@ -253,7 +253,7 @@ static inline int audio_ring_dist (int dst, int src, 
> int len)
>  #define AUDIO_STRINGIFY(n) AUDIO_STRINGIFY_(n)
>
>  #if defined _MSC_VER || defined __GNUC__
> -#define AUDIO_FUNC __FUNCTION__
> +#define AUDIO_FUNC __func__
>  #else
>  #define AUDIO_FUNC __FILE__ ":" AUDIO_STRINGIFY (__LINE__)
>  #endif

 Unrelated to this patch 
 Do we really support other compilers than msc and gcc?
>>>
>>> Let me rephrase the question: do we really support compilers that don't
>>> understand __func__?  The presence of numerous unconditional uses of
>>> __func__ in the tree means the answer is no.  Let's replace AUDIO_FUNC
>>> by plain __func__.
>>
>> Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by
>> __func__).
>
> I see.
>
> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?

I would really like to avoid that, as the conflicts will be a bit of a
mess. The way I see it there will be a lot of churn no matter what,
so we don't gain much by swapping the order around.

I have a new series ready to send today, so I'm going to send that
through as I would like at least some of these patches to make it in
2.11. After that if you think strongly the order should be changed I
can change it in the next version.

Thanks,
Alistair

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

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

Thanks Roger for your review comments. Please see below for my comments.

On 11/7/2017 5:21 AM, Roger Pau Monné wrote:

On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:

The life-cycle of a PCI device in Xen pciback is complex and is constrained
by the generic PCI locking mechanism.

- It starts with the device being bound to us, for which we do a function
   reset (done via SysFS so the PCI lock is held).
- If the device is unbound from us, we also do a function reset
   (done via SysFS so the PCI lock is held).
- If the device is un-assigned from a guest - we do a function reset
   (no PCI lock is held).

All reset operations are done on the individual PCI function level
(so bus:device:function).

The reset for an individual PCI function means device must support FLR
(PCIe or AF), PM reset on D3hot->D0 device specific reset, or a secondary
bus reset for a singleton device on a bus but FLR does not have widespread
support or it is not reliable in some cases. So, we need to provide an
alternate mechanism to users to perform a slot or bus level reset.

Currently, a slot or bus reset is not exposed in SysFS as there is no good
way of exposing a bus topology there. This is due to the complexity -
we MUST know that the different functions of a PCIe device are not in use
by other drivers, or if they are in use (say one of them is assigned to a
guest and the other is  idle) - it is still OK to reset the slot (assuming
both of them are owned by Xen pciback).

This patch does that by doing a slot or bus reset (if slot not supported)
if all of the functions of a PCIe device belong to Xen PCIback.

Due to the complexity with the PCI lock we cannot do the reset when a
device is bound ('echo $BDF > bind') or when unbound ('echo $BDF > unbind')
as the pci_[slot|bus]_reset also takes the same lock resulting in a
dead-lock.

Putting the reset function in a work-queue or thread won't work either -
as we have to do the reset function outside the 'unbind' context (it holds
the PCI lock). But once you 'unbind' a device the device is no longer under
the ownership of Xen pciback and the pci_set_drvdata has been reset, so
we cannot use a thread for this.

Instead of doing all this complex dance, we depend on the tool-stack doing
the right thing. As such, we implement the 'do_flr' SysFS attribute which
'xl' uses when a device is detached or attached from/to a guest. It
bypasses the need to worry about the PCI lock.

To not inadvertently do a bus reset that would affect devices that are in
use by other drivers (other than Xen pciback) prior to the reset, we check
that all of the devices under the bridge are owned by Xen pciback. If they
are not, we refrain from executing the bus (or slot) reset.

Signed-off-by: Govinda Tatti 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Boris Ostrovsky 
---
  Documentation/ABI/testing/sysfs-driver-pciback |  12 +++
  drivers/xen/xen-pciback/pci_stub.c | 125 +
  2 files changed, 137 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-driver-pciback 
b/Documentation/ABI/testing/sysfs-driver-pciback
index 6a733bf..ccf7dc0 100644
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
  #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
  will allow the guest to read and write to the configuration
  register 0x0E.
+
+What:   /sys/bus/pci/drivers/pciback/do_flr
+Date:   Nov 2017
+KernelVersion:  4.15
+Contact:xen-de...@lists.xenproject.org
+Description:
+An option to perform a slot or bus reset when a PCI device
+   is owned by Xen PCI backend. Writing a string of :BB:DD.F
+   will cause the pciback driver to perform a slot or bus reset
+   if the device supports it. It also checks to make sure that
+   all of the devices under the bridge are owned by Xen PCI
+   backend.
diff --git a/drivers/xen/xen-pciback/pci_stub.c 
b/drivers/xen/xen-pciback/pci_stub.c
index 6331a95..2b2c269 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,96 @@ struct pci_dev *pcistub_get_pci_dev(struct 
xen_pcibk_device *pdev,
return found_dev;
  }
  
+struct pcistub_args {

+   struct pci_dev *dev;

const?

This field will point to first device that is not owned by pcistub.



+   int dcount;

unsigned int.

OK.



+};
+
+static int pcistub_search_dev(struct pci_dev *dev, void *data)

Seems like this function would better return a boolean rather than an
int.
pcistub_search_dev() is invoked through pci_walk_bus() and it expects 
int return code.



+{
+   struct pcistub_device *psdev;
+   struct pcistub_args *arg = data;
+   bool found_dev = false;
+   unsigned long flags;
+
+   spin_lock_irqsave(&pcistub_devices_lock, flags);
+
+   

Re: [Xen-devel] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Eric Blake]

On 11/08/2017 08:51 AM, Alistair Francis wrote:

 Let me rephrase the question: do we really support compilers that don't
 understand __func__?  The presence of numerous unconditional uses of
 __func__ in the tree means the answer is no.  Let's replace AUDIO_FUNC
 by plain __func__.
>>>
>>> Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by
>>> __func__).
>>
>> I see.
>>
>> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?
> 
> I would really like to avoid that, as the conflicts will be a bit of a
> mess. The way I see it there will be a lot of churn no matter what,
> so we don't gain much by swapping the order around.
> 
> I have a new series ready to send today, so I'm going to send that
> through as I would like at least some of these patches to make it in
> 2.11. After that if you think strongly the order should be changed I
> can change it in the next version.

I think the reorder is not that hard.  Put 3/46 first (changing
AUDIO_FUNC to __func__), and then 1/46 doesn't have to touch any of the
files that used to use AUDIO_FUNC, because there is no intermediate
state using __FUNCTION__.

If I'm reading it correctly, the rebase conflict is limited to a slight
rewording of the commit message for 3/46, and one line in 1/46 to the
definition of AUDIO_FUNC (that will no longer be present).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



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

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Juergen Gross]

On 08/11/17 16:00, Govinda Tatti wrote:
> Thanks Roger for your review comments. Please see below for my comments.
> 
> On 11/7/2017 5:21 AM, Roger Pau Monné wrote:
>> On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:
>>> +out:
>>> +    if (!err)
>>> +    err = count;
>>> +
>>> +    return err;
>> What's the purpose of returning count here?
> Not sure. Will check with Konrad and address this comment.

You are telling sysfs that you have consumed all input characters.


Juergen

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

Re: [Xen-devel] [Qemu-devel] [PATCH v3 01/46] Replace all occurances of __FUNCTION__ with __func__

[Alistair Francis]

On Wed, Nov 8, 2017 at 7:00 AM, Eric Blake  wrote:
> On 11/08/2017 08:51 AM, Alistair Francis wrote:
>
> Let me rephrase the question: do we really support compilers that don't
> understand __func__?  The presence of numerous unconditional uses of
> __func__ in the tree means the answer is no.  Let's replace AUDIO_FUNC
> by plain __func__.

 Answered elsewhere in patch 3/46 (where we DO replace AUDIO_FUNC by
 __func__).
>>>
>>> I see.
>>>
>>> Put 03/46 first, so we don't have to mess with AUDIO_FUNC twice?
>>
>> I would really like to avoid that, as the conflicts will be a bit of a
>> mess. The way I see it there will be a lot of churn no matter what,
>> so we don't gain much by swapping the order around.
>>
>> I have a new series ready to send today, so I'm going to send that
>> through as I would like at least some of these patches to make it in
>> 2.11. After that if you think strongly the order should be changed I
>> can change it in the next version.
>
> I think the reorder is not that hard.  Put 3/46 first (changing
> AUDIO_FUNC to __func__), and then 1/46 doesn't have to touch any of the
> files that used to use AUDIO_FUNC, because there is no intermediate
> state using __FUNCTION__.
>
> If I'm reading it correctly, the rebase conflict is limited to a slight
> rewording of the commit message for 3/46, and one line in 1/46 to the
> definition of AUDIO_FUNC (that will no longer be present).

That's true, it didn't end up being that hard. I'm launching my tests
now, so I should be able to send the series out later today.

Hopefully some of this can make it in 2.11 :)

Thanks,
Alistair

>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
>

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

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

On 11/8/2017 9:09 AM, Juergen Gross wrote:

On 08/11/17 16:00, Govinda Tatti wrote:

Thanks Roger for your review comments. Please see below for my comments.

On 11/7/2017 5:21 AM, Roger Pau Monné wrote:

On Mon, Nov 06, 2017 at 12:48:42PM -0500, Govinda Tatti wrote:

+out:
+    if (!err)
+    err = count;
+
+    return err;

What's the purpose of returning count here?

Not sure. Will check with Konrad and address this comment.

You are telling sysfs that you have consumed all input characters.


Thanks Juergen

Cheers
GOVINDA

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

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

Thanks Jan for your review comments. Please see below for my comments.

On 11/7/2017 8:40 AM, Jan Beulich wrote:

On 06.11.17 at 18:48,  wrote:

--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -11,3 +11,15 @@ Description:
  #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
  will allow the guest to read and write to the configuration
  register 0x0E.
+
+What:   /sys/bus/pci/drivers/pciback/do_flr
+Date:   Nov 2017
+KernelVersion:  4.15
+Contact:xen-de...@lists.xenproject.org
+Description:
+An option to perform a slot or bus reset when a PCI device
+   is owned by Xen PCI backend. Writing a string of :BB:DD.F
+   will cause the pciback driver to perform a slot or bus reset
+   if the device supports it. It also checks to make sure that
+   all of the devices under the bridge are owned by Xen PCI
+   backend.

Why do you name this "do_flr" when you don't even try FLR, but
go to slot or then bus reset right away.
Yes, I agree but xen toolstack has already been modified to 
consume"do_flr" attribute. Hence, we are using the

function that matches with sysfs attribute.



+static int pcistub_reset_dev(struct pci_dev *dev)
+{
+   struct xen_pcibk_dev_data *dev_data;
+   bool slot = false, bus = false;
+
+   if (!dev)
+   return -EINVAL;
+
+   dev_dbg(&dev->dev, "[%s]\n", __func__);
+
+   if (!pci_probe_reset_slot(dev->slot)) {
+   slot = true;
+   } else if (!pci_probe_reset_bus(dev->bus)) {
+   /* We won't attempt to reset a root bridge. */
+   if (!pci_is_root_bus(dev->bus))
+   bus = true;
+   }
+
+   if (!bus && !slot)
+   return -EOPNOTSUPP;
+
+   if (!slot) {
+   struct pcistub_args arg = { .dev = NULL, .dcount = 0 };

Neither of the two initializers is really needed - just {} will do.

OK.



+   /*
+* Make sure all devices on this bus are owned by the
+* PCI backend so that we can safely reset the whole bus.
+*/
+   pci_walk_bus(dev->bus, pcistub_search_dev, &arg);
+
+   /* All devices under the bus should be part of pcistub! */
+   if (arg.dev) {
+   dev_err(&dev->dev, "%s device on the bus is not owned by 
pcistub\n",
+   pci_name(arg.dev));

I think "device" is superfluous here, while "the bus" could do with
replacing by something actually identifying the bus.

I assume you want "bus" number to be printed in above msg. If yes, will do.



+   return -EBUSY;
+   }
+
+   dev_dbg(&dev->dev, "pcistub owns %d devices on the bus\n",
+   arg.dcount);

Same here for "the bus", provided this log message is useful in the
first place.


+   }

Aren't you missing an "else" here? Aiui in the "slot" case it may
still be multiple devices/functions which are affected.
Good catch.  Our original code was performing same check, both for bus 
and slot case

but somehow I removed it during internal review based on some comment.

I will post revised patch later this week. Thanks.

Cheers
GOVINDA

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail REGR. vs. 
114507

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115657 pass 
in 115663
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115657 
pass in 115663
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail pass in 115657

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 114507
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114507
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114507
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114507
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114507
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114507
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuub0fbe46ad82982b289a44ee2495b59b0bad8a842
baseline version:
 qemuuf90ea7ba7c5ae7010ee0ce062207ae42530f57d6

Last test of basis   114507  2017-10-15 01:03:38 Z   24 days
Failing since114546  2017-10-16 12:16:28 Z   23 days   61 attempts
Testing same since   115657  2017-11-08 01:28:35 Z0 days2 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Alex Bennée 
  Alexey Kardashevskiy 
  Alexey Perevalov 
  Alistair Francis 
  Amarnath Valluri 
  Andreas Färber 
  Andrew Baumann 
  Anthoine Bourgeois 
  Anthony PERARD 
  Artyom Tarasenko 
  Bishara AbuHattoum 
  Carlo Marcelo Arenas Belón 
  Chen Hanxiao 
  Christian Borntraeger 
  Collin L. Walling 
  Cornelia Huck 
  Cornelia Huck 
  Cornelia Huck 
  Daniel Henrique Barboza 
  Daniel P. Berrange 
  David Gibson 
  David Hildenbrand 
  Dong Jia Shi 
  Dr. David Alan Gilbert 
  Eduardo Habkost 
  Eduardo Otubo 
  Emilio G. Cota 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Farhan Ali 
  Felipe Franciosi 
  Gerd Hoffmann 
  Greg K

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Olaf Hering]

On Thu, Oct 26, Olaf Hering wrote:

> > If not, then out-of-tree packages are going to have compatibility
> > problems with this change.
> Only if they use Requires=proc-xen.mount.

Any other objections to this change?

How to proceed with this?

Olaf


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

[Xen-devel] [PATCH v8 5/5] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

[Joao Martins]

This file defines an ABI shared between guest and hypervisor(s)
(KVM, Xen) and as such there should be an correspondent entry in
MAINTAINERS file. Notice that there's already a text notice at the
top of the header file, hence this commit simply enforces it more
explicitly and have both peers noticed when such changes happen.

Signed-off-by: Joao Martins 
Acked-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
Acked-by: Paolo Bonzini 
---
Changes since v4:
 * Add Paolo's Acked-by
 * Add Konrad's Reviewed-by

Changes since v1:
 * Add Juergen's Gross Acked-by.
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index af0cb69f6a3e..ff93f4a44d2e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7604,6 +7604,7 @@ S:Supported
 F: arch/x86/kvm/
 F: arch/x86/include/uapi/asm/kvm*
 F: arch/x86/include/asm/kvm*
+F: arch/x86/include/asm/pvclock-abi.h
 F: arch/x86/kernel/kvm.c
 F: arch/x86/kernel/kvmclock.c
 
@@ -14731,6 +14732,7 @@ F:  arch/x86/xen/
 F: drivers/*/xen-*front.c
 F: drivers/xen/
 F: arch/x86/include/asm/xen/
+F: arch/x86/include/asm/pvclock-abi.h
 F: include/xen/
 F: include/uapi/xen/
 F: Documentation/ABI/stable/sysfs-hypervisor-xen
-- 
2.11.0


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

[Xen-devel] [PATCH v8 0/5] x86/xen: pvclock vdso support

[Joao Martins]

Hey,

This is take 8 for vdso for Xen. PVCLOCK_TSC_STABLE_BIT can be set starting Xen
 4.8 which is required for vdso time related calls. In order to have it on, you
need to have the hypervisor clocksource be TSC e.g. with the following boot
params "clocksource=tsc tsc=stable:socket".

Series is structured as following:

Patch 1 probes for kvm guest in ptp_kvm in the event having
pvclock_pvti_cpu0_va() moved to common pvclock (on the next patch)
Patch 2 streamlines pvti page get/set in pvclock for both of its users
Patch 3,4 registers the pvti page on Xen and sets it in pvclock accordingly
Patch 5 adds a file to KVM/Xen maintainers for tracking pvclock ABI changes.

All patches appear to be Acked by its respective maintainers.

The difference to v7 is adding the Acks on patches 1 and 2 plus the adjustment
from Thomas to rename the getter function. (Changelog in individual patches)

Thanks,
Joao

Joao Martins (5):
  ptp_kvm: probe for kvm guest availability
  x86/pvclock: add setter for pvclock_pvti_cpu0_va
  x86/xen/time: set pvclock flags on xen_time_init()
  x86/xen/time: setup vcpu 0 time info page
  MAINTAINERS: xen, kvm: track pvclock-abi.h changes

 MAINTAINERS|  2 +
 arch/x86/entry/vdso/vma.c  |  2 +-
 arch/x86/include/asm/pvclock.h | 19 +
 arch/x86/kernel/kvmclock.c |  7 +--
 arch/x86/kernel/pvclock.c  | 14 ++
 arch/x86/xen/suspend.c |  4 ++
 arch/x86/xen/time.c| 97 ++
 arch/x86/xen/xen-ops.h |  2 +
 drivers/ptp/ptp_kvm.c  |  5 ++-
 include/xen/interface/vcpu.h   | 42 ++
 10 files changed, 177 insertions(+), 17 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH v8 3/5] x86/xen/time: set pvclock flags on xen_time_init()

[Joao Martins]

Specifically check for PVCLOCK_TSC_STABLE_BIT and if this bit is set,
then set it too on pvclock flags. This allows Xen clocksource to use it
and thus speeding up xen_clocksource_read() callers (i.e. sched_clock())

Signed-off-by: Joao Martins 
Reviewed-by: Boris Ostrovsky 
---
Changes since v5:
 * Add Boris RoB

New in v5
---
 arch/x86/xen/time.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index 1ecb05db3632..fc0148d3a70d 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -372,6 +372,7 @@ static const struct pv_time_ops xen_time_ops __initconst = {
 
 static void __init xen_time_init(void)
 {
+   struct pvclock_vcpu_time_info *pvti;
int cpu = smp_processor_id();
struct timespec tp;
 
@@ -395,6 +396,14 @@ static void __init xen_time_init(void)
 
setup_force_cpu_cap(X86_FEATURE_TSC);
 
+   /*
+* We check ahead on the primary time info if this
+* bit is supported hence speeding up Xen clocksource.
+*/
+   pvti = &__this_cpu_read(xen_vcpu)->time;
+   if (pvti->flags & PVCLOCK_TSC_STABLE_BIT)
+   pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT);
+
xen_setup_runstate_info(cpu);
xen_setup_timer(cpu);
xen_setup_cpu_clockevents();
-- 
2.11.0


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

[Xen-devel] [PATCH v8 1/5] ptp_kvm: probe for kvm guest availability

[Joao Martins]

In the event of moving pvclock_pvti_cpu0_va() definition to common
pvclock code, this function would return a value on non KVM guests.
Later on this would fail with a GPF on ptp_kvm_init when running on a
Xen guest. Therefore, ptp_kvm_init() should check whether it is running
in a KVM guest.

Signed-off-by: Joao Martins 
Acked-by: Radim Krčmář 
---
Changes since v7:
 * Add Radim's Acked-by
---
 drivers/ptp/ptp_kvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ptp/ptp_kvm.c b/drivers/ptp/ptp_kvm.c
index 2b1b212c219e..e04d7b2ecb3a 100644
--- a/drivers/ptp/ptp_kvm.c
+++ b/drivers/ptp/ptp_kvm.c
@@ -178,6 +178,9 @@ static int __init ptp_kvm_init(void)
 {
long ret;
 
+   if (!kvm_para_available())
+   return -ENODEV;
+
clock_pair_gpa = slow_virt_to_phys(&clock_pair);
hv_clock = pvclock_pvti_cpu0_va();
 
-- 
2.11.0


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

[Xen-devel] [PATCH v8 2/5] x86/pvclock: add setter for pvclock_pvti_cpu0_va

[Joao Martins]

Right now there is only a pvclock_pvti_cpu0_va() which is defined
on kvmclock since:

commit dac16fba6fc5
("x86/vdso: Get pvclock data from the vvar VMA instead of the fixmap")

The only user of this interface so far is kvm. This commit adds a
setter function for the pvti page and moves pvclock_pvti_cpu0_va
to pvclock, which is a more generic place to have it; and would
allow other PV clocksources to use it, such as Xen.

While moving pvclock_pvti_cpu0_va into pvclock, rename also this
function to pvclock_get_pvti_cpu0_va (including its call sites)
to be symmetric with the setter (pvclock_set_pvti_cpu0_va).

Signed-off-by: Joao Martins 
Acked-by: Andy Lutomirski 
Acked-by: Paolo Bonzini 
Acked-by: Thomas Gleixner 
---
Changes since v7:
 * Add Paolo Acked-by
 (Comments from Thomas Gleixner)
 * Rename getter to pvclock_get_pvti_cpu0_va
 and fixup its callsites (vdso/vma.c and ptp/ptp_kvm.c)
 * Add Thomas Acked-by

Changes since v1:
 * Rebased: the only conflict was that I had move the export
 pvclock_pvti_cpu0_va() symbol as it is used by kvm PTP driver.
 * Do not initialize pvti_cpu0_va to NULL (checkpatch error)
 ( Comments from Andy Lutomirski )
 * Removed asm/pvclock.h 'pvclock_set_pvti_cpu0_va' definition
 for non !PARAVIRT_CLOCK to better track screwed Kconfig stuff.
 * Add his Acked-by (provided the previous adjustment was made)

Changes since RFC:
 (Comments from Andy Lutomirski)
 * Add __init to pvclock_set_pvti_cpu0_va
 * Add WARN_ON(vclock_was_used(VCLOCK_PVCLOCK)) to
 pvclock_set_pvti_cpu0_va
---
 arch/x86/entry/vdso/vma.c  |  2 +-
 arch/x86/include/asm/pvclock.h | 19 ++-
 arch/x86/kernel/kvmclock.c |  7 +--
 arch/x86/kernel/pvclock.c  | 14 ++
 drivers/ptp/ptp_kvm.c  |  2 +-
 5 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 1911310959f8..a77fd3c8d824 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -112,7 +112,7 @@ static int vvar_fault(const struct vm_special_mapping *sm,
__pa_symbol(&__vvar_page) >> PAGE_SHIFT);
} else if (sym_offset == image->sym_pvclock_page) {
struct pvclock_vsyscall_time_info *pvti =
-   pvclock_pvti_cpu0_va();
+   pvclock_get_pvti_cpu0_va();
if (pvti && vclock_was_used(VCLOCK_PVCLOCK)) {
ret = vm_insert_pfn(
vma,
diff --git a/arch/x86/include/asm/pvclock.h b/arch/x86/include/asm/pvclock.h
index 448cfe1b48cf..55325f934d71 100644
--- a/arch/x86/include/asm/pvclock.h
+++ b/arch/x86/include/asm/pvclock.h
@@ -4,15 +4,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_KVM_GUEST
-extern struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void);
-#else
-static inline struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return NULL;
-}
-#endif
-
 /* some helper functions for xen and kvm pv clock sources */
 u64 pvclock_clocksource_read(struct pvclock_vcpu_time_info *src);
 u8 pvclock_read_flags(struct pvclock_vcpu_time_info *src);
@@ -101,4 +92,14 @@ struct pvclock_vsyscall_time_info {
 
 #define PVTI_SIZE sizeof(struct pvclock_vsyscall_time_info)
 
+#ifdef CONFIG_PARAVIRT_CLOCK
+void pvclock_set_pvti_cpu0_va(struct pvclock_vsyscall_time_info *pvti);
+struct pvclock_vsyscall_time_info *pvclock_get_pvti_cpu0_va(void);
+#else
+static inline struct pvclock_vsyscall_time_info *pvclock_get_pvti_cpu0_va(void)
+{
+   return NULL;
+}
+#endif
+
 #endif /* _ASM_X86_PVCLOCK_H */
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d88967659098..538738047ff5 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -47,12 +47,6 @@ early_param("no-kvmclock", parse_no_kvmclock);
 static struct pvclock_vsyscall_time_info *hv_clock;
 static struct pvclock_wall_clock wall_clock;
 
-struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
-{
-   return hv_clock;
-}
-EXPORT_SYMBOL_GPL(pvclock_pvti_cpu0_va);
-
 /*
  * The wallclock is the time of day when we booted. Since then, some time may
  * have elapsed since the hypervisor wrote the data. So we try to account for
@@ -334,6 +328,7 @@ int __init kvm_setup_vsyscall_timeinfo(void)
return 1;
}
 
+   pvclock_set_pvti_cpu0_va(hv_clock);
put_cpu();
 
kvm_clock.archdata.vclock_mode = VCLOCK_PVCLOCK;
diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 5c3f6d6a5078..761f6af6efa5 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -25,8 +25,10 @@
 
 #include 
 #include 
+#include 
 
 static u8 valid_flags __read_mostly = 0;
+static struct pvclock_vsyscall_time_info *pvti_cpu0_va __read_mostly;
 
 void pvclock_set_flags(u8 flags)
 {
@@ -144,3 +146,15 @@ void pvclock_read_wallclock(struct pvclock_wall_clock 
*wall_clock,
 
set_normalized_timespec(ts, now.tv_sec, now.tv_nsec);
 }

[Xen-devel] [PATCH v8 4/5] x86/xen/time: setup vcpu 0 time info page

[Joao Martins]

In order to support pvclock vdso on xen we need to setup the time
info page for vcpu 0 and register the page with Xen using the
VCPUOP_register_vcpu_time_memory_area hypercall. This hypercall
will also forcefully update the pvti which will set some of the
necessary flags for vdso. Afterwards we check if it supports the
PVCLOCK_TSC_STABLE_BIT flag which is mandatory for having
vdso/vsyscall support. And if so, it will set the cpu 0 pvti that
will be later on used when mapping the vdso image.

The xen headers are also updated to include the new hypercall for
registering the secondary vcpu_time_info struct.

Signed-off-by: Joao Martins 
Reviewed-by: Juergen Gross 
Reviewed-by: Boris Ostrovsky 
---
Changes since v5:
 * Move xen_setup_vsyscall_time_info within the PVCLOCK_TSC_STABLE_BIT
 clause added in predecessor patch.

Changes since v4:
 * Remove pvclock_set_flags since predecessor patch will set in
 xen_time_init. Consequently pvti local variable is not so useful
 and doesn't make things more clear - therefore remove it.
 * Adjust comment on xen_setup_vsyscall_time_info()
 * Add Juergen's Reviewed-by (Retained as there wasn't functional
 changes)

Changes since v3:
 (Comments from Juergen)
 * Remove _t added suffix from *GUEST_HANDLE* when sync vcpu.h
 with the latest

Changes since v2:
 (Comments from Juergen)
 * Omit the blank after the cast on all 3 occurrences.
 * Change last VCLOCK_PVCLOCK message to be more descriptive
 * Sync the complete vcpu.h header instead of just adding the
 needed one. (IOW adding VCPUOP_get_physid)

Changes since v1:
 * Check flags ahead to see if the  primary clock can use
 PVCLOCK_TSC_STABLE_BIT even if secondary registration fails.
 (Comments from Boris)
 * Remove addr, addr variables;
 * Change first pr_debug to pr_warn;
 * Change last pr_debug to pr_notice;
 * Add routine to solely register secondary time info.
 * Move xen_clock to outside xen_setup_vsyscall_time_info to allow
 restore path to simply re-register secondary time info. Let us
 handle the restore path more gracefully without re-allocating a
 page.
 * Removed cpu argument from xen_setup_vsyscall_time_info()
 * Adjustment failed registration error messages/loglevel to be the same
 * Also teardown secondary time info on suspend

Changes since RFC:
 (Comments from Boris and David)
 * Remove Kconfig option
 * Use get_zeroed_page/free/page
 * Remove the hypercall availability check
 * Unregister pvti with arg.addr.v = NULL if stable bit isn't supported.
 (New)
 * Set secondary copy on restore such that it works on migration.
 * Drop global xen_clock variable and stash it locally on
 xen_setup_vsyscall_time_info.
 * WARN_ON(ret) if we fail to unregister the pvti.
---
 arch/x86/xen/suspend.c   |  4 ++
 arch/x86/xen/time.c  | 90 +++-
 arch/x86/xen/xen-ops.h   |  2 +
 include/xen/interface/vcpu.h | 42 +
 4 files changed, 137 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/suspend.c b/arch/x86/xen/suspend.c
index d6b1680693a9..800ed36ecfba 100644
--- a/arch/x86/xen/suspend.c
+++ b/arch/x86/xen/suspend.c
@@ -16,6 +16,8 @@
 
 void xen_arch_pre_suspend(void)
 {
+   xen_save_time_memory_area();
+
if (xen_pv_domain())
xen_pv_pre_suspend();
 }
@@ -26,6 +28,8 @@ void xen_arch_post_suspend(int cancelled)
xen_pv_post_suspend(cancelled);
else
xen_hvm_post_suspend(cancelled);
+
+   xen_restore_time_memory_area();
 }
 
 static void xen_vcpu_notify_restore(void *data)
diff --git a/arch/x86/xen/time.c b/arch/x86/xen/time.c
index fc0148d3a70d..dec966fbe888 100644
--- a/arch/x86/xen/time.c
+++ b/arch/x86/xen/time.c
@@ -370,6 +370,92 @@ static const struct pv_time_ops xen_time_ops __initconst = 
{
.steal_clock = xen_steal_clock,
 };
 
+static struct pvclock_vsyscall_time_info *xen_clock __read_mostly;
+
+void xen_save_time_memory_area(void)
+{
+   struct vcpu_register_time_memory_area t;
+   int ret;
+
+   if (!xen_clock)
+   return;
+
+   t.addr.v = NULL;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+   if (ret != 0)
+   pr_notice("Cannot save secondary vcpu_time_info (err %d)",
+ ret);
+   else
+   clear_page(xen_clock);
+}
+
+void xen_restore_time_memory_area(void)
+{
+   struct vcpu_register_time_memory_area t;
+   int ret;
+
+   if (!xen_clock)
+   return;
+
+   t.addr.v = &xen_clock->pvti;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, &t);
+
+   /*
+* We don't disable VCLOCK_PVCLOCK entirely if it fails to register the
+* secondary time info with Xen or if we migrated to a host without the
+* necessary flags. On both of these cases what happens is either
+* process seeing a zeroed out pvti or seeing no PVCLOCK_TSC_STABLE_BIT
+* bit set. Userspace ch

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Wei Liu]

On Wed, Nov 08, 2017 at 05:24:14PM +0100, Olaf Hering wrote:
> On Thu, Oct 26, Olaf Hering wrote:
> 
> > > If not, then out-of-tree packages are going to have compatibility
> > > problems with this change.
> > Only if they use Requires=proc-xen.mount.
> 
> Any other objections to this change?
> 
> How to proceed with this?

Regardless of the decision whether we should backport this to older
branch, I think we should accept this patch going forward to avoid
breakage.

But is there really no way to ask nicely to see if systemd would accept
a change in behaviour? That is, to make proc-xen.mount (or any attempt
to mount API fs) a nop when xenfs is added to API file system.

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

Re: [Xen-devel] [PATCH] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Pasi Kärkkäinen]

Hi,

On Wed, Nov 08, 2017 at 09:44:48AM -0600, Govinda Tatti wrote:
> Thanks Jan for your review comments. Please see below for my comments.
> 
> On 11/7/2017 8:40 AM, Jan Beulich wrote:
> On 06.11.17 at 18:48,  wrote:
> >>--- a/Documentation/ABI/testing/sysfs-driver-pciback
> >>+++ b/Documentation/ABI/testing/sysfs-driver-pciback
> >>@@ -11,3 +11,15 @@ Description:
> >>  #echo 00:19.0-E0:2:FF > 
> >> /sys/bus/pci/drivers/pciback/quirks
> >>  will allow the guest to read and write to the 
> >> configuration
> >>  register 0x0E.
> >>+
> >>+What:   /sys/bus/pci/drivers/pciback/do_flr
> >>+Date:   Nov 2017
> >>+KernelVersion:  4.15
> >>+Contact:xen-de...@lists.xenproject.org
> >>+Description:
> >>+An option to perform a slot or bus reset when a PCI device
> >>+   is owned by Xen PCI backend. Writing a string of :BB:DD.F
> >>+   will cause the pciback driver to perform a slot or bus reset
> >>+   if the device supports it. It also checks to make sure that
> >>+   all of the devices under the bridge are owned by Xen PCI
> >>+   backend.
> >Why do you name this "do_flr" when you don't even try FLR, but
> >go to slot or then bus reset right away.
> Yes, I agree but xen toolstack has already been modified to consume"do_flr"
> attribute. Hence, we are using the
> function that matches with sysfs attribute.
>

Hmm.. I remember some discussion from ages ago related to this.

Back then it was suggested to "emulate" the flr capability (by doing slot or 
bus reset) for devices which don't have *native* flr available? So is this 
patch perhaps related to that?

If the PCI device in question has native flr capability, then native flr is 
used, right ? 
I guess I should read the full patch.. 

-- Pasi


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

Re: [Xen-devel] [PATCH v1] tools/hotplug: convert proc-xen.mount to proc-xen.service

[Olaf Hering]

On Wed, Nov 08, Wei Liu wrote:

> But is there really no way to ask nicely to see if systemd would accept
> a change in behaviour? That is, to make proc-xen.mount (or any attempt
> to mount API fs) a nop when xenfs is added to API file system.

I have considered that as well. If the failing unit is "proc-xen.mount"
and /proc/xen exists, just ignore the error. I will check if and how
that can be done.


Olaf


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

Re: [Xen-devel] [Qemu-devel] [PATCH v3] xen-disk: use an IOThread per instance

[Stefan Hajnoczi]

On Tue, Nov 07, 2017 at 05:46:53AM -0500, Paul Durrant wrote:
> This patch allocates an IOThread object for each xen_disk instance and
> sets the AIO context appropriately on connect. This allows processing
> of I/O to proceed in parallel.
> 
> The patch also adds tracepoints into xen_disk to make it possible to
> follow the state transtions of an instance in the log.

virtio-blk and virtio-scsi allow the user to specify an IOThread object.
This allows users to configure the device<->IOThread mapping any way
they like (e.g. 1:1, M:N).  Are you sure you want to hard-code the
IOThread mapping?


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

Re: [Xen-devel] [Qemu-devel] [PATCH v3] xen-disk: use an IOThread per instance

[Daniel P. Berrange]

On Wed, Nov 08, 2017 at 05:42:27PM +, Stefan Hajnoczi wrote:
> On Tue, Nov 07, 2017 at 05:46:53AM -0500, Paul Durrant wrote:
> > This patch allocates an IOThread object for each xen_disk instance and
> > sets the AIO context appropriately on connect. This allows processing
> > of I/O to proceed in parallel.
> > 
> > The patch also adds tracepoints into xen_disk to make it possible to
> > follow the state transtions of an instance in the log.
> 
> virtio-blk and virtio-scsi allow the user to specify an IOThread object.
> This allows users to configure the device<->IOThread mapping any way
> they like (e.g. 1:1, M:N).  Are you sure you want to hard-code the
> IOThread mapping?

I certainly think it'd be better for mgmt apps if all disks had the same
approach to IOThread mapping.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

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

[Xen-devel] [PATCH v2] x86/hvm: do not register hpet mmio during s3 cycle

[Eric Chanudet]

Do it once at domain creation (hpet_init).

Sleep -> Resume cycles will end up crashing an HVM guest with hpet as
the sequence during resume takes the path:
-> hvm_s3_suspend
  -> hpet_reset
-> hpet_deinit
-> hpet_init
  -> register_mmio_handler
-> hvm_next_io_handler

register_mmio_handler will use a new io handler each time, until
eventually it reaches NR_IO_HANDLERS, then hvm_next_io_handler calls
domain_crash.

Signed-off-by: Eric Chanudet 

---
v2:
  * make hpet_reinit static inline (one call site in this file)
  * remove single use local variable.
---
 xen/arch/x86/hvm/hpet.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index 3ea895a0fb..d8c61ca155 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -635,14 +635,10 @@ static int hpet_load(struct domain *d, 
hvm_domain_context_t *h)
 
 HVM_REGISTER_SAVE_RESTORE(HPET, hpet_save, hpet_load, 1, HVMSR_PER_DOM);
 
-void hpet_init(struct domain *d)
+static void hpet_set(HPETState *h)
 {
-HPETState *h = domain_vhpet(d);
 int i;
 
-if ( !has_vhpet(d) )
-return;
-
 memset(h, 0, sizeof(HPETState));
 
 rwlock_init(&h->lock);
@@ -668,11 +664,26 @@ void hpet_init(struct domain *d)
 h->hpet.comparator64[i] = ~0ULL;
 h->pt[i].source = PTSRC_isa;
 }
+}
 
+void hpet_init(struct domain *d)
+{
+if ( !has_vhpet(d) )
+return;
+
+hpet_set(domain_vhpet(d));
 register_mmio_handler(d, &hpet_mmio_ops);
 d->arch.hvm_domain.params[HVM_PARAM_HPET_ENABLED] = 1;
 }
 
+static inline void hpet_reinit(struct domain *d)
+{
+if ( !has_vhpet(d) )
+return;
+
+hpet_set(domain_vhpet(d));
+}
+
 void hpet_deinit(struct domain *d)
 {
 int i;
@@ -698,7 +709,7 @@ void hpet_deinit(struct domain *d)
 void hpet_reset(struct domain *d)
 {
 hpet_deinit(d);
-hpet_init(d);
+hpet_reinit(d);
 }
 
 /*
-- 
2.14.2

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

[Xen-devel] [PATCH] x86/pvh: Do not add DSDT and FACS to PVH dom0 XSDT

[Boris Ostrovsky]

These tables are pointed to from FADT. Adding them will
result in duplicate entries in the guest's tables.

Signed-off-by: Boris Ostrovsky 
---
 xen/arch/x86/hvm/dom0_build.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
index a67071c..c878bba 100644
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -818,6 +818,19 @@ static bool __init pvh_acpi_table_allowed(const char *sig)
 return true;
 }
 
+static bool __init pvh_acpi_table_in_xsdt(const char *sig)
+{
+/*
+ * DSDT and FACS are pointed to from FADT and thus don't belong
+ * in XSDT.
+ */
+if ( !strncmp(sig, ACPI_SIG_DSDT, ACPI_NAME_SIZE) ||
+ !strncmp(sig, ACPI_SIG_FACS, ACPI_NAME_SIZE) )
+return false;
+
+return true;
+}
+
 static int __init pvh_setup_acpi_xsdt(struct domain *d, paddr_t madt_addr,
   paddr_t *addr)
 {
@@ -841,7 +854,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 {
 const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
 
-if ( pvh_acpi_table_allowed(sig) )
+if ( pvh_acpi_table_allowed(sig) && pvh_acpi_table_in_xsdt(sig) )
 num_tables++;
 }
 
@@ -888,7 +901,7 @@ static int __init pvh_setup_acpi_xsdt(struct domain *d, 
paddr_t madt_addr,
 {
 const char *sig = acpi_gbl_root_table_list.tables[i].signature.ascii;
 
-if ( pvh_acpi_table_allowed(sig) )
+if ( pvh_acpi_table_allowed(sig) && pvh_acpi_table_in_xsdt(sig) )
 xsdt->table_offset_entry[j++] =
 acpi_gbl_root_table_list.tables[i].address;
 }
-- 
1.8.3.1


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

[Xen-devel] Failed to build qemu-xen on Arch Linux

[Petre Ovidiu PIRCALABU]

Hi,

I have encountered the following error while building xen ( staging  -  
9862926902ba035a3741afdf03da40a4d4b57a6f) :

  AR  libqemuutil.a
/home/pepi/work/xen/tools/qemu-xen-dir/ui/gtk.c: In function ‘gd_menu_copy’:
/home/pepi/work/xen/tools/qemu-xen-dir/ui/gtk.c:1705:5: error: 
‘vte_terminal_copy_clipboard’ is deprecated [-Werror=deprecated-declarations]
 vte_terminal_copy_clipboard(VTE_TERMINAL(vc->vte.terminal));
 ^~~
In file included from /usr/include/vte-2.91/vte/vte.h:35:0,
 from /home/pepi/work/xen/tools/qemu-xen-dir/ui/gtk.c:47:
/usr/include/vte-2.91/vte/vtedeprecated.h:94:6: note: declared here
 void vte_terminal_copy_clipboard(VteTerminal *terminal) _VTE_GNUC_NONNULL(1);
  ^~~
  AR  libqemustub.a

It looks like problem was fixed in this patch:
https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg02232.html

Can it be cherry-picked to qemu-xen?

Many thanks,
Petre


This email was scanned by Bitdefender

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

[Xen-devel] [linux-4.9 test] 115671: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 115613

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115566
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeatfail  like 115582
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeatfail  like 115597
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115613
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115613
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115613
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115613
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115613
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux5caae9d1419914177994363218616b869659e871
baseline version:
 linux06b639e5a1a665ba6c959398ea0e6171c162028b

Last test of basis   115613  2017-11-06 11:54:23 Z2 days
Testing same since   115671  2017-11-08 09:38:13 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aditya Pandit 
  Alex Deucher 
  Alexander Boyko 
  Alexander Usyskin 
  Andrew Morton 
  Andy Shevchenko 
  Arend van Spriel 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Arvind Yadav 
  Ashish Samant 
  Ashok Ra

Re: [Xen-devel] [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

[Boris Ostrovsky]

On 10/31/2017 09:46 PM, Dongli Zhang wrote:
> After guest live migration on xen, steal time in /proc/stat
> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
> xen_steal_lock() might be less than this_rq()->prev_steal_time which is
> derived from previous return value of xen_steal_clock().
>
> For instance, steal time of each vcpu is 335 before live migration.
>
> cpu  198 0 368 200064 1962 0 0 1340 0 0
> cpu0 38 0 81 50063 492 0 0 335 0 0
> cpu1 65 0 97 49763 634 0 0 335 0 0
> cpu2 38 0 81 50098 462 0 0 335 0 0
> cpu3 56 0 107 50138 374 0 0 335 0 0
>
> After live migration, steal time is reduced to 312.
>
> cpu  200 0 370 200330 1971 0 0 1248 0 0
> cpu0 38 0 82 50123 500 0 0 312 0 0
> cpu1 65 0 97 49832 634 0 0 312 0 0
> cpu2 39 0 82 50167 462 0 0 312 0 0
> cpu3 56 0 107 50207 374 0 0 312 0 0
>
> Since runstate times are cumulative and cleared during xen live migration
> by xen hypervisor, the idea of this patch is to accumulate runstate times
> to global percpu variables before live migration suspend. Once guest VM is
> resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
> runstate times and previously accumulated times stored in global percpu
> variables. Comments before the call of HYPERVISOR_suspend() has been
> removed as it is inaccurate. The call can return an error code (e.g.,
> possibly -EPERM in the future).
>
> Similar and more severe issue would impact prior linux 4.8-4.10 as
> discussed by Michael Las at
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
> which would overflow steal time and lead to 100% st usage in top command
> for linux 4.8-4.10. A backport of this patch would fix that issue.
>
> References: 
> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
> Signed-off-by: Dongli Zhang 

Applied to for-linus-4.15.

-boris

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

Re: [Xen-devel] [PATCH] xen: xenbus_probe_frontend: mark expected switch fall-throughs

[Boris Ostrovsky]

On 11/03/2017 04:03 AM, Juergen Gross wrote:
> On 02/11/17 19:41, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Addresses-Coverity-ID: 146562
>> Addresses-Coverity-ID: 146563
>> Signed-off-by: Gustavo A. R. Silva 
> Reviewed-by: Juergen Gross 


Applied to for-linus-4.15.

-boris

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

Re: [Xen-devel] [PATCH] xen/pvcalls-front: mark expected switch fall-through

[Boris Ostrovsky]

On 11/03/2017 04:04 AM, Juergen Gross wrote:
> On 02/11/17 19:51, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>>
>> Notice that in this particular case I placed the "fall through" comment
>> on its own line, which is what GCC is expecting to find.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> Reviewed-by: Juergen Gross 


Applied to for-linus-4.15.

-boris

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

Re: [Xen-devel] [PATCH] xen/pvcalls: fix unsigned less than zero error check

[Boris Ostrovsky]

On 11/03/2017 05:01 AM, Juergen Gross wrote:
> On 03/11/17 09:42, Colin King wrote:
>> From: Colin Ian King 
>>
>> The check on bedata->ref is never true because ref is an unsigned
>> integer. Fix this by assigning signed int ret to the return of the
>> call to gnttab_claim_grant_reference so the -ve return can be checked.
>>
>> Detected by CoverityScan, CID#1460358 ("Unsigned compared against 0")
>>
>> Fixes: 219681909913 ("xen/pvcalls: connect to the backend")
>> Signed-off-by: Colin Ian King 
> Reviewed-by: Juergen Gross 


Applied to for-linus-4.15.

-boris

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

Re: [Xen-devel] [PATCH] xen/pvcalls: remove redundant check for irq >= 0

[Boris Ostrovsky]

On 11/03/2017 06:01 AM, Juergen Gross wrote:
> On 03/11/17 10:20, Colin King wrote:
>> From: Colin Ian King 
>>
>> This is a moot point, but irq is always less than zero at the label
>> out_error, so the check for irq >= 0 is redundant and can be removed.
>>
>> Detected by CoverityScan, CID#1460371 ("Logically dead code")
>>
>> Fixes: cb1c7d9bbc87 ("xen/pvcalls: implement connect command")
>> Signed-off-by: Colin Ian King 
> Reviewed-by: Juergen Gross 


Applied to for-linus-4.15.

-boris

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

Re: [Xen-devel] [PATCH v4] xen: support priv-mapping in an HVM tools domain

[Boris Ostrovsky]

On 11/03/2017 04:51 PM, Boris Ostrovsky wrote:
> On 11/03/2017 01:04 PM, Paul Durrant wrote:
>> If the domain has XENFEAT_auto_translated_physmap then use of the PV-
>> specific HYPERVISOR_mmu_update hypercall is clearly incorrect.
>>
>> This patch adds checks in xen_remap_domain_gfn_array() and
>> xen_unmap_domain_gfn_array() which call through to the approprate
>> xlate_mmu function if the feature is present. A check is also added
>> to xen_remap_domain_gfn_range() to fail with -EOPNOTSUPP since this
>> should not be used in an HVM tools domain.
>>
>> Signed-off-by: Paul Durrant 
> Reviewed-by: Boris Ostrovsky 
>


Applied to for-linus-4.15.

-boris


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

Re: [Xen-devel] [PATCH v2 0/5] xen: grant table interface v2 support

[Boris Ostrovsky]

On 11/06/2017 03:46 PM, Boris Ostrovsky wrote:
> On 11/02/2017 05:19 AM, Juergen Gross wrote:
>> In order to support Linux to run as a pv guest on machines with huge
>> memory (>16TB) or as a hvm guest with more than 16TB of memory the
>> kernel has to support grant table interface v2, as v1 is limited to
>> 32 bit frame numbers.
>>
>> This series re-adds that support (it has been removed in 2015) and
>> restricts usage of v2 to the features of v1 in order to support
>> migration to hosts which only support v1.
>>
>> V2 is selected only in the following cases:
>> - the user has specified v2 via module parameter
>> - in a pv guest if the maximum possible memory address of the host is
>>   above 16TB (memory hotplug taken into account)
>> - in a hvm guest if the maximum guest memory address is above 16TB
>>   (again with memory hotplug taken into account)
>>
>> Changes in V2:
>> - patch 2: remove update_trans_entry() from gnttab_ops (Boris Ostrovsky)
>> - added new patch 4
>> - patch 5: use cpuid on pv and max_possible_pfn on hvm for version select
>>
>> Juergen Gross (5):
>>   xen: re-introduce support for grant v2 interface
>>   xen: limit grant v2 interface to the v1 functionality
>>   xen: add grant interface version dependent constants to gnttab_ops
>>   xen: update arch/x86/include/asm/xen/cpuid.h
>>   xen: select grant interface version
>>
>>  arch/arm/xen/grant-table.c   |   9 +-
>>  arch/x86/include/asm/xen/cpuid.h |  42 +--
>>  arch/x86/xen/grant-table.c   |  60 +-
>>  drivers/xen/grant-table.c| 244 
>> +++
>>  include/xen/grant_table.h|   5 +-
>>  5 files changed, 318 insertions(+), 42 deletions(-)
>>
>
> Reviewed-by: Boris Ostrovsky 


Applied to for-linus-4.15.

-boris

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