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

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-raw
testid xen-boot

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  f007cad159e99fa2acd3b2e9364fbb32ad28b971
  Bug not present: beaec533fc2701a28a4d667f67c9f59c6e4e0d13
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/113395/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-xl-raw.xen-boot
 --summary-out=tmp/113395.bisection-summary --basis-template=113031 
--blessings=real,real-bisect linux-linus test-amd64-i386-xl-raw xen-boot
Searching for failure / basis pass:
 113353 fail [host=merlot0] / 112277 [host=nobling1] 112271 [host=rimava1] 
112235 [host=italia0] 112182 [host=fiano0] 112083 [host=baroque1] 112049 ok.
Failure / basis pass flights: 113353 / 112049
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest f007cad159e99fa2acd3b2e9364fbb32ad28b971 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
Basis pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
d535d8922f571502252deaf607e82e7475cd1728
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#beaec533fc2701a28a4d667f67c9f59c6e4e0d13-f007cad159e99fa2acd3b2e9364fbb32ad28b971
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#414d069b38ab114b89085e44989bf57604ea86d7-c349189772cec43498b0bec8a84146f10b8937af
 
git://xenbits.xen.org/xen.git#d535d8922f571502252deaf607e82e7475cd1728-70892c317fd56064b09a4b0fcaa0781735e64efc
adhoc-revtuple-generator: tree discontiguous: linux-2.6
adhoc-revtuple-generator: tree discontiguous: qemu-xen
Loaded 1004 nodes in revision graph
Searching for test results:
 112019 [host=rimava0]
 111995 [host=huxelrebe1]
 112049 pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
d535d8922f571502252deaf607e82e7475cd1728
 112083 [host=baroque1]
 112182 [host=fiano0]
 112271 [host=rimava1]
 112235 [host=italia0]
 112277 [host=nobling1]
 113150 fail irrelevant
 113166 fail irrelevant
 113189 fail irrelevant
 113262 fail irrelevant
 113361 pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
39a2a62e5626327f141596ed3e78a55899437e11
 113349 fail f007cad159e99fa2acd3b2e9364fbb32ad28b971 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113354 pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
74d2e11ccfd2fe274ea111686c829534c815a9ae
 113323 fail f007cad159e99fa2acd3b2e9364fbb32ad28b971 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
c349189772cec43498b0bec8a84146f10b8937af 
70892c317fd56064b09a4b0fcaa0781735e64efc
 113348 pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
d535d8922f571502252deaf607e82e7475cd1728
 113357 pass beaec533fc2701a28a4d667f67c9f59c6e4e0d13 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
8051789e982499050680a26febeada7467e18a8d 
414d069b38ab114b89085e44989bf57604ea86d7 
6d3cc2d2667193e0ada89

[Xen-devel] [qemu-upstream-unstable baseline-only test] 72098: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 72098 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72098/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 21 leak-check/check fail REGR. 
vs. 72087

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-credit2   7 xen-boot fail   like 72087
 test-armhf-armhf-xl-multivcpu  7 xen-boot fail  like 72087
 test-armhf-armhf-xl-rtds  7 xen-boot fail   like 72087
 test-armhf-armhf-xl   7 xen-boot fail   like 72087
 test-armhf-armhf-libvirt  7 xen-boot fail   like 72087
 test-armhf-armhf-libvirt-xsm  7 xen-boot fail   like 72087
 test-armhf-armhf-xl-xsm   7 xen-boot fail   like 72087
 test-armhf-armhf-xl-vhd   7 xen-boot fail   like 72087
 test-armhf-armhf-libvirt-raw  7 xen-boot fail   like 72087
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10  fail like 72087
 test-armhf-armhf-xl-midway7 xen-boot fail   like 72087
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 72087
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail 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  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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

version targeted for testing:
 qemuuf5a4c84a5d6b19c154abed4ee0380a6f8fd98c60
baseline version:
 qemuuc349189772cec43498b0bec8a84146f10b8937af

Last test of basis72087  2017-09-09 22:45:25 Z3 days
Testing same since72098  2017-09-12 22:49:46 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Michael S. Tsirkin 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  broken  
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  blocked 
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-arm64-arm64-xl  blocked 
 test-armhf-armhf-xl

Re: [Xen-devel] [stage1-xen PATCH v1 04/10] build/fedora: Add `run` and `components/*` scripts

[Rajiv Ranganath]

On Tue, Sep 12 2017 at 01:36:04 AM, Stefano Stabellini  
wrote:

[...]

> Fortunately, from the stage1-xen code point of view, there is very
> little difference between PVHv2 and PV. Switching from one to the
> other should be a matter of adding one line to the xl config file.

There is a related use-case here that I think will be important to
users.

In stage1-xen we are packaging a Dom-U kernel. When this kernel crashes
we would want to capture its crash log. Depending on the nature of the
issue, users can then work with their own kernel team, vendor (who is
open to supporting LTS kernels) or upstream.

We might also want to consider supporting two LTS kernel versions on a
rolling basis. Users can then use something like labels [1] or
annotations [2] to toggle the kernel version. That way if their
containers start crashing under a newer Dom-U kernel, they can roll back
to a working kernel.

[...]

>> 3. Multiboot2 - One of the reasons why I documented using EFI is because
>> I could not get multiboot2 to work. It looks like the fix for it is on
>> its way. I anticipate using multiboot2 would be easier for users.
>
> That's for the host right? I didn't have that problem, but maybe because
> I am not using Fedora.

That's correct! I ran into this issue on Fedora host.

[...]

> You have a good point. I think we should be clear about the stability
> of the project and the backward compatibility in the README. We should
> openly say that it is still a "preview" and there is no "support" or
> "compatibility" yet.

Sounds good. I'll update README to reflect this.

> Choosing Xen 4.9 should not be seen as a statement of support. I think
> we should choose the Xen version based only on the technical merits.
>
> In the long term it would be great to support multiple stable versions
> and a development version of Xen. As of now, I think it makes sense to
> have an "add-hoc approach": I would use Xen 4.9 just because it is the
> best choice at the moment. Then, I would update to other versions when
> it makes sense, manually. I don't think that building against a changing
> target ("master") is a good idea, because we might end up stumbling
> across confusing and time-consuming bugs that have nothing to do with
> stage1-xen. However, we could pick a random commit on the Xen tree if
> that's convenient for us, because at this stage there is no support
> really. For example, PVCalls will require some tools changes in Xen.
> Once they are upstream, we'll want to update the Xen version to the
> latest with PVCalls support.
>
> Does it make sense?

Yes, it does. I'll switch to xen-4.9, qemu-2.10 and rkt-1.28 in the next
version of the patchset.

Best,
Rajiv

[1] https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
[2] 
https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/

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

Re: [Xen-devel] Booting signed xen.efi through shim

[Daniel Kiper]

Hi Tamas,

On Tue, Sep 12, 2017 at 05:40:35PM -0600, Tamas K Lengyel wrote:
> Hi all,
> for the last couple weeks I've been poking around the options
> available to get Xen booted on a Secureboot enabled box. My goal is to
> extend the chain of trust to the dom0 kernel. According to
> https://wiki.xenproject.org/wiki/Xen_EFI this is something that's
> supposed to be supported out-of-the-box right now via the shim
> protocol. However, when I try to boot a signed xen.efi (4.10 unstable
> head) through shim I get the error "Section 6 is inside image header"

Strange... Could you send more info about your environment?
C compiler type, its version, binutils version, etc. How
did you sign xen.efi? Which tool you used to do that?
Have you seen any warnings or errors during sign?

> and shim refuses to load Xen. OTOH I had been able to boot a
> custom-compiled grub2 from the shim no problem with Secureboot

What do you mean by "custom-compiled grub2"?

> enabled. The signed xen.efi also boots fine with Secureboot enabled if
> booted directly as an EFI application (but then no dom0 verification

IIRC, shim is very picky with PE format. So, anything which is loaded
by EFI loader may not be loaded by shim.

> is done AFAIU). Does anyone have any pointers on what's going on with

Right, only shim provides a such functionality.

> booting through the shim?

I am happy to help but in cases like that I need more info, e.g.: serial
console logs, output from "objdump -x xen/xen.efi" command, etc.

Daniel

PS I am traveling, so, I am reading my emails from time to time.

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

Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

[Rajiv Ranganath]

On Tue, Sep 12 2017 at 04:38:19 AM, Andrew Cooper  
wrote:
> On 11/09/2017 21:20, Stefano Stabellini wrote:

[...]

>> My only concern is about diverging from the upstream Xen codebase. I
>> think the runit scripts should call xencommons underneath. If xencommons
>> cannot cope with being called from runit, we could make changes to
>> xencommon in xen.git to make it so.
>>
>> Otherwise, we will end up in a situation such as:
>> - xen.git changes xencommons
>> - we don't notice
>> - we upgrade Xen version
>> - stage1-xen doesn't work anymore
>>
>> If we used xencommons underneath we would avoid this, and it looks like
>> xencommons could be made to work well with runit.
>
> If possible, upstream Xen should be made to be compatible with runit
> (this would be the ideal case). If not, upstream Xen should contain
> different styles of these files, which are selected between by a
> ./configure option (this is suboptimal, but better than locally
> forking). This offers the greatest chance that updates to one don't
> cause the other to be stale.

I agree that it would be beneficial to have upstream Xen support for
runit. However, runit is packaged differently in every distro.

We work around this issue by packaging our own version of runit [1].
Fedora does not include runit in its repositories. That helps because we
don't have to worry about conflicting with distro packaged runit.

One option to consider is for xen project to package its own version of
runit for major distros (we will have one for Fedora in stage1-xen), and
use that as the basis for runit support.

Since stage1-xen is still under development, maybe we can use runit in
stage1-xen as a testing ground. If things work out well, we can then see
how best to integrate with xencommons or add a configure option.

By then we will also know if there is broader community interest in
having runit support in xen.

As to changes to xencommons breaking stage1-xen, as we get closer to
stable release, we probably will have integration tests to catch this
and many other things! :-)

Best,
Rajiv

[1]: https://github.com/lambda-linux-fedora/runit/tree/ver-2.1.2-1.1.fc25

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

[Xen-devel] [xen-4.9-testing test] 113367: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 112943

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112907
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 112915
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112943
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 112943
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-i386-libvirt-qcow2 12 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
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail 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-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  2cc3d32f40c71cb242477a3f8938074d4fc36829
baseline version:
 xen  d23bcc5ae7342a6c369200cda46cf95bcf854dd0

Last test of basis   112943  2017-08-29 18:16:41 Z   14 days
Testing same since   113367  2017-09-12 13:11:34 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 

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

[Xen-devel] [qemu-mainline test] 113364: regressions - trouble: broken/fail/pass

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw broken
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113302

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  4 host-install(4)  broken pass in 113345
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 113345 
pass in 113364
 test-armhf-armhf-xl-credit2  17 guest-start.2fail in 113345 pass in 113364

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 113302

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 113345 like 
113302
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 113345 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113302
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113302
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113302
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113302
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu04ef33052c205170c92df21ca0b4be4f3b102188
baseline version:
 qemuua6e8c1dacfd37d34542e33600dcc50b7683b735a

Last test of basis   113302  2017-09-11 10:18:16 Z1 days
Testing same since   113345  2017-09-12 00:21:07 Z1 days2 attempts


People who touched revisions under test:
  Mark Cave-Ayland 
  Peter Maydell 
  Philippe Mathieu-Daudé 

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

Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

[Boris Ostrovsky]

On 09/12/2017 08:01 PM, Konrad Rzeszutek Wilk wrote:

On Mon, Sep 11, 2017 at 08:45:02PM -0400, Boris Ostrovsky wrote:



On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote:

Hey,

I've only been able to reproduce this on ARM64 (trying right now ARM32
as well), and not on x86.

If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
enable it and try to load a livepatch it blows up in page_alloc.c:738

This is with origin/staging (d0291f3391)


Can you still reproduce this if you revert 307c3be?


Sadly yes - it still crashes. I didn't capture the serial output.

I honestly think the issue is that on ARM64 the "sleep" loop does not
wake up as often as on x86 (CC-ing Dariof who I believe observed this
with Credit2 and the wakeup.. something) - maybe he remembers the
details. Anyhow my theory is that the pages are not scrubbed at all
when they go in the idle loop as once it goes to sleep - it stays there.



There is no (well, should not be) any timing dependencies in how/whether 
pages are scrubbed. If a page doesn't get scrubbed because someone 
didn't wake up then it should be scrubbed in alloc_heap_pages(). So in 
this case the page is thought to be clean (_PGC_need_scrub is not set), 
but it is not.


Have you tried running a guest (or two), rebooting in a loop?

Another thing to try is to set need_scrub to true in free_heap_pages().

-boris




Ah, see commit 05c52278a7c92bc753d9fe32017e4961012b9f23

Maybe this is related?



-boris


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-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  082fc63f20e827eb0229d520b4ebf54140d9b21b
baseline version:
 xen  16b1414de91b5a82a0996c67f6db3af7d7e32873

Last test of basis   113372  2017-09-12 14:01:13 Z0 days
Testing same since   113384  2017-09-12 23:14:17 Z0 days1 attempts


People who touched revisions under test:
  Bhupinder Thakur 
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=082fc63f20e827eb0229d520b4ebf54140d9b21b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
082fc63f20e827eb0229d520b4ebf54140d9b21b
+ branch=xen-unstable-smoke
+ revision=082fc63f20e827eb0229d520b4ebf54140d9b21b
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x082fc63f20e827eb0229d520b4ebf54140d9b21b = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ :

Re: [Xen-devel] [PATCH v3 14/17] livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn

[Konrad Rzeszutek Wilk]

On Tue, Sep 12, 2017 at 08:54:34AM -0600, Jan Beulich wrote:
> >>> On 12.09.17 at 02:37,  wrote:
> > With this change we can use _do_page_walk() to implement
> > arch_livepatch_lookup_mfn() which can be used to find out
> > vmap virtual addresses (as under x86 virt_to_mfn won't work
> > for vmap, but it does for arm!).
> 
> How about using domain_page_map_to_mfn() instead?

It is very colorfull:

diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 667573c..f90d4c8 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -17,11 +18,18 @@
 mfn_t arch_livepatch_lookup_mfn(unsigned long addr)
 {
 unsigned long cr3 = read_cr3() >> PAGE_SHIFT;
+mfn_t r, r2;
+uint64_t mfn;
 
 if ( !mfn_valid(_mfn(cr3)) )
 return INVALID_MFN;
 
-return _do_page_walk(cr3, addr);
+r = _do_page_walk(cr3, addr);
+mfn = domain_page_map_to_mfn((void *)addr);
+r2 = _mfn(mfn);
+WARN_ON( !mfn_eq(r, r2) );
+
+return r;
 }
 
 void arch_livepatch_revive(void)

..
(XEN) livepatch.c:1450: livepatch: xen_hello_world: CPU1 - IPIing the other 3 
CPUs
Applying xen_hello_world... (XEN) livepatch: xen_hello_world: Applying 1 
functions
(XEN) Assertion 'va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END' failed at 
domain_page.c:349
(XEN) [ Xen-4.10-unstable  x86_64  debug=y   Tainted:  C   ]
(XEN) CPU:1
(XEN) RIP:e008:[] domain_page_map_to_mfn+0x98/0xc8
(XEN) RFLAGS: 00010012   CONTEXT: hypervisor
(XEN) rax: 00d04020   rbx: 0009e400   rcx: 
(XEN) rdx: 00108020   rsi: 9e677000   rdi: 82d08020
(XEN) rbp: 84842789fe18   rsp: 84842789fe18   r8:  8484278d83c0
(XEN) r9:  0004   r10: 0001   r11: 0001
(XEN) r12: 82d08020   r13: 84843e220ab0   r14: 0009b3af6068
(XEN) r15:    cr0: 8005003b   cr4: 000426e0
(XEN) cr3: 9e677000   cr2: 8800078d4328
(XEN) ds: 002b   es: 002b   fs:    gs:    ss: e010   cs: e008
(XEN) Xen code around  (domain_page_map_to_mfn+0x98/0xc8):
(XEN)  48 3d ff ff ff 1f 76 04 <0f> 0b eb fe 48 c1 e7 10 48 c1 ef 1c 48 b8 00 00
(XEN) Xen stack trace from rsp=84842789fe18:
(XEN)84842789fe38 82d080286d05 0001 82d08060b180
(XEN)84842789fe88 82d08021b8b6 84842789fe58 82d0802395a5
(XEN)000d 84843e220bf0 84843e220ab0 84843e220bf0
(XEN)84843e220ab0 0009b3af6068 84842789feb8 82d08021bc38
(XEN)0001 0001 84843e220ab0 84843e220ab0
(XEN)84842789ff08 82d08021befa 84842789fed8 0246
(XEN) 84809e9a5000 0001 84809e6de000
(XEN)84842788c000  84842789fd78 82d08027d4e4
(XEN)8800394b6000 8800394b6002  
(XEN)c95f3e60 0001 0246 
(XEN) 9b810048  810013aa
(XEN)0001 deadbeefdeadf00d deadbeefdeadf00d 0100
(XEN)810013aa e033 0246 c95f3e48
(XEN)e02b 42f0e7438e1e7fc8 06c64a65b2da83f9 6ddeafb16f2755f2
(XEN)97e5fcb4dae8d065 ea89d67a0001 84809e9a5000 01b3b6129680
(XEN)000426e0
(XEN) Xen call trace:
(XEN)[] domain_page_map_to_mfn+0x98/0xc8
(XEN)[] arch_livepatch_lookup_mfn+0x46/0x61
(XEN)[] livepatch.c#livepatch_quiesce+0x45/0x1e4
(XEN)[] livepatch.c#apply_payload+0x3f/0x109
(XEN)[] check_for_livepatch_work+0x1f8/0x395
(XEN)[] domain.c#continue_idle_domain+0x1b/0x22
(XEN) 
(XEN) 
(XEN) 
(XEN) Panic on CPU 1:
(XEN) Assertion 'va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END' failed at 
domain_page.c:349
(XEN) 
(XEN) 
(XEN) Reboot in five seconds...

Which is due to:

287 start = (void *)xen_virt_end;
288 end = (void *)(XEN_VIRT_END - NR_CPUS * PAGE_SIZE);
289 
290 BUG_ON(end <= start);
291 
292 vm_init_type(VMAP_XEN, start, end);


If I modify it a bit:


diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 3432a854dd..a95e95b372 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -344,6 +344,11 @@ unsigned long domain_page_map_to_mfn(const void *ptr)
 pl1e = virt_to_xen_l1e(va);
 BUG_ON(!pl1e);
 }
+else if ( va >= xen_virt_end && va < (XEN_VIRT_END - NR_CPUS * PAGE_SIZE) )
+{
+pl1e = virt_to_xen_l1e(va);
+BUG_ON(!pl1e);
+}
 else
 {
 ASSERT(va >= MAPCACHE_VIRT_START && va < MAPCACHE_VIRT_END);

And then some extra debug:

(XEN) ptr=0x82004000d000, DIRECTMAP_VIRT_START=0x8480, 
VMAP_VIRT_S

Re: [Xen-devel] CONFIG_SCRUB_DEBUG=y + arm64 + livepatch = Xen BUG at page_alloc.c:738

[Konrad Rzeszutek Wilk]

On Mon, Sep 11, 2017 at 08:45:02PM -0400, Boris Ostrovsky wrote:
> 
> 
> On 09/11/2017 07:55 PM, Konrad Rzeszutek Wilk wrote:
> > Hey,
> > 
> > I've only been able to reproduce this on ARM64 (trying right now ARM32
> > as well), and not on x86.
> > 
> > If I compile Xen without CONFIG_SCRUB_DEBUG it works great. But if
> > enable it and try to load a livepatch it blows up in page_alloc.c:738
> > 
> > This is with origin/staging (d0291f3391)
> 
> Can you still reproduce this if you revert 307c3be?

Sadly yes - it still crashes. I didn't capture the serial output.

I honestly think the issue is that on ARM64 the "sleep" loop does not
wake up as often as on x86 (CC-ing Dariof who I believe observed this
with Credit2 and the wakeup.. something) - maybe he remembers the
details. Anyhow my theory is that the pages are not scrubbed at all
when they go in the idle loop as once it goes to sleep - it stays there.

Ah, see commit 05c52278a7c92bc753d9fe32017e4961012b9f23 

Maybe this is related?
> 
> 
> -boris

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf 62ef40c4959e7529053c4f0987e5dafc34880691
baseline version:
 ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc

Last test of basis   113143  2017-09-08 06:17:14 Z4 days
Failing since113156  2017-09-08 19:17:56 Z4 days   25 attempts
Testing same since   113375  2017-09-12 15:46:53 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Brijesh Singh 
  Dandan Bi 
  Hegde Nagaraj P 
  hegdenag 
  Jiaxin Wu 
  Laszlo Ersek 
  Paulo Alcantara 
  Star Zeng 
  Thomas Lamprecht 
  Wu Jiaxin 
  Yonghong Zhu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.

[Konrad Rzeszutek Wilk]

On Tue, Sep 12, 2017 at 08:48:33AM -0600, Jan Beulich wrote:
> >>> On 12.09.17 at 02:37,  wrote:
> > This surfaced due to "xen/livepatch/x86/arm32: Force
> > .livepatch.depends section to be uint32_t aligned." which switched
> > to a different way of including the build-id.
> > 
> > Each livepatch ends with a global:
> > 
> > 30:  1 OBJECT  GLOBAL HIDDEN 7 note_depends
> > 
> > which will cause collision when loading.
> > 
> > One attempted solution was to add in the Makefile stanza:
> >  @sed -i '/unsigned/static unsinged/' $@
> > 
> > But that resulted in the note_depends being omitted from the livepatch
> > (as it was static and not used) which meant we would not have an
> > .livepatch_depends section which we require.
> 
> Did you consider using objcopy's --localize-symbol instead?

Yes, so that note_depends is not globally visible. But that won't help
as hypervisor treats both local and global symbols as global when resolving
them.

That is each of the livepatch has the node_depends in it, and we can't
load xen_hello_world, followed by xen_replace_world test-case (so
stacking them on top of each other) - as both have the same local
symbol.

(This is fixed in "livepatch: Add local and global symbol resolution."
on which you said:

> All the 'GLOBAL' have to be unique per livepatch. But the
> 'LOCAL' can all be the same which means the semantic of 'static'
> on functions and data variables is the right one.

I think this is wrong: Afaict your change results in main image and
patch local symbols to now be treated differently. While this may
indeed help patches which are meant to replace others, it is going
to get in the way if a patch wants to reference a local symbol
already altered (or newly introduced) by a prior one.

(https://www.mail-archive.com/xen-devel@lists.xen.org/msg111710.html)


> 
> Jan
> 

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

[Xen-devel] Booting signed xen.efi through shim

[Tamas K Lengyel]

Hi all,
for the last couple weeks I've been poking around the options
available to get Xen booted on a Secureboot enabled box. My goal is to
extend the chain of trust to the dom0 kernel. According to
https://wiki.xenproject.org/wiki/Xen_EFI this is something that's
supposed to be supported out-of-the-box right now via the shim
protocol. However, when I try to boot a signed xen.efi (4.10 unstable
head) through shim I get the error "Section 6 is inside image header"
and shim refuses to load Xen. OTOH I had been able to boot a
custom-compiled grub2 from the shim no problem with Secureboot
enabled. The signed xen.efi also boots fine with Secureboot enabled if
booted directly as an EFI application (but then no dom0 verification
is done AFAIU). Does anyone have any pointers on what's going on with
booting through the shim?

Thanks,
Tamas

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

Re: [Xen-devel] [PATCH v3 11/13] xen/pvcalls: implement poll command

[Stefano Stabellini]

On Tue, 12 Sep 2017, Stefano Stabellini wrote:
> On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> > On 09/12/2017 06:17 PM, Stefano Stabellini wrote:
> > > On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> > > +
> > > +unsigned int pvcalls_front_poll(struct file *file, struct socket 
> > > *sock,
> > > +poll_table *wait)
> > > +{
> > > + struct pvcalls_bedata *bedata;
> > > + struct sock_mapping *map;
> > > +
> > > + if (!pvcalls_front_dev)
> > > + return POLLNVAL;
> > > + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> > > +
> > > + map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
> >  I just noticed this --- why is it READ_ONCE? Are you concerned that
> >  sk_send_head may change?
> > >>> No, but I wanted to avoid partial reads. A caller could call
> > >>> pvcalls_front_accept and pvcalls_front_poll on newsock almost at the
> > >>> same time (it is probably not the correct way to use the API), I wanted
> > >>> to make sure that "map" is either read correctly, or not read at all.
> > >> How can you have a partial read on a pointer?
> > > I don't think that the compiler makes any promises on translating a
> > > pointer read into a single read instruction. Of couse, I expect gcc to
> > > actually do it without any need for READ/WRITE_ONCE.
> > 
> > READ_ONCE() only guarantees ordering but not atomicity. It resolves (for
> > 64-bit pointers) to
> > 
> > case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
> > 
> > so if compiler was breaking accesses into two then nothing would have
> > prevented it from breaking them here (I don't think volatile declaration
> > would affect this). Moreover, for sizes >8 bytes  READ_ONCE() is
> > __builtin_memcpy() which is definitely not atomic.
> > 
> > So you can't rely on READ_ONCE being atomic from that perspective.
> 
> I thought that READ_ONCE guaranteed atomicity for sizes less or equal to
> the machine word size. It doesn't make any atomicity guarantees for
> sizes >8 bytes.
> 
> 
> > OTOH, I am pretty sure pointer accesses are guaranteed to be atomic. For
> > example, atomic64_read() is READ_ONCE(u64), which (per above) is
> > dereferencing of a 64-bit pointer in C.
> 
> I am happy to remove the READ_ONCE and WRITE_ONCE, if we all think it is
> safe.

Looking at other code in Linux, it seems that they are making this
assumption in many places. I'll remove READ/WRITE_ONCE.

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

Re: [Xen-devel] [PATCH v3 11/13] xen/pvcalls: implement poll command

[Stefano Stabellini]

On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> On 09/12/2017 06:17 PM, Stefano Stabellini wrote:
> > On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> > +
> > +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
> > +  poll_table *wait)
> > +{
> > +   struct pvcalls_bedata *bedata;
> > +   struct sock_mapping *map;
> > +
> > +   if (!pvcalls_front_dev)
> > +   return POLLNVAL;
> > +   bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> > +
> > +   map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
>  I just noticed this --- why is it READ_ONCE? Are you concerned that
>  sk_send_head may change?
> >>> No, but I wanted to avoid partial reads. A caller could call
> >>> pvcalls_front_accept and pvcalls_front_poll on newsock almost at the
> >>> same time (it is probably not the correct way to use the API), I wanted
> >>> to make sure that "map" is either read correctly, or not read at all.
> >> How can you have a partial read on a pointer?
> > I don't think that the compiler makes any promises on translating a
> > pointer read into a single read instruction. Of couse, I expect gcc to
> > actually do it without any need for READ/WRITE_ONCE.
> 
> READ_ONCE() only guarantees ordering but not atomicity. It resolves (for
> 64-bit pointers) to
> 
> case 8: *(__u64 *)res = *(volatile __u64 *)p; break;
> 
> so if compiler was breaking accesses into two then nothing would have
> prevented it from breaking them here (I don't think volatile declaration
> would affect this). Moreover, for sizes >8 bytes  READ_ONCE() is
> __builtin_memcpy() which is definitely not atomic.
> 
> So you can't rely on READ_ONCE being atomic from that perspective.

I thought that READ_ONCE guaranteed atomicity for sizes less or equal to
the machine word size. It doesn't make any atomicity guarantees for
sizes >8 bytes.


> OTOH, I am pretty sure pointer accesses are guaranteed to be atomic. For
> example, atomic64_read() is READ_ONCE(u64), which (per above) is
> dereferencing of a 64-bit pointer in C.

I am happy to remove the READ_ONCE and WRITE_ONCE, if we all think it is
safe.

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

Re: [Xen-devel] [PATCH v3 11/13] xen/pvcalls: implement poll command

[Boris Ostrovsky]

On 09/12/2017 06:17 PM, Stefano Stabellini wrote:
> On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> +
> +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
> +poll_table *wait)
> +{
> + struct pvcalls_bedata *bedata;
> + struct sock_mapping *map;
> +
> + if (!pvcalls_front_dev)
> + return POLLNVAL;
> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> +
> + map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
 I just noticed this --- why is it READ_ONCE? Are you concerned that
 sk_send_head may change?
>>> No, but I wanted to avoid partial reads. A caller could call
>>> pvcalls_front_accept and pvcalls_front_poll on newsock almost at the
>>> same time (it is probably not the correct way to use the API), I wanted
>>> to make sure that "map" is either read correctly, or not read at all.
>> How can you have a partial read on a pointer?
> I don't think that the compiler makes any promises on translating a
> pointer read into a single read instruction. Of couse, I expect gcc to
> actually do it without any need for READ/WRITE_ONCE.

READ_ONCE() only guarantees ordering but not atomicity. It resolves (for
64-bit pointers) to

case 8: *(__u64 *)res = *(volatile __u64 *)p; break;

so if compiler was breaking accesses into two then nothing would have
prevented it from breaking them here (I don't think volatile declaration
would affect this). Moreover, for sizes >8 bytes  READ_ONCE() is
__builtin_memcpy() which is definitely not atomic.

So you can't rely on READ_ONCE being atomic from that perspective.

OTOH, I am pretty sure pointer accesses are guaranteed to be atomic. For
example, atomic64_read() is READ_ONCE(u64), which (per above) is
dereferencing of a 64-bit pointer in C.

-boris



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
113170

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 113170
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113266
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 113266
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 113266
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113266
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113266
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113266
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113266
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 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-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-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-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-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  d0291f3391ab34b34092fcdc56abd8153cbe4579
baseline version:
 xen  70892c317fd56064b09a4b0fcaa0781735e64efc

Last test of basis   113266  2017-09-11 02:02:27 Z1 days
Testing same since   113331  2017-09-11 20:50:03 Z1 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Razvan Cojocaru 
  Wei Liu 

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

[Xen-devel] [qemu-upstream-unstable test] 113359: tolerable FAIL - PUSHED

[osstest service owner]

flight 113359 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/113359/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 113153
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113162
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113162
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113162
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 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
 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-raw 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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuf5a4c84a5d6b19c154abed4ee0380a6f8fd98c60
baseline version:
 qemuuc349189772cec43498b0bec8a84146f10b8937af

Last test of basis   113162  2017-09-09 10:03:39 Z3 days
Testing same since   113301  2017-09-11 10:16:50 Z1 days3 attempts


People who touched revisions under test:
  Anthony PERARD 
  Michael S. Tsirkin 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-

Re: [Xen-devel] [PATCH v3 11/13] xen/pvcalls: implement poll command

[Stefano Stabellini]

On Tue, 12 Sep 2017, Boris Ostrovsky wrote:
> >>> +
> >>> +unsigned int pvcalls_front_poll(struct file *file, struct socket *sock,
> >>> +poll_table *wait)
> >>> +{
> >>> + struct pvcalls_bedata *bedata;
> >>> + struct sock_mapping *map;
> >>> +
> >>> + if (!pvcalls_front_dev)
> >>> + return POLLNVAL;
> >>> + bedata = dev_get_drvdata(&pvcalls_front_dev->dev);
> >>> +
> >>> + map = (struct sock_mapping *) READ_ONCE(sock->sk->sk_send_head);
> >> I just noticed this --- why is it READ_ONCE? Are you concerned that
> >> sk_send_head may change?
> > No, but I wanted to avoid partial reads. A caller could call
> > pvcalls_front_accept and pvcalls_front_poll on newsock almost at the
> > same time (it is probably not the correct way to use the API), I wanted
> > to make sure that "map" is either read correctly, or not read at all.
> 
> How can you have a partial read on a pointer?

I don't think that the compiler makes any promises on translating a
pointer read into a single read instruction. Of couse, I expect gcc to
actually do it without any need for READ/WRITE_ONCE.

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

Re: [Xen-devel] [PATCH v2 0/7] xen/arm: Clean-up traps.c

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> Hi all,
> 
> xen/arch/arm/traps.c is beginning to get very big. This series is moving out
> the co-processor and sysreg emulation in separate files. This will avoid to
> grow traps.c when adding more registers emulation (coming soon).
> 
> A branch with this series has been pushed:
> 
> https://xenbits.xen.org/git-http/people/julieng/xen-unstable.git
> branch cleanup-traps-v2

I committed the first two patches. Only a couple of very minor comments
on the rest.


> Cheers,
> 
> Cc: volodymyr_babc...@epam.com
> 
> Julien Grall (7):
>   xen/arm: traps: Re-order the includes alphabetically
>   xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h
>   xen/arm: traps: Export a bunch of helpers to handle emulation
>   xen/arm: Move sysreg emulation outside of traps.c
>   xen/arm: Move co-processor emulation outside of traps.c
>   xen/arm: Move sysregs.h in arm64 sub-directory
>   xen/arm: Limit the scope of cpregs.h
> 
>  xen/arch/arm/Makefile  |   1 +
>  xen/arch/arm/arm64/Makefile|   1 +
>  xen/arch/arm/arm64/vsysreg.c   | 229 ++
>  xen/arch/arm/domain.c  |   2 +-
>  xen/arch/arm/smp.c |   1 -
>  xen/arch/arm/traps.c   | 702 
> ++---
>  xen/arch/arm/vcpreg.c  | 452 +++
>  xen/arch/arm/vgic-v3.c |   1 +
>  xen/arch/arm/vtimer.c  |   2 +
>  xen/include/asm-arm/arm32/processor.h  |   2 +
>  xen/include/asm-arm/arm32/traps.h  |  13 +
>  xen/include/asm-arm/arm64/processor.h  |   2 +
>  xen/include/asm-arm/{ => arm64}/sysregs.h  |  10 +-
>  xen/include/asm-arm/arm64/traps.h  |  18 +
>  xen/include/asm-arm/percpu.h   |   1 -
>  xen/include/asm-arm/processor.h|   2 -
>  xen/include/asm-arm/traps.h|  44 ++
>  xen/{arch/arm => include/asm-arm}/vtimer.h |   0
>  18 files changed, 811 insertions(+), 672 deletions(-)
>  create mode 100644 xen/arch/arm/arm64/vsysreg.c
>  create mode 100644 xen/arch/arm/vcpreg.c
>  create mode 100644 xen/include/asm-arm/arm32/traps.h
>  rename xen/include/asm-arm/{ => arm64}/sysregs.h (98%)
>  create mode 100644 xen/include/asm-arm/arm64/traps.h
>  create mode 100644 xen/include/asm-arm/traps.h
>  rename xen/{arch/arm => include/asm-arm}/vtimer.h (100%)
> 
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 7/7] xen/arm: Limit the scope of cpregs.h

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> Currently, cpregs.h is included in pretty much every files even for
> arm64. However, the only use for arm64 is when emulating co-processors.
> 
> For arm32, all users of processor.h expect cpregs.h to be included in
> order to access co-processors. So move the inclusion in
> asm-arm/arm32/processor.h.
> 
> cpregs.h will also be directly included in the co-processors emulation
> to accommodate arm64.
> 
> Signed-off-by: Julien Grall 

I can see that the patch works and does what you describe, but what is
the benefit? OK, we remove #include  from
asm-arm/processor.h, but then we have to add it to vcpreg.c, vgic-v3.c,
vtimer.c, and arm32/processor.h. Is there a long term benefit? What
prompted you into writing this patch?


> ---
> Changes in v2:
> - Update commit message
> ---
>  xen/arch/arm/smp.c| 1 -
>  xen/arch/arm/vcpreg.c | 1 +
>  xen/arch/arm/vgic-v3.c| 1 +
>  xen/arch/arm/vtimer.c | 2 ++
>  xen/include/asm-arm/arm32/processor.h | 2 ++
>  xen/include/asm-arm/percpu.h  | 1 -
>  xen/include/asm-arm/processor.h   | 1 -
>  7 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/arm/smp.c b/xen/arch/arm/smp.c
> index e7df0874d6..554f4992e6 100644
> --- a/xen/arch/arm/smp.c
> +++ b/xen/arch/arm/smp.c
> @@ -1,6 +1,5 @@
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/vcpreg.c b/xen/arch/arm/vcpreg.c
> index f3b08403fb..e363183ba8 100644
> --- a/xen/arch/arm/vcpreg.c
> +++ b/xen/arch/arm/vcpreg.c
> @@ -18,6 +18,7 @@
>  
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
> index cbeac28b28..a0cf993d13 100644
> --- a/xen/arch/arm/vgic-v3.c
> +++ b/xen/arch/arm/vgic-v3.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
> index 9c7e8f441c..0460962f08 100644
> --- a/xen/arch/arm/vtimer.c
> +++ b/xen/arch/arm/vtimer.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Check if regs is allowed access, user_gate is tail end of a
> diff --git a/xen/include/asm-arm/arm32/processor.h 
> b/xen/include/asm-arm/arm32/processor.h
> index 68cc82147e..fb330812af 100644
> --- a/xen/include/asm-arm/arm32/processor.h
> +++ b/xen/include/asm-arm/arm32/processor.h
> @@ -1,6 +1,8 @@
>  #ifndef __ASM_ARM_ARM32_PROCESSOR_H
>  #define __ASM_ARM_ARM32_PROCESSOR_H
>  
> +#include 
> +
>  #define ACTLR_CAXX_SMP  (1<<6)
>  
>  #ifndef __ASSEMBLY__
> diff --git a/xen/include/asm-arm/percpu.h b/xen/include/asm-arm/percpu.h
> index 7968532462..cdf64e0f77 100644
> --- a/xen/include/asm-arm/percpu.h
> +++ b/xen/include/asm-arm/percpu.h
> @@ -4,7 +4,6 @@
>  #ifndef __ASSEMBLY__
>  
>  #include 
> -#include 
>  #if defined(CONFIG_ARM_32)
>  # include 
>  #elif defined(CONFIG_ARM_64)
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index d791c12c9c..cd45e5f48f 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -1,7 +1,6 @@
>  #ifndef __ASM_ARM_PROCESSOR_H
>  #define __ASM_ARM_PROCESSOR_H
>  
> -#include 
>  #ifndef __ASSEMBLY__
>  #include 
>  #endif
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 6/7] xen/arm: Move sysregs.h in arm64 sub-directory

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> sysregs.h contains only code protected by #ifdef CONFIG_ARM_64. Move it
> in arm64 sub-directory to reflect that and remove the #ifdef.
> 
> At the same time, fixup the guards.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/include/asm-arm/arm64/processor.h |  2 ++
>  xen/include/asm-arm/{ => arm64}/sysregs.h | 10 +++---
>  xen/include/asm-arm/processor.h   |  1 -
>  3 files changed, 5 insertions(+), 8 deletions(-)
>  rename xen/include/asm-arm/{ => arm64}/sysregs.h (98%)
> 
> diff --git a/xen/include/asm-arm/arm64/processor.h 
> b/xen/include/asm-arm/arm64/processor.h
> index 24f836b023..c18ab7203d 100644
> --- a/xen/include/asm-arm/arm64/processor.h
> +++ b/xen/include/asm-arm/arm64/processor.h
> @@ -3,6 +3,8 @@
>  
>  #include 
>  
> +#include 
> +
>  #ifndef __ASSEMBLY__
>  
>  /* Anonymous union includes both 32- and 64-bit names (e.g., r0/x0). */
> diff --git a/xen/include/asm-arm/sysregs.h 
> b/xen/include/asm-arm/arm64/sysregs.h
> similarity index 98%
> rename from xen/include/asm-arm/sysregs.h
> rename to xen/include/asm-arm/arm64/sysregs.h
> index 887368e248..084d2a1e5d 100644
> --- a/xen/include/asm-arm/sysregs.h
> +++ b/xen/include/asm-arm/arm64/sysregs.h
> @@ -1,7 +1,5 @@
> -#ifndef __ASM_ARM_SYSREGS_H
> -#define __ASM_ARM_SYSREGS_H
> -
> -#ifdef CONFIG_ARM_64
> +#ifndef __ASM_ARM_ARM64_SYSREGS_H
> +#define __ASM_ARM_ARM64_SYSREGS_H
>  
>  #include 
>  
> @@ -168,9 +166,7 @@
>  #define ICH_AP1R2_EL2 __AP1Rx_EL2(2)
>  #define ICH_AP1R3_EL2 __AP1Rx_EL2(3)
>  
> -#endif
> -
> -#endif
> +#endif /* _ASM_ARM_ARM64_SYSREGS_H */
>  
>  /*
>   * Local variables:
> diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
> index 9f7a42f86b..d791c12c9c 100644
> --- a/xen/include/asm-arm/processor.h
> +++ b/xen/include/asm-arm/processor.h
> @@ -2,7 +2,6 @@
>  #define __ASM_ARM_PROCESSOR_H
>  
>  #include 
> -#include 
>  #ifndef __ASSEMBLY__
>  #include 
>  #endif
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 5/7] xen/arm: Move co-processor emulation outside of traps.c

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> The co-processor emulation is quite big and pretty much standalone. Move
> it in a separate file to shrink down the size of traps.c.
> 
> At the same time remove unused cpregs.h.
> 
> No functional change.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/Makefile   |   1 +
>  xen/arch/arm/traps.c| 421 -
>  xen/arch/arm/vcpreg.c   | 451 
> 
>  xen/include/asm-arm/traps.h |   8 +
>  4 files changed, 460 insertions(+), 421 deletions(-)
>  create mode 100644 xen/arch/arm/vcpreg.c
> 
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 282d2c2949..17bff98033 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -45,6 +45,7 @@ obj-y += smpboot.o
>  obj-y += sysctl.o
>  obj-y += time.o
>  obj-y += traps.o
> +obj-y += vcpreg.o
>  obj-y += vgic.o
>  obj-y += vgic-v2.o
>  obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index f00aa48892..5e6bc3173f 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -38,7 +38,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -1875,426 +1874,6 @@ void handle_ro_raz(struct cpu_user_regs *regs,
>  advance_pc(regs, hsr);
>  }
>  
> -static void do_cp15_32(struct cpu_user_regs *regs,
> -   const union hsr hsr)
> -{
> -const struct hsr_cp32 cp32 = hsr.cp32;
> -int regidx = cp32.reg;
> -struct vcpu *v = current;
> -
> -if ( !check_conditional_instr(regs, hsr) )
> -{
> -advance_pc(regs, hsr);
> -return;
> -}
> -
> -switch ( hsr.bits & HSR_CP32_REGS_MASK )
> -{
> -/*
> - * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
> - *
> - * ARMv7 (DDI 0406C.b): B4.1.22
> - * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
> - */
> -case HSR_CPREG32(CNTP_CTL):
> -case HSR_CPREG32(CNTP_TVAL):
> -if ( !vtimer_emulate(regs, hsr) )
> -return inject_undef_exception(regs, hsr);
> -break;
> -
> -/*
> - * HCR_EL2.TACR / HCR.TAC
> - *
> - * ARMv7 (DDI 0406C.b): B1.14.6
> - * ARMv8 (DDI 0487A.d): G6.2.1
> - */
> -case HSR_CPREG32(ACTLR):
> -if ( psr_mode_is_user(regs) )
> -return inject_undef_exception(regs, hsr);
> -if ( cp32.read )
> -set_user_reg(regs, regidx, v->arch.actlr);
> -break;
> -
> -/*
> - * MDCR_EL2.TPM
> - *
> - * ARMv7 (DDI 0406C.b): B1.14.17
> - * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61
> - *
> - * Unhandled:
> - *PMEVCNTR
> - *PMEVTYPER
> - *PMCCFILTR
> - *
> - * MDCR_EL2.TPMCR
> - *
> - * ARMv7 (DDI 0406C.b): B1.14.17
> - * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62
> - *
> - * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR.
> - */
> -/* We could trap ID_DFR0 and tell the guest we don't support
> - * performance monitoring, but Linux doesn't check the ID_DFR0.
> - * Therefore it will read PMCR.
> - *
> - * We tell the guest we have 0 counters. Unfortunately we must
> - * always support PMCCNTR (the cyle counter): we just RAZ/WI for all
> - * PM register, which doesn't crash the kernel at least
> - */
> -case HSR_CPREG32(PMUSERENR):
> -/* RO at EL0. RAZ/WI at EL1 */
> -if ( psr_mode_is_user(regs) )
> -return handle_ro_raz(regs, regidx, cp32.read, hsr, 0);
> -else
> -return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
> -case HSR_CPREG32(PMINTENSET):
> -case HSR_CPREG32(PMINTENCLR):
> -/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
> -return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
> -case HSR_CPREG32(PMCR):
> -case HSR_CPREG32(PMCNTENSET):
> -case HSR_CPREG32(PMCNTENCLR):
> -case HSR_CPREG32(PMOVSR):
> -case HSR_CPREG32(PMSWINC):
> -case HSR_CPREG32(PMSELR):
> -case HSR_CPREG32(PMCEID0):
> -case HSR_CPREG32(PMCEID1):
> -case HSR_CPREG32(PMCCNTR):
> -case HSR_CPREG32(PMXEVTYPER):
> -case HSR_CPREG32(PMXEVCNTR):
> -case HSR_CPREG32(PMOVSSET):
> -/*
> - * Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
> - * emulate that register as 0 above.
> - */
> -return handle_raz_wi(regs, regidx, cp32.read, hsr, 1);
> -
> -/*
> - * HCR_EL2.TIDCP
> - *
> - * ARMv7 (DDI 0406C.b): B1.14.3
> - * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
> - *
> - *  - CRn==c9, opc1=={0-7}, CRm=={c0-c2, c5-c8}, opc2=={0-7}
> - *(Cache and TCM lockdown registers)
> - *  - CRn==c10, opc1=={0-7}, CRm=={c0, c1, c4, c8}, opc2=={0-7}
> - *(VMSA CP15 c10 registers)
> - *  - CRn==c11, opc1=={0-7}, CRm=={c0-c8, c15}, opc2=={0-7}
> - *(VMSA 

Re: [Xen-devel] [PATCH v2 4/7] xen/arm: Move sysreg emulation outside of traps.c

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> The sysreg emulation is 64-bit specific and surrounded by #ifdef. Move
> them in a separate file arm/arm64/vsysreg.c to shrink down a bit traps.c
> 
> No functional change.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/arm64/Makefile   |   1 +
>  xen/arch/arm/arm64/vsysreg.c  | 229 
> ++
>  xen/arch/arm/traps.c  | 198 
>  xen/include/asm-arm/arm64/traps.h |   3 +
>  4 files changed, 233 insertions(+), 198 deletions(-)
>  create mode 100644 xen/arch/arm/arm64/vsysreg.c
> 
> diff --git a/xen/arch/arm/arm64/Makefile b/xen/arch/arm/arm64/Makefile
> index 149b6b3901..718fe44455 100644
> --- a/xen/arch/arm/arm64/Makefile
> +++ b/xen/arch/arm/arm64/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_LIVEPATCH) += livepatch.o
>  obj-y += smpboot.o
>  obj-y += traps.o
>  obj-y += vfp.o
> +obj-y += vsysreg.o
> diff --git a/xen/arch/arm/arm64/vsysreg.c b/xen/arch/arm/arm64/vsysreg.c
> new file mode 100644
> index 00..c57ac12503
> --- /dev/null
> +++ b/xen/arch/arm/arm64/vsysreg.c
> @@ -0,0 +1,229 @@
> +/*
> + * xen/arch/arm/arm64/sysreg.c
> + *
> + * Emulate system registers trapped.
> + *
> + * Copyright (c) 2011 Citrix Systems.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void do_sysreg(struct cpu_user_regs *regs,
> +   const union hsr hsr)
> +{
> +int regidx = hsr.sysreg.reg;
> +struct vcpu *v = current;
> +
> +switch ( hsr.bits & HSR_SYSREG_REGS_MASK )
> +{
> +/*
> + * HCR_EL2.TACR
> + *
> + * ARMv8 (DDI 0487A.d): D7.2.1
> + */
> +case HSR_SYSREG_ACTLR_EL1:
> +if ( psr_mode_is_user(regs) )
> +return inject_undef_exception(regs, hsr);
> +if ( hsr.sysreg.read )
> +set_user_reg(regs, regidx, v->arch.actlr);
> +break;
> +
> +/*
> + * MDCR_EL2.TDRA
> + *
> + * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
> + */
> +case HSR_SYSREG_MDRAR_EL1:
> +return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 1);
> +
> +/*
> + * MDCR_EL2.TDOSA
> + *
> + * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
> + *
> + * Unhandled:
> + *OSLSR_EL1
> + *DBGPRCR_EL1
> + */
> +case HSR_SYSREG_OSLAR_EL1:
> +return handle_wo_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +case HSR_SYSREG_OSDLR_EL1:
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +
> +/*
> + * MDCR_EL2.TDA
> + *
> + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59
> + *
> + * Unhandled:
> + *MDCCINT_EL1
> + *DBGDTR_EL0
> + *DBGDTRRX_EL0
> + *DBGDTRTX_EL0
> + *OSDTRRX_EL1
> + *OSDTRTX_EL1
> + *OSECCR_EL1
> + *DBGCLAIMSET_EL1
> + *DBGCLAIMCLR_EL1
> + *DBGAUTHSTATUS_EL1
> + */
> +case HSR_SYSREG_MDSCR_EL1:
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +case HSR_SYSREG_MDCCSR_EL0:
> +/*
> + * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate 
> that
> + * register as RAZ/WI above. So RO at both EL0 and EL1.
> + */
> +return handle_ro_raz(regs, regidx, hsr.sysreg.read, hsr, 0);
> +HSR_SYSREG_DBG_CASES(DBGBVR):
> +HSR_SYSREG_DBG_CASES(DBGBCR):
> +HSR_SYSREG_DBG_CASES(DBGWVR):
> +HSR_SYSREG_DBG_CASES(DBGWCR):
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +
> +/*
> + * MDCR_EL2.TPM
> + *
> + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61
> + *
> + * Unhandled:
> + *PMEVCNTR_EL0
> + *PMEVTYPER_EL0
> + *PMCCFILTR_EL0
> + * MDCR_EL2.TPMCR
> + *
> + * ARMv7 (DDI 0406C.b): B1.14.17
> + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62
> + *
> + * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR.
> + */
> +case HSR_SYSREG_PMINTENSET_EL1:
> +case HSR_SYSREG_PMINTENCLR_EL1:
> +/*
> + * Accessible from EL1 only, but if EL0 trap happens handle as
> + * undef.
> + */
> +return handle_raz_wi(regs, regidx, hsr.sysreg.read, hsr, 1);
> +case HSR_SYSREG_PMUSERENR_EL0:
> +/* RO at EL0. RAZ/WI at EL1 */
> +if ( psr_mode_is_user(regs) )
> +return handle_ro_raz(regs, regidx, h

Re: [Xen-devel] [PATCH v2 3/7] xen/arm: traps: Export a bunch of helpers to handle emulation

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> A follow-up patch will move some parts of traps.c in separate files.
> The will require to use helpers that are currently statically defined.
> Export the following helpers:
> - inject_undef64_exception
> - inject_undef_exception
> - check_conditional_instr
> - advance_pc
> - handle_raz_wi
> - handle_wo_wi
> - handle_ro_raz
> 
> Note that asm-arm/arm32/traps.h is empty but it is to keep parity with
> the arm64 counterpart.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> Cc: volodymyr_babc...@epam.com
> 
> Changes in v2:
> - Fixup guards
> - Add newline for clarity
> ---
>  xen/arch/arm/traps.c  | 43 
> +++
>  xen/include/asm-arm/arm32/traps.h | 13 
>  xen/include/asm-arm/arm64/traps.h | 15 ++
>  xen/include/asm-arm/traps.h   | 36 
>  4 files changed, 85 insertions(+), 22 deletions(-)
>  create mode 100644 xen/include/asm-arm/arm32/traps.h
>  create mode 100644 xen/include/asm-arm/arm64/traps.h
>  create mode 100644 xen/include/asm-arm/traps.h
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 6f32f700e5..1c334a7b99 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -49,6 +49,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -547,7 +548,7 @@ static vaddr_t exception_handler64(struct cpu_user_regs 
> *regs, vaddr_t offset)
>  }
>  
>  /* Inject an undefined exception into a 64 bit guest */
> -static void inject_undef64_exception(struct cpu_user_regs *regs, int 
> instr_len)
> +void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len)
>  {
>  vaddr_t handler;
>  const union hsr esr = {
> @@ -620,8 +621,7 @@ static void inject_iabt64_exception(struct cpu_user_regs 
> *regs,
>  
>  #endif
>  
> -static void inject_undef_exception(struct cpu_user_regs *regs,
> -   const union hsr hsr)
> +void inject_undef_exception(struct cpu_user_regs *regs, const union hsr hsr)
>  {
>  if ( is_32bit_domain(current->domain) )
>  inject_undef32_exception(regs);
> @@ -1714,8 +1714,7 @@ static const unsigned short cc_map[16] = {
>  0   /* NV */
>  };
>  
> -static int check_conditional_instr(struct cpu_user_regs *regs,
> -   const union hsr hsr)
> +int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr)
>  {
>  unsigned long cpsr, cpsr_cond;
>  int cond;
> @@ -1777,7 +1776,7 @@ static int check_conditional_instr(struct cpu_user_regs 
> *regs,
>  return 1;
>  }
>  
> -static void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
> +void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
>  {
>  unsigned long itbits, cond, cpsr = regs->cpsr;
>  
> @@ -1818,11 +1817,11 @@ static void advance_pc(struct cpu_user_regs *regs, 
> const union hsr hsr)
>  }
>  
>  /* Read as zero and write ignore */
> -static void handle_raz_wi(struct cpu_user_regs *regs,
> -  int regidx,
> -  bool read,
> -  const union hsr hsr,
> -  int min_el)
> +void handle_raz_wi(struct cpu_user_regs *regs,
> +   int regidx,
> +   bool read,
> +   const union hsr hsr,
> +   int min_el)
>  {
>  ASSERT((min_el == 0) || (min_el == 1));
>  
> @@ -1836,12 +1835,12 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
>  advance_pc(regs, hsr);
>  }
>  
> -/* Write only as write ignore */
> -static void handle_wo_wi(struct cpu_user_regs *regs,
> - int regidx,
> - bool read,
> - const union hsr hsr,
> - int min_el)
> +/* write only as write ignore */
> +void handle_wo_wi(struct cpu_user_regs *regs,
> +  int regidx,
> +  bool read,
> +  const union hsr hsr,
> +  int min_el)
>  {
>  ASSERT((min_el == 0) || (min_el == 1));
>  
> @@ -1856,11 +1855,11 @@ static void handle_wo_wi(struct cpu_user_regs *regs,
>  }
>  
>  /* Read only as read as zero */
> -static void handle_ro_raz(struct cpu_user_regs *regs,
> -  int regidx,
> -  bool read,
> -  const union hsr hsr,
> -  int min_el)
> +void handle_ro_raz(struct cpu_user_regs *regs,
> +   int regidx,
> +   bool read,
> +   const union hsr hsr,
> +   int min_el)
>  {
>  ASSERT((min_el == 0) || (min_el == 1));
>  
> diff --git a/xen/include/asm-arm/arm32/traps.h 
> b/xen/include/asm-arm/arm32/traps.h
> new file mode 100644
> index 00..e3c4a8b473
> --- /dev/nul

Re: [Xen-devel] [PATCH v2 2/7] xen/arm: Move arch/arm/vtimer.h to include/asm-arm/vtimer.h

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> It will be necessary to include vtimer.h from subdirectory making the
> inclusion a bit awkward.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

> ---
>  xen/arch/arm/domain.c  | 2 +-
>  xen/arch/arm/traps.c   | 2 +-
>  xen/{arch/arm => include/asm-arm}/vtimer.h | 0
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename xen/{arch/arm => include/asm-arm}/vtimer.h (100%)
> 
> diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
> index 6512f01463..784ae392cf 100644
> --- a/xen/arch/arm/domain.c
> +++ b/xen/arch/arm/domain.c
> @@ -33,8 +33,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -#include "vtimer.h"
>  #include "vuart.h"
>  
>  DEFINE_PER_CPU(struct vcpu *, curr_vcpu);
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 6b3dfd9bcf..6f32f700e5 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -50,9 +50,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "decode.h"
> -#include "vtimer.h"
>  
>  /* The base of the stack must always be double-word aligned, which means
>   * that both the kernel half of struct cpu_user_regs (which is pushed in
> diff --git a/xen/arch/arm/vtimer.h b/xen/include/asm-arm/vtimer.h
> similarity index 100%
> rename from xen/arch/arm/vtimer.h
> rename to xen/include/asm-arm/vtimer.h
> -- 
> 2.11.0
> 

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

Re: [Xen-devel] [PATCH v2 1/7] xen/arm: traps: Re-order the includes alphabetically

[Stefano Stabellini]

On Tue, 12 Sep 2017, Julien Grall wrote:
> Signed-off-by: Julien Grall 
> Acked-by: Bhupinder Thakur 

Reviewed-by: Stefano Stabellini 

> ---
> Changes in v2:
> - Fix alphabetical order
> - Add Bhupinder's acked-by
> ---
>  xen/arch/arm/traps.c | 40 +---
>  1 file changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 7f6ec15b5e..6b3dfd9bcf 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -16,41 +16,43 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> -#include 
> -#include 
> -#include 
> -#include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  #include 
> -#include 
> -#include 
> +
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> +
> +#include 
>  #include 
> -#include 
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "decode.h"
>  #include "vtimer.h"
> -#include 
> -#include 
> -#include 
> -#include 
>  
>  /* The base of the stack must always be double-word aligned, which means
>   * that both the kernel half of struct cpu_user_regs (which is pushed in
> -- 
> 2.11.0
> 

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-rumprun-i386  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 113031
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 113031
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 113031
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
113031
 test-amd64-i386-examine   7 reboot   fail REGR. vs. 113031
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 113323 
REGR. vs. 113031

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-ovmf-amd64 16 guest-localmigrate/x10 fail in 113323 
pass in 113353
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
113323
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 113323

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  7 xen-boot   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 113323 
blocked in 113031
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 113031
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 113031
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 113031
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-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-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-suppo

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Julien Grall]

Hi,

On 12/09/2017 20:52, Stefano Stabellini wrote:

On Tue, 12 Sep 2017, Roger Pau Monné wrote:

On Mon, Sep 11, 2017 at 06:01:59PM +0100, George Dunlap wrote:

+## Scalability
+
+### 1GB/2MB super page support
+
+Status: Supported


This needs something like:

Status, x86 HVM/PVH: Supported

IIRC on ARM page sizes are different (64K?)


There is a separate entry for different page granularities. 2MB and 1GB
super-pages, both based on 4K granularity, are supported on ARM too.


This entry and the entry "ARM: 16K and 64K pages in guests" are two 
different things.


Here we speak about the hypervisor whereas the other one is about guests 
itself.


At the moment, the hypervisor only supports 4K. The guests can support 
4K, 16K, 64K. The later two are only for AArch64 guest.


It is probably worth to rename the other entry to "ARM: 4K, 16K, 64K 
pages in guests" for avoiding confusion.


[...]


+### ARM: 16K and 64K pages in guests
+
+Status: Supported, with caveats
+
+No support for QEMU backends in a 16K or 64K domain.


Needs to be merged with the "1GB/2MB super page support"?


Super-pages are different from page granularity. 1GB and 2MB pages are
based on the same 4K page granularity, while 512MB pages are based on
64K granularity. Does it make sense?
Maybe we want to say "ARM: 16K and 64K page granularity in guest" to
clarify.


Each entry is related to different components. The first entry is about 
the hypervisor, whilst this one is about guests. We really don't care 
whether the guests is going to use superpage because at the end of the 
day this will get handle by the hardware directly.


The only thing we care is those guests to be able to interact with Xen 
(the interface is based on 4K granularity at the moment).

So I am not sure what we are trying to clarify at the end...

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Stefano Stabellini]

On Tue, 12 Sep 2017, Roger Pau Monné wrote:
> On Mon, Sep 11, 2017 at 06:01:59PM +0100, George Dunlap wrote:
> > +## Toolstack
> > +
> > +### xl
> > +
> > +Status: Supported
> > +
> > +### Direct-boot kernel image format
> > +
> > +Supported, x86: bzImage
> 
> ELF
> 
> > +Supported, ARM32: zImage
> > +Supported, ARM64: Image
> > +
> > +Format which the toolstack accept for direct-boot kernels
> 
> IMHO it would be good to provide references to the specs, for ELF that
> should be:
> 
> http://refspecs.linuxbase.org/elf/elf.pdf
> 
> > +### Qemu based disk backend (qdisk) for xl
> > +
> > +Status: Supported
> > +
> > +### Open vSwitch integration for xl
> > +
> > +Status: Supported
> 
> Status, Linux: Supported
> 
> I haven't played with vswitch on FreeBSD at all.
> 
> > +
> > +### systemd support for xl
> > +
> > +Status: Supported
> > +
> > +### JSON output support for xl
> > +
> > +Status: Experimental
> > +
> > +Output of information in machine-parseable JSON format
> > +
> > +### AHCI support for xl
> > +
> > +Status, x86: Supported
> > +
> > +### ACPI guest
> > +
> > +Status, x86 HVM: Supported
> > +Status, ARM: Tech Preview
> 
> status, x86 PVH: Tech preview
> 
> > +
> > +### PVUSB support for xl
> > +
> > +Status: Supported
> > +
> > +### HVM USB passthrough for xl
> > +
> > +Status, x86: Supported
> > +
> > +### QEMU backend hotplugging for xl
> > +
> > +Status: Supported
> 
> What's this exactly? Is it referring to hot-adding PV disk and nics?
> If so it shouldn't specifically reference xl, the same can be done
> with blkback or netback for example.
> 
> > +### Virtual cpu hotplug
> > +
> > +Status: Supported
> > +
> > +## Toolstack/3rd party
> > +
> > +### libvirt driver for xl
> > +
> > +Status: Supported, Security support external
> > +
> > +## Debugging, analysis, and crash post-mortem
> > +
> > +### gdbsx
> > +
> > +Status, x86: Supported
> > +
> > +Debugger to debug ELF guests
> > +
> > +### Guest serial sonsole
> > +
> > +Status: Supported
> > +
> > +Logs key hypervisor and Dom0 kernel events to a file
> > +
> > +### Soft-reset for PV guests
> > +
> > +Status: Supported
> > +   
> > +Soft-reset allows a new kernel to start 'from scratch' with a fresh VM 
> > state, 
> > +but with all the memory from the previous state of the VM intact.
> > +This is primarily designed to allow "crash kernels", 
> > +which can do core dumps of memory to help with debugging in the event of a 
> > crash.
> > +
> > +### xentrace
> > +
> > +Status, x86: Supported
> > +
> > +Tool to capture Xen trace buffer data
> > +
> > +### gcov
> > +
> > +Status: Supported, Not security supported
> > +
> > +Export hypervisor coverage data suitable for analysis by gcov or lcov.
> > +
> > +## Memory Management
> > +
> > +### Memory Ballooning
> > +
> > +Status: Supported
> > +
> > +### Memory Sharing
> > +
> > +Status, x86 HVM: Tech Preview
> > +Status, ARM: Tech Preview
> > +
> > +Allow sharing of identical pages between guests
> > +
> > +### Memory Paging
> > +
> > +Status, x86 HVM: Experimenal
> > +
> > +Allow pages belonging to guests to be paged to disk
> > +
> > +### Transcendent Memory
> > +
> > +Status: Experimental
> > +
> > +[XXX Add description]
> > +
> > +### Alternative p2m
> > +
> > +Status, x86 HVM: Tech Preview
> > +Status, ARM: Tech Preview
> > +
> > +Allows external monitoring of hypervisor memory
> > +by maintaining multiple physical to machine (p2m) memory mappings.
> > +
> > +## Resource Management
> > +
> > +### CPU Pools
> > +
> > +Status: Supported
> > +
> > +Groups physical cpus into distinct groups called "cpupools",
> > +with each pool having the capability of using different schedulers and 
> > scheduling properties.
> > +
> > +### Credit Scheduler
> > +
> > +Status: Supported
> > +
> > +The default scheduler, which is a weighted proportional fair share virtual 
> > CPU scheduler.
> > +
> > +### Credit2 Scheduler
> > +
> > +Status: Supported
> > +
> > +Credit2 is a general purpose scheduler for Xen,
> > +designed with particular focus on fairness, responsiveness and scalability
> > +
> > +### RTDS based Scheduler
> > +
> > +Status: Experimental
> > +
> > +A soft real-time CPU scheduler built to provide guaranteed CPU capacity to 
> > guest VMs on SMP hosts
> > +
> > +### ARINC653 Scheduler
> > +
> > +Status: Supported, Not security supported
> > +
> > +A periodically repeating fixed timeslice scheduler. Multicore support is 
> > not yet implemented.
> > +
> > +### Null Scheduler
> > +
> > +Status: Experimental
> > +
> > +A very simple, very static scheduling policy 
> > +that always schedules the same vCPU(s) on the same pCPU(s). 
> > +It is designed for maximum determinism and minimum overhead
> > +on embedded platforms.
> > +
> > +### Numa scheduler affinity
> > +
> > +Status, x86: Supported
> > +
> > +Enables Numa aware scheduling in Xen
> > +
> > +## Scalability

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

[Andrew Cooper]

On 08/09/17 15:48, Juergen Gross wrote:
>  static void gnttab_request_version(void)
>  {
> - int rc;
> + long rc;
>   struct gnttab_set_version gsv;
>  
> - gsv.version = 1;
> + rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);

This hypercall is information leak and layering violation.  Please can
we avoid adding more dependence on its presence?  (I'm got a
proto-series which strips various corners off the hypervisor for attack
surface reduction purposes, and this hypercall is one victim which is
restricted to privileged domains only.)

For translated guests, it is definitely not the right number to check. 
What matters is the maximum frame inside the translated guest, not on
the host.

For PV guests, I'm not sure what to suggest, but the result of
XENMEM_maximum_ram_page isn't applicable.  Xen's max_page can increase
at runtime through memory hotplug, after which ballooning operations can
leave Linux with a frame it wishes to grant which exceeds the limit
calculated here.

The more I look into this, the more of a mess it turns out to be.

~Andrew

> + if (rc < 0 || !(rc >> 32))
> + gsv.version = 1;
> + else
> + gsv.version = 2;
> + if (xen_gnttab_version >= 1 && xen_gnttab_version <= 2)
> + gsv.version = xen_gnttab_version;
>  
>   rc = HYPERVISOR_grant_table_op(GNTTABOP_set_version, &gsv, 1);
>   if (rc == 0 && gsv.version == 2)


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

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Juergen Gross]

On 12/09/17 18:21, Boris Ostrovsky wrote:
> On 09/12/2017 12:09 PM, Juergen Gross wrote:
>> On 12/09/17 18:05, Boris Ostrovsky wrote:
>>> On 09/12/2017 11:50 AM, Juergen Gross wrote:
 On 12/09/17 17:44, Boris Ostrovsky wrote:
> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>> As there is currently no user for sub-page grants or transient grants
>> remove that functionality. This at once makes it possible to switch
>> from grant v2 to grant v1 without restrictions, as there is no loss of
>> functionality other than the limited frame number width related to
>> the switch.
> But isn't that ABI violation? v2 is expected to support this (XSAs
> notwithstanding)
 No, I don't think so.

 The hypervisor still supports it, but the domU (or dom0) isn't required
 to make use of all the features IMHO. Or are you aware of any backend
 querying the grant version of a frontend and acting in another way if v2
 is detected?
>>> I am not aware of any but that doesn't mean that they don't (or won't)
>>> exist.
>> But isn't the frontend the one which is defining what is granted in
>> which way? How should there be an ABI breakage when the frontend just
>> isn't using sub-page or transitive grants?
> 
> People may provide both front and backend drivers and frontends, knowing
> that v2 is available, could decide to use those features.

No, without the functions to use them it will be impossible. So it won't
hit them on a random system by not working, but they would not be able
to load such a driver (same as today without V2 support).

In case they really want it they can send patches for support of subpage
or transient grants. Like they would have to do for complete V2 support
today.


Juergen


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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Wei Liu]

On Tue, Sep 12, 2017 at 05:36:32PM +0100, Andrew Cooper wrote:
> On 12/09/17 17:32, Wei Liu wrote:
> > On Tue, Sep 12, 2017 at 05:30:11PM +0100, Andrew Cooper wrote:
> >> On 12/09/17 15:58, Wei Liu wrote:
> >>> On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
>  As with the create side of things, these are largely identical.  Most 
>  cases
>  are actually destroying the mapping rather than replacing it with a 
>  stolen
>  entry.
> 
>  Reimplement their logic in replace_grant_pv_mapping() in a mostly common
>  way.
> 
>  No (intended) change in behaviour from a guests point of view.
> 
>  Signed-off-by: Andrew Cooper 
> >>> Reviewed-by: Wei Liu 
> >>>
> >>> With two suggestions:
> >>>
>   int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>   unsigned int flags, unsigned int 
>  cache_flags)
>   {
>  @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, 
>  unsigned long frame,
>   {
>   struct vcpu *curr = current;
>   struct domain *currd = curr->domain;
>  -l1_pgentry_t ol1e;
>  -int rc;
>  +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
>  +struct page_info *page;
>  +mfn_t gl1mfn;
>  +int rc = GNTST_general_error;
>   unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>   
>   /*
>  - * On top of the explicit settings done by 
>  create_grant_host_mapping()
>  + * On top of the explicit settings done by create_pv_host_mapping()
>    * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
>    * available and cachability flags, though.
>    */
>  @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, 
>  unsigned long frame,
>  ? _PAGE_GLOBAL
>  : _PAGE_GUEST_KERNEL | _PAGE_USER;
>   
>  +/*
>  + * addr comes from Xen's active_entry tracking, and was used 
>  successfully
>  + * to create a grant.
>  + *
>  + * The meaning of addr depends on GNTMAP_contains_pte.  It is 
>  either a
>  + * machine address of an L1e the guest has nominated to be altered, 
>  or a
>  + * linear address we need to look up the appropriate L1e for.
>  + *
>  + * Passing a new_addr of zero is taken to mean destroy.  Passing a
>  + * non-zero new_addr has only ever been available via
>  + * GNTABOP_unmap_and_replace and only when using linear addresses.
>  + */
> >>> IMHO this should be moved before the function.
> >> Which bit?  The addr and GNTMAP_contains_pte need to be here to explain
> >> the curious if statement below.
> >>
> >> The final paragraph only makes sense in the context of the middle 
> >> paragraph.
> > At least the new_addr == 0 means destroying mapping bit.
> 
> I've folded the following incremental delta.
> 
> ~Andrew
> 
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index f05a1d7..202eee2 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3958,6 +3958,11 @@ static bool steal_linear_address(unsigned long
> linear, l1_pgentry_t *out)
>  return okay;
>  }
>  
> +/*
> + * Passing a new_addr of zero is taken to mean destroy.  Passing a non-zero
> + * new_addr has only ever been available via GNTABOP_unmap_and_replace, and
> + * only when !(flags & GNTMAP_contains_pte).
> + */
>  int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
>   uint64_t new_addr, unsigned int flags)
>  {
> @@ -3986,10 +3991,6 @@ int replace_grant_pv_mapping(uint64_t addr,
> unsigned long frame,
>   * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
>   * machine address of an L1e the guest has nominated to be altered,
> or a
>   * linear address we need to look up the appropriate L1e for.
> - *
> - * Passing a new_addr of zero is taken to mean destroy.  Passing a
> - * non-zero new_addr has only ever been available via
> - * GNTABOP_unmap_and_replace and only when using linear addresses.
>   */
>  if ( flags & GNTMAP_contains_pte )
>  {
> @@ -3997,6 +3998,7 @@ int replace_grant_pv_mapping(uint64_t addr,
> unsigned long frame,
>  if ( new_addr )
>  goto out;
>  
> +/* Sanity check that we won't clobber the pagetable. */
>  if ( !IS_ALIGNED(addr, sizeof(nl1e)) )
>  {
>  ASSERT_UNREACHABLE();
> 

LGTM. Thanks.

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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Andrew Cooper]

On 12/09/17 17:32, Wei Liu wrote:
> On Tue, Sep 12, 2017 at 05:30:11PM +0100, Andrew Cooper wrote:
>> On 12/09/17 15:58, Wei Liu wrote:
>>> On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
 As with the create side of things, these are largely identical.  Most cases
 are actually destroying the mapping rather than replacing it with a stolen
 entry.

 Reimplement their logic in replace_grant_pv_mapping() in a mostly common
 way.

 No (intended) change in behaviour from a guests point of view.

 Signed-off-by: Andrew Cooper 
>>> Reviewed-by: Wei Liu 
>>>
>>> With two suggestions:
>>>
  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
  unsigned int flags, unsigned int cache_flags)
  {
 @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, 
 unsigned long frame,
  {
  struct vcpu *curr = current;
  struct domain *currd = curr->domain;
 -l1_pgentry_t ol1e;
 -int rc;
 +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
 +struct page_info *page;
 +mfn_t gl1mfn;
 +int rc = GNTST_general_error;
  unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
  
  /*
 - * On top of the explicit settings done by create_grant_host_mapping()
 + * On top of the explicit settings done by create_pv_host_mapping()
   * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
   * available and cachability flags, though.
   */
 @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, 
 unsigned long frame,
 ? _PAGE_GLOBAL
 : _PAGE_GUEST_KERNEL | _PAGE_USER;
  
 +/*
 + * addr comes from Xen's active_entry tracking, and was used 
 successfully
 + * to create a grant.
 + *
 + * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
 + * machine address of an L1e the guest has nominated to be altered, 
 or a
 + * linear address we need to look up the appropriate L1e for.
 + *
 + * Passing a new_addr of zero is taken to mean destroy.  Passing a
 + * non-zero new_addr has only ever been available via
 + * GNTABOP_unmap_and_replace and only when using linear addresses.
 + */
>>> IMHO this should be moved before the function.
>> Which bit?  The addr and GNTMAP_contains_pte need to be here to explain
>> the curious if statement below.
>>
>> The final paragraph only makes sense in the context of the middle paragraph.
> At least the new_addr == 0 means destroying mapping bit.

I've folded the following incremental delta.

~Andrew

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index f05a1d7..202eee2 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3958,6 +3958,11 @@ static bool steal_linear_address(unsigned long
linear, l1_pgentry_t *out)
 return okay;
 }
 
+/*
+ * Passing a new_addr of zero is taken to mean destroy.  Passing a non-zero
+ * new_addr has only ever been available via GNTABOP_unmap_and_replace, and
+ * only when !(flags & GNTMAP_contains_pte).
+ */
 int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
  uint64_t new_addr, unsigned int flags)
 {
@@ -3986,10 +3991,6 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
  * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
  * machine address of an L1e the guest has nominated to be altered,
or a
  * linear address we need to look up the appropriate L1e for.
- *
- * Passing a new_addr of zero is taken to mean destroy.  Passing a
- * non-zero new_addr has only ever been available via
- * GNTABOP_unmap_and_replace and only when using linear addresses.
  */
 if ( flags & GNTMAP_contains_pte )
 {
@@ -3997,6 +3998,7 @@ int replace_grant_pv_mapping(uint64_t addr,
unsigned long frame,
 if ( new_addr )
 goto out;
 
+/* Sanity check that we won't clobber the pagetable. */
 if ( !IS_ALIGNED(addr, sizeof(nl1e)) )
 {
 ASSERT_UNREACHABLE();


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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Wei Liu]

On Tue, Sep 12, 2017 at 05:30:11PM +0100, Andrew Cooper wrote:
> On 12/09/17 15:58, Wei Liu wrote:
> > On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
> >> As with the create side of things, these are largely identical.  Most cases
> >> are actually destroying the mapping rather than replacing it with a stolen
> >> entry.
> >>
> >> Reimplement their logic in replace_grant_pv_mapping() in a mostly common
> >> way.
> >>
> >> No (intended) change in behaviour from a guests point of view.
> >>
> >> Signed-off-by: Andrew Cooper 
> > Reviewed-by: Wei Liu 
> >
> > With two suggestions:
> >
> >>  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
> >>  unsigned int flags, unsigned int cache_flags)
> >>  {
> >> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, 
> >> unsigned long frame,
> >>  {
> >>  struct vcpu *curr = current;
> >>  struct domain *currd = curr->domain;
> >> -l1_pgentry_t ol1e;
> >> -int rc;
> >> +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
> >> +struct page_info *page;
> >> +mfn_t gl1mfn;
> >> +int rc = GNTST_general_error;
> >>  unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
> >>  
> >>  /*
> >> - * On top of the explicit settings done by create_grant_host_mapping()
> >> + * On top of the explicit settings done by create_pv_host_mapping()
> >>   * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
> >>   * available and cachability flags, though.
> >>   */
> >> @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, 
> >> unsigned long frame,
> >> ? _PAGE_GLOBAL
> >> : _PAGE_GUEST_KERNEL | _PAGE_USER;
> >>  
> >> +/*
> >> + * addr comes from Xen's active_entry tracking, and was used 
> >> successfully
> >> + * to create a grant.
> >> + *
> >> + * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
> >> + * machine address of an L1e the guest has nominated to be altered, 
> >> or a
> >> + * linear address we need to look up the appropriate L1e for.
> >> + *
> >> + * Passing a new_addr of zero is taken to mean destroy.  Passing a
> >> + * non-zero new_addr has only ever been available via
> >> + * GNTABOP_unmap_and_replace and only when using linear addresses.
> >> + */
> > IMHO this should be moved before the function.
> 
> Which bit?  The addr and GNTMAP_contains_pte need to be here to explain
> the curious if statement below.
> 
> The final paragraph only makes sense in the context of the middle paragraph.

At least the new_addr == 0 means destroying mapping bit.

> 
> >
> >>  if ( flags & GNTMAP_contains_pte )
> >>  {
> >> -if ( !new_addr )
> >> -return destroy_grant_pte_mapping(addr, frame, grant_pte_flags,
> >> - currd);
> >> +/* Replace not available in this addressing mode. */
> >> +if ( new_addr )
> >> +goto out;
> >> +
> >/*
> > * addr comes from Xen's active_entry tracking so isn't guest controlled,
> > * but it had still better be PTE-aligned.
> > */
> >
> > Consider keeping this comment?
> 
> Is it really that helpful?  It is in the context of "addr comes from
> Xen's active_entry tracking, and was used successfully to create the grant".

OK. I won't insist on this.

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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Andrew Cooper]

On 12/09/17 15:58, Wei Liu wrote:
> On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
>> As with the create side of things, these are largely identical.  Most cases
>> are actually destroying the mapping rather than replacing it with a stolen
>> entry.
>>
>> Reimplement their logic in replace_grant_pv_mapping() in a mostly common
>> way.
>>
>> No (intended) change in behaviour from a guests point of view.
>>
>> Signed-off-by: Andrew Cooper 
> Reviewed-by: Wei Liu 
>
> With two suggestions:
>
>>  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>>  unsigned int flags, unsigned int cache_flags)
>>  {
>> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned 
>> long frame,
>>  {
>>  struct vcpu *curr = current;
>>  struct domain *currd = curr->domain;
>> -l1_pgentry_t ol1e;
>> -int rc;
>> +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
>> +struct page_info *page;
>> +mfn_t gl1mfn;
>> +int rc = GNTST_general_error;
>>  unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>>  
>>  /*
>> - * On top of the explicit settings done by create_grant_host_mapping()
>> + * On top of the explicit settings done by create_pv_host_mapping()
>>   * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
>>   * available and cachability flags, though.
>>   */
>> @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned 
>> long frame,
>> ? _PAGE_GLOBAL
>> : _PAGE_GUEST_KERNEL | _PAGE_USER;
>>  
>> +/*
>> + * addr comes from Xen's active_entry tracking, and was used 
>> successfully
>> + * to create a grant.
>> + *
>> + * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
>> + * machine address of an L1e the guest has nominated to be altered, or a
>> + * linear address we need to look up the appropriate L1e for.
>> + *
>> + * Passing a new_addr of zero is taken to mean destroy.  Passing a
>> + * non-zero new_addr has only ever been available via
>> + * GNTABOP_unmap_and_replace and only when using linear addresses.
>> + */
> IMHO this should be moved before the function.

Which bit?  The addr and GNTMAP_contains_pte need to be here to explain
the curious if statement below.

The final paragraph only makes sense in the context of the middle paragraph.

>
>>  if ( flags & GNTMAP_contains_pte )
>>  {
>> -if ( !new_addr )
>> -return destroy_grant_pte_mapping(addr, frame, grant_pte_flags,
>> - currd);
>> +/* Replace not available in this addressing mode. */
>> +if ( new_addr )
>> +goto out;
>> +
>/*
> * addr comes from Xen's active_entry tracking so isn't guest controlled,
> * but it had still better be PTE-aligned.
> */
>
> Consider keeping this comment?

Is it really that helpful?  It is in the context of "addr comes from
Xen's active_entry tracking, and was used successfully to create the grant".

~Andrew

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

[Xen-devel] [PATCH v6 10/12] x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page

[Paul Durrant]

This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: Jan Beulich 
---
 xen/arch/x86/hvm/ioreq.c | 44 
 xen/include/asm-x86/hvm/domain.h |  2 +-
 2 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 18598a77ad..5e28980e97 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -211,7 +211,7 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
+static gfn_t hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
 struct domain *d = s->domain;
 unsigned int i;
@@ -221,20 +221,19 @@ static unsigned long hvm_alloc_ioreq_gfn(struct 
hvm_ioreq_server *s)
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) )
-return d->arch.hvm_domain.ioreq_gfn.base + i;
+return _gfn(d->arch.hvm_domain.ioreq_gfn.base + i);
 }
 
-return gfn_x(INVALID_GFN);
+return INVALID_GFN;
 }
 
-static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
-   unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s, gfn_t gfn)
 {
 struct domain *d = s->domain;
-unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
+unsigned int i = gfn_x(gfn) - d->arch.hvm_domain.ioreq_gfn.base;
 
 ASSERT(!IS_DEFAULT(s));
-ASSERT(gfn != gfn_x(INVALID_GFN));
+ASSERT(!gfn_eq(gfn, INVALID_GFN));
 
 set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
 }
@@ -243,7 +242,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
 destroy_ring_for_helper(&iorp->va, iorp->page);
@@ -252,7 +251,7 @@ static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 if ( !IS_DEFAULT(s) )
 hvm_free_ioreq_gfn(s, iorp->gfn);
 
-iorp->gfn = gfn_x(INVALID_GFN);
+iorp->gfn = INVALID_GFN;
 }
 
 static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
@@ -265,16 +264,17 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return -EINVAL;
 
 if ( IS_DEFAULT(s) )
-iorp->gfn = buf ?
-d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
-d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+iorp->gfn = _gfn(buf ?
+ d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+ d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN]);
 else
 iorp->gfn = hvm_alloc_ioreq_gfn(s);
 
-if ( iorp->gfn == gfn_x(INVALID_GFN) )
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
 return -ENOMEM;
 
-rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va);
+rc = prepare_ring_for_helper(d, gfn_x(iorp->gfn), &iorp->page,
+ &iorp->va);
 
 if ( rc )
 hvm_unmap_ioreq_gfn(s, buf);
@@ -313,10 +313,10 @@ static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server 
*s, bool buf)
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return;
 
-if ( guest_physmap_remove_page(d, _gfn(iorp->gfn),
+if ( guest_physmap_remove_page(d, iorp->gfn,
_mfn(page_to_mfn(iorp->page)), 0) )
 domain_crash(d);
 clear_page(iorp->va);
@@ -328,12 +328,12 @@ static int hvm_add_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
 int rc;
 
-if ( IS_DEFAULT(s) || iorp->gfn == gfn_x(INVALID_GFN) )
+if ( IS_DEFAULT(s) || gfn_eq(iorp->gfn, INVALID_GFN) )
 return 0;
 
 clear_page(iorp->va);
 
-rc = guest_physmap_add_page(d, _gfn(iorp->gfn),
+rc = guest_physmap_add_page(d, iorp->gfn,
 _mfn(page_to_mfn(iorp->page)), 0);
 if ( rc == 0 )
 paging_mark_dirty(d, _mfn(page_to_mfn(iorp->page)));
@@ -592,8 +592,8 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server *s,
 INIT_LIST_HEAD(&s->ioreq_vcpu_list);
 spin_lock_init(&s->bufioreq_lock);
 
-s->ioreq.gfn = gfn_x(INVALID_GFN);
-s->bufioreq.gfn = gfn_x(INVALID_GFN);
+s->ioreq.gfn = INVALID_GFN;
+s->bufioreq.gfn = INVALID_GFN;
 
 rc = hvm_ioreq_server_alloc_rangesets(s, id);
 if ( rc )
@@ -762,11 +762,11 @@ int hvm_get_ioreq_server_info(struct domain *d, 
ioservid_t id,
 if ( IS_

[Xen-devel] [PATCH v6 11/12] x86/hvm/ioreq: defer mapping gfns until they are actually requsted

[Paul Durrant]

A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.

This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the xen_dm_op_get_ioreq_server_info structure is re-purposed
to a flags field and new flag, XEN_DMOP_no_gfns, defined which modifies the
behaviour of XEN_DMOP_get_ioreq_server_info to allow the caller to avoid
requesting the gfn values.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 

v3:
 - Updated in response to review comments from Wei and Roger.
 - Added a HANDLE_BUFIOREQ macro to make the code neater.
 - This patch no longer introduces a security vulnerability since there
   is now an explicit limit on the number of ioreq servers that may be
   created for any one domain.
---
 tools/libs/devicemodel/core.c   |  8 +
 tools/libs/devicemodel/include/xendevicemodel.h |  6 ++--
 xen/arch/x86/hvm/dm.c   |  9 --
 xen/arch/x86/hvm/ioreq.c| 41 +
 xen/include/asm-x86/hvm/domain.h|  2 +-
 xen/include/public/hvm/dm_op.h  | 32 +++
 6 files changed, 59 insertions(+), 39 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index fcb260d29b..28958934bf 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -188,6 +188,14 @@ int xendevicemodel_get_ioreq_server_info(
 
 data->id = id;
 
+/*
+ * If the caller is not requesting gfn values then instruct the
+ * hypercall not to retrieve them as this may cause them to be
+ * mapped.
+ */
+if (!ioreq_gfn && !bufioreq_gfn)
+data->flags |= XEN_DMOP_no_gfns;
+
 rc = xendevicemodel_op(dmod, domid, 1, &op, sizeof(op));
 if (rc)
 return rc;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 13216db04a..d73a76da35 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -61,11 +61,11 @@ int xendevicemodel_create_ioreq_server(
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
  * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gfn
+ *  gfn. (May be NULL if not required)
  * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gfn
+ *gfn. (May be NULL if not required)
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
- * ioreq event channel
+ * ioreq event channel. (May be NULL if not required)
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 87ef4b6ca9..c020f0c99f 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -418,16 +418,19 @@ static int dm_op(const struct dmop_args *op_args)
 {
 struct xen_dm_op_get_ioreq_server_info *data =
 &op.u.get_ioreq_server_info;
+const uint16_t valid_flags = XEN_DMOP_no_gfns;
 
 const_op = false;
 
 rc = -EINVAL;
-if ( data->pad )
+if ( data->flags & ~valid_flags )
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   &data->ioreq_gfn,
-   &data->bufioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : &data->ioreq_gfn,
+   (data->flags & XEN_DMOP_no_gfns) ?
+   NULL : &data->bufioreq_gfn,
&data->bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 5e28980e97..e87dce0e64 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -354,6 +354,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 }
 
+#define HANDLE_BUFIOREQ(s) \
+(s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF)
+
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
  struct vcpu *v)
 {
@@ -375,7 +378,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 
 sv->ioreq_evtchn = rc;
 
-if ( v->vcpu_id == 0 && s->bufioreq.va != NULL )
+if ( v->vcpu_id == 0 && HANDLE_BUFIOREQ(s) )
 {
 struct domain *d = s->domain;
 
@@ -426,7 +429,7 @@ static void hvm_ioreq_server_remove_vcpu(struct 
hvm_

[Xen-devel] [PATCH v6 12/12] x86/hvm/ioreq: add a new mappable resource type...

[Paul Durrant]

... XENMEM_resource_ioreq_server

This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.

If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never be present in the P2M of the guest at any point and so are
not vulnerable to any direct attack by the guest. They are only ever
accessible by Xen and any domain that has mapping privilege over the
guest (which may or may not be limited to the domain running the emulator).

NOTE: Use of the new resource type is not compatible with use of
  XEN_DMOP_get_ioreq_server_info unless the XEN_DMOP_no_gfns flag is
  set.

Signed-off-by: Paul Durrant 
Acked-by: George Dunlap 
Reviewed-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Ian Jackson 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 

v5:
 - Use get_ioreq_server() function rather than indexing array directly.
 - Add more explanation into comments to state than mapping guest frames
   and allocation of pages for ioreq servers are not simultaneously
   permitted.
 - Add a comment into asm/ioreq.h stating the meaning of the index
   value passed to hvm_get_ioreq_server_frame().
---
 xen/arch/x86/hvm/ioreq.c| 131 +++-
 xen/arch/x86/mm.c   |  27 +
 xen/include/asm-x86/hvm/ioreq.h |   6 ++
 xen/include/public/hvm/dm_op.h  |   4 ++
 xen/include/public/memory.h |   3 +
 5 files changed, 170 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index e87dce0e64..a11680dc8f 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -260,6 +260,19 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
 int rc;
 
+if ( iorp->page )
+{
+/*
+ * If a page has already been allocated (which will happen on
+ * demand if hvm_get_ioreq_server_frame() is called), then
+ * mapping a guest frame is not permitted.
+ */
+if ( gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
 if ( d->is_dying )
 return -EINVAL;
 
@@ -282,6 +295,61 @@ static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, 
bool buf)
 return rc;
 }
 
+static int hvm_alloc_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct domain *currd = current->domain;
+struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
+
+if ( iorp->page )
+{
+/*
+ * If a guest frame has already been mapped (which may happen
+ * on demand if hvm_get_ioreq_server_info() is called), then
+ * allocating a page is not permitted.
+ */
+if ( !gfn_eq(iorp->gfn, INVALID_GFN) )
+return -EPERM;
+
+return 0;
+}
+
+/*
+ * Allocated IOREQ server pages are assigned to the emulating
+ * domain, not the target domain. This is because the emulator is
+ * likely to be destroyed after the target domain has been torn
+ * down, and we must use MEMF_no_refcount otherwise page allocation
+ * could fail if the emulating domain has already reached its
+ * maximum allocation.
+ */
+iorp->page = alloc_domheap_page(currd, MEMF_no_refcount);
+if ( !iorp->page )
+return -ENOMEM;
+
+iorp->va = __map_domain_page_global(iorp->page);
+if ( !iorp->va )
+{
+iorp->page = NULL;
+return -ENOMEM;
+}
+
+clear_page(iorp->va);
+return 0;
+}
+
+static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
+{
+struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
+
+if ( !iorp->page )
+return;
+
+unmap_domain_page_global(iorp->va);
+iorp->va = NULL;
+
+put_page(iorp->page);
+iorp->page = NULL;
+}
+
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
@@ -488,6 +556,27 @@ static void hvm_ioreq_server_unmap_pages(struct 
hvm_ioreq_server *s)
 hvm_unmap_ioreq_gfn(s, false);
 }
 
+static int hvm_ioreq_server_alloc_pages(struct hvm_ioreq_server *s)
+{
+int rc;
+
+rc = hvm_alloc_ioreq_mfn(s, false);
+
+if ( !rc && (s->bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF) )
+rc = hvm_alloc_ioreq_mfn(s, true);
+
+if ( rc )
+hvm_free_ioreq_mfn(s, false);
+
+return rc;
+}
+
+static void hvm_ioreq_server_free_pages(struct hvm_ioreq_server *s)
+{
+hvm_free_ioreq_mfn(s, true);
+hvm_free_ioreq_mfn(s, false);
+}
+
 static void hvm_ioreq_server_free_rangesets(struct hvm_ioreq_server *s)
 {
 unsigned int i;
@@ -614,7 +703,18 @@ static int hvm_ioreq_server_init(struct hvm_ioreq_server 
*s,
 
  fail_add:
 hvm_ioreq_server_remove_all_vcpus(s);
+
+/*
+ * NOTE: It is safe to call both hvm_ioreq_server_unmap_pag

Re: [Xen-devel] [PATCH v6 00/13] libxl: add PV display device driver interface

[Wei Liu]

On Tue, Sep 12, 2017 at 04:48:05PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Changes since V4:
> * Change libxl_device_nic_list to libxl__device_list;
> * Move incorrect memory leak fix to additional patch.
> 
> Patches on github [1].
> 
> [1] https://github.com/al1img/xen/tree/xl-vdispl-v6
> 

This branch only contained the first 5 patches as far as I can tell, and
it isn't based on top of staging.

Please fold in my acks and rebase all patches on top of staging.

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

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Boris Ostrovsky]

On 09/12/2017 12:09 PM, Juergen Gross wrote:
> On 12/09/17 18:05, Boris Ostrovsky wrote:
>> On 09/12/2017 11:50 AM, Juergen Gross wrote:
>>> On 12/09/17 17:44, Boris Ostrovsky wrote:
 On 09/08/2017 10:48 AM, Juergen Gross wrote:
> As there is currently no user for sub-page grants or transient grants
> remove that functionality. This at once makes it possible to switch
> from grant v2 to grant v1 without restrictions, as there is no loss of
> functionality other than the limited frame number width related to
> the switch.
 But isn't that ABI violation? v2 is expected to support this (XSAs
 notwithstanding)
>>> No, I don't think so.
>>>
>>> The hypervisor still supports it, but the domU (or dom0) isn't required
>>> to make use of all the features IMHO. Or are you aware of any backend
>>> querying the grant version of a frontend and acting in another way if v2
>>> is detected?
>> I am not aware of any but that doesn't mean that they don't (or won't)
>> exist.
> But isn't the frontend the one which is defining what is granted in
> which way? How should there be an ABI breakage when the frontend just
> isn't using sub-page or transitive grants?

People may provide both front and backend drivers and frontends, knowing
that v2 is available, could decide to use those features.

-boris

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

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version

[Boris Ostrovsky]

On 09/08/2017 10:48 AM, Juergen Gross wrote:
> Based on the maximum page number of the host select either grant v1 or
> grant v2.
>
> For testing purposes add a way to specify the grant interface version
> via a boot parameter.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 



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

Re: [Xen-devel] [PATCH 0/2] public/*ctl: drop unnecessary typedefs and handles

[Julien Grall]

Hi,

On 12/09/17 15:25, Jan Beulich wrote:

1: public/domctl: drop unnecessary typedefs and handles
2: public/sysctl: drop unnecessary typedefs and handles

Signed-off-by: Jan Beulich 


Acked-by: Julien Grall 

Cheers,





--
Julien Grall

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

Re: [Xen-devel] [PATCH 0/2] public/*ctl: drop unnecessary typedefs and handles

[Andrew Cooper]

On 12/09/17 15:25, Jan Beulich wrote:
> 1: public/domctl: drop unnecessary typedefs and handles
> 2: public/sysctl: drop unnecessary typedefs and handles
>
> Signed-off-by: Jan Beulich 
>

Acked-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH 1/2] public/domctl: drop unnecessary typedefs and handles

[Meng Xu]

On Tue, Sep 12, 2017 at 11:08 AM, Jan Beulich  wrote:
>
> By virtue of the struct xen_domctl container structure, most of them
> are really just cluttering the name space.
>
> While doing so,
> - convert an enum typed (pt_irq_type_t) structure field to a fixed
>   width type,
> - make x86's paging_domctl() and descendants take a properly typed
>   handle,
> - add const in a few places.
>
> Signed-off-by: Jan Beulich 


Acked-by: Meng Xu 

Thanks,

Meng

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

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

Re: [Xen-devel] [PATCH v6 10/13] libxl: change nic to use generec add function

[Wei Liu]

On Tue, Sep 12, 2017 at 04:48:15PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v6 11/13] libxl: fix memory leak in libxl__colo_save_setup

[Wei Liu]

On Tue, Sep 12, 2017 at 04:48:16PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Getting nic list in case userspace proxy is called
> without freeing. The fix is to use cds->nics to
> keep nic list. cds->nics will be freed in
> devices_teardown_cb.
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH v6 02/12] x86/mm: add HYPERVISOR_memory_op to acquire guest resources

[Paul Durrant]

Certain memory resources associated with a guest are not necessarily
present in the guest P2M and so are not necessarily available to be
foreign-mapped by a tools domain unless they are inserted, which risks
shattering a super-page mapping.

This patch adds a new memory op to allow such a resource to be priv-mapped
directly, by either a PV or HVM tools domain: grant table frames.

NOTE: Whilst the new op is not intrinsicly specific to the x86 architecture,
  I have no means to test it on an ARM platform and so cannot verify
  that it functions correctly. Hence it is currently only implemented
  for x86.

Signed-off-by: Paul Durrant 
Acked-by: George Dunlap 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v5:
 - Switched __copy_to/from_guest_offset() to copy_to/from_guest_offset().
---
 xen/arch/x86/mm.c | 111 ++
 xen/arch/x86/mm/p2m.c |   3 +-
 xen/common/grant_table.c  |  56 ++---
 xen/include/asm-x86/p2m.h |   3 ++
 xen/include/public/memory.h   |  38 ++-
 xen/include/xen/grant_table.h |   1 +
 6 files changed, 191 insertions(+), 21 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index cb0189efae..c8f50f3bb0 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -4768,6 +4768,107 @@ int xenmem_add_to_physmap_one(
 return rc;
 }
 
+static int xenmem_acquire_grant_table(struct domain *d,
+  unsigned long frame,
+  unsigned long nr_frames,
+  unsigned long mfn_list[])
+{
+unsigned int i;
+
+/*
+ * Iterate through the list backwards so that gnttab_get_frame() is
+ * first called for the highest numbered frame. This means that the
+ * out-of-bounds check will be done on the first iteration and, if
+ * the table needs to grow, it will only grow once.
+ */
+i = nr_frames;
+while ( i-- != 0 )
+{
+mfn_t mfn = gnttab_get_frame(d, frame + i);
+
+if ( mfn_eq(mfn, INVALID_MFN) )
+return -EINVAL;
+
+mfn_list[i] = mfn_x(mfn);
+}
+
+return 0;
+}
+
+static int xenmem_acquire_resource(xen_mem_acquire_resource_t *xmar)
+{
+struct domain *d, *currd = current->domain;
+unsigned long *mfn_list;
+int rc;
+
+if ( xmar->nr_frames == 0 )
+return -EINVAL;
+
+d = rcu_lock_domain_by_any_id(xmar->domid);
+if ( d == NULL )
+return -ESRCH;
+
+rc = xsm_domain_memory_map(XSM_TARGET, d);
+if ( rc )
+goto out;
+
+mfn_list = xmalloc_array(unsigned long, xmar->nr_frames);
+
+rc = -ENOMEM;
+if ( !mfn_list )
+goto out;
+
+switch ( xmar->type )
+{
+case XENMEM_resource_grant_table:
+rc = -EINVAL;
+if ( xmar->id ) /* must be zero for grant_table */
+break;
+
+rc = xenmem_acquire_grant_table(d, xmar->frame, xmar->nr_frames,
+mfn_list);
+break;
+
+default:
+rc = -EOPNOTSUPP;
+break;
+}
+
+if ( rc )
+goto free_and_out;
+
+if ( !paging_mode_translate(currd) )
+{
+if ( copy_to_guest_offset(xmar->gmfn_list, 0, mfn_list,
+  xmar->nr_frames) )
+rc = -EFAULT;
+}
+else
+{
+unsigned int i;
+
+for ( i = 0; i < xmar->nr_frames; i++ )
+{
+xen_pfn_t gfn;
+
+rc = -EFAULT;
+if ( copy_from_guest_offset(&gfn, xmar->gmfn_list, i, 1) )
+goto free_and_out;
+
+rc = set_foreign_p2m_entry(currd, gfn, _mfn(mfn_list[i]));
+if ( rc )
+goto free_and_out;
+}
+}
+
+ free_and_out:
+xfree(mfn_list);
+
+ out:
+rcu_unlock_domain(d);
+return rc;
+}
+
 long arch_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 int rc;
@@ -4990,6 +5091,16 @@ long arch_memory_op(unsigned long cmd, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 return rc;
 }
 
+case XENMEM_acquire_resource:
+{
+xen_mem_acquire_resource_t xmar;
+
+if ( copy_from_guest(&xmar, arg, 1) )
+return -EFAULT;
+
+return xenmem_acquire_resource(&xmar);
+}
+
 default:
 return subarch_memory_op(cmd, arg);
 }
diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index 0b479105b9..d0f8fc249b 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1121,8 +1121,7 @@ static int set_typed_p2m_entry(struct domain *d, unsigned 
long gfn, mfn_t mfn,
 }
 
 /* Set foreign mfn in the given guest's p2m table. */
-static int set_foreign_p2m_entry(struct domain *d, unsigned long gfn,
- mfn_t mfn)
+int set_foreign_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
 {
 return set_typed_p2m_entry(d, gfn, mfn, PAGE_ORDER_4K, p2m_map_foreign,
p2m_get_ho

[Xen-devel] [PATCH v6 07/12] x86/hvm/ioreq: use bool rather than bool_t

[Paul Durrant]

This patch changes use of bool_t to bool in the ioreq server code. It also
fixes an incorrect indentation in a continuation line.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/dm.c|   2 +-
 xen/arch/x86/hvm/hvm.c   |   2 +-
 xen/arch/x86/hvm/io.c|   4 +-
 xen/arch/x86/hvm/ioreq.c | 100 +++
 xen/include/asm-x86/hvm/domain.h |   6 +--
 xen/include/asm-x86/hvm/ioreq.h  |  14 +++---
 6 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index f7cb883fec..87ef4b6ca9 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -409,7 +409,7 @@ static int dm_op(const struct dmop_args *op_args)
 if ( data->pad[0] || data->pad[1] || data->pad[2] )
 break;
 
-rc = hvm_create_ioreq_server(d, curr_d->domain_id, 0,
+rc = hvm_create_ioreq_server(d, curr_d->domain_id, false,
  data->handle_bufioreq, &data->id);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 58b4afa1d1..031d07baf0 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4361,7 +4361,7 @@ static int hvmop_get_param(
 {
 domid_t domid = d->arch.hvm_domain.params[HVM_PARAM_DM_DOMAIN];
 
-rc = hvm_create_ioreq_server(d, domid, 1,
+rc = hvm_create_ioreq_server(d, domid, true,
  HVM_IOREQSRV_BUFIOREQ_LEGACY, NULL);
 if ( rc != 0 && rc != -EEXIST )
 goto out;
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index bf41954f59..1ddcaba52e 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -59,7 +59,7 @@ void send_timeoffset_req(unsigned long timeoff)
 if ( timeoff == 0 )
 return;
 
-if ( hvm_broadcast_ioreq(&p, 1) != 0 )
+if ( hvm_broadcast_ioreq(&p, true) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful timeoffset update\n");
 }
 
@@ -73,7 +73,7 @@ void send_invalidate_req(void)
 .data = ~0UL, /* flush all */
 };
 
-if ( hvm_broadcast_ioreq(&p, 0) != 0 )
+if ( hvm_broadcast_ioreq(&p, false) != 0 )
 gprintk(XENLOG_ERR, "Unsuccessful map-cache invalidate\n");
 }
 
diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index 69913cf3cd..f2e0b3f74a 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -43,7 +43,7 @@ static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct 
vcpu *v)
 return &p->vcpu_ioreq[v->vcpu_id];
 }
 
-bool_t hvm_io_pending(struct vcpu *v)
+bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
@@ -59,11 +59,11 @@ bool_t hvm_io_pending(struct vcpu *v)
   list_entry )
 {
 if ( sv->vcpu == v && sv->pending )
-return 1;
+return true;
 }
 }
 
-return 0;
+return false;
 }
 
 static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, uint64_t data)
@@ -82,10 +82,10 @@ static void hvm_io_assist(struct hvm_ioreq_vcpu *sv, 
uint64_t data)
 msix_write_completion(v);
 vcpu_end_shutdown_deferral(v);
 
-sv->pending = 0;
+sv->pending = false;
 }
 
-static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
+static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
 {
 while ( sv->pending )
 {
@@ -112,16 +112,16 @@ static bool_t hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, 
ioreq_t *p)
 break;
 default:
 gdprintk(XENLOG_ERR, "Weird HVM iorequest state %u\n", state);
-sv->pending = 0;
+sv->pending = false;
 domain_crash(sv->vcpu->domain);
-return 0; /* bail */
+return false; /* bail */
 }
 }
 
-return 1;
+return true;
 }
 
-bool_t handle_hvm_io_completion(struct vcpu *v)
+bool handle_hvm_io_completion(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io;
@@ -141,7 +141,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 if ( sv->vcpu == v && sv->pending )
 {
 if ( !hvm_wait_for_io(sv, get_ioreq(s, v)) )
-return 0;
+return false;
 
 break;
 }
@@ -178,7 +178,7 @@ bool_t handle_hvm_io_completion(struct vcpu *v)
 break;
 }
 
-return 1;
+return true;
 }
 
 static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
@@ -208,7 +208,7 @@ static void hvm_free_ioreq_gfn(struct domain *d, unsigned 
long gfn)
 set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t buf)
+static 

[Xen-devel] [PATCH v6 03/12] tools/libxenforeignmemory: add support for resource mapping

[Paul Durrant]

A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.

This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).

[1] 
http://xenbits.xen.org/gitweb/?p=people/pauldu/linux.git;a=commit;h=ce59a05e6712

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Fixed errno and removed single-use label
 - The unmap call now returns a status
 - Use C99 initialization for ioctl struct

v2:
 - Bump minor version up to 3.
---
 tools/include/xen-sys/Linux/privcmd.h  | 11 +
 tools/libs/foreignmemory/Makefile  |  2 +-
 tools/libs/foreignmemory/core.c| 53 ++
 .../libs/foreignmemory/include/xenforeignmemory.h  | 41 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |  5 ++
 tools/libs/foreignmemory/linux.c   | 45 ++
 tools/libs/foreignmemory/private.h | 31 +
 7 files changed, 187 insertions(+), 1 deletion(-)

diff --git a/tools/include/xen-sys/Linux/privcmd.h 
b/tools/include/xen-sys/Linux/privcmd.h
index 732ff7c15a..9531b728f9 100644
--- a/tools/include/xen-sys/Linux/privcmd.h
+++ b/tools/include/xen-sys/Linux/privcmd.h
@@ -86,6 +86,15 @@ typedef struct privcmd_dm_op {
const privcmd_dm_op_buf_t __user *ubufs;
 } privcmd_dm_op_t;
 
+typedef struct privcmd_mmap_resource {
+   domid_t dom;
+   __u32 type;
+   __u32 id;
+   __u32 idx;
+   __u64 num;
+   __u64 addr;
+} privcmd_mmap_resource_t;
+
 /*
  * @cmd: IOCTL_PRIVCMD_HYPERCALL
  * @arg: &privcmd_hypercall_t
@@ -103,5 +112,7 @@ typedef struct privcmd_dm_op {
_IOC(_IOC_NONE, 'P', 5, sizeof(privcmd_dm_op_t))
 #define IOCTL_PRIVCMD_RESTRICT \
_IOC(_IOC_NONE, 'P', 6, sizeof(domid_t))
+#define IOCTL_PRIVCMD_MMAP_RESOURCE\
+   _IOC(_IOC_NONE, 'P', 7, sizeof(privcmd_mmap_resource_t))
 
 #endif /* __LINUX_PUBLIC_PRIVCMD_H__ */
diff --git a/tools/libs/foreignmemory/Makefile 
b/tools/libs/foreignmemory/Makefile
index ab7f873f26..5c7f78f61d 100644
--- a/tools/libs/foreignmemory/Makefile
+++ b/tools/libs/foreignmemory/Makefile
@@ -2,7 +2,7 @@ XEN_ROOT = $(CURDIR)/../../..
 include $(XEN_ROOT)/tools/Rules.mk
 
 MAJOR= 1
-MINOR= 2
+MINOR= 3
 SHLIB_LDFLAGS += -Wl,--version-script=libxenforeignmemory.map
 
 CFLAGS   += -Werror -Wmissing-prototypes
diff --git a/tools/libs/foreignmemory/core.c b/tools/libs/foreignmemory/core.c
index a6897dc561..8d3f9f178f 100644
--- a/tools/libs/foreignmemory/core.c
+++ b/tools/libs/foreignmemory/core.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include 
+
 #include "private.h"
 
 xenforeignmemory_handle *xenforeignmemory_open(xentoollog_logger *logger,
@@ -120,6 +122,57 @@ int xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
 return osdep_xenforeignmemory_restrict(fmem, domid);
 }
 
+xenforeignmemory_resource_handle *xenforeignmemory_map_resource(
+xenforeignmemory_handle *fmem, domid_t domid, unsigned int type,
+unsigned int id, unsigned long frame, unsigned long nr_frames,
+void **paddr, int prot, int flags)
+{
+xenforeignmemory_resource_handle *fres;
+int rc;
+
+/* Check flags only contains POSIX defined values */
+if ( flags & ~(MAP_SHARED | MAP_PRIVATE) )
+{
+errno = EINVAL;
+return NULL;
+}
+
+fres = calloc(1, sizeof(*fres));
+if ( !fres )
+{
+errno = ENOMEM;
+return NULL;
+}
+
+fres->domid = domid;
+fres->type = type;
+fres->id = id;
+fres->frame = frame;
+fres->nr_frames = nr_frames;
+fres->addr = *paddr;
+fres->prot = prot;
+fres->flags = flags;
+
+rc = osdep_xenforeignmemory_map_resource(fmem, fres);
+if ( rc )
+{
+free(fres);
+fres = NULL;
+} else
+*paddr = fres->addr;
+
+return fres;
+}
+
+int xenforeignmemory_unmap_resource(
+xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
+{
+int rc = osdep_xenforeignmemory_unmap_resource(fmem, fres);
+
+free(fres);
+return rc;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/include/xenforeignmemory.h 
b/tools/libs/foreignmemory/include/xenforeignmemory.h
index f4814c390f..d594be8df0 100644
--- a/tools/libs/foreignmemory/include/xenforeignmemory.h
+++ b/tools/libs/foreignmemory/include/xenforeignmemory.h
@@ -138,6 +138,47 @@ int xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
 int xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
   domid_t domid);
 
+typedef struct xenforeignmemory_resource_handle 
xenforeignmemory_resource_handle;
+
+/**
+ * This function maps a guest resource.
+ *
+ * @parm fmem handle to the open foreignmemory interfac

[Xen-devel] [PATCH v6 00/12] x86: guest resource mapping

[Paul Durrant]

This series introduces support for direct mapping of guest resources.
The resources are:
 - Grant tables
 - IOREQ server pages

NOTE: This series is based on a master re-base of Juergen Gross's patch "xen: 
move
XENMAPSPACE_grant_table code into grant_table.c". For convenience the code is 
also available
on a branch at:

http://xenbits.xen.org/gitweb/?p=people/pauldu/xen.git;a=shortlog;h=refs/heads/ioreq10

v6:
 - Responded to missed comments from Roger
 
v5:
 - Responded to review comments from Wei

v4:
 - Responded to further review comments from Roger

v3:
 - Dropped original patch #1 since it is covered by Juergen's patch.
 - Added new xenforeignmemorycleanup patch (#4).
 - Replaced the patch introducing the ioreq server 'is_default' flag with one
   that changes the ioreq server list into an array (#8).

Paul Durrant (12):
  x86/mm: allow a privileged PV domain to map guest mfns
  x86/mm: add HYPERVISOR_memory_op to acquire guest resources
  tools/libxenforeignmemory: add support for resource mapping
  tools/libxenforeignmemory: reduce xenforeignmemory_restrict code
footprint
  tools/libxenctrl: use new xenforeignmemory API to seed grant table
  x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn
  x86/hvm/ioreq: use bool rather than bool_t
  x86/hvm/ioreq: maintain an array of ioreq servers rather than a list
  x86/hvm/ioreq: simplify code and use consistent naming
  x86/hvm/ioreq: use gfn_t in struct hvm_ioreq_page
  x86/hvm/ioreq: defer mapping gfns until they are actually requsted
  x86/hvm/ioreq: add a new mappable resource type...

 tools/include/xen-sys/Linux/privcmd.h  |  11 +
 tools/libs/devicemodel/core.c  |  18 +-
 tools/libs/devicemodel/include/xendevicemodel.h|  14 +-
 tools/libs/foreignmemory/Makefile  |   2 +-
 tools/libs/foreignmemory/core.c|  53 ++
 tools/libs/foreignmemory/freebsd.c |   7 -
 .../libs/foreignmemory/include/xenforeignmemory.h  |  41 +
 tools/libs/foreignmemory/libxenforeignmemory.map   |   5 +
 tools/libs/foreignmemory/linux.c   |  45 ++
 tools/libs/foreignmemory/minios.c  |   7 -
 tools/libs/foreignmemory/netbsd.c  |   7 -
 tools/libs/foreignmemory/private.h |  43 +-
 tools/libs/foreignmemory/solaris.c |   7 -
 tools/libxc/include/xc_dom.h   |   8 +-
 tools/libxc/xc_dom_boot.c  | 114 ++-
 tools/libxc/xc_sr_restore_x86_hvm.c|  10 +-
 tools/libxc/xc_sr_restore_x86_pv.c |   2 +-
 tools/libxl/libxl_dom.c|   1 -
 tools/python/xen/lowlevel/xc/xc.c  |   6 +-
 xen/arch/x86/hvm/dm.c  |  11 +-
 xen/arch/x86/hvm/hvm.c |   8 +-
 xen/arch/x86/hvm/io.c  |   4 +-
 xen/arch/x86/hvm/ioreq.c   | 869 +++--
 xen/arch/x86/mm.c  | 151 +++-
 xen/arch/x86/mm/p2m.c  |   3 +-
 xen/common/grant_table.c   |  56 +-
 xen/include/asm-x86/hvm/domain.h   |  21 +-
 xen/include/asm-x86/hvm/ioreq.h|  24 +-
 xen/include/asm-x86/p2m.h  |   3 +
 xen/include/public/hvm/dm_op.h |  46 +-
 xen/include/public/memory.h|  41 +-
 xen/include/xen/grant_table.h  |   1 +
 32 files changed, 1081 insertions(+), 558 deletions(-)

---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
-- 
2.11.0


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

[Xen-devel] [PATCH v6 01/12] x86/mm: allow a privileged PV domain to map guest mfns

[Paul Durrant]

In the case where a PV domain is mapping guest resources then it needs make
the HYPERVISOR_mmu_update call using DOMID_SELF, rather than the guest
domid, so that the passed in gmfn values are correctly treated as mfns
rather than gfns present in the guest p2m.

This patch removes a check which currently disallows mapping of a page when
the owner of the page tables matches the domain passed to
HYPERVISOR_mmu_update, but that domain is not the real owner of the page.
The check was introduced by patch d3c6a215ca9 ("x86: Clean up
get_page_from_l1e() to correctly distinguish between owner-of-pte and
owner-of-data-page in all cases") but it's not clear why it was needed.

Signed-off-by: Paul Durrant 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/mm.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index 2e5b15e7a2..cb0189efae 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -1024,12 +1024,15 @@ get_page_from_l1e(
(real_pg_owner != dom_cow) ) )
 {
 /*
- * Let privileged domains transfer the right to map their target
- * domain's pages. This is used to allow stub-domain pvfb export to
- * dom0, until pvfb supports granted mappings. At that time this
- * minor hack can go away.
+ * If the real page owner is not the domain specified in the
+ * hypercall then establish that the specified domain has
+ * mapping privilege over the page owner.
+ * This is used to allow stub-domain pvfb export to dom0. It is
+ * also used to allow a privileged PV domain to map mfns using
+ * DOMID_SELF, which is needed for mapping guest resources such
+ * grant table frames.
  */
-if ( (real_pg_owner == NULL) || (pg_owner == l1e_owner) ||
+if ( (real_pg_owner == NULL) ||
  xsm_priv_mapping(XSM_TARGET, pg_owner, real_pg_owner) )
 {
 gdprintk(XENLOG_WARNING,
-- 
2.11.0


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

[Xen-devel] [PATCH v6 04/12] tools/libxenforeignmemory: reduce xenforeignmemory_restrict code footprint

[Paul Durrant]

By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Removed extraneous freebsd code.

v3:
 - Patch added in response to review comments.
---
 tools/libs/foreignmemory/freebsd.c |  7 ---
 tools/libs/foreignmemory/minios.c  |  7 ---
 tools/libs/foreignmemory/netbsd.c  |  7 ---
 tools/libs/foreignmemory/private.h | 12 +---
 tools/libs/foreignmemory/solaris.c |  7 ---
 5 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/tools/libs/foreignmemory/freebsd.c 
b/tools/libs/foreignmemory/freebsd.c
index dec447485a..6e6bc4b11f 100644
--- a/tools/libs/foreignmemory/freebsd.c
+++ b/tools/libs/foreignmemory/freebsd.c
@@ -95,13 +95,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/minios.c 
b/tools/libs/foreignmemory/minios.c
index 75f340122e..43341ca301 100644
--- a/tools/libs/foreignmemory/minios.c
+++ b/tools/libs/foreignmemory/minios.c
@@ -58,13 +58,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num << PAGE_SHIFT);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/netbsd.c 
b/tools/libs/foreignmemory/netbsd.c
index 9bf95ef4f0..54a418ebd6 100644
--- a/tools/libs/foreignmemory/netbsd.c
+++ b/tools/libs/foreignmemory/netbsd.c
@@ -100,13 +100,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libs/foreignmemory/private.h 
b/tools/libs/foreignmemory/private.h
index 80b22bdbfc..b5d5f0a354 100644
--- a/tools/libs/foreignmemory/private.h
+++ b/tools/libs/foreignmemory/private.h
@@ -32,9 +32,6 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 int osdep_xenforeignmemory_unmap(xenforeignmemory_handle *fmem,
  void *addr, size_t num);
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid);
-
 #if defined(__NetBSD__) || defined(__sun__)
 /* Strictly compat for those two only only */
 void *compat_mapforeign_batch(xenforeignmem_handle *fmem, uint32_t dom,
@@ -54,6 +51,13 @@ struct xenforeignmemory_resource_handle {
 };
 
 #ifndef __linux__
+static inline int osdep_xenforeignmemory_restrict(xenforeignmemory_handle 
*fmem,
+  domid_t domid)
+{
+errno = EOPNOTSUPP;
+return -1;
+}
+
 static inline int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres)
 {
@@ -67,6 +71,8 @@ static inline int osdep_xenforeignmemory_unmap_resource(
 return 0;
 }
 #else
+int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
+domid_t domid);
 int osdep_xenforeignmemory_map_resource(
 xenforeignmemory_handle *fmem, xenforeignmemory_resource_handle *fres);
 int osdep_xenforeignmemory_unmap_resource(
diff --git a/tools/libs/foreignmemory/solaris.c 
b/tools/libs/foreignmemory/solaris.c
index a33decb4ae..ee8aae4fbd 100644
--- a/tools/libs/foreignmemory/solaris.c
+++ b/tools/libs/foreignmemory/solaris.c
@@ -97,13 +97,6 @@ int osdep_xenforeignmemory_unmap(xenforeignmemory_handle 
*fmem,
 return munmap(addr, num*XC_PAGE_SIZE);
 }
 
-int osdep_xenforeignmemory_restrict(xenforeignmemory_handle *fmem,
-domid_t domid)
-{
-errno = -EOPNOTSUPP;
-return -1;
-}
-
 /*
  * Local variables:
  * mode: C
-- 
2.11.0


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

[Xen-devel] [PATCH v6 06/12] x86/hvm/ioreq: rename .*pfn and .*gmfn to .*gfn

[Paul Durrant]

Since ioreq servers are only relevant to HVM guests and all the names in
question unequivocally refer to guest frame numbers, name them all .*gfn
to avoid any confusion.

This patch is purely cosmetic. No semantic or functional change.

Signed-off-by: Paul Durrant 
Reviewed-by: Wei Liu 
Reviewed-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 tools/libs/devicemodel/core.c   | 10 ++--
 tools/libs/devicemodel/include/xendevicemodel.h | 12 ++--
 xen/arch/x86/hvm/dm.c   |  4 +-
 xen/arch/x86/hvm/hvm.c  |  6 +-
 xen/arch/x86/hvm/ioreq.c| 74 -
 xen/include/asm-x86/hvm/domain.h|  4 +-
 xen/include/asm-x86/hvm/ioreq.h |  4 +-
 xen/include/public/hvm/dm_op.h  | 20 +++
 8 files changed, 67 insertions(+), 67 deletions(-)

diff --git a/tools/libs/devicemodel/core.c b/tools/libs/devicemodel/core.c
index d7c6476006..fcb260d29b 100644
--- a/tools/libs/devicemodel/core.c
+++ b/tools/libs/devicemodel/core.c
@@ -174,7 +174,7 @@ int xendevicemodel_create_ioreq_server(
 
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port)
 {
 struct xen_dm_op op;
@@ -192,11 +192,11 @@ int xendevicemodel_get_ioreq_server_info(
 if (rc)
 return rc;
 
-if (ioreq_pfn)
-*ioreq_pfn = data->ioreq_pfn;
+if (ioreq_gfn)
+*ioreq_gfn = data->ioreq_gfn;
 
-if (bufioreq_pfn)
-*bufioreq_pfn = data->bufioreq_pfn;
+if (bufioreq_gfn)
+*bufioreq_gfn = data->bufioreq_gfn;
 
 if (bufioreq_port)
 *bufioreq_port = data->bufioreq_port;
diff --git a/tools/libs/devicemodel/include/xendevicemodel.h 
b/tools/libs/devicemodel/include/xendevicemodel.h
index 580fad2f49..13216db04a 100644
--- a/tools/libs/devicemodel/include/xendevicemodel.h
+++ b/tools/libs/devicemodel/include/xendevicemodel.h
@@ -60,17 +60,17 @@ int xendevicemodel_create_ioreq_server(
  * @parm dmod a handle to an open devicemodel interface.
  * @parm domid the domain id to be serviced
  * @parm id the IOREQ Server id.
- * @parm ioreq_pfn pointer to a xen_pfn_t to receive the synchronous ioreq
- *  gmfn
- * @parm bufioreq_pfn pointer to a xen_pfn_t to receive the buffered ioreq
- *gmfn
+ * @parm ioreq_gfn pointer to a xen_pfn_t to receive the synchronous ioreq
+ *  gfn
+ * @parm bufioreq_gfn pointer to a xen_pfn_t to receive the buffered ioreq
+ *gfn
  * @parm bufioreq_port pointer to a evtchn_port_t to receive the buffered
  * ioreq event channel
  * @return 0 on success, -1 on failure.
  */
 int xendevicemodel_get_ioreq_server_info(
 xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
-xen_pfn_t *ioreq_pfn, xen_pfn_t *bufioreq_pfn,
+xen_pfn_t *ioreq_gfn, xen_pfn_t *bufioreq_gfn,
 evtchn_port_t *bufioreq_port);
 
 /**
@@ -168,7 +168,7 @@ int xendevicemodel_destroy_ioreq_server(
  * This function sets IOREQ Server state. An IOREQ Server
  * will not be passed emulation requests until it is in
  * the enabled state.
- * Note that the contents of the ioreq_pfn and bufioreq_pfn are
+ * Note that the contents of the ioreq_gfn and bufioreq_gfn are
  * not meaningful until the IOREQ Server is in the enabled state.
  *
  * @parm dmod a handle to an open devicemodel interface.
diff --git a/xen/arch/x86/hvm/dm.c b/xen/arch/x86/hvm/dm.c
index 4cf6deedc7..f7cb883fec 100644
--- a/xen/arch/x86/hvm/dm.c
+++ b/xen/arch/x86/hvm/dm.c
@@ -426,8 +426,8 @@ static int dm_op(const struct dmop_args *op_args)
 break;
 
 rc = hvm_get_ioreq_server_info(d, data->id,
-   &data->ioreq_pfn,
-   &data->bufioreq_pfn,
+   &data->ioreq_gfn,
+   &data->bufioreq_gfn,
&data->bufioreq_port);
 break;
 }
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 6cb903def5..58b4afa1d1 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4185,20 +4185,20 @@ static int hvmop_set_param(
 rc = -EINVAL;
 break;
 case HVM_PARAM_IOREQ_SERVER_PFN:
-d->arch.hvm_domain.ioreq_gmfn.base = a.value;
+d->arch.hvm_domain.ioreq_gfn.base = a.value;
 break;
 case HVM_PARAM_NR_IOREQ_SERVER_PAGES:
 {
 unsigned int i;
 
 if ( a.value == 0 ||
- a.value > sizeof(d->arch.hvm_domain.ioreq_gmfn.mask) * 8 )
+ a.value > sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8 )
 {
 rc = -EINVAL;
 break;
 }
 for ( i = 0; i < a.value; i++ )
-   

[Xen-devel] [PATCH v6 08/12] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

[Paul Durrant]

A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.

It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies the code to maintain an array of
that size rather than using a list.

Also, by reserving an array slot for the default server and populating
array slots early in create, the need to pass an 'is_default' boolean
to sub-functions can be avoided.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v6:
 - Updated according to comments made by Roger on v4 that I'd missed.

v5:
 - Switched GET/SET_IOREQ_SERVER() macros to get/set_ioreq_server()
   functions to avoid possible double-evaluation issues.

v4:
 - Introduced more helper macros and relocated them to the top of the
   code.

v3:
 - New patch (replacing "move is_default into struct hvm_ioreq_server") in
   response to review comments.
---
 xen/arch/x86/hvm/ioreq.c | 512 +++
 xen/include/asm-x86/hvm/domain.h |  11 +-
 2 files changed, 261 insertions(+), 262 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index f2e0b3f74a..be66870d46 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -33,6 +33,32 @@
 
 #include 
 
+static void set_ioreq_server(struct domain *d, unsigned int id,
+ struct hvm_ioreq_server *s)
+{
+ASSERT(id < MAX_NR_IOREQ_SERVERS);
+ASSERT(!d->arch.hvm_domain.ioreq_server.server[id]);
+
+d->arch.hvm_domain.ioreq_server.server[id] = s;
+}
+
+static struct hvm_ioreq_server *get_ioreq_server(struct domain *d,
+ unsigned int id)
+{
+if ( id >= MAX_NR_IOREQ_SERVERS )
+return NULL;
+
+return d->arch.hvm_domain.ioreq_server.server[id];
+}
+
+#define IS_DEFAULT(s) \
+((s) == get_ioreq_server((s)->domain, DEFAULT_IOSERVID))
+
+#define FOR_EACH_IOREQ_SERVER(d, id, s) \
+for ( (id) = 0, (s) = get_ioreq_server((d), (id)); \
+  (id) < MAX_NR_IOREQ_SERVERS; \
+  (s) = get_ioreq_server((d), ++(id)) )
+
 static ioreq_t *get_ioreq(struct hvm_ioreq_server *s, struct vcpu *v)
 {
 shared_iopage_t *p = s->ioreq.va;
@@ -47,13 +73,15 @@ bool hvm_io_pending(struct vcpu *v)
 {
 struct domain *d = v->domain;
 struct hvm_ioreq_server *s;
+unsigned int id;
 
-list_for_each_entry ( s,
-  &d->arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
+if ( !s )
+continue;
+
 list_for_each_entry ( sv,
   &s->ioreq_vcpu_list,
   list_entry )
@@ -127,13 +155,15 @@ bool handle_hvm_io_completion(struct vcpu *v)
 struct hvm_vcpu_io *vio = &v->arch.hvm_vcpu.hvm_io;
 struct hvm_ioreq_server *s;
 enum hvm_io_completion io_completion;
+unsigned int id;
 
-  list_for_each_entry ( s,
-  &d->arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
 struct hvm_ioreq_vcpu *sv;
 
+if ( !s )
+continue;
+
 list_for_each_entry ( sv,
   &s->ioreq_vcpu_list,
   list_entry )
@@ -243,14 +273,16 @@ static int hvm_map_ioreq_page(
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
 {
 const struct hvm_ioreq_server *s;
+unsigned int id;
 bool found = false;
 
 spin_lock_recursive(&d->arch.hvm_domain.ioreq_server.lock);
 
-list_for_each_entry ( s,
-  &d->arch.hvm_domain.ioreq_server.list,
-  list_entry )
+FOR_EACH_IOREQ_SERVER(d, id, s)
 {
+if ( !s )
+continue;
+
 if ( (s->ioreq.va && s->ioreq.page == page) ||
  (s->bufioreq.va && s->bufioreq.page == page) )
 {
@@ -301,8 +333,9 @@ static void hvm_update_ioreq_evtchn(struct hvm_ioreq_server 
*s,
 }
 }
 
+
 static int hvm_ioreq_server_add_vcpu(struct hvm_ioreq_server *s,
- bool is_default, struct vcpu *v)
+ struct vcpu *v)
 {
 struct hvm_ioreq_vcpu *sv;
 int rc;
@@ -331,7 +364,7 @@ static int hvm_ioreq_server_add_vcpu(struct 
hvm_ioreq_server *s,
 goto fail3;
 
 s->bufioreq_evtchn = rc;
-if ( is_default )
+if ( IS_DEFAULT(s) )
 d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_EVTCHN] =
 s->bufioreq_evtchn;
 }
@@ -431,7 +464,6 @@ static int hvm_ioreq_server_map_pages(struct 
hvm_ioreq_server *s,
 }
 
 static int hvm_ioreq_server_setup_pages(struct hvm_ioreq_server *s,
-  

[Xen-devel] [PATCH v6 05/12] tools/libxenctrl: use new xenforeignmemory API to seed grant table

[Paul Durrant]

A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).

This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in which
case the old scheme is used.

NOTE: The call to xc_dom_gnttab_hvm_seed() in hvm_build_set_params() was
  actually unnecessary, as the grant table has already been seeded
  by a prior call to xc_dom_gnttab_init() made by libxl__build_dom().

Signed-off-by: Paul Durrant 
Acked-by: Marek Marczykowski-Górecki 
Reviewed-by: Roger Pau Monné 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 

v4:
 - Minor cosmetic fix suggested by Roger.

v3:
 - Introduced xc_dom_set_gnttab_entry() to avoid duplicated code.
---
 tools/libxc/include/xc_dom.h|   8 +--
 tools/libxc/xc_dom_boot.c   | 114 +---
 tools/libxc/xc_sr_restore_x86_hvm.c |  10 ++--
 tools/libxc/xc_sr_restore_x86_pv.c  |   2 +-
 tools/libxl/libxl_dom.c |   1 -
 tools/python/xen/lowlevel/xc/xc.c   |   6 +-
 6 files changed, 92 insertions(+), 49 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ce47058c41..d6ca0a8680 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -323,12 +323,8 @@ void *xc_dom_boot_domU_map(struct xc_dom_image *dom, 
xen_pfn_t pfn,
 int xc_dom_boot_image(struct xc_dom_image *dom);
 int xc_dom_compat_check(struct xc_dom_image *dom);
 int xc_dom_gnttab_init(struct xc_dom_image *dom);
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid);
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
+int xc_dom_gnttab_seed(xc_interface *xch, domid_t guest_domid,
+   bool is_hvm,
xen_pfn_t console_gmfn,
xen_pfn_t xenstore_gmfn,
domid_t console_domid,
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index c3b44dd399..dc0a1fdee8 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -280,11 +280,29 @@ static xen_pfn_t xc_dom_gnttab_setup(xc_interface *xch, 
domid_t domid)
 return gmfn;
 }
 
-int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gmfn,
-   xen_pfn_t xenstore_gmfn,
-   domid_t console_domid,
-   domid_t xenstore_domid)
+static void xc_dom_set_gnttab_entry(xc_interface *xch,
+grant_entry_v1_t *gnttab,
+unsigned int idx,
+domid_t guest_domid,
+domid_t backend_domid,
+xen_pfn_t backend_gmfn)
+{
+if ( guest_domid == backend_domid || backend_gmfn == -1)
+return;
+
+xc_dom_printf(xch, "%s: [%u] -> 0x%"PRI_xen_pfn,
+  __FUNCTION__, idx, backend_gmfn);
+
+gnttab[idx].flags = GTF_permit_access;
+gnttab[idx].domid = backend_domid;
+gnttab[idx].frame = backend_gmfn;
+}
+
+static int compat_gnttab_seed(xc_interface *xch, domid_t domid,
+  xen_pfn_t console_gmfn,
+  xen_pfn_t xenstore_gmfn,
+  domid_t console_domid,
+  domid_t xenstore_domid)
 {
 
 xen_pfn_t gnttab_gmfn;
@@ -308,18 +326,10 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return -1;
 }
 
-if ( domid != console_domid  && console_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_CONSOLE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_CONSOLE].domid = console_domid;
-gnttab[GNTTAB_RESERVED_CONSOLE].frame = console_gmfn;
-}
-if ( domid != xenstore_domid && xenstore_gmfn != -1)
-{
-gnttab[GNTTAB_RESERVED_XENSTORE].flags = GTF_permit_access;
-gnttab[GNTTAB_RESERVED_XENSTORE].domid = xenstore_domid;
-gnttab[GNTTAB_RESERVED_XENSTORE].frame = xenstore_gmfn;
-}
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_CONSOLE,
+domid, console_domid, console_gmfn);
+xc_dom_set_gnttab_entry(xch, gnttab, GNTTAB_RESERVED_XENSTORE,
+domid, xenstore_domid, xenstore_gmfn);
 
 if ( munmap(gnttab, PAGE_SIZE) == -1 )
 {
@@ -337,11 +347,11 @@ int xc_dom_gnttab_seed(xc_interface *xch, domid_t domid,
 return 0;
 }
 
-int xc_dom_gnttab_hvm_seed(xc_interface *xch, domid_t domid,
-   xen_pfn_t console_gpfn,
-   xen_pfn_t xenstore_gpfn,
-   domid_t console_domid,
-

[Xen-devel] [PATCH v6 09/12] x86/hvm/ioreq: simplify code and use consistent naming

[Paul Durrant]

This patch re-works much of the ioreq server initialization and teardown
code:

- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
  to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
  separately by outer functions.
- Several functions now test the validity of the hvm_ioreq_page gfn value
  to determine whether they need to act. This means can be safely called
  for the bufioreq page even when it is not used.
- hvm_add/remove_ioreq_gfn() simply return in the case of the default
  IOREQ server so callers no longer need to test before calling.
- hvm_ioreq_server_setup_pages() is renamed to hvm_ioreq_server_map_pages()
  to mirror the existing hvm_ioreq_server_unmap_pages().

All of this significantly shortens the code.

Signed-off-by: Paul Durrant 
Reviewed-by: Roger Pau Monné 
Reviewed-by: Wei Liu 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 

v3:
 - Rebased on top of 's->is_default' to 'IS_DEFAULT(s)' changes.
 - Minor updates in response to review comments from Roger.
---
 xen/arch/x86/hvm/ioreq.c | 183 ++-
 1 file changed, 69 insertions(+), 114 deletions(-)

diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
index be66870d46..18598a77ad 100644
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -211,63 +211,75 @@ bool handle_hvm_io_completion(struct vcpu *v)
 return true;
 }
 
-static int hvm_alloc_ioreq_gfn(struct domain *d, unsigned long *gfn)
+static unsigned long hvm_alloc_ioreq_gfn(struct hvm_ioreq_server *s)
 {
+struct domain *d = s->domain;
 unsigned int i;
-int rc;
 
-rc = -ENOMEM;
+ASSERT(!IS_DEFAULT(s));
+
 for ( i = 0; i < sizeof(d->arch.hvm_domain.ioreq_gfn.mask) * 8; i++ )
 {
 if ( test_and_clear_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask) )
-{
-*gfn = d->arch.hvm_domain.ioreq_gfn.base + i;
-rc = 0;
-break;
-}
+return d->arch.hvm_domain.ioreq_gfn.base + i;
 }
 
-return rc;
+return gfn_x(INVALID_GFN);
 }
 
-static void hvm_free_ioreq_gfn(struct domain *d, unsigned long gfn)
+static void hvm_free_ioreq_gfn(struct hvm_ioreq_server *s,
+   unsigned long gfn)
 {
+struct domain *d = s->domain;
 unsigned int i = gfn - d->arch.hvm_domain.ioreq_gfn.base;
 
-if ( gfn != gfn_x(INVALID_GFN) )
-set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
+ASSERT(!IS_DEFAULT(s));
+ASSERT(gfn != gfn_x(INVALID_GFN));
+
+set_bit(i, &d->arch.hvm_domain.ioreq_gfn.mask);
 }
 
-static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool buf)
+static void hvm_unmap_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
 
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return;
+
 destroy_ring_for_helper(&iorp->va, iorp->page);
+iorp->page = NULL;
+
+if ( !IS_DEFAULT(s) )
+hvm_free_ioreq_gfn(s, iorp->gfn);
+
+iorp->gfn = gfn_x(INVALID_GFN);
 }
 
-static int hvm_map_ioreq_page(
-struct hvm_ioreq_server *s, bool buf, unsigned long gfn)
+static int hvm_map_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
 {
 struct domain *d = s->domain;
 struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
-struct page_info *page;
-void *va;
 int rc;
 
-if ( (rc = prepare_ring_for_helper(d, gfn, &page, &va)) )
-return rc;
-
-if ( (iorp->va != NULL) || d->is_dying )
-{
-destroy_ring_for_helper(&va, page);
+if ( d->is_dying )
 return -EINVAL;
-}
 
-iorp->va = va;
-iorp->page = page;
-iorp->gfn = gfn;
+if ( IS_DEFAULT(s) )
+iorp->gfn = buf ?
+d->arch.hvm_domain.params[HVM_PARAM_BUFIOREQ_PFN] :
+d->arch.hvm_domain.params[HVM_PARAM_IOREQ_PFN];
+else
+iorp->gfn = hvm_alloc_ioreq_gfn(s);
+
+if ( iorp->gfn == gfn_x(INVALID_GFN) )
+return -ENOMEM;
 
-return 0;
+rc = prepare_ring_for_helper(d, iorp->gfn, &iorp->page, &iorp->va);
+
+if ( rc )
+hvm_unmap_ioreq_gfn(s, buf);
+
+return rc;
 }
 
 bool is_ioreq_server_page(struct domain *d, const struct page_info *page)
@@ -283,8 +295,7 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 if ( !s )
 continue;
 
-if ( (s->ioreq.va && s->ioreq.page == page) ||
- (s->bufioreq.va && s->bufioreq.page == page) )
+if ( (s->ioreq.page == page) || (s->bufioreq.page == page) )
 {
 found = true;
 break;
@@ -296,20 +307,30 @@ bool is_ioreq_server_page(struct domain *d, const struct 
page_info *page)
 return found;
 }
 
-static void hvm_remove_ioreq_gfn(
-struct domain *d, struct hvm_ioreq_page *iorp)
+static void hvm_remove_ioreq_gfn(struct hvm_ioreq_server *s, bool buf)
+
 {
+struct domain *d = s->domain;
+struct hvm_ioreq_page *iorp = buf ? &s->bu

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Juergen Gross]

On 12/09/17 18:05, Boris Ostrovsky wrote:
> On 09/12/2017 11:50 AM, Juergen Gross wrote:
>> On 12/09/17 17:44, Boris Ostrovsky wrote:
>>> On 09/08/2017 10:48 AM, Juergen Gross wrote:
 As there is currently no user for sub-page grants or transient grants
 remove that functionality. This at once makes it possible to switch
 from grant v2 to grant v1 without restrictions, as there is no loss of
 functionality other than the limited frame number width related to
 the switch.
>>> But isn't that ABI violation? v2 is expected to support this (XSAs
>>> notwithstanding)
>> No, I don't think so.
>>
>> The hypervisor still supports it, but the domU (or dom0) isn't required
>> to make use of all the features IMHO. Or are you aware of any backend
>> querying the grant version of a frontend and acting in another way if v2
>> is detected?
> 
> I am not aware of any but that doesn't mean that they don't (or won't)
> exist.

But isn't the frontend the one which is defining what is granted in
which way? How should there be an ABI breakage when the frontend just
isn't using sub-page or transitive grants?


Juergen

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

Re: [Xen-devel] [PATCH 7/7] x86/mm: Prevent 32bit PV guests using out-of-range linear addresses

[Andrew Cooper]

On 12/09/17 16:50, Jan Beulich wrote:
 On 12.09.17 at 14:14,  wrote:
>> The grant ABI uses 64 bit values, and allows a PV guest to specify linear
>> addresses.  There is nothing interesting a 32bit PV guest can reference which
>> will pass an __addr_ok() check, but it should still get an error for trying.
> While I'm all for tightening checks, I'm not sure we reasonably can:
> Existing guests may (perhaps inadvertently) rely on this behavior,
> and hence may break with the change. I think a prereq to this is to
> have a command line option (or even a per-guest one) to control
> strict vs relaxed argument checking behavior, and tie the extra
> checks to that option being true.

At the moment, any attempt to use this behaviour will still cause a
general error, because we cant locate an L1e mapping the out-of-range
linear address.  Therefore, the guest wouldn't have had the grant
operation succeed before.

The problem is that its a latent security bug if we ever chose to reuse
these ranges for other purposes.

E.g. One idea I've had for a while is to move the XLAT translation logic
into guest mode, accessed via a modification to the hypercall page. 
This would mitigate security issues such as infinite loops or boundary
overflows, both of which we've had in the XLAT logic in the past.

~Andrew

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

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Boris Ostrovsky]

On 09/12/2017 11:50 AM, Juergen Gross wrote:
> On 12/09/17 17:44, Boris Ostrovsky wrote:
>> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>>> As there is currently no user for sub-page grants or transient grants
>>> remove that functionality. This at once makes it possible to switch
>>> from grant v2 to grant v1 without restrictions, as there is no loss of
>>> functionality other than the limited frame number width related to
>>> the switch.
>> But isn't that ABI violation? v2 is expected to support this (XSAs
>> notwithstanding)
> No, I don't think so.
>
> The hypervisor still supports it, but the domU (or dom0) isn't required
> to make use of all the features IMHO. Or are you aware of any backend
> querying the grant version of a frontend and acting in another way if v2
> is detected?

I am not aware of any but that doesn't mean that they don't (or won't)
exist.

-boris

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

Re: [Xen-devel] [PATCH 3/4] xen: add grant interface version dependent constants to gnttab_ops

[Boris Ostrovsky]

On 09/08/2017 10:48 AM, Juergen Gross wrote:
> Instead of having multiple variables with constants like
> grant_table_version or grefs_per_grant_frame add those to struct
> gnttab_ops and access them just via the gnttab_interface pointer.
>
> Signed-off-by: Juergen Gross 


One possible suggestion --- define gnttab_sframes() inline and get rid
of RPP/SPP.

But either way:
Reviewed-by: Boris Ostrovsky 

-boris



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

Re: [Xen-devel] [PATCH 0/2] public/*ctl: drop unnecessary typedefs and handles

[Wei Liu]

On Tue, Sep 12, 2017 at 08:25:47AM -0600, Jan Beulich wrote:
> 1: public/domctl: drop unnecessary typedefs and handles
> 2: public/sysctl: drop unnecessary typedefs and handles
> 
> Signed-off-by: Jan Beulich 
> 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/2] public/domctl: drop unnecessary typedefs and handles

[Dario Faggioli]

On Tue, 2017-09-12 at 09:08 -0600, Jan Beulich wrote:
> By virtue of the struct xen_domctl container structure, most of them
> are really just cluttering the name space.
> 
> While doing so,
> - convert an enum typed (pt_irq_type_t) structure field to a fixed
>   width type,
> - make x86's paging_domctl() and descendants take a properly typed
>   handle,
> - add const in a few places.
> 
> Signed-off-by: Jan Beulich 
> 
Acked-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/2] public/sysctl: drop unnecessary typedefs and handles

[Dario Faggioli]

On Tue, 2017-09-12 at 09:10 -0600, Jan Beulich wrote:
> By virtue of the struct xen_sysctl container structure, most of them
> are really just cluttering the name space.
> 
> Signed-off-by: Jan Beulich 
>
Acked-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Juergen Gross]

On 12/09/17 17:44, Boris Ostrovsky wrote:
> On 09/08/2017 10:48 AM, Juergen Gross wrote:
>> As there is currently no user for sub-page grants or transient grants
>> remove that functionality. This at once makes it possible to switch
>> from grant v2 to grant v1 without restrictions, as there is no loss of
>> functionality other than the limited frame number width related to
>> the switch.
> 
> But isn't that ABI violation? v2 is expected to support this (XSAs
> notwithstanding)

No, I don't think so.

The hypervisor still supports it, but the domU (or dom0) isn't required
to make use of all the features IMHO. Or are you aware of any backend
querying the grant version of a frontend and acting in another way if v2
is detected?


Juergen


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

Re: [Xen-devel] [PATCH 7/7] x86/mm: Prevent 32bit PV guests using out-of-range linear addresses

[Jan Beulich]

>>> On 12.09.17 at 14:14,  wrote:
> The grant ABI uses 64 bit values, and allows a PV guest to specify linear
> addresses.  There is nothing interesting a 32bit PV guest can reference which
> will pass an __addr_ok() check, but it should still get an error for trying.

While I'm all for tightening checks, I'm not sure we reasonably can:
Existing guests may (perhaps inadvertently) rely on this behavior,
and hence may break with the change. I think a prereq to this is to
have a command line option (or even a per-guest one) to control
strict vs relaxed argument checking behavior, and tie the extra
checks to that option being true.

Jan


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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Jan Beulich]

>>> On 12.09.17 at 14:14,  wrote:
> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned 
> long frame,
>  {
>  struct vcpu *curr = current;
>  struct domain *currd = curr->domain;
> -l1_pgentry_t ol1e;
> -int rc;
> +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
> +struct page_info *page;
> +mfn_t gl1mfn;
> +int rc = GNTST_general_error;
>  unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>  
>  /*
> - * On top of the explicit settings done by create_grant_host_mapping()
> + * On top of the explicit settings done by create_pv_host_mapping()

create_grant_pv_mapping()

Other than that
Reviewed-by: Jan Beulich 

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-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  16b1414de91b5a82a0996c67f6db3af7d7e32873
baseline version:
 xen  19cee44abfdf162a25d86f999d9a50bcfdf468bc

Last test of basis   113362  2017-09-12 11:01:28 Z0 days
Testing same since   113372  2017-09-12 14:01:13 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  George Dunlap 
  Jan Beulich 
  Juergen Gross 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=16b1414de91b5a82a0996c67f6db3af7d7e32873
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
16b1414de91b5a82a0996c67f6db3af7d7e32873
+ branch=xen-unstable-smoke
+ revision=16b1414de91b5a82a0996c67f6db3af7d7e32873
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.:.
 PERLLIB=.:.:.
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
+++ export PERLLIB=.:.:.:.
+++ PERLLIB=.:.:.:.
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x16b1414de91b5a82a0996c67f6db3af7d7e32873 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.

Re: [Xen-devel] [PATCH 1/4] xen: re-introduce support for grant v2 interface

[Juergen Gross]

On 12/09/17 17:41, Boris Ostrovsky wrote:
> 
>> +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
>> +   unsigned long max_nr_gframes,
>> +   grant_status_t **__shared)
>> +{
>> +grant_status_t *shared = *__shared;
>> +unsigned long addr;
>> +unsigned long i;
>> +
>> +if (shared == NULL)
>> +*__shared = shared = gnttab_status_vm_area.area->addr;
>> +
>> +addr = (unsigned long)shared;
>> +
>> +for (i = 0; i < nr_gframes; i++) {
>> +set_pte_at(&init_mm, addr, gnttab_status_vm_area.ptes[i],
>> +   mfn_pte(frames[i], PAGE_KERNEL));
>> +addr += PAGE_SIZE;
>> +}
>> +
>> +return 0;
>> +}
> 
> This looks pretty much identical to arch_gnttab_map_shared() except for
> gnttab_shared_vm_area vs. gnttab_status_vm_area,which can be passed in
> as a parameter.
> 
>> +
>>  void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
>>  {
>> +pte_t **ptes;
>>  unsigned long addr;
>>  unsigned long i;
>>  
>> +if (shared == gnttab_status_vm_area.area->addr)
>> +ptes = gnttab_status_vm_area.ptes;
>> +else
>> +ptes = gnttab_shared_vm_area.ptes;
>> +
>>  addr = (unsigned long)shared;
>>  
>>  for (i = 0; i < nr_gframes; i++) {
>> -set_pte_at(&init_mm, addr, gnttab_shared_vm_area.ptes[i],
>> -   __pte(0));
>> +set_pte_at(&init_mm, addr, ptes[i], __pte(0));
>>  addr += PAGE_SIZE;
>>  }
> 
> And this too looks like can be factored out (to something like
> arch_update_gnttab()). But perhaps not in this patch.
> 
>>  }
>> @@ -102,12 +129,35 @@ static int arch_gnttab_valloc(struct gnttab_vm_area 
>> *area, unsigned nr_frames)
>>  return 0;
>>  }
>>  
>> -int arch_gnttab_init(unsigned long nr_shared)
>> +static void arch_gnttab_vfree(struct gnttab_vm_area *area)
>>  {
>> +free_vm_area(area->area);
>> +kfree(area->ptes);
>> +}
> 
> Not sure there is need for this routine. It is used only once.
> 
> Also, as an overall comment -- It feels like there may be too many
> BUG_ON()s.

This patch is mostly a revert of David's patch removing grant v2 support
with just very few adaptions. I wanted to keep it as similar to the
former grant v2 support as possible.


Juergen

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

Re: [Xen-devel] [PATCH 2/4] xen: limit grant v2 interface to the v1 functionality

[Boris Ostrovsky]

On 09/08/2017 10:48 AM, Juergen Gross wrote:
> As there is currently no user for sub-page grants or transient grants
> remove that functionality. This at once makes it possible to switch
> from grant v2 to grant v1 without restrictions, as there is no loss of
> functionality other than the limited frame number width related to
> the switch.

But isn't that ABI violation? v2 is expected to support this (XSAs
notwithstanding)

-boris

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

Re: [Xen-devel] [PATCH 5/7] x86/mm: Carve steal_linear_address() out of replace_grant_host_mapping()

[Jan Beulich]

>>> On 12.09.17 at 16:19,  wrote:
> On Tue, Sep 12, 2017 at 01:14:44PM +0100, Andrew Cooper wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -4075,14 +4075,68 @@ int create_grant_pv_mapping(uint64_t addr, unsigned 
>> long frame,
>>  return rc;
>>  }
>>  
>> -int replace_grant_pv_mapping(uint64_t addr, unsigned long frame,
>> - uint64_t new_addr, unsigned int flags)
>> +/*
>> + * This exists soley for implementing GNTABOP_unmap_and_replace, the ABI of
>> + * which is bizare.  This GNTTABOP isn't used any more, but was used by
> 
> Should be "bizarre".
> 
>> + * classic-xen kernels and PVOps Linux before the M2P_OVERRIDE 
>> infrastructure
>> + * was replaced with something which actually worked.
>> + *
>> + * Look up the L1e mapping linear, and zap it.  Return the L1e via *out.
>> + * Returns a boolean indicating success.  If success, the caller is
>> + * responsible for calling put_page_from_l1e().
>> + */
> 
> Can't say much about the history; code-wise:
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/4] xen: re-introduce support for grant v2 interface

[Boris Ostrovsky]

> +int arch_gnttab_map_status(uint64_t *frames, unsigned long nr_gframes,
> +unsigned long max_nr_gframes,
> +grant_status_t **__shared)
> +{
> + grant_status_t *shared = *__shared;
> + unsigned long addr;
> + unsigned long i;
> +
> + if (shared == NULL)
> + *__shared = shared = gnttab_status_vm_area.area->addr;
> +
> + addr = (unsigned long)shared;
> +
> + for (i = 0; i < nr_gframes; i++) {
> + set_pte_at(&init_mm, addr, gnttab_status_vm_area.ptes[i],
> +mfn_pte(frames[i], PAGE_KERNEL));
> + addr += PAGE_SIZE;
> + }
> +
> + return 0;
> +}

This looks pretty much identical to arch_gnttab_map_shared() except for
gnttab_shared_vm_area vs. gnttab_status_vm_area,which can be passed in
as a parameter.

> +
>  void arch_gnttab_unmap(void *shared, unsigned long nr_gframes)
>  {
> + pte_t **ptes;
>   unsigned long addr;
>   unsigned long i;
>  
> + if (shared == gnttab_status_vm_area.area->addr)
> + ptes = gnttab_status_vm_area.ptes;
> + else
> + ptes = gnttab_shared_vm_area.ptes;
> +
>   addr = (unsigned long)shared;
>  
>   for (i = 0; i < nr_gframes; i++) {
> - set_pte_at(&init_mm, addr, gnttab_shared_vm_area.ptes[i],
> -__pte(0));
> + set_pte_at(&init_mm, addr, ptes[i], __pte(0));
>   addr += PAGE_SIZE;
>   }

And this too looks like can be factored out (to something like
arch_update_gnttab()). But perhaps not in this patch.

>  }
> @@ -102,12 +129,35 @@ static int arch_gnttab_valloc(struct gnttab_vm_area 
> *area, unsigned nr_frames)
>   return 0;
>  }
>  
> -int arch_gnttab_init(unsigned long nr_shared)
> +static void arch_gnttab_vfree(struct gnttab_vm_area *area)
>  {
> + free_vm_area(area->area);
> + kfree(area->ptes);
> +}

Not sure there is need for this routine. It is used only once.

Also, as an overall comment -- It feels like there may be too many
BUG_ON()s.


-boris

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

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

[osstest service owner]

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

Regressions :-(

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

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

version targeted for testing:
 ovmf b4e5807d2492efd9fc453b0a09a50f4c3ae77be1
baseline version:
 ovmf 3281ebb4ae7de2a858c2e7ec4998b7e55be1a4dc

Last test of basis   113143  2017-09-08 06:17:14 Z4 days
Failing since113156  2017-09-08 19:17:56 Z3 days   24 attempts
Testing same since   113360  2017-09-12 10:17:05 Z0 days1 attempts


People who touched revisions under test:
  Bi, Dandan 
  Brijesh Singh 
  Dandan Bi 
  Hegde Nagaraj P 
  hegdenag 
  Jiaxin Wu 
  Laszlo Ersek 
  Paulo Alcantara 
  Star Zeng 
  Thomas Lamprecht 
  Wu Jiaxin 
  Yonghong Zhu 

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



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH RFC v2] Add SUPPORT.md

[Rich Persaud]

> On Sep 11, 2017, at 13:01, George Dunlap  wrote:
> 
> +### XSM & FLASK
> +
> +Status: Experimental
> +
> +Compile time disabled
> +
> +### XSM & FLASK support for IS_PRIV
> +
> +Status: Experimental

In which specific areas is XSM lacking in Functional completeness, Functional 
stability and/or Interface stability, resulting in "Experimental" status?  What 
changes to XSM would be needed for it to qualify for "Supported" status?

If there will be no security support for features in Experimental status, would 
Xen Project accept patches to fix XSM security issues?  Could downstream 
projects issue CVEs for XSM security issues, if these will not be issued by Xen 
Project?

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

Re: [Xen-devel] [PATCH 1/2] public/domctl: drop unnecessary typedefs and handles

[Razvan Cojocaru]

On 09/12/2017 06:08 PM, Jan Beulich wrote:
> By virtue of the struct xen_domctl container structure, most of them
> are really just cluttering the name space.
> 
> While doing so,
> - convert an enum typed (pt_irq_type_t) structure field to a fixed
>   width type,
> - make x86's paging_domctl() and descendants take a properly typed
>   handle,
> - add const in a few places.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Razvan Cojocaru 


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 4/7] x86/mm: Combine create_grant_{pte, va}_mapping()

[Jan Beulich]

>>> On 12.09.17 at 14:14,  wrote:
> create_grant_{pte,va}_mapping() are nearly identical; all that is really
> different between them is how they convert their addr parameter to the pte to
> install the grant into.
> 
> Reimplement their logic in create_grant_pv_mapping() in a mostly common way.
> 
> No (intended) change in behaviour from a guests point of view.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 



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

Re: [Xen-devel] USB passthrough with Xen on ARM

[Juergen Gross]

On 12/09/17 17:08, Julien Grall wrote:
> Hello,
> 
> On 12/09/17 12:22, Roger Quadros wrote:
>>
>> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
>> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>>
>> On 12/09/17 13:57, Julien Grall wrote:
>>> Hi,
>>>
>>> On 12/09/17 11:00, Juergen Gross wrote:
 On 12/09/17 10:13, Roger Quadros wrote:
> Hi,
>
> I'm running Xen v4.9 on DRA7 (OMAP5/ArmV7) with Linux kernel v3.14
> (yikes!!) on dom0 and domU.
> I'm struggling to get USB passthrough working using pvUSB.
>
> My domU config file contains
>  usb = 1
>  usbctrl = ['type=qusb,version=2,ports=4',
> 'type=qusb,version=1, ports=4', ]
>
> I can see the vusb-0 and vusb-1 platform devices in /sys/devices
>
> And the following message on domU kernel log
> [    1.849572] xenbus_probe_frontend: Device with no driver:
> device/vusb/0
> [    1.849627] xenbus_probe_frontend: Device with no driver:
> device/vusb/1
>
> This means that there is no device driver for the vusb host
> controllers.
>
> What is the way forward? Do I need to apply some patches to the
> domU kernel to
> add support for the USB frontend HCD drivers?

 This is one mandatory step, yes. You'll need:

 https://lkml.org/lkml/2015/6/23/34
 https://lkml.org/lkml/2015/6/23/36

>>
>> OK, after applying the above 2 patches to v4.12 kernel for domU I'm
>> able to see the xen HCD driver
>> enumerate, but it times out most likely due to the missing pvusb backend.
>>
>> [    0.510149] vusb vusb-0: Xen USB2.0 Virtual Host Controller
>> [    0.510192] vusb vusb-0: new USB bus registered, assigned bus number 1
>> [    0.510811] hub 1-0:1.0: USB hub found
>> [    0.510865] hub 1-0:1.0: 4 ports detected
>> [    0.812721] vusb vusb-1: Xen USB1.1 Virtual Host Controller
>> [    0.812760] vusb vusb-1: new USB bus registered, assigned bus number 2
>> [    0.813356] hub 2-0:1.0: USB hub found
>> [    0.813410] hub 2-0:1.0: 4 ports detected
>>
>> ...
>>
>> [    5.888997] xenbus_probe_frontend: Waiting for devices to
>> initialise: 25s...20s...15s...10s...5s...0s...
>> [   35.919000]
>> 235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
>>
>> [  270.879130]
>> [  270.884161] xenbus_probe_frontend: Timeout connecting to device:
>> device/vusb/0 (local state 1, remote state 1)
>> [  270.887059] xenbus_probe_frontend: Timeout connecting to device:
>> device/vusb/1 (local state 1, remote state 1)
>>
 The question is whether this will be enough for you to make it work:
 the
 pvusb backend is qemu based. I'm not sure this will just work on ARM.
>>>
>>> Backends in QEMU should just work with ARM. Although, I haven't tried
>>> the PVUSB one.
>>>
>>
>> Newbie question now. How do I start the QEMU pvusb backend on dom0?
> 
> If I am not mistaken, the backend should be started by
> "/etc/init.d/xencommons start" which also start xenstore and all the
> userspace components for Xen.

No, it should be started by libxl as a per-domain device model.

> So you should have a QEMU running in Dom0. Can you check if it is the case?

You should see whether the device model is started by doing

xl -vvv create ...

When the domain has been started you can call

xenstore-ls

to see whether there are any device model related xenstore entries.
There should be some like:

/local/domain/0/device-model//backends/

 being "qusb" is the one you will need.

> Also, I would check that QEMU has been built with the PV USB backend. It
> depends on libusb. I am not entirely sure if the build system will
> require it and will therefore fault if it is not installed.

It won't. It will disable the backend without libusb being available.

> Juergen, do you have other idea why it would timeout?

qemu not running or without qusb support is the most probable one.


Juergen

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

Re: [Xen-devel] [PATCH 2/7] x86/mm: Factor out the grant flags to pte flags conversion logic

[Jan Beulich]

>>> On 12.09.17 at 15:28,  wrote:
> On Tue, Sep 12, 2017 at 01:14:41PM +0100, Andrew Cooper wrote:
>> This fixes a bug where the requested AVAIL* flags were not honoured in an
>> unmap_and_replace operation.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 3/7] x86/mm: Misc cleanup to {create, replace}_grant_host_mapping()

[Jan Beulich]

>>> On 12.09.17 at 15:40,  wrote:
> On Tue, Sep 12, 2017 at 01:14:42PM +0100, Andrew Cooper wrote:
>> The purpose of this patch is solely to simplify the resulting diff of later
>> changes.
>> 
>>  * Factor out curr and currd at the start of the functions.
>>  * Rename pte to nl1e.
>> 
>> No functional change.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH 1/7] x86/mm: Improvements to PV l1e mapping helpers

[Jan Beulich]

>>> On 12.09.17 at 14:29,  wrote:
> On Tue, Sep 12, 2017 at 01:14:40PM +0100, Andrew Cooper wrote:
>> Drop guest_unmap_l1e() and use unmap_domain_page() directly.  This will
>> simplify future cleanup.  Rename guest_map_l1e() to map_guest_l1e() to 
> closer
>> match the mapping nomenclature.
>> 
>> Switch map_guest_l1e() to using mfn_t.  Correct the comment to indicate that
>> it takes a linear address (not a virtual address), and correct the parameter
>> name.
>> 
>> No functional change.
>> 
>> Signed-off-by: Andrew Cooper 
> 
> Reviewed-by: Wei Liu 

Acked-by: Jan Beulich 



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

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using real mappings

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 12 September 2017 08:10
> To: Alexandru Isaila ; xen-devel@lists.xen.org
> Cc: Tim (Xen.org) ; George Dunlap
> ; jbeul...@suse.com; Ian Jackson
> ; konrad.w...@oracle.com; sstabell...@kernel.org;
> Wei Liu ; Paul Durrant ;
> boris.ostrov...@oracle.com; suravee.suthikulpa...@amd.com;
> jun.nakaj...@intel.com; Kevin Tian ; Razvan
> Cojocaru ; Mihai Donțu
> 
> Subject: Re: [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using
> real mappings
> 
> On 08/09/17 17:05, Alexandru Isaila wrote:
> > +} while ( frame < final );
> > +
> > +/* Entire access within a single frame? */
> > +if ( first == final )
> > +mapping = map_domain_page(hvmemul_ctxt->mfn[0]) + (linear &
> ~PAGE_MASK);
> > +/* Multiple frames? Need to vmap(). */
> > +else if ( (mapping = vmap(hvmemul_ctxt->mfn,
> > +  mfn - hvmemul_ctxt->mfn)) == NULL )
> > +goto unhandleable;
> > +
> > +#ifndef NDEBUG /* Poision unused mfn[]s with INVALID_MFN. */
> > +while ( mfn < hvmemul_ctxt->mfn + ARRAY_SIZE(hvmemul_ctxt->mfn)
> )
> > +{
> > +ASSERT(mfn_x(*mfn) == 0);
> > +*mfn++ = INVALID_MFN;
> > +}
> > +#endif
> > +
> > +return mapping;
> 
> /sigh - its sad what you notice when looking over your own code somewhat
> later...
> 
> the + (linear & ~PAGE_MASK) needs removing from the
> map_domain_page()
> call, and adding to this return statement, because it also needs to
> happen for the vmap() case.

Should vmap call through to map_domain_page() in the case of a single page I 
wonder?

  Paul

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

[Xen-devel] [PATCH 2/2] public/sysctl: drop unnecessary typedefs and handles

[Jan Beulich]

By virtue of the struct xen_sysctl container structure, most of them
are really just cluttering the name space.

Signed-off-by: Jan Beulich 

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1212,11 +1212,11 @@ int xc_readconsolering(xc_interface *xch
 int xc_send_debug_keys(xc_interface *xch, char *keys);
 int xc_set_parameters(xc_interface *xch, char *params);
 
-typedef xen_sysctl_physinfo_t xc_physinfo_t;
-typedef xen_sysctl_cputopo_t xc_cputopo_t;
-typedef xen_sysctl_numainfo_t xc_numainfo_t;
-typedef xen_sysctl_meminfo_t xc_meminfo_t;
-typedef xen_sysctl_pcitopoinfo_t xc_pcitopoinfo_t;
+typedef struct xen_sysctl_physinfo xc_physinfo_t;
+typedef struct xen_sysctl_cputopo xc_cputopo_t;
+typedef struct xen_sysctl_numainfo xc_numainfo_t;
+typedef struct xen_sysctl_meminfo xc_meminfo_t;
+typedef struct xen_sysctl_pcitopoinfo xc_pcitopoinfo_t;
 
 typedef uint32_t xc_cpu_to_node_t;
 typedef uint32_t xc_cpu_to_socket_t;
@@ -1240,7 +1240,7 @@ int xc_machphys_mfn_list(xc_interface *x
  unsigned long max_extents,
  xen_pfn_t *extent_start);
 
-typedef xen_sysctl_cpuinfo_t xc_cpuinfo_t;
+typedef struct xen_sysctl_cpuinfo xc_cpuinfo_t;
 int xc_getcpuinfo(xc_interface *xch, int max_cpus,
   xc_cpuinfo_t *info, int *nr_cpus); 
 
@@ -1853,8 +1853,8 @@ int xc_cpu_offline(xc_interface *xch, in
  * cpufreq para name of this structure named 
  * same as sysfs file name of native linux
  */
-typedef xen_userspace_t xc_userspace_t;
-typedef xen_ondemand_t xc_ondemand_t;
+typedef struct xen_userspace xc_userspace_t;
+typedef struct xen_ondemand xc_ondemand_t;
 
 struct xc_get_cpufreq_para {
 /* IN/OUT variable */
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -547,7 +547,7 @@ int xc_livepatch_upload(xc_interface *xc
 DECLARE_SYSCTL;
 DECLARE_HYPERCALL_BUFFER(char, local);
 DECLARE_HYPERCALL_BOUNCE(name, 0 /* later */, 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
-xen_livepatch_name_t def_name = { .pad = { 0, 0, 0 } };
+struct xen_livepatch_name def_name = { };
 
 if ( !name || !payload )
 {
@@ -594,12 +594,12 @@ int xc_livepatch_upload(xc_interface *xc
 
 int xc_livepatch_get(xc_interface *xch,
  char *name,
- xen_livepatch_status_t *status)
+ struct xen_livepatch_status *status)
 {
 int rc;
 DECLARE_SYSCTL;
 DECLARE_HYPERCALL_BOUNCE(name, 0 /*adjust later */, 
XC_HYPERCALL_BUFFER_BOUNCE_IN);
-xen_livepatch_name_t def_name = { .pad = { 0, 0, 0 } };
+struct xen_livepatch_name def_name = { };
 
 if ( !name )
 {
@@ -677,7 +677,7 @@ int xc_livepatch_get(xc_interface *xch,
  * retrieved (if any).
  */
 int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
-  xen_livepatch_status_t *info,
+  struct xen_livepatch_status *info,
   char *name, uint32_t *len,
   unsigned int *done,
   unsigned int *left)
@@ -837,7 +837,7 @@ static int _xc_livepatch_action(xc_inter
 DECLARE_SYSCTL;
 /* The size is figured out when we strlen(name) */
 DECLARE_HYPERCALL_BOUNCE(name, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
-xen_livepatch_name_t def_name = { .pad = { 0, 0, 0 } };
+struct xen_livepatch_name def_name = { };
 
 def_name.size = strlen(name) + 1;
 
--- a/xen/arch/arm/sysctl.c
+++ b/xen/arch/arm/sysctl.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-void arch_do_physinfo(xen_sysctl_physinfo_t *pi) { }
+void arch_do_physinfo(struct xen_sysctl_physinfo *pi) { }
 
 long arch_do_sysctl(struct xen_sysctl *sysctl,
 XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
--- a/xen/arch/x86/sysctl.c
+++ b/xen/arch/x86/sysctl.c
@@ -72,7 +72,7 @@ long cpu_down_helper(void *data)
 return ret;
 }
 
-void arch_do_physinfo(xen_sysctl_physinfo_t *pi)
+void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
 {
 memcpy(pi->hw_cap, boot_cpu_data.x86_capability,
min(sizeof(pi->hw_cap), sizeof(boot_cpu_data.x86_capability)));
--- a/xen/common/gcov/gcov.c
+++ b/xen/common/gcov/gcov.c
@@ -209,7 +209,7 @@ static int gcov_dump_all(XEN_GUEST_HANDL
 return ret;
 }
 
-int sysctl_gcov_op(xen_sysctl_gcov_op_t *op)
+int sysctl_gcov_op(struct xen_sysctl_gcov_op *op)
 {
 int ret;
 
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -104,7 +104,7 @@ static struct livepatch_work livepatch_w
  */
 static DEFINE_PER_CPU(bool_t, work_to_do);
 
-static int get_name(const xen_livepatch_name_t *name, char *n)
+static int get_name(const struct xen_livepatch_name *name, char *n)
 {
 if ( !name->size || name->size > XEN_LIVEPATCH_NAME_SIZE )
 return -EINVAL;
@@ -121,7 +121,7 @@ static int get_name(const xen_livepatch_
 return 0;
 }
 
-static int verify_payload(const xen_sysctl_livepatch_upload_t *upload, char *n)
+static int verify_payload(const struct xen_sysctl_livepatch_uploa

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using real mappings

[Andrew Cooper]

On 08/09/17 17:05, Alexandru Isaila wrote:
> +} while ( frame < final );
> +
> +/* Entire access within a single frame? */
> +if ( first == final )
> +mapping = map_domain_page(hvmemul_ctxt->mfn[0]) + (linear & 
> ~PAGE_MASK);
> +/* Multiple frames? Need to vmap(). */
> +else if ( (mapping = vmap(hvmemul_ctxt->mfn,
> +  mfn - hvmemul_ctxt->mfn)) == NULL )
> +goto unhandleable;
> +
> +#ifndef NDEBUG /* Poision unused mfn[]s with INVALID_MFN. */
> +while ( mfn < hvmemul_ctxt->mfn + ARRAY_SIZE(hvmemul_ctxt->mfn) )
> +{
> +ASSERT(mfn_x(*mfn) == 0);
> +*mfn++ = INVALID_MFN;
> +}
> +#endif
> +
> +return mapping;

/sigh - its sad what you notice when looking over your own code somewhat
later...

the + (linear & ~PAGE_MASK) needs removing from the map_domain_page()
call, and adding to this return statement, because it also needs to
happen for the vmap() case.

~Andrew

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

[Xen-devel] [PATCH 1/2] public/domctl: drop unnecessary typedefs and handles

[Jan Beulich]

By virtue of the struct xen_domctl container structure, most of them
are really just cluttering the name space.

While doing so,
- convert an enum typed (pt_irq_type_t) structure field to a fixed
  width type,
- make x86's paging_domctl() and descendants take a properly typed
  handle,
- add const in a few places.

Signed-off-by: Jan Beulich 

--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -903,7 +903,7 @@ int xc_vcpu_get_extstate(xc_interface *x
  uint32_t vcpu,
  xc_vcpu_extstate_t *extstate);
 
-typedef xen_domctl_getvcpuinfo_t xc_vcpuinfo_t;
+typedef struct xen_domctl_getvcpuinfo xc_vcpuinfo_t;
 int xc_vcpu_getinfo(xc_interface *xch,
 uint32_t domid,
 uint32_t vcpu,
@@ -916,7 +916,7 @@ long long xc_domain_get_cpu_usage(xc_int
 int xc_domain_sethandle(xc_interface *xch, uint32_t domid,
 xen_domain_handle_t handle);
 
-typedef xen_domctl_shadow_op_stats_t xc_shadow_op_stats_t;
+typedef struct xen_domctl_shadow_op_stats xc_shadow_op_stats_t;
 int xc_shadow_control(xc_interface *xch,
   uint32_t domid,
   unsigned int sop,
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1714,8 +1714,7 @@ int xc_domain_update_msi_irq(
 uint64_t gtable)
 {
 int rc;
-xen_domctl_bind_pt_irq_t *bind;
-
+struct xen_domctl_bind_pt_irq *bind;
 DECLARE_DOMCTL;
 
 domctl.cmd = XEN_DOMCTL_bind_pt_irq;
@@ -1740,8 +1739,7 @@ int xc_domain_unbind_msi_irq(
 uint32_t gflags)
 {
 int rc;
-xen_domctl_bind_pt_irq_t *bind;
-
+struct xen_domctl_bind_pt_irq *bind;
 DECLARE_DOMCTL;
 
 domctl.cmd = XEN_DOMCTL_unbind_pt_irq;
@@ -1770,7 +1768,7 @@ static int xc_domain_bind_pt_irq_int(
 uint16_t spi)
 {
 int rc;
-xen_domctl_bind_pt_irq_t * bind;
+struct xen_domctl_bind_pt_irq *bind;
 DECLARE_DOMCTL;
 
 domctl.cmd = XEN_DOMCTL_bind_pt_irq;
@@ -1828,7 +1826,7 @@ static int xc_domain_unbind_pt_irq_int(
 uint8_t spi)
 {
 int rc;
-xen_domctl_bind_pt_irq_t * bind;
+struct xen_domctl_bind_pt_irq *bind;
 DECLARE_DOMCTL;
 
 domctl.cmd = XEN_DOMCTL_unbind_pt_irq;
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -41,7 +41,7 @@ long arch_do_domctl(struct xen_domctl *d
 case XEN_DOMCTL_bind_pt_irq:
 {
 int rc;
-xen_domctl_bind_pt_irq_t *bind = &domctl->u.bind_pt_irq;
+struct xen_domctl_bind_pt_irq *bind = &domctl->u.bind_pt_irq;
 uint32_t irq = bind->u.spi.spi;
 uint32_t virq = bind->machine_irq;
 
@@ -87,7 +87,7 @@ long arch_do_domctl(struct xen_domctl *d
 case XEN_DOMCTL_unbind_pt_irq:
 {
 int rc;
-xen_domctl_bind_pt_irq_t *bind = &domctl->u.bind_pt_irq;
+struct xen_domctl_bind_pt_irq *bind = &domctl->u.bind_pt_irq;
 uint32_t irq = bind->u.spi.spi;
 uint32_t virq = bind->machine_irq;
 
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -48,7 +48,7 @@ static int gdbsx_guest_mem_io(domid_t do
 }
 
 static int update_domain_cpuid_info(struct domain *d,
-const xen_domctl_cpuid_t *ctl)
+const struct xen_domctl_cpuid *ctl)
 {
 struct cpuid_policy *p = d->arch.cpuid;
 const struct cpuid_leaf leaf = { ctl->eax, ctl->ebx, ctl->ecx, ctl->edx };
@@ -363,8 +363,7 @@ long arch_do_domctl(
 {
 
 case XEN_DOMCTL_shadow_op:
-ret = paging_domctl(d, &domctl->u.shadow_op,
-guest_handle_cast(u_domctl, void), 0);
+ret = paging_domctl(d, &domctl->u.shadow_op, u_domctl, 0);
 if ( ret == -ERESTART )
 return hypercall_create_continuation(__HYPERVISOR_arch_1,
  "h", u_domctl);
@@ -707,7 +706,7 @@ long arch_do_domctl(
 
 case XEN_DOMCTL_bind_pt_irq:
 {
-xen_domctl_bind_pt_irq_t *bind = &domctl->u.bind_pt_irq;
+struct xen_domctl_bind_pt_irq *bind = &domctl->u.bind_pt_irq;
 int irq;
 
 ret = -EINVAL;
@@ -738,7 +737,7 @@ long arch_do_domctl(
 
 case XEN_DOMCTL_unbind_pt_irq:
 {
-xen_domctl_bind_pt_irq_t *bind = &domctl->u.bind_pt_irq;
+struct xen_domctl_bind_pt_irq *bind = &domctl->u.bind_pt_irq;
 int irq = domain_pirq_to_irq(d, bind->machine_irq);
 
 ret = -EPERM;
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -162,7 +162,7 @@ static int vioapic_hwdom_map_gsi(unsigne
  unsigned int pol)
 {
 struct domain *currd = current->domain;
-xen_domctl_bind_pt_irq_t pt_irq_bind = {
+struct xen_domctl_bind_pt_irq pt_irq_bind = {
 .irq_type = PT_IRQ_TYPE_PCI,
 .machine_irq = gsi,
 };
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -608,8 +608,8 @@ out:
 paging_unlock(d);
 }
 
-int hap_domctl(struct domain *d, xen_domctl_sh

Re: [Xen-devel] USB passthrough with Xen on ARM

[Julien Grall]

Hello,

On 12/09/17 12:22, Roger Quadros wrote:


Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

On 12/09/17 13:57, Julien Grall wrote:

Hi,

On 12/09/17 11:00, Juergen Gross wrote:

On 12/09/17 10:13, Roger Quadros wrote:

Hi,

I'm running Xen v4.9 on DRA7 (OMAP5/ArmV7) with Linux kernel v3.14 (yikes!!) on 
dom0 and domU.
I'm struggling to get USB passthrough working using pvUSB.

My domU config file contains
 usb = 1
 usbctrl = ['type=qusb,version=2,ports=4', 'type=qusb,version=1, ports=4', ]

I can see the vusb-0 and vusb-1 platform devices in /sys/devices

And the following message on domU kernel log
[1.849572] xenbus_probe_frontend: Device with no driver: device/vusb/0
[1.849627] xenbus_probe_frontend: Device with no driver: device/vusb/1

This means that there is no device driver for the vusb host controllers.

What is the way forward? Do I need to apply some patches to the domU kernel to
add support for the USB frontend HCD drivers?


This is one mandatory step, yes. You'll need:

https://lkml.org/lkml/2015/6/23/34
https://lkml.org/lkml/2015/6/23/36



OK, after applying the above 2 patches to v4.12 kernel for domU I'm able to see 
the xen HCD driver
enumerate, but it times out most likely due to the missing pvusb backend.

[0.510149] vusb vusb-0: Xen USB2.0 Virtual Host Controller
[0.510192] vusb vusb-0: new USB bus registered, assigned bus number 1
[0.510811] hub 1-0:1.0: USB hub found
[0.510865] hub 1-0:1.0: 4 ports detected
[0.812721] vusb vusb-1: Xen USB1.1 Virtual Host Controller
[0.812760] vusb vusb-1: new USB bus registered, assigned bus number 2
[0.813356] hub 2-0:1.0: USB hub found
[0.813410] hub 2-0:1.0: 4 ports detected

...

[5.888997] xenbus_probe_frontend: Waiting for devices to initialise: 
25s...20s...15s...10s...5s...0s...
[   35.919000] 
235s...230s...225s...220s...215s...210s...205s...200s...195s...190s...185s...180s...175s...170s...165s...160s...155s...150s...145s...140s...135s...130s...125s...120s...115s...110s...105s...100s...95s...90s...85s...80s...75s...70s...65s...60s...55s...50s...45s...40s...35s...30s...25s...20s...15s...10s...5s...0s...
[  270.879130]
[  270.884161] xenbus_probe_frontend: Timeout connecting to device: 
device/vusb/0 (local state 1, remote state 1)
[  270.887059] xenbus_probe_frontend: Timeout connecting to device: 
device/vusb/1 (local state 1, remote state 1)


The question is whether this will be enough for you to make it work: the
pvusb backend is qemu based. I'm not sure this will just work on ARM.


Backends in QEMU should just work with ARM. Although, I haven't tried the PVUSB 
one.



Newbie question now. How do I start the QEMU pvusb backend on dom0?


If I am not mistaken, the backend should be started by 
"/etc/init.d/xencommons start" which also start xenstore and all the 
userspace components for Xen.


So you should have a QEMU running in Dom0. Can you check if it is the case?

Also, I would check that QEMU has been built with the PV USB backend. It 
depends on libusb. I am not entirely sure if the build system will 
require it and will therefore fault if it is not installed.


Juergen, do you have other idea why it would timeout?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using real mappings

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper
> Sent: 12 September 2017 07:38
> To: Paul Durrant ; 'Alexandru Isaila'
> ; xen-devel@lists.xen.org
> Cc: Tim (Xen.org) ; George Dunlap
> ; jbeul...@suse.com; Ian Jackson
> ; konrad.w...@oracle.com; sstabell...@kernel.org;
> Wei Liu ; boris.ostrov...@oracle.com;
> suravee.suthikulpa...@amd.com; jun.nakaj...@intel.com; Kevin Tian
> ; Razvan Cojocaru ;
> Mihai Donțu 
> Subject: Re: [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using
> real mappings
> 
> On 12/09/17 15:32, Paul Durrant wrote:
> >
> >> +{
> >> +ASSERT_UNREACHABLE();
> >> +goto unhandleable;
> >> +}
> >> +
> >> +do {
> >> +enum hvm_translation_result res;
> >> +struct page_info *page;
> >> +pagefault_info_t pfinfo;
> >> +p2m_type_t p2mt;
> >> +
> >> +/* Error checking.  Confirm that the current slot is clean. */
> >> +ASSERT(mfn_x(*mfn) == 0);
> >> +
> >> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true,
> pfec,
> >> + &pfinfo, &page, NULL, &p2mt);
> >> +
> >> +switch ( res )
> >> +{
> >> +case HVMTRANS_okay:
> >> +break;
> >> +
> >> +case HVMTRANS_bad_linear_to_gfn:
> >> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear, &hvmemul_ctxt-
> >ctxt);
> >> +err = ERR_PTR(~(long)X86EMUL_EXCEPTION);
> >> +goto out;
> >> +
> >> +case HVMTRANS_bad_gfn_to_mfn:
> >> +err = NULL;
> >> +goto out;
> >> +
> >> +case HVMTRANS_gfn_paged_out:
> >> +case HVMTRANS_gfn_shared:
> >> +err = ERR_PTR(~(long)X86EMUL_RETRY);
> >> +goto out;
> >> +
> >> +default:
> >> +goto unhandleable;
> >> +}
> >> +
> >> +*mfn++ = _mfn(page_to_mfn(page));
> >> +frame++;
> >> +
> >> +if ( p2m_is_discard_write(p2mt) )
> >> +{
> >> +err = ERR_PTR(~(long)X86EMUL_OKAY);
> >> +goto out;
> >> +}
> >> +
> >> +} while ( frame < final );
> > while ( ++frame < final ), and lose the increment above?
> 
> I deliberately wrote it this way, to avoid adding to the cognitive load
> of trying to work out what is going on.

IMO there is more cognitive load in separating the increment from the test, but 
I'm not that fussed.

  Paul

> 
> -1 to the suggestion.
> 
> ~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using real mappings

[Jan Beulich]

>>> On 12.09.17 at 16:37,  wrote:
> On 12/09/17 15:32, Paul Durrant wrote:
>>
>>> +{
>>> +ASSERT_UNREACHABLE();
>>> +goto unhandleable;
>>> +}
>>> +
>>> +do {
>>> +enum hvm_translation_result res;
>>> +struct page_info *page;
>>> +pagefault_info_t pfinfo;
>>> +p2m_type_t p2mt;
>>> +
>>> +/* Error checking.  Confirm that the current slot is clean. */
>>> +ASSERT(mfn_x(*mfn) == 0);
>>> +
>>> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
>>> + &pfinfo, &page, NULL, &p2mt);
>>> +
>>> +switch ( res )
>>> +{
>>> +case HVMTRANS_okay:
>>> +break;
>>> +
>>> +case HVMTRANS_bad_linear_to_gfn:
>>> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear, 
> &hvmemul_ctxt->ctxt);
>>> +err = ERR_PTR(~(long)X86EMUL_EXCEPTION);
>>> +goto out;
>>> +
>>> +case HVMTRANS_bad_gfn_to_mfn:
>>> +err = NULL;
>>> +goto out;
>>> +
>>> +case HVMTRANS_gfn_paged_out:
>>> +case HVMTRANS_gfn_shared:
>>> +err = ERR_PTR(~(long)X86EMUL_RETRY);
>>> +goto out;
>>> +
>>> +default:
>>> +goto unhandleable;
>>> +}
>>> +
>>> +*mfn++ = _mfn(page_to_mfn(page));
>>> +frame++;
>>> +
>>> +if ( p2m_is_discard_write(p2mt) )
>>> +{
>>> +err = ERR_PTR(~(long)X86EMUL_OKAY);
>>> +goto out;
>>> +}
>>> +
>>> +} while ( frame < final );
>> while ( ++frame < final ), and lose the increment above?
> 
> I deliberately wrote it this way, to avoid adding to the cognitive load
> of trying to work out what is going on.

It's a matter of taste as well as what you're used to whether the
increment inside the while() is helpful or hindering. I'm generally
of the opinion that things that belong together should go together
(just like for(;;) enforces by wanting everything on the same line),
and the increment and loop exit check do belong together.
Separating them like above would be advisable only if the
intermediate loop exit really requires the value to still be
un-incremented.

> -1 to the suggestion.

+1 from me, that is.

Jan


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

Re: [Xen-devel] [PATCH v2 09/24] xen/arm: Introduce hsr_xabt to gather common bits between hsr_dabt and

[Julien Grall]

Hmmm, the commit title is truncated. It should be:

"xen/arm: Introduce hsr_xabt to gather common bits between hsr_{d,i}abt"

Cheers,

On 12/09/17 11:03, Julien Grall wrote:

This will allow to consolidate some part of the data abort and prefetch
abort handling in a single function later on.

Signed-off-by: Julien Grall 
Reviewed-by: Andre Przywara 

---
 Changes in v2:
 - Add Andre's reviewed-by
---
  xen/include/asm-arm/processor.h | 13 +
  1 file changed, 13 insertions(+)

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index b6432b6bf4..51e1c92665 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -615,6 +615,19 @@ union hsr {
  unsigned long ec:6;/* Exception Class */
  } dabt; /* HSR_EC_DATA_ABORT_* */
  
+/* Contain the common bits between DABT and IABT */

+struct hsr_xabt {
+unsigned long fsc:6;/* Fault status code */
+unsigned long pad1:1;
+unsigned long s1ptw:1;  /* Stage 2 fault during stage 1 translation */
+unsigned long pad2:1;
+unsigned long eat:1;/* External abort type */
+unsigned long fnv:1;/* FAR not Valid */
+unsigned long pad3:14;
+unsigned long len:1;/* Instruction length */
+unsigned long ec:6; /* Exception Class */
+} xabt;
+
  #ifdef CONFIG_ARM_64
  struct hsr_brk {
  unsigned long comment:16;   /* Comment */



--
Julien Grall

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

Re: [Xen-devel] [PATCH 26/27 v8] xen/arm: vpl011: Correct the logic for asserting/de-asserting SBSA UART TX interrupt

[Julien Grall]

Hi Bhupinder,

I am just commenting on the commit message, Andre already commented the 
code.


On 28/08/17 09:56, Bhupinder Thakur wrote:

This patch fixes the issue observed when pl011 patches were tested on
the junos hardware by Andre/Julien. It was observed that when large output is
generated such as on running 'find /', output was getting truncated 
intermittently
due to OUT ring buffer getting full.

This issue was due to the fact that the SBSA UART driver expects that when
a TX interrupt is asserted then the FIFO queue should be atleast half empty and
that it can write N bytes in the FIFO, where N is half the FIFO queue size, 
without
the bytes getting dropped due to FIFO getting full.

This requirement is as per section 3.4.2 of [1], which is:

---
UARTTXINTR


This register does not exist in the SBSA, so you cannot say it is a 
requirement from the specification. The emulation should be based on the 
specification and not how a driver behave. You don't know how other OS 
have implemented the driver.


As I mentioned in my previous answer, we are in process to clarify in 
the specification and we can currently assume the interrupt will be 
triggered at halfway.


So the commit message should reflect that.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 6/7] x86/mm: Combine {destroy, replace}_grant_{pte, va}_mapping()

[Wei Liu]

On Tue, Sep 12, 2017 at 01:14:45PM +0100, Andrew Cooper wrote:
> As with the create side of things, these are largely identical.  Most cases
> are actually destroying the mapping rather than replacing it with a stolen
> entry.
> 
> Reimplement their logic in replace_grant_pv_mapping() in a mostly common
> way.
> 
> No (intended) change in behaviour from a guests point of view.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

With two suggestions:

>  int create_grant_pv_mapping(uint64_t addr, unsigned long frame,
>  unsigned int flags, unsigned int cache_flags)
>  {
> @@ -4136,12 +3959,14 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned 
> long frame,
>  {
>  struct vcpu *curr = current;
>  struct domain *currd = curr->domain;
> -l1_pgentry_t ol1e;
> -int rc;
> +l1_pgentry_t nl1e = l1e_empty(), ol1e, *pl1e;
> +struct page_info *page;
> +mfn_t gl1mfn;
> +int rc = GNTST_general_error;
>  unsigned int grant_pte_flags = grant_to_pte_flags(flags, 0);
>  
>  /*
> - * On top of the explicit settings done by create_grant_host_mapping()
> + * On top of the explicit settings done by create_pv_host_mapping()
>   * also open-code relevant parts of adjust_guest_l1e(). Don't mirror
>   * available and cachability flags, though.
>   */
> @@ -4150,24 +3975,96 @@ int replace_grant_pv_mapping(uint64_t addr, unsigned 
> long frame,
> ? _PAGE_GLOBAL
> : _PAGE_GUEST_KERNEL | _PAGE_USER;
>  
> +/*
> + * addr comes from Xen's active_entry tracking, and was used successfully
> + * to create a grant.
> + *
> + * The meaning of addr depends on GNTMAP_contains_pte.  It is either a
> + * machine address of an L1e the guest has nominated to be altered, or a
> + * linear address we need to look up the appropriate L1e for.
> + *
> + * Passing a new_addr of zero is taken to mean destroy.  Passing a
> + * non-zero new_addr has only ever been available via
> + * GNTABOP_unmap_and_replace and only when using linear addresses.
> + */

IMHO this should be moved before the function.

>  if ( flags & GNTMAP_contains_pte )
>  {
> -if ( !new_addr )
> -return destroy_grant_pte_mapping(addr, frame, grant_pte_flags,
> - currd);
> +/* Replace not available in this addressing mode. */
> +if ( new_addr )
> +goto out;
> +

   /*
* addr comes from Xen's active_entry tracking so isn't guest controlled,
* but it had still better be PTE-aligned.
*/

Consider keeping this comment?

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

Re: [Xen-devel] [PATCH v3 14/17] livepatch/x86/arm: arch/x86/mm: generalize do_page_walk() and implement arch_livepatch_lookup_mfn

[Jan Beulich]

>>> On 12.09.17 at 02:37,  wrote:
> With this change we can use _do_page_walk() to implement
> arch_livepatch_lookup_mfn() which can be used to find out
> vmap virtual addresses (as under x86 virt_to_mfn won't work
> for vmap, but it does for arm!).

How about using domain_page_map_to_mfn() instead?

Jan


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

Re: [Xen-devel] [PATCH v3 11/17] livepatch/x86/arm[32, 64]: Use common vmap code for applying.

[Andrew Cooper]

On 12/09/17 01:37, Konrad Rzeszutek Wilk wrote:
> Patch titled "livepatch/arm[32,64]: Modify livepatch_funcs" added
> the infrastructure on ARM [32,64] to use vmap as way to
> map read-only regions. On x86 we use a global register.
>
> But there is nothing wrong with using on x86 the same method
> as on ARM[32,64] - which is exactly what this patch does.

Yes there is :)

If you don't make updates to the .text section via the same linear
address as the instructions are being fetched, the Icache doesn't stay
synchronised.  This is VeryBad(tm) when patching the entry paths.

If you want to continue down this route, you need to reintroduce
sync_core() and call it appropriately on all cpus after patching is
complete, and take care to ensure that any spliced patch on the NMI/MCE
handlers still results in valid x86 opcode.

~Andrew

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

Re: [Xen-devel] [PATCH v3 08/17] livepatch/tests: Make sure all .livepatch.funcs sections are read-only

[Jan Beulich]

>>> On 12.09.17 at 02:37,  wrote:
> --- a/xen/test/livepatch/Makefile
> +++ b/xen/test/livepatch/Makefile
> @@ -54,6 +54,7 @@ xen_hello_world.o: config.h livepatch_depends.h
>  $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o
>   $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(LIVEPATCH) $^
>   $(OBJCOPY) --strip-debug --strip-symbol=$(NOTE_SYMBOL) $@
> + $(OBJCOPY) --set-section-flags .livepatch.funcs=alloc,readonly $@

Why multiple objcopy invocations?

Jan


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

Re: [Xen-devel] [PATCH v3 07/17] livepatch/arm/x86: Strip note_depends symbol from test-cases.

[Jan Beulich]

>>> On 12.09.17 at 02:37,  wrote:
> This surfaced due to "xen/livepatch/x86/arm32: Force
> .livepatch.depends section to be uint32_t aligned." which switched
> to a different way of including the build-id.
> 
> Each livepatch ends with a global:
> 
> 30:  1 OBJECT  GLOBAL HIDDEN 7 note_depends
> 
> which will cause collision when loading.
> 
> One attempted solution was to add in the Makefile stanza:
>  @sed -i '/unsigned/static unsinged/' $@
> 
> But that resulted in the note_depends being omitted from the livepatch
> (as it was static and not used) which meant we would not have an
> .livepatch_depends section which we require.

Did you consider using objcopy's --localize-symbol instead?

Jan


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

Re: [Xen-devel] [PATCH v2 13/13] [RFC] iommu: AMD-Vi: Squash map_pages/unmap_pages with map_page/unmap_page

[Oleksandr Tyshchenko]

Hi.

Gentle reminder.

On Mon, Aug 21, 2017 at 7:44 PM, Oleksandr Tyshchenko
 wrote:
> Hi, all.
>
> Any comments?
>
> On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
>  wrote:
>> From: Oleksandr Tyshchenko 
>>
>> Reduce the scope of the TODO by squashing single-page stuff with
>> multi-page one. Next target is to use large pages whenever possible
>> in the case that hardware supports them.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Jan Beulich 
>> CC: Suravee Suthikulpanit 
>>
>> ---
>>Changes in v1:
>>   -
>>
>>Changes in v2:
>>   -
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> ---
>>  xen/drivers/passthrough/amd/iommu_map.c | 250 
>> 
>>  1 file changed, 121 insertions(+), 129 deletions(-)
>>
>> diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
>> b/xen/drivers/passthrough/amd/iommu_map.c
>> index ea3a728..22d0cc6 100644
>> --- a/xen/drivers/passthrough/amd/iommu_map.c
>> +++ b/xen/drivers/passthrough/amd/iommu_map.c
>> @@ -631,188 +631,180 @@ static int update_paging_mode(struct domain *d, 
>> unsigned long gfn)
>>  return 0;
>>  }
>>
>> -static int __must_check amd_iommu_map_page(struct domain *d, unsigned long 
>> gfn,
>> -   unsigned long mfn,
>> -   unsigned int flags)
>> +/*
>> + * TODO: Optimize by using large pages whenever possible in the case
>> + * that hardware supports them.
>> + */
>> +int __must_check amd_iommu_map_pages(struct domain *d, unsigned long gfn,
>> + unsigned long mfn,
>> + unsigned int order,
>> + unsigned int flags)
>>  {
>> -bool_t need_flush = 0;
>>  struct domain_iommu *hd = dom_iommu(d);
>>  int rc;
>> -unsigned long pt_mfn[7];
>> -unsigned int merge_level;
>> +unsigned long orig_gfn = gfn;
>> +unsigned long i;
>>
>>  if ( iommu_use_hap_pt(d) )
>>  return 0;
>>
>> -memset(pt_mfn, 0, sizeof(pt_mfn));
>> -
>>  spin_lock(&hd->arch.mapping_lock);
>> -
>>  rc = amd_iommu_alloc_root(hd);
>> +spin_unlock(&hd->arch.mapping_lock);
>>  if ( rc )
>>  {
>> -spin_unlock(&hd->arch.mapping_lock);
>>  AMD_IOMMU_DEBUG("Root table alloc failed, gfn = %lx\n", gfn);
>>  domain_crash(d);
>>  return rc;
>>  }
>>
>> -/* Since HVM domain is initialized with 2 level IO page table,
>> - * we might need a deeper page table for lager gfn now */
>> -if ( is_hvm_domain(d) )
>> +for ( i = 0; i < (1UL << order); i++, gfn++, mfn++ )
>>  {
>> -if ( update_paging_mode(d, gfn) )
>> +bool_t need_flush = 0;
>> +unsigned long pt_mfn[7];
>> +unsigned int merge_level;
>> +
>> +memset(pt_mfn, 0, sizeof(pt_mfn));
>> +
>> +spin_lock(&hd->arch.mapping_lock);
>> +
>> +/* Since HVM domain is initialized with 2 level IO page table,
>> + * we might need a deeper page table for lager gfn now */
>> +if ( is_hvm_domain(d) )
>> +{
>> +if ( update_paging_mode(d, gfn) )
>> +{
>> +spin_unlock(&hd->arch.mapping_lock);
>> +AMD_IOMMU_DEBUG("Update page mode failed gfn = %lx\n", gfn);
>> +domain_crash(d);
>> +rc = -EFAULT;
>> +goto err;
>> +}
>> +}
>> +
>> +if ( iommu_pde_from_gfn(d, gfn, pt_mfn) || (pt_mfn[1] == 0) )
>>  {
>>  spin_unlock(&hd->arch.mapping_lock);
>> -AMD_IOMMU_DEBUG("Update page mode failed gfn = %lx\n", gfn);
>> +AMD_IOMMU_DEBUG("Invalid IO pagetable entry gfn = %lx\n", gfn);
>>  domain_crash(d);
>> -return -EFAULT;
>> +rc = -EFAULT;
>> +goto err;
>>  }
>> -}
>>
>> -if ( iommu_pde_from_gfn(d, gfn, pt_mfn) || (pt_mfn[1] == 0) )
>> -{
>> -spin_unlock(&hd->arch.mapping_lock);
>> -AMD_IOMMU_DEBUG("Invalid IO pagetable entry gfn = %lx\n", gfn);
>> -domain_crash(d);
>> -return -EFAULT;
>> -}
>> +/* Install 4k mapping first */
>> +need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn,
>> +   IOMMU_PAGING_MODE_LEVEL_1,
>> +   !!(flags & IOMMUF_writable),
>> +   !!(flags & IOMMUF_readable));
>>
>> -/* Install 4k mapping first */
>> -need_flush = set_iommu_pte_present(pt_mfn[1], gfn, mfn,
>> -   IOMMU_PAGING_MODE_LEVEL_1,
>> -   !!(flags & IOMMUF_writable),
>> -   !!(flags & IOMMUF_readable));
>> +/* Do not increase pde count if io mapping has not been changed */
>> +if ( !need_flush )
>> +{
>> +spin_unlock(&hd->arc

Re: [Xen-devel] [PATCH v2 12/13] [RFC] iommu: VT-d: Squash map_pages/unmap_pages with map_page/unmap_page

[Oleksandr Tyshchenko]

Hi.

Gentle reminder.

On Mon, Aug 21, 2017 at 7:44 PM, Oleksandr Tyshchenko
 wrote:
> Hi, all.
>
> Any comments?
>
> On Tue, Jul 25, 2017 at 8:26 PM, Oleksandr Tyshchenko
>  wrote:
>> From: Oleksandr Tyshchenko 
>>
>> Reduce the scope of the TODO by squashing single-page stuff with
>> multi-page one. Next target is to use large pages whenever possible
>> in the case that hardware supports them.
>>
>> Signed-off-by: Oleksandr Tyshchenko 
>> CC: Jan Beulich 
>> CC: Kevin Tian 
>>
>> ---
>>Changes in v1:
>>   -
>>
>>Changes in v2:
>>   -
>> ---
>>  xen/drivers/passthrough/vtd/iommu.c | 138 
>> +---
>>  1 file changed, 67 insertions(+), 71 deletions(-)
>>
>> diff --git a/xen/drivers/passthrough/vtd/iommu.c 
>> b/xen/drivers/passthrough/vtd/iommu.c
>> index 45d1f36..d20b2f9 100644
>> --- a/xen/drivers/passthrough/vtd/iommu.c
>> +++ b/xen/drivers/passthrough/vtd/iommu.c
>> @@ -1750,15 +1750,24 @@ static void iommu_domain_teardown(struct domain *d)
>>  spin_unlock(&hd->arch.mapping_lock);
>>  }
>>
>> -static int __must_check intel_iommu_map_page(struct domain *d,
>> - unsigned long gfn,
>> - unsigned long mfn,
>> - unsigned int flags)
>> +static int __must_check intel_iommu_unmap_pages(struct domain *d,
>> +unsigned long gfn,
>> +unsigned int order);
>> +
>> +/*
>> + * TODO: Optimize by using large pages whenever possible in the case
>> + * that hardware supports them.
>> + */
>> +static int __must_check intel_iommu_map_pages(struct domain *d,
>> +  unsigned long gfn,
>> +  unsigned long mfn,
>> +  unsigned int order,
>> +  unsigned int flags)
>>  {
>>  struct domain_iommu *hd = dom_iommu(d);
>> -struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
>> -u64 pg_maddr;
>>  int rc = 0;
>> +unsigned long orig_gfn = gfn;
>> +unsigned long i;
>>
>>  /* Do nothing if VT-d shares EPT page table */
>>  if ( iommu_use_hap_pt(d) )
>> @@ -1768,78 +1777,60 @@ static int __must_check intel_iommu_map_page(struct 
>> domain *d,
>>  if ( iommu_passthrough && is_hardware_domain(d) )
>>  return 0;
>>
>> -spin_lock(&hd->arch.mapping_lock);
>> -
>> -pg_maddr = addr_to_dma_page_maddr(d, (paddr_t)gfn << PAGE_SHIFT_4K, 1);
>> -if ( pg_maddr == 0 )
>> +for ( i = 0; i < (1UL << order); i++, gfn++, mfn++ )
>>  {
>> -spin_unlock(&hd->arch.mapping_lock);
>> -return -ENOMEM;
>> -}
>> -page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
>> -pte = page + (gfn & LEVEL_MASK);
>> -old = *pte;
>> -dma_set_pte_addr(new, (paddr_t)mfn << PAGE_SHIFT_4K);
>> -dma_set_pte_prot(new,
>> - ((flags & IOMMUF_readable) ? DMA_PTE_READ  : 0) |
>> - ((flags & IOMMUF_writable) ? DMA_PTE_WRITE : 0));
>> +struct dma_pte *page = NULL, *pte = NULL, old, new = { 0 };
>> +u64 pg_maddr;
>>
>> -/* Set the SNP on leaf page table if Snoop Control available */
>> -if ( iommu_snoop )
>> -dma_set_pte_snp(new);
>> +spin_lock(&hd->arch.mapping_lock);
>>
>> -if ( old.val == new.val )
>> -{
>> +pg_maddr = addr_to_dma_page_maddr(d, (paddr_t)gfn << PAGE_SHIFT_4K, 
>> 1);
>> +if ( pg_maddr == 0 )
>> +{
>> +spin_unlock(&hd->arch.mapping_lock);
>> +rc = -ENOMEM;
>> +goto err;
>> +}
>> +page = (struct dma_pte *)map_vtd_domain_page(pg_maddr);
>> +pte = page + (gfn & LEVEL_MASK);
>> +old = *pte;
>> +dma_set_pte_addr(new, (paddr_t)mfn << PAGE_SHIFT_4K);
>> +dma_set_pte_prot(new,
>> + ((flags & IOMMUF_readable) ? DMA_PTE_READ  : 0) |
>> + ((flags & IOMMUF_writable) ? DMA_PTE_WRITE : 0));
>> +
>> +/* Set the SNP on leaf page table if Snoop Control available */
>> +if ( iommu_snoop )
>> +dma_set_pte_snp(new);
>> +
>> +if ( old.val == new.val )
>> +{
>> +spin_unlock(&hd->arch.mapping_lock);
>> +unmap_vtd_domain_page(page);
>> +continue;
>> +}
>> +*pte = new;
>> +
>> +iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
>>  spin_unlock(&hd->arch.mapping_lock);
>>  unmap_vtd_domain_page(page);
>> -return 0;
>> -}
>> -*pte = new;
>> -
>> -iommu_flush_cache_entry(pte, sizeof(struct dma_pte));
>> -spin_unlock(&hd->arch.mapping_lock);
>> -unmap_vtd_domain_page(page);
>>
>> -if ( !this_cpu(iommu_dont_flush_iotlb) )
>> -rc = iommu_flush_iotlb(d

Re: [Xen-devel] [PATCH v2 4/4] x86/hvm: Implement hvmemul_write() using real mappings

[Andrew Cooper]

On 12/09/17 15:32, Paul Durrant wrote:
>
>> +{
>> +ASSERT_UNREACHABLE();
>> +goto unhandleable;
>> +}
>> +
>> +do {
>> +enum hvm_translation_result res;
>> +struct page_info *page;
>> +pagefault_info_t pfinfo;
>> +p2m_type_t p2mt;
>> +
>> +/* Error checking.  Confirm that the current slot is clean. */
>> +ASSERT(mfn_x(*mfn) == 0);
>> +
>> +res = hvm_translate_get_page(curr, frame << PAGE_SHIFT, true, pfec,
>> + &pfinfo, &page, NULL, &p2mt);
>> +
>> +switch ( res )
>> +{
>> +case HVMTRANS_okay:
>> +break;
>> +
>> +case HVMTRANS_bad_linear_to_gfn:
>> +x86_emul_pagefault(pfinfo.ec, pfinfo.linear, 
>> &hvmemul_ctxt->ctxt);
>> +err = ERR_PTR(~(long)X86EMUL_EXCEPTION);
>> +goto out;
>> +
>> +case HVMTRANS_bad_gfn_to_mfn:
>> +err = NULL;
>> +goto out;
>> +
>> +case HVMTRANS_gfn_paged_out:
>> +case HVMTRANS_gfn_shared:
>> +err = ERR_PTR(~(long)X86EMUL_RETRY);
>> +goto out;
>> +
>> +default:
>> +goto unhandleable;
>> +}
>> +
>> +*mfn++ = _mfn(page_to_mfn(page));
>> +frame++;
>> +
>> +if ( p2m_is_discard_write(p2mt) )
>> +{
>> +err = ERR_PTR(~(long)X86EMUL_OKAY);
>> +goto out;
>> +}
>> +
>> +} while ( frame < final );
> while ( ++frame < final ), and lose the increment above?

I deliberately wrote it this way, to avoid adding to the cognitive load
of trying to work out what is going on.

-1 to the suggestion.

~Andrew

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

Re: [Xen-devel] [PATCH v3 05/17] alternative/x86/arm32: Align altinstructions (and altinstr_replacement) sections.

[Jan Beulich]

>>> On 12.09.17 at 02:37,  wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -155,11 +155,9 @@ SECTIONS
> __initcall_end = .;
>  
>  #ifdef CONFIG_HAS_ALTERNATIVE
> -   . = ALIGN(4);

I think this one needs to say, while ...

> __alt_instructions = .;
> *(.altinstructions)
> __alt_instructions_end = .;
> -   . = ALIGN(4);

... this one can go and ...

> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -202,7 +202,6 @@ SECTIONS
>  * "Alternative instructions for different CPU types or capabilities"
>  * Think locking instructions on spinlocks.
>  */
> -   . = ALIGN(8);
>  __alt_instructions = .;

... this one again needs to stay, but the 8 can be replaced by a 4.
That's because otherwise there's the risk of the __alt_instructions
label to not be at the start of the first .altinstructions (solely
depending on what happens to be immediately before this script
section). I'm sorry for the earlier mis-guiding of mine.

> --- a/xen/include/asm-x86/alternative.h
> +++ b/xen/include/asm-x86/alternative.h
> @@ -56,6 +56,7 @@ extern void alternative_instructions(void);
>  
>  #define ALTERNATIVE_N(newinstr, feature, number) \
>   ".pushsection .altinstructions,\"a\"\n" \
> + ".p2align 2\n"  \
>   ALTINSTR_ENTRY(feature, number) \

I think the would better go into ALTINSTR_ENTRY(), and then also
into the altinstruction_entry assembler macro.

Jan


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

Re: [Xen-devel] [PATCH] xen_disk: avoid use of g_malloc0_n()

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 12 September 2017 07:24
> To: qemu-de...@nongnu.org
> Cc: Paul Durrant ; Stefano Stabellini
> ; xen-devel 
> Subject: [PATCH] xen_disk: avoid use of g_malloc0_n()
> 
> Prefer g_new() / g_new0() to be farther backwards compatible with older
> glib versions. As there's no point in zeroing the allocation here (the
> loop right afterwards fully initializes the memory), use the former.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> 
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -1232,7 +1232,7 @@ static int blk_connect(struct XenDevice
>  return -1;
>  }
> 
> -domids = g_malloc0_n(blkdev->nr_ring_ref, sizeof(uint32_t));
> +domids = g_new(uint32_t, blkdev->nr_ring_ref);
>  for (i = 0; i < blkdev->nr_ring_ref; i++) {
>  domids[i] = blkdev->xendev.dom;
>  }
> 
> 


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