date:20191021

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit2  broken
 test-arm64-arm64-xl-credit2   4 host-install(4)broken REGR. vs. 142933
 test-arm64-arm64-examine  5 host-install   broken REGR. vs. 142933
 test-amd64-amd64-libvirt 12 guest-start  fail REGR. vs. 142933
 test-amd64-amd64-xl-pvhv2-amd 16 guest-localmigrate  fail REGR. vs. 142933
 test-amd64-amd64-xl-credit1  15 guest-saverestorefail REGR. vs. 142933
 test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR. 
vs. 142933
 test-amd64-amd64-xl-pvhv2-intel 18 guest-localmigrate/x10 fail REGR. vs. 142933
 test-amd64-amd64-pair 24 guest-migrate/dst_host/src_host/debian.repeat fail 
REGR. vs. 142933
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 142933
 test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10   fail REGR. vs. 142933
 test-amd64-amd64-xl-shadow  20 guest-start/debian.repeat fail REGR. vs. 142933
 test-amd64-amd64-xl  21 guest-start.2fail REGR. vs. 142933
 test-amd64-amd64-xl-credit2 20 guest-start/debian.repeat fail REGR. vs. 142933
 test-amd64-amd64-xl-multivcpu 20 guest-start/debian.repeat fail REGR. vs. 
142933
 test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 142933

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 142933
 test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 142933

Tests which did not succeed, but are not blocking:
 test-amd64-i386-examine   8 reboot   fail  like 142933
 test-amd64-i386-xl-xsm7 xen-boot fail  like 142933
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail like 
142933
 test-amd64-i386-libvirt   7 xen-boot fail  like 142933
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot  fail like 142933
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot   fail like 142933
 test-amd64-i386-xl-shadow 7 xen-boot fail  like 142933
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail like 
142933
 test-amd64-i386-xl-raw7 xen-boot fail  like 142933
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot  fail like 142933
 test-amd64-i386-freebsd10-i386  7 xen-bootfail like 142933
 test-amd64-i386-xl7 xen-boot fail  like 142933
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot   fail like 142933
 test-amd64-i386-pair 10 xen-boot/src_hostfail  like 142933
 test-amd64-i386-pair 11 xen-boot/dst_hostfail  like 142933
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail  like 142933
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail  like 142933
 test-amd64-i386-libvirt-xsm   7 xen-boot fail  like 142933
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot   fail like 142933
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-bootfail like 142933
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  7 xen-boot   fail like 142933
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot   fail like 142933
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-bootfail like 142933
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot  fail like 142933
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot  fail like 142933
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot   fail like 142933
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot   fail like 142933
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot   fail like 142933
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm  7 xen-boot fail like 142933
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot   fail like 142933
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot   fail like 142933
 test-amd64-i386-xl-pvshim 7 xen-boot fail  like 142933
 test-amd64-i386-freebsd10-amd64  7 xen-boot   fail like 142933
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142933
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142933
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142933
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142933
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142933
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142933
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvopsbroken
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 142750
 test-amd64-amd64-xl-pvshim  20 guest-start/debian.repeat fail REGR. vs. 142750

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-pvshim 16 guest-localmigrate fail in 142907 pass in 142997
 test-arm64-arm64-examine 11 examine-serial/bootloader fail in 142973 pass in 
142907
 test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail in 142973 pass in 
142997
 test-armhf-armhf-xl-credit1   7 xen-boot   fail pass in 142973

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-thunderx  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-seattle 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl-seattle 14 saverestore-support-check fail in 142973 never 
pass
 test-arm64-arm64-xl-credit1 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl-credit1 14 saverestore-support-check fail in 142973 never 
pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail in 142973 never 
pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-check fail in 142973 never 
pass
 test-arm64-arm64-xl 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl 14 saverestore-support-check fail in 142973 never pass
 test-arm64-arm64-xl-credit2 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl-credit2 14 saverestore-support-check fail in 142973 never 
pass
 test-arm64-arm64-xl-xsm 13 migrate-support-check fail in 142973 never pass
 test-arm64-arm64-xl-xsm 14 saverestore-support-check fail in 142973 never pass
 test-armhf-armhf-xl-credit1 13 migrate-support-check fail in 142973 never pass
 test-armhf-armhf-xl-credit1 14 saverestore-support-check fail in 142973 never 
pass
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail  like 142750
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142750
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 142750
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 142750
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 142750
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 142750
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 142750
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142750
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-freebsd10-amd64

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid xen-boot

Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  7d194c2100ad2a6dded545887d02754948ca5241
  Bug not present: 249155c20f9b0754bc1b932a33344cfb4e0c2101
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/143016/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-freebsd10-amd64.xen-boot
 --summary-out=tmp/143016.bisection-summary --basis-template=133580 
--blessings=real,real-bisect linux-linus test-amd64-i386-freebsd10-amd64 
xen-boot
Searching for failure / basis pass:
 142984 fail [host=italia1] / 138849 [host=debina0] 138813 [host=baroque0] 
138780 [host=chardonnay1] 138754 [host=elbling1] 138735 [host=pinot1] 138710 
[host=elbling0] 138680 [host=debina1] 138661 [host=chardonnay0] 138639 
[host=fiano1] 138612 [host=fiano0] 138584 [host=baroque1] 138488 ok.
Failure / basis pass flights: 142984 / 138488
(tree with no url: minios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 7d194c2100ad2a6dded545887d02754948ca5241 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
0f28c513d392a807f7b4225964eba6e2b1c453a2 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
fc92d092ea4f704bc4d283c3911ee9894733f4ce 
518c935fac4d30b3ec35d4b6add82b17b7d7aca3
Basis pass 249155c20f9b0754bc1b932a33344cfb4e0c2101 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
719a684d7df1b5b5627f42447be4f12aab038343 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
6e56ed129c9782ba050a5fbfbf4ac12335b230f7 
f3d8eef9091747e70c505094f63514b43329a922
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#249155c20f9b0754bc1b932a33344cfb4e0c2101-7d194c2100ad2a6dded545887d02754948ca5241
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/osstest/ovmf.git#719a684d7df1b5b5627f42447be4f12aab038343-0f28c513d392a807f7b4225964eba6e2b1c453a2
 git://xenbits.xen.org/qemu-xen-traditional.\
 
git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#9cca02d8ffc23e9688a971d858e4ffdff5389b11-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#6e56ed129c9782ba050a5fbfbf4ac12335b230f7-fc92d092ea4f704bc4d283c3911ee9894733f4ce
 
git://xenbits.xen.org/xen.git#f3d8eef9091747e70c505094f63514b43329a922-518c935fac4d30b3ec35d4b6add82b17b7d7aca3
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 3003 nodes in revision graph
Searching for test results:
 138245 [host=elbling1]
 138386 [host=debina0]
 138488 pass 249155c20f9b0754bc1b932a33344cfb4e0c2101 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
719a684d7df1b5b5627f42447be4f12aab038343 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
9cca02d8ffc23e9688a971d858e4ffdff5389b11 
6e56ed129c9782ba050a5fbfbf4ac12335b230f7 
f3d8eef9091747e70c505094f63514b43329a922
 138584 [host=baroque1]
 138612 [host=fiano0]
 138639 [host=fiano1]
 138661 [host=chardonnay0]
 138680 [host=debina1]
 138710 [host=elbling0]
 138735 [host=pinot1]
 138754 [host=elbling1]
 138780 [host=chardonnay1]
 138813 [host=baroque0]
 138849 [host=debina0]
 138878 fail irrelevant
 138902 fail irrelevant
 138962 fail irrelevant
 139003 fail irrelevant
 139068 fail irrelevant
 139134 fail irrelevant
 139237 fail irrelevant
 139223 fail irrelevant
 139257 fail irrelevant
 139324 fail irrelevant
 139306 fail irrelevant
 139286 fail irrelevant
 139338 fail irrelevant
 139361 fail irrelevant
 139383 fail irrelevant
 139408 fail irrelevant
 139478 fail irrelevant
 139532 fail

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 61bb6eeb4d93c0a34c1995d87914ab41398f9550
baseline version:
 ovmf 2bbbdeeea21113185912a6a3ec8cdcaf862d8568

Last test of basis   142986  2019-10-21 01:09:56 Z0 days
Testing same since   142998  2019-10-21 08:41:48 Z0 days1 attempts


People who touched revisions under test:
  Maciej Rabeda 
  Marvin Haeuser 
  Rabeda, Maciej 

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
   2bbbdeeea2..61bb6eeb4d  61bb6eeb4d93c0a34c1995d87914ab41398f9550 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH RFC for-4.13 07/10] xen/arm: Allow insn.h to be called from assembly

2019-10-21 Thread Stefano Stabellini

On Mon, 21 Oct 2019, Julien Grall wrote:
> Hi Stefano,
> 
> On 10/1/19 10:00 PM, Stefano Stabellini wrote:
> > On Thu, 26 Sep 2019, Julien Grall wrote:
> > > A follow-up patch will require to include insn.h from assembly code. So
> > > wee need to protect any C-specific definition to avoid compilation
> >^ we   ^ definitions
> > 
> > > error when used in assembly code.
> >^ errors
> > 
> > 
> > > 
> > > Signed-off-by: Julien Grall 
> > > ---
> > >   xen/include/asm-arm/insn.h | 8 
> > >   1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/xen/include/asm-arm/insn.h b/xen/include/asm-arm/insn.h
> > > index 19277212e1..00391f83f9 100644
> > > --- a/xen/include/asm-arm/insn.h
> > > +++ b/xen/include/asm-arm/insn.h
> > > @@ -1,8 +1,14 @@
> > >   #ifndef __ARCH_ARM_INSN
> > >   #define __ARCH_ARM_INSN
> > >   +#ifndef __ASSEMBLY__
> > > +
> > >   #include 
> > >   +/*
> > > + * At the moment, arch-specific headers contain only definition for C
> > > + * code.
> > > + */
> > 
> > Please remove "At the moment, " because in-code comment should always
> > reflect the latest state of the codebase.
> 
> Well, we do have a lot of "Currently"/"At the moment"/"For now" in the code.
> Some of my patches went in recently with such wording, so why this particular
> one is a problem?

Yeah, I realize that a lot of our conventions are still tribal knowledge
(i.e. not written down anywhere.)

Let me explain my take on this. When one writes "At the
moment"/"Currently"/"For now" he/she implies that the code is just
temporary, or at least sub-optimal and something should be down about
it to improve. Maybe not immediately, but it would be nice to have.

I think it is OK to write something like "At the moment," to express
that meaning. That's OK.

In this specific case, the reason why I wrote that reply is that when I
read the in-code comment, it jarred for it ("jarred" as in something was
off, out of place.) And I think the reason is that the code looked OK,
and I didn't get what you think we should "improve" in the code after
this patch is applied.

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

Re: [Xen-devel] [PATCH RFC for-4.13 07/10] xen/arm: Allow insn.h to be called from assembly

2019-10-21 Thread Julien Grall


Hi Stefano,

On 10/1/19 10:00 PM, Stefano Stabellini wrote:

On Thu, 26 Sep 2019, Julien Grall wrote:

A follow-up patch will require to include insn.h from assembly code. So
wee need to protect any C-specific definition to avoid compilation

   ^ we   ^ definitions


error when used in assembly code.

   ^ errors




Signed-off-by: Julien Grall 
---
  xen/include/asm-arm/insn.h | 8 
  1 file changed, 8 insertions(+)

diff --git a/xen/include/asm-arm/insn.h b/xen/include/asm-arm/insn.h
index 19277212e1..00391f83f9 100644
--- a/xen/include/asm-arm/insn.h
+++ b/xen/include/asm-arm/insn.h
@@ -1,8 +1,14 @@
  #ifndef __ARCH_ARM_INSN
  #define __ARCH_ARM_INSN
  
+#ifndef __ASSEMBLY__

+
  #include 
  
+/*

+ * At the moment, arch-specific headers contain only definition for C
+ * code.
+ */


Please remove "At the moment, " because in-code comment should always
reflect the latest state of the codebase.


Well, we do have a lot of "Currently"/"At the moment"/"For now" in the 
code. Some of my patches went in recently with such wording, so why this 
particular one is a problem?


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH for-next v3 0/9] Port Xen to Hyper-V

Hi all

This is version 3 of the patch series.

This is the very first stage for porting Xen to run on Hyper-V with all the
goodies Hyper-V has to offer.  With this series, Xen can successfully detect
Hyper-V and prints out a message.  I would like to first get the code structure
and kconfig options agreed upon.

There are two major areas to be worked on:
  * Make Dom0 able to use Hyper-V's synthetic devices.
  * Make Xen use of the synthetic timer, reference TSC and enlightenment VMCS
and other interfaces.

They aren't trivial, and time can be scarce on my side, so I intend to post
patches piecemeal when they are ready.

Questions and comments are welcome.

Thanks,
Wei.

---
Changes in v3: See invididual patches

Changes in v2:
1. Introduce and use a hypervisor framework
2. Keep memmap infra under Xen for now

Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Roger Pau Monné 

Wei Liu (9):
  x86: introduce CONFIG_GUEST and move code
  x86: include asm_defns.h directly in hypercall.h
  x86: drop hypervisor_cpuid_base
  x86: include xen/lib.h in guest/hypercall.h
  x86: introduce hypervisor framework
  x86: rename hypervisor_{alloc,free}_unused_page
  x86: switch xen implementation to use hypervisor framework
  x86: be more verbose when running on a hypervisor
  x86: introduce CONFIG_HYPERV and detection code

 xen/arch/x86/Kconfig  | 13 +++
 xen/arch/x86/Makefile |  2 +-
 xen/arch/x86/guest/Makefile   |  6 +-
 xen/arch/x86/guest/hyperv/Makefile|  1 +
 xen/arch/x86/guest/hyperv/hyperv.c| 54 +++
 xen/arch/x86/guest/hypervisor.c   | 89 +++
 xen/arch/x86/guest/xen/Makefile   |  4 +
 xen/arch/x86/guest/{ => xen}/hypercall_page.S |  0
 xen/arch/x86/guest/{ => xen}/pvh-boot.c   |  2 +-
 xen/arch/x86/guest/{ => xen}/xen.c| 39 
 xen/arch/x86/pv/shim.c|  6 +-
 xen/arch/x86/setup.c  |  6 +-
 xen/include/asm-x86/guest.h   |  2 +
 xen/include/asm-x86/guest/hypercall.h |  4 +
 xen/include/asm-x86/guest/hyperv.h| 45 ++
 xen/include/asm-x86/guest/hypervisor.h| 64 +
 xen/include/asm-x86/guest/xen.h   | 24 ++---
 17 files changed, 314 insertions(+), 47 deletions(-)
 create mode 100644 xen/arch/x86/guest/hyperv/Makefile
 create mode 100644 xen/arch/x86/guest/hyperv/hyperv.c
 create mode 100644 xen/arch/x86/guest/hypervisor.c
 create mode 100644 xen/arch/x86/guest/xen/Makefile
 rename xen/arch/x86/guest/{ => xen}/hypercall_page.S (100%)
 rename xen/arch/x86/guest/{ => xen}/pvh-boot.c (99%)
 rename xen/arch/x86/guest/{ => xen}/xen.c (93%)
 create mode 100644 xen/include/asm-x86/guest/hyperv.h
 create mode 100644 xen/include/asm-x86/guest/hypervisor.h

-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 9/9] x86: introduce CONFIG_HYPERV and detection code

We use the same code structure as we did for Xen.

As starters, detect Hyper-V in probe routine. More complex
functionalities will be added later.

Signed-off-by: Wei Liu 
---
V3:
1. Remove some unused code
2. Rename structure
3. Also detect HV#1 signature
---
 xen/arch/x86/Kconfig   |  9 +
 xen/arch/x86/guest/Makefile|  1 +
 xen/arch/x86/guest/hyperv/Makefile |  1 +
 xen/arch/x86/guest/hyperv/hyperv.c | 54 ++
 xen/arch/x86/guest/hypervisor.c|  8 +
 xen/include/asm-x86/guest.h|  1 +
 xen/include/asm-x86/guest/hyperv.h | 45 +
 7 files changed, 119 insertions(+)
 create mode 100644 xen/arch/x86/guest/hyperv/Makefile
 create mode 100644 xen/arch/x86/guest/hyperv/hyperv.c
 create mode 100644 xen/include/asm-x86/guest/hyperv.h

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 867de857e8..56513c771c 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -164,6 +164,15 @@ endchoice
 config GUEST
bool
 
+config HYPERV_GUEST
+   def_bool n
+   select GUEST
+   prompt "Hyper-V Guest"
+   ---help---
+ Support for Xen detecting when it is running under Hyper-V.
+
+ If unsure, say N.
+
 config XEN_GUEST
def_bool n
select GUEST
diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
index f63d64bbee..f164196772 100644
--- a/xen/arch/x86/guest/Makefile
+++ b/xen/arch/x86/guest/Makefile
@@ -1,3 +1,4 @@
 obj-y += hypervisor.o
 
+subdir-$(CONFIG_HYPERV_GUEST) += hyperv
 subdir-$(CONFIG_XEN_GUEST) += xen
diff --git a/xen/arch/x86/guest/hyperv/Makefile 
b/xen/arch/x86/guest/hyperv/Makefile
new file mode 100644
index 00..68170109a9
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -0,0 +1 @@
+obj-y += hyperv.o
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
new file mode 100644
index 00..7ab4b127f3
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -0,0 +1,54 @@
+/**
+ * arch/x86/guest/hyperv/hyperv.c
+ *
+ * Support for detecting and running under Hyper-V.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2019 Microsoft.
+ */
+#include 
+
+#include 
+
+bool __init hyperv_probe(void)
+{
+uint32_t eax, ebx, ecx, edx;
+
+cpuid(0x4000, , , , );
+if ( !((ebx == 0x7263694d) &&  /* "Micr" */
+   (ecx == 0x666f736f) &&  /* "osof" */
+   (edx == 0x76482074)) )  /* "t Hv" */
+return false;
+
+cpuid(0x4001, , , , );
+if ( eax != 0x31237648 )/* Hv#1 */
+return false;
+
+return true;
+}
+
+struct hypervisor_ops hyperv_ops = {
+.name = "Hyper-V",
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index a666ad9526..17392d1ffa 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -43,6 +43,14 @@ bool hypervisor_probe(void)
 }
 #endif
 
+#ifdef CONFIG_HYPERV_GUEST
+if ( hyperv_probe() )
+{
+hops = _ops;
+return true;
+}
+#endif
+
 return false;
 }
 
diff --git a/xen/include/asm-x86/guest.h b/xen/include/asm-x86/guest.h
index 8e167165ae..94448606d4 100644
--- a/xen/include/asm-x86/guest.h
+++ b/xen/include/asm-x86/guest.h
@@ -20,6 +20,7 @@
 #define __X86_GUEST_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-x86/guest/hyperv.h 
b/xen/include/asm-x86/guest/hyperv.h
new file mode 100644
index 00..4b9cc5a836
--- /dev/null
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -0,0 +1,45 @@
+/**
+ * asm-x86/guest/hyperv.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *

[Xen-devel] [PATCH for-next v3 7/9] x86: switch xen implementation to use hypervisor framework

Take the chance to change probe_hypervisor to hypervisor_probe.

Signed-off-by: Wei Liu 
---
V3:
1. Address Roger's comments
2. Change xen_hypervisor_ops to xen_ops
---
 xen/arch/x86/guest/hypervisor.c   | 32 ++-
 xen/arch/x86/guest/xen/pvh-boot.c |  2 +-
 xen/arch/x86/guest/xen/xen.c  | 26 +
 xen/arch/x86/setup.c  |  2 +-
 xen/include/asm-x86/guest/xen.h   |  6 --
 5 files changed, 51 insertions(+), 17 deletions(-)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 89b9ae4de0..33bf1a769d 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -22,7 +22,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 static struct hypervisor_ops *hops __read_mostly;
 
@@ -31,9 +31,39 @@ bool hypervisor_probe(void)
 if ( hops )
 return true;
 
+/* Too early to use cpu_has_hypervisor */
+if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
+return false;
+
+#ifdef CONFIG_XEN_GUEST
+if ( xen_probe() )
+{
+hops = _ops;
+return true;
+}
+#endif
+
 return false;
 }
 
+void hypervisor_setup(void)
+{
+if ( hops && hops->setup )
+hops->setup();
+}
+
+void hypervisor_ap_setup(void)
+{
+if ( hops && hops->ap_setup )
+hops->ap_setup();
+}
+
+void hypervisor_resume(void)
+{
+if ( hops && hops->resume )
+hops->resume();
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/guest/xen/pvh-boot.c 
b/xen/arch/x86/guest/xen/pvh-boot.c
index ca8e156f7d..498625eae0 100644
--- a/xen/arch/x86/guest/xen/pvh-boot.c
+++ b/xen/arch/x86/guest/xen/pvh-boot.c
@@ -103,7 +103,7 @@ void __init pvh_init(multiboot_info_t **mbi, module_t **mod)
 {
 convert_pvh_info(mbi, mod);
 
-probe_hypervisor();
+hypervisor_probe();
 ASSERT(xen_guest);
 
 get_memory_map();
diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 9895025d02..655435c1f7 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -67,24 +67,19 @@ static void __init find_xen_leaves(void)
 }
 }
 
-void __init probe_hypervisor(void)
+bool __init xen_probe(void)
 {
-if ( xen_guest )
-return;
-
-/* Too early to use cpu_has_hypervisor */
-if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
-return;
-
 find_xen_leaves();
 
 if ( !xen_cpuid_base )
-return;
+return false;
 
 /* Fill the hypercall page. */
 wrmsrl(cpuid_ebx(xen_cpuid_base + 2), __pa(hypercall_page));
 
 xen_guest = true;
+
+return true;
 }
 
 static void map_shared_info(void)
@@ -249,7 +244,7 @@ static void init_evtchn(void)
 }
 }
 
-void __init hypervisor_setup(void)
+static void __init xen_setup(void)
 {
 init_memmap();
 
@@ -277,7 +272,7 @@ void __init hypervisor_setup(void)
 init_evtchn();
 }
 
-void hypervisor_ap_setup(void)
+static void xen_ap_setup(void)
 {
 set_vcpu_id();
 map_vcpuinfo();
@@ -307,7 +302,7 @@ static void ap_resume(void *unused)
 init_evtchn();
 }
 
-void hypervisor_resume(void)
+static void xen_resume(void)
 {
 /* Reset shared info page. */
 map_shared_info();
@@ -330,6 +325,13 @@ void hypervisor_resume(void)
 pv_console_init();
 }
 
+struct hypervisor_ops xen_ops = {
+.name = "Xen",
+.setup = xen_setup,
+.ap_setup = xen_ap_setup,
+.resume = xen_resume,
+};
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index dec60d0301..0ee11b15a6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -763,7 +763,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * allocing any xenheap structures wanted in lower memory. */
 kexec_early_calculations();
 
-probe_hypervisor();
+hypervisor_probe();
 
 parse_video_info();
 
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
index 8221fc1325..c3c6bea24f 100644
--- a/xen/include/asm-x86/guest/xen.h
+++ b/xen/include/asm-x86/guest/xen.h
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 
 #define XEN_shared_info ((struct shared_info 
*)fix_to_virt(FIX_XEN_SHARED_INFO))
 
@@ -31,8 +32,9 @@
 extern bool xen_guest;
 extern bool pv_console;
 extern uint32_t xen_cpuid_base;
+extern struct hypervisor_ops xen_ops;
 
-void probe_hypervisor(void);
+bool xen_probe(void);
 int xen_alloc_unused_page(mfn_t *mfn);
 int xen_free_unused_page(mfn_t mfn);
 
@@ -44,7 +46,7 @@ DECLARE_PER_CPU(struct vcpu_info *, vcpu_info);
 #define xen_guest 0
 #define pv_console 0
 
-static inline void probe_hypervisor(void) {}
+static inline bool xen_probe(void) { return false; }
 
 #endif /* CONFIG_XEN_GUEST */
 #endif /* __X86_GUEST_XEN_H__ */
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 1/9] x86: introduce CONFIG_GUEST and move code

Xen is able to run as a guest on Xen. We plan to make it able to run
on Hyper-V as well.

Introduce CONFIG_GUEST which is set to true if either running on Xen
or Hyper-V is desired. Restructure code hierarchy for new code to
come.

No functional change intended.

Signed-off-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
 xen/arch/x86/Kconfig  | 4 
 xen/arch/x86/Makefile | 2 +-
 xen/arch/x86/guest/Makefile   | 5 +
 xen/arch/x86/guest/xen/Makefile   | 4 
 xen/arch/x86/guest/{ => xen}/hypercall_page.S | 0
 xen/arch/x86/guest/{ => xen}/pvh-boot.c   | 0
 xen/arch/x86/guest/{ => xen}/xen.c| 0
 7 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 xen/arch/x86/guest/xen/Makefile
 rename xen/arch/x86/guest/{ => xen}/hypercall_page.S (100%)
 rename xen/arch/x86/guest/{ => xen}/pvh-boot.c (100%)
 rename xen/arch/x86/guest/{ => xen}/xen.c (100%)

diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 28b3b4692a..867de857e8 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -161,8 +161,12 @@ config XEN_ALIGN_2M
 
 endchoice
 
+config GUEST
+   bool
+
 config XEN_GUEST
def_bool n
+   select GUEST
prompt "Xen Guest"
---help---
  Support for Xen detecting when it is running under Xen.
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 2443fd2cc5..99a12d0090 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -1,7 +1,7 @@
 subdir-y += acpi
 subdir-y += cpu
 subdir-y += genapic
-subdir-$(CONFIG_XEN_GUEST) += guest
+subdir-$(CONFIG_GUEST) += guest
 subdir-$(CONFIG_HVM) += hvm
 subdir-y += mm
 subdir-$(CONFIG_XENOPROF) += oprofile
diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
index 26fb4b1007..6806f04947 100644
--- a/xen/arch/x86/guest/Makefile
+++ b/xen/arch/x86/guest/Makefile
@@ -1,4 +1 @@
-obj-y += hypercall_page.o
-obj-y += xen.o
-
-obj-bin-$(CONFIG_PVH_GUEST) += pvh-boot.init.o
+subdir-$(CONFIG_XEN_GUEST) += xen
diff --git a/xen/arch/x86/guest/xen/Makefile b/xen/arch/x86/guest/xen/Makefile
new file mode 100644
index 00..26fb4b1007
--- /dev/null
+++ b/xen/arch/x86/guest/xen/Makefile
@@ -0,0 +1,4 @@
+obj-y += hypercall_page.o
+obj-y += xen.o
+
+obj-bin-$(CONFIG_PVH_GUEST) += pvh-boot.init.o
diff --git a/xen/arch/x86/guest/hypercall_page.S 
b/xen/arch/x86/guest/xen/hypercall_page.S
similarity index 100%
rename from xen/arch/x86/guest/hypercall_page.S
rename to xen/arch/x86/guest/xen/hypercall_page.S
diff --git a/xen/arch/x86/guest/pvh-boot.c b/xen/arch/x86/guest/xen/pvh-boot.c
similarity index 100%
rename from xen/arch/x86/guest/pvh-boot.c
rename to xen/arch/x86/guest/xen/pvh-boot.c
diff --git a/xen/arch/x86/guest/xen.c b/xen/arch/x86/guest/xen/xen.c
similarity index 100%
rename from xen/arch/x86/guest/xen.c
rename to xen/arch/x86/guest/xen/xen.c
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 5/9] x86: introduce hypervisor framework

We will soon implement Hyper-V support for Xen. Add a framework for
that.

This requires moving some of the hypervisor_* functions from xen.h to
hypervisor.h.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/guest/Makefile|  2 +
 xen/arch/x86/guest/hypervisor.c| 45 +++
 xen/include/asm-x86/guest.h|  1 +
 xen/include/asm-x86/guest/hypervisor.h | 61 ++
 xen/include/asm-x86/guest/xen.h| 12 -
 5 files changed, 109 insertions(+), 12 deletions(-)
 create mode 100644 xen/arch/x86/guest/hypervisor.c
 create mode 100644 xen/include/asm-x86/guest/hypervisor.h

diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
index 6806f04947..f63d64bbee 100644
--- a/xen/arch/x86/guest/Makefile
+++ b/xen/arch/x86/guest/Makefile
@@ -1 +1,3 @@
+obj-y += hypervisor.o
+
 subdir-$(CONFIG_XEN_GUEST) += xen
diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
new file mode 100644
index 00..89b9ae4de0
--- /dev/null
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -0,0 +1,45 @@
+/**
+ * arch/x86/guest/hypervisor.c
+ *
+ * Support for detecting and running under a hypervisor.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; If not, see .
+ *
+ * Copyright (c) 2019 Microsoft.
+ */
+
+#include 
+
+#include 
+#include 
+
+static struct hypervisor_ops *hops __read_mostly;
+
+bool hypervisor_probe(void)
+{
+if ( hops )
+return true;
+
+return false;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/guest.h b/xen/include/asm-x86/guest.h
index a38c6b5b3f..8e167165ae 100644
--- a/xen/include/asm-x86/guest.h
+++ b/xen/include/asm-x86/guest.h
@@ -20,6 +20,7 @@
 #define __X86_GUEST_H__
 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
new file mode 100644
index 00..38344e2e89
--- /dev/null
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -0,0 +1,61 @@
+/**
+ * asm-x86/guest/hypervisor.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ *
+ * Copyright (c) 2019 Microsoft.
+ */
+
+#ifndef __X86_HYPERVISOR_H__
+#define __X86_HYPERVISOR_H__
+
+#ifdef CONFIG_GUEST
+
+struct hypervisor_ops {
+/* Name of the hypervisor */
+const char *name;
+/* Main setup routine */
+void (*setup)(void);
+/* AP setup */
+void (*ap_setup)(void);
+/* Resume from suspension */
+void (*resume)(void);
+};
+
+bool hypervisor_probe(void);
+void hypervisor_setup(void);
+void hypervisor_ap_setup(void);
+void hypervisor_resume(void);
+
+#else
+
+#include 
+
+static inline bool hypervisor_probe(void) { return false; }
+static inline void hypervisor_setup(void) {}
+static inline void hypervisor_ap_setup(void) {}
+static inline void hypervisor_resume(void) {}
+
+#endif  /* CONFIG_GUEST */
+
+#endif /* __X86_HYPERVISOR_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
index b015ed1883..3145f75361 100644
--- a/xen/include/asm-x86/guest/xen.h
+++ b/xen/include/asm-x86/guest/xen.h
@@ -33,11 +33,8 @@ extern bool pv_console;
 extern uint32_t xen_cpuid_base;
 
 void probe_hypervisor(void);
-void hypervisor_setup(void);
-void hypervisor_ap_setup(void);
 int hypervisor_alloc_unused_page(mfn_t *mfn);
 int hypervisor_free_unused_page(mfn_t mfn);
-void hypervisor_resume(void);
 
 DECLARE_PER_CPU(unsigned int, vcpu_id);

[Xen-devel] [PATCH for-next v3 2/9] x86: include asm_defns.h directly in hypercall.h

ASM_CALL_CONSTRAINT is defined there.

No functional change.

Signed-off-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
 xen/include/asm-x86/guest/hypercall.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/include/asm-x86/guest/hypercall.h 
b/xen/include/asm-x86/guest/hypercall.h
index d548816b30..c9deca6ffc 100644
--- a/xen/include/asm-x86/guest/hypercall.h
+++ b/xen/include/asm-x86/guest/hypercall.h
@@ -23,6 +23,8 @@
 
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 6/9] x86: rename hypervisor_{alloc, free}_unused_page

They are used in Xen code only.

No functional change.

Signed-off-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
 xen/arch/x86/guest/xen/xen.c| 6 +++---
 xen/arch/x86/pv/shim.c  | 4 ++--
 xen/include/asm-x86/guest/xen.h | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 78fc603996..9895025d02 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -97,7 +97,7 @@ static void map_shared_info(void)
 unsigned int i;
 unsigned long rc;
 
-if ( hypervisor_alloc_unused_page() )
+if ( xen_alloc_unused_page() )
 panic("unable to reserve shared info memory page\n");
 
 xatp.gpfn = mfn_x(mfn);
@@ -284,7 +284,7 @@ void hypervisor_ap_setup(void)
 init_evtchn();
 }
 
-int hypervisor_alloc_unused_page(mfn_t *mfn)
+int xen_alloc_unused_page(mfn_t *mfn)
 {
 unsigned long m;
 int rc;
@@ -296,7 +296,7 @@ int hypervisor_alloc_unused_page(mfn_t *mfn)
 return rc;
 }
 
-int hypervisor_free_unused_page(mfn_t mfn)
+int xen_free_unused_page(mfn_t mfn)
 {
 return rangeset_remove_range(mem, mfn_x(mfn), mfn_x(mfn));
 }
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 5441e89de2..41b4665649 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -739,7 +739,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
 };
 mfn_t mfn;
 
-rc = hypervisor_alloc_unused_page();
+rc = xen_alloc_unused_page();
 if ( rc )
 {
 gprintk(XENLOG_ERR,
@@ -751,7 +751,7 @@ static long pv_shim_grant_table_op(unsigned int cmd,
 rc = xen_hypercall_memory_op(XENMEM_add_to_physmap, );
 if ( rc )
 {
-hypervisor_free_unused_page(mfn);
+xen_free_unused_page(mfn);
 break;
 }
 
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
index 3145f75361..8221fc1325 100644
--- a/xen/include/asm-x86/guest/xen.h
+++ b/xen/include/asm-x86/guest/xen.h
@@ -33,8 +33,8 @@ extern bool pv_console;
 extern uint32_t xen_cpuid_base;
 
 void probe_hypervisor(void);
-int hypervisor_alloc_unused_page(mfn_t *mfn);
-int hypervisor_free_unused_page(mfn_t mfn);
+int xen_alloc_unused_page(mfn_t *mfn);
+int xen_free_unused_page(mfn_t mfn);
 
 DECLARE_PER_CPU(unsigned int, vcpu_id);
 DECLARE_PER_CPU(struct vcpu_info *, vcpu_info);
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 3/9] x86: drop hypervisor_cpuid_base

The only user is Xen specific code in PV shim. We can therefore export
the variable directly.

Signed-off-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
 xen/arch/x86/guest/xen/xen.c| 7 +--
 xen/arch/x86/pv/shim.c  | 2 +-
 xen/include/asm-x86/guest/xen.h | 2 +-
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
index 7b7a5badab..78fc603996 100644
--- a/xen/arch/x86/guest/xen/xen.c
+++ b/xen/arch/x86/guest/xen/xen.c
@@ -37,7 +37,7 @@
 
 bool __read_mostly xen_guest;
 
-static __read_mostly uint32_t xen_cpuid_base;
+__read_mostly uint32_t xen_cpuid_base;
 extern char hypercall_page[];
 static struct rangeset *mem;
 
@@ -301,11 +301,6 @@ int hypervisor_free_unused_page(mfn_t mfn)
 return rangeset_remove_range(mem, mfn_x(mfn), mfn_x(mfn));
 }
 
-uint32_t hypervisor_cpuid_base(void)
-{
-return xen_cpuid_base;
-}
-
 static void ap_resume(void *unused)
 {
 map_vcpuinfo();
diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 5edbcd9ac5..5441e89de2 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -990,7 +990,7 @@ domid_t get_initial_domain_id(void)
 if ( !pv_shim )
 return 0;
 
-cpuid(hypervisor_cpuid_base() + 4, , , , );
+cpuid(xen_cpuid_base + 4, , , , );
 
 return (eax & XEN_HVM_CPUID_DOMID_PRESENT) ? ecx : 1;
 }
diff --git a/xen/include/asm-x86/guest/xen.h b/xen/include/asm-x86/guest/xen.h
index 7e04e4a7ab..b015ed1883 100644
--- a/xen/include/asm-x86/guest/xen.h
+++ b/xen/include/asm-x86/guest/xen.h
@@ -30,13 +30,13 @@
 
 extern bool xen_guest;
 extern bool pv_console;
+extern uint32_t xen_cpuid_base;
 
 void probe_hypervisor(void);
 void hypervisor_setup(void);
 void hypervisor_ap_setup(void);
 int hypervisor_alloc_unused_page(mfn_t *mfn);
 int hypervisor_free_unused_page(mfn_t mfn);
-uint32_t hypervisor_cpuid_base(void);
 void hypervisor_resume(void);
 
 DECLARE_PER_CPU(unsigned int, vcpu_id);
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 8/9] x86: be more verbose when running on a hypervisor

Signed-off-by: Wei Liu 
---
V3: Address Roger's comment, add ASSERTs
---
 xen/arch/x86/guest/hypervisor.c| 6 ++
 xen/arch/x86/setup.c   | 6 +-
 xen/include/asm-x86/guest/hypervisor.h | 3 +++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
index 33bf1a769d..a666ad9526 100644
--- a/xen/arch/x86/guest/hypervisor.c
+++ b/xen/arch/x86/guest/hypervisor.c
@@ -46,6 +46,12 @@ bool hypervisor_probe(void)
 return false;
 }
 
+const char *hypervisor_name(void)
+{
+ASSERT(hops);
+return hops->name;
+}
+
 void hypervisor_setup(void)
 {
 if ( hops && hops->setup )
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 0ee11b15a6..cf5a7b8e1e 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -689,6 +689,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 int i, j, e820_warn = 0, bytes = 0;
 bool acpi_boot_table_init_done = false, relocated = false;
 int ret;
+bool running_on_hypervisor;
 struct ns16550_defaults ns16550 = {
 .data_bits = 8,
 .parity= 'n',
@@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
  * allocing any xenheap structures wanted in lower memory. */
 kexec_early_calculations();
 
-hypervisor_probe();
+running_on_hypervisor = hypervisor_probe();
 
 parse_video_info();
 
@@ -789,6 +790,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 
 printk("Xen image load base address: %#lx\n", xen_phys_start);
 
+if ( running_on_hypervisor )
+printk("Running on %s\n", hypervisor_name());
+
 #ifdef CONFIG_VIDEO
 printk("Video information:\n");
 
diff --git a/xen/include/asm-x86/guest/hypervisor.h 
b/xen/include/asm-x86/guest/hypervisor.h
index 38344e2e89..b583722f5d 100644
--- a/xen/include/asm-x86/guest/hypervisor.h
+++ b/xen/include/asm-x86/guest/hypervisor.h
@@ -36,15 +36,18 @@ bool hypervisor_probe(void);
 void hypervisor_setup(void);
 void hypervisor_ap_setup(void);
 void hypervisor_resume(void);
+const char *hypervisor_name(void);
 
 #else
 
+#include 
 #include 
 
 static inline bool hypervisor_probe(void) { return false; }
 static inline void hypervisor_setup(void) {}
 static inline void hypervisor_ap_setup(void) {}
 static inline void hypervisor_resume(void) {}
+static inline char *hypervisor_name(void) { ASSERT_UNREACHABLE(); return NULL; 
}
 
 #endif  /* CONFIG_GUEST */
 
-- 
2.20.1


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

[Xen-devel] [PATCH for-next v3 4/9] x86: include xen/lib.h in guest/hypercall.h

We need ASSERT_UNREACHABLE.

Signed-off-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
 xen/include/asm-x86/guest/hypercall.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xen/include/asm-x86/guest/hypercall.h 
b/xen/include/asm-x86/guest/hypercall.h
index c9deca6ffc..d0d2f5022d 100644
--- a/xen/include/asm-x86/guest/hypercall.h
+++ b/xen/include/asm-x86/guest/hypercall.h
@@ -182,6 +182,8 @@ static inline long xen_hypercall_set_evtchn_upcall_vector(
 
 #else /* CONFIG_XEN_GUEST */
 
+#include 
+
 #include 
 
 static inline void xen_hypercall_console_write(
-- 
2.20.1


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

Re: [Xen-devel] [PATCH v2 06/20] piix4: Add a i8257 DMA Controller as specified in datasheet

2019-10-21 Thread Philippe Mathieu-Daudé


On 10/21/19 5:25 PM, Li Qiang wrote:



Philippe Mathieu-Daudé mailto:phi...@redhat.com>> 于 
2019年10月18日周五 下午9:55写道：


From: Hervé Poussineau mailto:hpous...@reactos.org>>

Remove i8257 instantiated in malta board, to not have it twice.

Acked-by: Michael S. Tsirkin mailto:m...@redhat.com>>
Acked-by: Paolo Bonzini mailto:pbonz...@redhat.com>>
Signed-off-by: Hervé Poussineau mailto:hpous...@reactos.org>>
Message-Id: <20171216090228.28505-9-hpous...@reactos.org
>
Reviewed-by: Aleksandar Markovic mailto:amarko...@wavecomp.com>>
[PMD: rebased]
Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  hw/isa/piix4.c       | 4 
  hw/mips/mips_malta.c | 2 --
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index ac9383a658..0b24d8323c 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -29,6 +29,7 @@
  #include "hw/pci/pci.h"
  #include "hw/isa/isa.h"
  #include "hw/sysbus.h"
+#include "hw/dma/i8257.h"
  #include "migration/vmstate.h"
  #include "sysemu/reset.h"
  #include "sysemu/runstate.h"
@@ -167,6 +168,9 @@ static void piix4_realize(PCIDevice *dev, Error
**errp)
      /* initialize ISA irqs */
      isa_bus_irqs(isa_bus, s->isa);

+    /* DMA */
+    i8257_dma_init(isa_bus, 0);
+
      piix4_dev = dev;
  }


Could you please explain why this is better calling 'i8257_dma_init' in 
piix4 realize function

instead of calling it in mips_malta_init.


i8257_dma_init() is a bit misnamed as it instantiate 2x i8257.

The PIIX4 integrates 2x i8237 (very similar to the i8257).

The i8237 are parts of the PIIX4 chip, and are not chips on the Malta 
board PCB.


So when you instantiate a PIIX4 in QEMU, one expects them integrated, 
and should not have to manually manage them outside of the southbridge 
chipset.


I'm still a little of which things should be done in realize and which 
should be done in qom instance init function.


I remember a thread started by Peter Maydell when he was working on the 
MPS2 boards, but I can't find it.


Anyway this thread is more recent:
"Object instantiation vs. device realization: what to do when?"
https://www.mail-archive.com/qemu-devel@nongnu.org/msg596361.html



Thanks,
Li Qiang

diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
index e499b7a6bb..df247177ca 100644
--- a/hw/mips/mips_malta.c
+++ b/hw/mips/mips_malta.c
@@ -28,7 +28,6 @@
  #include "cpu.h"
  #include "hw/i386/pc.h"
  #include "hw/isa/superio.h"
-#include "hw/dma/i8257.h"
  #include "hw/char/serial.h"
  #include "net/net.h"
  #include "hw/boards.h"
@@ -1430,7 +1429,6 @@ void mips_malta_init(MachineState *machine)
      smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
                            isa_get_irq(NULL, 9), NULL, 0, NULL);
      pit = i8254_pit_init(isa_bus, 0x40, 0, NULL);
-    i8257_dma_init(isa_bus, 0);
      mc146818_rtc_init(isa_bus, 2000, NULL);

      /* generate SPD EEPROM data */
-- 
2.21.0





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

[Xen-devel] [seabios test] 142994: tolerable FAIL - PUSHED

flight 142994 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142994/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 142871
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 142871
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 142871
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 142871
 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-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 seabios  120996f147131eca8af90e30c900bc14bc824d9f
baseline version:
 seabios  fc92d092ea4f704bc4d283c3911ee9894733f4ce

Last test of basis   142871  2019-10-18 10:38:44 Z3 days
Testing same since   142994  2019-10-21 07:08:49 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Uwe Kleine-König 

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-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictpass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  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/seabios.git
   fc92d09..120996f  120996f147131eca8af90e30c900bc14bc824d9f -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH v2 09/20] hw/mips/mips_malta: Create IDE hard drive array dynamically

Philippe Mathieu-Daudé  于2019年10月18日周五 下午9:53写道：

> In the next commit we'll refactor the PIIX4 code out of
> mips_malta_init(). As a preliminary step, add the 'ide_drives'
> variable and create the drive array dynamically.
>
> Reviewed-by: Aleksandar Markovic 
> Signed-off-by: Philippe Mathieu-Daudé 
>

Reviewed-by: Li Qiang 


> ---
>  hw/mips/mips_malta.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 528c34a1c3..774bb810f6 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1235,7 +1235,8 @@ void mips_malta_init(MachineState *machine)
>  int piix4_devfn;
>  I2CBus *smbus;
>  DriveInfo *dinfo;
> -DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> +const size_t ide_drives = MAX_IDE_BUS * MAX_IDE_DEVS;
> +DriveInfo **hd;
>  int fl_idx = 0;
>  int be;
>
> @@ -1406,7 +1407,8 @@ void mips_malta_init(MachineState *machine)
>  pci_bus = gt64120_register(s->i8259);
>
>  /* Southbridge */
> -ide_drive_get(hd, ARRAY_SIZE(hd));
> +hd = g_new(DriveInfo *, ide_drives);
> +ide_drive_get(hd, ide_drives);
>
>  pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
>true, TYPE_PIIX4_PCI_DEVICE);
> @@ -1421,6 +1423,7 @@ void mips_malta_init(MachineState *machine)
>  }
>
>  pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1);
> +g_free(hd);
>  pci_create_simple(pci_bus, piix4_devfn + 2, "piix4-usb-uhci");
>  smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
>isa_get_irq(NULL, 9), NULL, 0, NULL);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Oct 21, 2019 at 04:02:33PM +0100, Andrew Cooper wrote:
> On 21/10/2019 11:26, Roger Pau Monné wrote:
> >>> +
> >>> +cpuid(0x4000, , , , );
> >>> +if ( (ebx == 0x7263694d) && /* "Micr" */
> >>> + (ecx == 0x666f736f) && /* "osof" */
> >>> + (edx == 0x76482074) )  /* "t Hv" */
> >> I guess there are no HyperV headers to import that have those values
> >> defined?
> >>
> >> Alternatively you could do something like the following I think:
> >>
> >> static const char hyperv_sig[] __initconst = "Microsoft Hv";
> >>
> >> bool __init hyperv_probe(void)
> >> {
> >> uint32_t eax, sig[3];
> >>
> >> cpuid(0x4000, , [0], [1], [2]);
> >> if ( !strncmp(hyperv_sig, sig, strncmp(hyperv_sig) )
> > Urg, I've made a mistake here, the line should be:
> >
> > !strncmp(hyperv_sig, sig, strlen(hyperv_sig))
> 
> Just because the leaves form an ascii string, doesn't mean that using
> string comparisons are the sane way to check.  3x 32bit compares are
> substantially more efficient, and far harder to get wrong.
> 
> Wei: On your detection algorithm, you also need to find HV#1 in
> 0x4001.eax to detect conformance to the viridian spec.

Sure I can do that.

I'm not sure it matters that much in practice though.

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v2 06/20] piix4: Add a i8257 DMA Controller as specified in datasheet

Philippe Mathieu-Daudé  于2019年10月18日周五 下午9:55写道：

> From: Hervé Poussineau 
>
> Remove i8257 instantiated in malta board, to not have it twice.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-9-hpous...@reactos.org>
> Reviewed-by: Aleksandar Markovic 
> [PMD: rebased]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 4 
>  hw/mips/mips_malta.c | 2 --
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index ac9383a658..0b24d8323c 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -29,6 +29,7 @@
>  #include "hw/pci/pci.h"
>  #include "hw/isa/isa.h"
>  #include "hw/sysbus.h"
> +#include "hw/dma/i8257.h"
>  #include "migration/vmstate.h"
>  #include "sysemu/reset.h"
>  #include "sysemu/runstate.h"
> @@ -167,6 +168,9 @@ static void piix4_realize(PCIDevice *dev, Error **errp)
>  /* initialize ISA irqs */
>  isa_bus_irqs(isa_bus, s->isa);
>
> +/* DMA */
> +i8257_dma_init(isa_bus, 0);
> +
>  piix4_dev = dev;
>  }
>
>
Could you please explain why this is better calling 'i8257_dma_init' in
piix4 realize function
instead of calling it in mips_malta_init.

I'm still a little of which things should be done in realize and which
should be done in qom instance init function.

Thanks,
Li Qiang



> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index e499b7a6bb..df247177ca 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -28,7 +28,6 @@
>  #include "cpu.h"
>  #include "hw/i386/pc.h"
>  #include "hw/isa/superio.h"
> -#include "hw/dma/i8257.h"
>  #include "hw/char/serial.h"
>  #include "net/net.h"
>  #include "hw/boards.h"
> @@ -1430,7 +1429,6 @@ void mips_malta_init(MachineState *machine)
>  smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100,
>isa_get_irq(NULL, 9), NULL, 0, NULL);
>  pit = i8254_pit_init(isa_bus, 0x40, 0, NULL);
> -i8257_dma_init(isa_bus, 0);
>  mc146818_rtc_init(isa_bus, 2000, NULL);
>
>  /* generate SPD EEPROM data */
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v2 05/20] piix4: Rename PIIX4 object to piix4-isa

Philippe Mathieu-Daudé  于2019年10月18日周五 下午9:53写道：

> From: Hervé Poussineau 
>
> Other piix4 parts are already named piix4-ide and piix4-usb-uhci.
>
> Reviewed-by: Philippe Mathieu-Daudé 
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-15-hpous...@reactos.org>
> Reviewed-by: Aleksandar Markovic 
> [PMD: rebased]
> Signed-off-by: Philippe Mathieu-Daudé 
>


Reviewed-by: Li Qiang 


> ---
>  hw/isa/piix4.c   | 1 -
>  hw/mips/mips_malta.c | 2 +-
>  include/hw/isa/isa.h | 2 ++
>  3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index 9c37c85ae2..ac9383a658 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -45,7 +45,6 @@ typedef struct PIIX4State {
>  uint8_t rcr;
>  } PIIX4State;
>
> -#define TYPE_PIIX4_PCI_DEVICE "PIIX4"
>  #define PIIX4_PCI_DEVICE(obj) \
>  OBJECT_CHECK(PIIX4State, (obj), TYPE_PIIX4_PCI_DEVICE)
>
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 7d25ab6c23..e499b7a6bb 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -1414,7 +1414,7 @@ void mips_malta_init(MachineState *machine)
>  ide_drive_get(hd, ARRAY_SIZE(hd));
>
>  pci = pci_create_simple_multifunction(pci_bus, PCI_DEVFN(10, 0),
> -  true, "PIIX4");
> +  true, TYPE_PIIX4_PCI_DEVICE);
>  dev = DEVICE(pci);
>  isa_bus = ISA_BUS(qdev_get_child_bus(dev, "isa.0"));
>  piix4_devfn = pci->devfn;
> diff --git a/include/hw/isa/isa.h b/include/hw/isa/isa.h
> index 018ada4f6f..79f703fd6c 100644
> --- a/include/hw/isa/isa.h
> +++ b/include/hw/isa/isa.h
> @@ -147,4 +147,6 @@ static inline ISABus *isa_bus_from_device(ISADevice *d)
>  return ISA_BUS(qdev_get_parent_bus(DEVICE(d)));
>  }
>
> +#define TYPE_PIIX4_PCI_DEVICE "piix4-isa"
> +
>  #endif
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Oct 21, 2019 at 05:11:26PM +0200, Roger Pau Monné wrote:
> On Mon, Oct 21, 2019 at 03:56:51PM +0100, Wei Liu wrote:
> > On Mon, Oct 21, 2019 at 12:22:25PM +0200, Roger Pau Monné wrote:
> > [...]
> > > > +bool __init hyperv_probe(void)
> > > > +{
> > > > +uint32_t eax, ebx, ecx, edx;
> > > > +bool hyperv_guest = false;
> > > 
> > > I don't think you need this local variable, you can return true in if
> > > the if condition matches, and false otherwise.
> > > 
> > 
> > Sure. I can drop it for now and reintroduce it when necessary.
> > 
> > > > +
> > > > +cpuid(0x4000, , , , );
> > > > +if ( (ebx == 0x7263694d) && /* "Micr" */
> > > > + (ecx == 0x666f736f) && /* "osof" */
> > > > + (edx == 0x76482074) )  /* "t Hv" */
> > > 
> > > I guess there are no HyperV headers to import that have those values
> > > defined?
> > > 
> > 
> > Not yet. I have plan to import a header from Linux. When that's done
> > these will be replaced by some macros.
> > 
> > So I will keep this as-is for now.
> 
> Is it really cumbersome to introduce the header now?
> 
> IMO it would be better to avoid deferring this to when you introduce
> the header, since it's easy to miss it.

The header in Linux is not without its problems. It certainly doesn't
have the signature values in it yet, so whether importing it now or
later is immaterial to this issue at hand. I will have to go through
that header file first but -ETIME.

Wei.

> 
> Thanks, Roger.

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

Re: [Xen-devel] [PATCH v2 04/20] Revert "irq: introduce qemu_irq_proxy()"

Philippe Mathieu-Daudé  于2019年10月18日周五 下午9:50写道：

> From: Philippe Mathieu-Daudé 
>
> This function isn't used anymore.
>
> This reverts commit 22ec3283efba9ba0792790da786d6776d83f2a92.
>
> Reviewed-by: Thomas Huth 
> Signed-off-by: Philippe Mathieu-Daudé 
>

Reviewed-by: Li Qiang 


> ---
>  hw/core/irq.c| 14 --
>  include/hw/irq.h |  5 -
>  2 files changed, 19 deletions(-)
>
> diff --git a/hw/core/irq.c b/hw/core/irq.c
> index 7cc0295d0e..fb3045b912 100644
> --- a/hw/core/irq.c
> +++ b/hw/core/irq.c
> @@ -120,20 +120,6 @@ qemu_irq qemu_irq_split(qemu_irq irq1, qemu_irq irq2)
>  return qemu_allocate_irq(qemu_splitirq, s, 0);
>  }
>
> -static void proxy_irq_handler(void *opaque, int n, int level)
> -{
> -qemu_irq **target = opaque;
> -
> -if (*target) {
> -qemu_set_irq((*target)[n], level);
> -}
> -}
> -
> -qemu_irq *qemu_irq_proxy(qemu_irq **target, int n)
> -{
> -return qemu_allocate_irqs(proxy_irq_handler, target, n);
> -}
> -
>  void qemu_irq_intercept_in(qemu_irq *gpio_in, qemu_irq_handler handler,
> int n)
>  {
>  int i;
> diff --git a/include/hw/irq.h b/include/hw/irq.h
> index fe527f6f51..24ba0ece11 100644
> --- a/include/hw/irq.h
> +++ b/include/hw/irq.h
> @@ -51,11 +51,6 @@ qemu_irq qemu_irq_invert(qemu_irq irq);
>   */
>  qemu_irq qemu_irq_split(qemu_irq irq1, qemu_irq irq2);
>
> -/* Returns a new IRQ set which connects 1:1 to another IRQ set, which
> - * may be set later.
> - */
> -qemu_irq *qemu_irq_proxy(qemu_irq **target, int n);
> -
>  /* For internal use in qtest.  Similar to qemu_irq_split, but operating
> on an existing vector of qemu_irq.  */
>  void qemu_irq_intercept_in(qemu_irq *gpio_in, qemu_irq_handler handler,
> int n);
> --
> 2.21.0
>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [OSSTEST PATCH 2/3] guest_prepare_disk: Only do the umount if we set an env var

This call to guest_umount_lv is here for the benefit of ad-hoc reruns
of (eg) ts-guest-start tidy up any ad-hoc messing about (eg from
earlier runs of ts-debian-fixup or something).  It is not needed in
production runs.

Serendipitously, this osstest code discovered a bug in the Linux
blkback: when tearing down, it sets the backend state to 6 before it
has closed the underlying block devices.  This ultimately means that
after "xl destroy" or "xl shutdown -w" there is a period when the
guest's open handle onto its storage is still open.  This is wrong.

This detection depends on us winning a tricky race.  So it shows up in
osstest as a very low probability heisenbug.  The bug is currently in
all versions of Linux and causing a bit of a nuisance.

It would be best to add a proper check for this bug.  However, this is
quite fiddly: really, it ought to be done as close to the xl command
completion as possible, in the same ssh invocation.  That would
involve a fair bit of plumbing and ad-hocery.  I don't think that
would be proportionate for such a low-impact bug.

So instead in this patch I just disable this cleanup code in the
troublesome case, unless it is explicitly requested by the user
setting OSSTEST_GUEST_DISK_MOUNT_CLEANUP to a trueish value.  (This
would be reasonably convenient for the ad-hoc testing that this call
serves.)

Thanks to Roger for diagnosing the Linux kernel bug.

CC: Jürgen Groß 
Signed-off-by: Ian Jackson 
Reviewed-by: Roger Pau Monne 
---
 Osstest/TestSupport.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 78f47480..6b0ee7a2 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1938,7 +1938,8 @@ sub guest_create_paused ($) {
 sub guest_prepare_disk ($) {
 my ($gho) = @_;
 
-guest_umount_lv($gho->{Host}, $gho);
+guest_umount_lv($gho->{Host}, $gho)
+   if $ENV{'OSSTEST_GUEST_DISK_MOUNT_CLEANUP'};
 
 return if ($gho->{Diskfmt} // 'none') eq "none";
 
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 1/3] cs-adjust-flight: Provide runvar-set-default

No change to existing code.

Signed-off-by: Ian Jackson 
---
 cs-adjust-flight | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index ae342506..98d40891 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -11,6 +11,7 @@
 #   jobs-list 
 #   jobs-del 
 #   runvar-set   
+#   runvar-set-default   
 #   runvar-del  
 #   runvar-change
 #   runvar-perlop   
@@ -260,6 +261,10 @@ our $runvar_rm_q = db_prepare
 our $runvar_insert_q = db_prepare
 ("INSERT INTO runvars (flight, job, name, val, synth)".
  " VALUES (?, ?, ?, ?, 'f')");
+our $runvar_insert_default_q = db_prepare
+("INSERT INTO runvars (flight, job, name, val, synth)".
+ " VALUES (?, ?, ?, ?, 'f')".
+ " ON CONFLICT DO NOTHING");
 
 sub runvar_set ($$$;$) {
 my ($job, $name, $val, $xwhat) = @_;
@@ -270,6 +275,16 @@ sub runvar_set ($$$;$) {
 verbose "\n";
 }
 
+sub runvar_set_default ($$$;$) {
+my ($job, $name, $val, $xwhat) = @_;
+my $y = $runvar_insert_default_q->execute($dstflight, $job, $name, $val);
+if ($y) {
+   verbose "$dstflight.$job $name := \`$val'";
+   verbose $xwhat if defined $xwhat;
+   verbose "\n";
+}
+}
+
 sub for_runvars () {
 my ($jobspec, $varspec, $fn, $ifnone) = @_;
 # calls $fn->($jobname, $varname, $varrow)
@@ -306,6 +321,18 @@ sub change__runvar_set {
 }, 'ANYWAY');
 }
 
+sub change__runvar_set_default {
+die unless @changes >= 3;
+my $jobs = shift @changes;
+my $name = shift @changes;
+my $val = shift @changes;
+
+for_jobs($dstflight, $jobs, sub {
+my ($job) = @_;
+runvar_set_default($job, $name, $val);
+}, 'ANYWAY');
+}
+
 sub change__runvar_del {
 die unless @changes >= 2;
 my $jobs = shift @changes;
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH 3/3] Toolstack/xl: Wrap a long command

No functional change.

Signed-off-by: Ian Jackson 
---
 Osstest/Toolstack/xl.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Toolstack/xl.pm b/Osstest/Toolstack/xl.pm
index d31af8c0..85972753 100644
--- a/Osstest/Toolstack/xl.pm
+++ b/Osstest/Toolstack/xl.pm
@@ -78,7 +78,8 @@ sub shutdown_wait ($$$) {
 my $gn = $gho->{Name};
 my $acpi_fallback = guest_var($gho,'acpi_shutdown','false') eq 'true'
&& $self->{Name} eq 'xl' ? "F" : "";
-target_cmd_root($ho,"$self->{_Command} shutdown -w${acpi_fallback} $gn", 
$timeout);
+target_cmd_root($ho,"$self->{_Command} shutdown -w${acpi_fallback} $gn",
+   $timeout);
 }
 
 sub _check_for_command($$) {
-- 
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/xenbus: fix self-deadlock after killing user process


On 21.10.19 14:33, James Dingwall wrote:

On Tue, Oct 01, 2019 at 05:03:55PM +0200, Juergen Gross wrote:

In case a user process using xenbus has open transactions and is killed
e.g. via ctrl-C the following cleanup of the allocated resources might
result in a deadlock due to trying to end a transaction in the xenbus
worker thread:

[ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds.
[ 2551.492215]   Tainted: P   OE 5.0.0-29-generic #5
[ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[ 2551.528585] xenbus  D037  2 0x8080
[ 2551.528590] Call Trace:
[ 2551.528603]  __schedule+0x2c0/0x870
[ 2551.528606]  ? _cond_resched+0x19/0x40
[ 2551.528632]  schedule+0x2c/0x70
[ 2551.528637]  xs_talkv+0x1ec/0x2b0
[ 2551.528642]  ? wait_woken+0x80/0x80
[ 2551.528645]  xs_single+0x53/0x80
[ 2551.528648]  xenbus_transaction_end+0x3b/0x70
[ 2551.528651]  xenbus_file_free+0x5a/0x160
[ 2551.528654]  xenbus_dev_queue_reply+0xc4/0x220
[ 2551.528657]  xenbus_thread+0x7de/0x880
[ 2551.528660]  ? wait_woken+0x80/0x80
[ 2551.528665]  kthread+0x121/0x140
[ 2551.528667]  ? xb_read+0x1d0/0x1d0
[ 2551.528670]  ? kthread_park+0x90/0x90
[ 2551.528673]  ret_from_fork+0x35/0x40

Fix this by doing the cleanup via a workqueue instead.

Reported-by: James Dingwall 
Fixes: fd8aa9095a95c ("xen: optimize xenbus driver for multiple concurrent xenstore 
accesses")
Cc:  # 4.11
Signed-off-by: Juergen Gross 
---
  drivers/xen/xenbus/xenbus_dev_frontend.c | 20 ++--
  1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
b/drivers/xen/xenbus/xenbus_dev_frontend.c
index 08adc590f631..597af455a522 100644
--- a/drivers/xen/xenbus/xenbus_dev_frontend.c
+++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
@@ -55,6 +55,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -116,6 +117,8 @@ struct xenbus_file_priv {
wait_queue_head_t read_waitq;
  
  	struct kref kref;

+
+   struct work_struct wq;
  };
  
  /* Read out any raw xenbus messages queued up. */

@@ -300,14 +303,14 @@ static void watch_fired(struct xenbus_watch *watch,
mutex_unlock(>dev_data->reply_mutex);
  }
  
-static void xenbus_file_free(struct kref *kref)

+static void xenbus_worker(struct work_struct *wq)
  {
struct xenbus_file_priv *u;
struct xenbus_transaction_holder *trans, *tmp;
struct watch_adapter *watch, *tmp_watch;
struct read_buffer *rb, *tmp_rb;
  
-	u = container_of(kref, struct xenbus_file_priv, kref);

+   u = container_of(wq, struct xenbus_file_priv, wq);
  
  	/*

 * No need for locking here because there are no other users,
@@ -333,6 +336,18 @@ static void xenbus_file_free(struct kref *kref)
kfree(u);
  }
  
+static void xenbus_file_free(struct kref *kref)

+{
+   struct xenbus_file_priv *u;
+
+   /*
+* We might be called in xenbus_thread().
+* Use workqueue to avoid deadlock.
+*/
+   u = container_of(kref, struct xenbus_file_priv, kref);
+   schedule_work(>wq);
+}
+
  static struct xenbus_transaction_holder *xenbus_get_transaction(
struct xenbus_file_priv *u, uint32_t tx_id)
  {
@@ -650,6 +665,7 @@ static int xenbus_file_open(struct inode *inode, struct 
file *filp)
INIT_LIST_HEAD(>watches);
INIT_LIST_HEAD(>read_buffers);
init_waitqueue_head(>read_waitq);
+   INIT_WORK(>wq, xenbus_worker);
  
  	mutex_init(>reply_mutex);

mutex_init(>msgbuffer_mutex);
--
2.16.4



We have been having some crashes with an Ubuntu 5.0.0-31 kernel with
this patch and thanks to the pstore fix "x86/xen: Return from panic
notifier" we caught the oops below.  It seems to be in the same area of
code as this patch but I'm unsure if it is directly related to this
change or a secondary issue.  From the logs collected I can see this
happened while there were several parallel `xl create` process running
but so I have not been able to reproduce this in a test script but
perhaps the trace will give some clues.

Thanks,
James


<4>[53626.726580] [ cut here ]
<2>[53626.726583] kernel BUG at /build/slowfs/ubuntu-bionic/mm/slub.c:305!
<4>[53626.739554] invalid opcode:  [#1] SMP NOPTI
<4>[53626.751119] CPU: 0 PID: 38 Comm: xenwatch Tainted: P   OE 
5.0.0-31-generic #33~18.04.1z1
<4>[53626.763015] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, 
BIOS U30 02/02/2019
<4>[53626.775100] RIP: e030:__slab_free+0x188/0x330
<4>[53626.787708] Code: 90 48 89 c7 e8 89 5d da ff 66 90 f0 49 0f ba 2c 24 00 72 68 
4d 3b 6c 24 20 74 11 49 0f ba 34 24 00 e8 8c 5d da ff 66 90 eb a9 <0f> 0b 49 3b 5c 24 
28 75 e8 48 8b 45 88 49 89 4c 24 28 49 89 44 24
<4>[53626.813409] RSP: e02b:c900463f7c80 EFLAGS: 00010246
<4>[53626.826151] RAX: 8881601c20a8 RBX: 820001a3 RCX: 
8881601c20a8
<4>[53626.838346] RDX: 8881601c20a8 RSI:

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Oct 21, 2019 at 03:56:51PM +0100, Wei Liu wrote:
> On Mon, Oct 21, 2019 at 12:22:25PM +0200, Roger Pau Monné wrote:
> [...]
> > > +bool __init hyperv_probe(void)
> > > +{
> > > +uint32_t eax, ebx, ecx, edx;
> > > +bool hyperv_guest = false;
> > 
> > I don't think you need this local variable, you can return true in if
> > the if condition matches, and false otherwise.
> > 
> 
> Sure. I can drop it for now and reintroduce it when necessary.
> 
> > > +
> > > +cpuid(0x4000, , , , );
> > > +if ( (ebx == 0x7263694d) && /* "Micr" */
> > > + (ecx == 0x666f736f) && /* "osof" */
> > > + (edx == 0x76482074) )  /* "t Hv" */
> > 
> > I guess there are no HyperV headers to import that have those values
> > defined?
> > 
> 
> Not yet. I have plan to import a header from Linux. When that's done
> these will be replaced by some macros.
> 
> So I will keep this as-is for now.

Is it really cumbersome to introduce the header now?

IMO it would be better to avoid deferring this to when you introduce
the header, since it's easy to miss it.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

2019-10-21 Thread Andrew Cooper

On 21/10/2019 11:26, Roger Pau Monné wrote:
>>> +
>>> +cpuid(0x4000, , , , );
>>> +if ( (ebx == 0x7263694d) && /* "Micr" */
>>> + (ecx == 0x666f736f) && /* "osof" */
>>> + (edx == 0x76482074) )  /* "t Hv" */
>> I guess there are no HyperV headers to import that have those values
>> defined?
>>
>> Alternatively you could do something like the following I think:
>>
>> static const char hyperv_sig[] __initconst = "Microsoft Hv";
>>
>> bool __init hyperv_probe(void)
>> {
>> uint32_t eax, sig[3];
>>
>> cpuid(0x4000, , [0], [1], [2]);
>> if ( !strncmp(hyperv_sig, sig, strncmp(hyperv_sig) )
> Urg, I've made a mistake here, the line should be:
>
> !strncmp(hyperv_sig, sig, strlen(hyperv_sig))

Just because the leaves form an ascii string, doesn't mean that using
string comparisons are the sane way to check.  3x 32bit compares are
substantially more efficient, and far harder to get wrong.

Wei: On your detection algorithm, you also need to find HV#1 in
0x4001.eax to detect conformance to the viridian spec.

~Andrew

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

Re: [Xen-devel] [PATCH v2 03/20] piix4: Add a i8259 Interrupt Controller as specified in datasheet

Philippe Mathieu-Daudé  于2019年10月18日周五 下午9:52写道：

> From: Hervé Poussineau 
>
> Add ISA irqs as piix4 gpio in, and CPU interrupt request as piix4 gpio out.
> Remove i8259 instanciated in malta board, to not have it twice.
>
> We can also remove the now unused piix4_init() function.
>
> Acked-by: Michael S. Tsirkin 
> Acked-by: Paolo Bonzini 
> Signed-off-by: Hervé Poussineau 
> Message-Id: <20171216090228.28505-8-hpous...@reactos.org>
> Reviewed-by: Aleksandar Markovic 
> [PMD: rebased, updated includes, use ISA_NUM_IRQS in for loop]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/isa/piix4.c   | 43 ---
>  hw/mips/mips_malta.c | 32 +---
>  include/hw/i386/pc.h |  1 -
>  3 files changed, 45 insertions(+), 31 deletions(-)
>
> diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
> index d0b18e0586..9c37c85ae2 100644
> --- a/hw/isa/piix4.c
> +++ b/hw/isa/piix4.c
> @@ -24,6 +24,7 @@
>   */
>
>  #include "qemu/osdep.h"
> +#include "hw/irq.h"
>  #include "hw/i386/pc.h"
>  #include "hw/pci/pci.h"
>  #include "hw/isa/isa.h"
> @@ -36,6 +37,8 @@ PCIDevice *piix4_dev;
>
>  typedef struct PIIX4State {
>  PCIDevice dev;
> +qemu_irq cpu_intr;
> +qemu_irq *isa;
>
>  /* Reset Control Register */
>  MemoryRegion rcr_mem;
> @@ -94,6 +97,18 @@ static const VMStateDescription vmstate_piix4 = {
>  }
>  };
>
> +static void piix4_request_i8259_irq(void *opaque, int irq, int level)
> +{
> +PIIX4State *s = opaque;
> +qemu_set_irq(s->cpu_intr, level);
> +}
> +
> +static void piix4_set_i8259_irq(void *opaque, int irq, int level)
> +{
> +PIIX4State *s = opaque;
> +qemu_set_irq(s->isa[irq], level);
> +}
> +
>  static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
>  unsigned int len)
>  {
> @@ -127,29 +142,35 @@ static const MemoryRegionOps piix4_rcr_ops = {
>  static void piix4_realize(PCIDevice *dev, Error **errp)
>  {
>  PIIX4State *s = PIIX4_PCI_DEVICE(dev);
> +ISABus *isa_bus;
> +qemu_irq *i8259_out_irq;
>
> -if (!isa_bus_new(DEVICE(dev), pci_address_space(dev),
> - pci_address_space_io(dev), errp)) {
> +isa_bus = isa_bus_new(DEVICE(dev), pci_address_space(dev),
> +  pci_address_space_io(dev), errp);
> +if (!isa_bus) {
>  return;
>  }
>
> +qdev_init_gpio_in_named(DEVICE(dev), piix4_set_i8259_irq,
> +"isa", ISA_NUM_IRQS);
> +qdev_init_gpio_out_named(DEVICE(dev), >cpu_intr,
> + "intr", 1);
> +
>


Does the piix4 hardware has the GPIO for interrupt? Seems not.



>  memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
>"reset-control", 1);
>  memory_region_add_subregion_overlap(pci_address_space_io(dev), 0xcf9,
>  >rcr_mem, 1);
>
> +/* initialize i8259 pic */
> +i8259_out_irq = qemu_allocate_irqs(piix4_request_i8259_irq, s, 1);
> +s->isa = i8259_init(isa_bus, *i8259_out_irq);
>

In i8259_init, we also allocate 16 input line and 1 output line.
Seems it is duplicated with the GPIO allocation in previous.

Also
Maybe here can uses
i8259(isa_bus, qemu_allocate_irq(piix4_request_i8259_irq, s, 0));


> +
> +/* initialize ISA irqs */
> +isa_bus_irqs(isa_bus, s->isa);
> +
>  piix4_dev = dev;
>  }
>
> -int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
> -{
> -PCIDevice *d;
> -
> -d = pci_create_simple_multifunction(bus, devfn, true, "PIIX4");
> -*isa_bus = ISA_BUS(qdev_get_child_bus(DEVICE(d), "isa.0"));
> -return d->devfn;
> -}
> -
>  static void piix4_class_init(ObjectClass *klass, void *data)
>  {
>  DeviceClass *dc = DEVICE_CLASS(klass);
> diff --git a/hw/mips/mips_malta.c b/hw/mips/mips_malta.c
> index 4d9c64b36a..7d25ab6c23 100644
> --- a/hw/mips/mips_malta.c
> +++ b/hw/mips/mips_malta.c
> @@ -97,7 +97,7 @@ typedef struct {
>  SysBusDevice parent_obj;
>
>  MIPSCPSState cps;
> -qemu_irq *i8259;
> +qemu_irq i8259[16];
>  } MaltaState;
>
>  static ISADevice *pit;
> @@ -1235,8 +1235,8 @@ void mips_malta_init(MachineState *machine)
>  int64_t kernel_entry, bootloader_run_addr;
>  PCIBus *pci_bus;
>  ISABus *isa_bus;
> -qemu_irq *isa_irq;
>  qemu_irq cbus_irq, i8259_irq;
> +PCIDevice *pci;
>  int piix4_devfn;
>  I2CBus *smbus;
>  DriveInfo *dinfo;
> @@ -1407,30 +1407,24 @@ void mips_malta_init(MachineState *machine)
>  /* Board ID = 0x420 (Malta Board with CoreLV) */
>  stl_p(memory_region_get_ram_ptr(bios_copy) + 0x10, 0x0420);
>
> -/*
> - * We have a circular dependency problem: pci_bus depends on isa_irq,
> - * isa_irq is provided by i8259, i8259 depends on ISA, ISA depends
> - * on piix4, and piix4 depends on pci_bus.  To stop the cycle we have
> - * qemu_irq_proxy() adds an extra bit of indirection, allowing us
> - * to resolve

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Oct 21, 2019 at 12:22:25PM +0200, Roger Pau Monné wrote:
[...]
> > +bool __init hyperv_probe(void)
> > +{
> > +uint32_t eax, ebx, ecx, edx;
> > +bool hyperv_guest = false;
> 
> I don't think you need this local variable, you can return true in if
> the if condition matches, and false otherwise.
> 

Sure. I can drop it for now and reintroduce it when necessary.

> > +
> > +cpuid(0x4000, , , , );
> > +if ( (ebx == 0x7263694d) && /* "Micr" */
> > + (ecx == 0x666f736f) && /* "osof" */
> > + (edx == 0x76482074) )  /* "t Hv" */
> 
> I guess there are no HyperV headers to import that have those values
> defined?
> 

Not yet. I have plan to import a header from Linux. When that's done
these will be replaced by some macros.

So I will keep this as-is for now.

[...]
> > +#ifndef __X86_GUEST_HYPERV_H__
> > +#define __X86_GUEST_HYPERV_H__
> > +
> > +#ifdef CONFIG_HYPERV_GUEST
> > +
> > +#include 
> > +
> > +extern struct hypervisor_ops hyperv_hypervisor_ops;
> 
> hyperv_ops would be fine by me, seems kind of redundant to have
> 'hyper' twice in a name.
> 

In that case I will also change xen_hypervisor_ops to xen_ops to remain
consistent.

Wei.

> Thanks, Roger.

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

[Xen-devel] [linux-4.4 test] 142989: regressions - trouble: broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit2  broken
 test-arm64-arm64-xl-seattle  broken
 test-amd64-amd64-xl-pvshim   16 guest-localmigrate   fail REGR. vs. 139698

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine  5 host-install broken pass in 142951
 test-arm64-arm64-xl-credit2   4 host-install(4)  broken pass in 142951
 test-arm64-arm64-xl-seattle   4 host-install(4)  broken pass in 142951
 test-amd64-i386-libvirt-pair 21 guest-start/debian fail in 142901 pass in 
142989
 test-amd64-amd64-xl-pvshim   12 guest-start  fail in 142951 pass in 142989
 test-armhf-armhf-libvirt-raw 10 debian-di-install fail in 142951 pass in 142989
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail pass in 142901
 test-amd64-i386-pair 11 xen-boot/dst_host  fail pass in 142951

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 139698

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine  8 reboot   fail in 142951 never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail in 142951 never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail in 142951 never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-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-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check

Re: [Xen-devel] [PATCH for-next v2 7/9] x86: switch xen implementation to use hypervisor framework

On Mon, Oct 21, 2019 at 11:56:36AM +0200, Roger Pau Monné wrote:
[...]
> >  static struct hypervisor_ops *hops __read_mostly;
> >  
> > @@ -31,7 +31,34 @@ bool hypervisor_probe(void)
> >  if ( hops )
> >  return true;
> >  
> > -return false;
> > +/* Too early to use cpu_has_hypervisor */
> > +if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
> > +return false;
> > +
> > +#ifdef CONFIG_XEN_GUEST
> > +if ( xen_probe() )
> > +hops = _hypervisor_ops;
> > +#endif
> 
> I think you likely want something like:
> 
> if ( xen_probe() )
> {
> hops = _hypervisor_ops;
>   return true;
> }
> if ( hyperv_probe() )
> {
> 
>   return true;
> }
> 
> return false;
> 
> In order to return after a successful probe, or else you lose cycles
> probing for hypervisors when a match has been found, and also in the
> Xen case you risk detecting the HyperV support in Xen and thus using
> that instead of the Xen one.
> 

Good point.

> Long term if we gain more guests support I would likely want to see
> hypervisor_ops turning into an array and gaining a probe function so
> that this can be done in a loop instead of having this function.
> 

That was my plan from the get-go but Xen lacked appropriate
infrastructure, hence I resorted to something akin to HVM hooks.

[...]
> > -void __init hypervisor_setup(void)
> > +void __init xen_setup(void)
> >  {
> >  init_memmap();
> >  
> > @@ -277,7 +272,7 @@ void __init hypervisor_setup(void)
> >  init_evtchn();
> >  }
> >  
> > -void hypervisor_ap_setup(void)
> > +void xen_ap_setup(void)
> >  {
> >  set_vcpu_id();
> >  map_vcpuinfo();
> > @@ -307,7 +302,7 @@ static void ap_resume(void *unused)
> >  init_evtchn();
> >  }
> >  
> > -void hypervisor_resume(void)
> > +void xen_resume(void)
> 
> I think xen_{setup/ap_setup/resume} can be made static now?

Indeed. I will fix this.

Wei.

> 
> Thanks, Roger.

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

Re: [Xen-devel] [PATCH for-next v2 8/9] x86: be more verbose when running on a hypervisor

On Mon, Oct 21, 2019 at 12:00:38PM +0200, Roger Pau Monné wrote:
> On Mon, Sep 30, 2019 at 04:00:42PM +0100, Wei Liu wrote:
> > Signed-off-by: Wei Liu 
> > ---
> >  xen/arch/x86/guest/hypervisor.c| 5 +
> >  xen/arch/x86/setup.c   | 6 +-
> >  xen/include/asm-x86/guest/hypervisor.h | 2 ++
> >  3 files changed, 12 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/x86/guest/hypervisor.c 
> > b/xen/arch/x86/guest/hypervisor.c
> > index 30453b6a7a..8161b26c5a 100644
> > --- a/xen/arch/x86/guest/hypervisor.c
> > +++ b/xen/arch/x86/guest/hypervisor.c
> > @@ -43,6 +43,11 @@ bool hypervisor_probe(void)
> >  return !!hops;
> >  }
> >  
> > +const char *hypervisor_name(void)
> > +{
> 
> I would maybe add ASSERT(hops);
> 
> > +return hops->name;
> > +}
> > +
[...]
> > diff --git a/xen/include/asm-x86/guest/hypervisor.h 
> > b/xen/include/asm-x86/guest/hypervisor.h
> > index 38344e2e89..a7d75bf9cf 100644
> > --- a/xen/include/asm-x86/guest/hypervisor.h
> > +++ b/xen/include/asm-x86/guest/hypervisor.h
> > @@ -36,6 +36,7 @@ bool hypervisor_probe(void);
> >  void hypervisor_setup(void);
> >  void hypervisor_ap_setup(void);
> >  void hypervisor_resume(void);
> > +const char *hypervisor_name(void);
> >  
> >  #else
> >  
> > @@ -45,6 +46,7 @@ static inline bool hypervisor_probe(void) { return false; 
> > }
> >  static inline void hypervisor_setup(void) {}
> >  static inline void hypervisor_ap_setup(void) {}
> >  static inline void hypervisor_resume(void) {}
> > +static inline char *hypervisor_name(void) { return NULL; }
> 
> I think you want an ASSERT_UNREACHABLE here, since hypervisor_name
> shouldn't be called unless Xen has detected that's running as a guest,
> which can only happen if CONFIG_GUEST is selected.

Ack to both comments.

Wei.

> 
> Thanks, Roger.

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

Re: [Xen-devel] [OSSTEST PATCH] guest_prepare_disk: Only do the umount if we set an env var

On Mon, Oct 21, 2019 at 02:32:15PM +0100, Ian Jackson wrote:
> This call to guest_umount_lv is here for the benefit of ad-hoc reruns
> of (eg) ts-guest-start tidy up any ad-hoc messing about (eg from
> earlier runs of ts-debian-fixup or something).  It is not needed in
> production runs.
> 
> Serendipitously, this osstest code discovered a bug in the Linux
> blkback: when tearing down, it sets the backend state to 6 before it
> has closed the underlying block devices.  This ultimately means that
> after "xl destroy" or "xl shutdown -w" there is a period when the
> guest's open handle onto its storage is still open.  This is wrong.
> 
> This detection depends on us winning a tricky race.  So it shows up in
> osstest as a very low probability heisenbug.  The bug is currently in
> all versions of Linux and causing a bit of a nuisance.
> 
> It would be best to add a proper check for this bug.  However, this is
> quite fiddly: really, it ought to be done as close to the xl command
> completion as possible, in the same ssh invocation.  That would
> involve a fair bit of plumbing and ad-hocery.  I don't think that
> would be proportionate for such a low-impact bug.
> 
> So instead in this patch I just disable this cleanup code in the
> troublesome case, unless it is explicitly requested by the user
> setting OSSTEST_GUEST_DISK_MOUNT_CLEANUP to a trueish value.  (This
> would be reasonably convenient for the ad-hoc testing that this call
> serves.)
> 
> Thanks to Roger for diagnosing the Linux kernel bug.
> 
> CC: Roger Pau Monne 
> CC: Jürgen Groß 
> Signed-off-by: Ian Jackson 

Thanks:

Reviewed-by: Roger Pau Monné 

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

[Xen-devel] [freebsd-master test] 143001: regressions - trouble: blocked/fail

flight 143001 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143001/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-freebsd   7 freebsd-buildfail REGR. vs. 141501

Tests which did not succeed, but are not blocking:
 build-amd64-xen-freebsd   1 build-check(1)   blocked  n/a
 build-amd64-freebsd-again 1 build-check(1)   blocked  n/a

version targeted for testing:
 freebsd  691baa0294c3f76b957f9e6a3ffe0c9c954263a7
baseline version:
 freebsd  14aef6dfca96006e52b8fb920bde7c612ba58b79

Last test of basis   141501  2019-09-20 09:19:51 Z   31 days
Failing since141701  2019-09-23 09:19:41 Z   28 days   12 attempts
Testing same since   143001  2019-10-21 09:20:15 Z0 days1 attempts


People who touched revisions under test:
  0mp <0...@freebsd.org>
  ae 
  alc 
  Alek Pinchuk 
  allanjude 
  ambrisko 
  andrew 
  asomers 
  avg 
  bapt 
  bdragon 
  bdrewery 
  br 
  brooks 
  brueffer 
  bz 
  cem 
  chs 
  cognet 
  cperciva 
  cy 
  dab 
  daichi 
  dchagin 
  dim 
  dougm 
  emaste 
  erj 
  eugen 
  gallatin 
  gjb 
  glebius 
  gonzo 
  grembo 
  hrs 
  hselasky 
  ian 
  imp 
  Jacob Keller 
  jeff 
  jhb 
  jhibbits 
  jilles 
  jkim 
  jlh 
  jmg 
  jtl 
  kaktus 
  kan 
  karels 
  kevans 
  kib 
  kp 
  lstewart 
  luporl 
  lwhsu 
  manu 
  marius 
  markj 
  mav 
  mckusick 
  mhorne 
  mjg 
  mm 
  mmacy 
  mmel 
  np 
  olivier 
  oshogbo 
  philip 
  phk 
  Piotr Pietruszewski 
  ray 
  rmacklem 
  royger 
  rrs 
  rstone 
  samm 
  schweikh 
  scottl 
  sef 
  sjg 
  tijl 
  Tom Caputi 
  trasz 
  tsoome 
  tuexen 
  vangyzen 
  vmaffione 
  yuripv 
  Zach Vargas 

jobs:
 build-amd64-freebsd-againblocked 
 build-amd64-freebsd  fail
 build-amd64-xen-freebsd  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 11556 lines long.)

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

[Xen-devel] [OSSTEST PATCH] guest_prepare_disk: Only do the umount if we set an env var

This call to guest_umount_lv is here for the benefit of ad-hoc reruns
of (eg) ts-guest-start tidy up any ad-hoc messing about (eg from
earlier runs of ts-debian-fixup or something).  It is not needed in
production runs.

Serendipitously, this osstest code discovered a bug in the Linux
blkback: when tearing down, it sets the backend state to 6 before it
has closed the underlying block devices.  This ultimately means that
after "xl destroy" or "xl shutdown -w" there is a period when the
guest's open handle onto its storage is still open.  This is wrong.

This detection depends on us winning a tricky race.  So it shows up in
osstest as a very low probability heisenbug.  The bug is currently in
all versions of Linux and causing a bit of a nuisance.

It would be best to add a proper check for this bug.  However, this is
quite fiddly: really, it ought to be done as close to the xl command
completion as possible, in the same ssh invocation.  That would
involve a fair bit of plumbing and ad-hocery.  I don't think that
would be proportionate for such a low-impact bug.

So instead in this patch I just disable this cleanup code in the
troublesome case, unless it is explicitly requested by the user
setting OSSTEST_GUEST_DISK_MOUNT_CLEANUP to a trueish value.  (This
would be reasonably convenient for the ad-hoc testing that this call
serves.)

Thanks to Roger for diagnosing the Linux kernel bug.

CC: Roger Pau Monne 
CC: Jürgen Groß 
Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 78f47480..6b0ee7a2 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1938,7 +1938,8 @@ sub guest_create_paused ($) {
 sub guest_prepare_disk ($) {
 my ($gho) = @_;
 
-guest_umount_lv($gho->{Host}, $gho);
+guest_umount_lv($gho->{Host}, $gho)
+   if $ENV{'OSSTEST_GUEST_DISK_MOUNT_CLEANUP'};
 
 return if ($gho->{Diskfmt} // 'none') eq "none";
 
-- 
2.11.0


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580
 test-arm64-arm64-xl-xsm   7 xen-boot fail REGR. vs. 133580

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   fail REGR. vs. 133580
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 10 debian-hvm-install fail 
baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 133580
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  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 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never

Re: [Xen-devel] PV-shim 4.13 assertion failures during vcpu_wake()


On 21.10.19 13:36, Roger Pau Monné wrote:

On Mon, Oct 21, 2019 at 12:52:10PM +0200, Jürgen Groß wrote:

On 21.10.19 11:51, Sergey Dyasli wrote:

Hello,

While testing pv-shim from a snapshot of staging 4.13 branch (with core-
scheduling patches applied), some sort of scheduling issues were uncovered
which usually leads to a guest lockup (sometimes with soft lockup messages
from Linux kernel).

This happens more frequently on SandyBridge CPUs. After enabling
CONFIG_DEBUG in pv-shim, the following assertions failed:

Null scheduler:

  Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' 
failed at ...are/xen-dir/xen-root/xen/include/xen/sched-if.h:278
  (full crash log: https://paste.debian.net/1108861/ )

Credit1 scheduler:

  Assertion 'cpumask_cycle(cpu, unit->cpu_hard_affinity) == cpu' failed at 
sched_credit.c:383
  (full crash log: https://paste.debian.net/1108862/ )

I'm currently investigation those, but would appreciate any help or
suggestions.


Hmm, I think that pv_shim_cpu_up() shouldn't do the vcpu_wake(), but the
caller.

Does the attached patch help?


Juergen



 From 068ea0419d1a67e967b9431ed11e24b731cd357f Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Mon, 21 Oct 2019 12:28:33 +0200
Subject: [PATCH] xen/shim: fix pv-shim cpu up/down

Calling vcpu_wake() from pv_shim_cpu_up() is wrong as it is not yet
sure that the correct scheduler has taken over the cpu.


I'm not sure why this is wrong, the scheduler should be capable of
handling 2 vCPUs on a single pCPU while the new pCPU is brought
online?


Oh, right, I made some false assumptions.

This patch is pure nonsense.


Juergen

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

Re: [Xen-devel] [RFC] Documentation formats, licenses and file system structure

2019-10-21 Thread Artem Mygaiev

Hi Lars

On Thu, 2019-10-17 at 17:30 +, Lars Kurth wrote:
> 
> On 17/10/2019, 18:05, "Rich Persaud" <
> pers...@gmail.com
> > wrote:
> 
> On Oct 17, 2019, at 12:55, Stefano Stabellini <
> sstabell...@kernel.org
> > wrote:
> > 
> > On Thu, 17 Oct 2019, Rich Persaud wrote:
> >>> On Oct 17, 2019, at 12:32, Stefano Stabellini <
> sstabell...@kernel.org
> > wrote:
> >>> 
> >>> On Thu, 17 Oct 2019, Lars Kurth wrote:
>  On 16/10/2019, 17:35, "Rich Persaud" <
> pers...@gmail.com
> > wrote:
>  
> >> On Oct 15, 2019, at 08:27, Lars Kurth <
> lars.kurth@gmail.com
> > wrote:
> > ...
> > 
> > My point really was is that due to storing the files in
> git, we essentially do NOT today do this.
> > So we would need to take extra action: e.g. manually or
> through tooling
> > 
> >>> 4.2: We could require individual authors to be credited:
> in that
> >>> case we probably ought to lead by example and
> list the authors
> >>> in a credit/license section and extract the
> information from
> >>> git logs when we generate it (at some point in
> the future)
> >>> 5: You give an indication whether you made changes ... in
> practice
> >>> this means you have to state significant changes made to
> the works
> >> 
> >> This is also helpful for provenance of changes, which is
> relevant in safety-oriented documentation.  It can be used to clearly
> delineate CC-licensed content (which may be reused by many companies)
> from "All Rights Reserved" commercial content that may be added for a
> specific commercial audience or purpose.
> > 
> > I agree
> > 
> > I think the outcome of this analysis is really that the
> only significant difference between BSD and CC-BY in this context is
> the  "All Rights Reserved" portion
>  
>    Also - BSD is a "software" license while CC-BY is a
> "content" license, so they are not strictly comparable, even if they
> use similar terminology.
>  
>  True, but as we have noticed the boundary between content
> and in-code docs content is fuzzy.
>  
> >> There is a difference between "software" which "runs on
> machines" and "documentation" which "runs on humans".  Combined
> software (e.g. BSD code from two origins) is executed identically,
> despite origin.  Humans make value judgements based on the
> author/origin of content, hence the focus on attribution.  Yes, there
> is a provenance graph in git (software/data), but that's not
> typically visible to human readers, except as a generated report,
> i.e. documentation.
> > 
> > Yes true. But also true for CC-BY-4 sources stored in git
> unless extra action is taken 
> > 
> > But my point is: 
> > * If we take extra action as e.g. proposed in 4.2 we can
> apply this uniformly to BSD as well as CC-BY pages
> > * We can add a section on re-use as proposed in 4.2 which
> recommends best practices around 5.  
> > * We can highlight sections that are BSD vs CC-BY in such a
> section, such that someone who has issue can remove these easily
> > 
> > In addition to these points: maybe it is too impractical to
> create ABI documentation based on CC-BY-4 (given that a lot of what
> we need is already in BSD sources). 
> > We could just copy some of the content in the BSD sources
> to new CC-BY-4 sources, but in practice it would just be hiding the
> potential legal issues behind it. 
> > Someone could contest the creation and argue that portions
> of the now CC-BY-4 sources are in fact BSD: in practice this is
> extremely unlikely, but it is possible.
> > 
> >>> As such, BSD-2/3-Clause in our context works similarly to
> CC-BY-4
> >>> from a downstream's perspective. In fact CC-BY-4 is
> somewhat stricter
> >> 
> >> If we don't want the incentives and provenance properties
> of CC-BY, there is the option of CC0, which is the equivalent of
> public domain.  This would delegate the task of separating commercial
> vs CC content to each reader, without any license-required
> attribution or separation.
> >> 
> >> Some background on licenses designed for documentation,
> which has different legal requirements than software:
> >> 
> >> 
> https://urldefense.com/v3/__https://www.dreamsongs.com/IHE/IHE-50.html__;!K6dmGCEab4ueJg!kzVGzaxQSxR-63kIKCKdKg9tpj03tZTi7-WJQ4Jv0YsIdRVLFr8VUmElp-msVq7CLg$
>  
> >> 
> https://urldefense.com/v3/__https://creativecommons.org/faq/*what-are-creative-commons-licenses__;Iw!K6dmGCEab4ueJg!kzVGzaxQSxR-63kIKCKdKg9tpj03tZTi7-WJQ4Jv0YsIdRVLFr8VUmElp-lzx1cSwA$
>   (not for s/w)
> > 
> > I will have a look. But the core issue - which is why I
> have proposed what I have - is the question on how practically

Re: [Xen-devel] [PATCH] xen/xenbus: fix self-deadlock after killing user process

2019-10-21 Thread James Dingwall

On Tue, Oct 01, 2019 at 05:03:55PM +0200, Juergen Gross wrote:
> In case a user process using xenbus has open transactions and is killed
> e.g. via ctrl-C the following cleanup of the allocated resources might
> result in a deadlock due to trying to end a transaction in the xenbus
> worker thread:
> 
> [ 2551.474706] INFO: task xenbus:37 blocked for more than 120 seconds.
> [ 2551.492215]   Tainted: P   OE 5.0.0-29-generic #5
> [ 2551.510263] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 2551.528585] xenbus  D037  2 0x8080
> [ 2551.528590] Call Trace:
> [ 2551.528603]  __schedule+0x2c0/0x870
> [ 2551.528606]  ? _cond_resched+0x19/0x40
> [ 2551.528632]  schedule+0x2c/0x70
> [ 2551.528637]  xs_talkv+0x1ec/0x2b0
> [ 2551.528642]  ? wait_woken+0x80/0x80
> [ 2551.528645]  xs_single+0x53/0x80
> [ 2551.528648]  xenbus_transaction_end+0x3b/0x70
> [ 2551.528651]  xenbus_file_free+0x5a/0x160
> [ 2551.528654]  xenbus_dev_queue_reply+0xc4/0x220
> [ 2551.528657]  xenbus_thread+0x7de/0x880
> [ 2551.528660]  ? wait_woken+0x80/0x80
> [ 2551.528665]  kthread+0x121/0x140
> [ 2551.528667]  ? xb_read+0x1d0/0x1d0
> [ 2551.528670]  ? kthread_park+0x90/0x90
> [ 2551.528673]  ret_from_fork+0x35/0x40
> 
> Fix this by doing the cleanup via a workqueue instead.
> 
> Reported-by: James Dingwall 
> Fixes: fd8aa9095a95c ("xen: optimize xenbus driver for multiple concurrent 
> xenstore accesses")
> Cc:  # 4.11
> Signed-off-by: Juergen Gross 
> ---
>  drivers/xen/xenbus/xenbus_dev_frontend.c | 20 ++--
>  1 file changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_dev_frontend.c 
> b/drivers/xen/xenbus/xenbus_dev_frontend.c
> index 08adc590f631..597af455a522 100644
> --- a/drivers/xen/xenbus/xenbus_dev_frontend.c
> +++ b/drivers/xen/xenbus/xenbus_dev_frontend.c
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -116,6 +117,8 @@ struct xenbus_file_priv {
>   wait_queue_head_t read_waitq;
>  
>   struct kref kref;
> +
> + struct work_struct wq;
>  };
>  
>  /* Read out any raw xenbus messages queued up. */
> @@ -300,14 +303,14 @@ static void watch_fired(struct xenbus_watch *watch,
>   mutex_unlock(>dev_data->reply_mutex);
>  }
>  
> -static void xenbus_file_free(struct kref *kref)
> +static void xenbus_worker(struct work_struct *wq)
>  {
>   struct xenbus_file_priv *u;
>   struct xenbus_transaction_holder *trans, *tmp;
>   struct watch_adapter *watch, *tmp_watch;
>   struct read_buffer *rb, *tmp_rb;
>  
> - u = container_of(kref, struct xenbus_file_priv, kref);
> + u = container_of(wq, struct xenbus_file_priv, wq);
>  
>   /*
>* No need for locking here because there are no other users,
> @@ -333,6 +336,18 @@ static void xenbus_file_free(struct kref *kref)
>   kfree(u);
>  }
>  
> +static void xenbus_file_free(struct kref *kref)
> +{
> + struct xenbus_file_priv *u;
> +
> + /*
> +  * We might be called in xenbus_thread().
> +  * Use workqueue to avoid deadlock.
> +  */
> + u = container_of(kref, struct xenbus_file_priv, kref);
> + schedule_work(>wq);
> +}
> +
>  static struct xenbus_transaction_holder *xenbus_get_transaction(
>   struct xenbus_file_priv *u, uint32_t tx_id)
>  {
> @@ -650,6 +665,7 @@ static int xenbus_file_open(struct inode *inode, struct 
> file *filp)
>   INIT_LIST_HEAD(>watches);
>   INIT_LIST_HEAD(>read_buffers);
>   init_waitqueue_head(>read_waitq);
> + INIT_WORK(>wq, xenbus_worker);
>  
>   mutex_init(>reply_mutex);
>   mutex_init(>msgbuffer_mutex);
> -- 
> 2.16.4
> 

We have been having some crashes with an Ubuntu 5.0.0-31 kernel with 
this patch and thanks to the pstore fix "x86/xen: Return from panic 
notifier" we caught the oops below.  It seems to be in the same area of 
code as this patch but I'm unsure if it is directly related to this 
change or a secondary issue.  From the logs collected I can see this 
happened while there were several parallel `xl create` process running 
but so I have not been able to reproduce this in a test script but 
perhaps the trace will give some clues.

Thanks,
James


<4>[53626.726580] [ cut here ]
<2>[53626.726583] kernel BUG at /build/slowfs/ubuntu-bionic/mm/slub.c:305!
<4>[53626.739554] invalid opcode:  [#1] SMP NOPTI
<4>[53626.751119] CPU: 0 PID: 38 Comm: xenwatch Tainted: P   OE 
5.0.0-31-generic #33~18.04.1z1
<4>[53626.763015] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, 
BIOS U30 02/02/2019
<4>[53626.775100] RIP: e030:__slab_free+0x188/0x330
<4>[53626.787708] Code: 90 48 89 c7 e8 89 5d da ff 66 90 f0 49 0f ba 2c 24 00 
72 68 4d 3b 6c 24 20 74 11 49 0f ba 34 24 00 e8 8c 5d da ff 66 90 eb a9 <0f> 0b 
49 3b 5c 24 28 75 e8 48 8b 45 88 49 89 4c 24 28 49 89 44 24
<4>[53626.813409] RSP: e02b:c900463f7c80 EFLAGS: 00010246

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

On Mon, Oct 21, 2019 at 12:29:45PM +0100, George Dunlap wrote:
> On 8/30/19 10:28 AM, Wei Liu wrote:
> > On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:
> >> We would like to have a common maintainers email address for DornerWorks
> >> maintained code, which currently is the ARINC653 scheduler. This will
> >> enable us to better monitor and respond to the Xen community. This patch
> >> adds a maintainer line with the DornerWorks maintainers email address.
> >> ---
> >>  MAINTAINERS | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 77413e0d9e..3cce253931 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -168,6 +168,7 @@ F: xen/common/argo.c
> >>  ARINC653 SCHEDULER
> >>  M:Josh Whitehead 
> >>  M:Robert VanVossen 
> >> +M:DornerWorks Xen-Devel 
> > 
> > The correct symbol here is L. 
> > 
> > L: Mailing list that is relevant to this area
> 
> But this isn't exactly a mailing list, is it?  The 'L:' tag is normally
> for things like the Linux Arm mailing list, the Linux Net mailing list,
> and so on -- *public* lists where discussions about that subsystem happen.
> 
> This isn't a public list where discussion happens.  At the moment, in
> fact, it looks like it might be a *single email account*, to which
> several people have access; at best it would be an alias that would go
> to a number of interested parties.  That seems closer to 'R:'.
> 
> I admit this is getting into the minutia of technicalities here. :-)
> 

My understanding is that the list being public is a not a requirement.
For example, Linux has this:

  L:  sparmaintai...@unisys.com (Unisys internal)

An alias for several people still qualifies as a list to me.

Anyway, either R or L works. I don't want to bikeshed further...

Wei.

>  -George

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

Re: [Xen-devel] PV-shim 4.13 assertion failures during vcpu_wake()

On Mon, Oct 21, 2019 at 12:52:10PM +0200, Jürgen Groß wrote:
> On 21.10.19 11:51, Sergey Dyasli wrote:
> > Hello,
> > 
> > While testing pv-shim from a snapshot of staging 4.13 branch (with core-
> > scheduling patches applied), some sort of scheduling issues were uncovered
> > which usually leads to a guest lockup (sometimes with soft lockup messages
> > from Linux kernel).
> > 
> > This happens more frequently on SandyBridge CPUs. After enabling
> > CONFIG_DEBUG in pv-shim, the following assertions failed:
> > 
> > Null scheduler:
> > 
> >  Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' 
> > failed at ...are/xen-dir/xen-root/xen/include/xen/sched-if.h:278
> >  (full crash log: https://paste.debian.net/1108861/ )
> > 
> > Credit1 scheduler:
> > 
> >  Assertion 'cpumask_cycle(cpu, unit->cpu_hard_affinity) == cpu' failed 
> > at sched_credit.c:383
> >  (full crash log: https://paste.debian.net/1108862/ )
> > 
> > I'm currently investigation those, but would appreciate any help or
> > suggestions.
> 
> Hmm, I think that pv_shim_cpu_up() shouldn't do the vcpu_wake(), but the
> caller.
> 
> Does the attached patch help?
> 
> 
> Juergen

> From 068ea0419d1a67e967b9431ed11e24b731cd357f Mon Sep 17 00:00:00 2001
> From: Juergen Gross 
> Date: Mon, 21 Oct 2019 12:28:33 +0200
> Subject: [PATCH] xen/shim: fix pv-shim cpu up/down
> 
> Calling vcpu_wake() from pv_shim_cpu_up() is wrong as it is not yet
> sure that the correct scheduler has taken over the cpu.

I'm not sure why this is wrong, the scheduler should be capable of
handling 2 vCPUs on a single pCPU while the new pCPU is brought
online?

Note that with the current code the vcpu_wake is not performed until
cpu_up_helper has been called and returned successfully.

> Doing the
> call after continue_hypercall_on_cpu() is correct, so let
> pv_shim_cpu_up() just online the cpu.
> 
> Adapt pv_shim_cpu_down() to be symmetric, even if that is not
> required for correctness.
> 
> Reported-by: Sergey Dyasli 
> Signed-off-by: Juergen Gross 
> ---
>  xen/arch/x86/pv/shim.c | 16 
>  xen/common/domain.c| 31 ++-
>  2 files changed, 18 insertions(+), 29 deletions(-)
> 
> diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
> index 5edbcd9ac5..bc6a2f3eb9 100644
> --- a/xen/arch/x86/pv/shim.c
> +++ b/xen/arch/x86/pv/shim.c
> @@ -815,16 +815,11 @@ long pv_shim_cpu_up(void *data)
>  {
>  struct vcpu *v = data;
>  struct domain *d = v->domain;
> -bool wake;
>  
>  BUG_ON(smp_processor_id() != 0);
>  
> -domain_lock(d);
>  if ( !v->is_initialised )
> -{
>  domain_unlock(d);
> -return -EINVAL;

I think you wanted to remove the domain_unlock not the return.

> -}
>  
>  if ( !cpu_online(v->vcpu_id) )
>  {
> @@ -832,18 +827,12 @@ long pv_shim_cpu_up(void *data)
>  
>  if ( rc )
>  {
> -domain_unlock(d);
>  gprintk(XENLOG_ERR, "Failed to bring up CPU#%u: %ld\n",
>  v->vcpu_id, rc);
>  return rc;
>  }
>  }
>  
> -wake = test_and_clear_bit(_VPF_down, >pause_flags);
> -domain_unlock(d);
> -if ( wake )
> -vcpu_wake(v);
> -
>  return 0;
>  }
>  
> @@ -852,11 +841,6 @@ long pv_shim_cpu_down(void *data)
>  struct vcpu *v = data;
>  long rc;
>  
> -BUG_ON(smp_processor_id() != 0);
> -
> -if ( !test_and_set_bit(_VPF_down, >pause_flags) )
> -vcpu_sleep_sync(v);
> -
>  if ( cpu_online(v->vcpu_id) )
>  {
>  rc = cpu_down_helper((void *)(unsigned long)v->vcpu_id);
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 9c7360ed2a..e83657e310 100644
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1428,19 +1428,21 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  break;
>  
>  case VCPUOP_up:
> -#ifdef CONFIG_X86
> -if ( pv_shim )
> -rc = continue_hypercall_on_cpu(0, pv_shim_cpu_up, v);
> -else
> -#endif
>  {
>  bool wake = false;
>  
>  domain_lock(d);
> -if ( !v->is_initialised )
> -rc = -EINVAL;
> -else
> -wake = test_and_clear_bit(_VPF_down, >pause_flags);
> +#ifdef CONFIG_X86
> +if ( pv_shim )
> +rc = continue_hypercall_on_cpu(0, pv_shim_cpu_up, v);
> +#endif
> +if ( !rc )
> +{
> +if ( !v->is_initialised )
> +rc = -EINVAL;
> +else
> +wake = test_and_clear_bit(_VPF_down, >pause_flags);
> +}

Hm, I'm not sure why this is any different from the current code,
continue_hypercall_on_cpu will schedule pv_shim_cpu_up to be called on
CPU0, but it won't wait for it to execute, so you are clearing the
pause_flags bit without having any guarantee that the physical CPU is
actually up?

The

Re: [Xen-devel] [PATCH] MAINTAINERS: Add DornerWorks maintainers email

2019-10-21 Thread George Dunlap

On 8/30/19 10:28 AM, Wei Liu wrote:
> On Fri, Aug 23, 2019 at 10:08:55AM -0400, Jeff Kubascik wrote:
>> We would like to have a common maintainers email address for DornerWorks
>> maintained code, which currently is the ARINC653 scheduler. This will
>> enable us to better monitor and respond to the Xen community. This patch
>> adds a maintainer line with the DornerWorks maintainers email address.
>> ---
>>  MAINTAINERS | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 77413e0d9e..3cce253931 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -168,6 +168,7 @@ F:   xen/common/argo.c
>>  ARINC653 SCHEDULER
>>  M:  Josh Whitehead 
>>  M:  Robert VanVossen 
>> +M:  DornerWorks Xen-Devel 
> 
> The correct symbol here is L. 
> 
> L: Mailing list that is relevant to this area

But this isn't exactly a mailing list, is it?  The 'L:' tag is normally
for things like the Linux Arm mailing list, the Linux Net mailing list,
and so on -- *public* lists where discussions about that subsystem happen.

This isn't a public list where discussion happens.  At the moment, in
fact, it looks like it might be a *single email account*, to which
several people have access; at best it would be an alias that would go
to a number of interested parties.  That seems closer to 'R:'.

I admit this is getting into the minutia of technicalities here. :-)

 -George

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

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

On 21.10.19 13:06, Ian Jackson wrote:

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 142973: regressions -
FAIL"):

On 21.10.19 10:23, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs.
142750

Roger, I believe you have looked into that one?

I guess the conversation via IRC with Ian regarding the race between
blkback and OSStest was related to the issue?

I think this failure is something else.

What happens here is this:

2019-10-21 02:58:32 Z executing ssh ... -v root@172.16.145.205 date
[bounch of output from ssh]
status (timed out) at Osstest/TestSupport.pm line 550.
2019-10-21 02:58:42 Z exit status 4

172.16.145.205 is the guest here. Ie, `ssh date guest' took longer
than 10s.

We can see that the guest networking is working soon after the
migration because we got most of the way through the ssh protocol
exchange. On the previous repetition the next message from ssh was
debug1: SSH2_MSG_SERVICE_ACCEPT received

Looking at

http://logs.test-lab.xenproject.org/osstest/logs/142973/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
which is, I think, the log of the "new" instance of guest, after
migration, there are messages about killing various services. Eg
[1918064738.820550] systemd[1]: systemd-udevd.service: Main process
exited, code=killed, status=6/ABRT
They don't seem to be normal. For example:

http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
is the previous xen-unstable flight and it doesn't have them. I
looked in

http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest.log.gz
too and that has some alarming messages from the kernel like
[ 686.692660] rcu_sched kthread starved for 1918092123128 jiffies!
g18446744073709551359 c18446744073709551358 f0x0 RCU_GP_WAIT_FQS(3)
->state=0x0 ->cpu=0
and accompanying stack traces. But the test passed there. I think
that is probably something else ?

This seems to be the issue Sergey is seeing, too.

ABRT suggests guest memory corruption.

Sure? I'd think of an abort() call.

If this is the case, could you, Ian, please add the workaround you were
thinking of to OSStest (unconditional by now, maybe make it condtitional
later)?

I can add the block race workaround but I don't think it will help
with migration anyway. The case where things go wrong is destroy.

Okay, no hurry then.

Juergen

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

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

On Mon, Oct 21, 2019 at 12:06:32PM +0100, Ian Jackson wrote:
> Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 142973: regressions 
> - FAIL"):
> > On 21.10.19 10:23, osstest service owner wrote:
> > > flight 142973 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/142973/
> > > 
> > > Regressions :-(
> > > 
> > > Tests which did not succeed and are blocking,
> > > including tests which could not be run:
> > >   test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10   fail REGR. vs. 
> > > 142750
> > 
> > Roger, I believe you have looked into that one?
> > 
> > I guess the conversation via IRC with Ian regarding the race between
> > blkback and OSStest was related to the issue?
> 
> I think this failure is something else.

I agree.

> What happens here is this:
> 
> 2019-10-21 02:58:32 Z executing ssh ... -v root@172.16.145.205 date 
> [bounch of output from ssh]
> status (timed out) at Osstest/TestSupport.pm line 550.
> 2019-10-21 02:58:42 Z exit status 4
> 
> 172.16.145.205 is the guest here.  Ie, `ssh date guest' took longer
> than 10s.
> 
> We can see that the guest networking is working soon after the
> migration because we got most of the way through the ssh protocol
> exchange.  On the previous repetition the next message from ssh was
>debug1: SSH2_MSG_SERVICE_ACCEPT received
> 
> Looking at
>   
> http://logs.test-lab.xenproject.org/osstest/logs/142973/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
> which is, I think, the log of the "new" instance of guest, after
> migration, there are messages about killing various services.  Eg
>   [1918064738.820550] systemd[1]: systemd-udevd.service: Main process
>   exited, code=killed, status=6/ABRT
> They don't seem to be normal.  For example:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
> is the previous xen-unstable flight and it doesn't have them.  I
> looked in
>   
> http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest.log.gz
> too and that has some alarming messages from the kernel like
>  [  686.692660] rcu_sched kthread starved for 1918092123128 jiffies!
>  g18446744073709551359 c18446744073709551358 f0x0 RCU_GP_WAIT_FQS(3)
>  ->state=0x0 ->cpu=0
> and accompanying stack traces.  But the test passed there.  I think
> that is probably something else ?

AFAICT there's corruption when migrating and also some kind of
lockup, not sure if those are related or not yet.

> ABRT suggests guest memory corruption.
> 
> > If this is the case, could you, Ian, please add the workaround you were
> > thinking of to OSStest (unconditional by now, maybe make it condtitional
> > later)?
> 
> I can add the block race workaround but I don't think it will help
> with migration anyway.  The case where things go wrong is destroy.
> 
> Roger, am I right that a normal guest shutdown is race-free ?  I think
> we tear things down in a slower manner and will therefore end up
> waiting for blkback ?  Or is that not true ?

It doesn't really matter whether shutdown or destroy is used, the
issue is that blkback switches to state 6 (Closed) before the disk is
closed, and hence there's no way for the toolstack to detect when the
disk has actually been released.

> 
> Maybe the right workaround is to disable the code in osstest which
> tries to clean up a previous failed run.  I think the kernel doesn't
> mind multiple blkfronts (or indeed multiple other tasks) using the
> same device at once.

Since the action when the disk is found to be in use is to try to
unmount it, maybe osstest should make sure the disk is actually
mounted first by parsing the output of mount? (or maybe there's a
better way to do it)

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] xen/typesafe: Force helpers to be always_inline

2019-10-21 Thread George Dunlap

On 10/7/19 10:25 AM, Jan Beulich wrote:
> On 04.10.2019 19:02, George Dunlap wrote:
>> On 10/2/19 9:11 AM, Jan Beulich wrote:
>>> On 01.10.2019 22:59, Andrew Cooper wrote:
 On 01/10/2019 09:38, Jan Beulich wrote:
> On 30.09.2019 21:16, Andrew Cooper wrote:
>> Clang in particular has a habit of out-of-lining these and creating 
>> multiple
>> local copies of _mfn() and mfn_x(), etc.  Override this behaviour.
> Is special casing the typesafe helpers then the right approach? The
> fundamental idea after all is to let the compiler decide. I certainly
> agree that not inlining such trivial functions despite the inline
> keyword looks far from optimal, but if there's such a general issue
> with clang, shouldn't we make "inline" expand to "always_inline"
> uniformly?

 Inline handing is a mess.

 We currently define inline to __inline__.  Undoing this results in build
 failures.

 Linux currently defines inline to always_inline and they are desperately
 trying to undo this (mis)behaviour.

 There are a few uses of always_inline for safety purposes (the
 speculative helpers).  Most uses of always_inline look to be workarounds
 for the size-of-asm bug/(mis)feature.

 In an ideal world, we wouldn't need it at all, but I definitely don't
 think that taking the Linux approach is a clever move.  We definitely
 have some static inlines which would better not being inline.
>>>
>>> IOW your suggested approach (at least for the foreseeable future) is to
>>> do what you do here and convert inline to always_inline as we see fit?
>>> If so, we should at least settle on some sufficiently firm criteria by
>>> which such a conversion would be justifiable.
>>>
>>> Seeing that this is primarily to help clang - did you consider
>>> introducing something like clang_inline, expanding to just inline for
>>> gcc, but always_inline for clang? This would at least provide a
>>> sufficiently easy way to undo this if a better clang-side approach can
>>> be found down the road.
>>
>> What would be the point of this?  The only reason always_inline isn't
>> necessary for gcc (if I'm following the argument) is because it so far
>> has always inlined these functions.  If it stopped inlining them, we'd
>> need to change it to always_inline anyway; so why not just say so to
>> begin with?
> 
> The point of this would be to _avoid_ using always_inline as much as
> possible. We really shouldn't fight compiler decisions more than
> absolutely necessary. Hence also my request for sufficiently firm
> criteria when to switch in the first place. Or else would could, as
> mentioned as an option elsewhere, make inline expand to always_inline
> uniformly. (Or course, even always_inline isn't a guarantee for the
> compiler to actually inline a function.)

Every time I try to compose an answer to this paragraph, I end up
writing the paragraph you responded to.  Let me try something else.

"We really shouldn't fight compiler decisions more than absolutely
necessary."

Sure.  But in this particular case, it's been determined that we want to
fight the compiler decision.  The reason for wanting it to be inline
doesn't depend on whether it's clang or gcc; we want it to be inlined
all the time no matter what.  So why go through the effort of inventing
a new thing targeted at clang?

Let's do a cost-benefits analysis of always_inline vs clang_inline.

For each future gcc version, either it will choose to inline this
function with the `inline` key word or not.

1. Use always_inline
 1a. gcc would have done inline anyway.  No cost.
 1b. gcc would not have inlined it.  always_inline takes effect and
there's no cost.
2. Use clang_inline
 2a. gcc would have done inline anyway.  No cost.
 2b. gcc doesn't inline it.  We have random bugs, a discussion, then a
patch to s/clang_inline/always_inline/g;.

IOW, I only see a cost here to 2, and no benefit.

"Hence also my request for sufficiently firm criteria when to switch in
the first place."

Having criteria describing exactly when we want to specify always_inline
would be nice.  But it doesn't change the fact that in this case, we
want it to be always inlined.

"Or else would could, as mentioned as an option elsewhere, make inline
expand to always_inline uniformly."

But you just said we don't want to fight compiler decisions more than
absolutely necessary.

 -George

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

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

Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 142973: regressions - 
FAIL"):
> On 21.10.19 10:23, osstest service owner wrote:
> > flight 142973 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/142973/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >   test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10   fail REGR. vs. 
> > 142750
> 
> Roger, I believe you have looked into that one?
> 
> I guess the conversation via IRC with Ian regarding the race between
> blkback and OSStest was related to the issue?

I think this failure is something else.

What happens here is this:

2019-10-21 02:58:32 Z executing ssh ... -v root@172.16.145.205 date 
[bounch of output from ssh]
status (timed out) at Osstest/TestSupport.pm line 550.
2019-10-21 02:58:42 Z exit status 4

172.16.145.205 is the guest here.  Ie, `ssh date guest' took longer
than 10s.

We can see that the guest networking is working soon after the
migration because we got most of the way through the ssh protocol
exchange.  On the previous repetition the next message from ssh was
   debug1: SSH2_MSG_SERVICE_ACCEPT received

Looking at

http://logs.test-lab.xenproject.org/osstest/logs/142973/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
which is, I think, the log of the "new" instance of guest, after
migration, there are messages about killing various services.  Eg
  [1918064738.820550] systemd[1]: systemd-udevd.service: Main process
  exited, code=killed, status=6/ABRT
They don't seem to be normal.  For example:

http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest--incoming.log
is the previous xen-unstable flight and it doesn't have them.  I
looked in

http://logs.test-lab.xenproject.org/osstest/logs/142865/test-amd64-amd64-xl-pvshim/rimava1---var-log-xen-console-guest-debian.guest.osstest.log.gz
too and that has some alarming messages from the kernel like
 [  686.692660] rcu_sched kthread starved for 1918092123128 jiffies!
 g18446744073709551359 c18446744073709551358 f0x0 RCU_GP_WAIT_FQS(3)
 ->state=0x0 ->cpu=0
and accompanying stack traces.  But the test passed there.  I think
that is probably something else ?

ABRT suggests guest memory corruption.

> If this is the case, could you, Ian, please add the workaround you were
> thinking of to OSStest (unconditional by now, maybe make it condtitional
> later)?

I can add the block race workaround but I don't think it will help
with migration anyway.  The case where things go wrong is destroy.

Roger, am I right that a normal guest shutdown is race-free ?  I think
we tear things down in a slower manner and will therefore end up
waiting for blkback ?  Or is that not true ?

Maybe the right workaround is to disable the code in osstest which
tries to clean up a previous failed run.  I think the kernel doesn't
mind multiple blkfronts (or indeed multiple other tasks) using the
same device at once.

Ian.

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

Re: [Xen-devel] PV-shim 4.13 assertion failures during vcpu_wake()


On 21.10.19 11:51, Sergey Dyasli wrote:

Hello,

While testing pv-shim from a snapshot of staging 4.13 branch (with core-
scheduling patches applied), some sort of scheduling issues were uncovered
which usually leads to a guest lockup (sometimes with soft lockup messages
from Linux kernel).

This happens more frequently on SandyBridge CPUs. After enabling
CONFIG_DEBUG in pv-shim, the following assertions failed:

Null scheduler:

 Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' 
failed at ...are/xen-dir/xen-root/xen/include/xen/sched-if.h:278
 (full crash log: https://paste.debian.net/1108861/ )

Credit1 scheduler:

 Assertion 'cpumask_cycle(cpu, unit->cpu_hard_affinity) == cpu' failed at 
sched_credit.c:383
 (full crash log: https://paste.debian.net/1108862/ )

I'm currently investigation those, but would appreciate any help or
suggestions.


Hmm, I think that pv_shim_cpu_up() shouldn't do the vcpu_wake(), but the
caller.

Does the attached patch help?


Juergen
>From 068ea0419d1a67e967b9431ed11e24b731cd357f Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Mon, 21 Oct 2019 12:28:33 +0200
Subject: [PATCH] xen/shim: fix pv-shim cpu up/down

Calling vcpu_wake() from pv_shim_cpu_up() is wrong as it is not yet
sure that the correct scheduler has taken over the cpu. Doing the
call after continue_hypercall_on_cpu() is correct, so let
pv_shim_cpu_up() just online the cpu.

Adapt pv_shim_cpu_down() to be symmetric, even if that is not
required for correctness.

Reported-by: Sergey Dyasli 
Signed-off-by: Juergen Gross 
---
 xen/arch/x86/pv/shim.c | 16 
 xen/common/domain.c| 31 ++-
 2 files changed, 18 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/pv/shim.c b/xen/arch/x86/pv/shim.c
index 5edbcd9ac5..bc6a2f3eb9 100644
--- a/xen/arch/x86/pv/shim.c
+++ b/xen/arch/x86/pv/shim.c
@@ -815,16 +815,11 @@ long pv_shim_cpu_up(void *data)
 {
 struct vcpu *v = data;
 struct domain *d = v->domain;
-bool wake;
 
 BUG_ON(smp_processor_id() != 0);
 
-domain_lock(d);
 if ( !v->is_initialised )
-{
 domain_unlock(d);
-return -EINVAL;
-}
 
 if ( !cpu_online(v->vcpu_id) )
 {
@@ -832,18 +827,12 @@ long pv_shim_cpu_up(void *data)
 
 if ( rc )
 {
-domain_unlock(d);
 gprintk(XENLOG_ERR, "Failed to bring up CPU#%u: %ld\n",
 v->vcpu_id, rc);
 return rc;
 }
 }
 
-wake = test_and_clear_bit(_VPF_down, >pause_flags);
-domain_unlock(d);
-if ( wake )
-vcpu_wake(v);
-
 return 0;
 }
 
@@ -852,11 +841,6 @@ long pv_shim_cpu_down(void *data)
 struct vcpu *v = data;
 long rc;
 
-BUG_ON(smp_processor_id() != 0);
-
-if ( !test_and_set_bit(_VPF_down, >pause_flags) )
-vcpu_sleep_sync(v);
-
 if ( cpu_online(v->vcpu_id) )
 {
 rc = cpu_down_helper((void *)(unsigned long)v->vcpu_id);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 9c7360ed2a..e83657e310 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1428,19 +1428,21 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 break;
 
 case VCPUOP_up:
-#ifdef CONFIG_X86
-if ( pv_shim )
-rc = continue_hypercall_on_cpu(0, pv_shim_cpu_up, v);
-else
-#endif
 {
 bool wake = false;
 
 domain_lock(d);
-if ( !v->is_initialised )
-rc = -EINVAL;
-else
-wake = test_and_clear_bit(_VPF_down, >pause_flags);
+#ifdef CONFIG_X86
+if ( pv_shim )
+rc = continue_hypercall_on_cpu(0, pv_shim_cpu_up, v);
+#endif
+if ( !rc )
+{
+if ( !v->is_initialised )
+rc = -EINVAL;
+else
+wake = test_and_clear_bit(_VPF_down, >pause_flags);
+}
 domain_unlock(d);
 if ( wake )
 vcpu_wake(v);
@@ -1465,14 +1467,17 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, XEN_GUEST_HANDLE_PARAM(void) arg)
 rc = 0;
 v = d->vcpu[vcpuid];
 
+#ifdef CONFIG_X86
+BUG_ON(pv_shim && smp_processor_id() != 0);
+#endif
+
+if ( !test_and_set_bit(_VPF_down, >pause_flags) )
+vcpu_sleep_nosync(v);
+
 #ifdef CONFIG_X86
 if ( pv_shim )
 rc = continue_hypercall_on_cpu(0, pv_shim_cpu_down, v);
-else
 #endif
-if ( !test_and_set_bit(_VPF_down, >pause_flags) )
-vcpu_sleep_nosync(v);
-
 break;
 
 case VCPUOP_is_up:
-- 
2.16.4

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

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Oct 21, 2019 at 12:22:25PM +0200, Roger Pau Monné wrote:
> On Mon, Sep 30, 2019 at 04:00:43PM +0100, Wei Liu wrote:
> > We use the same code structure as we die for Xen.
> > 
> > As starters, detect Hyper-V in probe routine. More complex
> > functionalities will be added later.
> > 
> > Signed-off-by: Wei Liu 
> > ---
> >  xen/arch/x86/Kconfig   |  9 
> >  xen/arch/x86/guest/Makefile|  1 +
> >  xen/arch/x86/guest/hyperv/Makefile |  1 +
> >  xen/arch/x86/guest/hyperv/hyperv.c | 69 ++
> >  xen/arch/x86/guest/hypervisor.c|  5 +++
> >  xen/include/asm-x86/guest.h|  1 +
> >  xen/include/asm-x86/guest/hyperv.h | 45 +++
> >  7 files changed, 131 insertions(+)
> >  create mode 100644 xen/arch/x86/guest/hyperv/Makefile
> >  create mode 100644 xen/arch/x86/guest/hyperv/hyperv.c
> >  create mode 100644 xen/include/asm-x86/guest/hyperv.h
> > 
> > diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> > index 584bdc1bb8..c5a93babfe 100644
> > --- a/xen/arch/x86/Kconfig
> > +++ b/xen/arch/x86/Kconfig
> > @@ -163,6 +163,15 @@ endchoice
> >  config GUEST
> > bool
> >  
> > +config HYPERV_GUEST
> > +   def_bool n
> > +   select GUEST
> > +   prompt "Hyper-V Guest"
> > +   ---help---
> > + Support for Xen detecting when it is running under Hyper-V.
> > +
> > + If unsure, say N.
> > +
> >  config XEN_GUEST
> > def_bool n
> > select GUEST
> > diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
> > index f63d64bbee..f164196772 100644
> > --- a/xen/arch/x86/guest/Makefile
> > +++ b/xen/arch/x86/guest/Makefile
> > @@ -1,3 +1,4 @@
> >  obj-y += hypervisor.o
> >  
> > +subdir-$(CONFIG_HYPERV_GUEST) += hyperv
> >  subdir-$(CONFIG_XEN_GUEST) += xen
> > diff --git a/xen/arch/x86/guest/hyperv/Makefile 
> > b/xen/arch/x86/guest/hyperv/Makefile
> > new file mode 100644
> > index 00..68170109a9
> > --- /dev/null
> > +++ b/xen/arch/x86/guest/hyperv/Makefile
> > @@ -0,0 +1 @@
> > +obj-y += hyperv.o
> > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
> > b/xen/arch/x86/guest/hyperv/hyperv.c
> > new file mode 100644
> > index 00..4494b87fe8
> > --- /dev/null
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -0,0 +1,69 @@
> > +/**
> > + * arch/x86/guest/hyperv/hyperv.c
> > + *
> > + * Support for detecting and running under Hyper-V.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; If not, see .
> > + *
> > + * Copyright (c) 2019 Microsoft.
> > + */
> > +#include 
> > +
> > +#include 
> > +
> > +bool __init hyperv_probe(void)
> > +{
> > +uint32_t eax, ebx, ecx, edx;
> > +bool hyperv_guest = false;
> 
> I don't think you need this local variable, you can return true in if
> the if condition matches, and false otherwise.
> 
> > +
> > +cpuid(0x4000, , , , );
> > +if ( (ebx == 0x7263694d) && /* "Micr" */
> > + (ecx == 0x666f736f) && /* "osof" */
> > + (edx == 0x76482074) )  /* "t Hv" */
> 
> I guess there are no HyperV headers to import that have those values
> defined?
> 
> Alternatively you could do something like the following I think:
> 
> static const char hyperv_sig[] __initconst = "Microsoft Hv";
> 
> bool __init hyperv_probe(void)
> {
> uint32_t eax, sig[3];
> 
> cpuid(0x4000, , [0], [1], [2]);
> if ( !strncmp(hyperv_sig, sig, strncmp(hyperv_sig) )

Urg, I've made a mistake here, the line should be:

!strncmp(hyperv_sig, sig, strlen(hyperv_sig))

And you can likely declare hyperv_sig inside the probe function also.

Roger.

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

Re: [Xen-devel] [PATCH for-next v2 9/9] x86: introduce CONFIG_HYPERV and detection code

On Mon, Sep 30, 2019 at 04:00:43PM +0100, Wei Liu wrote:
> We use the same code structure as we die for Xen.
> 
> As starters, detect Hyper-V in probe routine. More complex
> functionalities will be added later.
> 
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/Kconfig   |  9 
>  xen/arch/x86/guest/Makefile|  1 +
>  xen/arch/x86/guest/hyperv/Makefile |  1 +
>  xen/arch/x86/guest/hyperv/hyperv.c | 69 ++
>  xen/arch/x86/guest/hypervisor.c|  5 +++
>  xen/include/asm-x86/guest.h|  1 +
>  xen/include/asm-x86/guest/hyperv.h | 45 +++
>  7 files changed, 131 insertions(+)
>  create mode 100644 xen/arch/x86/guest/hyperv/Makefile
>  create mode 100644 xen/arch/x86/guest/hyperv/hyperv.c
>  create mode 100644 xen/include/asm-x86/guest/hyperv.h
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 584bdc1bb8..c5a93babfe 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -163,6 +163,15 @@ endchoice
>  config GUEST
>   bool
>  
> +config HYPERV_GUEST
> + def_bool n
> + select GUEST
> + prompt "Hyper-V Guest"
> + ---help---
> +   Support for Xen detecting when it is running under Hyper-V.
> +
> +   If unsure, say N.
> +
>  config XEN_GUEST
>   def_bool n
>   select GUEST
> diff --git a/xen/arch/x86/guest/Makefile b/xen/arch/x86/guest/Makefile
> index f63d64bbee..f164196772 100644
> --- a/xen/arch/x86/guest/Makefile
> +++ b/xen/arch/x86/guest/Makefile
> @@ -1,3 +1,4 @@
>  obj-y += hypervisor.o
>  
> +subdir-$(CONFIG_HYPERV_GUEST) += hyperv
>  subdir-$(CONFIG_XEN_GUEST) += xen
> diff --git a/xen/arch/x86/guest/hyperv/Makefile 
> b/xen/arch/x86/guest/hyperv/Makefile
> new file mode 100644
> index 00..68170109a9
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -0,0 +1 @@
> +obj-y += hyperv.o
> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
> b/xen/arch/x86/guest/hyperv/hyperv.c
> new file mode 100644
> index 00..4494b87fe8
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -0,0 +1,69 @@
> +/**
> + * arch/x86/guest/hyperv/hyperv.c
> + *
> + * Support for detecting and running under Hyper-V.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; If not, see .
> + *
> + * Copyright (c) 2019 Microsoft.
> + */
> +#include 
> +
> +#include 
> +
> +bool __init hyperv_probe(void)
> +{
> +uint32_t eax, ebx, ecx, edx;
> +bool hyperv_guest = false;

I don't think you need this local variable, you can return true in if
the if condition matches, and false otherwise.

> +
> +cpuid(0x4000, , , , );
> +if ( (ebx == 0x7263694d) && /* "Micr" */
> + (ecx == 0x666f736f) && /* "osof" */
> + (edx == 0x76482074) )  /* "t Hv" */

I guess there are no HyperV headers to import that have those values
defined?

Alternatively you could do something like the following I think:

static const char hyperv_sig[] __initconst = "Microsoft Hv";

bool __init hyperv_probe(void)
{
uint32_t eax, sig[3];

cpuid(0x4000, , [0], [1], [2]);
if ( !strncmp(hyperv_sig, sig, strncmp(hyperv_sig) )
return true;

return false;
}

> +hyperv_guest = true;
> +
> +return hyperv_guest;
> +}
> +
> +void __init hyperv_setup(void)
> +{
> +/* Nothing yet */
> +}
> +
> +void hyperv_ap_setup(void)
> +{
> +/* Nothing yet */
> +}
> +
> +void hyperv_resume(void)
> +{
> +/* Nothing yet */
> +}

There's no need to introduce such dummy functions, just leaving the
pointers as NULL should work fine, and the functions can be introduced
when there's logic in them.

> +
> +struct hypervisor_ops hyperv_hypervisor_ops = {
> +.name = "Hyper-V",
> +.setup = hyperv_setup,
> +.ap_setup = hyperv_ap_setup,
> +.resume = hyperv_resume,
> +};
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
> index 8161b26c5a..87a195e888 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -40,6 +40,11 @@ bool hypervisor_probe(void)
>  hops = _hypervisor_ops;
>  #endif
>  
> +#ifdef CONFIG_HYPERV_GUEST
> +if

Re: [Xen-devel] [PATCH for-next v2 8/9] x86: be more verbose when running on a hypervisor

On Mon, Sep 30, 2019 at 04:00:42PM +0100, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/guest/hypervisor.c| 5 +
>  xen/arch/x86/setup.c   | 6 +-
>  xen/include/asm-x86/guest/hypervisor.h | 2 ++
>  3 files changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
> index 30453b6a7a..8161b26c5a 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -43,6 +43,11 @@ bool hypervisor_probe(void)
>  return !!hops;
>  }
>  
> +const char *hypervisor_name(void)
> +{

I would maybe add ASSERT(hops);

> +return hops->name;
> +}
> +
>  void hypervisor_setup(void)
>  {
>  if ( hops && hops->setup )
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 0ee11b15a6..cf5a7b8e1e 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -689,6 +689,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  int i, j, e820_warn = 0, bytes = 0;
>  bool acpi_boot_table_init_done = false, relocated = false;
>  int ret;
> +bool running_on_hypervisor;
>  struct ns16550_defaults ns16550 = {
>  .data_bits = 8,
>  .parity= 'n',
> @@ -763,7 +764,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>   * allocing any xenheap structures wanted in lower memory. */
>  kexec_early_calculations();
>  
> -hypervisor_probe();
> +running_on_hypervisor = hypervisor_probe();
>  
>  parse_video_info();
>  
> @@ -789,6 +790,9 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  
>  printk("Xen image load base address: %#lx\n", xen_phys_start);
>  
> +if ( running_on_hypervisor )
> +printk("Running on %s\n", hypervisor_name());
> +
>  #ifdef CONFIG_VIDEO
>  printk("Video information:\n");
>  
> diff --git a/xen/include/asm-x86/guest/hypervisor.h 
> b/xen/include/asm-x86/guest/hypervisor.h
> index 38344e2e89..a7d75bf9cf 100644
> --- a/xen/include/asm-x86/guest/hypervisor.h
> +++ b/xen/include/asm-x86/guest/hypervisor.h
> @@ -36,6 +36,7 @@ bool hypervisor_probe(void);
>  void hypervisor_setup(void);
>  void hypervisor_ap_setup(void);
>  void hypervisor_resume(void);
> +const char *hypervisor_name(void);
>  
>  #else
>  
> @@ -45,6 +46,7 @@ static inline bool hypervisor_probe(void) { return false; }
>  static inline void hypervisor_setup(void) {}
>  static inline void hypervisor_ap_setup(void) {}
>  static inline void hypervisor_resume(void) {}
> +static inline char *hypervisor_name(void) { return NULL; }

I think you want an ASSERT_UNREACHABLE here, since hypervisor_name
shouldn't be called unless Xen has detected that's running as a guest,
which can only happen if CONFIG_GUEST is selected.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH for-next v2 7/9] x86: switch xen implementation to use hypervisor framework

On Mon, Sep 30, 2019 at 04:00:41PM +0100, Wei Liu wrote:
> Take the chance to change probe_hypervisor to hypervisor_probe.

The implementation LGTM.

> 
> Signed-off-by: Wei Liu 
> ---
>  xen/arch/x86/guest/hypervisor.c   | 31 +--
>  xen/arch/x86/guest/xen/pvh-boot.c |  2 +-
>  xen/arch/x86/guest/xen/xen.c  | 26 ++
>  xen/arch/x86/setup.c  |  2 +-
>  xen/include/asm-x86/guest/xen.h   |  6 --
>  5 files changed, 49 insertions(+), 18 deletions(-)
> 
> diff --git a/xen/arch/x86/guest/hypervisor.c b/xen/arch/x86/guest/hypervisor.c
> index 89b9ae4de0..30453b6a7a 100644
> --- a/xen/arch/x86/guest/hypervisor.c
> +++ b/xen/arch/x86/guest/hypervisor.c
> @@ -22,7 +22,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  
>  static struct hypervisor_ops *hops __read_mostly;
>  
> @@ -31,7 +31,34 @@ bool hypervisor_probe(void)
>  if ( hops )
>  return true;
>  
> -return false;
> +/* Too early to use cpu_has_hypervisor */
> +if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
> +return false;
> +
> +#ifdef CONFIG_XEN_GUEST
> +if ( xen_probe() )
> +hops = _hypervisor_ops;
> +#endif

I think you likely want something like:

if ( xen_probe() )
{
hops = _hypervisor_ops;
return true;
}
if ( hyperv_probe() )
{

return true;
}

return false;

In order to return after a successful probe, or else you lose cycles
probing for hypervisors when a match has been found, and also in the
Xen case you risk detecting the HyperV support in Xen and thus using
that instead of the Xen one.

Long term if we gain more guests support I would likely want to see
hypervisor_ops turning into an array and gaining a probe function so
that this can be done in a loop instead of having this function.

> +
> +return !!hops;
> +}
> +
> +void hypervisor_setup(void)
> +{
> +if ( hops && hops->setup )
> +hops->setup();
> +}
> +
> +void hypervisor_ap_setup(void)
> +{
> +if ( hops && hops->ap_setup )
> +hops->ap_setup();
> +}
> +
> +void hypervisor_resume(void)
> +{
> +if ( hops && hops->resume )
> +hops->resume();
>  }
>  
>  /*
> diff --git a/xen/arch/x86/guest/xen/pvh-boot.c 
> b/xen/arch/x86/guest/xen/pvh-boot.c
> index ca8e156f7d..498625eae0 100644
> --- a/xen/arch/x86/guest/xen/pvh-boot.c
> +++ b/xen/arch/x86/guest/xen/pvh-boot.c
> @@ -103,7 +103,7 @@ void __init pvh_init(multiboot_info_t **mbi, module_t 
> **mod)
>  {
>  convert_pvh_info(mbi, mod);
>  
> -probe_hypervisor();
> +hypervisor_probe();
>  ASSERT(xen_guest);
>  
>  get_memory_map();
> diff --git a/xen/arch/x86/guest/xen/xen.c b/xen/arch/x86/guest/xen/xen.c
> index 9895025d02..a9d321e5eb 100644
> --- a/xen/arch/x86/guest/xen/xen.c
> +++ b/xen/arch/x86/guest/xen/xen.c
> @@ -67,24 +67,19 @@ static void __init find_xen_leaves(void)
>  }
>  }
>  
> -void __init probe_hypervisor(void)
> +bool __init xen_probe(void)
>  {
> -if ( xen_guest )
> -return;
> -
> -/* Too early to use cpu_has_hypervisor */
> -if ( !(cpuid_ecx(1) & cpufeat_mask(X86_FEATURE_HYPERVISOR)) )
> -return;
> -
>  find_xen_leaves();
>  
>  if ( !xen_cpuid_base )
> -return;
> +return false;
>  
>  /* Fill the hypercall page. */
>  wrmsrl(cpuid_ebx(xen_cpuid_base + 2), __pa(hypercall_page));
>  
>  xen_guest = true;
> +
> +return true;
>  }
>  
>  static void map_shared_info(void)
> @@ -249,7 +244,7 @@ static void init_evtchn(void)
>  }
>  }
>  
> -void __init hypervisor_setup(void)
> +void __init xen_setup(void)
>  {
>  init_memmap();
>  
> @@ -277,7 +272,7 @@ void __init hypervisor_setup(void)
>  init_evtchn();
>  }
>  
> -void hypervisor_ap_setup(void)
> +void xen_ap_setup(void)
>  {
>  set_vcpu_id();
>  map_vcpuinfo();
> @@ -307,7 +302,7 @@ static void ap_resume(void *unused)
>  init_evtchn();
>  }
>  
> -void hypervisor_resume(void)
> +void xen_resume(void)

I think xen_{setup/ap_setup/resume} can be made static now?

Thanks, Roger.

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

[Xen-devel] PV-shim 4.13 assertion failures during vcpu_wake()

2019-10-21 Thread Sergey Dyasli

Hello,

While testing pv-shim from a snapshot of staging 4.13 branch (with core-
scheduling patches applied), some sort of scheduling issues were uncovered
which usually leads to a guest lockup (sometimes with soft lockup messages
from Linux kernel).

This happens more frequently on SandyBridge CPUs. After enabling
CONFIG_DEBUG in pv-shim, the following assertions failed:

Null scheduler:

Assertion 'lock == get_sched_res(i->res->master_cpu)->schedule_lock' failed 
at ...are/xen-dir/xen-root/xen/include/xen/sched-if.h:278
(full crash log: https://paste.debian.net/1108861/ )

Credit1 scheduler:

Assertion 'cpumask_cycle(cpu, unit->cpu_hard_affinity) == cpu' failed at 
sched_credit.c:383
(full crash log: https://paste.debian.net/1108862/ )

I'm currently investigation those, but would appreciate any help or
suggestions.

Thanks,
Sergey

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

[Xen-devel] [libvirt test] 142990: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 build-arm64   4 host-install(4)broken REGR. vs. 142840
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 142840
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 142840
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 142840

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  f31bdc7ced695becdd6a090b23ab3e4f57b3a323
baseline version:
 libvirt  b83884d1a0f422e8147a7d1a39ccec0e0cca3285

Last test of basis   142840  2019-10-17 15:43:16 Z3 days
Failing since142862  2019-10-18 07:07:12 Z3 days4 attempts
Testing same since   142990  2019-10-21 04:19:44 Z0 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Daniel Henrique Barboza 
  Daniel P. Berrangé 
  Julio Faracco 
  Ján Tomko 
  Malina Salina 
  Michal Privoznik 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd 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

Re: [Xen-devel] [PATCH for-next v2 6/9] x86: rename hypervisor_{alloc, free}_unused_page

On Mon, Sep 30, 2019 at 04:00:40PM +0100, Wei Liu wrote:
> They are used in Xen code only.
> 
> No functional change.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Roger Pau Monné 

Thanks.

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

Re: [Xen-devel] [PATCH for-next v2 4/9] x86: include xen/lib.h in guest/hypercall.h

On Mon, Sep 30, 2019 at 04:00:38PM +0100, Wei Liu wrote:
> We need ASSERT_UNREACHABLE.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Roger Pau Monné 

Thanks.

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

Re: [Xen-devel] [PATCH for-next v2 0/9] Port Xen to Hyper-V

On Mon, Sep 30, 2019 at 04:00:34PM +0100, Wei Liu wrote:
> Hi all
> 
> This is version 2 of the patch series.
> 
> This is the very first stage for porting Xen to run on Hyper-V with all the
> goodies Hyper-V has to offer.  With this series, Xen can successfully detect
> Hyper-V and prints out a message.  I would like to first get the code 
> structure
> and kconfig options agreed upon.
> 
> There are two major areas to be worked on:
>   * Make Dom0 able to use Hyper-V's synthetic devices.
>   * Make Xen use of the synthetic timer, reference TSC and enlightenment VMCS
> and other interfaces.
> 
> They aren't trivial, and time can be scarce on my side, so I intend to post
> patches piece meal when they are ready.
> 
> Questions and comments are welcome.
> 
> Thanks,
> Wei.
> 
> ---
> Changes in v2:
> 1. Introduce and use a hypervisor framework
> 2. Keep memmap infra under Xen for now

Ping?

Can I get an high level agreement on the code structure such that I can
continue building on top of this series?

Wei.

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

Re: [Xen-devel] [PATCH v2 02/20] piix4: Add the Reset Control Register

2019-10-21 Thread Philippe Mathieu-Daudé


On 10/21/19 3:25 AM, Li Qiang wrote:



Philippe Mathieu-Daudé mailto:phi...@redhat.com>> 于 
2019年10月18日周五 下午9:50写道：


From: Hervé Poussineau mailto:hpous...@reactos.org>>

The RCR I/O port (0xcf9) is used to generate a hard reset or a soft
reset.

Acked-by: Michael S. Tsirkin mailto:m...@redhat.com>>
Acked-by: Paolo Bonzini mailto:pbonz...@redhat.com>>
Signed-off-by: Hervé Poussineau mailto:hpous...@reactos.org>>
Message-Id: <20171216090228.28505-7-hpous...@reactos.org
>
Reviewed-by: Aleksandar Markovic mailto:amarko...@wavecomp.com>>
[PMD: rebased, updated includes]
Signed-off-by: Philippe Mathieu-Daudé mailto:phi...@redhat.com>>
---
  hw/isa/piix4.c | 49 ++---
  1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/hw/isa/piix4.c b/hw/isa/piix4.c
index 890d999abf..d0b18e0586 100644
--- a/hw/isa/piix4.c
+++ b/hw/isa/piix4.c
@@ -2,6 +2,7 @@
   * QEMU PIIX4 PCI Bridge Emulation
   *
   * Copyright (c) 2006 Fabrice Bellard
+ * Copyright (c) 2018 Hervé Poussineau
   *
   * Permission is hereby granted, free of charge, to any person
obtaining a copy
   * of this software and associated documentation files (the
"Software"), to deal
@@ -28,11 +29,17 @@
  #include "hw/isa/isa.h"
  #include "hw/sysbus.h"
  #include "migration/vmstate.h"
+#include "sysemu/reset.h"
+#include "sysemu/runstate.h"

  PCIDevice *piix4_dev;

  typedef struct PIIX4State {
      PCIDevice dev;
+
+    /* Reset Control Register */
+    MemoryRegion rcr_mem;
+    uint8_t rcr;
  } PIIX4State;

  #define TYPE_PIIX4_PCI_DEVICE "PIIX4"
@@ -87,15 +94,51 @@ static const VMStateDescription vmstate_piix4 = {
      }
  };

+static void piix4_rcr_write(void *opaque, hwaddr addr, uint64_t val,
+                            unsigned int len)
+{
+    PIIX4State *s = opaque;
+
+    if (val & 4) {
+        qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+        return;
+    }
+
+    s->rcr = val & 2; /* keep System Reset type only */
+}
+
+static uint64_t piix4_rcr_read(void *opaque, hwaddr addr, unsigned
int len)
+{
+    PIIX4State *s = opaque;
+
+    return s->rcr;
+}
+
+static const MemoryRegionOps piix4_rcr_ops = {
+    .read = piix4_rcr_read,
+    .write = piix4_rcr_write,
+    .endianness = DEVICE_LITTLE_ENDIAN,
+    .impl = {
+        .min_access_size = 1,
+        .max_access_size = 1,
+    },
+};
+
  static void piix4_realize(PCIDevice *dev, Error **errp)
  {
-    PIIX4State *d = PIIX4_PCI_DEVICE(dev);
+    PIIX4State *s = PIIX4_PCI_DEVICE(dev);

-    if (!isa_bus_new(DEVICE(d), pci_address_space(dev),
+    if (!isa_bus_new(DEVICE(dev), pci_address_space(dev),
                       pci_address_space_io(dev), errp)) {
          return;
      }
-    piix4_dev = >dev;
+
+    memory_region_init_io(>rcr_mem, OBJECT(dev), _rcr_ops, s,
+                          "reset-control", 1);
+    memory_region_add_subregion_overlap(pci_address_space_io(dev),
0xcf9,



Can we use 'RCR_IOPORT' instead of constant value here? Also don't see 
this change

in later patches of this seirals.


Good idea, I missed this one :)


Anyway

Reviewed-by: Li Qiang mailto:liq...@gmail.com>>


Thanks!



Thanks,
Li Qiang

+                                        >rcr_mem, 1);
+
+    piix4_dev = dev;
  }

  int piix4_init(PCIBus *bus, ISABus **isa_bus, int devfn)
-- 
2.21.0





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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2bbbdeeea21113185912a6a3ec8cdcaf862d8568
baseline version:
 ovmf 0f28c513d392a807f7b4225964eba6e2b1c453a2

Last test of basis   142895  2019-10-19 00:10:54 Z2 days
Testing same since   142986  2019-10-21 01:09:56 Z0 days1 attempts


People who touched revisions under test:
  Ashish Singhal 

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
   0f28c513d3..2bbbdeeea2  2bbbdeeea21113185912a6a3ec8cdcaf862d8568 -> 
xen-tested-master

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

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


On 21.10.19 10:23, osstest service owner wrote:

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
  test-amd64-amd64-xl-pvshim   18 guest-localmigrate/x10   fail REGR. vs. 142750


Roger, I believe you have looked into that one?

I guess the conversation via IRC with Ian regarding the race between
blkback and OSStest was related to the issue?

If this is the case, could you, Ian, please add the workaround you were
thinking of to OSStest (unconditional by now, maybe make it condtitional
later)?


Juergen

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

[Xen-devel] [xen-unstable test] 142973: regressions - FAIL