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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf d0a23f9f86dc39065429dc954adbc56b099b801e
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  147 days
Failing since 65593  2015-12-08 23:44:51 Z  147 days  206 attempts
Testing same since93414  2016-05-03 17:47:20 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

[Xen-devel] [qemu-upstream-4.6-testing test] 93415: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-startfail in 93389 pass in 93415
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat   fail pass in 93389

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  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-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-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   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-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu62936f64308aae81530b1273ad2c248b6476e62e
baseline version:
 qemuu9869880372c8e786502ce140d50158118e29a165

Last test of basis83624  2016-02-22 06:20:45 Z   71 days
Testing same since93357  2016-05-02 09:44:06 Z1 days4 attempts


People who touched revisions under test:
  "Hao, Xudong" 
  Anthony Perard 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  

Re: [Xen-devel] [PATCH v2 5/7] build: wire up pre-existing debug build flag

[Doug Goldstein]

On 5/3/16 9:50 AM, Jan Beulich wrote:
 On 03.05.16 at 16:29,  wrote:
>> This allows 'make debug=n' and 'make debug=y' work as it did previously
>> but only in the case of the user not having an existing .config file
>> from a 'make menuconfig'. This is because the command line 'debug' flag
>> can only be used to set the default value and if the user has already
>> built up a config with their real preference set.
> 
> Do we really need this?
> 
> Jan
> 

Honestly I did this because previously people didn't want to alter their
workflow, I am more than happy to drop this if others concur with you.

-- 
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] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Doug Goldstein]

On 5/3/16 9:43 AM, Jan Beulich wrote:
 On 03.05.16 at 16:29,  wrote:
>> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
>> was previously togglable on the command line so this adds a message for
>> users enabling it from the command line to tell them to enable it from
>> make menuconfig.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Jan Beulich 
>> CC: Andrew Cooper 
> 
> I think the Cc list should be quite a bit wider here.
> 
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -5,3 +5,14 @@ menuconfig DEBUG
>>If you want to debug Xen say Y and select any additional debugging
>>support options. Enabling this option is intended for development
>>purposes only, and not for production use.
>> +
>> +if DEBUG
> 
> Didn't we agree on "DEBUG || EXPERT" at the hackathon? With tha
> Reviewed-by: Jan Beulich 
> 

Well this will actually fundamentally change the patch. Because the
DEBUG flag is a menuconfig so I can't just do "DEBUG || EXPERT". I guess
the concern here is that I tied DEBUG to #undef NDEBUG? I can disconnect
that and make the operation of NDEBUG its own thing.

I can rename the CONFIG_VERBOSE_DEBUG option to something like
CONFIG_CONSOLE_DEBUG because its HYPERVISOR_console_io and ELF parsing.
Then create a CONFIG_VERBOSE_DEBUG option that controls NDEBUG?

-- 
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] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Tuesday, May 3, 2016 9:59 PM
> Cc: Andrew Cooper ; Wei Liu
> ; George Dunlap ; Ian
> Jackson ; Wu, Feng ; Stefano
> Stabellini ; xen-devel 
> ;
> Konrad Rzeszutek Wilk ; Tim Deegan 
> Subject: Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit
> PV guest code
> 
> >>> On 17.03.16 at 09:03,  wrote:
> > Since such guests' kernel code runs in ring 1, their memory accesses,
> > at the paging layer, are supervisor mode ones, and hence subject to
> > SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> > two features though (and so far we also don't expose the respective
> > feature flags), and hence may suffer page faults they cannot deal with.
> >
> > While the placement of the re-enabling slightly weakens the intended
> > protection, it was selected such that 64-bit paths would remain
> > unaffected where possible. At the expense of a further performance hit
> > the re-enabling could be put right next to the CLACs.
> >
> > Note that this introduces a number of extra TLB flushes - CR4.SMEP
> > transitioning from 0 to 1 always causes a flush, and it transitioning
> > from 1 to 0 may also do.
> >
> > Signed-off-by: Jan Beulich 
> 
> So I think we need to take some decision here, and I'm afraid
> Andrew and I won't be able to settle this between us. He's
> validly concerned about the performance impact this got proven
> to have (for 32-bit PV guests), yet I continue to think that correct
> behavior is more relevant than performance. Hence I think we
> should bite the bullet and take the change. For those who value
> performance more than security, they can always disable the use
> of SMEP and SMAP via command line option.

I think this is a proper solution for those who cares more about
performance. And BTW, Andrew, is there any detailed data which can
show the exact performance overhead introduced by this patch?

Thanks,
Feng

> 
> Of course I'm also concerned that Intel, who did introduce the
> functional regression in the first place, so far didn't participate at
> all in finding an acceptable solution to the problem at hand...
> 
> Jan


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

Re: [Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Doug Goldstein]

On 5/3/16 10:18 AM, Jan Beulich wrote:
 On 03.05.16 at 17:10,  wrote:
>> On 03/05/16 16:05, Jan Beulich wrote:
>> On 03.05.16 at 16:29,  wrote:
 --- /dev/null
 +++ b/xen/Kconfig.debug
 @@ -0,0 +1,7 @@
 +
 +menuconfig DEBUG
 +  bool "Debugging Options"
>>> One more thing: In the unstable branch this should really default to
>>> y, and the release check list should be adjusted to say that this
>>> default needs to be dropped (or inverted) while preparing a release.
>>>
>>> And obviously the "debug=" also needs to go away from ./Config.mk.
>>
>> Things other than Xen make use of debug= in the root Config.mk. 
>> Valgrind client requests for example in libxc.
>>
>> That option can't be moved without providing an alternative.
> 
> Why can't it be moved into tools/ if that's where it is still of interest?
> 
> Jan
> 

You could argue it could then move into the autoconf script which would
make the knobs more consistent for each part of the tree. The tools/
bits always as autoconf and the xen/ bits as Kconfig.

-- 
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] [PATCH v3 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

[Xu, Quan]

On May 04, 2016 10:02 AM, Tian, Kevin  wrote:
> > From: Xu, Quan
> > Sent: Friday, April 29, 2016 5:25 PM
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c
> > b/xen/drivers/passthrough/vtd/iommu.c
> > index cf847ec..bfee299 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -1301,7 +1301,7 @@ int domain_context_mapping_one(
> >  u64 maddr, pgd_maddr;
> >  u16 seg = iommu->intel->drhd->segment;
> >  int agaw;
> > -int rc;
> > +int rc, ret;
> >
> >  ASSERT(pcidevs_locked());
> >  spin_lock(>lock);
> > @@ -1435,7 +1435,12 @@ int domain_context_mapping_one(
> >  unmap_vtd_domain_page(context_entries);
> >
> >  if ( !seg )
> > -me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
> > +{
> > +ret = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
> > +
> > +if ( !rc && unlikely(ret) )
> > +rc = ret;
> > +}
> 
> similarly to make it simple no need to check ret again.

Agreed, I also hesitated to add this check. I'll drop similar ret check in this 
patch set.

Quan

> 
> >
> >  return rc;
> >  }


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

Re: [Xen-devel] [PATCH v3 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

[Xu, Quan]

On May 04, 2016 10:00 AM, Tian, Kevin  wrote:
> > From: Xu, Quan
> > Sent: Friday, April 29, 2016 5:25 PM
> > diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> > index 2885e31..9097333 100644
> > --- a/xen/arch/x86/acpi/power.c
> > +++ b/xen/arch/x86/acpi/power.c
> > @@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
> >
> >  static int device_power_down(void)
> >  {
> > +int err;
> > +
> >  console_suspend();
> >
> >  time_suspend();
> > @@ -53,11 +55,22 @@ static int device_power_down(void)
> >
> >  ioapic_suspend();
> >
> > -iommu_suspend();
> > +err = iommu_suspend();
> > +
> > +if ( err )
> > +goto iommu_suspend_error;
> >
> >  lapic_suspend();
> >
> >  return 0;
> > +
> > + iommu_suspend_error:
> > +ioapic_resume();
> > +i8259A_resume();
> > +time_resume();
> > +console_resume();
> > +
> > +return err;
> >  }
> 
> Jan had comment to better reuse device_power_up... looks no change in this
> version.

Yes,  __iiuc__, this may be an optimization, but not a must.
We can discuss this in detail In this version. 

Quan

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

Re: [Xen-devel] [PATCH v3 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index cf847ec..bfee299 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -1301,7 +1301,7 @@ int domain_context_mapping_one(
>  u64 maddr, pgd_maddr;
>  u16 seg = iommu->intel->drhd->segment;
>  int agaw;
> -int rc;
> +int rc, ret;
> 
>  ASSERT(pcidevs_locked());
>  spin_lock(>lock);
> @@ -1435,7 +1435,12 @@ int domain_context_mapping_one(
>  unmap_vtd_domain_page(context_entries);
> 
>  if ( !seg )
> -me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
> +{
> +ret = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
> +
> +if ( !rc && unlikely(ret) )
> +rc = ret;
> +}

similarly to make it simple no need to check ret again.

> 
>  return rc;
>  }


Thanks
Kevin

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

Re: [Xen-devel] [PATCH v3 09/10] IOMMU: propagate IOMMU Device-TLB flush error up to IOMMU suspending

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 2885e31..9097333 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -45,6 +45,8 @@ void do_suspend_lowlevel(void);
> 
>  static int device_power_down(void)
>  {
> +int err;
> +
>  console_suspend();
> 
>  time_suspend();
> @@ -53,11 +55,22 @@ static int device_power_down(void)
> 
>  ioapic_suspend();
> 
> -iommu_suspend();
> +err = iommu_suspend();
> +
> +if ( err )
> +goto iommu_suspend_error;
> 
>  lapic_suspend();
> 
>  return 0;
> +
> + iommu_suspend_error:
> +ioapic_resume();
> +i8259A_resume();
> +time_resume();
> +console_resume();
> +
> +return err;
>  }

Jan had comment to better reuse device_power_up... looks no change in this 
version.


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

Re: [Xen-devel] [PATCH v3 08/10] vt-d/ept: propagate IOMMU Device-TLB flush error up to EPT update.

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> 
> Propagate the IOMMU Device-TLB flush error up to the ept_set_entry(),
> when VT-d shares EPT page table.
> 
> Signed-off-by: Quan Xu 
> 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH v3 07/10] IOMMU: propagate IOMMU Device-TLB flush error up to iommu_iotlb_flush{, _all} (leaf ones).

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> 
> Propagate the IOMMU Device-TLB flush error up to the iommu_iotlb_flush{,_all}.
> 
> This patch fixes the leaf ones.
> 
> Signed-off-by: Quan Xu 
> 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Jan Beulich 
> CC: Kevin Tian 
> CC: Feng Wu 

Acked-by: Kevin Tian 

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

[Xen-devel] [xen-unstable test] 93408: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
93381

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

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  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-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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
 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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  356b5512b0dc9ce81a8007983a110de9798206dc
baseline version:
 xen  356b5512b0dc9ce81a8007983a110de9798206dc

Last test of basis93408  2016-05-03 15:19:14 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16925 days0 attempts

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-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev   

Re: [Xen-devel] [PATCH v3 03/10] IOMMU/MMU: enhance the call trees of IOMMU unmapping and mapping

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> 
> When IOMMU mapping is failed, we issue a best effort rollback, stopping
> IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
> error up to the call trees. When rollback is not feasible (in early
> initialization phase or trade-off of complexity) for the hardware domain,
> we do things on a best effort basis, only throwing out an error message.
> 
> IOMMU unmapping should perhaps continue despite an error, in an attempt
> to do best effort cleanup.
> 
> Signed-off-by: Quan Xu 
> 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: George Dunlap 
> ---
>  xen/arch/x86/mm.c   | 13 -
>  xen/arch/x86/mm/p2m-ept.c   | 27 +--
>  xen/arch/x86/mm/p2m-pt.c| 24 
>  xen/arch/x86/mm/p2m.c   | 11 +--
>  xen/drivers/passthrough/iommu.c | 14 +-
>  5 files changed, 75 insertions(+), 14 deletions(-)
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index a42097f..427097d 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -2467,7 +2467,7 @@ static int __get_page_type(struct page_info *page, 
> unsigned
> long type,
> int preemptible)
>  {
>  unsigned long nx, x, y = page->u.inuse.type_info;
> -int rc = 0;
> +int rc = 0, ret = 0;
> 
>  ASSERT(!(type & ~(PGT_type_mask | PGT_pae_xen_l2)));
> 
> @@ -2578,11 +2578,11 @@ static int __get_page_type(struct page_info *page, 
> unsigned
> long type,
>  if ( d && is_pv_domain(d) && unlikely(need_iommu(d)) )
>  {
>  if ( (x & PGT_type_mask) == PGT_writable_page )
> -iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
> +ret = iommu_unmap_page(d, mfn_to_gmfn(d, page_to_mfn(page)));
>  else if ( type == PGT_writable_page )
> -iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> -   page_to_mfn(page),
> -   IOMMUF_readable|IOMMUF_writable);
> +ret = iommu_map_page(d, mfn_to_gmfn(d, page_to_mfn(page)),
> + page_to_mfn(page),
> + IOMMUF_readable|IOMMUF_writable);
>  }
>  }
> 
> @@ -2599,6 +2599,9 @@ static int __get_page_type(struct page_info *page, 
> unsigned
> long type,
>  if ( (x & PGT_partial) && !(nx & PGT_partial) )
>  put_page(page);
> 
> +if ( !rc )
> +rc = ret;
> +
>  return rc;
>  }

I know there were quite some discussions before around above change (sorry I
didn't remember all of them). Just based on mental picture we should return
error where it firstly occurs. However above change looks favoring errors in
later "rc = alloc_page_type" over earlier iommu_map/unmap_page error. Is it
what we want? If there is a reason that we cannot return immediately upon
iommu_map/unmap, it's more reasonable to revert above check like below:

if ( !ret )
ret = rc;

return ret;

> 
> diff --git a/xen/arch/x86/mm/p2m-ept.c b/xen/arch/x86/mm/p2m-ept.c
> index 1ed5b47..df87944 100644
> --- a/xen/arch/x86/mm/p2m-ept.c
> +++ b/xen/arch/x86/mm/p2m-ept.c
> @@ -821,6 +821,8 @@ out:
>  if ( needs_sync )
>  ept_sync_domain(p2m);
> 
> +ret = 0;
> +
>  /* For host p2m, may need to change VT-d page table.*/
>  if ( rc == 0 && p2m_is_hostp2m(p2m) && need_iommu(d) &&
>   need_modify_vtd_table )
> @@ -831,11 +833,29 @@ out:
>  {
>  if ( iommu_flags )
>  for ( i = 0; i < (1 << order); i++ )
> -iommu_map_page(d, gfn + i, mfn_x(mfn) + i, iommu_flags);
> +{
> +rc = iommu_map_page(d, gfn + i, mfn_x(mfn) + i, 
> iommu_flags);
> +
> +if ( !ret && unlikely(rc) )

I think you should move check of ret before iommu_map_page, since we
should stop map against any error (either from best-effort unmap error side).

> +{
> +while ( i-- )
> +iommu_unmap_page(d, gfn + i);
> +
> +ret = rc;
> +break;
> +}
> +}
>  else
>  for ( i = 0; i < (1 << order); i++ )
> -iommu_unmap_page(d, gfn + i);
> +{
> +rc = iommu_unmap_page(d, gfn + i);
> +
> +if ( !ret && unlikely(rc) )
> +ret = rc;
> +}
>  }
> +
> +rc = 0;
>  }
> 
Thanks
Kevin

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH v3 02/10] IOMMU: handle IOMMU mapping and unmapping failures

[Tian, Kevin]

> From: Quan Xu
> Sent: Friday, April 29, 2016 5:25 PM
> 
> Treat IOMMU mapping and unmapping failures as a fatal to the domain
> (with the exception of the hardware domain).
> 
> If IOMMU mapping and unmapping failed, crash the domain (with the
> exception of the hardware domain) and propagate the error up to the
> call trees.
> 
> Signed-off-by: Quan Xu 
> Reviewed-by: Kevin Tian 
> 
> CC: Jan Beulich 
> ---
>  xen/drivers/passthrough/iommu.c | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c
> index b64676f..a0003ac 100644
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
> @@ -243,21 +243,47 @@ int iommu_map_page(struct domain *d, unsigned long gfn,
> unsigned long mfn,
> unsigned int flags)
>  {
>  struct hvm_iommu *hd = domain_hvm_iommu(d);
> +int rc;
> 
>  if ( !iommu_enabled || !hd->platform_ops )
>  return 0;
> 
> -return hd->platform_ops->map_page(d, gfn, mfn, flags);
> +rc = hd->platform_ops->map_page(d, gfn, mfn, flags);
> +
> +if ( rc )
> +{
> +if ( is_hardware_domain(d) )
> +printk(XENLOG_ERR
> +   "iommu_map_page: IOMMU mapping gfn %#lx mfn %#lx failed 
> for
> dom%d.",
> +   gfn, mfn, d->domain_id);
> +else
> +domain_crash(d);
> +}

It makes sense to print error messages for all domains, and
then selectively crash domain:

printk(XENLOG_ERR ...);
if ( !is_hardware_domain(d) )
domain_crash(d);

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

Re: [Xen-devel] [PATCH for 4.7 0/4] Assorted scheduling fixes

[Konrad Rzeszutek Wilk]

On Tue, May 03, 2016 at 11:46:27PM +0200, Dario Faggioli wrote:
> Hi,
> 
> This small series contains some bugfixes for various schedulers. They're all
> bugfixes, so I think all should be considered for 4.7. Here's some more
> detailed analysis.
> 
> Patch 1 and 3 are for Credit2. Patch 1 is a lot more important, as we have an
> ASSERT triggering without it. Patch 2 is behavioral fixing, which I believe it
> is important, but at least does not make anything explode.
> 
> Patch 2 fixes another ASSERT, in case a pCPU fails to come up. This is what
> Julien reported here:
> 
>  https://www.mail-archive.com/xen-devel@lists.xen.org/msg65918.html
> 
> Julien, the patch is very very similar to the one attached to one of my reply
> in that thread, but I had to change some small bits... Can you please re-test
> it?

I tested it. It does not crash anymore. However I see this:

(XEN) CPU1 never came online
(XEN) Failed to bring up CPU 1 (error -5)
(XEN) Bringing up CPU2
(XEN) CPU2 never came online
(XEN) Failed to bring up CPU 2 (error -5)
(XEN) Bringing up CPU3
(XEN) CPU3 never came online
(XEN) Failed to bring up CPU 3 (error -5)
(XEN) Brought up 1 CPUs


Which is not very reassuring. I don't know if that is expected.

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

Re: [Xen-devel] [PATCH v3 01/10] vt-d: fix the IOMMU flush issue

[Tian, Kevin]

> From: Xu, Quan
> Sent: Friday, April 29, 2016 5:25 PM
> 
> The propagation value from IOMMU flush interfaces may be positive, which
> indicates callers need to flush cache, not one of faliures.
> 
> when the propagation value is positive, this patch fixes this flush issue
> as follows:
>   - call iommu_flush_write_buffer() to flush cache.
>   - return zero.
> 
> Signed-off-by: Quan Xu 
> 
> CC: Kevin Tian 
> CC: Feng Wu 
> CC: Keir Fraser 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> ---
>  xen/drivers/passthrough/vtd/iommu.c | 94
> +
>  xen/include/asm-x86/iommu.h |  2 +-
>  2 files changed, 64 insertions(+), 32 deletions(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/iommu.c
> b/xen/drivers/passthrough/vtd/iommu.c
> index 5ad25dc..6e2e43a 100644
> --- a/xen/drivers/passthrough/vtd/iommu.c
> +++ b/xen/drivers/passthrough/vtd/iommu.c
> @@ -558,14 +558,16 @@ static void iommu_flush_all(void)
>  }
>  }
> 
> -static void __intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> -int dma_old_pte_present, unsigned int page_count)
> +static int iommu_flush_iotlb(struct domain *d, unsigned long gfn,
> + bool_t dma_old_pte_present,
> + unsigned int page_count)
>  {
>  struct hvm_iommu *hd = domain_hvm_iommu(d);
>  struct acpi_drhd_unit *drhd;
>  struct iommu *iommu;
>  int flush_dev_iotlb;
>  int iommu_domid;
> +int rc, ret = 0;
> 
>  /*
>   * No need pcideves_lock here because we have flush
> @@ -584,29 +586,35 @@ static void __intel_iommu_iotlb_flush(struct domain *d,
> unsigned long gfn,
>  continue;
> 
>  if ( page_count != 1 || gfn == INVALID_GFN )
> -{
> -if ( iommu_flush_iotlb_dsi(iommu, iommu_domid,
> -0, flush_dev_iotlb) )
> -iommu_flush_write_buffer(iommu);
> -}
> +rc = iommu_flush_iotlb_dsi(iommu, iommu_domid,
> +   0, flush_dev_iotlb);
>  else
> +rc = iommu_flush_iotlb_psi(iommu, iommu_domid,
> +   (paddr_t)gfn << PAGE_SHIFT_4K,
> +   PAGE_ORDER_4K,
> +   !dma_old_pte_present,
> +   flush_dev_iotlb);
> +
> +if ( rc > 0 )
>  {
> -if ( iommu_flush_iotlb_psi(iommu, iommu_domid,
> -(paddr_t)gfn << PAGE_SHIFT_4K, PAGE_ORDER_4K,
> -!dma_old_pte_present, flush_dev_iotlb) )
> -iommu_flush_write_buffer(iommu);
> +iommu_flush_write_buffer(iommu);
> +ret = 0;

You don't need 'ret' here. Just change 'rc' to 0.

>  }
> +else if ( rc < 0 )
> +ret = rc;

Then this change is not required

>  }
> +
> +return ret;

Then return 'rc' instead.

>  }
> 
>  static void intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn, 
> unsigned int
> page_count)

could we remove "Intel_" prefix completely? You can rename this
one to iommu_flush_iotlb_page...

>  {
> -__intel_iommu_iotlb_flush(d, gfn, 1, page_count);
> +iommu_flush_iotlb(d, gfn, 1, page_count);
>  }
> 
>  static void intel_iommu_iotlb_flush_all(struct domain *d)

and this one just iommu_flush_iotlb_all

>  {
> -__intel_iommu_iotlb_flush(d, INVALID_GFN, 0, 0);
> +iommu_flush_iotlb(d, INVALID_GFN, 0, 0);
>  }
> 


Thanks
Kevin

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

Re: [Xen-devel] [PATCH v2 3/5] x86/hvm: Rename hvm/event to hvm/monitor

[Tian, Kevin]

> From: Tamas K Lengyel [mailto:ta...@tklengyel.com]
> Sent: Saturday, April 30, 2016 2:08 AM
> 
> Mechanical renaming to better describe that the code in hvm/event is part of
> the monitor subsystem.
> 
> Signed-off-by: Tamas K Lengyel 

Acked-by: Kevin Tian 

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

Re: [Xen-devel] [PATCH V7] vm_event: Allow subscribing to write events for specific MSR-s

[Tian, Kevin]

> From: Razvan Cojocaru [mailto:rcojoc...@bitdefender.com]
> Sent: Friday, April 29, 2016 2:04 PM
> 
> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> The patch also introduces arch_monitor_init_domain() and
> arch_monitor_cleanup_domain(), to do monitor-specific work
> (as opposed to the previous way of doing all the setup in
> vm_event_init_domain() / vm_event_cleanup_domain()).
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
> 
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 
> 

Acked-by: Kevin Tian 

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

[Xen-devel] [xen-unstable baseline-only test] 44382: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44382 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44382/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 44378

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-midway   14 guest-stop   fail   like 44378
 build-amd64-rumpuserxen   6 xen-buildfail   like 44378
 build-i386-rumpuserxen6 xen-buildfail   like 44378
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44378
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44378

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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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  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-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  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

version targeted for testing:
 xen  356b5512b0dc9ce81a8007983a110de9798206dc
baseline version:
 xen  c2994f8632d56e5379e612daa216401477dccbdb

Last test of basis44378  2016-05-01 09:21:06 Z2 days
Testing same since44382  2016-05-03 15:20:23 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Tim Deegan 
  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-oldkern  pass
 build-i386-oldkern  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf d0a23f9f86dc39065429dc954adbc56b099b801e
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  147 days
Failing since 65593  2015-12-08 23:44:51 Z  146 days  205 attempts
Testing same since93414  2016-05-03 17:47:20 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

Re: [Xen-devel] xen/arm: Assertion 'timer->status >= TIMER_STATUS_inactive' failed at timer.c:279

[Dario Faggioli]

On Tue, 2016-05-03 at 14:23 +0100, Wei Liu wrote:
> On Tue, May 03, 2016 at 02:20:05PM +0100, George Dunlap wrote:
> > 
> > On Tue, May 3, 2016 at 2:03 PM, Julien Grall 
> > wrote:
> > > 
> > > Hi Dario and George,
> > > 
> > > What is the status of this patch? It would be nice to have it for
> > > Xen 4.7 to
> > > avoid unwanted crash when secondary CPUs fails to come online.
> > Wei, can you put this on your release blockers list?  (Julien, I
> > take
> > it this should be a blocker, right?)
> > 
> It's already on my list.
> 
Here it comes, as a part of a small series:
 http://lists.xen.org/archives/html/xen-devel/2016-05/msg00243.html

Sorry it took a bit but:
 1. I found a few other issues, an wanted to group them in a series;
 2. I tried to do what George asked, so document and put ASSERT()-s to
    make things clear and understandable.

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

[Xen-devel] [PATCH for 4.7 0/4] Assorted scheduling fixes

[Dario Faggioli]

Hi,

This small series contains some bugfixes for various schedulers. They're all
bugfixes, so I think all should be considered for 4.7. Here's some more
detailed analysis.

Patch 1 and 3 are for Credit2. Patch 1 is a lot more important, as we have an
ASSERT triggering without it. Patch 2 is behavioral fixing, which I believe it
is important, but at least does not make anything explode.

Patch 2 fixes another ASSERT, in case a pCPU fails to come up. This is what
Julien reported here:

 https://www.mail-archive.com/xen-devel@lists.xen.org/msg65918.html

Julien, the patch is very very similar to the one attached to one of my reply
in that thread, but I had to change some small bits... Can you please re-test
it?

Patch 4 makes the code of RTDS look consistent with what we state in patch 2,
so it's also important. Furthermore, it does fix a bug (although, again, not
one that would splat Xen) as, without it, we may have a timer used by the RTDS
scheduler bound to the pCPU of another cpupool with another scheduler. That
would introduce some unwanted and very difficult to recognize interference
between different schedulers in different pool, and should hence be avoided.

So this was awesomeness; about risks:
 - patch 1 is very small, super-self contained (zero impact outside of Credit2
   code) and it fixes an actual and 100% reproducible bug;
 - patch 2 is also totally self-contained and it can't possibly cause problems
   to anything else than to what it is trying to fix (Credit2's load balancer).
   It doesn't cure any ASSERT or Oops, so it's less interesting, but given the
   low risk --also considering that Credit2 will still be considered
   experimental in 4.7-- I think it can go in;
 - patch 3 is bigger, and a bit more complex. Note, however, that most of its
   content is code comments and ASSERT-s; it is self contained to scheduling
   (in the sense that it impacts all schedulers, but "just" them), and fixes
   a situation that, AFAIUI, is important for ARM;
 - patch 4 may again look not that critical. But, the fact that someone wanting
   to experiment with RTDS in a cpupool would face the kind of interference
   between independent cpupools that the patch cures is, I think, something
   worthwhile trying to avoid. Besides, it is again quite self contained, as
   it's indeed only relevant for RTDS (which is also going to be called
   experimental for 4.7).

Hope this helps. Thanks and Regards,
Dario
---
Dario Faggioli (4):
  xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()
  xen: sched: fix killing an uninitialized timer in free_pdata.
  xen: credit2: fix 2 (minor) issues in load tracking logic
  xen: adopt .deinit_pdata and improve timer handling

 xen/common/sched_credit.c  |   31 --
 xen/common/sched_credit2.c |   26 +++
 xen/common/sched_rt.c  |   74 +---
 xen/common/schedule.c  |   38 ++-
 xen/include/xen/sched-if.h |1 +
 5 files changed, 138 insertions(+), 32 deletions(-)
--
<> (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

[Xen-devel] [PATCH for 4.7 4/4] xen: adopt .deinit_pdata and improve timer handling

[Dario Faggioli]

The scheduling hooks API is now used properly, and no
initialization or de-initialization happen in
alloc/free_pdata any longer.

In fact, just like it is for Credit2, there is no real
need for implementing alloc_pdata and free_pdata.

This also made it possible to improve the replenishment
timer handling logic, such that now the timer is always
kept on one of the pCPU of the scheduler it's servicing.
Before this commit, in fact, even if the pCPU where the
timer happened to be initialized at creation time was
moved to another cpupool, the timer stayed there,
potentially inferfearing with the new scheduler of the
pCPU itself.

Signed-off-by: Dario Faggioli 
--
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Tianyang Chen 
Cc: Wei Liu 
---
 xen/common/sched_rt.c |   74 -
 1 file changed, 55 insertions(+), 19 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 673fc92..7f8f411 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -590,6 +590,10 @@ rt_init(struct scheduler *ops)
 if ( prv == NULL )
 return -ENOMEM;
 
+prv->repl_timer = xzalloc(struct timer);
+if ( prv->repl_timer == NULL )
+return -ENOMEM;
+
 spin_lock_init(>lock);
 INIT_LIST_HEAD(>sdom);
 INIT_LIST_HEAD(>runq);
@@ -600,12 +604,6 @@ rt_init(struct scheduler *ops)
 
 ops->sched_data = prv;
 
-/*
- * The timer initialization will happen later when
- * the first pcpu is added to this pool in alloc_pdata.
- */
-prv->repl_timer = NULL;
-
 return 0;
 }
 
@@ -614,7 +612,8 @@ rt_deinit(struct scheduler *ops)
 {
 struct rt_private *prv = rt_priv(ops);
 
-kill_timer(prv->repl_timer);
+ASSERT(prv->repl_timer->status == TIMER_STATUS_invalid ||
+   prv->repl_timer->status == TIMER_STATUS_killed);
 xfree(prv->repl_timer);
 
 ops->sched_data = NULL;
@@ -632,9 +631,19 @@ rt_init_pdata(const struct scheduler *ops, void *pdata, 
int cpu)
 spinlock_t *old_lock;
 unsigned long flags;
 
-/* Move the scheduler lock to our global runqueue lock.  */
 old_lock = pcpu_schedule_lock_irqsave(cpu, );
 
+/*
+ * TIMER_STATUS_invalid means we are the first cpu that sees the timer
+ * allocated but not initialized, and so it's up to us to initialize it.
+ */
+if ( prv->repl_timer->status == TIMER_STATUS_invalid )
+{
+init_timer(prv->repl_timer, repl_timer_handler, (void*) ops, cpu);
+dprintk(XENLOG_DEBUG, "RTDS: timer initialized on cpu %u\n", cpu);
+}
+
+/* Move the scheduler lock to our global runqueue lock.  */
 per_cpu(schedule_data, cpu).schedule_lock = >lock;
 
 /* _Not_ pcpu_schedule_unlock(): per_cpu().schedule_lock changed! */
@@ -659,6 +668,20 @@ rt_switch_sched(struct scheduler *new_ops, unsigned int 
cpu,
  */
 ASSERT(per_cpu(schedule_data, cpu).schedule_lock != >lock);
 
+/*
+ * If we are the absolute first cpu being switched toward this
+ * scheduler (in which case we'll see TIMER_STATUS_invalid), or the
+ * first one that is added back to the cpupool that had all its cpus
+ * removed (in which case we'll see TIMER_STATUS_killed), it's our
+ * job to (re)initialize the timer.
+ */
+if ( prv->repl_timer->status == TIMER_STATUS_invalid ||
+ prv->repl_timer->status == TIMER_STATUS_killed )
+{
+init_timer(prv->repl_timer, repl_timer_handler, (void*) new_ops, cpu);
+dprintk(XENLOG_DEBUG, "RTDS: timer initialized on cpu %u\n", cpu);
+}
+
 idle_vcpu[cpu]->sched_priv = vdata;
 per_cpu(scheduler, cpu) = new_ops;
 per_cpu(schedule_data, cpu).sched_priv = NULL; /* no pdata */
@@ -672,23 +695,36 @@ rt_switch_sched(struct scheduler *new_ops, unsigned int 
cpu,
 per_cpu(schedule_data, cpu).schedule_lock = >lock;
 }
 
-static void *
-rt_alloc_pdata(const struct scheduler *ops, int cpu)
+static void
+rt_deinit_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
+unsigned long flags;
 struct rt_private *prv = rt_priv(ops);
 
-if ( prv->repl_timer == NULL )
-{
-/* Allocate the timer on the first cpu of this pool. */
-prv->repl_timer = xzalloc(struct timer);
+spin_lock_irqsave(>lock, flags);
 
-if ( prv->repl_timer == NULL )
-return ERR_PTR(-ENOMEM);
+if ( prv->repl_timer->cpu == cpu )
+{
+struct cpupool *c = per_cpu(cpupool, cpu);
+unsigned int new_cpu = cpumask_cycle(cpu, cpupool_online_cpumask(c));
 
-init_timer(prv->repl_timer, repl_timer_handler, (void *)ops, cpu);
+/*
+ * Make sure the timer run on one of the cpus that are still available
+ * to this scheduler. If there aren't any left, it means it's the time
+ * to just kill it.
+ */
+if ( new_cpu >= nr_cpu_ids )
+{
+

[Xen-devel] [PATCH for 4.7 1/4] xen: sched: avoid spuriously re-enabling IRQs in csched2_switch_sched()

[Dario Faggioli]

In fact, interrupts are already disabled when calling
the hook from schedule_cpu_switch(), and hence using
anything different than just spin_lock() is wrong (and
ASSERT()-s in debug builds) or unnecessary.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Wei Liu 
---
 xen/common/sched_credit2.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 46b9279..50c1b9d 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2232,7 +2232,7 @@ csched2_switch_sched(struct scheduler *new_ops, unsigned 
int cpu,
  * And owning exactly that one (the lock of the old scheduler of this
  * cpu) is what is necessary to prevent races.
  */
-spin_lock_irq(>lock);
+spin_lock(>lock);
 
 idle_vcpu[cpu]->sched_priv = vdata;
 
@@ -2257,7 +2257,7 @@ csched2_switch_sched(struct scheduler *new_ops, unsigned 
int cpu,
 smp_mb();
 per_cpu(schedule_data, cpu).schedule_lock = >rqd[rqi].lock;
 
-spin_unlock_irq(>lock);
+spin_unlock(>lock);
 }
 
 static void


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

[Xen-devel] [PATCH for 4.7 3/4] xen: credit2: fix 2 (minor) issues in load tracking logic

[Dario Faggioli]

All calculations that involve load_last_update uses quantities
shifted by LOADAVG_GRANULARITY_SHIFT, so make sure that this
is true even when the field is assigned a value for the first
time, during vcpu allocation.

Also, during migration, while the loads of both the source and
destination runqueues certainly need changing, the vcpu being
moved does not change its running/non-running status, and its
calculated load should hence not be affected.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Wei Liu 
---
 xen/common/sched_credit2.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 803cc44..393364a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -867,7 +867,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
vcpu *vc, void *dd)
 svc->weight = svc->sdom->weight;
 /* Starting load of 50% */
 svc->avgload = 1ULL << (CSCHED2_PRIV(ops)->load_window_shift - 1);
-svc->load_last_update = NOW();
+svc->load_last_update = NOW() >> LOADAVG_GRANULARITY_SHIFT;
 }
 else
 {
@@ -1301,7 +1301,7 @@ static void migrate(const struct scheduler *ops,
 if ( __vcpu_on_runq(svc) )
 {
 __runq_remove(svc);
-update_load(ops, svc->rqd, svc, -1, now);
+update_load(ops, svc->rqd, NULL, -1, now);
 on_runq=1;
 }
 __runq_deassign(svc);
@@ -1314,7 +1314,7 @@ static void migrate(const struct scheduler *ops,
 __runq_assign(svc, trqd);
 if ( on_runq )
 {
-update_load(ops, svc->rqd, svc, 1, now);
+update_load(ops, svc->rqd, NULL, 1, now);
 runq_insert(ops, svc->vcpu->processor, svc);
 runq_tickle(ops, svc->vcpu->processor, svc, now);
 SCHED_STAT_CRANK(migrate_on_runq);


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

[Xen-devel] [PATCH for 4.7 2/4] xen: sched: fix killing an uninitialized timer in free_pdata.

[Dario Faggioli]

commit 64269d9365 "sched: implement .init_pdata in Credit,
Credit2 and RTDS" helped fixing Credit2 runqueues, and
the races we had in switching scheduler for pCPUs, but
introduced another issue. In fact, if CPU bringup fails
during __cpu_up() (and, more precisely, after CPU_UP_PREPARE,
but before CPU_STARTING) the CPU_UP_CANCELED notifier
would be executed, which calls the free_pdata hook.

Such hook does, right now, two things: (1) undo the
initialization done inside the init_pdata hook and (2)
free the memory allocated by the alloc_pdata hook.

However, in the failure path just described, it is possible
that only alloc_pdata were called, and this is potentially
an issue (depending on how actually free_pdata does).

In fact, for Credit1 (the only scheduler that actually
allocates per-pCPU data), this result in calling kill_timer()
on a timer that had not yet been initialized, which causes
the following:

(XEN) Xen call trace:
(XEN)[<0022e304>] timer.c#active_timer+0x8/0x24 (PC)
(XEN)[<0022f624>] kill_timer+0x108/0x2e0 (LR)
(XEN)[<002208c0>] sched_credit.c#csched_free_pdata+0xd8/0x114
(XEN)[<00227a18>] schedule.c#cpu_schedule_callback+0xc0/0x12c
(XEN)[<00219944>] notifier_call_chain+0x78/0x9c
(XEN)[<002015fc>] cpu_up+0x104/0x130
(XEN)[<0028f7c0>] start_xen+0xaf8/0xce0
(XEN)[<810021d8>] 810021d8
(XEN)
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'timer->status >= TIMER_STATUS_inactive' failed at timer.c:279
(XEN) 

Solve this by making the scheduler hooks API symmetric again,
i.e., by adding a deinit_pdata hook and making it responsible
of undoing what init_pdata did, rather than asking to free_pdata
to do everything.

This is cleaner and, in the case at hand, makes it possible to
only call free_pdata (which is the right thing to do) as only
allocation and no initialization was performed.

Reported-by: Julien Grall 
Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Konrad Rzeszutek Wilk 
Cc: varun.sw...@arm.com
Cc: Steve Capper 
Cc: Wei Liu 
---
 xen/common/sched_credit.c  |   31 +++
 xen/common/sched_credit2.c |   16 +---
 xen/common/schedule.c  |   38 +-
 xen/include/xen/sched-if.h |1 +
 4 files changed, 78 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index bc36837..db4d42a 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -485,11 +485,35 @@ static void
 csched_free_pdata(const struct scheduler *ops, void *pcpu, int cpu)
 {
 struct csched_private *prv = CSCHED_PRIV(ops);
+
+/*
+ * pcpu either points to a valid struct csched_pcpu, or is NULL, if we're
+ * beeing called from CPU_UP_CANCELLED, because bringing up a pCPU failed
+ * very early. xfree() does not really mind, but we want to be sure that,
+ * when we get here, either init_pdata has never been called, or
+ * deinit_pdata has been called already.
+ */
+ASSERT(!cpumask_test_cpu(cpu, prv->cpus));
+
+xfree(pcpu);
+}
+
+static void
+csched_deinit_pdata(const struct scheduler *ops, void *pcpu, int cpu)
+{
+struct csched_private *prv = CSCHED_PRIV(ops);
 struct csched_pcpu *spc = pcpu;
 unsigned long flags;
 
-if ( spc == NULL )
-return;
+/*
+ * Scheduler specific data for this pCPU must still be there and and be
+ * valid. In fact, if we are here:
+ *  1. alloc_pdata must have been called for this cpu, and free_pdata
+ * must not have been called on it before us,
+ *  2. init_pdata must have been called on this cpu, and deinit_pdata
+ * (us!) must not have been called on it already.
+ */
+ASSERT(spc && cpumask_test_cpu(cpu, prv->cpus));
 
 spin_lock_irqsave(>lock, flags);
 
@@ -507,8 +531,6 @@ csched_free_pdata(const struct scheduler *ops, void *pcpu, 
int cpu)
 kill_timer(>master_ticker);
 
 spin_unlock_irqrestore(>lock, flags);
-
-xfree(spc);
 }
 
 static void *
@@ -2091,6 +2113,7 @@ static const struct scheduler sched_credit_def = {
 .free_vdata = csched_free_vdata,
 .alloc_pdata= csched_alloc_pdata,
 .init_pdata = csched_init_pdata,
+.deinit_pdata   = csched_deinit_pdata,
 .free_pdata = csched_free_pdata,
 .switch_sched   = csched_switch_sched,
 .alloc_domdata  = csched_alloc_domdata,
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 50c1b9d..803cc44 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2201,6 +2201,12 @@ csched2_init_pdata(const struct scheduler *ops, void 
*pdata, int cpu)
 unsigned long flags;
 unsigned rqi;
 
+   

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

[osstest service owner]

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

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  1ca472c7208a7f72ab8a61aa7fe5fe1954fc345b
baseline version:
 xen  b90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483

Last test of basis93406  2016-05-03 14:01:58 Z0 days
Testing same since93412  2016-05-03 17:00:57 Z0 days1 attempts


People who touched revisions under test:
  David Vrabel 

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=1ca472c7208a7f72ab8a61aa7fe5fe1954fc345b
+ . ./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 
1ca472c7208a7f72ab8a61aa7fe5fe1954fc345b
+ branch=xen-unstable-smoke
+ revision=1ca472c7208a7f72ab8a61aa7fe5fe1954fc345b
+ . ./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.6-testing
+ '[' x1ca472c7208a7f72ab8a61aa7fe5fe1954fc345b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] Regression in Xen 4.7-rc1 - can't boot HVM guests with more than 64 vCPUS.

[Konrad Rzeszutek Wilk]

On Tue, May 3, 2016 at 12:55 PM, Konrad Rzeszutek Wilk
 wrote:
> On Tue, May 3, 2016 at 12:47 PM, Konrad Rzeszutek Wilk
>  wrote:
>>
>> The host has 240 CPUs and the HVM guests config looks as follow:
>>
>> -bash-4.1# cat /hvm.cfg
>> memory=64000

You can also make this 1024.

And on another machine (which only has 4 physical CPUs) I got some
date when trying starting this guest. The xl dmesg:reports

(XEN) HVM1 save: CPU
(XEN) HVM1 save: PIC
(XEN) HVM1 save: IOAPIC
(XEN) HVM1 save: LAPIC
(XEN) HVM1 save: LAPIC_REGS
(XEN) HVM1 save: PCI_IRQ
(XEN) HVM1 save: ISA_IRQ
(XEN) HVM1 save: PCI_LINK
(XEN) HVM1 save: PIT
(XEN) HVM1 save: RTC
(XEN) HVM1 save: HPET
(XEN) HVM1 save: PMTIMER
(XEN) HVM1 save: MTRR
(XEN) HVM1 save: VIRIDIAN_DOMAIN
(XEN) HVM1 save: CPU_XSAVE
(XEN) HVM1 save: VIRIDIAN_VCPU
(XEN) HVM1 save: VMCE_VCPU
(XEN) HVM1 save: TSC_ADJUST
(XEN) HVM1 restore: CPU 0

.. and:
bash-4.1# head qemu-dm-latest.log
char device redirected to /dev/pts/1 (label serial0)
qemu: hardware error: Fatal error while trying to get io event!

CPU #0:
EAX= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0

Let me try 4.6 and see where this goes. I know that 4.4 works fine.

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

Re: [Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Tamas K Lengyel]

On Tue, May 3, 2016 at 5:31 AM, Julien Grall  wrote:

> Hi Tamas,
>
>
> On 29/04/16 19:07, Tamas K Lengyel wrote:
>
>> The ARM SMC instructions are already configured to trap to Xen by
>> default. In
>> this patch we allow a user-space process in a privileged domain to receive
>> notification of when such event happens through the vm_event subsystem by
>> introducing the PRIVILEGED_CALL type.
>>
>> Signed-off-by: Tamas K Lengyel 
>> ---
>> Cc: Razvan Cojocaru 
>> Cc: Ian Jackson 
>> Cc: Stefano Stabellini 
>> Cc: Wei Liu 
>> Cc: Julien Grall 
>> Cc: Keir Fraser 
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>>
>> v2: introduce VM_EVENT_REASON_PRIVELEGED_CALL
>>  aarch64 support
>> ---
>>   MAINTAINERS |   6 +-
>>   tools/libxc/include/xenctrl.h   |   2 +
>>   tools/libxc/xc_monitor.c|  26 +++-
>>   tools/tests/xen-access/xen-access.c |  31 -
>>   xen/arch/arm/Makefile   |   2 +
>>   xen/arch/arm/monitor.c  |  80 +++
>>   xen/arch/arm/traps.c|  20 +-
>>   xen/arch/arm/vm_event.c | 127
>> 
>>   xen/arch/x86/hvm/event.c|   2 +
>>   xen/common/vm_event.c   |   1 -
>>   xen/include/asm-arm/domain.h|   5 ++
>>   xen/include/asm-arm/monitor.h   |  20 ++
>>   xen/include/asm-arm/vm_event.h  |  16 ++---
>>   xen/include/public/domctl.h |   1 +
>>   xen/include/public/vm_event.h   |  27 
>>   15 files changed, 333 insertions(+), 33 deletions(-)
>>   create mode 100644 xen/arch/arm/monitor.c
>>   create mode 100644 xen/arch/arm/vm_event.c
>>
>
> This patch is doing lots of things:
> - Add support for monitoring
> - Add support for vm_event
> - Monitor SMC
> - Move common code to arch specific code
>
> As far as I can tell, all are distinct from each other. Can you please
> split this patch in smaller ones?
>

While I can split off some parts into separate patches, like
getting/setting ARM registers through VM events and the tools patches, the
other components are pretty tightly coupled and don't actually make sense
to split them. For example, enabling a monitor domctl for an event without
the VM event components doesn't make much sense. Vice verse for the
vm_event parts without being able to enable them.


>
> [...]
>
> diff --git a/xen/arch/arm/monitor.c b/xen/arch/arm/monitor.c
>> new file mode 100644
>> index 000..e845f28
>> --- /dev/null
>> +++ b/xen/arch/arm/monitor.c
>>
>
> [...]
>
> +int monitor_smc(const struct cpu_user_regs *regs) {
>>
>
> The { should be on a separate line.


Ack.


>
>
> +struct vcpu *curr = current;
>> +vm_event_request_t req = { 0 };
>> +
>> +if ( !curr->domain->arch.monitor.privileged_call_enabled )
>> +return 0;
>> +
>> +req.reason = VM_EVENT_REASON_PRIVILEGED_CALL;
>> +req.vcpu_id = curr->vcpu_id;
>> +
>> +vm_event_fill_regs(, regs, curr->domain);
>> +
>> +return vm_event_monitor_traps(curr, 1, );
>> +}
>> +
>> +/*
>> + * Local variables:
>> + * mode: C
>> + * c-file-style: "BSD"
>> + * c-basic-offset: 4
>> + * indent-tabs-mode: nil
>> + * End:
>> + */
>> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
>> index 9abfc3c..9c8d395 100644
>> --- a/xen/arch/arm/traps.c
>> +++ b/xen/arch/arm/traps.c
>> @@ -41,6 +41,7 @@
>>   #include 
>>   #include 
>>   #include 
>> +#include 
>>
>>   #include "decode.h"
>>   #include "vtimer.h"
>> @@ -2491,6 +2492,21 @@ bad_data_abort:
>>   inject_dabt_exception(regs, info.gva, hsr.len);
>>   }
>>
>> +static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
>> +{
>> +int rc = 0;
>>
>
> Newline here.
>

Ack.


>
> +if ( current->domain->arch.monitor.privileged_call_enabled )
>> +{
>> +rc = monitor_smc(regs);
>> +}
>>
>
> The bracket are not necessary.
>

Ack.


>
> +
>> +if ( rc != 1 )
>>
>
> I think the code would be clearer if you introduce a define for "1".
>

Maybe not a define but calling the variable "handled" as we do on x86 would
be more descriptive.


>
> +{
>> +GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr));
>>
>
> This check cannot work for AArch64 guest.


For HSR_EC_SMC32 there is already
GUEST_BUG_ON(!psr_mode_is_32bit(regs->cpsr)); and for HSR_EC_SMC64 there is
GUEST_BUG_ON(psr_mode_is_32bit(regs->cpsr)); before calling do_trap_smc. So
are you saying that check is wrong for AArch64 as it is right now in
unstable? Also, is there any reason those checks are opposite of each other?


>
>
> +inject_undef_exception(regs, hsr);
>> +}
>> +}
>> +
>>   static void enter_hypervisor_head(struct cpu_user_regs *regs)
>>   {
>>   if ( 

Re: [Xen-devel] [PATCH V3] x86/monitor: Disallow setting mem_access_emulate_each_rep when vm_event is NULL

[Tamas K Lengyel]

On Tue, May 3, 2016 at 2:18 AM, Razvan Cojocaru 
wrote:

> On 05/03/2016 11:14 AM, Jan Beulich wrote:
>  On 29.04.16 at 18:12,  wrote:
> >> On 04/09/16 08:54, Razvan Cojocaru wrote:
> >>> It is meaningless (and potentially dangerous - see
> hvmemul_virtual_to_linear())
> >>> to set mem_access_emulate_each_rep before xc_monitor_enable() (which
> allocates
> >>> vcpu->arch.vm_event) has been called, so return an error from the
> >>> XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP hypercall when that is the case.
> >>>
> >>> Signed-off-by: Razvan Cojocaru 
> >>> Reviewed-by: Andrew Cooper 
> >>>
> >>> ---
> >>> Changes since V2:
> >>>  - Updated the if() condition as recommended by Andrew Cooper.
> >>>  - Added Andrew Cooper's Reviewed-by.
> >>> ---
> >>>  xen/include/asm-x86/monitor.h | 16 +---
> >>>  1 file changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/xen/include/asm-x86/monitor.h
> b/xen/include/asm-x86/monitor.h
> >>> index 0954b59..d367099 100644
> >>> --- a/xen/include/asm-x86/monitor.h
> >>> +++ b/xen/include/asm-x86/monitor.h
> >>> @@ -32,19 +32,29 @@
> >>>  static inline
> >>>  int arch_monitor_domctl_op(struct domain *d, struct
> xen_domctl_monitor_op *mop)
> >>>  {
> >>> +int rc = 0;
> >>> +
> >>>  switch ( mop->op )
> >>>  {
> >>>  case XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP:
> >>>  domain_pause(d);
> >>> -d->arch.mem_access_emulate_each_rep = !!mop->event;
> >>> +/*
> >>> + * Enabling mem_access_emulate_each_rep without a vm_event
> subscriber
> >>> + * is meaningless.
> >>> + */
> >>> +if ( d->max_vcpus && d->vcpu[0] && d->vcpu[0]->arch.vm_event )
> >>> +d->arch.mem_access_emulate_each_rep = !!mop->event;
> >>> +else
> >>> +rc = -EINVAL;
> >>> +
> >>>  domain_unpause(d);
> >>>  break;
> >>>
> >>>  default:
> >>> -return -EOPNOTSUPP;
> >>> +rc = -EOPNOTSUPP;
> >>>  }
> >>>
> >>> -return 0;
> >>> +return rc;
> >>>  }
> >>>
> >>>  int arch_monitor_domctl_event(struct domain *d,
> >>
> >> According to the previous list discussion with Andrew Cooper, this fix
> >> might be considered for the 4.7 release, so CC-ing Wei for a release
> >> ack, as suggested.
> >
> > Even if - without the pending ./MAINTAINERS adjustment - not
> > formally required, I don't understand why you didn't Cc Tamas on
> > this patch. I don't think this should go in without his ack.
>
> Of course, I was under the impression that he was in the recipients list
> (I let scripts/maintaners.pl do the work and didn't pay much attention
> to its output).
>
> By all means.
>

The maintainers file wasn't covering this header properly. Fixed in my
other patch-set.

Acked-by: Tamas K Lengyel 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Greg KH]

On Tue, May 03, 2016 at 10:10:24AM -0700, Luis R. Rodriguez wrote:
> On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez  wrote:
> > Thanks! Can you confirm if any Android or Brillo builds are already using 
> > it?
> 
> Also more importantly, any chance you can provide any technical
> reasons why initramfs cannot be used, or it was decided to not use it
> on these systems? It should help others in the future as well.

Some systems just don't need it, nor want it.  We can't break working
systems, so this is not something we can remove, sorry.

thanks,

greg k-h

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

[Xen-devel] [qemu-upstream-4.6-testing test] 93389: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm  3 host-install(3) broken in 93371 REGR. vs. 83624

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start fail pass in 93371

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)blocked in 93371 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)blocked in 93371 n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 93371 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 93371 never pass
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 93371 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-amd64-amd64-libvirt-xsm 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-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-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-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu62936f64308aae81530b1273ad2c248b6476e62e
baseline version:
 qemuu9869880372c8e786502ce140d50158118e29a165

Last test of basis83624  2016-02-22 06:20:45 Z   71 days
Testing same since93357  2016-05-02 09:44:06 Z1 days3 attempts


People who touched revisions under test:
  "Hao, Xudong" 
  Anthony Perard 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 0cd1e699e5f76b3323b5881932af8a62bc5edf2a
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  147 days
Failing since 65593  2015-12-08 23:44:51 Z  146 days  204 attempts
Testing same since93395  2016-05-03 07:56:26 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 
  Tian, Feng 
  Vladislav Vovchenko 
  Volker Rümelin 
  Yao Jiewen 
  Yao, 

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Kees Cook]

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez  wrote:
> On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez  wrote:
>> Thanks! Can you confirm if any Android or Brillo builds are already using it?
>
> Also more importantly, any chance you can provide any technical
> reasons why initramfs cannot be used, or it was decided to not use it
> on these systems? It should help others in the future as well.

In Chrome OS, the kernels are built specifically for the hardware
they're going to be on, so an initramfs was seen as a needless
additional boot step. Since Chrome OS was heavily optimized for boot
speed, it was designed to not need the initramfs at all. This is
actually enforced by the read-only boot firmware, so there's no
trivial way to _start_ using an initramfs on (existing) Chrome OS
devices either.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Luis R. Rodriguez]

On Tue, May 3, 2016 at 10:10 AM, Luis R. Rodriguez  wrote:
> or it was decided

Sorry I meant to say: 'or _why_ it was decided to not use initramfs on
these systems?'

  Luis

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Luis R. Rodriguez]

On Tue, May 3, 2016 at 10:07 AM, Luis R. Rodriguez  wrote:
> Thanks! Can you confirm if any Android or Brillo builds are already using it?

Also more importantly, any chance you can provide any technical
reasons why initramfs cannot be used, or it was decided to not use it
on these systems? It should help others in the future as well.

  Luis

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Luis R. Rodriguez]

On Mon, May 2, 2016 at 11:41 AM, Greg KH  wrote:
> On Mon, May 02, 2016 at 11:34:33AM -0700, Kees Cook wrote:
>> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez  wrote:
>> > On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote:
>> >> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
>> >> > This ports built-in firmware to use linker tables,
>> >> > this replaces the custom section solution with a
>> >> > generic solution.
>> >> >
>> >> > This also demos the use of the .rodata (SECTION_RO)
>> >> > linker tables.
>> >> >
>> >> > Tested with 0 built-in firmware, 1 and 2 built-in
>> >> > firmwares successfully.
>> >>
>> >> I think we'd do better to rip this support out entirely. It just isn't
>> >> needed; firmware can live in an initramfs and don't even need *any*
>> >> actual running userspace support to load it from there these days, do
>> >> we?
>> >
>> > I think this is reasonable if and only if we really don't know of anyone
>> > out there not able to use initramfs. I'm happy to rip it out.
>>
>> The changelog for this doesn't say anything about _why_ the change is
>> being made? (and what about other architectures.) Also, Chrome OS
>> doesn't use an initramfs (and plenty of other things don't too). Being
>> able to build monolithic kernels (e.g. Android and Brillo) with
>> builtin firmware is very handy. Please don't remove built-in firmware
>> support.
>
> I second this, we can't break existing systems at all.  I thought we
> were going to keep built-in firmware, right Luis?

Removing built-in firmware was simply a suggestion by David which we
were evaluating here -- patches were not even yet produced, although I
have them now if we wanted to rip it out. Since Kees noted it has
users, we'll keep it.

 Luis

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Luis R. Rodriguez]

On Mon, May 2, 2016 at 11:34 AM, Kees Cook  wrote:
> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez  wrote:
>> On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote:
>>> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
>>> > This ports built-in firmware to use linker tables,
>>> > this replaces the custom section solution with a
>>> > generic solution.
>>> >
>>> > This also demos the use of the .rodata (SECTION_RO)
>>> > linker tables.
>>> >
>>> > Tested with 0 built-in firmware, 1 and 2 built-in
>>> > firmwares successfully.
>>>
>>> I think we'd do better to rip this support out entirely. It just isn't
>>> needed; firmware can live in an initramfs and don't even need *any*
>>> actual running userspace support to load it from there these days, do
>>> we?
>>
>> I think this is reasonable if and only if we really don't know of anyone
>> out there not able to use initramfs. I'm happy to rip it out.
>
> The changelog for this doesn't say anything about _why_ the change is
> being made? (and what about other architectures.)

To be clear the RFC patch here is about linker table use and porting
custom table uses for a generic linker table solution. The topic of
conversation later changed to suggest that instead of porting built-in
firmware to linker tables we should just consider removing built-in
firmware all together. As for the reason _why_ we'd port built-in
firmware to linker tables, I'll be sure to add that in the next
iteration. The reason is that Linux has scattered strategies to both
extend and use custom linker sections, often requiring modifying the
custom linker script. The effort behind the linker script provides a
unified mechanism to do this, and also enables us to avoid having to
extend the custom linker script for this type of use.

> Also, Chrome OS
> doesn't use an initramfs (and plenty of other things don't too). Being
> able to build monolithic kernels (e.g. Android and Brillo) with
> builtin firmware is very handy. Please don't remove built-in firmware
> support.

Thanks! Can you confirm if any Android or Brillo builds are already using it?

  Luis

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

Re: [Xen-devel] [xen-unstable test] 93364: regressions - FAIL

[Dario Faggioli]

On Tue, 2016-05-03 at 11:34 +0100, Wei Liu wrote:
> On Tue, May 03, 2016 at 12:20:45AM +, osstest service owner
> wrote:
> > 
> > flight 93364 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/93364/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail
> > REGR. vs. 93337
> > 
> Commits tested in this flight:
> 
> xsplice: Missing if ( sec )
> tools: xen-xsplice.c: fix length parameter of memset in list_func
> ocaml/xc_get_cpu_featureset/arm: Return not implemented on ARM
> x86/shadow: account for ioreq server pages before complaining
> about
> not found mapping
> 
> I'm pretty sure the commits will not affect ARM guest startup, i.e.
> this
> is spurious failure. We can force push this if it is necessary.
> 
Agreed on the spurious-ness.

This occasional failure of Credit2 on ARM is next on my TODO list of
things to investigate, as soon as I'll be finished with merlot (which
is also not going as quick as I hoped, but anyway)

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] Regression in Xen 4.7-rc1 - can't boot HVM guests with more than 64 vCPUS.

[Konrad Rzeszutek Wilk]

On Tue, May 3, 2016 at 12:47 PM, Konrad Rzeszutek Wilk
 wrote:
>
> The host has 240 CPUs and the HVM guests config looks as follow:
>
> -bash-4.1# cat /hvm.cfg
> memory=64000
> name="big64"
> vcpus = 64
> disk= ['file:/isos/root_image.iso,hdc:cdrom,r']
> builder="hvm"

If I add :
device_model_version = 'qemu-xen-traditional'


> serial='pty'
> usb=1
> vnclisten="0.0.0.0:64"
>
I get this in /var/log/xen/qemu-dm-big64-qemu-trad.log:
-bash-4.1# cat qemu-dm-big64-qemu-trad.log
domid: 15
Strip off blktap sub-type prefix to /isos/root_image.iso (drv 'aio')
Using file /isos/root_image.iso in read-only mode
Watching device-model/15/logdirty/cmd
Watching device-model/15/command
Watching /local/domain/15/cpu
char device redirected to /dev/pts/13
qemu_map_cache_init nr_buckets = 1 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = f46f33b7-8e8d-4b63-b56c-4e01af0448d2
populating video RAM at ff00
mapping video RAM from ff00
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(device-model/15/xen_extended_power_mgmt): read error
xs_read(): vncpasswd get error.
/vm/f46f33b7-8e8d-4b63-b56c-4e01af0448d2/vncpasswd.
medium change watch on `hdc' (index: 0): aio:/isos/root_image.iso
Fatal error while trying to get io event!

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

Re: [Xen-devel] QEMU-TRAD Re: [PATCH] Fixed building with newer GNUTLS versions.

[Wei Liu]

On Tue, May 03, 2016 at 12:49:07PM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 03, 2016 at 05:35:45PM +0100, Wei Liu wrote:
> > The original patch seems to malformed.
> > 
> > I skim the code, the refactoring parts look correct to me. What I'm not
> > sure is whether the replacement is correct or not.
> > 
> > The reference to gnutls_priority_set_direct in [0] is from a section
> > called "Upgrading to 3.4.x from 3.3.x", while the version check in the
> > proposed patch checks for 2.2.0.
> > 
> > Do I miss anything here? What version does Fedora have?
> 
> gnutls-3.4.9-1.fc23.x86_64
> 
> qemu-trad builds fine under 
> gnutls-2.8.5-4.fc13.x86_64

So I guess we should fix the version checking in this patch. We should
go with 3.4 because that's what is in the canonical source.

Wei.

> 
> > 
> > Thanks
> > Wei.

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

Re: [Xen-devel] [PATCH 1/2] x86/p2m: clean up altp2m

[George Dunlap]

On Fri, Apr 29, 2016 at 3:49 PM, Jan Beulich  wrote:
> Signed-off-by: Jan Beulich 

Acked-by: George Dunlap 

>
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -618,9 +618,11 @@ void p2m_teardown(struct p2m_domain *p2m
>
>  void p2m_final_teardown(struct domain *d)
>  {
> -/* We must teardown unconditionally because
> +/*
> + * We must teardown both of them unconditionally because
>   * we initialise them unconditionally.
>   */
> +p2m_teardown_altp2m(d);
>  p2m_teardown_nestedp2m(d);
>
>  /* Iterate over all p2m tables per domain */
>
>
>
>
> ___
> 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] QEMU-TRAD Re: [PATCH] Fixed building with newer GNUTLS versions.

[Konrad Rzeszutek Wilk]

On Tue, May 03, 2016 at 05:35:45PM +0100, Wei Liu wrote:
> The original patch seems to malformed.
> 
> I skim the code, the refactoring parts look correct to me. What I'm not
> sure is whether the replacement is correct or not.
> 
> The reference to gnutls_priority_set_direct in [0] is from a section
> called "Upgrading to 3.4.x from 3.3.x", while the version check in the
> proposed patch checks for 2.2.0.
> 
> Do I miss anything here? What version does Fedora have?

gnutls-3.4.9-1.fc23.x86_64

qemu-trad builds fine under 
gnutls-2.8.5-4.fc13.x86_64

> 
> Thanks
> Wei.

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

[Xen-devel] Regression in Xen 4.7-rc1 - can't boot HVM guests with more than 64 vCPUS.

[Konrad Rzeszutek Wilk]

The host has 240 CPUs and the HVM guests config looks as follow:

-bash-4.1# cat /hvm.cfg 
memory=64000
name="big64"
vcpus = 64
disk= ['file:/isos/root_image.iso,hdc:cdrom,r']
builder="hvm"
serial='pty'
usb=1
vnclisten="0.0.0.0:64"

-bash-4.1# xl list | grep big64 
big64   13 64000 1 --p---   0.0

-bash-4.1# xl dmesg | grep d13
-bash-4.1# 
-bash-4.1# head /var/log/xen/qemu-dm-big64.log 
char device redirected to /dev/pts/10 (label serial0)
qemu: hardware error: Fatal error while trying to get io event!

CPU #0:
EAX= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300

(Attaching the full file).

If I lower the vCPUS down to 63 it boots fine.

This is todays built:
-bash-4.1# xl info
host   : sca05-0a81fa5b
release: 4.5.0-rc1upstream-11035-ge28f2c0
version: #1 SMP Tue May 3 09:33:28 EDT 2016
machine: x86_64
nr_cpus: 240
max_cpu_id : 239
nr_nodes   : 8
cores_per_socket   : 15
threads_per_core   : 2
cpu_mhz: 2793
hw_caps: 
b7ebfbff:77bee3ff:2c100800:0001:0001:0281::0100
virt_caps  : hvm hvm_directio
total_memory   : 6291334
free_memory: 5731766
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0
xen_major  : 4
xen_minor  : 8
xen_extra  : Hello Again Wor
xen_version: 4.7Hello Again Wor
xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 
hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler  : credit
xen_pagesize   : 4096
platform_params: virt_start=0x8000
xen_changeset  : Tue May 3 12:43:35 2016 +0100 git:b90ecd5-dirty
xen_commandline: com1=9600,8n1 dom0_mem=max:8G dom0_max_vcpus=8 
console=com1,vga loglvl=all cpufreq=verbose apic=debug
cc_compiler: gcc (GCC) 4.4.4 20100503 (Red Hat 4.4.4-2)
cc_compile_by  : konrad
cc_compile_domain  : us.oracle.com
cc_compile_date: Tue May  3 09:33:42 EDT 2016
build_id   : 082940fe9dc847e60892fad4c5bb1c3722022c08
xend_config_format : 4


[konrad@vm-konrad-f22 xen]$ git log --oneline HEAD^..
b90ecd5 Final touches for Xen 4.7.0-rc1
[konrad@vm-konrad-f22 xen]$ git diff --stat
 tools/libxl/libxlu_disk_l.c | 992 
+---
 tools/libxl/libxlu_disk_l.h |  34 +---
 2 files changed, 559 insertions(+), 467 deletions(-)

The SeaBIOS is (d14 is for the 63VCPU guest):
(d14) SeaBIOS (version rel-1.9.1-0-gb3ef39f)

char device redirected to /dev/pts/10 (label serial0)
qemu: hardware error: Fatal error while trying to get io event!

CPU #0:
EAX= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= DR3= 
DR6=0ff0 DR7=0400
EFER=
FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80
FPR0=  FPR1= 
FPR2=  FPR3= 
FPR4=  FPR5= 
FPR6=  FPR7= 
XMM00= XMM01=
XMM02= XMM03=
XMM04= XMM05=
XMM06= XMM07=
CPU #1:
EAX= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=fff0 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=1
ES =   9300
CS =f000   9b00
SS =   9300
DS =   9300
FS =   9300
GS =   9300
LDT=   8200
TR =   8b00
GDT=  
IDT=  
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2= DR3= 
DR6=0ff0 DR7=0400
EFER=
FCW=037f FSW= 

Re: [Xen-devel] [PATCH 1/2] x86/p2m: clean up altp2m

[George Dunlap]

On Tue, May 3, 2016 at 5:44 PM, George Dunlap
 wrote:
> On Fri, Apr 29, 2016 at 3:49 PM, Jan Beulich  wrote:
>> Signed-off-by: Jan Beulich 
>
> Acked-by: George Dunlap 

And I guess this is a candidate for backport to 4.6 too?

 -George

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

Re: [Xen-devel] QEMU-TRAD Re: [PATCH] Fixed building with newer GNUTLS versions.

[Wei Liu]

The original patch seems to malformed.

I skim the code, the refactoring parts look correct to me. What I'm not
sure is whether the replacement is correct or not.

The reference to gnutls_priority_set_direct in [0] is from a section
called "Upgrading to 3.4.x from 3.3.x", while the version check in the
proposed patch checks for 2.2.0.

Do I miss anything here? What version does Fedora have?

Thanks
Wei.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 91479
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
91479
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 91479

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-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  6620cd1efcb6f69a5151830b9cd564bf7e153fa6
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z   18 days
Failing since 91597  2016-04-16 04:20:46 Z   17 days   17 attempts
Testing same since93388  2016-05-03 04:22:43 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ben Gray 
  Boris Fiuczynski 
  Cole Robinson 
  Cédric Bosdonnat 
  Daniel Veillard 
  Dmitry Andreev 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shivaprasad G Bhat 
  Shivaprasad G Bhat 
  Simon Arlott 
  Yuri Chornoivan 

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   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 

Re: [Xen-devel] [PATCHv1 for-4.7] x86: show correct code in CPU state

[Wei Liu]

On Tue, May 03, 2016 at 05:19:26PM +0100, Andrew Cooper wrote:
> On 03/05/16 17:15, David Vrabel wrote:
> > When showing the CPU state (e.g., after a crash) the dump of code
> > around RIP is incorrect.
> >
> > Incorrect:
> >
> > Xen code around  (...):
> >  00 c6 c1 ee 08 48 c1 e0 <04> 03 04 f1 8b ...
> >  ^^ Uninitialized ^^ Missing 0x48
> >
> > Correct:
> >
> > Xen code around  (...):
> >  c6 c1 ee 08 48 c1 e0 04 <48> 03 04 f1 8b ...
> >
> > When coping the bytes before RIP, the destination was off-by-one.
> >
> > Signed-off-by: David Vrabel 
> 
> Reviewed-by: Andrew Cooper 
> 
> CC'ing Wei for release ack.

Release-acked-by: Wei Liu 

> 
> > ---
> >  xen/arch/x86/traps.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> > index 8384158..0895441 100644
> > --- a/xen/arch/x86/traps.c
> > +++ b/xen/arch/x86/traps.c
> > @@ -150,7 +150,7 @@ static void show_code(const struct cpu_user_regs *regs)
> >: "=" (missing_before),
> >  "=" (tmp), "=" (tmp)
> >: "0" (ARRAY_SIZE(insns_before)),
> > -"1" (insns_before + ARRAY_SIZE(insns_before)),
> > +"1" (insns_before + ARRAY_SIZE(insns_before) - 1),
> >  "2" (regs->rip - 1));
> >  clac();
> >  
> 

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

Re: [Xen-devel] [PATCHv1 for-4.7] x86: show correct code in CPU state

[Andrew Cooper]

On 03/05/16 17:15, David Vrabel wrote:
> When showing the CPU state (e.g., after a crash) the dump of code
> around RIP is incorrect.
>
> Incorrect:
>
> Xen code around  (...):
>  00 c6 c1 ee 08 48 c1 e0 <04> 03 04 f1 8b ...
>  ^^ Uninitialized ^^ Missing 0x48
>
> Correct:
>
> Xen code around  (...):
>  c6 c1 ee 08 48 c1 e0 04 <48> 03 04 f1 8b ...
>
> When coping the bytes before RIP, the destination was off-by-one.
>
> Signed-off-by: David Vrabel 

Reviewed-by: Andrew Cooper 

CC'ing Wei for release ack.

> ---
>  xen/arch/x86/traps.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 8384158..0895441 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -150,7 +150,7 @@ static void show_code(const struct cpu_user_regs *regs)
>: "=" (missing_before),
>  "=" (tmp), "=" (tmp)
>: "0" (ARRAY_SIZE(insns_before)),
> -"1" (insns_before + ARRAY_SIZE(insns_before)),
> +"1" (insns_before + ARRAY_SIZE(insns_before) - 1),
>  "2" (regs->rip - 1));
>  clac();
>  


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

Re: [Xen-devel] QEMU-TRAD Re: [PATCH] Fixed building with newer GNUTLS versions.

[Konrad Rzeszutek Wilk]

On Fri, Apr 01, 2016 at 12:45:26PM -0400, Konrad Rzeszutek Wilk wrote:

Hey Wei, Ian,

We really need this for Xen 4.7 - otherwise you cannot build qemu-trad under
Fedora Core 23:

home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c: In 
function ‘usbnet_receive’:
/home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c:1379:29:
 warning: comparison of constant ‘2’ with boolean expression is always false 
[-Wbool-compare]
 if (!s->rndis_state == RNDIS_DATA_INITIALIZED)
 ^
/home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c:1379:29:
 warning: logical not is only applied to the left hand side of comparison 
[-Wlogical-not-parentheses]
/home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c: In 
function ‘usbnet_can_receive’:
/home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c:1412:37:
 warning: comparison of constant ‘2’ with boolean expression is always false 
[-Wbool-compare]
 if (s->rndis && !s->rndis_state == RNDIS_DATA_INITIALIZED)
 ^
/home/konrad/ssd/konrad/xen/tools/qemu-xen-traditional-dir/hw/usb-net.c:1412:37:
 warning: logical not is only applied to the left hand side of comparison 
[-Wlogical-not-parentheses]
audio/sdlaudio.c: In function ‘sdl_init_out’:
audio/sdlaudio.c:337:11: warning: ‘shift’ is used uninitialized in this 
function [-Wuninitialized]
 shift <<= as->nchannels == 2;
   ^
vnc.c:1929:1: warning: ‘gnutls_anon_server_credentials’ is deprecated 
[-Wdeprecated-declarations]
 {
 ^
vnc.c: In function ‘vnc_tls_initialize_anon_cred’:
vnc.c:1930:5: warning: ‘gnutls_anon_server_credentials’ is deprecated 
[-Wdeprecated-declarations]
 gnutls_anon_server_credentials anon_cred;
 ^
vnc.c: In function ‘vnc_start_tls’:
vnc.c:2180:6: warning: implicit declaration of function 
‘gnutls_kx_set_priority’ [-Wimplicit-function-declaration]
  if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : 
kx_anon) < 0) {
  ^
vnc.c:2187:6: warning: implicit declaration of function 
‘gnutls_certificate_type_set_priority’ [-Wimplicit-function-declaration]
  if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) 
< 0) {



Thanks.

> On Fri, Apr 01, 2016 at 06:31:00PM +0200, Sjoer van der Ploeg wrote:
> > Dear Konrad,
> > 
> > 
> > The patch was tested on my testbed, after discovering that the build
> > failed. I had no need for qemu-traditional and forgot to disable it, but I
> > hate build errors  ;)
> > 
> > I do not think there should be any issues with the certs, as the used
> > functions were deprecated as explained here:
> > 
> > https://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html
> 
> Thank you for the explanation.
> 
> Re-adding xen-devel and Ian as that information is most helkpul in the commit
> description!
> 
> Thank you.
> > 
> > 
> > Yours,
> > 
> > Sjoer van der Ploeg
> > 
> > On Fri, Apr 1, 2016 at 3:51 PM, Konrad Rzeszutek Wilk <
> > konrad.w...@oracle.com> wrote:
> > 
> > > On Thu, Mar 31, 2016 at 10:58:19PM +0200, Sjoer van der Ploeg wrote:
> > >
> > > Heya!
> > >
> > > Thank you for posting this and also adding the #ifdef for older
> > > versions!
> > >
> > > Was wondering thought - had you double-checked that the new
> > > code path works with the certs?
> > >
> > > Thanks!
> > >
> > > P.S.
> > > CC-ing Ian who is the QEMU-traditional maintainer.
> > > > Signed-off-by: Sjoer van der Ploeg 
> > > > ---
> > > >  vnc.c | 71
> > > +--
> > > >  1 file changed, 48 insertions(+), 23 deletions(-)
> > > >
> > > > diff --git a/vnc.c b/vnc.c
> > > > index 573af3b..61d1555 100644
> > > > --- a/vnc.c
> > > > +++ b/vnc.c
> > > > @@ -1925,9 +1925,9 @@ static int vnc_tls_initialize(void)
> > > >  return 1;
> > > >  }
> > > >
> > > > -static gnutls_anon_server_credentials 
> > > > vnc_tls_initialize_anon_cred(void)
> > > > +static gnutls_anon_server_credentials_t
> > > vnc_tls_initialize_anon_cred(void)
> > > >  {
> > > > -gnutls_anon_server_credentials anon_cred;
> > > > +gnutls_anon_server_credentials_t anon_cred;
> > > >  int ret;
> > > >
> > > >  if ((ret = gnutls_anon_allocate_server_credentials(_cred)) <
> > > 0) {
> > > > @@ -2151,13 +2151,52 @@ static void vnc_handshake_io(void *opaque) {
> > > >   (vs)->subauth == VNC_AUTH_VENCRYPT_X509VNC ||\
> > > >   (vs)->subauth == VNC_AUTH_VENCRYPT_X509PLAIN)
> > > >
> > > > +#if defined(GNUTLS_VERSION_NUMBER) && \
> > > > +GNUTLS_VERSION_NUMBER >= 0x020200 /* 2.2.0 */
> > > > +static int vnc_set_gnutls_priority(gnutls_session_t s, int x509)
> > > > +{
> > > > +const char *priority = x509 ? "NORMAL" : "NORMAL:+ANON-DH";
> > > > +int rc;
> > > >
> > > > -static int vnc_start_tls(struct VncState *vs) {
> > > > -static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> > > > 

[Xen-devel] [PATCHv1 for-4.7] x86: show correct code in CPU state

[David Vrabel]

When showing the CPU state (e.g., after a crash) the dump of code
around RIP is incorrect.

Incorrect:

Xen code around  (...):
 00 c6 c1 ee 08 48 c1 e0 <04> 03 04 f1 8b ...
 ^^ Uninitialized ^^ Missing 0x48

Correct:

Xen code around  (...):
 c6 c1 ee 08 48 c1 e0 04 <48> 03 04 f1 8b ...

When coping the bytes before RIP, the destination was off-by-one.

Signed-off-by: David Vrabel 
---
 xen/arch/x86/traps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 8384158..0895441 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -150,7 +150,7 @@ static void show_code(const struct cpu_user_regs *regs)
   : "=" (missing_before),
 "=" (tmp), "=" (tmp)
   : "0" (ARRAY_SIZE(insns_before)),
-"1" (insns_before + ARRAY_SIZE(insns_before)),
+"1" (insns_before + ARRAY_SIZE(insns_before) - 1),
 "2" (regs->rip - 1));
 clac();
 
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7] configure: Fix when no libsystemd compat lib are available

[Anthony PERARD]

From systemd change log, since version 209, libsystemd.so contain
everything, including libsystemd-daemon.so. Distro may, or may not provide
the compatibility libraries which libsystemd-daemon is part of.

So, if libsystemd-daemon is not available, check for the presence of
a recent enough libsystemd.

Signed-off-by: Anthony PERARD 
---
Please, rerun ./autogen.sh on this patch.
---
 m4/systemd.m4 | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/m4/systemd.m4 b/m4/systemd.m4
index e4b1aa5..112dc11 100644
--- a/m4/systemd.m4
+++ b/m4/systemd.m4
@@ -41,7 +41,9 @@ AC_DEFUN([AX_ALLOW_SYSTEMD_OPTS], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_LIBS], [
-   PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon])
+   PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon],,
+   [PKG_CHECK_MODULES([SYSTEMD], [libsystemd >= 209])]
+)
dnl pkg-config older than 0.24 does not set these for
dnl PKG_CHECK_MODULES() worth also noting is that as of version 208
dnl of systemd pkg-config --cflags currently yields no extra flags yet.
@@ -94,8 +96,10 @@ AC_DEFUN([AX_CHECK_SYSTEMD], [
 ])
 
 AC_DEFUN([AX_CHECK_SYSTEMD_ENABLE_AVAILABLE], [
-   PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],
-  [systemd="n"])
+   PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [systemd="y"],[
+   PKG_CHECK_MODULES([SYSTEMD], [libsystemd >= 209],
+ [systemd="y"],[systemd="n"])
+   ])
 ])
 
 dnl Enables systemd by default and requires a --disable-systemd option flag
-- 
Anthony PERARD


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

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

[osstest service owner]

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

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  b90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483
baseline version:
 xen  356b5512b0dc9ce81a8007983a110de9798206dc

Last test of basis93366  2016-05-02 14:02:33 Z1 days
Testing same since93402  2016-05-03 12:01:36 Z0 days2 attempts


People who touched revisions under test:
  Ian Jackson 

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=b90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483
+ . ./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 
b90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483
+ branch=xen-unstable-smoke
+ revision=b90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483
+ . ./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.6-testing
+ '[' xb90ecd5f2ba3a1d28e69b724cc4e90afcb6ce483 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:48,  wrote:
> On 5/3/16 9:43 AM, Jan Beulich wrote:
> On 03.05.16 at 16:29,  wrote:
>>> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
>>> was previously togglable on the command line so this adds a message for
>>> users enabling it from the command line to tell them to enable it from
>>> make menuconfig.
>>>
>>> Signed-off-by: Doug Goldstein 
>>> ---
>>> CC: Jan Beulich 
>>> CC: Andrew Cooper 
>> 
>> I think the Cc list should be quite a bit wider here.
> 
> $ ./scripts/get_maintainer.pl
> patches/v2-0002-build-convert-crash_debug-to-Kconfig.patch
> Jan Beulich 
> Andrew Cooper 
> xen-devel@lists.xen.org 
> 
> Do you want me to CC THE REST?

With files belonging to REST being touched - yes. (And yes, we all
know the script isn't perfect.)

Jan


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

Re: [Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 17:10,  wrote:
> On 03/05/16 16:05, Jan Beulich wrote:
> On 03.05.16 at 16:29,  wrote:
>>> --- /dev/null
>>> +++ b/xen/Kconfig.debug
>>> @@ -0,0 +1,7 @@
>>> +
>>> +menuconfig DEBUG
>>> +   bool "Debugging Options"
>> One more thing: In the unstable branch this should really default to
>> y, and the release check list should be adjusted to say that this
>> default needs to be dropped (or inverted) while preparing a release.
>>
>> And obviously the "debug=" also needs to go away from ./Config.mk.
> 
> Things other than Xen make use of debug= in the root Config.mk. 
> Valgrind client requests for example in libxc.
> 
> That option can't be moved without providing an alternative.

Why can't it be moved into tools/ if that's where it is still of interest?

Jan


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

[Xen-devel] rdmsr general protection error

[Big Strong]

I want to test if my processor support VMFUNC which is described as:
>
>
> The IA32_VMX_VMFUNC MSR exists only on processors that support the
> 1-setting of the “activate secondary controls” VM-execution control (only if*
> bit 63 of the IA32_VMX_PROCBASED_CTLS MSR is 1*) and the 1-setting of the
> “enable VM functions” secondary processor-based VM-execution control (only
> if* bit 45 of the IA32_VMX_PROCBASED_CTLS2 MSR is 1*).


So in order to do that, I need to use rdmsr as follows:

//IA32_VMX_PROCBASED_CTLS
>  __asm__ __volatile__("rdmsr" : "=a" (eax), "=d" (edx) : "c" (0x482));

//IA32_VMX_PROCBASED_CTLS 2

 __asm__ __volatile__("rdmsr" : "=a" (eax), "=d" (edx) : "c" (0x48B));


But both the rdmsr instruction would cause a #GP, even when I run it from
the native linux as a root user and without xen running.

So is there a way to use the rdmsr in dom0?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH v2 1/2] xen: introduce dummy system device

[Anthony PERARD]

On Thu, Mar 10, 2016 at 04:19:29PM +0100, Juergen Gross wrote:
> Introduce a new dummy system device serving as parent for virtual
> buses. This will enable new pv backends to introduce virtual buses
> which are removable again opposed to system buses which are meant
> to stay once added.
> 
> Signed-off-by: Juergen Gross 

Looks good.

Acked-by: Anthony PERARD 

> ---
> V2: NOT changed, even if requested by Stefano Stabellini: the xen dummy
> system device is needed by virtfs for Xen PV(H) guests, too
> 
> Signed-off-by: Juergen Gross 
> ---
>  hw/xenpv/xen_machine_pv.c| 40 
>  include/hw/xen/xen_backend.h |  1 +
>  2 files changed, 41 insertions(+)
> 
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index fc13535..48d5bc6 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -25,10 +25,15 @@
>  #include "qemu/osdep.h"
>  #include "hw/hw.h"
>  #include "hw/boards.h"
> +#include "hw/sysbus.h"
>  #include "hw/xen/xen_backend.h"
>  #include "xen_domainbuild.h"
>  #include "sysemu/block-backend.h"
>  
> +#define TYPE_XENSYSDEV "xensysdev"
> +
> +DeviceState *xen_sysdev;
> +
>  static void xen_init_pv(MachineState *machine)
>  {
>  DriveInfo *dinfo;
> @@ -67,6 +72,9 @@ static void xen_init_pv(MachineState *machine)
>  break;
>  }
>  
> +xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
> +qdev_init_nofail(xen_sysdev);
> +
>  xen_be_register("console", _console_ops);
>  xen_be_register("vkbd", _kbdmouse_ops);
>  xen_be_register("vfb", _framebuffer_ops);
> @@ -101,6 +109,38 @@ static void xen_init_pv(MachineState *machine)
>  xen_init_display(xen_domid);
>  }
>  
> +static int xen_sysdev_init(SysBusDevice *dev)
> +{
> +return 0;
> +}
> +
> +static Property xen_sysdev_properties[] = {
> +{/* end of property list */},
> +};
> +
> +static void xen_sysdev_class_init(ObjectClass *klass, void *data)
> +{
> +DeviceClass *dc = DEVICE_CLASS(klass);
> +SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
> +
> +k->init = xen_sysdev_init;
> +dc->props = xen_sysdev_properties;
> +}
> +
> +static const TypeInfo xensysdev_info = {
> +.name  = TYPE_XENSYSDEV,
> +.parent= TYPE_SYS_BUS_DEVICE,
> +.instance_size = sizeof(SysBusDevice),
> +.class_init= xen_sysdev_class_init,
> +};
> +
> +static void xenpv_register_types(void)
> +{
> +type_register_static(_info);
> +}
> +
> +type_init(xenpv_register_types);
> +
>  static void xenpv_machine_init(MachineClass *mc)
>  {
>  mc->desc = "Xen Para-virtualized PC";
> diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
> index c839eeb..b4b4ff0 100644
> --- a/include/hw/xen/xen_backend.h
> +++ b/include/hw/xen/xen_backend.h
> @@ -60,6 +60,7 @@ extern xc_interface *xen_xc;
>  extern xenforeignmemory_handle *xen_fmem;
>  extern struct xs_handle *xenstore;
>  extern const char *xen_protocol;
> +extern DeviceState *xen_sysdev;
>  
>  /* xenstore helper functions */
>  int xenstore_write_str(const char *base, const char *node, const char *val);
> -- 
> 2.6.2
> 
> 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Andrew Cooper]

On 03/05/16 16:05, Jan Beulich wrote:
 On 03.05.16 at 16:29,  wrote:
>> --- /dev/null
>> +++ b/xen/Kconfig.debug
>> @@ -0,0 +1,7 @@
>> +
>> +menuconfig DEBUG
>> +bool "Debugging Options"
> One more thing: In the unstable branch this should really default to
> y, and the release check list should be adjusted to say that this
> default needs to be dropped (or inverted) while preparing a release.
>
> And obviously the "debug=" also needs to go away from ./Config.mk.

Things other than Xen make use of debug= in the root Config.mk. 
Valgrind client requests for example in libxc.

That option can't be moved without providing an alternative.

~Andrew

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

Re: [Xen-devel] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:47,  wrote:
> On 03/05/16 15:29, Doug Goldstein wrote:
>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>> index e5179f4..04f672f 100644
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -5,3 +5,14 @@ menuconfig DEBUG
>>If you want to debug Xen say Y and select any additional debugging
>>support options. Enabling this option is intended for development
>>purposes only, and not for production use.
>> +
>> +if DEBUG
>> +
>> +config CRASH_DEBUG
>> +bool "Crash Debugging Support"
>> +depends on X86
> 
> default n

See my reply to a later patch: Ideally we'd go without this (the default
is n anyway). The only thing I'm not sure is whether omitting the
defaults in such cases leads to questions getting asked during some
intended silent "make *config".

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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  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-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 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-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-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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
 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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  356b5512b0dc9ce81a8007983a110de9798206dc
baseline version:
 xen  c2994f8632d56e5379e612daa216401477dccbdb

Last test of basis93337  2016-05-02 01:57:38 Z1 days
Failing since 93364  2016-05-02 13:47:09 Z1 days2 attempts
Testing same since93381  2016-05-03 00:44:58 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Tim Deegan 
  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
 

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> On 03.05.16 at 16:41,  wrote:
> On 05/03/2016 05:30 PM, Jan Beulich wrote:
> On 03.05.16 at 16:20,  wrote:
>>> I've kept experimenting with the patch but can't quite figure out why
>>> minimizing the lock scope to the writeback part would not be sufficient,
>>> but it isn't.
>>>
>>> I.e. with this code:
>>>
>>> 3824  writeback:
>>> 3825 ops->smp_lock(lock_prefix);
>>> 3826 switch ( dst.type )
>>> 3827 {
>>> 3828 case OP_REG:
>>> 3829 /* The 4-byte case *is* correct: in 64-bit mode we 
>>> zero-extend. */
>>> 3830 switch ( dst.bytes )
>>> 3831 {
>>> 3832 case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
>>> 3833 case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
>>> 3834 case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext 
>>> */
>>> 3835 case 8: *dst.reg = dst.val; break;
>>> 3836 }
>>> 3837 break;
>>> 3838 case OP_MEM:
>>> 3839 if ( !(d & Mov) && (dst.orig_val == dst.val) &&
>>> 3840  !ctxt->force_writeback )
>>> 3841 /* nothing to do */;
>>> 3842 else if ( lock_prefix )
>>> 3843 rc = ops->cmpxchg(
>>> 3844 dst.mem.seg, dst.mem.off, _val,
>>> 3845 , dst.bytes, ctxt);
>>> 3846 else
>>> 3847 rc = ops->write(
>>> 3848 dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
>>> 3849 if ( rc != 0 )
>>> 3850 {
>>> 3851 ops->smp_unlock(lock_prefix);
>>> 3852 goto done;
>>> 3853 }
>>> 3854 default:
>>> 3855 break;
>>> 3856 }
>>> 3857 ops->smp_unlock(lock_prefix);
>>>
>>> I can still reproduce the guest hang. But if I lock at the very
>>> beginning of x86_emulate() and unlock before each return, no more hangs.
>> 
>> Isn't that obvious? Locked instructions are necessarily
>> read-modify-write ones, and hence the lock needs to be taken
>> before the read, and dropped after the write. But remember, I'll
>> continue to show opposition to this getting "fixed" this way (in the
>> emulator itself), as long as no proper explanation can be given
>> why making hvmemul_cmpxchg() do what its name says isn't all
>> we need (and hence why i386-like bus lock behavior is needed).
> 
> Yes, that's what I thought, but at a previous time I've described my
> attempt to lock _only_ hvmemul_cmpxchg() (which failed) - and the
> failure of that change to address the issue has been considered curious.
> I've probably not been able to explain clearly what I've tried, or have
> misunderstood the answer, and took it to mean that for some reason a
> similar change is supposed to be able to fix it.
> 
> Obviously locking hvmemul_cmpxchg() would have only affected the OP_MEM
> case above (with lock_prefix == 1), actually an even smaller scope than
> the new one, and with no read locking either.

Yeah, I may have got confused there too (resulting in me confusing
you, perhaps): Adding a spin lock to hvmemul_cmpxchg() of course
won't help. Making it use (or force us of) LOCK CMPXCHG would, I
suppose.

> I guess the question now is what avenues are there to make
> hvmemul_cmpxchg() do what its name says - I'm certainly open to trying
> out any alternatives - my main concern is to have the problem fixed in
> the best way possible, certainly not to have any specific version of
> this patch make it into Xen.

I guess making it no longer call hvmemul_write(), copying most of
that function's code while suitably replacing just the call to
hvm_copy_to_guest_virt() (with the assumption that the MMIO
paths at least for now don't need strict LOCK handling) is the only
viable route.

Jan


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

Re: [Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC1

[Wei Liu]

On Tue, May 03, 2016 at 05:09:14PM +0200, Olaf Hering wrote:
> On Tue, May 03, Wei Liu wrote:
> 
> > Xen 4.7 RC1 is tagged. You can check that out from xen.git:
> 
> This is a release, and the release checklist should have been applied to
> staging. Various things refer still to 4.6, like SONAMEs and pkgconfig
> output.
> 

Yes, we are aware of that. The plan is to update hose prior to the
actual release. Thanks for the heads-up anyway.

Wei.

> Olaf

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

Re: [Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC1

[Olaf Hering]

On Tue, May 03, Wei Liu wrote:

> Xen 4.7 RC1 is tagged. You can check that out from xen.git:

This is a release, and the release checklist should have been applied to
staging. Various things refer still to 4.6, like SONAMEs and pkgconfig
output.

Olaf

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

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/2] xen: add pvUSB backend

[Anthony PERARD]

On Thu, Mar 10, 2016 at 04:19:30PM +0100, Juergen Gross wrote:
> Add a backend for para-virtualized USB devices for xen domains.
> 
> The backend is using host-libusb to forward USB requests from a
> domain via libusb to the real device(s) passed through.
> 
> Signed-off-by: Juergen Gross 
> ---

[...]

> diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
> new file mode 100644
> index 000..b12077f
> --- /dev/null
> +++ b/hw/usb/xen-usb.c
> @@ -0,0 +1,1021 @@
> +/*
> + *  xen paravirt usb device backend
> + *
> + *  (c) Juergen Gross 
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; under version 2 of the License.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License along
> + *  with this program; if not, see .
> + *
> + *  Contributions after 2012-01-13 are licensed under the terms of the
> + *  GNU GPL, version 2 or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "qemu/osdep.h"
> +#include "qemu-common.h"
> +#include "qemu/config-file.h"
> +#include "hw/sysbus.h"
> +#include "hw/usb.h"
> +#include "hw/xen/xen_backend.h"
> +#include "monitor/qdev.h"
> +#include "qapi/qmp/qbool.h"
> +#include "qapi/qmp/qint.h"
> +#include "qapi/qmp/qstring.h"
> +#include "sys/user.h"
> +
> +#include 
> +#include 
> +
> +#define TR(xendev, lvl, fmt, args...)   \
> +{   \
> +struct timeval tv;  \
> +\
> +gettimeofday(, NULL);\
> +xen_be_printf(xendev, lvl, "%8ld.%06ld xen-usb(%s):" fmt,   \
> +  tv.tv_sec, tv.tv_usec, __func__, ##args); \
> +}
> +#define TR_BUS(xendev, fmt, args...) TR(xendev, 2, fmt, ##args)
> +#define TR_REQ(xendev, fmt, args...) TR(xendev, 3, fmt, ##args)
> +
> +#define USBBACK_MAXPORTSUSBIF_PIPE_PORT_MASK
> +#define USB_DEV_ADDR_SIZE   (USBIF_PIPE_DEV_MASK + 1)
> +
> +/* USB wire protocol: structure describing control request parameter. */
> +struct usbif_ctrlrequest {
> +uint8_tbRequestType;
> +uint8_tbRequest;
> +uint16_t   wValue;
> +uint16_t   wIndex;
> +uint16_t   wLength;
> +};
> +
> +struct usbback_info;
> +struct usbback_req;
> +
> +struct usbback_stub {
> +USBDevice *dev;
> +USBPort   port;
> +unsigned int  speed;
> +bool  attached;
> +QTAILQ_HEAD(submit_q_head, usbback_req) submit_q;
> +};
> +
> +struct usbback_req {
> +struct usbback_info  *usbif;
> +struct usbback_stub  *stub;
> +struct usbif_urb_request req;
> +USBPacketpacket;
> +
> +unsigned int nr_buffer_segs; /* # of transfer_buffer 
> segments */
> +unsigned int nr_extra_segs;  /* # of iso_frame_desc segments 
>  */
> +
> +QTAILQ_ENTRY(usbback_req) q;
> +
> +void *buffer;
> +void *isoc_buffer;
> +struct libusb_transfer   *xfer;
> +};
> +
> +struct usbback_info {
> +struct XenDevice xendev;  /* must be first */
> +USBBus   bus;
> +void *urb_sring;
> +void *conn_sring;
> +struct usbif_urb_back_ring urb_ring;
> +struct usbif_conn_back_ring conn_ring;
> +int  num_ports;
> +int  usb_ver;
> +bool ring_error;
> +QTAILQ_HEAD(req_free_q_head, usbback_req) req_free_q;
> +struct usbback_stub  ports[USBBACK_MAXPORTS];
> +struct usbback_stub  *addr_table[USB_DEV_ADDR_SIZE];
> +QEMUBH   *bh;
> +};
> +
> +static struct usbback_req *usbback_get_req(struct usbback_info *usbif)
> +{
> +struct usbback_req *usbback_req;
> +
> +if (QTAILQ_EMPTY(>req_free_q)) {
> +usbback_req = g_malloc0(sizeof(*usbback_req));

You could use g_new0(struct usbback_req, 1) here.

> +} else {
> +usbback_req = QTAILQ_FIRST(>req_free_q);
> +QTAILQ_REMOVE(>req_free_q, usbback_req, q);
> +}
> +return usbback_req;
> +}
> +
> +static void usbback_put_req(struct usbback_req *usbback_req)
> +{
> +struct usbback_info *usbif;
> +
> +usbif = usbback_req->usbif;
> +memset(usbback_req, 0, sizeof(*usbback_req));
> +QTAILQ_INSERT_HEAD(>req_free_q, usbback_req, q);
> +}
> +
> 

Re: [Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> --- /dev/null
> +++ b/xen/Kconfig.debug
> @@ -0,0 +1,7 @@
> +
> +menuconfig DEBUG
> + bool "Debugging Options"

One more thing: In the unstable branch this should really default to
y, and the release check list should be adjusted to say that this
default needs to be dropped (or inverted) while preparing a release.

And obviously the "debug=" also needs to go away from ./Config.mk.

Jan


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

Re: [Xen-devel] [PATCH v2 7/7] build: convert lock_profile to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> Convert the 'lock_profile' option to Kconfig as CONFIG_LOCK_PROFILE.
> 
> Signed-off-by: Doug Goldstein 

Subject to transformations paralleling such requested on earlier
patches:
Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 6/7] build: convert perfc{, _arrays} to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Jan Beulich 
> CC: Andrew Cooper 

Again too narrow a Cc list.

> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -28,6 +28,21 @@ config FRAME_POINTER
> maybe slower, but it gives very useful debugging information
> in case of any Xen bugs.
>  
> +config PERF_ARRAYS
> + bool "Performance Counter Array Histograms"
> + default n
> + depends on PERF_COUNTERS
> + ---help---
> +   Enables software performance counter array histograms.
> +
> +config PERF_COUNTERS
> + bool "Performance Counters"
> + default n
> + ---help---
> +   Enables software performance counters that allows you to analyze
> +   bottlenecks in the system. To access this data you must use the
> +   'xenperf' tool.

I guess you put them in this order because that's how they sort.
But for any of the menu config interfaces this will result in the
former not properly becoming a sub-item of the latter. IOW
dependent should always (directly) follow their master options.

Also - is "default n" really useful here? In one of the earlier
patches you had omitted it, and that's what I'd prefer unless
doing so has some bad side effect.

>  ifneq ($(origin kexec),undefined)
>  $(error "You must use 'make menuconfig' to enable/disable kexec now.")
>  endif

Considering this context - no similar addition here?

> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -151,7 +151,7 @@ void __dummy__(void)
>  OFFSET(TRAPBOUNCE_eip, struct trap_bounce, eip);
>  BLANK();
>  
> -#if PERF_COUNTERS
> +#if CONFIG_PERF_COUNTERS

#ifdef

> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -64,7 +64,7 @@ obj-$(CONFIG_XSPLICE) += xsplice_elf.o
>  
>  obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo 
> unlz4 earlycpio,$(n).init.o)
>  
> -obj-$(perfc)   += perfc.o
> +obj-$(CONFIG_PERF_COUNTERS)   += perfc.o

Please move this up at once, too, like you did in one of the earlier
patches.

Jan


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

Re: [Xen-devel] [PATCH v2 5/7] build: wire up pre-existing debug build flag

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> This allows 'make debug=n' and 'make debug=y' work as it did previously
> but only in the case of the user not having an existing .config file
> from a 'make menuconfig'. This is because the command line 'debug' flag
> can only be used to set the default value and if the user has already
> built up a config with their real preference set.

Do we really need this?

Jan


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

Re: [Xen-devel] [PATCH v2 4/7] build: convert frame_pointer to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,6 +15,14 @@ config CRASH_DEBUG
> If you want to be able to attach gdb to Xen to be able to debug
> Xen if it crashes then say Y.
>  
> +config FRAME_POINTER
> + bool "Compile Xen with frame pointers"
> + default y

Same as for patch 3, including the R-b.

Jan


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

Re: [Xen-devel] [PATCH v2 3/7] build: convert verbose to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,4 +15,11 @@ config CRASH_DEBUG
> If you want to be able to attach gdb to Xen to be able to debug
> Xen if it crashes then say Y.
>  
> +config VERBOSE_DEBUG
> + bool "Verbose debug messages"
> + default y

With the enclosing "if" adjusted, this would need to become
"default DEBUG", and I think that's a good idea anyway (i.e. even
if that other change was rejected by someone else, this would still
make the code prepared to _some_ future adjustment to that "if").

> @@ -17,10 +16,7 @@ include $(XEN_ROOT)/Config.mk
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.
>  ifeq ($(debug),y)
> -verbose   := y
>  frame_pointer := y
> -else
> -CFLAGS += -DNDEBUG

Ah, here's the change that belongs into patch 1.

Again, with those adjustments
Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Doug Goldstein]

On 5/3/16 9:43 AM, Jan Beulich wrote:
 On 03.05.16 at 16:29,  wrote:
>> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
>> was previously togglable on the command line so this adds a message for
>> users enabling it from the command line to tell them to enable it from
>> make menuconfig.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Jan Beulich 
>> CC: Andrew Cooper 
> 
> I think the Cc list should be quite a bit wider here.

$ ./scripts/get_maintainer.pl
patches/v2-0002-build-convert-crash_debug-to-Kconfig.patch
Jan Beulich 
Andrew Cooper 
xen-devel@lists.xen.org

Do you want me to CC THE REST?

-- 
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] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Andrew Cooper]

On 03/05/16 15:29, Doug Goldstein wrote:
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index e5179f4..04f672f 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -5,3 +5,14 @@ menuconfig DEBUG
> If you want to debug Xen say Y and select any additional debugging
> support options. Enabling this option is intended for development
> purposes only, and not for production use.
> +
> +if DEBUG
> +
> +config CRASH_DEBUG
> + bool "Crash Debugging Support"
> + depends on X86

default n

Even with debugging enabled before, this wasn't available by default
(see the hunk below).

~Andrew

> + ---help---
> +   If you want to be able to attach gdb to Xen to be able to debug
> +   Xen if it crashes then say Y.
> +
> +endif # DEBUG
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index 961d533..c044fd1 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -7,7 +7,6 @@ verbose   ?= n
>  perfc ?= n
>  perfc_arrays  ?= n
>  lock_profile  ?= n
> -crash_debug   ?= n
>  frame_pointer ?= n
>  lto   ?= n


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

Re: [Xen-devel] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
> was previously togglable on the command line so this adds a message for
> users enabling it from the command line to tell them to enable it from
> make menuconfig.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Jan Beulich 
> CC: Andrew Cooper 

I think the Cc list should be quite a bit wider here.

> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -5,3 +5,14 @@ menuconfig DEBUG
> If you want to debug Xen say Y and select any additional debugging
> support options. Enabling this option is intended for development
> purposes only, and not for production use.
> +
> +if DEBUG

Didn't we agree on "DEBUG || EXPERT" at the hackathon? With tha
Reviewed-by: Jan Beulich 

But one more suggestion:

> --- a/xen/include/asm-x86/debugger.h
> +++ b/xen/include/asm-x86/debugger.h
> @@ -39,7 +39,7 @@
>  #define DEBUGGER_trap_fatal(_v, _r) \
>  if ( debugger_trap_fatal(_v, _r) ) return;
>  
> -#if defined(CRASH_DEBUG)
> +#if defined(CONFIG_CRASH_DEBUG)

#ifdef

Jan


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru]

On 05/03/2016 05:30 PM, Jan Beulich wrote:
 On 03.05.16 at 16:20,  wrote:
>> I've kept experimenting with the patch but can't quite figure out why
>> minimizing the lock scope to the writeback part would not be sufficient,
>> but it isn't.
>>
>> I.e. with this code:
>>
>> 3824  writeback:
>> 3825 ops->smp_lock(lock_prefix);
>> 3826 switch ( dst.type )
>> 3827 {
>> 3828 case OP_REG:
>> 3829 /* The 4-byte case *is* correct: in 64-bit mode we zero-extend. 
>> */
>> 3830 switch ( dst.bytes )
>> 3831 {
>> 3832 case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
>> 3833 case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
>> 3834 case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext */
>> 3835 case 8: *dst.reg = dst.val; break;
>> 3836 }
>> 3837 break;
>> 3838 case OP_MEM:
>> 3839 if ( !(d & Mov) && (dst.orig_val == dst.val) &&
>> 3840  !ctxt->force_writeback )
>> 3841 /* nothing to do */;
>> 3842 else if ( lock_prefix )
>> 3843 rc = ops->cmpxchg(
>> 3844 dst.mem.seg, dst.mem.off, _val,
>> 3845 , dst.bytes, ctxt);
>> 3846 else
>> 3847 rc = ops->write(
>> 3848 dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
>> 3849 if ( rc != 0 )
>> 3850 {
>> 3851 ops->smp_unlock(lock_prefix);
>> 3852 goto done;
>> 3853 }
>> 3854 default:
>> 3855 break;
>> 3856 }
>> 3857 ops->smp_unlock(lock_prefix);
>>
>> I can still reproduce the guest hang. But if I lock at the very
>> beginning of x86_emulate() and unlock before each return, no more hangs.
> 
> Isn't that obvious? Locked instructions are necessarily
> read-modify-write ones, and hence the lock needs to be taken
> before the read, and dropped after the write. But remember, I'll
> continue to show opposition to this getting "fixed" this way (in the
> emulator itself), as long as no proper explanation can be given
> why making hvmemul_cmpxchg() do what its name says isn't all
> we need (and hence why i386-like bus lock behavior is needed).

Yes, that's what I thought, but at a previous time I've described my
attempt to lock _only_ hvmemul_cmpxchg() (which failed) - and the
failure of that change to address the issue has been considered curious.
I've probably not been able to explain clearly what I've tried, or have
misunderstood the answer, and took it to mean that for some reason a
similar change is supposed to be able to fix it.

Obviously locking hvmemul_cmpxchg() would have only affected the OP_MEM
case above (with lock_prefix == 1), actually an even smaller scope than
the new one, and with no read locking either.

I guess the question now is what avenues are there to make
hvmemul_cmpxchg() do what its name says - I'm certainly open to trying
out any alternatives - my main concern is to have the problem fixed in
the best way possible, certainly not to have any specific version of
this patch make it into Xen.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Doug Goldstein]

On 5/3/16 9:38 AM, Jan Beulich wrote:
 On 03.05.16 at 16:29,  wrote:
>> --- a/xen/include/xen/config.h
>> +++ b/xen/include/xen/config.h
>> @@ -81,4 +81,8 @@
>>  /* allow existing code to work with Kconfig variable */
>>  #define NR_CPUS CONFIG_NR_CPUS
>>  
>> +#ifndef CONFIG_DEBUG
>> +#define NDEBUG
>> +#endif
> 
> At the same time you should delete the -DNDEBUG from xen/Rules.mk.
> There shouldn't be two places controlling the same thing.
> 
> Jan
> 

You're right. That hunk slipped to 3/7 during a rebase. I'll repost with
that moved to 1/7.

-- 
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] [PATCH v2 1/7] build: add debug menu to Kconfig

[Jan Beulich]

>>> On 03.05.16 at 16:29,  wrote:
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -81,4 +81,8 @@
>  /* allow existing code to work with Kconfig variable */
>  #define NR_CPUS CONFIG_NR_CPUS
>  
> +#ifndef CONFIG_DEBUG
> +#define NDEBUG
> +#endif

At the same time you should delete the -DNDEBUG from xen/Rules.mk.
There shouldn't be two places controlling the same thing.

Jan


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

[Xen-devel] [PATCH v2 2/7] build: convert crash_debug to Kconfig

[Doug Goldstein]

Convert the crash_debug option to Kconfig as CONFIG_CRASH_DEBUG. This
was previously togglable on the command line so this adds a message for
users enabling it from the command line to tell them to enable it from
make menuconfig.

Signed-off-by: Doug Goldstein 
---
CC: Jan Beulich 
CC: Andrew Cooper 
---
 INSTALL|  1 -
 docs/misc/crashdb.txt  |  4 ++--
 xen/Kconfig.debug  | 11 +++
 xen/Rules.mk   |  5 +++--
 xen/arch/x86/Makefile  |  3 +--
 xen/arch/x86/x86_64/Makefile   |  2 +-
 xen/common/Makefile|  2 +-
 xen/include/asm-x86/debugger.h |  2 +-
 xen/include/xen/gdbstub.h  |  2 +-
 9 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/INSTALL b/INSTALL
index 95fa94d..2974b9b 100644
--- a/INSTALL
+++ b/INSTALL
@@ -231,7 +231,6 @@ verbose=y
 perfc=y
 perfc_arrays=y
 lock_profile=y
-crash_debug=y
 frame_pointer=y
 lto=y
 
diff --git a/docs/misc/crashdb.txt b/docs/misc/crashdb.txt
index b41a538..9733666 100644
--- a/docs/misc/crashdb.txt
+++ b/docs/misc/crashdb.txt
@@ -5,7 +5,7 @@ Xen has a simple gdb stub for doing post-mortem debugging i.e. 
once
 you've crashed it, you get to poke around and find out why.  There's
 also a special key handler for making it crash, which is handy.
 
-You need to have crash_debug=y set when compiling , and you also need
+You need to have CRASH_DEBUG=y set when compiling, and you also need
 to enable it on the Xen command line, eg by gdb=com1.
 
 If you need to have a serial port shared between gdb and the console,
@@ -19,7 +19,7 @@ if you have a simple null modem connection between the test 
box and
 the workstation, and aren't using a H/L split console:
 
   * Set debug=y in Config.mk
-  * Set crash_debug=y in xen/Rules.mk
+  * Set CRASH_DEBUG=y with `make -C xen menuconfig`
   * Make the changes in the attached patch, and build.
   * Arrange to pass gdb=com1 as a hypervisor command line argument
 (I already have com1=38400,8n1 console=com1,vga sync_console)
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index e5179f4..04f672f 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -5,3 +5,14 @@ menuconfig DEBUG
  If you want to debug Xen say Y and select any additional debugging
  support options. Enabling this option is intended for development
  purposes only, and not for production use.
+
+if DEBUG
+
+config CRASH_DEBUG
+   bool "Crash Debugging Support"
+   depends on X86
+   ---help---
+ If you want to be able to attach gdb to Xen to be able to debug
+ Xen if it crashes then say Y.
+
+endif # DEBUG
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 961d533..c044fd1 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -7,7 +7,6 @@ verbose   ?= n
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
-crash_debug   ?= n
 frame_pointer ?= n
 lto   ?= n
 
@@ -30,6 +29,9 @@ endif
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
+ifneq ($(origin crash_debug),undefined)
+$(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
+endif
 
 # Set ARCH/SUBARCH appropriately.
 override TARGET_SUBARCH  := $(XEN_TARGET_ARCH)
@@ -58,7 +60,6 @@ CFLAGS += -Wa,--strip-local-absolute
 endif
 
 CFLAGS-$(verbose)   += -DVERBOSE
-CFLAGS-$(crash_debug)   += -DCRASH_DEBUG
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 4665a68..4ccef4a 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -27,6 +27,7 @@ obj-y += domain_page.o
 obj-y += e820.o
 obj-y += extable.o
 obj-y += flushtlb.o
+obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
 obj-y += i387.o
 obj-y += i8259.o
 obj-y += io_apic.o
@@ -66,8 +67,6 @@ obj-y += vm_event.o
 obj-$(CONFIG_XSPLICE) += alternative.o xsplice.o
 obj-y += xstate.o
 
-obj-$(crash_debug) += gdbstub.o
-
 x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
 
 efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
diff --git a/xen/arch/x86/x86_64/Makefile b/xen/arch/x86/x86_64/Makefile
index 5b54c16..d8815e7 100644
--- a/xen/arch/x86/x86_64/Makefile
+++ b/xen/arch/x86/x86_64/Makefile
@@ -14,4 +14,4 @@ obj-y += cpu_idle.o
 obj-y += cpufreq.o
 obj-bin-$(CONFIG_KEXEC) += kexec_reloc.o
 
-obj-$(crash_debug)   += gdbstub.o
+obj-$(CONFIG_CRASH_DEBUG)   += gdbstub.o
diff --git a/xen/common/Makefile b/xen/common/Makefile
index afd84b6..a98bcc2 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -8,6 +8,7 @@ obj-y += domain.o
 obj-y += event_2l.o
 obj-y += event_channel.o
 obj-y += event_fifo.o
+obj-$(CONFIG_CRASH_DEBUG) += gdbstub.o
 obj-y += grant_table.o
 obj-y += guestcopy.o
 obj-bin-y += gunzip.init.o
@@ -64,7 +65,6 @@ obj-$(CONFIG_XSPLICE) += xsplice_elf.o
 

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Jan Beulich]

>>> On 03.05.16 at 16:20,  wrote:
> I've kept experimenting with the patch but can't quite figure out why
> minimizing the lock scope to the writeback part would not be sufficient,
> but it isn't.
> 
> I.e. with this code:
> 
> 3824  writeback:
> 3825 ops->smp_lock(lock_prefix);
> 3826 switch ( dst.type )
> 3827 {
> 3828 case OP_REG:
> 3829 /* The 4-byte case *is* correct: in 64-bit mode we zero-extend. 
> */
> 3830 switch ( dst.bytes )
> 3831 {
> 3832 case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
> 3833 case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
> 3834 case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b: zero-ext */
> 3835 case 8: *dst.reg = dst.val; break;
> 3836 }
> 3837 break;
> 3838 case OP_MEM:
> 3839 if ( !(d & Mov) && (dst.orig_val == dst.val) &&
> 3840  !ctxt->force_writeback )
> 3841 /* nothing to do */;
> 3842 else if ( lock_prefix )
> 3843 rc = ops->cmpxchg(
> 3844 dst.mem.seg, dst.mem.off, _val,
> 3845 , dst.bytes, ctxt);
> 3846 else
> 3847 rc = ops->write(
> 3848 dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
> 3849 if ( rc != 0 )
> 3850 {
> 3851 ops->smp_unlock(lock_prefix);
> 3852 goto done;
> 3853 }
> 3854 default:
> 3855 break;
> 3856 }
> 3857 ops->smp_unlock(lock_prefix);
> 
> I can still reproduce the guest hang. But if I lock at the very
> beginning of x86_emulate() and unlock before each return, no more hangs.

Isn't that obvious? Locked instructions are necessarily
read-modify-write ones, and hence the lock needs to be taken
before the read, and dropped after the write. But remember, I'll
continue to show opposition to this getting "fixed" this way (in the
emulator itself), as long as no proper explanation can be given
why making hvmemul_cmpxchg() do what its name says isn't all
we need (and hence why i386-like bus lock behavior is needed).

Jan


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

[Xen-devel] [PATCH v2 1/7] build: add debug menu to Kconfig

[Doug Goldstein]

There are a number of debugging options for Xen so the idea is to have a
menu to group them all together. Enabling this menu item will also
disable NDEBUG which will result in more debug prints. This was
previously wired into the 'debug=y' command line option.

Signed-off-by: Doug Goldstein 
---
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/Kconfig  | 2 ++
 xen/Kconfig.debug| 7 +++
 xen/include/xen/config.h | 4 
 3 files changed, 13 insertions(+)
 create mode 100644 xen/Kconfig.debug

diff --git a/xen/Kconfig b/xen/Kconfig
index fa8b27c..0fe7a1a 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -26,3 +26,5 @@ config DEFCONFIG_LIST
 config EXPERT
string
option env="XEN_CONFIG_EXPERT"
+
+source "Kconfig.debug"
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
new file mode 100644
index 000..e5179f4
--- /dev/null
+++ b/xen/Kconfig.debug
@@ -0,0 +1,7 @@
+
+menuconfig DEBUG
+   bool "Debugging Options"
+   ---help---
+ If you want to debug Xen say Y and select any additional debugging
+ support options. Enabling this option is intended for development
+ purposes only, and not for production use.
diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
index ef6e5ee..473c5e8 100644
--- a/xen/include/xen/config.h
+++ b/xen/include/xen/config.h
@@ -81,4 +81,8 @@
 /* allow existing code to work with Kconfig variable */
 #define NR_CPUS CONFIG_NR_CPUS
 
+#ifndef CONFIG_DEBUG
+#define NDEBUG
+#endif
+
 #endif /* __XEN_CONFIG_H__ */
-- 
2.7.3


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

[Xen-devel] [PATCH v2 4/7] build: convert frame_pointer to Kconfig

[Doug Goldstein]

Converts the frame_pointer option to a Kconfig option.

Signed-off-by: Doug Goldstein 
---
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 
---
 INSTALL   | 1 -
 xen/Kconfig.debug | 8 
 xen/Rules.mk  | 6 +-
 3 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/INSTALL b/INSTALL
index 35668bd..f55d42c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -230,7 +230,6 @@ hypervisor build.
 perfc=y
 perfc_arrays=y
 lock_profile=y
-frame_pointer=y
 lto=y
 
 During tools build external repos will be cloned into the source tree.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 89e26fe..c75cf1d 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -15,6 +15,14 @@ config CRASH_DEBUG
  If you want to be able to attach gdb to Xen to be able to debug
  Xen if it crashes then say Y.
 
+config FRAME_POINTER
+   bool "Compile Xen with frame pointers"
+   default y
+   ---help---
+ If you say Y here the resulting Xen will be slightly larger and
+ maybe slower, but it gives very useful debugging information
+ in case of any Xen bugs.
+
 config VERBOSE_DEBUG
bool "Verbose debug messages"
default y
diff --git a/xen/Rules.mk b/xen/Rules.mk
index b159451..84b9d81 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -6,7 +6,6 @@
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
-frame_pointer ?= n
 lto   ?= n
 
 -include $(BASEDIR)/include/config/auto.conf
@@ -15,9 +14,6 @@ include $(XEN_ROOT)/Config.mk
 
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
-ifeq ($(debug),y)
-frame_pointer := y
-endif
 ifeq ($(perfc_arrays),y)
 perfc := y
 endif
@@ -58,7 +54,7 @@ endif
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
-CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
+CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
 ifneq ($(max_phys_irqs),)
 CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
-- 
2.7.3


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

[Xen-devel] [PATCH v2 5/7] build: wire up pre-existing debug build flag

[Doug Goldstein]

This allows 'make debug=n' and 'make debug=y' work as it did previously
but only in the case of the user not having an existing .config file
from a 'make menuconfig'. This is because the command line 'debug' flag
can only be used to set the default value and if the user has already
built up a config with their real preference set.

Signed-off-by: Doug Goldstein 
---
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/Kconfig.debug | 5 +
 xen/Makefile  | 1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index c75cf1d..9aefa16 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -1,6 +1,11 @@
+config DEBUG_ENV
+   bool
+   option env="debug"
 
 menuconfig DEBUG
bool "Debugging Options"
+   default y if DEBUG_ENV = "y"
+   default n
---help---
  If you want to debug Xen say Y and select any additional debugging
  support options. Enabling this option is intended for development
diff --git a/xen/Makefile b/xen/Makefile
index 0d5f240..31cca71 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -27,6 +27,7 @@ SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
s'/arm\(32\|64\)/arm/g')
 # Don't break if the build process wasn't called from the top level
 # we need XEN_TARGET_ARCH to generate the proper config
 include $(XEN_ROOT)/Config.mk
+export debug
 
 # Allow someone to change their config file
 export KCONFIG_CONFIG ?= .config
-- 
2.7.3


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

[Xen-devel] [PATCH v2 7/7] build: convert lock_profile to Kconfig

[Doug Goldstein]

Convert the 'lock_profile' option to Kconfig as CONFIG_LOCK_PROFILE.

Signed-off-by: Doug Goldstein 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 
---
 INSTALL|  1 -
 xen/Kconfig.debug  |  8 
 xen/Rules.mk   |  2 --
 xen/arch/arm/xen.lds.S |  2 +-
 xen/arch/x86/domain.c  |  2 +-
 xen/arch/x86/xen.lds.S |  2 +-
 xen/common/keyhandler.c|  2 +-
 xen/common/spinlock.c  | 10 +-
 xen/common/sysctl.c|  2 +-
 xen/include/xen/spinlock.h |  4 ++--
 10 files changed, 20 insertions(+), 15 deletions(-)

diff --git a/INSTALL b/INSTALL
index 623887d..616a67a 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-lock_profile=y
 lto=y
 
 During tools build external repos will be cloned into the source tree.
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 3ea717e..a03aca9 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,6 +28,14 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
+config LOCK_PROFILE
+   bool "Lock Profiiling"
+   default n
+   ---help---
+ Lock profiling allows you to see how often locks are taken and 
blocked.
+ You can use serial console to print (and reset) using 'l' and 'L'
+ respectively, or the 'xenlockprof' tool.
+
 config PERF_ARRAYS
bool "Performance Counter Array Histograms"
default n
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 7e2cb5f..3015c5b 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,7 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-lock_profile  ?= n
 lto   ?= n
 
 -include $(BASEDIR)/include/config/auto.conf
@@ -43,7 +42,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
 ifneq ($(max_phys_irqs),)
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 1f010bd..76982b2 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -54,7 +54,7 @@ SECTIONS
*(.rodata)
*(.rodata.*)
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
*(.lockprofile.data)
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 5af2cc5..978ec3a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -251,7 +251,7 @@ struct domain *alloc_domain_struct(void)
 #endif
 
 
-#ifndef LOCK_PROFILE
+#ifndef CONFIG_LOCK_PROFILE
 BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
 #endif
 d = alloc_xenheap_pages(order, MEMF_bits(bits));
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index b14bcd2..a43b29d 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -103,7 +103,7 @@ SECTIONS
*(.ex_table.pre)
__stop___pre_ex_table = .;
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
. = ALIGN(POINTER_ALIGN);
__lock_profile_start = .;
*(.lockprofile.data)
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 65b70ce..16de6e8 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -64,7 +64,7 @@ static struct keyhandler {
 KEYHANDLER('P', perfc_reset, "reset performance counters", 0),
 #endif
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 KEYHANDLER('l', spinlock_profile_printall, "print lock profile info", 1),
 KEYHANDLER('L', spinlock_profile_reset, "reset lock profile info", 0),
 #endif
diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index b377bb9..017bdf3 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -85,7 +85,7 @@ void spin_debug_disable(void)
 
 #endif
 
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 
 #define LOCK_PROFILE_REL \
 if (lock->profile)   \
@@ -212,7 +212,7 @@ int _spin_trylock(spinlock_t *lock)
 if ( cmpxchg(>tickets.head_tail,
  old.head_tail, new.head_tail) != old.head_tail )
 return 0;
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 if (lock->profile)
 lock->profile->time_locked = NOW();
 #endif
@@ -227,7 +227,7 @@ int _spin_trylock(spinlock_t *lock)
 void _spin_barrier(spinlock_t *lock)
 {
 spinlock_tickets_t sample;
-#ifdef LOCK_PROFILE
+#ifdef CONFIG_LOCK_PROFILE
 s_time_t block = NOW();
 #endif
 
@@ -238,7 +238,7 @@ void _spin_barrier(spinlock_t *lock)
 {
 while ( observe_head(>tickets) == sample.head )
 arch_lock_relax();
-#ifdef LOCK_PROFILE
+#ifdef 

[Xen-devel] [PATCH v2 6/7] build: convert perfc{, _arrays} to Kconfig

[Doug Goldstein]

Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.

Signed-off-by: Doug Goldstein 
---
CC: Jan Beulich 
CC: Andrew Cooper 
---
 INSTALL   |  2 --
 xen/Kconfig.debug | 15 +++
 xen/Rules.mk  | 10 --
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/time.c   |  4 ++--
 xen/arch/x86/x86_64/asm-offsets.c |  2 +-
 xen/common/Makefile   |  2 +-
 xen/common/keyhandler.c   |  2 +-
 xen/common/perfc.c|  2 +-
 xen/common/sysctl.c   |  2 +-
 xen/include/asm-x86/asm_defns.h   |  2 +-
 xen/include/asm-x86/domain.h  |  2 +-
 xen/include/xen/perfc.h   |  8 
 xen/include/xen/sched.h   |  2 +-
 14 files changed, 30 insertions(+), 27 deletions(-)

diff --git a/INSTALL b/INSTALL
index f55d42c..623887d 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,8 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-perfc=y
-perfc_arrays=y
 lock_profile=y
 lto=y
 
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 9aefa16..3ea717e 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -28,6 +28,21 @@ config FRAME_POINTER
  maybe slower, but it gives very useful debugging information
  in case of any Xen bugs.
 
+config PERF_ARRAYS
+   bool "Performance Counter Array Histograms"
+   default n
+   depends on PERF_COUNTERS
+   ---help---
+ Enables software performance counter array histograms.
+
+config PERF_COUNTERS
+   bool "Performance Counters"
+   default n
+   ---help---
+ Enables software performance counters that allows you to analyze
+ bottlenecks in the system. To access this data you must use the
+ 'xenperf' tool.
+
 config VERBOSE_DEBUG
bool "Verbose debug messages"
default y
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 84b9d81..7e2cb5f 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,8 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-perfc ?= n
-perfc_arrays  ?= n
 lock_profile  ?= n
 lto   ?= n
 
@@ -12,12 +10,6 @@ lto   ?= n
 
 include $(XEN_ROOT)/Config.mk
 
-# Hardcoded configuration implications and dependencies.
-# Do this is a neater way if it becomes unwieldy.
-ifeq ($(perfc_arrays),y)
-perfc := y
-endif
-
 ifneq ($(origin kexec),undefined)
 $(error "You must use 'make menuconfig' to enable/disable kexec now.")
 endif
@@ -51,8 +43,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(perfc) += -DPERF_COUNTERS
-CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
 CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 82e2ed1..8519dc9 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3526,7 +3526,7 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 static uint64_t _hvm_rdtsc_intercept(void)
 {
 struct vcpu *curr = current;
-#if !defined(NDEBUG) || defined(PERF_COUNTERS)
+#if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 struct domain *currd = curr->domain;
 
 if ( currd->arch.vtsc )
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 6438b47..3928a5f 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1688,7 +1688,7 @@ void pv_soft_rdtsc(struct vcpu *v, struct cpu_user_regs 
*regs, int rdtscp)
 
 spin_lock(>arch.vtsc_lock);
 
-#if !defined(NDEBUG) || defined(PERF_COUNTERS)
+#if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 if ( guest_kernel_mode(v, regs) )
 d->arch.vtsc_kerncount++;
 else
@@ -1959,7 +1959,7 @@ static void dump_softtsc(unsigned char key)
 printk(",khz=%"PRIu32, d->arch.tsc_khz);
 if ( d->arch.incarnation )
 printk(",inc=%"PRIu32, d->arch.incarnation);
-#if !defined(NDEBUG) || defined(PERF_COUNTERS)
+#if !defined(NDEBUG) || defined(CONFIG_PERF_COUNTERS)
 if ( !(d->arch.vtsc_kerncount | d->arch.vtsc_usercount) )
 printk("\n");
 else
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index fa37ee0..891ddc8 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -151,7 +151,7 @@ void __dummy__(void)
 OFFSET(TRAPBOUNCE_eip, struct trap_bounce, eip);
 BLANK();
 
-#if PERF_COUNTERS
+#if CONFIG_PERF_COUNTERS
 DEFINE(ASM_PERFC_hypercalls, PERFC_hypercalls);
 DEFINE(ASM_PERFC_exceptions, PERFC_exceptions);
 BLANK();
diff --git a/xen/common/Makefile b/xen/common/Makefile
index a98bcc2..5891b1c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ 

[Xen-devel] [PATCH v2 3/7] build: convert verbose to Kconfig

[Doug Goldstein]

Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
enabled.

Signed-off-by: Doug Goldstein 
---
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Daniel De Graaf 
---
 INSTALL | 1 -
 xen/Kconfig.debug   | 7 +++
 xen/Rules.mk| 5 -
 xen/arch/arm/kernel.c   | 2 +-
 xen/arch/x86/domain_build.c | 2 +-
 xen/include/xsm/dummy.h | 2 +-
 6 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/INSTALL b/INSTALL
index 2974b9b..35668bd 100644
--- a/INSTALL
+++ b/INSTALL
@@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
 
 The following variables can be used to tweak some aspects of the
 hypervisor build.
-verbose=y
 perfc=y
 perfc_arrays=y
 lock_profile=y
diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 04f672f..89e26fe 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -15,4 +15,11 @@ config CRASH_DEBUG
  If you want to be able to attach gdb to Xen to be able to debug
  Xen if it crashes then say Y.
 
+config VERBOSE_DEBUG
+   bool "Verbose debug messages"
+   default y
+   ---help---
+ Guest output from HYPERVISOR_console_io and hypervisor parsing
+ ELF images (dom0) is logged in the Xen ring buffer.
+
 endif # DEBUG
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c044fd1..b159451 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -3,7 +3,6 @@
 # If you change any of these configuration options then you must
 # 'make clean' before rebuilding.
 #
-verbose   ?= n
 perfc ?= n
 perfc_arrays  ?= n
 lock_profile  ?= n
@@ -17,10 +16,7 @@ include $(XEN_ROOT)/Config.mk
 # Hardcoded configuration implications and dependencies.
 # Do this is a neater way if it becomes unwieldy.
 ifeq ($(debug),y)
-verbose   := y
 frame_pointer := y
-else
-CFLAGS += -DNDEBUG
 endif
 ifeq ($(perfc_arrays),y)
 perfc := y
@@ -59,7 +55,6 @@ ifneq ($(clang),y)
 CFLAGS += -Wa,--strip-local-absolute
 endif
 
-CFLAGS-$(verbose)   += -DVERBOSE
 CFLAGS-$(perfc) += -DPERF_COUNTERS
 CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
 CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
index 9871bd9..3f6cce3 100644
--- a/xen/arch/arm/kernel.c
+++ b/xen/arch/arm/kernel.c
@@ -472,7 +472,7 @@ static int kernel_elf_probe(struct kernel_info *info,
 
 if ( (rc = elf_init(>elf.elf, info->elf.kernel_img, size )) != 0 )
 goto err;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose(>elf.elf);
 #endif
 elf_parse_binary(>elf.elf);
diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
index f9a3eca..b29c377 100644
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -942,7 +942,7 @@ int __init construct_dom0(
 
 if ( (rc = elf_init(, image_start, image_len)) != 0 )
 return rc;
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 elf_set_verbose();
 #endif
 elf_parse_binary();
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index abbe282..406cd18 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -215,7 +215,7 @@ static XSM_INLINE int 
xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
 static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int cmd)
 {
 XSM_ASSERT_ACTION(XSM_OTHER);
-#ifdef VERBOSE
+#ifdef CONFIG_VERBOSE_DEBUG
 if ( cmd == CONSOLEIO_write )
 return xsm_default_action(XSM_HOOK, d, NULL);
 #endif
-- 
2.7.3


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

[Xen-devel] [PATCH v2 0/7] Kconfig debug options

[Doug Goldstein]

This converts the debug options from xen/Rules.mk to Kconfig. I'm unsure
if I properly described PERF_ARRAYS but otherwise the other descriptions
have either been provided by maintainers or improved by maintainers so
I am confident about those.

The big departure from Rules.mk is how NDEBUG is turned on (or isn't).
Basically if you enable the debug menu at all it will not turn on NDEBUG.
Previously this was only done when you supplied 'debug=n'. The inverse,
'debug=y' did 'verbose=y' and 'frame_pointer=y' so they were linked but
differently.

Doug Goldstein (7):
  build: add debug menu to Kconfig
  build: convert crash_debug to Kconfig
  build: convert verbose to Kconfig
  build: convert frame_pointer to Kconfig
  build: wire up pre-existing debug build flag
  build: convert perfc{,_arrays} to Kconfig
  build: convert lock_profile to Kconfig

 INSTALL   |  6 
 docs/misc/crashdb.txt |  4 +--
 xen/Kconfig   |  2 ++
 xen/Kconfig.debug | 61 +++
 xen/Makefile  |  1 +
 xen/Rules.mk  | 28 +++---
 xen/arch/arm/kernel.c |  2 +-
 xen/arch/arm/xen.lds.S|  2 +-
 xen/arch/x86/Makefile |  3 +-
 xen/arch/x86/domain.c |  2 +-
 xen/arch/x86/domain_build.c   |  2 +-
 xen/arch/x86/hvm/hvm.c|  2 +-
 xen/arch/x86/time.c   |  4 +--
 xen/arch/x86/x86_64/Makefile  |  2 +-
 xen/arch/x86/x86_64/asm-offsets.c |  2 +-
 xen/arch/x86/xen.lds.S|  2 +-
 xen/common/Makefile   |  4 +--
 xen/common/keyhandler.c   |  4 +--
 xen/common/perfc.c|  2 +-
 xen/common/spinlock.c | 10 +++
 xen/common/sysctl.c   |  4 +--
 xen/include/asm-x86/asm_defns.h   |  2 +-
 xen/include/asm-x86/debugger.h|  2 +-
 xen/include/asm-x86/domain.h  |  2 +-
 xen/include/xen/config.h  |  4 +++
 xen/include/xen/gdbstub.h |  2 +-
 xen/include/xen/perfc.h   |  8 ++---
 xen/include/xen/sched.h   |  2 +-
 xen/include/xen/spinlock.h|  4 +--
 xen/include/xsm/dummy.h   |  2 +-
 30 files changed, 109 insertions(+), 68 deletions(-)
 create mode 100644 xen/Kconfig.debug

-- 
2.7.3


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

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Jan Beulich]

>>> On 03.05.16 at 16:10,  wrote:
> On 03/05/16 14:58, Jan Beulich wrote:
> On 17.03.16 at 09:03,  wrote:
>>> Since such guests' kernel code runs in ring 1, their memory accesses,
>>> at the paging layer, are supervisor mode ones, and hence subject to
>>> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
>>> two features though (and so far we also don't expose the respective
>>> feature flags), and hence may suffer page faults they cannot deal with.
>>>
>>> While the placement of the re-enabling slightly weakens the intended
>>> protection, it was selected such that 64-bit paths would remain
>>> unaffected where possible. At the expense of a further performance hit
>>> the re-enabling could be put right next to the CLACs.
>>>
>>> Note that this introduces a number of extra TLB flushes - CR4.SMEP
>>> transitioning from 0 to 1 always causes a flush, and it transitioning
>>> from 1 to 0 may also do.
>>>
>>> Signed-off-by: Jan Beulich 
>> So I think we need to take some decision here, and I'm afraid
>> Andrew and I won't be able to settle this between us. He's
>> validly concerned about the performance impact this got proven
>> to have (for 32-bit PV guests), yet I continue to think that correct
>> behavior is more relevant than performance. Hence I think we
>> should bite the bullet and take the change. For those who value
>> performance more than security, they can always disable the use
>> of SMEP and SMAP via command line option.
>>
>> Of course I'm also concerned that Intel, who did introduce the
>> functional regression in the first place, so far didn't participate at
>> all in finding an acceptable solution to the problem at hand...
> 
> What I am even more concerned with is that the supposedly-optimised
> version which tried to omit cr4 writes whenever possible caused a higher
> performance overhead than the version which rewrite cr4 all the time.
> 
> As is stands, v3 of the series is even worse for performance than v2. 
> That alone means that v3 is not in a suitable state to be accepted, as
> there is some hidden bug in it.

For one, we could take v2 (albeit that would feel odd).

And then, from v3 showing worse performance (which only you
have seen the numbers for, and [hopefully] know what deviations
in them really mean) it does not follow that v3 is buggy. That's one
possibility, sure (albeit hard to explain, as functionally everything
is working fine for both you and me, afaik), but not the only one.
Another may be that hardware processes CR4 writes faster when
they happen in close succession to CR4 reads. And I'm sure more
could be come up with.

And finally, I'm not tied to this patch set. I'd be fine with some
other fix to restore correct behavior. What I'm not fine with is the
limbo state this is being left in, with me all the time having to revive
the discussion.

Jan


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

Re: [Xen-devel] [for-4.7] x86/emulate: synchronize LOCKed instruction emulation

[Razvan Cojocaru]

On 04/27/2016 10:14 AM, Razvan Cojocaru wrote:
> On 04/27/2016 09:22 AM, Jan Beulich wrote:
> On 26.04.16 at 19:23,  wrote:
>>> On 04/26/16 19:03, George Dunlap wrote:
 On 19/04/16 17:35, Jan Beulich wrote:
 Razvan Cojocaru  04/19/16 1:01 PM >>>
>> I think this might be because the LOCK prefix should guarantee that the
>> instruction that follows it has exclusive use of shared memory (for both
>> reads and writes) but I might be misreading the docs:
>
> LOCK definitely has no effect on other than the instruction it gets 
> applied
> to.

 Sorry I wasn't involved in this discussion -- what was the conclusion here?

 FWIW Andy's suggestion of using a stub seemed like the most robust
 solution, if that could be made to work.

 If you're going to submit a patch substantially similar to this one, let
 me know so I can review the mm bits of the original patch.
>>>
>>> I'm not really sure.
>>>
>>> Regarding this version of the patch, Jan has asked for more information
>>> on the performance impact, but I'm not sure how to obtain it in a
>>> rigorous manner.
>>
>> That was only one half, which Andrew has now answered. The
>> other was the not understood issue with a later variant you had
>> tried.
> 
> Right, there's the fact that this version (with read / write locking the
> whole function) works whereas just synchonizing hvmemul_cmpxchg() with a
> spin lock does not. It is not yet fully clear why (the part of the
> conversation at the very top of this email was an early attempt to
> elucidate it).

I've kept experimenting with the patch but can't quite figure out why
minimizing the lock scope to the writeback part would not be sufficient,
but it isn't.

I.e. with this code:

3824  writeback:
3825 ops->smp_lock(lock_prefix);
3826 switch ( dst.type )
3827 {
3828 case OP_REG:
3829 /* The 4-byte case *is* correct: in 64-bit mode we
zero-extend. */
3830 switch ( dst.bytes )
3831 {
3832 case 1: *(uint8_t  *)dst.reg = (uint8_t)dst.val; break;
3833 case 2: *(uint16_t *)dst.reg = (uint16_t)dst.val; break;
3834 case 4: *dst.reg = (uint32_t)dst.val; break; /* 64b:
zero-ext */
3835 case 8: *dst.reg = dst.val; break;
3836 }
3837 break;
3838 case OP_MEM:
3839 if ( !(d & Mov) && (dst.orig_val == dst.val) &&
3840  !ctxt->force_writeback )
3841 /* nothing to do */;
3842 else if ( lock_prefix )
3843 rc = ops->cmpxchg(
3844 dst.mem.seg, dst.mem.off, _val,
3845 , dst.bytes, ctxt);
3846 else
3847 rc = ops->write(
3848 dst.mem.seg, dst.mem.off, , dst.bytes, ctxt);
3849 if ( rc != 0 )
3850 {
3851 ops->smp_unlock(lock_prefix);
3852 goto done;
3853 }
3854 default:
3855 break;
3856 }
3857 ops->smp_unlock(lock_prefix);

I can still reproduce the guest hang. But if I lock at the very
beginning of x86_emulate() and unlock before each return, no more hangs.

I would appreciate any suggestions on how to go about trying to narrow
the scope of the lock, or figure out what subtlety is at work here.


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH v2 for-4.7 5/6] xen/xsplice: add ELFOSABI_FREEBSD as a supported OSABI for payloads

[Jan Beulich]

>>> On 03.05.16 at 12:55,  wrote:
> The calling convention used by the FreeBSD ELF OSABI is exactly the same as
> the the one defined by System V, so payloads with a FreeBSD OSABI should be
> accepted by the xsplice machinery.

Well, you realize that the ABI is more than just the calling convention?
I.e. your patch basically says ELFOSABI_NONE == ELFOSABI_FREEBSD,
in which case I wonder why the latter exists in the first place. Is there
a proper document somewhere describing everything the latter implies,
so that one can check whether for xSplice purposes such similar
treatment is indeed okay? Until then I'm afraid I'm opposed to this going
in.

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.7 4/6] xen/xsplice: check against ELFOSABI_NONE instead of ELFOSABI_SYSV

[Jan Beulich]

>>> On 03.05.16 at 12:55,  wrote:
> They are equivalent, but using ELFOSABI_NONE is more correct in this
> context.
> 
> Signed-off-by: Roger Pau Monné 

Pick one of
{Acked,Suggested}-by: Jan Beulich 

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

Re: [Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Andrew Cooper]

On 03/05/16 14:58, Jan Beulich wrote:
 On 17.03.16 at 09:03,  wrote:
>> Since such guests' kernel code runs in ring 1, their memory accesses,
>> at the paging layer, are supervisor mode ones, and hence subject to
>> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
>> two features though (and so far we also don't expose the respective
>> feature flags), and hence may suffer page faults they cannot deal with.
>>
>> While the placement of the re-enabling slightly weakens the intended
>> protection, it was selected such that 64-bit paths would remain
>> unaffected where possible. At the expense of a further performance hit
>> the re-enabling could be put right next to the CLACs.
>>
>> Note that this introduces a number of extra TLB flushes - CR4.SMEP
>> transitioning from 0 to 1 always causes a flush, and it transitioning
>> from 1 to 0 may also do.
>>
>> Signed-off-by: Jan Beulich 
> So I think we need to take some decision here, and I'm afraid
> Andrew and I won't be able to settle this between us. He's
> validly concerned about the performance impact this got proven
> to have (for 32-bit PV guests), yet I continue to think that correct
> behavior is more relevant than performance. Hence I think we
> should bite the bullet and take the change. For those who value
> performance more than security, they can always disable the use
> of SMEP and SMAP via command line option.
>
> Of course I'm also concerned that Intel, who did introduce the
> functional regression in the first place, so far didn't participate at
> all in finding an acceptable solution to the problem at hand...

What I am even more concerned with is that the supposedly-optimised
version which tried to omit cr4 writes whenever possible caused a higher
performance overhead than the version which rewrite cr4 all the time.

As is stands, v3 of the series is even worse for performance than v2. 
That alone means that v3 is not in a suitable state to be accepted, as
there is some hidden bug in it.

~Andrew

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

Re: [Xen-devel] SMMU, Unhandled context fault

[Peng Fan]

On Tue, May 03, 2016 at 11:58:17AM +0100, Julien Grall wrote:
>On 29/04/16 15:28, Peng Fan wrote:
>>Hi Julien,
>
>Hello Peng,
>
>>On Thu, Apr 28, 2016 at 02:14:58PM +0100, Julien Grall wrote:
Is there any big difference between XEN SMMU driver and linux SMMU driver?
I know that XEN only support Stage 2. But the initliaization flow is almost 
the same.
>>>
>>>The SMMU driver for Xen is a port from Linux 3.19-rc0. Since then the Linux
>>>driver has been reworked and it might be possible that we have missed some
>>>bug fix.
>>>
>>>Aside that, for Xen, the page tables are always shared between the SMMU and
>>>the processor.
>>
>>Thanks. I shared two picture that dumped using TRACE32.
>>
>>https://drive.google.com/file/d/0B9ruJqJLIGp7cHhhSFNSNC00MHc/view?usp=sharing
>>https://drive.google.com/file/d/0B9ruJqJLIGp7dmlqVllXYTIxajQ/view?usp=sharing
>>
>>Would you please help check?
>
>I am sorry but I have got no idea what each columns are supposed to contain.
>Can you share more details?

I add one more picture.
https://drive.google.com/file/d/0B9ruJqJLIGp7SUJOSUVPR1dHRFk/view?usp=sharing
The first colum is guest physical address, the second is machine address.

The FSR 0x4410, EF is 1, TF is 0. This means the mapping is correct, but 
there
is an external fault during translation?
The PTWF shows An external fault occurred while processing a translation table 
walk
I may need to check what kind external fault, it maybe not a mapping error.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall

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

[Xen-devel] [qemu-mainline baseline-only test] 44381: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44381 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44381/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 44377
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 44377

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44377

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-amd64-amd64-libvirt 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-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-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:
 qemuu975eb6a547f809608ccb08c221552f11af25
baseline version:
 qemuu47dac82d8b013a5c7dd044a797ae6727b553959a

Last test of basis44377  2016-04-30 11:31:53 Z3 days
Testing same since44381  2016-05-03 07:49:01 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Igor Mammedov 
  Jan Vesely 
  Laurent Vivier 
  Michael S. Tsirkin 
  Peter Maydell 
  Stefan Weil 

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-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 

[Xen-devel] Ping: [PATCH v3 2/4] x86: suppress SMEP and SMAP while running 32-bit PV guest code

[Jan Beulich]

>>> On 17.03.16 at 09:03,  wrote:
> Since such guests' kernel code runs in ring 1, their memory accesses,
> at the paging layer, are supervisor mode ones, and hence subject to
> SMAP/SMEP checks. Such guests cannot be expected to be aware of those
> two features though (and so far we also don't expose the respective
> feature flags), and hence may suffer page faults they cannot deal with.
> 
> While the placement of the re-enabling slightly weakens the intended
> protection, it was selected such that 64-bit paths would remain
> unaffected where possible. At the expense of a further performance hit
> the re-enabling could be put right next to the CLACs.
> 
> Note that this introduces a number of extra TLB flushes - CR4.SMEP
> transitioning from 0 to 1 always causes a flush, and it transitioning
> from 1 to 0 may also do.
> 
> Signed-off-by: Jan Beulich 

So I think we need to take some decision here, and I'm afraid
Andrew and I won't be able to settle this between us. He's
validly concerned about the performance impact this got proven
to have (for 32-bit PV guests), yet I continue to think that correct
behavior is more relevant than performance. Hence I think we
should bite the bullet and take the change. For those who value
performance more than security, they can always disable the use
of SMEP and SMAP via command line option.

Of course I'm also concerned that Intel, who did introduce the
functional regression in the first place, so far didn't participate at
all in finding an acceptable solution to the problem at hand...

Jan


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

Re: [Xen-devel] [RFC PATCH 3/7] build: convert verbose to Kconfig

[Doug Goldstein]

On 5/2/16 10:18 AM, Konrad Rzeszutek Wilk wrote:
> On Sun, May 01, 2016 at 11:10:42PM -0500, Doug Goldstein wrote:
>> Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
>> CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
>> enabled.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Stefano Stabellini 
>> CC: Julien Grall 
>> CC: Jan Beulich 
>> CC: Andrew Cooper 
>> CC: Daniel De Graaf 
>> ---
>>  INSTALL | 1 -
>>  xen/Kconfig.debug   | 6 ++
>>  xen/Rules.mk| 5 -
>>  xen/arch/arm/kernel.c   | 2 +-
>>  xen/arch/x86/domain_build.c | 2 +-
>>  xen/include/xsm/dummy.h | 2 +-
>>  6 files changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/INSTALL b/INSTALL
>> index 2974b9b..35668bd 100644
>> --- a/INSTALL
>> +++ b/INSTALL
>> @@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
>>  
>>  The following variables can be used to tweak some aspects of the
>>  hypervisor build.
>> -verbose=y
>>  perfc=y
>>  perfc_arrays=y
>>  lock_profile=y
>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>> index ee68f0d..94a6381 100644
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -15,4 +15,10 @@ config CRASH_DEBUG
>>If you want to be able to attach gdb to Xen to be able to debug
>>Xen if it crashes then say Y.
>>  
>> +config VERBOSE_DEBUG
>> +bool "Verbose debug messages"
>> +default y
>> +---help---
>> +  Enables the verbose flag when loading ELF images.
> 
> ..and when guests use HYPERVISOR_console_io
> 
> Perhaps:
> 
> Guest output from HYPERVISOR_console_io and hypervisor parsing ELF images
> (dom0) is logged in the Xen ring buffer?

Much better. Thanks!

-- 
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] [PATCH v2] x86/HVM: fix forwarding of internally cached requests

[Jan Beulich]

>>> On 03.05.16 at 14:50,  wrote:
> On April 29, 2016 12:11 AM,  wrote:
>> On April 28, 2016 11:13 PM, Jan Beulich  wrote:
>> > >>> On 25.04.16 at 10:40,  wrote:
>> > > With other patches also in place, still not work.
>> > > Jianzhong  has been left and Quan will take over the task.
>> >
>> > May I ask for another try, with current tip of staging plus
>> > http://lists.xenproject.org/archives/html/xen-devel/2016- 
>> > 04/msg03661.html
>> > ?
>> 
>> 
>> Sure, I will try it on tomorrow afternoon or next Tuesday.
> 
> Jan,
> Sorry, this is still working in progress.
>  The original env is broken. I am rebuilding a new env, with some problems 
> of Windows image.
> I checked the staging branch, and I found your patches are in staging branch 
> now,
>  so I am just going to test staging branch. Right?

Yes.


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

Re: [Xen-devel] [PATCH] xen/arm64: ensure that the correct SP is used for exceptions

[Wei Liu]

On Tue, May 03, 2016 at 11:43:34AM +0100, Julien Grall wrote:
> (CC Wei for release-ack)
> 
> Hello Kyle,
> 
> On 28/04/16 18:14, Kyle Temkin wrote:
> >From: "Kyle J. Temkin" 
> >
> >The ARMv8 architecture has a SPSel ("stack pointer selection") machine
> >register that allows us to determine which exception level's stack
> >pointer is loaded when an exception occurs. As we don't want to
> >use the non-priveleged SP_EL0 stack pointer -- or even assume that SP_EL0
> 
> NIT: s/priveleged/privileged/
> 
> >points to a valid address in the hypervisor context--  we'll need to ensure
> >that our EL2 code sets the SPSel to SP_ELn mode, so exceptions that trap
> >to EL2 use the EL2 stack pointer.
> >
> >This corrects an issue that can manifest as a hang-on-IRQ on some
> >arm64 cores if the firmware/bootloader has previously initialized SPSel
> >to 0; in which case Xen's exceptions will incorrectly use an invalid SP_EL0,
> >and will endlessly spin on the synchronous abort handler.
> >
> >Signed-off-by: Kyle Temkin 
> 
> Reviewed-by: Julien Grall 
> 
> Wei, this is a bug-fix and I think it should go to Xen 4.7.
> 

Release-acked-by: Wei Liu 

> We would also need to backport this patch on Xen 4.4 -> Xen 4.6.
> 
> Regards,
> 
> >---
> >  xen/arch/arm/arm64/head.S | 5 +
> >  1 file changed, 5 insertions(+)
> >
> >diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> >index 946e2c9..d5831f2 100644
> >--- a/xen/arch/arm/arm64/head.S
> >+++ b/xen/arch/arm/arm64/head.S
> >@@ -361,6 +361,11 @@ skip_bss:
> >  ldr   x0, =(HSCTLR_BASE)
> >  msr   SCTLR_EL2, x0
> >
> >+/* Ensure that any exceptions encountered at EL2
> >+ * are handled using the EL2 stack pointer, rather
> >+ * than SP_EL0. */
> >+msr spsel, #1
> >+
> >  /* Rebuild the boot pagetable's first-level entries. The structure
> >   * is described in mm.c.
> >   *
> >
> 
> -- 
> Julien Grall

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

Re: [Xen-devel] [ANNOUNCEMENT] Xen 4.7 RC1

[Wei Liu]

On Tue, May 03, 2016 at 02:10:35PM +0100, Wei Liu wrote:
> Hi all
> 
> Xen 4.7 RC1 is tagged. You can check that out from xen.git:
> 
>   git://xenbits.xen.org/xen.git 4.7.0-rc1
> 
> Please send bug reports and test reports to
> xen-de...@lists.xenproject.org. When sending bug reports, please CC
> relevant maintainers and me (wei.l...@citrix.com).
> 

For you convenience there is also tarball at:

http://bits.xensource.com/oss-xen/release/4.7.0-rc1/xen-4.7.0-rc1.tar.gz

And the signature is at:

http://bits.xensource.com/oss-xen/release/4.7.0-rc1/xen-4.7.0-rc1.tar.gz.sig

Wei.

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

Re: [Xen-devel] [PATCH] IOMMU/x86: per-domain control structure is not HVM-specific

[Wei Liu]

On Mon, May 02, 2016 at 06:55:35AM -0600, Jan Beulich wrote:
> ... and hence should not live in the HVM part of the PV/HVM union. In
> fact it's not even architecture specific (there already is a per-arch
> extension type to it), so it gets moved out right to common struct
> domain.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 


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

Re: [Xen-devel] [PATCH v2 for-4.7 3/6] tools/xsplice: fix mixing system errno values with Xen ones.

[Konrad Rzeszutek Wilk]

On Tue, May 03, 2016 at 02:29:20PM +0100, Wei Liu wrote:
> On Tue, May 03, 2016 at 09:27:23AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, May 03, 2016 at 12:55:07PM +0200, Roger Pau Monne wrote:
> > > Avoid using system errno values when comparing with Xen errno values.
> > > 
> > > Signed-off-by: Roger Pau Monné 
> > 
> > Reviewed-by: Konrad Rzeszutek Wilk 
> > 
> > And since Wei acked it I may as well put it in now after some tests.
> > 
> 
> I don't expect it would make a difference on Linux, but more testing
> wouldn't hurt.

Right. I stuck 'Reviewed-by' on all of them except the
"libxl: fix usage of XEN_EOPNOTSUPP"

And they are ready to be checked in (after I test them)- so just give me
the heads up when you would like that.


> 
> Wei.

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