[Xen-devel] [libvirt test] 95768: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 95460
 test-amd64-amd64-libvirt-vhd  3 host-install(3) broken REGR. vs. 95460

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

version targeted for testing:
 libvirt  8ce58b0081e301375913c9147ae4daeed01fd37e
baseline version:
 libvirt  1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc

Last test of basis95460  2016-06-09 05:57:15 Z6 days
Failing since 95520  2016-06-10 18:36:19 Z5 days5 attempts
Testing same since95768  2016-06-15 08:39:15 Z0 days1 attempts


People who touched revisions under test:
  Chunyan Liu 
  Daniel P. Berrange 
  Guido Günther 
  Jim Fehlig 
  Jingjing Shao 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Pavel Hrdina 
  Riku Voipio 
  Roman Bogorodskiy 
  Wang Yufei 
  Wei Liu 

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



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-rumpuserxen   3 host-install(3) broken REGR. vs. 94728
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 94728

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu  3 host-install(3) broken in 95674 pass in 95762
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 95674 pass in 95762
 test-amd64-amd64-i386-pvgrub  3 host-install(3)  broken in 95674 pass in 95762
 test-amd64-i386-pair  3 host-install/src_host(3) broken in 95674 pass in 95762
 test-amd64-amd64-libvirt-pair 3 host-install/src_host(3) broken in 95674 pass 
in 95762
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 95674 pass in 
95762
 test-amd64-i386-xl3 host-install(3)   broken pass in 95674
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3) broken pass in 95674
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
95674
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
95674
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)  broken pass in 95674
 test-amd64-amd64-xl-qemut-winxpsp3  3 host-install(3) broken pass in 95674
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 95458 pass in 95762
 test-amd64-i386-freebsd10-amd64 10 guest-start  fail pass in 95458
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop  fail pass in 95521
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat   fail pass in 95674

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-build fail in 95458 like 94728
 build-i386-rumpuserxen6 xen-buildfail   like 94728
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94728
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94728
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94728

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

Re: [Xen-devel] [PATCH] AMD IOMMU: correctly propagate errors from amd_iommu_init()

[Xu, Quan]

On June 14, 2016 5:03 PM, Jan Beulich  wrote:
> -if ( amd_iommu_update_ivrs_mapping_acpi() != 0 )
> +rc = amd_iommu_update_ivrs_mapping_acpi();
> +if ( rc )
>  goto error_out;
> 
>  /* initialize io-apic interrupt remapping entries */
> -if ( iommu_intremap && amd_iommu_setup_ioapic_remapping() != 0 )
> +if ( iommu_intremap )
> +rc = amd_iommu_setup_ioapic_remapping();
> +if ( rc )
>  goto error_out;


Is it better to indent this if() here? Then,

+if ( iommu_intremap )
+{
+rc = amd_iommu_setup_ioapic_remapping();
+if ( rc )
+goto error_out;
+}

Quan

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

Re: [Xen-devel] [PATCH] xen/arm: gic-v2: Only create GICv2m node when there are GICv2m frame available

[Wei Chen]

On 15 June 2016 at 21:40, Julien Grall  wrote:
> Xen will crash on platform where GICv2m is not available with the
> following error:
>
> (XEN) Can't find ranges property for the gic node
> (XEN) Device tree generation failed (-15).
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) Could not set up DOM0 guest OS
> (XEN) 
>
> This is because the property "ranges" may not be present in the GIC
> when there are no GICv2m frames.
>
> Skip the creation of the GICv2m node when the hardware does not
> support it.
>
> This fixes boot after commit "xen/arm: Export GICv2m register frames to
> DOM0 by device tree".
>
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/gic-v2.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 2c1c0ba..4e2f4c7 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -669,6 +669,10 @@ static int gicv2m_make_dt_node(const struct domain *d,
>  const struct dt_device_node *v2m = NULL;
>  const struct v2m_data *v2m_data;
>
> +/* It is not necessary to create the node if there are not GICv2m frames 
> */
> +if ( list_empty(_info) )
> +return 0;
> +
>  /* The sub-nodes require the ranges property */
>  prop = dt_get_property(gic, "ranges", );
>  if ( !prop )
> --
> 1.9.1
>

Looks fine to me.

Acked-by: Wei Chen 

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

[Xen-devel] [linux-3.10 test] 95747: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 86412
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 86412
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1  fail REGR. vs. 86412

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu  3 host-install(3) broken in 95665 pass in 95747
 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 95665 pass in 95747
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
95665 pass in 95747
 test-amd64-i386-xl-raw3 host-install(3)  broken in 95665 pass in 95747
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 95665 pass in 95747
 test-amd64-i386-xl-qemuu-win7-amd64 3 host-install(3) broken in 95665 pass in 
95747
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 95665 pass in 
95747
 test-amd64-i386-pair  3 host-install/src_host(3)  broken pass in 95665
 test-amd64-i386-libvirt-pair  3 host-install/src_host(3)  broken pass in 95665
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)  broken pass in 95665
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 
95665
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 95665
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken pass in 95665

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxca1199fccf14540e86f6da955333e31d6fec5f3e
baseline version:
 linux326a1b2d50cbe1f890e56ab60b9215cd30053f5a

Last test of basis86412  2016-03-16 16:24:33 Z   91 days
Testing same since95665  2016-06-13 14:51:45 Z2 days2 attempts


People who touched revisions under test:
  Aaro Koskinen 
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alex Deucher 
  Alexandre Belloni 
  Alexandre Bounine 
  Alexey Khoroshilov 
  Allain Legacy 
  Andi Kleen 
  Andrew Morton 
  Andrey Gelman 
  Andy Lutomirski 
  Andy Lutomirski  # On a Dell XPS 13 9350
  Anton Blanchard 
  Antonio Quartulli 
  Aristeu Rozanski 
  Arnaldo Carvalho de Melo 
  Arnd Bergmann 
  Artem Bityutskiy 
  Aurelien Jacquiot 
  Behan Webster 
  Ben Hutchings 
  Bill Sommerfeld 
  Bjorn Helgaas 
  Bjørn Mork 
  Bob Moore 
  Borislav Petkov 
  Brian King 
  Brian Norris 
  Chanwoo Choi 
  Chas Williams <3ch...@gmail.com>
  Chris Friesen 
  Dan Carpenter 
  Dan Streetman 
  Daniel Fraga 
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 95353
 test-amd64-amd64-xl-qcow2 3 host-install(3) broken REGR. vs. 95353
 test-amd64-amd64-i386-pvgrub  3 host-install(3) broken REGR. vs. 95353
 test-amd64-i386-libvirt-pair 3 host-install/src_host(3) broken REGR. vs. 95353
 test-amd64-amd64-migrupgrade 4 host-install/dst_host(4) broken REGR. vs. 95353
 test-amd64-amd64-libvirt-pair 4 host-install/dst_host(4) broken REGR. vs. 95353
 test-amd64-i386-xl-qemuu-ovmf-amd64  3 host-install(3)  broken REGR. vs. 95353
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 3 host-install(3) broken REGR. vs. 
95353
 test-amd64-i386-xl-qemut-winxpsp3  3 host-install(3)broken REGR. vs. 95353
 test-armhf-armhf-libvirt-xsm  6 xen-boot  fail REGR. vs. 95353
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install   fail REGR. vs. 95353
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 95353
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 95353
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install 
fail REGR. vs. 95353
 test-amd64-i386-xl-qemut-win7-amd64  9 windows-installfail REGR. vs. 95353
 test-amd64-amd64-xl-qemut-win7-amd64  9 windows-install   fail REGR. vs. 95353
 test-amd64-amd64-xl-qemuu-win7-amd64  9 windows-install   fail REGR. vs. 95353
 test-amd64-i386-xl-qemuu-win7-amd64  9 windows-installfail REGR. vs. 95353
 test-amd64-i386-xl-qemuu-winxpsp3  9 windows-install  fail REGR. vs. 95353

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 95353
 build-i386-rumpuserxen6 xen-buildfail   like 95353
 test-amd64-i386-freebsd10-amd64 10 guest-start fail like 95353
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 95353

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

version targeted for testing:
 xen  d337764d9b8e89eb9cb9d5be509823d9286f00c4
baseline version:
 xen  

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

[Joao Martins]

On 06/15/2016 11:26 AM, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1328,21 +1328,51 @@ static void time_calibration(void *unuse
>   , 1);
>  }
>  
> +static struct {
> +s_time_t local_stime, master_stime;
> +} ap_bringup_ref;
> +
> +void time_latch_stamps(void) {
^ style: shouldn't this bracket be on a new 
line?

> +unsigned long flags;
> +u64 tsc;
> +
> +local_irq_save(flags);
> +ap_bringup_ref.master_stime = read_platform_stime();
> +tsc = rdtsc();
> +local_irq_restore(flags);
> +
> +ap_bringup_ref.local_stime = get_s_time_fixed(tsc);
> +}
> +
>  void init_percpu_time(void)
>  {
>  struct cpu_time *t = _cpu(cpu_time);
>  unsigned long flags;
> +u64 tsc;
>  s_time_t now;
>  
>  /* Initial estimate for TSC rate. */
>  t->tsc_scale = per_cpu(cpu_time, 0).tsc_scale;
>  
>  local_irq_save(flags);
> -t->local_tsc_stamp = rdtsc();
>  now = read_platform_stime();
Do we need to take another read from the platform timer here? We could
just reuse the one on ap_bringup_ref.master_stime. See also below.

> +tsc = rdtsc();
>  local_irq_restore(flags);
>  
>  t->stime_master_stamp = now;
> +/*
> + * To avoid a discontinuity (TSC and platform clock can't be expected
> + * to be in perfect sync), initialization here needs to match up with
> + * local_time_calibration()'s decision whether to use its fast path.
> + */
> +if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
> +{
> +if ( system_state < SYS_STATE_smp_boot )
> +now = get_s_time_fixed(tsc);
> +else
> +now += ap_bringup_ref.local_stime - ap_bringup_ref.master_stime;
> +}
> +t->local_tsc_stamp= tsc;

As far as my current experimentation (both v1 of this patch and the whole 
series on
v2), the source of the remaining warps could be fixed with this seeding. Though 
I
think this seeding might not yet be correct. Essentially the boot CPU you do
get_s_time_fixed(tsc), which basically gives you a value strictly calculated 
with TSC
since boot_tsc_stamp. For the other CPUs you append the time skew between TSC 
and
platform timer calculated before AP bringup, with a value just read on the 
platform
timer. Which I assume you take this as an approximation skew between TSC and 
platform
timer.

So, before this patch cpu_time is filled like this:

CPU 0: M0 , T0
CPU 1: M1 , T1
CPU 2: M2 , T2

With this patch it goes like:

CPU 0: L0 , T0
CPU 1: L1 = (M1 + (L - M)), T1
CPU 2: L2 = (M2 + (L - M)), T2

Given that,

1) values separated by commas are respectively local stime, tsc that are
written in cpu_time
2) M2 > M1 > M0 as values read from platform timer.
3) L and M solely as values calculated on CPU doing AP bringup.

After this seeding, local_time_calibration will increment the deltas between
calibrations every second, based entirely on a monotonically increasing TSC. 
Altough
I see two issues here: 1) appending to a new read from platform time which might
already be offsetted by the one taken from the boot CPU and 2) the skew you 
calculate
don't account for the current tsc. Which leads to local stime and tsc still not 
being
a valid pair for the secondary CPUs. So it would be possible that 
get_s_time(S0) on
CPU0 immediately followed by a get_s_time(S1) on CPU1 [S1 > S0] ends up 
returning a
value backwards IOW L0 + scale(S0 - T0) is bigger than L1 + scale(S1 - T1). 
That is
independently of the deltas being added on every calibration.

So how about we do the seeding in another way?

1) Relying on individual CPU TSC like you do on CPU 0:

 t->stamp.master_stime = now;
+t->stamp.local_tsc = 0;
+t->stamp.local_stime = 0;
+
 if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
 {
 now = get_s_time_fixed(tsc);
 }

(...)

Or 2) taking into account the skew between platform timer and tsc we take on
init_percpu_time. Diff below based on this series:

@@ -1394,11 +1508,14 @@ void init_percpu_time(void)
 t->tsc_scale = per_cpu(cpu_time, 0).tsc_scale;

 local_irq_save(flags);
-now = read_platform_stime();
+now = ap_bringup_ref.master_stime;
 tsc = rdtsc_ordered();
 local_irq_restore(flags);

 t->stamp.master_stime = now;
+t->stamp.local_tsc = boot_tsc_stamp;
+t->stamp.local_stime = 0;
+

 /*
  * To avoid a discontinuity (TSC and platform clock can't be expected
  * to be in perfect sync), initialization here needs to match up with
@@ -1406,10 +1523,12 @@ void init_percpu_time(void)
  */
 if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
 {
+u64 stime = get_s_time_fixed(tsc);
+
 if ( system_state < SYS_STATE_smp_boot )
-now = get_s_time_fixed(tsc);
+now = stime;
 else
-now += ap_bringup_ref.local_stime - ap_bringup_ref.master_stime;
+now += stime - ap_bringup_ref.master_stime;
 }

Second 

[Xen-devel] [linux-3.14 test] 95744: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 95164
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 95164
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail in 95585 REGR. vs. 
95164
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1 fail in 95585 REGR. vs. 95164

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 95585 pass in 95657
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 
95657 pass in 95585
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 95657 
pass in 95585
 test-amd64-amd64-qemuu-nested-amd 3 host-install(3) broken in 95657 pass in 
95585
 test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken in 95657 pass in 
95585
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken in 95657 pass in 95585
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 95657 pass in 
95744
 test-amd64-i386-xl-qemuu-winxpsp3 3 host-install(3) broken in 95657 pass in 
95744
 test-amd64-i386-libvirt   3 host-install(3)   broken pass in 95585
 test-amd64-i386-xl3 host-install(3)   broken pass in 95657
 test-amd64-i386-pair  3 host-install/src_host(3)  broken pass in 95657
 test-amd64-i386-libvirt-pair  3 host-install/src_host(3)  broken pass in 95657
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 95657

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail in 95585 like 95164
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 95585 like 95164
 build-i386-rumpuserxen6 xen-buildfail   like 95164
 build-amd64-rumpuserxen   6 xen-buildfail   like 95164
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95164
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95164

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  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-pair 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-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-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-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemut-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start   fail in 95585 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail in 95585 never pass
 test-amd64-i386-libvirt  12 migrate-support-check fail in 95585 never pass
 test-amd64-amd64-libvirt 12 migrate-support-check fail in 95585 never pass
 

Re: [Xen-devel] [PATCH 7/7] oxenstored: honour XEN_RUN_DIR

[David Scott]

> On 15 Jun 2016, at 12:15, Wei Liu  wrote:
> 
> Move default the pid file under XEN_RUN_DIR. Note that it changes the
> location from /var/run to /var/run/xen.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Dave Scott 
> ---
> tools/ocaml/xenstored/xenstored.ml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/ocaml/xenstored/xenstored.ml 
> b/tools/ocaml/xenstored/xenstored.ml
> index 30570ed..7ea4026 100644
> --- a/tools/ocaml/xenstored/xenstored.ml
> +++ b/tools/ocaml/xenstored/xenstored.ml
> @@ -81,7 +81,7 @@ let config_filename cf =
>   | Some name -> name
>   | None  -> Define.default_config_dir ^ "/oxenstored.conf"
> 
> -let default_pidfile = "/var/run/xenstored.pid"
> +let default_pidfile = Paths.xen_run_dir ^ "/xenstored.pid"
> 
> let ring_scan_interval = ref 20
> 
> -- 
> 2.1.4
> 

Looks fine to me.

Acked-by: David Scott 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  c3380e713ebf538556458016a1ae0a1e8c55209b
  Bug not present: 3704b9003f9c54c2a4d14d3c7e26e6dd3c1819a2
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/95793/


  commit c3380e713ebf538556458016a1ae0a1e8c55209b
  Author: Jiri Denemark 
  Date:   Mon Jun 6 14:43:07 2016 +0200
  
  tests: Add CPU detection test for AMD A10-5800K
  
  Signed-off-by: Jiri Denemark 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/95793.bisection-summary --basis-template=95460 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 95638 fail [host=godello0] / 95460 ok.
Failure / basis pass flights: 95638 / 95460
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 2e34cb546370b5115164d61a346ea433a5999837 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
Basis pass 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc-2e34cb546370b5115164d61a346ea433a5999837
 
git://git.sv.gnu.org/gnulib.git#246b3b28808ee5f4664be674dce573af9497fc7a-246b3b28808ee5f4664be674dce573af9497fc7a
 
git://xenbits.xen.org/qemu-xen-traditional.git#df553c056104e3dd8a2bd2e72539a57c4c085bae-df553c056104e3dd8a2bd2e72539a57c4c085bae
 
git://xenbits.xen.org/qemu-xen.git#44a072f0de0d57c95c2212bbce0232b7b74f-44a072f0de0d57c95c2212bbce0232b7b74f
 
git://xenbits.xen.org/xen.git#c2a17869d5dcd845d646bf4db122cad73596a2be-c2a17869d5dcd845d646bf4db122cad73596a2be
Loaded 1001 nodes in revision graph
Searching for test results:
 95460 pass 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95520 fail 13da6ff078321a692ce151d9123dcce6b130292a 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95577 fail 85d54f133c3b811d06fd8d55702ead03385a8a56 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95638 fail 2e34cb546370b5115164d61a346ea433a5999837 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95784 pass a54234c37bf58c28e8f26939c058121701b77589 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95789 fail c3380e713ebf538556458016a1ae0a1e8c55209b 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95777 fail bee9c530022d9cab5c9ab79bc2387fcd1dff0e0d 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95790 pass 3704b9003f9c54c2a4d14d3c7e26e6dd3c1819a2 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95771 pass 1a41ed5af5e1704dd9b0bdca40df5c9cacbdabfc 
246b3b28808ee5f4664be674dce573af9497fc7a 
df553c056104e3dd8a2bd2e72539a57c4c085bae 
44a072f0de0d57c95c2212bbce0232b7b74f 
c2a17869d5dcd845d646bf4db122cad73596a2be
 95779 pass 

[Xen-devel] [PATCH raisin v3] Update to 4.7, update qemu and qemu_traditional recipes

[George Dunlap]

Add a 4.7 config file, make it the default.

Also update the qemu and qemu_traditional recipies after Ian Cambell's
work to split off separate libraries.

Signed-off-by: George Dunlap 
---
Changes in v3:
- Reword comment
- Don't use tabs

Changes in v2:
 - Only add the extra #defines when building 4.7 or master, and add an
   explanation of what they're for.


CC: Stefano Stabellini 
---
 components/qemu | 32 +++-
 components/qemu_traditional |  2 +-
 configs/config-4.7  |  8 
 defconfig   |  2 +-
 4 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/components/qemu b/components/qemu
index e0d92a5..b49ed1d 100644
--- a/components/qemu
+++ b/components/qemu
@@ -20,18 +20,32 @@ function qemu_check_package() {
 }
 
 function qemu_build() {
+local QEMU_EXTRA_CFLAGS
 cd "$BASEDIR"
 git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
 cd qemu-dir
-./configure --enable-xen --target-list=i386-softmmu --prefix=$PREFIX \
---extra-cflags="-I$INST_DIR/$PREFIX/include" \
---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
- -L$INST_DIR/$PREFIX/lib64 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
---disable-kvm \
---disable-docs \
---bindir=$PREFIX/lib/xen/bin \
---datadir=$PREFIX/share/qemu-xen \
---disable-guest-agent
+
+QEMU_EXTRA_CFLAGS="-I$INST_DIR/$PREFIX/include"
+
+if [[ "$XEN_RELEASE" == "4.7" || "$XEN_RELEASE" == "master" ]] ; then
+# qemu-xen released with 4.7.0 doesn't use the new libxc api,
+# nor does it know how to ask for the compat api, so we need
+# to tell it to do so manually.
+QEMU_EXTRA_CFLAGS="$QEMU_EXTRA_CFLAGS -DXC_WANT_COMPAT_EVTCHN_API=1 \
+ -DXC_WANT_COMPAT_GNTTAB_API=1 \
+ -DXC_WANT_COMPAT_MAP_FOREIGN_API=1"
+fi
+
+./configure --enable-xen --target-list=i386-softmmu \
+   --prefix=$PREFIX \
+   --extra-cflags="$QEMU_EXTRA_CFLAGS" \
+   --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
+ -L$INST_DIR/$PREFIX/lib64 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
+   --bindir=$PREFIX/lib/xen/bin \
+   --datadir=$PREFIX/share/qemu-xen \
+   --disable-kvm \
+   --disable-docs \
+   --disable-guest-agent
 $RAISIN_MAKE all
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 cd "$BASEDIR"
diff --git a/components/qemu_traditional b/components/qemu_traditional
index 3150c3e..8732fe2 100644
--- a/components/qemu_traditional
+++ b/components/qemu_traditional
@@ -30,7 +30,7 @@ function qemu_traditional_build() {
 
 export CONFIG_BLKTAP1=n
 export XEN_ROOT="$BASEDIR"/xen-dir
-./xen-setup
+./xen-setup --extra-cflags="-D__XEN_TOOLS__"
 $RAISIN_MAKE all
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 cd "$BASEDIR"
diff --git a/configs/config-4.7 b/configs/config-4.7
new file mode 100644
index 000..66fe467
--- /dev/null
+++ b/configs/config-4.7
@@ -0,0 +1,8 @@
+XEN_REVISION="origin/stable-4.7"
+QEMU_REVISION="origin/stable-4.7"
+QEMU_TRADITIONAL_REVISION="origin/stable-4.7"
+SEABIOS_REVISION="rel-1.9.2"
+GRUB_REVISION="master"
+LIBVIRT_REVISION="origin/v1.3.3-maint"
+OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
+LINUX_REVISION="master"
diff --git a/defconfig b/defconfig
index 8e79a43..f8ef398 100644
--- a/defconfig
+++ b/defconfig
@@ -2,7 +2,7 @@
 # Setup a Xen based system.
 
 # Available options: 4.5, 4.6, master (for development branch)
-XEN_RELEASE="4.6"
+XEN_RELEASE="4.7"
 
 # Components
 ## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
-- 
2.1.4


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

[Xen-devel] [PATCH raisin v3] Raisin: Update to 4.7

[George Dunlap]

v3:
 - Only 4.7 patch remaining (other patches acked & committed)

v2:
 - Include fixes for config-master as well
 - Only include qemu / libxc compatiblity #defines for 4.7 and master


George Dunlap (1):
  Update to 4.7, update qemu and qemu_traditional recipes

 components/qemu | 32 +++-
 components/qemu_traditional |  2 +-
 configs/config-4.7  |  8 
 defconfig   |  2 +-
 4 files changed, 33 insertions(+), 11 deletions(-)
 create mode 100644 configs/config-4.7

-- 
2.1.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  759b9618b8a22ddd87d01c0bff5366814b17eea7
baseline version:
 xen  d337764d9b8e89eb9cb9d5be509823d9286f00c4

Last test of basis95735  2016-06-14 19:01:08 Z0 days
Testing same since95786  2016-06-15 16:07:33 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Suravee Suthikulpanit 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v3 4/5] libxl: update vcpus bitmap in retrieved guest config

[Anthony PERARD]

On Wed, Jun 15, 2016 at 10:31:41AM +0100, Wei Liu wrote:
> ... because the available vcpu bitmap can change during domain life time
> due to cpu hotplug and unplug.
> 
> For QEMU upstream, we interrogate QEMU for the number of vcpus. For
> others, we look directly into xenstore for information.
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Wei Liu 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH raisin v2 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[George Dunlap]

On 15/06/16 18:13, Stefano Stabellini wrote:
> On Wed, 15 Jun 2016, George Dunlap wrote:
>> Add a 4.7 config file, make it the default.
>>
>> Also update the qemu and qemu_traditional recipies after Ian Cambell's
>> work to split off separate libraries.
>>
>> Signed-off-by: George Dunlap 
>> ---
>> Changes in v2:
>>  - Only add the extra #defines when building 4.7 or master, and add an
>>explanation of what they're for.
>>
>>
>> CC: Stefano Stabellini 
>> ---
>>  components/qemu | 30 ++
>>  components/qemu_traditional |  2 +-
>>  configs/config-4.7  |  8 
>>  defconfig   |  2 +-
>>  4 files changed, 32 insertions(+), 10 deletions(-)
>>
>> diff --git a/components/qemu b/components/qemu
>> index e0d92a5..23e112c 100644
>> --- a/components/qemu
>> +++ b/components/qemu
>> @@ -20,18 +20,32 @@ function qemu_check_package() {
>>  }
>>  
>>  function qemu_build() {
>> +local QEMU_EXTRA_CFLAGS
>>  cd "$BASEDIR"
>>  git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
>>  cd qemu-dir
>> -./configure --enable-xen --target-list=i386-softmmu --prefix=$PREFIX \
>> ---extra-cflags="-I$INST_DIR/$PREFIX/include" \
>> ---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
>> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
>> +
>> +QEMU_EXTRA_CFLAGS="-I$INST_DIR/$PREFIX/include"
>> +
>> +if [[ "$XEN_RELEASE" == "4.7" || "$XEN_RELEASE" == "master" ]] ; then
>> +# qemu-xen released with 4.7.0 doesn't use the new libxc api,
>> +# nor properly detect it so as to use the old version; so we
> ^ has to use ?

No, but it is rather an unusual grammar construction so maybe it could
be reworded. What about:

"qemu-xen released with 4.7.0 doesn't use the new libxc api, nor does it
know how to ask for the compat api, so we need to tell it to do so
manually."

> 
> 
>> +# need to tell it to do so manually.
> 
> This patch is mixing tabs and spaces.

So it does.  I'll have to figure out how to get emacs to behave.

 -George


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

Re: [Xen-devel] [PATCH raisin v2 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[Stefano Stabellini]

On Wed, 15 Jun 2016, George Dunlap wrote:
> Add a 4.7 config file, make it the default.
> 
> Also update the qemu and qemu_traditional recipies after Ian Cambell's
> work to split off separate libraries.
> 
> Signed-off-by: George Dunlap 
> ---
> Changes in v2:
>  - Only add the extra #defines when building 4.7 or master, and add an
>explanation of what they're for.
> 
> 
> CC: Stefano Stabellini 
> ---
>  components/qemu | 30 ++
>  components/qemu_traditional |  2 +-
>  configs/config-4.7  |  8 
>  defconfig   |  2 +-
>  4 files changed, 32 insertions(+), 10 deletions(-)
> 
> diff --git a/components/qemu b/components/qemu
> index e0d92a5..23e112c 100644
> --- a/components/qemu
> +++ b/components/qemu
> @@ -20,18 +20,32 @@ function qemu_check_package() {
>  }
>  
>  function qemu_build() {
> +local QEMU_EXTRA_CFLAGS
>  cd "$BASEDIR"
>  git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
>  cd qemu-dir
> -./configure --enable-xen --target-list=i386-softmmu --prefix=$PREFIX \
> ---extra-cflags="-I$INST_DIR/$PREFIX/include" \
> ---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
> +
> +QEMU_EXTRA_CFLAGS="-I$INST_DIR/$PREFIX/include"
> +
> +if [[ "$XEN_RELEASE" == "4.7" || "$XEN_RELEASE" == "master" ]] ; then
> + # qemu-xen released with 4.7.0 doesn't use the new libxc api,
> + # nor properly detect it so as to use the old version; so we
^ has to use ?


> + # need to tell it to do so manually.

This patch is mixing tabs and spaces.



> + QEMU_EXTRA_CFLAGS="$QEMU_EXTRA_CFLAGS -DXC_WANT_COMPAT_EVTCHN_API=1 \
> + -DXC_WANT_COMPAT_GNTTAB_API=1 \
> + -DXC_WANT_COMPAT_MAP_FOREIGN_API=1"
> +fi
> +
> +./configure --enable-xen --target-list=i386-softmmu \
> + --prefix=$PREFIX \
> + --extra-cflags="$QEMU_EXTRA_CFLAGS" \
> + --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
>   -L$INST_DIR/$PREFIX/lib64 
> -Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
> ---disable-kvm \
> ---disable-docs \
> ---bindir=$PREFIX/lib/xen/bin \
> ---datadir=$PREFIX/share/qemu-xen \
> ---disable-guest-agent
> + --bindir=$PREFIX/lib/xen/bin \
> + --datadir=$PREFIX/share/qemu-xen \
> + --disable-kvm \
> + --disable-docs \
> + --disable-guest-agent
>  $RAISIN_MAKE all
>  $RAISIN_MAKE install DESTDIR="$INST_DIR"
>  cd "$BASEDIR"
> diff --git a/components/qemu_traditional b/components/qemu_traditional
> index 3150c3e..8732fe2 100644
> --- a/components/qemu_traditional
> +++ b/components/qemu_traditional
> @@ -30,7 +30,7 @@ function qemu_traditional_build() {
>  
>  export CONFIG_BLKTAP1=n
>  export XEN_ROOT="$BASEDIR"/xen-dir
> -./xen-setup
> +./xen-setup --extra-cflags="-D__XEN_TOOLS__"
>  $RAISIN_MAKE all
>  $RAISIN_MAKE install DESTDIR="$INST_DIR"
>  cd "$BASEDIR"
> diff --git a/configs/config-4.7 b/configs/config-4.7
> new file mode 100644
> index 000..66fe467
> --- /dev/null
> +++ b/configs/config-4.7
> @@ -0,0 +1,8 @@
> +XEN_REVISION="origin/stable-4.7"
> +QEMU_REVISION="origin/stable-4.7"
> +QEMU_TRADITIONAL_REVISION="origin/stable-4.7"
> +SEABIOS_REVISION="rel-1.9.2"
> +GRUB_REVISION="master"
> +LIBVIRT_REVISION="origin/v1.3.3-maint"
> +OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
> +LINUX_REVISION="master"
> diff --git a/defconfig b/defconfig
> index 8e79a43..f8ef398 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -2,7 +2,7 @@
>  # Setup a Xen based system.
>  
>  # Available options: 4.5, 4.6, master (for development branch)
> -XEN_RELEASE="4.6"
> +XEN_RELEASE="4.7"
>  
>  # Components
>  ## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] error while compiling Xen from the source

[Wim ten Have]

On Wed, Jun 15, 2016 at 6:34 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

P.S.
The Git Manual is very solid.

That helped O:-) ... now reading

https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH raisin v2 3/4] Update config-4.6 and config-4.5 to point to stable branches; fix config-master

[Stefano Stabellini]

On Wed, 15 Jun 2016, George Dunlap wrote:
> Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branches.
> 
> And point the default libvirt to point to the libvirt 1.3.3
> maintenance branch, rather than xen-tested-master.
> 
> Also update OVMF revision for 4.6 to a version that builds with modern
> gccs.
> 
> Point config-master libvirt to libvirt's "master" rather than xenbits'
> xen-tested-master, to avoid having to switch to xenbits repo.
> 
> Finally, fix config-master by pointing ovmf and seabios to the correct
> branch (master, not xen-tested-master).
> 
> Singed-off-by: George Dunlap 

Acked-by: Stefano Stabellini 


> v2:
>  - Use libvirt-master rather than xen-tested-master for config-master
>  - Fix seabios and ovmf revisions for config-master
> 
> CC: Stefano Stabellini 
> ---
>  configs/config-4.5 | 6 +++---
>  configs/config-4.6 | 8 
>  configs/config-master  | 6 +++---
>  configs/config-url-git | 2 +-
>  4 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/configs/config-4.5 b/configs/config-4.5
> index 4163b68..8db9a9d 100644
> --- a/configs/config-4.5
> +++ b/configs/config-4.5
> @@ -1,8 +1,8 @@
>  XEN_REVISION="origin/stable-4.5"
> -QEMU_REVISION="master"
> -QEMU_TRADITIONAL_REVISION="master"
> +QEMU_REVISION="origin/stable-4.5"
> +QEMU_TRADITIONAL_REVISION="origin/stable-4.5"
>  SEABIOS_REVISION="rel-1.7.5"
>  GRUB_REVISION="master"
> -LIBVIRT_REVISION="origin/xen-tested-master"
> +LIBVIRT_REVISION="origin/v1.3.3-maint"
>  OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>  LINUX_REVISION="master"
> diff --git a/configs/config-4.6 b/configs/config-4.6
> index e8b2a09..b003a30 100644
> --- a/configs/config-4.6
> +++ b/configs/config-4.6
> @@ -1,8 +1,8 @@
>  XEN_REVISION="origin/stable-4.6"
> -QEMU_REVISION="master"
> -QEMU_TRADITIONAL_REVISION="master"
> +QEMU_REVISION="origin/stable-4.6"
> +QEMU_TRADITIONAL_REVISION="origin/stable-4.6"
>  SEABIOS_REVISION="rel-1.8.2"
>  GRUB_REVISION="master"
> -LIBVIRT_REVISION="origin/xen-tested-master"
> -OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
> +LIBVIRT_REVISION="origin/v1.3.3-maint"
> +OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
>  LINUX_REVISION="master"
> diff --git a/configs/config-master b/configs/config-master
> index bd26ce3..8d8ad7e 100644
> --- a/configs/config-master
> +++ b/configs/config-master
> @@ -1,8 +1,8 @@
>  XEN_REVISION="master"
>  QEMU_REVISION="master"
>  QEMU_TRADITIONAL_REVISION="master"
> -SEABIOS_REVISION="origin/xen-tested-master"
> +SEABIOS_REVISION="master"
> +OVMF_REVISION="master"
>  GRUB_REVISION="master"
> -LIBVIRT_REVISION="origin/xen-tested-master"
> -OVMF_REVISION="origin/xen-tested-master"
> +LIBVIRT_REVISION="master"
>  LINUX_REVISION="master"
> diff --git a/configs/config-url-git b/configs/config-url-git
> index 79813c4..614f522 100644
> --- a/configs/config-url-git
> +++ b/configs/config-url-git
> @@ -3,6 +3,6 @@ QEMU_URL="git://xenbits.xen.org/qemu-xen.git"
>  QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-traditional.git"
>  SEABIOS_URL="git://xenbits.xen.org/seabios.git"
>  GRUB_URL="git://git.savannah.gnu.org/grub.git"
> -LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
> +LIBVIRT_URL="git://libvirt.org/libvirt.git"
>  OVMF_URL="git://xenbits.xen.org/ovmf.git"
>  LINUX_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH v3 2/5] libxl: factor out libxl__get_device_modlel_version

[Anthony PERARD]

On Wed, Jun 15, 2016 at 10:31:39AM +0100, Wei Liu wrote:
> Factor out the logic to determine device model version to a function. It
> will be used later. Note that code now also checks if the stbudom field
> is actually set before trying to extract a value from it.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

[Xen-devel] [PATCH 1/1] qemu-qdisk: indirect descriptors

[Paulina Szubarczyk]

Introduction of indirect descriptors for qdisk.

Changes in the xen_blkif.h file:
 - struct blkif_x86_**_request contains union of
   'struct blkif_x86_**_request_direct' (previous struct blkif_x86_**_request)
   and 'struct blkif_x86_**_request_indirect'
 - new helper functions to rewrite 'struct blkif_x86_**_request_**'
   to struct 'blkif_request_local' named like that to not interfer with
   'blkif_request' from "tools/include/xen/io/blkif.h"
 - a set of macros to maintain the indirect descriptors

Changes in the xen_disk.c file:
 - a new boolean feature_indirect member
 - a new helper function ioreq_get_operation_and_nr_segments
 - a new ioreq_parse_indirect function called when 'BLKIF_OP_INDIRECT'
   occurs. The function grant maps the pages with indirect descriptors and copy
   the segments to a local seg[MAX_INDIRECT_SEGMENTS] tabel placed in ioreq.

   After that the ioreq_parse function proceedes withoth changes. For
   direct request segments are mem-copied to the ioreq page.

Signed-off-by: Paulina Szubarczyk 
---
 hw/block/xen_blkif.h | 151 ++
 hw/block/xen_disk.c  | 187 ++-
 include/hw/xen/xen_backend.h |   2 +
 3 files changed, 285 insertions(+), 55 deletions(-)

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index c68487cb..04dce2f 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -18,40 +18,97 @@ struct blkif_common_response {
 
 /* i386 protocol version */
 #pragma pack(push, 4)
-struct blkif_x86_32_request {
-   uint8_toperation;/* BLKIF_OP_??? */
+struct blkif_x86_32_request_direct {
uint8_tnr_segments;  /* number of segments   */
blkif_vdev_t   handle;   /* only for read/write requests */
uint64_t   id;   /* private guest value, echoed in resp  */
blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
+
+struct blkif_x86_32_request_indirect {
+   uint8_toperation;
+   uint16_t   nr_segments;
+   uint64_t   id;
+   blkif_sector_t sector_number;
+   blkif_vdev_t   handle;
+   uint16_t   _pad2;
+   grant_ref_tindirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];
+   uint64_t   _pad3; /* make it 64 byte aligned */
+} __attribute__((__packed__));
+
+struct blkif_x86_32_request {
+   uint8_toperation;
+   union  {
+   struct blkif_x86_32_request_direct direct;
+   struct blkif_x86_32_request_indirect indirect;
+   } u;
+} __attribute__((__packed__));
+
 struct blkif_x86_32_response {
uint64_tid;  /* copied from request */
uint8_t operation;   /* copied from request */
int16_t status;  /* BLKIF_RSP_???   */
-};
+} __attribute__((__packed__));
+
 typedef struct blkif_x86_32_request blkif_x86_32_request_t;
+typedef struct blkif_x86_32_request_direct blkif_x86_32_request_direct_t;
+typedef struct blkif_x86_32_request_indirect blkif_x86_32_request_indirect_t;
 typedef struct blkif_x86_32_response blkif_x86_32_response_t;
 #pragma pack(pop)
 
 /* x86_64 protocol version */
-struct blkif_x86_64_request {
-   uint8_toperation;/* BLKIF_OP_??? */
+struct blkif_x86_64_request_direct {
uint8_tnr_segments;  /* number of segments   */
blkif_vdev_t   handle;   /* only for read/write requests */
-   uint64_t   __attribute__((__aligned__(8))) id;
+   uint32_t   _pad1;/* offsetof(blkif_request,u.rw.id) == 8 */
+   uint64_t   id;   /* private guest value, echoed in resp  */
blkif_sector_t sector_number;/* start sector idx on disk (r/w only)  */
struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_REQUEST];
-};
+} __attribute__((__packed__));
+
+struct blkif_x86_64_request_indirect {
+   uint8_toperation;
+   uint16_t   nr_segments;
+   uint32_t   _pad1;  
+   uint64_t   id;
+   blkif_sector_t sector_number;
+   blkif_vdev_t   handle;
+   uint16_t   _pad2;
+   grant_ref_tindirect_grefs[BLKIF_MAX_INDIRECT_PAGES_PER_REQUEST];
+   uint32_t  _pad3; /* make it 64 byte aligned */
+} __attribute__((__packed__));
+
+struct blkif_x86_64_request {
+   uint8_toperation;/* BLKIF_OP_??? */
+   union {
+   struct blkif_x86_64_request_direct direct;
+   struct blkif_x86_64_request_indirect indirect;
+   } u;
+} __attribute__((__packed__));
+
 struct blkif_x86_64_response {
-   uint64_t   __attribute__((__aligned__(8))) id;
+   uint64_tid;  

[Xen-devel] [PATCH 0/1] qemu-qdisk: indirect descriptors

[Paulina Szubarczyk]

In the meantime I tried an implementation for indirect descriptors for qemu.
Described further in the next mail. It is based on current staging branch of 
qemu. 

From tests I did not observed an improvement. A decrease of bandwith starts 
earlier when the block size increase then for staging branch, especially for 
higher values of iodepth[1]. 
I run it under gprof and all the results are available on my github[2] 
but below is a part of flat profile for staging and indirect descriptors when 
fio is run with iodepth=256 and bs=256 for 300 sec. 

In the indirect descriptors implementation more time is spent in ioreq_unmap
function with smaller number of calls. I tried to check if it cooperate better
with grant copy running in the same time vmstat but then rapidly memory is 
exhausted and swap-out/in, the part of the listings are below, and that is not
a case for poor grant copy implementation. 
I tried also different values of MAX_INDIRECT_SEGMENTS in the range 
{256, 128, 64, 32, 16} without bigger difference.

I would appreciate any suggestions how to approach the problem.  

flat profiles:
indirect descriptors
 Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls   s/call   s/call  name
13.19  1.12 1.12   653798 0.00 0.00  get_clock_realtime
 10.13  1.98 0.8683570 0.00 0.00  ioreq_unmap
  4.77  2.38 0.41 31245461 0.00 0.00  rcu_read_unlock
  4.12  2.73 0.3583423 0.00 0.00  ioreq_map
  3.65  3.04 0.31 20900170 0.00 0.00  phys_page_find
  3.12  3.31 0.27 20886790 0.00 0.00  address_space_rw
  2.24  3.50 0.19 20886790 0.00 0.00  address_space_translate
  2.00  3.67 0.17 10849312 0.00 0.00  test_and_clear_bit
  1.88  3.83 0.16 31245456 0.00 0.00  rcu_read_lock
  1.71  3.98 0.14 41773586 0.00 0.00  memory_access_is_direct
  1.65  4.12 0.14 10330994 0.00 0.00  xen_map_cache_unlocked
  1.59  4.25 0.14 20886785 0.00 0.00  
address_space_translate_internal
  1.53  4.38 0.13 10339152 0.00 0.00  cpu_inw
  1.41  4.50 0.12 10458730 0.00 0.00  find_portio
  1.30  4.61 0.11 10389053 0.00 0.00  cpu_physical_memory_rw
  1.12  4.71 0.10 10358655 0.00 0.00  qemu_get_ram_block
  1.06  4.79 0.09 31245450 0.00 0.00  xen_enabled
  1.06  4.88 0.09 10447242 0.00 0.00  portio_read
  1.06  4.97 0.09   237496 0.00 0.00  cpu_ioreq_pio
  1.06  5.07 0.09 1557 0.00 0.00  vnc_refresh_server_sur

 staging 
 Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls   s/call   s/call  name
 11.51  1.61 1.61   970388 0.00 0.00  get_clock_realtime
  9.58  2.95 1.34  1186036 0.00 0.00  ioreq_unmap
  5.50  3.72 0.77  1187881 0.00 0.00  ioreq_map
  4.15  4.30 0.58 31195245 0.00 0.00  rcu_read_unlock
  2.50  4.65 0.35 31195243 0.00 0.00  rcu_read_lock
  2.50  5.00 0.35 20866261 0.00 0.00  phys_page_find
  1.79  5.25 0.25 20852888 0.00 0.00  address_space_rw
  1.36  5.44 0.19  4912499 0.00 0.00  qemu_coroutine_switch
  1.22  5.61 0.17 20852881 0.00 0.00  address_space_translate
  1.22  5.78 0.17  6141137 0.00 0.00  bdrv_is_inserted
  1.07  5.93 0.15  2455277 0.00 0.00  tracked_request_end
  1.07  6.08 0.15  1187877 0.00 0.00  ioreq_parse
  1.00  6.22 0.14 20852887 0.00 0.00  
address_space_translate_internal
  1.00  6.36 0.14  2456463 0.00 0.00  qemu_aio_unref
  1.00  6.50 0.14  2456156 0.00 0.00  qemu_coroutine_enter
  0.93  6.63 0.13 41705784 0.00 0.00  memory_access_is_direct

vmstat listings:
grant map
procs ---memory-- ---swap-- -io -system-- --cpu-
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa st
 1  1 11 62   277563800  4052   244 16250 14124  6 20 71  2 
 1
 1  0 11 58   277963800  4308 0 16227 14254  7 18 74  1 
 0
 1  0 11 56   278163800  2320  1456 16310 14124  6 19 74  0 
 1
 1  0 13 67   277663101  3924  1372 14720 14019  6 20 74  0 
 1
 1  0 13 66   277963100  2768 0 16105 14038  6 19 74  0 
 0
 1  0 13 63   278263100  3000 0 14471 14002  6 19 74  0 
 0
 1  0 13 58   278663200  398836 12383 13135  7 19 73  1 
 0
 1  0 13 56   278963200  2488   116 12417 13853  6 20 74  0 
 0
 1  0 13 61   278862700  2556   296 12402 13382  7 20 73  0 
 0

Re: [Xen-devel] [PATCH v2 2/2] qdisk - hw/block/xen_disk: grant copy implementation

[Paulina Szubarczyk]

On Mon, 2016-06-13 at 11:58 +0100, David Vrabel wrote:
> On 13/06/16 11:44, Paulina Szubarczyk wrote:
> > On Mon, 2016-06-13 at 11:15 +0100, David Vrabel wrote:
> >> On 13/06/16 10:43, Paulina Szubarczyk wrote:
> >>> Copy data operated on during request from/to local buffers to/from 
> >>> the grant references. 
> >>>
> >>> Before grant copy operation local buffers must be allocated what is 
> >>> done by calling ioreq_init_copy_buffers. For the 'read' operation, 
> >>> first, the qemu device invokes the read operation on local buffers 
> >>> and on the completion grant copy is called and buffers are freed. 
> >>> For the 'write' operation grant copy is performed before invoking 
> >>> write by qemu device. 
> >>>
> >>> A new value 'feature_grant_copy' is added to recognize when the 
> >>> grant copy operation is supported by a guest. 
> >>> The body of the function 'ioreq_runio_qemu_aio' is moved to 
> >>> 'ioreq_runio_qemu_aio_blk' and in the 'ioreq_runio_qemu_aio' depending
> >>> on the support for grant copy according checks, initialization, grant 
> >>> operation are made, then the 'ioreq_runio_qemu_aio_blk' function is 
> >>> called. 
> >>
> >> I think you should add an option to force the use of grant mapping even
> >> if copy support is detected.  If future changes to the grant map
> >> infrastructure makes it faster or if grant map scales better in some
> >> systems, then it would be useful to be able to use it.
> > 
> > The 'feature_grant_copy' is a boolean and could be set to false in such 
> > case.
> > There could be added a node in XenStore, for example
> > 'feature-force-grant-map', which when set by frontend will be read
> > during a connection and changed the value to false forcing the grant map
> > operation.
> 
> This option should not be exposed/controlled by the frontend.  I was
> thinking of a command line option to qemu or similar.

I think then there should be possibility for setting this in 
xl block-attach  and in the config file that 
defines the domain in the corresponding fields. But if there is 
a need for such feature I would rather do it in a different patch.

Paulina


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

Re: [Xen-devel] [PATCH v3 3/5] libxl: introduce libxl__qmp_query_cpus

[Anthony PERARD]

On Wed, Jun 15, 2016 at 10:31:40AM +0100, Wei Liu wrote:
> It interrogates QEMU for CPUs and update the bitmap accordingly.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Boris Ostrovsky]

On 06/15/2016 11:54 AM, Jan Beulich wrote:
>
> Yes, albeit two then isn't enough either if we want to fully address
> the basic issue here: We'd have to latch as many translations as
> there are possibly pages involved in the execution of a single
> instruction.

Re: translations changing under us --- can't they change between guest
issuing two STOS instructions and the emulator picking up the latched
one (from the first instruction) when emulating the second?

-boris



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

Re: [Xen-devel] error while compiling Xen from the source

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2016 at 05:26:52PM +0200, Wim ten Have wrote:
> Running F23 here seemed to go trough good with above URL (making up much
> for my environment).
> 
> The only part causing me trouble is page specific direction setting the
> branch:
> 
> $ cd xen;
> *git checkout -b staging staging*

It loooks to have missed the 'origin' part.

One usually does 'git checkout origin/staging -b staging'

> 
> 
> Instead I did here (and think it should be)
> 
> $ cd xen; *git checkout -b staging*
> 
> Example:
> 
> 
>  git checkout -b staging
> Switched to a new branch 'staging'

The -b creates a new branch. And you called it staging.
But it may have nothing to do with the origin staging.

git branch -r

gives a good idea of the remote branches (so the ones you pull from)
vs the local ones:

git branch

Usually when you clone a tree it will clone the 'master' branch.
So I think your 'staging' is at the same commit as the 'master'.
If you want the latest, you would need to do:

git branch -d staging
git checkout origin/staging -b staging


P.S.
The Git Manual is very solid.
> 
> 
> On Wed, Jun 15, 2016 at 5:07 PM, Konrad Rzeszutek Wilk <
> konrad.w...@oracle.com> wrote:
> 
> > On Fri, Jun 10, 2016 at 04:03:30PM +0100, Safa Hamza wrote:
> > > i'm really confused
> > > i build xen from the source in pc running ubuntu mate but while trying to
> >
> > Take a look at
> > http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source#Build_Dependencies_-_Debian_.2F_Ubuntu
> > and follow the directions there.
> >
> > ___
> > Xen-devel mailing list
> > Xen-devel@lists.xen.org
> > http://lists.xen.org/xen-devel
> >

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

[Xen-devel] [qemu-upstream-4.3-testing test] 95733: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken REGR. vs. 
80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 80927
 build-i386-libvirt5 libvirt-build fail REGR. vs. 80927
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
80927
 test-amd64-amd64-amd64-pvgrub  9 debian-di-installfail REGR. vs. 80927

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass

version targeted for testing:
 qemuu12e8fccf5b5460be7aecddc71d27eceaba6e1f15
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  130 days
Failing since 93977  2016-05-10 11:09:16 Z   36 days  124 attempts
Testing same since95534  2016-06-11 00:59:46 Z4 days4 attempts


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

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops broken  
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64broken  
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair blocked 
 test-amd64-amd64-pv  pass
 test-amd64-i386-pv   blocked 
 test-amd64-amd64-amd64-pvgrubfail
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   

[Xen-devel] Xen on Dragonboard 410C

[Fadwa Messaoudi]

Hi,
i'm working on the dragonboard trying to install Xen on it, do you have any
documentation to help me and ease my work.
Best regards,
Fadwa Messaoudi.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/7] hotplug/FreeBSD: honour XEN_RUN_DIR

[Roger Pau Monné]

On Wed, Jun 15, 2016 at 12:15:05PM +0100, Wei Liu wrote:
> Store xldevd.pid under XEN_RUN_DIR. Note that the default location would
> change from /var/run to /var/run/xen.
> 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

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

[Xen-devel] [PATCH raisin v2 0/4] Raisin: Fixes for 4.6 and master, update to 4.7

[George Dunlap]

v2:
 - Include fixes for config-master as well
 - Only include qemu / libxc compatiblity #defines for 4.7 and master


George Dunlap (4):
  components/xen: Actually disable rombios
  config: Separate config urls into a separate file
  Update config-4.6 and config-4.5 to point to stable branches; fix
config-master
  Update to 4.7, update qemu and qemu_traditional recipes

 components/qemu | 30 +
 components/qemu_traditional |  2 +-
 components/xen  |  2 +-
 configs/config-4.5  | 45 +++
 configs/config-4.6  | 47 -
 configs/config-4.7  |  8 
 configs/config-master   | 44 +++---
 configs/config-url-git  |  8 
 configs/config-url-http |  7 +++
 defconfig   | 35 -
 10 files changed, 91 insertions(+), 137 deletions(-)
 create mode 100644 configs/config-4.7
 create mode 100644 configs/config-url-git
 create mode 100644 configs/config-url-http
 mode change 12 => 100644 defconfig

-- 
2.1.4


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

[Xen-devel] [PATCH raisin v2 3/4] Update config-4.6 and config-4.5 to point to stable branches; fix config-master

[George Dunlap]

Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branches.

And point the default libvirt to point to the libvirt 1.3.3
maintenance branch, rather than xen-tested-master.

Also update OVMF revision for 4.6 to a version that builds with modern
gccs.

Point config-master libvirt to libvirt's "master" rather than xenbits'
xen-tested-master, to avoid having to switch to xenbits repo.

Finally, fix config-master by pointing ovmf and seabios to the correct
branch (master, not xen-tested-master).

Singed-off-by: George Dunlap 
---
v2:
 - Use libvirt-master rather than xen-tested-master for config-master
 - Fix seabios and ovmf revisions for config-master

CC: Stefano Stabellini 
---
 configs/config-4.5 | 6 +++---
 configs/config-4.6 | 8 
 configs/config-master  | 6 +++---
 configs/config-url-git | 2 +-
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/configs/config-4.5 b/configs/config-4.5
index 4163b68..8db9a9d 100644
--- a/configs/config-4.5
+++ b/configs/config-4.5
@@ -1,8 +1,8 @@
 XEN_REVISION="origin/stable-4.5"
-QEMU_REVISION="master"
-QEMU_TRADITIONAL_REVISION="master"
+QEMU_REVISION="origin/stable-4.5"
+QEMU_TRADITIONAL_REVISION="origin/stable-4.5"
 SEABIOS_REVISION="rel-1.7.5"
 GRUB_REVISION="master"
-LIBVIRT_REVISION="origin/xen-tested-master"
+LIBVIRT_REVISION="origin/v1.3.3-maint"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
diff --git a/configs/config-4.6 b/configs/config-4.6
index e8b2a09..b003a30 100644
--- a/configs/config-4.6
+++ b/configs/config-4.6
@@ -1,8 +1,8 @@
 XEN_REVISION="origin/stable-4.6"
-QEMU_REVISION="master"
-QEMU_TRADITIONAL_REVISION="master"
+QEMU_REVISION="origin/stable-4.6"
+QEMU_TRADITIONAL_REVISION="origin/stable-4.6"
 SEABIOS_REVISION="rel-1.8.2"
 GRUB_REVISION="master"
-LIBVIRT_REVISION="origin/xen-tested-master"
-OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
+LIBVIRT_REVISION="origin/v1.3.3-maint"
+OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
 LINUX_REVISION="master"
diff --git a/configs/config-master b/configs/config-master
index bd26ce3..8d8ad7e 100644
--- a/configs/config-master
+++ b/configs/config-master
@@ -1,8 +1,8 @@
 XEN_REVISION="master"
 QEMU_REVISION="master"
 QEMU_TRADITIONAL_REVISION="master"
-SEABIOS_REVISION="origin/xen-tested-master"
+SEABIOS_REVISION="master"
+OVMF_REVISION="master"
 GRUB_REVISION="master"
-LIBVIRT_REVISION="origin/xen-tested-master"
-OVMF_REVISION="origin/xen-tested-master"
+LIBVIRT_REVISION="master"
 LINUX_REVISION="master"
diff --git a/configs/config-url-git b/configs/config-url-git
index 79813c4..614f522 100644
--- a/configs/config-url-git
+++ b/configs/config-url-git
@@ -3,6 +3,6 @@ QEMU_URL="git://xenbits.xen.org/qemu-xen.git"
 QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-traditional.git"
 SEABIOS_URL="git://xenbits.xen.org/seabios.git"
 GRUB_URL="git://git.savannah.gnu.org/grub.git"
-LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
+LIBVIRT_URL="git://libvirt.org/libvirt.git"
 OVMF_URL="git://xenbits.xen.org/ovmf.git"
 LINUX_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
-- 
2.1.4


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

[Xen-devel] [PATCH raisin v2 2/4] config: Separate config urls into a separate file

[George Dunlap]

So that we're not duplicating information.

Signed-off-by: George Dunlap 
Acked-by: Stefano Stabellini 
---
CC: Stefano Stabellini 
---
 configs/config-4.5  | 39 ---
 configs/config-4.6  | 39 ---
 configs/config-master   | 38 --
 configs/config-url-git  |  8 
 configs/config-url-http |  7 +++
 defconfig   | 35 ++-
 6 files changed, 49 insertions(+), 117 deletions(-)

diff --git a/configs/config-4.5 b/configs/config-4.5
index e3b92d5..4163b68 100644
--- a/configs/config-4.5
+++ b/configs/config-4.5
@@ -1,37 +1,3 @@
-# Config variables for raisin
-# Setup a Xen 4.5 based system
-
-# Components
-## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
-## Core xen functionality: xen
-## Remove a component from the list below, if you want to disable it
-## You can manually overwrite this list using the COMPONENTS
-## environmental variable.
-ENABLED_COMPONENTS="seabios ovmf xen qemu qemu_traditional grub libvirt"
-
-# Build config
-## Make command to run
-MAKE="make -j2"
-## Installation prefix (configure --prefix)
-PREFIX="/usr"
-## Install everything under DESTDIR
-## If you want to install under / run raise.sh -i
-DESTDIR=dist
-
-# Git urls. Use the http urls if you are behind a firewall.
-#XEN_URL="http://xenbits.xen.org/git-http/xen.git;
-#GRUB_URL="http://git.savannah.gnu.org/r/grub.git;
-#LIBVIRT_URL="https://gitorious.org/libvirt/libvirt.git;
-XEN_URL="git://xenbits.xen.org/xen.git"
-QEMU_URL="git://xenbits.xen.org/qemu-upstream-4.5-testing.git"
-QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-4.5-testing.git"
-SEABIOS_URL="git://xenbits.xen.org/seabios.git"
-GRUB_URL="git://git.savannah.gnu.org/grub.git"
-LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
-OVMF_URL="git://xenbits.xen.org/ovmf.git"
-LINUX_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
-
-# Software versions.
 XEN_REVISION="origin/stable-4.5"
 QEMU_REVISION="master"
 QEMU_TRADITIONAL_REVISION="master"
@@ -40,8 +6,3 @@ GRUB_REVISION="master"
 LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
-
-# Tests
-## All tests: busybox-pv busybox-hvm
-## ENABLED_TESTS is the list of test run by raise test
-ENABLED_TESTS="busybox-pv busybox-hvm"
diff --git a/configs/config-4.6 b/configs/config-4.6
index ebd45e7..e8b2a09 100644
--- a/configs/config-4.6
+++ b/configs/config-4.6
@@ -1,37 +1,3 @@
-# Config variables for raisin
-# Setup a Xen 4.6 based system
-
-# Components
-## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
-## Core xen functionality: xen
-## Remove a component from the list below, if you want to disable it
-## You can manually overwrite this list using the COMPONENTS
-## environmental variable.
-ENABLED_COMPONENTS="seabios ovmf xen qemu qemu_traditional grub libvirt"
-
-# Build config
-## Make command to run
-MAKE="make -j2"
-## Installation prefix (configure --prefix)
-PREFIX="/usr"
-## Install everything under DESTDIR
-## If you want to install under / run raise.sh -i
-DESTDIR=dist
-
-# Git urls. Use the http urls if you are behind a firewall.
-#XEN_URL="http://xenbits.xen.org/git-http/xen.git;
-#GRUB_URL="http://git.savannah.gnu.org/r/grub.git;
-#LIBVIRT_URL="https://gitorious.org/libvirt/libvirt.git;
-XEN_URL="git://xenbits.xen.org/xen.git"
-QEMU_URL="git://xenbits.xen.org/qemu-upstream-4.6-testing.git"
-QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-4.6-testing.git"
-SEABIOS_URL="git://xenbits.xen.org/seabios.git"
-GRUB_URL="git://git.savannah.gnu.org/grub.git"
-LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
-OVMF_URL="git://xenbits.xen.org/ovmf.git"
-LINUX_URL="git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git"
-
-# Software versions.
 XEN_REVISION="origin/stable-4.6"
 QEMU_REVISION="master"
 QEMU_TRADITIONAL_REVISION="master"
@@ -40,8 +6,3 @@ GRUB_REVISION="master"
 LIBVIRT_REVISION="origin/xen-tested-master"
 OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 LINUX_REVISION="master"
-
-# Tests
-## All tests: busybox-pv busybox-hvm
-## ENABLED_TESTS is the list of test run by raise test
-ENABLED_TESTS="busybox-pv busybox-hvm"
diff --git a/configs/config-master b/configs/config-master
index b218708..bd26ce3 100644
--- a/configs/config-master
+++ b/configs/config-master
@@ -1,36 +1,3 @@
-# Config variables for raisin
-
-# Components
-## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
-## Core xen functionality: xen
-## Remove a component from the list below, if you want to disable it
-## You can manually overwrite this list using the COMPONENTS
-## environmental variable.
-ENABLED_COMPONENTS="seabios ovmf xen qemu qemu_traditional grub libvirt"
-
-# Build config
-## Make command to run

[Xen-devel] [PATCH raisin v2 1/4] components/xen: Actually disable rombios

[George Dunlap]

Commit 5fe3855 meant to disable rombios, but didn't.  This causes the following
build failure:

gcc   -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs
-D__XEN_TOOLS__ -MMD -MF .rombios.o.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs  -DNDEBUG -Werror
-fno-stack-protector -fno-exceptions -fno-builtin -msoft-float
-I/usr/local/src/xenboil/raisin/xen-dir-remote/tools/firmware/hvmloader/../../../tools/include
-U__XEN_TOOLS__
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
-DENABLE_OVMF -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o rombios.o rombios.c
rombios.c: In function ‘rombios_load_roms’:
rombios.c:103:39: error: ‘etherboot’ undeclared (first use in this function)
   etherboot);

Disable rombios instead.

Reported-by: Holger Schramm 
Signed-off-by: George Dunlap 
Acked-by: Stefano Stabellini 
---
CC: Stefano Stabellini 
---
 components/xen | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/components/xen b/components/xen
index 894d119..ea290aa 100644
--- a/components/xen
+++ b/components/xen
@@ -45,7 +45,7 @@ function xen_build() {
 export ETHERBOOT_NICS=""
 ./configure --prefix=$PREFIX 
--with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
 --disable-stubdom --disable-qemu-traditional \
---enable-rombios $seabios_opt $ovmf_opt
+--disable-rombios $seabios_opt $ovmf_opt
 $RAISIN_MAKE
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 unset ETHERBOOT_NICS
-- 
2.1.4


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

[Xen-devel] [PATCH raisin v2 4/4] Update to 4.7, update qemu and qemu_traditional recipes

[George Dunlap]

Add a 4.7 config file, make it the default.

Also update the qemu and qemu_traditional recipies after Ian Cambell's
work to split off separate libraries.

Signed-off-by: George Dunlap 
---
Changes in v2:
 - Only add the extra #defines when building 4.7 or master, and add an
   explanation of what they're for.


CC: Stefano Stabellini 
---
 components/qemu | 30 ++
 components/qemu_traditional |  2 +-
 configs/config-4.7  |  8 
 defconfig   |  2 +-
 4 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/components/qemu b/components/qemu
index e0d92a5..23e112c 100644
--- a/components/qemu
+++ b/components/qemu
@@ -20,18 +20,32 @@ function qemu_check_package() {
 }
 
 function qemu_build() {
+local QEMU_EXTRA_CFLAGS
 cd "$BASEDIR"
 git-checkout $QEMU_URL $QEMU_REVISION qemu-dir
 cd qemu-dir
-./configure --enable-xen --target-list=i386-softmmu --prefix=$PREFIX \
---extra-cflags="-I$INST_DIR/$PREFIX/include" \
---extra-ldflags="-L$INST_DIR/$PREFIX/lib 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
+
+QEMU_EXTRA_CFLAGS="-I$INST_DIR/$PREFIX/include"
+
+if [[ "$XEN_RELEASE" == "4.7" || "$XEN_RELEASE" == "master" ]] ; then
+   # qemu-xen released with 4.7.0 doesn't use the new libxc api,
+   # nor properly detect it so as to use the old version; so we
+   # need to tell it to do so manually.
+   QEMU_EXTRA_CFLAGS="$QEMU_EXTRA_CFLAGS -DXC_WANT_COMPAT_EVTCHN_API=1 \
+   -DXC_WANT_COMPAT_GNTTAB_API=1 \
+   -DXC_WANT_COMPAT_MAP_FOREIGN_API=1"
+fi
+
+./configure --enable-xen --target-list=i386-softmmu \
+   --prefix=$PREFIX \
+   --extra-cflags="$QEMU_EXTRA_CFLAGS" \
+   --extra-ldflags="-L$INST_DIR/$PREFIX/lib 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
  -L$INST_DIR/$PREFIX/lib64 
-Wl,-rpath-link=$INST_DIR/$PREFIX/lib64" \
---disable-kvm \
---disable-docs \
---bindir=$PREFIX/lib/xen/bin \
---datadir=$PREFIX/share/qemu-xen \
---disable-guest-agent
+   --bindir=$PREFIX/lib/xen/bin \
+   --datadir=$PREFIX/share/qemu-xen \
+   --disable-kvm \
+   --disable-docs \
+   --disable-guest-agent
 $RAISIN_MAKE all
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 cd "$BASEDIR"
diff --git a/components/qemu_traditional b/components/qemu_traditional
index 3150c3e..8732fe2 100644
--- a/components/qemu_traditional
+++ b/components/qemu_traditional
@@ -30,7 +30,7 @@ function qemu_traditional_build() {
 
 export CONFIG_BLKTAP1=n
 export XEN_ROOT="$BASEDIR"/xen-dir
-./xen-setup
+./xen-setup --extra-cflags="-D__XEN_TOOLS__"
 $RAISIN_MAKE all
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 cd "$BASEDIR"
diff --git a/configs/config-4.7 b/configs/config-4.7
new file mode 100644
index 000..66fe467
--- /dev/null
+++ b/configs/config-4.7
@@ -0,0 +1,8 @@
+XEN_REVISION="origin/stable-4.7"
+QEMU_REVISION="origin/stable-4.7"
+QEMU_TRADITIONAL_REVISION="origin/stable-4.7"
+SEABIOS_REVISION="rel-1.9.2"
+GRUB_REVISION="master"
+LIBVIRT_REVISION="origin/v1.3.3-maint"
+OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
+LINUX_REVISION="master"
diff --git a/defconfig b/defconfig
index 8e79a43..f8ef398 100644
--- a/defconfig
+++ b/defconfig
@@ -2,7 +2,7 @@
 # Setup a Xen based system.
 
 # Available options: 4.5, 4.6, master (for development branch)
-XEN_RELEASE="4.6"
+XEN_RELEASE="4.7"
 
 # Components
 ## All components: seabios ovmf xen qemu qemu_traditional grub libvirt linux
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 5/7] hotplug/Linux: honour XEN_RUN_DIR

[Roger Pau Monné]

On Wed, Jun 15, 2016 at 12:15:07PM +0100, Wei Liu wrote:
> Store various PID files under XEN_RUN_DIR. Note that this change the
> default location from /var/run to /var/run/xen.
> 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

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

Re: [Xen-devel] [PATCH 4/7] hotplug/NetBSD: honour XEN_RUN_DIR

[Roger Pau Monné]

On Wed, Jun 15, 2016 at 12:15:06PM +0100, Wei Liu wrote:
> Store xldevd.pid under XEN_RUN_DIR. Note that this will change the
> default location from /var/run to /var/run/xen.
> 
> Signed-off-by: Wei Liu 

Acked-by: Roger Pau Monné 

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 17:46,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 15 June 2016 16:43
>> To: Paul Durrant
>> Cc: Sander Eikelenboom; xen-devel@lists.xen.org; Boris Ostrovsky
>> Subject: RE: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
>> emulate.c:144 RIP: c000:[<336a>]
>> 
>> >>> On 15.06.16 at 17:29,  wrote:
>> >>  -Original Message-
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 15 June 2016 16:22
>> >> To: Paul Durrant; Boris Ostrovsky
>> >> Cc: Sander Eikelenboom; xen-devel@lists.xen.org 
>> >> Subject: Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called
>> from
>> >> emulate.c:144 RIP: c000:[<336a>]
>> >>
>> >> >>> On 15.06.16 at 16:56,  wrote:
>> >> > On 06/15/2016 10:39 AM, Jan Beulich wrote:
>> >> > On 15.06.16 at 16:32,  wrote:
>> >> >>> So perhaps we shouldn't latch data for anything over page size.
>> >> >> But why? What we latch is the start of the accessed range, so
>> >> >> the repeat count shouldn't matter?
>> >> >
>> >> > Because otherwise we won't emulate full stos (or movs) --- we truncate
>> >> > *reps to fit into a page, don't we?
>> >>
>> >> That merely causes the instruction to get restarted (with a smaller
>> >> rCX).
>> >>
>> >> > And then we fail the completion check.
>> >> >
>> >> > And we should latch only when we don't cross page boundary, not just
>> >> > when we are under 4K. Or maybe it's not that we don't latch it. It's
>> >> > that we don't use latched data if page boundary is being crossed.
>> >>
>> >> Ah, I think that's it: When we hand a batch to qemu which crosses
>> >> a page boundary and latch the start address translation, upon
>> >> retry (after qemu did its job) we'd wrongly reduce the repeat count
>> >> because of finding the start address in the cache. So indeed I think
>> >> it should be the latter: Not using an available translation is likely
>> >> better than breaking up a large batch we hand to qemu. Paul, what
>> >> do you think?
>> >
>> > Presumably we can tell the difference because we have the vio ioreq state,
>> > which should tell us that we're waiting for I/O completion and so, in this
>> > case, you can avoid reducing the repeat count when retrying. You should
>> still
>> > be able to use the latched translation though, shouldn't you?
>> 
>> Would we want to rely on it despite crossing a page boundary?
>> Of course what was determined to be contiguous should
>> continue to be, so one might even say using the latched
>> translation in that case would provide more consistent results
>> (as we'd become independent of a guest page table change).
> 
> Yes, exactly.

The only downside is that this will need require peeking at
current->arch.hvm_vcpu.hvm_io.io_req.state, which would
(even if the source file is the same) be a mild layering violation.

>> But then again a MOVS has two memory operands ...
>> 
> 
> True... more of an argument for having two latched addresses though, right?

Yes, albeit two then isn't enough either if we want to fully address
the basic issue here: We'd have to latch as many translations as
there are possibly pages involved in the execution of a single
instruction.

Jan


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

Re: [Xen-devel] [PATCH RFC 2/2] xen: make available hvm_fep to non-debug build as well

[Wei Liu]

On Wed, Jun 15, 2016 at 11:12:08AM -0500, Doug Goldstein wrote:
> On 6/15/16 9:47 AM, Wei Liu wrote:
> > On Wed, Jun 15, 2016 at 09:39:24AM -0500, Doug Goldstein wrote:
> >> On 6/15/16 9:31 AM, Wei Liu wrote:
> > [...]
> >>> -#ifndef NDEBUG
> >>>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> >>>  extern bool_t opt_hvm_fep;
> >>> -#else
> >>> -#define opt_hvm_fep 0
> >>> -#endif
> >>
> >> Please instead add this as a Kconfig option and you can default it to
> >> enabled.
> >>
> > 
> > Sure, it is reasonable that you want to compile this out.
> > 
> > But which section does it belong to? Architecture Features I guess?
> > 
> > Wei.
> > 
> 
> That sounds reasonable to me. You can add it to arch/Kconfig if it makes
> sense for both ARM and x86.
> 

I think it should be x86 only for now. ARM doesn't have instruction
emulator.

Wei.

> -- 
> Doug Goldstein
> 




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

Re: [Xen-devel] [PATCH RFC 2/2] xen: make available hvm_fep to non-debug build as well

[Doug Goldstein]

On 6/15/16 9:47 AM, Wei Liu wrote:
> On Wed, Jun 15, 2016 at 09:39:24AM -0500, Doug Goldstein wrote:
>> On 6/15/16 9:31 AM, Wei Liu wrote:
> [...]
>>> -#ifndef NDEBUG
>>>  /* Permit use of the Forced Emulation Prefix in HVM guests */
>>>  extern bool_t opt_hvm_fep;
>>> -#else
>>> -#define opt_hvm_fep 0
>>> -#endif
>>
>> Please instead add this as a Kconfig option and you can default it to
>> enabled.
>>
> 
> Sure, it is reasonable that you want to compile this out.
> 
> But which section does it belong to? Architecture Features I guess?
> 
> Wei.
> 

That sounds reasonable to me. You can add it to arch/Kconfig if it makes
sense for both ARM and x86.

-- 
Doug Goldstein



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

Re: [Xen-devel] error while compiling Xen from the source

[Wei Liu]

On Wed, Jun 15, 2016 at 05:26:52PM +0200, Wim ten Have wrote:
> Running F23 here seemed to go trough good with above URL (making up much
> for my environment).
> 
> The only part causing me trouble is page specific direction setting the
> branch:
> 
> $ cd xen;
> *git checkout -b staging staging*
> 

It should have been

  git checkout -b staging origin/staging

Wei.

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

[Xen-devel] [xen-4.7-testing test] 95728: tolerable trouble: blocked/broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-xsm   3 host-install(3)  broken in 95653 pass in 95728
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 95653 pass in 95728
 test-amd64-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 95653 pass in 
95728
 test-amd64-i386-libvirt   3 host-install(3)   broken pass in 95653
 test-amd64-amd64-libvirt-pair  3 host-install/src_host(3) broken pass in 95653
 test-amd64-i386-freebsd10-i386  3 host-install(3) broken pass in 95653
 test-amd64-i386-libvirt-pair  4 host-install/dst_host(4)  broken pass in 95653
 test-amd64-i386-freebsd10-amd64  3 host-install(3)broken pass in 95653
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 3 host-install(3) broken pass in 95653
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken pass in 95653
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 95653
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 15 guest-localmigrate/x10 fail in 
95653 pass in 95728
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 95653 pass in 
95728

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 95446
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 95653 like 95446
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95446

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

version targeted for testing:
 xen  81722e7d443d33f48416c31f03ab4c2a9ba54b23
baseline version:
 xen  c2a17869d5dcd845d646bf4db122cad73596a2be

Last test of basis95446  2016-06-08 16:21:53 Z6 

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 June 2016 16:43
> To: Paul Durrant
> Cc: Sander Eikelenboom; xen-devel@lists.xen.org; Boris Ostrovsky
> Subject: RE: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
> emulate.c:144 RIP: c000:[<336a>]
> 
> >>> On 15.06.16 at 17:29,  wrote:
> >>  -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 15 June 2016 16:22
> >> To: Paul Durrant; Boris Ostrovsky
> >> Cc: Sander Eikelenboom; xen-devel@lists.xen.org
> >> Subject: Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called
> from
> >> emulate.c:144 RIP: c000:[<336a>]
> >>
> >> >>> On 15.06.16 at 16:56,  wrote:
> >> > On 06/15/2016 10:39 AM, Jan Beulich wrote:
> >> > On 15.06.16 at 16:32,  wrote:
> >> >>> So perhaps we shouldn't latch data for anything over page size.
> >> >> But why? What we latch is the start of the accessed range, so
> >> >> the repeat count shouldn't matter?
> >> >
> >> > Because otherwise we won't emulate full stos (or movs) --- we truncate
> >> > *reps to fit into a page, don't we?
> >>
> >> That merely causes the instruction to get restarted (with a smaller
> >> rCX).
> >>
> >> > And then we fail the completion check.
> >> >
> >> > And we should latch only when we don't cross page boundary, not just
> >> > when we are under 4K. Or maybe it's not that we don't latch it. It's
> >> > that we don't use latched data if page boundary is being crossed.
> >>
> >> Ah, I think that's it: When we hand a batch to qemu which crosses
> >> a page boundary and latch the start address translation, upon
> >> retry (after qemu did its job) we'd wrongly reduce the repeat count
> >> because of finding the start address in the cache. So indeed I think
> >> it should be the latter: Not using an available translation is likely
> >> better than breaking up a large batch we hand to qemu. Paul, what
> >> do you think?
> >
> > Presumably we can tell the difference because we have the vio ioreq state,
> > which should tell us that we're waiting for I/O completion and so, in this
> > case, you can avoid reducing the repeat count when retrying. You should
> still
> > be able to use the latched translation though, shouldn't you?
> 
> Would we want to rely on it despite crossing a page boundary?
> Of course what was determined to be contiguous should
> continue to be, so one might even say using the latched
> translation in that case would provide more consistent results
> (as we'd become independent of a guest page table change).

Yes, exactly.

> But then again a MOVS has two memory operands ...
> 

True... more of an argument for having two latched addresses though, right?

  Paul

> Jan


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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 17:29,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 15 June 2016 16:22
>> To: Paul Durrant; Boris Ostrovsky
>> Cc: Sander Eikelenboom; xen-devel@lists.xen.org 
>> Subject: Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
>> emulate.c:144 RIP: c000:[<336a>]
>> 
>> >>> On 15.06.16 at 16:56,  wrote:
>> > On 06/15/2016 10:39 AM, Jan Beulich wrote:
>> > On 15.06.16 at 16:32,  wrote:
>> >>> So perhaps we shouldn't latch data for anything over page size.
>> >> But why? What we latch is the start of the accessed range, so
>> >> the repeat count shouldn't matter?
>> >
>> > Because otherwise we won't emulate full stos (or movs) --- we truncate
>> > *reps to fit into a page, don't we?
>> 
>> That merely causes the instruction to get restarted (with a smaller
>> rCX).
>> 
>> > And then we fail the completion check.
>> >
>> > And we should latch only when we don't cross page boundary, not just
>> > when we are under 4K. Or maybe it's not that we don't latch it. It's
>> > that we don't use latched data if page boundary is being crossed.
>> 
>> Ah, I think that's it: When we hand a batch to qemu which crosses
>> a page boundary and latch the start address translation, upon
>> retry (after qemu did its job) we'd wrongly reduce the repeat count
>> because of finding the start address in the cache. So indeed I think
>> it should be the latter: Not using an available translation is likely
>> better than breaking up a large batch we hand to qemu. Paul, what
>> do you think?
> 
> Presumably we can tell the difference because we have the vio ioreq state, 
> which should tell us that we're waiting for I/O completion and so, in this 
> case, you can avoid reducing the repeat count when retrying. You should still 
> be able to use the latched translation though, shouldn't you?

Would we want to rely on it despite crossing a page boundary?
Of course what was determined to be contiguous should
continue to be, so one might even say using the latched
translation in that case would provide more consistent results
(as we'd become independent of a guest page table change).
But then again a MOVS has two memory operands ...

Jan


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

Re: [Xen-devel] error while compiling Xen from the source

[Meng Xu]

On Thu, Jun 2, 2016 at 11:22 AM, Safa Hamza  wrote:
> hello
> in order to build   Xen from the source on my host (Intel x86-x64 running
> Ubuntu mate)
> I downloaded Xen Source Code from
> git clone git://xenbits.xen.org/xen.gitthen
> git checkout -b RELEASE-4.3.1 RELEASE-4.3.1
> I configured it successfully but when I want to compiled, an error showed up
>
>
>
> cc1: all warnings being treated as errors
> /home/safa/xen/tools/blktap/drivers/../../../tools/Rules.mk:89: recipe for
> target 'block-qcow.o' failed
> make[5]: *** [block-qcow.o] Error 1
> make[5]: Leaving directory '/home/safa/xen/tools/blktap/drivers'
> /home/safa/xen/tools/blktap/../../tools/Rules.mk:105: recipe for target
> 'subdir-install-drivers' failed
> make[4]: *** [subdir-install-drivers] Error 2
> make[4]: Leaving directory '/home/safa/xen/tools/blktap'
> /home/safa/xen/tools/blktap/../../tools/Rules.mk:100: recipe for target
> 'subdirs-install' failed
> make[3]: *** [subdirs-install] Error 2
> make[3]: Leaving directory '/home/safa/xen/tools/blktap'
> /home/safa/xen/tools/../tools/Rules.mk:105: recipe for target
> 'subdir-install-blktap' failed
> make[2]: *** [subdir-install-blktap] Error 2
> make[2]: Leaving directory '/home/safa/xen/tools'
> /home/safa/xen/tools/../tools/Rules.mk:100: recipe for target
> 'subdirs-install' failed
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory '/home/safa/xen/tools'
> Makefile:74: recipe for target 'install-tools' failed
> make: *** [install-tools] Error 2
>
>
> how can I fix it... it may be a missing package!!  I didn't find the
> solution after spending a long time googling
> i  I’ll appreciate your help
>

There is a video about how to install RT-Xen at [1]. Since the
installation of RT-Xen and Xen are exactly same, you may want to have
a look and follow the video's instruciton. Hopefully it will be
helpful..

https://www.youtube.com/watch?v=PCIG5clWROo

Best,

Meng
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 15 June 2016 16:22
> To: Paul Durrant; Boris Ostrovsky
> Cc: Sander Eikelenboom; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from
> emulate.c:144 RIP: c000:[<336a>]
> 
> >>> On 15.06.16 at 16:56,  wrote:
> > On 06/15/2016 10:39 AM, Jan Beulich wrote:
> > On 15.06.16 at 16:32,  wrote:
> >>> So perhaps we shouldn't latch data for anything over page size.
> >> But why? What we latch is the start of the accessed range, so
> >> the repeat count shouldn't matter?
> >
> > Because otherwise we won't emulate full stos (or movs) --- we truncate
> > *reps to fit into a page, don't we?
> 
> That merely causes the instruction to get restarted (with a smaller
> rCX).
> 
> > And then we fail the completion check.
> >
> > And we should latch only when we don't cross page boundary, not just
> > when we are under 4K. Or maybe it's not that we don't latch it. It's
> > that we don't use latched data if page boundary is being crossed.
> 
> Ah, I think that's it: When we hand a batch to qemu which crosses
> a page boundary and latch the start address translation, upon
> retry (after qemu did its job) we'd wrongly reduce the repeat count
> because of finding the start address in the cache. So indeed I think
> it should be the latter: Not using an available translation is likely
> better than breaking up a large batch we hand to qemu. Paul, what
> do you think?

Presumably we can tell the difference because we have the vio ioreq state, 
which should tell us that we're waiting for I/O completion and so, in this 
case, you can avoid reducing the repeat count when retrying. You should still 
be able to use the latched translation though, shouldn't you?

  Paul 

> 
> In any event I'll revert the patch from staging, until I can provide
> a fixed one.
> 
> Jan


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

Re: [Xen-devel] Question about sharing spinlock_t among VMs in Xen

[Meng Xu]

On Tue, Jun 14, 2016 at 12:01 PM, Andrew Cooper
 wrote:
>
> On 14/06/16 03:13, Meng Xu wrote:
> > On Mon, Jun 13, 2016 at 6:54 PM, Andrew Cooper
> >  wrote:
> >> On 13/06/2016 18:43, Meng Xu wrote:
> >>> Hi,
> >>>
> >>> I have a quick question about using the Linux spin_lock() in Xen
> >>> environment to protect some host-wide shared (memory) resource among
> >>> VMs.
> >>>
> >>> *** The question is as follows ***
> >>> Suppose I have two Linux VMs sharing the same spinlock_t lock (through
> >>> the sharing memory) on the same host. Suppose we have one process in
> >>> each VM. Each process uses the linux function spin_lock() [1] to
> >>> grab & release the lock.
> >>> Will these two processes in the two VMs have race on the shared lock?
> >> "Race" is debatable.  (After all, the point of a lock is to have
> >> serialise multiple accessors).  But yes, this will be the same lock.
> >>
> >> The underlying cache coherency fabric will perform atomic locked
> >> operations on the same physical piece of RAM.
> > The experiment we did is on a computer that is not NUMA.
>
> Why do you think this makes any difference?  Unless you have a
> uni-processor system from ages ago, there will be cache coherency being
> done in hardware.
>
> > So it should not be caused by the sync. issue in hardware.
>
> I do not understand what you are trying to say here.


I was thinking if the x86 memory consistency model, i.e., TSO,  will
cause any issue? Should we use some memory barrier to sync. the memory
operation?

>
>
> >
> >> The important question is whether the two difference VMs have an
> >> identical idea of what a spinlock_t is.  If not, this will definitely fail.
> > I see the key point here now. However, I'm not that sure about if the
> > two VMs have an *identical idea* of what a spinlock_t is.
>
> If you are not sure, then the answer is almost certainly no.


Fair enough...

>
>
> > In otherwords, how to tell "if two VMs have an identical idea of what a
> > spinlock_t is"?
>
> Is struct spinlock_t, and all functions which modify it, identical
> between all VMs trying to participate in the use of this shared memory
> spinlock?


Yes. The spinlock_t and all functions which modify it are identical
between all VMs.
Does this mean they have the identical idea of what a spinlock_t is?

>
>
> >
> > The current situation is as follows:
> > Both VMs are using the same memory area for the spinlock_t variable.
> > The spin_lock() in both VMs are operating on the same spinlock_t
> > variable. So IMHO, the spinlock_t should be identical to these two
> > VMs?
> > Please correct me if I'm wrong. (I guess my understanding of the
> > "identical idea of spinlock_t" may probably be incorrect. :-( )
> >
> >>> My speculation is that it should have the race on the shard lock when
> >>> the spin_lock() function in *two VMs* operate on the same lock.
> >>>
> >>> We did some quick experiment on this and we found one VM sometimes see
> >>> the soft lockup on the lock. But we want to make sure our
> >>> understanding is correct.
> >>>
> >>> We are exploring if we can use the spin_lock to protect the shared
> >>> resources among VMs, instead of using the PV drivers. If the
> >>> spin_lock() in linux can provide the host-wide atomicity (which will
> >>> surprise me, though), that will be great. Otherwise, we probably have
> >>> to expose the spin_lock in Xen to the Linux?
> >> What are you attempting to protect like this?
> > For example, if two VMs are sharing a chunk of memory with both read
> > and write permissions, a VM has to grab the lock before it can operate
> > on the shared memory.
> > If we want a VM directly operate on the shared resource, instead of
> > using the PV device model, we may need to use spinlock to protect the
> > access to the shared resource. That's why we are looking at the
> > spinlock.
> >
> >> Anything which a guest can spin on like this is a recipe for disaster,
> >> as you observe, as the guest which holds the lock will get scheduled out
> >> in favour of the guest attempting to take the lock.
> > It is true in general. The reason why we choose to let it spin is
> > because some people in academia propose the protocols to access the
> > shared resource through spinlock. In order to apply their theory, we
> > may need to follow the system model they assumed. The theory did
> > consider the situation when a guest/VCPU that is spinning on a lock is
> > schedule out. The theory has to consider the extra delay caused by
> > this situation. [OK. This is the reason why we did like this. But we
> > are also thinking if we can do better in terms of the overall system
> > performance.]
> >
> > BTW, I agree with you that letting guest spin like this could be a
> > problem for the overall system performance.
> >
> >> Alternatively, two
> >> different guests with a different idea of how to manage the memory
> >> backing a spinlock_t.
> > Just to confirm:
> > Did you mean 

Re: [Xen-devel] error while compiling Xen from the source

[Wim ten Have]

Running F23 here seemed to go trough good with above URL (making up much
for my environment).

The only part causing me trouble is page specific direction setting the
branch:

$ cd xen;
*git checkout -b staging staging*


Instead I did here (and think it should be)

$ cd xen; *git checkout -b staging*

Example:


 git checkout -b staging
Switched to a new branch 'staging'


On Wed, Jun 15, 2016 at 5:07 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:

> On Fri, Jun 10, 2016 at 04:03:30PM +0100, Safa Hamza wrote:
> > i'm really confused
> > i build xen from the source in pc running ubuntu mate but while trying to
>
> Take a look at
> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source#Build_Dependencies_-_Debian_.2F_Ubuntu
> and follow the directions there.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] AMD IOMMU: correctly propagate errors from amd_iommu_init()

[Suravee Suthikulanit]

On 6/14/2016 4:09 AM, Andrew Cooper wrote:

On 14/06/16 10:03, Jan Beulich wrote:

... instead of using -ENODEV for any kind of error. It in particular
addresses Coverity ID 1362694 (introduced by commit eb48587210 ["AMD
IOMMU: introduce support for IVHD block type 11h"]).

Coverity ID: 1362694

Signed-off-by: Jan Beulich 


Reviewed-by: Andrew Cooper 




Reviewed-by: Suravee Suthikulpanit 
Tested-by: Suravee Suthikulpanit 

Thank you for the fix up.

Suravee

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 16:56,  wrote:
> On 06/15/2016 10:39 AM, Jan Beulich wrote:
> On 15.06.16 at 16:32,  wrote:
>>> So perhaps we shouldn't latch data for anything over page size.
>> But why? What we latch is the start of the accessed range, so
>> the repeat count shouldn't matter?
> 
> Because otherwise we won't emulate full stos (or movs) --- we truncate
> *reps to fit into a page, don't we?

That merely causes the instruction to get restarted (with a smaller
rCX).

> And then we fail the completion check.
> 
> And we should latch only when we don't cross page boundary, not just
> when we are under 4K. Or maybe it's not that we don't latch it. It's
> that we don't use latched data if page boundary is being crossed.

Ah, I think that's it: When we hand a batch to qemu which crosses
a page boundary and latch the start address translation, upon
retry (after qemu did its job) we'd wrongly reduce the repeat count
because of finding the start address in the cache. So indeed I think
it should be the latter: Not using an available translation is likely
better than breaking up a large batch we hand to qemu. Paul, what
do you think?

In any event I'll revert the patch from staging, until I can provide
a fixed one.

Jan


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

Re: [Xen-devel] error while compiling Xen from the source

[Konrad Rzeszutek Wilk]

On Fri, Jun 10, 2016 at 04:03:30PM +0100, Safa Hamza wrote:
> i'm really confused
> i build xen from the source in pc running ubuntu mate but while trying to

Take a look at 
http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source#Build_Dependencies_-_Debian_.2F_Ubuntu
and follow the directions there.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl   3 host-install(3) broken REGR. vs. 94856
 test-amd64-i386-xl3 host-install(3) broken REGR. vs. 94856
 test-amd64-amd64-libvirt-pair 3 host-install/src_host(3) broken REGR. vs. 94856
 test-amd64-amd64-amd64-pvgrub  3 host-install(3)broken REGR. vs. 94856
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3)   broken REGR. vs. 94856
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 94856
 test-amd64-i386-libvirt-xsm   3 host-install(3) broken REGR. vs. 94856
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 94856
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 94856
 test-armhf-armhf-libvirt  5 xen-install   fail REGR. vs. 94856
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1fail REGR. vs. 94856
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat fail REGR. vs. 94856
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 94856

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94856
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94856
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94856

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

version targeted for testing:
 qemuud32490ca74c700edc74f0b2f6b7536b52a644739
baseline version:
 qemuud6550e9ed2e1a60d889dfb721de00d9a4e3bafbe

Last test of basis94856  2016-05-27 20:14:49 Z   18 days
Failing since 94983  2016-05-31 09:40:12 Z   15 days   19 attempts
Testing same since95724  2016-06-14 14:27:36 Z1 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Alex Bligh 
  Alexander Graf 
  Alexey Kardashevskiy 
  Alistair Francis 
  Anthony PERARD 
  Anton Blanchard 
  Ard Biesheuvel 
  Benjamin Herrenschmidt 
  Bharata B Rao 
  Cao jin 
  Changlong Xie 
  Chen Fan 
  Christian Borntraeger 
  Cole Robinson 
  Colin Lord 
  Corey Minyard 

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Boris Ostrovsky]

On 06/15/2016 10:39 AM, Jan Beulich wrote:
 On 15.06.16 at 16:32,  wrote:
>> So perhaps we shouldn't latch data for anything over page size.
> But why? What we latch is the start of the accessed range, so
> the repeat count shouldn't matter?

Because otherwise we won't emulate full stos (or movs) --- we truncate
*reps to fit into a page, don't we? And then we fail the completion check.

And we should latch only when we don't cross page boundary, not just
when we are under 4K. Or maybe it's not that we don't latch it. It's
that we don't use latched data if page boundary is being crossed.


-boris


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

Re: [Xen-devel] [PATCH RFC 1/2] xen/kernel: document 'C' in print_tainted

[Jan Beulich]

>>> On 15.06.16 at 16:31,  wrote:
> Signed-off-by: Wei Liu 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH RFC 2/2] xen: make available hvm_fep to non-debug build as well

[Wei Liu]

On Wed, Jun 15, 2016 at 09:39:24AM -0500, Doug Goldstein wrote:
> On 6/15/16 9:31 AM, Wei Liu wrote:
[...]
> > -#ifndef NDEBUG
> >  /* Permit use of the Forced Emulation Prefix in HVM guests */
> >  extern bool_t opt_hvm_fep;
> > -#else
> > -#define opt_hvm_fep 0
> > -#endif
> 
> Please instead add this as a Kconfig option and you can default it to
> enabled.
> 

Sure, it is reasonable that you want to compile this out.

But which section does it belong to? Architecture Features I guess?

Wei.

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

Re: [Xen-devel] [PATCH RFC 2/2] xen: make available hvm_fep to non-debug build as well

[Doug Goldstein]

On 6/15/16 9:31 AM, Wei Liu wrote:
> Originally hvm_fep was guarded by NDEBUG, which means it was only
> available to debug builds.
> 
> However there is value to have it for non-debug builds as well. User can
> use that to run tests in setup that replicates production setup.
> 
> Make it clear with a sync_console style warning that this option can't
> be used in production setup. Update command line documentation
> accordingly. Finally mark Xen as tainted when this option is enabled.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Andrew Cooper 
> Cc: Jan Beulich 
> ---
>  docs/misc/xen-command-line.markdown |  8 ++--
>  xen/arch/x86/hvm/hvm.c  | 31 ---
>  xen/common/kernel.c |  6 --
>  xen/include/asm-x86/hvm/hvm.h   |  4 
>  xen/include/xen/lib.h   |  1 +
>  5 files changed, 39 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown 
> b/docs/misc/xen-command-line.markdown
> index fed732c..dc53e24 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -878,8 +878,12 @@ Recognized in debug builds of the hypervisor only.
>  Allow use of the Forced Emulation Prefix in HVM guests, to allow emulation of
>  arbitrary instructions.
>  
> -This option is intended for development purposes, and is only available in
> -debug builds of the hypervisor.
> +This option is intended for development and testing purposes.
> +
> +*Warning*
> +As this feature opens up the instruction emulator to HVM guest, don't
> +use this in production system. No security support is provided when
> +this flag is set.
>  
>  ### hvm\_port80
>  > `= `
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 78db903..5bafaef 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -37,6 +37,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -95,11 +96,9 @@ unsigned long __section(".bss.page_aligned")
>  static bool_t __initdata opt_hap_enabled = 1;
>  boolean_param("hap", opt_hap_enabled);
>  
> -#ifndef opt_hvm_fep
>  /* Permit use of the Forced Emulation Prefix in HVM guests */
> -bool_t opt_hvm_fep;
> +bool_t __read_mostly opt_hvm_fep;
>  boolean_param("hvm_fep", opt_hvm_fep);
> -#endif
>  
>  /* Xen command-line option to enable altp2m */
>  static bool_t __initdata opt_altp2m_enabled = 0;
> @@ -182,6 +181,32 @@ static int __init hvm_enable(void)
>  if ( !opt_altp2m_enabled )
>  hvm_funcs.altp2m_supported = 0;
>  
> +if ( opt_hvm_fep )
> +{
> +unsigned i, j;
> +
> +printk("**\n");
> +printk("*** WARNING: HVM FORCED EMULATION PREFIX IS 
> PERMITTED\n");
> +printk("*** This option is *ONLY* intended to aid debugging "
> +   "and testing of Xen\n");
> +printk("*** that HVM guest can enter instruction emulator "
> +   "with UD instruction.\n");
> +printk("*** It has implication on the security of the 
> system.\n");
> +printk("*** Please *DO NOT* use this in production.\n");
> +printk("**\n");
> +add_taint(TAINT_HVM_FEP);
> +for ( i = 0; i < 3; i++ )
> +{
> +printk("%d... ", 3-i);
> +for ( j = 0; j < 100; j++ )
> +{
> +process_pending_softirqs();
> +mdelay(10);
> +}
> +}
> +printk("\n");
> +}
> +
>  /*
>   * Allow direct access to the PC debug ports 0x80 and 0xed (they are
>   * often used for I/O delays, but the vmexits simply slow things down).
> diff --git a/xen/common/kernel.c b/xen/common/kernel.c
> index dae7e35..5bf77aa 100644
> --- a/xen/common/kernel.c
> +++ b/xen/common/kernel.c
> @@ -175,6 +175,7 @@ int __init parse_bool(const char *s)
>   *  'M' - Machine had a machine check experience.
>   *  'B' - System has hit bad_page.
>   *  'C' - Console output is synchronous.
> + *  'H' - HVM forced emulation prefix is permitted.
>   *
>   *  The string is overwritten by the next call to print_taint().
>   */
> @@ -182,11 +183,12 @@ char *print_tainted(char *str)
>  {
>  if ( tainted )
>  {
> -snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c",
> +snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c%c",
>   tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
>   tainted & TAINT_MACHINE_CHECK ? 'M' : ' ',
>   tainted & TAINT_BAD_PAGE ? 'B' : ' ',
> - tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ');
> + tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ',
> + tainted & TAINT_HVM_FEP ? 'H' : ' ');
>  }
>  else
>  {
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 16:32,  wrote:
> So perhaps we shouldn't latch data for anything over page size.

But why? What we latch is the start of the accessed range, so
the repeat count shouldn't matter?

> Something like this (it seems to work):

I'm rather hesitant to take a change like this without understanding
why this helps nor whether this really deals with the problem in all
cases.

Jan

> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1195,7 +1195,8 @@ static int hvmemul_rep_movs(
>  if ( rc != X86EMUL_OKAY )
>  return rc;
>  
> -latch_linear_to_phys(vio, saddr, sgpa, 0);
> +if ( *reps * bytes_per_rep <= PAGE_SIZE)
> +latch_linear_to_phys(vio, saddr, sgpa, 0);
>  }
>  
>  bytes = PAGE_SIZE - (daddr & ~PAGE_MASK);
> @@ -1214,7 +1215,8 @@ static int hvmemul_rep_movs(
>  if ( rc != X86EMUL_OKAY )
>  return rc;
>  
> -latch_linear_to_phys(vio, daddr, dgpa, 1);
> +if ( *reps * bytes_per_rep <= PAGE_SIZE)
> +latch_linear_to_phys(vio, daddr, dgpa, 1);
>  }
>  
>  /* Check for MMIO ops */
> @@ -1339,7 +1341,8 @@ static int hvmemul_rep_stos(
>  if ( rc != X86EMUL_OKAY )
>  return rc;
>  
> -latch_linear_to_phys(vio, addr, gpa, 1);
> +if ( *reps * bytes_per_rep <= PAGE_SIZE)
> +latch_linear_to_phys(vio, addr, gpa, 1);
>  }
>  
>  /* Check for MMIO op */




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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 16:20,  wrote:
> On 06/15/2016 10:07 AM, Jan Beulich wrote:
> On 15.06.16 at 15:58,  wrote:
>>> Wednesday, June 15, 2016, 2:48:55 PM, you wrote:
 Apart from that, and just to see whether there are other differences
 between your guest(s) and mine, could you post a guest config from
 one that's affected?
>>> Hope you are not too disappointed it's rather sparse:
>> In no way.
>>
>>> builder='hvm'
>>> device_model_version = 'qemu-xen'
>>> device_model_user = 'root'
>>> memory = 512
>>> name = 'test_guest'
>>> vcpus = 4
>>> cpu_weight = 768
>>> vif = [ 'bridge=xen_bridge, ip=192.168.1.15, mac=00:16:3E:C4:72:83, 
>>> model=e1000' ]
>>> disk = [ 'phy:/dev/xen_vms/test_guest1,hda,w', 
>>> 'phy:/dev/xen_vms/test_guest2,hdb,w' ]
>>> on_crash = 'preserve'
>>> boot='c'
>>> vnc=0
>>> serial='pty'
>> I wonder whether mine having
>>
>> stdvga=0
>>
>> matters. Albeit a quick test passing stdvga=1 works here. And I
>> don't think the vnc= setting should have an effect here.
> 
> Our nightly picked up this crash as well on an AMD box (Intel passed).
> 
> I believe this is due to
> 
> +   if ( *reps * bytes_per_rep > bytes )
> +*reps = bytes / bytes_per_rep;
> 
> in hvmemul_rep_stos() and then, as you pointed out in another message,
> we fail p.count > *reps comparison.

But the really interesting thing then is - why only AMD?

Jan


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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Boris Ostrovsky]

On 06/15/2016 10:20 AM, Boris Ostrovsky wrote:
> On 06/15/2016 10:07 AM, Jan Beulich wrote:
> On 15.06.16 at 15:58,  wrote:
>>> Wednesday, June 15, 2016, 2:48:55 PM, you wrote:
 Apart from that, and just to see whether there are other differences
 between your guest(s) and mine, could you post a guest config from
 one that's affected?
>>> Hope you are not too disappointed it's rather sparse:
>> In no way.
>>
>>> builder='hvm'
>>> device_model_version = 'qemu-xen'
>>> device_model_user = 'root'
>>> memory = 512
>>> name = 'test_guest'
>>> vcpus = 4
>>> cpu_weight = 768
>>> vif = [ 'bridge=xen_bridge, ip=192.168.1.15, mac=00:16:3E:C4:72:83, 
>>> model=e1000' ]
>>> disk = [ 'phy:/dev/xen_vms/test_guest1,hda,w', 
>>> 'phy:/dev/xen_vms/test_guest2,hdb,w' ]
>>> on_crash = 'preserve'
>>> boot='c'
>>> vnc=0
>>> serial='pty'
>> I wonder whether mine having
>>
>> stdvga=0
>>
>> matters. Albeit a quick test passing stdvga=1 works here. And I
>> don't think the vnc= setting should have an effect here.
> Our nightly picked up this crash as well on an AMD box (Intel passed).
>
> I believe this is due to
>
> +   if ( *reps * bytes_per_rep > bytes )
> +*reps = bytes / bytes_per_rep;
>
> in hvmemul_rep_stos() and then, as you pointed out in another message,
> we fail p.count > *reps comparison.
>
> -boris
>
> -boris
> in hvmemul_rep_stos.
>


So perhaps we shouldn't latch data for anything over page size.
Something like this (it seems to work):

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index d164092..6fabb76 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1195,7 +1195,8 @@ static int hvmemul_rep_movs(
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-latch_linear_to_phys(vio, saddr, sgpa, 0);
+if ( *reps * bytes_per_rep <= PAGE_SIZE)
+latch_linear_to_phys(vio, saddr, sgpa, 0);
 }
 
 bytes = PAGE_SIZE - (daddr & ~PAGE_MASK);
@@ -1214,7 +1215,8 @@ static int hvmemul_rep_movs(
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-latch_linear_to_phys(vio, daddr, dgpa, 1);
+if ( *reps * bytes_per_rep <= PAGE_SIZE)
+latch_linear_to_phys(vio, daddr, dgpa, 1);
 }
 
 /* Check for MMIO ops */
@@ -1339,7 +1341,8 @@ static int hvmemul_rep_stos(
 if ( rc != X86EMUL_OKAY )
 return rc;
 
-latch_linear_to_phys(vio, addr, gpa, 1);
+if ( *reps * bytes_per_rep <= PAGE_SIZE)
+latch_linear_to_phys(vio, addr, gpa, 1);
 }
 
 /* Check for MMIO op */


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

[Xen-devel] [PATCH RFC 0/2] Make hvm_fep available to non-debug builds

[Wei Liu]

Wei Liu (2):
  xen/kernel: document 'C' in print_tainted
  xen: make available hvm_fep to non-debug build as well

 docs/misc/xen-command-line.markdown |  8 ++--
 xen/arch/x86/hvm/hvm.c  | 31 ---
 xen/common/kernel.c |  7 +--
 xen/include/asm-x86/hvm/hvm.h   |  4 
 xen/include/xen/lib.h   |  1 +
 5 files changed, 40 insertions(+), 11 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH RFC 2/2] xen: make available hvm_fep to non-debug build as well

[Wei Liu]

Originally hvm_fep was guarded by NDEBUG, which means it was only
available to debug builds.

However there is value to have it for non-debug builds as well. User can
use that to run tests in setup that replicates production setup.

Make it clear with a sync_console style warning that this option can't
be used in production setup. Update command line documentation
accordingly. Finally mark Xen as tainted when this option is enabled.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
 docs/misc/xen-command-line.markdown |  8 ++--
 xen/arch/x86/hvm/hvm.c  | 31 ---
 xen/common/kernel.c |  6 --
 xen/include/asm-x86/hvm/hvm.h   |  4 
 xen/include/xen/lib.h   |  1 +
 5 files changed, 39 insertions(+), 11 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index fed732c..dc53e24 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -878,8 +878,12 @@ Recognized in debug builds of the hypervisor only.
 Allow use of the Forced Emulation Prefix in HVM guests, to allow emulation of
 arbitrary instructions.
 
-This option is intended for development purposes, and is only available in
-debug builds of the hypervisor.
+This option is intended for development and testing purposes.
+
+*Warning*
+As this feature opens up the instruction emulator to HVM guest, don't
+use this in production system. No security support is provided when
+this flag is set.
 
 ### hvm\_port80
 > `= `
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 78db903..5bafaef 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -95,11 +96,9 @@ unsigned long __section(".bss.page_aligned")
 static bool_t __initdata opt_hap_enabled = 1;
 boolean_param("hap", opt_hap_enabled);
 
-#ifndef opt_hvm_fep
 /* Permit use of the Forced Emulation Prefix in HVM guests */
-bool_t opt_hvm_fep;
+bool_t __read_mostly opt_hvm_fep;
 boolean_param("hvm_fep", opt_hvm_fep);
-#endif
 
 /* Xen command-line option to enable altp2m */
 static bool_t __initdata opt_altp2m_enabled = 0;
@@ -182,6 +181,32 @@ static int __init hvm_enable(void)
 if ( !opt_altp2m_enabled )
 hvm_funcs.altp2m_supported = 0;
 
+if ( opt_hvm_fep )
+{
+unsigned i, j;
+
+printk("**\n");
+printk("*** WARNING: HVM FORCED EMULATION PREFIX IS PERMITTED\n");
+printk("*** This option is *ONLY* intended to aid debugging "
+   "and testing of Xen\n");
+printk("*** that HVM guest can enter instruction emulator "
+   "with UD instruction.\n");
+printk("*** It has implication on the security of the system.\n");
+printk("*** Please *DO NOT* use this in production.\n");
+printk("**\n");
+add_taint(TAINT_HVM_FEP);
+for ( i = 0; i < 3; i++ )
+{
+printk("%d... ", 3-i);
+for ( j = 0; j < 100; j++ )
+{
+process_pending_softirqs();
+mdelay(10);
+}
+}
+printk("\n");
+}
+
 /*
  * Allow direct access to the PC debug ports 0x80 and 0xed (they are
  * often used for I/O delays, but the vmexits simply slow things down).
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index dae7e35..5bf77aa 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -175,6 +175,7 @@ int __init parse_bool(const char *s)
  *  'M' - Machine had a machine check experience.
  *  'B' - System has hit bad_page.
  *  'C' - Console output is synchronous.
+ *  'H' - HVM forced emulation prefix is permitted.
  *
  *  The string is overwritten by the next call to print_taint().
  */
@@ -182,11 +183,12 @@ char *print_tainted(char *str)
 {
 if ( tainted )
 {
-snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c",
+snprintf(str, TAINT_STRING_MAX_LEN, "Tainted: %c%c%c%c%c",
  tainted & TAINT_UNSAFE_SMP ? 'S' : ' ',
  tainted & TAINT_MACHINE_CHECK ? 'M' : ' ',
  tainted & TAINT_BAD_PAGE ? 'B' : ' ',
- tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ');
+ tainted & TAINT_SYNC_CONSOLE ? 'C' : ' ',
+ tainted & TAINT_HVM_FEP ? 'H' : ' ');
 }
 else
 {
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index f486ee9..217112d 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -27,12 +27,8 @@
 #include 
 #include 
 
-#ifndef NDEBUG
 /* Permit use of the Forced Emulation Prefix in HVM guests */
 extern bool_t opt_hvm_fep;
-#else
-#define opt_hvm_fep 0
-#endif
 
 /* 

[Xen-devel] [PATCH RFC 1/2] xen/kernel: document 'C' in print_tainted

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/common/kernel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 1a6823a..dae7e35 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -174,6 +174,7 @@ int __init parse_bool(const char *s)
  *  'S' - SMP with CPUs not designed for SMP.
  *  'M' - Machine had a machine check experience.
  *  'B' - System has hit bad_page.
+ *  'C' - Console output is synchronous.
  *
  *  The string is overwritten by the next call to print_taint().
  */
-- 
2.1.4


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

Re: [Xen-devel] Make hvm_fep available to non-debug build as well?

[Wei Liu]

On Tue, Jun 14, 2016 at 12:36:09PM +0100, Andrew Cooper wrote:
> On 14/06/16 11:54, Jan Beulich wrote:
>  On 14.06.16 at 12:47,  wrote:
> >> Andrew and I had a short conversation on IRC about why hvm_fep is only
> >> available to debug build. Here is what he said:
> >>
> >>  liuw: because hvm_fep puts a very large attack surface back
> >>   into the hypervisor
> >>  I intoduced it originally to make it easy to test the
> >>   instruction emulator without requiring a race condition between 
> >> two
> >>   vcpus
> >>  so I guess paranoia is the underlying answer to your question
> >>  there is nothing wrong in principle with making available in
> >>   non-debug builds
> >>
> >> I think I agree with him that in principle it should be possible to
> >> make hvm_fep available to non-debug build. Andrew also suggested a
> >> sync_console style warning, which I think makes sense.
> > Properly documented I'm not heavily opposed (but also not fully
> > convinced of this being a good idea).
> 
> I have had one case where I needed to make FEP available in non-debug
> build, as a bug I was chasing had its repro symptoms disappeared in a
> debug build. 
> (https://github.com/xenserver/xen-4.6.pg/commit/5826deab561dd92efaaeeb222c27184be257fad5
> for those who are interested)
> 
> So long as it is obvious when it is enabled, I am a hesitant +1.
> 

OK, I think I can start writing patch(es) to do that now.

Wei.

> ~Andrew

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Boris Ostrovsky]

On 06/15/2016 10:07 AM, Jan Beulich wrote:
 On 15.06.16 at 15:58,  wrote:
>> Wednesday, June 15, 2016, 2:48:55 PM, you wrote:
>>> Apart from that, and just to see whether there are other differences
>>> between your guest(s) and mine, could you post a guest config from
>>> one that's affected?
>> Hope you are not too disappointed it's rather sparse:
> In no way.
>
>> builder='hvm'
>> device_model_version = 'qemu-xen'
>> device_model_user = 'root'
>> memory = 512
>> name = 'test_guest'
>> vcpus = 4
>> cpu_weight = 768
>> vif = [ 'bridge=xen_bridge, ip=192.168.1.15, mac=00:16:3E:C4:72:83, 
>> model=e1000' ]
>> disk = [ 'phy:/dev/xen_vms/test_guest1,hda,w', 
>> 'phy:/dev/xen_vms/test_guest2,hdb,w' ]
>> on_crash = 'preserve'
>> boot='c'
>> vnc=0
>> serial='pty'
> I wonder whether mine having
>
> stdvga=0
>
> matters. Albeit a quick test passing stdvga=1 works here. And I
> don't think the vnc= setting should have an effect here.

Our nightly picked up this crash as well on an AMD box (Intel passed).

I believe this is due to

+   if ( *reps * bytes_per_rep > bytes )
+*reps = bytes / bytes_per_rep;

in hvmemul_rep_stos() and then, as you pointed out in another message,
we fail p.count > *reps comparison.

-boris

-boris
in hvmemul_rep_stos.


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

[Xen-devel] efd1535 xen-blkfront: don't call talk_to_blkback when already connected to blkback and 2a6f71a xen-blkfront: fix resume issues after a migration

[Konrad Rzeszutek Wilk]

Heya!

Please put on the 4.6 stable tree these two following patches:

2a6f71a xen-blkfront: fix resume issues after a migration
efd1535 xen-blkfront: don't call talk_to_blkback when already connected to 
blkback

And for the 4.5 stable tree:

2a6f71a xen-blkfront: fix resume issues after a migration

The impact is that without these patches the migration of a guest
using Linux v4.5, or v4.6 falls on its face.

Thanks.

P.S.
When I sent the patch to Jens Axboe I forgot to put Cc: sta...@vger.kernel.org
on it. Sorry!

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

Re: [Xen-devel] [PATCH 1/2] xen-blkfront: don't call talk_to_blkback when already connected to blkback

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2016 at 09:39:00AM +0100, Ross Lagerwall wrote:
> On 06/08/2016 03:47 PM, Konrad Rzeszutek Wilk wrote:
> >On Wed, Jun 08, 2016 at 02:46:38PM +0800, Bob Liu wrote:
> >>
> >>On 06/07/2016 11:25 PM, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Jun 01, 2016 at 01:49:23PM +0800, Bob Liu wrote:
> 
> On 06/01/2016 04:33 AM, Konrad Rzeszutek Wilk wrote:
> >On Tue, May 31, 2016 at 04:59:16PM +0800, Bob Liu wrote:
> >>Sometimes blkfont may receive twice blkback_changed() notification after
> >>migration, then talk_to_blkback() will be called twice too and confused
> >>xen-blkback.
> >
> ... snip
> But sometimes blkfront receives
> blkback_changed() event more than once!
> >>>
> >>>I think I know why. The udev scripts that get invoked when when
> >>>we attach a disk are a bit custom. As such I think they just
> >>>revalidate the size leading to this.
> >>>
> >>>And this 'poke-at-XenbusStateConnected' state multiple times
> >>>is allowed. It is used to signal disk changes (or just to revalidate).
> >>>Hence it does not matter why really - we need to deal with this.
> >>>
> >>>I modified your patch a bit and are testing it:
> >>>
> >>
> >>Looks much better, thank you very much!
> >
> >Great! I also had it tested overnight and there was no hitch will send it
> >out soon.
> >
> 
> I'd like to request that this patch is backported to Linux 4.5 and both of
> the patches in this series are backported to Linux 4.6. This is affecting
> Debian Testing (using Linux 4.6). It fails to recover its disk when resuming
> or migrating.

Good idea. Done.
> 
> Thanks,
> -- 
> Ross Lagerwall

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 15:58,  wrote:
> Wednesday, June 15, 2016, 2:48:55 PM, you wrote:
>> Apart from that, and just to see whether there are other differences
>> between your guest(s) and mine, could you post a guest config from
>> one that's affected?
> 
> Hope you are not too disappointed it's rather sparse:

In no way.

> builder='hvm'
> device_model_version = 'qemu-xen'
> device_model_user = 'root'
> memory = 512
> name = 'test_guest'
> vcpus = 4
> cpu_weight = 768
> vif = [ 'bridge=xen_bridge, ip=192.168.1.15, mac=00:16:3E:C4:72:83, 
> model=e1000' ]
> disk = [ 'phy:/dev/xen_vms/test_guest1,hda,w', 
> 'phy:/dev/xen_vms/test_guest2,hdb,w' ]
> on_crash = 'preserve'
> boot='c'
> vnc=0
> serial='pty'

I wonder whether mine having

stdvga=0

matters. Albeit a quick test passing stdvga=1 works here. And I
don't think the vnc= setting should have an effect here.

Jan


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

Re: [Xen-devel] [PATCH raisin 3/4] Update config-4.6 and config-4.5 to point to stable branches

[Stefano Stabellini]

On Wed, 15 Jun 2016, George Dunlap wrote:
> On 15/06/16 11:53, Stefano Stabellini wrote:
> > On Wed, 15 Jun 2016, George Dunlap wrote:
> >> On 15/06/16 11:24, Stefano Stabellini wrote:
> >>> On Tue, 14 Jun 2016, George Dunlap wrote:
>  On 14/06/16 11:01, Stefano Stabellini wrote:
> > On Tue, 14 Jun 2016, George Dunlap wrote:
> >> On 14/06/16 10:40, Stefano Stabellini wrote:
> >>> On Mon, 13 Jun 2016, George Dunlap wrote:
>  Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branches.
> 
>  And point the default libvirt to point to the libvirt 1.3.3
>  maintenance branch, rather than xen-tested-master.
> 
>  Also update OVMF revision for 4.6 to a version that builds with 
>  modern
>  gccs.
> 
>  Singed-off-by: George Dunlap 
> 
>  CC: Stefano Stabellini 
>  ---
>   configs/config-4.5 | 6 +++---
>   configs/config-4.6 | 8 
>   configs/config-master  | 3 +++
>   configs/config-url-git | 2 +-
>   4 files changed, 11 insertions(+), 8 deletions(-)
> 
>  diff --git a/configs/config-4.5 b/configs/config-4.5
>  index 4163b68..8db9a9d 100644
>  --- a/configs/config-4.5
>  +++ b/configs/config-4.5
>  @@ -1,8 +1,8 @@
>   XEN_REVISION="origin/stable-4.5"
>  -QEMU_REVISION="master"
>  -QEMU_TRADITIONAL_REVISION="master"
>  +QEMU_REVISION="origin/stable-4.5"
>  +QEMU_TRADITIONAL_REVISION="origin/stable-4.5"
>   SEABIOS_REVISION="rel-1.7.5"
>   GRUB_REVISION="master"
>  -LIBVIRT_REVISION="origin/xen-tested-master"
>  +LIBVIRT_REVISION="origin/v1.3.3-maint"
>   OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>   LINUX_REVISION="master"
>  diff --git a/configs/config-4.6 b/configs/config-4.6
>  index e8b2a09..b003a30 100644
>  --- a/configs/config-4.6
>  +++ b/configs/config-4.6
>  @@ -1,8 +1,8 @@
>   XEN_REVISION="origin/stable-4.6"
>  -QEMU_REVISION="master"
>  -QEMU_TRADITIONAL_REVISION="master"
>  +QEMU_REVISION="origin/stable-4.6"
>  +QEMU_TRADITIONAL_REVISION="origin/stable-4.6"
>   SEABIOS_REVISION="rel-1.8.2"
>   GRUB_REVISION="master"
>  -LIBVIRT_REVISION="origin/xen-tested-master"
>  -OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
>  +LIBVIRT_REVISION="origin/v1.3.3-maint"
>  +OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
>   LINUX_REVISION="master"
>  diff --git a/configs/config-master b/configs/config-master
>  index bd26ce3..fce7436 100644
>  --- a/configs/config-master
>  +++ b/configs/config-master
>  @@ -6,3 +6,6 @@ GRUB_REVISION="master"
>   LIBVIRT_REVISION="origin/xen-tested-master"
>   OVMF_REVISION="origin/xen-tested-master"
>   LINUX_REVISION="master"
>  +
>  +# oss-tested branch
>  +LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
> >>>
> >>> Why keep this around? I would remove it.
> >>
> >> Because...
> >>
>  diff --git a/configs/config-url-git b/configs/config-url-git
>  index 79813c4..614f522 100644
>  --- a/configs/config-url-git
>  +++ b/configs/config-url-git
>  @@ -3,6 +3,6 @@ QEMU_URL="git://xenbits.xen.org/qemu-xen.git"
>   
>  QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-traditional.git"
>   SEABIOS_URL="git://xenbits.xen.org/seabios.git"
>   GRUB_URL="git://git.savannah.gnu.org/grub.git"
>  -LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
>  +LIBVIRT_URL="git://libvirt.org/libvirt.git"
> >>
> >> ...here, the LIBVIRT_URL in config-url-git is set to the libvirt.org 
> >> URL
> >> so that the stable releases can be pointed to v1.3.3-maint instead. The
> >> xen.org repo doesn't contain the v1.3.3-maint branch, and the
> >> libvirt.org repo doesn't contain the 'xen-tested-master' branch.
> >>
> >> I admit this is a bit ugly, *almost* separating things entirely but 
> >> then
> >> not. But I don't see another easy way of having both the 1.3.3
> >> maintenance branch and the oss-tested branch. (Unless we started having
> >> osstest test the maintenance branch as well.)
> >  
> > I would drop git://xenbits.xen.org/libvirt.git and xen-tested-master
> > entirely and just stick to v1.3.3-maint everywhere. Or the other way
> > around.
> 
>  Well I assume that people building one of the releases want something
>  relatively stable and supported, so xen-tested-master is obviously
>  unsuitable (and might not actually be capable of building against Xen
>  versions older than a certain point due to 

Re: [Xen-devel] [PATCH v5 1/2] x86/mem-sharing: Bulk mem-sharing entire domains

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2016 at 02:14:15AM -0600, Jan Beulich wrote:
> >>> On 14.06.16 at 18:33,  wrote:
> >> +/* Check for continuation if it's not the last iteration. */
> >> +if ( limit > ++bulk->start && hypercall_preempt_check() )
> > 
> > I surprised the compiler didn't complain to you about lack of parenthesis.
> 
> I'm puzzled - what kind of warning would you expect here? The
> compiler -  afaik - treats relational operators vs logical AND/OR as
> having well known precedence wrt to one another; what iirc it
> would warn about is lack of parentheses in an expression using
> both of the logical operators, as people frequently don't know
> that && has higher precedence than ||.

Maybe those are the warnings I had seen in the past. I recall
that with a more modern compiler it would give me suggestions to
use parenthesis. But I honestly can't recall the details.

Either way - the code is fine.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH 2/3] Update to use a .config file

[Konrad Rzeszutek Wilk]

On Wed, Jun 15, 2016 at 09:08:46AM +0100, Ross Lagerwall wrote:
> On 06/14/2016 04:35 PM, Konrad Rzeszutek Wilk wrote:
> >On Fri, Jun 10, 2016 at 12:02:44PM +0100, Ross Lagerwall wrote:
> >>Remove the old --xen-debug option, and instead, require the user to pass
> >>a .config file matching the original build's .config.
> >
> >Hm, that throws this off a bit for the older hypervisors (to which
> >I had backported livepatch). Perhaps we could add some logic to
> >check if common/Kconfig exist?
> 
> At this point rather than adding extra logic to support different
> still-experimental versions, I'd rather just have a different branch. Maybe
> have a branch per Xen release?
> 
> >
> >And I also wonder if the --xen-debug option removal should be a seperate
> >patch?
> >
> 
> Well the two are related -- the motivation to use the .config is because the
> debug flag is now controlled by the .config rather than the command-line
> argument.

But not in the 4.7 that is going out - that 'debug=y' is non-Kconfig?
> 
> -- 
> Ross Lagerwall

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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Sander Eikelenboom]

Wednesday, June 15, 2016, 2:48:55 PM, you wrote:

 On 15.06.16 at 14:00,  wrote:
>> Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
>> On 15.06.16 at 11:38,  wrote:
 Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
> On 15.06.16 at 01:49,  wrote:
>>> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
>>> but one of the latest commits seems to have broken boot of HVM guests
>>> (using qemu-xen) previous build with xen_changeset git:6e908ee worked 
>>> fine.
 
>> Primary suspects would seem to be 67fc274bbe and bfa84968b2,
>> but (obviously) I didn't see any issues with them in my own
>> testing, so could you
>> - instead of doing a full bisect, revert just those two
 
> Will give reverting that a shot.
 
 Reverting bfa84968b2 is sufficient.
>> 
>>> Could you give this wild guess a try on top of the tree without the
>>> revert?
>> 
>>> --- unstable.orig/xen/arch/x86/hvm/emulate.c
>>> +++ unstable/xen/arch/x86/hvm/emulate.c
>>> @@ -1180,7 +1180,7 @@ static int hvmemul_rep_movs(
>>>  pfec |= PFEC_user_mode;
>>>  
>>>  bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
>> -if ( vio->>mmio_access.read_access &&
>> +if ( vio->>mmio_access.read_access && !vio->mmio_access.write_access &&
>>>   (vio->mmio_gla == (saddr & PAGE_MASK)) &&
>>>   bytes >= bytes_per_rep )
>>>  {
>> 
>> Unfortunately still crashes.

> Thanks for trying. Which basically just leaves the p.count > *reps
> part in that domain_crash() condition, as that's the only other thing
> involved in that check which said commit could have an effect on (as
> far as I can tell at least). Would you be up for another experiment,
> removing that one line? Other things to try (just to understand the
> issue) would be to
> - revert only each half of said commit individually (the two hunks
>   really are independent),
> - remove just the two latch_linear_to_phys() calls.

Will try some of that and let you know.

> Apart from that, and just to see whether there are other differences
> between your guest(s) and mine, could you post a guest config from
> one that's affected?

Hope you are not too disappointed it's rather sparse:

builder='hvm'
device_model_version = 'qemu-xen'
device_model_user = 'root'
memory = 512
name = 'test_guest'
vcpus = 4
cpu_weight = 768
vif = [ 'bridge=xen_bridge, ip=192.168.1.15, mac=00:16:3E:C4:72:83, 
model=e1000' ]
disk = [ 'phy:/dev/xen_vms/test_guest1,hda,w', 
'phy:/dev/xen_vms/test_guest2,hdb,w' ]
on_crash = 'preserve'
boot='c'
vnc=0
serial='pty'

Both dom0 and guest run Debian Jessie, as said platform is AMD, running a 
4.7-rc3ish kernel.


> Jan



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

[Xen-devel] [PATCH] xen/arm: gic-v2: Only create GICv2m node when there are GICv2m frame available

[Julien Grall]

Xen will crash on platform where GICv2m is not available with the
following error:

(XEN) Can't find ranges property for the gic node
(XEN) Device tree generation failed (-15).
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Could not set up DOM0 guest OS
(XEN) 

This is because the property "ranges" may not be present in the GIC
when there are no GICv2m frames.

Skip the creation of the GICv2m node when the hardware does not
support it.

This fixes boot after commit "xen/arm: Export GICv2m register frames to
DOM0 by device tree".

Signed-off-by: Julien Grall 
---
 xen/arch/arm/gic-v2.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 2c1c0ba..4e2f4c7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -669,6 +669,10 @@ static int gicv2m_make_dt_node(const struct domain *d,
 const struct dt_device_node *v2m = NULL;
 const struct v2m_data *v2m_data;
 
+/* It is not necessary to create the node if there are not GICv2m frames */
+if ( list_empty(_info) )
+return 0;
+
 /* The sub-nodes require the ranges property */
 prop = dt_get_property(gic, "ranges", );
 if ( !prop )
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v3 1/5] libxl: libxl_domain_need_memory shouldn't modify b_info

[Wei Liu]

On Wed, Jun 15, 2016 at 03:31:46PM +0200, Dario Faggioli wrote:
> On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> > This function is used to return the memory needed for a guest. It's
> > not
> > in a position to modify the b_info passed in (note the _setdefault
> > function).
> > 
> > Use a copy of b_info to do the calculation. Define a macro to mark
> > the
> > change in API.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Ian Jackson 
> > 
> > v3: new
> > Any suggestion on the macro name?
> > 
> Maybe LIBXL_HAVE_DOMAIN_NEED_MEMORY_BINFO_CONST
> 
> (a bit long, I know...)

Heh...

> 
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 2c0f868..905852d 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -67,6 +67,13 @@
> >   * the same $(XEN_VERSION) (e.g. throughout a major release).
> >   */
> >  
> > +/* LIBXL_HAVE_DOMAIN_NEED_MEMORY_V2
> > + *
> > + * If this is defined, libxl_domain_need_memory no longer modifies
> > + * passed in b_info.
> > + */
> > +#define LIBXL_HAVE_DOMAIN_NEED_MEMORY_V2
> > +
> >
> So, out of curiosity (or I should say "ignorance" :-)) how is one
> supposed to use this macro?

#ifdef MACRO
  /* new API */
#else
  /* old API */
  /* probably want to pass in a scratch copy of b_info */
#endif

> 
> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
> 



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

Re: [Xen-devel] [PATCH v3 3/5] libxl: introduce libxl__qmp_query_cpus

[Dario Faggioli]

On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> It interrogates QEMU for CPUs and update the bitmap accordingly.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Anthony PERARD 
> 
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 1/5] libxl: libxl_domain_need_memory shouldn't modify b_info

[Dario Faggioli]

On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> This function is used to return the memory needed for a guest. It's
> not
> in a position to modify the b_info passed in (note the _setdefault
> function).
> 
> Use a copy of b_info to do the calculation. Define a macro to mark
> the
> change in API.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> 
> v3: new
> Any suggestion on the macro name?
> 
Maybe LIBXL_HAVE_DOMAIN_NEED_MEMORY_BINFO_CONST

(a bit long, I know...)

> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 2c0f868..905852d 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -67,6 +67,13 @@
>   * the same $(XEN_VERSION) (e.g. throughout a major release).
>   */
>  
> +/* LIBXL_HAVE_DOMAIN_NEED_MEMORY_V2
> + *
> + * If this is defined, libxl_domain_need_memory no longer modifies
> + * passed in b_info.
> + */
> +#define LIBXL_HAVE_DOMAIN_NEED_MEMORY_V2
> +
>
So, out of curiosity (or I should say "ignorance" :-)) how is one
supposed to use this macro?

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/5] libxl: factor out libxl__get_device_modlel_version

[Dario Faggioli]

On Wed, 2016-06-15 at 10:31 +0100, Wei Liu wrote:
> Factor out the logic to determine device model version to a function.
> It
> will be used later. Note that code now also checks if the stbudom
> field
> is actually set before trying to extract a value from it.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Jackson 
> Cc: Anthony PERARD 
>
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] dom0 is not listed in xl list

[Wei Liu]

Drop xen-devel to BCC, add xen-users

This question is more suitable for xen-users.

On Wed, Jun 15, 2016 at 05:45:52PM +0430, sepanta s wrote:
> Hi,
> 
> after installing xen 4.7, the output of xl list is empty and
> dom0 is not found. what could be the problem ?
> The dmesg content is attached.

Does the command succeed but shows nothing? Does xl hang?

Not sure what distribution you use. Please make sure xenstored and other
services are running.

As far as I can tell Xen booted fine.

Wei.

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

[Xen-devel] dom0 is not listed in xl list

[sepanta s]

Hi,

after installing xen 4.7, the output of xl list is empty and
dom0 is not found. what could be the problem ?
The dmesg content is attached.
 Xen 4.7.0-rc
(XEN) Xen version 4.7.0-rc (root@) (gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4) 
debug=y Wed Jun 15 17:30:18 IRDT 2016
(XEN) Latest ChangeSet: Fri Jun 3 12:50:10 2016 -0400 git:c2a1786-dirty
(XEN) Bootloader: GRUB 2.02~beta2-9ubuntu1.7
(XEN) Command line: placeholder loglvl=all guest_loglvl=all 
dom0_mem=3000M,max:3899M dom0_max_vcpus=2 dom0_vcpus_pin=true hap=true altp2m=1 
no-real-mode edd=off
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Multiboot-e820 RAM map:
(XEN)   - 0009f000 (usable)
(XEN)  0009f000 - 000a (reserved)
(XEN)  0010 - 2000 (usable)
(XEN)  2000 - 2020 (reserved)
(XEN)  2020 - 4000 (usable)
(XEN)  4000 - 4020 (reserved)
(XEN)  4020 - ce39 (usable)
(XEN)  ce39 - ce3d3000 type 20
(XEN)  ce3d3000 - ce403000 (reserved)
(XEN)  ce403000 - ce417000 type 20
(XEN)  ce417000 - ce941000 (reserved)
(XEN)  ce941000 - ceb95000 (ACPI NVS)
(XEN)  ceb95000 - ceba2000 (ACPI data)
(XEN)  ceba2000 - cebc1000 (ACPI NVS)
(XEN)  cebc1000 - cebc6000 (ACPI data)
(XEN)  cebc6000 - cec09000 (ACPI NVS)
(XEN)  cec09000 - cf00 (usable)
(XEN)  cf80 - dfa0 (reserved)
(XEN)  f800 - fc00 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fed0 - fed04000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00019f60 (usable)
(XEN) ACPI: RSDP 000FC910, 0024 (r2 ALASKA)
(XEN) ACPI: XSDT CEB95070, 0064 (r1 ALASKAA M I  1072009 AMI 10013)
(XEN) ACPI: FACP CEB9F938, 00F4 (r4 ALASKAA M I  1072009 AMI 10013)
(XEN) ACPI: DSDT CEB95168, A7CE (r2 ALASKAA M I   15 INTL 20051117)
(XEN) ACPI: FACS CEBBFF80, 0040
(XEN) ACPI: APIC CEB9FA30, 0062 (r3 ALASKAA M I  1072009 AMI 10013)
(XEN) ACPI: MCFG CEB9FA98, 003C (r1 ALASKAA M I  1072009 MSFT   97)
(XEN) ACPI: HPET CEB9FAD8, 0038 (r1 ALASKAA M I  1072009 AMI.5)
(XEN) ACPI: SSDT CEB9FB10, 0460 (r1 IdeRef IdeTable 1000 INTL 20091112)
(XEN) ACPI: SSDT CEB9FF70, 08A2 (r1  PmRef  Cpu0Ist 3000 INTL 20051117)
(XEN) ACPI: SSDT CEBA0818, 0A92 (r1  PmRefCpuPm 3000 INTL 20051117)
(XEN) ACPI: BGRT CEBA12B0, 0038 (r0 ALASKAA M I  1072009 AMI 10013)
(XEN) System RAM: 5849MB (5989528kB)
(XEN) No NUMA configuration found
(XEN) Faking a node at -00019f60
(XEN) Domain heap initialised
(XEN) found SMP MP-table at 000fcc50
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x408
(XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0]
(XEN) ACPI: 32/64X FACS address mismatch in FADT - cebbff80/, 
using 32
(XEN) ACPI: wakeup_vec[cebbff8c], vec_size[20]
(XEN) ACPI: Local APIC address 0xfee0
(XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
(XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
(XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
(XEN) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
(XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
(XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
(XEN) ACPI: IRQ0 used by override.
(XEN) ACPI: IRQ2 used by override.
(XEN) ACPI: IRQ9 used by override.
(XEN) Enabling APIC mode:  Flat.  Using 1 I/O APICs
(XEN) ACPI: HPET id: 0x8086a701 base: 0xfed0
(XEN) ERST table was not found
(XEN) ACPI: BGRT: invalidating v1 image at 0xc4b5018
(XEN) Using ACPI (MADT) for SMP configuration information
(XEN) SMP: Allowing 2 CPUs (0 hotplug CPUs)
(XEN) IRQ limits: 24 GSI, 376 MSI/MSI-X
(XEN) xstate_init: using cntxt_size: 0x240 and states: 0x3
(XEN) mce_intel.c:735: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 
extended MCE MSR 0
(XEN) Intel machine check reporting enabled
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Detected 2693.944 MHz processor.
(XEN) Initing memory sharing.
(XEN) alt table 82d0802dd550 -> 82d0802de9d8
(XEN) PCI: MCFG configuration 0: base f800 segment  buses 00 - 3f
(XEN) PCI: MCFG area at f800 reserved in E820
(XEN) PCI: Using MCFG for segment  bus 00-3f
(XEN) I/O virtualisation disabled
(XEN) nr_sockets: 2
(XEN) Enabled directed EOI with ioapic_ack_old on!
(XEN) ENABLING IO-APIC IRQs

Re: [Xen-devel] [PATCH] x86: show remote CPU state upon fatal NMI

[Andrew Cooper]

On 15/06/16 13:59, Jan Beulich wrote:
 On 15.06.16 at 13:03,  wrote:
>> On 15/06/16 08:55, Jan Beulich wrote:
> @@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
>  printk("Faulting linear address: %p\n", _p(cr2));
>  show_page_walk(cr2);
>  }
> +else if ( trapnr == TRAP_nmi )
> +{
> +cpumask_andnot(_show_state_mask, _online_map,
> +   cpumask_of(smp_processor_id()));
> +set_nmi_callback(nmi_show_execution_state);
> +smp_send_nmi_allbutself();
 This would cause far less spinlock contention as

 for_each_cpu( cpu, nmi_show_state_mask )
 smp_send_nmi(cpu);

 I realise this involves introducing a new smp function, but it would
 substantially reduce contention on the console lock.
>>> Again, I don't see why lock contention would matter here. And then
>>> I also don't see how sending the IPIs individually would make matters
>>> significantly better: The sending will surely finish much faster than
>>> the printing.
>> Contention is a problem because you have replaced the NMI callback, and
>> the watchdog is still running.  Especially if sync_console is in effect,
>> you are liable to incur a further timeout, queueing up more NMIs.
>>
>> Although now I think of it, that won't matter so long as the NMIs don't
>> nest.
>>
>> The one advantage of sending the NMIs in order is that the information
>> dump will happen in order, which is slightly more use than having them
>> in a random order on a large machine.
> How that? All the NMIs will still arrive at about the same time, so
> while some low numbered CPUs may indeed get their state printed
> in order, higher numbered ones may still make it into the lock region
> in any order. (And no, building upon ticket locks making randomness
> much less likely is neither an option, nor would it really help: Just
> think of a lower numbered CPU first having to come out of a deep
> C-state or running at a much lower P-state than a higher numbered
> one.)

Hmm true.  There isn't a acknowledgement of the start of the NMI
handler, and putting one in sounds like far more effort and fragility
than it is worth.

>
 I would recommend moving this clause into nmi_watchdog_tick(), so that
 it doesn't get involved for non-watchdog NMIs.  IOCK/SERR NMIs won't
 have anything interesting to print from here.  I would also recommend
 disabling the watchdog before IPI'ing.
>>> And indeed I would have wanted it there, but I can't see how it can
>>> reasonably be put there: fatal_trap() doesn't return, so we can't put
>>> it after. And we definitely want to get state of the local CPU out
>>> before we try to log state of any of the remote CPUs. So the only
>>> options I see would be to
>>> - somehow specially flag the regs structure, but that feels hackish
>>>   (among other aspects nmi_watchdog_tick() has that parameter
>>>   const qualified for the very reason that it isn't supposed to fiddle
>>>   with it),
>>> - introduce a global flag.
>> How about a boolean flag to fatal_trap()?  It doesn't have many callers,
>> and this kind of printing might also be useful for some MCEs.
> Ah, right, there indeed aren't that many. Can you qualify "some"
> a bit better, so that maybe I can have the patch pass true there
> right away?

Any MCE which is in-practice synchronous might benefit.  I wouldn't
worry about updating the MCE callers as part of this.

~Andrew

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

Re: [Xen-devel] Issues with PCI-Passtrough (VT-d) in HVM with Xen 4.6

[Jan Beulich]

>>> On 15.06.16 at 12:45,  wrote:
> In reply to -
> http://lists.xen.org/archives/html/xen-devel/2016-06/msg00622.html 
> 
> HI, I am working with Jurgen on the issue, as per Jan's request I tried to
> write explicitly only latency timer to be written -
> bool force_write = false;
> if ((dev_data->permissive || xen_pcibk_permissive) &&
>   offset == PCI_CACHE_LINE_SIZE && size == 4)
>  force_write = true;
> ...
> 
> if ((force_write || !handled) && !err) {...}
> 
> But then it exposed another issue, the command register field seems not to
> be restored also
> because I think the bits which are to be restored are not
> in PCI_COMMAND_GUEST mask.

Please be more precise: Which bits in particular are not getting
set back to the needed values (I would guess the memory
and/or I/O decode ones, which we specifically must not allow
the guest to control, but I'd like to be certain)?

If my guess is correct, then I think rather than adding some
hackish workaround to pciback you'd better see whether there's
a way to cause a pci_disable_device() through your driver before
the reset, and a pci_enable_device() after. Or actually, I think
you can do this via plain config space writes from your driver: Try
writing the Command Register with the two decode bits clear
right before restoring the intended value (see the logic close to
the top of command_write()).

Jan


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

[Xen-devel] [PATCH 1/1] tools/livepatch: initialise j to 0 to make some versions of gcc happy

[Dongli Zhang]

Initialise j to 0 to make some versions of gcc (e.g., gcc4.5/4.3) happy to
avoid compilation error by commit beba3693f7243e68bbe31fe3794da91068eeea5b.

Signed-off-by: Dongli Zhang 
---
 tools/misc/xen-livepatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index 3162489..62c072e 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -412,7 +412,7 @@ struct {
 
 int main(int argc, char *argv[])
 {
-int i, j, ret;
+int i, j = 0, ret;
 
 if ( argc  <= 1 )
 {
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] x86: show remote CPU state upon fatal NMI

[Jan Beulich]

>>> On 15.06.16 at 13:03,  wrote:
> On 15/06/16 08:55, Jan Beulich wrote:
 @@ -570,6 +600,15 @@ void fatal_trap(const struct cpu_user_re
  printk("Faulting linear address: %p\n", _p(cr2));
  show_page_walk(cr2);
  }
 +else if ( trapnr == TRAP_nmi )
 +{
 +cpumask_andnot(_show_state_mask, _online_map,
 +   cpumask_of(smp_processor_id()));
 +set_nmi_callback(nmi_show_execution_state);
 +smp_send_nmi_allbutself();
>>> This would cause far less spinlock contention as
>>>
>>> for_each_cpu( cpu, nmi_show_state_mask )
>>> smp_send_nmi(cpu);
>>>
>>> I realise this involves introducing a new smp function, but it would
>>> substantially reduce contention on the console lock.
>> Again, I don't see why lock contention would matter here. And then
>> I also don't see how sending the IPIs individually would make matters
>> significantly better: The sending will surely finish much faster than
>> the printing.
> 
> Contention is a problem because you have replaced the NMI callback, and
> the watchdog is still running.  Especially if sync_console is in effect,
> you are liable to incur a further timeout, queueing up more NMIs.
> 
> Although now I think of it, that won't matter so long as the NMIs don't
> nest.
> 
> The one advantage of sending the NMIs in order is that the information
> dump will happen in order, which is slightly more use than having them
> in a random order on a large machine.

How that? All the NMIs will still arrive at about the same time, so
while some low numbered CPUs may indeed get their state printed
in order, higher numbered ones may still make it into the lock region
in any order. (And no, building upon ticket locks making randomness
much less likely is neither an option, nor would it really help: Just
think of a lower numbered CPU first having to come out of a deep
C-state or running at a much lower P-state than a higher numbered
one.)

>>> I would recommend moving this clause into nmi_watchdog_tick(), so that
>>> it doesn't get involved for non-watchdog NMIs.  IOCK/SERR NMIs won't
>>> have anything interesting to print from here.  I would also recommend
>>> disabling the watchdog before IPI'ing.
>> And indeed I would have wanted it there, but I can't see how it can
>> reasonably be put there: fatal_trap() doesn't return, so we can't put
>> it after. And we definitely want to get state of the local CPU out
>> before we try to log state of any of the remote CPUs. So the only
>> options I see would be to
>> - somehow specially flag the regs structure, but that feels hackish
>>   (among other aspects nmi_watchdog_tick() has that parameter
>>   const qualified for the very reason that it isn't supposed to fiddle
>>   with it),
>> - introduce a global flag.
> 
> How about a boolean flag to fatal_trap()?  It doesn't have many callers,
> and this kind of printing might also be useful for some MCEs.

Ah, right, there indeed aren't that many. Can you qualify "some"
a bit better, so that maybe I can have the patch pass true there
right away?

Jan


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

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Jan Beulich]

>>> On 15.06.16 at 14:00,  wrote:
> Wednesday, June 15, 2016, 12:12:37 PM, you wrote:
> On 15.06.16 at 11:38,  wrote:
>>> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
 Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
 On 15.06.16 at 01:49,  wrote:
>> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
>> but one of the latest commits seems to have broken boot of HVM guests
>> (using qemu-xen) previous build with xen_changeset git:6e908ee worked 
>> fine.
>>> 
> Primary suspects would seem to be 67fc274bbe and bfa84968b2,
> but (obviously) I didn't see any issues with them in my own
> testing, so could you
> - instead of doing a full bisect, revert just those two
>>> 
 Will give reverting that a shot.
>>> 
>>> Reverting bfa84968b2 is sufficient.
> 
>> Could you give this wild guess a try on top of the tree without the
>> revert?
> 
>> --- unstable.orig/xen/arch/x86/hvm/emulate.c
>> +++ unstable/xen/arch/x86/hvm/emulate.c
>> @@ -1180,7 +1180,7 @@ static int hvmemul_rep_movs(
>>  pfec |= PFEC_user_mode;
>>  
>>  bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
> -if ( vio->>mmio_access.read_access &&
> +if ( vio->>mmio_access.read_access && !vio->mmio_access.write_access &&
>>   (vio->mmio_gla == (saddr & PAGE_MASK)) &&
>>   bytes >= bytes_per_rep )
>>  {
> 
> Unfortunately still crashes.

Thanks for trying. Which basically just leaves the p.count > *reps
part in that domain_crash() condition, as that's the only other thing
involved in that check which said commit could have an effect on (as
far as I can tell at least). Would you be up for another experiment,
removing that one line? Other things to try (just to understand the
issue) would be to
- revert only each half of said commit individually (the two hunks
  really are independent),
- remove just the two latch_linear_to_phys() calls.

Apart from that, and just to see whether there are other differences
between your guest(s) and mine, could you post a guest config from
one that's affected?

Jan


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

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

[Jan Beulich]

>>> On 15.06.16 at 12:52,  wrote:
> On 6/14/2016 6:45 PM, Jan Beulich wrote:
> On 19.05.16 at 11:05,  wrote:
>>> A new HVMOP - HVMOP_map_mem_type_to_ioreq_server, is added to
>>> let one ioreq server claim/disclaim its responsibility for the
>>> handling of guest pages with p2m type p2m_ioreq_server. Users
>>> of this HVMOP can specify which kind of operation is supposed
>>> to be emulated in a parameter named flags. Currently, this HVMOP
>>> only support the emulation of write operations. And it can be
>>> easily extended to support the emulation of read ones if an
>>> ioreq server has such requirement in the future.
>> Didn't we determine that this isn't as easy as everyone first thought?
> 
> My understanding is that to emulate read, we need to change the definition
> of is_epte_present(), and I do not think this change will cause much 
> trouble.
> But since no one is using the read emulation, I am convinced the more 
> cautious
> way is to only support emulations for write operations for now.

Well, okay. I'd personally drop the "easily", but you know what
to tell people if later they come ask how this "easily" was meant.

>>> @@ -914,6 +916,45 @@ int hvm_unmap_io_range_from_ioreq_server(struct domain 
> *d, ioservid_t id,
>>>   return rc;
>>>   }
>>>   
>>> +int hvm_map_mem_type_to_ioreq_server(struct domain *d, ioservid_t id,
>>> + uint16_t type, uint32_t flags)
>> I see no reason why both can't be unsigned int.
> 
> Parameter type is passed in from the type field inside struct 
> xen_hvm_map_mem_type_to_ioreq_server,
> which is a uint16_t, followed with a uint16_t pad. Now I am wondering, 
> may be we can just remove the pad
> field in this structure and just define type as uint32_t.

I think keeping the interface structure unchanged is the desirable
route here. What I dislike is the passing around of non-natural
width types, which is more expensive in terms of processing. I.e.
as long as a fixed width type (which is necessary to be used in
the public interface) fits in "unsigned int", that should be the
respective internal type. Otherwise "unsigned long" etc.

There are cases where even internally we indeed want to use
fixed width types, and admittedly there are likely far more cases
where internally fixed width types get used without good reason,
but just like everywhere else - let's please not make this worse.
IOW please use fixed width types only when you really need them.

>>> --- a/xen/arch/x86/mm/p2m-ept.c
>>> +++ b/xen/arch/x86/mm/p2m-ept.c
>>> @@ -132,6 +132,12 @@ static void ept_p2m_type_to_flags(struct p2m_domain 
>>> *p2m, ept_entry_t *entry,
>>>   entry->r = entry->w = entry->x = 1;
>>>   entry->a = entry->d = !!cpu_has_vmx_ept_ad;
>>>   break;
>>> +case p2m_ioreq_server:
>>> +entry->r = entry->x = 1;
>> Why x?
> 
> Setting entry->x to 1 is not a must. I can remove it. :)

Please do. We shouldn't grant permissions without reason.

>>> @@ -94,8 +96,16 @@ static unsigned long p2m_type_to_flags(p2m_type_t t, 
>>> mfn_t mfn,
>>>   default:
>>>   return flags | _PAGE_NX_BIT;
>>>   case p2m_grant_map_ro:
>>> -case p2m_ioreq_server:
>>>   return flags | P2M_BASE_FLAGS | _PAGE_NX_BIT;
>>> +case p2m_ioreq_server:
>>> +{
>>> +flags |= P2M_BASE_FLAGS | _PAGE_RW;
>>> +
>>> +if ( p2m->ioreq.flags & P2M_IOREQ_HANDLE_WRITE_ACCESS )
>>> +return flags & ~_PAGE_RW;
>>> +else
>>> +return flags;
>>> +}
>> Same here (for the missing _PAGE_NX) plus no need for braces.
> 
> I'll remove the brace. And we do not need to set the _PAGE_NX_BIT, like 
> the p2m_ram_ro case I guess.

I hope you mean the inverse: You should set _PAGE_NX_BIT here.

>>> + struct hvm_ioreq_server *s)
>>> +{
>>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +int rc;
>>> +
>>> +spin_lock(>ioreq.lock);
>>> +
>>> +if ( flags == 0 )
>>> +{
>>> +rc = -EINVAL;
>>> +if ( p2m->ioreq.server != s )
>>> +goto out;
>>> +
>>> +/* Unmap ioreq server from p2m type by passing flags with 0. */
>>> +p2m->ioreq.server = NULL;
>>> +p2m->ioreq.flags = 0;
>>> +}
>> What does "passing" refer to in the comment?
> 
> It means if this routine is called with flags=0, it will unmap the ioreq 
> server.

Oh, that's a completely different reading of the comment than I had
implied: With what you say, "flags" here really refers to the function
parameter, whereas I implied it to refer to the structure field. I think
if that's what you want to say, then the comment should be put next
to the surrounding if() to clarify what "flags" refers to.

>>> +{
>>> +struct p2m_domain *p2m = p2m_get_hostp2m(d);
>>> +struct hvm_ioreq_server *s;
>>> +
>>> +spin_lock(>ioreq.lock);
>>> +
>>> +s = p2m->ioreq.server;
>>> +

Re: [Xen-devel] Xen-unstable 4.8: HVM domain_crash called from emulate.c:144 RIP: c000:[<000000000000336a>]

[Sander Eikelenboom]

Wednesday, June 15, 2016, 12:12:37 PM, you wrote:

 On 15.06.16 at 11:38,  wrote:
>> Wednesday, June 15, 2016, 10:57:03 AM, you wrote:
>> 
>>> Wednesday, June 15, 2016, 10:29:37 AM, you wrote:
>> 
>>> On 15.06.16 at 01:49,  wrote:
> Just tested latest xen-unstable 4.8 (xen_changeset git:d337764),
> but one of the latest commits seems to have broken boot of HVM guests
> (using qemu-xen) previous build with xen_changeset git:6e908ee worked 
> fine.
>> 
 Primary suspects would seem to be 67fc274bbe and bfa84968b2,
 but (obviously) I didn't see any issues with them in my own
 testing, so could you
 - instead of doing a full bisect, revert just those two
>> 
>>> Will give reverting that a shot.
>> 
>> Reverting bfa84968b2 is sufficient.

> Could you give this wild guess a try on top of the tree without the
> revert?

> --- unstable.orig/xen/arch/x86/hvm/emulate.c
> +++ unstable/xen/arch/x86/hvm/emulate.c
> @@ -1180,7 +1180,7 @@ static int hvmemul_rep_movs(
>  pfec |= PFEC_user_mode;
>  
>  bytes = PAGE_SIZE - (saddr & ~PAGE_MASK);
-if ( vio->>mmio_access.read_access &&
+if ( vio->>mmio_access.read_access && !vio->mmio_access.write_access &&
>   (vio->mmio_gla == (saddr & PAGE_MASK)) &&
>   bytes >= bytes_per_rep )
>  {

Unfortunately still crashes.

--
Sander

 And then of course this domain_crash() could of course be
 accompanied by some helpful printk() ...
>> 
>> Do you have a debug patch of what you are interested in ?

> Not yet - basically we should log all of the variables involved in the
> condition leading to the domain_crash().

> Jan



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

Re: [Xen-devel] vTPM detaching issue

[Wei Liu]

On Tue, Jun 14, 2016 at 12:32:19PM +0200, Andrea Genuise wrote:
[...]
> libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend
> /local/domain/748/backend/vtpm/749/0/state (hoping for state change to 6):
> xswait timeout (path=/local/domain/748/backend/vtpm/749/0/state)
> libxl: debug: libxl_event.c:677:libxl__ev_xswatch_deregister: watch
> w=0x1c4c1f0 wpath=/local/domain/748/backend/vtpm/749/0/state token=3/0:
> deregister slotnum=3
> libxl: debug: libxl_event.c:867:devstate_callback: backend
> /local/domain/748/backend/vtpm/749/0/state wanted state 6  timed out

This. The toolstack is waiting for the state to change to 6. But that
never happened.

> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
> w=0x1c4c1f0: deregister unregistered
> libxl: debug: libxl_device.c:937:device_backend_callback: calling
> device_backend_cleanup
> libxl: debug: libxl_event.c:691:libxl__ev_xswatch_deregister: watch
> w=0x1c4c1f0: deregister unregistered
> libxl: debug: libxl_device.c:943:device_backend_callback: Timeout reached,
> initiating forced remove

I think this is due to interaction between frontend and backend, but I'm
not an expert on vtpm so I don't have further comment.

Wei.

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

Re: [Xen-devel] Next 4.6.x stable release, numbering, qemu-tag

[George Dunlap]

On 15/06/16 11:46, Jan Beulich wrote:
 On 15.06.16 at 12:30,  wrote:
>> On 15/06/16 11:25, Jan Beulich wrote:
>> On 15.06.16 at 12:13,  wrote:
 On 15/06/16 11:04, Jan Beulich wrote:
 On 15.06.16 at 11:35,  wrote:
>> The version of qemu-xen that was tagged with 4.6 had been through
>> several rounds of RCs, months of osstesting, and even through a slew of
>> builds on Travis (which does build Ubuntu, but apparently just not the
>> bleeding-edge version).  I only happened to notice it as I was trying to
>> get patches for raisin for 4.7.
>
> The mere fact that 4.6.0 and 4.6.1 exhibited the same issue (and,
> from what you're saying now, which is different from what I've
> understood before, already did when they were cut) would make
> dealing with the issue a non-release-critical one for my taste. IOW,
> if a new version of Ubuntu showed up after 4.6.1, then fixing the
> issue in 4.6.2 (now 4.6.3) would indeed be rather desirable. If,
> however, that release was around already at the time 4.6.1 got
> cut, then I don't see why this is so urgent a problem to address.

 And this is exactly what happened -- the version of Ubuntu which breaks
 is 16.04, which (as the name indicates) came out in April 2016 -- two
 months after 4.6.1. :-)
>>>
>>> In which case I don't really follow what you tried to point out with
>>> the first sentence of your earlier reply still visible above.
>>
>> I should have said, "tagged 4.6.2".  My point was, there already was a
>> lot of testing done for 4.6.2; the tag was done with all the care that
>> can be reasonably expected.
> 
> Okay, maybe I'm confused then. I had thought all of this was a result
> of the thread titled "compilation fail, xen staging-4.6, vnc.c,
> qemu-tradintional issues under ubuntu 16.04", which aiui has its origin
> in March.

Indeed, that thread did show up in March, and the author said he was
building against 16.04, even though Google tells  me Ubuntu 16.04 wasn't
released until 21 April 2016.  He must have been using a beta release of it.

And unfortunately his report dropped through the cracks.  The fix from
upstream should have been backported to qemu-xen at that point, but it
(apparently) didn't come to the attention of the right people.

"Remember all the things you've forgotten or didn't notice" is about as
actionable as "fix all the bugs you don't know exist". :-)

 -George

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

[Xen-devel] [PATCH v2 0/2] Support consistent reads of mapped vcpu_runstate_info

[Juergen Gross]

A guest mapping vcpu_runstate_info into its memory can't read this
information from another cpu but the one the data is referring to.
Reason is there is no reliable way for the guest to detect a concurrent
data update by the hypervisor.

This patch series adds an update flag to the mapped data which can be
used by the guest to detect an update is occurring. As this flag is
modifying the current interface it has to be activated by using a
vm_assist hypercall, which in turn has to be made available for ARM.

Runtime tested on x86 with a modified Linux kernel using the new
feature.
Compile tested only for ARM.

Changes in V2:
- patch 1: readded the #ifdef's as requested by Jan Beulich
- patch 2: smp_wmb() instead of wmb() as requested by Andrew Cooper
- patch 2: use sizeof() as requested by Jan Beulich
- patch 2: eliminate new variable update_flag as requested by Jan Beulich

Juergen Gross (2):
  xen/arm: add support for vm_assist hypercall
  xen: add update indicator to vcpu_runstate_info

 xen/arch/arm/domain.c| 21 +
 xen/arch/arm/traps.c |  1 +
 xen/arch/x86/domain.c| 30 ++
 xen/include/asm-arm/config.h |  2 ++
 xen/include/asm-x86/config.h |  1 +
 xen/include/public/vcpu.h|  6 ++
 xen/include/public/xen.h |  7 +++
 7 files changed, 68 insertions(+)

-- 
2.6.6


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

[Xen-devel] [PATCH v2 1/2] xen/arm: add support for vm_assist hypercall

[Juergen Gross]

Up to now the vm_assist hypercall hasn't been supported on ARM, as
there are only x86 specific features to switch. Add support of
vm_assist on ARM for future use.

Signed-off-by: Juergen Gross 
Reviewed-by: Julien Grall 
---
V2: readded the #ifdef's as requested by Jan Beulich
---
 xen/arch/arm/traps.c | 1 +
 xen/include/asm-arm/config.h | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aa3e3c2..44926ca 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1282,6 +1282,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
 HYPERCALL(multicall, 2),
 HYPERCALL(platform_op, 1),
 HYPERCALL_ARM(vcpu_op, 3),
+HYPERCALL(vm_assist, 2),
 };
 
 #ifndef NDEBUG
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 2d11b62..563f49b 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -199,6 +199,8 @@ extern unsigned long frametable_virt_end;
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
+#define VM_ASSIST_VALID  (0)
+
 #endif /* __ARM_CONFIG_H__ */
 /*
  * Local variables:
-- 
2.6.6


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

[Xen-devel] [PATCH v2 2/2] xen: add update indicator to vcpu_runstate_info

[Juergen Gross]

In order to support reading another vcpu's mapped vcpu_runstate_info
an indicator for an occurring update of the runstate information is
needed.

Add the possibility to activate setting this indicator in the highest
bit of state_entry_time via a vm_assist hypercall. When activated the
update indicator will be set before the runstate information is
modified in guest memory and it will be reset after modification is
done. As state_entry_time is guaranteed to be different after each
update the guest can detect any update (either in progress or while
reading the runstate data) by comparing state_entry_time before and
after reading runstate data: in case the values differ or the update
indicator was set the data might be inconsistent and should be reread.

Signed-off-by: Juergen Gross 
---
V2: smp_wmb() instead of wmb() as requested by Andrew Cooper
use sizeof() as requested by Jan Beulich
eliminate new variable update_flag as requested by Jan Beulich
---
 xen/arch/arm/domain.c| 21 +
 xen/arch/x86/domain.c| 30 ++
 xen/include/asm-arm/config.h |  2 +-
 xen/include/asm-x86/config.h |  1 +
 xen/include/public/vcpu.h|  6 ++
 xen/include/public/xen.h |  7 +++
 6 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 1365b4a..ad50b19 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -239,10 +239,31 @@ static void ctxt_switch_to(struct vcpu *n)
 /* Update per-VCPU guest runstate shared memory area (if registered). */
 static void update_runstate_area(struct vcpu *v)
 {
+void __user *guest_handle = NULL;
+unsigned off = 0;
+
 if ( guest_handle_is_null(runstate_guest(v)) )
 return;
 
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+off = offsetof(struct vcpu_runstate_info, state_entry_time) +
+  sizeof(v->runstate.state_entry_time) - 1;
+guest_handle = v->runstate_guest.p;
+guest_handle += off;
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+smp_wmb();
+}
+
 __copy_to_guest(runstate_guest(v), >runstate, 1);
+
+if ( guest_handle )
+{
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+smp_wmb();
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+}
 }
 
 static void schedule_tail(struct vcpu *prev)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 989bc74..8890661 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1926,12 +1926,35 @@ bool_t update_runstate_area(struct vcpu *v)
 {
 bool_t rc;
 smap_check_policy_t smap_policy;
+void __user *guest_handle = NULL;
+unsigned off = 0;
 
 if ( guest_handle_is_null(runstate_guest(v)) )
 return 1;
 
 smap_policy = smap_policy_change(v, SMAP_CHECK_ENABLED);
 
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
+{
+off = offsetof(struct vcpu_runstate_info, state_entry_time) +
+  sizeof(v->runstate.state_entry_time) - 1;
+if ( has_32bit_shinfo(v->domain) )
+{
+guest_handle = v->runstate_guest.compat.p;
+guest_handle +=
+offsetof(struct compat_vcpu_runstate_info, state_entry_time) +
+sizeof(v->runstate.state_entry_time) - 1;
+}
+else
+{
+guest_handle = v->runstate_guest.native.p;
+guest_handle += off;
+}
+v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+smp_wmb();
+}
+
 if ( has_32bit_shinfo(v->domain) )
 {
 struct compat_vcpu_runstate_info info;
@@ -1944,6 +1967,13 @@ bool_t update_runstate_area(struct vcpu *v)
 rc = __copy_to_guest(runstate_guest(v), >runstate, 1) !=
  sizeof(v->runstate);
 
+if ( guest_handle )
+{
+v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
+smp_wmb();
+__raw_copy_to_guest(guest_handle, (void *)>runstate + off, 1);
+}
+
 smap_policy_change(v, smap_policy);
 
 return rc;
diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 563f49b..ce3edc2 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -199,7 +199,7 @@ extern unsigned long frametable_virt_end;
 #define watchdog_disable() ((void)0)
 #define watchdog_enable()  ((void)0)
 
-#define VM_ASSIST_VALID  (0)
+#define VM_ASSIST_VALID  (1UL << VMASST_TYPE_runstate_update_flag)
 
 #endif /* __ARM_CONFIG_H__ */
 /*
diff --git a/xen/include/asm-x86/config.h b/xen/include/asm-x86/config.h
index c10129d..6fd84e7 100644
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -332,6 +332,7 @@ extern unsigned long xen_phys_start;
   

[Xen-devel] [xen-4.6-testing test] 95718: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-migrupgrade 3 host-install/src_host(3) broken in 95645 pass 
in 95718
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 3 host-install(3) broken in 95645 
pass in 95718
 test-amd64-amd64-libvirt-pair  3 host-install/src_host(3) broken pass in 95564
 test-amd64-amd64-xl-xsm   3 host-install(3)   broken pass in 95645
 test-amd64-amd64-pair 3 host-install/src_host(3)  broken pass in 95645
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken pass in 
95645
 test-amd64-i386-xl-xsm3 host-install(3)   broken pass in 95645
 test-amd64-i386-qemuu-rhel6hvm-amd  3 host-install(3) broken pass in 95645
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
pass in 95645
 test-amd64-i386-rumpuserxen-i386  3 host-install(3)   broken pass in 95645
 test-amd64-i386-xl-qemuu-debianhvm-amd64 3 host-install(3) broken pass in 95645
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
95564 pass in 95718
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 5 xen-install fail in 95645 
pass in 95564
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 95645 pass in 
95718
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 95564
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 95645

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 95447
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 95564 like 95447
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 95447
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 95447
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 95447
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 95447

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

version targeted for testing:
 xen  

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

[George Dunlap]

On 15/06/16 11:21, Jan Beulich wrote:
>> I think you've tripped over "changing coding styles" in unfamiliar code
>> before too, so you know how frustrating it is to try to follow the
>> existing coding style only to be told that you did it wrong. :-)
> 
> Agreed, you caught me on this one. Albeit with the slight
> difference that in the public interface we can't as easily correct
> old mistakes to aid people who simply clone surrounding code
> when adding new bits (the possibility of adding #ifdef-ery doesn't
> seem very attractive to me there, unless we got reports of actual
> name space collisions).

Indeed; and just to be clear, I wasn't trying to criticize the
deprecated coding style in the headers -- but given that there *is*
deprecated coding style, it's worth a slight apology when asking people
to use the new style instead of falling in line with what's already
there. :-)

 -George

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

Re: [Xen-devel] [PATCH v5 5/6] dcdbas: make use of smp_call_on_cpu()

[Juergen Gross]

On 06/04/16 16:17, Juergen Gross wrote:

Use smp_call_on_cpu() to raise SMI on cpu 0.
Make call secure by adding get_online_cpus() to avoid e.g. suspend
resume cycles in between.

Signed-off-by: Juergen Gross 


Could please some maintainer comment on this patch?


Juergen


---
V4: add call to get_online_cpus()
---
  drivers/firmware/dcdbas.c | 51 ---
  1 file changed, 26 insertions(+), 25 deletions(-)

diff --git a/drivers/firmware/dcdbas.c b/drivers/firmware/dcdbas.c
index 829eec8..2fe1a13 100644
--- a/drivers/firmware/dcdbas.c
+++ b/drivers/firmware/dcdbas.c
@@ -23,6 +23,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -238,33 +239,14 @@ static ssize_t host_control_on_shutdown_store(struct 
device *dev,
return count;
  }

-/**
- * dcdbas_smi_request: generate SMI request
- *
- * Called with smi_data_lock.
- */
-int dcdbas_smi_request(struct smi_cmd *smi_cmd)
+static int raise_smi(void *par)
  {
-   cpumask_var_t old_mask;
-   int ret = 0;
+   struct smi_cmd *smi_cmd = par;

-   if (smi_cmd->magic != SMI_CMD_MAGIC) {
-   dev_info(_pdev->dev, "%s: invalid magic value\n",
-__func__);
-   return -EBADR;
-   }
-
-   /* SMI requires CPU 0 */
-   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
-   return -ENOMEM;
-
-   cpumask_copy(old_mask, >cpus_allowed);
-   set_cpus_allowed_ptr(current, cpumask_of(0));
if (smp_processor_id() != 0) {
dev_dbg(_pdev->dev, "%s: failed to get CPU 0\n",
__func__);
-   ret = -EBUSY;
-   goto out;
+   return -EBUSY;
}

/* generate SMI */
@@ -280,9 +262,28 @@ int dcdbas_smi_request(struct smi_cmd *smi_cmd)
: "memory"
);

-out:
-   set_cpus_allowed_ptr(current, old_mask);
-   free_cpumask_var(old_mask);
+   return 0;
+}
+/**
+ * dcdbas_smi_request: generate SMI request
+ *
+ * Called with smi_data_lock.
+ */
+int dcdbas_smi_request(struct smi_cmd *smi_cmd)
+{
+   int ret;
+
+   if (smi_cmd->magic != SMI_CMD_MAGIC) {
+   dev_info(_pdev->dev, "%s: invalid magic value\n",
+__func__);
+   return -EBADR;
+   }
+
+   /* SMI requires CPU 0 */
+   get_online_cpus();
+   ret = smp_call_on_cpu(0, raise_smi, smi_cmd, true);
+   put_online_cpus();
+
return ret;
  }





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

Re: [Xen-devel] [PATCH v5 2/6] virt, sched: add generic vcpu pinning support

[Juergen Gross]

On 06/04/16 16:17, Juergen Gross wrote:

Add generic virtualization support for pinning the current vcpu to a
specified physical cpu. As this operation isn't performance critical
(a very limited set of operations like BIOS calls and SMIs is expected
to need this) just add a hypervisor specific indirection.

Signed-off-by: Juergen Gross 


Could please some maintainer comment on this patch?


Juergen


---
V4: move this patch some places up in the series
 WARN_ONCE in case platform doesn't support pinning as requested by
 Peter Zijlstra

V3: use getc_cpu()/put_cpu() as suggested by David Vrabel

V2: adapt to using workqueues
 add include/linux/hypervisor.h to hide architecture specific stuff
 from generic kernel code

In case paravirt maintainers don't want to be responsible for
include/linux/hypervisor.h I could take it.
---
  MAINTAINERS   |  1 +
  arch/x86/include/asm/hypervisor.h |  4 
  arch/x86/kernel/cpu/hypervisor.c  | 11 +++
  include/linux/hypervisor.h| 17 +
  kernel/smp.c  |  1 +
  kernel/up.c   |  1 +
  6 files changed, 35 insertions(+)
  create mode 100644 include/linux/hypervisor.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 40eb1db..d3bde4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8330,6 +8330,7 @@ S:Supported
  F:Documentation/virtual/paravirt_ops.txt
  F:arch/*/kernel/paravirt*
  F:arch/*/include/asm/paravirt.h
+F: include/linux/hypervisor.h

  PARIDE DRIVERS FOR PARALLEL PORT IDE DEVICES
  M:Tim Waugh 
diff --git a/arch/x86/include/asm/hypervisor.h 
b/arch/x86/include/asm/hypervisor.h
index 055ea99..67942b6 100644
--- a/arch/x86/include/asm/hypervisor.h
+++ b/arch/x86/include/asm/hypervisor.h
@@ -43,6 +43,9 @@ struct hypervisor_x86 {

/* X2APIC detection (run once per boot) */
bool(*x2apic_available)(void);
+
+   /* pin current vcpu to specified physical cpu (run rarely) */
+   void(*pin_vcpu)(int);
  };

  extern const struct hypervisor_x86 *x86_hyper;
@@ -56,6 +59,7 @@ extern const struct hypervisor_x86 x86_hyper_kvm;
  extern void init_hypervisor(struct cpuinfo_x86 *c);
  extern void init_hypervisor_platform(void);
  extern bool hypervisor_x2apic_available(void);
+extern void hypervisor_pin_vcpu(int cpu);
  #else
  static inline void init_hypervisor(struct cpuinfo_x86 *c) { }
  static inline void init_hypervisor_platform(void) { }
diff --git a/arch/x86/kernel/cpu/hypervisor.c b/arch/x86/kernel/cpu/hypervisor.c
index 73d391a..ff108f8 100644
--- a/arch/x86/kernel/cpu/hypervisor.c
+++ b/arch/x86/kernel/cpu/hypervisor.c
@@ -85,3 +85,14 @@ bool __init hypervisor_x2apic_available(void)
   x86_hyper->x2apic_available &&
   x86_hyper->x2apic_available();
  }
+
+void hypervisor_pin_vcpu(int cpu)
+{
+   if (!x86_hyper)
+   return;
+
+   if (x86_hyper->pin_vcpu)
+   x86_hyper->pin_vcpu(cpu);
+   else
+   WARN_ONCE(1, "vcpu pinning requested but not supported!\n");
+}
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
new file mode 100644
index 000..3fa5ef2
--- /dev/null
+++ b/include/linux/hypervisor.h
@@ -0,0 +1,17 @@
+#ifndef __LINUX_HYPEVISOR_H
+#define __LINUX_HYPEVISOR_H
+
+/*
+ * Generic Hypervisor support
+ * Juergen Gross 
+ */
+
+#ifdef CONFIG_HYPERVISOR_GUEST
+#include 
+#else
+static inline void hypervisor_pin_vcpu(int cpu)
+{
+}
+#endif
+
+#endif /* __LINUX_HYPEVISOR_H */
diff --git a/kernel/smp.c b/kernel/smp.c
index 7416544..9388064 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 

  #include "smpboot.h"

diff --git a/kernel/up.c b/kernel/up.c
index 1760bf3..3ccee2b 100644
--- a/kernel/up.c
+++ b/kernel/up.c
@@ -6,6 +6,7 @@
  #include 
  #include 
  #include 
+#include 

  int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
int wait)




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

[Xen-devel] [PATCH 0/7] Honour more configure variables in various places (iteration 3)

[Wei Liu]

This series deals with hard-coded /var/run in code.

Wei Liu (7):
  xenconsoled: honour XEN_RUN_DIR
  tools/helper: honour XEN_RUN_DIR in init-xenstore-domain.c
  hotplug/FreeBSD: honour XEN_RUN_DIR
  hotplug/NetBSD: honour XEN_RUN_DIR
  hotplug/Linux: honour XEN_RUN_DIR
  libxenstat: honour XEN_RUN_DIR
  oxenstored: honour XEN_RUN_DIR

 .gitignore| 2 ++
 tools/console/daemon/main.c   | 2 +-
 tools/helpers/Makefile| 7 +--
 tools/helpers/init-xenstore-domain.c  | 8 +---
 tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 2 +-
 tools/hotplug/Linux/init.d/xencommons.in  | 6 +++---
 tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
 tools/hotplug/NetBSD/rc.d/xendriverdomain.in  | 2 +-
 tools/ocaml/xenstored/xenstored.ml| 2 +-
 tools/xenstat/libxenstat/Makefile | 7 ++-
 tools/xenstat/libxenstat/src/xenstat_qmp.c| 3 ++-
 11 files changed, 28 insertions(+), 15 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 7/7] oxenstored: honour XEN_RUN_DIR

[Wei Liu]

Move default the pid file under XEN_RUN_DIR. Note that it changes the
location from /var/run to /var/run/xen.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Dave Scott 
---
 tools/ocaml/xenstored/xenstored.ml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/ocaml/xenstored/xenstored.ml 
b/tools/ocaml/xenstored/xenstored.ml
index 30570ed..7ea4026 100644
--- a/tools/ocaml/xenstored/xenstored.ml
+++ b/tools/ocaml/xenstored/xenstored.ml
@@ -81,7 +81,7 @@ let config_filename cf =
| Some name -> name
| None  -> Define.default_config_dir ^ "/oxenstored.conf"
 
-let default_pidfile = "/var/run/xenstored.pid"
+let default_pidfile = Paths.xen_run_dir ^ "/xenstored.pid"
 
 let ring_scan_interval = ref 20
 
-- 
2.1.4


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

[Xen-devel] [PATCH 6/7] libxenstat: honour XEN_RUN_DIR

[Wei Liu]

This is because libxl uses XEN_RUN_DIR to generate the socket path for
libxenstat while libxenstat itself uses hard-coded path, which is not
necessary in sync with libxl.

Generate a _paths.h because it is required to make this change work.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 .gitignore | 1 +
 tools/xenstat/libxenstat/Makefile  | 7 ++-
 tools/xenstat/libxenstat/src/xenstat_qmp.c | 3 ++-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index d4ffaa6..9b8dece 100644
--- a/.gitignore
+++ b/.gitignore
@@ -220,6 +220,7 @@ tools/xenmon/xentrace_setmask
 tools/xenmon/xenbaked
 tools/xenpaging/xenpaging
 tools/xenpmd/xenpmd
+tools/xenstat/libxenstat/src/_paths.h
 tools/xenstat/xentop/xentop
 tools/xenstore/xenstore
 tools/xenstore/xenstore-chmod
diff --git a/tools/xenstat/libxenstat/Makefile 
b/tools/xenstat/libxenstat/Makefile
index 850d24a..213d998 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -40,6 +40,8 @@ LDLIBS-$(CONFIG_SunOS) += -lkstat
 .PHONY: all
 all: $(LIB) $(SHLIB) $(SHLIB_LINKS)
 
+$(OBJECTS-y): src/_paths.h
+
 $(LIB): $(OBJECTS-y)
$(AR) rc $@ $^
$(RANLIB) $@
@@ -135,9 +137,12 @@ endif
 .PHONY: clean
 clean:
rm -f $(LIB) $(SHLIB) $(SHLIB_LINKS) $(OBJECTS-y) \
- $(BINDINGS) $(BINDINGSRC) $(DEPS)
+ $(BINDINGS) $(BINDINGSRC) $(DEPS) src/_paths.h
 
 .PHONY: distclean
 distclean: clean
 
 -include $(DEPS)
+
+genpath-target = $(call buildmakevars2header,src/_paths.h)
+$(eval $(genpath-target))
diff --git a/tools/xenstat/libxenstat/src/xenstat_qmp.c 
b/tools/xenstat/libxenstat/src/xenstat_qmp.c
index c12929a..a87c937 100644
--- a/tools/xenstat/libxenstat/src/xenstat_qmp.c
+++ b/tools/xenstat/libxenstat/src/xenstat_qmp.c
@@ -23,6 +23,7 @@
 #include 
 
 #include "xenstat_priv.h"
+#include "_paths.h"
 
 #ifdef HAVE_YAJL_YAJL_VERSION_H
 #  include 
@@ -398,7 +399,7 @@ static void read_attributes_qdisk_dom(xenstat_node *node, 
domid_t domain)
free(val);
 
/* Connect to this VMs QMP socket */
-   snprintf(path, sizeof(path), "/var/run/xen/qmp-libxenstat-%i", domain);
+   snprintf(path, sizeof(path), XEN_RUN_DIR "/qmp-libxenstat-%i", domain);
if ((qfd = qmp_connect(path)) < 0)
return;
 
-- 
2.1.4


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

[Xen-devel] [PATCH 5/7] hotplug/Linux: honour XEN_RUN_DIR

[Wei Liu]

Store various PID files under XEN_RUN_DIR. Note that this change the
default location from /var/run to /var/run/xen.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Roger Pau Monné 
---
 tools/hotplug/Linux/init.d/xencommons.in  | 6 +++---
 tools/hotplug/Linux/init.d/xendriverdomain.in | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/hotplug/Linux/init.d/xencommons.in 
b/tools/hotplug/Linux/init.d/xencommons.in
index 7b69fc2..2d8f30b 100644
--- a/tools/hotplug/Linux/init.d/xencommons.in
+++ b/tools/hotplug/Linux/init.d/xencommons.in
@@ -27,8 +27,8 @@ xencommons_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
 
 test -f $xencommons_config/xencommons && . $xencommons_config/xencommons
 
-XENCONSOLED_PIDFILE=/var/run/xenconsoled.pid
-QEMU_PIDFILE=/var/run/qemu-dom0.pid
+XENCONSOLED_PIDFILE=@XEN_RUN_DIR@/xenconsoled.pid
+QEMU_PIDFILE=@XEN_RUN_DIR@/qemu-dom0.pid
 shopt -s extglob
 
 # not running in Xen dom0 or domU
@@ -70,7 +70,7 @@ do_start () {
 
if [ -n "$XENSTORED" ] ; then
echo -n Starting $XENSTORED...
-   $XENSTORED --pid-file /var/run/xenstored.pid $XENSTORED_ARGS
+   $XENSTORED --pid-file @XEN_RUN_DIR@/xenstored.pid 
$XENSTORED_ARGS
else
echo "No xenstored found"
exit 1
diff --git a/tools/hotplug/Linux/init.d/xendriverdomain.in 
b/tools/hotplug/Linux/init.d/xendriverdomain.in
index 8d4592a..c63060f 100644
--- a/tools/hotplug/Linux/init.d/xendriverdomain.in
+++ b/tools/hotplug/Linux/init.d/xendriverdomain.in
@@ -24,7 +24,7 @@ xendriverdomain_config=@CONFIG_DIR@/@CONFIG_LEAF_DIR@
 
 test -f $xendriverdomain_config/xendriverdomain && . 
$xendriverdomain_config/xendriverdomain
 
-XLDEVD_PIDFILE=/var/run/xldevd.pid
+XLDEVD_PIDFILE=@XEN_RUN_DIR@/xldevd.pid
 
 # not running in Xen dom0 or domU
 if ! test -d /proc/xen ; then
-- 
2.1.4


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

[Xen-devel] [PATCH 1/7] xenconsoled: honour XEN_RUN_DIR

[Wei Liu]

Place the PID file under XEN_RUN_DIR by default. Note this change the
default location from /var/run to /var/run/xen.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/console/daemon/main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c
index 20e3513..806d2fd 100644
--- a/tools/console/daemon/main.c
+++ b/tools/console/daemon/main.c
@@ -193,7 +193,7 @@ int main(int argc, char **argv)
increase_fd_limit();
 
if (!is_interactive) {
-   daemonize(pidfile ? pidfile : "/var/run/xenconsoled.pid");
+   daemonize(pidfile ? pidfile : XEN_RUN_DIR "/xenconsoled.pid");
}
 
if (!xen_setup())
-- 
2.1.4


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

Re: [Xen-devel] [PATCH raisin 3/4] Update config-4.6 and config-4.5 to point to stable branches

[George Dunlap]

On 15/06/16 11:53, Stefano Stabellini wrote:
> On Wed, 15 Jun 2016, George Dunlap wrote:
>> On 15/06/16 11:24, Stefano Stabellini wrote:
>>> On Tue, 14 Jun 2016, George Dunlap wrote:
 On 14/06/16 11:01, Stefano Stabellini wrote:
> On Tue, 14 Jun 2016, George Dunlap wrote:
>> On 14/06/16 10:40, Stefano Stabellini wrote:
>>> On Mon, 13 Jun 2016, George Dunlap wrote:
 Point xen, qemu, and qemu-trad to stable-4.5 and -4.6 branches.

 And point the default libvirt to point to the libvirt 1.3.3
 maintenance branch, rather than xen-tested-master.

 Also update OVMF revision for 4.6 to a version that builds with modern
 gccs.

 Singed-off-by: George Dunlap 

 CC: Stefano Stabellini 
 ---
  configs/config-4.5 | 6 +++---
  configs/config-4.6 | 8 
  configs/config-master  | 3 +++
  configs/config-url-git | 2 +-
  4 files changed, 11 insertions(+), 8 deletions(-)

 diff --git a/configs/config-4.5 b/configs/config-4.5
 index 4163b68..8db9a9d 100644
 --- a/configs/config-4.5
 +++ b/configs/config-4.5
 @@ -1,8 +1,8 @@
  XEN_REVISION="origin/stable-4.5"
 -QEMU_REVISION="master"
 -QEMU_TRADITIONAL_REVISION="master"
 +QEMU_REVISION="origin/stable-4.5"
 +QEMU_TRADITIONAL_REVISION="origin/stable-4.5"
  SEABIOS_REVISION="rel-1.7.5"
  GRUB_REVISION="master"
 -LIBVIRT_REVISION="origin/xen-tested-master"
 +LIBVIRT_REVISION="origin/v1.3.3-maint"
  OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
  LINUX_REVISION="master"
 diff --git a/configs/config-4.6 b/configs/config-4.6
 index e8b2a09..b003a30 100644
 --- a/configs/config-4.6
 +++ b/configs/config-4.6
 @@ -1,8 +1,8 @@
  XEN_REVISION="origin/stable-4.6"
 -QEMU_REVISION="master"
 -QEMU_TRADITIONAL_REVISION="master"
 +QEMU_REVISION="origin/stable-4.6"
 +QEMU_TRADITIONAL_REVISION="origin/stable-4.6"
  SEABIOS_REVISION="rel-1.8.2"
  GRUB_REVISION="master"
 -LIBVIRT_REVISION="origin/xen-tested-master"
 -OVMF_REVISION="cb9a7ebabcd6b8a49dc0854b2f9592d732b5afbd"
 +LIBVIRT_REVISION="origin/v1.3.3-maint"
 +OVMF_REVISION="52a99493cce88a9d4ec8a02d7f1bd1a1001ce60d"
  LINUX_REVISION="master"
 diff --git a/configs/config-master b/configs/config-master
 index bd26ce3..fce7436 100644
 --- a/configs/config-master
 +++ b/configs/config-master
 @@ -6,3 +6,6 @@ GRUB_REVISION="master"
  LIBVIRT_REVISION="origin/xen-tested-master"
  OVMF_REVISION="origin/xen-tested-master"
  LINUX_REVISION="master"
 +
 +# oss-tested branch
 +LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
>>>
>>> Why keep this around? I would remove it.
>>
>> Because...
>>
 diff --git a/configs/config-url-git b/configs/config-url-git
 index 79813c4..614f522 100644
 --- a/configs/config-url-git
 +++ b/configs/config-url-git
 @@ -3,6 +3,6 @@ QEMU_URL="git://xenbits.xen.org/qemu-xen.git"
  QEMU_TRADITIONAL_URL="git://xenbits.xen.org/qemu-xen-traditional.git"
  SEABIOS_URL="git://xenbits.xen.org/seabios.git"
  GRUB_URL="git://git.savannah.gnu.org/grub.git"
 -LIBVIRT_URL="git://xenbits.xen.org/libvirt.git"
 +LIBVIRT_URL="git://libvirt.org/libvirt.git"
>>
>> ...here, the LIBVIRT_URL in config-url-git is set to the libvirt.org URL
>> so that the stable releases can be pointed to v1.3.3-maint instead. The
>> xen.org repo doesn't contain the v1.3.3-maint branch, and the
>> libvirt.org repo doesn't contain the 'xen-tested-master' branch.
>>
>> I admit this is a bit ugly, *almost* separating things entirely but then
>> not. But I don't see another easy way of having both the 1.3.3
>> maintenance branch and the oss-tested branch. (Unless we started having
>> osstest test the maintenance branch as well.)
>  
> I would drop git://xenbits.xen.org/libvirt.git and xen-tested-master
> entirely and just stick to v1.3.3-maint everywhere. Or the other way
> around.

 Well I assume that people building one of the releases want something
 relatively stable and supported, so xen-tested-master is obviously
 unsuitable (and might not actually be capable of building against Xen
 versions older than a certain point due to the fact that libxl cannot be
 both forward- and backward-compatible).  And I also assume that people
 building with XEN_RELEASE="master" want the bleeding edge of everything
 so that they can test new features (or indeed, so that they can write
 new features).  So I think we 

[Xen-devel] [PATCH 2/7] tools/helper: honour XEN_RUN_DIR in init-xenstore-domain.c

[Wei Liu]

Place the PID file under XEN_RUN_DIR. Note that this change the default
location from /var/run to /var/run/xen.

Generate a _paths.h as that is required to make this change work.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 .gitignore   | 1 +
 tools/helpers/Makefile   | 7 +--
 tools/helpers/init-xenstore-domain.c | 8 +---
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/.gitignore b/.gitignore
index e019f2e..d4ffaa6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -145,6 +145,7 @@ tools/flask/utils/flask-loadpolicy
 tools/flask/utils/flask-setenforce
 tools/flask/utils/flask-set-bool
 tools/flask/utils/flask-label-pci
+tools/helpers/_paths.h
 tools/helpers/init-xenstore-domain
 tools/helpers/xen-init-dom0
 tools/hotplug/common/hotplugpath.sh
diff --git a/tools/helpers/Makefile b/tools/helpers/Makefile
index a05a368..5d444aa 100644
--- a/tools/helpers/Makefile
+++ b/tools/helpers/Makefile
@@ -28,7 +28,7 @@ all: $(PROGS)
 xen-init-dom0: $(XEN_INIT_DOM0_OBJS)
$(CC) $(LDFLAGS) -o $@ $(XEN_INIT_DOM0_OBJS) $(LDLIBS_libxentoollog) 
$(LDLIBS_libxenstore) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
 
-init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS)
+init-xenstore-domain: $(INIT_XENSTORE_DOMAIN_OBJS) _paths.h
$(CC) $(LDFLAGS) -o $@ $(INIT_XENSTORE_DOMAIN_OBJS) 
$(LDLIBS_libxentoollog) $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenguest) $(LDLIBS_libxenlight) $(APPEND_LDFLAGS)
 
 .PHONY: install
@@ -41,6 +41,9 @@ endif
 
 .PHONY: clean
 clean:
-   $(RM) -f *.o $(PROGS) $(DEPS)
+   $(RM) -f *.o $(PROGS) $(DEPS) _paths.h
 
 distclean: clean
+
+genpath-target = $(call buildmakevars2header,_paths.h)
+$(eval $(genpath-target))
diff --git a/tools/helpers/init-xenstore-domain.c 
b/tools/helpers/init-xenstore-domain.c
index 909542b..53b4b01 100644
--- a/tools/helpers/init-xenstore-domain.c
+++ b/tools/helpers/init-xenstore-domain.c
@@ -14,6 +14,7 @@
 #include 
 
 #include "init-dom-json.h"
+#include "_paths.h"
 
 static uint32_t domid = ~0;
 static char *kernel;
@@ -316,10 +317,10 @@ int main(int argc, char** argv)
 do_xs_write_dom(xsh, "memory/static-max", buf);
 xs_close(xsh);
 
-fd = creat("/var/run/xenstored.pid", 0666);
+fd = creat(XEN_RUN_DIR "/xenstored.pid", 0666);
 if ( fd < 0 )
 {
-fprintf(stderr, "Creating /var/run/xenstored.pid failed\n");
+fprintf(stderr, "Creating " XEN_RUN_DIR "/xenstored.pid failed\n");
 return 3;
 }
 rv = snprintf(buf, 16, "domid:%d\n", domid);
@@ -327,7 +328,8 @@ int main(int argc, char** argv)
 close(fd);
 if ( rv < 0 )
 {
-fprintf(stderr, "Writing domid to /var/run/xenstored.pid failed\n");
+fprintf(stderr,
+"Writing domid to " XEN_RUN_DIR "/xenstored.pid failed\n");
 return 3;
 }
 
-- 
2.1.4


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

[Xen-devel] [PATCH 3/7] hotplug/FreeBSD: honour XEN_RUN_DIR

[Wei Liu]

Store xldevd.pid under XEN_RUN_DIR. Note that the default location would
change from /var/run to /var/run/xen.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Roger Pau Monné 
---
 tools/hotplug/FreeBSD/rc.d/xendriverdomain.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in 
b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
index 4063c06..8ece7c3 100644
--- a/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
+++ b/tools/hotplug/FreeBSD/rc.d/xendriverdomain.in
@@ -18,7 +18,7 @@ start_cmd="xendriverdomain_startcmd"
 stop_cmd="xendriverdomain_stop"
 extra_commands=""
 
-XLDEVD_PIDFILE="/var/run/xldevd.pid"
+XLDEVD_PIDFILE="@XEN_RUN_DIR@/xldevd.pid"
 
 xendriverdomain_precmd()
 {
-- 
2.1.4


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