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

[osstest service owner]

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

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

Last test of basis   134640  2019-04-11 13:15:51 Z5 days
Failing since134738  2019-04-13 03:33:26 Z4 days   10 attempts
Testing same since   134852  2019-04-16 06:41:35 Z0 days5 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bret Barkelew 
  Chasel Chiu 
  Chasel, Chiu 
  Christian Rodriguez 
  Dandan Bi 
  Dong, Guo 
  Fan, ZhijuX 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Rodriguez, Christian 
  Shenglei Zhang 
  Zhichao Gao 
  Zhiju.Fan 

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
   e0fd9ece26..0eccea3fbe  0eccea3fbe2f6d4999d972d9310d4f2717f5100c -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH net-next] xen-netfront: mark expected switch fall-through

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Mon, 15 Apr 2019 16:11:41 -0500

> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> This patch fixes the following warning:
> 
> drivers/net/xen-netfront.c: In function ‘netback_changed’:
> drivers/net/xen-netfront.c:2038:6: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>if (dev->state == XenbusStateClosed)
>   ^
> drivers/net/xen-netfront.c:2041:2: note: here
>   case XenbusStateClosing:
>   ^~~~
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   25 days
Failing since134068  2019-03-25 12:00:51 Z   22 days  115 attempts
Testing same since   134834  2019-04-15 19:00:48 Z1 days9 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

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

[osstest service owner]

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

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. 133909
 build-i3866 xen-buildfail REGR. vs. 133909

Tests which did not succeed, but are not blocking:
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 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-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-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-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-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-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133909
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133909
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 133909
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133909
 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 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-check

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   25 days
Failing since134068  2019-03-25 12:00:51 Z   22 days  114 attempts
Testing same since   134834  2019-04-15 19:00:48 Z1 days8 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 0eccea3fbe2f6d4999d972d9310d4f2717f5100c
baseline version:
 ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33

Last test of basis   134640  2019-04-11 13:15:51 Z5 days
Failing since134738  2019-04-13 03:33:26 Z3 days9 attempts
Testing same since   134852  2019-04-16 06:41:35 Z0 days4 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bret Barkelew 
  Chasel Chiu 
  Chasel, Chiu 
  Christian Rodriguez 
  Dandan Bi 
  Dong, Guo 
  Fan, ZhijuX 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Rodriguez, Christian 
  Shenglei Zhang 
  Zhichao Gao 
  Zhiju.Fan 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   fail
 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


Not pushing.

(No revision log; it would be 417 lines long.)

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

Re: [Xen-devel] [PATCH 00/12] xen/arm: Add support to build with clang

[Stefano Stabellini]

On Fri, 29 Mar 2019, Julien Grall wrote:
> On 28/03/2019 11:27, Artem Mygaiev wrote:
> > Hi Julien,
> 
> Hi Artem,
> 
> > On Wed, 2019-03-27 at 18:45 +, Julien Grall wrote:
> > > Hi all,
> > > 
> > > This series adds support to build Xen Arm with clang. This series was
> > > tested
> > > with clang 8.0.
> > > 
> > > Note that I only did build for arm64. I still need to look at the arm32
> > > build.
> > > 
> > 
> > I wonder if you have time to try the series with Arm Compiler 6? I am
> > asking because AFAIK it is based on clang/llvm [1] and there's a
> > safety-compliant version of it certified by TUV [2]. I don't have a
> > license yet so cannot try it myself but maybe you have access.
> I gave a quick try to the Arm Compiler. I had to hack a bit config/StdGNU.mk
> to pass armclang and the appropriate target option.
> 
> I also had a linking issue at the end where __2snprintf was not found. It
> seems the compiler replace snprintf with __2snprintf, I haven't figured out
> why yet.

But after these changes, does it work?

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

Re: [Xen-devel] [PATCH] xen/arm: p2m: configure pa_range_info table to support 42 bit PA systems.

[Stefano Stabellini]

On Mon, 8 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 3/15/19 11:57 PM, Feng Kan OS wrote:
> > Thanks Julien.
> > 
> > On 3/15/19 4:21 AM, Julien Grall wrote:
> > > Hi,
> > > 
> > > Thank you for posting the patch.
> > > 
> > > Title: No need for full stop in the commit title.
> > > 
> > > On 15/03/2019 08:34, Vishnu Pajjuri OS wrote:
> > > I can't remember which other platforms support 42-bits PA. I think at
> > > that time it was X-Gene. As long as no current embedded platform we
> > > support use 42-bit PA, this change may be ok. Stefano do you recall what
> > > was the platform?
> > Ampere eMAG platform is essentially the continuation of X-Gene. These
> > systems are targeted as servers with upto 1TB of RAM.
> > > 
> > > In any case, the new behavior (and consequence) needs to be clearly
> > > explained in the commit message.
> > Got it, we will resubmit if Stefano is okay with the change.
> 
> To make progress on this patch, I would suggest to resubmit it with the
> changes requested.

Yes, please send the new patch. Sorry for the late reply.

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

Re: [Xen-devel] booting domU guest as pvh works in xen-4.11.1 but fails in 4.12

[M A Young]

On Tue, 16 Apr 2019, Andrew Cooper wrote:

> From the log:
> 
> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 erro
> r:0 in ld-2.29.so[7f797dc61000+21000]
> 
> 
> Can you disassemble ld-2.29.so and find out what that instruction is?  It is
> almost certainly a related factor.

I get lines like
[1.384356] traps: modprobe[36] trap invalid opcode ip:7f57448af179 
sp:7fff8fc3a938 error:0 in ld-2.29.so[7f5744895000+2]

I am guessing the right place to look in ld-2.29.so is 
0x7f57448af179-0x7f5744895-2 = 86873 in which case I get
(gdb) x/10i 86873
   0x15359 <_dl_close_worker+3593>: mov(%rsi,%rcx,8),%r8
   0x1535d <_dl_close_worker+3597>: testb  $0x20,0x31d(%r8)
   0x15365 <_dl_close_worker+3605>: jne0x15375 
<_dl_close_worker+3621>
   0x15367 <_dl_close_worker+3607>: cmp%ecx,%edx
   0x15369 <_dl_close_worker+3609>: je 0x15372 
<_dl_close_worker+3618>
   0x1536b <_dl_close_worker+3611>: mov%edx,%r9d
   0x1536e <_dl_close_worker+3614>: mov%r8,(%rsi,%r9,8)
   0x15372 <_dl_close_worker+3618>: add$0x1,%edx
   0x15375 <_dl_close_worker+3621>: add$0x1,%rcx
   0x15379 <_dl_close_worker+3625>: cmp%ecx,%eax

Some more lines like this are
[1.571479] traps: modprobe[41] trap invalid opcode ip:7f3e3628d179 
sp:7ffc86abbe08 error:0 in ld-2.29.so[7f3e36273000+2]
[1.630562] traps: modprobe[43] trap invalid opcode ip:7f227b39a179 
sp:7ffdfd943198 error:0 in ld-2.29.so[7f227b38+2]
which all seem to get to the same place. Is this useful or am I looking in 
the wrong place?

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

Re: [Xen-devel] [PATCH for-next] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt

[Julien Grall]

Hi Stefano,

On 4/16/19 10:51 PM, Stefano Stabellini wrote:

On Mon, 28 Jan 2019, Julien Grall wrote:

While SPIs are shared between CPU, it is not possible to receive the
same interrupts on a different CPU while the interrupt is in active
state. The deactivation of the interrupt is done at the end of the
handling.

This means the _IRQ_PENDING logic is unecessary on Arm as a same
interrupt can never come up while in the loop. So remove it to
simplify the interrupt handle code.

Signed-off-by: Julien Grall 
---
  xen/arch/arm/irq.c | 32 ++--
  1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
index c51cf333ce..3877657a52 100644
--- a/xen/arch/arm/irq.c
+++ b/xen/arch/arm/irq.c
@@ -199,6 +199,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
  {
  struct irq_desc *desc = irq_to_desc(irq);
+struct irqaction *action;
  
  perfc_incr(irqs);
  
@@ -242,35 +243,22 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)

  goto out_no_end;
  }
  
-set_bit(_IRQ_PENDING, >status);

-
-/*
- * Since we set PENDING, if another processor is handling a different
- * instance of this same irq, the other processor will take care of it.
- */
-if ( test_bit(_IRQ_DISABLED, >status) ||
- test_bit(_IRQ_INPROGRESS, >status) )
+if ( test_bit(_IRQ_DISABLED, >status) )
  goto out;


It is a good idea to remove the IRQ_PENDING logic, that is OK.


However, are we sure that we want to remove the _IRQ_INPROGRESS check
too? IRQ handlers shouldn't be called twice in a row. Given that
_IRQ_INPROGRESS can be set manually (gicv2_set_active_state) it seems it
would be a good idea to keep the check anyway?


set_active_state is only used by the vGIC to replicate state from of the 
virtual interrupt to the physical interrupt. We don't have the virtual 
interrupt in this path (see above).


Any other user (e.g interrupts routed to Xen) would be pretty broken. At 
best you would break the interrupt flow. At worst, you may never receive 
the interrupt again.


So I think we can drop _IRQ_PROGRESS here.

Cheers,

--
Julien Grall

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10   fail REGR. vs. 133580
 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 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-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-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux6d0a598489ca687e1ebac37eef546526eca41347
baseline version:
 linux736706bee3298208343a76096370e4f6a5c55915

Last test of basis   133580  2019-03-04 19:53:09 Z   43 days
Failing since133605  2019-03-05 20:03:14 Z   42 days   23 attempts
Testing same since   134749  2019-04-13 09:32:57 Z3 days1 attempts


2269 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH for-next] xen/arm: irq: Don't use _IRQ_PENDING when handling host interrupt

[Stefano Stabellini]

On Mon, 28 Jan 2019, Julien Grall wrote:
> While SPIs are shared between CPU, it is not possible to receive the
> same interrupts on a different CPU while the interrupt is in active
> state. The deactivation of the interrupt is done at the end of the
> handling.
> 
> This means the _IRQ_PENDING logic is unecessary on Arm as a same
> interrupt can never come up while in the loop. So remove it to
> simplify the interrupt handle code.
> 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/irq.c | 32 ++--
>  1 file changed, 10 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index c51cf333ce..3877657a52 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -199,6 +199,7 @@ int request_irq(unsigned int irq, unsigned int irqflags,
>  void do_IRQ(struct cpu_user_regs *regs, unsigned int irq, int is_fiq)
>  {
>  struct irq_desc *desc = irq_to_desc(irq);
> +struct irqaction *action;
>  
>  perfc_incr(irqs);
>  
> @@ -242,35 +243,22 @@ void do_IRQ(struct cpu_user_regs *regs, unsigned int 
> irq, int is_fiq)
>  goto out_no_end;
>  }
>  
> -set_bit(_IRQ_PENDING, >status);
> -
> -/*
> - * Since we set PENDING, if another processor is handling a different
> - * instance of this same irq, the other processor will take care of it.
> - */
> -if ( test_bit(_IRQ_DISABLED, >status) ||
> - test_bit(_IRQ_INPROGRESS, >status) )
> +if ( test_bit(_IRQ_DISABLED, >status) )
>  goto out;

It is a good idea to remove the IRQ_PENDING logic, that is OK.


However, are we sure that we want to remove the _IRQ_INPROGRESS check
too? IRQ handlers shouldn't be called twice in a row. Given that
_IRQ_INPROGRESS can be set manually (gicv2_set_active_state) it seems it
would be a good idea to keep the check anyway?


>  set_bit(_IRQ_INPROGRESS, >status);
>  
> -while ( test_bit(_IRQ_PENDING, >status) )
> -{
> -struct irqaction *action;
> +action = desc->action;
>  
> -clear_bit(_IRQ_PENDING, >status);
> -action = desc->action;
> +spin_unlock_irq(>lock);
>  
> -spin_unlock_irq(>lock);
> -
> -do
> -{
> -action->handler(irq, action->dev_id, regs);
> -action = action->next;
> -} while ( action );
> +do
> +{
> +action->handler(irq, action->dev_id, regs);
> +action = action->next;
> +} while ( action );
>  
> -spin_lock_irq(>lock);
> -}
> +spin_lock_irq(>lock);
>  
>  clear_bit(_IRQ_INPROGRESS, >status);
>  
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH] xen/arm: kernel: Remove Dom prefix when using %pd format

[Stefano Stabellini]

On Tue, 19 Mar 2019, Julien Grall wrote:
> The format %pd will already prefix the domain ID with 'd'. So avoid to
> prefix with 'Dom'.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 

> ---
>  xen/arch/arm/kernel.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index d04a862f99..e3ffdb2fa1 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -484,7 +484,7 @@ int __init kernel_probe(struct kernel_info *info,
>  return -ENOENT;
>  }
>  
> -printk("Loading Dom%pd kernel from boot module @ %"PRIpaddr"\n",
> +printk("Loading %pd kernel from boot module @ %"PRIpaddr"\n",
> info->d, info->kernel_bootmodule->start);
>  if ( info->initrd_bootmodule )
>  printk("Loading ramdisk from boot module @ %"PRIpaddr"\n",
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH] xen/arm64: head: Combine lsl and str instructions in a single one

[Stefano Stabellini]

On Tue, 19 Mar 2019, Julien Grall wrote:
> From: Julien Grall 
> 
> We can optimize a bit the assembly code by combining the 2 instructions
> in a single one. This likely not going to make the code faster, but
> likely make easier to read the assembly.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/arch/arm/arm64/head.S | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
> index 0b7f6e7f92..4589a37874 100644
> --- a/xen/arch/arm/arm64/head.S
> +++ b/xen/arch/arm/arm64/head.S
> @@ -418,8 +418,7 @@ skip_bss:
>  
>  mov   x3, #PT_PT /* x2 := table map of boot_first_id */
>  orr   x2, x2, x3 /*   + rights for linear PT */
> -lsl   x1, x1, #3 /* x1 := Slot offset */
> -str   x2, [x4, x1]
> +str   x2, [x4, x1, lsl #3]
>  
>  load_paddr x4, boot_first_id
>  
> @@ -428,8 +427,7 @@ skip_bss:
>  mov   x3, #PT_MEM/* x2 := Section map */
>  orr   x2, x2, x3
>  and   x1, x1, #LPAE_ENTRY_MASK /* x1 := Slot offset */
> -lsl   x1, x1, #3
> -str   x2, [x4, x1]   /* Mapping of paddr(start) */
> +str   x2, [x4, x1, lsl #3]   /* Mapping of paddr(start) */
>  mov   x25, #1/* x25 := identity map now in place */
>  
>  1:  /* Setup boot_first: */
> @@ -450,8 +448,7 @@ skip_bss:
>  lsl   x2, x2, #FIRST_SHIFT   /* Base address for 1GB mapping */
>  mov   x3, #PT_MEM/* x2 := Section map */
>  orr   x2, x2, x3
> -lsl   x1, x1, #3 /* x1 := Slot offset */
> -str   x2, [x4, x1]   /* Create mapping of paddr(start)*/
> +str   x2, [x4, x1, lsl #3]   /* Create mapping of paddr(start)*/
>  mov   x25, #1/* x25 := identity map now in place */
>  
>  1:  /* Setup boot_second: */
> @@ -473,8 +470,7 @@ skip_bss:
>  lsl   x2, x2, #SECOND_SHIFT  /* Base address for 2MB mapping */
>  mov   x3, #PT_MEM/* x2 := Section map */
>  orr   x2, x2, x3
> -lsl   x1, x1, #3 /* x1 := Slot offset */
> -str   x2, [x4, x1]   /* Create mapping of paddr(start)*/
> +str   x2, [x4, x1, lsl #3]   /* Create mapping of paddr(start)*/
>  mov   x25, #1/* x25 := identity map now in place */
>  
>  1:  /* Setup boot_third: */
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 4/4] xen/console: Simplify domU console handling in guest_console_write

[Stefano Stabellini]

On Tue, 2 Apr 2019, Julien Grall wrote:
> 2 paths in the domU console handling are now the same. So they can be
> merged to make the code simpler.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  xen/drivers/char/console.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
> 
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index b119bf980b..5483d66512 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -584,13 +584,8 @@ static long 
> guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, int count)
>  *kout = '\0';
>  spin_lock(>pbuf_lock);
>  kcount = kin - kbuf;
> -if ( c == '\n' )
> -{
> -cd->pbuf[cd->pbuf_idx] = '\0';
> -guest_printk(cd, XENLOG_G_DEBUG "%s%s\n", cd->pbuf, kbuf);
> -cd->pbuf_idx = 0;
> -}
> -else if ( cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1) )
> +if ( c != '\n' &&
> +(cd->pbuf_idx + (kout - kbuf) < (DOMAIN_PBUF_SIZE - 1)) )
>  {
>  /* buffer the output until a newline */
>  memcpy(cd->pbuf + cd->pbuf_idx, kbuf, kout - kbuf);
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

[Stefano Stabellini]

On Tue, 2 Apr 2019, Julien Grall wrote:
> Currently, OS developpers will have to look at Xen code in order to know
> the parameters of an hypercall and how it is meant to work.
> 
> This is not a trivial task as you may need to have a deep understanding
> of Xen internal.
> 
> This patch attempts to document the behavior of HYPERCALL_console_io() to
> help OS developer.
> 
> Signed-off-by: Julien Grall 

I love this, thank you!


> ---
> 
> This is a first attempt to address the lack on documentation for
> hypercalls. We may want to decide a format to use in every hypercall so
> it can be readable for the OS developer and easily consummed by
> documentation tools.
> ---
>  xen/include/public/xen.h | 21 -
>  1 file changed, 20 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
> index ccdffc0ad1..7c119c6782 100644
> --- a/xen/include/public/xen.h
> +++ b/xen/include/public/xen.h
> @@ -97,6 +97,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
>  #define __HYPERVISOR_set_timer_op 15
>  #define __HYPERVISOR_event_channel_op_compat 16 /* compat since 0x00030202 */
>  #define __HYPERVISOR_xen_version  17
> +/* HYPERVISOR_console_io(int cmd, int count, XEN_GUEST_HANDLE(char) buffer); 
> */

I agree with Jan: I wouldn't put this comment here. Maybe down below
with the other comment. The reason is that I think it would be best not
to break the simple list of hypercall numbers.


>  #define __HYPERVISOR_console_io   18
>  #define __HYPERVISOR_physdev_op_compat19 /* compat since 0x00030202 */
>  #define __HYPERVISOR_grant_table_op   20
> @@ -486,7 +487,25 @@ DEFINE_XEN_GUEST_HANDLE(mmuext_op_t);
>  /* ` } */
>  
>  /*
> - * Commands to HYPERVISOR_console_io().
> + * Commands to HYPERVISOR_console_io()
> + *
> + * @cmd: Command (see below)
> + * @count: Size of the buffer to read/write
> + * @buffer: Pointer in the guest memory
> + *
> + * List of commands:
> + *
> + *  * CONSOLEIO_write: Write the buffer on Xen console.
> + *  For the hardware domain, all the characters in the buffer will
> + *  be written. Characters will be printed to directly to the
> + *  console.
> + *  For all the other domains, only the printable characters will be
> + *  written. Characters may be buffered until a newline (i.e '\n') is
> + *  found.
> + *  Return 0 on success, otherwise return an error code.
> + *  * CONSOLE_read: Attempts to read up @count characters from Xen console.
> + *  Return the number of character read on success, otherwise return
> + *  an error code.

This is great! My only suggestion for improvement would be to use a
special annotation for the return value. I think it would make it easier
to spot. Maybe something like @return:

 * CONSOLEIO_write: Write the buffer on Xen console.
 For the hardware domain, all the characters in the buffer will
 be written. Characters will be printed to directly to the
 console.
 For all the other domains, only the printable characters will be
 written. Characters may be buffered until a newline (i.e '\n') is
 found.
 @return: 0 on success, otherwise return an error code.
 * CONSOLE_read: Attempts to read up @count characters from Xen console.
 @return: the number of character read on success, otherwise return
  an error code.


>  #define CONSOLEIO_write 0
>  #define CONSOLEIO_read  1
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH 2/4] xen/console: Don't treat NUL character as the end of the buffer

[Stefano Stabellini]

On Tue, 2 Apr 2019, Julien Grall wrote:
> After upgrading Debian to Buster, I have began to notice console
> mangling when using zsh in Dom0. This is happenning because output sent by
> zsh to the console may contain NULs in the middle of the buffer.
> 
> The actual implementation of CONSOLEIO_write considers that a buffer
> always terminate with a NUL and therefore will ignore anything after it.
> 
> In general, NULs are perfectly legitimate in terminal streams. For
> instance, this could be used for padding slow terminals. See terminfo(5)
> section `Delays and Padding`, or search for the pcre '\bpad'.
> 
> Other use cases includes using the console for dumping non-human
> readable information (e.g debugger, file if no network...). With the
> current behavior, the resulting stream will end up to be corrupted.
> 
> The documentation for CONSOLEIO_write is pretty limited (to not say
> inexistent). From the declaration, the hypercall takes a buffer and size.
> So this could lead to think the NUL character is allowed in the middle of
> the buffer.
> 
> This patch updates the console API to pass the size along the buffer
> down so we can remove the reliance on buffer terminating by a NUL
> character.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> This patch was originally sent standalone [1]. But the series grows to
> include another bug found in the console code and documentation.
> 
> Change since the standalone version:
> - Fix early printk on Arm
> - Fix gdbstub
> - Remove unecessary leading NUL character added by Xen
> - Handle DomU console
> - Rework the commit message
> 
> Below a small C program to repro the bug on Xen:
> 
> int main(void)
> {
> write(1,
>   
> "\r\33[0m\0\0\0\0\0\0\0\0\33[27m\33[24m\33[j\33[32mjulien\33[31m@\33[00m\33[36mjuno2-julieng:~\33[37m>",
>   75);
> write(1,
>   
> "\33[K\33[32C\33[01;33m--juno2-julieng-13:44--\33[00m\33[37m\33[55D",
>   54);
> write(1, "\33[?2004h", 8);
> 
> return 0;
> }
> 
> Without this patch, the only --juno2-julieng-13:44-- will be printed in
> yellow.
> 
> This patch was tested on Arm using serial console. I am not entirely
> sure whether the video and PV console is correct. I would appreciate help
> for testing here.
> 
> [1] https://lists.xenproject.org/archives/html/xen-devel/2019-02/msg01932.html
> ---
>  xen/arch/arm/early_printk.c   |  5 ++--
>  xen/common/gdbstub.c  |  6 ++--
>  xen/drivers/char/console.c| 58 
> +++
>  xen/drivers/char/consoled.c   |  7 ++---
>  xen/drivers/char/serial.c |  8 --
>  xen/drivers/char/xen_pv_console.c | 10 +++
>  xen/drivers/video/lfb.c   | 14 ++
>  xen/drivers/video/lfb.h   |  4 +--
>  xen/drivers/video/vga.c   | 14 ++
>  xen/include/xen/console.h |  2 +-
>  xen/include/xen/early_printk.h|  2 +-
>  xen/include/xen/pv_console.h  |  4 +--
>  xen/include/xen/serial.h  |  4 +--
>  xen/include/xen/video.h   |  4 +--
>  14 files changed, 73 insertions(+), 69 deletions(-)
> 
> diff --git a/xen/arch/arm/early_printk.c b/xen/arch/arm/early_printk.c
> index 97466a12b1..35a47c7229 100644
> --- a/xen/arch/arm/early_printk.c
> +++ b/xen/arch/arm/early_printk.c
> @@ -17,9 +17,10 @@
>  void early_putch(char c);
>  void early_flush(void);
>  
> -void early_puts(const char *s)
> +void early_puts(const char *s, unsigned int nr)
>  {
> -while (*s != '\0') {
> +while ( nr-- > 0 )
> +{
>  if (*s == '\n')
>  early_putch('\r');
>  early_putch(*s);
> diff --git a/xen/common/gdbstub.c b/xen/common/gdbstub.c
> index 07095e1ec7..08a4dda9f3 100644
> --- a/xen/common/gdbstub.c
> +++ b/xen/common/gdbstub.c
> @@ -68,7 +68,7 @@ static void gdb_smp_resume(void);
>  static char __initdata opt_gdb[30];
>  string_param("gdb", opt_gdb);
>  
> -static void gdbstub_console_puts(const char *str);
> +static void gdbstub_console_puts(const char *str, unsigned int nr);
>  
>  /* value <-> char (de)serialzers */
>  static char
> @@ -546,14 +546,14 @@ __gdb_ctx = {
>  static struct gdb_context *gdb_ctx = &__gdb_ctx;
>  
>  static void
> -gdbstub_console_puts(const char *str)
> +gdbstub_console_puts(const char *str, unsigned int nr)
>  {
>  const char *p;
>  
>  gdb_start_packet(gdb_ctx);
>  gdb_write_to_packet_char('O', gdb_ctx);
>  
> -for ( p = str; *p != '\0'; p++ )
> +for ( p = str; nr > 0; p++, nr-- )
>  {
>  gdb_write_to_packet_char(hex2char((*p>>4) & 0x0f), gdb_ctx );
>  gdb_write_to_packet_char(hex2char((*p) & 0x0f), gdb_ctx );
> diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
> index 9bbcb0f57a..b119bf980b 100644
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -325,9 +325,9 @@ long read_console_ring(struct xen_sysctl_readconsole *op)
>  static char serial_rx_ring[SERIAL_RX_SIZE];
>  static unsigned int 

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   25 days
Failing since134068  2019-03-25 12:00:51 Z   22 days  113 attempts
Testing same since   134834  2019-04-15 19:00:48 Z1 days7 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

Re: [Xen-devel] [PATCH] x86/shadow: Drop incorrect diagnostic when shadowing TSS.RSP0

[Tim Deegan]

At 13:32 +0100 on 08 Apr (1554730320), Andrew Cooper wrote:
> On 08/04/2019 13:11, Jan Beulich wrote:
>  On 08.04.19 at 13:37,  wrote:
> >> On 08/04/2019 11:14, Jan Beulich wrote:
> >> On 05.04.19 at 21:09,  wrote:
>  --- a/xen/arch/x86/mm/shadow/multi.c
>  +++ b/xen/arch/x86/mm/shadow/multi.c
>  @@ -3305,8 +3305,9 @@ static int sh_page_fault(struct vcpu *v,
>   {
>   /*
>    * If we are in the middle of injecting an exception or 
>  interrupt then
>  - * we should not emulate: it is not the instruction at %eip 
>  that caused
>  - * the fault. Furthermore it is almost certainly the case the 
>  handler
>  + * we should not emulate: the fault is a side effect of the 
>  processor
>  + * trying to push an exception frame onto a stack which has yet 
>  to be
>  + * shadowed.  Furthermore it is almost certainly the case the 
>  handler
>    * stack is currently considered to be a page table, so we 
>  should
>    * unshadow the faulting page before exiting.
>    */
> > I'm (at least) mildly confused: I follow what you write (I think), but
> > you again say "the stack always becomes shadowed". My original
> > question was whether you really mean that, as stacks, if at all,
> > should get shadowed only unintentionally (and hence get un-shadowed
> > immediately when that condition is detected). That is, my (slightly
> > rephrased) question stands: Do you perhaps mean the page tables
> > mapping the stack to become shadowed, rather than the stack itself?
> 
> I guess this is an issue of terminology, to which I defer to Tim to judge.

Hi,

Sorry for the delay; I have been away.

FWIW I prefer the original comment, and I think that referring to the
stack as "not yet shadowed" is confusing when the problem might be
that the stack itself is indeed shadowed.  I'd also be happy with just
saying "the fault is a side effect of the processor trying to push an
exception frame onto the stack."

Happy to see the debug message being removed if it's being triggered
in the real world.  IIRC it has not proved to be useful since that
code was first developed.  So, with the comment adjusted,
Acked-by: Tim Deegan 

Cheers,

Tim.

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

Re: [Xen-devel] [PATCH RFC 01/49] xen/sched: call cpu_disable_scheduler() via cpu notifier

[Stefano Stabellini]

On Mon, 1 Apr 2019, Julien Grall wrote:
> Hi,
> 
> On 4/1/19 10:40 AM, Juergen Gross wrote:
> > On 01/04/2019 11:21, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 3/29/19 3:08 PM, Juergen Gross wrote:
> > > > cpu_disable_scheduler() is being called from __cpu_disable() today.
> > > > There is no need to execute it on the cpu just being disabled, so use
> > > > the CPU_DEAD case of the cpu notifier chain. Moving the call out of
> > > > stop_machine() context is fine, as we just need to hold the domain RCU
> > > > lock and need the scheduler percpu data to be still allocated.
> > > > 
> > > > Add another hook for CPU_DOWN_PREPARE to bail out early in case
> > > > cpu_disable_scheduler() would fail. This will avoid crashes in rare
> > > > cases for cpu hotplug or suspend.
> > > > 
> > > > While at it remove a superfluous smp_mb() in the ARM __cpu_disable()
> > > > incarnation.
> > > 
> > > This is not obvious why the smp_mb() is superfluous. Can you please
> > > provide more details on why this is not necessary?
> > 
> > cpumask_clear_cpu() should already have the needed semantics, no?
> > It is based on clear_bit() which is defined to be atomic.
> 
> atomicity does not mean the store/load cannot be re-ordered by the CPU. You
> would need a barrier to prevent re-ordering.
> 
> cpumask_clear_cpu() and clear_bit() does not contain any barrier, so
> store/load can be re-ordered.
> 
> I see we have similar smp_mb() barrier in __cpu_die(). Sadly, there are no
> documentation in the code why the barrier is here. The logs don't help either.
> 
> The barrier here will ensure that the load/store related to disabling the CPU
> are seen before any load/store happening after the return. Although, I am not
> sure why this is necessary.
> 
> Stefano, Do you remember the rationale?

/me doing some archeology

I am pretty sure it was meant to accompany the cpumask_clear_cpu call. I
think we should keep it in __cpu_disable right after cpumask_clear_cpu.

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

Re: [Xen-devel] [PATCH] SUPPORT.md: Specify support lifetime for 4.12

[Stefano Stabellini]

On Mon, 1 Apr 2019, Ian Jackson wrote:
> CC: Lars Kurth 
> CC: Juergen Gross 
> Signed-off-by: Ian Jackson 
> ---
>  SUPPORT.md | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/SUPPORT.md b/SUPPORT.md
> index 19fc8d7533..d4173d70ad 100644
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -9,10 +9,10 @@ for the definitions of the support status levels etc.
>  
>  # Release Support
>  
> -Xen-Version: 4.12-rc
> -Initial-Release: n/a
> -Supported-Until: TBD
> -Security-Support-Until: Unreleased - not yet security-supported
> +Xen-Version: 4.12
> +Initial-Release: TBD
> +Supported-Until: 2020-10-02
> +Security-Support-Until: 2022-04-02
>  
>  Release Notes
>  :  href="https://wiki.xenproject.org/wiki/Xen_Project_X.YY_Release_Notes;>RN

I don't know about the specific of the dates chosen, but I am a great
fun of having them in SUPPORT.md. Thank you!

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

Re: [Xen-devel] booting domU guest as pvh works in xen-4.11.1 but fails in 4.12

[Pry Mar]

On 4/16/19, Roger Pau Monné  wrote:
> On Mon, Apr 15, 2019 at 04:18:57PM -0700, Pry Mar wrote:
>> Hello,
>>
>> https://paste.debian.net/1077718/
>>
>> I get a kernel panic as shown in the paste above no matter how I
>> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
>> pvgrub2 (i386-xen_pvh support).
>>
>> The dom0 here is ub1804, kernel-4.18, and xen-4.12 with debian
>> packages (self built).
>> ~$ sudo dpkg -l | grep -P 'xen|qemu' | grep '^ii'
>> ii  libxen-4.12:amd64  4.12.0-1+ub18u04.1amd64
>>Public libs for Xen
>> ii  libxenstore3.0:amd64  4.12.0-1+ub18u04.1amd64
>>   Xenstore communications library for Xen
>> ii  libxentoolcore1:amd64  4.12.0-1+ub18u04.1amd64
>>helper for qemu & libxenstore
>> ii  qemuu 3.1.0-1+ub18u04.1 amd64
>> qemu-system-i386 (3.1.0/xen-4.12) with 9pfs support
>> ii  xen-hypervisor-4.12-amd64 4.12.0-1+ub18u04.1
>>  amd64Xen Hypervisor on AMD64
>> ii  xen-utils-4.124.12.0-1+ub18u04.1
>>  amd64XEN administrative tools
>> ii  xen-utils-common  4.12.0-1+ub18u04.1
>>  all  Xen administrative tools - common files
>> ii  xen-virbr00.1-2
>>  all  Setup a virbr0 bridge and dnsmasq on a
>> ii  xenstore-utils4.12.0-1+ub18u04.1
>>  amd64Xenstore command line utilities for Xen
>>
>> The same xl config and grub config works in xen-4.11.1. I've searched
>> for any new options in xl.cfg that could influence this, but nothing
>> catches my eye.
>
> Do same kernel and initrd work fine when booted as PV or HVM?
>
> Thanks, Roger.
>
yes, I tried PV, but not HVM. None of the ld*.so errors appear
traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95
sp:7ffe3099cdb8 error:0 in ld-2.29.so[7f797dc61000+21000]

the log is similar as booting pvh in 4.11.1 for pv.

hth,
PryMar56

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

[Xen-devel] [linux-4.19 test] 134743: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken  in 134615
 build-arm64  broken  in 134615
 build-arm64-xsm  broken  in 134615
 build-arm64-xsm4 host-install(4) broken in 134615 REGR. vs. 129313
 build-arm644 host-install(4) broken in 134615 REGR. vs. 129313
 build-arm64-pvops  4 host-install(4) broken in 134615 REGR. vs. 129313
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 129313
 test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 129313
 build-i386-pvops  6 kernel-build fail REGR. vs. 129313
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail pass in 134615

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 134615 n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked in 134615 n/a
 build-arm64-libvirt   1 build-check(1)   blocked in 134615 n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked in 134615 n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked in 134615 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 134615 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 134615 n/a
 test-amd64-i386-examine   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 guest-start  fail in 134615 never pass
 

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 0eccea3fbe2f6d4999d972d9310d4f2717f5100c
baseline version:
 ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33

Last test of basis   134640  2019-04-11 13:15:51 Z5 days
Failing since134738  2019-04-13 03:33:26 Z3 days8 attempts
Testing same since   134852  2019-04-16 06:41:35 Z0 days3 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bret Barkelew 
  Chasel Chiu 
  Chasel, Chiu 
  Christian Rodriguez 
  Dandan Bi 
  Dong, Guo 
  Fan, ZhijuX 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Rodriguez, Christian 
  Shenglei Zhang 
  Zhichao Gao 
  Zhiju.Fan 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   fail
 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


Not pushing.

(No revision log; it would be 417 lines long.)

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

[Xen-devel] [xen-4.8-testing test] 134735: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   6 xen-buildfail REGR. vs. 130965
 build-i386-prev   6 xen-buildfail REGR. vs. 130965
 build-i386-xsm6 xen-buildfail REGR. vs. 130965
 build-amd64   6 xen-buildfail REGR. vs. 130965
 build-amd64-prev  6 xen-buildfail REGR. vs. 130965
 build-i3866 xen-buildfail REGR. vs. 130965

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-shadow1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-livepatch1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked 

[Xen-devel] [qemu-mainline bisection] complete test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid guest-saverestore

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  d97a39d903fe33c45be83ac6943a2f82a3649a11
  Bug not present: b3fc0af1ff5e922d4dd7c875394dbd26dc7313b4
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/134868/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/qemu-mainline/test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm.guest-saverestore.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm.guest-saverestore
 --summary-out=tmp/134868.bisection-summary --basis-template=133909 
--blessings=real,real-bisect qemu-mainline 
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm guest-saverestore
Searching for failure / basis pass:
 133997 fail [host=elbling1] / 133909 [host=fiano1] 133872 [host=merlot0] 
133791 [host=debina1] 133750 [host=chardonnay1] 133703 [host=rimava1] 133677 
[host=baroque0] 133650 [host=pinot1] 133613 [host=albana1] 133589 
[host=baroque1] 133576 [host=merlot1] 133552 [host=italia1] 133503 
[host=albana0] 133467 [host=italia0] 133284 [host=italia1] 133267 
[host=albana1] 132945 [host=baroque0] 132847 [host=baroque1] 132772 ok.
Failure / basis pass flights: 133997 / 132772
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 25e2e4e04f13901b3db903b2301bd11381bdf128 
8089c00979a5b089cff592c6b91420e595657167 
16e5b0787687d8904dad2c026107409eb9bfcb95 
5726a8d0f1958af80ad8e514bc2c18d213e739b7 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
d97a39d903fe33c45be83ac6943a2f82a3649a11 
59e9783ddf18e650622e0573cad4f08db65592e4
Basis pass d56afb8e3997ae19fd7449f773065a2b997dc7c1 
8089c00979a5b089cff592c6b91420e595657167 
16e5b0787687d8904dad2c026107409eb9bfcb95 
e1e364bf09d92018d35f20a004ffcfd4cbeffa34 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
b3fc0af1ff5e922d4dd7c875394dbd26dc7313b4 
f50dd67950ca9d5a517501af10de7c8d88d1a188
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#d56afb8e3997ae19fd7449f773065a2b997dc7c1-25e2e4e04f13901b3db903b2301bd11381bdf128
 
https://git.savannah.gnu.org/git/gnulib.git/#8089c00979a5b089cff592c6b91420e595657167-8089c00979a5b089cff592c6b91420e595657167
 
https://gitlab.com/keycodemap/keycodemapdb.git#16e5b0787687d8904dad2c026107409eb9bfcb95-16e5b0787687d8904dad2c026107409eb9bfcb95
 git://xenbits.xen.org/linux-pvops.git#e1e364bf09d92018d35f20a004ffcfd4cbef\
 fa34-5726a8d0f1958af80ad8e514bc2c18d213e739b7 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://git.qemu.org/qemu.git#b3fc0af1ff5e922d4dd7c875394dbd26dc7313b4-d97a39d903fe33c45be83ac6943a2f82a3649a11
 
git://xenbits.xen.org/xen.git#f50dd67950ca9d5a517501af10de7c8d88d1a188-59e9783ddf18e\
 650622e0573cad4f08db65592e4
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to 
remove them.

From git://cache:9419/git://git.qemu.org/qemu
   a9b305ba29..dbfc49b69a  master -> origin/master
adhoc-revtuple-generator: tree discontiguous: qemu
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the 

Re: [Xen-devel] Xen 4.12.0-rc Hangs Around masked ExtINT on CPU#

[John L. Poole]

On 3/27/2019 7:21 AM, Jan Beulich wrote:

On 27.03.19 at 14:25,  wrote:

On 3/27/2019 1:14 AM, Jan Beulich wrote:

On 26.03.19 at 18:21,  wrote:

zeta /usr/local/src/xen # cat xen/.config |grep CONFIG_HVM
# CONFIG_HVM is not set
zeta /usr/local/src/xen #

# tried 2 boot attempts
log at: https://pastebin.com/nL4BWJ6Y

Hang points at lines:

Thanks for trying anyway; one further possibility eliminated. Looking
at the logs I've had another thought (wild guess again, so not really
much hope): Could you try "mwait-idle=no"?


I modified man_xen.cfg by adding at the end the kernel parameter:

mwait-idle=no

Rebooted.
Result: hung:

Thanks. I'm afraid I'm out of ideas for the moment.

Jan



Jan,

Recall, the Xen kernel successfully launched in 2017 when I first built
Xen in Gentoo, that was about version 4.7.1.  I had to launch it
from an EFI console.  I've tried to revert back to 4.7.1 and
build a kernel and I have found it too difficult as certain
dependencies have since been removed from Gentoo.

I've been studying apic.c and the differences between 4.7.1
and HEAD.  Here's a DIFF:

http://quickdiff.net/?unique_id=948598C4-31A2-D028-CE95-F04632C1871A
Create a new one? 

I see that currently there is a structure:

static const struct x86_cpu_id __initconstrel deadline_match[] = {

which identifies the microarchitecture, e.g. Haswell, Skylake.

https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/apic.c;h=2a2432619e3edce2cdbc275abbd4e80ffcdcd9f0;hb=HEAD#l1146


Line 1176 has a return if there is a failure to match, yet further down 
if there

is a version mismatch, there is a XENLOG_WARNING:

TSC_DEADLINE disabled due to Errata;
please update microcode to version %#x (or later)


My serveris Atom based, a Supermicro A1SAi-2750F
https://www.supermicro.com/products/motherboard/Atom/X10/A1SAi-2750F.cfm
which has an Intel® Atom™ Processor C2750.

https://ark.intel.com/content/www/us/en/ark/products/77987/intel-atom-processor-c2750-4m-cache-2-40-ghz.html

I believe my CPU chip is from a 22 nanometer fabrication process and
Wikipedia tells me that accordingly, the microarchitecture is Silvermont.
https://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures#Atom_Lines

Moreover, the Intel documentation confirms this:

"2.1.15 The Intel® Atom™ Processor Family Based on Silvermont 
Microarchitecture (2013)

Intel Atom Processor C2xxx, E3xxx, S1xxx series are based on the
Silvermont microarchitecture. Processors based on the Silvermont
microarchitecture supports instruction set extensions up to and
including SSE4.2, AESNI, and PCLMULQDQ."  from page 2-5 of the
Software Developer’s Manual (below).

I'm wondering if the fact that I was able to boot a kernel under Xen 2.4.7
and the unexplained hanging at boot for 4.7.12+ is related to the fact 
that the

Silvermont architecture is not accounted from in the deadline structure.

sheet 784-5 states that bit 24 "TSC-Deadline" with this description:
"A value of 1 indicates that the processor’s local APIC timer supports
one-shot operation using a TSC deadline value."

from the Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Combined Volumes:
1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4

at:
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

Is any of the above bird-dogging helpful or cause you to have an
"Ahah!" moment?

John




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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   25 days
Failing since134068  2019-03-25 12:00:51 Z   22 days  112 attempts
Testing same since   134834  2019-04-15 19:00:48 Z0 days6 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

Re: [Xen-devel] [PATCH -next] xen-swiotlb: Make two functions static

[Boris Ostrovsky]

On 4/16/19 10:49 AM, Yue Haibing wrote:
> From: YueHaibing 
>
> Fix sparse warnings:
>
> drivers/xen/swiotlb-xen.c:489:1: warning:
>  symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be 
> static?
> drivers/xen/swiotlb-xen.c:496:1: warning:
>  symbol 'xen_swiotlb_sync_single_for_device' was not declared. Should it be 
> static?
>
> Reported-by: Hulk Robot 
> Signed-off-by: YueHaibing 


I think latest patches from Christoph take care of this.

-boris


> ---
>  drivers/xen/swiotlb-xen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
> index 877baf2..e741df4 100644
> --- a/drivers/xen/swiotlb-xen.c
> +++ b/drivers/xen/swiotlb-xen.c
> @@ -485,14 +485,14 @@ xen_swiotlb_sync_single(struct device *hwdev, 
> dma_addr_t dev_addr,
>   xen_dma_sync_single_for_device(hwdev, dev_addr, size, dir);
>  }
>  
> -void
> +static void
>  xen_swiotlb_sync_single_for_cpu(struct device *hwdev, dma_addr_t dev_addr,
>   size_t size, enum dma_data_direction dir)
>  {
>   xen_swiotlb_sync_single(hwdev, dev_addr, size, dir, SYNC_FOR_CPU);
>  }
>  
> -void
> +static void
>  xen_swiotlb_sync_single_for_device(struct device *hwdev, dma_addr_t dev_addr,
>  size_t size, enum dma_data_direction dir)
>  {


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

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[George Dunlap]

On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 8:02 AM George Dunlap  
> wrote:
>>
>> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
>>> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>>>  wrote:

 The code for getting the entry and then populating was repeated in
 p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().

 The code is now in one place with a bool param that lets the caller choose
 if it populates after get_entry().

 If remapping is being done then both the old and new gfn's should be
 unshared in the hostp2m for keeping things consistent. The page type
 of old_gfn was already checked whether it's p2m_ram_rw and bail if it
 wasn't so functionality-wise this just simplifies things as a user
 doesn't have to request unsharing manually before remapping.
 Now, if the new_gfn is invalid it shouldn't query the hostp2m as
 that is effectively a request to remove the entry from the altp2m.
 But provided that scenario is used only when removing entries that
 were previously remapped/copied to the altp2m, those entries already
 went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
 affect so the core function get_altp2m_entry() is calling
 __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.

 altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
 because on a new altp2m view the function will fail with invalid mfn if
 p2m->set_entry() was not called before.

 Signed-off-by: Alexandru Isaila 
 Signed-off-by: George Dunlap 
 Reviewed-by: George Dunlap 

 ---
 Changes since V4:
 - Add altp2m to patch name
 - Change func name from get_altp2m_entry() to
 altp2m_get_entry().
 ---
  xen/arch/x86/mm/mem_access.c | 30 ++---
  xen/arch/x86/mm/p2m.c| 84 
  xen/include/asm-x86/p2m.h| 17 
  3 files changed, 66 insertions(+), 65 deletions(-)

 diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
 index a144bb0ce4..ddfe0169c0 100644
 --- a/xen/arch/x86/mm/mem_access.c
 +++ b/xen/arch/x86/mm/mem_access.c
 @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, 
 struct p2m_domain *hp2m,
  mfn_t mfn;
  p2m_type_t t;
  p2m_access_t old_a;
 -unsigned int page_order;
 -unsigned long gfn_l = gfn_x(gfn);
  int rc;

 -mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
 -
 -/* Check host p2m if no valid entry in alternate */
 -if ( !mfn_valid(mfn) )
 -{
 -
 -mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
 -P2M_ALLOC | P2M_UNSHARE, _order, 
 0);
 -
 -rc = -ESRCH;
 -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
 -return rc;
 -
 -/* If this is a superpage, copy that first */
 -if ( page_order != PAGE_ORDER_4K )
 -{
 -unsigned long mask = ~((1UL << page_order) - 1);
 -gfn_t gfn2 = _gfn(gfn_l & mask);
 -mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
 -
 -rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 
 1);
 -if ( rc )
 -return rc;
 -}
 -}
 +rc = altp2m_get_entry_prepopulate(ap2m, gfn, , , _a);
 +if ( rc )
 +return rc;

  /*
   * Inherit the old suppress #VE bit value if it is already set, or 
 set it
 diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
 index 9e81a30cc4..7bedfd593b 100644
 --- a/xen/arch/x86/mm/p2m.c
 +++ b/xen/arch/x86/mm/p2m.c
>>>
>>> Wouldn't it make more sense to start adding new altp2m functions to
>>> mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
>>> also be relocated there at some point in the future.
>>>
 @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
  mm_write_unlock(>lock);
  }

 +int altp2m_get_entry(struct p2m_domain *ap2m,
 +gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
 +p2m_access_t *a, bool prepopulate)
 +{
 +*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
 +
 +/* Check host p2m if no valid entry in alternate */
 +if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
 +{
 +struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
 +unsigned int page_order;
 +int rc;
 +
 +*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
 + P2M_ALLOC | P2M_UNSHARE, 
 _order, 0);
>>>
>>> So despite the name being altp2m_get_entry you now return an entry
>>> from the 

Re: [Xen-devel] [PATCH net-next] xen-netfront: mark expected switch fall-through

[Gustavo A. R. Silva]

On 4/16/19 2:17 AM, Juergen Gross wrote:
> On 15/04/2019 23:11, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> This patch fixes the following warning:
>>
>> drivers/net/xen-netfront.c: In function ‘netback_changed’:
>> drivers/net/xen-netfront.c:2038:6: warning: this statement may fall through 
>> [-Wimplicit-fallthrough=]
>>if (dev->state == XenbusStateClosed)
>>   ^
>> drivers/net/xen-netfront.c:2041:2: note: here
>>   case XenbusStateClosing:
>>   ^~~~
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> Notice that, in this particular case, the code comment is modified
>> in accordance with what GCC is expecting to find.
>>
>> This patch is part of the ongoing efforts to enable
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva 
> 
> Reviewed-by: Juergen Gross 
> 

Thanks, Juergen.
--
Gustavo

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

[Xen-devel] [PATCH -next] xen-swiotlb: Make two functions static

[Yue Haibing]

From: YueHaibing 

Fix sparse warnings:

drivers/xen/swiotlb-xen.c:489:1: warning:
 symbol 'xen_swiotlb_sync_single_for_cpu' was not declared. Should it be static?
drivers/xen/swiotlb-xen.c:496:1: warning:
 symbol 'xen_swiotlb_sync_single_for_device' was not declared. Should it be 
static?

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
---
 drivers/xen/swiotlb-xen.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 877baf2..e741df4 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -485,14 +485,14 @@ xen_swiotlb_sync_single(struct device *hwdev, dma_addr_t 
dev_addr,
xen_dma_sync_single_for_device(hwdev, dev_addr, size, dir);
 }
 
-void
+static void
 xen_swiotlb_sync_single_for_cpu(struct device *hwdev, dma_addr_t dev_addr,
size_t size, enum dma_data_direction dir)
 {
xen_swiotlb_sync_single(hwdev, dev_addr, size, dir, SYNC_FOR_CPU);
 }
 
-void
+static void
 xen_swiotlb_sync_single_for_device(struct device *hwdev, dma_addr_t dev_addr,
   size_t size, enum dma_data_direction dir)
 {
-- 
2.7.4



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

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[Tamas K Lengyel]

On Tue, Apr 16, 2019 at 7:58 AM George Dunlap  wrote:
>
> On 4/16/19 2:51 PM, Andrew Cooper wrote:
> > On 16/04/2019 14:44, Tamas K Lengyel wrote:
> >>
> >>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> >>> index 2801a8ccca..8dc4353645 100644
> >>> --- a/xen/include/asm-x86/p2m.h
> >>> +++ b/xen/include/asm-x86/p2m.h
> >>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain 
> >>> *d, mfn_t mfn)
> >>>  return mfn_x(mfn);
> >>>  }
> >>>
> >>> +int altp2m_get_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
> >>> + p2m_type_t *t, p2m_access_t *a, bool prepopulate);
> >>> +
> >>> +static inline int altp2m_get_entry_direct(struct p2m_domain *ap2m,
> >>> +  gfn_t gfn, mfn_t *mfn,
> >>> +  p2m_type_t *t, p2m_access_t *a)
> >>> +{
> >>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, false);
> >>> +}
> >>> +
> >>> +static inline int altp2m_get_entry_prepopulate(struct p2m_domain *ap2m,
> >>> +   gfn_t gfn, mfn_t *mfn,
> >>> +   p2m_type_t *t, 
> >>> p2m_access_t *a)
> >>> +{
> >>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, true);
> >>> +}
> >> Are these wrappers really required? I don't think they add anything to
> >> readability, it's just yet another layer that does almost nothing.
> >
> > From a readability point of view, boolean parameters are about as opaque
> > as they come.  The same goes for all other scalar parameters which don't
> > have a mnemonic.
> >
> > For someone who is not an expert of the intricacies of the subsystem,
> > having the options spelt out in wrappers like this is extremely helpful
> > to reduce the cognitive load of trying to follow the code.
>
> This is exactly why I did it this way.
>
> The other pattern I think is tolerable is having a #define to use as an
> argument; for example:
>
> #define AP2MGET_prepopulate true
> #define AP2MGET_peekfalse
>
> Then you get:
>
>   mfn = altp2m_get_entry(..., AP2MGET_prepopulate);
>
> But then you run into namespacing issues with the prefixes.
>
> I wouldn't object to doing it the above way, but I think the wrappers is
> probably simpler and clearer for this case.  I do object to passing in
> naked booleans.

Fair enough. I personally prefer the #define route though, it just
avoids creating lasagna code. With wrappers by the time I dig through
them trying to figure out where they actually land I tend to forget
why I was looking for it in the first place. Perhaps that's just me..

Tamas

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

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[Tamas K Lengyel]

On Tue, Apr 16, 2019 at 8:02 AM George Dunlap  wrote:
>
> On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
> > On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
> >  wrote:
> >>
> >> The code for getting the entry and then populating was repeated in
> >> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
> >>
> >> The code is now in one place with a bool param that lets the caller choose
> >> if it populates after get_entry().
> >>
> >> If remapping is being done then both the old and new gfn's should be
> >> unshared in the hostp2m for keeping things consistent. The page type
> >> of old_gfn was already checked whether it's p2m_ram_rw and bail if it
> >> wasn't so functionality-wise this just simplifies things as a user
> >> doesn't have to request unsharing manually before remapping.
> >> Now, if the new_gfn is invalid it shouldn't query the hostp2m as
> >> that is effectively a request to remove the entry from the altp2m.
> >> But provided that scenario is used only when removing entries that
> >> were previously remapped/copied to the altp2m, those entries already
> >> went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
> >> affect so the core function get_altp2m_entry() is calling
> >> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
> >>
> >> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
> >> because on a new altp2m view the function will fail with invalid mfn if
> >> p2m->set_entry() was not called before.
> >>
> >> Signed-off-by: Alexandru Isaila 
> >> Signed-off-by: George Dunlap 
> >> Reviewed-by: George Dunlap 
> >>
> >> ---
> >> Changes since V4:
> >> - Add altp2m to patch name
> >> - Change func name from get_altp2m_entry() to
> >> altp2m_get_entry().
> >> ---
> >>  xen/arch/x86/mm/mem_access.c | 30 ++---
> >>  xen/arch/x86/mm/p2m.c| 84 
> >>  xen/include/asm-x86/p2m.h| 17 
> >>  3 files changed, 66 insertions(+), 65 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> >> index a144bb0ce4..ddfe0169c0 100644
> >> --- a/xen/arch/x86/mm/mem_access.c
> >> +++ b/xen/arch/x86/mm/mem_access.c
> >> @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, 
> >> struct p2m_domain *hp2m,
> >>  mfn_t mfn;
> >>  p2m_type_t t;
> >>  p2m_access_t old_a;
> >> -unsigned int page_order;
> >> -unsigned long gfn_l = gfn_x(gfn);
> >>  int rc;
> >>
> >> -mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
> >> -
> >> -/* Check host p2m if no valid entry in alternate */
> >> -if ( !mfn_valid(mfn) )
> >> -{
> >> -
> >> -mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
> >> -P2M_ALLOC | P2M_UNSHARE, _order, 
> >> 0);
> >> -
> >> -rc = -ESRCH;
> >> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> >> -return rc;
> >> -
> >> -/* If this is a superpage, copy that first */
> >> -if ( page_order != PAGE_ORDER_4K )
> >> -{
> >> -unsigned long mask = ~((1UL << page_order) - 1);
> >> -gfn_t gfn2 = _gfn(gfn_l & mask);
> >> -mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
> >> -
> >> -rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 
> >> 1);
> >> -if ( rc )
> >> -return rc;
> >> -}
> >> -}
> >> +rc = altp2m_get_entry_prepopulate(ap2m, gfn, , , _a);
> >> +if ( rc )
> >> +return rc;
> >>
> >>  /*
> >>   * Inherit the old suppress #VE bit value if it is already set, or 
> >> set it
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 9e81a30cc4..7bedfd593b 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >
> > Wouldn't it make more sense to start adding new altp2m functions to
> > mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
> > also be relocated there at some point in the future.
> >
> >> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
> >>  mm_write_unlock(>lock);
> >>  }
> >>
> >> +int altp2m_get_entry(struct p2m_domain *ap2m,
> >> +gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
> >> +p2m_access_t *a, bool prepopulate)
> >> +{
> >> +*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
> >> +
> >> +/* Check host p2m if no valid entry in alternate */
> >> +if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
> >> +{
> >> +struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
> >> +unsigned int page_order;
> >> +int rc;
> >> +
> >> +*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
> >> + P2M_ALLOC | P2M_UNSHARE, 
> >> _order, 0);
> >
> > So despite the name being altp2m_get_entry you now return an entry
> > from the hostp2m, even if prepopulate is false. If the 

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[George Dunlap]

On 4/16/19 2:44 PM, Tamas K Lengyel wrote:
> On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
>  wrote:
>>
>> The code for getting the entry and then populating was repeated in
>> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>>
>> The code is now in one place with a bool param that lets the caller choose
>> if it populates after get_entry().
>>
>> If remapping is being done then both the old and new gfn's should be
>> unshared in the hostp2m for keeping things consistent. The page type
>> of old_gfn was already checked whether it's p2m_ram_rw and bail if it
>> wasn't so functionality-wise this just simplifies things as a user
>> doesn't have to request unsharing manually before remapping.
>> Now, if the new_gfn is invalid it shouldn't query the hostp2m as
>> that is effectively a request to remove the entry from the altp2m.
>> But provided that scenario is used only when removing entries that
>> were previously remapped/copied to the altp2m, those entries already
>> went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
>> affect so the core function get_altp2m_entry() is calling
>> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
>>
>> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
>> because on a new altp2m view the function will fail with invalid mfn if
>> p2m->set_entry() was not called before.
>>
>> Signed-off-by: Alexandru Isaila 
>> Signed-off-by: George Dunlap 
>> Reviewed-by: George Dunlap 
>>
>> ---
>> Changes since V4:
>> - Add altp2m to patch name
>> - Change func name from get_altp2m_entry() to
>> altp2m_get_entry().
>> ---
>>  xen/arch/x86/mm/mem_access.c | 30 ++---
>>  xen/arch/x86/mm/p2m.c| 84 
>>  xen/include/asm-x86/p2m.h| 17 
>>  3 files changed, 66 insertions(+), 65 deletions(-)
>>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index a144bb0ce4..ddfe0169c0 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
>> p2m_domain *hp2m,
>>  mfn_t mfn;
>>  p2m_type_t t;
>>  p2m_access_t old_a;
>> -unsigned int page_order;
>> -unsigned long gfn_l = gfn_x(gfn);
>>  int rc;
>>
>> -mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
>> -
>> -/* Check host p2m if no valid entry in alternate */
>> -if ( !mfn_valid(mfn) )
>> -{
>> -
>> -mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
>> -P2M_ALLOC | P2M_UNSHARE, _order, 
>> 0);
>> -
>> -rc = -ESRCH;
>> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
>> -return rc;
>> -
>> -/* If this is a superpage, copy that first */
>> -if ( page_order != PAGE_ORDER_4K )
>> -{
>> -unsigned long mask = ~((1UL << page_order) - 1);
>> -gfn_t gfn2 = _gfn(gfn_l & mask);
>> -mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>> -
>> -rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
>> -if ( rc )
>> -return rc;
>> -}
>> -}
>> +rc = altp2m_get_entry_prepopulate(ap2m, gfn, , , _a);
>> +if ( rc )
>> +return rc;
>>
>>  /*
>>   * Inherit the old suppress #VE bit value if it is already set, or set 
>> it
>> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
>> index 9e81a30cc4..7bedfd593b 100644
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
> 
> Wouldn't it make more sense to start adding new altp2m functions to
> mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
> also be relocated there at some point in the future.
> 
>> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>>  mm_write_unlock(>lock);
>>  }
>>
>> +int altp2m_get_entry(struct p2m_domain *ap2m,
>> +gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
>> +p2m_access_t *a, bool prepopulate)
>> +{
>> +*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
>> +
>> +/* Check host p2m if no valid entry in alternate */
>> +if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
>> +{
>> +struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
>> +unsigned int page_order;
>> +int rc;
>> +
>> +*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
>> + P2M_ALLOC | P2M_UNSHARE, _order, 
>> 0);
> 
> So despite the name being altp2m_get_entry you now return an entry
> from the hostp2m, even if prepopulate is false. If the caller knows it
> doesn't want that entry to be copied into the altp2m, why not have it
> call __get_gfn_type_access itself for the hostp2m? IMHO this is just
> confusing and doesn't help readability of the altp2m code.

You return the ap2m entry if it's present, or the hp2m entry if it's
not.  It's 

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[George Dunlap]

On 4/16/19 2:51 PM, Andrew Cooper wrote:
> On 16/04/2019 14:44, Tamas K Lengyel wrote:
>>
>>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>>> index 2801a8ccca..8dc4353645 100644
>>> --- a/xen/include/asm-x86/p2m.h
>>> +++ b/xen/include/asm-x86/p2m.h
>>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain 
>>> *d, mfn_t mfn)
>>>  return mfn_x(mfn);
>>>  }
>>>
>>> +int altp2m_get_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
>>> + p2m_type_t *t, p2m_access_t *a, bool prepopulate);
>>> +
>>> +static inline int altp2m_get_entry_direct(struct p2m_domain *ap2m,
>>> +  gfn_t gfn, mfn_t *mfn,
>>> +  p2m_type_t *t, p2m_access_t *a)
>>> +{
>>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, false);
>>> +}
>>> +
>>> +static inline int altp2m_get_entry_prepopulate(struct p2m_domain *ap2m,
>>> +   gfn_t gfn, mfn_t *mfn,
>>> +   p2m_type_t *t, p2m_access_t 
>>> *a)
>>> +{
>>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, true);
>>> +}
>> Are these wrappers really required? I don't think they add anything to
>> readability, it's just yet another layer that does almost nothing.
> 
> From a readability point of view, boolean parameters are about as opaque
> as they come.  The same goes for all other scalar parameters which don't
> have a mnemonic.
> 
> For someone who is not an expert of the intricacies of the subsystem,
> having the options spelt out in wrappers like this is extremely helpful
> to reduce the cognitive load of trying to follow the code.

This is exactly why I did it this way.

The other pattern I think is tolerable is having a #define to use as an
argument; for example:

#define AP2MGET_prepopulate true
#define AP2MGET_peekfalse

Then you get:

  mfn = altp2m_get_entry(..., AP2MGET_prepopulate);

But then you run into namespacing issues with the prefixes.

I wouldn't object to doing it the above way, but I think the wrappers is
probably simpler and clearer for this case.  I do object to passing in
naked booleans.

 -George

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

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[Andrew Cooper]

On 16/04/2019 14:44, Tamas K Lengyel wrote:
>
>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>> index 2801a8ccca..8dc4353645 100644
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain 
>> *d, mfn_t mfn)
>>  return mfn_x(mfn);
>>  }
>>
>> +int altp2m_get_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
>> + p2m_type_t *t, p2m_access_t *a, bool prepopulate);
>> +
>> +static inline int altp2m_get_entry_direct(struct p2m_domain *ap2m,
>> +  gfn_t gfn, mfn_t *mfn,
>> +  p2m_type_t *t, p2m_access_t *a)
>> +{
>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, false);
>> +}
>> +
>> +static inline int altp2m_get_entry_prepopulate(struct p2m_domain *ap2m,
>> +   gfn_t gfn, mfn_t *mfn,
>> +   p2m_type_t *t, p2m_access_t 
>> *a)
>> +{
>> +return altp2m_get_entry(ap2m, gfn, mfn, t, a, true);
>> +}
> Are these wrappers really required? I don't think they add anything to
> readability, it's just yet another layer that does almost nothing.

From a readability point of view, boolean parameters are about as opaque
as they come.  The same goes for all other scalar parameters which don't
have a mnemonic.

For someone who is not an expert of the intricacies of the subsystem,
having the options spelt out in wrappers like this is extremely helpful
to reduce the cognitive load of trying to follow the code.

If it were up to me, all of our code would be wrapped like this, but I
know that others have differing opinions.

~Andrew

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

Re: [Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[Tamas K Lengyel]

On Tue, Apr 16, 2019 at 2:45 AM Alexandru Stefan ISAILA
 wrote:
>
> The code for getting the entry and then populating was repeated in
> p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().
>
> The code is now in one place with a bool param that lets the caller choose
> if it populates after get_entry().
>
> If remapping is being done then both the old and new gfn's should be
> unshared in the hostp2m for keeping things consistent. The page type
> of old_gfn was already checked whether it's p2m_ram_rw and bail if it
> wasn't so functionality-wise this just simplifies things as a user
> doesn't have to request unsharing manually before remapping.
> Now, if the new_gfn is invalid it shouldn't query the hostp2m as
> that is effectively a request to remove the entry from the altp2m.
> But provided that scenario is used only when removing entries that
> were previously remapped/copied to the altp2m, those entries already
> went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
> affect so the core function get_altp2m_entry() is calling
> __get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.
>
> altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
> because on a new altp2m view the function will fail with invalid mfn if
> p2m->set_entry() was not called before.
>
> Signed-off-by: Alexandru Isaila 
> Signed-off-by: George Dunlap 
> Reviewed-by: George Dunlap 
>
> ---
> Changes since V4:
> - Add altp2m to patch name
> - Change func name from get_altp2m_entry() to
> altp2m_get_entry().
> ---
>  xen/arch/x86/mm/mem_access.c | 30 ++---
>  xen/arch/x86/mm/p2m.c| 84 
>  xen/include/asm-x86/p2m.h| 17 
>  3 files changed, 66 insertions(+), 65 deletions(-)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index a144bb0ce4..ddfe0169c0 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
> p2m_domain *hp2m,
>  mfn_t mfn;
>  p2m_type_t t;
>  p2m_access_t old_a;
> -unsigned int page_order;
> -unsigned long gfn_l = gfn_x(gfn);
>  int rc;
>
> -mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
> -
> -/* Check host p2m if no valid entry in alternate */
> -if ( !mfn_valid(mfn) )
> -{
> -
> -mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
> -P2M_ALLOC | P2M_UNSHARE, _order, 0);
> -
> -rc = -ESRCH;
> -if ( !mfn_valid(mfn) || t != p2m_ram_rw )
> -return rc;
> -
> -/* If this is a superpage, copy that first */
> -if ( page_order != PAGE_ORDER_4K )
> -{
> -unsigned long mask = ~((1UL << page_order) - 1);
> -gfn_t gfn2 = _gfn(gfn_l & mask);
> -mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
> -
> -rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
> -if ( rc )
> -return rc;
> -}
> -}
> +rc = altp2m_get_entry_prepopulate(ap2m, gfn, , , _a);
> +if ( rc )
> +return rc;
>
>  /*
>   * Inherit the old suppress #VE bit value if it is already set, or set it
> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> index 9e81a30cc4..7bedfd593b 100644
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c

Wouldn't it make more sense to start adding new altp2m functions to
mm/altp2m.c instead? Probably the altp2m functions from mm/p2m.c could
also be relocated there at some point in the future.

> @@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
>  mm_write_unlock(>lock);
>  }
>
> +int altp2m_get_entry(struct p2m_domain *ap2m,
> +gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
> +p2m_access_t *a, bool prepopulate)
> +{
> +*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
> +
> +/* Check host p2m if no valid entry in alternate */
> +if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
> +{
> +struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
> +unsigned int page_order;
> +int rc;
> +
> +*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
> + P2M_ALLOC | P2M_UNSHARE, _order, 
> 0);

So despite the name being altp2m_get_entry you now return an entry
from the hostp2m, even if prepopulate is false. If the caller knows it
doesn't want that entry to be copied into the altp2m, why not have it
call __get_gfn_type_access itself for the hostp2m? IMHO this is just
confusing and doesn't help readability of the altp2m code.

> +
> +rc = -ESRCH;
> +if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
> +return rc;
> +
> +/* If this is a superpage, copy that first */
> +if ( prepopulate && page_order != PAGE_ORDER_4K )
> +{
> +

Re: [Xen-devel] Xen commit 9b0bc91b3 possibly removed too much info from README

[Kevin Buckley]

> Oh wait, I don't think there is anything to fix there. Those sentences
> look repetitive but they do say different things: in tools case, it says
> "repos will be cloned"; in stubdom case, it says "external packages
> will be downloaded. So they do reflect correctly what will happen.
>

Let me narrow things down a bit further to highlight the duplication

8<8<8<8<8<8<8<8<
During tools build external repos will be cloned into the source tree.<=== 1
This variable can be used to point to a different git binary to be used.
GIT=

During tools build external repos will be cloned into the source tree.<=== 2
During stubdom build external packages will be downloaded into the
source tree. These variables can be used to point to a different
locations.
 XEN_EXTFILES_URL=
OVMF_UPSTREAM_URL=
8<8<8<8<8<8<8<8<

Hope that's clearer ?

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

Re: [Xen-devel] Xen commit 9b0bc91b3 possibly removed too much info from README

[Kevin Buckley]

On Mon, 15 Apr 2019 at 17:24, Wei Liu  wrote:
>
> On Sat, Apr 13, 2019 at 11:17:48AM +0800, Kevin Buckley wrote:
> > On Thu, 11 Apr 2019 at 18:29, Wei Liu  wrote:
> > >
> > > ...
> > > Sure. I will write a patch.
> > >
> > > Wei.
> >
> > Couple of other things I noticed after posting the original observation,
> > that might be of use in patching the documentation
> >
> > 1)
> >
> > The tools/Makefile has a bare PYTHON EnvVar that isn't seemingly
> > replaced by the PYTHON= value supplied to configure, so I also
> > needed to specify the
> >
> > PYTHON=/path/to/interpreter
> >
> > as an argument to the "make world" as well as to the configure.
>
> The only appearance of PYTHON in tools/Makefile is in the qemu build.
> It already has the right form.
>
> I tested the following:
>
> $ PYTHON=/usr/bin/python3 ./configure
> $ make -j8 world 2>&1 | tee log # broken atm unfortunately
> $ make -C tools subdir-all-qemu-xen-dir # the rune which has PYTHON in it
>
> And then I looked for the relevant bits in log:
>
> PKG_CONFIG_PATH=/local/work/xen.git/tools/../tools/pkg-config${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
>  \
> $source/configure --enable-xen --target-list=i386-softmmu \
> 
> --python=python3 \
>
> Not sure which bare PYTHON EnvVar you referred to. Can you clarify?


Here's what i did having pulled the master at commit cb70a26

tar xf /path/to/xen-cb70a26.tar.gz

cd xen-master/

PYTHON=/usr/bin/python3 ./configure --prefix=/usr   \
   --disable-seabios   \
   --disable-qemu-traditional  \
   --disable-rombios \
   --disable-stubdom 2>&1 | tee ../config.log

make EFI_DIR=/usr/lib/efi world 2>&1 | tee ../make_world_3.out


...
gcc -Wp,-MD,tools/kconfig/.zconf.tab.o.d-D_GNU_SOURCE
-D_DEFAULT_SOURCE -DCURSES_LOC="" -DNCURSES_WIDECHAR=1
-DLOCALE  -Itools/kconfig -c -o tools/kconfig/zconf.tab.o
tools/kconfig/zconf.tab.c
gcc  -o tools/kconfig/conf tools/kconfig/conf.o tools/kconfig/zconf.tab.o
tools/kconfig/conf -s --silentoldconfig Kconfig
make[3]: Leaving directory '/usr/src/xen/xen-master/xen'
make -f Rules.mk _install
make[3]: Entering directory '/usr/src/xen/xen-master/xen'
make -C tools
make[4]: Entering directory '/usr/src/xen/xen-master/xen/tools'
make symbols
make[5]: Entering directory '/usr/src/xen/xen-master/xen/tools'
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
-fno-strict-aliasing -Wdeclaration-after-statement -o symbols
symbols.c
make[5]: Leaving directory '/usr/src/xen/xen-master/xen/tools'
make[4]: Leaving directory '/usr/src/xen/xen-master/xen/tools'
make -f /usr/src/xen/xen-master/xen/Rules.mk include/xen/compile.h
make[4]: Entering directory '/usr/src/xen/xen-master/xen'
 Xen 4.13-unstable
/bin/sh: python: command not found
make[4]: *** [Makefile:169: include/xen/compile.h] Error 127
make[4]: Leaving directory '/usr/src/xen/xen-master/xen'
make[3]: *** [Makefile:137: /usr/src/xen/xen-master/xen/xen] Error 2
make[3]: Leaving directory '/usr/src/xen/xen-master/xen'
make[2]: *** [Makefile:45: install] Error 2
make[2]: Leaving directory '/usr/src/xen/xen-master/xen'
make[1]: *** [Makefile:123: install-xen] Error 2
make[1]: Leaving directory '/usr/src/xen/xen-master'
make: *** [Makefile:165: world] Error 2


Note the

/bin/sh: python: command not found

whilst, in the tools/Makefile,, I see


PKG_CONFIG_PATH=$(XEN_ROOT)/tools/pkg-config$${PKG_CONFIG_PATH:+:$${PKG_CONFIG_PATH}}
\
$$source/configure --enable-xen --target-list=i386-softmmu \
$(QEMU_XEN_ENABLE_DEBUG) \
$$enable_trace_backend \
--prefix=$(LIBEXEC) \
--libdir=$(LIBEXEC_LIB) \
--includedir=$(LIBEXEC_INC) \
--source-path=$$source \
--extra-cflags="-DXC_WANT_COMPAT_EVTCHN_API=1 \
-DXC_WANT_COMPAT_GNTTAB_API=1 \
-DXC_WANT_COMPAT_MAP_FOREIGN_API=1 \
-DXC_WANT_COMPAT_DEVICEMODEL_API=1 \
-I$(XEN_ROOT)/tools/include \
-I$(XEN_ROOT)/tools/libs/toolcore/include \
-I$(XEN_ROOT)/tools/libs/toollog/include \
-I$(XEN_ROOT)/tools/libs/evtchn/include \
-I$(XEN_ROOT)/tools/libs/gnttab/include \
-I$(XEN_ROOT)/tools/libs/foreignmemory/include \
-I$(XEN_ROOT)/tools/libs/devicemodel/include \
-I$(XEN_ROOT)/tools/libxc/include \
-I$(XEN_ROOT)/tools/xenstore/include \
-I$(XEN_ROOT)/tools/xenstore/compat/include \
$(EXTRA_CFLAGS_QEMU_XEN)" \
--extra-ldflags="-L$(XEN_ROOT)/tools/libxc \
-L$(XEN_ROOT)/tools/xenstore \
-L$(XEN_ROOT)/tools/libs/toolcore \
-L$(XEN_ROOT)/tools/libs/evtchn \
-L$(XEN_ROOT)/tools/libs/gnttab \
-L$(XEN_ROOT)/tools/libs/foreignmemory \
-L$(XEN_ROOT)/tools/libs/devicemodel \

Re: [Xen-devel] [PATCH V3 2/5] xen/arm: drivers: scif: Extend driver to handle other interfaces

[Oleksandr]

On 16.04.19 12:11, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 4/15/19 12:30 PM, Oleksandr wrote:


On 14.04.19 19:55, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.


Can you briefly explain in the commit message what differs?


Sure




[...]

@@ -65,13 +100,16 @@ static void scif_uart_interrupt(int irq, void 
*data, struct cpu_user_regs *regs)

  serial_rx_interrupt(port, regs);
    /* Error Interrupt */
-    if ( status & SCIF_ERRORS )
-    scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-    if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-    scif_writew(uart, SCIF_SCLSR, 0);
+    if ( status & params->error_mask )
+    scif_writew(uart, params->status_reg, 
~params->error_mask);

+    if ( params->overrun_reg != params->status_reg )


Below you will write the same register twice if overrun_reg == 
status_reg (see scif_uart_init_preirq). Would there be any issue if 
you do the same here?


I didn't expect any issue to write the same register twice during 
initialization to simplify the code, that why I agreed to remove the 
check in V1.


But I am not sure about doing so here. We could simplify the code by 
just removing "if ( params->overrun_reg != params->status_reg )",


but we would need to do extra operation for SCIFA which has 
overrun_reg == status_reg.


What way do you prefer?


It is not about preference, it is about correctness. In my previous 
reply, I pointed out that you define overrun_mask for SCIFA but it 
will never be used. Without any explanation, the code looks pretty wrong.


Looking at the next patch, you get away from any problem with SCIFA 
because the overrun_mask is a subset of error_mask. But I still don't 
see why trying to prevent to write a second time is an issue, the more 
the Linux driver does not seem to do this dance.


So at best, you need to explain in the commit message why you try to 
skip the register when it is the same.


I got your point.


I can make the following changes:

1. Drop "if ( params->overrun_reg != params->status_reg )" check everywhere.

2. Remove overrun_bit (SCASSR_ORER) from error_mask for SCIFA.

This way we will get a much cleaner code where overrun_mask is used for 
both interfaces.


What do you think?




Cheers,


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] booting domU guest as pvh works in xen-4.11.1 but fails in 4.12

[Andrew Cooper]

On 16/04/2019 00:18, Pry Mar wrote:
> Hello,
>
> https://paste.debian.net/1077718/
>
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).

>From the log:
> traps: modprobe[48] trap invalid opcode ip:7f797dc7bb95 sp:7ffe3099cdb8 
> error:0 in ld-2.29.so[7f797dc61000+21000]

Can you disassemble ld-2.29.so and find out what that instruction is? 
It is almost certainly a related factor.

> [1.127818] Run /init as init process
> [1.130195] Kernel panic - not syncing: Attempted to kill init! 
> exitcode=0x0004
> [1.130230] CPU: 0 PID: 1 Comm: init Not tainted 5.0.0-8-generic #9-Ubuntu
> [1.130243] Call Trace:
> [1.130284]  dump_stack+0x63/0x8a
> [1.130296]  panic+0x101/0x2a7
> [1.130306]  do_exit.cold.24+0x26/0x75
> [1.130315]  do_group_exit+0x43/0xb0
> [1.130325]  get_signal+0x139/0x6d0
> [1.130336]  do_signal+0x34/0x710
> [1.130345]  ? do_trap+0xda/0xe0
> [1.130375]  exit_to_usermode_loop+0x8e/0x100
> [1.130387]  prepare_exit_to_usermode+0x5a/0x80
> [1.130399]  ? invalid_op+0xa/0x20
> [1.130408]  retint_user+0x8/0x8
> [1.130418] RIP: 0033:0x7feef6fe4b95
> [1.130433] Code: Bad RIP value.
> [1.130441] RSP: 002b:7ffdda330e78 EFLAGS: 00010246
> [1.130452] RAX: 000c RBX: 0001 RCX: 
> 000b
> [1.130466] RDX: 0042 RSI: 7feef6fecd75 RDI: 
> 
> [1.130479] RBP: 55c1b07f7040 R08: 0019 R09: 
> 0001
> [1.130493] R10:  R11: 004d R12: 
> 000b
> [1.130507] R13: 7feef6fcb810 R14:  R15: 
> 7ffdda331119
> [1.130733] Kernel Offset: 0x240 from 0x8100 (relocation 
> range: 0x8000-0xbfff)

This looks to be related to the #UD from above, but rather more fatal.

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

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

[osstest service owner]

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

Regressions :-(

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

version targeted for testing:
 ovmf 0eccea3fbe2f6d4999d972d9310d4f2717f5100c
baseline version:
 ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33

Last test of basis   134640  2019-04-11 13:15:51 Z4 days
Failing since134738  2019-04-13 03:33:26 Z3 days7 attempts
Testing same since   134852  2019-04-16 06:41:35 Z0 days2 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bret Barkelew 
  Chasel Chiu 
  Chasel, Chiu 
  Christian Rodriguez 
  Dandan Bi 
  Dong, Guo 
  Fan, ZhijuX 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Rodriguez, Christian 
  Shenglei Zhang 
  Zhichao Gao 
  Zhiju.Fan 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   fail
 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


Not pushing.

(No revision log; it would be 417 lines long.)

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

[Xen-devel] [livepatch: independ. modules 3/3] python: Add XC binding for Xen build ID

[Pawel Wieczorkiewicz]

Extend the list of xc() object methods with additional one to display
Xen's buildid. The implementation follows the libxl implementation
(e.g. max buildid size assumption being XC_PAGE_SIZE).

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Mazein 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Norbert Manthey 

CC: Marek Marczykowski-Gorecki 
---
 tools/python/xen/lowlevel/xc/xc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index cc8175a11e..66db18ec3a 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1202,6 +1202,26 @@ out:
 return ret_obj ? ret_obj : pyxc_error_to_exception(self->xc_handle);
 }
 
+static PyObject *pyxc_xenbuildid(XcObject *self)
+{
+xen_build_id_t *buildid;
+int i, r;
+char *str;
+
+buildid = alloca(sizeof(buildid->len) + XC_PAGE_SIZE);
+buildid->len = XC_PAGE_SIZE - sizeof(*buildid);
+
+r = xc_version(self->xc_handle, XENVER_build_id, buildid);
+if ( r <= 0 )
+return pyxc_error_to_exception(self->xc_handle);
+
+str = alloca((r * 2) + 1);
+for ( i = 0; i < r; i++ )
+snprintf([i * 2], 3, "%02hhx", buildid->buf[i]);
+
+return Py_BuildValue("s", str);
+}
+
 static PyObject *pyxc_xeninfo(XcObject *self)
 {
 xen_extraversion_t xen_extra;
@@ -2350,6 +2370,13 @@ static PyMethodDef pyxc_methods[] = {
   "Returns [dict]: information about Xen"
   "[None]: on failure.\n" },
 
+{ "buildid",
+  (PyCFunction)pyxc_xenbuildid,
+  METH_NOARGS, "\n"
+  "Get Xen buildid\n"
+  "Returns [str]: Xen buildid"
+  "[None]: on failure.\n" },
+
 { "shadow_control", 
   (PyCFunction)pyxc_shadow_control, 
   METH_VARARGS | METH_KEYWORDS, "\n"
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools: independ. modules] livepatch-build: Embed hypervisor build id into every hotpatch

[Pawel Wieczorkiewicz]

This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.

With stacked hotpatch modules it is essential that each and every
hotpatch is verified against the hypervisor build id upon upload.
It must not be possible to successfully upload hotpatches built for
incorrect version of the hypervisor.

To achieve that always embed an additional ELF section:
'.livpatch.xen_depends' containing the hypervisor build id.

The hypervisor build id must be always provided as a command line
parameter: --xen-depends.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 livepatch-build | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/livepatch-build b/livepatch-build
index c057fa1..0938b3a 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -30,6 +30,7 @@ DEBUG=n
 XEN_DEBUG=n
 SKIP=
 DEPENDS=
+XEN_DEPENDS=
 PRELINK=
 XENSYMS=xen-syms
 
@@ -157,6 +158,9 @@ function create_patch()
 # Create a dependency section
 perl -e "print pack 'VVVZ*H*', 4, 20, 3, 'GNU', '${DEPENDS}'" > depends.bin
 
+# Create a Xen dependency section
+perl -e "print pack 'VVVZ*H*', 4, 20, 3, 'GNU', '${XEN_DEPENDS}'" > 
xen_depends.bin
+
 echo "Creating patch module..."
 if [ -z "$PRELINK" ]; then
 ld -r -o "${PATCHNAME}.livepatch" --build-id=sha1 $(find output -type 
f -name "*.o") || die
@@ -168,6 +172,9 @@ function create_patch()
 
 objcopy --add-section .livepatch.depends=depends.bin 
"${PATCHNAME}.livepatch"
 objcopy --set-section-flags .livepatch.depends=alloc,readonly 
"${PATCHNAME}.livepatch"
+
+objcopy --add-section .livepatch.xen_depends=xen_depends.bin 
"${PATCHNAME}.livepatch"
+objcopy --set-section-flags .livepatch.xen_depends=alloc,readonly 
"${PATCHNAME}.livepatch"
 }
 
 usage() {
@@ -183,12 +190,13 @@ usage() {
 echo "--xen-debugBuild debug Xen (if your .config does not 
have the options)" >&2
 echo "--xen-syms Build against a xen-syms" >&2
 echo "--depends  Required build-id" >&2
+echo "--xen-depends  Required Xen build-id" >&2
 echo "--prelink  Prelink" >&2
 }
 
 find_tools || die "can't find supporting tools"
 
-options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:,patch:,config:,output:,cpus:,skip:,debug,xen-debug,xen-syms:,depends:,prelink"
 -- "$@") || die "getopt failed"
+options=$(getopt -o hs:p:c:o:j:k:d -l 
"help,srcdir:,patch:,config:,output:,cpus:,skip:,debug,xen-debug,xen-syms:,depends:,xen-depends:,prelink"
 -- "$@") || die "getopt failed"
 
 eval set -- "$options"
 
@@ -247,6 +255,11 @@ while [[ $# -gt 0 ]]; do
 DEPENDS="$1"
 shift
 ;;
+--xen-depends)
+shift
+XEN_DEPENDS="$1"
+shift
+;;
 --prelink)
 PRELINK=--resolve
 shift
@@ -263,6 +276,7 @@ done
 [ -z "$configarg" ] && die ".config not given"
 [ -z "$outputarg" ] && die "Output directory not given"
 [ -z "$DEPENDS" ] && die "Build-id dependency not given"
+[ -z "$XEN_DEPENDS" ] && die "Xen Build-id dependency not given"
 
 SRCDIR="$(readlink -m -- "$srcarg")"
 PATCHFILE="$(readlink -m -- "$patcharg")"
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch: independ. modules 2/3] livepatch: Allow to override inter-modules buildid dependency

[Pawel Wieczorkiewicz]

By default Livepatch enforces the following buildid-based dependency
chain between hotpatch modules:
  1) first module depends on given hypervisor buildid
  2) every consecutive module depends on previous module's buildid
This way proper hotpatch stack order is maintained and enforced.
While it is important for production hotpatches it limits agility and
blocks usage of testing or debug hotpatches. These kinds of hotpatch
modules are typically expected to be loaded at any time irrespective
of current state of the modules stack.

To enable testing and debug hotpatches allow user dynamically ignore
the inter-modules dependency. In this case only hypervisor buildid
match is verified and enforced.

To allow userland pass additional paremeters for livepatch actions
add support for action flags.
Each of the apply, revert, unload and revert action gets additional
64-bit parameter 'flags' where extra flags can be applied in a mask
form.
Initially only one flag '--nodeps' is added for the apply action.
This flag modifies the default buildid dependency check as described
above.
The global sysctl interface input flag parameter is defined with a
single corresponding flag macro:
  LIVEPATCH_ACTION_APPLY_NODEPS (1 << 0)

The userland xen-livepatch tool is modified to support the '--nodeps'
flag for apply and load commands. A general mechanism for specifying
more flags in the future for apply and other action is however added.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Eslam Elnikety 
Reviewed-by: Petre Eftime 
Reviewed-by: Leonard Foerster 
Reviewed-by: Martin Pohlack 
Reviewed-by: Norbert Manthey 
---
 tools/libxc/include/xenctrl.h |   9 ++--
 tools/libxc/xc_misc.c |  20 +++
 tools/misc/xen-livepatch.c| 121 +++---
 xen/common/livepatch.c|  14 +++--
 xen/include/public/sysctl.h   |   9 
 5 files changed, 138 insertions(+), 35 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a3628e56bb..6e1e41c0c9 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2618,11 +2618,12 @@ int xc_livepatch_list(xc_interface *xch, unsigned int 
max, unsigned int start,
  * to complete them. The `timeout` offers an option to expire the
  * operation if it could not be completed within the specified time
  * (in ns). Value of 0 means let hypervisor decide the best timeout.
+ * The `flags` allows to pass extra parameters to the actions.
  */
-int xc_livepatch_apply(xc_interface *xch, char *name, uint32_t timeout);
-int xc_livepatch_revert(xc_interface *xch, char *name, uint32_t timeout);
-int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout);
-int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout);
+int xc_livepatch_apply(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags);
+int xc_livepatch_revert(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags);
+int xc_livepatch_unload(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags);
+int xc_livepatch_replace(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags);
 
 /*
  * Ensure cache coherency after memory modifications. A call to this function
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 5e6714ae2b..b7289c2d4d 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -831,7 +831,8 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, 
unsigned int start,
 static int _xc_livepatch_action(xc_interface *xch,
 char *name,
 unsigned int action,
-uint32_t timeout)
+uint32_t timeout,
+uint64_t flags)
 {
 int rc;
 DECLARE_SYSCTL;
@@ -857,6 +858,7 @@ static int _xc_livepatch_action(xc_interface *xch,
 sysctl.u.livepatch.pad = 0;
 sysctl.u.livepatch.u.action.cmd = action;
 sysctl.u.livepatch.u.action.timeout = timeout;
+sysctl.u.livepatch.u.action.flags = flags;
 
 sysctl.u.livepatch.u.action.name = def_name;
 set_xen_guest_handle(sysctl.u.livepatch.u.action.name.name, name);
@@ -868,24 +870,24 @@ static int _xc_livepatch_action(xc_interface *xch,
 return rc;
 }
 
-int xc_livepatch_apply(xc_interface *xch, char *name, uint32_t timeout)
+int xc_livepatch_apply(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags)
 {
-return _xc_livepatch_action(xch, name, LIVEPATCH_ACTION_APPLY, timeout);
+return _xc_livepatch_action(xch, name, LIVEPATCH_ACTION_APPLY, timeout, 
flags);
 }
 
-int xc_livepatch_revert(xc_interface *xch, char *name, uint32_t timeout)
+int xc_livepatch_revert(xc_interface *xch, char *name, uint32_t timeout, 
uint64_t flags)
 {
-return _xc_livepatch_action(xch, name, LIVEPATCH_ACTION_REVERT, timeout);
+return _xc_livepatch_action(xch, name, LIVEPATCH_ACTION_REVERT, 

[Xen-devel] [livepatch: independ. modules 1/3] livepatch: Always check hypervisor build ID upon hotpatch upload

[Pawel Wieczorkiewicz]

This change is part of a independant stacked hotpatch modules
feature. This feature allows to bypass dependencies between modules
upon loading, but still verifies Xen build ID matching.

In order to prevent (up)loading any hotpatches built for different
hypervisor version as indicated by the Xen Build ID, add checking for
the payload's vs Xen's build id match.

To achieve that embed into every hotpatch another section with a
dedicated hypervisor build id in it. After the payload is loaded and
the .livepatch.xen_depends section becomes available, perform the
check and reject the payload if there is no match.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Eslam Elnikety 
Reviewed-by: Martin Pohlack 
---
 xen/common/livepatch.c  | 47 +
 xen/include/xen/livepatch.h |  7 ---
 2 files changed, 51 insertions(+), 3 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index d6eaae6d3b..6a4af6ce57 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -74,6 +74,7 @@ struct payload {
 unsigned int nsyms;  /* Nr of entries in .strtab and 
symbols. */
 struct livepatch_build_id id;/* ELFNOTE_DESC(.note.gnu.build-id) 
of the payload. */
 struct livepatch_build_id dep;   /* ELFNOTE_DESC(.livepatch.depends). 
*/
+struct livepatch_build_id xen_dep;   /* 
ELFNOTE_DESC(.livepatch.xen_depends). */
 livepatch_loadcall_t *const *load_funcs;   /* The array of funcs to call 
after */
 livepatch_unloadcall_t *const *unload_funcs;/* load and unload of the 
payload. */
 unsigned int n_load_funcs;   /* Nr of the funcs to load and 
execute. */
@@ -476,11 +477,34 @@ static bool section_ok(const struct livepatch_elf *elf,
 return true;
 }
 
+static int check_xen_build_id(const struct payload *payload)
+{
+const void *id = NULL;
+unsigned int len = 0;
+int rc;
+
+ASSERT(payload->xen_dep.len);
+ASSERT(payload->xen_dep.p);
+
+rc = xen_build_id(, );
+if ( rc )
+return rc;
+
+if ( payload->xen_dep.len != len || memcmp(id, payload->xen_dep.p, len) ) {
+dprintk(XENLOG_ERR, "%s%s: check against hypervisor build-id 
failed!\n",
+LIVEPATCH, payload->name);
+return -EINVAL;
+}
+
+return 0;
+}
+
 static int check_special_sections(const struct livepatch_elf *elf)
 {
 unsigned int i;
 static const char *const names[] = { ELF_LIVEPATCH_FUNC,
  ELF_LIVEPATCH_DEPENDS,
+ ELF_LIVEPATCH_XEN_DEPENDS,
  ELF_BUILD_ID_NOTE};
 DECLARE_BITMAP(found, ARRAY_SIZE(names)) = { 0 };
 
@@ -632,6 +656,22 @@ static int prepare_payload(struct payload *payload,
 return -EINVAL;
 }
 
+sec = livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_XEN_DEPENDS);
+if ( sec )
+{
+n = sec->load_addr;
+
+if ( sec->sec->sh_size <= sizeof(*n) )
+return -EINVAL;
+
+if ( xen_build_id_check(n, sec->sec->sh_size,
+>xen_dep.p, >xen_dep.len) )
+return -EINVAL;
+
+if ( !payload->xen_dep.len || !payload->xen_dep.p )
+return -EINVAL;
+}
+
 /* Setup the virtual region with proper data. */
 region = >region;
 
@@ -882,6 +922,10 @@ static int load_payload_data(struct payload *payload, void 
*raw, size_t len)
 if ( rc )
 goto out;
 
+rc = check_xen_build_id(payload);
+if ( rc )
+goto out;
+
 rc = build_symbol_table(payload, );
 if ( rc )
 goto out;
@@ -1655,6 +1699,9 @@ static void livepatch_printall(unsigned char key)
 
 if ( data->dep.len )
 printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
+
+if ( data->xen_dep.len )
+printk("depend-on-xen=%*phN\n", data->xen_dep.len, 
data->xen_dep.p);
 }
 
 spin_unlock(_lock);
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 1b1817ca0d..ed997aa4cc 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -29,9 +29,10 @@ struct xen_sysctl_livepatch_op;
 /* Convenience define for printk. */
 #define LIVEPATCH "livepatch: "
 /* ELF payload special section names. */
-#define ELF_LIVEPATCH_FUNC".livepatch.funcs"
-#define ELF_LIVEPATCH_DEPENDS ".livepatch.depends"
-#define ELF_BUILD_ID_NOTE  ".note.gnu.build-id"
+#define ELF_LIVEPATCH_FUNC".livepatch.funcs"
+#define ELF_LIVEPATCH_DEPENDS ".livepatch.depends"
+#define ELF_LIVEPATCH_XEN_DEPENDS ".livepatch.xen_depends"
+#define ELF_BUILD_ID_NOTE ".note.gnu.build-id"
 /* Arbitrary limit for payload size and .bss section size. */
 #define LIVEPATCH_MAX_SIZE MB(2)
 
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian 

[Xen-devel] [livepatch-build-tools part3 1/3] create-diff-object: Do not create empty .livepatch.funcs section

[Pawel Wieczorkiewicz]

When there is no changed function in the generated payload, do not
create an empty .livepatch.funcs section. Hypervisor code considers
such payloads as broken and rejects to load them.

Such payloads without any changed functions may appear when only
hooks are specified.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Mazein 
Reviewed-by: Martin Pohlack 

CR: https://code.amazon.com/reviews/CR-7368634
---
 create-diff-object.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index 82f777e..af2245c 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1744,6 +1744,11 @@ static void livepatch_create_patches_sections(struct 
kpatch_elf *kelf,
if (sym->type == STT_FUNC && sym->status == CHANGED)
nr++;
 
+   if (nr == 0) {
+   log_debug("No changed functions found. Skipping 
.livepatch.funcs section creation\n");
+   return;
+   }
+
/* create text/rela section pair */
sec = create_section_pair(kelf, ".livepatch.funcs", sizeof(*funcs), nr);
relasec = sec->rela;
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools part3 3/3] create-diff-object: Strip all undefined entires of known size

[Pawel Wieczorkiewicz]

The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
copied along (with all their entries unchanged), while some of the
corresponding symbols are not copied along at all.
This leads to having incorrect dummy (STN_UNDEF) entries in the final
hotpatch ELF file.

The newly added function livepatch_strip_undefined_elements() detects
and removes all undefined RELA entries as well as their corresponding
PROGBITS section entries.
Since the sections may contain elements of unknown size (sh.sh_entsize
== 0), perform the strip only on sections with well defined entry
sizes.

After replacing the stripped rela list, it is assumed that the next
invocation of the kpatch_rebuild_rela_section_data() will adjust all
section header parameters according to the current state.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Pohlack 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
Reviewed-by: Andra-Irina Paraschiv 

CR: https://code.amazon.com/reviews/CR-7368662
---
 create-diff-object.c | 115 ++-
 1 file changed, 113 insertions(+), 2 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index 96b6716..4f031ef 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1473,6 +1473,13 @@ static inline int get_section_entry_size(const struct 
section *sec, struct kpatc
 return entry_size;
 }
 
+/* Check if RELA entry has undefined (STN_UNDEF) or unchanged/not-included 
elements. */
+static inline bool has_rela_undefined_element(const struct rela *rela)
+{
+   return (GELF_R_SYM(rela->rela.r_info) == STN_UNDEF) ||
+  (!rela->sym->include && (rela->sym->status == SAME));
+}
+
 static void kpatch_verify_patchability(struct kpatch_elf *kelf)
 {
struct section *sec;
@@ -1520,8 +1527,7 @@ static void kpatch_verify_patchability(struct kpatch_elf 
*kelf)
if (rela->offset < offset || 
rela->offset >= offset + entry_size)
continue;
 
-   if 
((GELF_R_SYM(rela->rela.r_info) == STN_UNDEF) ||
-   (!rela->sym->include && 
(rela->sym->status == SAME))) {
+   if 
(has_rela_undefined_element(rela)) {
log_normal("section %s 
has an entry with a STN_UNDEF symbol: %s\n",
   sec->name, 
rela->sym->name ? rela->sym->name : "none");
errs++;
@@ -1889,6 +1895,109 @@ static void livepatch_create_patches_sections(struct 
kpatch_elf *kelf,
 
 }
 
+/*
+ * The patched ELF object file contains all sections and symbols as resulted
+ * from the compilation. However, certain symbols may not be copied over to
+ * the resulting object file, due to being unchanged or not included for other
+ * reasons.
+ * In such situation the resulting object file has the entire sections copied
+ * along (with all their entries unchanged), while some of the corresponding
+ * symbols are not copied along at all.
+ * This leads to having incorrect dummy (STN_UNDEF) entries in the final
+ * hotpatch ELF file.
+ * This functions removes all undefined entries of known size from both
+ * RELA and PROGBITS sections of the patched elf object.
+ */
+static void livepatch_strip_undefined_elements(struct kpatch_elf *kelf)
+{
+   struct section *sec;
+
+   list_for_each_entry(sec, >sections, list) {
+   struct rela *rela, *safe;
+   int src_offset = 0, dst_offset = 0;
+   int entry_size, align, aligned_size;
+   char *src, *dst;
+   LIST_HEAD(newrelas);
+
+   /* use RELA section to find all its undefined entries */
+   if (!is_rela_section(sec))
+   continue;
+
+   /* only known, fixed-size entries can be stripped */
+   entry_size = get_section_entry_size(sec->base, kelf);
+   if (entry_size == 0)
+   continue;
+
+   /* alloc buffer for new base section */
+   dst = malloc(sec->base->sh.sh_size);
+   if (!dst)
+   ERROR("malloc");
+
+   /* iterate through all entries of a corresponding base section 
for this RELA section */
+   for ( src = sec->base->data->d_buf; src_offset < 
sec->base->sh.sh_size; src_offset += entry_size ) {
+   bool found_valid = false;
+
+   list_for_each_entry_safe(rela, safe, >relas, list) 
{
+

[Xen-devel] [livepatch-build-tools part3 2/3] create-diff-object: Extend patchability verification: STN_UNDEF

[Pawel Wieczorkiewicz]

During verification check if all sections do not contain any entries
with undefined symbols (STN_UNDEF). This situation can happen when a
section is copied over from its original object to a patched object,
but various symbols related to the section are not copied along.
This scenario happens typically during stacked hotpatches creation
(between 2 different hotpatch modules).

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Martin Pohlack 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
Reviewed-by: Andra-Irina Paraschiv 

CR: https://code.amazon.com/reviews/CR-7368645
---
 create-diff-object.c | 60 
 1 file changed, 60 insertions(+)

diff --git a/create-diff-object.c b/create-diff-object.c
index af2245c..96b6716 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1448,6 +1448,31 @@ static void kpatch_print_changes(struct kpatch_elf *kelf)
}
 }
 
+static inline int get_section_entry_size(const struct section *sec, struct 
kpatch_elf *kelf)
+{
+   int entry_size;
+
+   /*
+* Base sections typically do not define fixed size elements.
+* Detect section's element size in case it's a special section.
+* Otherwise, skip it due to an unknown sh_entsize.
+*/
+   entry_size = sec->sh.sh_entsize;
+   if (entry_size == 0) {
+   struct special_section *special;
+
+   /* Find special section group_size. */
+   for (special = special_sections; special->name; special++) {
+   /* Match sections starting with special->name prefix */
+   if (!strncmp(sec->name, special->name, 
strlen(special->name))) {
+   return special->group_size(kelf, 0);
+   }
+   }
+}
+
+return entry_size;
+}
+
 static void kpatch_verify_patchability(struct kpatch_elf *kelf)
 {
struct section *sec;
@@ -1471,6 +1496,41 @@ static void kpatch_verify_patchability(struct kpatch_elf 
*kelf)
errs++;
}
 
+   if (sec->include) {
+   if (!is_standard_section(sec) && !is_rela_section(sec) 
&&
+   !is_debug_section(sec) && !is_special_section(sec)) 
{
+   if (!is_referenced_section(sec, kelf)) {
+   log_normal("section %s included, but 
not referenced\n", sec->name);
+   errs++;
+   }
+   }
+
+   /* Check if a RELA section does not contain any entries 
with
+* undefined symbols (STN_UNDEF). This situation can 
happen
+* when a section is copied over from its original 
object to
+* a patched object, but various symbols related to the 
section
+* are not copied along.
+*/
+   if (is_rela_section(sec)) {
+   int offset, entry_size = 
get_section_entry_size(sec, kelf);
+   struct rela *rela;
+
+   for ( offset = 0; offset < 
sec->base->data->d_size && entry_size; offset += entry_size ) {
+   list_for_each_entry(rela, >relas, 
list) {
+   if (rela->offset < offset || 
rela->offset >= offset + entry_size)
+   continue;
+
+   if 
((GELF_R_SYM(rela->rela.r_info) == STN_UNDEF) ||
+   (!rela->sym->include && 
(rela->sym->status == SAME))) {
+   log_normal("section %s 
has an entry with a STN_UNDEF symbol: %s\n",
+  sec->name, 
rela->sym->name ? rela->sym->name : "none");
+   errs++;
+   }
+   }
+   }
+   }
+   }
+
/*
 * ensure we aren't including .data.* or .bss.*
 * (.data.unlikely is ok b/c it only has __warned vars)
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   24 days
Failing since134068  2019-03-25 12:00:51 Z   22 days  111 attempts
Testing same since   134834  2019-04-15 19:00:48 Z0 days5 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

[Xen-devel] [livepatch-build-tools part2 2/6] common: Add is_referenced_section() helper function

[Pawel Wieczorkiewicz]

This function checks if given section has an included corresponding
RELA section and/or any of the symbols table symbols references the
section. Section associated symbols are ignored here as there is
always such a symbol for every section.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 common.c | 22 +-
 common.h |  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/common.c b/common.c
index 1fb07cb..c968299 100644
--- a/common.c
+++ b/common.c
@@ -15,7 +15,7 @@
 
 int is_rela_section(struct section *sec)
 {
-   return (sec->sh.sh_type == SHT_RELA);
+   return sec && (sec->sh.sh_type == SHT_RELA);
 }
 
 int is_local_sym(struct symbol *sym)
@@ -270,6 +270,26 @@ int is_standard_section(struct section *sec)
}
 }
 
+int is_referenced_section(const struct section *sec, const struct kpatch_elf 
*kelf)
+{
+   struct symbol *sym;
+
+   if (is_rela_section(sec->rela) && sec->rela->include)
+   return true;
+
+   list_for_each_entry(sym, >symbols, list) {
+   if (!sym->include || !sym->sec)
+   continue;
+   /* Ignore section associated sections */
+   if (sym->type == STT_SECTION)
+   continue;
+   if (sym->sec->index == sec->index)
+   return true;
+   }
+
+   return false;
+}
+
 /* returns the offset of the string in the string table */
 int offset_of_string(struct list_head *list, char *name)
 {
diff --git a/common.h b/common.h
index cda690d..affe16b 100644
--- a/common.h
+++ b/common.h
@@ -151,6 +151,7 @@ int is_text_section(struct section *sec);
 int is_debug_section(struct section *sec);
 int is_rela_section(struct section *sec);
 int is_standard_section(struct section *sec);
+int is_referenced_section(const struct section *sec, const struct kpatch_elf 
*kelf);
 int is_local_sym(struct symbol *sym);
 
 void rela_insn(struct section *sec, struct rela *rela, struct insn *insn);
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools part2 3/6] create-diff-object: Add is_special_section() helper function

[Pawel Wieczorkiewicz]

This function determines, based on the given section name, if the
sections belongs to the special sections category.
It treats a name from the special_sections array as a prefix. Any
sections whose name starts with special section prefix is considered
a special section.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 common.c | 23 +++
 common.h |  1 +
 2 files changed, 24 insertions(+)

diff --git a/common.c b/common.c
index c968299..a2c860b 100644
--- a/common.c
+++ b/common.c
@@ -290,6 +290,29 @@ int is_referenced_section(const struct section *sec, const 
struct kpatch_elf *ke
return false;
 }
 
+int is_special_section(struct section *sec)
+{
+   static struct special_section_names {
+   const char *name;
+   } names[] = {
+   { .name = ".bug_frames" },
+   { .name = ".fixup"  },
+   { .name = ".ex_table"   },
+   { .name = ".altinstructions"},
+   { .name = ".altinstr_replacement"   },
+   { .name = ".livepatch.hooks"},
+   { .name = NULL  },
+   };
+   struct special_section_names *special;
+
+   for (special = names; special->name; special++) {
+   if (!strncmp(sec->name, special->name, strlen(special->name)))
+   return true;
+   }
+
+   return false;
+}
+
 /* returns the offset of the string in the string table */
 int offset_of_string(struct list_head *list, char *name)
 {
diff --git a/common.h b/common.h
index affe16b..6d38e88 100644
--- a/common.h
+++ b/common.h
@@ -152,6 +152,7 @@ int is_debug_section(struct section *sec);
 int is_rela_section(struct section *sec);
 int is_standard_section(struct section *sec);
 int is_referenced_section(const struct section *sec, const struct kpatch_elf 
*kelf);
+int is_special_section(struct section *sec);
 int is_local_sym(struct symbol *sym);
 
 void rela_insn(struct section *sec, struct rela *rela, struct insn *insn);
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools part2 5/6] create-diff-object: Add new entries to special sections array

[Pawel Wieczorkiewicz]

Handle .livepatch.hooks* and .altinstr_replacement sections as the
special sections with assigned group_size resolution function.
By default each .livepatch.hooks* sections' entry is 8 bytes long (a
pointer). The .altinstr_replacement section follows the .altinstructions
section settings.

Allow to specify different .livepatch.hooks* section entry size using
shell environment variable HOOK_STRUCT_SIZE.

Cleanup an incorrect indentation around group_size resulution functions.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 create-diff-object.c | 87 
 1 file changed, 54 insertions(+), 33 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index b0b4dcb..f6060cd 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -960,51 +960,64 @@ static void kpatch_mark_constant_labels_same(struct 
kpatch_elf *kelf)
 
 static int bug_frames_group_size(struct kpatch_elf *kelf, int offset)
 {
-static int size = 0;
-char *str;
-if (!size) {
-str = getenv("BUG_STRUCT_SIZE");
-size = str ? atoi(str) : 8;
-}
-
-return size;
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("BUG_STRUCT_SIZE");
+   size = str ? atoi(str) : 8;
+   }
+
+   return size;
 }
 
 static int bug_frames_3_group_size(struct kpatch_elf *kelf, int offset)
 {
-static int size = 0;
-char *str;
-if (!size) {
-str = getenv("BUG_STRUCT_SIZE");
-size = str ? atoi(str) : 16;
-}
-
-return size;
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("BUG_STRUCT_SIZE");
+   size = str ? atoi(str) : 16;
+   }
+
+   return size;
 }
 
 static int ex_table_group_size(struct kpatch_elf *kelf, int offset)
 {
-static int size = 0;
-char *str;
-if (!size) {
-str = getenv("EX_STRUCT_SIZE");
-size = str ? atoi(str) : 8;
-}
-
-return size;
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("EX_STRUCT_SIZE");
+   size = str ? atoi(str) : 8;
+   }
+
+   return size;
 }
 
 static int altinstructions_group_size(struct kpatch_elf *kelf, int offset)
 {
-static int size = 0;
-char *str;
-if (!size) {
-str = getenv("ALT_STRUCT_SIZE");
-size = str ? atoi(str) : 12;
-}
-
-printf("altinstr_size=%d\n", size);
-return size;
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("ALT_STRUCT_SIZE");
+   size = str ? atoi(str) : 12;
+   }
+
+   printf("altinstr_size=%d\n", size);
+   return size;
+}
+
+static int livepatch_hooks_group_size(struct kpatch_elf *kelf, int offset)
+{
+   static int size = 0;
+   char *str;
+   if (!size) {
+   str = getenv("HOOK_STRUCT_SIZE");
+   size = str ? atoi(str) : 8;
+   }
+
+   printf("livepatch_hooks_size=%d\n", size);
+   return size;
 }
 
 /*
@@ -1084,6 +1097,14 @@ static struct special_section special_sections[] = {
.name   = ".altinstructions",
.group_size = altinstructions_group_size,
},
+   {
+   .name   = ".altinstr_replacement",
+   .group_size = altinstructions_group_size,
+   },
+   {
+   .name   = ".livepatch.hooks",
+   .group_size = livepatch_hooks_group_size,
+   },
{},
 };
 
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools part2 4/6] livepatch-build: detect special section group sizes

[Pawel Wieczorkiewicz]

Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions
in the DWARF metadata.

This is a livepatch backport of kpatch upstream commit [1]:
kpatch-build: detect special section group sizes 170449847136a48b19fc

Xen only deals with alt_instr, bug_frame and exception_table_entry
structures, so sizes of these structers are obtained from xen-syms.

This change is needed since with recent Xen the alt_instr structure
has changed size from 12 to 14 bytes.

[1] 
https://github.com/jpoimboe/kpatch/commit/170449847136a48b19fcceb19c1d4d257d386b56

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Martin Mazein 
---
 create-diff-object.c | 60 
 livepatch-build  | 23 
 2 files changed, 74 insertions(+), 9 deletions(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index 1e6e617..b0b4dcb 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -958,12 +958,54 @@ static void kpatch_mark_constant_labels_same(struct 
kpatch_elf *kelf)
}
 }
 
-static int bug_frames_0_group_size(struct kpatch_elf *kelf, int offset) { 
return 8; }
-static int bug_frames_1_group_size(struct kpatch_elf *kelf, int offset) { 
return 8; }
-static int bug_frames_2_group_size(struct kpatch_elf *kelf, int offset) { 
return 8; }
-static int bug_frames_3_group_size(struct kpatch_elf *kelf, int offset) { 
return 16; }
-static int ex_table_group_size(struct kpatch_elf *kelf, int offset) { return 
8; }
-static int altinstructions_group_size(struct kpatch_elf *kelf, int offset) { 
return 12; }
+static int bug_frames_group_size(struct kpatch_elf *kelf, int offset)
+{
+static int size = 0;
+char *str;
+if (!size) {
+str = getenv("BUG_STRUCT_SIZE");
+size = str ? atoi(str) : 8;
+}
+
+return size;
+}
+
+static int bug_frames_3_group_size(struct kpatch_elf *kelf, int offset)
+{
+static int size = 0;
+char *str;
+if (!size) {
+str = getenv("BUG_STRUCT_SIZE");
+size = str ? atoi(str) : 16;
+}
+
+return size;
+}
+
+static int ex_table_group_size(struct kpatch_elf *kelf, int offset)
+{
+static int size = 0;
+char *str;
+if (!size) {
+str = getenv("EX_STRUCT_SIZE");
+size = str ? atoi(str) : 8;
+}
+
+return size;
+}
+
+static int altinstructions_group_size(struct kpatch_elf *kelf, int offset)
+{
+static int size = 0;
+char *str;
+if (!size) {
+str = getenv("ALT_STRUCT_SIZE");
+size = str ? atoi(str) : 12;
+}
+
+printf("altinstr_size=%d\n", size);
+return size;
+}
 
 /*
  * The rela groups in the .fixup section vary in size.  The beginning of each
@@ -1016,15 +1058,15 @@ static int fixup_group_size(struct kpatch_elf *kelf, 
int offset)
 static struct special_section special_sections[] = {
{
.name   = ".bug_frames.0",
-   .group_size = bug_frames_0_group_size,
+   .group_size = bug_frames_group_size,
},
{
.name   = ".bug_frames.1",
-   .group_size = bug_frames_1_group_size,
+   .group_size = bug_frames_group_size,
},
{
.name   = ".bug_frames.2",
-   .group_size = bug_frames_2_group_size,
+   .group_size = bug_frames_group_size,
},
{
.name   = ".bug_frames.3",
diff --git a/livepatch-build b/livepatch-build
index c057fa1..a6cae12 100755
--- a/livepatch-build
+++ b/livepatch-build
@@ -284,6 +284,29 @@ echo "Output directory: ${OUTPUT}"
 echo ""
 echo
 
+if [ -f "$XENSYMS" ]; then
+echo "Reading special section data"
+SPECIAL_VARS=$(readelf -wi "$XENSYMS" |
+   gawk --non-decimal-data '
+   BEGIN { a = b = e = 0 }
+   a == 0 && /DW_AT_name.* alt_instr/ {a = 1; next}
+   b == 0 && /DW_AT_name.* bug_frame/ {b = 1; next}
+   e == 0 && /DW_AT_name.* exception_table_entry/ {e = 1; next}
+   a == 1 {printf("export ALT_STRUCT_SIZE=%d\n", $4); a = 2}
+   b == 1 {printf("export BUG_STRUCT_SIZE=%d\n", $4); b = 2}
+   e == 1 {printf("export EX_STRUCT_SIZE=%d\n", $4); e = 2}
+   a == 2 && b == 2 && e == 2 {exit}')
+[[ -n $SPECIAL_VARS ]] && eval "$SPECIAL_VARS"
+if [[ -z $ALT_STRUCT_SIZE ]] || [[ -z $BUG_STRUCT_SIZE ]] || [[ -z 
$EX_STRUCT_SIZE ]]; then
+die "can't find special struct size"
+fi
+for i in $ALT_STRUCT_SIZE $BUG_STRUCT_SIZE $EX_STRUCT_SIZE; do
+if [[ ! $i -gt 0 ]] || [[ ! $i -le 16 ]]; then
+die "invalid special struct size $i"
+fi
+done
+fi
+
 if [ "${SKIP}" != "build" ]; then
 [ -e "${OUTPUT}" ] && die "Output directory exists"
 grep -q 

[Xen-devel] [livepatch-build-tools part2 1/6] common: Add is_standard_section() helper function

[Pawel Wieczorkiewicz]

Detect standard (always to be included) sections via their section
header type. The standard sections: ".shstrtab", ".symtab", ".strtab"
are either of type SHT_SYMTAB or SHT_STRTAB.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 common.c | 12 
 common.h |  1 +
 create-diff-object.c |  5 +
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/common.c b/common.c
index bc63955..1fb07cb 100644
--- a/common.c
+++ b/common.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "list.h"
@@ -258,6 +259,17 @@ int is_debug_section(struct section *sec)
return !strncmp(name, ".debug_", 7);
 }
 
+int is_standard_section(struct section *sec)
+{
+   switch (sec->sh.sh_type) {
+   case SHT_STRTAB:
+   case SHT_SYMTAB:
+   return true;
+   default:
+   return false;
+   }
+}
+
 /* returns the offset of the string in the string table */
 int offset_of_string(struct list_head *list, char *name)
 {
diff --git a/common.h b/common.h
index 7599fe7..cda690d 100644
--- a/common.h
+++ b/common.h
@@ -150,6 +150,7 @@ struct symbol *find_symbol_by_name(struct list_head *list, 
const char *name);
 int is_text_section(struct section *sec);
 int is_debug_section(struct section *sec);
 int is_rela_section(struct section *sec);
+int is_standard_section(struct section *sec);
 int is_local_sym(struct symbol *sym);
 
 void rela_insn(struct section *sec, struct rela *rela, struct insn *insn);
diff --git a/create-diff-object.c b/create-diff-object.c
index 82f777e..1e6e617 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1278,10 +1278,7 @@ static void kpatch_include_standard_elements(struct 
kpatch_elf *kelf)
 
list_for_each_entry(sec, >sections, list) {
/* include these sections even if they haven't changed */
-   if (!strcmp(sec->name, ".shstrtab") ||
-   !strcmp(sec->name, ".strtab") ||
-   !strcmp(sec->name, ".symtab") ||
-   should_include_str_section(sec->name)) {
+   if (is_standard_section(sec) || 
should_include_str_section(sec->name)) {
sec->include = 1;
if (sec->secsym)
sec->secsym->include = 1;
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [livepatch-build-tools part2 6/6] create-diff-object: Do not include all .rodata sections

[Pawel Wieczorkiewicz]

Starting with the "2af6f1aa6233 Fix patch creation with GCC 6.1+" commit
all .rodata sections are included by default (regardless of whether they
are needed or not).
During stacked hotpatch builds it leads to unnecessary duplication of
the .rodata sections as each and every consecutive hotpatch contains all
the .rodata section of previous hotpatches.

To prevent this situation, mark the .rodata section for inclusion only
if they are referenced by any of the current hotpatch symbols (or a
corresponding RELA section).

Extend patchability verification to detect all non-standard, non-rela,
non-debug and non-special sections that are not referenced by any of
the symbols or RELA sections.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Norbert Manthey 
---
 create-diff-object.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/create-diff-object.c b/create-diff-object.c
index f6060cd..f7eb421 100644
--- a/create-diff-object.c
+++ b/create-diff-object.c
@@ -1341,7 +1341,7 @@ static void kpatch_include_standard_elements(struct 
kpatch_elf *kelf)
 
list_for_each_entry(sec, >sections, list) {
/* include these sections even if they haven't changed */
-   if (is_standard_section(sec) || 
should_include_str_section(sec->name)) {
+   if (is_standard_section(sec)) {
sec->include = 1;
if (sec->secsym)
sec->secsym->include = 1;
@@ -1352,6 +1352,19 @@ static void kpatch_include_standard_elements(struct 
kpatch_elf *kelf)
list_entry(kelf->symbols.next, struct symbol, list)->include = 1;
 }
 
+static void kpatch_include_standard_string_elements(struct kpatch_elf *kelf)
+{
+   struct section *sec;
+
+   list_for_each_entry(sec, >sections, list) {
+   if (should_include_str_section(sec->name) && 
is_referenced_section(sec, kelf)) {
+   sec->include = 1;
+   if (sec->secsym)
+   sec->secsym->include = 1;
+   }
+   }
+}
+
 #define inc_printf(fmt, ...) \
log_debug("%*s" fmt, recurselevel, "", ##__VA_ARGS__);
 
@@ -1531,6 +1544,16 @@ static void kpatch_verify_patchability(struct kpatch_elf 
*kelf)
errs++;
}
 
+   if (sec->include) {
+   if (!is_standard_section(sec) && !is_rela_section(sec) 
&&
+   !is_debug_section(sec) && !is_special_section(sec)) 
{
+   if (!is_referenced_section(sec, kelf)) {
+   log_normal("section %s included, but 
not referenced\n", sec->name);
+   errs++;
+   }
+   }
+   }
+
/*
 * ensure we aren't including .data.* or .bss.*
 * (.data.unlikely is ok b/c it only has __warned vars)
@@ -2062,6 +2085,8 @@ int main(int argc, char *argv[])
kpatch_include_debug_sections(kelf_patched);
log_debug("Include hook elements\n");
kpatch_include_hook_elements(kelf_patched);
+   log_debug("Include standard string elements\n");
+   kpatch_include_standard_string_elements(kelf_patched);
log_debug("Include new globals\n");
new_globals_exist = kpatch_include_new_globals(kelf_patched);
log_debug("new_globals_exist = %d\n", new_globals_exist);
-- 
2.16.5




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Christian Schlaeger, Ralf Herbrich
Ust-ID: DE 289 237 879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B



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

[Xen-devel] [REBASE PATCH v5 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_map_pages()

[Souptick Joarder]

Convert to use vm_map_pages() to map range of kernel memory
to user vma.

vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer,
not as a in-buffer offset by design and it always want to mmap a
whole buffer from its beginning.

Signed-off-by: Souptick Joarder 
Suggested-by: Marek Szyprowski 
Reviewed-by: Marek Szyprowski 
---
 drivers/media/common/videobuf2/videobuf2-core.c|  7 +++
 .../media/common/videobuf2/videobuf2-dma-contig.c  |  6 --
 drivers/media/common/videobuf2/videobuf2-dma-sg.c  | 22 ++
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-core.c 
b/drivers/media/common/videobuf2/videobuf2-core.c
index 70e8c33..ca4577a 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -2175,6 +2175,13 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct 
*vma)
goto unlock;
}
 
+   /*
+* vm_pgoff is treated in V4L2 API as a 'cookie' to select a buffer,
+* not as a in-buffer offset. We always want to mmap a whole buffer
+* from its beginning.
+*/
+   vma->vm_pgoff = 0;
+
ret = call_memop(vb, mmap, vb->planes[plane].mem_priv, vma);
 
 unlock:
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index aff0ab7..46245c5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -186,12 +186,6 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
return -EINVAL;
}
 
-   /*
-* dma_mmap_* uses vm_pgoff as in-buffer offset, but we want to
-* map whole buffer
-*/
-   vma->vm_pgoff = 0;
-
ret = dma_mmap_attrs(buf->dev, vma, buf->cookie,
buf->dma_addr, buf->size, buf->attrs);
 
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 015e737..d6b8eca 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -328,28 +328,18 @@ static unsigned int vb2_dma_sg_num_users(void *buf_priv)
 static int vb2_dma_sg_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dma_sg_buf *buf = buf_priv;
-   unsigned long uaddr = vma->vm_start;
-   unsigned long usize = vma->vm_end - vma->vm_start;
-   int i = 0;
+   int err;
 
if (!buf) {
printk(KERN_ERR "No memory to map\n");
return -EINVAL;
}
 
-   do {
-   int ret;
-
-   ret = vm_insert_page(vma, uaddr, buf->pages[i++]);
-   if (ret) {
-   printk(KERN_ERR "Remapping memory, error: %d\n", ret);
-   return ret;
-   }
-
-   uaddr += PAGE_SIZE;
-   usize -= PAGE_SIZE;
-   } while (usize > 0);
-
+   err = vm_map_pages(vma, buf->pages, buf->num_pages);
+   if (err) {
+   printk(KERN_ERR "Remapping memory, error: %d\n", err);
+   return err;
+   }
 
/*
 * Use common vm_area operations to track buffer refcount.
-- 
1.9.1


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

[Xen-devel] [REBASE PATCH v5 2/9] arm: mm: dma-mapping: Convert to use vm_map_pages()

[Souptick Joarder]

Convert to use vm_map_pages() to map range of kernel
memory to user vma.

Signed-off-by: Souptick Joarder 
---
 arch/arm/mm/dma-mapping.c | 22 ++
 1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f1e2922..de7c76e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1575,31 +1575,21 @@ static int __arm_iommu_mmap_attrs(struct device *dev, 
struct vm_area_struct *vma
void *cpu_addr, dma_addr_t dma_addr, size_t size,
unsigned long attrs)
 {
-   unsigned long uaddr = vma->vm_start;
-   unsigned long usize = vma->vm_end - vma->vm_start;
struct page **pages = __iommu_get_pages(cpu_addr, attrs);
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   unsigned long off = vma->vm_pgoff;
+   int err;
 
if (!pages)
return -ENXIO;
 
-   if (off >= nr_pages || (usize >> PAGE_SHIFT) > nr_pages - off)
+   if (vma->vm_pgoff >= nr_pages)
return -ENXIO;
 
-   pages += off;
-
-   do {
-   int ret = vm_insert_page(vma, uaddr, *pages++);
-   if (ret) {
-   pr_err("Remapping memory failed: %d\n", ret);
-   return ret;
-   }
-   uaddr += PAGE_SIZE;
-   usize -= PAGE_SIZE;
-   } while (usize > 0);
+   err = vm_map_pages(vma, pages, nr_pages);
+   if (err)
+   pr_err("Remapping memory failed: %d\n", err);
 
-   return 0;
+   return err;
 }
 static int arm_iommu_mmap_attrs(struct device *dev,
struct vm_area_struct *vma, void *cpu_addr,
-- 
1.9.1


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

[Xen-devel] [REBASE PATCH v5 3/9] drivers/firewire/core-iso.c: Convert to use vm_map_pages_zero()

[Souptick Joarder]

Convert to use vm_map_pages_zero() to map range of kernel memory
to user vma.

This driver has ignored vm_pgoff and mapped the entire pages. We
could later "fix" these drivers to behave according to the normal
vm_pgoff offsetting simply by removing the _zero suffix on the
function name and if that causes regressions, it gives us an easy
way to revert.

Signed-off-by: Souptick Joarder 
---
 drivers/firewire/core-iso.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/firewire/core-iso.c b/drivers/firewire/core-iso.c
index 35e784c..5414eb1 100644
--- a/drivers/firewire/core-iso.c
+++ b/drivers/firewire/core-iso.c
@@ -107,19 +107,8 @@ int fw_iso_buffer_init(struct fw_iso_buffer *buffer, 
struct fw_card *card,
 int fw_iso_buffer_map_vma(struct fw_iso_buffer *buffer,
  struct vm_area_struct *vma)
 {
-   unsigned long uaddr;
-   int i, err;
-
-   uaddr = vma->vm_start;
-   for (i = 0; i < buffer->page_count; i++) {
-   err = vm_insert_page(vma, uaddr, buffer->pages[i]);
-   if (err)
-   return err;
-
-   uaddr += PAGE_SIZE;
-   }
-
-   return 0;
+   return vm_map_pages_zero(vma, buffer->pages,
+   buffer->page_count);
 }
 
 void fw_iso_buffer_destroy(struct fw_iso_buffer *buffer,
-- 
1.9.1


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

[Xen-devel] [REBASE PATCH v5 6/9] iommu/dma-iommu.c: Convert to use vm_map_pages()

[Souptick Joarder]

Convert to use vm_map_pages() to map range of kernel
memory to user vma.

Signed-off-by: Souptick Joarder 
---
 drivers/iommu/dma-iommu.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index d19f3d6..bacebff 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -620,17 +620,7 @@ struct page **iommu_dma_alloc(struct device *dev, size_t 
size, gfp_t gfp,
 
 int iommu_dma_mmap(struct page **pages, size_t size, struct vm_area_struct 
*vma)
 {
-   unsigned long uaddr = vma->vm_start;
-   unsigned int i, count = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   int ret = -ENXIO;
-
-   for (i = vma->vm_pgoff; i < count && uaddr < vma->vm_end; i++) {
-   ret = vm_insert_page(vma, uaddr, pages[i]);
-   if (ret)
-   break;
-   uaddr += PAGE_SIZE;
-   }
-   return ret;
+   return vm_map_pages(vma, pages, PAGE_ALIGN(size) >> PAGE_SHIFT);
 }
 
 static dma_addr_t __iommu_dma_map(struct device *dev, phys_addr_t phys,
-- 
1.9.1


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

[Xen-devel] [REBASE PATCH v5 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_map_pages()

[Souptick Joarder]

Convert to use vm_map_pages() to map range of kernel
memory to user vma.

Tested on Rockchip hardware and display is working,
including talking to Lima via prime.

Signed-off-by: Souptick Joarder 
Tested-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index a8db758..a2ebb08 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -221,26 +221,13 @@ static int rockchip_drm_gem_object_mmap_iommu(struct 
drm_gem_object *obj,
  struct vm_area_struct *vma)
 {
struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
-   unsigned int i, count = obj->size >> PAGE_SHIFT;
+   unsigned int count = obj->size >> PAGE_SHIFT;
unsigned long user_count = vma_pages(vma);
-   unsigned long uaddr = vma->vm_start;
-   unsigned long offset = vma->vm_pgoff;
-   unsigned long end = user_count + offset;
-   int ret;
 
if (user_count == 0)
return -ENXIO;
-   if (end > count)
-   return -ENXIO;
 
-   for (i = offset; i < end; i++) {
-   ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
-   if (ret)
-   return ret;
-   uaddr += PAGE_SIZE;
-   }
-
-   return 0;
+   return vm_map_pages(vma, rk_obj->pages, count);
 }
 
 static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v2] x86/msr: Fix fallout from mostly c/s 832c180

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of 
> Andrew Cooper
> Sent: 15 April 2019 13:03
> To: Xen-devel 
> Cc: Kevin Tian ; Wei Liu ; Jan 
> Beulich ;
> Andrew Cooper ; Jun Nakajima 
> ; Roger Pau Monne
> 
> Subject: [Xen-devel] [PATCH v2] x86/msr: Fix fallout from mostly c/s 832c180
> 
>  * Fix the shim build by providing a !CONFIG_HVM declaration for
>hvm_get_guest_bndcfgs(), and removing the introduced
>ASSERT(is_hvm_domain(d))'s.  They are needed for DCE to keep the build
>working.  Furthermore, in this way, the risk of runtime type confusion is
>removed.
>  * Revert the de-const'ing of the vcpu pointer in vmx_get_guest_bndcfgs().
>vmx_vmcs_enter() really does mutate the vcpu, and may cause it to undergo a
>full de/reschedule, which is in violation of the ABI described by
>hvm_get_guest_bndcfgs().  guest_rdmsr() was always going to need to lose
>its const parameter, and this was the correct time for it to happen.
>  * The MSRs in vcpu_msrs are in numeric order.  Re-position XSS to match.

My R-b was actually contingent on a comment in the header above the sruct to 
state the desire for the MSRs to be in numeric order.

  Paul

> 
> Signed-off-by: Andrew Cooper 
> Reviewed-by: Paul Durrant 
> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> 
> v2:
>  * Rephrase the commit message
> ---
>  xen/arch/x86/hvm/vmx/vmx.c |  5 +
>  xen/arch/x86/msr.c | 18 +-
>  xen/arch/x86/pv/emul-priv-op.c |  2 +-
>  xen/include/asm-x86/hvm/hvm.h  |  5 +++--
>  xen/include/asm-x86/msr.h  | 12 ++--
>  5 files changed, 16 insertions(+), 26 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index c46e05b..283eb7b 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1150,11 +1150,8 @@ static bool vmx_set_guest_bndcfgs(struct vcpu *v, u64 
> val)
>  return true;
>  }
> 
> -static bool vmx_get_guest_bndcfgs(const struct vcpu *cv, u64 *val)
> +static bool vmx_get_guest_bndcfgs(struct vcpu *v, u64 *val)
>  {
> -/* Get a non-const pointer for vmx_vmcs_enter() */
> -struct vcpu *v = cv->domain->vcpu[cv->vcpu_id];
> -
>  ASSERT(cpu_has_mpx && cpu_has_vmx_mpx);
> 
>  vmx_vmcs_enter(v);
> diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c
> index 815d599..0049a73 100644
> --- a/xen/arch/x86/msr.c
> +++ b/xen/arch/x86/msr.c
> @@ -115,7 +115,7 @@ int init_vcpu_msr_policy(struct vcpu *v)
>  return 0;
>  }
> 
> -int guest_rdmsr(const struct vcpu *v, uint32_t msr, uint64_t *val)
> +int guest_rdmsr(struct vcpu *v, uint32_t msr, uint64_t *val)
>  {
>  const struct vcpu *curr = current;
>  const struct domain *d = v->domain;
> @@ -182,13 +182,9 @@ int guest_rdmsr(const struct vcpu *v, uint32_t msr, 
> uint64_t *val)
>  break;
> 
>  case MSR_IA32_BNDCFGS:
> -if ( !cp->feat.mpx )
> +if ( !cp->feat.mpx || !is_hvm_domain(d) ||
> + !hvm_get_guest_bndcfgs(v, val) )
>  goto gp_fault;
> -
> -ASSERT(is_hvm_domain(d));
> -if (!hvm_get_guest_bndcfgs(v, val) )
> -goto gp_fault;
> -
>  break;
> 
>  case MSR_IA32_XSS:
> @@ -375,13 +371,9 @@ int guest_wrmsr(struct vcpu *v, uint32_t msr, uint64_t 
> val)
>  break;
> 
>  case MSR_IA32_BNDCFGS:
> -if ( !cp->feat.mpx )
> +if ( !cp->feat.mpx || !is_hvm_domain(d) ||
> + !hvm_set_guest_bndcfgs(v, val) )
>  goto gp_fault;
> -
> -ASSERT(is_hvm_domain(d));
> -if ( !hvm_set_guest_bndcfgs(v, val) )
> -goto gp_fault;
> -
>  break;
> 
>  case MSR_IA32_XSS:
> diff --git a/xen/arch/x86/pv/emul-priv-op.c b/xen/arch/x86/pv/emul-priv-op.c
> index a55a400..af74f50 100644
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -819,7 +819,7 @@ static inline bool is_cpufreq_controller(const struct 
> domain *d)
>  static int read_msr(unsigned int reg, uint64_t *val,
>  struct x86_emulate_ctxt *ctxt)
>  {
> -const struct vcpu *curr = current;
> +struct vcpu *curr = current;
>  const struct domain *currd = curr->domain;
>  bool vpmu_msr = false;
>  int ret;
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index c811fa9..157f0de 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -145,7 +145,7 @@ struct hvm_function_table {
>  int  (*get_guest_pat)(struct vcpu *v, u64 *);
>  int  (*set_guest_pat)(struct vcpu *v, u64);
> 
> -bool (*get_guest_bndcfgs)(const struct vcpu *v, u64 *);
> +bool (*get_guest_bndcfgs)(struct vcpu *v, u64 *);
>  bool (*set_guest_bndcfgs)(struct vcpu *v, u64);
> 
>  void (*set_tsc_offset)(struct vcpu *v, u64 offset, u64 at_tsc);
> @@ -444,7 +444,7 @@ static inline unsigned long 

Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot

[Roger Pau Monné]

Adding the Linux Xen maintainers, in case they can provide some insight.

On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote:
> ref: from chat in #xen
> 
>   [08:53]  pgnd: would be good to send an email so we can keep 
> track of this in a more formal way.
> 
> I've got Xen PV Dom0 booted on a Linux UEFI box
> 
>   dmesg | grep -i "xen version"
>   [1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD)
> 
>   uname -rm
>   5.0.7-lp150.5.g012b5f1-default x86_64
> 
>   lsb_release -rd
>   Description:openSUSE Leap 15.0
>   Release:15.0
> 
>   rpm -qa | grep -i qemu | egrep "seabios|u-3"
>   qemu-seabios-1.12.0-lp150.513.13.noarch
>   qemu-3.1.0-lp150.513.13.x86_64
> 
>   rpm -qa | grep -i ovmf
>   ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
>   
> qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch
>   ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64
> 
>   rpm -qa | grep grub2 |egrep "xen|efi"
>   grub2-x86_64-efi-2.02-lp150.64.10.noarch
>   grub2-x86_64-xen-2.02-lp150.64.10.noarch
> &
> 
>   rpm -qa | grep -i efi | grep git | sort
>   efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64
>   efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64
>   libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64
> 
> note these^^ EFI* tools -- src from efi master branch, pkgs available here,
> 
>   https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar
>   
> https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr
> 
> -- were needed, as distro packaged versions' were old/problematic ...
> 
> With this^^ config, all's well
> 
>   serial boot log
>   ...
>   [0.00] efi: EFI v2.31 by American Megatrends
>   [0.00] efi:  ESRT=0x9ef8d998  ACPI 2.0=0x9e819000  
> ACPI=0x9e819000  SMBIOS=0xf04c0  MPS=0xfd490
>   [0.00] SMBIOS 2.7 present.
>   [0.00] Hypervisor detected: Xen PV
>   [0.00] Xen version 4.12.
>   ...
> 
> at shell prompt,
> 
>   xl list
>   NameID   Mem VCPUs  
> State   Time(s)
>   Domain-0 0  4016 4 
> r-5949.6
>   Xenstore 131 1 
> -b   0.2
> 
>   efibootmgr -v
>   BootCurrent: 
>   Timeout: 1 seconds
>   BootOrder: 
>   Boot* openSUSE-pgnXEN 
> HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi)
> dp: 04 01 2a ... 04 00
> 
> enabling PVH Dom0, adding to grub configs,
> 
>   GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..."
>   GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..."
> 
> then mkinitrd & grub reconfig,
> 
>   serial boot log
>   Xen 4.12.0_09-lp150.640 (c/s ) EFI loader
>   ...
>   (XEN) [0027dcded44e] Bootloader: EFI
>   ...
>   Using configuration file 'xen-4.12.0_09-lp150.640.cfg'
>   ...
>   [0.00] BIOS-e820: [mem 
> 0x0001-0x00016a2acfff] usable
>   [0.00] BIOS-e820: [mem 
> 0x00016a2ad000-0x00085dff] unusable
>   [0.00] NX (Execute Disable) protection: active
>   [0.00] SMBIOS 2.7 present.
>   [0.00] Hypervisor detected: Xen HVM
>   [0.00] Xen version 4.12.
>   ...
> 
> Note, there is NO "efi: ..." log content, as in the prior, PV mode example.
> 
> at shell prompt,
> 
>   xl list
>   NameID   Mem VCPUs  
> State   Time(s)
>   Domain-0 0  4015 4 
> r- 563.0
>   Xenstore 131 1 
> -b   0.0
> 
> but, in this Dom0=pvh mode,
> 
>   efibootmgr -v
>   EFI variables are not supported on this system.

So boot works as expected, it's just interaction with the EFI firmware
by dom0 that seems to be broken. I'm currently setting up a Linux EFI
box to test this, thanks for the report.

Roger.

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

Re: [Xen-devel] [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

[Ian Jackson]

Jan Beulich writes ("Re: [PATCH 3/4] xen/public: Document 
HYPERCALL_console_io()"):
> On 09.04.19 at 13:26,  wrote:
> > I haven't replicated the ` because I have no idea what they are used for. I 
> > would appreciate if you provide pointer how to use them.
> 
> Well, I can only point you at the history of things, e.g.
> 262e118a37 "docs/html/: Annotations for two hypercalls".

That is a reasonable example, but:

There is in fact some documentation for the ` syntax.
See docs/xen-headers, which is the script which scans the .h
files and makes the online hypercall documentation.  The syntax
doc is rather terse, I'm afraid, but it's only a 400-line
script...

I wrote that script because I wanted some kind of browseable
documentation, and I didn't want to totally overhaul the headers.

Ian.

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

Re: [Xen-devel] [linux-arm-xen test] 134708: regressions - all pass

[Ian Jackson]

Julien Grall writes ("Re: [Xen-devel] [linux-arm-xen test] 134708: regressions 
- all pass"):
> On 4/15/19 7:28 PM, osstest service owner wrote:
> > flight 134708 linux-arm-xen real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/134708/
...
> >   test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 
> > 119195
> 
> I am a bit confused with the failure here [1]:
> 
> 2019-04-13 22:36:55 Z -- substep 11 examine-serial/bootloader fail 
> -- 
> 
> IIUC, we are looking for "osstest cookie". However this does not seem to
> appear on rochester0's logs. Any insights how "osstest cookie" will be output?

Hi.  Yes, this is an issue I already discovered...

Ian Jackson writes ("[OSSTEST PATCH 00/62] Update to Debian stable (stretch)"):
> There seem to be a number of outstanding problems which I decided were
> not blockers:
...
>  * The serial output from the new rochester arm64 machines is missing
>some of the grub bootloader messages (and this is detected by one
>of the examine jobs).  I may need help from someone familiar with
>these machines' hardware/firmware.

I decided that this issue was not serious enough to be a blocker.  It
may need some force pushes, especially if we can't fix it soon,
because osstest will try this test, in other flights, on the
rochesters, where it fails, and that looks like a regression.

In particular, this is not a regression in the linux-arm-xen branch.
So we could force push it.


As for the bug:

This check is checking that the osstest serial log captures the output
from the bootloader.  This can be quite important for debugging,
especially to distinguish hardware or configuration problems from
software problems.  Seeing the bootloader output also provides
a useful reference point to people unfamiliar with osstest.

This check is primarily a test on osstest itself; it is also part of
machine commissioning.  The test works by putting a magic string in
the bootloader output.

Compare the failure above
  
http://logs.test-lab.xenproject.org/osstest/logs/134708/test-arm64-arm64-examine/info.html
with this one which ran on laxton1:
  
http://logs.test-lab.xenproject.org/osstest/logs/134643/test-arm64-arm64-examine/info.html

If you look at the final grub config
  
http://logs.test-lab.xenproject.org/osstest/logs/134643/test-arm64-arm64-examine/laxton1--grub.cfg.new
you can see things like this
  menuentry 'osstest cookie 0b4b9311157321d55cca9d25ff49159d Debian GNU/Linux' 
--class debian --class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-simple-a8e4e9c6-4829-402b-93aa-964f9cf39c41' {

In
  
http://logs.test-lab.xenproject.org/osstest/logs/134643/test-arm64-arm64-examine/serial-laxton1.log
near Apr 11 17:07:07.787491, you can see the osstest cookie coming
out in the serial representation, in amongst the cursor positioning
codes.

In
  
http://logs.test-lab.xenproject.org/osstest/logs/134708/test-arm64-arm64-examine/serial-rochester0.log
near Apr 13 22:34:32.442724 you see a banner from grub and then a
bunch of "invalid utf-8 sequence: \304", and at the end some actual
messages from grub.  But the meat of the menu, including the cookie,
is missing.

So the osstest considers the test a failure: the thing it arranged to
appear in the bootloader output was not visible in the serial log.


I have not yet investigated this beyond making these observations.  It
is possible that there is a disagreement over character encoding or
something, and what is happening is that line drawing characters are
being misinterpreted by sympathy.  It might be a firmware bug or a
grub bug or a sympathy bug or a hardware design issue.  I think the
next steps would be to determine exactly what sequence of bytes are
being sent by the host, and to investigate its BIOS options for
controlling serial terminal output.


HTH.

Ian.

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

Re: [Xen-devel] [PATCH] livepatch-build-tools: Detect special section group sizes

[Ross Lagerwall]

On 4/12/19 5:50 AM, Glenn Enright wrote:

A recent xsa livepatch failed to generate due to the following
message in create-diff-object.log ...

/livepatch-build-tools/create-diff-object: ERROR: grant_table.o:
kpatch_regenerate_special_section: 1162: group size mismatch for section
.altinstructions

This is similar to the issue reported and fixed in
https://github.com/dynup/kpatch/pull/528 which says ...
"Hard-coding the special section group sizes is unreliable.
  Instead, determine them dynamically by finding the related
  struct definitions in the DWARF metadata."

Signed-off-by: Glenn Enright 
---
CC: Ross Lagerwall 
CC: Konrad Rzeszutek Wilk 

This patch resulted in a loadable livepatch. The alt section size in my
case was actually 14.

Thanks for the patch!

Reviewed-by: Ross Lagerwall 

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

Re: [Xen-devel] [PATCH 3/4] xen/public: Document HYPERCALL_console_io()

[Julien Grall]

Hi Jan,

On 4/9/19 12:42 PM, Jan Beulich wrote:

On 09.04.19 at 13:26,  wrote:

On 03/04/2019 14:04, Jan Beulich wrote:

Also please note the quotation used by the mentioned
existing doc comments, as well as a few other formal aspects
(like them also making clear what the return type is). I think
that's a model used elsewhere as well, so I think you should
follow it here.


I haven't replicated the ` because I have no idea what they are used for. I
would appreciate if you provide pointer how to use them.


Well, I can only point you at the history of things, e.g.
262e118a37 "docs/html/: Annotations for two hypercalls".


Thank you for the pointer. However, we don't seem to use this formatting 
everywhere. For instance, the formatting used in my patch seems to be 
consistent with xen/include/public/vcpu.h.


Furthermore, the description of the hypercall is done on top of the 
definition of the hypercall number. Before I rework this patch, could we 
agree on what formatting we want?





The other thing is: As mentioned elsewhere, I don't think the
first two parameters should be plain int. I'm not happy to see
this proliferate into documentation as well, i.e. I'd prefer if
this was corrected before adding documentation. Would you
be willing to do this, or should I add it to my todo list?


While switching from cmd from signed to unsigned should be ok. This would
introduce a different behavior of for count.


Since this removes an error condition, I think this is an okay change
to happen, without ...


Are we happy with that, or shall we add a check ((int)count) > 0?


... any such extra check. This also isn't going to introduce any new
real risk of a long running operation or some such - if 2Gb of input
data are fine, I can't see why 4Gb wouldn't be, too.


Fair point. I will update the prototype accordingly.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [Qemu-devel] [Qemu-block] [PATCH 2/3] xen-bus: allow AioContext to be specified for each event channel

[Paul Durrant]

> -Original Message-
[snip]
> > > I wonder if the `'is_external' parameter of aio_set_fd_handler shoud be
> > > `true' here, instead. That flag seems to be used when making a snapshot
> > > of a blockdev, for example.
> > >
> > > That was introduced by:
> > > dca21ef23ba48f6f1428c59f295a857e5dc203c8^..c07bc2c1658fffeee08eb46402b2f66d55b07586
> > >
> > > What do you think?
> >
> > Interesting. I admit I was merely transcribing what qemu_set_fd_handler() 
> > passes without really
> looking into the values. Looking at the arguments that virtio-blk passes to 
> aio_set_event_notifier()
> though, and what 'is_external' means, it would appear that setting it to true 
> is probably the right
> thing to do. Do you want me to send a v2 of the series or can you fix it up?
> 
> Hi,
> Handlers are invoked by the aio_poll() event loop.  Some handlers are
> considered "external" in the sense that they submit new I/O requests
> from the guest or outside world.  Others are considered "internal" in
> the sense that they are part of the block layer and not an entry point
> into the block layer.
> 
> There are points where the block layer wants to run the event loop but
> new requests must not be submitted.  In this case aio_disable_external()
> will be called so that "external" handlers are not processed.
> 
> For example, see virtio's virtio_queue_aio_set_host_notifier_handler().
> This is the virtqueue kick ioeventfd and it shouldn't be processed when
> aio_disable_external() has been called.
> 

Thanks for the explanation Stefan. Xen event channels/shared rings should 
indeed be considered as external sources.

  Cheers,

Paul

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

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

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  be3d5b30331d87e177744dbe23138b9ebcdc86f1
baseline version:
 xen  cb70a26f78848fe45f593f7ebc9cfaac760a791b

Last test of basis   133991  2019-03-22 15:00:46 Z   24 days
Failing since134068  2019-03-25 12:00:51 Z   21 days  110 attempts
Testing same since   134834  2019-04-15 19:00:48 Z0 days4 attempts


People who touched revisions under test:
  Alexandru Isaila 
  Alexandru Stefan ISAILA 
  Amit Singh Tomar 
  Andrew Cooper 
  Anthony PERARD 
  Brian Woods 
  Christian Lindig 
  Doug Goldstein 
  George Dunlap 
  Igor Druzhinin 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Lukas Juenger 
  M A Young 
  Norbert Manthey 
  Oleksandr Andrushchenko 
  Paul Durrant 
  Pawel Wieczorkiewicz 
  Petre Pircalabu 
  Razvan Cojocaru 
  Tamas K Lengyel 
  Wei Liu 
  Xiaochen Wang 
  Xin Li 

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

(No revision log; it would be 2099 lines long.)

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

Re: [Xen-devel] [PATCH V3 5/5] xen/arm: Add early printk support for SCIFA compatible UARTs

[Julien Grall]

Hi Oleksandr,

On 4/15/19 12:43 PM, Oleksandr wrote:


On 14.04.19 20:56, Julien Grall wrote:

On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

This patch makes possible to use existing early prink code
for Renesas "Stout" board based on R-Car H2 SoC (SCIFA).

The "EARLY_PRINTK_VERSION" for that board should be 'A':
CONFIG_EARLY_PRINTK=scif,0xe6c4,A

Signed-off-by: Oleksandr Tyshchenko 
CC: Julien Grall 

---
 Changes in v3:
 - It was decided not to introduce new debug-scifa.inc
   for handling SCIFA interface, but to extend existing
   debug-scif.inc for handling both interfaces.
   This patch is a result of splitting an initial patch
   "xen/arm: Add SCIFA UART support for early printk"
   and only adds a support.
---
  xen/arch/arm/arm32/debug-scif.inc | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/arm32/debug-scif.inc 
b/xen/arch/arm/arm32/debug-scif.inc

index a8d2eae..94a18ea 100644
--- a/xen/arch/arm/arm32/debug-scif.inc
+++ b/xen/arch/arm/arm32/debug-scif.inc
@@ -1,7 +1,7 @@
  /*
   * xen/arch/arm/arm32/debug-scif.inc
   *
- * SCIF specific debug code
+ * SCIF(A) specific debug code
   *
   * Oleksandr Tyshchenko 
   * Copyright (C) 2014, Globallogic.
@@ -22,10 +22,13 @@
  #ifdef EARLY_PRINTK_VERSION_NONE
  #define STATUS_REG    SCIF_SCFSR
  #define TX_FIFO_REG   SCIF_SCFTDR
+#elif EARLY_PRINTK_VERSION_A
+#define STATUS_REG    SCIFA_SCASSR
+#define TX_FIFO_REG   SCIFA_SCAFTDR
  #endif
    /*
- * SCIF UART wait UART to be ready to transmit
+ * SCIF(A) UART wait UART to be ready to transmit


When SCIFB will be introduced, we will have to modify this comment 
again. As we are only dealing with any version of SCIC in this file, 
could we just rework the comment to avoid mentioning the UART name?


I think, yes. What about using SCIF(X)? Shall I update 
scif-uart.c/scif-uart.h which has SCIF(A) string?


In comments, I would just drop completely "SCIF(A)".

For copyright header, we can either keep SCIF(A) or use SCIF(X). Which 
ever you prefer.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-4.9-testing test] 134721: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm  broken  in 134611
 build-arm64-pvopsbroken  in 134611
 build-arm64  broken  in 134611
 build-arm644 host-install(4) broken in 134611 REGR. vs. 132889
 build-arm64-pvops  4 host-install(4) broken in 134611 REGR. vs. 132889
 build-arm64-xsm4 host-install(4) broken in 134611 REGR. vs. 132889
 build-i386-prev   6 xen-buildfail REGR. vs. 132889
 build-amd64-prev  6 xen-buildfail REGR. vs. 132889
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 132889

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 15 guest-saverestore.2 fail in 
134611 pass in 134721
 test-armhf-armhf-libvirt-raw 15 guest-start/debian.repeat fail in 134611 pass 
in 134721
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10  fail pass in 134611
 test-amd64-i386-libvirt-pair 26 leak-check/check/src_host  fail pass in 134611
 test-amd64-i386-libvirt-pair 27 leak-check/check/dst_host  fail pass in 134611
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
134611
 test-armhf-armhf-xl  19 leak-check/check   fail pass in 134611
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 21 leak-check/check fail pass in 
134611
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
134611
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
134611

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked in 134611 n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked in 134611 n/a
 build-arm64-libvirt   1 build-check(1)   blocked in 134611 n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked in 134611 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked in 134611 n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked in 134611 n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 132889
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop   fail blocked in 132889
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 134611 blocked in 
132889
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 134611 like 132889
 test-amd64-amd64-xl-rtds 10 debian-install  fail in 134611 like 132889
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail in 134611 like 132889
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   fail in 134611 like 132889
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 134611 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 134611 never 
pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 132889
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132889
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-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-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-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
 

Re: [Xen-devel] booting domU guest as pvh works in xen-4.11.1 but fails in 4.12

[Roger Pau Monné]

On Mon, Apr 15, 2019 at 04:18:57PM -0700, Pry Mar wrote:
> Hello,
> 
> https://paste.debian.net/1077718/
> 
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).
> 
> The dom0 here is ub1804, kernel-4.18, and xen-4.12 with debian
> packages (self built).
> ~$ sudo dpkg -l | grep -P 'xen|qemu' | grep '^ii'
> ii  libxen-4.12:amd64  4.12.0-1+ub18u04.1amd64
>Public libs for Xen
> ii  libxenstore3.0:amd64  4.12.0-1+ub18u04.1amd64
>   Xenstore communications library for Xen
> ii  libxentoolcore1:amd64  4.12.0-1+ub18u04.1amd64
>helper for qemu & libxenstore
> ii  qemuu 3.1.0-1+ub18u04.1 amd64
> qemu-system-i386 (3.1.0/xen-4.12) with 9pfs support
> ii  xen-hypervisor-4.12-amd64 4.12.0-1+ub18u04.1
>  amd64Xen Hypervisor on AMD64
> ii  xen-utils-4.124.12.0-1+ub18u04.1
>  amd64XEN administrative tools
> ii  xen-utils-common  4.12.0-1+ub18u04.1
>  all  Xen administrative tools - common files
> ii  xen-virbr00.1-2
>  all  Setup a virbr0 bridge and dnsmasq on a
> ii  xenstore-utils4.12.0-1+ub18u04.1
>  amd64Xenstore command line utilities for Xen
> 
> The same xl config and grub config works in xen-4.11.1. I've searched
> for any new options in xl.cfg that could influence this, but nothing
> catches my eye.

Do same kernel and initrd work fine when booted as PV or HVM?

Thanks, Roger.

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

Re: [Xen-devel] [PATCH V3 2/5] xen/arm: drivers: scif: Extend driver to handle other interfaces

[Julien Grall]

Hi Oleksandr,

On 4/15/19 12:30 PM, Oleksandr wrote:


On 14.04.19 19:55, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 4/8/19 11:14 AM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

Extend driver to be able to handle other SCIF(X) compatible
interfaces as well. These interfaces have lot in common,
but mostly differ in offsets and bits for some registers.


Can you briefly explain in the commit message what differs?


Sure




[...]

@@ -65,13 +100,16 @@ static void scif_uart_interrupt(int irq, void 
*data, struct cpu_user_regs *regs)

  serial_rx_interrupt(port, regs);
    /* Error Interrupt */
-    if ( status & SCIF_ERRORS )
-    scif_writew(uart, SCIF_SCFSR, ~SCIF_ERRORS);
-    if ( scif_readw(uart, SCIF_SCLSR) & SCLSR_ORER )
-    scif_writew(uart, SCIF_SCLSR, 0);
+    if ( status & params->error_mask )
+    scif_writew(uart, params->status_reg, ~params->error_mask);
+    if ( params->overrun_reg != params->status_reg )


Below you will write the same register twice if overrun_reg == 
status_reg (see scif_uart_init_preirq). Would there be any issue if 
you do the same here?


I didn't expect any issue to write the same register twice during 
initialization to simplify the code, that why I agreed to remove the 
check in V1.


But I am not sure about doing so here. We could simplify the code by 
just removing "if ( params->overrun_reg != params->status_reg )",


but we would need to do extra operation for SCIFA which has overrun_reg 
== status_reg.


What way do you prefer?


It is not about preference, it is about correctness. In my previous 
reply, I pointed out that you define overrun_mask for SCIFA but it will 
never be used. Without any explanation, the code looks pretty wrong.


Looking at the next patch, you get away from any problem with SCIFA 
because the overrun_mask is a subset of error_mask. But I still don't 
see why trying to prevent to write a second time is an issue, the more 
the Linux driver does not seem to do this dance.


So at best, you need to explain in the commit message why you try to 
skip the register when it is the same.


Cheers,

--
Julien Grall

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

Re: [edk2-devel] [PATCH v2 31/31] OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg

[Laszlo Ersek]

On 04/09/19 13:08, Anthony PERARD wrote:
> A Xen PVH guest doesn't have a RTC that OVMF would expect, so
> PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware
> from finish to boot. To prevent that, we will use the
> XenRealTimeClockLib from ArmVirtPkg which simply always return the same
> time. This will work on both Xen PVH and HVM guests.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD 
> ---
>  OvmfPkg/XenOvmf.dsc | 5 -
>  OvmfPkg/XenOvmf.fdf | 2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index 72d6ea8b29..14ef9ea9f2 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -577,7 +577,10 @@ [Components]
>}
>MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>MdeModulePkg/Universal/Metronome/Metronome.inf
> -  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
> +
> +  
> RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> +  }
>MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
>MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
>  
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index 9aa998f15f..1b62da2ec5 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -293,7 +293,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
>  INF  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
> -INF  
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
> +INF  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>  
>  INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> 

(1) I suggest following "ArmVirtXen.dsc", that is, please resolve the
RealTimeClockLib class to XenRealTimeClockLib.inf globally, under
[LibraryClasses].

With that,

Acked-by: Laszlo Ersek 

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39160): https://edk2.groups.io/g/devel/message/39160
Mute This Topic: https://groups.io/mt/30998054/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 30/31] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg

[Laszlo Ersek]

On 04/09/19 13:08, Anthony PERARD wrote:
> So it can be used from the OvmfPkg by the following patch,
> "OvmfPkg/XenOvmf: use RealTimeClockRuntimeDxe from EmbeddedPkg"

(1) Please make the commit message self-contained.

with that,

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD 
> ---
>  ArmVirtPkg/ArmVirtXen.dsc   
> | 2 +-
>  {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf 
> | 0
>  {ArmVirtPkg => OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c   
> | 0
>  3 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index a3688ae2cb..d5d8d79561 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -33,7 +33,7 @@ [Defines]
>  
>  [LibraryClasses]
>
> SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
> -  
> RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> +  
> RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
>XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>  
>
> ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf 
> b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
> diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c 
> b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> similarity index 100%
> rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#39159): https://edk2.groups.io/g/devel/message/39159
Mute This Topic: https://groups.io/mt/30998048/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 29/31] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

[Laszlo Ersek]

On 04/09/19 13:08, Anthony PERARD wrote:
> This "device" use XenIoMmioLib to reserve some space to be use by the
> Grant Tables.

(1) can we replace "this device" with "XenIoPvhDxe"?

> 
> The call is only done if it is necessary, we simply detect if the guest
> is probably PVH, as in this case there is currently no PCI bus, and no

(2) why "probably"? I've been under the impression that XenPvhDetected()
is decisive.

> PCI Xen platform device which would start the XenIoPciDxe and allocate
> the space for the Grant Tables.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Anthony PERARD 
> ---
> 
> Notes:
> v2:
> - do allocation in EntryPoint like the other user of XenIoMmioLib.
> - allocate memory instead of hardcoded addr.
> - cleanup, add copyright
> - detect if we are running in PVH mode
> 
>  OvmfPkg/XenOvmf.dsc  |  2 ++
>  OvmfPkg/XenOvmf.fdf  |  1 +
>  OvmfPkg/{XenIoPciDxe/XenIoPciDxe.inf => XenIoPvhDxe/XenIoPvhDxe.inf} | 26 
> +-
>  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c| 38 
> 
>  4 files changed, 49 insertions(+), 18 deletions(-)
> 
> diff --git a/OvmfPkg/XenOvmf.dsc b/OvmfPkg/XenOvmf.dsc
> index a26f611058..72d6ea8b29 100644
> --- a/OvmfPkg/XenOvmf.dsc
> +++ b/OvmfPkg/XenOvmf.dsc
> @@ -199,6 +199,7 @@ [LibraryClasses]
>
> OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
>XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
>XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
> +  XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
>  
>
> Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
>  
> @@ -596,6 +597,7 @@ [Components]
>
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
> +  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> diff --git a/OvmfPkg/XenOvmf.fdf b/OvmfPkg/XenOvmf.fdf
> index e078c7b405..9aa998f15f 100644
> --- a/OvmfPkg/XenOvmf.fdf
> +++ b/OvmfPkg/XenOvmf.fdf
> @@ -295,6 +295,7 @@ [FV.DXEFV]
>  INF  MdeModulePkg/Universal/Metronome/Metronome.inf
>  INF  
> PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
>  
> +INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf

So you keep both drivers in OvmfXen. Is there any chance that both
drivers will launch successfully and the protocol database ends up with
two instances of gXenIoProtocolGuid?

... If the PCI device PCI_VENDOR_ID_XEN/PCI_DEVICE_ID_XEN_PLATFORM is
exclusive to HVM, then I guess the mutual exclusion is guaranteed.

> diff --git a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf 
> b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> similarity index 56%
> copy from OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> copy to OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf

(this is a false positive of "--find-copies-harder", OK)

> index b32075a381..985b6d54b7 100644
> --- a/OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
> +++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
> @@ -1,7 +1,7 @@
>  ## @file
> -#  Driver for the virtual Xen PCI device
> +#  Driver for the XenIo protocol
>  #
> -#  Copyright (C) 2015, Linaro Ltd.
> +#  Copyright (c) 2019, Citrix Systems, Inc.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD 
> License
> @@ -15,31 +15,21 @@
>  
>  [Defines]
>INF_VERSION   = 0x00010005
> -  BASE_NAME = XenIoPciDxe
> -  FILE_GUID = cf569f50-de44-4f54-b4d7-f4ae25cda599
> +  BASE_NAME = XenIoPvhDxe
> +  FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
>MODULE_TYPE   = UEFI_DRIVER

(3) Please "downgrade" this to DXE_DRIVER. This driver doesn't follow
the UEFI driver model (which is fine), and there is no reason to suggest
it is more than a DXE (i.e., platform) driver.

For that, you'll have to introduce a [Depex] section, but I think it can
be just TRUE -- I don't think you need any particular protocols
(architectural or not).

>VERSION_STRING= 1.0
> -  ENTRY_POINT   = XenIoPciDeviceEntryPoint
> +  ENTRY_POINT   = InitializeXenIoPvhDxe
>  
>  [Packages]
>MdePkg/MdePkg.dec
>OvmfPkg/OvmfPkg.dec
>  
>  [Sources]
> -  XenIoPciDxe.c
> +  XenIoPvhDxe.c
>  
>  [LibraryClasses]
>UefiDriverEntryPoint
> -  UefiBootServicesTableLib
>MemoryAllocationLib
> -  BaseMemoryLib
> -  BaseLib
> -  UefiLib
> -  DebugLib
> -
> -[Protocols]
> -  gEfiDriverBindingProtocolGuid
> -  gEfiPciIoProtocolGuid
> -  

[Xen-devel] [PATCH v5] x86/altp2m: Aggregate get entry and populate into common funcs

[Alexandru Stefan ISAILA]

The code for getting the entry and then populating was repeated in
p2m_change_altp2m_gfn() and in p2m_set_altp2m_mem_access().

The code is now in one place with a bool param that lets the caller choose
if it populates after get_entry().

If remapping is being done then both the old and new gfn's should be
unshared in the hostp2m for keeping things consistent. The page type
of old_gfn was already checked whether it's p2m_ram_rw and bail if it
wasn't so functionality-wise this just simplifies things as a user
doesn't have to request unsharing manually before remapping.
Now, if the new_gfn is invalid it shouldn't query the hostp2m as
that is effectively a request to remove the entry from the altp2m.
But provided that scenario is used only when removing entries that
were previously remapped/copied to the altp2m, those entries already
went through P2M_ALLOC | P2M_UNSHARE before, so it won't have an
affect so the core function get_altp2m_entry() is calling
__get_gfn_type_access() with P2M_ALLOC | P2M_UNSHARE.

altp2m_get_entry_direct() is also called in p2m_set_suppress_ve()
because on a new altp2m view the function will fail with invalid mfn if
p2m->set_entry() was not called before.

Signed-off-by: Alexandru Isaila 
Signed-off-by: George Dunlap 
Reviewed-by: George Dunlap 

---
Changes since V4:
- Add altp2m to patch name
- Change func name from get_altp2m_entry() to
altp2m_get_entry().
---
 xen/arch/x86/mm/mem_access.c | 30 ++---
 xen/arch/x86/mm/p2m.c| 84 
 xen/include/asm-x86/p2m.h| 17 
 3 files changed, 66 insertions(+), 65 deletions(-)

diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
index a144bb0ce4..ddfe0169c0 100644
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -262,35 +262,11 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct 
p2m_domain *hp2m,
 mfn_t mfn;
 p2m_type_t t;
 p2m_access_t old_a;
-unsigned int page_order;
-unsigned long gfn_l = gfn_x(gfn);
 int rc;
 
-mfn = ap2m->get_entry(ap2m, gfn, , _a, 0, NULL, NULL);
-
-/* Check host p2m if no valid entry in alternate */
-if ( !mfn_valid(mfn) )
-{
-
-mfn = __get_gfn_type_access(hp2m, gfn_l, , _a,
-P2M_ALLOC | P2M_UNSHARE, _order, 0);
-
-rc = -ESRCH;
-if ( !mfn_valid(mfn) || t != p2m_ram_rw )
-return rc;
-
-/* If this is a superpage, copy that first */
-if ( page_order != PAGE_ORDER_4K )
-{
-unsigned long mask = ~((1UL << page_order) - 1);
-gfn_t gfn2 = _gfn(gfn_l & mask);
-mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
-
-rc = ap2m->set_entry(ap2m, gfn2, mfn2, page_order, t, old_a, 1);
-if ( rc )
-return rc;
-}
-}
+rc = altp2m_get_entry_prepopulate(ap2m, gfn, , , _a);
+if ( rc )
+return rc;
 
 /*
  * Inherit the old suppress #VE bit value if it is already set, or set it
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 9e81a30cc4..7bedfd593b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -478,6 +478,43 @@ void p2m_unlock_and_tlb_flush(struct p2m_domain *p2m)
 mm_write_unlock(>lock);
 }
 
+int altp2m_get_entry(struct p2m_domain *ap2m,
+gfn_t gfn, mfn_t *mfn, p2m_type_t *t,
+p2m_access_t *a, bool prepopulate)
+{
+*mfn = ap2m->get_entry(ap2m, gfn, t, a, 0, NULL, NULL);
+
+/* Check host p2m if no valid entry in alternate */
+if ( !mfn_valid(*mfn) && !p2m_is_hostp2m(ap2m) )
+{
+struct p2m_domain *hp2m = p2m_get_hostp2m(ap2m->domain);
+unsigned int page_order;
+int rc;
+
+*mfn = __get_gfn_type_access(hp2m, gfn_x(gfn), t, a,
+ P2M_ALLOC | P2M_UNSHARE, _order, 0);
+
+rc = -ESRCH;
+if ( !mfn_valid(*mfn) || *t != p2m_ram_rw )
+return rc;
+
+/* If this is a superpage, copy that first */
+if ( prepopulate && page_order != PAGE_ORDER_4K )
+{
+unsigned long mask = ~((1UL << page_order) - 1);
+gfn_t gfn_aligned = _gfn(gfn_x(gfn) & mask);
+mfn_t mfn_aligned = _mfn(mfn_x(*mfn) & mask);
+
+rc = ap2m->set_entry(ap2m, gfn_aligned, mfn_aligned, page_order, 
*t, *a, 1);
+if ( rc )
+return rc;
+}
+}
+
+return 0;
+}
+
+
 mfn_t __get_gfn_type_access(struct p2m_domain *p2m, unsigned long gfn_l,
 p2m_type_t *t, p2m_access_t *a, p2m_query_t q,
 unsigned int *page_order, bool_t locked)
@@ -2618,7 +2655,6 @@ int p2m_change_altp2m_gfn(struct domain *d, unsigned int 
idx,
 p2m_access_t a;
 p2m_type_t t;
 mfn_t mfn;
-unsigned int page_order;
 int rc = -EINVAL;
 
 if ( idx >= MAX_ALTP2M || d->arch.altp2m_eptp[idx] == 

[Xen-devel] [distros-debian-snapshot test] 83988: trouble: blocked/broken

[Platform Team regression test user]

flight 83988 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/83988/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-i386   broken
 build-amd64-pvopsbroken
 build-armhf  broken
 build-amd64  broken
 build-i386-pvops broken
 build-armhf-pvops 3 syslog-serverrunning
 build-armhf   3 syslog-serverrunning

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-i386-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 test-armhf-armhf-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-current-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-weekly-netinst-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-i386-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-current-netinst-pygrub  1 build-check(1)blocked n/a
 test-amd64-i386-amd64-current-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-daily-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-i386-daily-netboot-pvgrub  1 build-check(1)blocked n/a
 test-amd64-i386-i386-weekly-netinst-pygrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-weekly-netinst-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-daily-netboot-pygrub  1 build-check(1)   blocked n/a
 build-armhf-pvops 4 host-install(4)  broken like 83913
 build-armhf   4 host-install(4)  broken like 83913
 build-i3864 host-install(4)  broken like 83913
 build-amd64   4 host-install(4)  broken like 83913
 build-i386-pvops  4 host-install(4)  broken like 83913
 build-amd64-pvops 4 host-install(4)  broken like 83913
 build-armhf-pvops 5 capture-logs broken like 83913
 build-armhf   5 capture-logs broken like 83913

baseline version:
 flight   83913

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-daily-netboot-pvgrub  blocked 
 test-amd64-i386-i386-daily-netboot-pvgrubblocked 
 test-amd64-i386-amd64-daily-netboot-pygrub   blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  blocked 
 test-amd64-amd64-i386-daily-netboot-pygrub   blocked 
 test-amd64-amd64-amd64-current-netinst-pygrubblocked 
 test-amd64-i386-amd64-current-netinst-pygrub blocked 
 test-amd64-amd64-i386-current-netinst-pygrub blocked 
 test-amd64-i386-i386-current-netinst-pygrub  blocked 
 test-amd64-amd64-amd64-weekly-netinst-pygrub blocked 
 test-amd64-i386-amd64-weekly-netinst-pygrub  blocked 
 test-amd64-amd64-i386-weekly-netinst-pygrub  blocked 
 test-amd64-i386-i386-weekly-netinst-pygrub   blocked 



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.xensource.com/osstest/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

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

[osstest service owner]

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

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. 134640
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 134640

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 0eccea3fbe2f6d4999d972d9310d4f2717f5100c
baseline version:
 ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33

Last test of basis   134640  2019-04-11 13:15:51 Z4 days
Failing since134738  2019-04-13 03:33:26 Z3 days6 attempts
Testing same since   134852  2019-04-16 06:41:35 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Bret Barkelew 
  Chasel Chiu 
  Chasel, Chiu 
  Christian Rodriguez 
  Dandan Bi 
  Dong, Guo 
  Fan, ZhijuX 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Rodriguez, Christian 
  Shenglei Zhang 
  Zhichao Gao 
  Zhiju.Fan 

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



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

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

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

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


Not pushing.

(No revision log; it would be 417 lines long.)

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

Re: [Xen-devel] booting domU guest as pvh works in xen-4.11.1 but fails in 4.12

[M A Young]

On Mon, 15 Apr 2019, Pry Mar wrote:

> Hello,
> 
> https://paste.debian.net/1077718/
> 
> I get a kernel panic as shown in the paste above no matter how I
> launch pvh, with bootloader (pygrub), kernel direct (4.18+), or
> pvgrub2 (i386-xen_pvh support).
> 
> The dom0 here is ub1804, kernel-4.18, and xen-4.12 with debian
> packages (self built).
> ~$ sudo dpkg -l | grep -P 'xen|qemu' | grep '^ii'
> ii  libxen-4.12:amd64  4.12.0-1+ub18u04.1amd64
>Public libs for Xen
> ii  libxenstore3.0:amd64  4.12.0-1+ub18u04.1amd64
>   Xenstore communications library for Xen
> ii  libxentoolcore1:amd64  4.12.0-1+ub18u04.1amd64
>helper for qemu & libxenstore
> ii  qemuu 3.1.0-1+ub18u04.1 amd64
> qemu-system-i386 (3.1.0/xen-4.12) with 9pfs support
> ii  xen-hypervisor-4.12-amd64 4.12.0-1+ub18u04.1
>  amd64Xen Hypervisor on AMD64
> ii  xen-utils-4.124.12.0-1+ub18u04.1
>  amd64XEN administrative tools
> ii  xen-utils-common  4.12.0-1+ub18u04.1
>  all  Xen administrative tools - common files
> ii  xen-virbr00.1-2
>  all  Setup a virbr0 bridge and dnsmasq on a
> ii  xenstore-utils4.12.0-1+ub18u04.1
>  amd64Xenstore command line utilities for Xen
> 
> The same xl config and grub config works in xen-4.11.1. I've searched
> for any new options in xl.cfg that could influence this, but nothing
> catches my eye.
> 
> I get the same dmesg in other boot methods, but the i386-xen_pvh style
> yields more info at the end. The (fire-missle) grub script is provided
> Hans van Kranenburg .
> 
> Before the initrd unpacks I see many errors (line 201 of paste):
> fuse init modprobe trap invalid opcode ip:7f797dc7bb95
> 
> But later the xen_netfront and xen_blkfront drivers load fine and then
> trouble starts.
> 
> PryMar56,
> ##xen-packaging on Freenode IRC

I have seen a similar crash on Fedora on a F30 guest that works with PV 
but crashes with HVM on 4.12 but not on 4.11.1. I am seeing similar 
behaviour on a Windows 10 HVM guest, though that is harder to diagnose.

Michael Young

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

Re: [Xen-devel] [PATCH v4] x86/mm: Aggregate get entry and populate into common funcs

[Alexandru Stefan ISAILA]

On 15.04.2019 18:37, Jan Beulich wrote:
 Alexandru Stefan ISAILA  04/15/19 11:23 AM >>>
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -514,6 +514,23 @@ static inline unsigned long mfn_to_gfn(struct domain 
>> *d, mfn_t mfn)
>   >return mfn_x(mfn);
>> }
>   >
>> +int get_altp2m_entry(struct p2m_domain *ap2m, gfn_t gfn, mfn_t *mfn,
>> + p2m_type_t *t, p2m_access_t *a, bool prepopulate);
>> +
>> +static inline int altp2m_get_entry_direct(struct p2m_domain *ap2m,
>> +  gfn_t gfn, mfn_t *mfn,
>> +  p2m_type_t *t, p2m_access_t 
>> *a)
>> +{
>> +return get_altp2m_entry(ap2m, gfn, mfn, t, a, false);
>> +}
>> +
>> +static inline int altp2m_get_entry_prepopulate(struct p2m_domain *ap2m,
>> +   gfn_t gfn, mfn_t *mfn,
>> +   p2m_type_t *t, p2m_access_t 
>> *a)
>> +{
>> +return get_altp2m_entry(ap2m, gfn, mfn, t, a, true);
>> +}
> 
> The worker function name would imo better be altp2m_get_entry(), then in line
> with its two wrappers.
> 

Ok it will be changed in the next version.

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

[Xen-devel] [PATCH] gitlab-ci: allow specifying base and tip in build test

[Wei Liu]

We will soon provide this new capability to humans and automated
systems.

The default behaviour is retained: tip and base are passed by Gitlab
CI.

Signed-off-by: Wei Liu 
---
 automation/gitlab-ci/build-each-commit.sh | 10 +-
 automation/gitlab-ci/test.yaml|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/automation/gitlab-ci/build-each-commit.sh 
b/automation/gitlab-ci/build-each-commit.sh
index 879028b5a7..19e337b468 100755
--- a/automation/gitlab-ci/build-each-commit.sh
+++ b/automation/gitlab-ci/build-each-commit.sh
@@ -1,18 +1,18 @@
 #!/bin/bash
 
 # For a newly pushed branch the BEFORE_SHA will be all 0s
-if [[ ${CI_COMMIT_BEFORE_SHA} ==  ]]; 
then
+if [[ ${BASE} ==  ]]; then
 echo "Newly pushed branch, skipped"
 exit 0
 fi
 
-git merge-base --is-ancestor ${CI_COMMIT_BEFORE_SHA} ${CI_COMMIT_SHA}
+git merge-base --is-ancestor ${BASE} ${TIP}
 if [[ $? -ne 0 ]]; then
-echo "${CI_COMMIT_SHA} is not a descendent of ${CI_COMMIT_BEFORE_SHA}, 
skipped"
+echo "${TIP} is not a descendent of ${BASE}, skipped"
 exit 0
 fi
 
-echo "Building ${CI_COMMIT_BEFORE_SHA}..${CI_COMMIT_SHA}"
+echo "Building ${BASE}..${TIP}"
 
-NON_SYMBOLIC_REF=1 ./automation/scripts/build-test.sh ${CI_COMMIT_BEFORE_SHA} 
${CI_COMMIT_SHA} \
+NON_SYMBOLIC_REF=1 ./automation/scripts/build-test.sh ${BASE} ${TIP} \
 bash -c "git clean -ffdx && ./automation/scripts/build"
diff --git a/automation/gitlab-ci/test.yaml b/automation/gitlab-ci/test.yaml
index d4556afe11..a795866673 100644
--- a/automation/gitlab-ci/test.yaml
+++ b/automation/gitlab-ci/test.yaml
@@ -7,7 +7,7 @@ build-each-commit-gcc:
 XEN_TARGET_ARCH: x86_64
 CC: gcc
   script:
-- ./automation/gitlab-ci/build-each-commit.sh 2>&1 | tee 
build-each-commit-gcc.log
+- BASE=${BASE_SHA:-${CI_COMMIT_BEFORE_SHA}} 
TIP=${TIP_SHA:-${CI_COMMIT_SHA}} ./automation/gitlab-ci/build-each-commit.sh 
2>&1 | tee build-each-commit-gcc.log
   artifacts:
 paths:
   - '*.log'
-- 
2.20.1


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

Re: [Xen-devel] [PATCH net-next] xen-netfront: mark expected switch fall-through

[Juergen Gross]

On 15/04/2019 23:11, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
> 
> This patch fixes the following warning:
> 
> drivers/net/xen-netfront.c: In function ‘netback_changed’:
> drivers/net/xen-netfront.c:2038:6: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>if (dev->state == XenbusStateClosed)
>   ^
> drivers/net/xen-netfront.c:2041:2: note: here
>   case XenbusStateClosing:
>   ^~~~
> 
> Warning level 3 was used: -Wimplicit-fallthrough=3
> 
> Notice that, in this particular case, the code comment is modified
> in accordance with what GCC is expecting to find.
> 
> This patch is part of the ongoing efforts to enable
> -Wimplicit-fallthrough.
> 
> Signed-off-by: Gustavo A. R. Silva 

Reviewed-by: Juergen Gross 


Juergen

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

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

[osstest service owner]

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

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf eb33b3994d06de418222e664cb1c17369436e93c
baseline version:
 ovmf e0fd9ece26c9b84a1a756a869ff2a4525e23ab33

Last test of basis   134640  2019-04-11 13:15:51 Z4 days
Failing since134738  2019-04-13 03:33:26 Z3 days5 attempts
Testing same since   134839  2019-04-15 23:11:36 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Dong, Guo 
  Guo Dong 
  Kinney, Michael D 
  Laszlo Ersek 
  Michael D Kinney 
  Shenglei Zhang 

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 fail
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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 eb33b3994d06de418222e664cb1c17369436e93c
Author: Kinney, Michael D 
Date:   Tue Apr 2 13:09:09 2019 -0700

EmulatorPkg/Unix: Rename GdbRun to GdbRun.sh

https://bugzilla.tianocore.org/show_bug.cgi?id=1657

Add .sh file extension to the shell script GdbRun so
changes to this file will pass PatchCheck.py.

Also update all scripts that execute GdbRun to
execute GdbRun.sh instead.

Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney 
Reviewed-by: Jordan Justen 

commit 04af8bf262f1917b74745f8ffd3aa8fb465352df
Author: Dong, Guo 
Date:   Thu Apr 11 08:51:22 2019 -0700

UefiPayloadPkg: Enhance UEFI payload for coreboot and Slim Bootloader

CorebootModulePkg and CorebootPayloadPkg originally supports coreboot only.
In order to support other bootloaders, such as Slim Bootloader, they need
be updated to be more generic.
UEFI Payload (UefiPayloadPkg) a converged package from CorebootModulePkg
and CorebootPayloadPkg with following updates:
a. Support both coreboot and Slim Bootloader
b. Removed SataControllerDxe and BaseSerialPortLib16550 to use EDK2 modules
c. Support passing bootloader parameter to UEFI payload, e.g. coreboot
   table from coreboot or HOB list from Slim Bootloader
d. Using GraphicsOutputDxe from EDK2 with minor change instead of FbGop
e. Remove the dependency to IntelFrameworkPkg and IntelFrameworkModulePkg
   and QuarkSocPkg
f. Use BaseDebugLibSerialPort library as DebugLib
g. Use HPET timer, drop legacy 8254 timer support
h. Use BaseXApicX2ApicLib instead of BaseXApicLib
i. Remove HOB gUefiFrameBufferInfoGuid to use EDK2 graphics HOBs.
j. Other clean ups

On how UefiPayloadPkg could work with coreboot/Slim Bootloader, please
refer UefiPayloadPkg/BuildAndIntegrationInstructions.txt

Once UefiPayloadPkg is checked-in, CorebootModulePkg and CorebootPayloadPkg
could be retired.

Signed-off-by: Guo Dong 
Reviewed-by: Maurice Ma 

commit 87fcc6e8634efadb535ea0d7e9869e72e772fccf
Author: Dandan Bi 
Date:   Tue Apr 2 13:50:22 2019 +0800

CorebootPayloadPkg: Remove the dependency of ShellBinPkg

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1675

In long term we will remove ShellBinPkg, so now we update
platform to use ShellPkg only.

Cc: Maurice Ma 
Cc: Prince Agyeman 
Cc: Benjamin You 
Contributed-under: TianoCore Contribution Agreement 1.1

[Xen-devel] xen COMPAT definition

[Diego Alejandro Parra Guzman]

Hi guys.

Currently Im working with xen source code, tring to include new
functionality; in specifict, Im working with xenoprof. But, I've found
some compilation problems  due to the flag #define COMPAT.

here my questions:

What  the COMPAT definition does?
Pros and Cons of COMPAT enable/disable?
How to ENABLE/DISABLE that flag?
how COMPAT affects xenoprof?
how COMPAT affects arm64 cross compilation?

Thank you.

cheers
Diego




-- 
Diego Alejandro Parra Guzmán
Estudiante de ingeniería electrónica
Universidad distrital FJC

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