date:20180712

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-ws16-amd64   broken in 125005
 test-amd64-i386-qemuu-rhel6hvm-intel  broken in 125005
 test-amd64-amd64-xl-xsm  broken  in 125005
 test-amd64-amd64-libvirt-xsm broken  in 125005
 test-amd64-i386-libvirt-xsm  broken  in 125005
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stopfail REGR. vs. 124248

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-ws16-amd64 4 host-install(4) broken in 125005 pass in 
125077
 test-amd64-amd64-xl-xsm  4 host-install(4) broken in 125005 pass in 125077
 test-amd64-i386-libvirt-xsm  4 host-install(4) broken in 125005 pass in 125077
 test-amd64-amd64-libvirt-xsm 4 host-install(4) broken in 125005 pass in 125077
 test-amd64-i386-qemuu-rhel6hvm-intel 4 host-install(4) broken in 125005 pass 
in 125077
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail in 125005 pass 
in 125077
 test-amd64-amd64-xl-qemut-ws16-amd64 14 guest-localmigrate fail in 125005 pass 
in 125077
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 15 guest-saverestore.2 fail in 
125044 pass in 125077
 test-amd64-i386-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail in 125044 pass 
in 125077
 test-armhf-armhf-xl-xsm   6 xen-installfail pass in 125005
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-saverestore.2 fail pass 
in 125044
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 125044
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
125044

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 124328
 test-amd64-i386-xl-qemuu-ws16-amd64 18 guest-start/win.repeat fail blocked in 
124328
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 125005 
blocked in 124328
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail in 125005 like 124328
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 125005 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 125005 never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 14 guest-localmigrate fail in 125044 like 
124248
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 125044 
like 124248
 test-amd64-i386-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 125044 
like 124248
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop  fail in 125044 like 124328
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 124248
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail like 124328
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 124328
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 124328
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124328
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

Re: [Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile

On Thu, Jul 12, 2018 at 02:33:42PM -0500, Doug Goldstein wrote:
> On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> > We don't need to specify /bin/bash in the entry point rune, otherwise
> > non-interactive invocation of the container would fail with something
> > like:
> > 
> > + C=debian:stretch-i386
> > + export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> > + CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> > + cd /local/work/COMMITTER/xen-32.git
> > + git fetch origin
> > + con git reset --hard origin/staging
> > *** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is up 
> > to date
> > *** Launching container ...
> > /usr/bin/git: /usr/bin/git: cannot execute binary file
> > 
> > While at it, use shorthand "linux32".
> > 
> > Signed-off-by: Wei Liu 
> > ---
> 
> Acked-by: Doug Goldstein 

Oh I forgot to note that there's a typo in the subject but that can just
be fixed while committing.

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

[Xen-devel] [ovmf test] 125143: all pass - PUSHED

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 79b10d4ce4f08aab4b9548fabc4542ca78a96247
baseline version:
 ovmf 0a563f3fecfd9baffe8dce51bb4411d6a748a936

Last test of basis   125124  2018-07-12 08:10:41 Z0 days
Testing same since   125143  2018-07-12 22:10:39 Z0 days1 attempts


People who touched revisions under test:
  Roman Bacik 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   0a563f3fec..79b10d4ce4  79b10d4ce4f08aab4b9548fabc4542ca78a96247 -> 
xen-tested-master

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

Re: [Xen-devel] x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

2018-07-12 Thread Kang, Luwei

Hi Lars,
I think I have sent the minutes of design session to you. I attached the email 
in case you can’t found.

Thanks,
Luwei Kang

From: Lars Kurth [mailto:lars.ku...@citrix.com]
Sent: Thursday, July 12, 2018 9:23 PM
To: Ji, John ; xen-devel 
Cc: committ...@xenproject.org; Tamas K Lengyel ; 
intel-xen ; daniel.ki...@oracle.com; Roger Pau Monne 
; Christopher Clark ; Rich 
Persaud ; Brian Woods ; Stefano 
Stabellini ; Julien Grall ; 
Juergen Gross 
Subject: Re: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

John,
Thank you. I have notes and slides for SGX, which are already published and 
Intel Processor Trace (just the slides – already published, but I am not sure 
whether these already were updated to reflect the design discussion) and 
EPT-Based Sub-Page Protection (just the slides – already published)
Lars

From: "Ji, John" mailto:john...@intel.com>>
Date: Thursday, 12 July 2018 at 13:33
To: Lars Kurth mailto:lars.ku...@citrix.com>>, xen-devel 
mailto:xen-devel@lists.xenproject.org>>
Cc: "committ...@xenproject.org" 
mailto:committ...@xenproject.org>>, Tamas K Lengyel 
mailto:tamas.k.leng...@gmail.com>>, intel-xen 
mailto:intel-...@intel.com>>, 
"daniel.ki...@oracle.com" 
mailto:daniel.ki...@oracle.com>>, Roger Monne 
mailto:roger@citrix.com>>, Christopher Clark 
mailto:christopher.w.cl...@gmail.com>>, Rich 
Persaud mailto:pers...@gmail.com>>, Brian Woods 
mailto:brian.wo...@amd.com>>, Stefano Stabellini 
mailto:sstabell...@kernel.org>>, Julien Grall 
mailto:julien.gr...@arm.com>>, Juergen Gross 
mailto:jgr...@suse.com>>
Subject: RE: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

I will Yu and Yi to send out discussion notes.

>>### Add vNVDIMM support to HVM domains
>>Stakeholders: Zhang Yi, Intel, Zhang Yu, Intel, George Dunlap, Citrix ``` _As 
>>far as I understand a simple and clean way to implement this has been found, 
>>but the design session notes are still missing_

>>_We spent almost two days on NVDIMM related discussions: we have something 
>>that should be fairly simple and easy to implement. Dan Williams is happy to 
>>take changes into upstream as long as they are sensible._

Best Regards

John Ji

-Original Message-
From: Lars Kurth [mailto:lars.ku...@citrix.com]
Sent: Thursday, July 12, 2018 5:07 PM
To: xen-devel 
mailto:xen-devel@lists.xenproject.org>>
Cc: committ...@xenproject.org; Tamas K 
Lengyel mailto:tamas.k.leng...@gmail.com>>; 
intel-xen mailto:intel-...@intel.com>>; 
daniel.ki...@oracle.com; Roger Pau Monne 
mailto:roger@citrix.com>>; Christopher Clark 
mailto:christopher.w.cl...@gmail.com>>; Rich 
Persaud mailto:pers...@gmail.com>>; Brian Woods 
mailto:brian.wo...@amd.com>>; Stefano Stabellini 
mailto:sstabell...@kernel.org>>; Julien Grall 
mailto:julien.gr...@arm.com>>; Juergen Gross 
mailto:jgr...@suse.com>>
Subject: Re: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

Also attached minutes as PDF and Markdown

# Agenda and Minutes: x86 Community Call July 2018

_No new items were added to the agenda._  _Minutes are added in blue (in the 
PDF only)_

## Attendees

Lars Kurth, Citrix
Roger Pau Monne, Citrix
Juergen Gross, Suse
Jan Beulich, Suse
Christopher Clark, OpenXT
Janakarajan Natarajan, AMD
Brian Woods, AMD
Rich Persaud, OpenXT
George Dunlap, Citrix
Wei, Andy, Paul - Citrix

## Release Cadence for Xen 4.12

Following the release cadence session at the developer summit (see 
https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00166
 & 
https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/
edit) we have to make a decision whether
* Go on as we are for 4.
* Move to 9 months, until we fixed the underlying issues as outlined in the 
thread and
write-up: the problem is that unless we get some sort of commitment to address 
the issues, just changing the release cadence will not make a difference
* Skip a release as a one-off: Set ourselves some goals that must be achieved 
in this cycle around testing - this will need some commitment from vendors

I was planning to allocate up to 30 minutes to this discussion

Juergen: raises the point that keeping the release cadence at 6 months is very 
unfair on Jan who has raised many times that the workload resulting from having 
to maintain so many release branches would be too high. After running 6 monthly 
releases for some time, this has in fact come true, when at the time Jan’s 
concerns were dismissed. The overhead breaks down into backporting fixes, 
backporting security fixes and dealing with the release mechanics.

Jan: raised the point that hardly anyone responds to calls for back-ports and 
if so, only send change-sets and lat Jan do the backporting. Jan also says he 
suspects that people may not respond to backport requests, because that would 
require them to backport the

Re: [Xen-devel] [PATCH v2 09/21] xen/arm: move cmdline out of boot_modules

2018-07-12 Thread Stefano Stabellini

On Tue, 10 Jul 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/07/2018 01:00, Stefano Stabellini wrote:
> > On Mon, 9 Jul 2018, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 07/07/18 00:12, Stefano Stabellini wrote:
> > > > Remove the cmdline field from struct boot_module, cmdline is stored
> > > > independently out of the boot_modules array as dom0_cmdline.
> > > 
> > > I am not entirely convince of this patch, this does not seem to go towards
> > > a
> > > better code base because dom0_cmdline is only set if "bootargs". This may
> > > raise some confusing to the developer.
> > 
> > I'll add a comment on top of dom0_cmdline to clarify its purpose:
> > 
> > /*
> >   * Dom0 command line as passed via Device Tree as "bootargs" for the
> >   * Dom0 kernel module.
> >   */
> > 
> > 
> > > I would still prefer to keep the command-line in the boot module structure
> > > and
> > > find a way to associated the bootmodule with a node.
> > 
> > How do you suggest we find a good way to associate a boot module with a
> > node?
> > 
> > I have thought about this problem quite a bit. Although I admit this
> > patch is not super nice, it is the best option I found. I have actually
> > developed 2 other completely different implementations of this fix and
> > they were all worse than this. This is the third incarnation. It is
> > actually surprisingly easy to do worse than this patch.
> 
> I actually have an idea. Looking at the Device-Tree specification [1], a path
> should always be unique. This means that for a given path a/b/c/d, d will
> always be unique.
> 
> Reading the binding you introduced, the multiboot node will be a child of a
> node with the compatible "xen,domain". As the name of the parent node will be
> unique, you can tag the boot-module with that name. No need for the full path
> as all the configuration node should follow the pattern /chosen/.
> 
> When the guest is built, you have the Device-Tree path of the configuration in
> hand. From that you can deduce the name that you could re-use to find the
> correct boot-module.
> 
> You may still require a separate handling similar to your next patch of Dom0
> as with the current wording they could be a level deeper. But we can tight the
> wording for the new bindings (though, I think it is tight enough).
> 
> What do you think?
> 
> Now regarding the current implementation, it does not follow the defined
> specification. The multiboot nodes are looked everywhere in the DT rather than
> only /chosen. This is an implementation bug and should be fixed.

After our discussion this morning, I introduced a separate array to
store the cmdline of the boot modules. The second array uses the device
tree node name as index.

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

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  41cb2db62627a7438d938aae487550c3f4acb1da
baseline version:
 xen  b9a3c9535622c78d04c3d548513af81c8e64d0f1

Last test of basis   125135  2018-07-12 15:00:31 Z0 days
Testing same since   125140  2018-07-12 18:00:57 Z0 days2 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Lars Kurth 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   b9a3c95356..41cb2db626  41cb2db62627a7438d938aae487550c3f4acb1da -> smoke

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

[Xen-devel] [ovmf baseline-only test] 74962: all pass

2018-07-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 74962 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74962/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0a563f3fecfd9baffe8dce51bb4411d6a748a936
baseline version:
 ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1

Last test of basis74959  2018-07-12 05:24:33 Z0 days
Testing same since74962  2018-07-12 13:27:56 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  bob.c.f...@intel.com 
  Laszlo Ersek 
  Ni, Ruiyu 
  Ruiyu Ni 

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



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

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

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


Push not applicable.


commit 0a563f3fecfd9baffe8dce51bb4411d6a748a936
Author: bob.c.f...@intel.com 
Date:   Wed Jul 11 00:19:24 2018 +0800

BaseTool: Fixed the incorrect cache key.

This patch is to fix the incorrect cache key of
skip ModuleAutoGen cache.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Bob Feng 
Cc: Liming Gao 
Reviewed-by: Liming Gao 

commit c563077a380437c114aba4c95be65eb963ebc1f3
Author: Ni, Ruiyu 
Date:   Mon Jul 2 14:01:35 2018 +0800

UefiCpuPkg/MpInitLib: Avoid calling PEI services from AP

Today's MpInitLib PEI implementation directly calls
PeiServices->GetHobList() from AP which may cause racing issue.

This patch fixes this issue by duplicating IDT for APs.
Because CpuMpData structure is stored just after IDT, the CpuMPData
address equals to IDTR.BASE + IDTR.LIMIT + 1.

v2:
  1. Add ALIGN_VALUE() on BufferSize.
  2. Add ASSERT() to make sure no memory usage outside of the allocated 
buffer.
  3. Add more comments in InitConfig path when restoring 
CpuData[0].VolatileRegisters.

Cc: Jeff Fan 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Fish Andrew 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Reviewed-by: Eric Dong 
Acked-by: Laszlo Ersek 
Tested-by: Laszlo Ersek 

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   6 xen-buildfail REGR. vs. 125135

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 xen  41cb2db62627a7438d938aae487550c3f4acb1da
baseline version:
 xen  b9a3c9535622c78d04c3d548513af81c8e64d0f1

Last test of basis   125135  2018-07-12 15:00:31 Z0 days
Testing same since   125140  2018-07-12 18:00:57 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Jan Beulich 
  Lars Kurth 
  Wei Liu 

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


Not pushing.


commit 41cb2db62627a7438d938aae487550c3f4acb1da
Author: Ian Jackson 
Date:   Thu Jul 12 15:36:11 2018 +0100

xen: oprofile/nmi_int.c: Drop unwanted sexual reference

This is not really very nice.

This line doesn't have much value in itself.  The rest of this comment
block is pretty clear what it wants to convey.  So delete it.

(While we are here, adopt the CODING_STYLE-mandated formatting.)

Signed-off-by: Ian Jackson 
Acked-by: Wei Liu 
Acked-by: Lars Kurth 
Acked-by: George Dunlap 
---
v3: Restore erroneously-dropped tab.
v2: Delete the comment entirely.
(qemu changes not included)

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

Re: [Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile

On Thu, Jul 12, 2018 at 05:31:27PM +0100, Wei Liu wrote:
> We don't need to specify /bin/bash in the entry point rune, otherwise
> non-interactive invocation of the container would fail with something
> like:
> 
> + C=debian:stretch-i386
> + export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> + CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
> + cd /local/work/COMMITTER/xen-32.git
> + git fetch origin
> + con git reset --hard origin/staging
> *** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is up to 
> date
> *** Launching container ...
> /usr/bin/git: /usr/bin/git: cannot execute binary file
> 
> While at it, use shorthand "linux32".
> 
> Signed-off-by: Wei Liu 
> ---

Acked-by: Doug Goldstein 

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

[Xen-devel] [distros-debian-wheezy test] 74961: all pass

2018-07-12 Thread Platform Team regression test user

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

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   74938

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v2 00/21] dom0less step1: boot multiple domains from device tree

2018-07-12 Thread Julien Grall


Hi,

Would it be possible to provide a branch with the patch applied? It 
would be nice to have that for every version, so I can easily know on 
which version of you are based and avoid spending time trying to apply 
it :).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 15/21] xen/arm: generate vpl011 node on device tree for domU

2018-07-12 Thread Julien Grall


Hi Stefano,

On 07/07/2018 00:12, Stefano Stabellini wrote:

Introduce vpl011 support to guests started from Xen: it provides a
simple way to print output from a guest, as most guests come with a
pl011 driver. It is also able to provide a working console with
interrupt support.

The UART exposed to the guest is a SBSA compatible UART and not a PL011.
SBSA UART is a subset of PL011 r1p5. A full PL011 implementation in Xen
would just be too difficult, so guests may require some drivers changes.

Enable vpl011 conditionally if the user requested it.

Make set_interrupt_ppi able to handle non-PPI and rename it
set_interrupt.

Signed-off-by: Stefano Stabellini 
---
Changes in v2:
- code style fixes
- make set_interrupt_ppi generic
- rename set_interrupt_ppi to set_interrupt
- only make the vpl011 node if the option was enabled
---
  xen/arch/arm/domain_build.c | 90 +
  1 file changed, 75 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 48a91ad..718be48 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -519,17 +519,17 @@ static int write_properties(struct domain *d, struct 
kernel_info *kinfo,
  
  typedef __be32 gic_interrupt_t[3];
  
-static void set_interrupt_ppi(gic_interrupt_t interrupt, unsigned int irq,

-  unsigned int cpumask, unsigned int level)
+static void set_interrupt(gic_interrupt_t interrupt, unsigned int irq,
+  unsigned int cpumask, unsigned int level)
  {
  __be32 *cells = interrupt;
+int is_ppi = (irq < 32);


I was about to suggest a bool, but I am not entirely sure what would be 
the value when it is true.


However, I think you want this to be !!(irq < 32) to make ensure it will 
be 0/1.


  
-BUG_ON(irq < 16);

-BUG_ON(irq >= 32);


Can we keep an ASSERT/BUG_ON to confirm no SGI is passed here?


+irq -= (is_ppi) ? 16: 32; /* PPIs start at 16, SPIs at 32 */
  
  /* See linux Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt */

-dt_set_cell(, 1, 1); /* is a PPI */
-dt_set_cell(, 1, irq - 16); /* PPIs start at 16 */
+dt_set_cell(, 1, is_ppi); /* is a PPI? */
+dt_set_cell(, 1, irq);
  dt_set_cell(, 1, (cpumask << 8) | level);
  }
  
@@ -648,7 +648,7 @@ static int make_hypervisor_node(struct domain *d,

   *  - All CPUs
   *  TODO: Handle properly the cpumask;
   */
-set_interrupt_ppi(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intr, d->arch.evtchn_irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
  res = fdt_property_interrupts(fdt, , 1);
  if ( res )
  return res;
@@ -924,15 +924,15 @@ static int make_timer_node(const struct domain *d, void 
*fdt,
  
  irq = timer_get_irq(TIMER_PHYS_SECURE_PPI);

  dt_dprintk("  Secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
  
  irq = timer_get_irq(TIMER_PHYS_NONSECURE_PPI);

  dt_dprintk("  Non secure interrupt %u\n", irq);
-set_interrupt_ppi(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
  
  irq = timer_get_irq(TIMER_VIRT_PPI);

  dt_dprintk("  Virt interrupt %u\n", irq);
-set_interrupt_ppi(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], irq, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
  
  res = fdt_property_interrupts(fdt, intrs, 3);

  if ( res )
@@ -1503,9 +1503,9 @@ static int make_timer_domU_node(const struct domain *d, 
void *fdt)
  return res;
  }
  
-set_interrupt_ppi(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);

-set_interrupt_ppi(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
-set_interrupt_ppi(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[0], GUEST_TIMER_PHYS_S_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[1], GUEST_TIMER_PHYS_NS_PPI, 0xf, 
DT_IRQ_TYPE_LEVEL_LOW);
+set_interrupt(intrs[2], GUEST_TIMER_VIRT_PPI, 0xf, DT_IRQ_TYPE_LEVEL_LOW);
  
  res = fdt_property(fdt, "interrupts", intrs, sizeof (intrs[0]) * 3);

  if ( res )
@@ -1520,12 +1520,63 @@ static int make_timer_domU_node(const struct domain *d, 
void *fdt)
  return res;
  }
  
+#ifdef CONFIG_SBSA_VUART_CONSOLE

+static int make_vpl011_uart_node(const struct domain *d, void *fdt,
+ int addrcells, int sizecells)
+{
+int res;
+gic_interrupt_t intr;
+int reg_size = addrcells + sizecells;
+int nr_cells = reg_size;
+__be32 reg[nr_cells];
+__be32 *cells;
+
+res = fdt_begin_node(fdt, "sbsa-pl011");
+if ( res )
+return res;
+
+res = fdt_property_string(fdt, "compatible", "arm,sbsa-uart");
+if ( res )
+return res;
+
+cells = [0];
+dt_child_set_range(,

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  b9a3c9535622c78d04c3d548513af81c8e64d0f1
baseline version:
 xen  e21ba44f771226a5f6f0ce269aabcfb019eae539

Last test of basis   125125  2018-07-12 09:00:30 Z0 days
Testing same since   125135  2018-07-12 15:00:31 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Wei Liu 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   e21ba44f77..b9a3c95356  b9a3c9535622c78d04c3d548513af81c8e64d0f1 -> smoke

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

Re: [Xen-devel] [PATCH v2] xen: setup pv irq ops vector earlier

2018-07-12 Thread Boris Ostrovsky

On 07/12/2018 11:40 AM, Juergen Gross wrote:
> Setting pv_irq_ops for Xen PV domains should be done as early as
> possible in order to support e.g. very early printk() usage.
>
> The same applies to xen_vcpu_info_reset(0), as it is needed for the
> pv irq ops.
>
> Move the call of xen_setup_machphys_mapping() after initializing the
> pv functions as it contains a WARN_ON(), too.
>
> Remove the no longer necessary conditional in xen_init_irq_ops()
> from PVH V1 times to make clear this is a PV only function.
>
> Cc:  # 4.14
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [PATCH] xen/x86/vpmu: Zero struct pt_regs before calling into sample handling code

2018-07-12 Thread Boris Ostrovsky

Otherwise we may leak kernel stack for events that sample user
registers.

Reported-by: Mark Rutland 
Signed-off-by: Boris Ostrovsky 
Cc: sta...@vger.kernel.org
---
 arch/x86/xen/pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/xen/pmu.c b/arch/x86/xen/pmu.c
index 7d00d4a..95997e6 100644
--- a/arch/x86/xen/pmu.c
+++ b/arch/x86/xen/pmu.c
@@ -478,7 +478,7 @@ static void xen_convert_regs(const struct xen_pmu_regs 
*xen_regs,
 irqreturn_t xen_pmu_irq_handler(int irq, void *dev_id)
 {
int err, ret = IRQ_NONE;
-   struct pt_regs regs;
+   struct pt_regs regs = {0};
const struct xen_pmu_data *xenpmu_data = get_xenpmu_data();
uint8_t xenpmu_flags = get_xenpmu_flags();
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v2] tools: remove local links to the x86 headers

In the x86 test harness and the fuzzer, and instead create a link in
the tools/include directory that can be used by all the tools.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
---
Changes since v1:
 - Don't remove the header dependencies in the makefile for the x86
   emulator test harness.
---
 tools/fuzz/x86_instruction_emulator/Makefile | 10 +++---
 tools/include/Makefile   |  3 +++
 tools/tests/x86_emulator/Makefile| 10 +++---
 tools/tests/x86_emulator/x86-emulate.h   |  6 +++---
 4 files changed, 12 insertions(+), 17 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index fbbb70bbfc..eb88f9412c 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -13,11 +13,6 @@ x86_emulate:
 
 x86_emulate/%: x86_emulate ;
 
-asm:
-   [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
-
-asm/%: asm ;
-
 x86-emulate.c x86-emulate.h wrappers.c: %:
[ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*
 
@@ -27,7 +22,8 @@ GCOV_FLAGS := --coverage
 %-cov.o: %.c
$(CC) -c $(CFLAGS) $(GCOV_FLAGS) $< -o $@
 
-x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
+x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
+ x86-vendors.h x86-defns.h msr-index.h)
 x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
 
 # x86-emulate.c will be implicit for both
@@ -50,7 +46,7 @@ all: x86-insn-fuzz-all
 
 .PHONY: distclean
 distclean: clean
-   rm -f x86_emulate x86-emulate.c x86-emulate.h asm
+   rm -f x86_emulate x86-emulate.c x86-emulate.h
 
 .PHONY: clean
 clean:
diff --git a/tools/include/Makefile b/tools/include/Makefile
index 666510530e..270a34f318 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -21,6 +21,9 @@ xen/.dir:
ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
xen/libelf/
ln -s ../xen-foreign xen/foreign
ln -sf $(XEN_ROOT)/xen/include/acpi acpi
+ifeq ($(CONFIG_X86),y)
+   ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
+endif
touch $@
 
 # Not xen/xsm as that clashes with link to
diff --git a/tools/tests/x86_emulator/Makefile 
b/tools/tests/x86_emulator/Makefile
index 417d5c0941..dec81c33b2 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -118,7 +118,7 @@ $(TARGET): x86-emulate.o test_x86_emulator.o wrappers.o
 
 .PHONY: clean
 clean:
-   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
x86_emulate asm
+   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
x86_emulate
 
 .PHONY: distclean
 distclean: clean
@@ -131,16 +131,12 @@ x86_emulate:
 
 x86_emulate/%: x86_emulate ;
 
-asm:
-   [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
-
-asm/%: asm ;
-
 HOSTCFLAGS-x86_64 := -fno-PIE
 $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
 HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
 
-x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
+x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
+ x86-vendors.h x86-defns.h msr-index.h)
 x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
 
 x86-emulate.o test_x86_emulator.o wrappers.o: %.o: %.c $(x86_emulate.h)
diff --git a/tools/tests/x86_emulator/x86-emulate.h 
b/tools/tests/x86_emulator/x86-emulate.h
index fd1ba5218b..b249e4673c 100644
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -11,9 +11,9 @@
 
 #include 
 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 
 #include 
 
-- 
2.17.1


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumprun-i386 broken
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 123837

Tests which are failing intermittently (not blocking):
 test-amd64-i386-rumprun-i386  4 host-install(4)  broken pass in 125043
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 125043 pass in 
125072
 test-armhf-armhf-libvirt-xsm 16 guest-start/debian.repeat fail in 125043 pass 
in 125072
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
125043

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 123837
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 123837
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 123837
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 123837
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 123837
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 123837
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 123837
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10

Re: [Xen-devel] [PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

>>> On 12.07.18 at 17:39,  wrote:
> Ian Jackson writes ("[PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual 
> reference"):
>> This is not really very nice.
>> 
>> This line doesn't have much value in itself.  The rest of this comment
>> block is pretty clear what it wants to convey.  So delete it.
>> 
>> (While we are here, adopt the CODING_STYLE-mandated formatting.)
> 
> Thanks, everyone, now committed.
> 
> Jan, can you queue this up for appropriate backports, or would you
> like me to put it on my list ?

I've queued it here.

Jan



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

Re: [Xen-devel] [PATCH v3 3/3] xen/x86: declare the efi symbol as weak

On Thu, Jul 12, 2018 at 01:35:14PM +0200, Daniel Kiper wrote:
> On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> > This allows removing the DEFINED conditional in the linker script, and
> > fixes compilation with lld:
> 
> s/lld/LLVM linker/?
> 
> Could you mention the version of LLVM linker in the commit message?
> And I am still not sure why do you insist on this patch series.
> IIRC you have told us that both issues will be fixed in LLVM.

Right, but I have no idea when lld 7.0.0 will be released, much less
when it will be merged into FreeBSD base system.

> > ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
> > /root/src/xen/xen/common/symbols-dummy.o -o 
> > /root/src/xen/xen/.xen-syms.0
> > ld: error: xen.lds:233: symbol not found: efi
> >
> > Signed-off-by: Roger Pau Monné 
> 
> With this patch applied ld from binutils 2.22 complains in this way:
> 
> ld-melf_x86_64  -T xen.lds -N prelink.o --build-id=sha1 \
> xen/common/symbols-dummy.o -o xen/.xen-syms.0
> prelink.o: In function `acpi_os_get_root_pointer':
> xen/drivers/acpi/osl.c:73:(.init.text+0x192e9): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> xen/drivers/acpi/osl.c:75:(.init.text+0x192f6): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> prelink.o: In function `efi_check_config':
> xen/arch/x86/mpparse.c:702:(.init.text+0x238ce): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/mpparse.c:706:(.init.text+0x238f2): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> prelink.o: In function `dmi_efi_iterate':
> xen/arch/x86/dmi_scan.c:377:(.init.text+0x3666f): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:391:(.init.text+0x366d7): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:400:(.init.text+0x36735): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:414:(.init.text+0x367b1): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'

Hm, weird. I've tested with ld 2.17.50 and it worked fine. Seems like
gitlab is able to reproduce this, so let me see if I can solve it.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] tools: remove local links to the x86 headers

>>> On 12.07.18 at 17:20,  wrote:
> On Thu, Jul 12, 2018 at 06:01:43AM -0600, Jan Beulich wrote:
>> >>> On 12.07.18 at 12:40,  wrote:
>> > --- a/tools/include/Makefile
>> > +++ b/tools/include/Makefile
>> > @@ -21,6 +21,9 @@ xen/.dir:
>> >ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
> xen/libelf/
>> >ln -s ../xen-foreign xen/foreign
>> >ln -sf $(XEN_ROOT)/xen/include/acpi acpi
>> > +ifeq ($(CONFIG_X86),y)
>> > +  ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
>> > +endif
>> 
>> Don't you need a .gitignore adjustment for this?
> 
> There's already a tools/include/xen/* that covers it.

Ah, good.

>> > --- a/tools/tests/x86_emulator/Makefile
>> > +++ b/tools/tests/x86_emulator/Makefile
>> > @@ -118,7 +118,7 @@ $(TARGET): x86-emulate.o test_x86_emulator.o wrappers.o
>> >  
>> >  .PHONY: clean
>> >  clean:
>> > -  rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
>> > x86_emulate 
>> > asm
>> > +  rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
>> > x86_emulate
>> >  
>> >  .PHONY: distclean
>> >  distclean: clean
>> > @@ -131,17 +131,11 @@ x86_emulate:
>> >  
>> >  x86_emulate/%: x86_emulate ;
>> >  
>> > -asm:
>> > -  [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
>> > -
>> > -asm/%: asm ;
>> > -
>> >  HOSTCFLAGS-x86_64 := -fno-PIE
>> >  $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
>> >  HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
>> >  
>> > -x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
>> > -x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
>> > +x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h
>> 
>> While removing this dependency in the fuzzer case looks to be fine, it
>> clearly isn't here: No .*.d get generated, so a change to any of those
>> files would now no longer trigger a re-build.
> 
> Oh, right. I've changed it to:
> 
> x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
>  x86-vendors.h x86-defns.h msr-index.h)
> x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
> 
> AFAICT this works fine and detects changes in the files.

Looks okay, thanks.

Jan



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

Re: [Xen-devel] [PATCH v3.1] libxl: Design of an async API to issue QMP commands to QEMU

Sorry for not noticing that you had replied.

Anthony PERARD writes ("Re: [PATCH v3.1] libxl: Design of an async API to issue 
QMP commands to QEMU"):
> Before replying to this email, here is the description of what state a
> QMP connection can be. This states are only internal to libxl_qmp.c, the
> rest of libxl doesn't need to know.
...
> +/*
> + * This are different state possible when the QMP client (libxl) is waiting.
> + * Transition from one state to the other is listed after.

These are the states of some internal libxl_qmp_something struct ?

> + * States:
> + *   Undefined
> + *   Disconnected
> + *  nothing, no allocated ressources
> + *   Connecting
> + *  Have allocated ressources,
> + *  Have connected to the QMP socket,
> + *  Waiting for server greeting.
> + *   Capability Negociation
> + *  QMP server is in Capabilities Negotiation mode.
> + *  Waiting for a response to the "qmp_capabilities" command
> + *   Connected
> + *  QMP server is in command mode,
> + *  commands can be issued

This looks like a plausible set of states.

> > > + * Possible states:
> > > + *  Undefined
> > > + *Might contain anything.
> > > + *  Idle
> > > + *Struct contents are defined enough to pass to any
> > > + *libxl__qmp_cmd_* functions but is not registered and callback
> > > + *will not be called. The struct does not contain references to
> > > + *any allocated resources so can be thrown away.
> > > + *  Active
> > > + *Currently waiting for a response from QEMU, and callback can be
> > > + *called. _dispose must be called to reclaim resources.
> > 
> > I don't think this set of states is accurate.  In particular, your API
> > description (about connection management) implies that there are at
> > least these states:
> >   (i) undefined
> >   (ii) there is no qmp connection open
> >   (iii) we have sent a command and are expecting a callback
> >   (iv) there is a qmp connection open, but no command is outstanding
> > 
> > (iv) does not fit into any of the categories above.
> 
> I don't think the state of a qmp connection can fit into
> libxl__qmp_cmd_state. The "Active" state doesn't mean that a qmp
> connection is open or that the command have been sent. It merely mean
> that the syscall socket(3) and connect(3) have return successfully, and
> there will be an attempt later to sent the command to qemu.

I think you haven't quite understood my point.

My understanding of your API is that it gives the user of
libl__qmp_cmd a certain amount of visibility of the existence or
otherwise of the qmp connection.

You say:

  + * When called from within a callback, the same QMP connection will be
  + * reused to execute the new command. This is important in the case
  + * where the first command is "add-fd" and the second command use the
  + * fdset created by QEMU.

This implies that at the top of the callback, the qmp connection is
actually in some kind of extra state which is not covered by any of
your Undefined, Idle or Active.

It is not Undefined, obviously.

It is not Active because no response is being awaited any longer.
(If a response were being awaited, then it would not be sensible for
the callback to issue another command, because your rule is one
command at once.)

And it is not Idle because it contains references to allocated
resources - namely, the qmp connection fd.

So your documented state model is too poor to express what is going
on.  You need to write down at least one additional state, which you
might call `Connected'.


Also, I have just noticed that you say "from within a callback".  That
suggests that the code which makes the callback does something to the
libxl__qmp_state after after the callback returns.

That is contrary to the way that everything else works in libxl.  In
libxl, such a callback is made as the last thing before returning back
to the event loop.

The reason is that the state struct (in this case the libxl__qmp_cmd)
may be part of a larger struct, which is completed and deallocated
somewhere in the series of (nested) callback functions.  So the memory
may not be valid any more.


Another way to look at this is that you actually have a fourth state
which I will call WithinCallback.  On entry to the callback, the cmd
is in WithinCallback state.

In WithinCallback state, it is allowed to request that another command
is sent (putting the cmd back into Active).

But in the WithinCallback state, the libxl__qmp_cmd contains
references to resources and may not be freed.  Furthermore, as I read
your commentary, the WithinCallback state cannot be exited other than
to Active, or by returning from the callback.

That would make it very awkward for the user of this interface to ever
free the cmd.  After all, they can only free the memory for it when
the state is Idle or Undefined.  So they need to get it into Idle
which they can only do by returning, but then they have lost
control...


So this is why I say you should have a

[Xen-devel] [PATCH] automation/build: update stretck-i386 dockerfile

We don't need to specify /bin/bash in the entry point rune, otherwise
non-interactive invocation of the container would fail with something
like:

+ C=debian:stretch-i386
+ export CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
+ CONTAINER=registry.gitlab.com/xen-project/xen/debian:stretch-i386
+ cd /local/work/COMMITTER/xen-32.git
+ git fetch origin
+ con git reset --hard origin/staging
*** Ensuring registry.gitlab.com/xen-project/xen/debian:stretch-i386 is up to 
date
*** Launching container ...
/usr/bin/git: /usr/bin/git: cannot execute binary file

While at it, use shorthand "linux32".

Signed-off-by: Wei Liu 
---
 automation/build/debian/stretch-i386.dockerfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/automation/build/debian/stretch-i386.dockerfile 
b/automation/build/debian/stretch-i386.dockerfile
index ec37a5fbf8..65247a474e 100644
--- a/automation/build/debian/stretch-i386.dockerfile
+++ b/automation/build/debian/stretch-i386.dockerfile
@@ -8,7 +8,7 @@ ENV USER root
 RUN mkdir /build
 WORKDIR /build
 
-ENTRYPOINT ["/usr/bin/setarch", "i686", "/bin/bash"]
+ENTRYPOINT ["linux32"]
 
 # build depends
 RUN apt-get update && \
-- 
2.11.0


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

Re: [Xen-devel] [PATCH] scripts: add helper script to use Docker containers

On Thu, Jul 12, 2018 at 08:53:06AM -0500, Doug Goldstein wrote:
> This adds a script that can be used to do builds easily within the
> defined containers under the automation directory. These containers live
> in the public GitLab registry under the xen-project namespace. The
> script can be executed a number of ways but the default is to drop you
> at a bash shell within a Debian Stretch container at the top level of
> the source tree.
> 
> Signed-off-by: Doug Goldstein 
> ---
> A few folks have asked about this so I'm CCing folks directly. I'm
> completely game for changing anything that makes this easier for folks
> to use. This is primarily geared as a developer/maintainer tool but
> its also good for folks just starting out with Xen and not having
> all the dependencies installed.

+1 to this.

I have found this script to be quite handy.

Wei.

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

Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads

On 11/07/18 13:10, Jan Beulich wrote:
> Shared resources (L1 cache and TLB in particular) present a risk of
> information leak via side channels. Don't use hyperthreads in such
> cases, but allow independent control of their use at the same time.
>
> Signed-off-by: Jan Beulich 
> ---
> An option to avoid the up/down cycle would be to avoid clearing the
> sibling (and then perhaps also core) map of parked CPUs, allowing to
> bail early from cpu_up_helper().
>
> TBD: How to prevent the CPU from transiently becoming available for
>  scheduling when being onlined at runtime?

This looks like an argument for cancelling at call-in time, no?

> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>  ### hpetbroadcast (x86)
>  > `= `
>  
> +### ht (x86)

I'd suggest smt rather than ht here.  SMT is the technical term, while
HT is Intel's marketing name.

~Andrew

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

Re: [Xen-devel] [PATCH 5/8] x86: bring up all CPUs even if not all are supposed to be used

On 11/07/18 13:09, Jan Beulich wrote:
> Reportedly Intel CPUs which can't broadcast #MC to all targeted
> cores/threads because some have CR4.MCE clear will shut down. Therefore
> we want to keep CR4.MCE enabled when offlining a CPU, and we need to
> bring up all CPUs in order to be able to set CR4.MCE in the first place.
>
> The use of clear_in_cr4() in cpu_mcheck_disable() was ill advised
> anyway, and to avoid future similar mistakes I'm removing clear_in_cr4()
> altogether right here.
>
> Signed-off-by: Jan Beulich 
> ---
> Instead of fully bringing up CPUs and then calling cpu_down(), another
> option would be to suppress/cancel full bringup in smp_callin().

What is the practical difference?  When we know ahead of time that we
are intending to part the core, then cancelling in smp_callin() seems
cleaner.

> --- a/xen/arch/x86/mpparse.c
> +++ b/xen/arch/x86/mpparse.c
> @@ -68,18 +68,26 @@ physid_mask_t phys_cpu_present_map;
>  
>  void __init set_nr_cpu_ids(unsigned int max_cpus)
>  {
> + unsigned int tot_cpus = num_processors + disabled_cpus;
> +
>   if (!max_cpus)
> - max_cpus = num_processors + disabled_cpus;
> + max_cpus = tot_cpus;
>   if (max_cpus > NR_CPUS)
>   max_cpus = NR_CPUS;
>   else if (!max_cpus)
>   max_cpus = 1;
>   printk(XENLOG_INFO "SMP: Allowing %u CPUs (%d hotplug CPUs)\n",
>  max_cpus, max_t(int, max_cpus - num_processors, 0));
> - nr_cpu_ids = max_cpus;
> +
> + if (!park_offline_cpus)
> + tot_cpus = max_cpus;
> + nr_cpu_ids = min(tot_cpus, NR_CPUS + 0u);
> + if (park_offline_cpus && nr_cpu_ids < num_processors)
> + printk(XENLOG_WARNING "SMP: Cannot bring up %u further CPUs\n",
> +num_processors - nr_cpu_ids);
>  
>  #ifndef nr_cpumask_bits
> - nr_cpumask_bits = (max_cpus + (BITS_PER_LONG - 1)) &
> + nr_cpumask_bits = (nr_cpu_ids + (BITS_PER_LONG - 1)) &
> ~(BITS_PER_LONG - 1);

ROUNDUP() ?

~Andrew

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

Re: [Xen-devel] [PATCH v3 1/3] xen/x86: replace '||' usage in the linker script

On Thu, Jul 12, 2018 at 01:38:21PM +0200, Daniel Kiper wrote:
> On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> > With '|'. The result is the same, and the later works with lld. Fixes
> > the following error when building Xen with lld:
> >
> > ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
> > /root/src/xen/xen/common/symbols-dummy.o -o 
> > /root/src/xen/xen/.xen-syms.0
> > ld: error: xen.lds:260: malformed number: |
> > >>> ASSERT(__image_base__ > (261 >> 8) * 0x) | (261 
> > >>> << 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 30))) ||
> > >>> 
> > >>>   ^
> >
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Daniel Kiper 
> > ---
> >  xen/arch/x86/xen.lds.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> > index 70afedd31d..326e885402 100644
> > --- a/xen/arch/x86/xen.lds.S
> > +++ b/xen/arch/x86/xen.lds.S
> > @@ -331,7 +331,7 @@ SECTIONS
> >.comment 0 : { *(.comment) }
> >  }
> >
> > -ASSERT(__image_base__ > XEN_VIRT_START ||
> > +ASSERT(__image_base__ > XEN_VIRT_START |
> > __2M_rwdata_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
> > "Xen image overlaps stubs area")
> 
> I am not happy with this change. Is the same needed for any "&&"?

I haven't tried, but I assume both '||' and '&&' would be equally
broken. There's no '&&' ATM anyway.

> Anyway, if maintainers are OK with that I will just ask you to put
> the comment before the ASSERT() why you use "|" instead of "||".

OK, I can add something like:

"lld (LLVM linker) version 6.0.0 doesn't support '||', so use '|'
instead."

Thanks, Roger.

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

[Xen-devel] [PATCH v2] xen: setup pv irq ops vector earlier

2018-07-12 Thread Juergen Gross

Setting pv_irq_ops for Xen PV domains should be done as early as
possible in order to support e.g. very early printk() usage.

The same applies to xen_vcpu_info_reset(0), as it is needed for the
pv irq ops.

Move the call of xen_setup_machphys_mapping() after initializing the
pv functions as it contains a WARN_ON(), too.

Remove the no longer necessary conditional in xen_init_irq_ops()
from PVH V1 times to make clear this is a PV only function.

Cc:  # 4.14
Signed-off-by: Juergen Gross 
---
 arch/x86/xen/enlighten_pv.c | 24 +++-
 arch/x86/xen/irq.c  |  4 +---
 2 files changed, 12 insertions(+), 16 deletions(-)

diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 4816b6f82a9a..439a94bf89ad 100644
--- a/arch/x86/xen/enlighten_pv.c
+++ b/arch/x86/xen/enlighten_pv.c
@@ -1207,12 +1207,20 @@ asmlinkage __visible void __init xen_start_kernel(void)
 
xen_setup_features();
 
-   xen_setup_machphys_mapping();
-
/* Install Xen paravirt ops */
pv_info = xen_info;
pv_init_ops.patch = paravirt_patch_default;
pv_cpu_ops = xen_cpu_ops;
+   xen_init_irq_ops();
+
+   /*
+* Setup xen_vcpu early because it is needed for
+* local_irq_disable(), irqs_disabled(), e.g. in printk().
+*
+* Don't do the full vcpu_info placement stuff until we have
+* the cpu_possible_mask and a non-dummy shared_info.
+*/
+   xen_vcpu_info_reset(0);
 
x86_platform.get_nmi_reason = xen_get_nmi_reason;
 
@@ -1225,6 +1233,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
 * Set up some pagetable state before starting to set any ptes.
 */
 
+   xen_setup_machphys_mapping();
xen_init_mmu_ops();
 
/* Prevent unwanted bits from being set in PTEs. */
@@ -1250,20 +1259,9 @@ asmlinkage __visible void __init xen_start_kernel(void)
get_cpu_cap(_cpu_data);
x86_configure_nx();
 
-   xen_init_irq_ops();
-
/* Let's presume PV guests always boot on vCPU with id 0. */
per_cpu(xen_vcpu_id, 0) = 0;
 
-   /*
-* Setup xen_vcpu early because idt_setup_early_handler needs it for
-* local_irq_disable(), irqs_disabled().
-*
-* Don't do the full vcpu_info placement stuff until we have
-* the cpu_possible_mask and a non-dummy shared_info.
-*/
-   xen_vcpu_info_reset(0);
-
idt_setup_early_handler();
 
xen_init_capabilities();
diff --git a/arch/x86/xen/irq.c b/arch/x86/xen/irq.c
index 74179852e46c..7515a19fd324 100644
--- a/arch/x86/xen/irq.c
+++ b/arch/x86/xen/irq.c
@@ -128,8 +128,6 @@ static const struct pv_irq_ops xen_irq_ops __initconst = {
 
 void __init xen_init_irq_ops(void)
 {
-   /* For PVH we use default pv_irq_ops settings. */
-   if (!xen_feature(XENFEAT_hvm_callback_vector))
-   pv_irq_ops = xen_irq_ops;
+   pv_irq_ops = xen_irq_ops;
x86_init.irqs.intr_init = xen_init_IRQ;
 }
-- 
2.13.7


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

Re: [Xen-devel] [PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

Ian Jackson writes ("[PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual 
reference"):
> This is not really very nice.
> 
> This line doesn't have much value in itself.  The rest of this comment
> block is pretty clear what it wants to convey.  So delete it.
> 
> (While we are here, adopt the CODING_STYLE-mandated formatting.)

Thanks, everyone, now committed.

Jan, can you queue this up for appropriate backports, or would you
like me to put it on my list ?

Ian.

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

[Xen-devel] [PATCH v3] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

This is not really very nice.

This line doesn't have much value in itself.  The rest of this comment
block is pretty clear what it wants to convey.  So delete it.

(While we are here, adopt the CODING_STYLE-mandated formatting.)

Signed-off-by: Ian Jackson 
Acked-by: Wei Liu 
Acked-by: Lars Kurth 
Acked-by: George Dunlap 
---
v3: Restore erroneously-dropped tab.
v2: Delete the comment entirely.
---
 xen/arch/x86/oprofile/nmi_int.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index d8f5230..3dfb8fe 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -182,7 +182,7 @@ int nmi_reserve_counters(void)
if (!allocate_msrs())
return -ENOMEM;
 
-   /* We walk a thin line between law and rape here.
+   /*
 * We need to be careful to install our NMI handler
 * without actually triggering any NMIs as this will
 * break the core code horrifically.
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] tools: remove local links to the x86 headers

On Thu, Jul 12, 2018 at 06:01:43AM -0600, Jan Beulich wrote:
> >>> On 12.07.18 at 12:40,  wrote:
> > --- a/tools/include/Makefile
> > +++ b/tools/include/Makefile
> > @@ -21,6 +21,9 @@ xen/.dir:
> > ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
> > xen/libelf/
> > ln -s ../xen-foreign xen/foreign
> > ln -sf $(XEN_ROOT)/xen/include/acpi acpi
> > +ifeq ($(CONFIG_X86),y)
> > +   ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
> > +endif
> 
> Don't you need a .gitignore adjustment for this?

There's already a tools/include/xen/* that covers it.

> > --- a/tools/tests/x86_emulator/Makefile
> > +++ b/tools/tests/x86_emulator/Makefile
> > @@ -118,7 +118,7 @@ $(TARGET): x86-emulate.o test_x86_emulator.o wrappers.o
> >  
> >  .PHONY: clean
> >  clean:
> > -   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
> > x86_emulate 
> > asm
> > +   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
> > x86_emulate
> >  
> >  .PHONY: distclean
> >  distclean: clean
> > @@ -131,17 +131,11 @@ x86_emulate:
> >  
> >  x86_emulate/%: x86_emulate ;
> >  
> > -asm:
> > -   [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
> > -
> > -asm/%: asm ;
> > -
> >  HOSTCFLAGS-x86_64 := -fno-PIE
> >  $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
> >  HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
> >  
> > -x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
> > -x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
> > +x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h
> 
> While removing this dependency in the fuzzer case looks to be fine, it
> clearly isn't here: No .*.d get generated, so a change to any of those
> files would now no longer trigger a re-build.

Oh, right. I've changed it to:

x86.h := $(addprefix $(XEN_ROOT)/tools/include/xen/asm/,\
 x86-vendors.h x86-defns.h msr-index.h)
x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)

AFAICT this works fine and detects changes in the files.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

>>> On 12.07.18 at 17:08,  wrote:
> This is not really very nice.
> 
> This line doesn't have much value in itself.  The rest of this comment
> block is pretty clear what it wants to convey.  So delete it.
> 
> (While we are here, adopt the CODING_STYLE-mandated formatting.)
> 
> Signed-off-by: Ian Jackson 
> Acked-by: Wei Liu 
> Acked-by: Lars Kurth 
> Acked-by: George Dunlap 

> --- a/xen/arch/x86/oprofile/nmi_int.c
> +++ b/xen/arch/x86/oprofile/nmi_int.c
> @@ -182,8 +182,8 @@ int nmi_reserve_counters(void)
>   if (!allocate_msrs())
>   return -ENOMEM;
>  
> - /* We walk a thin line between law and rape here.
> -  * We need to be careful to install our NMI handler
> + /*
> + * We need to be careful to install our NMI handler

Would be nice indeed if you could restore the tab here, for being
a Linux style file.

Jan



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

Re: [Xen-devel] [PATCH 8/8] cpumask: tidy {,z}alloc_cpumask_var()

On Wed, Jul 11, 2018 at 06:12:14AM -0600, Jan Beulich wrote:
> Drop unnecessary casts and use bool in favor of bool_t.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] Xen for Automotive - white paper on virtualization

2018-07-12 Thread Michele Paolino

Thank you Rich to share this with the XEN community,

Any comment is welcome.

Regards,

On Thu, Jul 12, 2018 at 2:39 PM, Rich Persaud  wrote:

> Thanks to everyone who contributed to the AGL virtualization white paper
> and to Michele Paolino for stewarding it from concept to final publication.
>   I’ve added it to the Xen wiki:
>
> https://wiki.xenproject.org/wiki/Automotive_Whitepapers
>
> Rich
>



-- 
*Michele Paolino, Virtualization Architect*


*Virtual Open Systems SASMixed-Critical Virtualization Solutions*
*Automotive | IoT-Edge | Embedded Systems*

*Web: www.virtualopensystems.com *
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v2] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

This is not really very nice.

This line doesn't have much value in itself.  The rest of this comment
block is pretty clear what it wants to convey.  So delete it.

(While we are here, adopt the CODING_STYLE-mandated formatting.)

Signed-off-by: Ian Jackson 
Acked-by: Wei Liu 
Acked-by: Lars Kurth 
Acked-by: George Dunlap https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 6/6] osstest: add FreeBSD Xen build job

On Thu, Jul 12, 2018 at 03:50:07PM +0100, Ian Jackson wrote:
> Roger Pau Monne writes ("[PATCH v2 6/6] osstest: add FreeBSD Xen build job"):
> > To both the FreeBSD and the xen-unstable flights.
> > 
> > This is the runvar difference of a xen-unstable flight:
> 
> Can you split out the refactoring, please ?

Sure, I've pushed it to:

git://xenbits.xen.org/people/royger/osstest.git freebsd_improvement_v3

If you prefer I can also send the updated series to the mailing list.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted sexual reference



> On 12 Jul 2018, at 15:49, Wei Liu  wrote:
> 
> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
>> This is not really very nice.
>> 
>> I don't understand the technical details here but `violence' is
>> probably fair.  The word `violence' is often used metaphorically in a
>> technical context so I think it's probably OK for use in this way.
>> 
>> IMO this patch should be backported to all maintained trees.
>> 
>> Signed-off-by: Ian Jackson 
>> ---
>> xen/arch/x86/oprofile/nmi_int.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/xen/arch/x86/oprofile/nmi_int.c 
>> b/xen/arch/x86/oprofile/nmi_int.c
>> index d8f5230..cc36827 100644
>> --- a/xen/arch/x86/oprofile/nmi_int.c
>> +++ b/xen/arch/x86/oprofile/nmi_int.c
>> @@ -182,7 +182,7 @@ int nmi_reserve_counters(void)
>>  if (!allocate_msrs())
>>  return -ENOMEM;
>> 
>> -/* We walk a thin line between law and rape here.
>> +/* We walk a thin line between law and violence here.
> 
> IMHO this line doesn't have much value in itself. The rest of this
> comment block is pretty clear what it wants to convey.
> 
> Wei.
> 

I agree: we should delete or replace with "ATTENTION:". The following section 
part of the comment is what is important

>>   * We need to be careful to install our NMI handler
>>   * without actually triggering any NMIs as this will
>>   * break the core code horrifically

Lars


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

Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

2018-07-12 Thread George Dunlap

On Thu, Jul 12, 2018 at 3:52 PM, Ian Jackson  wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop 
> unwanted sexual reference"):
>> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
>> > -   /* We walk a thin line between law and rape here.
>> > +   /* We walk a thin line between law and violence here.
>>
>> IMHO this line doesn't have much value in itself. The rest of this
>> comment block is pretty clear what it wants to convey.
>
> Lars expressed a similar sentiment on irc.  I would be very happy to
> delete it entirely.  I will defer to the hypervisor maintainers on
> that.

+1 for deleting it.  Technically it requires an x86 maintianer's ack.

 -George

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

Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

Wei Liu writes ("Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted 
sexual reference"):
> On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
> > -   /* We walk a thin line between law and rape here.
> > +   /* We walk a thin line between law and violence here.
> 
> IMHO this line doesn't have much value in itself. The rest of this
> comment block is pretty clear what it wants to convey.

Lars expressed a similar sentiment on irc.  I would be very happy to
delete it entirely.  I will defer to the hypervisor maintainers on
that.

Ian.

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

Re: [Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

On Thu, Jul 12, 2018 at 03:41:55PM +0100, Ian Jackson wrote:
> This is not really very nice.
> 
> I don't understand the technical details here but `violence' is
> probably fair.  The word `violence' is often used metaphorically in a
> technical context so I think it's probably OK for use in this way.
> 
> IMO this patch should be backported to all maintained trees.
> 
> Signed-off-by: Ian Jackson 
> ---
>  xen/arch/x86/oprofile/nmi_int.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
> index d8f5230..cc36827 100644
> --- a/xen/arch/x86/oprofile/nmi_int.c
> +++ b/xen/arch/x86/oprofile/nmi_int.c
> @@ -182,7 +182,7 @@ int nmi_reserve_counters(void)
>   if (!allocate_msrs())
>   return -ENOMEM;
>  
> - /* We walk a thin line between law and rape here.
> + /* We walk a thin line between law and violence here.

IMHO this line doesn't have much value in itself. The rest of this
comment block is pretty clear what it wants to convey.

Wei.

>* We need to be careful to install our NMI handler
>* without actually triggering any NMIs as this will
>* break the core code horrifically.
> -- 
> 2.1.4
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel

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

Re: [Xen-devel] [PATCH v2 6/6] osstest: add FreeBSD Xen build job

Roger Pau Monne writes ("[PATCH v2 6/6] osstest: add FreeBSD Xen build job"):
> To both the FreeBSD and the xen-unstable flights.
> 
> This is the runvar difference of a xen-unstable flight:

Can you split out the refactoring, please ?

That way I can do my own runvar difference on the just-refactoring
part of the series.

Thanks,
Ian.

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

[Xen-devel] [PATCH v2 5/6] osstest: set the make command to use for xen-build

The default make on FreeBSD is the BSD make, and Xen requires the GNU
make in order to build. Set the make command based on the OS for the
Xen build.

Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
Changes since v1:
 - Use gmake for all BSDs.
---
 ts-xen-build | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/ts-xen-build b/ts-xen-build
index 57913d4f..48bf062f 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -28,6 +28,7 @@ tsreadconfig();
 selectbuildhost(\@ARGV);
 
 our $dokconfig = 1;
+our $make = $ho->{OS} =~ m/bsd/ ? "gmake" : "make";
 
 while (@ARGV && $ARGV[0] =~ m/^-/) {
 $_ = shift @ARGV;
@@ -156,24 +157,24 @@ END
 
 buildcmd_stamped_logged(600, 'xen', 'kconfig', '',

[Xen-devel] [PATCH v2 1/6] osstest: allow appending to existing runvars

From: Ian Jackson 

So that the contents of the runvar can be expanded. There are
currently two ways to do this:

 - Using += will append to the end of the runvar.
 - Using ,= will append to the end of the runvar using ',' as the
   separator.

Note that if the runvar is empty {,|+}= just sets the runvar.

Signed-off-by: Ian Jackson 
---
 cs-job-create | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cs-job-create b/cs-job-create
index 064a9294..1980a625 100755
--- a/cs-job-create
+++ b/cs-job-create
@@ -53,8 +53,12 @@ foreach my $rv (@runvars) {
 $suppress{$1}= 1;
 next;
 }
-$rv =~ m/^([a-z][0-9a-z_]*)(\~?)\=(.*)$/ or die "$rv ?";
-my ($name,$synth,$val) = ($1,$2,$3);
+$rv =~ m/^([a-z][0-9a-z_]*)(\~?)([+,]?)\=(.*)$/ or die "$rv ?";
+my ($name,$synth,$add,$val) = ($1,$2,$3,$4);
+if ($add && $runvars{$name}) {
+   die "$name synth mismatch" if !!$runvars{$name}[1] ne !!$synth;
+   $val = $runvars{$name}[0].($add ne '+' && $add).$val;
+}
 $runvars{$name}= [$val,$synth];
 }
 
-- 
2.17.1


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

[Xen-devel] [PATCH v2 2/6] osstest: remove duplicate set_freebsd_runvars

The set_freebsd_runvars helper in mfi-common is a superset of the
original function present in make-freebsd-flight, and will attempt to
fetch the last anointed FreeBSD build as a last resort option if no
FreeBSD build is signaled from the FreeBSD env vars. There's no reason
to have this duplication, since the set_freebsd_runvars in mfi-common
is perfectly suitable to be used by make-freebsd-flight.

This duplication was wrongly introduced by d36a7d892f by adding a
set_freebsd_runvars to mfi-common without removing the original
function in make-freebsd-flight.

Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
Changes since v1:
 - Add commit message.
---
 make-freebsd-flight | 31 ---
 1 file changed, 31 deletions(-)

diff --git a/make-freebsd-flight b/make-freebsd-flight
index 66d4b816..1a2b359c 100755
--- a/make-freebsd-flight
+++ b/make-freebsd-flight
@@ -36,37 +36,6 @@ job_create_build_filter_callback () {
 :
 }
 
-set_freebsd_runvars () {
-# Caller should have done if required:
-# local freebsd_runvars
-#
-# Figure out where are the installer binaries. The order is the
-# following:
-#
-# 1. Env variable FREEBSD__BUILDJOB: use the output from a
-# previous build--freebsd.
-#
-# 2. Env variables FREEBSD_DIST, FREEBSD_VERSION: set before calling
-# into make-flight, provide the path to the installer image, the sets
-# to install and the version being installed.
-#
-# 3. Config file FreeBSDDist, FreeBSDVersion: same as 2. except that
-# they are set on the config file.
-#
-envvar="FREEBSD_${arch^^}_BUILDJOB"
-if [ -n "${!envvar}" ]; then
-freebsd_runvars="freebsdbuildjob=${!envvar}"
-elif [ -n "$FREEBSD_DIST" ] && [ -n "$FREEBSD_VERSION" ]; then
-freebsd_runvars="freebsd_distpath=$FREEBSD_DIST/$arch \
- freebsd_version=$FREEBSD_VERSION"
-else
-distpath=`getconfig "FreeBSDDist"`
-version=`getconfig "FreeBSDVersion"`
-freebsd_runvars="freebsd_distpath=$distpath/$arch \
- freebsd_version=$version"
-fi
-}
-
 for arch in "$arches"; do
 set_freebsd_runvars
 job_create_build build-$arch-freebsd build-freebsd  \
-- 
2.17.1


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

[Xen-devel] [PATCH v2 4/6] osstest: limit FreeBSD jobs to hardware booting in BIOS mode

There's no support yet in osstest to install FreeBSD from UEFI, so for
the time being limit the FreeBSD jobs to boxes booting with legacy
BIOS.

The hostflags are not set for examine jobs, in order to avoid them
from only running on BIOS boxes.

Signed-off-by: Roger Pau Monné 
Acked-by: Ian Jackson 
---
Note that this patch depends on Ian Jackson's resource allocation
series.
---
Changes since v1:
 - Fix nonbreaking space.
 - Fix long line.
---
 make-flight |  3 ++-
 mfi-common  | 16 
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/make-flight b/make-flight
index 4e2d464f..deb2276d 100755
--- a/make-flight
+++ b/make-flight
@@ -704,7 +704,8 @@ do_examine_one () {
   local freebsd_runvars
   # set_freebsd_runvars expects $arch to be set to the desired FreeBSD arch.
   local arch=$dom0arch
-  set_freebsd_runvars
+  # Pass true to not append any hostflags when creating the FreeBSD runvars.
+  set_freebsd_runvars true
   job_create_test test-$xenarch$kern-$dom0arch-examine \
   host-examine-xen xl $xenarch $dom0arch \
   all_hostflags=$most_hostflags $freebsd_runvars
diff --git a/mfi-common b/mfi-common
index 0e6cf01e..74645259 100644
--- a/mfi-common
+++ b/mfi-common
@@ -149,27 +149,35 @@ set_freebsd_runvars () {
 #
 # 4. Look for an anointed build of FreeBSD `master' (Executive only)
 #
+local no_hostflags=$1
 local envvar="FREEBSD_${arch^^}_BUILDJOB"
+
+if [ x$no_hostflags != xtrue ]; then
+# osstest doesn't yet know how to install FreeBSD on UEFI hosts, so
+# limit the usable hardware to boxes that boot from BIOS.
+freebsd_runvars="all_hostflags,=PropEq:Firmware:bios:bios"
+fi
+
 if [ -n "${!envvar}" ]; then
-freebsd_runvars="freebsdbuildjob=${!envvar}"
+freebsd_runvars="$freebsd_runvars freebsdbuildjob=${!envvar}"
 return
 fi
 if [ -n "$FREEBSD_DIST" ] && [ -n "$FREEBSD_VERSION" ]; then
-freebsd_runvars="freebsd_distpath=$FREEBSD_DIST/$arch \
+freebsd_runvars="$freebsd_runvars freebsd_distpath=$FREEBSD_DIST/$arch 
\
  freebsd_version=$FREEBSD_VERSION"
 return
 fi
 local distpath=`getconfig "FreeBSDDist"`
 if [ -n "$distpath" ]; then
 local version=`getconfig "FreeBSDVersion"`
-freebsd_runvars="freebsd_distpath=$distpath/$arch \
+freebsd_runvars="$freebsd_runvars freebsd_distpath=$distpath/$arch \
  freebsd_version=$version"
 return
 fi
 local anointment="freebsd build master $arch"
 local flightjob=`./mg-anoint retrieve --tolerate-unprepared "$anointment"`
 if [ -n "$flightjob" ]; then
-freebsd_runvars="freebsdbuildjob=${flightjob/ /.}"
+freebsd_runvars="$freebsd_runvars freebsdbuildjob=${flightjob/ /.}"
 return
 fi
 }
-- 
2.17.1


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

[Xen-devel] [PATCH v2 6/6] osstest: add FreeBSD Xen build job

To both the FreeBSD and the xen-unstable flights.

This is the runvar difference of a xen-unstable flight:

+build-amd64-xen-freebsd all_host_os  freebsd
+build-amd64-xen-xsm-freebsd all_host_os  freebsd
+build-amd64-xen-freebsd all_hostflagsPropEq:Firmware:bios:bios
+build-amd64-xen-xsm-freebsd all_hostflagsPropEq:Firmware:bios:bios
+build-amd64-xen-freebsd arch amd64
+build-amd64-xen-xsm-freebsd arch amd64
+build-amd64-xen-freebsd enable_livepatch true
+build-amd64-xen-xsm-freebsd enable_livepatch true
+build-amd64-xen-freebsd enable_ovmf  false
+build-amd64-xen-xsm-freebsd enable_ovmf  false
+build-amd64-xen-freebsd enable_xend  false
+build-amd64-xen-xsm-freebsd enable_xend  false
+build-amd64-xen-freebsd enable_xsm   false
+build-amd64-xen-xsm-freebsd enable_xsm   true
+build-amd64-xen-freebsd freebsdbuildjob  125104.build-amd64-freebsd
+build-amd64-xen-xsm-freebsd freebsdbuildjob  125104.build-amd64-freebsd
+build-amd64-xen-freebsd host_hostflags   arch-amd64,purpose-build
+build-amd64-xen-xsm-freebsd host_hostflags   arch-amd64,purpose-build
+build-amd64-xen-freebsd revision_minios
+build-amd64-xen-xsm-freebsd revision_minios
+build-amd64-xen-freebsd revision_ovmf
+build-amd64-xen-xsm-freebsd revision_ovmf
+build-amd64-xen-freebsd revision_qemu
+build-amd64-xen-xsm-freebsd revision_qemu
+build-amd64-xen-freebsd revision_qemuu
+build-amd64-xen-xsm-freebsd revision_qemuu
+build-amd64-xen-freebsd revision_seabios
+build-amd64-xen-xsm-freebsd revision_seabios
+build-amd64-xen-freebsd revision_xen
+build-amd64-xen-xsm-freebsd revision_xen
+build-amd64-xen-freebsd tree_minios
+build-amd64-xen-xsm-freebsd tree_minios
+build-amd64-xen-freebsd tree_ovmf
+build-amd64-xen-xsm-freebsd tree_ovmf
+build-amd64-xen-freebsd tree_qemu
git://xenbits.xen.org/qemu-xen-traditional.git
+build-amd64-xen-xsm-freebsd tree_qemu
git://xenbits.xen.org/qemu-xen-traditional.git
+build-amd64-xen-freebsd tree_qemuu   git://xenbits.xen.org/qemu-xen.git
+build-amd64-xen-xsm-freebsd tree_qemuu   git://xenbits.xen.org/qemu-xen.git
+build-amd64-xen-freebsd tree_seabios
+build-amd64-xen-xsm-freebsd tree_seabios
+build-amd64-xen-freebsd tree_xen git://xenbits.xen.org/xen.git
+build-amd64-xen-xsm-freebsd tree_xen git://xenbits.xen.org/xen.git

Signed-off-by: Roger Pau Monné 
---
Changes since v1:
 - Fix enabling of FreeBSD Xen buildjob based on branch.
 - Introduce a helper to add the FreeBSD Xen build jobs.
 - Introduce the ts-xen-build-freebsd wrapper around ts-xen-build for
   FreeBSD.
 - Introduce a create_xen_build_job helper.
---
 make-freebsd-flight   |  6 +
 mfi-common| 60 ++-
 sg-run-job|  5 
 ts-build-prep-freebsd |  5 +++-
 ts-xen-build-freebsd  | 19 ++
 5 files changed, 76 insertions(+), 19 deletions(-)
 create mode 100755 ts-xen-build-freebsd

diff --git a/make-freebsd-flight b/make-freebsd-flight
index 6c530ebe..d3c413b5 100755
--- a/make-freebsd-flight
+++ b/make-freebsd-flight
@@ -46,6 +46,12 @@ for arch in "$arches"; do
 freebsd_runvars="$freebsd_runvars freebsdbuildjob=build-$arch-freebsd \
  recipe_testinstall=true"
 create_freebsd_build_job build-$arch-freebsd-again
+
+# Create a Xen build job that's going to use the output from the first
+# FreeBSD build job.
+create_xen_build_job build-$arch-xen-freebsd build-xen-freebsd  \
+host_hostflags=arch-$arch,purpose-build all_host_os=freebsd \
+$freebsd_runvars
 done
 
 echo $flight
diff --git a/mfi-common b/mfi-common
index 74645259..54e1f62b 100644
--- a/mfi-common
+++ b/mfi-common
@@ -196,6 +196,30 @@ create_freebsd_build_job () {
 $freebsd_runvars
 }
 
+create_xen_build_job () {
+  local name=$1; shift
+  local recipe=$1; shift
+  local extra_runvars=$@; shift
+
+  job_create_build $name $recipe\
+arch=$arch enable_xend=$build_defxend enable_ovmf=$enable_ovmf  \
+enable_xsm=$enable_xsm $livepatch_runvars   \
+tree_qemu=$TREE_QEMU\
+tree_qemuu=$TREE_QEMU_UPSTREAM  \
+tree_xen=$TREE_XEN  \
+tree_seabios=$TREE_SEABIOS  \
+tree_ovmf=$TREE_OVMF\
+tree_minios=$TREE_MINIOS\
+revision_xen=$REVISION_XEN  \
+revision_qemu=$REVISION_QEMU\
+revision_qemuu=$REVISION_QEMU_UPSTREAM  \
+revision_seabios=$REVISION_SEABIOS  \
+

[Xen-devel] [PATCH v2 0/6] osstest: FreeBSD bugfixes and improvements

Hello,

The first 4 patches in this patch series prevent FreeBSD jobs from
running on boxes booting from UEFI. This is needed due to osstest lack
of support for installing FreeBSD from UEFI at the moment.

Last two patches add support for creating Xen build jobs running on
FreeBSD. Such a job is added to the FreeBSD flight and also to the Xen
flights.

The patches can also be found at:

git://xenbits.xen.org/people/royger/osstest.git freebsd_improvement_v2

Thanks, Roger.

Ian Jackson (1):
  osstest: allow appending to existing runvars

Roger Pau Monne (5):
  osstest: remove duplicate set_freebsd_runvars
  osstest: abstract code to create a FreeBSD build job
  osstest: limit FreeBSD jobs to hardware booting in BIOS mode
  osstest: set the make command to use for xen-build
  osstest: add FreeBSD Xen build job

 cs-job-create |  8 +++-
 make-flight   |  3 +-
 make-freebsd-flight   | 61 ++---
 mfi-common| 90 ---
 sg-run-job|  5 +++
 ts-build-prep-freebsd |  5 ++-
 ts-xen-build  | 11 +++---
 ts-xen-build-freebsd  | 19 +
 8 files changed, 121 insertions(+), 81 deletions(-)
 create mode 100755 ts-xen-build-freebsd

-- 
2.17.1


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

[Xen-devel] [PATCH v2 3/6] osstest: abstract code to create a FreeBSD build job

Into a helper. A diff of the runvars of flights generated with and
without the patch show no differences.

No functional change.

Signed-off-by: Roger Pau Monné 
---
 make-freebsd-flight | 24 +---
 mfi-common  | 14 ++
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/make-freebsd-flight b/make-freebsd-flight
index 1a2b359c..6c530ebe 100755
--- a/make-freebsd-flight
+++ b/make-freebsd-flight
@@ -38,28 +38,14 @@ job_create_build_filter_callback () {
 
 for arch in "$arches"; do
 set_freebsd_runvars
-job_create_build build-$arch-freebsd build-freebsd  \
-arch=$arch  \
-$RUNVARS $BUILD_RUNVARS $BUILD_FREEBSD_RUNVARS  \
-$arch_runvars   \
-tree_freebsd=$TREE_FREEBSD  \
-revision_freebsd=$REVISION_FREEBSD  \
-host_hostflags=arch-$arch,purpose-build \
-all_host_os=freebsd \
-$freebsd_runvars
+
+create_freebsd_build_job build-$arch-freebsd
 
 # Create an identical job that's going to use the build output from
 # the previous one.
-job_create_build build-$arch-freebsd-again build-freebsd\
-arch=$arch  \
-$RUNVARS $BUILD_RUNVARS $BUILD_FREEBSD_RUNVARS  \
-$arch_runvars   \
-tree_freebsd=$TREE_FREEBSD  \
-revision_freebsd=$REVISION_FREEBSD  \
-host_hostflags=arch-$arch,purpose-build \
-all_host_os=freebsd \
-freebsdbuildjob=build-$arch-freebsd \
-recipe_testinstall=true
+freebsd_runvars="$freebsd_runvars freebsdbuildjob=build-$arch-freebsd \
+ recipe_testinstall=true"
+create_freebsd_build_job build-$arch-freebsd-again
 done
 
 echo $flight
diff --git a/mfi-common b/mfi-common
index 9b6c9470..0e6cf01e 100644
--- a/mfi-common
+++ b/mfi-common
@@ -174,6 +174,20 @@ set_freebsd_runvars () {
 fi
 }
 
+create_freebsd_build_job () {
+  local name=$1
+
+  job_create_build $name build-freebsd  \
+arch=$arch  \
+$RUNVARS $BUILD_RUNVARS $BUILD_FREEBSD_RUNVARS  \
+$arch_runvars   \
+tree_freebsd=$TREE_FREEBSD  \
+revision_freebsd=$REVISION_FREEBSD  \
+host_hostflags=arch-$arch,purpose-build \
+all_host_os=freebsd \
+$freebsd_runvars
+}
+
 create_build_jobs () {
 
   local arch
-- 
2.17.1


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  broken
 test-armhf-armhf-xl   4 host-install(4)broken REGR. vs. 124232
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 124232
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 16 
depriv-audit-qemu/create/privcmd running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 16 
depriv-audit-qemu/create/privcmd running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 17 
depriv-audit-qemu/create/gntdev running
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 17 
depriv-audit-qemu/create/gntdev running
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 18 
depriv-audit-qemu/create/evtchn running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 18 
depriv-audit-qemu/create/evtchn running
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 19 
depriv-audit-qemu/create/other running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 19 
depriv-audit-qemu/create/other running
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 20 
depriv-audit-qemu/create/xenstore running
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 20 
depriv-audit-qemu/create/xenstore running

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 124232
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 124232
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 124232
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 124232
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 124232
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 124232
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 15 
depriv-audit-qemu/create fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 15 
depriv-audit-qemu/create fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop

[Xen-devel] [PATCH] xen: oprofile/nmi_int.c: Drop unwanted sexual reference

This is not really very nice.

I don't understand the technical details here but `violence' is
probably fair.  The word `violence' is often used metaphorically in a
technical context so I think it's probably OK for use in this way.

IMO this patch should be backported to all maintained trees.

Signed-off-by: Ian Jackson 
---
 xen/arch/x86/oprofile/nmi_int.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/oprofile/nmi_int.c b/xen/arch/x86/oprofile/nmi_int.c
index d8f5230..cc36827 100644
--- a/xen/arch/x86/oprofile/nmi_int.c
+++ b/xen/arch/x86/oprofile/nmi_int.c
@@ -182,7 +182,7 @@ int nmi_reserve_counters(void)
if (!allocate_msrs())
return -ENOMEM;
 
-   /* We walk a thin line between law and rape here.
+   /* We walk a thin line between law and violence here.
 * We need to be careful to install our NMI handler
 * without actually triggering any NMIs as this will
 * break the core code horrifically.
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 4/8] x86/AMD: distinguish compute units from hyper-threads

>>> On 12.07.18 at 15:02,  wrote:
> On 11/07/18 13:07, Jan Beulich wrote:
>> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
>> the difference is not very big. The most relevant change (requiring some
>> code restructuring) is that the topoext feature no longer means there is
>> a valid CU ID.
>>
>> Take the opportunity and convert wrongly plain int variables in
>> set_cpu_sibling_map() to unsigned int.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -504,17 +504,23 @@ static void amd_get_topology(struct cpui
>>  u32 eax, ebx, ecx, edx;
>>  
>>  cpuid(0x801e, , , , );
>> -c->compute_unit_id = ebx & 0xFF;
>>  c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1;
>> +
>> +if (c->x86 < 0x17)
>> +c->compute_unit_id = ebx & 0xFF;
>> +else {
>> +c->cpu_core_id = ebx & 0xFF;
>> +c->x86_max_cores /= c->x86_num_siblings;
>> +}
> 
> The indentation here is odd.  It turns out the function uses entirely
> 8-spaces rather than tabs, like the rest of the file.

Ouch - didn't notice this.

> Would you mind either retaining spaces, or fixing up the entire function
> (probably easiest as a prereq patch) ?

I'll fix this up here, not in a prereq patch (for backporting's sake).
I'll consider adding a follow-up patch.

Jan



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

[Xen-devel] Xen 4.8.4 released

All,

I am pleased to announce the release of Xen 4.8.4. This is
available immediately from its git repository
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 
(tag RELEASE-4.8.4) or from the XenProject download page
http://www.xenproject.org/downloads/xen-archives/xen-project-48-series/xen-484.html
 
(where a list of changes can also be found).

We recommend all users of the 4.8 stable series to update to this
latest point release.

Regards, Jan



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

Re: [Xen-devel] [PATCH] automation/build: build ovmf

On Wed, Jul 11, 2018 at 02:16:16PM +0100, Wei Liu wrote:
> Install nasm and build ovmf with gcc on x86.
> 
> Signed-off-by: Wei Liu 
> ---

Acked-by: Doug Goldstein 

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

[Xen-devel] [PATCH] scripts: add helper script to use Docker containers

This adds a script that can be used to do builds easily within the
defined containers under the automation directory. These containers live
in the public GitLab registry under the xen-project namespace. The
script can be executed a number of ways but the default is to drop you
at a bash shell within a Debian Stretch container at the top level of
the source tree.

Signed-off-by: Doug Goldstein 
---
A few folks have asked about this so I'm CCing folks directly. I'm
completely game for changing anything that makes this easier for folks
to use. This is primarily geared as a developer/maintainer tool but
its also good for folks just starting out with Xen and not having
all the dependencies installed.

CC: Andrew Cooper 
CC: George Dunlap 
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Wei Liu 
---
 automation/build/README.md  | 53 ---
 automation/scripts/containerize | 93 ++-
 2 files changed, 138 insertions(+), 8 deletions(-)
 create mode 100755 automation/scripts/containerize

diff --git a/automation/build/README.md b/automation/build/README.md
index 0206d57..be4526c 100644
--- a/automation/build/README.md
+++ b/automation/build/README.md
@@ -5,9 +5,12 @@ These Docker containers should make it possible to build Xen in
 any of the available environments on any system that supports
 running Docker. They are organized by distro and tagged with
 the version of that distro. They are available from the GitLab
-Container Registry under the Xen project at:
+Container Registry under the Xen project at the [registry] and
+can be pulled with Docker from the following path:
 
-registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
+docker pull registry.gitlab.com/xen-project/xen/DISTRO:VERSION
+```
 
 To see the list of available containers run `make` in this
 directory. You will have to replace the `/` with a `:` to use
@@ -19,16 +22,50 @@ Building Xen
 From the top level of the source tree it should be possible to
 run the following:
 
-docker run --rm -it -v $(PWD):/build -u $(id -u) -e CC=gcc $(CONTAINER) make
+```
+./automation/scripts/containerize make
+```
 
-There are other modifications that can be made but this will run
-the `make` command inside the specified container. It will use your
-currently checked out source tree to build with, ensure that file
-permissions remain consistent and clean up after itself.
+Which will cause the top level `make` to execute within the default
+container, which is currently defined as Debian Stretch. Any arguments
+specified to the script will be executed within the container from
+the default shell.
+
+There are several environment variables which the containerize script
+understands.
+
+- CONTAINER: This overrides the container to use. For CentOS 7.2, use:
+
+  ```
+  CONTAINER=centos72 ./automation/scripts/containerize make
+  ```
+
+- WORKDIR: This overrides the path that will be available under the
+  `/build` directory in the container, which is the default path.
+
+  ```
+  WORKDIR=/some/other/path ./automation/scripts/containerize ls
+  ```
+
+- XEN_CONFIG_EXPERT: If this is defined in your shell it will be
+  automatically passed through to the container.
+
+- CONTAINER_NAME: By default the container name is set based on the
+  container itself so that its easy to attach other terminals to your
+  container. This however prevents you from running multiple containers
+  of the same version. Override the name value to cause it to name
+  the container differently on start.
+
+- EXTRA_CONTAINER_ARGS: Allows you to pass extra arguments to Docker
+  when starting the container.
 
 Building a container
 
 
 There is a makefile to make this process easier. You should be
 able to run `make DISTRO/VERSION` to have Docker build the container
-for you.
+for you. If you define the `PUSH` environment variable when running the
+former `make` command, it will push the container to the [registry] if
+you have access to do so.
+
+[registry]: https://gitlab.com/xen-project/xen/container_registry
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
new file mode 100755
index 000..7253617
--- /dev/null
+++ b/automation/scripts/containerize
@@ -0,0 +1,93 @@
+#!/bin/bash
+
+einfo() {
+   echo "$*" >&2
+}
+
+die() {
+echo "$*" >&2
+exit 1
+}
+
+#
+# The caller is expected to override the CONTAINER environment
+# variable with the container they wish to launch.
+#
+BASE="registry.gitlab.com/xen-project/xen"
+case "_${CONTAINER}" in
+_centos72) CONTAINER="${BASE}/centos:7.2" ;;
+_trusty) CONTAINER="${BASE}/ubuntu:trusty" ;;
+_xenial) CONTAINER="${BASE}/ubuntu:xenial" ;;
+_jessie) CONTAINER="${BASE}/debian:jessie" ;;
+_stretch|_) CONTAINER="${BASE}/debian:stretch" ;;
+esac
+
+# get our container name and version
+containid=${CONTAINER%:*}
+containver=${CONTAINER#*:}
+
+# Save the commands for future use
+cmd=$@
+
+# If no command was specified, just drop us into

Re: [Xen-devel] x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

John,
Thank you. I have notes and slides for SGX, which are already published and 
Intel Processor Trace (just the slides – already published, but I am not sure 
whether these already were updated to reflect the design discussion) and 
EPT-Based Sub-Page Protection (just the slides – already published)
Lars

From: "Ji, John" 
Date: Thursday, 12 July 2018 at 13:33
To: Lars Kurth , xen-devel 

Cc: "committ...@xenproject.org" , Tamas K Lengyel 
, intel-xen , 
"daniel.ki...@oracle.com" , Roger Monne 
, Christopher Clark , Rich 
Persaud , Brian Woods , Stefano 
Stabellini , Julien Grall , 
Juergen Gross 
Subject: RE: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

I will Yu and Yi to send out discussion notes.

>>### Add vNVDIMM support to HVM domains
>>Stakeholders: Zhang Yi, Intel, Zhang Yu, Intel, George Dunlap, Citrix ``` _As 
>>far as I understand a simple and clean way to implement this has been found, 
>>but the design session notes are still missing_

>>_We spent almost two days on NVDIMM related discussions: we have something 
>>that should be fairly simple and easy to implement. Dan Williams is happy to 
>>take changes into upstream as long as they are sensible._

Best Regards

John Ji

-Original Message-
From: Lars Kurth [mailto:lars.ku...@citrix.com]
Sent: Thursday, July 12, 2018 5:07 PM
To: xen-devel 
Cc: committ...@xenproject.org; Tamas K Lengyel ; 
intel-xen ; daniel.ki...@oracle.com; Roger Pau Monne 
; Christopher Clark ; Rich 
Persaud ; Brian Woods ; Stefano 
Stabellini ; Julien Grall ; 
Juergen Gross 
Subject: Re: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

Also attached minutes as PDF and Markdown

# Agenda and Minutes: x86 Community Call July 2018

_No new items were added to the agenda._  _Minutes are added in blue (in the 
PDF only)_

## Attendees

Lars Kurth, Citrix
Roger Pau Monne, Citrix
Juergen Gross, Suse
Jan Beulich, Suse
Christopher Clark, OpenXT
Janakarajan Natarajan, AMD
Brian Woods, AMD
Rich Persaud, OpenXT
George Dunlap, Citrix
Wei, Andy, Paul - Citrix

## Release Cadence for Xen 4.12

Following the release cadence session at the developer summit (see 
https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00166
 & 
https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/
edit) we have to make a decision whether
* Go on as we are for 4.
* Move to 9 months, until we fixed the underlying issues as outlined in the 
thread and
write-up: the problem is that unless we get some sort of commitment to address 
the issues, just changing the release cadence will not make a difference
* Skip a release as a one-off: Set ourselves some goals that must be achieved 
in this cycle around testing - this will need some commitment from vendors

I was planning to allocate up to 30 minutes to this discussion

Juergen: raises the point that keeping the release cadence at 6 months is very 
unfair on Jan who has raised many times that the workload resulting from having 
to maintain so many release branches would be too high. After running 6 monthly 
releases for some time, this has in fact come true, when at the time Jan’s 
concerns were dismissed. The overhead breaks down into backporting fixes, 
backporting security fixes and dealing with the release mechanics.

Jan: raised the point that hardly anyone responds to calls for back-ports and 
if so, only send change-sets and lat Jan do the backporting. Jan also says he 
suspects that people may not respond to backport requests, because that would 
require them to backport the patches.

George: points out that unless he remembers at the time he writes or reviews a 
patch, whether it is back-port worthy.

George and Andrew raised the idea that we could maintain a list of pending 
backports and assign backport tasks to people.

Jan: maintaining releases as a single person is the most efficient way of doing 
it. A single person doing all trees is most efficient, but then we need to 
restrict the number of trees. And
2 releases per year are too many.

Andrew: suggests that an even/odd releases model with different support cycles 
would solve this. By doing this, we would retain the discipline of doing 
releases.

Juergen: this would however impose the release overhead

Andrew: agrees that we need to reduce our release overhead regardless, but this 
issue is orthogonal from the release cadence.

**Staying at 6 months we would either have to find someone who would like to 
carry the maintenance load, or move to a longer cadence. Also we need to make 
it clear that reducing the release overhead is independent from release cadence 
and process. We should be doing this irrespective depending on the cadence.**

Juergen: We could l **ook at 8 months (instead of 9)it is better from a 
scheduling perspective (working around public holidays).**  With an 8 month 
release cycle, the release occurs at only 3 different dates during the calendar 
year, rather than the 4 dates with

[Xen-devel] [ovmf baseline-only test] 74959: all pass

2018-07-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 74959 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74959/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1
baseline version:
 ovmf c6a14de3ef30291918f3b15436cf6a75db413eea

Last test of basis74956  2018-07-11 11:56:44 Z1 days
Testing same since74959  2018-07-12 05:24:33 Z0 days1 attempts


People who touched revisions under test:
  Gary Lin 
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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


Push not applicable.


commit 895b87e38015e0698c6a5c0633e0156b038a56f1
Author: Jiaxin Wu 
Date:   Mon Jul 2 09:48:12 2018 +0800

NetworkPkg/HttpDxe: Fix the bug when parsing HTTP(S) message body.

*v2: Resolve the conflict commit.

*v3: Fixed the failure if BodyLength in HTTP token is less than the received
size of HTTPS message.

HttpBodyParserCallback function is to parse the HTTP(S) message body so as 
to
confirm whether there is the next message header. But it doesn't record the
parsing message data/length correctly.

This patch is refine the parsing logic so as to fix the potential failure.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Gary Lin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Fu Siyuan 
Reviewed-by: Ye Ting 
Tested-by: Gary Lin 

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

[Xen-devel] [linux-linus test] 125069: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  4 memdisk-try-append   fail REGR. vs. 123554
 test-armhf-armhf-examine  8 reboot   fail REGR. vs. 123554
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-xl-cubietruck  7 xen-boot   fail REGR. vs. 123554
 test-armhf-armhf-libvirt-raw  7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-xl-credit2   7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-xl-xsm   7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-libvirt  7 xen-boot fail REGR. vs. 123554
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 123554

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

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

version targeted for testing:
 linux1e4b044d22517cae7047c99038abb23243ca
baseline version:
 linux0512e0134582ef85dee77d51aae77dcd1edec495

Last test of basis   123554  2018-06-01 13:09:41 Z   40 days
Failing since123655  2018-06-03 01:45:35 Z   39 days   23 attempts
Testing same since   125069  2018-07-09 23:23:08 Z2 days1 attempts


2220 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH 4/8] x86/AMD: distinguish compute units from hyper-threads

On 11/07/18 13:07, Jan Beulich wrote:
> Fam17 replaces CUs by HTs, which we should reflect accordingly, even if
> the difference is not very big. The most relevant change (requiring some
> code restructuring) is that the topoext feature no longer means there is
> a valid CU ID.
>
> Take the opportunity and convert wrongly plain int variables in
> set_cpu_sibling_map() to unsigned int.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -504,17 +504,23 @@ static void amd_get_topology(struct cpui
>  u32 eax, ebx, ecx, edx;
>  
>  cpuid(0x801e, , , , );
> -c->compute_unit_id = ebx & 0xFF;
>  c->x86_num_siblings = ((ebx >> 8) & 0x3) + 1;
> +
> + if (c->x86 < 0x17)
> + c->compute_unit_id = ebx & 0xFF;
> + else {
> + c->cpu_core_id = ebx & 0xFF;
> + c->x86_max_cores /= c->x86_num_siblings;
> + }

The indentation here is odd.  It turns out the function uses entirely
8-spaces rather than tabs, like the rest of the file.

Would you mind either retaining spaces, or fixing up the entire function
(probably easiest as a prereq patch) ?

Otherwise LGTM.

~Andrew

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

Re: [Xen-devel] [PATCH 3/8] allow cpu_down() to be called earlier

On 11/07/18 13:06, Jan Beulich wrote:
> The function's use of the stop-machine logic has so far prevented its
> use ahead of the processing of the "ordinary" initcalls. Since at this
> early time we're in a controlled environment anyway, there's no need for
> such a heavy tool. Additionally this ought to have less of a performance
> impact especially on large systems, compared to the alternative of
> making stop-machine functionality available earlier.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 2/8] x86: distinguish CPU offlining from CPU removal

On 11/07/18 13:06, Jan Beulich wrote:
> In order to be able to service #MC on offlined CPUs, GDT, IDT, stack,

For clarity, I'd phrase this as "CPUs, the GDT, ..." to help visually
separate CPUs as it isn't a part of the rest of the list.

> --- a/xen/arch/x86/genapic/x2apic.c
> +++ b/xen/arch/x86/genapic/x2apic.c
> @@ -201,18 +201,25 @@ static int update_clusterinfo(
>  if ( !cluster_cpus_spare )
>  cluster_cpus_spare = xzalloc(cpumask_t);
>  if ( !cluster_cpus_spare ||
> - !alloc_cpumask_var(_cpu(scratch_mask, cpu)) )
> + !cond_alloc_cpumask_var(_cpu(scratch_mask, cpu)) )
>  err = -ENOMEM;
>  break;
>  case CPU_UP_CANCELED:
>  case CPU_DEAD:
> +case CPU_REMOVE:
> +if ( park_offline_cpus == (action != CPU_REMOVE) )
> +break;
>  if ( per_cpu(cluster_cpus, cpu) )
>  {
>  cpumask_clear_cpu(cpu, per_cpu(cluster_cpus, cpu));
>  if ( cpumask_empty(per_cpu(cluster_cpus, cpu)) )
> +{
>  xfree(per_cpu(cluster_cpus, cpu));
> +per_cpu(cluster_cpus, cpu) = NULL;
> +}
>  }
>  free_cpumask_var(per_cpu(scratch_mask, cpu));
> +clear_cpumask_var(_cpu(scratch_mask, cpu));

freeing and NULL-ing the pointer at the same time is already a common
pattern  How about introducing

/* Free an allocation, and zero the pointer to it. */
#define XFREE(p)
({
    typeof(*p) *_p = (p);

    xfree(_p);
    _p = NULL;
})

and a similar wrapper for FREE_CPUMASK_VAR(p) which takes care of the
NULL-ing as well?

In time as these start to get used more widely, it should reduce the
chances of double-freeing in cleanup paths.

> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
>  cpumask_t cpu_online_map __read_mostly;
>  EXPORT_SYMBOL(cpu_online_map);
>  
> +bool __read_mostly park_offline_cpus;
> +
>  unsigned int __read_mostly nr_sockets;
>  cpumask_t **__read_mostly socket_cpumask;
>  static cpumask_t *secondary_socket_cpumask;
> @@ -887,7 +889,7 @@ static void cleanup_cpu_root_pgt(unsigne
>  }
>  }
>  
> -static void cpu_smpboot_free(unsigned int cpu)
> +static void cpu_smpboot_free(unsigned int cpu, bool all)

Perhaps "remove" or "remove_cpu", to match the CPU_REMOVE terminology?

Also, we probably want a comment here explaining the difference between
parking and removing in terms of what infrastructure needs to remain valid.

~Andrew

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

Re: [Xen-devel] Xen for Automotive - white paper on virtualization

2018-07-12 Thread Rich Persaud

Thanks to everyone who contributed to the AGL virtualization white paper and to 
Michele Paolino for stewarding it from concept to final publication.   I’ve 
added it to the Xen wiki:

https://wiki.xenproject.org/wiki/Automotive_Whitepapers

Rich___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

2018-07-12 Thread Ji, John

I will Yu and Yi to send out discussion notes.

>>### Add vNVDIMM support to HVM domains
>>Stakeholders: Zhang Yi, Intel, Zhang Yu, Intel, George Dunlap, Citrix ``` _As 
>>far as I understand a simple and clean way to implement this has been found, 
>>but the design session notes are still missing_

>>_We spent almost two days on NVDIMM related discussions: we have something 
>>that should be fairly simple and easy to implement. Dan Williams is happy to 
>>take changes into upstream as long as they are sensible._



Best Regards

John Ji


-Original Message-
From: Lars Kurth [mailto:lars.ku...@citrix.com]
Sent: Thursday, July 12, 2018 5:07 PM
To: xen-devel 
Cc: committ...@xenproject.org; Tamas K Lengyel ; 
intel-xen ; daniel.ki...@oracle.com; Roger Pau Monne 
; Christopher Clark ; Rich 
Persaud ; Brian Woods ; Stefano 
Stabellini ; Julien Grall ; 
Juergen Gross 
Subject: Re: x86 Community Call - Wed July 11, 14:00 - 15:00 UTC - Minutes

Also attached minutes as PDF and Markdown

# Agenda and Minutes: x86 Community Call July 2018

_No new items were added to the agenda._  _Minutes are added in blue (in the 
PDF only)_

## Attendees

Lars Kurth, Citrix
Roger Pau Monne, Citrix
Juergen Gross, Suse
Jan Beulich, Suse
Christopher Clark, OpenXT
Janakarajan Natarajan, AMD
Brian Woods, AMD
Rich Persaud, OpenXT
George Dunlap, Citrix
Wei, Andy, Paul - Citrix

## Release Cadence for Xen 4.12

Following the release cadence session at the developer summit (see 
https://lists.xenproject.org/archives/html/xen-devel/2018-07/threads.html#00166
 & 
https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/
edit) we have to make a decision whether
* Go on as we are for 4.
* Move to 9 months, until we fixed the underlying issues as outlined in the 
thread and
write-up: the problem is that unless we get some sort of commitment to address 
the issues, just changing the release cadence will not make a difference
* Skip a release as a one-off: Set ourselves some goals that must be achieved 
in this cycle around testing - this will need some commitment from vendors

I was planning to allocate up to 30 minutes to this discussion

Juergen: raises the point that keeping the release cadence at 6 months is very 
unfair on Jan who has raised many times that the workload resulting from having 
to maintain so many release branches would be too high. After running 6 monthly 
releases for some time, this has in fact come true, when at the time Jan’s 
concerns were dismissed. The overhead breaks down into backporting fixes, 
backporting security fixes and dealing with the release mechanics.

Jan: raised the point that hardly anyone responds to calls for back-ports and 
if so, only send change-sets and lat Jan do the backporting. Jan also says he 
suspects that people may not respond to backport requests, because that would 
require them to backport the patches.

George: points out that unless he remembers at the time he writes or reviews a 
patch, whether it is back-port worthy.

George and Andrew raised the idea that we could maintain a list of pending 
backports and assign backport tasks to people.

Jan: maintaining releases as a single person is the most efficient way of doing 
it. A single person doing all trees is most efficient, but then we need to 
restrict the number of trees. And
2 releases per year are too many.

Andrew: suggests that an even/odd releases model with different support cycles 
would solve this. By doing this, we would retain the discipline of doing 
releases.

Juergen: this would however impose the release overhead

Andrew: agrees that we need to reduce our release overhead regardless, but this 
issue is orthogonal from the release cadence.

**Staying at 6 months we would either have to find someone who would like to 
carry the maintenance load, or move to a longer cadence. Also we need to make 
it clear that reducing the release overhead is independent from release cadence 
and process. We should be doing this irrespective depending on the cadence.**

Juergen: We could l **ook at 8 months (instead of 9)it is better from a 
scheduling perspective (working around public holidays).**  With an 8 month 
release cycle, the release occurs at only 3 different dates during the calendar 
year, rather than the 4 dates with a 9 month cycle. This makes planning easier 
for selecting dates that avoid public holidays. 8 months is also closer to the 
6 month cycle for those preferring shorter cadence. An 8 month cycle would not 
increase the number of concurrently supported branches when compared with a 9 
month cycle.

**ACTION: George will put together a survey for the committers outlining the 
issue and trade-offs and then go from there**

## Project Management stuff to keep the Momentum going

We have made significant progress on design related questions at the developer 
summit.
Although not all the notes for these have been published (SGX and NVDIMM are 
missing, the former are on my plate).

Re: [Xen-devel] [PATCH v2] drm: Replace NULL with error value in drm_prime_pages_to_sg

2018-07-12 Thread Dan Carpenter

On Thu, Jul 12, 2018 at 02:58:00PM +0300, Oleksandr Andrushchenko wrote:
> On 06/18/2018 03:32 PM, Oleksandr Andrushchenko wrote:
> > On 06/18/2018 03:29 PM, Dan Carpenter wrote:
> > > On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:
> > > > drivers/gpu/drm/drm_gem_cma_helper.c    | 2 +-
> > > >   drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
> > > >   2 files changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > > > b/drivers/gpu/drm/drm_gem_cma_helper.c
> > > > index 80a5115c3846..ce868ce288fb 100644
> > > > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > > > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > > > @@ -436,7 +436,7 @@ struct sg_table
> > > > *drm_gem_cma_prime_get_sg_table(struct drm_gem_object *obj)
> > > >     sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
> > > >   if (!sgt)
> > > > -    return NULL;
> > > > +    return ERR_PTR(-ENOMEM);
> > > >     ret = dma_get_sgtable(obj->dev->dev, sgt, cma_obj->vaddr,
> > > >     cma_obj->paddr, obj->size);
> > > 
> > > If dma_get_sgtable() fails then we return NULL.
> > > 
> > > Fix that and it should be good.
> > You mean I can put your r-b with that fixed?
> ping

Yeah.  Send the v2 patch and I'll review it.

regards,
dan carpenter


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

[Xen-devel] [ovmf test] 125124: all pass - PUSHED

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 0a563f3fecfd9baffe8dce51bb4411d6a748a936
baseline version:
 ovmf c563077a380437c114aba4c95be65eb963ebc1f3

Last test of basis   125122  2018-07-12 05:10:44 Z0 days
Testing same since   125124  2018-07-12 08:10:41 Z0 days1 attempts


People who touched revisions under test:
  Bob Feng 
  bob.c.f...@intel.com 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   c563077a38..0a563f3fec  0a563f3fecfd9baffe8dce51bb4411d6a748a936 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH] tools: remove local links to the x86 headers

>>> On 12.07.18 at 12:40,  wrote:
> --- a/tools/include/Makefile
> +++ b/tools/include/Makefile
> @@ -21,6 +21,9 @@ xen/.dir:
>   ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
> xen/libelf/
>   ln -s ../xen-foreign xen/foreign
>   ln -sf $(XEN_ROOT)/xen/include/acpi acpi
> +ifeq ($(CONFIG_X86),y)
> + ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
> +endif

Don't you need a .gitignore adjustment for this?

> --- a/tools/tests/x86_emulator/Makefile
> +++ b/tools/tests/x86_emulator/Makefile
> @@ -118,7 +118,7 @@ $(TARGET): x86-emulate.o test_x86_emulator.o wrappers.o
>  
>  .PHONY: clean
>  clean:
> - rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
> x86_emulate 
> asm
> + rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
> x86_emulate
>  
>  .PHONY: distclean
>  distclean: clean
> @@ -131,17 +131,11 @@ x86_emulate:
>  
>  x86_emulate/%: x86_emulate ;
>  
> -asm:
> - [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
> -
> -asm/%: asm ;
> -
>  HOSTCFLAGS-x86_64 := -fno-PIE
>  $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
>  HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
>  
> -x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
> -x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
> +x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h

While removing this dependency in the fuzzer case looks to be fine, it
clearly isn't here: No .*.d get generated, so a change to any of those
files would now no longer trigger a re-build.

Jan



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

Re: [Xen-devel] [PATCH v2] drm: Replace NULL with error value in drm_prime_pages_to_sg

2018-07-12 Thread Oleksandr Andrushchenko


On 06/18/2018 03:32 PM, Oleksandr Andrushchenko wrote:

On 06/18/2018 03:29 PM, Dan Carpenter wrote:

On Mon, Jun 18, 2018 at 09:07:09AM +0300, Oleksandr Andrushchenko wrote:

drivers/gpu/drm/drm_gem_cma_helper.c    | 2 +-
  drivers/gpu/drm/xen/xen_drm_front_gem.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c

index 80a5115c3846..ce868ce288fb 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -436,7 +436,7 @@ struct sg_table 
*drm_gem_cma_prime_get_sg_table(struct drm_gem_object *obj)

    sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
  if (!sgt)
-    return NULL;
+    return ERR_PTR(-ENOMEM);
    ret = dma_get_sgtable(obj->dev->dev, sgt, cma_obj->vaddr,
    cma_obj->paddr, obj->size);


If dma_get_sgtable() fails then we return NULL.

Fix that and it should be good.

You mean I can put your r-b with that fixed?

ping

regards,
dan carpenter






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

Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols

>>> On 12.07.18 at 13:37,  wrote:
> On 11/07/18 16:34, Roger Pau Monne wrote:
>> And replace the open-coded versions already in tree. No functional
>> change.
>>
>> Signed-off-by: Roger Pau Monné 
>> ---
>> Cc: Jan Beulich 
>> Cc: Andrew Cooper 
>> Cc: Daniel Kiper 
>> ---
>>  xen/include/xen/compiler.h  | 2 ++
>>  xen/include/xen/livepatch_payload.h | 4 ++--
>>  2 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>> index a7e05681c9..001f589655 100644
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -18,6 +18,8 @@
>>  
>>  #define __packed  __attribute__((__packed__))
>>  
>> +#define __weak__attribute__((weak))
> 
> __week__  (can be fixed on commit)

Oh, indeed, as long as you mean __weak__.

> Otherwise, Reivewed-by: Andrew Cooper 

Jan


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

Re: [Xen-devel] [PATCH v3 3/3] xen/x86: declare the efi symbol as weak

>>> On 12.07.18 at 13:35,  wrote:
> On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
>> This allows removing the DEFINED conditional in the linker script, and
>> fixes compilation with lld:
> 
> s/lld/LLVM linker/?
> 
> Could you mention the version of LLVM linker in the commit message?
> And I am still not sure why do you insist on this patch series.
> IIRC you have told us that both issues will be fixed in LLVM.
> 
>> ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
>> /root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
>> ld: error: xen.lds:233: symbol not found: efi
>>
>> Signed-off-by: Roger Pau Monné 
> 
> With this patch applied ld from binutils 2.22 complains in this way:
> 
> ld-melf_x86_64  -T xen.lds -N prelink.o --build-id=sha1 \
> xen/common/symbols-dummy.o -o xen/.xen-syms.0
> prelink.o: In function `acpi_os_get_root_pointer':
> xen/drivers/acpi/osl.c:73:(.init.text+0x192e9): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> xen/drivers/acpi/osl.c:75:(.init.text+0x192f6): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> prelink.o: In function `efi_check_config':
> xen/arch/x86/mpparse.c:702:(.init.text+0x238ce): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/mpparse.c:706:(.init.text+0x238f2): relocation truncated to fit: 
> R_X86_64_PC32 against undefined symbol `efi'
> prelink.o: In function `dmi_efi_iterate':
> xen/arch/x86/dmi_scan.c:377:(.init.text+0x3666f): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:391:(.init.text+0x366d7): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:400:(.init.text+0x36735): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'
> xen/arch/x86/dmi_scan.c:414:(.init.text+0x367b1): relocation truncated to 
> fit: R_X86_64_PC32 against undefined symbol `efi'

Oh, I could indeed have thought of this risk.

Jan


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

Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary

>>> On 12.07.18 at 12:52,  wrote:
> On Wed, Jul 11, 2018 at 06:26:23AM -0600, Jan Beulich wrote:
>> >>> On 11.07.18 at 13:41,  wrote:
>> > On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
>> >> >>> On 10.07.18 at 12:48,  wrote:
>> >> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote:
>> >> >> >>> On 06.07.18 at 16:02,  wrote:
>> >> >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote:
>> >> >> >> >>> On 04.07.18 at 18:35,  wrote:
>> >> >> >> > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote:
>> >> >> >> >> >>> On 04.07.18 at 16:01,  wrote:
>> >> >> >> >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote:
>> >> >> >> >> >> >>> On 19.06.18 at 16:35,  wrote:
>> >> >> >> >> >> > @@ -582,6 +587,12 @@ static void __init 
>> >> >> >> >> >> > efi_arch_memory_setup(void)
>> >> >> >> >> >> >  if ( !efi_enabled(EFI_LOADER) )
>> >> >> >> >> >> >  return;
>> >> >> >> >> >> >
>> >> >> >> >> >> > +if ( efi_enabled(EFI_MB_LOADER) )
>> >> >> >> >> >> > +for ( pte = __page_tables_start; pte < 
>> >> >> >> >> >> > __page_tables_end;
>> >> >> >> >> >> > +  pte += ( pte != (intpte_t *)l2_identmap ) ? 
>> >> >> >> >> >> > 1 : 4 * 
> L2_PAGETABLE_ENTRIES )
>> >> >> >> >> >>
>> >> >> >> >> >> Please avoid explicit casts - _get_intpte(l2_identmap[0]) 
>> >> >> >> >> >> or
>> >> >> >> >> >> something along those lines ought to work here. Same for
>> >> >> >> >> >> 4 * L2_PAGETABLE_ENTRIES - you mean ARRAY_SIZE() there.
>> >> >> >> >> >
>> >> >> >> >> > OK.
>> >> >> >> >> >
>> >> >> >> >> >> Also this whole code block needs a comment, to explain what it
>> >> >> >> >> >> does and also why l2_identmap needs skipping.
>> >> >> >> >> >>
>> >> >> >> >> >> Furthermore - isn't this off by one, and you process 
>> >> >> >> >> >> l2_identmap[0]
>> >> >> >> >> >> this way, skipping the rest _plus_ the first following entry? 
>> >> >> >> >> >> I think
>> >> >> >> >> >
>> >> >> >> >> > The code mimics similar code in head.S.
>> >> >> >> >>
>> >> >> >> >> I can't see a similar off-by-1 in head.S.
>> >> >> >> >
>> >> >> >> >  662 /*
>> >> >> >> >  663  * Update frame addresses in page tables excluding 
> l2_identmap
>> >> >> >> >  664  * without its first entry which points to 
>> >> >> >> > l1_identmap.
>> >> >> >> >  665  */
>> >> >> >> >  666 mov 
>> >> >> >> > $((__page_tables_end-__page_tables_start)/8),%ecx
>> >> >> >> >  667 mov 
>> >> >> >> > $(((l2_identmap-__page_tables_start)/8)+1),%edx
>> >> >> >> >  668 1:  cmp 
> $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
>> >> >> >> >  669 cmove   %edx,%ecx
>> >> >> >> >  670 testl   
> $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
>> >> >> >> >  671 jz  2f
>> >> >> >> >  672 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
>> >> >> >> >  673 2:  loop1b
>> >> >> >>
>> >> >> >> Well - this is the code in question, but you fail to point out where
>> >> >> >> the off-by-1 is.
>> >> >> >
>> >> >> > Line 667, 668 and 669.
>> >> >>
>> >> >> I don't think so, no. Note the -8 in lines 670 and 672.
>> >> >
>> >> > However, you are missing +1 in line 667.
>> >>
>> >> I don't think I am: The first entry of l2_identmap actually needs
>> >> processing afaics (and as the comment says), as that's the only one
>> >> with non-absolute contents. IOW - part of my original comment was
>> >> wrong, but the other half (you skipping one entry) still seems
>> >> applicable, as does the part concerning the missing comment.
>> >
>> > It seems correct to me. l2_identmap[0] gets updated and then
>> > we move to l3_bootmap[0]. Am I missing something?
>>
>> Hmm, yes, I think you're right. But the way you've coded it it's
>> less obvious than in the assembly variant, and typically it should
>> be the other way around. I'd really like you to make this a closer
>> match.
> 
> Do you suggest that we should do that backwards as we do in ASM?
> Or anything else?

The closer the match, the better imo. I wouldn't insist on it being
done backwards though, unless there's a particular reason for that.

Jan


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

Re: [Xen-devel] [PATCH 2/8] x86: distinguish CPU offlining from CPU removal

>>> On 12.07.18 at 12:53,  wrote:
> On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
> [...]
>> --- a/xen/arch/x86/smpboot.c
>> +++ b/xen/arch/x86/smpboot.c
>> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
>>  cpumask_t cpu_online_map __read_mostly;
>>  EXPORT_SYMBOL(cpu_online_map);
>>  
>> +bool __read_mostly park_offline_cpus;
>> +
>>  unsigned int __read_mostly nr_sockets;
>>  cpumask_t **__read_mostly socket_cpumask;
>>  static cpumask_t *secondary_socket_cpumask;
>> @@ -887,7 +889,7 @@ static void cleanup_cpu_root_pgt(unsigne
>>  }
>>  }
>>  
>> -static void cpu_smpboot_free(unsigned int cpu)
>> +static void cpu_smpboot_free(unsigned int cpu, bool all)
> 
> I think "all" is too vague. It doesn't convey the idea what constitutes
> "partial". But I don't have any better suggestion either.

Indeed I've been trying to come up with a better name before
posting, but couldn't. One thing though - I don't think the name
should in anyway be required to express what "partial" means.

>> @@ -898,15 +900,24 @@ static void cpu_smpboot_free(unsigned in
>>  socket_cpumask[socket] = NULL;
>>  }
>>  
>> -c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
>> -c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
>> -c[cpu].compute_unit_id = INVALID_CUID;
>>  cpumask_clear_cpu(cpu, _sibling_setup_map);
>>  
>> -free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
>> -free_cpumask_var(per_cpu(cpu_core_mask, cpu));
>> -if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
>> -free_cpumask_var(per_cpu(scratch_cpumask, cpu));
>> +if ( all )
>> +{
>> +c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
>> +c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
>> +c[cpu].compute_unit_id = INVALID_CUID;
>> +
>> +free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
>> +clear_cpumask_var(_cpu(cpu_sibling_mask, cpu));
>> +free_cpumask_var(per_cpu(cpu_core_mask, cpu));
>> +clear_cpumask_var(_cpu(cpu_core_mask, cpu));
>> +if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
>> +{
>> +free_cpumask_var(per_cpu(scratch_cpumask, cpu));
>> +clear_cpumask_var(_cpu(scratch_cpumask, cpu));
>> +}
> 
> One thing that's not mentioned in the commit message is why various
> masks are kept. I guess they are needed for some other parts of the
> system to remain operational.

Hmm, I've taken the opposite approach: Free in "partial" mode
only what I could prove won't be needed.

Jan



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

Re: [Xen-devel] [PATCH v3 1/3] xen/x86: replace '||' usage in the linker script

On Wed, Jul 11, 2018 at 05:34:48PM +0200, Roger Pau Monne wrote:
> With '|'. The result is the same, and the later works with lld. Fixes
> the following error when building Xen with lld:
>
> ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
> /root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
> ld: error: xen.lds:260: malformed number: |
> >>> ASSERT(__image_base__ > (261 >> 8) * 0x) | (261 
> >>> << 39))) + ((1 << 39) / 2)) + (64 << 30)) + (1 << 30)) + (1 << 30))) ||
> >>>   
> >>> ^
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Daniel Kiper 
> ---
>  xen/arch/x86/xen.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index 70afedd31d..326e885402 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -331,7 +331,7 @@ SECTIONS
>.comment 0 : { *(.comment) }
>  }
>
> -ASSERT(__image_base__ > XEN_VIRT_START ||
> +ASSERT(__image_base__ > XEN_VIRT_START |
> __2M_rwdata_end <= XEN_VIRT_END - NR_CPUS * PAGE_SIZE,
> "Xen image overlaps stubs area")

I am not happy with this change. Is the same needed for any "&&"?
Anyway, if maintainers are OK with that I will just ask you to put
the comment before the ASSERT() why you use "|" instead of "||".

Daniel

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

Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols

On 11/07/18 16:34, Roger Pau Monne wrote:
> And replace the open-coded versions already in tree. No functional
> change.
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Daniel Kiper 
> ---
>  xen/include/xen/compiler.h  | 2 ++
>  xen/include/xen/livepatch_payload.h | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> index a7e05681c9..001f589655 100644
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -18,6 +18,8 @@
>  
>  #define __packed  __attribute__((__packed__))
>  
> +#define __weak__attribute__((weak))

__week__  (can be fixed on commit)

Otherwise, Reivewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH v3 3/3] xen/x86: declare the efi symbol as weak

On Wed, Jul 11, 2018 at 05:34:50PM +0200, Roger Pau Monne wrote:
> This allows removing the DEFINED conditional in the linker script, and
> fixes compilation with lld:

s/lld/LLVM linker/?

Could you mention the version of LLVM linker in the commit message?
And I am still not sure why do you insist on this patch series.
IIRC you have told us that both issues will be fixed in LLVM.

> ld-melf_x86_64_fbsd  -T xen.lds -N prelink.o --build-id=sha1 \
> /root/src/xen/xen/common/symbols-dummy.o -o /root/src/xen/xen/.xen-syms.0
> ld: error: xen.lds:233: symbol not found: efi
>
> Signed-off-by: Roger Pau Monné 

With this patch applied ld from binutils 2.22 complains in this way:

ld-melf_x86_64  -T xen.lds -N prelink.o --build-id=sha1 \
xen/common/symbols-dummy.o -o xen/.xen-syms.0
prelink.o: In function `acpi_os_get_root_pointer':
xen/drivers/acpi/osl.c:73:(.init.text+0x192e9): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
xen/drivers/acpi/osl.c:75:(.init.text+0x192f6): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
prelink.o: In function `efi_check_config':
xen/arch/x86/mpparse.c:702:(.init.text+0x238ce): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
xen/arch/x86/mpparse.c:706:(.init.text+0x238f2): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
prelink.o: In function `dmi_efi_iterate':
xen/arch/x86/dmi_scan.c:377:(.init.text+0x3666f): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
xen/arch/x86/dmi_scan.c:391:(.init.text+0x366d7): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
xen/arch/x86/dmi_scan.c:400:(.init.text+0x36735): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'
xen/arch/x86/dmi_scan.c:414:(.init.text+0x367b1): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `efi'

Everything works with binutils 2.28.

Daniel

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

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

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  e21ba44f771226a5f6f0ce269aabcfb019eae539
baseline version:
 xen  f1ad5ff73e7d07e6a18488430583168a857f2847

Last test of basis   125117  2018-07-11 20:00:22 Z0 days
Testing same since   125125  2018-07-12 09:00:30 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Roger Pau Monné 
  Sergey Dyasli 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f1ad5ff73e..e21ba44f77  e21ba44f771226a5f6f0ce269aabcfb019eae539 -> smoke

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

Re: [Xen-devel] [ovmf test] 125119: regressions - FAIL

2018-07-12 Thread Anthony PERARD

On Thu, Jul 12, 2018 at 02:53:55AM +, osstest service owner wrote:
> flight 125119 ovmf real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/125119/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-pvops  6 kernel-build fail REGR. vs. 
> 125105

1 hour (actually 4000s) was not enough to clone/checkout Linux.

But the next run, of the same job on the same machine only took about
300s.

-- 
Anthony PERARD

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

[Xen-devel] [xen-4.8-testing baseline-only test] 74958: regressions - FAIL

2018-07-12 Thread Platform Team regression test user

This run is configured for baseline tests only.

flight 74958 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74958/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 15 guest-saverestore.2 fail REGR. vs. 74889

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail like 74889
 test-armhf-armhf-libvirt 12 guest-start  fail   like 74889
 test-armhf-armhf-libvirt-xsm 12 guest-start  fail   like 74889
 test-armhf-armhf-xl-multivcpu 12 guest-start  fail  like 74889
 test-armhf-armhf-xl-credit2  12 guest-start  fail   like 74889
 test-armhf-armhf-xl-midway   12 guest-start  fail   like 74889
 test-armhf-armhf-xl-xsm  12 guest-start  fail   like 74889
 test-armhf-armhf-xl  12 guest-start  fail   like 74889
 test-armhf-armhf-xl-rtds 12 guest-start  fail   like 74889
 test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail like 74889
 test-armhf-armhf-xl-vhd  10 debian-di-installfail   like 74889
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail   like 74889
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 74889
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 74889
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 74889
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  e39ff386f626ba44f8a9a9608d8f5f13ff7945ef
baseline version:
 xen  c1aaad5627448a84c4e49304d89b11a8e6f588e7

Last test of basis74889  2018-06-19 16:50:54 Z   22 days
Testing same since74958  2018-07-12 02:22:46 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64-xtf  pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumprun  pass
 build-i386-rumprun   pass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4

Re: [Xen-devel] [PATCH] tools: remove local links to the x86 headers

On Thu, Jul 12, 2018 at 12:40:34PM +0200, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
> 
> No functional change.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 8/8] efi: drop original xen.efi code and build mechanism

On Wed, Jul 11, 2018 at 06:33:15AM -0600, Jan Beulich wrote:
> >>> On 11.07.18 at 13:57,  wrote:
> > On Tue, Jul 10, 2018 at 08:05:56AM -0600, Jan Beulich wrote:
> >> >>> On 10.07.18 at 13:35,  wrote:
> >> > On Fri, Jul 06, 2018 at 09:16:38AM -0600, Jan Beulich wrote:
> >> >> >>> On 06.07.18 at 16:46,  wrote:
> >> >> > OK, xen.mb.efi does not need relocs because:
> >> >> >   - we generate PE file from xen-syms file like we do with ELF output;
> >> >> > so, the code in the PE file is the same like in the ELF file;
> >> >> > hence, if ELF works why PE should not,
> >> >> >   - all addressing is relative to %rip as it is in ELF file,
> >> >>
> >> >> What are the several hundred base relocs in xen.efi doing then? Sure
> >> >> some of them wouldn't really be needed, but I doubt that's true for
> >> >> all of them. The first and foremost case of non-RIP-relative addressing
> >> >> is data with static initializers pointing elsewhere in the image. These
> >> >> need relocations applied to work.
> >> >>
> >> >> Once again - a fundamental criteria is whether your binary can be used
> >> >> in place of the current xen.efi. I can't convince myself that you've
> >> >> actually tried that out. At the very least I'd expect the static array 
> >> >> in
> >> >> PrintErrMesg() to present problems here.
> >> >
> >> > Ugh... You are right. I forgot about that. Sadly the problem applies to
> >> > the EFI boot code in the xen.gz too. So, both things have to be fixed.
> >> > At first sight it seems to me that we can leave relocs in the xen-syms
> >> > and then attach them to the xen.mb.efi/xen.gz somehow. It would be nice
> >> > to do that just only for the EFI boot code. Should not we put it in
> >> > separate section then? Another question is the size of the .reloc 
> >> > section.
> >> > We do not know it in advance. So, probably we should build the code in
> >> > two steps as we do now. Or prealloc a static place and fill it later.
> >> > This way we would have just one phase build.
> >>
> >> Any static allocation/reservation scheme is wasteful at first and 
> >> eventually
> >> not allocating/reserving enough space. Unless there's a way to reasonably
> >> well estimate the size ahead of time, I'd be opposed to such a model. As
> >
> > I have the same concerns in regards to that.
> >
> >> to a separate section - sure, why not? Relocations are in a separate 
> >> section
> >> in xen.efi as well.
> >
> > I was thinking about separate section for EFI boot code itself, e.g. 
> > .text.efi.
> > Then probably it will be much easier to identify and use/get relocs needed 
> > only
> > for that code.
>
> How would you constrain which other code can be called from code in this
> section? While things like memcpy() won't need relocations, there would be
> no separation between code that can and be called here and code that
> must not be.

I think that it is difficult or even impossible. However, the EFI boot
code is quite well self contained, so, there is chance that this way
we can reduce the number of generated relocs.

Daniel

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

Re: [Xen-devel] [PATCH 3/8] allow cpu_down() to be called earlier

On Wed, Jul 11, 2018 at 06:06:52AM -0600, Jan Beulich wrote:
> The function's use of the stop-machine logic has so far prevented its
> use ahead of the processing of the "ordinary" initcalls. Since at this
> early time we're in a controlled environment anyway, there's no need for
> such a heavy tool. Additionally this ought to have less of a performance
> impact especially on large systems, compared to the alternative of
> making stop-machine functionality available earlier.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/8] x86: distinguish CPU offlining from CPU removal

On Wed, Jul 11, 2018 at 06:06:04AM -0600, Jan Beulich wrote:
[...]
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -63,6 +63,8 @@ static cpumask_t scratch_cpu0mask;
>  cpumask_t cpu_online_map __read_mostly;
>  EXPORT_SYMBOL(cpu_online_map);
>  
> +bool __read_mostly park_offline_cpus;
> +
>  unsigned int __read_mostly nr_sockets;
>  cpumask_t **__read_mostly socket_cpumask;
>  static cpumask_t *secondary_socket_cpumask;
> @@ -887,7 +889,7 @@ static void cleanup_cpu_root_pgt(unsigne
>  }
>  }
>  
> -static void cpu_smpboot_free(unsigned int cpu)
> +static void cpu_smpboot_free(unsigned int cpu, bool all)

I think "all" is too vague. It doesn't convey the idea what constitutes
"partial". But I don't have any better suggestion either.

>  {
>  unsigned int order, socket = cpu_to_socket(cpu);
>  struct cpuinfo_x86 *c = cpu_data;
> @@ -898,15 +900,24 @@ static void cpu_smpboot_free(unsigned in
>  socket_cpumask[socket] = NULL;
>  }
>  
> -c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
> -c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
> -c[cpu].compute_unit_id = INVALID_CUID;
>  cpumask_clear_cpu(cpu, _sibling_setup_map);
>  
> -free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
> -free_cpumask_var(per_cpu(cpu_core_mask, cpu));
> -if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
> -free_cpumask_var(per_cpu(scratch_cpumask, cpu));
> +if ( all )
> +{
> +c[cpu].phys_proc_id = XEN_INVALID_SOCKET_ID;
> +c[cpu].cpu_core_id = XEN_INVALID_CORE_ID;
> +c[cpu].compute_unit_id = INVALID_CUID;
> +
> +free_cpumask_var(per_cpu(cpu_sibling_mask, cpu));
> +clear_cpumask_var(_cpu(cpu_sibling_mask, cpu));
> +free_cpumask_var(per_cpu(cpu_core_mask, cpu));
> +clear_cpumask_var(_cpu(cpu_core_mask, cpu));
> +if ( per_cpu(scratch_cpumask, cpu) != _cpu0mask )
> +{
> +free_cpumask_var(per_cpu(scratch_cpumask, cpu));
> +clear_cpumask_var(_cpu(scratch_cpumask, cpu));
> +}

One thing that's not mentioned in the commit message is why various
masks are kept. I guess they are needed for some other parts of the
system to remain operational.

The rest looks fine to me.

Wei.

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

Re: [Xen-devel] [PATCH v2 3/8] xen/x86: manually build xen.mb.efi binary

On Wed, Jul 11, 2018 at 06:26:23AM -0600, Jan Beulich wrote:
> >>> On 11.07.18 at 13:41,  wrote:
> > On Tue, Jul 10, 2018 at 07:54:51AM -0600, Jan Beulich wrote:
> >> >>> On 10.07.18 at 12:48,  wrote:
> >> > On Fri, Jul 06, 2018 at 09:08:29AM -0600, Jan Beulich wrote:
> >> >> >>> On 06.07.18 at 16:02,  wrote:
> >> >> > On Thu, Jul 05, 2018 at 02:18:03AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 04.07.18 at 18:35,  wrote:
> >> >> >> > On Wed, Jul 04, 2018 at 09:27:43AM -0600, Jan Beulich wrote:
> >> >> >> >> >>> On 04.07.18 at 16:01,  wrote:
> >> >> >> >> > On Mon, Jun 25, 2018 at 09:36:07AM -0600, Jan Beulich wrote:
> >> >> >> >> >> >>> On 19.06.18 at 16:35,  wrote:
> >> >> >> >> >> > @@ -582,6 +587,12 @@ static void __init 
> >> >> >> >> >> > efi_arch_memory_setup(void)
> >> >> >> >> >> >  if ( !efi_enabled(EFI_LOADER) )
> >> >> >> >> >> >  return;
> >> >> >> >> >> >
> >> >> >> >> >> > +if ( efi_enabled(EFI_MB_LOADER) )
> >> >> >> >> >> > +for ( pte = __page_tables_start; pte < 
> >> >> >> >> >> > __page_tables_end;
> >> >> >> >> >> > +  pte += ( pte != (intpte_t *)l2_identmap ) ? 1 
> >> >> >> >> >> > : 4 * L2_PAGETABLE_ENTRIES )
> >> >> >> >> >>
> >> >> >> >> >> Please avoid explicit casts - _get_intpte(l2_identmap[0]) 
> >> >> >> >> >> or
> >> >> >> >> >> something along those lines ought to work here. Same for
> >> >> >> >> >> 4 * L2_PAGETABLE_ENTRIES - you mean ARRAY_SIZE() there.
> >> >> >> >> >
> >> >> >> >> > OK.
> >> >> >> >> >
> >> >> >> >> >> Also this whole code block needs a comment, to explain what it
> >> >> >> >> >> does and also why l2_identmap needs skipping.
> >> >> >> >> >>
> >> >> >> >> >> Furthermore - isn't this off by one, and you process 
> >> >> >> >> >> l2_identmap[0]
> >> >> >> >> >> this way, skipping the rest _plus_ the first following entry? 
> >> >> >> >> >> I think
> >> >> >> >> >
> >> >> >> >> > The code mimics similar code in head.S.
> >> >> >> >>
> >> >> >> >> I can't see a similar off-by-1 in head.S.
> >> >> >> >
> >> >> >> >  662 /*
> >> >> >> >  663  * Update frame addresses in page tables excluding 
> >> >> >> > l2_identmap
> >> >> >> >  664  * without its first entry which points to 
> >> >> >> > l1_identmap.
> >> >> >> >  665  */
> >> >> >> >  666 mov 
> >> >> >> > $((__page_tables_end-__page_tables_start)/8),%ecx
> >> >> >> >  667 mov 
> >> >> >> > $(((l2_identmap-__page_tables_start)/8)+1),%edx
> >> >> >> >  668 1:  cmp 
> >> >> >> > $((l2_identmap+l2_identmap_sizeof-__page_tables_start)/8),%ecx
> >> >> >> >  669 cmove   %edx,%ecx
> >> >> >> >  670 testl   
> >> >> >> > $_PAGE_PRESENT,sym_fs(__page_tables_start)-8(,%ecx,8)
> >> >> >> >  671 jz  2f
> >> >> >> >  672 add %esi,sym_fs(__page_tables_start)-8(,%ecx,8)
> >> >> >> >  673 2:  loop1b
> >> >> >>
> >> >> >> Well - this is the code in question, but you fail to point out where
> >> >> >> the off-by-1 is.
> >> >> >
> >> >> > Line 667, 668 and 669.
> >> >>
> >> >> I don't think so, no. Note the -8 in lines 670 and 672.
> >> >
> >> > However, you are missing +1 in line 667.
> >>
> >> I don't think I am: The first entry of l2_identmap actually needs
> >> processing afaics (and as the comment says), as that's the only one
> >> with non-absolute contents. IOW - part of my original comment was
> >> wrong, but the other half (you skipping one entry) still seems
> >> applicable, as does the part concerning the missing comment.
> >
> > It seems correct to me. l2_identmap[0] gets updated and then
> > we move to l3_bootmap[0]. Am I missing something?
>
> Hmm, yes, I think you're right. But the way you've coded it it's
> less obvious than in the assembly variant, and typically it should
> be the other way around. I'd really like you to make this a closer
> match.

Do you suggest that we should do that backwards as we do in ASM?
Or anything else?

Daniel

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

Re: [Xen-devel] 4.9.3 preparations

Jan Beulich writes ("RE: [Xen-devel] 4.9.3 preparations"):
> On 11.07.18 at 18:23,  wrote:
> > 08641a9e8870d3b174d95aaa55ecba43387563b5 would be nice to have included.
> 
> Ian, that's one for you, unless you tell me to take it.

Indeed.  I've committed it.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] tools: remove local links to the x86 headers

On 12/07/18 11:40, Roger Pau Monne wrote:
> In the x86 test harness and the fuzzer, and instead create a link in
> the tools/include directory that can be used by all the tools.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné 

Acked-by: Andrew Cooper 

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

[Xen-devel] [PATCH] tools: remove local links to the x86 headers

In the x86 test harness and the fuzzer, and instead create a link in
the tools/include directory that can be used by all the tools.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/fuzz/x86_instruction_emulator/Makefile | 10 ++
 tools/include/Makefile   |  3 +++
 tools/tests/x86_emulator/Makefile| 10 ++
 tools/tests/x86_emulator/x86-emulate.h   |  6 +++---
 4 files changed, 10 insertions(+), 19 deletions(-)

diff --git a/tools/fuzz/x86_instruction_emulator/Makefile 
b/tools/fuzz/x86_instruction_emulator/Makefile
index fbbb70bbfc..e76743de24 100644
--- a/tools/fuzz/x86_instruction_emulator/Makefile
+++ b/tools/fuzz/x86_instruction_emulator/Makefile
@@ -13,11 +13,6 @@ x86_emulate:
 
 x86_emulate/%: x86_emulate ;
 
-asm:
-   [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
-
-asm/%: asm ;
-
 x86-emulate.c x86-emulate.h wrappers.c: %:
[ -L $* ] || ln -sf $(XEN_ROOT)/tools/tests/x86_emulator/$*
 
@@ -27,8 +22,7 @@ GCOV_FLAGS := --coverage
 %-cov.o: %.c
$(CC) -c $(CFLAGS) $(GCOV_FLAGS) $< -o $@
 
-x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
-x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
+x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h
 
 # x86-emulate.c will be implicit for both
 x86-emulate.o x86-emulate-cov.o: x86_emulate/x86_emulate.c $(x86_emulate.h)
@@ -50,7 +44,7 @@ all: x86-insn-fuzz-all
 
 .PHONY: distclean
 distclean: clean
-   rm -f x86_emulate x86-emulate.c x86-emulate.h asm
+   rm -f x86_emulate x86-emulate.c x86-emulate.h
 
 .PHONY: clean
 clean:
diff --git a/tools/include/Makefile b/tools/include/Makefile
index 666510530e..270a34f318 100644
--- a/tools/include/Makefile
+++ b/tools/include/Makefile
@@ -21,6 +21,9 @@ xen/.dir:
ln -sf $(addprefix $(XEN_ROOT)/xen/include/xen/,libelf.h elfstructs.h) 
xen/libelf/
ln -s ../xen-foreign xen/foreign
ln -sf $(XEN_ROOT)/xen/include/acpi acpi
+ifeq ($(CONFIG_X86),y)
+   ln -sf $(XEN_ROOT)/xen/include/asm-x86 xen/asm
+endif
touch $@
 
 # Not xen/xsm as that clashes with link to
diff --git a/tools/tests/x86_emulator/Makefile 
b/tools/tests/x86_emulator/Makefile
index 417d5c0941..10031b74d1 100644
--- a/tools/tests/x86_emulator/Makefile
+++ b/tools/tests/x86_emulator/Makefile
@@ -118,7 +118,7 @@ $(TARGET): x86-emulate.o test_x86_emulator.o wrappers.o
 
 .PHONY: clean
 clean:
-   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
x86_emulate asm
+   rm -rf $(TARGET) *.o *~ core $(addsuffix .h,$(TESTCASES)) *.bin 
x86_emulate
 
 .PHONY: distclean
 distclean: clean
@@ -131,17 +131,11 @@ x86_emulate:
 
 x86_emulate/%: x86_emulate ;
 
-asm:
-   [ -L $@ ] || ln -sf $(XEN_ROOT)/xen/include/asm-x86 $@
-
-asm/%: asm ;
-
 HOSTCFLAGS-x86_64 := -fno-PIE
 $(call cc-option-add,HOSTCFLAGS-x86_64,HOSTCC,-no-pie)
 HOSTCFLAGS += $(CFLAGS_xeninclude) -I. $(HOSTCFLAGS-$(XEN_COMPILE_ARCH))
 
-x86.h := asm/x86-vendors.h asm/x86-defns.h asm/msr-index.h
-x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h $(x86.h)
+x86_emulate.h := x86-emulate.h x86_emulate/x86_emulate.h
 
 x86-emulate.o test_x86_emulator.o wrappers.o: %.o: %.c $(x86_emulate.h)
$(HOSTCC) $(HOSTCFLAGS) -c -g -o $@ $<
diff --git a/tools/tests/x86_emulator/x86-emulate.h 
b/tools/tests/x86_emulator/x86-emulate.h
index fd1ba5218b..b249e4673c 100644
--- a/tools/tests/x86_emulator/x86-emulate.h
+++ b/tools/tests/x86_emulator/x86-emulate.h
@@ -11,9 +11,9 @@
 
 #include 
 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 
 #include 
 
-- 
2.17.1


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

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

On 06/07/2018, 17:42, "Lars Kurth" wrote:

Hi all, (I also moved the AB to BCC)

I summarized the discussion in
https://docs.google.com/document/d/1W7OuISUau-FtPG6tIinD4GXYFb-hKDjaqTj84pogNrA/edit?usp=sharing

I may have missed some things or misinterpreted them, but it looks as if
consensus is emerging in some areas. I would like to discuss what we do for the
4.12 release at next week's community call. As far as I can see we have a few
options:
* Go on as we are
* Move to 9 months, until we fixed the underlying issues - the problem is
that unless we get some sort of commitment
* Skip a release as a one-off: Set ourselves some goals that must be
achieved in this cycle around testing - this will need some commitment from
vendors

Regards
Lars

That discussion took place yesterday, including some people who were not at the
design session, but not the complete list of people. Thus, I am copying the
notes into here as well (and the google doc), such that everything is in one
place.

Juergen: raises the point that keeping the release cadence at 6 months is very
unfair on Jan
who has raised many times that the workload resulting from having to maintain
so many
release branches would be too high. After running 6 monthly releases for some
time, this
has in fact come true, when at the time Jan’s concerns were dismissed. The
overhead
breaks down into backporting fixes, backporting security fixes and dealing with
the release
mechanics.

Jan: raised the point that hardly anyone responds to calls for back-ports and
if so, only send
change-sets and Jan do the backporting. Jan also says he suspects that people
may not
respond to backport requests, because that would require them to backport the
patches.

George: points out that unless he remembers at the time he writes or reviews a
patch,
whether it is back-port worthy.

George and Andrew raised the idea that we could maintain a list of pending
backports and
assign backport tasks to people.

Jan: maintaining releases as a single person is the most efficient way of doing
it. A single
person doing all trees is most efficient, but then we need to restrict the
number of trees. And
2 releases per year are too many.

Andrew: suggests that an even/odd releases model with different support cycles
would solve
this. By doing this, we would retain the discipline of doing releases.

Juergen: this would however impose the release overhead

Andrew: agrees that we need to reduce our release overhead regardless, but this
issue is
orthogonal from the release cadence.

**Staying at 6 months we would either have to find someone who would like to
carry the
maintenance load, or move to a longer cadence. Also we need to make it clear
that
reducing the release overhead is independent from release cadence and process.
We
should be doing this irrespective depending on the cadence.**

Juergen: We could ** look at 8 months (instead of 9)it is better from a
scheduling
perspective (working around public holidays).** With an 8 month release
cycle, the release
occurs at only 3 different dates during the calendar year, rather than the 4
dates with a 9
month cycle. This makes planning easier for selecting dates that avoid public
holidays. 8
months is also closer to the 6 month cycle for those preferring shorter
cadence. An 8 month
cycle would not increase the number of concurrently supported branches when
compared
with a 9 month cycle.

**ACTION: George will put together a survey for the committers outlining the
issue and
trade-offs and then go from there**

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

[Xen-devel] [Notes for xen summit 2018 design session] SGX deep dive and SGX virtualization design discussion

The notes and PPT were sent to me by Kai to be published
An SGX back-ground presentation can be found at 
https://www.slideshare.net/xen_com_mgr/xpdds18-design-session-sgx-deep-dive-and-sgx-virtualization-discussion-kai-huang-intel
 

Key agreements during a discussion between present maintainers and Kai
* There is no need to  support SGX for PV guests at least initially: this is 
something that can be added in a second phase
* We don’t need to expose SGX to dom0 and let Xen hypervisor manage EPC
* Query SGX info: 
   - Ultimately the interface is the toolstack maintainer's call (aka Wei). 
   - George: maybe extending existing xl command is the best way forward: 
something like ‘xl info -sgx’, ‘xl list  -sgx’
* New XL parameter for SGX to create VM to allow admin to configure virtual EPC 
size and support launch control:
   - sgx = ‘epc=,lehash=,lewr=<0|1>’
* EPC size configured by ‘epc=’, EPC base calculated by toolstack.
   - KVM SGX will introduce new SGX parameter (similar to Xen’s) in Qemu
   - Should we pass SGX info to Qemu from XL? Andrew: No we should not. It 
should not be very complicated to calculate in XL.
* EPC management: we should integrate EPC management into the existing memory 
management framework to leverage existing MM code (ex, page allocation, etc).
* EPC virtualization: it’s perfectly fine to only support static partitioning, 
at least in a first implementation
   - When needed, we can extend to support EPC ballooning and oversubscription, 
depending on user requirements as they emerge
* CPUID handling: We should rebase patches based on Andrew’s CPUID and MSR 
series. 
   - Note from Lars: the patches in question are 
 - [PATCH 00/13] x86: CPUID and MSR policy marshalling support, which has 
been posted but it is only covering ⅓ of the needed patches and requires some 
fixes. 
 - Sergey is working on the libxc side and Andrew on the hypervisor 
auditing/checking. 
 - Roger is working on topology support, which depends on the other three 
pieces, bit Lars is not sure whether these are needed for SGX
   - Andrew: it’s also good to review other patches not related to CPUID/MSR.
* Live migration, snapshot, checkpointing: we should support them as long as 
both Linux and Windows SGX drivers commit to support “sudden loss of EPC” 
(which is not hardware behaviour though).
* ACPI: Overall current approach is OK. We can review when patch is ready. Need 
to use 2 32-bit variables for 64-bit variables in ‘struct acpi_info’.


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

Re: [Xen-devel] [PATCH v2 03/10] x86: Add Intel Processor Trace support for cpuid

>>> On 12.07.18 at 09:21,  wrote:
>> >>> On 30.05.18 at 15:27,  wrote:
>> > @@ -759,12 +760,19 @@ int xc_cpuid_apply_policy(xc_interface *xch, 
>> > uint32_t domid,
>> >  continue;
>> >  }
>> >
>> > +if ( input[0] == 0x14 )
>> > +{
>> > +input[1]++;
>> > +if ( input[1] == 1 )
>> > +continue;
>> > +}
>> 
>> Together with what's there and what iirc Andrew's series puts here, this 
> should become a switch() imo.
> 
> Why use switch() here? I don't think need change to switch() and I can't 
> find any example in this function use switch(). For example leaf 4 is also 
> implement like this.
> 
> /* Intel cache descriptor leaves. */
> if ( input[0] == 4 )
> {
> input[1]++;
> /* More to do? Then loop keeping %%eax==0x0004. */
> if ( (regs[0] & 0x1f) != 0 )
> continue;
> }

For exactly this reason - instead of multiple if()-s evaluating
input[0], switch(input[0]) is preferred.

>> > --- a/xen/include/asm-x86/cpuid.h
>> > +++ b/xen/include/asm-x86/cpuid.h
>> > @@ -58,10 +58,11 @@ DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
>> >  /* Default masking MSR values, calculated at boot. */  extern struct
>> > cpuidmasks cpuidmask_defaults;
>> >
>> > -#define CPUID_GUEST_NR_BASIC  (0xdu + 1)
>> > +#define CPUID_GUEST_NR_BASIC  (0x14u + 1)
>> 
>> Is there anything to convince me that the intermediate leaves don't need any 
> further handling added anywhere? Same question btw
>> for the libxc side bumping of DEF_MAX_BASE.
> 
> They are all zero and meaningless in these intermediate leaves. So I think 
> we don't need do anything. what is your concern ?

As said - how can I convince myself that no further handling is needed?
How did you convince yourself? For example, update_domain_cpuid_info()
will then allow to set the intermediate fields to arbitrary values, without
recalculate_cpuid_policy() doing anything with them. After all
cpuid_featureset_to_policy() only sets explicit fields, but doesn't clear the
policy up front. Andrew - isn't this still a left-over piece of white-listing?

>> > @@ -166,6 +167,15 @@ struct cpuid_policy
>> >  } comp[CPUID_GUEST_NR_XSTATE];
>> >  } xstate;
>> >
>> > +/* Structured feature leaf: 0x0014[xx] */
>> > +union {
>> > +struct cpuid_leaf raw[CPUID_GUEST_NR_IPT];
>> > +struct {
>> > +/* Subleaf 0. */
>> > +uint32_t max_subleaf;
>> > +};
>> > +} ipt;
>> 
>> In particular this looks to be placed earlier than it should be (in other 
> words I'm getting the impression that you failed to insert
>> some padding for the skipped leaves).
> 
> I think we don't need add some padding for skipped leaves because these are 
> accessed by name (e.g. xstate, ipt ...) not offset.

Oh, right, I was mistaken here - the immediately containing entity
is a struct, not a union.

Jan



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

Re: [Xen-devel] [PATCH v3 2/3] xen/compiler: introduce a define for weak symbols

Forgot to Cc maintainers.

On Wed, Jul 11, 2018 at 05:34:49PM +0200, Roger Pau Monne wrote:
> And replace the open-coded versions already in tree. No functional
> change.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Daniel Kiper 
> ---
>  xen/include/xen/compiler.h  | 2 ++
>  xen/include/xen/livepatch_payload.h | 4 ++--
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> index a7e05681c9..001f589655 100644
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -18,6 +18,8 @@
>  
>  #define __packed  __attribute__((__packed__))
>  
> +#define __weak__attribute__((weak))
> +
>  #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
>  #define unreachable() do {} while (1)
>  #else
> diff --git a/xen/include/xen/livepatch_payload.h 
> b/xen/include/xen/livepatch_payload.h
> index 8f38cc2c60..4a1a96d054 100644
> --- a/xen/include/xen/livepatch_payload.h
> +++ b/xen/include/xen/livepatch_payload.h
> @@ -24,7 +24,7 @@ typedef void livepatch_unloadcall_t(void);
>   * executed in series by the livepatch infrastructure at patch load time.
>   */
>  #define LIVEPATCH_LOAD_HOOK(_fn) \
> -livepatch_loadcall_t *__attribute__((weak)) \
> +livepatch_loadcall_t *__weak \
>  const livepatch_load_data_##_fn __section(".livepatch.hooks.load") = 
> _fn;
>  
>  /*
> @@ -33,7 +33,7 @@ typedef void livepatch_unloadcall_t(void);
>   * Same as LOAD hook with s/load/unload/
>   */
>  #define LIVEPATCH_UNLOAD_HOOK(_fn) \
> - livepatch_unloadcall_t *__attribute__((weak)) \
> + livepatch_unloadcall_t *__weak \
>  const livepatch_unload_data_##_fn 
> __section(".livepatch.hooks.unload") = _fn;
>  
>  #endif /* __XEN_LIVEPATCH_PAYLOAD_H__ */
> -- 
> 2.17.1
> 

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

Re: [Xen-devel] [PATCH v2 03/10] x86: Add Intel Processor Trace support for cpuid

2018-07-12 Thread Kang, Luwei

> >>> On 30.05.18 at 15:27,  wrote:
> > @@ -759,12 +760,19 @@ int xc_cpuid_apply_policy(xc_interface *xch, uint32_t 
> > domid,
> >  continue;
> >  }
> >
> > +if ( input[0] == 0x14 )
> > +{
> > +input[1]++;
> > +if ( input[1] == 1 )
> > +continue;
> > +}
> 
> Together with what's there and what iirc Andrew's series puts here, this 
> should become a switch() imo.

Why use switch() here? I don't think need change to switch() and I can't find 
any example in this function use switch(). For example leaf 4 is also implement 
like this.

/* Intel cache descriptor leaves. */
if ( input[0] == 4 )
{
input[1]++;
/* More to do? Then loop keeping %%eax==0x0004. */
if ( (regs[0] & 0x1f) != 0 )
continue;
}

> 
> > @@ -583,7 +584,19 @@ void recalculate_cpuid_policy(struct domain *d)
> >  __clear_bit(X86_FEATURE_VMX, max_fs);
> >  __clear_bit(X86_FEATURE_SVM, max_fs);
> >  }
> > +
> > +/*
> > + * Hide Intel Processor trace feature when hardware not support
> > + * PT-VMX or ipt option is off.
> > + */
> > +if ( ipt_mode == IPT_MODE_OFF )
> > +{
> > +__clear_bit(X86_FEATURE_IPT, max_fs);
> > +zero_leaves(p->ipt.raw, 0, ARRAY_SIZE(p->ipt.raw) - 1);
> > +}
> 
> The clearing of bits in max_fs further up is needed here because this varies 
> depending on domain config. You, otoh, put a
> conditional here which is not going to change post boot. This instead belongs 
> into
> calculate_hvm_max_policy() I believe.

ipt_mode is any global parameter for all domain. Move to 
calculate_hvm_max_policy() is good to me.
Will fix in next version.

> 
> > @@ -101,6 +102,10 @@ static int update_domain_cpuid_info(struct domain *d,
> >  p->feat.raw[ctl->input[1]] = leaf;
> >  break;
> >
> > +case IPT_CPUID:
> > +p->ipt.raw[ctl->input[1]] = leaf;
> > +break;
> 
> This lacks a bounds check of ctl->input[1] (in the earlier switch()).

Oh, get it. 

> 
> > --- a/xen/include/asm-x86/cpufeature.h
> > +++ b/xen/include/asm-x86/cpufeature.h
> > @@ -102,6 +102,7 @@
> >  #define cpu_has_mpx boot_cpu_has(X86_FEATURE_MPX)
> >  #define cpu_has_rdseed  boot_cpu_has(X86_FEATURE_RDSEED)
> >  #define cpu_has_smapboot_cpu_has(X86_FEATURE_SMAP)
> > +#define cpu_has_ipt boot_cpu_has(X86_FEATURE_IPT)
> 
> This definition is unused.

Will remove it.

> 
> > --- a/xen/include/asm-x86/cpuid.h
> > +++ b/xen/include/asm-x86/cpuid.h
> > @@ -58,10 +58,11 @@ DECLARE_PER_CPU(struct cpuidmasks, cpuidmasks);
> >  /* Default masking MSR values, calculated at boot. */  extern struct
> > cpuidmasks cpuidmask_defaults;
> >
> > -#define CPUID_GUEST_NR_BASIC  (0xdu + 1)
> > +#define CPUID_GUEST_NR_BASIC  (0x14u + 1)
> 
> Is there anything to convince me that the intermediate leaves don't need any 
> further handling added anywhere? Same question btw
> for the libxc side bumping of DEF_MAX_BASE.

They are all zero and meaningless in these intermediate leaves. So I think we 
don't need do anything. what is your concern ?

> 
> > @@ -166,6 +167,15 @@ struct cpuid_policy
> >  } comp[CPUID_GUEST_NR_XSTATE];
> >  } xstate;
> >
> > +/* Structured feature leaf: 0x0014[xx] */
> > +union {
> > +struct cpuid_leaf raw[CPUID_GUEST_NR_IPT];
> > +struct {
> > +/* Subleaf 0. */
> > +uint32_t max_subleaf;
> > +};
> > +} ipt;
> 
> In particular this looks to be placed earlier than it should be (in other 
> words I'm getting the impression that you failed to insert
> some padding for the skipped leaves).

I think we don't need add some padding for skipped leaves because these are 
accessed by name (e.g. xstate, ipt ...) not offset.

Thanks,
Luwei Kang

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

[Xen-devel] [ovmf test] 125122: all pass - PUSHED

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf c563077a380437c114aba4c95be65eb963ebc1f3
baseline version:
 ovmf 895b87e38015e0698c6a5c0633e0156b038a56f1

Last test of basis   125120  2018-07-12 02:54:22 Z0 days
Testing same since   125122  2018-07-12 05:10:44 Z0 days1 attempts


People who touched revisions under test:
  Laszlo Ersek 
  Ni, Ruiyu 
  Ruiyu Ni 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   895b87e380..c563077a38  c563077a380437c114aba4c95be65eb963ebc1f3 -> 
xen-tested-master

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

Re: [Xen-devel] 4.9.3 preparations