[Xen-devel] [PATCH] x86/mm: fix a potential race condition in map_pages_to_xen().

[Yu Zhang]

In map_pages_to_xen(), a L2 page table entry may be reset to point to
a superpage, and its corresponding L1 page table need be freed in such
scenario, when these L1 page table entries are mapping to consecutive
page frames and having the same mapping flags.

However, variable `pl1e` is not protected by the lock before L1 page table
is enumerated. A race condition may happen if this code path is invoked
simultaneously on different CPUs.

For example, `pl1e` value on CPU0 may hold an obsolete value, pointing
to a page which has just been freed on CPU1. Besides, before this page
is reused, it will still be holding the old PTEs, referencing consecutive
page frames. Consequently the `free_xen_pagetable(l2e_to_l1e(ol2e))` will
be triggered on CPU0, resulting the unexpected free of a normal page.

Protecting the `pl1e` with the lock will fix this race condition.

Signed-off-by: Min He 
Signed-off-by: Yi Zhang 
Signed-off-by: Yu Zhang 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a20fdca..9c9afa1 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4844,9 +4844,10 @@ int map_pages_to_xen(
 {
 unsigned long base_mfn;
 
-pl1e = l2e_to_l1e(*pl2e);
 if ( locking )
 spin_lock(_pgdir_lock);
+
+pl1e = l2e_to_l1e(*pl2e);
 base_mfn = l1e_get_pfn(*pl1e) & ~(L1_PAGETABLE_ENTRIES - 1);
 for ( i = 0; i < L1_PAGETABLE_ENTRIES; i++, pl1e++ )
 if ( (l1e_get_pfn(*pl1e) != (base_mfn + i)) ||
-- 
2.5.0


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

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

[osstest service owner]

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

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 115684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 115657 
pass in 115684
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 115663 
pass in 115657
 test-armhf-armhf-xl-cubietruck  6 xen-install  fail pass in 115663
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115663

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-xl-cubietruck 13 migrate-support-check fail in 115663 never 
pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail in 115663 
never pass
 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-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   25 days
Failing since114546  2017-10-16 12:16:28 Z   23 days   62 attempts
Testing same since   115657  2017-11-08 01:28:35 Z1 days3 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 

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

[Jayadev Kumaran]

Hello Konrad,

Apologies for the incomplete mail. Adding to the previous reply;

>> not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error:

> looks like it could not allocate memory?

In my configuration file, i had used "memory=1024" . However if I use any
value <=512 , the above error log is not seen. However the rest of the logs
appear and it is still unable to add disk devices.

Regards

On Thu, Nov 9, 2017 at 12:09 PM, Jayadev Kumaran 
wrote:

> Hello Konrad,
>
> >> What does 'xl info' say? B/c:
>
> xl info gives the below output
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *root@omap5-evm:~# xl infohost   :
> omap5-evmrelease: 3.15.0-dirtyversion: #18
> SMP Fri Nov 3 14:33:50 IST 2017machine:
> armv7lnr_cpus: 2max_cpu_id :
> 1nr_nodes   : 1cores_per_socket   : 1threads_per_core
> : 1cpu_mhz: 6hw_caps:
> :::::::virt_caps
> :total_memory   : 2032free_memory:
> 1439sharing_freed_memory   : 0sharing_used_memory:
> 0outstanding_claims : 0free_cpus  : 0xen_major
> : 4xen_minor  : 10xen_extra  :
> .0-rcxen_version: 4.10.0-rcxen_caps   :
> xen-3.0-armv7l xen_scheduler  : creditxen_pagesize   :
> 4096platform_params: virt_start=0x20xen_changeset  :
> Mon Oct 16 15:14:16 2017 +0100 git:24fb44e-dirtyxen_commandline:
> sync_console console=dtuart dtuart=serial2cc_compiler:
> arm-linux-gnueabihf-gcc (crosstool-NG
> linaro-1.13.1-4.7-2013.03cc_compile_by  :
> ritikacc_compile_domain  : cc_compile_date: Fri Oct 27 11:39:32
> IST 2017build_id   :
> ed71e48dc494388691dac13664932a8f5ed3ee45xend_config_format : 4*
>  >> not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error:
>
>  > looks like it could not allocate memory?
>
> On Wed, Nov 8, 2017 at 8:22 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
>
>> 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 listName
>> ID
>> > 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] Unable to create guest PV domain on OMAP5432

[Jayadev Kumaran]

Hello Konrad,

>> What does 'xl info' say? B/c:

xl info gives the below output




































*root@omap5-evm:~# xl infohost   :
omap5-evmrelease: 3.15.0-dirtyversion: #18
SMP Fri Nov 3 14:33:50 IST 2017machine:
armv7lnr_cpus: 2max_cpu_id :
1nr_nodes   : 1cores_per_socket   : 1threads_per_core
: 1cpu_mhz: 6hw_caps:
:::::::virt_caps
:total_memory   : 2032free_memory:
1439sharing_freed_memory   : 0sharing_used_memory:
0outstanding_claims : 0free_cpus  : 0xen_major
: 4xen_minor  : 10xen_extra  :
.0-rcxen_version: 4.10.0-rcxen_caps   :
xen-3.0-armv7l xen_scheduler  : creditxen_pagesize   :
4096platform_params: virt_start=0x20xen_changeset  :
Mon Oct 16 15:14:16 2017 +0100 git:24fb44e-dirtyxen_commandline:
sync_console console=dtuart dtuart=serial2cc_compiler:
arm-linux-gnueabihf-gcc (crosstool-NG
linaro-1.13.1-4.7-2013.03cc_compile_by  :
ritikacc_compile_domain  : cc_compile_date: Fri Oct 27 11:39:32
IST 2017build_id   :
ed71e48dc494388691dac13664932a8f5ed3ee45xend_config_format : 4*
 >> not allocate order=18 extent: id=4 memflags=0xc0 (0 of 1)libxl: error:

 > looks like it could not allocate memory?

On Wed, Nov 8, 2017 at 8:22 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> 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] [llvm-dev] [PATCH for-next 7/9] coverage: introduce support for llvm profiling

[Vedant Kumar]

- llvm-dev, since the code review can continue without that audience.

vedant

> On Nov 8, 2017, at 3:08 AM, Jan Beulich via llvm-dev 
>  wrote:
> 
 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
> 
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


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

[Xen-devel] [linux-linus test] 115678: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm broken  in 115658

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm 4 host-install(4) broken in 115658 pass in 115678
 test-amd64-amd64-xl-qcow2 19 guest-start/debian.repeat fail in 115658 pass in 
115678
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115658 pass 
in 115678
 test-amd64-i386-rumprun-i386 17 rumprun-demo-xenstorels/xenstorels.repeat fail 
pass in 115658
 test-amd64-i386-xl-raw   19 guest-start/debian.repeat  fail pass in 115658
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat  fail pass in 115658

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115643
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115643
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 115643
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115643
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115643
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115643
 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-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:
 linuxe4880bc5dfb1f02b152e62a894b5c6f3e995b3cf

Last test of basis   115643  2017-11-07 12:06:20 Z1 days
Testing same since   115658  2017-11-08 02:33:06 Z1 days2 attempts


People who touched revisions under test:
  Borislav Petkov 
  Hannes 

Re: [Xen-devel] Xen PVH support in grub2

[Konrad Rzeszutek Wilk]

On Tue, Nov 07, 2017 at 11:10:29AM -0500, Boris Ostrovsky wrote:
> On 11/07/2017 02:42 AM, Juergen Gross wrote:
> > On 06/11/17 17:42, Boris Ostrovsky wrote:
> >> On 11/06/2017 10:05 AM, Juergen Gross wrote:
> >>> On 06/11/17 15:51, Boris Ostrovsky wrote:
>  On 11/06/2017 02:16 AM, Juergen Gross wrote:
> > On 03/11/17 20:00, Boris Ostrovsky wrote:
> >> On 11/03/2017 02:40 PM, Juergen Gross wrote:
> >>> On 03/11/17 19:35, Boris Ostrovsky wrote:
>  On 11/03/2017 02:23 PM, Juergen Gross wrote:
> > On 03/11/17 19:19, Boris Ostrovsky wrote:
> >> On 11/03/2017 02:05 PM, Juergen Gross wrote:
> >>> So again the question: how to tell whether we are PVH or HVM in
> >>> init_hypervisor_platform()? ACPi tables are scanned way later...
> >> Can we make grub/OVMF append a boot option?
> >>
> >> Or set setup_header.hardware_subarch to something? We already have
> >> X86_SUBARCH_XEN but it is only used by PV.  Or we might be able to 
> >> use
> >> hardware_subarch_data (will need to get a buy-in from x86 
> >> maintainers, I
> >> think).
> > But wouldn't this break the idea to reuse the native boot paths in
> > grub/OVMF without further modifications?
>  WDYM? We will have to have some sort of a plugin in either one to 
>  build
>  the zeropage anyway. So we'd set hardware_subarch there, in addition 
>  to
>  other things like setting memory and such.
> >>> But isn't the zeropage already being built? I admit that setting 
> >>> subarch
> >>> isn't a big deal, but using another entry with a passed-through pvh
> >>> start struct isn't either...
> >> I don't follow, sorry. My understanding is that zeropage will be built
> >> by PVH-enlightened grub so part of this process would be setting the
> >> subarch bit.
> > My reasoning was based on Roger's remark:
> >
> > "OTOH if Linux is capable of booting from the native entry point inside
> > of a PVH container, we would only have to port OVMF and grub in order
> > to work inside of a PVH container, leaving the rest of the logic
> > untouched."
>  Right, and in my mind porting OVMF/grub includes creating proper 
>  zeropage.
> >>> Aah, okay. I reasoned on the assumption to just enable OVMF/grub to run
> >>> in PVH environment without touching the parts setting up anything for
> >>> the new kernel.
> >> Someone needs to do what xen_prepare_pvh() does.
> > As the loader is filling in the memory map information 
> 
> That's the thing that I thought may need to be done by us (setting
> commandline too) . But I haven't looked at Xen support in grub so maybe
> it's already there.
> 
> > the only thing
> > remaining would be setting xen_pvh. And this could be delayed as my test
> > have shown, so we only need to detect the PVH case from inside the
> > kernel. One possibility would be the flags in the ACPI FADT table as
> > Roger mentioned, another idea would be a flag in zeropage set by the
> > loader.
> >
> >> And, for 64-bit, we also may need to build early pagetables since
> >> startup_64() (unlike startup_32()) expects paging to be on. (I don't
> >> know whether this is already part of standard FW codepath)
> > This would be done the same way as for a native kernel.
> 
> This is done by Linux trampoline code. AFAIK grub loads kernel in realmode.

Adding in Maran who is looking at re-using PVH for qemu launching
the kernels.

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

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

Re: [Xen-devel] [BUG] blkback reporting incorrect number of sectors, unable to boot

[Mike Reardon]

So am I correct in reading this that for at least the foreseeable future
storage using 4k sector sizes is not gonna happen?  I'm just trying to
figure out if I need to get some different hardware.

Thank you!

On Tue, Nov 7, 2017 at 5:41 AM, Roger Pau Monné 
wrote:

> On Tue, Nov 07, 2017 at 04:31:06AM -0700, Jan Beulich wrote:
> > >>> On 07.11.17 at 11:30,  wrote:
> > > On Mon, Nov 06, 2017 at 05:33:37AM -0700, Jan Beulich wrote:
> > >> >>> On 04.11.17 at 05:48,  wrote:
> > >> > I added some additional storage to my server with some native 4k
> sector
> > >> > size disks.  The LVM volumes on that array seem to work fine when
> mounted
> > >> > by the host, and when passed through to any of the Linux guests, but
> > >> > Windows guests aren't able to use them when using PV drivers.  The
> work
> > >> > fine to install when I first install Windows (Windows 10, latest
> build) but
> > >> > once I install the PV drivers it will no longer boot and give an
> > >> > inaccessible boot device error.  If I assign the storage to a
> different
> > >> > Windows guest that already has the drivers installed (as secondary
> storage,
> > >> > not as the boot device) I see the disk listed in disk management,
> but the
> > >> > size of the disk is 8x larger than it should be.  After looking
> into it a
> > >> > bit, the disk is reporting 8x the number of sectors it should have
> when I
> > >> > run xenstore-ls.  Here is the info from xenstore-ls for the
> relevant volume:
> > >> >
> > >> >   51712 = ""
> > >> >frontend = "/local/domain/8/device/vbd/51712"
> > >> >params = "/dev/tv_storage/main-storage"
> > >> >script = "/etc/xen/scripts/block"
> > >> >frontend-id = "8"
> > >> >online = "1"
> > >> >removable = "0"
> > >> >bootable = "1"
> > >> >state = "2"
> > >> >dev = "xvda"
> > >> >type = "phy"
> > >> >mode = "w"
> > >> >device-type = "disk"
> > >> >discard-enable = "1"
> > >> >feature-max-indirect-segments = "256"
> > >> >multi-queue-max-queues = "12"
> > >> >max-ring-page-order = "4"
> > >> >physical-device = "fe:0"
> > >> >physical-device-path = "/dev/dm-0"
> > >> >hotplug-status = "connected"
> > >> >feature-flush-cache = "1"
> > >> >feature-discard = "0"
> > >> >feature-barrier = "1"
> > >> >feature-persistent = "1"
> > >> >sectors = "34359738368"
> > >> >info = "0"
> > >> >sector-size = "4096"
> > >> >physical-sector-size = "4096"
> > >> >
> > >> >
> > >> > Here are the numbers for the volume as reported by fdisk:
> > >> >
> > >> > Disk /dev/tv_storage/main-storage: 16 TiB, 17592186044416 bytes,
> 4294967296
> > >> > sectors
> > >> > Units: sectors of 1 * 4096 = 4096 bytes
> > >> > Sector size (logical/physical): 4096 bytes / 4096 bytes
> > >> > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > >> > Disklabel type: dos
> > >> > Disk identifier: 0x
> > >> >
> > >> > DeviceBoot StartEndSectors Size
> Id Type
> > >> > /dev/tv_storage/main-storage1  1 4294967295 4294967295  16T
> ee GPT
> > >> >
> > >> >
> > >> > As with the size reported in Windows disk management, the number of
> sectors
> > >> > from xenstore seems is 8x higher than what it should be.  The disks
> aren't
> > >> > using 512b sector emulation, they are natively 4k, so I have no
> idea where
> > >> > the 8x increase is coming from.
> > >>
> > >> Hmm, looks like a backend problem indeed: struct hd_struct's
> > >> nr_sects (which get_capacity() returns) looks to be in 512-byte
> > >> units, regardless of actual sector size. Hence the plain
> > >> get_capacity() use as well the (wrongly open coded) use of
> > >> part_nr_sects_read() looks insufficient in vbd_sz(). Roger,
> > >> Konrad?
> > >
> > > Hm, AFAICT sector-size should always be set to 512.
> >
> > Which would mean that bdev_logical_block_size() can't be used by
> > blkback to set this value. Yet then - what's the point of the xenstore
> > setting if it's always the same value anyway?
>
> Some frontends (at least FreeBSD) will choke if sector-size is not
> set. So we have the following scenario:
>
>  - Windows: acknowledges sector-size * sectors in order to set disk
>capacity.
>  - Linux: sets disk capacity to sectors * 512.
>  - FreeBSD: sets disk capacity to sector-size * sectors, will choke if
>sector-size is not set.
>
> In order to keep compatibility with all of them AFAICT the only option
> is to hardcode sector-size to 512 in xenstore.
>
> Roger.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Oops, The address lines were somehow dropped by my mail client.
Adding Wei.

2017-11-09 10:06 GMT+08:00 Zhongze Liu :
> Hi Wei,
>
> 2017-11-01 23:55 GMT+08:00 Wei Liu :
>> On Thu, Oct 19, 2017 at 10:36:33AM +0800, Zhongze Liu wrote:
>>> Add libxl__sshm_del to unmap static shared memory areas mapped by
>>> libxl__sshm_add during domain creation. The unmapping process is:
>>>
>>> * For a master: decrease the refcount of the sshm region, if the refcount
>>>   reaches 0, cleanup the whole sshm path.
>>> * For a slave: unmap the shared pages, and cleanup related xs entries.
>>>   decrease the refcount of the sshm region, if the refcount reaches 0,
>>>   cleanup the whole sshm path.
>>>
>>
>> This appears to be in line with what we discussed.
>>
>> I would like to see some explanation for: if one or more of the things
>> the code does fail half way, the system is still going to be in a
>> consistent state. Most notably, there isn't going to be any page leaked
>> with uncleaned refs.
>>
>
> The unmapping code is invoked during the domain destruction process, so
> we can't roll back. Everything done here is a "best effort": even if the code
> fails half way, what I could do is to report the errors and proceed anyway.
>
> I might be totally wrong. So please correct me.
>
>>> +
>>> +rc = libxl__xs_transaction_commit(gc, );
>>> +if (!rc) break;
>>> +if (rc < 0) goto out;
>>> + isretry = true;
>>
>> Indentation.
>
> Cheers,
>
> Zhongze Liu

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

Re: [Xen-devel] [PATCH v3 5/7] libxl: support unmapping static shared memory areas during domain destruction

[Zhongze Liu]

Hi Wei,

2017-11-01 23:55 GMT+08:00 Wei Liu :
> On Thu, Oct 19, 2017 at 10:36:33AM +0800, Zhongze Liu wrote:
>> Add libxl__sshm_del to unmap static shared memory areas mapped by
>> libxl__sshm_add during domain creation. The unmapping process is:
>>
>> * For a master: decrease the refcount of the sshm region, if the refcount
>>   reaches 0, cleanup the whole sshm path.
>> * For a slave: unmap the shared pages, and cleanup related xs entries.
>>   decrease the refcount of the sshm region, if the refcount reaches 0,
>>   cleanup the whole sshm path.
>>
>
> This appears to be in line with what we discussed.
>
> I would like to see some explanation for: if one or more of the things
> the code does fail half way, the system is still going to be in a
> consistent state. Most notably, there isn't going to be any page leaked
> with uncleaned refs.
>

The unmapping code is invoked during the domain destruction process, so
we can't roll back. Everything done here is a "best effort": even if the code
fails half way, what I could do is to report the errors and proceed anyway.

I might be totally wrong. So please correct me.

>> +
>> +rc = libxl__xs_transaction_commit(gc, );
>> +if (!rc) break;
>> +if (rc < 0) goto out;
>> + isretry = true;
>
> Indentation.

Cheers,

Zhongze Liu

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

[Xen-devel] [linux-next test] 115674: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd   7 xen-boot fail REGR. vs. 115643
 test-armhf-armhf-xl-xsm   7 xen-boot fail REGR. vs. 115643
 test-armhf-armhf-xl-arndale   7 xen-boot fail REGR. vs. 115643
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail REGR. vs. 115643
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 115643
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 115643
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 115643
 build-amd64-pvops 6 kernel-build fail REGR. vs. 115643
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 115643

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds  7 xen-boot fail REGR. vs. 115643

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115643
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115643
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115643
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115643
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 

Re: [Xen-devel] [BUG] xen-mceinj tool testing cause dom0 crash

[Haozhong Zhang]

On 11/07/17 01:37 -0700, Jan Beulich wrote:
> >>> On 07.11.17 at 09:23,  wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, November 7, 2017 4:09 PM
> >> >>> On 07.11.17 at 02:37,  wrote:
> >> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> >> Sent: Monday, November 6, 2017 5:17 PM
> >> >> >>> On 03.11.17 at 09:29,  wrote:
> >> >> > We figured out the problem, some corner scripts triggered the error
> >> >> > injection at the same page (pfn 0x180020) twice, i.e. "./xen-mceinj
> >> >> > -t 0" run over one time, which resulted in Dom0 crash.
> >> >>
> >> >> But isn't this a valid scenario, which shouldn't result in a kernel 
> >> >> crash?
> >> > What if
> >> >> two successive #MCs occurred for the same page?
> >> >> I.e. ...
> >> >>
> >> >
> >> > Yes, it's another valid scenario, the expect result is kernel crash.
> >> 
> >> Kernel _crash_ or rather kernel _panic_? Of course without any kernel 
> >> messages
> >> we can't tell one from the other, but to me this makes a difference 
> >> nevertheless.
> >> 
> > Exactly, Dom0 crash.
> 
> I don't believe a crash is the expected outcome here.
>

This test case injects two errors to the same dom0 page. During the
first injection, offline_page() is called to set PGC_broken flag of
that page. During the second injection, offline_page() detects the
same broken page is touched again, and then tries to shutdown the page
owner, i.e. dom0 in this case:

/*
 * NB. When broken page belong to guest, usually hypervisor will
 * notify the guest to handle the broken page. However, hypervisor
 * need to prevent malicious guest access the broken page again.
 * Under such case, hypervisor shutdown guest, preventing recursive mce.
 */
if ( (pg->count_info & PGC_broken) && (owner = page_get_owner(pg)) )
{
*status = PG_OFFLINE_AGAIN;
domain_shutdown(owner, SHUTDOWN_crash);
return 0;
}

So I think Dom0 crash and the following machine reboot are the
expected behaviors here.

But, it looks a (unexpected) page fault happens during the reboot.
Xudong, can you check whether a normal reboot on that machine triggers
a page fault?

> > And I didn't see any "kernel panic" message from the log -- attach the 
> > original log again.
> 
> Well, as said - there _no_ kernel log message at all, and hence we
> can't tell whether it's a crash or a plain panic. Iirc Xen's "Hardware
> Dom0 crashed" can't distinguish the two cases.
> 

The crash is triggered in offline_page() before Xen can inject the
error to Dom0, so there is no dom0 kernel log around the crash.

This can be confirmed by dumping the call trace when
hwdom_shutdown(SHUTDOWN_crash) is called. Xudong, can you do this?

Thanks,
Haozhong

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

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

[Goel, Sameer]

On 10/24/2017 8:08 AM, Julien Grall wrote:
> Hi Sameer,
> 
> On 19/10/17 15:53, Goel, Sameer wrote:
>> On 10/12/2017 6:45 AM, Julien Grall wrote:
>>> On 21/09/17 01:37, Sameer Goel wrote:
 This will be used as a device property to match the DMA capable devices
 with the associated SMMU. The header file is a port from linux. The code
 was changed to remove the types that were not needed for Xen.
>>>
>>> I think you probably want a bit more context in the commit message about 
>>> implement fwnode.h in common code.
>>>
>>> Within this series, fwnode seems to only be used by Arm. So what would be 
>>> the advantage to get that in xen/? Is it going to be used by x86 or taken 
>>> advantage in common code?
>>>

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

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

 diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
 index 6734ae8..78c38fe 100644
 --- a/xen/include/asm-arm/device.h
 +++ b/xen/include/asm-arm/device.h
 @@ -2,6 +2,7 @@
    #define __ASM_ARM_DEVICE_H
      #include 
 +#include 
      enum device_type
    {
 @@ -19,6 +20,7 @@ struct device
    #ifdef CONFIG_HAS_DEVICE_TREE
    struct dt_device_node *of_node; /* Used by drivers imported from 
 Linux */
>>>
>>> I was expecting a todo in the code after the discussion about leave of_node 
>>> here.
>>>
    #endif
 +    struct fwnode_handle *fwnode; /*fw device node identifier */
>> The fwnode handle was provide a match cookie for the SMMUs and not much 
>> else. Even with this around we will need the
>> dt info in the device node. I agree that this rolls up into fw spec and I 
>> can look at the code cleanup for the next patch.
> 
> A clean-up patch would be great but not necessary. What I expect is a TODO 
> mentioning the possible clean-up.
> 
I looked through the Linux code a bit more. The reason for pulling in the 
fwnode was to port the iort code as is. So, really I do not need this at all. 
All I need is a dummy struct for fwnode.

I will remove this header file and add a new definition in the linux compat 
header. What is a good location for this header?
> Cheers,
> 

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

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

Re: [Xen-devel] [PATCH v3 4/7] libxl: support mapping static shared memory areas during domain creation

[Zhongze Liu]

Hi Wei,

2017-11-01 23:55 GMT+08:00 Wei Liu :
> On Thu, Oct 19, 2017 at 10:36:32AM +0800, Zhongze Liu wrote:
>> Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
>> process involves the follwing steps:
>>
>>   * Set defaults and check for further errors in the static_shm configs:
>> overlapping areas, invalid ranges, duplicated master domain,
>> no master domain etc.
>>   * Write infomation of static shared memory areas into the appropriate
>> xenstore paths.
>>   * Use xc_domain_add_to_physmap_batch to do the page sharing.
>>   * Set the refcount of the shared region accordingly
>>
>> Temporarily mark this as unsupported on x86 because calling p2m_add_foregin 
>> on
>> two domU's is currently not allowd on x86 (see the comments in
>> x86/mm/p2m.c:p2m_add_foregin for more details).
>>
>> This is for the proposal "Allow setting up shared memory areas between VMs
>> from xl config file" (see [1]).
>>
>> [1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
>>
>> Signed-off-by: Zhongze Liu 
>>
>> Cc: Wei Liu 
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> Cc: xen-devel@lists.xen.org
>> ---
>>   V3:
>>   * unmap the successfully mapped pages whenever rc != 0
>
>
> A general note: please properly capitalise the comments.
>
>> ---
>>  tools/libxl/Makefile |   2 +-
>>  tools/libxl/libxl_arch.h |   6 +
>>  tools/libxl/libxl_arm.c  |  15 ++
>>  tools/libxl/libxl_create.c   |  27 +++
>>  tools/libxl/libxl_internal.h |  13 ++
>>  tools/libxl/libxl_sshm.c | 395 
>> +++
>>  tools/libxl/libxl_x86.c  |  18 ++
>>  7 files changed, 475 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/libxl/libxl_sshm.c
>>
>> diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
>> index 5a861f72cb..91bc70cda2 100644
>> --- a/tools/libxl/Makefile
>> +++ b/tools/libxl/Makefile
> [...]
>> +
>> +/* check if the sshm slave configs in @sshm overlap */
>> +int libxl__sshm_check_overlap(libxl__gc *gc, uint32_t domid,
>> + libxl_static_shm *sshms, int len)
>> +{
>> +
>> +const libxl_static_shm **slave_sshms = NULL;
>> +int num_slaves;
>> +int i;
>> +
>> +if (!len) return 0;
>> +
>> +slave_sshms = libxl__calloc(gc, len, sizeof(slave_sshms[0]));
>> +num_slaves = 0;
>> +for (i = 0; i < len; ++i) {
>> +if (sshms[i].role == LIBXL_SSHM_ROLE_SLAVE)
>> +slave_sshms[num_slaves++] = sshms + i;
>> +}
>> +qsort(slave_sshms, num_slaves, sizeof(slave_sshms[0]), sshm_range_cmp);
>> +
>> +for (i = 0; i < num_slaves - 1; ++i) {
>> +if (slave_sshms[i+1]->begin < slave_sshms[i]->end) {
>> +SSHM_ERROR(domid, slave_sshms[i+1]->id, "slave ranges 
>> overlap.");
>> +return ERROR_INVAL;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/*   libxl__sshm_do_map -- map pages into slave's physmap
>> + *
>> + *   This functions maps
>> + * mater gfn: [@msshm->begin + @sshm->offset, @msshm->end + 
>> @sshm->offset)
>
> "master"
>
> This is confusing. What if offset is not page aligned?

No, it will always be page-aligned. This was documented in the man
page and also checked
in the corresponding libxlu_* function.

>
>> + *   into
>> + * slave gfn: [@sshm->begin, @sshm->end)
>> + *
>> + *   The gfns of the pages that are successfully mapped will be stored
>> + *   in @mapped, and the number of the gfns will be stored in @nmapped.
>> + *
>> + *   The caller have to guarentee that sshm->begin < sshm->end */
>> +static int libxl__sshm_do_map(libxl__gc *gc, uint32_t mid, uint32_t sid,
>> +  libxl_static_shm *sshm, libxl_static_shm 
>> *msshm,
>> +  xen_pfn_t *mapped, unsigned int *nmapped)
>> +{
>> +int rc;
>> +int i;
>> +unsigned int num_mpages, num_spages, num_success, offset;
>> +int *errs;
>> +xen_ulong_t *idxs;
>> +xen_pfn_t *gpfns;
>> +
>> +num_mpages = (msshm->end - msshm->begin) >> XC_PAGE_SHIFT;
>> +num_spages = (sshm->end - sshm->begin) >> XC_PAGE_SHIFT;
>> +offset = sshm->offset >> XC_PAGE_SHIFT;
>> +
>> +/* Check range. Test offset < mpages first to avoid overflow */
>> +if ((offset >= num_mpages) || (num_mpages - offset < num_spages)) {
>> +SSHM_ERROR(sid, sshm->id, "exceeds master's address space.");
>> +rc = ERROR_INVAL;
>> +goto out;
>> +}
>> +
>> +/* fill out the pfn's and do the mapping */
>> +errs = libxl__calloc(gc, num_spages, sizeof(int));
>> +idxs = libxl__calloc(gc, num_spages, sizeof(xen_ulong_t));
>> +gpfns = libxl__calloc(gc, num_spages, sizeof(xen_pfn_t));
>> +for (i = 0; i < num_spages; i++) {
>> +idxs[i] = (msshm->begin >> XC_PAGE_SHIFT) + offset + i;
>> +

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

[Hao, Xudong]

> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com]
> Sent: Tuesday, November 7, 2017 5:33 PM
> To: Hao, Xudong 
> Cc: Julien Grall ; Stefano Stabellini
> ; Lars Kurth ; Quan Xu
> ; Kang, Luwei ; Zhang,
> PengtaoX ; Julien Grall ;
> Jan Beulich ; Xen-devel ;
> Anthony PERARD ; Wei Liu 
> Subject: Re: [Xen-devel] [BUG] win2008 guest cannot get ip through sriov
> 
> On Mon, Nov 06, 2017 at 01:04:56AM +, Hao, Xudong wrote:
> > > -Original Message-
> > > From: Roger Pau Monné [mailto:roger@citrix.com]
> > > Sent: Friday, November 3, 2017 7:23 PM
> > > To: Hao, Xudong 
> > > Cc: Julien Grall ; Stefano Stabellini
> > > ; Lars Kurth ; Quan
> > > Xu ; Kang, Luwei ; Zhang,
> > > PengtaoX ; Julien Grall
> > > ; Jan Beulich ; Xen-devel
> > > ; Anthony PERARD
> > > ; Wei Liu 
> > > Subject: Re: [Xen-devel] [BUG] win2008 guest cannot get ip through
> > > sriov
> > >
> > > On Fri, Nov 03, 2017 at 01:10:26AM +, Hao, Xudong wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Julien Grall [mailto:julien.gr...@linaro.org]
> > > > > Sent: Thursday, November 2, 2017 9:50 PM
> > > > > To: Stefano Stabellini 
> > > > > Cc: Hao, Xudong ; Jan Beulich
> > > > > ; Quan Xu ; Lars Kurth
> > > > > ; Wei Liu ; Zhang,
> > > > > PengtaoX ; Kang, Luwei
> > > > > ; Julien Grall ;
> > > > > Anthony PERARD ; Xen-devel  > > > > de...@lists.xenproject.org>
> > > > > Subject: Re: [Xen-devel] [BUG] win2008 guest cannot get ip
> > > > > through sriov
> > > > >
> > > > > Hi,
> > > > >
> > > > > 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?
> > > > >
> > > >
> > > > Qemu Xen tree is default which is in Xen source code configuration
> > > > file
> > > Config.mk, I tested it with it.
> > > > QEMU_UPSTREAM_URL ?= http://xenbits.xen.org/git-http/qemu-xen.git
> > >
> > > Can you please make sure you have QEMU commit a80363: xen/pt: allow
> > > QEMU to request MSI unmasking at bind time. AFAICT this is not yet
> > > in the qemu-xen tree.
> > >
> >
> > Roger,
> > Maybe I misunderstood of your question and my last mail confused you.
> Qemu-xen didn't have commit a80363, so I report this issue to ask for sync up
> with qemu upstream. Last mail I mean I usually used Qemu Xen tree to do test,
> and found out this issue.
> 
> Before requesting the backport, have you tested whether it fixes your issues?
> 

Yes, Luwei (Cced) tested it with pass result.


Thanks,
-Xudong

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

[Xen-devel] [linux-3.18 test] 115673: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeatfail like 115495
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 115495
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 115495
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 115495
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 115495
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115495
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 115495
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 115495
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeatfail  like 115495
 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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-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-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-libvirt-raw 12 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-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-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-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop 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-amd64-amd64-xl-qemut-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-qemut-win10-i386 10 windows-installfail 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:
 linux943dc0b3ef9f0168494d6dca305cd0cf53a0b3d4
baseline version:
 linux4f823316dac3de3463dfbea2be3812102a76e246

Last test of basis   115495  2017-11-02 19:35:18 Z6 days
Testing same since   115673  2017-11-08 09:43:38 Z0 days1 attempts


People who touched revisions under test:
  Alexander Boyko 
  Andrew Morton 
  Andy Shevchenko 
  Arnd Bergmann 
  Ashish Samant 
  Boris Ostrovsky 
  Borislav Petkov 
  Catalin Marinas 
  Chris Brandt 
  Dan Carpenter 
  David Howells 

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

[Govinda Tatti]

Thanks Pasi for your response. Please see below for my comments.

On 11/8/2017 11:38 AM, Pasi Kärkkäinen wrote:

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?

I don't think so but either Konrad or someone can comment on it.


If the PCI device in question has native flr capability, then native flr is 
used, right ?

Yes.

I guess I should read the full patch..

Please check it and let us know your comments.

Cheers
GOVINDA

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

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

[Govinda Tatti]

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 | 119 +
 2 files changed, 131 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..e2677a6 100644
--- a/drivers/xen/xen-pciback/pci_stub.c
+++ b/drivers/xen/xen-pciback/pci_stub.c
@@ -244,6 +244,91 @@ struct pci_dev *pcistub_get_pci_dev(struct 
xen_pcibk_device *pdev,
return found_dev;
 }
 
+struct pcistub_args {
+   struct pci_dev *dev;
+   unsigned int dcount;
+};
+
+static int pcistub_search_dev(struct pci_dev *dev, void *data)
+{
+   struct pcistub_device *psdev;
+   struct pcistub_args *arg = data;
+   bool found_dev = false;
+   unsigned long flags;
+
+   spin_lock_irqsave(_devices_lock, flags);
+
+   list_for_each_entry(psdev, _devices, dev_list) {
+   if (psdev->dev == dev) {
+   found_dev = true;
+   arg->dcount++;
+   break;
+   }
+   }
+
+   spin_unlock_irqrestore(_devices_lock, flags);
+
+   /* Device not owned by pcistub, someone owns it. Abort the walk */
+   if (!found_dev)

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

[Boris Ostrovsky]

On 11/08/2017 08:30 AM, Juergen Gross wrote:
> 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 


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

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] 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] 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-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: 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 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

[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 
  

[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] [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] [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(>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, _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

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

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] [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] [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

[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

[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, );
+   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 = _clock->pvti;
+
+   ret = HYPERVISOR_vcpu_op(VCPUOP_register_vcpu_time_memory_area, 0, );
+
+   /*
+* 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 

[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 

[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(_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 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 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

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] [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 

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, "[%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, );
+
+   /* All devices under the bus should be part of pcistub! */
+   if (arg.dev) {
+   dev_err(>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, "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

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] [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

[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__

[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

[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 

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] 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

[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] [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 == 

[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 

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

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 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 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 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 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

[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] 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 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 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

[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 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

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

[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

[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

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

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: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 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 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

[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] 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

[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] [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] [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] 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] [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 

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] [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] [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] 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] [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

[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] [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.

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] [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] [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
> , 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 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] [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 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 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

[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

[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

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

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 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