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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  4 host-ping-check-native   fail REGR. vs. 107325

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107325
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107325

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  fd6e3f48ede2e3a01ef849ea4411d6507515956e
baseline version:
 libvirt  4c661a944d75638db76483bbd058981b4c0595a8

Last test of basis   107325  2017-04-09 17:17:18 Z1 days
Testing same since   107353  2017-04-10 16:31:08 Z0 days1 attempts


People who touched revisions under test:
  John Ferlan 
  Marc Hartmayer 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 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-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 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 

[Xen-devel] null domains after xl destroy

[Glenn Enright]

Hi all

We are seeing an odd issue with domu domains from xl destroy, under 
recent 4.9 kernels a (null) domain is left behind.


This has occurred on a variety of hardware, with no obvious commonality.

4.4.55 does not show this behavior.

On my test machine I have the following packages installed under 
centos6, from https://xen.crc.id.au/


~]# rpm -qa | grep xen
xen47-licenses-4.7.2-4.el6.x86_64
xen47-4.7.2-4.el6.x86_64
kernel-xen-4.9.21-1.el6xen.x86_64
xen47-ocaml-4.7.2-4.el6.x86_64
xen47-libs-4.7.2-4.el6.x86_64
xen47-libcacard-4.7.2-4.el6.x86_64
xen47-hypervisor-4.7.2-4.el6.x86_64
xen47-runtime-4.7.2-4.el6.x86_64
kernel-xen-firmware-4.9.21-1.el6xen.x86_64

I've also replicated the issue with 4.9.17 and 4.9.20

To replicate, on a cleanly booted dom0 with one pv VM, I run the 
following on the VM


{
while true; do
 dd bs=1M count=512 if=/dev/zero of=test conv=fdatasync
done
}

Then on the dom0 I do this sequence to reliably get a null domain. This 
occurs with oxenstored and xenstored both.


{
xl sync 1
xl destroy 1
}

xl list then renders something like ...

(null)   1 4 4 --p--d 
   9.8 0


From what I can see it appears to be disk related. Affected VMs all use 
lvm storage for their boot disk. lvdisplay of the affected lv shows that 
the lv has is being help open by something.


~]# lvdisplay test/test.img | grep open
  # open 1

I've not been able to determine what that thing is as yet. I tried lsof, 
dmsetup, various lv tools. Waiting for the disk to be released does not 
work.


~]# xl list
NameID   Mem VCPUs  State 
Time(s)
Domain-0 0  1512 2 r- 
  29.0
(null)   1 4 4 --p--d 
   9.8


xenstore-ls reports nothing for the null domain id that I can see.

I can later start and restart the affected domain, but direct operations 
on the lv such as removing it don't work since it is 'busy'.


Does anyone have thoughts on this? Happy to provide any output that 
might be useful, not subscribed to this list so please CC.


Regards, Glenn
http://rimuhosting.com

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

Re: [Xen-devel] [PATCH] x86/xen/time: set ->min_delta_ticks and ->max_delta_ticks

[Juergen Gross]

On 30/03/17 22:06, Nicolai Stange wrote:
> In preparation for making the clockevents core NTP correction aware,
> all clockevent device drivers must set ->min_delta_ticks and
> ->max_delta_ticks rather than ->min_delta_ns and ->max_delta_ns: a
> clockevent device's rate is going to change dynamically and thus, the
> ratio of ns to ticks ceases to stay invariant.
> 
> Make the x86 arch's xen clockevent driver initialize these fields properly.
> 
> This patch alone doesn't introduce any change in functionality as the
> clockevents core still looks exclusively at the (untouched) ->min_delta_ns
> and ->max_delta_ns. As soon as this has changed, a followup patch will
> purge the initialization of ->min_delta_ns and ->max_delta_ns from this
> driver.
> 
> Signed-off-by: Nicolai Stange 

Applied to xen/tip for-linus-4.12


Thanks,

Juergen


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

[Xen-devel] [linux-next test] 107332: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-boot   fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-rumprun-amd64  6 xen-boot   fail REGR. vs. 107284
 test-amd64-i386-freebsd10-amd64  6 xen-boot  fail REGR. vs. 107284
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 107284
 test-amd64-amd64-qemuu-nested-intel  6 xen-boot  fail REGR. vs. 107284
 test-amd64-amd64-pair 9 xen-boot/src_hostfail REGR. vs. 107284
 test-amd64-amd64-pair10 xen-boot/dst_hostfail REGR. vs. 107284
 test-amd64-i386-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 107284
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 107284
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host   fail REGR. vs. 107284
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host   fail REGR. vs. 107284
 test-amd64-amd64-xl   6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-libvirt   6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-libvirt-xsm   6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-libvirt  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-boot   fail REGR. vs. 107284
 test-amd64-amd64-i386-pvgrub  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-pvh-intel  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107284
 test-amd64-amd64-libvirt-xsm  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-amd64-pvgrub  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 107284
 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 107284
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 107284
 test-amd64-amd64-pygrub   6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-xsm   6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-libvirt-vhd  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-credit2   6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 107284
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-rumprun-i386  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-bootfail REGR. vs. 107284
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107284
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-xl-pvh-amd   6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-multivcpu  6 xen-bootfail REGR. vs. 107284
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-boot   fail REGR. vs. 107284
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
107284
 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 107284
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 107284
 test-amd64-amd64-qemuu-nested-amd  6 xen-boot   

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[hrg]

On Tue, Apr 11, 2017 at 3:50 AM, Stefano Stabellini
 wrote:
> On Mon, 10 Apr 2017, Stefano Stabellini wrote:
>> On Mon, 10 Apr 2017, hrg wrote:
>> > On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
>> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
>> > >> Hi,
>> > >>
>> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
>> > >> instead of first level entry (if map to rom other than guest memory
>> > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned
>> > >> out memory, qemu did not invalidate cache entries in linked
>> > >> list(entry->next), so when VM balloon back in memory, gfns probably
>> > >> mapped to different mfns, thus if guest asks device to DMA to these
>> > >> GPA, qemu may DMA to stale MFNs.
>> > >>
>> > >> So I think in xen_invalidate_map_cache() linked lists should also be
>> > >> checked and invalidated.
>> > >>
>> > >> What’s your opinion? Is this a bug? Is my analyze correct?
>>
>> Yes, you are right. We need to go through the list for each element of
>> the array in xen_invalidate_map_cache. Can you come up with a patch?
>
> I spoke too soon. In the regular case there should be no locked mappings
> when xen_invalidate_map_cache is called (see the DPRINTF warning at the
> beginning of the functions). Without locked mappings, there should never
> be more than one element in each list (see xen_map_cache_unlocked:
> entry->lock == true is a necessary condition to append a new entry to
> the list, otherwise it is just remapped).
>
> Can you confirm that what you are seeing are locked mappings
> when xen_invalidate_map_cache is called? To find out, enable the DPRINTK
> by turning it into a printf or by defininig MAPCACHE_DEBUG.

In fact, I think the DPRINTF above is incorrect too. In
pci_add_option_rom(), rtl8139 rom is locked mapped in
pci_add_option_rom->memory_region_get_ram_ptr (after
memory_region_init_ram). So actually I think we should remove the
DPRINTF warning as it is normal.

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

[Xen-devel] [xtf test] 107352: all pass - PUSHED

[osstest service owner]

flight 107352 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/107352/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  7a69524b288907b6d29581ddc1152b1324e13f73
baseline version:
 xtf  ad3af7b1acce6cf396cdb397b2ce3eb9c30e0691

Last test of basis   107244  2017-04-06 14:44:18 Z4 days
Testing same since   107352  2017-04-10 16:13:57 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   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=xtf
+ revision=7a69524b288907b6d29581ddc1152b1324e13f73
+ . ./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 xtf 
7a69524b288907b6d29581ddc1152b1324e13f73
+ branch=xtf
+ revision=7a69524b288907b6d29581ddc1152b1324e13f73
+ . ./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=xtf
+ xenbranch=xen-unstable
+ '[' xxtf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x7a69524b288907b6d29581ddc1152b1324e13f73 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' 

[Xen-devel] [Outreachy] Interested in Xen Code Review Dashboard

[Candida Haynes]

Hi,

I apologize to anyone who receives this twice - I received an
error/bounce message.
I am writing because I am interested in applying to Outreachy and
contributing to the Xen Code Review Dashboard. My most formal experience
with open source was in 2014 when I participated in the Ascend Project.

I know I need to make a small code contribution so I am here to find out
what to do. I have used Mercurial and Git, and have been studying
JavaScript and Python so I am comfortable switching contexts and learning
how different software works. I've also been exposed to Go, Ruby, Elm, and
Swift through tutorials and immersive weekend workshops. My JavaScript
stack is Node, Express, and PostgreSQL. I've interacted with Bugzilla and
(briefly) with Try-Server. I enjoy working with data and have
participated in PyData, but I want to learn more. I think this project
lends itself to that. Can anyone advise on how to get started on the "small
contribution" or if there is anyone else I need to add to this e-mail?
Thanks a lot!

Candida Haynes / Didit
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [xen-4.7-testing test] 107333: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107233
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107233
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107233
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107233
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107233
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107233
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107233

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   5 xen-buildfail   never pass
 build-arm64-xsm   5 xen-buildfail   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-i386-libvirt  12 migrate-support-checkfail   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-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-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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 build-arm64-pvops 5 kernel-build fail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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

version targeted for testing:
 xen  469fc7e9b62a302d95509163e5b9ac444c103e14
baseline version:
 xen  6cf0da59518356b399cf178b36e5af7403ee5ece

Last test of basis   107233  2017-04-06 10:18:59 Z4 days
Testing same since   107283  2017-04-08 00:02:48 Z3 days3 attempts


People who touched revisions under test:
  Stefano Stabellini 

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

Re: [Xen-devel] [PATCH v3] ns16550-Add-command-line-parsing-adjustments

[Paratey, Swapnil]

Hi Jan,

Thank you very much for your review comments.
I need a few clarifications to move forward.


On 4/3/2017 6:55 AM, Jan Beulich wrote:

On 31.03.17 at 17:42,  wrote:

The title needs improvement - it doesn't really reflect what the
patch does.


I apologize for this. I kept the name same since it was the third version
of the patch and thought that it would help in tracking the evolution of
the patch.

The new proposed title:
- ns16550: Support for UART parameters to be specified as name-value pairs

Please let me know about
- how to track the evolution of the patch (whether to mention [PATCH v4])
- whether this patch should mention ChangeSets from the previous versions
- if the subject should be more precise and whether I should respect Git's
60-character recommended limit for patch subjects.


Add name=value parsing options for com1 and com2 to add flexibility
in setting register values for MMIO UART devices.

Maintain backward compatibility with previous positional parameter
specfications.

eg. com1=115200,8n1,0x3f8,4
eg. com1=baud=115200,parity=n,reg_width=4,reg_shift=2,irq=4
eg. com1=115200,8n1,0x3f8,4,reg_width=4,reg_shift=2

I would have been nice if you split the new format handling from
the addition of the new sub-options.


--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -324,6 +324,43 @@ Both option `com1` and `com2` follow the same format.
  
  A typical setup for most situations might be `com1=115200,8n1`
  
+In addition to the above positional specification for UART parameters,

+name=value pair specfications are also supported. This is used to add
+flexibility for UART devices which require additional UART parameter
+configurations.
+
+The comma separation still delineates positional parameters. Hence,
+unless the parameter is explicitly specified with name=value option, it
+will be considered a positional parameter.
+
+The syntax consists of
+com1=(comma-separated positional parameters),(comma separated name-value pairs)
+
+The accepted name keywords for name=value pairs are
+ * `baud` - accepts integer baud rate (eg. 115200) or `auto`
+ * `bridge`- accepts xx:xx:xx. Similar to bridge-bdf in positional parameters.
+ notation is ::
+ * `clock_hz`- accepts large integers to setup UART clock frequencies.
+   Do note - these values are multiplied by 16.
+ * `data_bits` - integer between 5 and 8
+ * `dev` - accepted values are `pci` OR `amt`. If this option
+   is used to specify if the serial device is pci-based. The io_base
+   cannot be specified when `dev=pci` or `dev=amt` is used.
+ * `io_base` - accepts integer which specified IO base port for UART registers
+ * `irq` - IRQ number to use
+ * `parity` - accepted values are same as positional parameters
+ * `port` - used to specify which port the PCI serial device is located on
+notation is xx:xx:xx ::

Everywhere above PCI device specifications wrongly use : instead
of . as separator between device and function.


+ * `reg_shift` - register shifts required to set UART registers
+ * `reg_width` - register width required to set UART registers
+ (only accepts 1 and 4)
+ * `stop_bits` - only accepts 1 or 2 for the number of stop bits

Since these are all new anyway, can we please use - instead of _
as separator characters inside sub-option names? Dashed are
slightly easier to type than underscores on most keyboards.


--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -48,7 +48,7 @@ static void __init assign_integer_param(
  
  void __init cmdline_parse(const char *cmdline)

  {
-char opt[100], *optval, *optkey, *q;
+char opt[512], *optval, *optkey, *q;

Why not MAX_CMDLINE_LENGTH? But anyway both this and ...


--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -38,11 +38,27 @@
   * can be specified in place of a numeric baud rate. Polled mode is specified
   * by requesting irq 0.
   */
-static char __initdata opt_com1[30] = "";
-static char __initdata opt_com2[30] = "";
+static char __initdata opt_com1[MAX_CMDLINE_LENGTH] = "";
+static char __initdata opt_com2[MAX_CMDLINE_LENGTH] = "";

... this seems to be excessive growth.


Is 128 bytes a good number? It easily accommodates all the UART command line
parameters.


+typedef enum e_serial_param_type {
+BAUD=0,

Stray "=0". Also I don't think enumerator identifiers should be all
capitals.


+BRIDGEBDF,
+CLOCKHZ,
+DATABITS,
+DEVICE,
+IO_BASE,
+IRQ,
+PARITY,
+PORTBDF,
+REG_SHIFT,
+REG_WIDTH,
+STOPBITS,
+__MAX_SERIAL_PARAM /* introduce more parameters before this line */

Stray double underscores.


@@ -77,6 +93,29 @@ static struct ns16550 {
  #endif
  } ns16550_com[2] = { { 0 } };
  
+struct serial_param_var

+{
+char *sp_name;

const


+serial_param_type sp_type;
+};
+
+/* enum struct keeping a table of all accepted parameter names
+ * for parsing cmdline for serial 

Re: [Xen-devel] ITS emulation race conditions

[Stefano Stabellini]

On Mon, 10 Apr 2017, Andre Przywara wrote:
> Hi,
> 
> On 10/04/17 00:12, André Przywara wrote:
> > Hi,
> > 
> > I wanted to run some ideas on how to prevent the race conditions we are
> > facing with the ITS emulation and removing devices and/or LPIs.
> > I think Stefano's idea of tagging a discarded LPI is the key, but still
> > some details are left to be solved.
> > I think we are dealing with two issues:
> > 1) A guest's DISCARD can race with in incoming LPI.
> > Ideally DISCARD would remove the host LPI -> vLPI connection (in the
> > host_lpis table), so any new incoming (host) LPI would simply be
> > discarded very early in gicv3_do_LPI() without ever resolving into a
> > virtual LPI. Now while this removal is atomic, we could have just missed
> > an incoming LPI, so the old virtual LPI would still traverse down the
> > VGIC with a "doomed" virtual LPI ID.
> > I wonder if that could be solved by a "crosswise" check:
> > - The DISCARD handler *first* tags the pending_irq as "UNMAPPED", *then*
> > removes the host_lpis connectin.
> > - do_LPI() reads the host_lpis() array, *then* checks the UNMAPPED tag
> > in the corresponding pending_irq (or lets vgic_vcpu_inject_irq() do that).
> > With this setup the DISCARD handler can assume that no new virtual LPI
> > instances enter the VGIC afterwards.
> >
> > 2) An unmapped LPI might still be in use by the VGIC, foremost might
> > still be in an LR.
> > Tagging the pending_irq should solve this in general. Whenever a VGIC
> > function finds the UNMAPPED tag, it does not process the vIRQ, but
> > retires it. For simplicity we might limit this to handling when a VCPU
> > exists and an LR gets cleaned up: If we hit a tagged pending_irq here,
> > we clean the LR, remove the pending_irq from all lists and signal the
> > ITS emulation that this pending_irq is now ready to be removed (by
> > calling some kind of cleanup_lpi() function, for instance).
> > The ITS code can then remove the struct pending_irq from the radix tree.
> > MAPD(V=0) is now using this to tag all still mapped events as
> > "UNMAPPED", the counting down the "still alive" pending_irqs in
> > cleanup_lpi() until they reach zero. At this point it should be safe to
> > free the pend_irq array.
> > 
> > Does that sound like a plan?
> > Do I miss something here? Probably yes, hence I am asking ;-)
> 
> So there are two issues with this:
> - For doing the LPI cleanup, we would need to call a virtual ITS or
> virtual LPI specific function directly from gic.c. This looks like bad
> coding style, as it breaks the abstraction (calling a virtual LPI/ITS
> specific function from within gic.c)

This is just code organization, I am not worried about it. We might have
to register cleanup functions. The real problem to solve is below.


> - If we have a "DISCARD; MAPTI" sequence, targeting the same vLPI, while
> this vLPI is still in an LR (but not cleaned up until both commands have
> been handled), we end up with using the wrong pending_irq struct (the
> new one). (I assume the UNMAPPED tag would be cleared upon the new MAPTI).

It looks like "DISCARD; MAPTI" would be a problem even if we go with
"GIC: Add checks for NULL pointer pending_irq's", because instead of a
NULL pending_irq, we could get the new pending_irq, the one backing the
same vlpi but a different eventid.


> Can this create problems?
> I see two possibilities:
> a) the old vLPI is still pending in the LR: as the new LR would be
> pristine, the code in update_one_lr() would just clean the QUEUED bit,
> but not do anything further. The LR would be kept as used by this vLPI,
> with the state still set to GICH_LR_PENDING. Upon re-entering the VCPU
> this would make the new vLPI pending.
> b) the old vLPI has been EOIed: the new LR would be pristine, the code
> in update_one_lr() would try to clean it up anyway, which should not
> hurt, AFAICT.

This cannot be allowed to happen. We have to keep a consistent internal
state at all times: we cannot change the vlpi mapping in pend_lpi_tree
before the old vlpi is completed discarded. We cannot have a vlpi marked
as "UNMAPPED", but still alive in an LR, while vlpi_to_pending already
returns the new vlpi.

We have a number of possible approaches, I'll mark them with [letter].


[a] On DISCARD we do everything we can to remove the vlpi from
everywhere:

- if pending_irq is in lr_queue, remove it from the list
- if the vlpi is in an LR register as pending (not active, see below),
  remove it from the LR (see the code in gic_restore_pending_irqs, under
  "No more free LRs: find a lower priority irq to evict")
- remove pending_irq from inflight
- remove pending_irq from pend_lpi_tree

At this stage there should be no more traces of the vlpi/pending_irq
anywhere.

What do we do if a "DISCARD; MAPTI" pair of commands is issued while the
old vlpi is still ACTIVE in an LR?  ACTIVE means that the guest is still
handling the irq and hasn't even EOIed it yet. I know that physical LPIs
have no active state, but what 

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107219

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107219
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107219
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107219
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107219
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107219
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107219

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

version targeted for testing:
 qemuu5daf9b3025baef10ee7b77daa003d5696b58d5dc
baseline version:
 qemuu1fde6ee885d3e778acb326cab9f7037939839537

Last test of basis   107219  2017-04-05 15:36:01 Z5 days
Failing since107250  2017-04-06 17:17:05 Z4 days4 attempts
Testing same since   107277  2017-04-07 19:47:31 Z3 days3 attempts


People who touched revisions under test:
  Alex Williamson 
  Fam Zheng 
  Jeff Cody 
  Kashyap Chamarthy 
  Kevin Wolf 
  Max Reitz 
  Paolo Bonzini 
  Peter Maydell 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107247
 build-armhf-xsm   5 xen-buildfail REGR. vs. 107247

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107247
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107247
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107247
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107247
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107247
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107247
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107247

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

version targeted for testing:
 xen  6772d50a50ca4315f658e33194f966e48d180384
baseline version:
 xen  de5f36a266b41cafc47c876700a9c1a494aa296f

Last test of basis   107247  2017-04-06 15:46:51 Z4 days
Failing since107275  2017-04-07 17:57:44 Z3 days3 attempts
Testing same since   107315  2017-04-08 22:17:02 Z1 days2 attempts


People who touched revisions under test:
  Adrian Pop 
  Andre Przywara 
  Andrew Cooper 
  Chao Gao 
  Daniel De Graaf 
  Daniel Kiper 
  Dario Faggioli 
  Feng Wu 
  George Dunlap 
  Haozhong Zhang 
  Ian Jackson 
  Ian Jackson 
  Jan Beulich 
  Jan Beulich  [x86]
  Julien Grall 
  Kevin Tian 
  Mohit Gambhir 
  Paul Durrant 
  Razvan Cojocaru 
  Roger Pau Monné 
  Ronald Rojas 
  Sergej Proskurin 

Re: [Xen-devel] [PATCH v2] xen, kdump: handle pv domain in paddr_vmcoreinfo_note()

[Daniel Kiper]

On Fri, Apr 07, 2017 at 11:16:22AM +0200, Petr Tesarik wrote:
> On Wed, 5 Apr 2017 13:13:00 +0200
> Petr Tesarik  wrote:
>
> > On Tue, 4 Apr 2017 12:42:53 -0700 (PDT)
> > Daniel Kiper  wrote:
> >
> >[...]
> > > So, if Petr did relevant tests that is nice. However, then, IMO, this
> > > patch begs Petr Tested-by.
> >
> > Actually, I tested with this patch applied on top of kernel 4.4 (SLES
> > 12 SP2). It matches what traditional Xen had always done, so I am quite
> > confident it will work with a later kernel, but to give my Tested-by,
> > let me first re-run the test on master, hopefully until today EOB.
>
> It took me much longer than anticipated (I had some trouble setting up
> the host again), but I can confirm that the patch works as expected on

No problem. I know how it works.

> top of 4.11-rc5.

Great!

> Without the patch, makedumpfile in the crash kernel complains:
>
> /proc/vmcore doesn't contain vmcoreinfo.

Though, I would like to ask you to do crash tool tests too.
Could you do that?

> With the patch applied, dumping still fails later because of an
> unrelated bug in makedumpfile, but I was able to extract the kernel
> message buffer with "makedumpfile --dump-dmesg". This already confirms
> VMCOREINFO presence and usability.

Is it Xen specific issue or more generic one?

Daniel

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
baseline version:
 ovmf c137d95081690d4877fbeb5f1856972e84ac32f2

Last test of basis71166  2017-04-09 07:16:55 Z1 days
Testing same since71169  2017-04-10 14:21:51 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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



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

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

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


Push not applicable.


commit 1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
Author: Hao Wu 
Date:   Fri Apr 7 10:11:49 2017 +0800

AppPkg/Applications/Python/PyMod-2.7.2: Replace non-ascii characters

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

Contributed-under: TianoCore Contribution Agreement 1.0
Contributed-by: gray.wang 
Signed-off-by: Hao Wu 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[Stefano Stabellini]

On Mon, 10 Apr 2017, Stefano Stabellini wrote:
> On Mon, 10 Apr 2017, hrg wrote:
> > On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
> > > On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
> > >> Hi,
> > >>
> > >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
> > >> instead of first level entry (if map to rom other than guest memory
> > >> comes first), while in xen_invalidate_map_cache(), when VM ballooned
> > >> out memory, qemu did not invalidate cache entries in linked
> > >> list(entry->next), so when VM balloon back in memory, gfns probably
> > >> mapped to different mfns, thus if guest asks device to DMA to these
> > >> GPA, qemu may DMA to stale MFNs.
> > >>
> > >> So I think in xen_invalidate_map_cache() linked lists should also be
> > >> checked and invalidated.
> > >>
> > >> What’s your opinion? Is this a bug? Is my analyze correct?
> 
> Yes, you are right. We need to go through the list for each element of
> the array in xen_invalidate_map_cache. Can you come up with a patch?

I spoke too soon. In the regular case there should be no locked mappings
when xen_invalidate_map_cache is called (see the DPRINTF warning at the
beginning of the functions). Without locked mappings, there should never
be more than one element in each list (see xen_map_cache_unlocked:
entry->lock == true is a necessary condition to append a new entry to
the list, otherwise it is just remapped).

Can you confirm that what you are seeing are locked mappings
when xen_invalidate_map_cache is called? To find out, enable the DPRINTK
by turning it into a printf or by defininig MAPCACHE_DEBUG.___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH] kexec: Add spinlock for the whole hypercall

[Eric DeVolder]

When we concurrently try to unload and load crash
images we eventually get:

 Xen call trace:
[] machine_kexec_add_page+0x3a0/0x3fa
[] machine_kexec_load+0xdb/0x107
[] kexec.c#kexec_load_slot+0x11/0x42
[] kexec.c#kexec_load+0x119/0x150
[] kexec.c#do_kexec_op_internal+0xab/0xcf
[] do_kexec_op+0xe/0x1e
[] pv_hypercall+0x20a/0x44a
[] cpufreq.c#test_all_events+0/0x30

 Pagetable walk from 820040088320:
  L4[0x104] = 0002979d1063 
  L3[0x001] = 0002979d0063 
  L2[0x000] = 0002979c7063 
  L1[0x088] = 80037a91ede97063 

The interesting thing is that the page bits (063) look legit.

The operation on which we blow up is us trying to write
in the L1 and finding that the L2 entry points to some
bizzare MFN. It stinks of a race, and it looks like
the issue is due to no concurrency locks when dealing
with the crash kernel space.

Specifically we concurrently call kimage_alloc_crash_control_page
which iterates over the kexec_crash_area.start -> kexec_crash_area.size
and once found:

  if ( page )
  {
  image->next_crash_page = hole_end;
  clear_domain_page(_mfn(page_to_mfn(page)));
  }

clears. Since the parameters of what MFN to use are provided
by the callers (and the area to search is bounded) the the 'page'
is probably the same. So #1 we concurrently clear the
'control_code_page'.

The next step is us passing this 'control_code_page' to
machine_kexec_add_page. This function requires the MFNs:
page_to_maddr(image->control_code_page).

And this would always return the same virtual address, as
the MFN of the control_code_page is inside of the
kexec_crash_area.start -> kexec_crash_area.size area.

Then machine_kexec_add_page updates the L1 .. which can be done
concurrently and on subsequent calls we mangle it up.

This is all a theory at this time, but testing reveals
that adding the spinlock at the kexec hypercall fixes
the crash.

An alternative solution would be to only add the spinlock
on paths that touch the CRASH region and not everything.

NOTE: The spinlock in kexec_swap_images() was removed as
this function is only reachable on the kexec call, which is
now entirely protected by a spinlock, thus the local spinlock
is no longer necessary.

NOTE: This patch follows 5c5216 (kexec: clear kexec_image slot
when unloading kexec image) to prevent crashes during
simultaneous load/unloads.

Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Eric DeVolder 
Reviewed-by: Daniel Kiper 
---
 xen/common/kexec.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/xen/common/kexec.c b/xen/common/kexec.c
index 072cc8e..5bcc356 100644
--- a/xen/common/kexec.c
+++ b/xen/common/kexec.c
@@ -819,7 +819,6 @@ static int kexec_exec(XEN_GUEST_HANDLE_PARAM(void) uarg)
 static int kexec_swap_images(int type, struct kexec_image *new,
  struct kexec_image **old)
 {
-static DEFINE_SPINLOCK(kexec_lock);
 int base, bit, pos;
 int new_slot, old_slot;
 
@@ -831,8 +830,6 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 if ( kexec_load_get_bits(type, , ) )
 return -EINVAL;
 
-spin_lock(_lock);
-
 pos = (test_bit(bit, _flags) != 0);
 old_slot = base + pos;
 new_slot = base + !pos;
@@ -845,8 +842,6 @@ static int kexec_swap_images(int type, struct kexec_image 
*new,
 clear_bit(old_slot, _flags);
 *old = kexec_image[old_slot];
 
-spin_unlock(_lock);
-
 return 0;
 }
 
@@ -1187,12 +1182,22 @@ static int do_kexec_op_internal(unsigned long op,
 XEN_GUEST_HANDLE_PARAM(void) uarg,
 bool_t compat)
 {
+static DEFINE_SPINLOCK(kexec_lock);
 int ret = -EINVAL;
 
 ret = xsm_kexec(XSM_PRIV);
 if ( ret )
 return ret;
 
+/*
+ * Because we write directly to the reserved memory
+ * region when loading crash kernels we need a spinlock here to
+ * prevent multiple crash kernels from attempting to load
+ * simultaneously, and to prevent a crash kernel from loading
+ * over the top of a in use crash kernel.
+ */
+spin_lock(_lock);
+
 switch ( op )
 {
 case KEXEC_CMD_kexec_get_range:
@@ -1227,6 +1232,8 @@ static int do_kexec_op_internal(unsigned long op,
 break;
 }
 
+spin_unlock(_lock);
+
 return ret;
 }
 
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Josh Poimboeuf]

On Mon, Apr 10, 2017 at 01:23:46PM +0200, Jiri Slaby wrote:
> On 03/22/2017, 04:44 PM, Jiri Slaby wrote:
> > On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
> >> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
> >>> Somewhere END was used to end a function, elsewhere, nothing was used.
> >>> So unify it and mark them all by SYM_FUNC_END.
> >>>
> >>> Signed-off-by: Jiri Slaby 
> >>
> >> For me these patches would be easier to review if the SYM_FUNC_START and
> >> SYM_FUNC_END pairs for a given function are done in the same patch.
> > 
> > This patchset was intended to make everything paired with minimum
> > changes. I certainly can change also counter-elements of each
> > added/changed one if you prefer.
> 
> So do really you want me to use the new macros while I am
> adding/changing the counter-macro? Is there anything else blocking the
> merge of the patches?

The code should be in a mergeable state after each patch.  If only
patches 1-3 were merged, the code would be in an inconsistent state,
with some functions having confusing ENTRY/SYM_FUNC_END pairs.  That
complicates git history and also makes it harder to review each patch.

It would be cleaner to separate things out.  First, convert ENTRY/END
functions to use ENDPROC, which is a minor bug fix.  Then they can be
converted to the new SYM_FUNC_START/END macros in a separate patch.

-- 
Josh

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

[Xen-devel] [linux-4.9 test] 107328: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107238

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-vhd 9 debian-di-install fail in 107313 pass in 107328
 test-arm64-arm64-libvirt-qcow2 9 debian-di-install fail in 107313 pass in 
107328
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 107313 pass 
in 107328
 test-armhf-armhf-xl-xsm   6 xen-boot   fail pass in 107313

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop   fail REGR. vs. 107238
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 107313 like 
107238
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107238
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107238
 test-armhf-armhf-xl   6 xen-boot fail  like 107238
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107238

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-xsm 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl 12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-check fail in 107313 never 
pass
 test-armhf-armhf-xl 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-check fail in 107313 never 
pass
 test-armhf-armhf-xl-rtds12 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 107313 never pass
 test-armhf-armhf-xl-vhd 11 migrate-support-check fail in 107313 never pass
 test-armhf-armhf-xl-vhd 12 saverestore-support-check fail in 107313 never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-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-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 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-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  

[Xen-devel] [xen-4.8-testing baseline-only test] 71168: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 71155
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71155
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71155
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71155

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-intel 17 capture-logs/l1(17) fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  e1c62cdf782085605ea1186912fc419dd9464027
baseline version:
 xen  ec7f9e1df2aa6cf8376d26eafca554c6521d2e7c

Last test of basis71155  2017-04-06 06:20:09 Z4 days
Testing same since71168  2017-04-10 10:46:43 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jonathan Davies 
  

Re: [Xen-devel] [Qemu-devel] [RFC/BUG] xen-mapcache: buggy invalidate map cache?

[Stefano Stabellini]

On Mon, 10 Apr 2017, hrg wrote:
> On Sun, Apr 9, 2017 at 11:55 PM, hrg  wrote:
> > On Sun, Apr 9, 2017 at 11:52 PM, hrg  wrote:
> >> Hi,
> >>
> >> In xen_map_cache_unlocked(), map to guest memory maybe in entry->next
> >> instead of first level entry (if map to rom other than guest memory
> >> comes first), while in xen_invalidate_map_cache(), when VM ballooned
> >> out memory, qemu did not invalidate cache entries in linked
> >> list(entry->next), so when VM balloon back in memory, gfns probably
> >> mapped to different mfns, thus if guest asks device to DMA to these
> >> GPA, qemu may DMA to stale MFNs.
> >>
> >> So I think in xen_invalidate_map_cache() linked lists should also be
> >> checked and invalidated.
> >>
> >> What’s your opinion? Is this a bug? Is my analyze correct?

Yes, you are right. We need to go through the list for each element of
the array in xen_invalidate_map_cache. Can you come up with a patch?___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

>> The following is meant as a real question without any prejudice:
>>
>> How old a Xen version do we want to support in the Linux kernel?
>>
>> - Only those being still maintained (meaning getting security fixes)

Definitely not this. 4.4 is the oldest version receiving official XSA
patches and it's only 3 years old.

>> - Versions max. X years after getting last security fixes (what value
>>   of X?)
>> - From version Y on (what value of Y?)
>> - All versions which we can think of
>>
>> I think we should answer this question in order to know what we can
>> remove in the Linux kernel without breaking something.
> Ideally, "All versions which we can think of", unless it becomes too
> difficult. In that case, I would switch to "From version Y" where Y is
> not troublesome to support (and older than the oldest supported Xen
> release).

So Oracle, for example, officially supports its virtualization product
for 8 to 10 years.

Which means that 10 years after a product is released it is possible to
see new version of Linux on  such a product (although realistically
vendors may generally support more limited sets of guests).

If we are to follow this line of reasoning Xen 3.4 needs to be supported
--- it was released in 2009.

-boris


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

[Xen-devel] [xen-unstable-smoke test] 107355: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  17cd6621688bce9972d924264fd7aba44c31
baseline version:
 xen  ce70926b4f88d3f7510bd4699dc7fc3996539084

Last test of basis   107340  2017-04-10 15:02:39 Z0 days
Testing same since   107355  2017-04-10 17:01:24 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Roger Pau Monné 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=17cd6621688bce9972d924264fd7aba44c31
+ . ./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 
17cd6621688bce9972d924264fd7aba44c31
+ branch=xen-unstable-smoke
+ revision=17cd6621688bce9972d924264fd7aba44c31
+ . ./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.8-testing
+ '[' x17cd6621688bce9972d924264fd7aba44c31 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : 

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Stefano Stabellini]

On Mon, 10 Apr 2017, Juergen Gross wrote:
> On 10/04/17 17:32, Raslan, KarimAllah wrote:
> > 
> > Ahmed, Karim Allah
> > karah...@amazon.de
> > 
> > 
> > 
> >> On Apr 10, 2017, at 3:57 PM, Juergen Gross  wrote:
> >>
> >> On 10/04/17 15:47, Boris Ostrovsky wrote:
> >>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>  On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> > On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> >> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> >>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>  tl;dr:
>  Please apply
> 
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> partially revert "xen: Remove event channel notification through
>   Xen PCI platform device"
> 
>  to all stable branches which have a version of the original broken
>  commit.  This includes at least 4.9.y.
> 
>  Background:
> 
>  osstest service owner writes ("[linux-4.9 baseline test] 107238: 
>  tolerable FAIL"):
>  ...
> > test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
>  osstest doesn't consider this a regresion because it looks for
>  regressions within a branch, and this is the first test of Linux 4.9.
>  However, this is a regression from the kernel we are currently using.
> 
>  L1 dom0 console log:
>   
>  http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
> 
>  It seems to have got stuck halfway through booting.
> 
>  The message
>   (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
>  input to DOM0)
>  shows where osstest timed out on this test, and started its log
>  capture process (including collecting debug key output).
> 
>  Complete logs for this job here:
>   
>  http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
> 
>  Juergen Gross tells me that this is due to the lack of
>  da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
> 
>  Thanks,
>  Ian.
> 
>  PS: Stefano, Boris: did you already request a backport of this 
>  commit?
>  If not, why not ?
> >>> No, but this should indeed be backported to 4.9+
> >> Boris, are you going to do that?
> > Is there anything that needs to be done beyond just applying it to 4.9
> > (4.10 apparently already has it).
>  No, I don't think so. 4.9 already has the offending commit.
> >>>
> >>>
> >>> Looks like there will be a new version of the original patch
> >>> (72a9b186292) so we should hold off with backport request to 4.9:
> >>>
> >>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
> >>
> >> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> >> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> >> problem (after all the author admitted the bug isn't being hit in
> >> reality due to a short-circuit in the code)?
> > 
> > IMHO, even if 72a9b186292 has not been reworked we should completely revert 
> > it
> > not only partially revert it. Before this commit at least kernel 4.9+ would
> > work on older Xen versions (< 4.0) while now, it will not even boot.
> 
> The following is meant as a real question without any prejudice:
> 
> How old a Xen version do we want to support in the Linux kernel?
> 
> - Only those being still maintained (meaning getting security fixes)
> - Versions max. X years after getting last security fixes (what value
>   of X?)
> - From version Y on (what value of Y?)
> - All versions which we can think of
> 
> I think we should answer this question in order to know what we can
> remove in the Linux kernel without breaking something.

Ideally, "All versions which we can think of", unless it becomes too
difficult. In that case, I would switch to "From version Y" where Y is
not troublesome to support (and older than the oldest supported Xen
release).

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

Re: [Xen-devel] [PATCH v7 0/7] Xen transport for 9pfs frontend driver

[Stefano Stabellini]

On Mon, 10 Apr 2017, Juergen Gross wrote:
> On 05/04/17 21:03, Stefano Stabellini wrote:
> > Hi all,
> > 
> > This patch series implements a new transport for 9pfs, aimed at Xen
> > systems.
> > 
> > The transport is based on a traditional Xen frontend and backend drivers
> > pair. This patch series implements the frontend, which typically runs in
> > a regular unprivileged guest.
> > 
> > I also sent a series that implements the backend in userspace in QEMU,
> > which typically runs in Dom0 (but could also run in a another guest).
> > 
> > The frontend complies to the Xen transport for 9pfs specification
> > version 1, available here:
> > 
> > https://xenbits.xen.org/docs/unstable/misc/9pfs.html
> > 
> > 
> > The new Xen ring macros pulled in Linux in the first patch of the series
> > have been committed upstream in Xen, so there is nothing holding back
> > this series any longer. It could be considered for 4.12 or 4.13. It
> > should probably go via the Xen tree.
> > 
> > 
> > Changes in v7:
> > - merging the final version of the macros (Xen upstream commit
> >   f000908276382e1c0a3de359f9bbc7ba83999119)
> > - fixup argument ordering of the ring/write_packet macros callers
> > 
> > Changes in v6:
> > - add reviewd-bys
> > - fix error paths
> > - make p9_xen_write_todo return bool
> > 
> > Changes in v5:
> > - test priv->tag instead of ret
> > - run checkpatch.pl against the whole series, fix all issues
> > - set intf->ring_order appropriately
> > - use shorter link to 9pfs spec
> > 
> > Changes in v4:
> > - code style improvements
> > - use xenbus_read_unsigned when possible
> > - do not leak "versions"
> > - introduce BUILD_BUG_ON
> > - introduce rwlock to protect the xen_9pfs_devs list
> > - add review-by
> > 
> > Changes in v3:
> > - add full copyright header to trans_xen.c
> > - rename ring->ring to ring->data
> > - handle gnttab_grant_foreign_access errors
> > - remove ring->bytes
> > - wrap long lines
> > - add reviewed-by
> > 
> > Changes in v2:
> > - use XEN_PAGE_SHIFT instead of PAGE_SHIFT
> > - remove unnecessary initializations
> > - fix error paths
> > - fix memory allocations for 64K kernels
> > - simplify p9_xen_create and p9_xen_close
> > - use virt_XXX barriers
> > - set status = REQ_STATUS_ERROR inside the p9_xen_response loop
> > - add in-code comments
> > 
> > 
> > Stefano Stabellini (7):
> >   xen: import new ring macros in ring.h
> >   xen: introduce the header file for the Xen 9pfs transport protocol
> >   xen/9pfs: introduce Xen 9pfs transport driver
> >   xen/9pfs: connect to the backend
> >   xen/9pfs: send requests to the backend
> >   xen/9pfs: receive responses
> >   xen/9pfs: build 9pfs Xen transport driver
> > 
> >  include/xen/interface/io/9pfs.h |  36 +++
> >  include/xen/interface/io/ring.h | 143 +++
> >  net/9p/Kconfig  |   8 +
> >  net/9p/Makefile |   4 +
> >  net/9p/trans_xen.c  | 545 
> > 
> >  5 files changed, 736 insertions(+)
> >  create mode 100644 include/xen/interface/io/9pfs.h
> >  create mode 100644 net/9p/trans_xen.c
> 
> Series committed to xen/tip for-linus-4.12

Thank you!

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

[Xen-devel] [xen-4.8-testing test] 107324: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107210

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 107294

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107210
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107210
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107210
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107210
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107210

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

version targeted for testing:
 xen  c2a541500d5e0684f18ed9739dc8d18b39496244
baseline version:
 xen  ec7f9e1df2aa6cf8376d26eafca554c6521d2e7c

Last test of basis   107210  2017-04-05 05:29:32 Z5 days
Failing since107234  2017-04-06 10:19:41 Z4 days4 attempts
Testing same since   107294  2017-04-08 05:28:13 Z2 days2 attempts


People who touched revisions under test:
  George Dunlap 
  Ian Jackson 
  Jonathan Davies 
  Juergen Gross 
  Paul Durrant 

[Xen-devel] [xen-4.6-testing test] 107327: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate broken REGR. vs. 107208

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107208
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107208
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107208
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107208
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107208
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107208
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107208
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 107208
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107208

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail in 107311 never 
pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail in 107311 
never pass
 test-xtf-amd64-amd64-3   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-xtf-amd64-amd64-4   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-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
 test-armhf-armhf-libvirt-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   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-xtf-amd64-amd64-2   64 xtf/test-pv32pae-xsa-194 fail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 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 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  cf35a354efe2d45d6c345455100fc8023eb038e2
baseline version:
 xen  bb92bb77bc98d44cc8e4d8e6d61ae82517455f41

Last test of basis   107208  2017-04-05 04:30:53 Z5 days
Failing since107235  2017-04-06 10:21:34 Z4 days4 attempts
Testing same since   107311  2017-04-08 11:48:44 Z2 days2 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Dave Scott 
  David Scott 
  Ian Jackson 
  Jonathan Davies 
  Juergen Gross 
  Stefano Stabellini 
  Thomas Sanders 

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

[Xen-devel] [xen-unstable-smoke test] 107340: tolerable trouble: broken/fail/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  ce70926b4f88d3f7510bd4699dc7fc3996539084
baseline version:
 xen  6772d50a50ca4315f658e33194f966e48d180384

Last test of basis   107287  2017-04-08 02:02:12 Z2 days
Testing same since   107340  2017-04-10 15:02:39 Z0 days1 attempts


People who touched revisions under test:
  Jonathan Davies 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 build-arm64-pvopsfail
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  broken  
 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=ce70926b4f88d3f7510bd4699dc7fc3996539084
+ . ./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 
ce70926b4f88d3f7510bd4699dc7fc3996539084
+ branch=xen-unstable-smoke
+ revision=ce70926b4f88d3f7510bd4699dc7fc3996539084
+ . ./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.8-testing
+ '[' xce70926b4f88d3f7510bd4699dc7fc3996539084 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : 

Re: [Xen-devel] ITS emulation race conditions

[Andre Przywara]

Hi,

On 10/04/17 00:12, André Przywara wrote:
> Hi,
> 
> I wanted to run some ideas on how to prevent the race conditions we are
> facing with the ITS emulation and removing devices and/or LPIs.
> I think Stefano's idea of tagging a discarded LPI is the key, but still
> some details are left to be solved.
> I think we are dealing with two issues:
> 1) A guest's DISCARD can race with in incoming LPI.
> Ideally DISCARD would remove the host LPI -> vLPI connection (in the
> host_lpis table), so any new incoming (host) LPI would simply be
> discarded very early in gicv3_do_LPI() without ever resolving into a
> virtual LPI. Now while this removal is atomic, we could have just missed
> an incoming LPI, so the old virtual LPI would still traverse down the
> VGIC with a "doomed" virtual LPI ID.
> I wonder if that could be solved by a "crosswise" check:
> - The DISCARD handler *first* tags the pending_irq as "UNMAPPED", *then*
> removes the host_lpis connectin.
> - do_LPI() reads the host_lpis() array, *then* checks the UNMAPPED tag
> in the corresponding pending_irq (or lets vgic_vcpu_inject_irq() do that).
> With this setup the DISCARD handler can assume that no new virtual LPI
> instances enter the VGIC afterwards.
> 
> 2) An unmapped LPI might still be in use by the VGIC, foremost might
> still be in an LR.
> Tagging the pending_irq should solve this in general. Whenever a VGIC
> function finds the UNMAPPED tag, it does not process the vIRQ, but
> retires it. For simplicity we might limit this to handling when a VCPU
> exists and an LR gets cleaned up: If we hit a tagged pending_irq here,
> we clean the LR, remove the pending_irq from all lists and signal the
> ITS emulation that this pending_irq is now ready to be removed (by
> calling some kind of cleanup_lpi() function, for instance).
> The ITS code can then remove the struct pending_irq from the radix tree.
> MAPD(V=0) is now using this to tag all still mapped events as
> "UNMAPPED", the counting down the "still alive" pending_irqs in
> cleanup_lpi() until they reach zero. At this point it should be safe to
> free the pend_irq array.
> 
> Does that sound like a plan?
> Do I miss something here? Probably yes, hence I am asking ;-)

So there are two issues with this:
- For doing the LPI cleanup, we would need to call a virtual ITS or
virtual LPI specific function directly from gic.c. This looks like bad
coding style, as it breaks the abstraction (calling a virtual LPI/ITS
specific function from within gic.c)

- If we have a "DISCARD; MAPTI" sequence, targeting the same vLPI, while
this vLPI is still in an LR (but not cleaned up until both commands have
been handled), we end up with using the wrong pending_irq struct (the
new one). (I assume the UNMAPPED tag would be cleared upon the new MAPTI).

Can this create problems?
I see two possibilities:
a) the old vLPI is still pending in the LR: as the new LR would be
pristine, the code in update_one_lr() would just clean the QUEUED bit,
but not do anything further. The LR would be kept as used by this vLPI,
with the state still set to GICH_LR_PENDING. Upon re-entering the VCPU
this would make the new vLPI pending.
b) the old vLPI has been EOIed: the new LR would be pristine, the code
in update_one_lr() would try to clean it up anyway, which should not
hurt, AFAICT.

So if there is no new LPI triggered, a) would be wrong, but b) right. Is
that correct so far?

Now if there is a new LPI, a) would be correct, though the priority
might be different (though I am not sure this is an issue). b) should
work anyway, since the cleanup code checks for a new pending condition,
so would (re-)inject the (new) vLPI.

Julien does not seem to be a fan of this tagging idea, as this might
create more subtle failures that we don't see at the moment (which I can
understand).

So I would like to know how to proceed here:
I) stick to the tag, and fix that particular case above by checking for
the "inflight && ENABLED" condition and clearing the LR if the
pending_irq does not state it's pending anymore
II) introduce a NO_LONGER_PENDING tag in addition to the UNMAPPED tag,
where a new MAPTI just clears UNMAPPED_LPI, but keeps NO_LONGER_PENDING.
NO_LONGER_PENDING would be checked and cleared by update_one_lr(),
UNMAPPED by vgic_vcpu_inject_irq().
That would leave the issue how to call the pend_irq_cleanup() function
from update_one_lr() without breaking abstraction
III) Revert to the "check for NULL" solution.

MMh, this is nasty stuff, any suggestions?

Cheers,
Andre.

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

[Xen-devel] [PATCH 1/8] selecthost: Default pdu to "unsupported" rather than nothing

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 4ced6c0..a498ddd 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -814,7 +814,7 @@ sub serial_fetch_logs ($) {
 sub power_cycle_host_setup ($) {
 my ($ho) = @_;
 my $methobjs = [ ];
-foreach my $meth (split /\;\s*/, $ho->{Power}) {
+foreach my $meth (split /\;\s*/, ($ho->{Power} // 'unsupported')) {
push @$methobjs, get_host_method_object($ho,'PDU',$meth);
 }
 $ho->{PowerMethobjs} = $methobjs;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 3/8] mg-allocate: Redirect a few messages to stderr

[Ian Jackson]

These were, anomalously, printed to stdout.  We are going to want to
reserve stdout for programmatically-useful output.

Signed-off-by: Ian Jackson 
---
 mg-allocate |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/mg-allocate b/mg-allocate
index 7b1eb62..f895af2 100755
--- a/mg-allocate
+++ b/mg-allocate
@@ -430,8 +430,8 @@ sub plan () {
my @reqlist;
foreach my $poss (@possmatrix) {
my $tplanned= plan_search
-   ($plan, sub { print " @_\n"; }, $duration, $poss);
-   printf " possibility Start=%d %s\n",
+   ($plan, sub { print STDERR " @_\n"; }, $duration, $poss);
+   printf STDERR " possibility Start=%d %s\n",
$tplanned->{Start}, showposs($poss);
if (!$planned || $tplanned->{Start} < $planned->{Start}) {
$planned = $tplanned;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 5/8] ts-hosts-allocate-Executive: Honour OSSTEST_NOALLOCATE

[Ian Jackson]

This allows host allocation to be skipped even though the rest of the
job is being run.

Signed-off-by: Ian Jackson 
---
 ts-hosts-allocate-Executive |5 +
 1 file changed, 5 insertions(+)

diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 0b83365..9417226 100755
--- a/ts-hosts-allocate-Executive
+++ b/ts-hosts-allocate-Executive
@@ -50,6 +50,11 @@ while (@ARGV and $ARGV[0] =~ m/^-/) {
 }
 }
 
+if ($ENV{'OSSTEST_NOALLOCATE'}) {
+logm("OSSTEST_NOALLOCATE set, doing nothing.");
+exit 0;
+}
+
 # initialised by setup:
 our $taskid;
 our %magictaskid;
-- 
1.7.10.4


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

[Xen-devel] [PATCH 8/8] serial logs capture: Detect errors from glob

[Ian Jackson]

Empirically, if glob cannot do its work, it sets $! and returns an
empty list.

Signed-off-by: Ian Jackson 
---
 Osstest/Serial/sympathy.pm |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Osstest/Serial/sympathy.pm b/Osstest/Serial/sympathy.pm
index 84a1e09..7461e07 100644
--- a/Osstest/Serial/sympathy.pm
+++ b/Osstest/Serial/sympathy.pm
@@ -112,7 +112,10 @@ sub fetch_logs {
 my %done;
 for (;;) {
 my $anydone= 0;
-foreach my $logfile (glob $logpat) {
+$!=0;
+my @logfiles = glob $logpat;
+die "$logpat (@logfiles) $!" if $!;
+foreach my $logfile (@logfiles) {
 my $lh= new IO::File $logfile, 'r';
 if (!defined $lh) {
 $!== or warn "$logfile $!";
-- 
1.7.10.4


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

[Xen-devel] [PATCH 4/8] mg-allocate: Provide --stdout-output

[Ian Jackson]

This prints RESTYPE/RESNAME/SHAREIX to stdout, after allocation is
successful (outside the db retry loop).  This means that a
programmatic caller can now tell what was allocated, even if the spec
was complex.

Signed-off-by: Ian Jackson 
---
 mg-allocate |8 
 1 file changed, 8 insertions(+)

diff --git a/mg-allocate b/mg-allocate
index f895af2..287823a 100755
--- a/mg-allocate
+++ b/mg-allocate
@@ -93,6 +93,7 @@ our $donate_spec;
 our $donate_taskid;
 our @steal_specs;
 our %steal_taskids;
+our $stdout_output;
 
 sub alloc_prep () {
 $tid= findtask();
@@ -329,6 +330,7 @@ END
 }
 return ($ok, { Allocate => $allocate,
   Shareix => $got_shareix,
+  Report => "$restype/$resname/$got_shareix",
   Info => "$resname ($restype/$resname/$got_shareix)"
});
 }
@@ -352,6 +354,10 @@ sub loggot {
  "DEALLOCATED").
 ": ".$_->{Info})
foreach @got;
+if ($stdout_output) {
+   print $_->{Report}, "\n" or die $!
+   foreach @got;
+}
 }
 
 sub execute (;$) {
@@ -515,6 +521,8 @@ while (@ARGV && $ARGV[0] =~ m/^[-0-9]/) {
} elsif (s/^--steal$/-/) {
die "--steal needs task\n" unless @ARGV;
push @steal_specs, shift @ARGV;
+   } elsif (s/^--stdout-output$/-/) {
+   $stdout_output = 1;
 } else {
 die "bad option \`$_'";
 }
-- 
1.7.10.4


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

[Xen-devel] [PATCH 6/8] mg-repro-setup: New script for setting up repros automatically

[Ian Jackson]

Given a previously failed job, this will:
 * Create a flight for the repro attempt
 * (Optionally) allocate a host to the user's personal task
 * (Optionally) wipe the host
 * Install the version of Xen and Linux used by that flight
 * Run the job until the specified step finishes
 * Email the user

Signed-off-by: Ian Jackson 
---
 mg-repro-setup |  200 
 1 file changed, 200 insertions(+)
 create mode 100755 mg-repro-setup

diff --git a/mg-repro-setup b/mg-repro-setup
new file mode 100755
index 000..c673cb6
--- /dev/null
+++ b/mg-repro-setup
@@ -0,0 +1,200 @@
+#!/bin/bash
+
+# This is part of "osstest", an automated testing framework for Xen.
+# Copyright (C) 2009-2017 Citrix Inc.
+# 
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU Affero General Public License for more details.
+# 
+# You should have received a copy of the GNU Affero General Public License
+# along with this program.  If not, see .
+
+
+usage () { cat <   host must be allocated, skip host-install
+   [host=]wipe:  host must be allocated, wipe it
+   [host=]alloc:mg-allocate and wipe
+   none:   no hosts (should be only HOSTPSEC)
+
+ OPTIONs
+   -t estimated duration (default = 28d)
+   --rogue  bypass queuing system and allocate now
+   -r=  set runvar
+   -r! delete runvar
+   -Bdefault is 'play'
+   -E... -f... -P   as for mg-execute-fligght
+
+END
+
+}
+
+badusage () { echo >&2 "bad usage"; usage >&2; exit 126; }
+
+set -e -o posix
+
+mgexecflags=()
+adjustsets=()
+adjusts=()
+allocs=()
+logfile=tmp/mg-repro-setup.log
+duration=28d
+blessing=play
+
+while true; do
+   case "$1" in
+   -*) ;;
+   *)  break   ;;
+   esac
+   arg=$1; shift
+case "$arg" in
+-[E]?*|-P) mgexecflags+=("$arg")   ;;
+-B?*)  blessing=${arg#-B}  ;;
+-f?*)  refflight=${arg#-f} ;;
+   -t?*)   duration=${arg#-t}  ;;
+   --rogue)duration='' ;;
+   -l*)logfile=${arg#-l}   ;;
+   -r!*)   adjustsets+=("${arg#-r}")   ;;
+   -r*=*)  adjustsets+=("${arg#-r}")   ;;
+   --) break   ;;
+   *)  badusage;;
+   esac
+done
+
+case $# in
+0|1|2|3)   badusage;;
+esac
+
+example_flight=$1  ; shift
+job=$1 ; shift
+testid=$1  ; shift
+
+: ${refflight:=$example_flight}
+
+delrunvar () {
+   adjusts+=(runvar-del "$job" "$1")
+}
+adjrunvar () {
+   delrunvar "$1"
+   adjusts+=(runvar-set "$job" "$1" "$2")
+}
+
+for arg in "${adjustsets[@]}"; do
+   case "$arg" in
+   !*) delrunvar "${arg#!}";;
+   *=*)adjrunvar "${arg%%=*}" "{$arg#*=}"  ;;
+   *)  bad-adjuistset-pattern  ;;
+   esac
+done
+
+while [ $# -ne 0 ]; do
+   arg=$1; shift
+
+   case "$arg" in
+   none:)
+   # provided so we can repro a job with no hosts
+   ;;
+   *:*)# [IDENT=]MODE:SPEC
+   identmode=${arg%%:*}
+   spec=${arg#*:}
+   ;;
+   *=*)# IDENT=SPEC
+   identmode=${arg%%=*}=reuse
+   spec=${arg#*=}
+   ;;
+   *)  # SPEC
+   identmode=reuse
+   spec=$arg
+   ;;
+   esac
+   case "$identmode" in # [IDENT=]MODE
+   *=*)# IDENT=MODE
+   ident=${identmode%%=*}
+   mode=${identmode#*=}
+   ;;
+   *)
+   ident=host
+   mode=$identmode
+   ;;
+   esac
+
+   case "$mode" in
+   wipe|alloc) ;;
+   *)  adjrunvar ${ident}_hostflagadjust no-reinstall ;;
+   esac
+
+   case "$mode" in
+   alloc)  alloc_specs+=("$spec")
+   alloc_idents+=($ident)
+   ;;
+   *)  adjrunvar $ident $spec
+   ;;
+   esac
+done
+
+progressf () { printf >&2 "$@"; }
+progress () { progressf "%s\n" "$1"; }
+
+progress "logging to $logfile"
+savelog "$logfile"
+exec 3>"$logfile"
+
+OSSTEST_TASK=$(perl -e '
+   use Osstest;
+   use Osstest::Executive;
+   csreadconfig();
+   

[Xen-devel] [PATCH 7/8] serial logs capture: chomp parameters to the perl script

[Ian Jackson]

For reasons that aren't clear, perl's glob operator ignores the \n.
We can gloss over that for now, but let's chomp it in case they fix
that.

Signed-off-by: Ian Jackson 
---
 Osstest/Serial/sympathy.pm |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Osstest/Serial/sympathy.pm b/Osstest/Serial/sympathy.pm
index 0d09576..84a1e09 100644
--- a/Osstest/Serial/sympathy.pm
+++ b/Osstest/Serial/sympathy.pm
@@ -106,8 +106,8 @@ sub fetch_logs {
 use strict qw(refs vars);
 use IO::File;
 $|=1;
-my $started= ;  defined $started or die $!;
-my $logpat= ;   defined $logpat or die $!;
+my $started= ;  chomp $started or die $!;
+my $logpat= ;   chomp $logpat or die $!;
 
 my %done;
 for (;;) {
-- 
1.7.10.4


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

[Xen-devel] [PATCH 2/8] selecthost: Honour IDENT_hostflagadjust runvar

[Ian Jackson]

This allows runvars to override hostflags from the resource database
or configuration.

Signed-off-by: Ian Jackson 
---
 Osstest/TestSupport.pm |8 
 1 file changed, 8 insertions(+)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index a498ddd..88b0a65 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -966,6 +966,14 @@ sub selecthost ($) {
 
 $ho->{Flags} = $mhostdb->get_flags($ho);
 
+foreach my $adj (split /,/, ($r{"${ident}_hostflagadjust"} // '')) {
+   if ($adj =~ s/^!//) {
+   delete $ho->{Flags}{$adj};
+   } else {
+   $ho->{Flags}{$adj} = 1;
+   }
+}
+
 #- fqdn -
 
 my $defaultfqdn = $name;
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH for-4.9 v3 2/3] x86/atomic: fix clang build

[Roger Pau Monne]

On Mon, Apr 10, 2017 at 09:19:52AM -0600, Jan Beulich wrote:
> >>> On 10.04.17 at 15:34,  wrote:
> > --- a/xen/include/asm-x86/atomic.h
> > +++ b/xen/include/asm-x86/atomic.h
> > @@ -41,20 +41,42 @@ build_add_sized(add_u64_sized, "q", uint64_t, "ri")
> >  #undef build_write_atomic
> >  #undef build_add_sized
> >  
> > -void __bad_atomic_size(void);
> > +/*
> > + * NB: read_atomic needs to be a static inline function because clang 
> > doesn't
> > + * like breaks inside of expressions, even when there's an inner switch 
> > where
> > + * those breaks should apply, and complains with "'break' is bound to 
> > loop, GCC
> > + * binds it to switch", so the following code:
> > + *
> > + * while ( read_atomic() ) { ... }
> > + *
> > + * Doesn't work if read_atomic is a macro with an inner switch.
> > + */
> > +static inline unsigned long readatomic(const void *p, size_t s)
> > +{
> > +switch ( s )
> > +{
> > +case 1:
> > +return read_u8_atomic((uint8_t *)p);
> > +case 2:
> > +return read_u16_atomic((uint16_t *)p);
> > +case 4:
> > +return read_u32_atomic((uint32_t *)p);
> > +case 8:
> > +return read_u64_atomic((uint64_t *)p);
> 
> By going though void as the function's parameter type I don't think
> you need the bogus casts here anymore.
> 
> > +default:
> > +ASSERT_UNREACHABLE();
> > +return 0;
> > +}
> > +}
> >  
> > -#define read_atomic(p) ({ \
> > -unsigned long x_; \
> > -switch ( sizeof(*(p)) ) { \
> > -case 1: x_ = read_u8_atomic((uint8_t *)(p)); break;   \
> > -case 2: x_ = read_u16_atomic((uint16_t *)(p)); break; \
> > -case 4: x_ = read_u32_atomic((uint32_t *)(p)); break; \
> > -case 8: x_ = read_u64_atomic((uint64_t *)(p)); break; \
> > -default: x_ = 0; __bad_atomic_size(); break;  \
> > -} \
> > -(typeof(*(p)))x_; \
> > +#define read_atomic(p) ({  \
> > +BUILD_BUG_ON(sizeof(*(p)) != 1 && sizeof(*(p)) != 2 && \
> > + sizeof(*(p)) != 4 && sizeof(*(p)) != 8);  \
> > +(typeof(*(p)))readatomic(p, sizeof(*(p))); \
> >  })
> 
> So did you take a look at whether / how much generated code
> changes?

No, I haven't looked.

> In any event, while this is better than dealing with it at the use
> site(s) of the macro, I still don't think this is really acceptable,
> mainly because it still doesn't scale: What if tomorrow I use
> write_atomic() in a context that clang doesn't like? And perhaps
> we have a few more such constructs, or may be gaining them
> at any time going forward. I'm honestly not convinced of the
> usefulness of keeping our code clang compliant, if they have
> such fundamental issues with the understanding of the
> language spec.

Well, I think clang has proven useful in the past for detecting issues that gcc
didn't catch. Those should all be considered bugs, and IMHO clang is quite good
at solving them. I never had issues sending bug reports upstream, and getting
them fixed. I cannot sadly say the same about gcc.

In any case, I don't think it's reasonable to expect no bugs (like Xen also has
bugs). I understand your reluctance to merge this because it pollutes the code
just to fix a bug that's not even ours, but I don't see any other way to solve
this.

I have a (I think) less intrusive fix, which relies on using _Pragma, pasted
below. Let me know what you think, and I can formally submit it.

---8<---
diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index 2fbe705518..d24e30c3df 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -43,8 +43,23 @@ build_add_sized(add_u64_sized, "q", uint64_t, "ri")
 
 void __bad_atomic_size(void);
 
+/*
+ * NB: we need to disable the gcc-compat warnings for clang in read_atomic or
+ * else it will complain with: "'break' is bound to loop, GCC binds it to
+ * switch" when read_atomic is used inside of a while expression inside of a
+ * switch statement, ie:
+ *
+ * switch (...)
+ * {
+ * case ...:
+ *  while ( read_atomic() ) { ... }
+ *
+ * This has already been reported upstream:
+ * http://bugs.llvm.org/show_bug.cgi?id=32595
+ */
 #define read_atomic(p) ({ \
 unsigned long x_; \
+CLANG_DISABLE_WARN_GCC_COMPAT_START   \
 switch ( sizeof(*(p)) ) { \
 case 1: x_ = read_u8_atomic((uint8_t *)(p)); break;   \
 case 2: x_ = read_u16_atomic((uint16_t *)(p)); break; \
@@ -52,6 +67,7 @@ void __bad_atomic_size(void);
 case 8: x_ = read_u64_atomic((uint64_t *)(p)); break; \
 default: x_ = 0; __bad_atomic_size(); break;  \
 } 

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

On 10/04/17 17:32, Raslan, KarimAllah wrote:
> 
> Ahmed, Karim Allah
> karah...@amazon.de
> 
> 
> 
>> On Apr 10, 2017, at 3:57 PM, Juergen Gross  wrote:
>>
>> On 10/04/17 15:47, Boris Ostrovsky wrote:
>>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
 On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
 tl;dr:
 Please apply

da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
partially revert "xen: Remove event channel notification through
  Xen PCI platform device"

 to all stable branches which have a version of the original broken
 commit.  This includes at least 4.9.y.

 Background:

 osstest service owner writes ("[linux-4.9 baseline test] 107238: 
 tolerable FAIL"):
 ...
> test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
 osstest doesn't consider this a regresion because it looks for
 regressions within a branch, and this is the first test of Linux 4.9.
 However, this is a regression from the kernel we are currently using.

 L1 dom0 console log:
  
 http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log

 It seems to have got stuck halfway through booting.

 The message
  (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
 input to DOM0)
 shows where osstest timed out on this test, and started its log
 capture process (including collecting debug key output).

 Complete logs for this job here:
  
 http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html

 Juergen Gross tells me that this is due to the lack of
 da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.

 Thanks,
 Ian.

 PS: Stefano, Boris: did you already request a backport of this commit?
 If not, why not ?
>>> No, but this should indeed be backported to 4.9+
>> Boris, are you going to do that?
> Is there anything that needs to be done beyond just applying it to 4.9
> (4.10 apparently already has it).
 No, I don't think so. 4.9 already has the offending commit.
>>>
>>>
>>> Looks like there will be a new version of the original patch
>>> (72a9b186292) so we should hold off with backport request to 4.9:
>>>
>>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
>>
>> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
>> reworked: Do we really care for Xen versions < 4.0 and a theoretical
>> problem (after all the author admitted the bug isn't being hit in
>> reality due to a short-circuit in the code)?
> 
> IMHO, even if 72a9b186292 has not been reworked we should completely revert it
> not only partially revert it. Before this commit at least kernel 4.9+ would
> work on older Xen versions (< 4.0) while now, it will not even boot.

The following is meant as a real question without any prejudice:

How old a Xen version do we want to support in the Linux kernel?

- Only those being still maintained (meaning getting security fixes)
- Versions max. X years after getting last security fixes (what value
  of X?)
- From version Y on (what value of Y?)
- All versions which we can think of

I think we should answer this question in order to know what we can
remove in the Linux kernel without breaking something.

> I do agree however that fixing INTx sounds completely useless since there is
> no combination of Xen+Linux that would lead to the bug by default (unless you
> forced the use of INTx even when vector injection is supported which is what I
> did during testing the original patch).

Right.


Juergen

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

[Xen-devel] [libvirt test] 107325: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107298
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107298
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107298

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-pvops 5 kernel-build fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  4c661a944d75638db76483bbd058981b4c0595a8
baseline version:
 libvirt  98f424d5038b362d1b62549930d0b9253106bdca

Last test of basis   107298  2017-04-08 08:04:13 Z2 days
Testing same since   107325  2017-04-09 17:17:18 Z0 days1 attempts


People who touched revisions under test:
  Dawid Zamirski 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsfail
 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-arm64-arm64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw pass
 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


Pushing revision :

+ branch=libvirt
+ revision=4c661a944d75638db76483bbd058981b4c0595a8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-install   fail REGR. vs. 106822

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   2 hosts-allocate   broken pass in 107232
 test-armhf-armhf-xl-multivcpu 11 guest-start fail in 107232 pass in 107326
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail in 107232 
pass in 107326
 test-armhf-armhf-libvirt-raw  7 host-ping-check-xenfail pass in 107307
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
107307

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 107232 blocked in 
106822
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop   fail in 107307 like 106822
 test-xtf-amd64-amd64-3   20 xtf/test-hvm32-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-3 33 xtf/test-hvm32pae-invlpg~shadow fail like 106822
 test-xtf-amd64-amd64-3   44 xtf/test-hvm64-invlpg~shadow fail  like 106822
 test-xtf-amd64-amd64-2   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-4   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-1   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-5   54 leak-check/check fail  like 106822
 test-xtf-amd64-amd64-3   54 leak-check/check fail  like 106822
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 106822
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 106822
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 106822

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale 12 migrate-support-check fail in 107232 never pass
 test-armhf-armhf-xl-arndale 13 saverestore-support-check fail in 107232 never 
pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail in 107232 never pass
 test-xtf-amd64-amd64-2   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-2   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-1   10 xtf-fep  fail   never pass
 test-xtf-amd64-amd64-4   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   18 xtf/test-hvm32-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-2 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-2   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-4 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1 31 xtf/test-hvm32pae-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-4   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-1 37 xtf/test-hvm32pse-cpuid-faulting fail never pass
 test-xtf-amd64-amd64-1   41 xtf/test-hvm64-cpuid-faulting fail  never pass
 test-xtf-amd64-amd64-5   10 xtf-fep  fail   never pass
 build-i386-rumprun7 xen-buildfail   never pass
 build-amd64-rumprun   7 xen-buildfail   never pass
 test-xtf-amd64-amd64-3   10 xtf-fep  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-4   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-xtf-amd64-amd64-1   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-5   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-xtf-amd64-amd64-3   53 xtf/test-hvm64-xsa-195   fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 

Re: [Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Wei Liu]

On Mon, Apr 10, 2017 at 04:16:12PM +0100, Andrew Cooper wrote:
> On 10/04/17 16:12, Wei Liu wrote:
> > On Mon, Apr 10, 2017 at 04:04:22PM +0100, Andrew Cooper wrote:
> >> On 10/04/17 14:27, Wei Liu wrote:
> >>> No functional change.
> >>>
> >>> Signed-off-by: Wei Liu 
> >> Throughout this series, please make sure you add in proper NULL'ing of
> >> freed data.
> >>
> >> While this patch is no functional change at the moment, you have
> >> introduced a latent double-free bug for if (/when) pv_domain_destroy()
> >> gets used on a failed create path.
> >>
> > No it won't. I made pv_domain_initialise idempotent.
> 
> Ah - I hadn't spotted that.
> 
> My long-term goal is to reorder the init/destroy logic such that init
> has no cleanup in it, and any failure comes out and calls destroy at the
> top level.

Just like what we do in libxl? :-)

> 
> This will avoid us opencoding the teardown logic twice;  we have had
> bugs in the past where the two paths are different (the most common of
> which is missing cleanup in the destroy path, leading to a memory leak).
> 

Given there is going to be a lot of code churn, I think the best bet at
the moment is to have the teardown logic twice, with each setting
respective fields to their "NULL" state. Although that's a bit
excessive, but it would prevent accidental memory leak or double free
errors. And then after we are happy with the overall structures of
hypervisor code, we can then audit the code to remove the clean up code
in _init.

What do you think?

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Wei Liu]

On Mon, Apr 10, 2017 at 04:04:22PM +0100, Andrew Cooper wrote:
> On 10/04/17 14:27, Wei Liu wrote:
> > No functional change.
> >
> > Signed-off-by: Wei Liu 
> 
> Throughout this series, please make sure you add in proper NULL'ing of
> freed data.
> 
> While this patch is no functional change at the moment, you have
> introduced a latent double-free bug for if (/when) pv_domain_destroy()
> gets used on a failed create path.
> 

No it won't. I made pv_domain_initialise idempotent.

> Please make all of these functions idempotent when breaking them out.
> 

This is a good point. I can make this one idempotent as well.

Wei.

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Raslan, KarimAllah]

Ahmed, Karim Allah
karah...@amazon.de



> On Apr 10, 2017, at 3:57 PM, Juergen Gross  wrote:
> 
> On 10/04/17 15:47, Boris Ostrovsky wrote:
>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
 On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>> tl;dr:
>>> Please apply
>>> 
>>>da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>>partially revert "xen: Remove event channel notification through
>>>  Xen PCI platform device"
>>> 
>>> to all stable branches which have a version of the original broken
>>> commit.  This includes at least 4.9.y.
>>> 
>>> Background:
>>> 
>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: 
>>> tolerable FAIL"):
>>> ...
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
>>> osstest doesn't consider this a regresion because it looks for
>>> regressions within a branch, and this is the first test of Linux 4.9.
>>> However, this is a regression from the kernel we are currently using.
>>> 
>>> L1 dom0 console log:
>>>  
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>> 
>>> It seems to have got stuck halfway through booting.
>>> 
>>> The message
>>>  (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
>>> input to DOM0)
>>> shows where osstest timed out on this test, and started its log
>>> capture process (including collecting debug key output).
>>> 
>>> Complete logs for this job here:
>>>  
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>> 
>>> Juergen Gross tells me that this is due to the lack of
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>> 
>>> Thanks,
>>> Ian.
>>> 
>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>> If not, why not ?
>> No, but this should indeed be backported to 4.9+
> Boris, are you going to do that?
 Is there anything that needs to be done beyond just applying it to 4.9
 (4.10 apparently already has it).
>>> No, I don't think so. 4.9 already has the offending commit.
>> 
>> 
>> Looks like there will be a new version of the original patch
>> (72a9b186292) so we should hold off with backport request to 4.9:
>> 
>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
> 
> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> problem (after all the author admitted the bug isn't being hit in
> reality due to a short-circuit in the code)?

IMHO, even if 72a9b186292 has not been reworked we should completely revert it
not only partially revert it. Before this commit at least kernel 4.9+ would
work on older Xen versions (< 4.0) while now, it will not even boot.

I do agree however that fixing INTx sounds completely useless since there is
no combination of Xen+Linux that would lead to the bug by default (unless you
forced the use of INTx even when vector injection is supported which is what I
did during testing the original patch).

> 
> And even if we do: I'd rather add another patch to stable later than
> keeping a real bug in Linux 4.9 which has been hit at least 3 times
> up to now (by Stefano, George and Ian).
> 
> 
> Juergen
> 

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] [PATCH for-4.9 v3 1/3] xsm: fix clang 3.5 build after c47d1d

[Julien Grall]

Hi Roger,

On 10/04/17 14:34, Roger Pau Monne wrote:

The changes introduced on c47d1d broke the clang build due to undefined
references to __xsm_action_mismatch_detected, because clang hasn't optimized
the code properly. The following patch allows the clang build to work again,
while keeping the same functionality.

Signed-off-by: Roger Pau Monné 


Tested-by: Julien Grall 

Can someone commit this patch today? I'd like to cut an RC as soon as 
osstest pushed to staging.


Cheers,


---
Cc: Daniel De Graaf 
Cc: Julien Grall 
Cc: Tamas K Lengyel 
---
Changes since v2:
 - Use an "if" like v1.

Changes since v1:
 - Remove unused "break".
 - Remove if condition.

NB: this fixes travis build: https://travis-ci.org/royger/xen/builds/219697038
---
 xen/include/xsm/dummy.h | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 56a8814d82..62fcea6f04 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -557,25 +557,21 @@ static XSM_INLINE int 
xsm_hvm_param_altp2mhvm(XSM_DEFAULT_ARG struct domain *d)

 static XSM_INLINE int xsm_hvm_altp2mhvm_op(XSM_DEFAULT_ARG struct domain *d, 
uint64_t mode, uint32_t op)
 {
-xsm_default_t a;
 XSM_ASSERT_ACTION(XSM_OTHER);

 switch ( mode )
 {
 case XEN_ALTP2M_mixed:
-a = XSM_TARGET;
-break;
+return xsm_default_action(XSM_TARGET, current->domain, d);
 case XEN_ALTP2M_external:
-a = XSM_DM_PRIV;
-break;
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 case XEN_ALTP2M_limited:
-a = (HVMOP_altp2m_vcpu_enable_notify == op) ? XSM_TARGET : XSM_DM_PRIV;
-break;
+if ( HVMOP_altp2m_vcpu_enable_notify == op )
+return xsm_default_action(XSM_TARGET, current->domain, d);
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 default:
 return -EPERM;
-};
-
-return xsm_default_action(a, current->domain, d);
+}
 }

 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, 
int mode, int op)



--
Julien Grall

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

Re: [Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Andrew Cooper]

On 10/04/17 16:22, Wei Liu wrote:
> On Mon, Apr 10, 2017 at 04:16:12PM +0100, Andrew Cooper wrote:
>> On 10/04/17 16:12, Wei Liu wrote:
>>> On Mon, Apr 10, 2017 at 04:04:22PM +0100, Andrew Cooper wrote:
 On 10/04/17 14:27, Wei Liu wrote:
> No functional change.
>
> Signed-off-by: Wei Liu 
 Throughout this series, please make sure you add in proper NULL'ing of
 freed data.

 While this patch is no functional change at the moment, you have
 introduced a latent double-free bug for if (/when) pv_domain_destroy()
 gets used on a failed create path.

>>> No it won't. I made pv_domain_initialise idempotent.
>> Ah - I hadn't spotted that.
>>
>> My long-term goal is to reorder the init/destroy logic such that init
>> has no cleanup in it, and any failure comes out and calls destroy at the
>> top level.
> Just like what we do in libxl? :-)
>
>> This will avoid us opencoding the teardown logic twice;  we have had
>> bugs in the past where the two paths are different (the most common of
>> which is missing cleanup in the destroy path, leading to a memory leak).
>>
> Given there is going to be a lot of code churn, I think the best bet at
> the moment is to have the teardown logic twice, with each setting
> respective fields to their "NULL" state. Although that's a bit
> excessive, but it would prevent accidental memory leak or double free
> errors. And then after we are happy with the overall structures of
> hypervisor code, we can then audit the code to remove the clean up code
> in _init.
>
> What do you think?

For now, keep the patches along their current line, but making the
teardown idempotent.  I wasn't trying to lumber you with all the work. ;)

I have a series starting from the common code, but it will require
coordinated changes between all architectures.  This will be far easier
to reason about when all the underlying functions are idempotent.

~Andrew

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

[Xen-devel] [linux-linus test] 107320: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   2 hosts-allocate  broken REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   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-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux78d91a75b40fcf6a08506d308abf2413a29b7e30
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  641 days
Failing since 59348  2015-07-10 04:24:05 Z  640 days  381 attempts
Testing same since   107320  2017-04-09 07:59:23 Z1 days1 attempts


8148 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [PATCH for-4.9 v3 3/3] x86/atomic: fix cmpxchg16b inline assembly to work with clang

[Jan Beulich]

>>> On 10.04.17 at 15:34,  wrote:
> clang doesn't understand the "=A" register constrain when used with 64bits
> assembly and spits out an internal error:
> 
> fatal error: error in backend: Cannot select: 0x7f9fb89c9390: i64 = 
> build_pair 0x7f9fb89c92b0,
>   0x7f9fb89c9320
>   0x7f9fb89c92b0: i32,ch,glue = CopyFromReg 0x7f9fb89c9240, Register:i32 
> %EAX, 0x7f9fb89c9240:1
> 0x7f9fb89c8c20: i32 = Register %EAX
> 0x7f9fb89c9240: ch,glue = inlineasm 0x7f9fb89c90f0,
> TargetExternalSymbol:i64'lock; cmpxchg16b $1', MDNode:ch<0x7f9fb8476c38>,
> TargetConstant:i64<25>, TargetConstant:i32<18>, Register:i32 %EAX, 
> Register:i32
> %EDX, TargetConstant:i32<196622>, 0x7f9fb89c87c0, TargetConstant:i32<9>,
> Register:i64 %RCX, TargetConstant:i32<9>, Register:i64 %RBX,
> TargetConstant:i32<9>, Register:i64 %RDX, TargetConstant:i32<9>, Register:i64
> %RAX, TargetConstant:i32<196622>, 0x7f9fb89c87c0, TargetConstant:i32<12>,
> Register:i32 %EFLAGS, 0x7f9fb89c90f0:1
>   0x7f9fb89c8a60: i64 = TargetExternalSymbol'lock; cmpxchg16b $1'
>   0x7f9fb89c8b40: i64 = TargetConstant<25>
>   0x7f9fb89c8bb0: i32 = TargetConstant<18>
>   0x7f9fb89c8c20: i32 = Register %EAX
>   0x7f9fb89c8c90: i32 = Register %EDX
>   0x7f9fb89c8d00: i32 = TargetConstant<196622>
>   0x7f9fb89c87c0: i64,ch = load 0x7f9fb9053da0, 
> FrameIndex:i64<1>, 
> undef:i64
> 0x7f9fb9053a90: i64 = FrameIndex<1>
> 0x7f9fb9053e80: i64 = undef
>   0x7f9fb89c8e50: i32 = TargetConstant<9>
>   0x7f9fb89c8d70: i64 = Register %RCX
>   0x7f9fb89c8e50: i32 = TargetConstant<9>
>   0x7f9fb89c8ec0: i64 = Register %RBX
>   0x7f9fb89c8e50: i32 = TargetConstant<9>
>   0x7f9fb89c8fa0: i64 = Register %RDX
>   0x7f9fb89c8e50: i32 = TargetConstant<9>
>   0x7f9fb89c9080: i64 = Register %RAX
> [...]
> 
> Fix this by specifying "rdx:rax" manually using the "d" and "a" constraints.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Jan Beulich 

Albeit it would have been a good idea to add a code comment, so
there won't be someone wanting to undo this as it can be done
with fewer operands (and hence in a more legible way).

Jan

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

Re: [Xen-devel] [PATCH for-4.9 v3 2/3] x86/atomic: fix clang build

[Jan Beulich]

>>> On 10.04.17 at 15:34,  wrote:
> --- a/xen/include/asm-x86/atomic.h
> +++ b/xen/include/asm-x86/atomic.h
> @@ -41,20 +41,42 @@ build_add_sized(add_u64_sized, "q", uint64_t, "ri")
>  #undef build_write_atomic
>  #undef build_add_sized
>  
> -void __bad_atomic_size(void);
> +/*
> + * NB: read_atomic needs to be a static inline function because clang doesn't
> + * like breaks inside of expressions, even when there's an inner switch where
> + * those breaks should apply, and complains with "'break' is bound to loop, 
> GCC
> + * binds it to switch", so the following code:
> + *
> + * while ( read_atomic() ) { ... }
> + *
> + * Doesn't work if read_atomic is a macro with an inner switch.
> + */
> +static inline unsigned long readatomic(const void *p, size_t s)
> +{
> +switch ( s )
> +{
> +case 1:
> +return read_u8_atomic((uint8_t *)p);
> +case 2:
> +return read_u16_atomic((uint16_t *)p);
> +case 4:
> +return read_u32_atomic((uint32_t *)p);
> +case 8:
> +return read_u64_atomic((uint64_t *)p);

By going though void as the function's parameter type I don't think
you need the bogus casts here anymore.

> +default:
> +ASSERT_UNREACHABLE();
> +return 0;
> +}
> +}
>  
> -#define read_atomic(p) ({ \
> -unsigned long x_; \
> -switch ( sizeof(*(p)) ) { \
> -case 1: x_ = read_u8_atomic((uint8_t *)(p)); break;   \
> -case 2: x_ = read_u16_atomic((uint16_t *)(p)); break; \
> -case 4: x_ = read_u32_atomic((uint32_t *)(p)); break; \
> -case 8: x_ = read_u64_atomic((uint64_t *)(p)); break; \
> -default: x_ = 0; __bad_atomic_size(); break;  \
> -} \
> -(typeof(*(p)))x_; \
> +#define read_atomic(p) ({  \
> +BUILD_BUG_ON(sizeof(*(p)) != 1 && sizeof(*(p)) != 2 && \
> + sizeof(*(p)) != 4 && sizeof(*(p)) != 8);  \
> +(typeof(*(p)))readatomic(p, sizeof(*(p))); \
>  })

So did you take a look at whether / how much generated code
changes?

In any event, while this is better than dealing with it at the use
site(s) of the macro, I still don't think this is really acceptable,
mainly because it still doesn't scale: What if tomorrow I use
write_atomic() in a context that clang doesn't like? And perhaps
we have a few more such constructs, or may be gaining them
at any time going forward. I'm honestly not convinced of the
usefulness of keeping our code clang compliant, if they have
such fundamental issues with the understanding of the
language spec.

Bottom line - I currently can't see myself ack-ing ugliness like
this, but I also think I don't want to stand in the way of
someone else (read: Andrew) doing so if this is really deemed
an appropriate solution by everyone else.

Jan


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

Re: [Xen-devel] [PATCH for-next 4/8] x86/domain: push some code down to hvm_domain_initialise

[Andrew Cooper]

On 10/04/17 14:27, Wei Liu wrote:
> We want to have a single entry point to initialise hvm guest.  The
> timing to set hap bit and create per domain mapping is deferred, but
> that's not a problem.
>
> No functional change.
>
> Signed-off-by: Wei Liu 

Two observations...

> ---
>  xen/arch/x86/domain.c | 11 ++-
>  xen/arch/x86/hvm/hvm.c| 25 +
>  xen/include/asm-x86/hvm/hvm.h |  2 +-
>  3 files changed, 20 insertions(+), 18 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index ddebff6187..af060d8239 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -663,7 +656,7 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  
>  if ( is_hvm_domain(d) )
>  {
> -if ( (rc = hvm_domain_initialise(d)) != 0 )
> +if ( (rc = hvm_domain_initialise(d, domcr_flags)) != 0 )

If we are pushing these values down (which I agree is a good idea),
please can we push xen_arch_domainconfig down as well.

>  goto fail;
>  }
>  else
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index f50d15ff50..7fc49bb03d 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -615,10 +615,17 @@ int hvm_domain_initialise(struct domain *d)
>  
>  hvm_init_cacheattr_region_list(d);
>  
> -rc = paging_enable(d, PG_refcounts|PG_translate|PG_external);
> +d->arch.hvm_domain.hap_enabled =
> +hvm_funcs.hap_supported && (domcr_flags & DOMCRF_hap);

We really should fail with -EOPNOTSUPP.

The toolstack already knows whether HAP is available, and nothing good
can come from Xen falling silently back to shadow behind the toolstacks
back.

Probably worth being in a solo patch though.

~Andrew

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

Re: [Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Andrew Cooper]

On 10/04/17 16:12, Wei Liu wrote:
> On Mon, Apr 10, 2017 at 04:04:22PM +0100, Andrew Cooper wrote:
>> On 10/04/17 14:27, Wei Liu wrote:
>>> No functional change.
>>>
>>> Signed-off-by: Wei Liu 
>> Throughout this series, please make sure you add in proper NULL'ing of
>> freed data.
>>
>> While this patch is no functional change at the moment, you have
>> introduced a latent double-free bug for if (/when) pv_domain_destroy()
>> gets used on a failed create path.
>>
> No it won't. I made pv_domain_initialise idempotent.

Ah - I hadn't spotted that.

My long-term goal is to reorder the init/destroy logic such that init
has no cleanup in it, and any failure comes out and calls destroy at the
top level.

This will avoid us opencoding the teardown logic twice;  we have had
bugs in the past where the two paths are different (the most common of
which is missing cleanup in the destroy path, leading to a memory leak).

~Andrew

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

Re: [Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Andrew Cooper]

On 10/04/17 14:27, Wei Liu wrote:
> No functional change.
>
> Signed-off-by: Wei Liu 

Throughout this series, please make sure you add in proper NULL'ing of
freed data.

While this patch is no functional change at the moment, you have
introduced a latent double-free bug for if (/when) pv_domain_destroy()
gets used on a failed create path.

Please make all of these functions idempotent when breaking them out.

~Andrew

> ---
>  xen/arch/x86/domain.c | 17 +
>  1 file changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index af060d8239..05885a103d 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -527,6 +527,12 @@ static bool emulation_flags_ok(const struct domain *d, 
> uint32_t emflags)
>  return true;
>  }
>  
> +static void pv_domain_destroy(struct domain *d)
> +{
> +xfree(d->arch.pv_domain.cpuidmasks);
> +free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> +}
> +
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
> @@ -704,10 +710,8 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  paging_final_teardown(d);
>  free_perdomain_mappings(d);
>  if ( is_pv_domain(d) )
> -{
> -xfree(d->arch.pv_domain.cpuidmasks);
> -free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> -}
> +pv_domain_destroy(d);
> +
>  return rc;
>  }
>  
> @@ -727,10 +731,7 @@ void arch_domain_destroy(struct domain *d)
>  
>  free_perdomain_mappings(d);
>  if ( is_pv_domain(d) )
> -{
> -free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> -xfree(d->arch.pv_domain.cpuidmasks);
> -}
> +pv_domain_destroy(d);
>  
>  free_xenheap_page(d->shared_info);
>  cleanup_domain_irq_mapping(d);


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

[Xen-devel] xl.cfg vfb list parsing issues

[Doug Freed]

Hi,

This issue came up in the #xen IRC channel on freenode, and Andrew
Cooper asked for somebody to email xen-devel so it could be fixed.  A
user had the following line in their domain config and couldn't figure
out why it wasn't working correctly:

vfb=['vnclisten="10.1.1.8:2"']

The answer is, of course, that the parser is not expecting the
parameter to be quoted.  Unfortunately, the above line is consistent
with how the setting is documented in the manpage:

"vnclisten="ADDRESS[:DISPLAYNUM]""

Andrew suggested that failing to parse the parameter should trigger a
parse error, rather than proceeding as if the setting hadn't been
provided at all.  At the very least, the manpage should be updated to
remove the quoting.

-Doug
dwfreed

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

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Konrad Rzeszutek Wilk]

On Mon, Apr 10, 2017 at 03:21:41PM +0100, Andrew Cooper wrote:
> On 10/04/17 15:12, Konrad Rzeszutek Wilk wrote:
> > On Mon, Apr 10, 2017 at 02:28:58PM +0100, Wei Liu wrote:
> >> On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
> >>> On 10/04/17 12:24, lidonglin wrote:
>  Hi all:
> 
>  I have one question about PCI passthrough. I found
>  that if I created a VM with host pci device(cfg file as below), there
>  were some xenstore keys exsiting in /local/domain/0 and
>  /local/domain/DomID/. Besides I found one unknown device in device
>  manager of Windows OS with Class ID FF80 from vendor ID 5853. My
>  questions  are as below:
> 
>   
> 
>  1.   Why do we create frontend and backend key pairs in xenstore?
>   I think  Passthrough is not PV,  was it possible that we just used
>  these keys to record something?
> 
>  2.After review the code, I think backend keys are used to
>  record state of hostdev, some codes will query something using these
>  keys. But for frontend keys, can we delete them?
> 
>  3.   if frontend keys exist in xenstore, then unknown device will
>  appear in device manager. Can we fix this?  For  an obsessive,  he
>  can’t stand for this.
> 
> >>> This is a libxl bug which has been reported before, but nothing happened.
> >>>
> >>> libxl must not start a PV pci-back when doing HVM PCI passthrough using
> >>> qemu, because absolutely nothing good can come of having two different
> >>> ways of poking at PCI state.
> >>>
> >>> The patch, unchanged from before, is
> >>> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
> >>>
> >> ISTR Konrad made some comments about it. CC Konrad.
> > Aye. My primary beef was that you need some FLR mechanism and pciback
> > does that. The 'do_flr' was the solution to that - as you could
> > effectively do it via an ioctl and all would be good.
> >
> > Except I am probably missing some edge case (like guest is killed
> > and we need to do an FLR again, or there are AERs to deal with, etc) so
> > some pciback -> xenstore -> libxl needs to be in place even for HVM guests.
> >
> > Just disabling pciback for HVM does not solve the problem that:
> >
> >  - We need FLR
> >  - We need AER support (CC-ing Venu who is working on this for 
> > libxl/pciback)
> 
> The problem is that pciback is two distinct pieces of functionality.  It
> should be split in half, so the "steal a device from its real driver and

Yes sure.

> provide reset functionality" is purposefully separate from "be the
> reverse half the PV interface".

> 
> Qemu has no problems with resetting the device when necessary, though,

It does? The sysfs 'reset' is does not do everything you expect.

> which is why this patch functions perfectly well in a real system.
> 
> ~Andrew

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

Re: [Xen-devel] [PATCH for-4.9] xsm: fix clang 3.5 build after c47d1d

[Daniel De Graaf]

On 04/10/2017 04:41 AM, Roger Pau Monne wrote:

On Fri, Apr 07, 2017 at 08:54:59AM -0600, Jan Beulich wrote:

On 07.04.17 at 16:34,  wrote:

The changes introduced on c47d1d broke the clang build due to undefined
references to __xsm_action_mismatch_detected, because clang hasn't optimized
the code properly.


This starts to become annoying.


Yes, tell me about it... I don't think we can blame clang for those failures
anyway. Xen is relying on optimizations to do compile time validations, and
AFAIK this is a grey area. There's nothing in the C spec that guarantees you
that those calls will be removed.

Anyway, will send a new version shortly.


If this problem expands more, I think it would be best to restrict the check to
a particular compiler or #define (as long as it's one used in the build bot);
there's no need to do this kind of check on every build as long as it's done on
occasional builds.  Alternatively, it could be done by a static analysis tool,
but I've not looked into how to do that with Coverity.

--
Daniel De Graaf
National Security Agency

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

Re: [Xen-devel] [PATCH for-4.9 v3 1/3] xsm: fix clang 3.5 build after c47d1d

[Daniel De Graaf]

On 04/10/2017 09:34 AM, Roger Pau Monne wrote:

The changes introduced on c47d1d broke the clang build due to undefined
references to __xsm_action_mismatch_detected, because clang hasn't optimized
the code properly. The following patch allows the clang build to work again,
while keeping the same functionality.

Signed-off-by: Roger Pau Monné 


Acked-by: Daniel De Graaf 

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

Re: [Xen-devel] [PATCH 2/2] xen, input: repair xen-kbdfront resolution setting via xenstore

[Oleksandr Andrushchenko]

On 03/21/2017 07:19 PM, Juergen Gross wrote:

Setting the pointing device resolution via Xenstore isn't working
reliably: in case XenbusStateInitWait has been missed the resolution
settings won't be read. Correct this.

Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross 
---
  drivers/input/misc/xen-kbdfront.c | 32 
  1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 2df5678..7585fa4 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -312,11 +312,27 @@ static void xenkbd_disconnect_backend(struct xenkbd_info 
*info)
info->gref = -1;
  }
  
+static void xenkbd_set_connected(struct xenbus_device *dev)

+{
+   struct xenkbd_info *info = dev_get_drvdata(>dev);
+   int ret;
+
+   if (xenbus_read_unsigned(info->xbdev->otherend,
+"feature-abs-pointer", 0)) {
+   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
+  "request-abs-pointer", "1");
+   if (ret)
+   pr_warn("xenkbd: can't request abs-pointer");
+   }
+
+   xenbus_switch_state(dev, XenbusStateConnected);
+}
+
  static void xenkbd_backend_changed(struct xenbus_device *dev,
   enum xenbus_state backend_state)
  {
struct xenkbd_info *info = dev_get_drvdata(>dev);
-   int ret, val;
+   int val;
  
  	switch (backend_state) {

case XenbusStateInitialising:
@@ -327,16 +343,7 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
break;
  
  	case XenbusStateInitWait:

-InitWait:
-   if (xenbus_read_unsigned(info->xbdev->otherend,
-"feature-abs-pointer", 0)) {
-   ret = xenbus_write(XBT_NIL, info->xbdev->nodename,
-  "request-abs-pointer", "1");
-   if (ret)
-   pr_warning("xenkbd: can't request abs-pointer");
-   }
-
-   xenbus_switch_state(dev, XenbusStateConnected);
+   xenkbd_set_connected(dev);
break;
  
  	case XenbusStateConnected:

@@ -346,7 +353,8 @@ static void xenkbd_backend_changed(struct xenbus_device 
*dev,
 * get Connected twice here.
 */
if (dev->state != XenbusStateConnected)
-   goto InitWait; /* no InitWait seen yet, fudge it */
+   /* No InitWait seen yet, fudge it. */
+   xenkbd_set_connected(dev);
  
  		/* Set input abs params to match backend screen res */

if (xenbus_scanf(XBT_NIL, info->xbdev->otherend,

Reviewed-by: Oleksandr Andrushchenko 

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

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Andrew Cooper]

On 10/04/17 15:12, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 10, 2017 at 02:28:58PM +0100, Wei Liu wrote:
>> On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
>>> On 10/04/17 12:24, lidonglin wrote:
 Hi all:

 I have one question about PCI passthrough. I found
 that if I created a VM with host pci device(cfg file as below), there
 were some xenstore keys exsiting in /local/domain/0 and
 /local/domain/DomID/. Besides I found one unknown device in device
 manager of Windows OS with Class ID FF80 from vendor ID 5853. My
 questions  are as below:

  

 1.   Why do we create frontend and backend key pairs in xenstore?
  I think  Passthrough is not PV,  was it possible that we just used
 these keys to record something?

 2.After review the code, I think backend keys are used to
 record state of hostdev, some codes will query something using these
 keys. But for frontend keys, can we delete them?

 3.   if frontend keys exist in xenstore, then unknown device will
 appear in device manager. Can we fix this?  For  an obsessive,  he
 can’t stand for this.

>>> This is a libxl bug which has been reported before, but nothing happened.
>>>
>>> libxl must not start a PV pci-back when doing HVM PCI passthrough using
>>> qemu, because absolutely nothing good can come of having two different
>>> ways of poking at PCI state.
>>>
>>> The patch, unchanged from before, is
>>> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
>>>
>> ISTR Konrad made some comments about it. CC Konrad.
> Aye. My primary beef was that you need some FLR mechanism and pciback
> does that. The 'do_flr' was the solution to that - as you could
> effectively do it via an ioctl and all would be good.
>
> Except I am probably missing some edge case (like guest is killed
> and we need to do an FLR again, or there are AERs to deal with, etc) so
> some pciback -> xenstore -> libxl needs to be in place even for HVM guests.
>
> Just disabling pciback for HVM does not solve the problem that:
>
>  - We need FLR
>  - We need AER support (CC-ing Venu who is working on this for libxl/pciback)

The problem is that pciback is two distinct pieces of functionality.  It
should be split in half, so the "steal a device from its real driver and
provide reset functionality" is purposefully separate from "be the
reverse half the PV interface".

Qemu has no problems with resetting the device when necessary, though,
which is why this patch functions perfectly well in a real system.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] xen, input: add xen-kbdfront module parameter for setting resolution

[Oleksandr Andrushchenko]

On 04/10/2017 05:11 PM, Juergen Gross wrote:

On 10/04/17 16:00, Oleksandr Andrushchenko wrote:


On 04/10/2017 04:50 PM, Juergen Gross wrote:

On 10/04/17 15:44, Oleksandr Andrushchenko wrote:

Hi, Juergen!

On 03/21/2017 07:19 PM, Juergen Gross wrote:

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

Signed-off-by: Juergen Gross 
---
drivers/input/misc/xen-kbdfront.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 3900875..2df5678 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
};
+enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
+static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(size, int, NULL, 0444);

is this by intention that you use 0444 here?
It means read-only, thus one cannot change these,
so what is the point of the module parameters then?

You can see the settings in sysfs.

this is good so we can see actual width/height
used by the pv driver

The values are settable via boot parameter.

but then, if one has other values set in XenStore,
these will/may be overridden, making it inconsistent,
e.g. values loaded at start as module parameters
(*size* array) is not going to be updated on
XenbusStateInitWait/XenbusStateConnected. So, we'll
end up with wrong parameters shown via sysfs
one more question is why do we need module parameters
if the same can be read from XenStore?

Because up to now nobody is setting the Xenstore values. This is
something I'm planning to do for Xen 4.10.

ah, good to know. btw, if you are about to add
width/height for the pointer device will you also add
the same for multi-touch?

  Up to then we need a
workaround.

But you are right: The module parameters should be updated with
the values read from Xenstore.


Juergen



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

[Xen-devel] [PATCH for-4.9 v3 3/3] x86/atomic: fix cmpxchg16b inline assembly to work with clang

[Roger Pau Monne]

clang doesn't understand the "=A" register constrain when used with 64bits
assembly and spits out an internal error:

fatal error: error in backend: Cannot select: 0x7f9fb89c9390: i64 = build_pair 
0x7f9fb89c92b0,
  0x7f9fb89c9320
  0x7f9fb89c92b0: i32,ch,glue = CopyFromReg 0x7f9fb89c9240, Register:i32 %EAX, 
0x7f9fb89c9240:1
0x7f9fb89c8c20: i32 = Register %EAX
0x7f9fb89c9240: ch,glue = inlineasm 0x7f9fb89c90f0,
TargetExternalSymbol:i64'lock; cmpxchg16b $1', MDNode:ch<0x7f9fb8476c38>,
TargetConstant:i64<25>, TargetConstant:i32<18>, Register:i32 %EAX, Register:i32
%EDX, TargetConstant:i32<196622>, 0x7f9fb89c87c0, TargetConstant:i32<9>,
Register:i64 %RCX, TargetConstant:i32<9>, Register:i64 %RBX,
TargetConstant:i32<9>, Register:i64 %RDX, TargetConstant:i32<9>, Register:i64
%RAX, TargetConstant:i32<196622>, 0x7f9fb89c87c0, TargetConstant:i32<12>,
Register:i32 %EFLAGS, 0x7f9fb89c90f0:1
  0x7f9fb89c8a60: i64 = TargetExternalSymbol'lock; cmpxchg16b $1'
  0x7f9fb89c8b40: i64 = TargetConstant<25>
  0x7f9fb89c8bb0: i32 = TargetConstant<18>
  0x7f9fb89c8c20: i32 = Register %EAX
  0x7f9fb89c8c90: i32 = Register %EDX
  0x7f9fb89c8d00: i32 = TargetConstant<196622>
  0x7f9fb89c87c0: i64,ch = load 0x7f9fb9053da0, FrameIndex:i64<1>, 
undef:i64
0x7f9fb9053a90: i64 = FrameIndex<1>
0x7f9fb9053e80: i64 = undef
  0x7f9fb89c8e50: i32 = TargetConstant<9>
  0x7f9fb89c8d70: i64 = Register %RCX
  0x7f9fb89c8e50: i32 = TargetConstant<9>
  0x7f9fb89c8ec0: i64 = Register %RBX
  0x7f9fb89c8e50: i32 = TargetConstant<9>
  0x7f9fb89c8fa0: i64 = Register %RDX
  0x7f9fb89c8e50: i32 = TargetConstant<9>
  0x7f9fb89c9080: i64 = Register %RAX
[...]

Fix this by specifying "rdx:rax" manually using the "d" and "a" constraints.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v2:
 - New in this version.

---
NB: this is the only usage of "=A" on 64bit assembly in Xen. I will send a bug
report upstream to get this fixed, so that clang properly understands "=A" for
64bit assembly as "RDX:RAX", but in the meantime I would like to get this
patch accepted so the clang build can be functional again.

Upstream bug report can be found at: http://bugs.llvm.org/show_bug.cgi?id=32594
---
 xen/include/asm-x86/x86_64/system.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/xen/include/asm-x86/x86_64/system.h 
b/xen/include/asm-x86/x86_64/system.h
index 7026c05a25..0a438cd9d1 100644
--- a/xen/include/asm-x86/x86_64/system.h
+++ b/xen/include/asm-x86/x86_64/system.h
@@ -14,20 +14,20 @@
  */
 
 static always_inline __uint128_t __cmpxchg16b(
-volatile void *ptr, const __uint128_t *old, const __uint128_t *new)
+volatile void *ptr, const __uint128_t *oldp, const __uint128_t *newp)
 {
-__uint128_t prev;
-uint64_t new_high = *new >> 64;
-uint64_t new_low = *new;
+union {
+struct { uint64_t lo, hi; };
+__uint128_t raw;
+} new = { .raw = *newp }, old = { .raw = *oldp }, prev;
 
 ASSERT(cpu_has_cx16);
 
-asm volatile ( "lock; cmpxchg16b %1"
-   : "=A" (prev), "+m" (*__xg(ptr))
-   : "c" (new_high), "b" (new_low),
- "0" (*old) );
+asm volatile ( "lock; cmpxchg16b %2"
+   : "=d" (prev.hi), "=a" (prev.lo), "+m" (*__xg(ptr))
+   : "c" (new.hi), "b" (new.lo), "0" (old.hi), "1" (old.lo) );
 
-return prev;
+return prev.raw;
 }
 
 #define cmpxchg16b(ptr, o, n) ({   \
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH for-4.9 v3 1/3] xsm: fix clang 3.5 build after c47d1d

[Roger Pau Monne]

The changes introduced on c47d1d broke the clang build due to undefined
references to __xsm_action_mismatch_detected, because clang hasn't optimized
the code properly. The following patch allows the clang build to work again,
while keeping the same functionality.

Signed-off-by: Roger Pau Monné 
---
Cc: Daniel De Graaf 
Cc: Julien Grall 
Cc: Tamas K Lengyel 
---
Changes since v2:
 - Use an "if" like v1.

Changes since v1:
 - Remove unused "break".
 - Remove if condition.

NB: this fixes travis build: https://travis-ci.org/royger/xen/builds/219697038
---
 xen/include/xsm/dummy.h | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 56a8814d82..62fcea6f04 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -557,25 +557,21 @@ static XSM_INLINE int 
xsm_hvm_param_altp2mhvm(XSM_DEFAULT_ARG struct domain *d)
 
 static XSM_INLINE int xsm_hvm_altp2mhvm_op(XSM_DEFAULT_ARG struct domain *d, 
uint64_t mode, uint32_t op)
 {
-xsm_default_t a;
 XSM_ASSERT_ACTION(XSM_OTHER);
 
 switch ( mode )
 {
 case XEN_ALTP2M_mixed:
-a = XSM_TARGET;
-break;
+return xsm_default_action(XSM_TARGET, current->domain, d);
 case XEN_ALTP2M_external:
-a = XSM_DM_PRIV;
-break;
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 case XEN_ALTP2M_limited:
-a = (HVMOP_altp2m_vcpu_enable_notify == op) ? XSM_TARGET : XSM_DM_PRIV;
-break;
+if ( HVMOP_altp2m_vcpu_enable_notify == op )
+return xsm_default_action(XSM_TARGET, current->domain, d);
+return xsm_default_action(XSM_DM_PRIV, current->domain, d);
 default:
 return -EPERM;
-};
-
-return xsm_default_action(a, current->domain, d);
+}
 }
 
 static XSM_INLINE int xsm_vm_event_control(XSM_DEFAULT_ARG struct domain *d, 
int mode, int op)
-- 
2.11.0 (Apple Git-81)


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

[Xen-devel] [PATCH for-4.9 v3 2/3] x86/atomic: fix clang build

[Roger Pau Monne]

The current code in dm_op breaks clang build with:

dm.c:411:21: error: 'break' is bound to loop, GCC binds it to switch 
[-Werror,-Wgcc-compat]
while ( read_atomic(>ioreq.entry_count) &&
^
xen/include/asm/atomic.h:53:43: note: expanded from macro 'read_atomic'
default: x_ = 0; __bad_atomic_size(); break;  \
  ^

Introduce a readatomic static inline helper function in order to solve this.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Changes since v2:
 - Introduce a readatomic static inline helper in order to prevent moving the
   read_atomic check.

Changes since v1:
 - New in this version.
---
 xen/include/asm-x86/atomic.h | 44 +---
 1 file changed, 33 insertions(+), 11 deletions(-)

diff --git a/xen/include/asm-x86/atomic.h b/xen/include/asm-x86/atomic.h
index 2fbe705518..ae87a0dcf5 100644
--- a/xen/include/asm-x86/atomic.h
+++ b/xen/include/asm-x86/atomic.h
@@ -41,20 +41,42 @@ build_add_sized(add_u64_sized, "q", uint64_t, "ri")
 #undef build_write_atomic
 #undef build_add_sized
 
-void __bad_atomic_size(void);
+/*
+ * NB: read_atomic needs to be a static inline function because clang doesn't
+ * like breaks inside of expressions, even when there's an inner switch where
+ * those breaks should apply, and complains with "'break' is bound to loop, GCC
+ * binds it to switch", so the following code:
+ *
+ * while ( read_atomic() ) { ... }
+ *
+ * Doesn't work if read_atomic is a macro with an inner switch.
+ */
+static inline unsigned long readatomic(const void *p, size_t s)
+{
+switch ( s )
+{
+case 1:
+return read_u8_atomic((uint8_t *)p);
+case 2:
+return read_u16_atomic((uint16_t *)p);
+case 4:
+return read_u32_atomic((uint32_t *)p);
+case 8:
+return read_u64_atomic((uint64_t *)p);
+default:
+ASSERT_UNREACHABLE();
+return 0;
+}
+}
 
-#define read_atomic(p) ({ \
-unsigned long x_; \
-switch ( sizeof(*(p)) ) { \
-case 1: x_ = read_u8_atomic((uint8_t *)(p)); break;   \
-case 2: x_ = read_u16_atomic((uint16_t *)(p)); break; \
-case 4: x_ = read_u32_atomic((uint32_t *)(p)); break; \
-case 8: x_ = read_u64_atomic((uint64_t *)(p)); break; \
-default: x_ = 0; __bad_atomic_size(); break;  \
-} \
-(typeof(*(p)))x_; \
+#define read_atomic(p) ({  \
+BUILD_BUG_ON(sizeof(*(p)) != 1 && sizeof(*(p)) != 2 && \
+ sizeof(*(p)) != 4 && sizeof(*(p)) != 8);  \
+(typeof(*(p)))readatomic(p, sizeof(*(p))); \
 })
 
+void __bad_atomic_size(void);
+
 #define write_atomic(p, x) ({ \
 typeof(*(p)) __x = (x);   \
 unsigned long x_ = (unsigned long)__x;\
-- 
2.11.0 (Apple Git-81)


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

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Konrad Rzeszutek Wilk]

On Mon, Apr 10, 2017 at 02:28:58PM +0100, Wei Liu wrote:
> On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
> > On 10/04/17 12:24, lidonglin wrote:
> > >
> > > Hi all:
> > >
> > > I have one question about PCI passthrough. I found
> > > that if I created a VM with host pci device(cfg file as below), there
> > > were some xenstore keys exsiting in /local/domain/0 and
> > > /local/domain/DomID/. Besides I found one unknown device in device
> > > manager of Windows OS with Class ID FF80 from vendor ID 5853. My
> > > questions  are as below:
> > >
> > >  
> > >
> > > 1.   Why do we create frontend and backend key pairs in xenstore?
> > >  I think  Passthrough is not PV,  was it possible that we just used
> > > these keys to record something?
> > >
> > > 2.After review the code, I think backend keys are used to
> > > record state of hostdev, some codes will query something using these
> > > keys. But for frontend keys, can we delete them?
> > >
> > > 3.   if frontend keys exist in xenstore, then unknown device will
> > > appear in device manager. Can we fix this?  For  an obsessive,  he
> > > can’t stand for this.
> > >
> > 
> > This is a libxl bug which has been reported before, but nothing happened.
> > 
> > libxl must not start a PV pci-back when doing HVM PCI passthrough using
> > qemu, because absolutely nothing good can come of having two different
> > ways of poking at PCI state.
> > 
> > The patch, unchanged from before, is
> > https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
> > 
> 
> ISTR Konrad made some comments about it. CC Konrad.

Aye. My primary beef was that you need some FLR mechanism and pciback
does that. The 'do_flr' was the solution to that - as you could
effectively do it via an ioctl and all would be good.

Except I am probably missing some edge case (like guest is killed
and we need to do an FLR again, or there are AERs to deal with, etc) so
some pciback -> xenstore -> libxl needs to be in place even for HVM guests.

Just disabling pciback for HVM does not solve the problem that:

 - We need FLR
 - We need AER support (CC-ing Venu who is working on this for libxl/pciback)

> 
> > ~Andrew

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

On 04/10/2017 09:57 AM, Juergen Gross wrote:
> On 10/04/17 15:47, Boris Ostrovsky wrote:
>> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
 On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>>> tl;dr:
>>>  Please apply
>>>
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>>> partially revert "xen: Remove event channel notification through
>>>   Xen PCI platform device"
>>>
>>>  to all stable branches which have a version of the original broken
>>>  commit.  This includes at least 4.9.y.
>>>
>>> Background:
>>>
>>> osstest service owner writes ("[linux-4.9 baseline test] 107238: 
>>> tolerable FAIL"):
>>> ...
  test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
>>> osstest doesn't consider this a regresion because it looks for
>>> regressions within a branch, and this is the first test of Linux 4.9.
>>> However, this is a regression from the kernel we are currently using.
>>>
>>> L1 dom0 console log:
>>>   
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>>
>>> It seems to have got stuck halfway through booting.
>>>
>>> The message
>>>   (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
>>> input to DOM0)
>>> shows where osstest timed out on this test, and started its log
>>> capture process (including collecting debug key output).
>>>
>>> Complete logs for this job here:
>>>   
>>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>>
>>> Juergen Gross tells me that this is due to the lack of
>>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>>
>>> Thanks,
>>> Ian.
>>>
>>> PS: Stefano, Boris: did you already request a backport of this commit?
>>> If not, why not ?
>> No, but this should indeed be backported to 4.9+
> Boris, are you going to do that?
 Is there anything that needs to be done beyond just applying it to 4.9
 (4.10 apparently already has it).
>>> No, I don't think so. 4.9 already has the offending commit.
>>
>> Looks like there will be a new version of the original patch
>> (72a9b186292) so we should hold off with backport request to 4.9:
>>
>> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html
> TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
> reworked: Do we really care for Xen versions < 4.0 and a theoretical
> problem (after all the author admitted the bug isn't being hit in
> reality due to a short-circuit in the code)?

I don't know what the deal is with <4.0 Xen and I am not sure whether we
can boot new-ish Linux on those releases regardless of this specific
issue. I am certainly only testing Xen 4.1+ and have been doing this for
at least last 2-3 years.


>
> And even if we do: I'd rather add another patch to stable later than
> keeping a real bug in Linux 4.9 which has been hit at least 3 times
> up to now (by Stefano, George and Ian).

That would depend on how soon the new patch shows up.

-boris

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

Re: [Xen-devel] [PATCH 1/2] xen, input: add xen-kbdfront module parameter for setting resolution

[Juergen Gross]

On 10/04/17 16:00, Oleksandr Andrushchenko wrote:
> 
> 
> On 04/10/2017 04:50 PM, Juergen Gross wrote:
>> On 10/04/17 15:44, Oleksandr Andrushchenko wrote:
>>> Hi, Juergen!
>>>
>>> On 03/21/2017 07:19 PM, Juergen Gross wrote:
 Add a parameter for setting the resolution of xen-kbdfront in order to
 be able to cope with a (virtual) frame buffer of arbitrary resolution.

 Signed-off-by: Juergen Gross 
 ---
drivers/input/misc/xen-kbdfront.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)

 diff --git a/drivers/input/misc/xen-kbdfront.c
 b/drivers/input/misc/xen-kbdfront.c
 index 3900875..2df5678 100644
 --- a/drivers/input/misc/xen-kbdfront.c
 +++ b/drivers/input/misc/xen-kbdfront.c
 @@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
};
+enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
 +static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
 +module_param_array(size, int, NULL, 0444);
>>> is this by intention that you use 0444 here?
>>> It means read-only, thus one cannot change these,
>>> so what is the point of the module parameters then?
>> You can see the settings in sysfs.
> this is good so we can see actual width/height
> used by the pv driver
>> The values are settable via boot parameter.
> but then, if one has other values set in XenStore,
> these will/may be overridden, making it inconsistent,
> e.g. values loaded at start as module parameters
> (*size* array) is not going to be updated on
> XenbusStateInitWait/XenbusStateConnected. So, we'll
> end up with wrong parameters shown via sysfs
> one more question is why do we need module parameters
> if the same can be read from XenStore?

Because up to now nobody is setting the Xenstore values. This is
something I'm planning to do for Xen 4.10. Up to then we need a
workaround.

But you are right: The module parameters should be updated with
the values read from Xenstore.


Juergen

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

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Wei Liu]

On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
> On 10/04/17 12:24, lidonglin wrote:
> >
> > Hi all:
> >
> > I have one question about PCI passthrough. I found
> > that if I created a VM with host pci device(cfg file as below), there
> > were some xenstore keys exsiting in /local/domain/0 and
> > /local/domain/DomID/. Besides I found one unknown device in device
> > manager of Windows OS with Class ID FF80 from vendor ID 5853. My
> > questions  are as below:
> >
> >  
> >
> > 1.   Why do we create frontend and backend key pairs in xenstore?
> >  I think  Passthrough is not PV,  was it possible that we just used
> > these keys to record something?
> >
> > 2.After review the code, I think backend keys are used to
> > record state of hostdev, some codes will query something using these
> > keys. But for frontend keys, can we delete them?
> >
> > 3.   if frontend keys exist in xenstore, then unknown device will
> > appear in device manager. Can we fix this?  For  an obsessive,  he
> > can’t stand for this.
> >
> 
> This is a libxl bug which has been reported before, but nothing happened.
> 
> libxl must not start a PV pci-back when doing HVM PCI passthrough using
> qemu, because absolutely nothing good can come of having two different
> ways of poking at PCI state.
> 
> The patch, unchanged from before, is
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch
> 

ISTR Konrad made some comments about it. CC Konrad.

> ~Andrew

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

[Xen-devel] [PATCH for-next 1/8] xen.h: fix comment for vcpu_guest_context

[Wei Liu]

Use the correct vcpuop name and delete on trailing white space.

Signed-off-by: Wei Liu 
---
 xen/include/public/arch-x86/xen.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index 8a9ba7982b..f21332e897 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -159,10 +159,10 @@ DEFINE_XEN_GUEST_HANDLE(trap_info_t);
 typedef uint64_t tsc_timestamp_t; /* RDTSC timestamp */
 
 /*
- * The following is all CPU context. Note that the fpu_ctxt block is filled 
+ * The following is all CPU context. Note that the fpu_ctxt block is filled
  * in by FXSAVE if the CPU has feature FXSR; otherwise FSAVE is used.
  *
- * Also note that when calling DOMCTL_setvcpucontext and VCPU_initialise
+ * Also note that when calling DOMCTL_setvcpucontext and VCPUOP_initialise
  * for HVM and PVH guests, not all information in this structure is updated:
  *
  * - For HVM guests, the structures read include: fpu_ctxt (if
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 0/8] Refactor x86/domain.c

[Wei Liu]

This series refactors x86/domain.c to move HVM and PV specific code to their
respective directory.

The arch_set_info_guest is not touched yet. Refactoring that function will be
in another series because 1) I need to touch ARM code as well; 2) I need to do
some archaeology to know why it is done like that. The end result possibily
will involve changing toolstack a bit as well.

Wei.

Wei Liu (8):
  xen.h: fix comment for vcpu_guest_context
  x86/domain: factor out pv_vcpu_initialise
  x86/domain: factor out pv_vcpu_destroy
  x86/domain: push some code down to hvm_domain_initialise
  x86/domain: factor out pv_domain_destroy
  x86/domain: factor out pv_domain_initialise
  x86/domain: move PV specific code to pv/domain.c
  x86/domain: move HVM specific code to hvm/domain.c

 xen/arch/x86/domain.c | 538 ++
 xen/arch/x86/hvm/Makefile |   1 +
 xen/arch/x86/hvm/domain.c | 322 +++
 xen/arch/x86/hvm/hvm.c|  25 +-
 xen/arch/x86/pv/Makefile  |   1 +
 xen/arch/x86/pv/domain.c  | 270 +++
 xen/include/asm-x86/domain.h  |   3 +
 xen/include/asm-x86/hvm/hvm.h |   2 +-
 xen/include/asm-x86/pv/pv.h   |  29 ++
 xen/include/public/arch-x86/xen.h |   4 +-
 10 files changed, 662 insertions(+), 533 deletions(-)
 create mode 100644 xen/arch/x86/hvm/domain.c
 create mode 100644 xen/arch/x86/pv/domain.c
 create mode 100644 xen/include/asm-x86/pv/pv.h

-- 
2.11.0


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

[Xen-devel] [PATCH for-next 3/8] x86/domain: factor out pv_vcpu_destroy

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 96c777c771..ddebff6187 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -479,17 +479,22 @@ int vcpu_initialise(struct vcpu *v)
 return rc;
 }
 
-void vcpu_destroy(struct vcpu *v)
+static void pv_vcpu_destroy(struct vcpu *v)
 {
-xfree(v->arch.vm_event);
-v->arch.vm_event = NULL;
-
 if ( is_pv_32bit_vcpu(v) )
 {
 free_compat_arg_xlat(v);
 release_compat_l4(v);
 }
 
+xfree(v->arch.pv_vcpu.trap_ctxt);
+}
+
+void vcpu_destroy(struct vcpu *v)
+{
+xfree(v->arch.vm_event);
+v->arch.vm_event = NULL;
+
 vcpu_destroy_fpu(v);
 
 if ( !is_idle_domain(v->domain) )
@@ -498,8 +503,8 @@ void vcpu_destroy(struct vcpu *v)
 if ( is_hvm_vcpu(v) )
 hvm_vcpu_destroy(v);
 else
-xfree(v->arch.pv_vcpu.trap_ctxt);
-}
+pv_vcpu_destroy(v);
+ }
 
 static bool emulation_flags_ok(const struct domain *d, uint32_t emflags)
 {
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 4/8] x86/domain: push some code down to hvm_domain_initialise

[Wei Liu]

We want to have a single entry point to initialise hvm guest.  The
timing to set hap bit and create per domain mapping is deferred, but
that's not a problem.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 11 ++-
 xen/arch/x86/hvm/hvm.c| 25 +
 xen/include/asm-x86/hvm/hvm.h |  2 +-
 3 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ddebff6187..af060d8239 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -587,14 +587,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 d->arch.emulation_flags = emflags;
 }
 
-if ( is_hvm_domain(d) )
-{
-d->arch.hvm_domain.hap_enabled =
-hvm_funcs.hap_supported && (domcr_flags & DOMCRF_hap);
-
-rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
-}
-else if ( is_idle_domain(d) )
+if ( is_idle_domain(d) )
 rc = 0;
 else
 {
@@ -663,7 +656,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 
 if ( is_hvm_domain(d) )
 {
-if ( (rc = hvm_domain_initialise(d)) != 0 )
+if ( (rc = hvm_domain_initialise(d, domcr_flags)) != 0 )
 goto fail;
 }
 else
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f50d15ff50..7fc49bb03d 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -595,7 +595,7 @@ static int hvm_print_line(
 return X86EMUL_OKAY;
 }
 
-int hvm_domain_initialise(struct domain *d)
+int hvm_domain_initialise(struct domain *d, unsigned int domcr_flags)
 {
 unsigned int nr_gsis;
 int rc;
@@ -615,10 +615,17 @@ int hvm_domain_initialise(struct domain *d)
 
 hvm_init_cacheattr_region_list(d);
 
-rc = paging_enable(d, PG_refcounts|PG_translate|PG_external);
+d->arch.hvm_domain.hap_enabled =
+hvm_funcs.hap_supported && (domcr_flags & DOMCRF_hap);
+
+rc = create_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0, NULL, NULL);
 if ( rc != 0 )
 goto fail0;
 
+rc = paging_enable(d, PG_refcounts|PG_translate|PG_external);
+if ( rc != 0 )
+goto fail1;
+
 nr_gsis = is_hardware_domain(d) ? nr_irqs_gsi : NR_HVM_DOMU_IRQS;
 d->arch.hvm_domain.pl_time = xzalloc(struct pl_time);
 d->arch.hvm_domain.params = xzalloc_array(uint64_t, HVM_NR_PARAMS);
@@ -629,7 +636,7 @@ int hvm_domain_initialise(struct domain *d)
 rc = -ENOMEM;
 if ( !d->arch.hvm_domain.pl_time || !d->arch.hvm_domain.irq ||
  !d->arch.hvm_domain.params  || !d->arch.hvm_domain.io_handler )
-goto fail1;
+goto fail2;
 
 /* Set the number of GSIs */
 hvm_domain_irq(d)->nr_gsis = nr_gsis;
@@ -647,7 +654,7 @@ int hvm_domain_initialise(struct domain *d)
 if ( d->arch.hvm_domain.io_bitmap == NULL )
 {
 rc = -ENOMEM;
-goto fail1;
+goto fail2;
 }
 memset(d->arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
 }
@@ -666,7 +673,7 @@ int hvm_domain_initialise(struct domain *d)
 
 rc = vioapic_init(d);
 if ( rc != 0 )
-goto fail1;
+goto fail2;
 
 stdvga_init(d);
 
@@ -679,21 +686,23 @@ int hvm_domain_initialise(struct domain *d)
 
 rc = hvm_funcs.domain_initialise(d);
 if ( rc != 0 )
-goto fail2;
+goto fail3;
 
 return 0;
 
- fail2:
+ fail3:
 rtc_deinit(d);
 stdvga_deinit(d);
 vioapic_deinit(d);
- fail1:
+ fail2:
 if ( is_hardware_domain(d) )
 xfree(d->arch.hvm_domain.io_bitmap);
 xfree(d->arch.hvm_domain.io_handler);
 xfree(d->arch.hvm_domain.params);
 xfree(d->arch.hvm_domain.pl_time);
 xfree(d->arch.hvm_domain.irq);
+ fail1:
+destroy_perdomain_mapping(d, PERDOMAIN_VIRT_START, 0);
  fail0:
 hvm_destroy_cacheattr_region_list(d);
 return rc;
diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
index 7a85b2e3b5..d3fef9ca52 100644
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -236,7 +236,7 @@ extern s8 hvm_port80_allowed;
 extern const struct hvm_function_table *start_svm(void);
 extern const struct hvm_function_table *start_vmx(void);
 
-int hvm_domain_initialise(struct domain *d);
+int hvm_domain_initialise(struct domain *d, unsigned int domcr_flags);
 void hvm_domain_relinquish_resources(struct domain *d);
 void hvm_domain_destroy(struct domain *d);
 void hvm_domain_soft_reset(struct domain *d);
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 5/8] x86/domain: factor out pv_domain_destroy

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index af060d8239..05885a103d 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -527,6 +527,12 @@ static bool emulation_flags_ok(const struct domain *d, 
uint32_t emflags)
 return true;
 }
 
+static void pv_domain_destroy(struct domain *d)
+{
+xfree(d->arch.pv_domain.cpuidmasks);
+free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
@@ -704,10 +710,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 paging_final_teardown(d);
 free_perdomain_mappings(d);
 if ( is_pv_domain(d) )
-{
-xfree(d->arch.pv_domain.cpuidmasks);
-free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
-}
+pv_domain_destroy(d);
+
 return rc;
 }
 
@@ -727,10 +731,7 @@ void arch_domain_destroy(struct domain *d)
 
 free_perdomain_mappings(d);
 if ( is_pv_domain(d) )
-{
-free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
-xfree(d->arch.pv_domain.cpuidmasks);
-}
+pv_domain_destroy(d);
 
 free_xenheap_page(d->shared_info);
 cleanup_domain_irq_mapping(d);
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 6/8] x86/domain: factor out pv_domain_initialise

[Wei Liu]

Lump everything PV related in arch_domain_create into
pv_domain_initialise.

Though domcr_flags is not necessary, the new function is given one to
match hvm counterpart.

Since it cleans up after itself there is no need to clean up in
arch_domain_create in case of failure.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 97 +++
 1 file changed, 60 insertions(+), 37 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 05885a103d..ed16adf77a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -533,6 +533,58 @@ static void pv_domain_destroy(struct domain *d)
 free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
 }
 
+static int pv_domain_initialise(struct domain *d, unsigned int domcr_flags)
+{
+static const struct arch_csw pv_csw = {
+.from = paravirt_ctxt_switch_from,
+.to   = paravirt_ctxt_switch_to,
+.tail = continue_nonidle_domain,
+};
+int rc = -ENOMEM;
+
+d->arch.pv_domain.gdt_ldt_l1tab =
+alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
+if ( !d->arch.pv_domain.gdt_ldt_l1tab )
+goto fail;
+clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
+
+if ( levelling_caps & ~LCAP_faulting )
+{
+d->arch.pv_domain.cpuidmasks = xmalloc(struct cpuidmasks);
+if ( !d->arch.pv_domain.cpuidmasks )
+goto fail;
+*d->arch.pv_domain.cpuidmasks = cpuidmask_defaults;
+}
+
+rc = create_perdomain_mapping(d, GDT_LDT_VIRT_START,
+  GDT_LDT_MBYTES << (20 - PAGE_SHIFT),
+  NULL, NULL);
+if ( rc )
+goto fail;
+
+d->arch.ctxt_switch = _csw;
+
+/* 64-bit PV guest by default. */
+d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+
+return 0;
+
+fail:
+if ( d->arch.pv_domain.gdt_ldt_l1tab )
+{
+free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
+d->arch.pv_domain.gdt_ldt_l1tab = NULL;
+}
+
+if ( d->arch.pv_domain.cpuidmasks )
+{
+xfree(d->arch.pv_domain.cpuidmasks);
+d->arch.pv_domain.cpuidmasks = NULL;
+}
+
+return rc;
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
@@ -593,30 +645,7 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 d->arch.emulation_flags = emflags;
 }
 
-if ( is_idle_domain(d) )
-rc = 0;
-else
-{
-d->arch.pv_domain.gdt_ldt_l1tab =
-alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
-if ( !d->arch.pv_domain.gdt_ldt_l1tab )
-goto fail;
-clear_page(d->arch.pv_domain.gdt_ldt_l1tab);
-
-if ( levelling_caps & ~LCAP_faulting )
-{
-d->arch.pv_domain.cpuidmasks = xmalloc(struct cpuidmasks);
-if ( !d->arch.pv_domain.cpuidmasks )
-goto fail;
-*d->arch.pv_domain.cpuidmasks = cpuidmask_defaults;
-}
-
-rc = create_perdomain_mapping(d, GDT_LDT_VIRT_START,
-  GDT_LDT_MBYTES << (20 - PAGE_SHIFT),
-  NULL, NULL);
-}
-if ( rc )
-goto fail;
+rc = 0;
 
 mapcache_domain_init(d);
 
@@ -665,23 +694,20 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( (rc = hvm_domain_initialise(d, domcr_flags)) != 0 )
 goto fail;
 }
-else
+else if ( is_idle_domain(d) )
 {
-static const struct arch_csw pv_csw = {
-.from = paravirt_ctxt_switch_from,
-.to   = paravirt_ctxt_switch_to,
-.tail = continue_nonidle_domain,
-};
 static const struct arch_csw idle_csw = {
 .from = paravirt_ctxt_switch_from,
 .to   = paravirt_ctxt_switch_to,
 .tail = continue_idle_domain,
 };
 
-d->arch.ctxt_switch = is_idle_domain(d) ? _csw : _csw;
-
-/* 64-bit PV guest by default. */
-d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
+d->arch.ctxt_switch = _csw;
+}
+else
+{
+if ( (rc = pv_domain_initialise(d, domcr_flags)) != 0 )
+goto fail;
 }
 
 /* initialize default tsc behavior in case tools don't */
@@ -709,9 +735,6 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 if ( paging_initialised )
 paging_final_teardown(d);
 free_perdomain_mappings(d);
-if ( is_pv_domain(d) )
-pv_domain_destroy(d);
-
 return rc;
 }
 
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 2/8] x86/domain: factor out pv_vcpu_initialise

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 65 ---
 1 file changed, 36 insertions(+), 29 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 90e2b1f82a..96c777c771 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -387,37 +387,10 @@ int switch_compat(struct domain *d)
 return rc;
 }
 
-int vcpu_initialise(struct vcpu *v)
+static int pv_vcpu_initialise(struct vcpu *v)
 {
 struct domain *d = v->domain;
-int rc;
-
-v->arch.flags = TF_kernel_mode;
-
-rc = mapcache_vcpu_init(v);
-if ( rc )
-return rc;
-
-if ( !is_idle_domain(d) )
-{
-paging_vcpu_init(v);
-
-if ( (rc = vcpu_init_fpu(v)) != 0 )
-return rc;
-
-vmce_init_vcpu(v);
-}
-else if ( (rc = xstate_alloc_save_area(v)) != 0 )
-return rc;
-
-spin_lock_init(>arch.vpmu.vpmu_lock);
-
-if ( is_hvm_domain(d) )
-{
-rc = hvm_vcpu_initialise(v);
-goto done;
-}
-
+int rc = 0;
 
 spin_lock_init(>arch.pv_vcpu.shadow_ldt_lock);
 
@@ -458,7 +431,41 @@ int vcpu_initialise(struct vcpu *v)
 goto done;
 }
 }
+
  done:
+return rc;
+}
+
+int vcpu_initialise(struct vcpu *v)
+{
+struct domain *d = v->domain;
+int rc;
+
+v->arch.flags = TF_kernel_mode;
+
+rc = mapcache_vcpu_init(v);
+if ( rc )
+return rc;
+
+if ( !is_idle_domain(d) )
+{
+paging_vcpu_init(v);
+
+if ( (rc = vcpu_init_fpu(v)) != 0 )
+return rc;
+
+vmce_init_vcpu(v);
+}
+else if ( (rc = xstate_alloc_save_area(v)) != 0 )
+return rc;
+
+spin_lock_init(>arch.vpmu.vpmu_lock);
+
+if ( is_hvm_domain(d) )
+rc = hvm_vcpu_initialise(v);
+else
+rc = pv_vcpu_initialise(v);
+
 if ( rc )
 {
 vcpu_destroy_fpu(v);
-- 
2.11.0


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

[Xen-devel] [PATCH for-next 8/8] x86/domain: move HVM specific code to hvm/domain.c

[Wei Liu]

There is only one function arch_set_info_hvm_guest is moved. The
check_segment function is also moved since arch_set_info_hvm_guest is
the only user.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c | 291 -
 xen/arch/x86/hvm/Makefile |   1 +
 xen/arch/x86/hvm/domain.c | 322 ++
 3 files changed, 323 insertions(+), 291 deletions(-)
 create mode 100644 xen/arch/x86/hvm/domain.c

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4a2363fc96..80a86e1ba2 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1060,297 +1060,6 @@ int arch_set_info_guest(
 #undef c
 }
 
-static inline int check_segment(struct segment_register *reg,
-enum x86_segment seg)
-{
-
-if ( reg->attr.fields.pad != 0 )
-{
-gprintk(XENLOG_ERR, "Segment attribute bits 12-15 are not zero\n");
-return -EINVAL;
-}
-
-if ( reg->attr.bytes == 0 )
-{
-if ( seg != x86_seg_ds && seg != x86_seg_es )
-{
-gprintk(XENLOG_ERR, "Null selector provided for CS, SS or TR\n");
-return -EINVAL;
-}
-return 0;
-}
-
-if ( seg == x86_seg_tr )
-{
-if ( reg->attr.fields.s )
-{
-gprintk(XENLOG_ERR, "Code or data segment provided for TR\n");
-return -EINVAL;
-}
-
-if ( reg->attr.fields.type != SYS_DESC_tss_busy )
-{
-gprintk(XENLOG_ERR, "Non-32-bit-TSS segment provided for TR\n");
-return -EINVAL;
-}
-}
-else if ( !reg->attr.fields.s )
-{
-gprintk(XENLOG_ERR,
-"System segment provided for a code or data segment\n");
-return -EINVAL;
-}
-
-if ( !reg->attr.fields.p )
-{
-gprintk(XENLOG_ERR, "Non-present segment provided\n");
-return -EINVAL;
-}
-
-if ( seg == x86_seg_cs && !(reg->attr.fields.type & 0x8) )
-{
-gprintk(XENLOG_ERR, "Non-code segment provided for CS\n");
-return -EINVAL;
-}
-
-if ( seg == x86_seg_ss &&
- ((reg->attr.fields.type & 0x8) || !(reg->attr.fields.type & 0x2)) )
-{
-gprintk(XENLOG_ERR, "Non-writeable segment provided for SS\n");
-return -EINVAL;
-}
-
-if ( reg->attr.fields.s && seg != x86_seg_ss && seg != x86_seg_cs &&
- (reg->attr.fields.type & 0x8) && !(reg->attr.fields.type & 0x2) )
-{
-gprintk(XENLOG_ERR, "Non-readable segment provided for DS or ES\n");
-return -EINVAL;
-}
-
-return 0;
-}
-
-/* Called by VCPUOP_initialise for HVM guests. */
-int arch_set_info_hvm_guest(struct vcpu *v, const vcpu_hvm_context_t *ctx)
-{
-struct cpu_user_regs *uregs = >arch.user_regs;
-struct segment_register cs, ds, ss, es, tr;
-const char *errstr;
-int rc;
-
-if ( ctx->pad != 0 )
-return -EINVAL;
-
-switch ( ctx->mode )
-{
-default:
-return -EINVAL;
-
-case VCPU_HVM_MODE_32B:
-{
-const struct vcpu_hvm_x86_32 *regs = >cpu_regs.x86_32;
-uint32_t limit;
-
-if ( ctx->cpu_regs.x86_32.pad1 != 0 ||
- ctx->cpu_regs.x86_32.pad2[0] != 0 ||
- ctx->cpu_regs.x86_32.pad2[1] != 0 ||
- ctx->cpu_regs.x86_32.pad2[2] != 0 )
-return -EINVAL;
-
-#define SEG(s, r) ({\
-s = (struct segment_register){ .base = (r)->s ## _base, \
-   .limit = (r)->s ## _limit,   \
-   .attr.bytes = (r)->s ## _ar };   \
-/* Set accessed / busy bit for present segments. */ \
-if ( s.attr.fields.p )  \
-s.attr.fields.type |= (x86_seg_##s != x86_seg_tr ? 1 : 2);  \
-check_segment(, x86_seg_ ## s); })
-
-rc = SEG(cs, regs);
-rc |= SEG(ds, regs);
-rc |= SEG(ss, regs);
-rc |= SEG(es, regs);
-rc |= SEG(tr, regs);
-#undef SEG
-
-if ( rc != 0 )
-return rc;
-
-/* Basic sanity checks. */
-limit = cs.limit;
-if ( cs.attr.fields.g )
-limit = (limit << 12) | 0xfff;
-if ( regs->eip > limit )
-{
-gprintk(XENLOG_ERR, "EIP (%#08x) outside CS limit (%#08x)\n",
-regs->eip, limit);
-return -EINVAL;
-}
-
-if ( ss.attr.fields.dpl != cs.attr.fields.dpl )
-{
-gprintk(XENLOG_ERR, "SS.DPL (%u) is different than CS.DPL (%u)\n",
-ss.attr.fields.dpl, cs.attr.fields.dpl);
-return -EINVAL;
-}
-
-if ( ds.attr.fields.p && ds.attr.fields.dpl > cs.attr.fields.dpl )
-{
-gprintk(XENLOG_ERR, "DS.DPL (%u) is greater than CS.DPL (%u)\n",
-   

[Xen-devel] [PATCH for-next 7/8] x86/domain: move PV specific code to pv/domain.c

[Wei Liu]

Move all the PV specific code along with the supporting code to
pv/domain.c.

This in turn requires exporting a few functions in header files. Export
paravirt context switch functions in domain.h and create pv/pv.h for
the rest.

No functional change.

Signed-off-by: Wei Liu 
---
 xen/arch/x86/domain.c| 250 +--
 xen/arch/x86/pv/Makefile |   1 +
 xen/arch/x86/pv/domain.c | 270 +++
 xen/include/asm-x86/domain.h |   3 +
 xen/include/asm-x86/pv/pv.h  |  29 +
 5 files changed, 306 insertions(+), 247 deletions(-)
 create mode 100644 xen/arch/x86/pv/domain.c
 create mode 100644 xen/include/asm-x86/pv/pv.h

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index ed16adf77a..4a2363fc96 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -63,6 +63,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
 
@@ -70,9 +71,6 @@ static void default_idle(void);
 void (*pm_idle) (void) __read_mostly = default_idle;
 void (*dead_idle) (void) __read_mostly = default_dead_idle;
 
-static void paravirt_ctxt_switch_from(struct vcpu *v);
-static void paravirt_ctxt_switch_to(struct vcpu *v);
-
 static void default_idle(void)
 {
 local_irq_disable();
@@ -145,13 +143,6 @@ static void noreturn continue_idle_domain(struct vcpu *v)
 reset_stack_and_jump(idle_loop);
 }
 
-static void noreturn continue_nonidle_domain(struct vcpu *v)
-{
-check_wakeup_from_wait();
-mark_regs_dirty(guest_cpu_user_regs());
-reset_stack_and_jump(ret_from_intr);
-}
-
 void dump_pageframe_info(struct domain *d)
 {
 struct page_info *page;
@@ -313,129 +304,6 @@ void free_vcpu_struct(struct vcpu *v)
 free_xenheap_page(v);
 }
 
-static int setup_compat_l4(struct vcpu *v)
-{
-struct page_info *pg;
-l4_pgentry_t *l4tab;
-
-pg = alloc_domheap_page(v->domain, MEMF_no_owner);
-if ( pg == NULL )
-return -ENOMEM;
-
-/* This page needs to look like a pagetable so that it can be shadowed */
-pg->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
-
-l4tab = __map_domain_page(pg);
-clear_page(l4tab);
-init_guest_l4_table(l4tab, v->domain, 1);
-unmap_domain_page(l4tab);
-
-v->arch.guest_table = pagetable_from_page(pg);
-v->arch.guest_table_user = v->arch.guest_table;
-
-return 0;
-}
-
-static void release_compat_l4(struct vcpu *v)
-{
-free_domheap_page(pagetable_get_page(v->arch.guest_table));
-v->arch.guest_table = pagetable_null();
-v->arch.guest_table_user = pagetable_null();
-}
-
-int switch_compat(struct domain *d)
-{
-struct vcpu *v;
-int rc;
-
-if ( is_hvm_domain(d) || d->tot_pages != 0 )
-return -EACCES;
-if ( is_pv_32bit_domain(d) )
-return 0;
-
-d->arch.has_32bit_shinfo = 1;
-if ( is_pv_domain(d) )
-d->arch.is_32bit_pv = 1;
-
-for_each_vcpu( d, v )
-{
-rc = setup_compat_arg_xlat(v);
-if ( !rc )
-rc = setup_compat_l4(v);
-
-if ( rc )
-goto undo_and_fail;
-}
-
-domain_set_alloc_bitsize(d);
-recalculate_cpuid_policy(d);
-
-d->arch.x87_fip_width = 4;
-
-return 0;
-
- undo_and_fail:
-d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
-for_each_vcpu( d, v )
-{
-free_compat_arg_xlat(v);
-
-if ( !pagetable_is_null(v->arch.guest_table) )
-release_compat_l4(v);
-}
-
-return rc;
-}
-
-static int pv_vcpu_initialise(struct vcpu *v)
-{
-struct domain *d = v->domain;
-int rc = 0;
-
-spin_lock_init(>arch.pv_vcpu.shadow_ldt_lock);
-
-if ( !is_idle_domain(d) )
-{
-rc = create_perdomain_mapping(d, GDT_VIRT_START(v),
-  1 << GDT_LDT_VCPU_SHIFT,
-  d->arch.pv_domain.gdt_ldt_l1tab, NULL);
-if ( rc )
-goto done;
-
-BUILD_BUG_ON(NR_VECTORS * sizeof(*v->arch.pv_vcpu.trap_ctxt) >
- PAGE_SIZE);
-v->arch.pv_vcpu.trap_ctxt = xzalloc_array(struct trap_info,
-  NR_VECTORS);
-if ( !v->arch.pv_vcpu.trap_ctxt )
-{
-rc = -ENOMEM;
-goto done;
-}
-
-/* PV guests by default have a 100Hz ticker. */
-v->periodic_period = MILLISECS(10);
-}
-else
-v->arch.cr3 = __pa(idle_pg_table);
-
-v->arch.pv_vcpu.ctrlreg[4] = real_cr4_to_pv_guest_cr4(mmu_cr4_features);
-
-if ( is_pv_32bit_domain(d) )
-{
-if ( (rc = setup_compat_arg_xlat(v)) )
-goto done;
-
-if ( (rc = setup_compat_l4(v)) )
-{
-free_compat_arg_xlat(v);
-goto done;
-}
-}
-
- done:
-return rc;
-}
-
 int vcpu_initialise(struct vcpu *v)
 {
 struct domain *d = v->domain;
@@ -479,17 +347,6 @@ int vcpu_initialise(struct vcpu *v)
 return rc;
 

Re: [Xen-devel] [PATCH 1/2] xen, input: add xen-kbdfront module parameter for setting resolution

[Oleksandr Andrushchenko]

On 04/10/2017 04:50 PM, Juergen Gross wrote:

On 10/04/17 15:44, Oleksandr Andrushchenko wrote:

Hi, Juergen!

On 03/21/2017 07:19 PM, Juergen Gross wrote:

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

Signed-off-by: Juergen Gross 
---
   drivers/input/misc/xen-kbdfront.c | 10 --
   1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c
b/drivers/input/misc/xen-kbdfront.c
index 3900875..2df5678 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
   char phys[32];
   };
   +enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
+static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(size, int, NULL, 0444);

is this by intention that you use 0444 here?
It means read-only, thus one cannot change these,
so what is the point of the module parameters then?

You can see the settings in sysfs.

this is good so we can see actual width/height
used by the pv driver

The values are settable via boot parameter.

but then, if one has other values set in XenStore,
these will/may be overridden, making it inconsistent,
e.g. values loaded at start as module parameters
(*size* array) is not going to be updated on
XenbusStateInitWait/XenbusStateConnected. So, we'll
end up with wrong parameters shown via sysfs
one more question is why do we need module parameters
if the same can be read from XenStore?



Juergen

Thank you,
Oleksandr

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Juergen Gross]

On 10/04/17 15:47, Boris Ostrovsky wrote:
> On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
 On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
> On 04/07/2017 07:58 AM, Ian Jackson wrote:
>> tl;dr:
>>  Please apply
>>
>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
>> partially revert "xen: Remove event channel notification through
>>   Xen PCI platform device"
>>
>>  to all stable branches which have a version of the original broken
>>  commit.  This includes at least 4.9.y.
>>
>> Background:
>>
>> osstest service owner writes ("[linux-4.9 baseline test] 107238: 
>> tolerable FAIL"):
>> ...
>>>  test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
>> osstest doesn't consider this a regresion because it looks for
>> regressions within a branch, and this is the first test of Linux 4.9.
>> However, this is a regression from the kernel we are currently using.
>>
>> L1 dom0 console log:
>>   
>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>>
>> It seems to have got stuck halfway through booting.
>>
>> The message
>>   (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
>> input to DOM0)
>> shows where osstest timed out on this test, and started its log
>> capture process (including collecting debug key output).
>>
>> Complete logs for this job here:
>>   
>> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>>
>> Juergen Gross tells me that this is due to the lack of
>> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>>
>> Thanks,
>> Ian.
>>
>> PS: Stefano, Boris: did you already request a backport of this commit?
>> If not, why not ?
> No, but this should indeed be backported to 4.9+
 Boris, are you going to do that?
>>> Is there anything that needs to be done beyond just applying it to 4.9
>>> (4.10 apparently already has it).
>> No, I don't think so. 4.9 already has the offending commit.
> 
> 
> Looks like there will be a new version of the original patch
> (72a9b186292) so we should hold off with backport request to 4.9:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html

TBH: I'm not convinced by the reasoning why 72a9b186292 has to be
reworked: Do we really care for Xen versions < 4.0 and a theoretical
problem (after all the author admitted the bug isn't being hit in
reality due to a short-circuit in the code)?

And even if we do: I'd rather add another patch to stable later than
keeping a real bug in Linux 4.9 which has been hit at least 3 times
up to now (by Stefano, George and Ian).


Juergen


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
baseline version:
 ovmf c137d95081690d4877fbeb5f1856972e84ac32f2

Last test of basis   107308  2017-04-08 08:47:38 Z2 days
Testing same since   107329  2017-04-10 00:44:13 Z0 days1 attempts


People who touched revisions under test:
  Hao Wu 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
+ . ./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 ovmf 
1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
+ branch=ovmf
+ revision=1ea946d0f9ea7de963545fbe93cc7f781c03d0b2
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.8-testing
+ '[' x1ea946d0f9ea7de963545fbe93cc7f781c03d0b2 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : 

Re: [Xen-devel] [PATCH 1/2] xen, input: add xen-kbdfront module parameter for setting resolution

[Juergen Gross]

On 10/04/17 15:44, Oleksandr Andrushchenko wrote:
> Hi, Juergen!
> 
> On 03/21/2017 07:19 PM, Juergen Gross wrote:
>> Add a parameter for setting the resolution of xen-kbdfront in order to
>> be able to cope with a (virtual) frame buffer of arbitrary resolution.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>   drivers/input/misc/xen-kbdfront.c | 10 --
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/input/misc/xen-kbdfront.c
>> b/drivers/input/misc/xen-kbdfront.c
>> index 3900875..2df5678 100644
>> --- a/drivers/input/misc/xen-kbdfront.c
>> +++ b/drivers/input/misc/xen-kbdfront.c
>> @@ -41,6 +41,12 @@ struct xenkbd_info {
>>   char phys[32];
>>   };
>>   +enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };
>> +static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
>> +module_param_array(size, int, NULL, 0444);
> is this by intention that you use 0444 here?
> It means read-only, thus one cannot change these,
> so what is the point of the module parameters then?

You can see the settings in sysfs.

The values are settable via boot parameter.


Juergen

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

Re: [Xen-devel] Please apply "partially revert "xen: Remove event channel..."

[Boris Ostrovsky]

On 04/07/2017 06:11 PM, Stefano Stabellini wrote:
> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
>> On 04/07/2017 01:36 PM, Stefano Stabellini wrote:
>>> On Fri, 7 Apr 2017, Boris Ostrovsky wrote:
 On 04/07/2017 07:58 AM, Ian Jackson wrote:
> tl;dr:
>  Please apply
>
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1
> partially revert "xen: Remove event channel notification through
>   Xen PCI platform device"
>
>  to all stable branches which have a version of the original broken
>  commit.  This includes at least 4.9.y.
>
> Background:
>
> osstest service owner writes ("[linux-4.9 baseline test] 107238: 
> tolerable FAIL"):
> ...
>>  test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1  fail never pass
> osstest doesn't consider this a regresion because it looks for
> regressions within a branch, and this is the first test of Linux 4.9.
> However, this is a regression from the kernel we are currently using.
>
> L1 dom0 console log:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/huxelrebe0---var-log-xen-osstest-serial-l1.guest.osstest.log
>
> It seems to have got stuck halfway through booting.
>
> The message
>   (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch 
> input to DOM0)
> shows where osstest timed out on this test, and started its log
> capture process (including collecting debug key output).
>
> Complete logs for this job here:
>   
> http://logs.test-lab.xenproject.org/osstest/logs/107238/test-amd64-amd64-qemuu-nested-intel/info.html
>
> Juergen Gross tells me that this is due to the lack of
> da72ff5bfcb02c6ac8b169a7cf597a3c8e6c4de1.
>
> Thanks,
> Ian.
>
> PS: Stefano, Boris: did you already request a backport of this commit?
> If not, why not ?
 No, but this should indeed be backported to 4.9+
>>> Boris, are you going to do that?
>> Is there anything that needs to be done beyond just applying it to 4.9
>> (4.10 apparently already has it).
> No, I don't think so. 4.9 already has the offending commit.


Looks like there will be a new version of the original patch
(72a9b186292) so we should hold off with backport request to 4.9:

https://lists.xenproject.org/archives/html/xen-devel/2017-04/msg01468.html

-boris

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

Re: [Xen-devel] [PATCH 1/2] xen, input: add xen-kbdfront module parameter for setting resolution

[Oleksandr Andrushchenko]

Hi, Juergen!

On 03/21/2017 07:19 PM, Juergen Gross wrote:

Add a parameter for setting the resolution of xen-kbdfront in order to
be able to cope with a (virtual) frame buffer of arbitrary resolution.

Signed-off-by: Juergen Gross 
---
  drivers/input/misc/xen-kbdfront.c | 10 --
  1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/misc/xen-kbdfront.c 
b/drivers/input/misc/xen-kbdfront.c
index 3900875..2df5678 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -41,6 +41,12 @@ struct xenkbd_info {
char phys[32];
  };
  
+enum { KPARAM_WIDTH, KPARAM_HEIGHT, KPARAM_CNT };

+static int size[KPARAM_CNT] = { XENFB_WIDTH, XENFB_HEIGHT };
+module_param_array(size, int, NULL, 0444);

is this by intention that you use 0444 here?
It means read-only, thus one cannot change these,
so what is the point of the module parameters then?

+MODULE_PARM_DESC(size,
+   "Pointing device width, height in pixels (default 800,600)");
+
  static int xenkbd_remove(struct xenbus_device *);
  static int xenkbd_connect_backend(struct xenbus_device *, struct xenkbd_info 
*);
  static void xenkbd_disconnect_backend(struct xenkbd_info *);
@@ -174,8 +180,8 @@ static int xenkbd_probe(struct xenbus_device *dev,
  
  	if (abs) {

__set_bit(EV_ABS, ptr->evbit);
-   input_set_abs_params(ptr, ABS_X, 0, XENFB_WIDTH, 0, 0);
-   input_set_abs_params(ptr, ABS_Y, 0, XENFB_HEIGHT, 0, 0);
+   input_set_abs_params(ptr, ABS_X, 0, size[KPARAM_WIDTH], 0, 0);
+   input_set_abs_params(ptr, ABS_Y, 0, size[KPARAM_HEIGHT], 0, 0);
} else {
input_set_capability(ptr, EV_REL, REL_X);
input_set_capability(ptr, EV_REL, REL_Y);

Thank you,
Oleksandr

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

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Konrad Rzeszutek Wilk]

On Mon, Apr 10, 2017 at 01:46:20PM +0100, Andrew Cooper wrote:
> On 10/04/17 12:24, lidonglin wrote:
> >
> > Hi all:
> >
> > I have one question about PCI passthrough. I found
> > that if I created a VM with host pci device(cfg file as below), there
> > were some xenstore keys exsiting in /local/domain/0 and
> > /local/domain/DomID/. Besides I found one unknown device in device
> > manager of Windows OS with Class ID FF80 from vendor ID 5853. My
> > questions  are as below:
> >
> >  
> >
> > 1.   Why do we create frontend and backend key pairs in xenstore?
> >  I think  Passthrough is not PV,  was it possible that we just used
> > these keys to record something?
> >
> > 2.After review the code, I think backend keys are used to
> > record state of hostdev, some codes will query something using these
> > keys. But for frontend keys, can we delete them?
> >
> > 3.   if frontend keys exist in xenstore, then unknown device will
> > appear in device manager. Can we fix this?  For  an obsessive,  he
> > can’t stand for this.
> >
> 
> This is a libxl bug which has been reported before, but nothing happened.
> 
> libxl must not start a PV pci-back when doing HVM PCI passthrough using
> qemu, because absolutely nothing good can come of having two different
> ways of poking at PCI state.

.. Except that we need some way of doing FLR and Pciback
is the one doing it.

The right way would be to expand pciback to support the do_flr ioctl
and combine it with your patch.

> 
> The patch, unchanged from before, is
> https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch

Attaching the flr one (inline) and attachemnt


>From 314a0ff66af9380de4cd4c8a7f4f648c6f593bb8 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk 
Date: Wed, 3 Dec 2014 15:47:02 -0500
Subject: [PATCH] xen/pciback: Implement PCI reset slot or bus with 'do_flr'
 SysFS attribute

The life-cycle of a PCI device in Xen pciback is complex
and is constrained by the PCI generic locking mechanism.

It starts with the device being binded to us - for which
we do a device function reset (and done via SysFS
so the PCI lock is held)

If the device is unbinded from us - we also do a function
reset (also done via SysFS so the PCI lock is held).

If the device is un-assigned from a guest - we do a function
reset (no PCI lock).

All on the individual PCI function level (so bus:device:function).

Unfortunatly a function reset is not adequate for certain
PCIe devices. The reset for an individual PCI function "means
device must support FLR (PCIe or AF), PM reset on D3hot->D0
device specific reset, or be a singleton device on a bus
a secondary bus reset.  FLR does not have widespread support,
reset is not very reliable, and bus topology is dictated by the
and device design.  We need to provide a means for a user to
a bus reset in cases where the existing mechanisms are not
 or not reliable. " (Adam Williamson, 'vfio-pci: PCI hot reset
interface' commit 8b27ee60bfd6bbb84d2df28fa706c5c5081066ca).

As such to do a slot or a bus reset is we need another mechanism.
This is not exposed SysFS as there is no good way of exposing
a bus topology there.

This is due to the complexity - we MUST know that the different
functions off a PCIe device are not in use by other drivers, or
if they are in use (say one of them is assigned to a guest
and the other is idle) - it is still OK to reset the slot
(assuming both of them are owned by Xen pciback).

This patch does that by doing an slot or bus reset (if
slot not supported) if all of the functions of a PCIe
device belong to Xen PCIback. We do not care if the device is
in-use as we depend on the toolstack to be aware of this -
however if it is we will WARN the user.

Due to the complexity with the PCI lock we cannot do
the reset when a device is binded ('echo $BDF > bind')
or when unbinded ('echo $BDF > unbind') as the pci_[slot|bus]_reset
also take the same lock resulting in a dead-lock.

Putting the reset function in a workqueue or thread
won't work either - as we have to do the reset function
outside the 'unbind' context (it holds the PCI lock).
But once you 'unbind' a device the device is no longer
under the ownership of Xen pciback and the pci_set_drvdata
has been reset so we cannot use a thread for this.

Instead of doing all this complex dance, we depend on the toolstack
doing the right thing. As such implement the 'do_flr' SysFS attribute
which 'xl' uses when a device is detached or attached from/to a guest.
It bypasses the need to worry about the PCI lock.

To not inadvertly do a bus reset that would affect devices that
are in use by other drivers (other than Xen pciback) prior
to the reset we check that all of the devices under the bridge
are owned by Xen pciback. If they are not we do not do
the bus (or slot) reset.

We also warn the user if the device is in use - but still
continue with the reset. This should 

Re: [Xen-devel] [PATCH 0/5] Towards a restartable oxenstored

[Julien Grall]

Hi Wei,

On 10/04/17 10:47, Wei Liu wrote:

Cc Julien

These are small bug fixes that can be safely committed, IMHO.


Release-acked-by: Julien Grall 

Cheers,



On Fri, Apr 07, 2017 at 02:27:17PM +0100, Jonathan Davies wrote:

In order to make oxenstored restartable, we need to save internal state
to a file on exit and restore from this file on startup.

Much of the infrastructure for making oxenstored restartable already
existed, but a handful of bugs prevented it from working.

After these patches I can do the following:

# xenstore-write foo bar
# xenstore-read foo
bar
# xenstore-ls -f -p | sort > contents.before
# killall oxenstored
# ./oxenstored --restart
# xenstore-ls -f -p | sort > contents.after
# diff contents.before contents.after
# xenstore-read foo
bar

... and I can do similar kinds of activity in a guest across the
restart.

Note that clients of local socket connections will get EPIPE or similar
when oxenstored terminates. Hence these clients need to handle this
gracefully, e.g. by attempting to reconnect, if they wish to tolerate
xenstored restarts.

With these patches, the state saved on exit contains information about
inter-domain connections and active watches, and the contents of the
store. Some internal state is not currently preserved over a restart:
  1. quota usage info
  2. partially-read and already-queued packets from rings
  3. recent transaction history

Items 1 and 2 are probably needed for this to be considered fully
functional, so fixes for them should follow. But the bugfixes in this
series already represent a worthwhile improvement.

Jonathan Davies (5):
  oxenstored: initialise logging earlier
  oxenstored: avoid leading slash in paths in saved store state
  oxenstored: save remote evtchn port, not local port
  oxenstored: improve event-channel binding logging
  oxenstored: make --restart option best-effort

 tools/ocaml/xenstored/domain.ml|  4 ++--
 tools/ocaml/xenstored/store.ml |  8 +++-
 tools/ocaml/xenstored/xenstored.ml | 10 ++
 3 files changed, 15 insertions(+), 7 deletions(-)

--
2.7.4



--
Julien Grall

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

Re: [Xen-devel] [PATCH] tools/golang: Add myself as maintainer

[Konrad Rzeszutek Wilk]

On Mon, Apr 10, 2017 at 12:21:01PM +0100, George Dunlap wrote:
> On 10/04/17 11:37, George Dunlap wrote:
> > On 06/04/17 20:52, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Apr 06, 2017 at 03:57:06PM +0100, George Dunlap wrote:
> >>> Signed-off-by: George Dunlap 
> >>> ---
> >>> Andrew Cooper 
> >>> Ian Jackson 
> >>> Jan Beulich 
> >>> Konrad Rzeszutek Wilk 
> >>> Stefano Stabellini 
> >>> Tim Deegan 
> >>> Wei Liu 
> >>> ---
> >>>  MAINTAINERS | 7 +++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/MAINTAINERS b/MAINTAINERS
> >>> index c38bcd4..050cb35 100644
> >>> --- a/MAINTAINERS
> >>> +++ b/MAINTAINERS
> >>> @@ -206,6 +206,13 @@ S:   Supported
> >>>  F:   xen/arch/x86/debug.c
> >>>  F:   tools/debugger/gdbsx/
> >>>  
> >>> +GOLANG BINDINGS
> >>> +M:  George Dunlap 
> >>> +M:   Ian Jackson 
> >>> +M:   Wei Liu 
> >>
> >> Something is off with the spaces/tabs?
> > 
> > So it would seem... my emacs seems to never want to add tabs when I
> > type, but will leave them there when I copy-and-paste.
> > 
> > Attached is a patch with all tabs.
> 
> Sorry, try this one instead...


> 
>  -George

> >From b12d39d102dd06c3639b647b2d9064045fd6e977 Mon Sep 17 00:00:00 2001
> From: George Dunlap 
> Date: Thu, 6 Apr 2017 15:52:10 +0100
> Subject: [PATCH] tools/golang: Add myself as maintainer
> 
> Signed-off-by: George Dunlap 
> ---
> Changes since v1: Fix tabs
> 
> CC: Andrew Cooper 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 

Acked-by: Konrad Rzeszutek Wilk 

> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> ---
>  MAINTAINERS | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c38bcd4..b43a501 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -206,6 +206,13 @@ S:   Supported
>  F:   xen/arch/x86/debug.c
>  F:   tools/debugger/gdbsx/
>  
> +GOLANG BINDINGS
> +M:   George Dunlap 
> +M:   Ian Jackson 
> +M:   Wei Liu 
> +S:   Supported
> +F:   tools/golang
> +
>  INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>  M:   Gang Wei 
>  M:   Shane Wang 
> -- 
> 2.1.4
> 


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

Re: [Xen-devel] [PATCH for-4.9] x86/emul: Drop more redundant ctxt.event_pending checks

[Jan Beulich]

>>> On 10.04.17 at 14:14,  wrote:
> Since c/s 92cf67888a, x86_emulate_wrapper() asserts stricter behaviour about
> the relationship between X86EMUL_EXCEPTION and ctxt.event_pending.
> 
> These removals should have been included in the aforementioned changeset, and
> were only omitted due an oversight.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 

Interesting that I saw your and Paul's discussion half an hour before
the patch arrived ...

Jan


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

[Xen-devel] [PATCH for-4.9] x86/emul: Drop more redundant ctxt.event_pending checks

[Andrew Cooper]

Since c/s 92cf67888a, x86_emulate_wrapper() asserts stricter behaviour about
the relationship between X86EMUL_EXCEPTION and ctxt.event_pending.

These removals should have been included in the aforementioned changeset, and
were only omitted due an oversight.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Tim Deegan 
CC: Paul Durrant 
CC: Jun Nakajima 
CC: Kevin Tian 
CC: Julien Grall 
---
 xen/arch/x86/hvm/emulate.c  |  6 ++
 xen/arch/x86/hvm/hvm.c  |  3 +--
 xen/arch/x86/hvm/io.c   |  3 +--
 xen/arch/x86/hvm/vmx/realmode.c | 15 ---
 xen/arch/x86/mm/shadow/multi.c  |  2 +-
 xen/arch/x86/traps.c|  9 -
 6 files changed, 5 insertions(+), 33 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 06b8f1b..91e269f 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2035,8 +2035,7 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 hvm_dump_emulation_state(XENLOG_G_WARNING "MMCFG", );
 break;
 case X86EMUL_EXCEPTION:
-if ( ctxt.ctxt.event_pending )
-hvm_inject_event();
+hvm_inject_event();
 /* fallthrough */
 default:
 hvm_emulate_writeback();
@@ -2095,8 +2094,7 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
 hvm_inject_hw_exception(trapnr, errcode);
 break;
 case X86EMUL_EXCEPTION:
-if ( ctx.ctxt.event_pending )
-hvm_inject_event();
+hvm_inject_event();
 break;
 }
 
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f50d15f..9ffe702 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3696,8 +3696,7 @@ void hvm_ud_intercept(struct cpu_user_regs *regs)
 hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
 break;
 case X86EMUL_EXCEPTION:
-if ( ctxt.ctxt.event_pending )
-hvm_inject_event();
+hvm_inject_event();
 /* fall through */
 default:
 hvm_emulate_writeback();
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 9e00409..67528d9 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -100,8 +100,7 @@ bool hvm_emulate_one_insn(hvm_emulate_validate_t *validate)
 return false;
 
 case X86EMUL_EXCEPTION:
-if ( ctxt.ctxt.event_pending )
-hvm_inject_event();
+hvm_inject_event();
 break;
 }
 
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index 7b908c7..4eb4232 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -114,21 +114,6 @@ void vmx_realmode_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt)
 
 if ( rc == X86EMUL_EXCEPTION )
 {
-if ( !hvmemul_ctxt->ctxt.event_pending )
-{
-unsigned long intr_info;
-
-__vmread(VM_ENTRY_INTR_INFO, _info);
-__vmwrite(VM_ENTRY_INTR_INFO, 0);
-if ( !(intr_info & INTR_INFO_VALID_MASK) )
-{
-gdprintk(XENLOG_ERR, "Exception pending but no info.\n");
-goto fail;
-}
-hvmemul_ctxt->ctxt.event.vector = (uint8_t)intr_info;
-hvmemul_ctxt->ctxt.event.insn_len = 0;
-}
-
 if ( unlikely(curr->domain->debugger_attached) &&
  ((hvmemul_ctxt->ctxt.event.vector == TRAP_debug) ||
   (hvmemul_ctxt->ctxt.event.vector == TRAP_int3)) )
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index 5195d61..2fb0125 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3457,7 +3457,7 @@ static int sh_page_fault(struct vcpu *v,
 
 r = x86_emulate(_ctxt.ctxt, emul_ops);
 
-if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
+if ( r == X86EMUL_EXCEPTION )
 {
 /*
  * This emulation covers writes to shadow pagetables.  We tolerate #PF
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index d69769f..ca0a04a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -3185,15 +3185,9 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 if ( IS_ERR_OR_NULL(state) )
 {
 if ( PTR_ERR(state) == -X86EMUL_EXCEPTION )
-{
-ASSERT(ctxt.ctxt.event_pending);
 pv_inject_event();
-}
 else
-{
-ASSERT(!ctxt.ctxt.event_pending);
 do_guest_trap(TRAP_gp_fault, regs);
-}
 return;
 }
 
@@ -3234,13 +3228,10 @@ static void emulate_gate_op(struct cpu_user_regs *regs)
 
 if ( rc == X86EMUL_EXCEPTION )
 {
-ASSERT(ctxt.ctxt.event_pending);
 pv_inject_event();
 return;
 }
 
-

Re: [Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[Andrew Cooper]

On 10/04/17 12:24, lidonglin wrote:
>
> Hi all:
>
> I have one question about PCI passthrough. I found
> that if I created a VM with host pci device(cfg file as below), there
> were some xenstore keys exsiting in /local/domain/0 and
> /local/domain/DomID/. Besides I found one unknown device in device
> manager of Windows OS with Class ID FF80 from vendor ID 5853. My
> questions  are as below:
>
>  
>
> 1.   Why do we create frontend and backend key pairs in xenstore?
>  I think  Passthrough is not PV,  was it possible that we just used
> these keys to record something?
>
> 2.After review the code, I think backend keys are used to
> record state of hostdev, some codes will query something using these
> keys. But for frontend keys, can we delete them?
>
> 3.   if frontend keys exist in xenstore, then unknown device will
> appear in device manager. Can we fix this?  For  an obsessive,  he
> can’t stand for this.
>

This is a libxl bug which has been reported before, but nothing happened.

libxl must not start a PV pci-back when doing HVM PCI passthrough using
qemu, because absolutely nothing good can come of having two different
ways of poking at PCI state.

The patch, unchanged from before, is
https://github.com/xenserver/xen-4.7.pg/blob/master/master/0001-libxl-Don-t-insert-PCI-device-into-xenstore-for-HVM-.patch

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

Re: [Xen-devel] [PATCH v10 05/25] x86: refactor psr: L3 CAT: implement CPU init and free flow.

[Yi Sun]

On 17-04-10 11:27:04, Yi Sun wrote:
> On 17-04-07 03:46:42, Jan Beulich wrote:
> > >>> On 07.04.17 at 11:08,  wrote:
> > > On 17-04-07 02:48:40, Jan Beulich wrote:
> > >> >>> On 07.04.17 at 07:17,  wrote:
> > >> > On 17-04-06 08:02:15, Jan Beulich wrote:
> > >> >> Okay, so not the context switch path then, But you must be
> > >> >> changing the MSRs _somewhere_, and the question is why this
> > >> >> somewhere isn't sufficient.
> > >> >> 
> > >> > Besides the restore behavior in init process, I restore the MSRs when 
> > >> > ref[cos]
> > >> > is reduced to 0. This behavior happens in two scenarios:
> > >> > 1. In a value setting process, restore MSR if the ref[old_cos] is 
> > >> > reduced to 0.
> > >> > 2. When a domain is destroyed, its ref[cos] is reduced too.
> > >> > 
> > >> > Reason to restore is below:
> > >> >   For features,  e.g. CDP, which cos_num is more than 1, we have to
> > >> >   restore the old_cos value back to default when ref[old_cos] is 0.
> > >> >   Otherwise, user will see wrong values when this COS ID is reused. 
> > >> > E.g.
> > >> >   user wants to set DATA to 0x3ff for a new domain. He hopes to see the
> > >> >   DATA is set to 0x3ff and CODE should be the default value, 0x7ff. But
> > >> >   if the COS ID picked for this action is the one that has been used by
> > >> >   other domain and the CODE has been set to 0x1ff. Then, user will see
> > >> >   DATA: 0x3ff, CODE: 0x1ff. So, we have to restore COS values for 
> > >> > features
> > >> >   using multiple COSs.
> > >> 
> > >> I still don't feel my question being answered. Without a COS
> > >> ever allocated on a socket, how can values in MSRs other than
> > >> the first (index 0) one be used by anyone? I ask because if they
> > >> can't be used, their values don't matter (all you need to make
> > >> sure is to write them regardless of their currently cached value).
> > > 
> > > The COS ID using is managed by domain (d->arch.psr_cos_ids[socket]). Even 
> > > if a
> > > socket is offline, the COS ID saved in domain is still valid (domain is 
> > > alive).
> > > When this socket is online again, the domain may be scheduled onto it to 
> > > run.
> > > Then, the COS ID (e.g 2) will be used to get/set value for this domain. 
> > > If we
> > > don't restore MSRs on the socket, we may get an unknown value. This the 
> > > reason
> > > we have to restore MSRs in 'cat_init_feature' which is called when socket 
> > > is
> > > online.
> > 
> > No, it's not. At least that's not the only way to solve the problem:
> > As said, you could equally well make sure you always write the MSR
> > the first time a vCPU using a particular COS is being scheduled onto
> > the newly onlined pCPU. In fact most of the time it is better if
> > generic code can also deal with special cases than to introduce
> > special purpose code. Hence my insisting on you properly explaining
> > why generic code can't deal with the post-online situation here.
> > 
> Then, I propose another simple solution to handle this case. When writing
> MSRs, check if all values in val_array are same as old values (kept in
> 'cos_reg_val[]'). If a value is different, the MSR will be written and the
> corresponding member in 'cos_reg_val[]' will be updated. Still use above
> sample, user wants to set DATA to 0x3ff for a new domain. After value array
> assembling, the val_array will be val[DATA]=0x3ff, val[CODE]=0x7ff. The
> cos_reg_val[DATA]=0x7ff and cos_reg_val[DATA]=0x1ff. So, both of them will
> be updated.
> 
I want to explain more to make it clearer. The original codes are to solve the
issues when a COS ID is free and reused by other domain. With the newly
proposed method above, we can solve this issue too. E.g:
1. COS ID 1 is used by domain 1. Its CODE=0x1ff, DATA=0x7ff. They are kept in
   cos_reg_val[1 - CODE] and cos_reg_val[1 - DATA].
2. For some reason, COS ID 1 is free.
3. We want to set DATA of a new domain (8) to 0x3ff. Its old_cos is 0 so that
   val_array assembled is CODE=0x7ff, DATA=0x3ff. Then COS ID 1 is picked.
4. In write flow, iterate the feature's type array according to cos_num to
   set both CODE and DATA if val_array member is different with cos_reg_val
   member.

Below are codes to explain it clearly:

static void l3_cdp_write_msr(unsigned int cos, uint32_t val, ...)
{
/* Data. For above case, get_cdp_data(..., cos) returns 0x7ff */
if ( type == PSR_CBM_TYPE_L3_DATA && get_cdp_data(feat, cos) != val )
{
get_cdp_data(feat, cos) = val;
wrmsrl(MSR_IA32_PSR_L3_MASK_DATA(cos), val);
}
/* Code. For above case, get_cdp_code(..., cos) returns 0x1ff */
if ( type == PSR_CBM_TYPE_L3_CODE && get_cdp_code(feat, cos) != val )
{
get_cdp_code(feat, cos) = val;
wrmsrl(MSR_IA32_PSR_L3_MASK_CODE(cos), val);
}
}

struct cos_write_info
{
unsigned int cos;
struct feat_node *feature;
/* All COS MSRs values of the feature. */
uint32_t *val;

Re: [Xen-devel] [PATCH] xen: Remove event channel notification through Xen PCI platform device

[Raslan, KarimAllah]

Unfortunately, this commit is potentially a candidate for reverting. After a
lengthy qualification I realized that there is a function called:
"xen_strict_xenbus_quirk()" that is being called in the offending path that
short-circuits the offending code!

So at the moment any domU kernel with this commit will not boot on any Xen
version < 4.0!  So nobody with Xen < 4.0 was complaining not because nobody is
using it but rather because there is a short-circuit in the code that avoids
hitting the offending code in the first place! So the original assumption that
the code is dead might no be 100% correct!

So even though the code for INTx is broken for any Xen > 4.0, the right thing
to do now is to actually fix the INTx properly and completely revert this
commit (actually now also commit da72ff5bfcb0 needs to be reverted to cleanly
revert this commit) to avoid any potential regression.

David,
Does this make sense to you?

I will send a patch to fix INTx shortly as well.

On 9/30/16, 4:46 PM, "David Vrabel"  wrote:

On 26/08/16 22:55, KarimAllah Ahmed wrote:
> Ever since commit 254d1a3f02eb ("xen/pv-on-hvm kexec: shutdown watches
> from old kernel") using the INTx interrupt from Xen PCI platform device 
for
> event channel notification would just lockup the guest during bootup.
> postcore_initcall now calls xs_reset_watches which will eventually try to 
read
> a value from XenStore and will get stuck on read_reply at XenBus forever 
since
> the platform driver is not probed yet and its INTx interrupt handler is 
not
> registered yet. That means that the guest can not be notified at this 
moment of
> any pending event channels and none of the per-event handlers will ever be
> invoked (including the XenStore one) and the reply will never be picked 
up by
> the kernel.

Applied to for-linus-4.9, thanks.

David




Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.9] x86/emul: Drop more redundant ctxt.event_pending checks

[Andrew Cooper]

On 10/04/17 13:24, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 10 April 2017 13:15
>> To: Xen-devel 
>> Cc: Andrew Cooper ; Jan Beulich
>> ; Tim (Xen.org) ; Paul Durrant
>> ; Jun Nakajima ; Kevin
>> Tian ; Julien Grall 
>> Subject: [PATCH for-4.9] x86/emul: Drop more redundant
>> ctxt.event_pending checks
>>
>> Since c/s 92cf67888a, x86_emulate_wrapper() asserts stricter behaviour
>> about
>> the relationship between X86EMUL_EXCEPTION and ctxt.event_pending.
>>
>> These removals should have been included in the aforementioned
>> changeset, and
>> were only omitted due an oversight.
>>
> As long as suitable assertions are in place...
>
> Reviewed-by: Paul Durrant 

The assertion in question is

ASSERT(ctxt->event_pending == (rc == X86EMUL_EXCEPTION));

in x86_emulate_wrapper() which transparently replaces x86_emulate() in
debug builds.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.9] x86/emul: Drop more redundant ctxt.event_pending checks

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 10 April 2017 13:15
> To: Xen-devel 
> Cc: Andrew Cooper ; Jan Beulich
> ; Tim (Xen.org) ; Paul Durrant
> ; Jun Nakajima ; Kevin
> Tian ; Julien Grall 
> Subject: [PATCH for-4.9] x86/emul: Drop more redundant
> ctxt.event_pending checks
> 
> Since c/s 92cf67888a, x86_emulate_wrapper() asserts stricter behaviour
> about
> the relationship between X86EMUL_EXCEPTION and ctxt.event_pending.
> 
> These removals should have been included in the aforementioned
> changeset, and
> were only omitted due an oversight.
> 

As long as suitable assertions are in place...

Reviewed-by: Paul Durrant 

> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: Tim Deegan 
> CC: Paul Durrant 
> CC: Jun Nakajima 
> CC: Kevin Tian 
> CC: Julien Grall 
> ---
>  xen/arch/x86/hvm/emulate.c  |  6 ++
>  xen/arch/x86/hvm/hvm.c  |  3 +--
>  xen/arch/x86/hvm/io.c   |  3 +--
>  xen/arch/x86/hvm/vmx/realmode.c | 15 ---
>  xen/arch/x86/mm/shadow/multi.c  |  2 +-
>  xen/arch/x86/traps.c|  9 -
>  6 files changed, 5 insertions(+), 33 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 06b8f1b..91e269f 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -2035,8 +2035,7 @@ int hvm_emulate_one_mmio(unsigned long mfn,
> unsigned long gla)
>  hvm_dump_emulation_state(XENLOG_G_WARNING "MMCFG", );
>  break;
>  case X86EMUL_EXCEPTION:
> -if ( ctxt.ctxt.event_pending )
> -hvm_inject_event();
> +hvm_inject_event();
>  /* fallthrough */
>  default:
>  hvm_emulate_writeback();
> @@ -2095,8 +2094,7 @@ void hvm_emulate_one_vm_event(enum
> emul_kind kind, unsigned int trapnr,
>  hvm_inject_hw_exception(trapnr, errcode);
>  break;
>  case X86EMUL_EXCEPTION:
> -if ( ctx.ctxt.event_pending )
> -hvm_inject_event();
> +hvm_inject_event();
>  break;
>  }
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index f50d15f..9ffe702 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3696,8 +3696,7 @@ void hvm_ud_intercept(struct cpu_user_regs
> *regs)
>  hvm_inject_hw_exception(TRAP_invalid_op, X86_EVENT_NO_EC);
>  break;
>  case X86EMUL_EXCEPTION:
> -if ( ctxt.ctxt.event_pending )
> -hvm_inject_event();
> +hvm_inject_event();
>  /* fall through */
>  default:
>  hvm_emulate_writeback();
> diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> index 9e00409..67528d9 100644
> --- a/xen/arch/x86/hvm/io.c
> +++ b/xen/arch/x86/hvm/io.c
> @@ -100,8 +100,7 @@ bool
> hvm_emulate_one_insn(hvm_emulate_validate_t *validate)
>  return false;
> 
>  case X86EMUL_EXCEPTION:
> -if ( ctxt.ctxt.event_pending )
> -hvm_inject_event();
> +hvm_inject_event();
>  break;
>  }
> 
> diff --git a/xen/arch/x86/hvm/vmx/realmode.c
> b/xen/arch/x86/hvm/vmx/realmode.c
> index 7b908c7..4eb4232 100644
> --- a/xen/arch/x86/hvm/vmx/realmode.c
> +++ b/xen/arch/x86/hvm/vmx/realmode.c
> @@ -114,21 +114,6 @@ void vmx_realmode_emulate_one(struct
> hvm_emulate_ctxt *hvmemul_ctxt)
> 
>  if ( rc == X86EMUL_EXCEPTION )
>  {
> -if ( !hvmemul_ctxt->ctxt.event_pending )
> -{
> -unsigned long intr_info;
> -
> -__vmread(VM_ENTRY_INTR_INFO, _info);
> -__vmwrite(VM_ENTRY_INTR_INFO, 0);
> -if ( !(intr_info & INTR_INFO_VALID_MASK) )
> -{
> -gdprintk(XENLOG_ERR, "Exception pending but no info.\n");
> -goto fail;
> -}
> -hvmemul_ctxt->ctxt.event.vector = (uint8_t)intr_info;
> -hvmemul_ctxt->ctxt.event.insn_len = 0;
> -}
> -
>  if ( unlikely(curr->domain->debugger_attached) &&
>   ((hvmemul_ctxt->ctxt.event.vector == TRAP_debug) ||
>(hvmemul_ctxt->ctxt.event.vector == TRAP_int3)) )
> diff --git a/xen/arch/x86/mm/shadow/multi.c
> b/xen/arch/x86/mm/shadow/multi.c
> index 5195d61..2fb0125 100644
> --- a/xen/arch/x86/mm/shadow/multi.c
> +++ b/xen/arch/x86/mm/shadow/multi.c
> @@ -3457,7 +3457,7 @@ static int sh_page_fault(struct vcpu *v,
> 
>  r = x86_emulate(_ctxt.ctxt, emul_ops);
> 
> -if ( r == X86EMUL_EXCEPTION && emul_ctxt.ctxt.event_pending )
> +if ( r == X86EMUL_EXCEPTION )
>  {
>  /*
>   * This emulation covers writes to shadow 

Re: [Xen-devel] [PATCH] tools/golang: Add myself as maintainer

[George Dunlap]

On 10/04/17 11:37, George Dunlap wrote:
> On 06/04/17 20:52, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 06, 2017 at 03:57:06PM +0100, George Dunlap wrote:
>>> Signed-off-by: George Dunlap 
>>> ---
>>> Andrew Cooper 
>>> Ian Jackson 
>>> Jan Beulich 
>>> Konrad Rzeszutek Wilk 
>>> Stefano Stabellini 
>>> Tim Deegan 
>>> Wei Liu 
>>> ---
>>>  MAINTAINERS | 7 +++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index c38bcd4..050cb35 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -206,6 +206,13 @@ S: Supported
>>>  F: xen/arch/x86/debug.c
>>>  F: tools/debugger/gdbsx/
>>>  
>>> +GOLANG BINDINGS
>>> +M:  George Dunlap 
>>> +M: Ian Jackson 
>>> +M: Wei Liu 
>>
>> Something is off with the spaces/tabs?
> 
> So it would seem... my emacs seems to never want to add tabs when I
> type, but will leave them there when I copy-and-paste.
> 
> Attached is a patch with all tabs.

Sorry, try this one instead...

 -George
>From b12d39d102dd06c3639b647b2d9064045fd6e977 Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Thu, 6 Apr 2017 15:52:10 +0100
Subject: [PATCH] tools/golang: Add myself as maintainer

Signed-off-by: George Dunlap 
---
Changes since v1: Fix tabs

CC: Andrew Cooper 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c38bcd4..b43a501 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -206,6 +206,13 @@ S:	Supported
 F:	xen/arch/x86/debug.c
 F:	tools/debugger/gdbsx/
 
+GOLANG BINDINGS
+M:	George Dunlap 
+M:	Ian Jackson 
+M:	Wei Liu 
+S:	Supported
+F:	tools/golang
+
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Gang Wei 
 M:	Shane Wang 
-- 
2.1.4

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

[Xen-devel] PCI passthrough will cause unknown device appearance in device manager of Windows OS via xenstore keys

[lidonglin]

Hi all:
I have one question about PCI passthrough. I found that if I 
created a VM with host pci device(cfg file as below), there were some xenstore 
keys exsiting in /local/domain/0 and /local/domain/DomID/. Besides I found one 
unknown device in device manager of Windows OS with Class ID FF80 from vendor 
ID 5853. My questions  are as below:


1.   Why do we create frontend and backend key pairs in xenstore?  I think  
Passthrough is not PV,  was it possible that we just used these keys to record 
something?

2.After review the code, I think backend keys are used to record state 
of hostdev, some codes will query something using these keys. But for frontend 
keys, can we delete them?

3.   if frontend keys exist in xenstore, then unknown device will appear in 
device manager. Can we fix this?  For  an obsessive,  he can't stand for this.

Cfg file as below:
builder = "hvm"
name = "win2008_server_r2_sp1_64"
viridian = 1
memory = 8192
maxmem = 8192
vcpus = 4
disk = [ '/mnt /win2008_server_ent_r2_sp1_64_gputhrough_vhd,vhd,xvda,rw' ]
vnc = 1
vnclisten = 'xxx.xxx.xxx.xxx'
vncdisplay = 0
usb = 1
usbdevice = ['tablet']
pci = [":06:00.0"]

I use xen-4.8.0 version.

Xenstore keys
For domU
/local/domain/5/device/vkbd/0/backend = "/local/domain/0/backend/vkbd/5/0"
/local/domain/5/device/vkbd/0/backend-id = "0"
/local/domain/5/device/vkbd/0/state = "1"
/local/domain/5/device/pci = ""
/local/domain/5/device/pci/0 = ""
/local/domain/5/device/pci/0/backend = "/local/domain/0/backend/pci/5/0"
/local/domain/5/device/pci/0/backend-id = "0"
/local/domain/5/device/pci/0/state = "1"
/local/domain/5/control = ""

For dom0
/local/domain/0/backend/vkbd/5/0/feature-abs-pointer = "1"
/local/domain/0/backend/vkbd/5/0/hotplug-status = "connected"
/local/domain/0/backend/pci = ""
/local/domain/0/backend/pci/5 = ""
/local/domain/0/backend/pci/5/0 = ""
/local/domain/0/backend/pci/5/0/frontend = "/local/domain/5/device/pci/0"
/local/domain/0/backend/pci/5/0/frontend-id = "5"
/local/domain/0/backend/pci/5/0/online = "1"
/local/domain/0/backend/pci/5/0/state = "3"
/local/domain/0/backend/pci/5/0/domain = "win2008_server_r2_sp1_64"
/local/domain/0/backend/pci/5/0/key-0 = ":06:00.0"
/local/domain/0/backend/pci/5/0/dev-0 = ":06:00.0"
/local/domain/0/backend/pci/5/0/vdevfn-0 = "20"
/local/domain/0/backend/pci/5/0/opts-0 = 
"msitranslate=0,power_mgmt=0,permissive=0"
/local/domain/0/backend/pci/5/0/state-0 = "3"
/local/domain/0/backend/pci/5/0/num_devs = "1"
/local/domain/0/backend/pci/5/0/vdev-0 = ":00:00.00"
/local/domain/0/backend/pci/5/0/root-0 = ":00"
/local/domain/0/backend/pci/5/0/root_num = "1"
/local/domain/5 = ""
/local/domain/5/vm = "/vm/81296e36-1576-4b58-bb6e-17dc2b4ea1f6"


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

Re: [Xen-devel] [PATCH v2 03/10] x86: assembly, use SYM_FUNC_END for functions

[Jiri Slaby]

On 03/22/2017, 04:44 PM, Jiri Slaby wrote:
> On 03/22/2017, 03:26 PM, Josh Poimboeuf wrote:
>> On Mon, Mar 20, 2017 at 01:32:15PM +0100, Jiri Slaby wrote:
>>> Somewhere END was used to end a function, elsewhere, nothing was used.
>>> So unify it and mark them all by SYM_FUNC_END.
>>>
>>> Signed-off-by: Jiri Slaby 
>>
>> For me these patches would be easier to review if the SYM_FUNC_START and
>> SYM_FUNC_END pairs for a given function are done in the same patch.
> 
> This patchset was intended to make everything paired with minimum
> changes. I certainly can change also counter-elements of each
> added/changed one if you prefer.

So do really you want me to use the new macros while I am
adding/changing the counter-macro? Is there anything else blocking the
merge of the patches?

>> Also I noticed several cases in entry_64.S where the old ENTRY macro is
>> still used, and paired with SYM_FUNC_END.
>>
>> Maybe there should be an x86 version of the deprecated ENTRY/ENDPROC/etc
>> macros which throw a warning or an error?
> 
> Yes, my plan is to throw ENTRY/ENDPROC on the floor from x86 completely.
> And I will do it after this patchset settles down by sed or something in
> one shot (per directory or something).
> 
> thanks,
-- 
js
suse labs

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

Re: [Xen-devel] [PATCH] x86emul: add "unblock NMI" retire flag

[Jan Beulich]

>>> On 10.04.17 at 13:01,  wrote:
> On 10/04/17 11:58, Jan Beulich wrote:
>> No matter that we emulate IRET for (guest) real more only right now, we
>> should get its effect on (virtual) NMI delivery right.
>>
>> Signed-off-by: Jan Beulich 
> 
> At a minimum, you need to mask unblock_nmi out of the assertion in
> x86_emulate_wrapper(), as we now have a retire flag which is legitimate
> to use when rc != OKAY.

Oops, thanks for noticing.

Jan


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

Re: [Xen-devel] [PATCH] x86emul: add "unblock NMI" retire flag

[Andrew Cooper]

On 10/04/17 11:58, Jan Beulich wrote:
> No matter that we emulate IRET for (guest) real more only right now, we
> should get its effect on (virtual) NMI delivery right.
>
> Signed-off-by: Jan Beulich 

At a minimum, you need to mask unblock_nmi out of the assertion in
x86_emulate_wrapper(), as we now have a retire flag which is legitimate
to use when rc != OKAY.

Everything else looks fine.

~Andrew

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

Re: [Xen-devel] [PATCH] tools/golang: Add myself as maintainer

[George Dunlap]

On 06/04/17 20:52, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 06, 2017 at 03:57:06PM +0100, George Dunlap wrote:
>> Signed-off-by: George Dunlap 
>> ---
>> Andrew Cooper 
>> Ian Jackson 
>> Jan Beulich 
>> Konrad Rzeszutek Wilk 
>> Stefano Stabellini 
>> Tim Deegan 
>> Wei Liu 
>> ---
>>  MAINTAINERS | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index c38bcd4..050cb35 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -206,6 +206,13 @@ S:  Supported
>>  F:  xen/arch/x86/debug.c
>>  F:  tools/debugger/gdbsx/
>>  
>> +GOLANG BINDINGS
>> +M:  George Dunlap 
>> +M:  Ian Jackson 
>> +M:  Wei Liu 
> 
> Something is off with the spaces/tabs?

So it would seem... my emacs seems to never want to add tabs when I
type, but will leave them there when I copy-and-paste.

Attached is a patch with all tabs.

 -George

>From 60a6f69a6b1bed54c607638f4597e70b9cdaabed Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Thu, 6 Apr 2017 15:52:10 +0100
Subject: [PATCH] tools/golang: Add myself as maintainer

Signed-off-by: George Dunlap 
---
Changes since v1: Fix tabs

CC: Andrew Cooper 
CC: Ian Jackson 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c38bcd4..050cb35 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -206,6 +206,13 @@ S:	Supported
 F:	xen/arch/x86/debug.c
 F:	tools/debugger/gdbsx/
 
+GOLANG BINDINGS
+M:  George Dunlap 
+M:	Ian Jackson 
+M:	Wei Liu 
+S:  Supported
+F:  tools/golang
+
 INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
 M:	Gang Wei 
 M:	Shane Wang 
-- 
2.1.4

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

Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

Hi Ian,

After internal discussion we think that putting positions and z-orders
of virtual connectors
to the Xen store and libxl configuration is not so good idea. Because
their composition
depends on an application and usage. We consider automotive usage.
For example one of domain drives navigation system and depends on scenario
the navigation window position and size can be changed. In that case on the host
should be an instance of window manager or something like that.
The window manager will decide where to put the virtual displays.

What is important for frontend and backend are number of virtual
connectors and their
resolutions.

If it is ok, following is libxl/xl configuration proposal:

1. Configuration file:
vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]

* backend - backend domain id or name (if different from dom 0);
* devId - device id (if different from 0);
* beAlloc - indicated where to allocate buffers (according to protocol [1]);
* connectors - resolutions for connectors list: 800x600 for
connector 0, 1024x768 for connector 1, etc.

2. libxl_types.idl:

libxl_connector_param = Struct("connector_param", [
("width", uint32),
("height", uint32)
])

libxl_device_vdispl = Struct("device_vdispl", [
("backend_domid", libxl_domid),
("backend_domname", string),
("devid", libxl_devid),
("be_alloc", bool),
("connectors", Array(libxl_connector_param, "num_connectors"))
])

libxl_connectorinfo = Struct("connectorinfo", [
("width", uint32),
("height", uint32),
("evtch", integer),
("rref", integer),
], dir=DIR_OUT)

libxl_vdisplinfo = Struct("vdisplinfo", [
("backend", string),
("backend_id", uint32),
("frontend", string),
("frontend_id", uint32),
("devid", libxl_devid),
("state", integer),
("be_alloc", bool),
("connectors", Array(libxl_connectorinfo, "num_connectors"))
], dir=DIR_OUT)

3. xl command line:

{ "vdispl-attach",
  _vdisplattach, 1, 1,
  "Create a new virtual display device",
  " [devId=] [backend=] [beAlloc=]"\
  " [connectors=",
  "BackAlloc - set to 1 to allow backend allocated display buffers\n"
  "Resolutions - list of connector's resolutions in WxH format:\n"
  "800x600,1024x768"
},
{ "vdispl-list",
  _vdispllist, 0, 0,
  "List virtual display devices for a domain",
  "",
},
{ "vdispl-detach",
  _vdispldetach, 0, 1,
  "Destroy a domain's virtual display device",
  " ",
},


[1] http://marc.info/?l=xen-devel=149137266022490=2

Thanks.

-- 
Best Regards,
Oleksandr Grytsov.

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

[Xen-devel] [PATCH] x86emul: add "unblock NMI" retire flag

[Jan Beulich]

No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
 memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
 }
 
-if ( rc != X86EMUL_OKAY )
-return rc;
+new_intr_shadow = hvmemul_ctxt->intr_shadow;
 
-if ( hvmemul_ctxt->ctxt.retire.singlestep )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+/*
+ * IRET, if valid in the given context, clears NMI blocking
+ * (irrespective of rc).
+ */
+if ( hvmemul_ctxt->ctxt.retire.unblock_nmi )
+new_intr_shadow &= ~HVM_INTR_SHADOW_NMI;
 
-new_intr_shadow = hvmemul_ctxt->intr_shadow;
+if ( rc == X86EMUL_OKAY )
+{
+if ( hvmemul_ctxt->ctxt.retire.singlestep )
+hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 
-/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.mov_ss )
-new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
-
-/* STI instruction toggles STI shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.sti )
-new_intr_shadow ^= HVM_INTR_SHADOW_STI;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
+/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
+if ( hvmemul_ctxt->ctxt.retire.mov_ss )
+new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
+else
+new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
+
+/* STI instruction toggles STI shadow, else we just clear it. */
+if ( hvmemul_ctxt->ctxt.retire.sti )
+new_intr_shadow ^= HVM_INTR_SHADOW_STI;
+else
+new_intr_shadow &= ~HVM_INTR_SHADOW_STI;
+}
 
 if ( hvmemul_ctxt->intr_shadow != new_intr_shadow )
 {
@@ -1981,13 +1988,11 @@ static int _hvm_emulate_one(struct hvm_e
 hvm_funcs.set_interrupt_shadow(curr, new_intr_shadow);
 }
 
-if ( hvmemul_ctxt->ctxt.retire.hlt &&
+if ( rc == X86EMUL_OKAY && hvmemul_ctxt->ctxt.retire.hlt &&
  !hvm_local_events_need_delivery(curr) )
-{
 hvm_hlt(regs->eflags);
-}
 
-return X86EMUL_OKAY;
+return rc;
 }
 
 int hvm_emulate_one(
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -4002,6 +4002,7 @@ x86_emulate(
 uint32_t mask = X86_EFLAGS_VIP | X86_EFLAGS_VIF | X86_EFLAGS_VM;
 
 fail_if(!in_realmode(ctxt, ops));
+ctxt->retire.unblock_nmi = true;
 if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
   , op_bytes, ctxt, ops)) ||
  (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -490,6 +490,7 @@ struct x86_emulate_ctxt
 bool hlt:1;  /* Instruction HLTed. */
 bool mov_ss:1;   /* Instruction sets MOV-SS irq shadow. */
 bool sti:1;  /* Instruction sets STI irq shadow. */
+bool unblock_nmi:1;  /* Instruction clears NMI blocking. */
 bool singlestep:1;   /* Singlestepping was active. */
 };
 } retire;



x86emul: add "unblock NMI" retire flag

No matter that we emulate IRET for (guest) real more only right now, we
should get its effect on (virtual) NMI delivery right.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1955,25 +1955,32 @@ static int _hvm_emulate_one(struct hvm_e
 memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio->mmio_insn_bytes);
 }
 
-if ( rc != X86EMUL_OKAY )
-return rc;
+new_intr_shadow = hvmemul_ctxt->intr_shadow;
 
-if ( hvmemul_ctxt->ctxt.retire.singlestep )
-hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
+/*
+ * IRET, if valid in the given context, clears NMI blocking
+ * (irrespective of rc).
+ */
+if ( hvmemul_ctxt->ctxt.retire.unblock_nmi )
+new_intr_shadow &= ~HVM_INTR_SHADOW_NMI;
 
-new_intr_shadow = hvmemul_ctxt->intr_shadow;
+if ( rc == X86EMUL_OKAY )
+{
+if ( hvmemul_ctxt->ctxt.retire.singlestep )
+hvm_inject_hw_exception(TRAP_debug, X86_EVENT_NO_EC);
 
-/* MOV-SS instruction toggles MOV-SS shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.mov_ss )
-new_intr_shadow ^= HVM_INTR_SHADOW_MOV_SS;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_MOV_SS;
-
-/* STI instruction toggles STI shadow, else we just clear it. */
-if ( hvmemul_ctxt->ctxt.retire.sti )
-new_intr_shadow ^= HVM_INTR_SHADOW_STI;
-else
-new_intr_shadow &= ~HVM_INTR_SHADOW_STI;

Re: [Xen-devel] [PATCH for-4.9 v2 1/2] xsm: fix clang 3.5 build after c47d1d

[Julien Grall]

On 10/04/17 11:50, Jan Beulich wrote:

On 10.04.17 at 12:39,  wrote:

Hi Roger,

On 10/04/17 10:01, Roger Pau Monne wrote:

The changes introduced on c47d1d broke the clang build due to undefined
references to __xsm_action_mismatch_detected, because clang hasn't optimized
the code properly. The following patch allows the clang build to work again,
while keeping the same functionality.

Signed-off-by: Roger Pau Monné 
---
Cc: Daniel De Graaf 
Cc: Julien Grall 
Cc: Tamas K Lengyel 
---
Changes since v1:
 - Remove unused "break".
 - Remove if condition.


This new version does not fix the ARM32 build (though the previous
one does). I still get:

prelink.o: In function `xsm_default_action':
/home/julieng/works/xen/xen/include/xsm/dummy.h:80: undefined reference to
`__xsm_action_mismatch_detected'
arm-linux-gnueabihf-ld: /home/julieng/works/xen/xen/.xen-syms.0: hidden
symbol `__xsm_action_mismatch_detected' isn't defined


I have to admit that I was afraid of this, after having seen this is
an issue for ARM too. I guess the suggested use of a conditional
expression (instead of if/else) needs to be undone, which is quite
sad.


I think this would be the safest for now, I would like to cut an RC soon 
with what has been pushed before the code freeze. This would mean v1 + 
removing pointless break.


Cheers,

--
Julien Grall

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

[Xen-devel] Starting by making a small contribution

[shivani ahuja]

Hello,

As, its my first day to work for XEN - Hypervisor Project, I need a little
guidance on how so I start making my contribution and work along with the
project. I have read all the info available on outreachy wiki page. I have
to setup my system to work accordingly. Please help me to reach out to the
best person who could help me starting with the internship.

Looking forward for a response.


*ThankYou.*


*Regards,*
*Shivani.*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel