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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  92938e5d149669033aecdfb3d1396948d49d1887
baseline version:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100

Last test of basis   122642  2018-05-07 16:00:38 Z1 days
Failing since122654  2018-05-08 17:00:50 Z0 days3 attempts
Testing same since   122662  2018-05-08 19:00:37 Z0 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 
  Xen Project Security Team 

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



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   f78c832285..92938e5d14  92938e5d149669033aecdfb3d1396948d49d1887 -> smoke

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt18 guest-start/debian.repeat fail REGR. vs. 122642

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

version targeted for testing:
 xen  92938e5d149669033aecdfb3d1396948d49d1887
baseline version:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100

Last test of basis   122642  2018-05-07 16:00:38 Z1 days
Failing since122654  2018-05-08 17:00:50 Z0 days2 attempts
Testing same since   122662  2018-05-08 19:00:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Roger Pau Monné 
  Xen Project Security Team 

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



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 92938e5d149669033aecdfb3d1396948d49d1887
Author: Jan Beulich 
Date:   Tue May 8 18:12:56 2018 +0100

x86/HVM: guard against emulator driving ioreq state in weird ways

In the case where hvm_wait_for_io() calls wait_on_xen_event_channel(),
p->state ends up being read twice in succession: once to determine that
state != p->state, and then again at the top of the loop.  This gives a
compromised emulator a chance to change the state back between the two
reads, potentially keeping Xen in a loop indefinitely.

Instead:
* Read p->state once in each of the wait_on_xen_event_channel() tests,
* re-use that value the next time around,
* and insist that the states continue to transition "forward" (with the
  exception of the transition to STATE_IOREQ_NONE).

This is XSA-262.

Signed-off-by: Jan Beulich 
Reviewed-by: George Dunlap 

commit 14c3f68a57361f20be33ec3848f83d8636a0d34e
Author: Xen Project Security Team 
Date:   Tue May 8 18:12:10 2018 +0100

x86/vpt: add support for IO-APIC routed interrupts

And modify the HPET code to make use of it. Currently HPET interrupts
are always treated as ISA and thus injected through the vPIC. This is
wrong because HPET interrupts when not in legacy mode should be
injected from the IO-APIC.

To make things worse, the supported interrupt routing values are set
to [20..23], which clearly falls outside of the ISA range, thus
leading to an ASSERT in debug builds or memory corruption in non-debug
builds because the interrupt injection code will write out of the
bounds of the arch.hvm_domain.vpic array.

Since the HPET interrupt source can change between ISA and IO-APIC
always destroy the timer before changing the mode, or else Xen risks
changing it while the timer is active.

Note that vpt interrupt injection is racy in the sense that the
vIO-APIC RTE entry can be written by the guest in between the call to
pt_irq_masked and hvm_ioapic_assert, or the call to pt_update_irq and
pt_intr_post. Those are not deemed to be security issues, but rather
quirks of the current implementation. In the worse case the guest
might lose interrupts or get multiple interrupt 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-xsm 16 guest-start/debian.repeat fail REGR. vs. 122642
 test-armhf-armhf-xl  12 guest-start  fail REGR. vs. 122642

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

version targeted for testing:
 xen  b190f0c0c1dff13ce92c5f056a87d6c81d3ee8f9
baseline version:
 xen  f78c8322850dbe3dbe9cd828ee00767190529100

Last test of basis   122642  2018-05-07 16:00:38 Z1 days
Testing same since   122654  2018-05-08 17:00:50 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

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



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

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

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

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


Not pushing.


commit b190f0c0c1dff13ce92c5f056a87d6c81d3ee8f9
Author: Andrew Cooper 
Date:   Tue May 8 13:45:45 2018 +0100

x86/domain: Drop the only-written smap_check_policy infrastructure

c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
smap_check logic, it exists only to work around a bug in guest_walk_tables()
was resolved by the aformentioned commit.

Remove the unused variables and associated infrastructure.

Reported-by: Jason Andryuk 
Signed-off-by: Andrew Cooper 
Reviewed-by: George Dunlap 
Reviewed-by: Roger Pau Monné 
Release-acked-by: Juergen Gross 
(qemu changes not included)

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

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-arm64-arm64-xl-credit2  broken
 build-arm64-libvirt  broken
 test-arm64-arm64-xl  broken
 build-arm64-libvirt   4 host-install(4)broken REGR. vs. 122580
 test-arm64-arm64-xl   4 host-install(4)broken REGR. vs. 122580
 test-arm64-arm64-examine  5 host-install   broken REGR. vs. 122580
 test-arm64-arm64-xl-xsm  broken  in 122621

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-xl-xsm  4 host-install(4) broken in 122621 pass in 122631
 test-arm64-arm64-xl-credit2   4 host-install(4)  broken pass in 122621
 test-amd64-amd64-pair21 guest-start/debian fail pass in 122621
 test-amd64-amd64-xl-xsm  12 guest-startfail pass in 122621
 test-amd64-i386-xl-xsm   12 guest-startfail pass in 122621
 test-amd64-amd64-libvirt 18 guest-start/debian.repeat  fail pass in 122621
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 122621
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 18 
guest-start/debianhvm.repeat fail pass in 122621
 test-amd64-amd64-xl-qemuu-ovmf-amd64 18 guest-start/debianhvm.repeat fail pass 
in 122621
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
122621

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

[Xen-devel] Xen Security Advisory 260 (CVE-2018-8897) - x86: mishandling of debug exceptions

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory CVE-2018-8897 / XSA-260
  version 2

 x86: mishandling of debug exceptions

UPDATES IN VERSION 2


Public release.

Updated .meta file

ISSUE DESCRIPTION
=

When switching stacks, it is critical to have a matching stack segment
and stack pointer.  To allow an atomic update from what would otherwise
be two adjacent instructions, an update which changes the stack segment
(either a mov or pop instruction with %ss encoded as the destination
register) sets the movss shadow for one instruction.

The exact behaviour of the movss shadow is poorly understood.

In practice, a movss shadow delays some debug exceptions (e.g. from a
hardware breakpoint) until the subsequent instruction has completed.  If
the subsequent instruction normally transitions to supervisor mode
(e.g. a system call), then the debug exception will be taken after the
transition to ring0 is completed.

For most transitions to supervisor mode, this only confuses Xen into
printing a lot of debugging information.  For the syscall instruction
however, the exception gets taken before the syscall handler can move
off the guest stack.

IMPACT
==

A malicious PV guest can escalate their privilege to that of the
hypervisor.

VULNERABLE SYSTEMS
==

All versions of Xen are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

Only x86 PV guests can exploit the vulnerability.  x86 HVM and PVH
guests cannot exploit the vulnerability.

An attacker needs to be able to control hardware debugging facilities to
exploit the vulnerability, but such permissions are typically available
to unprivileged users.

MITIGATION
==

Running only HVM or PVH guests avoids the vulnerability.

Note however that a compromised device model (running in dom0 or a
stub domain) can carry out this attack, so users with HVM domains are
also advised to patch their systems.

CREDITS
===

This issue was discovered by Andy Lutomirski, and Nick Peterson of Everdox
Tech LLC.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa260-unstable/*.patch xen-unstable
xsa260-4.10/*.patch Xen 4.10.x
xsa260-4.9/*.patch  Xen 4.9.x
xsa260-4.8/*.patch  Xen 4.8.x
xsa260-4.7/*.patch  Xen 4.7.x
xsa260-4.6/*.patch  Xen 4.6.x

$ sha256sum xsa260* xsa260*/*
f436009ea6d6a30cf9c316e909dcd260c223264884d2e4fc5b74bdaf2e515815  xsa260.meta
0f7e3cfecc59986fc950694bba7bb31ee9680b2390920335d6853fdf83ded9ef  
xsa260-unstable/xsa260-1.patch
4df5b9d05a8f02754b1e819b8cad35b3da9ba7fcdaee0fc762d572481ef69f93  
xsa260-unstable/xsa260-2.patch
5c3f9cbc777ed7a93a97a4665e0188e1b1a05dd057da830203e018c73e9e5ce7  
xsa260-unstable/xsa260-3.patch
4b280ec02418f30f0576e84f23ae565acee4fcc2d398b3828c1e12d9346583af  
xsa260-unstable/xsa260-4.patch
2c5ce2851351a40df9ed17fae3c6f7505dcda60209945321b545b6b6e4f065cb  
xsa260-4.6/xsa260-1.patch
bfa2eb161f570b0295464ef41fc5add52e10853a1ec81de107f1a9deb945982f  
xsa260-4.6/xsa260-2.patch
2f30c4fbebeb77da50caff62a0f28d3afe8993bee19233543170f1955cebdcbc  
xsa260-4.6/xsa260-3.patch
363af89377d5819ad1450c8806824707d3e15700c179129aed62128e62ab1a0e  
xsa260-4.6/xsa260-4.patch
0c2552a36737975f4f46d7054b49fd018b68c302cef3b39b27c2f17cc60eb531  
xsa260-4.7/xsa260-1.patch
a92ef233a83923d6a18d51528ff28630ae3f1134ee76f2347397e22da9c84c24  
xsa260-4.7/xsa260-2.patch
8469af8ba5b6722738b27c328eccc1d341af49c2e2bb23fe7b327a3349267b0e  
xsa260-4.7/xsa260-3.patch
0327c2ef7984a4aa000849c68a01181fdb01962637e78629c6fb34bb95414a74  
xsa260-4.7/xsa260-4.patch
a9be346f111bca3faf98045c089638ba960f291eb9ace03e8922d7b4f8a9b37e  
xsa260-4.8/xsa260-1.patch
740c0ee49936430fdf66ae8b75f9f51fe728c71a7c7a56667f845aea7669d344  
xsa260-4.8/xsa260-2.patch
94dbb7ad7d409f9170950162904247c7cf0e360cec2a0a1f1a6653ce9ca43283  
xsa260-4.8/xsa260-3.patch
db440d76685cf1e8c332aea2aa13e6be43b1b7f68d9225dfe99bb2ee12e18b9e  
xsa260-4.8/xsa260-4.patch
11b55f664a4043ed3a79d3e1a07877c68c8c19df6112feffdac1e55547f0002e  
xsa260-4.9/xsa260-1.patch
38a762f8cf8db763d70f1ef35a4c2cac23282b694527a97b2eaf100a14f767eb  
xsa260-4.9/xsa260-2.patch
18d9ffd273bdbd070e1b613e7f18ed21cdb874dba5f7964e14bb4a3dbc8844ec  
xsa260-4.9/xsa260-3.patch
c3d689d581c2ce6beaaa9d955f159a3b5da8007a24a08969b0953e89491f15a5  
xsa260-4.9/xsa260-4.patch
ffac7ab75bf65f8286b37d21cb4a4401d898670a4e52af88d8202ce4fe66edef  
xsa260-4.10/xsa260-1.patch
fe85832a9b5b1076b3a9bdbd28a2f3be57cd019d66a725ce64698b1bd74145a8  
xsa260-4.10/xsa260-2.patch
1955aed73828e23da871ef10e5ec49670ce59bdd06af2772e978f8e817e0319f  
xsa260-4.10/xsa260-3.patch
8f504f8fcf100f8a00bece9c4df8b8933dceeaf29b50492317f9cbf74aaf4aa4  
xsa260-4.10/xsa260-4.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even 

[Xen-devel] Xen Security Advisory 262 - qemu may drive Xen into unbounded loop

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-262
  version 2

qemu may drive Xen into unbounded loop

UPDATES IN VERSION 2


Public release.

Updated .meta file

ISSUE DESCRIPTION
=

When Xen sends requests to a device model, the next expected action
inside Xen is tracked using a state field.  The requests themselves
are placed in a memory page shared with the device model, so that the
device model can communicate to Xen its progress on the request.  The
state field is in the request itself, where the device model may write
to it.  Xen correctly rejects invalid state values, but failed to reject
invalid transitions between states.  As a result, a device model which
switches a request between two states at the right times can drive Xen
into an unbounded loop.

IMPACT
==

A malicious unprivileged device model can cause a Denial of Service
(DoS) affecting the entire host.  Specifically, it may prevent use of a
physical CPU for an indeterminate period of time.

VULNERABLE SYSTEMS
==

All Xen versions are vulnerable.

Only x86 systems are affected.  ARM systems are not affected.

Only HVM guests can expose this vulnerability.  PV and PVH guests cannot
expose this vulnerability, but note that the domains being able to
leverage the vulnerability are PV or PVH ones, running the device model.

This vulnerability is only applicable to Xen systems using stub domains.

MITIGATION
==

Running only PV or PVH guests will avoid this issue.

(The security of a Xen system using stub domains is still better than
with a qemu-dm running as an unrestricted dom0 process.  Therefore
users with these configurations should not switch to an unrestricted
dom0 qemu-dm.)

CREDITS
===

This issue was discovered by Jan Beulich of SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa262.patch   xen-unstable
xsa262-4.10.patch  Xen 4.10.x
xsa262-4.9.patch   Xen 4.9.x, Xen 4.8.x, Xen 4.7.x
xsa262-4.6.patch   Xen 4.6.x

$ sha256sum xsa262*
a5a3458c5efdad282bd769fcab2b94ebfe0a979befae3b4703201fcbf0970cc7  xsa262.meta
5aa73753d3eec8ae391b1364c430df7517bf4bdb3e65a8e6e8431898348f4ad9  xsa262.patch
7196b468b916bf956f8dc0cab20a5c29f8a1bfa4de4e4fa982b7b9c8494e4c0d  
xsa262-4.6.patch
ec2b6ba9ed1d5e97fed4b54767160a75fe19d67e4519f716739bebdb78816191  
xsa262-4.9.patch
91d3b329131b6d434b268c0c55fd4900033fce8b2582bd9278ae967efc980fb0  
xsa262-4.10.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJa8dQhAAoJEIP+FMlX6CvZyCUH/1eCZrElPEOUySjMRbix0EJ8
TW5pWx76PX27Hek4fk+tFxsfDWEqWN4AP9YgjSQKNyXUWEr1oiyq83Vq/JXM6bHt
HSWbrh7sjkkziEGqlOXpryS8/RIE3CZC5nQOTAsPX65tB+2nXkOY5zwuxXM8Ivn6
9p0yitSWd3Ve68PLAhthb/7BDdsAgITtgtxuTDHmDB6h32Fo8m990nD1jbAcP9WR
q32gqXUMdlCf161/viPkSnrRqsnmdzPbXDsAzqtnUeVGNtqb5mI8jqox9Z6JGedG
qMwlZVWO7TzcpO/18KbI8qYypL2/ensEo4bPbvRN7qzA6y8QGwMrLsygtZuBVkw=
=D72A
-END PGP SIGNATURE-


xsa262.meta
Description: Binary data


xsa262.patch
Description: Binary data


xsa262-4.6.patch
Description: Binary data


xsa262-4.9.patch
Description: Binary data


xsa262-4.10.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] Xen Security Advisory 261 - x86 vHPET interrupt injection errors

[Xen . org security team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Xen Security Advisory XSA-261
  version 2

 x86 vHPET interrupt injection errors

UPDATES IN VERSION 2


Versions 3.1 ... 3.3 don't appear to be vulnerable.

Public release.

Updated .meta file

ISSUE DESCRIPTION
=

The High Precision Event Timer (HPET) can be configured to deliver
interrupts in one of three different modes - through legacy interrupts;
through the IO-APIC; or optionally via a method similar to PCI MSI.  The
last mode is optional and not implemented by Xen.  However, of the first
two modes, only the legacy variant was properly implemented.

If a guest set up an HPET timer in IO-APIC mode, Xen would still
handle this using the code for the legacy mode.  Unfortunately, the
available IO-APIC mode interrupt numbers are higher than legacy mode
interrupts.  The result was array overruns.

IMPACT
==

A malicious or buggy HVM guest may cause a hypervisor crash, resulting
in a Denial of Service (DoS) affecting the entire host.  Privilege
escalation, or information leaks, cannot be excluded.

VULNERABLE SYSTEMS
==

Xen versions 3.4 and later are vulnerable.

Only x86 systems are vulnerable.  ARM systems are not vulnerable.

Only x86 HVM guests can exploit the vulnerability.  x86 PV and PVH
guests cannot exploit the vulnerability.

Only x86 HVM guests provided with hypervisor-side HPET emulation can
exploit the vulnerability.  That is the default configuration.  x86
HVM guests whose configuration explicitly disables this emulation (via
"hpet=0") cannot exploit the vulnerability.

MITIGATION
==

Running only PV or PVH guests avoids the vulnerability.

Not exposing the hypervisor based HPET emulation to HVM guests, by
adding "hpet=0" to the guest configuration, also avoids the
vulnerability.

CREDITS
===

This issue was discovered by Roger Pau Monné of Citrix.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa261.patch   xen-unstable, Xen 4.10.x
xsa261-4.9.patch   Xen 4.9.x
xsa261-4.8.patch   Xen 4.8.x
xsa261-4.7.patch   Xen 4.7.x, Xen 4.6.x

$ sha256sum xsa261*
7b7bbf0fb497491911816e522902f72d3b41355ba71455ab82ebf980160d1a1f  xsa261.meta
175501977204db84d08a6fd81d9fd4b69f97f70cbf6f65e6ce0abfeab03eae95  xsa261.patch
98fb28bac871aae7c2f897a5506a2b03f340bf122a3a7f65aa65f3b3c9a525b4  
xsa261-4.7.patch
503f1476813e6572dc37b5a0df65b5390567230d9cc006752bf72bf57bbd754d  
xsa261-4.8.patch
f1aac841327d3b5b1e2007b4ebe56223de488e1eb2fa636653725d7d7cd5f82a  
xsa261-4.9.patch
$

DEPLOYMENT DURING EMBARGO
=

Deployment of the patches described above (or others which are
substantially similar) and the PV/PVH guest mitigation are permitted
during the embargo, even on public-facing systems with untrusted guest
users and administrators.

HOWEVER deployment of the "hpet=0" guest config mitigation described
above is NOT permitted (except where all the affected systems and VMs
are administered and used only by organisations which are members of
the Xen Project Security Issues Predisclosure List).  Specifically,
deployment on public cloud systems is NOT permitted.

This is because in that case the configuration change is visible to the
guest, which could lead to the rediscovery of the vulnerability.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJa8dQgAAoJEIP+FMlX6CvZZ54IAIlcZ6vu0mYvjwL8I23QbbtW
8uDzgozK9S8r2tPXxn6gbqSwFACuKeS61hnhw7v3gNEClpSQip+dHlGS6ME3AUVZ
m0Vtn6eDQXHiwW+9jM4/j8gxLAqgfxUUpTuR74tZxh0kMmXKShirt+ob+9ptxfB7
nu8QiEVDH87P7JnDUXn1czNBRuD3KP0cmsAW/7VaOUm5R/+1RwYX6df9rEN6TU/+
LWMrBeepU8mh8oRgA5yJ78iiCB6KUfURsz1JuPmNd49rSTVK2WGFAH5vNz7EjRyU
kbVAJgjWYGGFo0BTXSt8kCi0pdlGEHRh3+KIIuvAxm+JfQtrFC0K8lpzQcpTPYY=
=jUil
-END PGP SIGNATURE-


xsa261.meta
Description: Binary data


xsa261.patch
Description: Binary data


xsa261-4.7.patch
Description: Binary data


xsa261-4.8.patch
Description: Binary data


xsa261-4.9.patch
Description: Binary data
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Olaf Hering]

Am Tue, 8 May 2018 13:31:43 +0200
schrieb Olaf Hering :

> On the sending side offset 0xc9 is unlocked on the other fd, which allows 
> F_WRLCK to succeed:
> 
> It seems on the receiving side some code forgets to unclock offset 0xc9, 
> which causes F_WRLCK to fail:

It looks like the IDE unplug is not permanent.
On the receiving side the IDE disk is reattached, and it keeps the qcow2 image 
busy.
Does anyone happen to know how to make the unplug permanent, at least for the 
blocklayer?

Olaf


pgpOVVvpZns8N.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Julien Grall]

Hi,

On 08/05/18 17:20, Andrew Cooper wrote:

On 08/05/18 17:10, Roger Pau Monné wrote:

On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:

c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
smap_check logic, it exists only to work around a bug in guest_walk_tables()
was resolved by the aformentioned commit.

Remove the unused variables and associated infrastructure.

Reported-by: Jason Andryuk 
Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 


diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 8b66096..197f8d6 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -595,7 +583,6 @@ struct arch_vcpu
  
  struct guest_memory_policy

  {
-smap_check_policy_t smap_policy;
  bool nested_guest_mode;

Maybe guest_memory_policy could be dropped and
update_guest_memory_policy updated to take a bool nested_mode
parameter?


update_guest_memory_policy() stores the old value in the passed
structure, and would more accurately be toggle_guest_memory_policy()
when it came to guest mode.


Or the function can be dropped altogether likely.


Sadly not yet.  This exists because of Xen's virtual-address based API
for the shared info and time mappings.  This API is bad and wrong and
wants fixing.  ISTR Juergen and Julien having plans to deal with this?


This should indeed be fixed properly, I was waiting some answer on my 
questions before attempting to go further on a fix (see [1] and [2]). I 
didn't have bandwidth so far to ping on the subject.


Cheers,

[1] 
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg08836.html
[2] 
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg08835.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Andrew Cooper]

On 08/05/18 17:10, Roger Pau Monné wrote:
> On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only to work around a bug in guest_walk_tables()
>> was resolved by the aformentioned commit.
>>
>> Remove the unused variables and associated infrastructure.
>>
>> Reported-by: Jason Andryuk 
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Roger Pau Monné 
>
>> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
>> index 8b66096..197f8d6 100644
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -595,7 +583,6 @@ struct arch_vcpu
>>  
>>  struct guest_memory_policy
>>  {
>> -smap_check_policy_t smap_policy;
>>  bool nested_guest_mode;
> Maybe guest_memory_policy could be dropped and
> update_guest_memory_policy updated to take a bool nested_mode
> parameter? 

update_guest_memory_policy() stores the old value in the passed
structure, and would more accurately be toggle_guest_memory_policy()
when it came to guest mode.

> Or the function can be dropped altogether likely.

Sadly not yet.  This exists because of Xen's virtual-address based API
for the shared info and time mappings.  This API is bad and wrong and
wants fixing.  ISTR Juergen and Julien having plans to deal with this?

~Andrew

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

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Andrew Cooper]

On 08/05/18 17:05, George Dunlap wrote:
> On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper  
> wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only to work around a bug in guest_walk_tables()
>> was resolved by the aformentioned commit.
>>
>> Remove the unused variables and associated infrastructure.
>>
>> Reported-by: Jason Andryuk 
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: George Dunlap 
>
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Juergen Gross 
>> CC: Jason Andryuk 
>>
>> I'm on the fence as to whether to suggest this for 4.11 at this point.  Its
>> probably not something to be backported, but it is a nice bit of cleanup, and
>> removes a particularly gross hack.
> It looks like the commit that made this code vestigal was introduced
> in March 2017?  So we've already had two releases with this flag not
> doing anything, and no ill effects reported.

Well, it is a write-only variable.  I'd be rather concerned if it did
anything.

> I'd be in favor of accepting a patch like this for 4.11, and also for
> backporting it to 4.10 and 4.9

Ok - I'm not fussed either way.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Roger Pau Monné]

On Tue, May 08, 2018 at 02:03:04PM +0100, Andrew Cooper wrote:
> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
> consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
> smap_check logic, it exists only to work around a bug in guest_walk_tables()
> was resolved by the aformentioned commit.
> 
> Remove the unused variables and associated infrastructure.
> 
> Reported-by: Jason Andryuk 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Roger Pau Monné 

> diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
> index 8b66096..197f8d6 100644
> --- a/xen/include/asm-x86/domain.h
> +++ b/xen/include/asm-x86/domain.h
> @@ -595,7 +583,6 @@ struct arch_vcpu
>  
>  struct guest_memory_policy
>  {
> -smap_check_policy_t smap_policy;
>  bool nested_guest_mode;

Maybe guest_memory_policy could be dropped and
update_guest_memory_policy updated to take a bool nested_mode
parameter? Or the function can be dropped altogether likely.

In any case, this can be done in a followup cleanup patch.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Juergen Gross]

On 08/05/18 18:05, George Dunlap wrote:
> On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper  
> wrote:
>> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
>> consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
>> smap_check logic, it exists only to work around a bug in guest_walk_tables()
>> was resolved by the aformentioned commit.
>>
>> Remove the unused variables and associated infrastructure.
>>
>> Reported-by: Jason Andryuk 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: George Dunlap 
> 
>> ---
>> CC: Jan Beulich 
>> CC: Wei Liu 
>> CC: Roger Pau Monné 
>> CC: Juergen Gross 
>> CC: Jason Andryuk 
>>
>> I'm on the fence as to whether to suggest this for 4.11 at this point.  Its
>> probably not something to be backported, but it is a nice bit of cleanup, and
>> removes a particularly gross hack.
> 
> It looks like the commit that made this code vestigal was introduced
> in March 2017?  So we've already had two releases with this flag not
> doing anything, and no ill effects reported.
> 
> I'd be in favor of accepting a patch like this for 4.11, and also for
> backporting it to 4.10 and 4.9

Okay, so:

Release-acked-by: Juergen Gross 


Juergen


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

Re: [Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[George Dunlap]

On Tue, May 8, 2018 at 2:03 PM, Andrew Cooper  wrote:
> c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
> consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
> smap_check logic, it exists only to work around a bug in guest_walk_tables()
> was resolved by the aformentioned commit.
>
> Remove the unused variables and associated infrastructure.
>
> Reported-by: Jason Andryuk 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Juergen Gross 
> CC: Jason Andryuk 
>
> I'm on the fence as to whether to suggest this for 4.11 at this point.  Its
> probably not something to be backported, but it is a nice bit of cleanup, and
> removes a particularly gross hack.

It looks like the commit that made this code vestigal was introduced
in March 2017?  So we've already had two releases with this flag not
doing anything, and no ill effects reported.

I'd be in favor of accepting a patch like this for 4.11, and also for
backporting it to 4.10 and 4.9

 -George

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

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Stefano Stabellini]

On Tue, 8 May 2018, Julien Grall wrote:
> Hi Stefano,
> 
> On 08/05/18 01:11, Stefano Stabellini wrote:
> > On Fri, 6 Apr 2018, Stefano Stabellini wrote:
> > > > > > > 3) Understand how to address dom0. FreeRTOS Dom0 sounds like a
> > > > > > > good
> > > > > > > solution.
> > > > > > > Next step: reach out to Dornerworks and/or others that worked with
> > > > > > > FreeRTOS on Xen before. Figure out whether FreeRTOS is actually a
> > > > > > > suitable solution and what needs to be done to run FreeRTOS as
> > > > > > > Dom0.
> > > > > > 
> > > > > > Some things to check at this stage:
> > > > > > a) I believe there is a safety certified version of FreeRTOS - I
> > > > > > could not
> > > > > > find
> > > > > > much, except for https://www.freertos.org/FreeRTOS-
> > > > > > Plus/Safety_Critical_Certified/SafeRTOS-Safety-Critical-Certification.shtml
> > > > > > -
> > > > > > which describes SafeRTOS a commercial safety certified FreeRTOS and
> > > > > > (mostly) API compliant version of FreeRTOS. Or am I missing
> > > > > > something
> > > > > > here?
> > > > > > b) There is a DomU capable version from Galois (Jonathan Docherty
> > > > > > CC'ed) -
> > > > > > I don't know whether others also have such versions
> > > > > 
> > > > > I ported the version of FreeRTOS that Xilinx distributes with their
> > > > > SDK to
> > > > > run as a domU on the ZUS+ in 2016 and round tripped the change set
> > > > > back to
> > > > > Richard Barry.
> > > > > I've also heard interest in running RTEMS as a guest OS.
> > > > > 
> > > > 
> > > > We've had experience in running QNX in domu, but that was not very
> > > > welcomed by
> > > > BB QSSL folks back then :) They dont really like OSS
> > 
> > One more option (apparently taken by others) is to demonstrate that
> > after boot Dom0 cannot affect the system anymore.
> 
> Can you describe what you mean by "affecting the system anymore".

I don't actually know: I have been told that this is a strategy pursued
by other hypervisors. I guess we'll find out more details as we get more
familiar with the certification requirements.


> > To do that, we would
> > have to get rid of Dom0 entirely after booting all domains, or,
> > deprivilege/restrict its possible effects on the system. Something like
> > turning Dom0 into a DomU after booting all the other guests.
> > This might actually be easier to achieve than "dom0-less" or using
> > FreeRTOS as dom0.
> 
> Other than accessing the hypercall, there are few other way for Dom0 to affect
> the platform:
>   - Dom0 by default has access to all the hardware but the one assigned
> to DomUs. Those hardware may give the possibility to affect the
> platform irreversibly (or even rebooting).
>   - Not all DMA-capable devices are today protected by an IOMMU
> 
> You probably can create something similar to the hardware domain as on x86
> (i.e all the hardware is owned by a separate domain other than Dom0), but then
> it is only shifting the problem.

Yeah, you are right. It looks like turning Dom0 into a DomU is not good
enough. Maybe for this option to be viable we would actually have to
terminate (or pause and never unpause?) dom0 after boot.


> However, you surely need an entity to handle domain crash. You don't want to
> reboot your platform (and therefore you safety critical domain) for a crashed
> UI, right? So how this is going to be handled in your option?

We need to understand the certification requirements better to know the
answer to this. I am guessing that UI crashes are not handled from the
certification point of view -- maybe we only need to demonstrate that
the system is not affected by them?

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

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

[George Dunlap]

On Tue, May 8, 2018 at 4:10 PM, Daniel P. Berrangé  wrote:
>> With my Xen maintainer hat on: I wouldn't feel justified, personally,
>> in asking another project to continue supporting older versions.  If
>> we didn't want to bump our own glib version, we would have to disable
>> "upstream" QEMU (as opposed to Xen's old qemu fork) for older versions
>> of glib.
>
> Or could you say that people need to use a stable version of QEMU ?
> eg users wanting Xen on RHEL-6, can use "upstream" QEMU, but they'll
> need to stick with the 2.12 stable branch version - not use git master
> or future releases. I guess it depends whether you can expect 2.12
> QEMU to carry on working correctly with ongoing Xen changes.

Yes, that's a good point.  In theory older versions of QEMU should in
theory continue working with newer versions of Xen.

Two points about that solution:

1. Our release tarball currently ships with a snapshotted version of a
specific version of QEMU, and if you check out a release tag in our
git repo it will by default clone a specific version of qemu for you.
Users / downstreams would have to disable that and clone their own
version.

2. While in theory all versions should continue to work, in practice
our testing system and the majority of our downstreams use the version
specified by the release, even when they build QEMU separately.  (I
think Debian may be an exception to this rule but I'm not sure.)
Using an older version of QEMU does mean going "off the beaten track"
a bit, increasing slightly the chance of random bugs.

Anyway, from what I can tell, your decision sounds entirely
reasonable, and users and downstreams who don't want to / can't update
glib have a number of options, so I personally don't see any grounds
for objecting or complaining.  Thanks again for the heads-up.

 -George

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

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

[Daniel P . Berrangé]

On Tue, May 08, 2018 at 03:50:49PM +0100, George Dunlap wrote:
> On Fri, May 4, 2018 at 10:00 PM, Daniel P. Berrangé  
> wrote:
> > CC'ing xen-devel in case Xen maintainers have a need for something that
> > will that conflict with this proposal wrt supported build platforms.
> 
> Thanks for the heads-up.  CC'ing some more people who usually have
> opinions on this sort of thing.
> 
> >
> > On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote:
> >> This short series is a followup the discussions around min glib version
> >> when Olaf found we had accidentally increased the min glib by using a
> >> newer function:
> >>
> >>   https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02699.html
> >>
> >> Some key points from that thread
> >>
> >>   - Although we have a docker job that tries to test the min glib
> >> version is adhered to, that's only run post-build, not by Peter's
> >> merge tests, nor by patchew.
> >>
> >>   - The docker min glib test failed to detect the problem anyway
> >> because RHEL had backported the symbol in question.
> >>
> >>   - The docker min glib test only builds with certain configure
> >> options so isn't foolproof.
> >>
> >>   - The modern distros we implicitly care about have way newer glib
> >> than 2.22
> >>
> >>   - Peter's OS-X build host previously had 2.22, but after switching
> >> from fink to homebrew now has 2.56
> >>
> >>   - I suggested following libvirt's lead in writing a policy for how
> >> we pick supported OS targets to inform maintainers when min versions
> >> can be increased.
> >>
> >> This series writes such a document largely based on one I wrote for
> >> libvirt with a few changes, largely around OS-X and *BSD. Note it
> >> is not meant to be an exhaustive list of distros we'll build on, rather
> >> a representative selection, so that we can identify the range of 3rd
> >> party library versions we need to care about. So if your favourite
> >> distro is missing, dont be alarmed, as it probably ships similar
> >> vintage software to one of those listed - if not feel free to suggest
> >> additions.
> >>
> >> Based on that doc and https://repology.org/metapackage/glib/versions,
> >> I identified that we could feasibly set min glib to 2.42. Note that
> >> this would be dropping RHEL-6 as a build host (RHEL-6.0 came out in
> >> 2010 so that's reasonable to drop IMHO). It would still cover 2 major
> >> Debian versions and 2 most recent Ubuntu LTS (16.04, 18.04, but *not*
> >> 14.04). This min glib lets us remove almost all our compat code.
> >>
> >> Most interestingly, thanks tothe new min version being greater than
> >> 2.32, we can now use GLIB_VERSION_MAX_ALLOWED to validate the correct
> >> API usage according to our min version:
> >>
> >>   
> >> https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
> >>
> >> This means that *all* our CI jobs & developer builds will be enforcing
> >> the min version, so means very many more conditionally built features
> >> will get their build validated against min glib version. This would
> >> do a much better job of catching mistakes than our min-glib docker
> >> job, making that obsolete.
> >>
> >> Daniel P. Berrangé (3):
> >>   qemu-doc: provide details of supported build platforms
> >>   glib: bump min required glib library version to 2.42
> >>   glib: enforce the minimum required version and warn about old APIs
> 
> Two responses from me.
> 
> With my Xen maintainer hat on: I wouldn't feel justified, personally,
> in asking another project to continue supporting older versions.  If
> we didn't want to bump our own glib version, we would have to disable
> "upstream" QEMU (as opposed to Xen's old qemu fork) for older versions
> of glib.

Or could you say that people need to use a stable version of QEMU ?
eg users wanting Xen on RHEL-6, can use "upstream" QEMU, but they'll
need to stick with the 2.12 stable branch version - not use git master
or future releases. I guess it depends whether you can expect 2.12
QEMU to carry on working correctly with ongoing Xen changes.

> 
> That said, when we've had similar discussions for our own project,
> we've generally aimed at supporting all major currently-supported
> distros, which would include RHEL 6 / CentOS 6.
> 
> Tailing into that, with my CentOS package maintainer hat on: You said
> that the code in question compiled on RHEL 6 because RH had backported
> the function in question.  Will QEMU continue to actually compile on
> RHEL 6 / CentOS 6?  I.e., will configure be checking for that
> function, or only checking for the version number?

No, the function discussed was just one example of the extra work we
have in trying to maintain compat with old distros, and how even with
testing we sometimes mess up.

This patch is explicitly requiring a much newer glib2 version by doing
a min version check with pkg-config. So with this change applied,
RHEL-6/CentOS-6 

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

[Paolo Bonzini]

On 08/05/2018 16:50, George Dunlap wrote:
> Tailing into that, with my CentOS package maintainer hat on: You said
> that the code in question compiled on RHEL 6 because RH had backported
> the function in question.  Will QEMU continue to actually compile on
> RHEL 6 / CentOS 6?  I.e., will configure be checking for that
> function, or only checking for the version number?

The latter, because we're also dropping all the compatibility code that
allowed QEMU to compile on older glib versions.

Paolo

> If the former, then the CentOS 6 Xen packages won't be affected.  If
> the latter, then at some point I'll have to stop updating the Xen
> version for CentOS 6 -- but as the CentOS 6 EOL is coming up in 2020,
> it shouldn't be too much of a hardship.


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

Re: [Xen-devel] [PATCH 0/3] Document intent for supported build platforms and bump min glib to 2.42

[George Dunlap]

On Fri, May 4, 2018 at 10:00 PM, Daniel P. Berrangé  wrote:
> CC'ing xen-devel in case Xen maintainers have a need for something that
> will that conflict with this proposal wrt supported build platforms.

Thanks for the heads-up.  CC'ing some more people who usually have
opinions on this sort of thing.

>
> On Fri, May 04, 2018 at 05:00:23PM +0100, Daniel P. Berrangé wrote:
>> This short series is a followup the discussions around min glib version
>> when Olaf found we had accidentally increased the min glib by using a
>> newer function:
>>
>>   https://lists.gnu.org/archive/html/qemu-devel/2018-04/msg02699.html
>>
>> Some key points from that thread
>>
>>   - Although we have a docker job that tries to test the min glib
>> version is adhered to, that's only run post-build, not by Peter's
>> merge tests, nor by patchew.
>>
>>   - The docker min glib test failed to detect the problem anyway
>> because RHEL had backported the symbol in question.
>>
>>   - The docker min glib test only builds with certain configure
>> options so isn't foolproof.
>>
>>   - The modern distros we implicitly care about have way newer glib
>> than 2.22
>>
>>   - Peter's OS-X build host previously had 2.22, but after switching
>> from fink to homebrew now has 2.56
>>
>>   - I suggested following libvirt's lead in writing a policy for how
>> we pick supported OS targets to inform maintainers when min versions
>> can be increased.
>>
>> This series writes such a document largely based on one I wrote for
>> libvirt with a few changes, largely around OS-X and *BSD. Note it
>> is not meant to be an exhaustive list of distros we'll build on, rather
>> a representative selection, so that we can identify the range of 3rd
>> party library versions we need to care about. So if your favourite
>> distro is missing, dont be alarmed, as it probably ships similar
>> vintage software to one of those listed - if not feel free to suggest
>> additions.
>>
>> Based on that doc and https://repology.org/metapackage/glib/versions,
>> I identified that we could feasibly set min glib to 2.42. Note that
>> this would be dropping RHEL-6 as a build host (RHEL-6.0 came out in
>> 2010 so that's reasonable to drop IMHO). It would still cover 2 major
>> Debian versions and 2 most recent Ubuntu LTS (16.04, 18.04, but *not*
>> 14.04). This min glib lets us remove almost all our compat code.
>>
>> Most interestingly, thanks tothe new min version being greater than
>> 2.32, we can now use GLIB_VERSION_MAX_ALLOWED to validate the correct
>> API usage according to our min version:
>>
>>   
>> https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MAX-ALLOWED:CAPS
>>
>> This means that *all* our CI jobs & developer builds will be enforcing
>> the min version, so means very many more conditionally built features
>> will get their build validated against min glib version. This would
>> do a much better job of catching mistakes than our min-glib docker
>> job, making that obsolete.
>>
>> Daniel P. Berrangé (3):
>>   qemu-doc: provide details of supported build platforms
>>   glib: bump min required glib library version to 2.42
>>   glib: enforce the minimum required version and warn about old APIs

Two responses from me.

With my Xen maintainer hat on: I wouldn't feel justified, personally,
in asking another project to continue supporting older versions.  If
we didn't want to bump our own glib version, we would have to disable
"upstream" QEMU (as opposed to Xen's old qemu fork) for older versions
of glib.

That said, when we've had similar discussions for our own project,
we've generally aimed at supporting all major currently-supported
distros, which would include RHEL 6 / CentOS 6.

Tailing into that, with my CentOS package maintainer hat on: You said
that the code in question compiled on RHEL 6 because RH had backported
the function in question.  Will QEMU continue to actually compile on
RHEL 6 / CentOS 6?  I.e., will configure be checking for that
function, or only checking for the version number?

If the former, then the CentOS 6 Xen packages won't be affected.  If
the latter, then at some point I'll have to stop updating the Xen
version for CentOS 6 -- but as the CentOS 6 EOL is coming up in 2020,
it shouldn't be too much of a hardship.

 -George

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

Re: [Xen-devel] [PATCH v3 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Mirela Simonovic]

Hi Julien,

On Tue, May 8, 2018 at 4:14 PM, Julien Grall  wrote:
>
>
> On 07/05/18 15:55, Mirela Simonovic wrote:
>>
>> Hi Julien,
>
>
> Hi Mirela,
>
>> On Mon, Apr 30, 2018 at 4:47 PM, Julien Grall 
>> wrote:
>>>
>>> On 27/04/18 18:12, Mirela Simonovic wrote:

printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
 -   4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
 +   4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, vtcr);
  p2m_vmid_allocator_init();
  /* It is not allowed to concatenate a level zero root */
BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
 -setup_virt_paging_one((void *)val);
 -smp_call_function(setup_virt_paging_one, (void *)val, 1);
 +setup_virt_paging_one(NULL);
 +smp_call_function(setup_virt_paging_one, NULL, 1);
 +}
 +
 +static int cpu_virt_paging_callback(
 +struct notifier_block *nfb, unsigned long action, void *hcpu)
>>>
>>>
>>>
>>> The indentation looks wrong.
>>>
>>
>> Editor indented this for me and it looks the same as in other places
>> where a notifier is defined. I did
>> grep -r "struct notifier_block \*nfb,"
>> to check. It looks weird but seems correct
>
>
> Indeed, I am not sure why it is done like that for notifiers. I can't see
> any reason to split like that given the first parameter can fit on the first
> line without hitting the 80 columns.
>
> So I would much prefer if we follow Xen coding style:
>
> static int cpu_virt_paging_callback(struct notifier_block *nfb,
> unsigned long action,
> void *hcpu);
>

Please just one more clarification: why did you split line after 2nd
argument? 3rd argument could fit in 80 chars.
The only coding style I found is in CODING_STYLE file, which doesn't
specify that much details - I'm just trying to understand where to
find more info in order to avoid coding style-related iterations in
future. Is there any other source specifying coding style for Xen?

Thanks,
Mirela

> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH v3 05/10] xen/arm: Setup virtual paging for non-boot CPUs on hotplug/resume

[Julien Grall]

On 07/05/18 15:55, Mirela Simonovic wrote:

Hi Julien,


Hi Mirela,


On Mon, Apr 30, 2018 at 4:47 PM, Julien Grall  wrote:

On 27/04/18 18:12, Mirela Simonovic wrote:

   printk("P2M: %d levels with order-%d root, VTCR 0x%lx\n",
-   4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, val);
+   4 - P2M_ROOT_LEVEL, P2M_ROOT_ORDER, vtcr);
 p2m_vmid_allocator_init();
 /* It is not allowed to concatenate a level zero root */
   BUG_ON( P2M_ROOT_LEVEL == 0 && P2M_ROOT_ORDER > 0 );
-setup_virt_paging_one((void *)val);
-smp_call_function(setup_virt_paging_one, (void *)val, 1);
+setup_virt_paging_one(NULL);
+smp_call_function(setup_virt_paging_one, NULL, 1);
+}
+
+static int cpu_virt_paging_callback(
+struct notifier_block *nfb, unsigned long action, void *hcpu)



The indentation looks wrong.



Editor indented this for me and it looks the same as in other places
where a notifier is defined. I did
grep -r "struct notifier_block \*nfb,"
to check. It looks weird but seems correct


Indeed, I am not sure why it is done like that for notifiers. I can't 
see any reason to split like that given the first parameter can fit on 
the first line without hitting the 80 columns.


So I would much prefer if we follow Xen coding style:

static int cpu_virt_paging_callback(struct notifier_block *nfb,
unsigned long action,
void *hcpu);

Cheers,

--
Julien Grall

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

[Xen-devel] [Patch v3 1/2] x86/smp: count the number of online physical processor in the system

[Chao Gao]

Mainly for the patch behind which relies on 'nr_phys_cpus' to estimate
the time needed for microcode update in the worst case.

Signed-off-by: Chao Gao 
---
v3:
 - new

---
 xen/arch/x86/smpboot.c| 13 +
 xen/include/asm-x86/smp.h |  3 +++
 2 files changed, 16 insertions(+)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 86fa410..c3c3558 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -67,6 +67,8 @@ unsigned int __read_mostly nr_sockets;
 cpumask_t **__read_mostly socket_cpumask;
 static cpumask_t *secondary_socket_cpumask;
 
+unsigned int __read_mostly nr_phys_cpus;
+
 struct cpuinfo_x86 cpu_data[NR_CPUS];
 
 u32 x86_cpu_to_apicid[NR_CPUS] __read_mostly =
@@ -262,6 +264,10 @@ static void set_cpu_sibling_map(int cpu)
 cpumask_set_cpu(cpu, per_cpu(cpu_sibling_mask, cpu));
 }
 
+/* Increase physical processor count when a new cpu comes up */
+if ( cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) == 1 )
+nr_phys_cpus++;
+
 if ( c[cpu].x86_max_cores == 1 )
 {
 cpumask_copy(per_cpu(cpu_core_mask, cpu),
@@ -1156,6 +1162,13 @@ remove_siblinginfo(int cpu)
 cpu_data[sibling].booted_cores--;
 }
 
+/*
+ * Decrease physical processor count when all threads of a physical
+ * processor go down
+ */
+if ( cpumask_weight(per_cpu(cpu_sibling_mask, cpu)) == 1 )
+nr_phys_cpus--;
+
 for_each_cpu(sibling, per_cpu(cpu_sibling_mask, cpu))
 cpumask_clear_cpu(cpu, per_cpu(cpu_sibling_mask, sibling));
 cpumask_clear(per_cpu(cpu_sibling_mask, cpu));
diff --git a/xen/include/asm-x86/smp.h b/xen/include/asm-x86/smp.h
index 4e5f673..910888a 100644
--- a/xen/include/asm-x86/smp.h
+++ b/xen/include/asm-x86/smp.h
@@ -65,6 +65,9 @@ uint32_t get_cur_idle_nums(void);
  */
 extern unsigned int nr_sockets;
 
+/* The number of online physical CPUs in this system */
+extern unsigned int nr_phys_cpus;
+
 void set_nr_sockets(void);
 
 /* Representing HT and core siblings in each socket. */
-- 
1.8.3.1


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

[Xen-devel] [Patch v3 2/2] x86/microcode: Synchronize late microcode loading

[Chao Gao]

This patch ports microcode improvement patches from linux kernel.

Before you read any further: the early loading method is still the
preferred one and you should always do that. The following patch is
improving the late loading mechanism for long running jobs and cloud use
cases.

Gather all cores and serialize the microcode update on them by doing it
one-by-one to make the late update process as reliable as possible and
avoid potential issues caused by the microcode update.

This patch is also in accord with Andrew's suggestion,
"Rendezvous all online cpus in an IPI to apply the patch, and keep the
processors in until all have completed the patch.", in [1].

[1]:https://wiki.xenproject.org/wiki/XenParavirtOps/microcode_update#Run_time_microcode_updates

Signed-off-by: Chao Gao 
Tested-by: Chao Gao 
[linux commit: a5321aec6412b20b5ad15db2d6b916c05349dbff]
[linux commit: bb8c13d61a629276a162c1d2b1a20a815cbcfbb7]
Cc: Kevin Tian 
Cc: Jun Nakajima 
Cc: Ashok Raj 
Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
v3:
 - make the 2nd parameter of wait_for_cpu() unsigned
 - correct the inverted condition in the 2nd if() in do_microcode_update().
 - when waiting for the finish of microcode update, scale the timeout by
 physical processor count other than logical thread count
 - pass the return value of stop_machine_run() to the caller.

v2:
 - Reduce the timeout from 1s to 30ms
 - update microcode with better parallelism; only one logical thread of each
 core tries to take lock and do the update.
 - remove 'error' field from struct microcode_info
 - correct coding style issues
---
 xen/arch/x86/microcode.c | 117 ---
 1 file changed, 91 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/microcode.c b/xen/arch/x86/microcode.c
index 4163f50..355bc6d 100644
--- a/xen/arch/x86/microcode.c
+++ b/xen/arch/x86/microcode.c
@@ -22,6 +22,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -30,15 +31,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+/* By default, wait for 3us */
+#define MICROCODE_DEFAULT_TIMEOUT 3
+
 static module_t __initdata ucode_mod;
 static signed int __initdata ucode_mod_idx;
 static bool_t __initdata ucode_mod_forced;
@@ -187,9 +194,9 @@ static DEFINE_SPINLOCK(microcode_mutex);
 DEFINE_PER_CPU(struct ucode_cpu_info, ucode_cpu_info);
 
 struct microcode_info {
-unsigned int cpu;
+cpumask_t cpus;
+atomic_t cpu_in, cpu_out;
 uint32_t buffer_size;
-int error;
 char buffer[1];
 };
 
@@ -281,24 +288,56 @@ static int microcode_update_cpu(const void *buf, size_t 
size)
 return err;
 }
 
-static long do_microcode_update(void *_info)
+/* Wait for all CPUs to rendezvous with a timeout (us) */
+static int wait_for_cpus(atomic_t *cnt, unsigned int timeout)
 {
-struct microcode_info *info = _info;
-int error;
+unsigned int cpus = num_online_cpus();
 
-BUG_ON(info->cpu != smp_processor_id());
+atomic_inc(cnt);
 
-error = microcode_update_cpu(info->buffer, info->buffer_size);
-if ( error )
-info->error = error;
+while ( atomic_read(cnt) != cpus )
+{
+if ( timeout <= 0 )
+{
+printk("Timeout when waiting for CPUs calling in\n");
+return -EBUSY;
+}
+udelay(1);
+timeout--;
+}
 
-info->cpu = cpumask_next(info->cpu, _online_map);
-if ( info->cpu < nr_cpu_ids )
-return continue_hypercall_on_cpu(info->cpu, do_microcode_update, info);
+return 0;
+}
 
-error = info->error;
-xfree(info);
-return error;
+static int do_microcode_update(void *_info)
+{
+struct microcode_info *info = _info;
+unsigned int cpu = smp_processor_id();
+int ret;
+
+ret = wait_for_cpus(>cpu_in, MICROCODE_DEFAULT_TIMEOUT);
+if ( ret )
+return ret;
+
+/*
+ * Logical threads which set the first bit in cpu_sibling_mask can do
+ * the update. Other sibling threads just await the completion of
+ * microcode update.
+ */
+if ( !cpumask_test_and_set_cpu(
+cpumask_first(per_cpu(cpu_sibling_mask, cpu)), >cpus) )
+ret = microcode_update_cpu(info->buffer, info->buffer_size);
+/*
+ * Increase the wait timeout to a safe value here since we're serializing
+ * the microcode update and that could take a while on a large number of
+ * CPUs. And that is fine as the *actual* timeout will be determined by
+ * the last CPU finished updating and thus cut short
+ */
+if ( wait_for_cpus(>cpu_out, MICROCODE_DEFAULT_TIMEOUT *
+   nr_phys_cpus) )
+panic("Timeout when 

Re: [Xen-devel] Xen and safety certification, Minutes of the meeting on Apr 4th

[Julien Grall]

Hi Stefano,

On 08/05/18 01:11, Stefano Stabellini wrote:

On Fri, 6 Apr 2018, Stefano Stabellini wrote:

3) Understand how to address dom0. FreeRTOS Dom0 sounds like a good
solution.
Next step: reach out to Dornerworks and/or others that worked with
FreeRTOS on Xen before. Figure out whether FreeRTOS is actually a
suitable solution and what needs to be done to run FreeRTOS as Dom0.


Some things to check at this stage:
a) I believe there is a safety certified version of FreeRTOS - I could not
find
much, except for https://www.freertos.org/FreeRTOS-
Plus/Safety_Critical_Certified/SafeRTOS-Safety-Critical-Certification.shtml
-
which describes SafeRTOS a commercial safety certified FreeRTOS and
(mostly) API compliant version of FreeRTOS. Or am I missing something
here?
b) There is a DomU capable version from Galois (Jonathan Docherty CC'ed) -
I don't know whether others also have such versions


I ported the version of FreeRTOS that Xilinx distributes with their SDK to
run as a domU on the ZUS+ in 2016 and round tripped the change set back to
Richard Barry.
I've also heard interest in running RTEMS as a guest OS.



We've had experience in running QNX in domu, but that was not very welcomed by
BB QSSL folks back then :) They dont really like OSS


One more option (apparently taken by others) is to demonstrate that
after boot Dom0 cannot affect the system anymore.


Can you describe what you mean by "affecting the system anymore".


To do that, we would
have to get rid of Dom0 entirely after booting all domains, or,
deprivilege/restrict its possible effects on the system. Something like
turning Dom0 into a DomU after booting all the other guests.
This might actually be easier to achieve than "dom0-less" or using
FreeRTOS as dom0.


Other than accessing the hypercall, there are few other way for Dom0 to 
affect the platform:
	- Dom0 by default has access to all the hardware but the one assigned 
to DomUs. Those hardware may give the possibility to affect the

platform irreversibly (or even rebooting).
- Not all DMA-capable devices are today protected by an IOMMU

You probably can create something similar to the hardware domain as on 
x86 (i.e all the hardware is owned by a separate domain other than 
Dom0), but then it is only shifting the problem.


However, you surely need an entity to handle domain crash. You don't 
want to reboot your platform (and therefore you safety critical domain) 
for a crashed UI, right? So how this is going to be handled in your option?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 0/2] fix several issues in documentation

[George Dunlap]

On 05/08/2018 02:08 PM, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH v3 0/2] fix several issues in 
> documentation"):
>> On 08/05/18 11:25, George Dunlap wrote:
>>> But maybe that's a discussion to have when we open the 4.12 development
>>> window.
>>
>> Another point is to add a call of "make -C docs all" to the OSStest
>> smoke test after my patches have gone in.
> 
> We should add it to all of the tests.

NB you not only have to add that test command, you have to make sure
(for instance) that pdflatex is installed, or you don't trip over these
particular issues.

 -George

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

Re: [Xen-devel] [PATCH RFC 6/7] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2()

[Daniel Kiper]

On Fri, May 04, 2018 at 09:46:33AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53,  wrote:
> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -383,9 +383,13 @@ __efi64_mb2_start:
> >  jmp x86_32_switch
> >
> >  .Lefi_multiboot2_proto:
> > -/* Zero EFI SystemTable and EFI ImageHandle addresses. */
> > +/*
> > + * Zero EFI SystemTable, EFI ImageHandle and
> > + * dom0 kernel module struct addresses.
> > + */
> >  xor %esi,%esi
> >  xor %edi,%edi
> > +xor %r14d,%r14d
> >
> >  /* Skip Multiboot2 information fixed part. */
> >  lea (MB2_fixed_sizeof+MULTIBOOT2_TAG_ALIGN-1)(%rbx),%ecx
> > @@ -423,6 +427,15 @@ __efi64_mb2_start:
> >  cmove   MB2_efi64_ih(%rcx),%rdi
> >  je  .Lefi_mb2_next_tag
> >
> > +/* Get dom0 kernel module struct address from Multiboot2 
> > information. */
> > +cmpl$MULTIBOOT2_TAG_TYPE_MODULE,MB2_tag_type(%rcx)
> > +jne .Lefi_mb2_end
> > +
> > +test%r14d,%r14d
> > +cmovz   %ecx,%r14d
> > +jmp .Lefi_mb2_next_tag
> > +
> > +.Lefi_mb2_end:
> >  /* Is it the end of Multiboot2 information? */
> >  cmpl$MULTIBOOT2_TAG_TYPE_END,MB2_tag_type(%rcx)
> >  je  .Lrun_bs
> > @@ -484,9 +497,12 @@ __efi64_mb2_start:
> >  /* Keep the stack aligned. Do not pop a single item off it. */
> >  mov (%rsp),%rdi
> >
> > +mov %r14d,%edx
> > +
> >  /*
> >   * efi_multiboot2() is called according to System V AMD64 ABI:
> > - *   - IN:  %rdi - EFI ImageHandle, %rsi - EFI SystemTable.
> > + *   - IN: %rdi - EFI ImageHandle, %rsi - EFI SystemTable,
> > + * %rdx - dom0 kernel module struct address.
>
> How come everything further up treats this as a 32-bit quantity only?

According to the Multiboot2 spec the bootloader is not allowed to
put the kernel (xen.gz) and the modules above 4 GiB boundary. And
comment below __efi64_mb2_start label is clear about that.

> > @@ -47,6 +49,7 @@ extern const struct pe_base_relocs {
> >
> >  static void __init efi_arch_relocate_image(unsigned long delta)
> >  {
> > +#if 0
> >  const struct pe_base_relocs *base_relocs;
> >
> >  for ( base_relocs = __base_relocs_start; base_relocs <
> > __base_relocs_end; )
> > @@ -95,6 +98,7 @@ static void __init efi_arch_relocate_image(unsigned long 
> > delta)
> >  }
> >  base_relocs = (const void *)(base_relocs->entries + i + (i & 1));
> >  }
> > +#endif
> >  }
>
> ???

Please forget it. This is just an RFC. It will be fixed in v2.

> > @@ -669,7 +673,9 @@ static bool __init
> > efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable)
> >
> >  static void efi_arch_flush_dcache_area(const void *vaddr, UINTN size) { }
> >
> > -void __init efi_multiboot2(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> > *SystemTable)
> > +void __init efi_multiboot2(EFI_HANDLE ImageHandle,
> > +   EFI_SYSTEM_TABLE *SystemTable,
> > +   multiboot2_tag_module_t *dom0_kernel)
>
> const?

Will do.

Daniel

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

Re: [Xen-devel] [PATCH v2 4/5] doc: correct feature-levelling.pandoc syntax

[George Dunlap]

On 05/08/2018 02:00 PM, Andrew Cooper wrote:
> On 08/05/18 13:58, George Dunlap wrote:
>> On 05/07/2018 11:16 AM, Juergen Gross wrote:
>>> "make -C docs all" fails due to incorrect markdown syntax in
>>> feature-levelling.pandoc. Correct it.
>>>
>>> Signed-off-by: Juergen Gross 
>> I tripped across this one too; and in any case the original code is
>> pretty clearly not right:
>>
>> Reviewed-by: George Dunlap 
> 
> Nack. This perfectly fine and correct markdown.
> 
> Like Juergen, you've got a packaging issue, and need to install
> texlive-latex-extra to resolve it.

Fair enough that there's a packaging issue.  But does it really make
sense to quote it and then code it, rather than just making it code to
begin with?

 -George

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

Re: [Xen-devel] [PATCH v3 0/2] fix several issues in documentation

[Ian Jackson]

Juergen Gross writes ("Re: [Xen-devel] [PATCH v3 0/2] fix several issues in 
documentation"):
> On 08/05/18 11:25, George Dunlap wrote:
> > But maybe that's a discussion to have when we open the 4.12 development
> > window.
> 
> Another point is to add a call of "make -C docs all" to the OSStest
> smoke test after my patches have gone in.

We should add it to all of the tests.

Ian.

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

Re: [Xen-devel] [PATCH v3 2/2] doc: correct intel_psr_cat_cdp.pandoc syntax

[Juergen Gross]

On 08/05/18 14:56, George Dunlap wrote:
> On 05/08/2018 07:47 AM, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> intel_psr_cat_cdp.pandoc. Correct it.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  docs/features/intel_psr_cat_cdp.pandoc | 562 
>> ++---
>>  1 file changed, 300 insertions(+), 262 deletions(-)
>>
>> diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
>> b/docs/features/intel_psr_cat_cdp.pandoc
>> index 04fb256dd9..a076e8a755 100644
>> --- a/docs/features/intel_psr_cat_cdp.pandoc
>> +++ b/docs/features/intel_psr_cat_cdp.pandoc
>> @@ -1,5 +1,5 @@
>>  % Intel Cache Allocation Technology and Code and Data Prioritization 
>> Features
>> -% Revision 1.16
>> +% Revision 1.17
> 
> Do we really need to bump the revision number just to fix markdown
> formatting?

I just followed the example of version 1.16 which was a much smaller
syntactical change.


Juergen

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

[Xen-devel] [PATCH] x86/domain: Drop the only-written smap_check_policy infrastructure

[Andrew Cooper]

c/s 4c5d78a10d "x86/pagewalk: Re-implement the pagetable walker" dropped the
consumer of smap_policy.  Looking at c/s 31ae587e6f which introduced the
smap_check logic, it exists only to work around a bug in guest_walk_tables()
was resolved by the aformentioned commit.

Remove the unused variables and associated infrastructure.

Reported-by: Jason Andryuk 
Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
CC: Jason Andryuk 

I'm on the fence as to whether to suggest this for 4.11 at this point.  Its
probably not something to be backported, but it is a nice bit of cleanup, and
removes a particularly gross hack.
---
 xen/arch/x86/domain.c|  7 +--
 xen/arch/x86/time.c  |  3 +--
 xen/include/asm-x86/domain.h | 13 -
 3 files changed, 2 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 801ac33..4ff3d2f3 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -217,13 +217,9 @@ void dump_pageframe_info(struct domain *d)
 void update_guest_memory_policy(struct vcpu *v,
 struct guest_memory_policy *policy)
 {
-smap_check_policy_t old_smap_policy = v->arch.smap_check_policy;
 bool old_guest_mode = nestedhvm_is_n2(v);
 bool new_guest_mode = policy->nested_guest_mode;
 
-v->arch.smap_check_policy = policy->smap_policy;
-policy->smap_policy = old_smap_policy;
-
 /*
  * When 'v' is in the nested guest mode, all guest copy
  * functions/macros which finally call paging_gva_to_gfn()
@@ -1541,8 +1537,7 @@ void paravirt_ctxt_switch_to(struct vcpu *v)
 bool update_runstate_area(struct vcpu *v)
 {
 bool rc;
-struct guest_memory_policy policy =
-{ .smap_policy = SMAP_CHECK_ENABLED, .nested_guest_mode = false };
+struct guest_memory_policy policy = { .nested_guest_mode = false };
 void __user *guest_handle = NULL;
 
 if ( guest_handle_is_null(runstate_guest(v)) )
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 84c1c0c..c342d00 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1106,8 +1106,7 @@ bool update_secondary_system_time(struct vcpu *v,
   struct vcpu_time_info *u)
 {
 XEN_GUEST_HANDLE(vcpu_time_info_t) user_u = v->arch.time_info_guest;
-struct guest_memory_policy policy =
-{ .smap_policy = SMAP_CHECK_ENABLED, .nested_guest_mode = false };
+struct guest_memory_policy policy = { .nested_guest_mode = false };
 
 if ( guest_handle_is_null(user_u) )
 return true;
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index 8b66096..197f8d6 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -508,12 +508,6 @@ struct pv_vcpu
 struct vcpu_time_info pending_system_time;
 };
 
-typedef enum __packed {
-SMAP_CHECK_HONOR_CPL_AC,/* honor the guest's CPL and AC */
-SMAP_CHECK_ENABLED, /* enable the check */
-SMAP_CHECK_DISABLED,/* disable the check */
-} smap_check_policy_t;
-
 struct arch_vcpu
 {
 /*
@@ -569,12 +563,6 @@ struct arch_vcpu
  * and thus should be saved/restored. */
 bool_t nonlazy_xstate_used;
 
-/*
- * The SMAP check policy when updating runstate_guest(v) and the
- * secondary system time.
- */
-smap_check_policy_t smap_check_policy;
-
 struct vmce vmce;
 
 struct paging_vcpu paging;
@@ -595,7 +583,6 @@ struct arch_vcpu
 
 struct guest_memory_policy
 {
-smap_check_policy_t smap_policy;
 bool nested_guest_mode;
 };
 
-- 
2.1.4


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

Re: [Xen-devel] [PATCH RFC 3/7] xen/x86: Add some addresses to the Multiboot header

[Daniel Kiper]

On Fri, May 04, 2018 at 09:40:51AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53,  wrote:
> > In comparison to ELF the PE format is not supported by the Multiboot
> > protocol. So, if we wish to load xen.efi using this protocol we have
> > to put header_addr, load_addr, load_end_addr, bss_end_addr and
> > entry_addr data into Multiboot header.
>
> Looks fine, but you will want to assure us that this non-ELF method of
> loading is compatible with each and every loader able of loading Xen so
> far.

We have tested internally backport of this patch series and only one
SYSLINUX bug surfaced until now. This is Multiboot implementation
issue which have to be fixed at some point in SYSLINUX. However, it
only manifests with ELF files (e.g. xen.gz) if some ELF addresses are
not in line with addresses in Multiboot header (this happened due to
not intended incorrect .efi.pe.header section placement; patch series
posted here does not have this issue). So, this does not apply to
xen.efi and everything works as expected.

Daniel

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

Re: [Xen-devel] [PATCH v2 4/5] doc: correct feature-levelling.pandoc syntax

[Andrew Cooper]

On 08/05/18 13:58, George Dunlap wrote:
> On 05/07/2018 11:16 AM, Juergen Gross wrote:
>> "make -C docs all" fails due to incorrect markdown syntax in
>> feature-levelling.pandoc. Correct it.
>>
>> Signed-off-by: Juergen Gross 
> I tripped across this one too; and in any case the original code is
> pretty clearly not right:
>
> Reviewed-by: George Dunlap 

Nack. This perfectly fine and correct markdown.

Like Juergen, you've got a packaging issue, and need to install
texlive-latex-extra to resolve it.

~Andrew

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

Re: [Xen-devel] [PATCH v2 4/5] doc: correct feature-levelling.pandoc syntax

[George Dunlap]

On 05/07/2018 11:16 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> feature-levelling.pandoc. Correct it.
> 
> Signed-off-by: Juergen Gross 

I tripped across this one too; and in any case the original code is
pretty clearly not right:

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH v3 2/2] doc: correct intel_psr_cat_cdp.pandoc syntax

[George Dunlap]

On 05/08/2018 07:47 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> intel_psr_cat_cdp.pandoc. Correct it.
> 
> Signed-off-by: Juergen Gross 
> ---
>  docs/features/intel_psr_cat_cdp.pandoc | 562 
> ++---
>  1 file changed, 300 insertions(+), 262 deletions(-)
> 
> diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
> b/docs/features/intel_psr_cat_cdp.pandoc
> index 04fb256dd9..a076e8a755 100644
> --- a/docs/features/intel_psr_cat_cdp.pandoc
> +++ b/docs/features/intel_psr_cat_cdp.pandoc
> @@ -1,5 +1,5 @@
>  % Intel Cache Allocation Technology and Code and Data Prioritization Features
> -% Revision 1.16
> +% Revision 1.17

Do we really need to bump the revision number just to fix markdown
formatting?

Other than that, looks good to me:

Reviewed-by: George Dunlap 

(I'm tempted to bikeshed about removing the ```, but I'll refrain.)

 -George

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

Re: [Xen-devel] [PATCH RFC 2/7] xen/x86: Manually build PE header

[Daniel Kiper]

On Fri, May 04, 2018 at 09:38:03AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53,  wrote:
> > This is the first step to get:
> >   - one binary which can be loaded by the EFI loader,
> > Multiboot and Multiboot2 protocols,
> >   - if we wish, in the future we can drop xen/xen.gz
> > and build xen.efi only,
>
> If anything, generate xen.gz from xen.efi - I see value in the compression,

I generate both xen.gz and xen.efi from xen-syms. Anyway, as I can see
we currently depend more on ELF output than earlier. So, I do not expect
that we would be able to drop xen.gz in the near future.

> but the EFI loader requires an uncompressed binary. And of course we'd have
> to raise the minimal gcc version requirement.
>
> > --- a/xen/arch/x86/Rules.mk
> > +++ b/xen/arch/x86/Rules.mk
> > @@ -7,6 +7,8 @@ CFLAGS += -I$(BASEDIR)/include
> >  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-generic
> >  CFLAGS += -I$(BASEDIR)/include/asm-x86/mach-default
> >  CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFFSET)
> > +CFLAGS += -DXEN_LOAD_ALIGN=XEN_IMG_OFFSET
> > +CFLAGS += -DXEN_FILE_ALIGN=PAGE_SIZE
>
> ??? (Sadly your description talks about benefits only, not about what the
> patch actually does.)

OK, I will improve the commit message. And maybe 
s/XEN_FILE_ALIGN/XEN_EFI_FILE_ALIGN/.
And s/PAGE_SIZE/512/. This is minimal value required by PE spec. I have used
PAGE_SIZE earlier just to be on safe side and in line with the output from ld.

> > --- a/xen/arch/x86/boot/head.S
> > +++ b/xen/arch/x86/boot/head.S
> > @@ -1,3 +1,4 @@
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -44,6 +45,150 @@
> >  .Lmb2ht_init_end\@:
> >  .endm
> >
> > +.section .efi.pe.header, "a", @progbits
> > +
> > +ENTRY(efi_pe_head)
>
> Since you put this in a separate section anyway, why don't you place it in
> a C file (perhaps even of its own) with suitably declared structures?

Really? I thought that it makes sense to have all bootloader headers in
one place. Additionally, C requires struct definition in advance and later
it have to be filled somehow. So, it will be twice as large. Hence, I do not
see much benefit in using C here. OK, maybe it will be a bit more readable.

> > +/*
> > + * Legacy EXE header.
> > + *
> > + * Most of it is copied from binutils package, version 2.28,
> > + * include/coff/pe.h:struct external_PEI_filehdr and
> > + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out().
> > + *
> > + * Page is equal 512 bytes here.
> > + * Paragraph is equal 16 bytes here.
> > + */
> > +.short  0x5a4d /* EXE magic number. */
> > +.short  0x90   /* Bytes on last page 
> > of file. */
> > +.short  0x3/* Pages in file. */
> > +.short  0  /* Relocations. */
> > +.short  0x4/* Size of header in 
> > paragraphs. */
> > +.short  0  /* Minimum extra 
> > paragraphs needed. */
> > +.short  0x /* Maximum extra 
> > paragraphs needed. */
> > +.short  0  /* Initial (relative) 
> > SS value. */
> > +.short  0xb8   /* Initial SP value. */
> > +.short  0  /* Checksum. */
> > +.short  0  /* Initial IP value. */
> > +.short  0  /* Initial (relative) 
> > CS value. */
> > +.short  0x40   /* File address of 
> > relocation table. */
> > +.short  0  /* Overlay number. */
> > +.fill   4, 2, 0/* Reserved words. */
> > +.short  0  /* OEM identifier. */
> > +.short  0  /* OEM information. */
> > +.fill   10, 2, 0   /* Reserved words. */
> > +.long   pe_header - efi_pe_head/* File address of the 
> > PE header. */
> > +
> > +/*
> > + * DOS message.
> > + *
> > + * It is copied from binutils package, version 2.28,
> > + * include/coff/pe.h:struct external_PEI_filehdr and
> > + * bfd/peXXigen.c:_bfd_XXi_only_swap_filehdr_out().
> > + */
> > +.long   0x0eba1f0e
> > +.long   0xcd09b400
> > +.long   0x4c01b821
> > +.long   0x685421cd
> > +.long   0x70207369
> > +.long   0x72676f72
> > +.long   0x63206d61
> > +.long   0x6f6e6e61
> > +.long   0x65622074
> > +.long   0x6e757220
> > +.long   0x206e6920
> > +.long   0x20534f44
> > +.long   0x65646f6d
> > +.long   

Re: [Xen-devel] [RFC PATCH] x86/pagewalk: Honor SMAP_CHECK_DISABLED

[Andrew Cooper]

On 08/05/18 12:38, Jason Andryuk wrote:
> On Mon, May 7, 2018 at 4:05 PM, Andrew Cooper  
> wrote:
>> On 07/05/2018 20:57, Jason Andryuk wrote:
>>> commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
>>> Re-implement the pagetable walker) removed honoring the
>>> smap_check_policy of the running VCPU.  guest_walk_tables is used by
>>> copy_{to,from}_guest for HVMs, so it is called when the hypervisor is
>>> copying data and SMAP is inappropriate to enforce.
>>>
>>> The out-of-tree v4v hypercall copies a domain's source buffer into a
>>> different domain's destination ring.  For an HVM, the kernel makes the
>>> hypercall from ring 0, so the userspace buffer access looks like a SMAP
>>> violation.  In Xen 4.6, v4v could set SMAP_CHECK_DISABLED to avoid this
>>> SMAP failure, but that no longer works since the re-write.
>>>
>>> Signed-off-by: Jason Andryuk 
>> I'm sorry, but no.  It is never appropriate to ignore the guest paging
>> settings.  The correct fix here is in the kernel, to surround the v4v
>> hypercall handler with stac/clac to whitelist userspace accesses.  See
>> the implementation of the privcmd hypercall which already does this.
> Oh, I didn't realize stac/clac are already used with a hypercall.
> Thanks for the pointer.
>
>> If I could go back in time and nack the introduction of
>> smap_check_policy, I would.  As it stands, I'm (slowly) removing its
>> use, and will eventually delete it.
> I think you are close.  It seems to me smap_check_policy is set but not used.

So it is!  Patch incomming.

~Andrew

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

Re: [Xen-devel] [PATCH RFC 1/7] xen: Introduce XEN_COMPILE_POSIX_TIME

[Daniel Kiper]

On Mon, Apr 30, 2018 at 09:56:38AM -0600, Jan Beulich wrote:
> >>> On 08.07.17 at 23:53,  wrote:
> > We need the POSIX time to properly fill the TimeDateStamp field in the PE
> > header.
> >
> > Signed-off-by: Daniel Kiper 
> > ---
> >  xen/Makefile |   14 --
> >  xen/include/xen/compile.h.in |1 +
> >  2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/xen/Makefile b/xen/Makefile
> > index f6a6bc2..2424690 100644
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -6,12 +6,13 @@ export XEN_EXTRAVERSION ?= -unstable$(XEN_VENDORVERSION)
> >  export XEN_FULLVERSION   = 
> > $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
> >  -include xen-version
> >
> > -export XEN_WHOAMI  ?= $(USER)
> > -export XEN_DOMAIN  ?= $(shell ([ -x /bin/dnsdomainname ] && 
> > /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo 
> > [unknown]))
> > -export XEN_BUILD_DATE  ?= $(shell LC_ALL=C date)
> > -export XEN_BUILD_TIME  ?= $(shell LC_ALL=C date +%T)
> > -export XEN_BUILD_HOST  ?= $(shell hostname)
> > -export XEN_CONFIG_EXPERT ?= n
> > +export XEN_WHOAMI  ?= $(USER)
> > +export XEN_DOMAIN  ?= $(shell ([ -x /bin/dnsdomainname ] && 
> > /bin/dnsdomainname) || ([ -x /bin/domainname ] && /bin/domainname || echo 
> > [unknown]))
> > +export XEN_BUILD_DATE  ?= $(shell LC_ALL=C date)
> > +export XEN_BUILD_TIME  ?= $(shell LC_ALL=C date +%T)
> > +export XEN_BUILD_POSIX_TIME?= $(shell LC_ALL=C date +%s)
>
> If you run two independent commands anyway, I don't see why you need to
> obtain the POSIX time here. If you're really after the time stamps agreeing,
> then you should invoke date only once (strictly speaking this also applies to
> the DATE vs TIME invocation, but lets hope people sleep at midnight rather
> than building Xen).

If you wish I can fix this and feed the XEN_BUILD_DATE output into subsequent
date commands.

> > @@ -164,6 +165,7 @@ delete-unfresh-files:
> >  include/xen/compile.h: include/xen/compile.h.in .banner
> > @sed -e 's/@@date@@/$(XEN_BUILD_DATE)/g' \
> > -e 's/@@time@@/$(XEN_BUILD_TIME)/g' \
> > +   -e 's/@@posix_time@@/$(XEN_BUILD_POSIX_TIME)/g' \
>
> In order to fill a PE header, do you really need to make this available in
> compile.h?

Why not? I think that we should have all time related constants defined
in one place. Even if one of them is used just only once.

Daniel

PS Your comments come just in time. I am working on the second version
   of the patches.

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

Re: [Xen-devel] [PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Oleksandr Andrushchenko]

On 05/08/2018 12:34 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:26 PM, Dan Carpenter wrote:

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you


diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct 
xen_drm_front_info *front_info)

  front_info->drm_info = drm_info;
    drm_dev = drm_dev_alloc(_drm_driver, dev);
-    if (!drm_dev) {
-    ret = -ENOMEM;
+    if (IS_ERR(drm_dev)) {
+    ret = PTR_ERR(drm_dev);
  goto fail;
  }
  ___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel





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

Re: [Xen-devel] [PATCH 3/3] drm/xen-front: Fix loop timeout

[Oleksandr Andrushchenko]

On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:28 PM, Dan Carpenter wrote:

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
   */
  while ((xenbus_read_unsigned(front_info->xb_dev->otherend, 
"state",

   XenbusStateUnknown) != XenbusStateInitWait) &&
- to--)
+ --to)
  msleep(10);
    if (!to) {
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel





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

Re: [Xen-devel] [PATCH 2/3] drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling

[Oleksandr Andrushchenko]

On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:27 PM, Dan Carpenter wrote:

The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you
diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c 
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c

index d5705251a0d6..8099cb343ae3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -383,7 +383,7 @@ xen_drm_front_shbuf_alloc(struct 
xen_drm_front_shbuf_cfg *cfg)

    buf = kzalloc(sizeof(*buf), GFP_KERNEL);
  if (!buf)
-    return NULL;
+    return ERR_PTR(-ENOMEM);
    if (cfg->be_alloc)
  buf->ops = _ops;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 8615e8522c7a..378cb7ce0db5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -188,8 +188,8 @@ int xen_drm_front_dbuf_create(struct 
xen_drm_front_info *front_info,

  buf_cfg.be_alloc = front_info->cfg.be_alloc;
    shbuf = xen_drm_front_shbuf_alloc(_cfg);
-    if (!shbuf)
-    return -ENOMEM;
+    if (IS_ERR(shbuf))
+    return PTR_ERR(shbuf);
    ret = dbuf_add_to_list(front_info, shbuf, dbuf_cookie);
  if (ret < 0) {
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel





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

Re: [Xen-devel] [RFC PATCH] x86/pagewalk: Honor SMAP_CHECK_DISABLED

[Jason Andryuk]

On Mon, May 7, 2018 at 4:05 PM, Andrew Cooper  wrote:
> On 07/05/2018 20:57, Jason Andryuk wrote:
>> commit 4c5d78a10dc89427140a50a1df5a0b8e9f073e82 (x86/pagewalk:
>> Re-implement the pagetable walker) removed honoring the
>> smap_check_policy of the running VCPU.  guest_walk_tables is used by
>> copy_{to,from}_guest for HVMs, so it is called when the hypervisor is
>> copying data and SMAP is inappropriate to enforce.
>>
>> The out-of-tree v4v hypercall copies a domain's source buffer into a
>> different domain's destination ring.  For an HVM, the kernel makes the
>> hypercall from ring 0, so the userspace buffer access looks like a SMAP
>> violation.  In Xen 4.6, v4v could set SMAP_CHECK_DISABLED to avoid this
>> SMAP failure, but that no longer works since the re-write.
>>
>> Signed-off-by: Jason Andryuk 
>
> I'm sorry, but no.  It is never appropriate to ignore the guest paging
> settings.  The correct fix here is in the kernel, to surround the v4v
> hypercall handler with stac/clac to whitelist userspace accesses.  See
> the implementation of the privcmd hypercall which already does this.

Oh, I didn't realize stac/clac are already used with a hypercall.
Thanks for the pointer.

> If I could go back in time and nack the introduction of
> smap_check_policy, I would.  As it stands, I'm (slowly) removing its
> use, and will eventually delete it.

I think you are close.  It seems to me smap_check_policy is set but not used.

Regards,
Jason

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

Re: [Xen-devel] migration regression in xen-4.11 and qemu-2.11 and qcow2

[Olaf Hering]

Am Mon, 7 May 2018 17:19:46 +0200
schrieb Olaf Hering :

> What I gathered during debugging so far is that somehow qemu on the receiving 
> side locks a region twice:

After further debugging with many wild printfs:
On the receiving side blockdev_init sets BDRV_O_INACTIVE because 
RUN_STATE_INMIGRATE is true.
BDRV_O_INACTIVE causes bdrv_is_writable to return false.
As a result bdrv_format_default_perms does not set BLK_PERM_WRITE in perms.

On the sending side offset 0xc9 is unlocked on the other fd, which allows 
F_WRLCK to succeed:
2018-05-08T11:20:54.491168Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:20:54.492162Z qemu-system-i386: qemu_lock_fd_test: 28 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:20:54.494752Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.189455Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.190460Z qemu-system-i386: qemu_lock_fd_test: 28 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.192726Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.194298Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.195079Z qemu-system-i386: qemu_lock_fd_test: 28 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.197123Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.199378Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.201108Z qemu-system-i386: qemu_lock_fcntl: 28 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.344335Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.345969Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.346836Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.348937Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.359691Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.360632Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.363221Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.364781Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:05.365607Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:05.367794Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success

It seems on the receiving side some code forgets to unclock offset 0xc9, which 
causes F_WRLCK to fail:
2018-05-08T11:21:52.108809Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:52.112193Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.113028Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:52.115401Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.122037Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.122886Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:52.125189Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.126969Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.127801Z qemu-system-i386: qemu_lock_fd_test: 27 c9 1 
F_WRLCK>F_UNLCK 0 Success
2018-05-08T11:21:52.130109Z qemu-system-i386: qemu_lock_fcntl: 27 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.859199Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:52.862010Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_RDLCK>F_RDLCK 0 Success
2018-05-08T11:21:52.862673Z qemu-system-i386: qemu_lock_fd_test: 39 c9 1 
F_WRLCK>F_RDLCK 0 Success
2018-05-08T11:21:53.112935Z qemu-system-i386: qemu_lock_fd_test: 39 c9 1 
F_WRLCK>F_RDLCK 0 Success
2018-05-08T11:21:53.363246Z qemu-system-i386: qemu_lock_fd_test: 39 c9 1 
F_WRLCK>F_RDLCK 0 Success
2018-05-08T11:21:53.615668Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:53.616426Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_UNLCK>F_UNLCK 0 Success
2018-05-08T11:21:53.616816Z qemu-system-i386: qemu_lock_fcntl: 39 c9 1 
F_UNLCK>F_UNLCK 0 Success


It is unclear why that was never noticed in xen-4.10, qemu-2.9 did not have 
that bug.
Also, if a KVM or Xen guest is migrated should make zero difference for the 
qcow2 driver...


Olaf


pgpWN6QTJ3Lby.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl script to optimise the workflow when using git format-patch with get_maintainer.pl

[Lars Kurth]

On 08/05/2018, 11:48, "Ian Jackson"  wrote:

Lars Kurth writes ("Re: [PATCH for-4.11 v3 1/1] Add new add_maintainers.pl 
script to optimise the workflow when using git format-patch with 
get_maintainer.pl"):
> On 04/05/2018, 18:43, "Ian Jackson"  wrote:
> > +my $patch_prefix = "0"; # Use a 0, such that v* does not get 
picked up
> > +# Obviously this will only work for series 
with
> > +# < 999 patches, which should be fine
> 
> I don't understand the purpose of this:
>  
> This is a bit of a hack! 
> 
> There are several different usage patterns for g-f-p when working on a 
series,
> which result in $patch_dir being used differently. In one case
> a) the user stores patches for multiple series in $patch_dir
> Thus, $patchdir may contain files starting with *, 0001*, ... 
v1-000*, v2-000*

OMG.  It had not even occurred to me that anyone would do that.  But I
think this workflow choice is independent of --reroll-count, which is
mainly used to control patch subject lines.

A workflow where *different* patch series are mingled in the same
directory cannot be supported, because what when their reroll counts
collide?  So these must be different versions (different rerolls) of
the same series.

I suggest the following approach:

Test whether v--cover-letter.patch exists.  If it
does, expect every patch to start with v.  If it does
not, expect simply -cover-letter.patch to exist, and every patch
to start with just the patch number.

So I guess $patch_prefix would be '[0-9]' or "v${reroll_count}-[0-9]".

That makes sense

> > +if ($rerollcount > 0) {
> > +$patch_prefix = "v".$rerollcount;
> > +}
> ...
> > +my $pattern = $patch_dir.'/'.$patch_prefix.'*'.$patch_ext;
> > +print "Then perform:\n".
> > +  "git send-email -to xen-devel\@lists.xenproject.org ".
> > +  $patch_dir.'/'.$patch_prefix."*.patch"."\n";
> 
> What files matching *.patch exist here that should not be processed ?
> If the answer is none then $patch_prefix is redundant, I think ?
> 
> Well, it depends. G-s-m will send everything in $patch_dir.
> I have not checked whether it ignores backups (~ .bak), but I assume it 
does.
> In any case, for scenario a1) and a2) I do need to select which files
> to select in g-s-e.

For the purposes of documentation and informative messages like this
one, I think you can assume workflow (b).  I think workflow (a) is not
to be recommended.

(Anyway, who keeps their g-f-p output directories ?  I don't...)

Sure: I think right now the documentation and messages don't cover this. So if 
we move to the approach you suggested, all should be fine.

> > +if (! -e $get_maintainer) {
> > +die "$tool: The tool requires $get_maintainer\n";
> 
> I still don't like this check.  What if the user specifies an
> implementation of $get_maintainer which is on the PATH ?
> 
> The way get_maintainer.pl works is that it has to be called in the root
> directory of the Xen and Linux trees. There are some checks in the
> tool that throw an error when you call it from another location.

You have misunderstood my remark.  I am not talking about the cwd.

I mean, if the user says --get-maintainer=generic-get-maintaienr
where /usr/bin/generic-get-maintaienr exists.

OK: simply removing the check would just do this

Lars 

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

[Xen-devel] [distros-debian-snapshot test] 74691: regressions - FAIL

[Platform Team regression test user]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail REGR. 
vs. 74656

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail like 74656
 test-amd64-amd64-i386-daily-netboot-pygrub 10 debian-di-install fail like 74656
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 74656
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74656
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
74656
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
74656
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74656
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
74656
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
74656
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
74656
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
74656

baseline version:
 flight   74656

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] xenbits DSA ssh keys to be disabled

[Ian Jackson]

Ian Jackson writes ("xenbits DSA ssh keys to be disabled"):
> DSA keys ("dss") are 1024-bit and not really considered good practice
> any more.  By default in Debian's openssh-server, they are now
> disabled.
> 
> We are going to disable these soon.  Can you please make sure that the
> ssh keys you use to access xenbits are not DSA keys ?  DSA keys start
> with
>   ssh-dss ...
> in your .ssh/authorized_keys.
> 
> After we disable the DSA keys you might have to get us to manually
> update your key, if you don't have another key you can use.

This has now been done.  If you are having trouble, please get in
touch with me or Lars.

Ian.

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

Re: [Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

[George Dunlap]

On 05/08/2018 07:47 AM, Juergen Gross wrote:
> "make -C docs all" fails due to incorrect markdown syntax in
> livepatch.markdown. Correct it.
> 
> Signed-off-by: Juergen Gross 
> Reviewed-by: Konrad Rzeszutek Wilk 

Git complains of trailing whitespace:

Importing patch "doc-correct-livepatch-markdown" ... :69:
trailing whitespace.

:72: trailing whitespace.

:98: trailing whitespace.

:232: trailing whitespace.

:238: trailing whitespace.

Checking patch docs/misc/livepatch.markdown...
Applied patch docs/misc/livepatch.markdown cleanly.
warning: squelched 13 whitespace errors
warning: 18 lines add whitespace errors.


> ---
>  docs/misc/livepatch.markdown | 590 
> ---
>  1 file changed, 273 insertions(+), 317 deletions(-)
> 
> diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
> index 54a6b850cb..a4de44472a 100644
> --- a/docs/misc/livepatch.markdown
> +++ b/docs/misc/livepatch.markdown
> @@ -89,33 +89,27 @@ As example we will assume the hypervisor does not have 
> XSA-132 (see
>  4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
>  the hypervisor with it. The original code looks as so:
>  
> -
> -   48 89 e0  mov%rsp,%rax  
> -   48 25 00 80 ff ff and$0x8000,%rax  
> -
> +   48 89 e0  mov%rsp,%rax
> +   48 25 00 80 ff ff and$0x8000,%rax
>  
>  while the new patched hypervisor would be:
>  
> -
> -   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
> -   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
> -   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
> -   48 89 e0  mov%rsp,%rax  
> -   48 25 00 80 ff ff and$0x8000,%rax  
> -
> +   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
> +   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
> +   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
> +   48 89 e0  mov%rsp,%rax
> +   48 25 00 80 ff ff and$0x8000,%rax
>  
> -This is inside the arch_do_domctl. This new change adds 21 extra
> +This is inside the arch\_do\_domctl. This new change adds 21 extra

It seems like nearly all of these would be better served by making them
code blocks ( `arch_do_domctl`). It is:
* easier to read in text format (one of the  main points of markdown),
* fewer characters to type,
* looks better rendered into html or pdf, and
* doesn't require   tags for < and >.

 -George

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

Re: [Xen-devel] [PATCH v6] x86/mm: Suppresses vm_events caused by page-walks

[Wei Liu]

On Mon, May 07, 2018 at 04:40:12PM +0300, Alexandru Isaila wrote:
> This patch is adding a way to enable/disable inguest pagefault
> events. It introduces the xc_monitor_inguest_pagefault function
> and adds the inguest_pagefault_disabled in the monitor structure.
> This is needed by the introspection so it will only get gla
> faults and not get spammed with other faults.
> In p2m_mem_access_check() we emulate so no event will get sent.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V5:
>   - Add comment for the xc_monitor_inguest_pagefault() func.
> - Add altp2m_write_no_gpt test in xen_access
> ---
>  tools/libxc/include/xenctrl.h   |  7 +++
>  tools/libxc/xc_monitor.c| 14 ++

Acked-by: Wei Liu 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64  broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm   broken
 build-arm64-pvopsbroken
 test-amd64-amd64-xl-qemut-debianhvm-amd64   broken
 test-amd64-i386-libvirt  broken
 test-amd64-amd64-xl-rtds broken
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-install(4) broken REGR. 
vs. 118324
 test-amd64-amd64-xl-qemut-debianhvm-amd64 4 host-install(4) broken REGR. vs. 
118324
 test-amd64-i386-libvirt   4 host-install(4)broken REGR. vs. 118324
 build-arm64   4 host-install(4)broken REGR. vs. 118324
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 118324
 test-armhf-armhf-libvirt-raw 10 debian-di-installfail REGR. vs. 118324
 test-armhf-armhf-xl-arndale  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-credit2  10 debian-install   fail REGR. vs. 118324
 test-armhf-armhf-xl-multivcpu 10 debian-install  fail REGR. vs. 118324
 test-armhf-armhf-xl-vhd  11 guest-start  fail REGR. vs. 118324
 test-armhf-armhf-xl  10 debian-install   fail REGR. vs. 118324

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  4 host-install(4)broken REGR. vs. 118324
 test-armhf-armhf-xl-rtds 10 debian-install   fail REGR. vs. 118324

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-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-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 118324
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 118324
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 118324
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 118324
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 118324
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 118324
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux701e39d05119229b92ecca4add7b7ed2193622c3
baseline version:
 linux5b7d27967dabfb17c21b0d98b29153b9e3ee71e5

Last test of basis   118324  2018-01-25 07:31:24 Z  103 days
Failing since118362  2018-01-26 16:56:17 Z  101 days   81 attempts
Testing same since   122630  2018-05-07 02:20:02 Z1 days1 attempts


3437 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm   

Re: [Xen-devel] [PATCH v2 02/10] x86/HVM: Rename vlapic_read_aligned() to vlapic_reg_read()

[Wei Liu]

On Mon, May 07, 2018 at 04:07:45PM -0500, Janakarajan Natarajan wrote:
> Rename vlapic_read_aligned() to vlapic_reg_read() to make it a pair of
> vlapic_reg_write().
> 
> Signed-off-by: Janakarajan Natarajan 
> ---
>  xen/arch/x86/hvm/vlapic.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 1b9f00a0e4..c9b6461cbf 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -592,7 +592,7 @@ static void vlapic_set_tdcr(struct vlapic *vlapic, 
> unsigned int val)
>  "timer_divisor: %d", vlapic->hw.timer_divisor);
>  }
>  
> -static uint32_t vlapic_read_aligned(const struct vlapic *vlapic,
> +static uint32_t vlapic_reg_read(const struct vlapic *vlapic,
>  unsigned int offset)

Minor issue: indentation needs to be adjusted.

Wei.

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

Re: [Xen-devel] [PATCH] pci: treat class 0 devices as endpoints

[Andrew Cooper]

On 08/05/18 10:33, Roger Pau Monne wrote:
> Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
> class code. Treat them as endpoints, so that they can be handled by
> the IOMMU and properly passed-through to the hardware domain.
>
> Such device has been seen on a Super Micro server, lspci -vv reports:
>
> 00:13.0 Non-VGA unclassified device: Intel Corporation Device a135 (rev 31)
>   Subsystem: Super Micro Computer Inc Device 0931
>   Flags: bus master, fast devsel, latency 0, IRQ 11
>   Memory at df222000 (64-bit, non-prefetchable) [size=4K]
>   Capabilities: [80] Power Management version 3
>
> Arguably this is not a legacy device (since this is a new server), but
> in any case Xen needs to deal with it.
>
> Suggested-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 

FWIW, An updated lspci reports:

00:13.0 Non-VGA unclassified device: Intel Corporation Sunrise Point-H 
Integrated Sensor Hub (rev 31)
Subsystem: Super Micro Computer Inc Device 0931

~Andrew

> ---
> Cc: Jan Beulich 
> ---
>  xen/drivers/passthrough/pci.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
> index 1db69d5b99..c4890a4295 100644
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -927,10 +927,11 @@ enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn)
>  case PCI_CLASS_BRIDGE_HOST:
>  return DEV_TYPE_PCI_HOST_BRIDGE;
>  
> -case 0x: case 0x:
> +case 0x:
>  return DEV_TYPE_PCI_UNKNOWN;
>  }
>  
> +/* NB: treat legacy pre PCI 2.0 devices (class_device == 0) as 
> endpoints. */
>  return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI;
>  }
>  


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

[Xen-devel] [PATCH v3.5 1/2] doc: correct livepatch.markdown syntax

[Andrew Cooper]

From: Juergen Gross 

"make -C docs all" fails due to incorrect markdown syntax in
livepatch.markdown. Correct it.

Signed-off-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 

Misc fixes:
 * Insert real URLs
 * Drop trailing whitespace
 * Consistent alignment and indentation for code blocks and lists
 * Consistent capitalisation
 * Consistent use of `` blocks for command line arguments and function names
 * Rearrange things not to leave  and  in the text

No change in content.  The document now reads rather more consistently in HTML
and PDF form.

Signed-off-by: Andrew Cooper 
---
 docs/misc/livepatch.markdown | 693 ---
 1 file changed, 320 insertions(+), 373 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b85..2bdf871 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -85,53 +85,42 @@ mechanism. See `Trampoline (e9 opcode)` section for more 
details.
 ### Example of trampoline and in-place splicing
 
 As example we will assume the hypervisor does not have XSA-132 (see
-*domctl/sysctl: don't leak hypervisor stack to toolstacks*
-4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
-the hypervisor with it. The original code looks as so:
+[domctl/sysctl: don't leak hypervisor stack to 
toolstacks](http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=4ff3449f0e9d175ceb9551d3f2aecb59273f639d))
+and we would like to binary patch the hypervisor with it. The original code
+looks as so:
 
-
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+48 89 e0  mov%rsp,%rax
+48 25 00 80 ff ff and$0x8000,%rax
 
 while the new patched hypervisor would be:
 
-
-   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
-   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
-   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
+48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
+48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
+48 89 e0  mov%rsp,%rax
+48 25 00 80 ff ff and$0x8000,%rax
 
-This is inside the arch_do_domctl. This new change adds 21 extra
+This is inside the arch\_do\_domctl. This new change adds 21 extra
 bytes of code which alters all the offsets inside the function. To alter
 these offsets and add the extra 21 bytes of code we might not have enough
 space in .text to squeeze this in.
 
 As such we could simplify this problem by only patching the site
-which calls arch_do_domctl:
+which calls arch\_do\_domctl:
 
-
-do_domctl:  
- e8 4b b1 05 00  callq  82d08015fbb9   
-
+do_domctl:
+e8 4b b1 05 00  callq  82d08015fbb9 
 
 with a new address for where the new `arch_do_domctl` would be (this
 area would be allocated dynamically).
 
 Astute readers will wonder what we need to do if we were to patch `do_domctl`
 - which is not called directly by hypervisor but on behalf of the guests via
-the `compat_hypercall_table` and `hypercall_table`.
-Patching the offset in `hypercall_table` for `do_domctl:
-(82d080103079 :)
+the `compat_hypercall_table` and `hypercall_table`.  Patching the offset in
+`hypercall_table` for `do_domctl`:
 
-
-
- 82d08024d490:   79 30  
- 82d08024d492:   10 80 d0 82 ff ff   
-
-
+82d08024d490:   79 30
+82d08024d492:   10 80 d0 82 ff ff
 
 with the new address where the new `do_domctl` is possible. The other
 place where it is used is in `hvm_hypercall64_table` which would need
@@ -139,10 +128,11 @@ to be patched in a similar way. This would require an 
in-place splicing
 of the new virtual address of `arch_do_domctl`.
 
 In summary this example patched the callee of the affected function by
- * allocating memory for the new code to live in,
- * changing the virtual address in all the functions which called the old
+
+ * Allocating memory for the new code to live in,
+ * Changing the virtual address in all the functions which called the old
code (computing the new offset, patching the callq with a new callq).
- * changing the function pointer tables with the new virtual address of
+ * Changing the function pointer tables with the new virtual address of
the function (splicing in the new virtual address). Since this table
resides in the .rodata section we would need to temporarily change the
page table permissions during this part.
@@ -162,21 +152,18 @@ existing function to be patched to jump directly to the 
new code. This
 lessens the locations to be patched to one but it puts pressure on the
 CPU branching logic (I-cache, but it is just one 

Re: [Xen-devel] [PATCH 0/2] vpci/msi: fix updating already bound MSI interrupts

[Roger Pau Monné]

On Tue, May 08, 2018 at 11:30:18AM +0200, Juergen Gross wrote:
> On 08/05/18 11:23, Roger Pau Monne wrote:
> > Hello,
> > 
> > There's a bug in current vpci code for MSI emulation when updating an
> > already bound interrupt. The code will disable and enable the interrupt
> > in order to update the binding, which calls unmap_domain_pirq that
> > disables the global MSI enable flag in the control register.
> > 
> > In order to fix this incorrect behavior introduce a new update helper
> > that should be used to update the bindings of an already enabled group
> > of MSI interrupts.
> > 
> > Thanks, Roger.
> > 
> > Roger Pau Monne (2):
> >   vpci/msi: split code to bind pirq
> >   vpci/msi: fix update of bound MSI interrupts
> > 
> >  xen/arch/x86/hvm/vmsi.c | 96 +
> >  xen/drivers/vpci/msi.c  |  3 +-
> >  xen/include/xen/vpci.h  |  2 +
> >  3 files changed, 71 insertions(+), 30 deletions(-)
> > 
> 
> I guess this is 4.11 material?

Hm, I think so given PVH Dom0 is experimental. OTOH this changes are
to code used exclusively by PVH Dom0, so there's no chance of breaking
anything else. Let's see what the maintainers think and I can Cc you
later if required.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH 3/3] drm/xen-front: Fix loop timeout

[Oleksandr Andrushchenko]

On 05/08/2018 12:28 PM, Dan Carpenter wrote:

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
 */
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
 XenbusStateUnknown) != XenbusStateInitWait) 
&&
-to--)
+--to)
msleep(10);
  
  	if (!to) {

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

[Xen-devel] [PATCH] pci: treat class 0 devices as endpoints

[Roger Pau Monne]

Class 0 devices are legacy pre PCI 2.0 devices that didn't have a
class code. Treat them as endpoints, so that they can be handled by
the IOMMU and properly passed-through to the hardware domain.

Such device has been seen on a Super Micro server, lspci -vv reports:

00:13.0 Non-VGA unclassified device: Intel Corporation Device a135 (rev 31)
Subsystem: Super Micro Computer Inc Device 0931
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at df222000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [80] Power Management version 3

Arguably this is not a legacy device (since this is a new server), but
in any case Xen needs to deal with it.

Suggested-by: Andrew Cooper 
Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
---
 xen/drivers/passthrough/pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c
index 1db69d5b99..c4890a4295 100644
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -927,10 +927,11 @@ enum pdev_type pdev_type(u16 seg, u8 bus, u8 devfn)
 case PCI_CLASS_BRIDGE_HOST:
 return DEV_TYPE_PCI_HOST_BRIDGE;
 
-case 0x: case 0x:
+case 0x:
 return DEV_TYPE_PCI_UNKNOWN;
 }
 
+/* NB: treat legacy pre PCI 2.0 devices (class_device == 0) as endpoints. 
*/
 return pos ? DEV_TYPE_PCIe_ENDPOINT : DEV_TYPE_PCI;
 }
 
-- 
2.17.0


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

Re: [Xen-devel] [PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Oleksandr Andrushchenko]

On 05/08/2018 12:26 PM, Dan Carpenter wrote:

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 


diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct xen_drm_front_info 
*front_info)
front_info->drm_info = drm_info;
  
  	drm_dev = drm_dev_alloc(_drm_driver, dev);

-   if (!drm_dev) {
-   ret = -ENOMEM;
+   if (IS_ERR(drm_dev)) {
+   ret = PTR_ERR(drm_dev);
goto fail;
}
  
___

dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel



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

Re: [Xen-devel] [PATCH v3 0/2] fix several issues in documentation

[Juergen Gross]

On 08/05/18 11:25, George Dunlap wrote:
> On 05/08/2018 07:47 AM, Juergen Gross wrote:
>> Some documents contain invalid pandoc syntax leading to failures when
>> creating PDFs from them, e.g. when calling "make all" in the docs
>> directory.
>>
>> Correct those by using proper lists, code blocks and special character
>> escaping.
> 
> It's probably worth discussing at some point exactly which dialect(s) of
> Markdown we'll support, and what we should call the resulting files.
> 
> I'd be in favor of standardizing on pandoc markdown, and naming all the
> files '.md'.  Then we could, for instance, use `~~~` to indicate longer
> code blocks, rather than four-space indentations (which are slightly
> annoying if you're copy-and-pasting from other code).
> 
> But maybe that's a discussion to have when we open the 4.12 development
> window.

Another point is to add a call of "make -C docs all" to the OSStest
smoke test after my patches have gone in.


Juergen

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

Re: [Xen-devel] [PATCH 0/2] vpci/msi: fix updating already bound MSI interrupts

[Juergen Gross]

On 08/05/18 11:23, Roger Pau Monne wrote:
> Hello,
> 
> There's a bug in current vpci code for MSI emulation when updating an
> already bound interrupt. The code will disable and enable the interrupt
> in order to update the binding, which calls unmap_domain_pirq that
> disables the global MSI enable flag in the control register.
> 
> In order to fix this incorrect behavior introduce a new update helper
> that should be used to update the bindings of an already enabled group
> of MSI interrupts.
> 
> Thanks, Roger.
> 
> Roger Pau Monne (2):
>   vpci/msi: split code to bind pirq
>   vpci/msi: fix update of bound MSI interrupts
> 
>  xen/arch/x86/hvm/vmsi.c | 96 +
>  xen/drivers/vpci/msi.c  |  3 +-
>  xen/include/xen/vpci.h  |  2 +
>  3 files changed, 71 insertions(+), 30 deletions(-)
> 

I guess this is 4.11 material?


Juergen

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

[Xen-devel] [PATCH 3/3] drm/xen-front: Fix loop timeout

[Dan Carpenter]

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
 */
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
 XenbusStateUnknown) != 
XenbusStateInitWait) &&
-to--)
+--to)
msleep(10);
 
if (!to) {

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

[Xen-devel] [PATCH 2/3] drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling

[Dan Carpenter]

The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly.  I've
changed it to always return error pointer consistently.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c 
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index d5705251a0d6..8099cb343ae3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -383,7 +383,7 @@ xen_drm_front_shbuf_alloc(struct xen_drm_front_shbuf_cfg 
*cfg)
 
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
if (cfg->be_alloc)
buf->ops = _ops;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 8615e8522c7a..378cb7ce0db5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -188,8 +188,8 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info 
*front_info,
buf_cfg.be_alloc = front_info->cfg.be_alloc;
 
shbuf = xen_drm_front_shbuf_alloc(_cfg);
-   if (!shbuf)
-   return -ENOMEM;
+   if (IS_ERR(shbuf))
+   return PTR_ERR(shbuf);
 
ret = dbuf_add_to_list(front_info, shbuf, dbuf_cookie);
if (ret < 0) {

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

Re: [Xen-devel] [PATCH v3 0/2] fix several issues in documentation

[George Dunlap]

On 05/08/2018 07:47 AM, Juergen Gross wrote:
> Some documents contain invalid pandoc syntax leading to failures when
> creating PDFs from them, e.g. when calling "make all" in the docs
> directory.
> 
> Correct those by using proper lists, code blocks and special character
> escaping.

It's probably worth discussing at some point exactly which dialect(s) of
Markdown we'll support, and what we should call the resulting files.

I'd be in favor of standardizing on pandoc markdown, and naming all the
files '.md'.  Then we could, for instance, use `~~~` to indicate longer
code blocks, rather than four-space indentations (which are slightly
annoying if you're copy-and-pasting from other code).

But maybe that's a discussion to have when we open the 4.12 development
window.

 -George

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

[Xen-devel] [PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Dan Carpenter]

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct xen_drm_front_info 
*front_info)
front_info->drm_info = drm_info;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
-   if (!drm_dev) {
-   ret = -ENOMEM;
+   if (IS_ERR(drm_dev)) {
+   ret = PTR_ERR(drm_dev);
goto fail;
}
 

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

[Xen-devel] [PATCH 1/2] vpci/msi: split code to bind pirq

[Roger Pau Monne]

And put it in a separate update function. This is required in order to
improve binding of MSI PIRQs when using vPCI.

No functional change.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/vmsi.c | 73 +
 1 file changed, 45 insertions(+), 28 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 900d4f67d4..6e19851439 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -663,6 +663,42 @@ void vpci_msi_arch_mask(struct vpci_msi *msi, const struct 
pci_dev *pdev,
 vpci_mask_pirq(pdev->domain, msi->arch.pirq + entry, mask);
 }
 
+static int vpci_msi_update(const struct pci_dev *pdev, uint32_t data,
+   uint64_t address, unsigned int vectors,
+   unsigned int pirq, uint32_t mask)
+{
+unsigned int i;
+
+ASSERT(pcidevs_locked());
+
+for ( i = 0; i < vectors; i++ )
+{
+uint8_t vector = MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
+uint8_t vector_mask = 0xff >> (8 - fls(vectors) + 1);
+struct xen_domctl_bind_pt_irq bind = {
+.machine_irq = pirq + i,
+.irq_type = PT_IRQ_TYPE_MSI,
+.u.msi.gvec = (vector & ~vector_mask) |
+  ((vector + i) & vector_mask),
+.u.msi.gflags = msi_gflags(data, address, (mask >> i) & 1),
+};
+int rc = pt_irq_create_bind(pdev->domain, );
+
+if ( rc )
+{
+gdprintk(XENLOG_ERR,
+ "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
+ pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn), pirq + i, rc);
+while ( bind.machine_irq-- )
+pt_irq_destroy_bind(pdev->domain, );
+return rc;
+}
+}
+
+return 0;
+}
+
 static int vpci_msi_enable(const struct pci_dev *pdev, uint32_t data,
uint64_t address, unsigned int nr,
paddr_t table_base, uint32_t mask)
@@ -674,7 +710,7 @@ static int vpci_msi_enable(const struct pci_dev *pdev, 
uint32_t data,
 .table_base = table_base,
 .entry_nr = nr,
 };
-unsigned int i, vectors = table_base ? 1 : nr;
+unsigned vectors = table_base ? 1 : nr;
 int rc, pirq = INVALID_PIRQ;
 
 /* Get a PIRQ. */
@@ -690,36 +726,17 @@ static int vpci_msi_enable(const struct pci_dev *pdev, 
uint32_t data,
 return rc;
 }
 
-for ( i = 0; i < vectors; i++ )
+pcidevs_lock();
+rc = vpci_msi_update(pdev, data, address, vectors, pirq, mask);
+if ( rc )
 {
-uint8_t vector = MASK_EXTR(data, MSI_DATA_VECTOR_MASK);
-uint8_t vector_mask = 0xff >> (8 - fls(vectors) + 1);
-struct xen_domctl_bind_pt_irq bind = {
-.machine_irq = pirq + i,
-.irq_type = PT_IRQ_TYPE_MSI,
-.u.msi.gvec = (vector & ~vector_mask) |
-  ((vector + i) & vector_mask),
-.u.msi.gflags = msi_gflags(data, address, (mask >> i) & 1),
-};
-
-pcidevs_lock();
-rc = pt_irq_create_bind(pdev->domain, );
-if ( rc )
-{
-gdprintk(XENLOG_ERR,
- "%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
- pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
- PCI_FUNC(pdev->devfn), pirq + i, rc);
-while ( bind.machine_irq-- )
-pt_irq_destroy_bind(pdev->domain, );
-spin_lock(>domain->event_lock);
-unmap_domain_pirq(pdev->domain, pirq);
-spin_unlock(>domain->event_lock);
-pcidevs_unlock();
-return rc;
-}
+spin_lock(>domain->event_lock);
+unmap_domain_pirq(pdev->domain, pirq);
+spin_unlock(>domain->event_lock);
 pcidevs_unlock();
+return rc;
 }
+pcidevs_unlock();
 
 return pirq;
 }
-- 
2.17.0


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

[Xen-devel] [PATCH 2/2] vpci/msi: fix update of bound MSI interrupts

[Roger Pau Monne]

Current update process of already bound MSI interrupts is wrong
because unmap_domain_pirq calls pci_disable_msi, which disables MSI
interrupts on the device. On the other hand map_domain_pirq doesn't
enable MSI, so the current update process of already enabled MSI
entries is wrong because MSI control bit will be disabled by
unmap_domain_pirq and not re-enabled by map_domain_pirq.

In order to fix this avoid unmapping the PIRQs and just update the
binding of the PIRQ. A new arch helper to do that is introduced.

Note that MSI-X is not affected because unmap_domain_pirq only
disables the MSI enable control bit for the MSI case, for MSI-X the
bit is left untouched by unmap_domain_pirq.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Julien Grall 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/arch/x86/hvm/vmsi.c | 23 +++
 xen/drivers/vpci/msi.c  |  3 +--
 xen/include/xen/vpci.h  |  2 ++
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/vmsi.c b/xen/arch/x86/hvm/vmsi.c
index 6e19851439..8f9f84a6f3 100644
--- a/xen/arch/x86/hvm/vmsi.c
+++ b/xen/arch/x86/hvm/vmsi.c
@@ -699,6 +699,29 @@ static int vpci_msi_update(const struct pci_dev *pdev, 
uint32_t data,
 return 0;
 }
 
+int vpci_msi_arch_update(struct vpci_msi *msi, const struct pci_dev *pdev)
+{
+int rc;
+
+ASSERT(msi->arch.pirq != INVALID_PIRQ);
+
+pcidevs_lock();
+rc = vpci_msi_update(pdev, msi->data, msi->address, msi->vectors,
+ msi->arch.pirq, msi->mask);
+if ( rc )
+{
+spin_lock(>domain->event_lock);
+unmap_domain_pirq(pdev->domain, msi->arch.pirq);
+spin_unlock(>domain->event_lock);
+pcidevs_unlock();
+msi->arch.pirq = INVALID_PIRQ;
+return rc;
+}
+pcidevs_unlock();
+
+return 0;
+}
+
 static int vpci_msi_enable(const struct pci_dev *pdev, uint32_t data,
uint64_t address, unsigned int nr,
paddr_t table_base, uint32_t mask)
diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
index ad26c38a92..8f15ad7bf2 100644
--- a/xen/drivers/vpci/msi.c
+++ b/xen/drivers/vpci/msi.c
@@ -87,8 +87,7 @@ static void update_msi(const struct pci_dev *pdev, struct 
vpci_msi *msi)
 if ( !msi->enabled )
 return;
 
-vpci_msi_arch_disable(msi, pdev);
-if ( vpci_msi_arch_enable(msi, pdev, msi->vectors) )
+if ( vpci_msi_arch_update(msi, pdev) )
 msi->enabled = false;
 }
 
diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
index 72d2225a97..af2b8580ee 100644
--- a/xen/include/xen/vpci.h
+++ b/xen/include/xen/vpci.h
@@ -159,6 +159,8 @@ int __must_check vpci_msi_arch_enable(struct vpci_msi *msi,
   const struct pci_dev *pdev,
   unsigned int vectors);
 void vpci_msi_arch_disable(struct vpci_msi *msi, const struct pci_dev *pdev);
+int __must_check vpci_msi_arch_update(struct vpci_msi *msi,
+  const struct pci_dev *pdev);
 void vpci_msi_arch_init(struct vpci_msi *msi);
 void vpci_msi_arch_print(const struct vpci_msi *msi);
 
-- 
2.17.0


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

[Xen-devel] [PATCH 0/2] vpci/msi: fix updating already bound MSI interrupts

[Roger Pau Monne]

Hello,

There's a bug in current vpci code for MSI emulation when updating an
already bound interrupt. The code will disable and enable the interrupt
in order to update the binding, which calls unmap_domain_pirq that
disables the global MSI enable flag in the control register.

In order to fix this incorrect behavior introduce a new update helper
that should be used to update the bindings of an already enabled group
of MSI interrupts.

Thanks, Roger.

Roger Pau Monne (2):
  vpci/msi: split code to bind pirq
  vpci/msi: fix update of bound MSI interrupts

 xen/arch/x86/hvm/vmsi.c | 96 +
 xen/drivers/vpci/msi.c  |  3 +-
 xen/include/xen/vpci.h  |  2 +
 3 files changed, 71 insertions(+), 30 deletions(-)

-- 
2.17.0


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

Re: [Xen-devel] [OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it work with stretch

[Wei Liu]

On Tue, May 08, 2018 at 10:20:20AM +0100, Wei Liu wrote:
> On Wed, Mar 07, 2018 at 02:45:50PM +, Ian Jackson wrote:
> > Wei Liu writes ("[OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it 
> > work with stretch"):
> > > On the server side, only add oldstyle= and port= on Wheezy and Jessie.
> > > Stretch doesn't support or need those anymore.
> > ...
> > > +if ($cho->{Suite} !~ m/stretch/) {
> > > +configclient_pre_stretch();
> > 
> > This will go wrong in buster.  Your match needs to be inverted and the
> > set of suites too, so that unknown suites get the new behaviour.
> > 
> > It's probably easier to swap the limbs of the if.
> > 
> > > +
> > > +if ($cho->{Suite} !~ m/squeeze|wheezy|jessie/) {
> > > + foreach my $v (@vols) {
> > > + my $nbddev = "nbd$v->{Ix}";
> > > + target_cmd_root($cho, < > > +mkdir -p /dev/$v->{Gho}{Vg}
> > > +if ! test -L $v->{Path}; then ln -s /dev/$nbddev $v->{Path}; fi
> > > +END
> > 
> > This seems to duplicate code in what is now configclient_pre_stretch.
> 
> The snippet is duplicate but there isn't a better way to do it.
> 
> In pre stretch function, the snippet is put into the client config file
> and nbd-client will run it.
> 
> New ndb-client config file is different. I don't think it can run shell
> script anymore.
> 
> > 
> > I also don't understand the logic that says:
> >  - on stretch, do the post-stretch thing, and make this symlink
> >  - on squeeze..jessie, do the pre-stretch thing, and make this symlink
> 
> They are both needed by osstest.
> 
> >  - on sarge, do the pre-stretch thing, and make the symlink twice
> 
> I don't follow. There is no sarge here. I don't think that's relevant
> anymore. If you like, I can list squeeze and sarge in the pre stretch
> listing.
> 

BTW my assumption is anyone who runs osstest in the wild will have at
least wheezy at this point. If you think otherwise, please let me know.

Wei.

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

Re: [Xen-devel] [OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it work with stretch

[Wei Liu]

On Wed, Mar 07, 2018 at 02:45:50PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it work 
> with stretch"):
> > On the server side, only add oldstyle= and port= on Wheezy and Jessie.
> > Stretch doesn't support or need those anymore.
> ...
> > +if ($cho->{Suite} !~ m/stretch/) {
> > +configclient_pre_stretch();
> 
> This will go wrong in buster.  Your match needs to be inverted and the
> set of suites too, so that unknown suites get the new behaviour.
> 
> It's probably easier to swap the limbs of the if.
> 
> > +
> > +if ($cho->{Suite} !~ m/squeeze|wheezy|jessie/) {
> > +   foreach my $v (@vols) {
> > +   my $nbddev = "nbd$v->{Ix}";
> > +   target_cmd_root($cho, < > +mkdir -p /dev/$v->{Gho}{Vg}
> > +if ! test -L $v->{Path}; then ln -s /dev/$nbddev $v->{Path}; fi
> > +END
> 
> This seems to duplicate code in what is now configclient_pre_stretch.

The snippet is duplicate but there isn't a better way to do it.

In pre stretch function, the snippet is put into the client config file
and nbd-client will run it.

New ndb-client config file is different. I don't think it can run shell
script anymore.

> 
> I also don't understand the logic that says:
>  - on stretch, do the post-stretch thing, and make this symlink
>  - on squeeze..jessie, do the pre-stretch thing, and make this symlink

They are both needed by osstest.

>  - on sarge, do the pre-stretch thing, and make the symlink twice

I don't follow. There is no sarge here. I don't think that's relevant
anymore. If you like, I can list squeeze and sarge in the pre stretch
listing.

Wei.

> ?
> 
> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v2 13/19] TestSupport: add dpkg option when installing packages

[Wei Liu]

On Wed, Mar 07, 2018 at 03:11:47PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 13/19] TestSupport: add dpkg option when 
> installing packages"):
> > Upgrading configuration file of nbd-client is controlled by dpkg in
> > stretch. Add dpkg option to keep old configuration file(s).
> 
> I don't think w just want to suppress all these conffile conflicts.
> 
> Instead, perhaps it is possible to install nbd-client first and then
> configure it, avoiding this problem.

AIUI the confi file is installed first because we want nbd-client to
get configured and starts automatically after installation.

It might work if we install nbd-client first, install config file and
then restart the service. I will need to try.

Wei.

> 
> Ian.

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

Re: [Xen-devel] [OSSTEST PATCH v2 08/19] ts-guests-nbd-mirror: use target_{get, put}file_root to transfter cfg

[Wei Liu]

On Wed, Mar 07, 2018 at 03:04:41PM +, Ian Jackson wrote:
> Wei Liu writes ("[OSSTEST PATCH v2 08/19] ts-guests-nbd-mirror: use 
> target_{get,put}file_root to transfter cfg"):
> > The original code used target_cmd_output_root which caused a trailing
> > new line to be deleted, which caused libvirt converter to fail.
> > 
> > It wasn't discovered until now because we appended too many "\n".
> > 
> > Use target_{get,put}file_root to do the job.
> 
> Maybe target_getfilecontents and stashfilecontents and
> target_putfilecontents would be easier and also better ?
> 
> It is usually better to use the existing facilities for inventing
> stash file names because they check for uniqueness.
> 

There is no target_getfilecontents, and the method I used is used
throughout osstest code.

> Or maybe you want to invent `target_getfile_stash' which uses
> open_unique_stashfile and target_getfile, and returns the filename.
> 

Let me see if I can invent something after fixing those more important
issues.

Wei.

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

Re: [Xen-devel] [PATCH] xen: xenbus: Fix a possible data race in xs_request_enter

[Jia-Ju Bai]

On 2018/5/8 15:02, Juergen Gross wrote:

On 08/05/18 05:34, Jia-Ju Bai wrote:

The read operation to "req->type" is protected by
the lock on line 128, but the write operation to
this data on line 118 is not protected by the lock.
Thus, there may exist a data race for "req->type".

To fix this data race, the write operation to "req->type"
should be also protected by the lock.

No, xs_request_enter() is never called for a request already visible to
another thread or processor. So no race exists.


Okay, thanks for your reply.


Best wishes,
Jia-Ju Bai

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

Re: [Xen-devel] [PATCH] xen: xenbus: Fix a possible data race in xs_request_enter

[Juergen Gross]

On 08/05/18 05:34, Jia-Ju Bai wrote:
> The read operation to "req->type" is protected by
> the lock on line 128, but the write operation to
> this data on line 118 is not protected by the lock.
> Thus, there may exist a data race for "req->type".
> 
> To fix this data race, the write operation to "req->type" 
> should be also protected by the lock.

No, xs_request_enter() is never called for a request already visible to
another thread or processor. So no race exists.


Juergen

> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/xen/xenbus/xenbus_xs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
> index 49a3874ae6bb..274cdfee08b1 100644
> --- a/drivers/xen/xenbus/xenbus_xs.c
> +++ b/drivers/xen/xenbus/xenbus_xs.c
> @@ -115,10 +115,10 @@ static uint32_t xs_request_enter(struct xb_req_data 
> *req)
>  {
>   uint32_t rq_id;
>  
> - req->type = req->msg.type;
> -
>   spin_lock(_state_lock);
>  
> + req->type = req->msg.type;
> +
>   while (!xs_state_users && xs_suspend_active) {
>   spin_unlock(_state_lock);
>   wait_event(xs_state_enter_wq, xs_suspend_active == 0);
> 


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

[Xen-devel] [PATCH v3 1/2] doc: correct livepatch.markdown syntax

[Juergen Gross]

"make -C docs all" fails due to incorrect markdown syntax in
livepatch.markdown. Correct it.

Signed-off-by: Juergen Gross 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 docs/misc/livepatch.markdown | 590 ---
 1 file changed, 273 insertions(+), 317 deletions(-)

diff --git a/docs/misc/livepatch.markdown b/docs/misc/livepatch.markdown
index 54a6b850cb..a4de44472a 100644
--- a/docs/misc/livepatch.markdown
+++ b/docs/misc/livepatch.markdown
@@ -89,33 +89,27 @@ As example we will assume the hypervisor does not have 
XSA-132 (see
 4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
 the hypervisor with it. The original code looks as so:
 
-
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
 while the new patched hypervisor would be:
 
-
-   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
-   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
-   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
-   48 89 e0  mov%rsp,%rax  
-   48 25 00 80 ff ff and$0x8000,%rax  
-
+   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)
+   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)
+   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)
+   48 89 e0  mov%rsp,%rax
+   48 25 00 80 ff ff and$0x8000,%rax
 
-This is inside the arch_do_domctl. This new change adds 21 extra
+This is inside the arch\_do\_domctl. This new change adds 21 extra
 bytes of code which alters all the offsets inside the function. To alter
 these offsets and add the extra 21 bytes of code we might not have enough
 space in .text to squeeze this in.
 
 As such we could simplify this problem by only patching the site
-which calls arch_do_domctl:
+which calls arch\_do\_domctl:
 
-
-do_domctl:  
- e8 4b b1 05 00  callq  82d08015fbb9   
-
+do_domctl:
+ e8 4b b1 05 00  callq  82d08015fbb9 
 
 with a new address for where the new `arch_do_domctl` would be (this
 area would be allocated dynamically).
@@ -123,15 +117,13 @@ area would be allocated dynamically).
 Astute readers will wonder what we need to do if we were to patch `do_domctl`
 - which is not called directly by hypervisor but on behalf of the guests via
 the `compat_hypercall_table` and `hypercall_table`.
-Patching the offset in `hypercall_table` for `do_domctl:
-(82d080103079 :)
+Patching the offset in `hypercall_table` for `do_domctl`:
+(82d080103079 do\_domctl:)
 
-
-
- 82d08024d490:   79 30  
- 82d08024d492:   10 80 d0 82 ff ff   
-
-
+
+ 82d08024d490:   79 30
+ 82d08024d492:   10 80 d0 82 ff ff
+
 
 with the new address where the new `do_domctl` is possible. The other
 place where it is used is in `hvm_hypercall64_table` which would need
@@ -164,19 +156,17 @@ CPU branching logic (I-cache, but it is just one 
unconditional jump).
 
 For this example we will assume that the hypervisor has not been compiled
 with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
-for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+for certain HYPERVISOR\_xen\_version sub-ops*) which mem-sets an structure
 in `xen_version` hypercall. This function is not called **anywhere** in
 the hypervisor (it is called by the guest) but referenced in the
 `compat_hypercall_table` and `hypercall_table` (and indirectly called
 from that). Patching the offset in `hypercall_table` for the old
-`do_xen_version` (82d080112f9e )
-
-
- 82d08024b270 :   
- ...  
- 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff  
+`do_xen_version` (82d080112f9e do\_xen\_version)
 
-
+ 82d08024b270 :
+ ...
+ 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff
+
 
 with the new address where the new `do_xen_version` is possible. The other
 place where it is used is in `hvm_hypercall64_table` which would need
@@ -184,21 +174,17 @@ to be patched in a similar way. This would require an 
in-place splicing
 of the new virtual address of `do_xen_version`.
 
 An alternative solution would be to patch insert a trampoline in the
-old `do_xen_version' function to directly jump to the new `do_xen_version`.
+old `do_xen_version` function to directly jump to the new `do_xen_version`.
 
-
- 82d080112f9e do_xen_version:  
- 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax  
- 82d080112fa5:   83 ff 09cmp$0x9,%edi  
- 82d080112fa8:   0f 87 24 05 00 00   ja 82d0801134d2 ; 
do_xen_version+0x534  
-
+ 82d080112f9e do_xen_version:
+ 82d080112f9e:   48 c7 c0 da ff ff ffmov
$0xffda,%rax
+ 82d080112fa5:   83 ff 09  

[Xen-devel] [PATCH v3 2/2] doc: correct intel_psr_cat_cdp.pandoc syntax

[Juergen Gross]

"make -C docs all" fails due to incorrect markdown syntax in
intel_psr_cat_cdp.pandoc. Correct it.

Signed-off-by: Juergen Gross 
---
 docs/features/intel_psr_cat_cdp.pandoc | 562 ++---
 1 file changed, 300 insertions(+), 262 deletions(-)

diff --git a/docs/features/intel_psr_cat_cdp.pandoc 
b/docs/features/intel_psr_cat_cdp.pandoc
index 04fb256dd9..a076e8a755 100644
--- a/docs/features/intel_psr_cat_cdp.pandoc
+++ b/docs/features/intel_psr_cat_cdp.pandoc
@@ -1,5 +1,5 @@
 % Intel Cache Allocation Technology and Code and Data Prioritization Features
-% Revision 1.16
+% Revision 1.17
 
 \clearpage
 
@@ -35,64 +35,71 @@ Technology (CAT) and Code and Data Prioritization (CDP).
 CAT allows an OS or hypervisor to control allocation of a CPU's shared cache
 based on application/domain priority or Class of Service (COS). Each COS is
 configured using capacity bitmasks (CBMs) which represent cache capacity and
-indicate the degree of overlap and isolation between classes. Once CAT is co-
-nfigured, the processor allows access to portions of cache according to the
+indicate the degree of overlap and isolation between classes. Once CAT is
+configured, the processor allows access to portions of cache according to the
 established COS. Intel Xeon processor E5 v4 family (and some others) introduce
 capabilities to configure and make use of the CAT mechanism on the L3 cache.
 Intel Goldmont processor provides support for control over the L2 cache.
 
 Code and Data Prioritization (CDP) Technology is an extension of CAT. CDP
 enables isolation and separate prioritization of code and data fetches to
-the L3 cache in a SW configurable manner, which can enable workload priorit-
-ization and tuning of cache capacity to the characteristics of the workload.
-CDP extends CAT by providing separate code and data masks per Class of Service
-(COS). When SW configures to enable CDP, L3 CAT is disabled.
+the L3 cache in a SW configurable manner, which can enable workload
+prioritization and tuning of cache capacity to the characteristics of the
+workload. CDP extends CAT by providing separate code and data masks per Class
+of Service (COS). When SW configures to enable CDP, L3 CAT is disabled.
 
 # User details
 
 * Feature Enabling:
 
-  Add "psr=cat" to boot line parameter to enable all supported level CAT featu-
-  res. Add "psr=cdp" to enable L3 CDP but disables L3 CAT by SW.
+Add "psr=cat" to boot line parameter to enable all supported level CAT
+features. Add "psr=cdp" to enable L3 CDP but disables L3 CAT by SW.
 
 * xl interfaces:
 
-  1. `psr-cat-show [OPTIONS] domain-id`:
+1. `psr-cat-show [OPTIONS] domain-id`:
 
- Show L2 CAT or L3 CAT/CDP CBM of the domain designated by Xen domain-id.
+Show L2 CAT or L3 CAT/CDP CBM of the domain designated by Xen 
domain-id.
 
- Option `-l`:
- `-l2`: Show cbm for L2 cache.
- `-l3`: Show cbm for L3 cache.
+Option `-l`:
 
- If `-lX` is specified and LX is not supported, print error.
- If no `-l` is specified, level 3 is the default option.
+`-l2`: Show cbm for L2 cache.
 
-  2. `psr-cat-set [OPTIONS] domain-id cbm`:
+`-l3`: Show cbm for L3 cache.
 
- Set L2 CAT or L3 CAT/CDP CBM to the domain designated by Xen domain-id.
+If `-lX` is specified and LX is not supported, print error.
+If no `-l` is specified, level 3 is the default option.
 
- Option `-s`: Specify the socket to process, otherwise all sockets are
- processed.
+2. `psr-cat-set [OPTIONS] domain-id cbm`:
 
- Option `-l`:
- `-l2`: Specify cbm for L2 cache.
- `-l3`: Specify cbm for L3 cache.
+Set L2 CAT or L3 CAT/CDP CBM to the domain designated by Xen domain-id.
 
- If `-lX` is specified and LX is not supported, print error.
- If no `-l` is specified, level 3 is the default option.
+Option `-s`: Specify the socket to process, otherwise all sockets are
+processed.
 
- Option `-c` or `-d`:
- `-c`: Set L3 CDP code cbm.
- `-d`: Set L3 CDP data cbm.
+Option `-l`:
 
-  3. `psr-hwinfo [OPTIONS]`:
+`-l2`: Specify cbm for L2 cache.
 
- Show CMT & L2 CAT & L3 CAT/CDP HW information on every socket.
+`-l3`: Specify cbm for L3 cache.
 
- Option `-m, --cmt`: Show Cache Monitoring Technology (CMT) hardware info.
+If `-lX` is specified and LX is not supported, print error.
+If no `-l` is specified, level 3 is the default option.
 
- Option `-a, --cat`: Show CAT/CDP hardware info.
+Option `-c` or `-d`:
+
+`-c`: Set L3 CDP code cbm.
+
+`-d`: Set L3 CDP data cbm.
+
+3. `psr-hwinfo [OPTIONS]`:
+
+Show CMT & L2 CAT & L3 CAT/CDP HW information on every socket.
+
+Option `-m, --cmt`: Show Cache Monitoring Technology (CMT) hardware
+info.
+
+Option `-a, --cat`: Show CAT/CDP hardware info.
 
 # Technical details
 
@@ -101,305 +108,307 @@ PSR 

[Xen-devel] [PATCH v3 0/2] fix several issues in documentation

[Juergen Gross]

Some documents contain invalid pandoc syntax leading to failures when
creating PDFs from them, e.g. when calling "make all" in the docs
directory.

Correct those by using proper lists, code blocks and special character
escaping.

Changes in V3:
- dropped patches 1 and 2 of V2 as already applied
- complete rework of intel_psr_cat_cdp.pandoc formatting (Andrew)

Changes in V2:
- dropped patches 1 and 4 as already applied
- rebased to current staging
- re-added dropped line in livepatch.markdown (Konrad)

In case the maintainers are fine with my changes I believe the series
should be included in 4.11. So for the series:

Release-acked-by: Juergen Gross 

Juergen Gross (2):
  doc: correct livepatch.markdown syntax
  doc: correct intel_psr_cat_cdp.pandoc syntax

 docs/features/intel_psr_cat_cdp.pandoc | 562 ---
 docs/misc/livepatch.markdown   | 590 +++--
 2 files changed, 573 insertions(+), 579 deletions(-)

-- 
2.13.6


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

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

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qcow2broken
 build-arm64-xsm  broken
 test-amd64-i386-libvirt-xsm  broken
 build-arm64-pvopsbroken
 build-arm64-libvirt  broken
 build-arm64-libvirt   4 host-install(4)broken REGR. vs. 122357
 build-arm64-xsm   4 host-install(4)broken REGR. vs. 122357
 build-arm64-pvops 4 host-install(4)broken REGR. vs. 122357
 test-arm64-arm64-libvirt-xsm broken  in 122615
 test-arm64-arm64-xl-xsm  broken  in 122615
 test-arm64-arm64-xl  broken  in 122615
 test-arm64-arm64-xl4 host-install(4) broken in 122615 REGR. vs. 122357
 test-arm64-arm64-xl-xsm4 host-install(4) broken in 122615 REGR. vs. 122357
 test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 122615 REGR. vs. 
122357

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-xsm   4 host-install(4)  broken pass in 122615
 test-amd64-amd64-xl-qcow2 4 host-install(4)  broken pass in 122615

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