[Xen-devel] [xen-4.5-testing test] 94448: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 94384 pass 
in 94448
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 94384 pass 
in 94448
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 94384

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 94384 like 93928
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93989
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
93989

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

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z5 days
Testing same since94030  2016-05-11 13:08:55 Z4 days7 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  159 days  266 attempts
Testing same since94464  2016-05-16 04:05:08 Z0 days1 attempts


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 053d95e7e5e37378f6b21fe19009423762be894f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  159 days  265 attempts
Testing same since94396  2016-05-15 10:13:22 Z0 days5 attempts


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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Meng Xu]

Hi Doug,

Do you happen to know if Xen has an existing mechanism to make
/dev/xen/xenbus as a default device for xenstored?

On Sun, May 15, 2016 at 11:30 PM, Dagaen Golomb  wrote:
>> > Hi All,
>> >
>> > I'm having an interesting issue. I am working on a project that
>> > requires me to share memory between dom0 and domUs. I have this
>> > successfully working using the grant table and the XenStore to
>> > communicate grefs.
>> >
>> > My issue is this. I have one domU running Ubuntu 12.04 with a
>> > default
>> > 3.8.x kernel that has no issue reading or writing from the XenStore.
>> > My work also requires some kernel modifications, and we have made
>> > these changes in the 4.1.0 kernel. In particular, we've only added a
>> > simple hypercall. This modified kernel is what dom0 is running, on
>> > top
>> > of Xen 4.7 rc1.
>> 
>>  Without reading the rest of the thread but seeing the kernel
>>  versions.
>>  Can you check how you're communicating to xenstore? Is it via
>>  /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give
>>  you
>>  deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer
>>  should
>>  prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>>  that default didn't land until Xen 4.7. Since you're on the right
>>  versions I expect you're using /dev/xen/xenbus but you never know.
>> >>>
>> >>> How do I know which is being used? /dev/xen/xenbus is there and so is
>> >>> process/xen/xenbus. Could this be a problem with header version
>> >>> mismatches or something similar? I'm using the xen/xenstore.h header
>> >>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>> >>> should be in /dev/, and the old kernel is before 3.14 but the new one
>> >>> is after, but I would presume the standard headers are updated to
>> >>> account for this. Is there an easy way to check for this? Also, would
>> >>> the same issue cause writes to fails? Because writes from the same
>> >>> domain work fine, and appear to other domains using xenstore-ls.
>> >>>
>> >>> Regards,
>> >>> Dagaen Golomb
>> >>>
>> >>
>> >> Use strace on the process and see what gets opened.
>> >
>> > Ah, of course. It seems both the working and non-working domains are
>> > using /proc/...
>>
>> Then according to Doug, "Anything after 3.14 will give you
>> > deadlocks if you try to use /proc/xen/xenbus.". Maybe the non-working
>> > domU uses kernel version after 3.14.
>
> It does, being the custom kernel on version 4.1.0. But Dom0 uses this same
> exact kernel and reads/writes just fine! The only solution if this is indeed
> the problem appears to be changing the kernel source we build on or some
> hacky method such as symlinking /proc/.. to /dev/.., there has to be an
> elegant real solution to this...

Hi Dagaen,

Maybe we can try to create a symlink /proc/xen/xenbus to
/dev/xen/xenbus and see if works.

I'm not that sure about if you can just define a env. variable
XENSTORED_PATH to /dev/xen/xenbus to make /dev/xen/xenbus as a default
choice.. But it's no harm to try.

BTW, this is a useful link to refer to:
http://lists.xenproject.org/archives/html/xen-devel/2015-08/msg01679.html


Best Regards,

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

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

[Xen-devel] xen: 82599 passthrough problem

[liuenliang]

Hi,all:

I also met this problem when passthrough 82599 to domU by SRIOV, and the call 
stack as follows:
(XEN) Xen call trace:
(XEN)[] panic+0xc3/0x1a0
(XEN)[] symbols_lookup+0x22/0x2a0
(XEN)[] syscall_enter+0x88/0x8d
(XEN)[] syscall_enter+0x88/0x8d
(XEN)[] __print_symbol+0x8a/0xc0
(XEN)[] syscall_enter+0x88/0x8d
(XEN)[] show_stack+0x110/0x180
(XEN)[] __pirq_guest_unbind+0x2d8/0x340
(XEN)[] __pirq_guest_unbind+0x2d8/0x340
(XEN)[] do_invalid_op+0x394/0x420
(XEN)[] handle_exception_saved+0x30/0x6e
(XEN)[] __pirq_guest_unbind+0x2d6/0x340
(XEN)[] domain_spin_lock_irq_desc+0x64/0xa0
(XEN)[] pirq_guest_unbind+0x5d/0x160
(XEN)[] pci_release_devices+0x129/0x220
(XEN)[] domain_relinquish_resources+0xa8/0x2a0
(XEN)[] domain_kill+0x84/0x100
(XEN)[] do_domctl+0x9c4/0x1620
(XEN)[] syscall_enter+0x88/0x8d


1) The version of xen-syms is xen-syms-4.1.2_115 and the passthrough is done 
via 'pci='. 
2) I using qemu-xen, and the version is 1.2.2.
3) This happens when I reboot the guest(HVM), but not happens all the time.

BTW, the bug "corruption  caused by race conditions between device allocation 
and deallocation to a domain." is fixed.(the link is:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=15a9f34d1b1a6c50f2da046a6e4c6726a230d089)

So, anyone who knows what is the problem and any advices? Thanks.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

> > Hi All,
> >
> > I'm having an interesting issue. I am working on a project that
> > requires me to share memory between dom0 and domUs. I have this
> > successfully working using the grant table and the XenStore to
> > communicate grefs.
> >
> > My issue is this. I have one domU running Ubuntu 12.04 with a
default
> > 3.8.x kernel that has no issue reading or writing from the XenStore.
> > My work also requires some kernel modifications, and we have made
> > these changes in the 4.1.0 kernel. In particular, we've only added a
> > simple hypercall. This modified kernel is what dom0 is running, on
top
> > of Xen 4.7 rc1.
> 
>  Without reading the rest of the thread but seeing the kernel
versions.
>  Can you check how you're communicating to xenstore? Is it via
>  /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give
you
>  deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer
should
>  prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>  that default didn't land until Xen 4.7. Since you're on the right
>  versions I expect you're using /dev/xen/xenbus but you never know.
> >>>
> >>> How do I know which is being used? /dev/xen/xenbus is there and so is
> >>> process/xen/xenbus. Could this be a problem with header version
> >>> mismatches or something similar? I'm using the xen/xenstore.h header
> >>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
> >>> should be in /dev/, and the old kernel is before 3.14 but the new one
> >>> is after, but I would presume the standard headers are updated to
> >>> account for this. Is there an easy way to check for this? Also, would
> >>> the same issue cause writes to fails? Because writes from the same
> >>> domain work fine, and appear to other domains using xenstore-ls.
> >>>
> >>> Regards,
> >>> Dagaen Golomb
> >>>
> >>
> >> Use strace on the process and see what gets opened.
> >
> > Ah, of course. It seems both the working and non-working domains are
> > using /proc/...
>
> Then according to Doug, "Anything after 3.14 will give you
> > deadlocks if you try to use /proc/xen/xenbus.". Maybe the non-working
domU uses kernel version after 3.14.

It does, being the custom kernel on version 4.1.0. But Dom0 uses this same
exact kernel and reads/writes just fine! The only solution if this is
indeed the problem appears to be changing the kernel source we build on or
some hacky method such as symlinking /proc/.. to /dev/.., there has to be
an elegant real solution to this...

Regards,
Dagaen Golomb
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Meng Xu]

On Sun, May 15, 2016 at 9:41 PM, Dagaen Golomb  wrote:
>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
 On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.

 Without reading the rest of the thread but seeing the kernel versions.
 Can you check how you're communicating to xenstore? Is it via
 /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
 deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
 prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
 that default didn't land until Xen 4.7. Since you're on the right
 versions I expect you're using /dev/xen/xenbus but you never know.
>>>
>>> How do I know which is being used? /dev/xen/xenbus is there and so is
>>> process/xen/xenbus. Could this be a problem with header version
>>> mismatches or something similar? I'm using the xen/xenstore.h header
>>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>>> should be in /dev/, and the old kernel is before 3.14 but the new one
>>> is after, but I would presume the standard headers are updated to
>>> account for this. Is there an easy way to check for this? Also, would
>>> the same issue cause writes to fails? Because writes from the same
>>> domain work fine, and appear to other domains using xenstore-ls.
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>> Use strace on the process and see what gets opened.
>
> Ah, of course. It seems both the working and non-working domains are
> using /proc/...

Then according to Doug, "Anything after 3.14 will give you
> deadlocks if you try to use /proc/xen/xenbus.". Maybe the non-working domU 
> uses kernel version after 3.14?

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

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

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

As you suggested, I used xen 4.7.0-rc2 to test it again and the problem
still exists.

$ sudo xl create xen-config/win7
> Parsing config from xen-config/win7
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl_create.c:1252:domcreate_launch_dm: unable to add disk
> devices
> libxl: error: libxl_device.c:1033:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vbd/1/51712
> libxl: error: libxl.c:1636:devices_destroy_cb: libxl__devices_destroy
> failed for 1
> libxl: error: libxl.c:1564:libxl__destroy_domid: non-existant domain 1
> libxl: error: libxl.c:1523:domain_destroy_callback: unable to destroy
> guest with domid 1
> libxl: error: libxl.c:1452:domain_destroy_cb: destruction of domain 1
> failed


Denied behaviors:

~$ sudo xl dmesg | grep avc
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event


Corresponding rules:

~$ sudo xl dmesg | grep avc | audit2allow
> #= dom0_t ==
> allow dom0_t self:event send;


When I tried to add this rule to xen.te, it says

libsepol.check_assertion_helper: neverallow on line 2023 violated by allow
> dom0_t dom0_t:event { send };
>

So I comment the following restriction in policy.conf and recompile flask
policy with the new rule added.

neverallow * ~event_type:event { create send status };


This time no rule violations are generated by checking 'xl dmesg| grep
avc', but the errors in the very first place when creating domU (both hvm
and pv, with or without seclabel) still exist.

Basic info of xen configuration:

$ sudo xl info
> host   : storage
> release: 3.19.0
> version: #1 SMP Tue Dec 8 09:27:36 CST 2015
> machine: x86_64
> nr_cpus: 6
> max_cpu_id : 143
> nr_nodes   : 1
> cores_per_socket   : 6
> threads_per_core   : 1
> cpu_mhz: 1600
> hw_caps:
> b7ebfbff:77fef3ff:2c100800:0021:0001:37ab:
>
>:0100
> virt_caps  : hvm hvm_directio
> total_memory   : 32667
> free_memory: 24046
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 7
> xen_extra  : .0-rc
> xen_version: 4.7.0-rc
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-
>  x86_32p
> hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 94368
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 94368
 test-armhf-armhf-libvirt  7 host-ping-check-xen   fail REGR. vs. 94368
 test-armhf-armhf-xl-multivcpu  9 debian-install   fail REGR. vs. 94368

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

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

version targeted for testing:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis94368  2016-05-15 05:56:52 Z0 days
Testing same since94442  2016-05-15 18:46:42 Z0 days1 attempts


People who touched revisions under test:
  Jim Fehlig 
  Wei Liu 

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
 Hi All,

 I'm having an interesting issue. I am working on a project that
 requires me to share memory between dom0 and domUs. I have this
 successfully working using the grant table and the XenStore to
 communicate grefs.

 My issue is this. I have one domU running Ubuntu 12.04 with a default
 3.8.x kernel that has no issue reading or writing from the XenStore.
 My work also requires some kernel modifications, and we have made
 these changes in the 4.1.0 kernel. In particular, we've only added a
 simple hypercall. This modified kernel is what dom0 is running, on top
 of Xen 4.7 rc1.
>>>
>>> Without reading the rest of the thread but seeing the kernel versions.
>>> Can you check how you're communicating to xenstore? Is it via
>>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
>>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
>>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>>> that default didn't land until Xen 4.7. Since you're on the right
>>> versions I expect you're using /dev/xen/xenbus but you never know.
>>
>> How do I know which is being used? /dev/xen/xenbus is there and so is
>> process/xen/xenbus. Could this be a problem with header version
>> mismatches or something similar? I'm using the xen/xenstore.h header
>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>> should be in /dev/, and the old kernel is before 3.14 but the new one
>> is after, but I would presume the standard headers are updated to
>> account for this. Is there an easy way to check for this? Also, would
>> the same issue cause writes to fails? Because writes from the same
>> domain work fine, and appear to other domains using xenstore-ls.
>>
>> Regards,
>> Dagaen Golomb
>>
>
> Use strace on the process and see what gets opened.

Ah, of course. It seems both the working and non-working domains are
using /proc/...

Regards,
Dagaen Golomb

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Doug Goldstein]

On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
>>> Hi All,
>>>
>>> I'm having an interesting issue. I am working on a project that
>>> requires me to share memory between dom0 and domUs. I have this
>>> successfully working using the grant table and the XenStore to
>>> communicate grefs.
>>>
>>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>>> My work also requires some kernel modifications, and we have made
>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>>> simple hypercall. This modified kernel is what dom0 is running, on top
>>> of Xen 4.7 rc1.
>>
>> Without reading the rest of the thread but seeing the kernel versions.
>> Can you check how you're communicating to xenstore? Is it via
>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>> that default didn't land until Xen 4.7. Since you're on the right
>> versions I expect you're using /dev/xen/xenbus but you never know.
> 
> How do I know which is being used? /dev/xen/xenbus is there and so is
> process/xen/xenbus. Could this be a problem with header version
> mismatches or something similar? I'm using the xen/xenstore.h header
> file for all of my xenstore interactions. I'm running Xen 4.7 so it
> should be in /dev/, and the old kernel is before 3.14 but the new one
> is after, but I would presume the standard headers are updated to
> account for this. Is there an easy way to check for this? Also, would
> the same issue cause writes to fails? Because writes from the same
> domain work fine, and appear to other domains using xenstore-ls.
> 
> Regards,
> Dagaen Golomb
> 

Use strace on the process and see what gets opened.

-- 
Doug Goldstein



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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> > Hi All,
> >
> > I'm having an interesting issue. I am working on a project that
> > requires me to share memory between dom0 and domUs. I have this
> > successfully working using the grant table and the XenStore to
> > communicate grefs.
> >
> > My issue is this. I have one domU running Ubuntu 12.04 with a default
> > 3.8.x kernel that has no issue reading or writing from the XenStore.
> > My work also requires some kernel modifications, and we have made
> > these changes in the 4.1.0 kernel. In particular, we've only added a
> > simple hypercall. This modified kernel is what dom0 is running, on top
> > of Xen 4.7 rc1.
>
> Without reading the rest of the thread but seeing the kernel versions.
> Can you check how you're communicating to xenstore? Is it via
> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
> that default didn't land until Xen 4.7. Since you're on the right
> versions I expect you're using /dev/xen/xenbus but you never know.

How do I know which is being used? /dev/xen/xenbus is there and so is
process/xen/xenbus. Could this be a problem with header version
mismatches or something similar? I'm using the xen/xenstore.h header
file for all of my xenstore interactions. I'm running Xen 4.7 so it
should be in /dev/, and the old kernel is before 3.14 but the new one
is after, but I would presume the standard headers are updated to
account for this. Is there an easy way to check for this? Also, would
the same issue cause writes to fails? Because writes from the same
domain work fine, and appear to other domains using xenstore-ls.

Regards,
Dagaen Golomb

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Doug Goldstein]

On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> Hi All,
> 
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
> 
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.

Without reading the rest of the thread but seeing the kernel versions.
Can you check how you're communicating to xenstore? Is it via
/dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
that default didn't land until Xen 4.7. Since you're on the right
versions I expect you're using /dev/xen/xenbus but you never know.

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH] v3 - Add exclusive locking option to block-iscsi

[Steven Haigh]

On 2016-05-12 21:02, Wei Liu wrote:

Hi Steven

On Mon, May 09, 2016 at 02:22:48PM +1000, Steven Haigh wrote:

On 2016-05-05 15:52, Steven Haigh wrote:
>On 2016-05-05 12:32, Steven Haigh wrote:
>>Overview
>>
>>If you're using iSCSI, you can mount a target by multiple Dom0
>>machines on the same target. For non-cluster aware filesystems, this
>>can lead to disk corruption and general bad times by all. The iSCSI
>>protocol allows the use of persistent reservations as per the SCSI
>>disk spec. Low level SCSI commands for locking are handled by the
>>sg_persist program (bundled with sg3_utils package in EL).
>>
>>The aim of this patch is to create a 'locktarget=y' option specified
>>within the disk 'target' command for iSCSI to lock the target in
>>exclusive mode on VM start with a key generated from the local systems
>>IP, and release this lock on the shutdown of the DomU.
>>
>>Example Config:
>>disk=
>>['script=block-iscsi,vdev=xvda,target=iqn=iqn.1986-03.com.sun:02:mytarget,portal=iscsi.example.com,locktarget=y']


You seem to suggest an extension (locktarget) to disk spec as well but
you patch doesn't contain modification to
docs/txt/misc/xl-disk-configuration.txt.


Correct. There is no documentation for the existing block-iscsi script 
within xl-disk-configuration.txt.


In fact, there is no mention at all regarding block-iscsi in any of the 
documentation that I can see.


--
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

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

[Xen-devel] [xen-4.5-testing bisection] complete build-armhf-libvirt

[osstest service owner]

branch xen-4.5-testing
xenbranch xen-4.5-testing
job build-armhf-libvirt
testid libvirt-build

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://xenbits.xen.org/libvirt.git
  Bug introduced:  e744065679ccba8471d28b2cf6e93f443cd20c8c
  Bug not present: 744d74fafd0048c01a2b5cc18d1b03917ece8886
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/94455/


  commit e744065679ccba8471d28b2cf6e93f443cd20c8c
  Author: Jim Fehlig 
  Date:   Thu Apr 14 16:10:32 2016 -0600
  
  libxl: use LIBXL_API_VERSION 0x040200
  
  To ensure the libvirt libxl driver will build with future versions
  of Xen where the libxl API may change in incompatible ways,
  explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
  does use new libxl APIs that have been added since Xen 4.2, but
  currently it does not make use of any changes made to existing
  APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
  The version can be bumped if/when the libxl driver consumes the
  changed APIs.
  
  Further details can be found in the following discussion thread
  
  https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html
  Signed-off-by: Jim Fehlig 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.5-testing/build-armhf-libvirt.libvirt-build
 --summary-out=tmp/94455.bisection-summary --basis-template=93989 
--blessings=real,real-bisect xen-4.5-testing build-armhf-libvirt libvirt-build
Searching for failure / basis pass:
 94384 fail [host=cubietruck-gleizes] / 94030 [host=arndale-westfield] 93989 
[host=cubietruck-metzinger] 93928 [host=cubietruck-braque] 93905 ok.
Failure / basis pass flights: 94384 / 93905
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9055faebd426b44ad2c3bb97d6b8b0dd3496ab35 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
1334fa937ad269e9f476fc6a69fd895f5fc99864
Basis pass 8b62c65d24bdb20121d3147b4f4dc98bac4f024b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#8b62c65d24bdb20121d3147b4f4dc98bac4f024b-9055faebd426b44ad2c3bb97d6b8b0dd3496ab35
 
git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-6cc32c63e80bc1a30c521b2f07f2b54909b59892
 
git://xenbits.xen.org/qemu-xen.git#90045485cae7ba34334c5f2a6e7b007f2ab7dc2d-63d6eab2fda43e9cfdaa33e9ffde755da8e98e32
 
git://xenbits.xen.org/xen.git#065b1347b0902fd68291ddc593a0055259793383-1334fa937ad269e9f476fc6a69fd895f5fc99864
Loaded 3006 nodes in revision graph
Searching for test results:
 93905 pass 8b62c65d24bdb20121d3147b4f4dc98bac4f024b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 93928 [host=cubietruck-braque]
 93989 [host=cubietruck-metzinger]
 94030 [host=arndale-westfield]
 94079 []
 94135 fail 677b94f48763efd703cb80ea5e7badeff857de5d 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
1334fa937ad269e9f476fc6a69fd895f5fc99864
 94290 fail 9055faebd426b44ad2c3bb97d6b8b0dd3496ab35 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
63d6eab2fda43e9cfdaa33e9ffde755da8e98e32 
1334fa937ad269e9f476fc6a69fd895f5fc99864
 94371 fail caa16d31688725b6031e155d8c1e20d5008559ba 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 94333 pass 8b62c65d24bdb20121d3147b4f4dc98bac4f024b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 94433 pass 744d74fafd0048c01a2b5cc18d1b03917ece8886 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 94381 fail c81bba4f6f925eda28e64bc6593e916f852db99e 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 94400 pass 03e750f35d6d8cc39dcdeb893b96e732bd2315ef 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
90045485cae7ba34334c5f2a6e7b007f2ab7dc2d 
065b1347b0902fd68291ddc593a0055259793383
 94409 pass 00307b5d8211a0206a57aa634e016c886d375746 

[Xen-devel] [qemu-upstream-4.3-testing test] 94449: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   99 days
Testing same since93977  2016-05-10 11:09:16 Z5 days   12 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [PATCH 2/2] xen: sched: rtds: use non-atomic bit-ops

[Tianyang Chen]

Vcpu flags are checked and cleared atomically. Performance can be
improved with corresponding non-atomic versions since schedule.c
already has spin_locks in place.

Signed-off-by: Tianyang Chen 
---
 xen/common/sched_rt.c |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 1584d53..1a18f6d 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -936,7 +936,7 @@ burn_budget(const struct scheduler *ops, struct rt_vcpu 
*svc, s_time_t now)
 if ( svc->cur_budget <= 0 )
 {
 svc->cur_budget = 0;
-set_bit(__RTDS_depleted, >flags);
+__set_bit(__RTDS_depleted, >flags);
 }
 
 /* TRACE */
@@ -1050,7 +1050,7 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
bool_t tasklet_work_sched
 if ( snext != scurr &&
  !is_idle_vcpu(current) &&
  vcpu_runnable(current) )
-set_bit(__RTDS_delayed_runq_add, >flags);
+__set_bit(__RTDS_delayed_runq_add, >flags);
 
 snext->last_start = now;
 ret.time =  -1; /* if an idle vcpu is picked */
@@ -1059,7 +1059,7 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
bool_t tasklet_work_sched
 if ( snext != scurr )
 {
 q_remove(snext);
-set_bit(__RTDS_scheduled, >flags);
+__set_bit(__RTDS_scheduled, >flags);
 }
 if ( snext->vcpu->processor != cpu )
 {
@@ -1093,7 +1093,7 @@ rt_vcpu_sleep(const struct scheduler *ops, struct vcpu 
*vc)
 replq_remove(ops, svc);
 }
 else if ( svc->flags & RTDS_delayed_runq_add )
-clear_bit(__RTDS_delayed_runq_add, >flags);
+__clear_bit(__RTDS_delayed_runq_add, >flags);
 }
 
 /*
@@ -1235,7 +1235,7 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
  */
 if ( unlikely(svc->flags & RTDS_scheduled) )
 {
-set_bit(__RTDS_delayed_runq_add, >flags);
+__set_bit(__RTDS_delayed_runq_add, >flags);
 /*
  * The vcpu is waking up already, and we didn't even had the time to
  * remove its next replenishment event from the replenishment queue
@@ -1266,12 +1266,12 @@ rt_context_saved(const struct scheduler *ops, struct 
vcpu *vc)
 struct rt_vcpu *svc = rt_vcpu(vc);
 spinlock_t *lock = vcpu_schedule_lock_irq(vc);
 
-clear_bit(__RTDS_scheduled, >flags);
+__clear_bit(__RTDS_scheduled, >flags);
 /* not insert idle vcpu to runq */
 if ( is_idle_vcpu(vc) )
 goto out;
 
-if ( test_and_clear_bit(__RTDS_delayed_runq_add, >flags) &&
+if ( __test_and_clear_bit(__RTDS_delayed_runq_add, >flags) &&
  likely(vcpu_runnable(vc)) )
 {
 runq_insert(ops, svc);
@@ -1447,7 +1447,7 @@ static void repl_timer_handler(void *data){
 runq_tickle(ops, next_on_runq);
 }
 else if ( vcpu_on_q(svc) &&
-  test_and_clear_bit(__RTDS_depleted, >flags) )
+  __test_and_clear_bit(__RTDS_depleted, >flags) )
 runq_tickle(ops, svc);
 
 list_del(>replq_elem);
-- 
1.7.9.5


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

[Xen-devel] [PATCH 1/2] xen: sched: rtds refactor code

[Tianyang Chen]

No functional change:
 -Various coding style fix
 -Added comments for UPDATE_LIMIT_SHIFT.

Signed-off-by: Tianyang Chen 
---
 xen/common/sched_rt.c |  106 ++---
 1 file changed, 56 insertions(+), 50 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 7f8f411..1584d53 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -80,7 +80,7 @@
  * in schedule.c
  *
  * The functions involes RunQ and needs to grab locks are:
- *vcpu_insert, vcpu_remove, context_saved, __runq_insert
+ *vcpu_insert, vcpu_remove, context_saved, runq_insert
  */
 
 
@@ -107,6 +107,12 @@
  */
 #define RTDS_MIN_BUDGET (MICROSECS(10))
 
+/*
+ * UPDATE_LIMIT_SHIT: a constant used in rt_update_deadline(). When finding
+ * the next deadline, performing addition could be faster if the difference
+ * between cur_deadline and now is small. If the difference is bigger than
+ * 1024 * period, use multiplication.
+ */
 #define UPDATE_LIMIT_SHIFT  10
 
 /*
@@ -158,25 +164,25 @@
 static void repl_timer_handler(void *data);
 
 /*
- * Systme-wide private data, include global RunQueue/DepletedQ
+ * System-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
  * physical cpus. It can be grabbed via vcpu_schedule_lock_irq()
  */
 struct rt_private {
-spinlock_t lock;/* the global coarse grand lock */
-struct list_head sdom;  /* list of availalbe domains, used for dump */
-struct list_head runq;  /* ordered list of runnable vcpus */
-struct list_head depletedq; /* unordered list of depleted vcpus */
-struct list_head replq; /* ordered list of vcpus that need 
replenishment */
-cpumask_t tickled;  /* cpus been tickled */
-struct timer *repl_timer;   /* replenishment timer */
+spinlock_t lock; /* the global coarse grand lock */
+struct list_head sdom;   /* list of availalbe domains, used for dump */
+struct list_head runq;   /* ordered list of runnable vcpus */
+struct list_head depletedq;  /* unordered list of depleted vcpus */
+struct list_head replq;  /* ordered list of vcpus that need 
replenishment */
+cpumask_t tickled;   /* cpus been tickled */
+struct timer *repl_timer;/* replenishment timer */
 };
 
 /*
  * Virtual CPU
  */
 struct rt_vcpu {
-struct list_head q_elem;/* on the runq/depletedq list */
+struct list_head q_elem; /* on the runq/depletedq list */
 struct list_head replq_elem; /* on the replenishment events list */
 
 /* Up-pointers */
@@ -188,19 +194,19 @@ struct rt_vcpu {
 s_time_t budget;
 
 /* VCPU current infomation in nanosecond */
-s_time_t cur_budget;/* current budget */
-s_time_t last_start;/* last start time */
-s_time_t cur_deadline;  /* current deadline for EDF */
+s_time_t cur_budget; /* current budget */
+s_time_t last_start; /* last start time */
+s_time_t cur_deadline;   /* current deadline for EDF */
 
-unsigned flags; /* mark __RTDS_scheduled, etc.. */
+unsigned flags;  /* mark __RTDS_scheduled, etc.. */
 };
 
 /*
  * Domain
  */
 struct rt_dom {
-struct list_head sdom_elem; /* link list on rt_priv */
-struct domain *dom; /* pointer to upper domain */
+struct list_head sdom_elem;  /* link list on rt_priv */
+struct domain *dom;  /* pointer to upper domain */
 };
 
 /*
@@ -241,13 +247,13 @@ static inline struct list_head *rt_replq(const struct 
scheduler *ops)
  * and the replenishment events queue.
  */
 static int
-__vcpu_on_q(const struct rt_vcpu *svc)
+vcpu_on_q(const struct rt_vcpu *svc)
 {
return !list_empty(>q_elem);
 }
 
 static struct rt_vcpu *
-__q_elem(struct list_head *elem)
+q_elem(struct list_head *elem)
 {
 return list_entry(elem, struct rt_vcpu, q_elem);
 }
@@ -303,7 +309,7 @@ rt_dump_vcpu(const struct scheduler *ops, const struct 
rt_vcpu *svc)
 svc->cur_budget,
 svc->cur_deadline,
 svc->last_start,
-__vcpu_on_q(svc),
+vcpu_on_q(svc),
 vcpu_runnable(svc->vcpu),
 svc->flags,
 keyhandler_scratch);
@@ -339,28 +345,28 @@ rt_dump(const struct scheduler *ops)
 replq = rt_replq(ops);
 
 printk("Global RunQueue info:\n");
-list_for_each( iter, runq )
+list_for_each ( iter, runq )
 {
-svc = __q_elem(iter);
+svc = q_elem(iter);
 rt_dump_vcpu(ops, svc);
 }
 
 printk("Global DepletedQueue info:\n");
-list_for_each( iter, depletedq )
+list_for_each ( iter, depletedq )
 {
-svc = __q_elem(iter);
+svc = q_elem(iter);
 rt_dump_vcpu(ops, svc);
 }
 
 printk("Global Replenishment Events info:\n");
-list_for_each( iter, replq )
+list_for_each ( iter, replq 

[Xen-devel] [PATCH 0/2] xen: sched: rtds refactor code

[Tianyang Chen]

The first part of this patch series aims at fixing coding syle issue
for control structures. Because locks are grabbed in schedule.c before
hooks are called, underscores in front of function names are removed.

The second part replaces atomic bit-ops with non-atomic ones since locks
are grabbed in schedule.c.

Discussions:
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01528.html
http://www.gossamer-threads.com/lists/xen/devel/431251?do=post_view_threaded#431251

Tianyang Chen (2):
  xen: sched: rtds refactor code
  xen: sched: rtds: use non-atomic bit-ops

 xen/common/sched_rt.c |  122 ++---
 1 file changed, 64 insertions(+), 58 deletions(-)

-- 
1.7.9.5


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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.
>
> The guest I mentioned before with the default kernel can still read
> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
> running our kernel.
>
> The issue I'm having is with another newly created guest (i.e., it is
> not a copy of the working one, this is because I needed more space and
> couldn't expand the original disk image). It is also running Ubuntu
> 12.04 but has been upgraded to our modified kernel. On this guest I
> can write to the XenStore, and see that the writes were indeed
> successful using xenstore-ls in dom0. However, when this same guest
> attempts to read from the XenStore, it doesn't return an error code
> but instead just blocks indefinitely. I've waiting many minutes to
> make sure its not just blocking for a while, it appears like it will
> block forever. The block is happening when I start the transaction.
> I've also tried not using a transaction, in which case it blocks on
> the read itself.
>
> I have an inkling this may be something as simple as a configuration
> issue, but I can't seem to find anything. Also, the fact that writes
> work fine but reads do not is perplexing me.
>
> Any help would be appreciated!

 Nothing should block like this.  Without seeing your patch, I can't
 comment as to whether you have accidentally broken things.
>>>
>>> I don't see any way the patch could be causing this. It simply adds
>>> another function and case clause to an already-existing hypercall, and
>>> when you call the hypercall with that option it returns the current
>>> budget of a passed-in vcpu. It doesn't even come close to touching
>>> grant mechanics, and doesn't modify any state - it simply returns a
>>> value that previously was hidden in the kernel.
>>>
 Other avenues of investigation are to look at what the xenstored process
 is doing in dom0 (is it idle? or is it spinning?), and to look in the
 xenstored log file to see if anything suspicious occurs.
>>>
>>> I tried booting into older, stock kernels. They all work with the
>>> read. However, I do not see why the kernel modification would be the
>>> issue as described above. I also have the dom0 running this kernel and
>>> it reads and writes the XenStore just dandy. Are there any kernel
>>> config issues that could do this?
>>
>> What if you use the .config of the kernel in the working domU to
>> compile the kernel in the not-working domU?
>> I assume you used the same kernel source code for both domUs.
>
> I could try this. Right now I did the same procedure, but not the same
> .config (both times working off of oldconfig and then defaults for new
> items). I'm not sure if it really makes sense for them to have the
> same config, but its worth a try.
>
> Also, I did use the same source for both.

I just tried using the same .config file/ Due to differences in the
tool stack (notably gcc version) the only change was the stack
protector from strong to normal. Compiled as expected but issue still
persists. I'm stumped.

Regards,
Dagaen Golomb
Ph.D. Student, University of Pennsylvania

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 053d95e7e5e37378f6b21fe19009423762be894f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  158 days  264 attempts
Testing same since94396  2016-05-15 10:13:22 Z0 days4 attempts


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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

 Hi All,

 I'm having an interesting issue. I am working on a project that
 requires me to share memory between dom0 and domUs. I have this
 successfully working using the grant table and the XenStore to
 communicate grefs.

 My issue is this. I have one domU running Ubuntu 12.04 with a default
 3.8.x kernel that has no issue reading or writing from the XenStore.
 My work also requires some kernel modifications, and we have made
 these changes in the 4.1.0 kernel. In particular, we've only added a
 simple hypercall. This modified kernel is what dom0 is running, on top
 of Xen 4.7 rc1.

 The guest I mentioned before with the default kernel can still read
 and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
 running our kernel.

 The issue I'm having is with another newly created guest (i.e., it is
 not a copy of the working one, this is because I needed more space and
 couldn't expand the original disk image). It is also running Ubuntu
 12.04 but has been upgraded to our modified kernel. On this guest I
 can write to the XenStore, and see that the writes were indeed
 successful using xenstore-ls in dom0. However, when this same guest
 attempts to read from the XenStore, it doesn't return an error code
 but instead just blocks indefinitely. I've waiting many minutes to
 make sure its not just blocking for a while, it appears like it will
 block forever. The block is happening when I start the transaction.
 I've also tried not using a transaction, in which case it blocks on
 the read itself.

 I have an inkling this may be something as simple as a configuration
 issue, but I can't seem to find anything. Also, the fact that writes
 work fine but reads do not is perplexing me.

 Any help would be appreciated!
>>>
>>> Nothing should block like this.  Without seeing your patch, I can't
>>> comment as to whether you have accidentally broken things.
>>
>> I don't see any way the patch could be causing this. It simply adds
>> another function and case clause to an already-existing hypercall, and
>> when you call the hypercall with that option it returns the current
>> budget of a passed-in vcpu. It doesn't even come close to touching
>> grant mechanics, and doesn't modify any state - it simply returns a
>> value that previously was hidden in the kernel.
>>
>>> Other avenues of investigation are to look at what the xenstored process
>>> is doing in dom0 (is it idle? or is it spinning?), and to look in the
>>> xenstored log file to see if anything suspicious occurs.
>>
>> I tried booting into older, stock kernels. They all work with the
>> read. However, I do not see why the kernel modification would be the
>> issue as described above. I also have the dom0 running this kernel and
>> it reads and writes the XenStore just dandy. Are there any kernel
>> config issues that could do this?
>
> What if you use the .config of the kernel in the working domU to
> compile the kernel in the not-working domU?
> I assume you used the same kernel source code for both domUs.

I could try this. Right now I did the same procedure, but not the same
.config (both times working off of oldconfig and then defaults for new
items). I'm not sure if it really makes sense for them to have the
same config, but its worth a try.

Also, I did use the same source for both.

Regards,
Dagaen Golomb
Ph.D. Student, University of Pennsylvania

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

[Xen-devel] [xen-4.6-testing test] 94398: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93932
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93932

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   3 host-install(3)  broken in 94232 pass in 94398
 test-amd64-i386-xl-raw3 host-install(3)  broken in 94317 pass in 94398
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 94232 
pass in 94398
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail in 
94317 pass in 94398
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail pass in 94232
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail pass in 94317

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

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

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z5 days
Failing since 94000  2016-05-10 18:10:33 Z5 days7 attempts
Testing same since94036  2016-05-11 15:51:26 Z4 days6 attempts


People who touched revisions under test:
  Ian Jackson 

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Meng Xu]

On Sun, May 15, 2016 at 3:54 PM, Dagaen Golomb  wrote:
>>> Hi All,
>>>
>>> I'm having an interesting issue. I am working on a project that
>>> requires me to share memory between dom0 and domUs. I have this
>>> successfully working using the grant table and the XenStore to
>>> communicate grefs.
>>>
>>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>>> My work also requires some kernel modifications, and we have made
>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>>> simple hypercall. This modified kernel is what dom0 is running, on top
>>> of Xen 4.7 rc1.
>>>
>>> The guest I mentioned before with the default kernel can still read
>>> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
>>> running our kernel.
>>>
>>> The issue I'm having is with another newly created guest (i.e., it is
>>> not a copy of the working one, this is because I needed more space and
>>> couldn't expand the original disk image). It is also running Ubuntu
>>> 12.04 but has been upgraded to our modified kernel. On this guest I
>>> can write to the XenStore, and see that the writes were indeed
>>> successful using xenstore-ls in dom0. However, when this same guest
>>> attempts to read from the XenStore, it doesn't return an error code
>>> but instead just blocks indefinitely. I've waiting many minutes to
>>> make sure its not just blocking for a while, it appears like it will
>>> block forever. The block is happening when I start the transaction.
>>> I've also tried not using a transaction, in which case it blocks on
>>> the read itself.
>>>
>>> I have an inkling this may be something as simple as a configuration
>>> issue, but I can't seem to find anything. Also, the fact that writes
>>> work fine but reads do not is perplexing me.
>>>
>>> Any help would be appreciated!
>>
>> Nothing should block like this.  Without seeing your patch, I can't
>> comment as to whether you have accidentally broken things.
>
> I don't see any way the patch could be causing this. It simply adds
> another function and case clause to an already-existing hypercall, and
> when you call the hypercall with that option it returns the current
> budget of a passed-in vcpu. It doesn't even come close to touching
> grant mechanics, and doesn't modify any state - it simply returns a
> value that previously was hidden in the kernel.
>
>> Other avenues of investigation are to look at what the xenstored process
>> is doing in dom0 (is it idle? or is it spinning?), and to look in the
>> xenstored log file to see if anything suspicious occurs.
>
> I tried booting into older, stock kernels. They all work with the
> read. However, I do not see why the kernel modification would be the
> issue as described above. I also have the dom0 running this kernel and
> it reads and writes the XenStore just dandy. Are there any kernel
> config issues that could do this?

What if you use the .config of the kernel in the working domU to
compile the kernel in the not-working domU?
I assume you used the same kernel source code for both domUs.


Best Regards,

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 053d95e7e5e37378f6b21fe19009423762be894f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  158 days  263 attempts
Testing same since94396  2016-05-15 10:13:22 Z0 days3 attempts


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

[Xen-devel] [qemu-upstream-4.3-testing test] 94417: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   99 days
Testing same since93977  2016-05-10 11:09:16 Z5 days   11 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

>>> I'm having an interesting issue. I am working on a project that
>>> requires me to share memory between dom0 and domUs. I have this
>>> successfully working using the grant table and the XenStore to
>>> communicate grefs.
>>>
>>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>>> My work also requires some kernel modifications, and we have made
>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>>> simple hypercall. This modified kernel is what dom0 is running, on top
>>> of Xen 4.7 rc1.
>>>
>>> The guest I mentioned before with the default kernel can still read
>>> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
>>> running our kernel.
>>>
>>> The issue I'm having is with another newly created guest (i.e., it is
>>> not a copy of the working one, this is because I needed more space and
>>> couldn't expand the original disk image). It is also running Ubuntu
>>> 12.04 but has been upgraded to our modified kernel. On this guest I
>>> can write to the XenStore, and see that the writes were indeed
>>> successful using xenstore-ls in dom0. However, when this same guest
>>> attempts to read from the XenStore, it doesn't return an error code
>>> but instead just blocks indefinitely. I've waiting many minutes to
>>> make sure its not just blocking for a while, it appears like it will
>>> block forever. The block is happening when I start the transaction.
>>> I've also tried not using a transaction, in which case it blocks on
>>> the read itself.
>>>
>>> I have an inkling this may be something as simple as a configuration
>>> issue, but I can't seem to find anything. Also, the fact that writes
>>> work fine but reads do not is perplexing me.
>>>
>>> Any help would be appreciated!
>>
>> Nothing should block like this.  Without seeing your patch, I can't
>> comment as to whether you have accidentally broken things.
>
> I don't see any way the patch could be causing this. It simply adds
> another function and case clause to an already-existing hypercall, and
> when you call the hypercall with that option it returns the current
> budget of a passed-in vcpu. It doesn't even come close to touching
> grant mechanics, and doesn't modify any state - it simply returns a
> value that previously was hidden in the kernel.
>
>> Other avenues of investigation are to look at what the xenstored process
>> is doing in dom0 (is it idle? or is it spinning?), and to look in the
>> xenstored log file to see if anything suspicious occurs.
>
> I tried booting into older, stock kernels. They all work with the
> read. However, I do not see why the kernel modification would be the
> issue as described above. I also have the dom0 running this kernel and
> it reads and writes the XenStore just dandy. Are there any kernel
> config issues that could do this? This is very confusing. I have one
> instance of it working with reads so it can be inherent to the kernel
> build itself...
>
> Xenstore (or any grep-ed "xen" process for that matter) are acting
> fine. No changes in memory or CPU when blocking vs before blocking.
> xenstored-access.log is this:
>
> [20160515T19:45:42.207Z]  A992 newconn
> [20160515T19:45:42.210Z]  A992 endconn
> [20160515T19:45:42.223Z]  A993 newconn
> [20160515T19:45:42.223Z]  A993 write /local/domain/15/mbroe 
> \017\001
> [20160515T19:45:42.223Z]  A993 endconn
> [20160515T19:45:42.232Z]  A994 newconn
> [20160515T19:45:42.232Z]  A994.1   setperms  /local/domain/15/mbroe n0 b15
> [20160515T19:45:42.233Z]  A994.1   setperms
> /local/domain/15/mbroe/gref n0 b15
> [20160515T19:45:42.233Z]  A994.1   setperms
> /local/domain/15/mbroe/min_budget n0 b15
> [20160515T19:45:42.234Z]  A994.1   commit
> [20160515T19:45:42.234Z]  A994 endconn
> [20160515T19:46:25.215Z]  A995 newconn
> [20160515T19:46:25.215Z]  A995 endconn
> [20160515T19:46:29.540Z]  A996 newconn
> [20160515T19:46:29.541Z]  A996 watch
> /local/domain/15/mbroe/max_block max_block
> [20160515T19:46:29.541Z]  A996 w event
> /local/domain/15/mbroe/max_block max_block
> [20160515T19:46:29.542Z]  A996.1   commit
> [20160515T19:46:29.543Z]  A996 watch
> /local/domain/15/mbroe/num_blocks num_blocks
> [20160515T19:46:29.543Z]  A996 w event
> /local/domain/15/mbroe/num_blocks num_blocks
> [20160515T19:46:29.544Z]  A996.2   commit
> [20160515T19:46:29.545Z]  A996.3   write /local/domain/15/mbroe/gref 8
> [20160515T19:46:29.546Z]  A996.3   commit
> [20160515T19:46:29.546Z]  A996.4   write
> /local/domain/15/mbroe/min_budget 10
> [20160515T19:46:29.547Z]  A996.4   commit
> [20160515T19:46:29.548Z]  A996 endconn
>
> ** Above is dom0, running our kernel, doing both read and write just
> fine, and setting permission for dom15. **
>
> [20160515T19:47:44.562Z]  D15  watch
> 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

>> Hi All,
>>
>> I'm having an interesting issue. I am working on a project that
>> requires me to share memory between dom0 and domUs. I have this
>> successfully working using the grant table and the XenStore to
>> communicate grefs.
>>
>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>> My work also requires some kernel modifications, and we have made
>> these changes in the 4.1.0 kernel. In particular, we've only added a
>> simple hypercall. This modified kernel is what dom0 is running, on top
>> of Xen 4.7 rc1.
>>
>> The guest I mentioned before with the default kernel can still read
>> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
>> running our kernel.
>>
>> The issue I'm having is with another newly created guest (i.e., it is
>> not a copy of the working one, this is because I needed more space and
>> couldn't expand the original disk image). It is also running Ubuntu
>> 12.04 but has been upgraded to our modified kernel. On this guest I
>> can write to the XenStore, and see that the writes were indeed
>> successful using xenstore-ls in dom0. However, when this same guest
>> attempts to read from the XenStore, it doesn't return an error code
>> but instead just blocks indefinitely. I've waiting many minutes to
>> make sure its not just blocking for a while, it appears like it will
>> block forever. The block is happening when I start the transaction.
>> I've also tried not using a transaction, in which case it blocks on
>> the read itself.
>>
>> I have an inkling this may be something as simple as a configuration
>> issue, but I can't seem to find anything. Also, the fact that writes
>> work fine but reads do not is perplexing me.
>>
>> Any help would be appreciated!
>
> Nothing should block like this.  Without seeing your patch, I can't
> comment as to whether you have accidentally broken things.

I don't see any way the patch could be causing this. It simply adds
another function and case clause to an already-existing hypercall, and
when you call the hypercall with that option it returns the current
budget of a passed-in vcpu. It doesn't even come close to touching
grant mechanics, and doesn't modify any state - it simply returns a
value that previously was hidden in the kernel.

> Other avenues of investigation are to look at what the xenstored process
> is doing in dom0 (is it idle? or is it spinning?), and to look in the
> xenstored log file to see if anything suspicious occurs.

I tried booting into older, stock kernels. They all work with the
read. However, I do not see why the kernel modification would be the
issue as described above. I also have the dom0 running this kernel and
it reads and writes the XenStore just dandy. Are there any kernel
config issues that could do this? This is very confusing. I have one
instance of it working with reads so it can be inherent to the kernel
build itself...

Xenstore (or any grep-ed "xen" process for that matter) are acting
fine. No changes in memory or CPU when blocking vs before blocking.
xenstored-access.log is this:

[20160515T19:45:42.207Z]  A992 newconn
[20160515T19:45:42.210Z]  A992 endconn
[20160515T19:45:42.223Z]  A993 newconn
[20160515T19:45:42.223Z]  A993 write /local/domain/15/mbroe \017\001
[20160515T19:45:42.223Z]  A993 endconn
[20160515T19:45:42.232Z]  A994 newconn
[20160515T19:45:42.232Z]  A994.1   setperms  /local/domain/15/mbroe n0 b15
[20160515T19:45:42.233Z]  A994.1   setperms
/local/domain/15/mbroe/gref n0 b15
[20160515T19:45:42.233Z]  A994.1   setperms
/local/domain/15/mbroe/min_budget n0 b15
[20160515T19:45:42.234Z]  A994.1   commit
[20160515T19:45:42.234Z]  A994 endconn
[20160515T19:46:25.215Z]  A995 newconn
[20160515T19:46:25.215Z]  A995 endconn
[20160515T19:46:29.540Z]  A996 newconn
[20160515T19:46:29.541Z]  A996 watch
/local/domain/15/mbroe/max_block max_block
[20160515T19:46:29.541Z]  A996 w event
/local/domain/15/mbroe/max_block max_block
[20160515T19:46:29.542Z]  A996.1   commit
[20160515T19:46:29.543Z]  A996 watch
/local/domain/15/mbroe/num_blocks num_blocks
[20160515T19:46:29.543Z]  A996 w event
/local/domain/15/mbroe/num_blocks num_blocks
[20160515T19:46:29.544Z]  A996.2   commit
[20160515T19:46:29.545Z]  A996.3   write /local/domain/15/mbroe/gref 8
[20160515T19:46:29.546Z]  A996.3   commit
[20160515T19:46:29.546Z]  A996.4   write
/local/domain/15/mbroe/min_budget 10
[20160515T19:46:29.547Z]  A996.4   commit
[20160515T19:46:29.548Z]  A996 endconn

** Above is dom0, running our kernel, doing both read and write just
fine, and setting permission for dom15. **

[20160515T19:47:44.562Z]  D15  watch
/local/domain/15/mbroe/gref 88007B2F3390
[20160515T19:47:44.562Z]  D15  w event
/local/domain/15/mbroe/gref 88007B2F3390

[Xen-devel] [xen-4.5-testing test] 94384: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 94135 pass 
in 94384
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 94135 
pass in 94384
 test-amd64-amd64-xl-qcow2 9 debian-di-install  fail in 94290 pass in 94384
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94135
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-install fail pass in 94290

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 94135 like 93989
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93928
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989

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

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z5 days
Testing same since94030  2016-05-11 13:08:55 Z4 days6 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 

[Xen-devel] [xen-4.6-testing bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-4.6-testing
xenbranch xen-4.6-testing
job build-amd64-libvirt
testid libvirt-build

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt_gnulib git://git.sv.gnu.org/gnulib.git
  Bug introduced:  71090a2a314d9c378afd6f842abb49f60b42d4ef
  Bug not present: 92bbc1b583743b7e463cdfbcd048d9d52063b8c4
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/9/


  commit 71090a2a314d9c378afd6f842abb49f60b42d4ef
  Author: Paul Eggert 
  Date:   Fri Jan 1 00:56:19 2016 -0800
  
  version-etc: new year
  
  * build-aux/gendocs.sh (version):
  * doc/gendocs_template:
  * doc/gendocs_template_min:
  * doc/gnulib.texi:
  * lib/version-etc.c (COPYRIGHT_YEAR):
  Update copyright dates by hand in templates and the like.
  * all files: Run 'make update-copyright'.


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.6-testing/build-amd64-libvirt.libvirt-build
 --summary-out=tmp/9.bisection-summary --basis-template=93932 
--blessings=real,real-bisect xen-4.6-testing build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 94087 fail [host=rimava0] / 94000 [host=chardonnay0] 93932 [host=huxelrebe1] 
92181 [host=huxelrebe0] 88309 [host=godello0] 88153 [host=italia0] 87889 
[host=godello1] 86632 [host=godello1] 86551 [host=godello0] 85893 
[host=godello0] 85324 [host=godello0] 84924 [host=baroque0] 83820 
[host=godello1] 83674 [host=italia1] 83120 [host=italia1] 83001 [host=godello1] 
81632 [host=godello1] 78701 [host=baroque0] 78528 [host=huxelrebe1] 77441 
[host=chardonnay1] 77259 [host=italia1] 76950 [host=baroque1] 67098 
[host=godello0] 66942 [host=baroque1] 66794 [host=baroque1] 66648 
[host=chardonnay0] 66537 [host=pinot1] 66394 [host=godello0] 65639 
[host=fiano1] 65355 [host=godello0] 65327 [host=godello1] 65299 [host=godello1] 
65283 [host=fiano1] 65256 [host=godello0] 65241 [host=chardonnay0] 65227 
[host=godello0] 65210 [host=baroque1] 65182 [host=nocera0] 65158 
[host=godello1] 65136 [host=nocera0] 65112 [host=godello0] 65088 
[host=baroque1] 65028 ok.
Failure / basis pass flights: 94087 / 65028
(tree in latest but not in basispass: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest e5aecc2f800e8e14edd561dc5af4f763f040d842 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
24f0ea5fcd2f7c07f56015d0d8a4bda5faf2a9bd 
14a60f98e0cd16e2636afb136129ed7f11cbfce0 
426783e661da942f8b7871613479db4daa6a16c3
Basis pass 3c7590e0a435d833895fc7b5be489e53e223ad95 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9 
78833c04250416f1870c458309d3ac0e5cf915fd
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#3c7590e0a435d833895fc7b5be489e53e223ad95-e5aecc2f800e8e14edd561dc5af4f763f040d842
 
git://git.sv.gnu.org/gnulib.git#f39477dba778e99392948dd3dd19ec0d46aee932-6cc32c63e80bc1a30c521b2f07f2b54909b59892
 
git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-24f0ea5fcd2f7c07f56015d0d8a4bda5faf2a9bd
 
git://xenbits.xen.org/qemu-xen.git#980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9-14a60f98e0cd16e2636afb136129ed7f11cbfce0
 
git://xenbits.xen.org/xen.git#78833c04250416f1870c458309d3ac0e5cf915fd-426783e661da942f8b7871613479db4daa6a16c3
adhoc-revtuple-generator: tree discontiguous: libvirt
Loaded 26066 nodes in revision graph
Searching for test results:
 64935 [host=godello1]
 65028 pass 3c7590e0a435d833895fc7b5be489e53e223ad95 
f39477dba778e99392948dd3dd19ec0d46aee932 
bc00cad75d8bcc3ba696992bec219c21db8406aa 
980dfcf5b8d8161871f81d1987b2f8ea5d7d4db9 
78833c04250416f1870c458309d3ac0e5cf915fd
 64988 [host=baroque1]
 65112 [host=godello0]
 65088 [host=baroque1]
 65136 [host=nocera0]
 65158 [host=godello1]
 65182 [host=nocera0]
 65210 [host=baroque1]
 65227 [host=godello0]
 65241 [host=chardonnay0]
 65256 [host=godello0]
 65299 [host=godello1]
 65283 [host=fiano1]
 65327 [host=godello1]
 65355 [host=godello0]
 65639 [host=fiano1]
 66394 [host=godello0]
 66537 [host=pinot1]
 66648 [host=chardonnay0]
 66794 [host=baroque1]
 66942 [host=baroque1]
 67098 [host=godello0]
 76950 [host=baroque1]
 77259 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 053d95e7e5e37378f6b21fe19009423762be894f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  158 days  262 attempts
Testing same since94396  2016-05-15 10:13:22 Z0 days2 attempts


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis94112  2016-05-13 18:02:38 Z2 days
Testing same since94428  2016-05-15 16:00:58 Z0 days1 attempts


People who touched revisions under test:
  Jim Fehlig 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Andrew Cooper]

On 15/05/16 17:40, Dagaen Golomb wrote:
> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.
>
> The guest I mentioned before with the default kernel can still read
> and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
> running our kernel.
>
> The issue I'm having is with another newly created guest (i.e., it is
> not a copy of the working one, this is because I needed more space and
> couldn't expand the original disk image). It is also running Ubuntu
> 12.04 but has been upgraded to our modified kernel. On this guest I
> can write to the XenStore, and see that the writes were indeed
> successful using xenstore-ls in dom0. However, when this same guest
> attempts to read from the XenStore, it doesn't return an error code
> but instead just blocks indefinitely. I've waiting many minutes to
> make sure its not just blocking for a while, it appears like it will
> block forever. The block is happening when I start the transaction.
> I've also tried not using a transaction, in which case it blocks on
> the read itself.
>
> I have an inkling this may be something as simple as a configuration
> issue, but I can't seem to find anything. Also, the fact that writes
> work fine but reads do not is perplexing me.
>
> Any help would be appreciated!

Nothing should block like this.  Without seeing your patch, I can't
comment as to whether you have accidentally broken things.

Other avenues of investigation are to look at what the xenstored process
is doing in dom0 (is it idle? or is it spinning?), and to look in the
xenstored log file to see if anything suspicious occurs.

~Andrew

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

[Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

Hi All,

I'm having an interesting issue. I am working on a project that
requires me to share memory between dom0 and domUs. I have this
successfully working using the grant table and the XenStore to
communicate grefs.

My issue is this. I have one domU running Ubuntu 12.04 with a default
3.8.x kernel that has no issue reading or writing from the XenStore.
My work also requires some kernel modifications, and we have made
these changes in the 4.1.0 kernel. In particular, we've only added a
simple hypercall. This modified kernel is what dom0 is running, on top
of Xen 4.7 rc1.

The guest I mentioned before with the default kernel can still read
and write the XenStore just fine when on Xen 4.7 rc1 and with dom0
running our kernel.

The issue I'm having is with another newly created guest (i.e., it is
not a copy of the working one, this is because I needed more space and
couldn't expand the original disk image). It is also running Ubuntu
12.04 but has been upgraded to our modified kernel. On this guest I
can write to the XenStore, and see that the writes were indeed
successful using xenstore-ls in dom0. However, when this same guest
attempts to read from the XenStore, it doesn't return an error code
but instead just blocks indefinitely. I've waiting many minutes to
make sure its not just blocking for a while, it appears like it will
block forever. The block is happening when I start the transaction.
I've also tried not using a transaction, in which case it blocks on
the read itself.

I have an inkling this may be something as simple as a configuration
issue, but I can't seem to find anything. Also, the fact that writes
work fine but reads do not is perplexing me.

Any help would be appreciated!

Regards,
Dagaen Golomb
Ph.D. Student, University of Pennsylvania

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

version targeted for testing:
 ovmf 053d95e7e5e37378f6b21fe19009423762be894f
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  158 days  261 attempts
Testing same since94396  2016-05-15 10:13:22 Z0 days1 attempts


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

[Xen-devel] [xen-unstable test] 94368: tolerable trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-pair 4 host-install/dst_host(4) broken in 94281 pass in 94368
 test-armhf-armhf-libvirt-raw  3 host-install(3)  broken in 94281 pass in 94368
 test-amd64-i386-xl3 host-install(3)   broken pass in 94281
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 94281 
pass in 94368

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

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

version targeted for testing:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis94368  2016-05-15 05:56:52 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16936 days0 attempts

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

[Xen-devel] [xen-unstable baseline-only test] 44418: trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]

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

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

version targeted for testing:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73
baseline version:
 xen  cd2cd109e7db3a7e689c20b8991d41115ed5bea6

Last test of basis44414  2016-05-14 00:52:11 Z1 days
Testing same since44418  2016-05-15 06:19:24 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 

Re: [Xen-devel] [PATCH V2] libxl: don't add cache mode for qdisk cdrom drives

[Wei Liu]

On Fri, May 13, 2016 at 02:36:18PM -0600, Jim Fehlig wrote:
> On 05/10/2016 04:06 AM, Stefano Stabellini wrote:
> > On Mon, 9 May 2016, Wei Liu wrote:
> >> On Thu, Apr 28, 2016 at 03:20:46PM -0600, Jim Fehlig wrote:
> >>> qemu commit 91a097e7 forbids specifying cache mode for empty
> >>> drives. Attempting to create a domain with an empty qdisk cdrom
> >>> drive results in
> >>>
> >>> qemu-system-x86_64: -drive if=ide,index=1,readonly=on,media=cdrom,
> >>>cache=writeback,id=ide-832: Must specify either driver or file
> >>>
> >> We need to fix this one way or another.
> >>
> >>> libxl only allows an empty 'target=' for cdroms. By default, cdroms
> >>> are readonly (see the 'access' parameter in xl-disk-configuration.txt)
> >>> and forced to readonly by any tools (e.g. xl) using libxlutil's
> >>> xlu_disk_parse() function. With cdroms always marked readonly,
> >>> explicitly specifying the cache mode for cdrom drives can be dropped.
> >>> The drive's 'readonly=on' option can also be set unconditionally.
> >>>
> >>> Signed-off-by: Jim Fehlig 
> >> CC Stefano who made the change to use writeback in
> >> e9a327bbbcab127625b0917a2780cb3601a81d01 . Also CC Anthony.
> >>
> >> Ian, Stefano and Anthony, do you have opinion on this patch?
> > It looks good to me. We could consider to backport it, given that we
> > only have a loose relationship with QEMU and older versions of Xen could
> > end up running with newer versions of QEMU.
> 
> Wei,
> 
> Will this patch make 4.7? It allows empty cdroms with freshly released QEMU 
> 2.6 :-).
> 

Yes, it's on my radar. I wanted to give some time for other people to
look at it.

Now two weeks has passed, I've queued it up for committing.

Wei.


> Regards,
> Jim
> 

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

Re: [Xen-devel] unable to create domain after enabling XSM

[Andrew Cooper]

On 15/05/16 15:25, Big Strong wrote:
> Hi,
>
> I've configured xen 4.6.0 with xsm enabled and use the default flask
> policy to boot the dom0.

For issues like this, please always use the latest stable branch, in
this case making that Xen 4.6.1+.  It is entirely possible that bugfixes
have been backported.

In this case, can you try current master (or 4.7.0-rc2)? Some of these
errors have definitely been fixed in the 4.7 dev period.

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94389: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   99 days
Testing same since93977  2016-05-10 11:09:16 Z5 days   10 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Hi,

I've configured xen 4.6.0 with xsm enabled and use the default flask policy
to boot the dom0.
However, when I tried to create a domU, it will fail for following reasons:

>
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  denied  { send } for domid=0 scontext=system_u:system_r:dom0_t
> tcontext=system_u:system_r:dom0_t tclass=event
> (XEN) avc:  granted  { load_policy } for domid=0
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:security_t
> tclass=security
> (XEN) avc:  granted  { load_policy } for domid=0
> scontext=system_u:system_r:dom0_t tcontext=system_u:system_r:security_t
> tclass=security


So I added following rules to xen.te, which is achived by 'sudo xl dmesg |
grep avc | audit2allow'

>
> allow dom0_t xen_t:domain getdomaininfo;
> allow dom0_t xen_t:event send;
> allow dom0_t xen_t:grant copy;
> allow dom0_t xen_t:hvm { trackdirtyvram irqlevel };
> allow dom0_t xen_t:domain { destroy pause };
> allow dom0_t self:event send;


And recompiled the flask policy and load it using 'xl loadpolicy', however,
the creation of domU (both hvm and pv, with or without seclable) will still
fail for the following reasons, even though there are no avc violations.

$ sudo xl create ~/xen-config/ubuntu-hvm3
> Parsing config from /home/john/xen-config/ubuntu-hvm
> libxl: error: libxl_device.c:952:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/5/51712
> libxl: error: libxl_device.c:952:device_backend_callback: unable to add
> device with path /local/domain/0/backend/vbd/5/5632
> libxl: error: libxl_create.c:1174:domcreate_launch_dm: unable to add disk
> devices
> libxl: error: libxl_dm.c:1956:kill_device_model: unable to find device
> model pid in /local/domain/5/image/device-model-pid
> libxl: error: libxl.c:1628:libxl__destroy_domid:
> libxl__destroy_device_model failed for 5
> libxl: error: libxl_device.c:952:device_backend_callback: unable to remove
> device with path /local/domain/0/backend/vbd/5/51712
> libxl: error: libxl_device.c:952:device_backend_callback: unable to remove
> device with path /local/domain/0/backend/vbd/5/5632
> libxl: error: libxl.c:1665:devices_destroy_cb: libxl__devices_destroy
> failed for 5
> libxl: error: libxl.c:1591:libxl__destroy_domid: non-existant domain 5
> libxl: error: libxl.c:1549:domain_destroy_callback: unable to destroy
> guest with domid 5
> libxl: error: libxl.c:1476:domain_destroy_cb: destruction of domain 5
> failed


When the xsm is disabled, the creation succeed. What are these errors mean
anyway?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-coverity test] 94390: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73
baseline version:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47

Last test of basis94026  2016-05-11 09:19:01 Z4 days
Testing same since94390  2016-05-15 09:18:54 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  George Dunlap 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Olaf Hering 
  Paul Durrant 
  Wei Liu 

jobs:
 coverity-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 :

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

[Xen-devel] [xen-4.6-testing test] 94317: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93932
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93932

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm   3 host-install(3)  broken in 94232 pass in 94317
 test-amd64-i386-xl-raw3 host-install(3)   broken pass in 94232
 test-amd64-amd64-xl-qemut-debianhvm-amd64 9 debian-hvm-install fail in 94232 
pass in 94317
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail pass in 
94232
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail pass in 94232

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

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

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z5 days
Failing since 94000  2016-05-10 18:10:33 Z4 days6 attempts
Testing same since94036  2016-05-11 15:51:26 Z3 days5 attempts


People who touched revisions under test:
  Ian Jackson 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  159 days
Failing since 65593  2015-12-08 23:44:51 Z  158 days  260 attempts
Testing same since94150  2016-05-14 05:42:59 Z1 days4 attempts


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-boot  fail REGR. vs. 94142

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

version targeted for testing:
 libvirt  4b3a46ca6a8e836b75801bd27198c28cfe33f698
baseline version:
 libvirt  9055faebd426b44ad2c3bb97d6b8b0dd3496ab35

Last test of basis94142  2016-05-14 04:22:47 Z1 days
Testing same since94338  2016-05-15 04:20:41 Z0 days1 attempts


People who touched revisions under test:
  Michal Privoznik 

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



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

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

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

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


Not pushing.


commit 4b3a46ca6a8e836b75801bd27198c28cfe33f698
Author: Michal Privoznik 
Date:   Mon Apr 18 16:15:35 2016 +0200

tests: Introduce check-file-access.pl

This script will check output generated by virtestmock against a
white list. All non matching records found are printed out. So
far, the white list is rather sparse at the moment.
This test should be ran only after all other tests finished, and
should cleanup the temporary file before their execution. Because
I'm unable to reflect these requirements in Makefile.am
correctly, I've introduced new target 'check-access' under which
this test is available.

Signed-off-by: Michal Privoznik 

[Xen-devel] [qemu-upstream-4.3-testing test] 94335: trouble: blocked/broken

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   98 days
Testing same since93977  2016-05-10 11:09:16 Z4 days9 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

[Xen-devel] [xen-4.5-testing test] 94290: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 94135 pass 
in 94290
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 94135 
pass in 94290
 test-amd64-amd64-xl-qcow2 9 debian-di-install   fail pass in 94135
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94135

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 94135 like 93989
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93928
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989

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

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z4 days
Testing same since94030  2016-05-11 13:08:55 Z3 days5 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44402
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44402
 build-armhf   3 host-install(3) broken REGR. vs. 44402
 test-amd64-amd64-libvirt 11 guest-start   fail REGR. vs. 44402
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail REGR. vs. 44402

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

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

version targeted for testing:
 qemuu70f87e0f0aa04f764dabaeb3ed71ff195748076a
baseline version:
 qemuu860a3b34854d8abe9af9f1eb584691de926ce897

Last test of basis44402  2016-05-10 21:54:42 Z4 days
Testing same since44417  2016-05-14 23:28:33 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Alex Bennée 
  Aurelien Jarno 
  Changlong Xie 
  Cole Robinson 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Edgar E. Iglesias 
  Emilio G. Cota 
  Eric Blake 
  Fam Zheng 
  Gerd Hoffmann 
  Gonglei 
  Isaac Lozano <109loza...@gmail.com>
  Janne Karhunen 
  Jean-Christophe Dubois 
  Kevin Wolf 
  Leon Alrae 
  Markus Armbruster 
  Max Reitz 
  Md Haris Iqbal 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Maydell 
  Pooja Dhannawat 
  Ren Kimura 
  Richard Henderson 
  Roman Kagan 
  Sascha Silbe 
  Sergey Fedorov 
  Sergey Fedorov 
  Sergey Sorokin 
  Shannon Zhao 
  Stefan Hajnoczi 
  Stefan Weil 
  Sylvain Garrigues 
  Wei Jiangang 
  Wen Congyang 
  xiaoqiang zhao 
  xiaoqiang.zhao