Re: [Xen-devel] David Vrabel mail bouncing

[Juergen Gross]

On 26/04/17 07:03, Stephen Rothwell wrote:
> Hi all,
> 
> David's citrix.com email address is bouncing.  Is there a new one I should
> use for the xen-tip tree contact, or should I just remove him?
> 

Just remove him, please. He is no longer maintainer of the Xen tree.


Juergen

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

[Xen-devel] [seabios bisection] complete build-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  99704f26360ee8d4f85081c6c50ce64f47961f6d
  Bug not present: 6f9b62ca57322197e26d3b22ff11b629697142bd
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107701/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/seabios/build-amd64.xen-build 
--summary-out=tmp/107701.bisection-summary --basis-template=106986 
--blessings=real,real-bisect seabios build-amd64 xen-build
Searching for failure / basis pass:
 107677 fail [host=godello0] / 106986 [host=godello1] 106637 [host=italia0] 
106381 [host=italia0] 106372 [host=baroque0] 105970 [host=godello1] 105952 
[host=fiano0] 105928 [host=nobling0] 105739 [host=baroque0] 105734 
[host=huxelrebe0] 104940 [host=huxelrebe0] 104213 [host=baroque0] 104000 
[host=huxelrebe1] 102858 [host=merlot0] 102799 [host=elbling1] 102484 
[host=merlot0] 101716 ok.
Failure / basis pass flights: 107677 / 101716
(tree with no url: minios)
(tree with no url: ovmf)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
Basis pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#6cfcdf037edadba984ccf8476b5d1e2a0940b789-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7
 
git://git.seabios.org/seabios.git#d7adf6044a4c772b497e97272adf97426b34a249-19fdcca467ad3436d68ef88899b4dcd78154a9c6
 
git://xenbits.xen.org/xen.git#6f9b62ca57322197e26d3b22ff11b629697142bd-99704f26360ee8d4f85081c6c50ce64f47961f6d
adhoc-revtuple-generator: tree discontiguous: xen
Loaded 10929 nodes in revision graph
Searching for test results:
 101716 pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
 102484 [host=merlot0]
 102859 [host=elbling1]
 102858 [host=merlot0]
 102799 [host=elbling1]
 102894 [host=huxelrebe0]
 104000 [host=huxelrebe1]
 104213 [host=baroque0]
 104940 [host=huxelrebe0]
 105734 [host=huxelrebe0]
 105738 [host=baroque0]
 105741 [host=huxelrebe0]
 105739 [host=baroque0]
 105928 [host=nobling0]
 105952 [host=fiano0]
 105969 [host=huxelrebe0]
 105982 pass irrelevant
 105970 [host=godello1]
 106372 [host=baroque0]
 106381 [host=italia0]
 106637 [host=italia0]
 106986 [host=godello1]
 107688 pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107663 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107670 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107677 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107689 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107691 pass 8b4834ee1202852ed83a9fc61268c65fb6961ea7 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 
6bc4164cc8570ed3140d34080e38878adce13593 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107690 pass b669e922b37b8957248798a5eb7aa96a666cd3fe 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
dbf9dd27f3aefc171839d60c188134da8ad3089d 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107692 pass 8b4834ee1202852ed83a9fc61268c65fb6961ea7 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 
c68aff57ce317d9f2d69d20eba893a10d964f316 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107693 pass 8051789e982499050680a26febeada7467e18a8d 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9e981317be20ab85bb68a670e79735f9685a3348
baseline version:
 ovmf d7dd4f0a0678c458005ea40acba70984c58bcb20

Last test of basis   107645  2017-04-25 10:46:12 Z0 days
Testing same since   107683  2017-04-26 01:15:30 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] Is Xen supports banana PI?

[casionwoo]

Is Xen supports banana PI?
Cause It’s A-20 but there’s no document for support banana-pi
Cause I’m wonder if there’s documentation for support banana-pi or anyone who 
already started for banana pi
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] David Vrabel mail bouncing

[Stephen Rothwell]

Hi all,

David's citrix.com email address is bouncing.  Is there a new one I should
use for the xen-tip tree contact, or should I just remove him?

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] linux-next: manual merge of the xen-tip tree with the tip tree

[Stephen Rothwell]

Hi all,

On Wed, 12 Apr 2017 14:30:21 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the xen-tip tree got a conflict in:
> 
>   arch/x86/xen/enlighten.c
> 
> between commit:
> 
>   687d77a5f7b2 ("x86/xen: Update e820 table handling to the new core x86 E820 
> code")
> 
> from the tip tree and commit:
> 
>   ca7b75377014 ("x86/xen: split off enlighten_pvh.c")
> 
> from the xen-tip tree.
> 
> The latter moved the code changed by the former to another file, so I
> have applied the following merge fix patch.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

The fix patch now looks like this:

From: Stephen Rothwell 
Date: Wed, 12 Apr 2017 14:27:23 +1000
Subject: [PATCH] x86/xen: merge fix for arch/x86/xen/enlighten.c code movement

Signed-off-by: Stephen Rothwell 
---
 arch/x86/xen/enlighten_pvh.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 2bc7d5bb01cf..98ab17673454 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -37,8 +38,8 @@ static void __init init_pvh_bootparams(void)
 
memset(_bootparams, 0, sizeof(pvh_bootparams));
 
-   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_map);
-   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_map);
+   memmap.nr_entries = ARRAY_SIZE(pvh_bootparams.e820_table);
+   set_xen_guest_handle(memmap.buffer, pvh_bootparams.e820_table);
rc = HYPERVISOR_memory_op(XENMEM_memory_map, );
if (rc) {
xen_raw_printk("XENMEM_memory_map failed (%d)\n", rc);
@@ -46,13 +47,13 @@ static void __init init_pvh_bootparams(void)
}
pvh_bootparams.e820_entries = memmap.nr_entries;
 
-   if (pvh_bootparams.e820_entries < E820MAX - 1) {
-   pvh_bootparams.e820_map[pvh_bootparams.e820_entries].addr =
+   if (pvh_bootparams.e820_entries < E820_MAX_ENTRIES_ZEROPAGE - 1) {
+   pvh_bootparams.e820_table[pvh_bootparams.e820_entries].addr =
ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[pvh_bootparams.e820_entries].size =
+   pvh_bootparams.e820_table[pvh_bootparams.e820_entries].size =
ISA_END_ADDRESS - ISA_START_ADDRESS;
-   pvh_bootparams.e820_map[pvh_bootparams.e820_entries].type =
-   E820_RESERVED;
+   pvh_bootparams.e820_table[pvh_bootparams.e820_entries].type =
+   E820_TYPE_RESERVED;
pvh_bootparams.e820_entries++;
} else
xen_raw_printk("Warning: Can fit ISA range into e820\n");
-- 
2.11.0

-- 
Cheers,
Stephen Rothwell

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

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Juergen Gross]

On 25/04/17 21:18, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote:
>> And what happens when there is a scheduling event right here?
>> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong
>> path.
> 
> So the whole thing we're doing right now is wrong: set bit and then
> clear bit.

Right. And this is handled by my patch.

The really clean solution would be to add this test to set_cpu_bug()
et al. Don't set/clear the bit if anyone selected to force a value.
The force variants would be capable to overwrite, the normal variants
wouldn't. This would require a lot of research to avoid pitfalls with
today's handling, though. OTOH one could remove all the calls to
apply_forced_caps().

> 
> We should not set the bit at all and there won't be any window to get it
> wrong.
> 
> So can we do something like this instead:
> 
>   if (!cpu_has(c, X86_FEATURE_XENPV))
>   set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> 
> or is XENPV the wrong thing to test?

This would work. OTOH I'd prefer to test whether the bit should be
forced to remain zero than use the knowledge _who_ is trying to force
it.


Juergen

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

[Xen-devel] [seabios bisection] complete build-amd64-xsm

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-xsm
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  99704f26360ee8d4f85081c6c50ce64f47961f6d
  Bug not present: 6f9b62ca57322197e26d3b22ff11b629697142bd
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/107685/


  (Revision log too long, omitted.)


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/seabios/build-amd64-xsm.xen-build 
--summary-out=tmp/107685.bisection-summary --basis-template=106986 
--blessings=real,real-bisect seabios build-amd64-xsm xen-build
Searching for failure / basis pass:
 107677 fail [host=godello0] / 106986 [host=godello1] 106637 [host=italia0] 
106381 [host=italia0] 106372 [host=rimava0] 105970 [host=godello1] 105952 
[host=fiano0] 105928 [host=nobling0] 105739 [host=huxelrebe0] 105734 
[host=huxelrebe0] 104940 [host=huxelrebe0] 104213 [host=baroque0] 104000 
[host=huxelrebe1] 102858 [host=elbling1] 102799 [host=elbling1] 102484 
[host=merlot0] 101716 ok.
Failure / basis pass flights: 107677 / 101716
(tree with no url: minios)
(tree with no url: ovmf)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://git.seabios.org/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
Basis pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#c4e0d84d3c92923fdbc7fa922638d54e5e834753-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#6cfcdf037edadba984ccf8476b5d1e2a0940b789-e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7
 
git://git.seabios.org/seabios.git#d7adf6044a4c772b497e97272adf97426b34a249-19fdcca467ad3436d68ef88899b4dcd78154a9c6
 
git://xenbits.xen.org/xen.git#6f9b62ca57322197e26d3b22ff11b629697142bd-99704f26360ee8d4f85081c6c50ce64f47961f6d
adhoc-revtuple-generator: tree discontiguous: xen
Loaded 10929 nodes in revision graph
Searching for test results:
 101716 pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
 102484 [host=merlot0]
 102858 [host=elbling1]
 102799 [host=elbling1]
 104000 [host=huxelrebe1]
 104213 [host=baroque0]
 104940 [host=huxelrebe0]
 105734 [host=huxelrebe0]
 105739 [host=huxelrebe0]
 105928 [host=nobling0]
 105952 [host=fiano0]
 105970 [host=godello1]
 106372 [host=rimava0]
 106381 [host=italia0]
 106637 [host=italia0]
 106986 [host=godello1]
 107671 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107680 pass 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
5fbf246bdb9c1ee3f474d3f343e2a79db060c93c 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107672 pass b669e922b37b8957248798a5eb7aa96a666cd3fe 
08c008de9c7d3ac71f71c87cc04a47819ca228dc 
dbf9dd27f3aefc171839d60c188134da8ad3089d 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107675 pass 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
c68aff57ce317d9f2d69d20eba893a10d964f316 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107663 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107673 pass 8b4834ee1202852ed83a9fc61268c65fb6961ea7 
57e8fbb2f702001a18bd81e9fe31b26d94247ac9 
6bc4164cc8570ed3140d34080e38878adce13593 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107669 pass c4e0d84d3c92923fdbc7fa922638d54e5e834753 
6cfcdf037edadba984ccf8476b5d1e2a0940b789 
d7adf6044a4c772b497e97272adf97426b34a249 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107678 pass 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
5fbf246bdb9c1ee3f474d3f343e2a79db060c93c 
6f9b62ca57322197e26d3b22ff11b629697142bd
 107670 fail 8051789e982499050680a26febeada7467e18a8d 
e97832ec6b2a7ddd48b8e6d1d848ffdfee6a31c7 
19fdcca467ad3436d68ef88899b4dcd78154a9c6 
99704f26360ee8d4f85081c6c50ce64f47961f6d
 107674 pass 

[Xen-devel] [qemu-mainline test] 107644: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-amd 19 guest-start/debian.repeat fail REGR. vs. 107636

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107636
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107636
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107636
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107636
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107636
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107636
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuuf4b5b021c847669b1c78050aea26fe9abceef6dd
baseline version:
 qemuueab1e53cacfb1d877317d5e7b416ddb43858d92e

Last test of basis   107636  2017-04-24 21:15:22 Z1 days
Testing same since   107644  2017-04-25 10:26:10 Z0 days1 attempts


People who touched revisions under test:
  Ashish Mittal 
  Ashish Mittal 
  Jeff Cody 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass

Re: [Xen-devel] [Qemu-devel] [PATCH 10/21] xen: import ring.h from xen

[Philippe Mathieu-Daudé]

On 04/25/2017 03:35 PM, Stefano Stabellini wrote:

Do not use the ring.h header installed on the system. Instead, import
the header into the QEMU codebase. This avoids problems when QEMU is
built against a Xen version too old to provide all the ring macros.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 


Reviewed-by: Philippe Mathieu-Daudé 


CC: anthony.per...@citrix.com
CC: jgr...@suse.com
---
 hw/block/xen_blkif.h |   2 +-
 hw/usb/xen-usb.c |   2 +-
 include/hw/xen/io/ring.h | 482 +++
 3 files changed, 484 insertions(+), 2 deletions(-)
 create mode 100644 include/hw/xen/io/ring.h

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index 3300b6f..3e6e1ea 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -1,7 +1,7 @@
 #ifndef XEN_BLKIF_H
 #define XEN_BLKIF_H

-#include 
+#include "hw/xen/io/ring.h"
 #include 
 #include 

diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 8e676e6..370b3d9 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -33,7 +33,7 @@
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qstring.h"

-#include 
+#include "hw/xen/io/ring.h"
 #include 

 /*
diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h
new file mode 100644
index 000..abbca47
--- /dev/null
+++ b/include/hw/xen/io/ring.h
@@ -0,0 +1,482 @@
+/**
+ * ring.h
+ *
+ * Shared producer-consumer ring macros.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Tim Deegan and Andrew Warfield November 2004.
+ */
+
+#ifndef __XEN_PUBLIC_IO_RING_H__
+#define __XEN_PUBLIC_IO_RING_H__
+
+/*
+ * When #include'ing this header, you need to provide the following
+ * declaration upfront:
+ * - standard integers types (uint8_t, uint16_t, etc)
+ * They are provided by stdint.h of the standard headers.
+ *
+ * In addition, if you intend to use the FLEX macros, you also need to
+ * provide the following, before invoking the FLEX macros:
+ * - size_t
+ * - memcpy
+ * - grant_ref_t
+ * These declarations are provided by string.h of the standard headers,
+ * and grant_table.h from the Xen public headers.
+ */
+
+#if __XEN_INTERFACE_VERSION__ < 0x00030208
+#define xen_mb()  mb()
+#define xen_rmb() rmb()
+#define xen_wmb() wmb()
+#endif
+
+typedef unsigned int RING_IDX;
+
+/* Round a 32-bit unsigned constant down to the nearest power of two. */
+#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 0x1))
+#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
+#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
+#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
+#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
+
+/*
+ * Calculate size of a shared ring, given the total available space for the
+ * ring and indexes (_sz), and the name tag of the request/response structure.
+ * A ring contains as many entries as will fit, rounded down to the nearest
+ * power of two (so we can mask with (size-1) to loop around).
+ */
+#define __CONST_RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \
+   sizeof(((struct _s##_sring *)0)->ring[0])))
+/*
+ * The same for passing in an actual pointer instead of a name tag.
+ */
+#define __RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
+
+/*
+ * Macros to make the correct C datatypes for a new kind of ring.
+ *
+ * To make a new ring datatype, you need to have two message structures,
+ * let's say request_t, and response_t already defined.
+ *
+ * In a header where you want the ring datatype declared, you then do:
+ *
+ * DEFINE_RING_TYPES(mytag, request_t, response_t);
+ *
+ * These expand out to give you a set of types, as you can see below.
+ * 

Re: [Xen-devel] [PATCH v3 04/29] x86: assembly, use ENDPROC for functions

[Josh Poimboeuf]

On Fri, Apr 21, 2017 at 04:12:40PM +0200, Jiri Slaby wrote:
> Somewhere END was used to end a function. It is not intended to be used
> for functions, because it does not mark the actual symbols as functions.
> Use ENDPROC in such cases which does the right job.
> 
> Signed-off-by: Jiri Slaby 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: 
> Cc: Boris Ostrovsky 
> Cc: Juergen Gross 
> Reviewed-by: Juergen Gross  [xen parts]
> Cc: 
> ---
>  arch/x86/entry/entry_32.S| 58 
> 
>  arch/x86/entry/entry_64.S| 40 +--
>  arch/x86/entry/entry_64_compat.S |  4 +--
>  arch/x86/kernel/ftrace_32.S  |  8 +++---
>  arch/x86/kernel/ftrace_64.S  | 10 +++
>  arch/x86/xen/xen-pvh.S   |  2 +-
>  6 files changed, 61 insertions(+), 61 deletions(-)
> 
> diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
> index 50bc26949e9e..a546b84aec01 100644
> --- a/arch/x86/entry/entry_32.S
> +++ b/arch/x86/entry/entry_32.S
> @@ -249,7 +249,7 @@ ENTRY(__switch_to_asm)
>   popl%ebp
>  
>   jmp __switch_to
> -END(__switch_to_asm)
> +ENDPROC(__switch_to_asm)
>  
>  /*
>   * A newly forked process directly context switches into this address.
> @@ -289,7 +289,7 @@ ENTRY(ret_from_fork)
>*/
>   movl$0, PT_EAX(%esp)
>   jmp 2b
> -END(ret_from_fork)
> +ENDPROC(ret_from_fork)
>  
>  /*
>   * Return to user mode is not as complex as all this looks,
> @@ -323,7 +323,7 @@ ENTRY(resume_userspace)
>   movl%esp, %eax
>   callprepare_exit_to_usermode
>   jmp restore_all
> -END(ret_from_exception)
> +ENDPROC(ret_from_exception)

What exactly is the motivation of this patch?  It would be good to
describe that in the commit message.

Is the point to allow objtool to generate CFI for it?  If so, I don't
really see how that would work.  Today, objtool considers ENDPROC to
annotate a *callable* function which conforms to the C calling ABI and
can be called by another function.  The stack is in a known state at
function entry, and so the CFI (or frame pointer info) can be reliably
determined.

But entry code is different.  In most cases, the global symbols aren't
actually called, and they don't follow any conventions.  The code is
spaghetti-esque, with HW handlers and jumps everywhere.  The state of
the stack at symbol entry varies per "function".  That's why objtool
ignores these files.

For special cases (like entry code), I was thinking we'd need manual CFI
annotations, like we had before.  Or maybe there's another way, like
some new macros which tell objtool about the HW entry points and the
state of the registers there.

But I'm having trouble seeing how marking these code snippets with
ENTRY/ENDPROC would help objtool make any sense of the code and where
things are on the stack.

-- 
Josh

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
71221
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 71221

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71221
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71221
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71221
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71221
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71221
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 71221

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

version targeted for testing:
 qemuueab1e53cacfb1d877317d5e7b416ddb43858d92e
baseline version:
 qemuu32c7e0ab755745e961f1772e95cac381cc68769d

Last test of basis71221  2017-04-23 12:17:21 Z2 days
Testing same since71230  2017-04-25 10:46:16 Z0 days1 attempts


People who touched revisions under test:
  Aurelien Jarno 
  BALATON Zoltan 
  David Gibson 
  Fam Zheng 
  Gerd Hoffmann 
  Laurent Vivier 
  Marc-André Lureau 
  Mark 

[Xen-devel] [seabios test] 107677: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   26 days
Testing same since   107663  2017-04-25 17:17:46 Z0 days3 attempts


People who touched revisions under test:
  Julius Werner 

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-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to 

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  1846c75ecc946a877b455dc997e38f8424d31906
baseline version:
 xtf  637b0d1d1a02b0563cd1966bee800e9e5617e9fa

Last test of basis   107659  2017-04-25 14:44:52 Z0 days
Testing same since   107664  2017-04-25 17:44:27 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

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

[Xen-devel] [xen-unstable test] 107642: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail  like 107635
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 107635
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 107635
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 107635
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107635
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail  like 107635
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 107635
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 107635
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail  like 107635
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  99704f26360ee8d4f85081c6c50ce64f47961f6d
baseline version:
 xen  99704f26360ee8d4f85081c6c50ce64f47961f6d

Last test of basis   107642  2017-04-25 06:47:07 Z0 days
Testing same since  (not found) 0 attempts

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

[Xen-devel] [seabios test] 107670: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   26 days
Testing same since   107663  2017-04-25 17:17:46 Z0 days2 attempts


People who touched revisions under test:
  Julius Werner 

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-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to 

Re: [Xen-devel] [PATCH v3 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

[Mohit Gambhir]

On 04/25/2017 02:20 PM, Andrew Cooper wrote:

On 24/04/17 18:54, Mohit Gambhir wrote:

This patch tests VPMU functionality in the hypervisor on Intel machines.
The tests write to all valid bits in the MSRs that get exposed to the guests
when VPMU is enabled. The tests also write invalid values to the bits
that should be masked and expect the wrmsr call to fault.

The tests are currently unsupported for AMD machines and PV guests.

Signed-off-by: Mohit Gambhir 
---
  tests/vpmu/Makefile |   9 +
  tests/vpmu/main.c   | 504 
  2 files changed, 513 insertions(+)
  create mode 100644 tests/vpmu/Makefile
  create mode 100644 tests/vpmu/main.c

diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
new file mode 100644
index 000..1eaf436
--- /dev/null
+++ b/tests/vpmu/Makefile
@@ -0,0 +1,9 @@
+include $(ROOT)/build/common.mk
+
+NAME  := vpmu
+CATEGORY  := utility

utilities don't get run automatically.  Is this intentional?  If it
isn't, what is the plan for making it automatically run?  vpmu is still
disabled by default in all branches due to the security vulnerabilities,
so even if this vpmu test was automatically run, it would skip due to
vpmu not being visible.
The reason I wanted it to not run automatically was because I thought it 
will fail when vpmu
is not enabled - which is the default case. But if XTF will skip vpmu 
tests when it is disabled
then we can run the tests automatically. Should the CATEGORY be 
functional in that case?

As a tangent, I wonder if it would be a useful to have a separate
category for incomplete tests, but which are still useful to have for
manual running.
Possibly. Utility category seems to do just that but I can see that it 
is really not meant for
functional tests. There are situations where writing tests before or 
while implementing a
feature is useful  and in that case this new category can be beneficial. 
It would also benefit

to have some kind of "expected failure" return type.

+TEST-ENVS := $(ALL_ENVIRONMENTS)

You build for all environments, but then have PV unilaterally skip.
Again, is this intentional?
Yes, I thought I would go back and add PV/AMD tests in V2 but I can 
leave those TEST-ENVS

out for now and "skip the skip" :) if that's preferable.

For HVM, why all environments?  does PMU have any interaction with the
operating or paging mode in use at the time of the samples?

Not that I know of. So should it just be hvm64?

+
+obj-perenv += main.o
+
+include $(ROOT)/build/gen.mk
diff --git a/tests/vpmu/main.c b/tests/vpmu/main.c
new file mode 100644
index 000..ed00953
--- /dev/null
+++ b/tests/vpmu/main.c
@@ -0,0 +1,504 @@
+/**
+ * @file tests/vpmu/main.c
+ * @ref test-vpmu
+ *
+ * @page test-vpmu vpmu
+ *
+ * Test MSRs exposed by VPMU for various versions of Architectural Performance
+ * Monitoring Unit

This needs rather more information.  What tests are performed?  Take a
look at http://xenbits.xen.org/docs/xtf/test-index.html, particularly
the functional tests.

OK, will fix it in the next version of the patch.

+ *
+ * @see tests/vpmu/main.c
+ */
+
+#include 
+#include 
+#include 
+
+#define EVENT_UOPS_RETIRED   0x004101c2
+#define EVENT_UOPS_RETIRED_ANYTHREAD 0x006101c2
+#define FIXED_CTR_CTL_BITS   4
+#define FIXED_CTR_ENABLE 0x000A
+#define FIXED_CTR_ENABLE_ANYTHREAD   0x000E
+#define IA32_PERFEVENTSELx_ENABLE_ANYTHREAD  (1ull << 21)
+#define IA32_PERFEVENTSELx_ENABLE_PCB(1ull << 19)
+#define IA32_DEBUGCTL_Freeze_LBR_ON_PMI  (1ull << 11)
+#define IA32_DEBUGCTL_Freeze_PerfMon_On_PMI  (1ull << 12)
+
+const char test_title[] = "Test vpmu";
+
+static void get_intel_pmu_version(uint8_t *v, uint8_t *ng, uint8_t *nf,
+  uint8_t *ngb)
+{

IMO, It looks like the logic would be easier to follow if this wasn't
broken out of test_main().


OK, will fix it in the next version of the patch.

+/* Inter Software Development Manual Vol 2A
+ * Table 3-8  Information Returned by CPUID Instruction */

Please follow Xen Hypervisor coding style.  Therefore,

/* Single line comments like this please. */

and

/*
  * Multi-line comments
  * like this please.
  */


OK, will fix it in the next version of the patch.

+
+uint32_t leaf = 0x0a, subleaf = 0;
+
+uint32_t eax, ebx, ecx, edx;
+
+cpuid_count(leaf, subleaf, , , , );

You need to check max_leaf >= 0x0a before this is valid to do.  I have
just pushed a change which exposes max_leaf and max_extd_leaf from the
boot-time cpuid collection logic, which you can use.

OK, will fix it in the next version of the patch.

+
+/* Extract the version ID - EAX 7:0 */
+*v =  (eax & 0xff);
+
+/* Extract number of general purpose counter regs - EAX 15:8 */
+*ng = (eax >> 8) & 0xff;
+
+/* Extract number of fixed function counter regs - EDX 4:0 */
+*nf = edx & 0x1f;
+
+/* Extract number 

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Borislav Petkov]

On Tue, Apr 25, 2017 at 09:17:13PM +0100, Andrew Cooper wrote:
> The problem (for all ring-deprivileged virtuailsation; not just Xen PV),
> is that

I know what that that bug flag is for.

I'm asking whether the xen guest boot sets a flag early - like XENPV,
for example - which can differentiate between baremetal and virt boot in
a fairly generic manner so that we don't set that bug flag then instead
of the set and then clear dance we do currently.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Andrew Cooper]

On 25/04/17 20:18, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote:
>> And what happens when there is a scheduling event right here?
>> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong
>> path.
> So the whole thing we're doing right now is wrong: set bit and then
> clear bit.
>
> We should not set the bit at all and there won't be any window to get it
> wrong.
>
> So can we do something like this instead:
>
>   if (!cpu_has(c, X86_FEATURE_XENPV))
>   set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>
> or is XENPV the wrong thing to test?
>

X86_BUG_SYSRET_SS_ATTRS only actually causes a problem if you enter the
kernel via an IDT vector (forcing %ss to NULL), then exiting the kernel
via the optimistic sysret path, which on AMD loads the %ss selector, but
apparently doesn't update the segment cache (and %ss.dpl in particular).

The problem (for all ring-deprivileged virtuailsation; not just Xen PV),
is that

savesegment(ss, ss_sel);
if (ss_sel != __KERNEL_DS)
loadsegment(ss, __KERNEL_DS);

tries to load %ss with an RPL of 0, and things blow up.

~Andrew

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

Re: [Xen-devel] [PATCH v8 for-4.9 3/5] hvm/dmop: Implement copy_{to, from}_guest_buf() in terms of raw accessors

[Andrew Cooper]

On 24/04/17 09:19, Jan Beulich wrote:
 On 21.04.17 at 18:10,  wrote:
>> On 21/04/17 16:45, Jan Beulich wrote:
>> On 21.04.17 at 16:05,  wrote:
 +#define COPY_FROM_GUEST_BUF(dst, args, buf_idx) \
 +_raw_copy_from_guest_buf(, args, buf_idx, sizeof(dst))
 +
 +#define COPY_TO_GUEST_BUF(args, buf_idx, src) \
 +_raw_copy_to_guest_buf(args, buf_idx, , sizeof(src))
> (Side note: src also isn't properly parenthesized, and the title went
> out of sync with the implementation.)
>
>>> Why all caps all of the sudden?
>> This is the start of some code improvements, given the fallout from XSA-212.
> I don't think making the names shout is an improvement in any way.
> The #define-s above may still look fine, but the code using them is
> now looking plain ugly (even more so with the yet longer names
> introduced in patch 4).

That is a matter of opinion which I don't share, but ok.

As an alternative, how else do you suggest making it obvious to the
reader of the code that this thing which looks like a function doesn't
have function semantics?  (This is the purpose I am trying to get across.)

>> make it more obvious to people reading the code that it *is not* a C
>> function and doesn't behave like one.
>>
>> It is getting embarrassing how many security vulnerability we are seeing
>> because macros look like they are doing one thing, yet actually do
>> something else, and improving the quality of the code is the only way
>> this is going to get better.
> Considering the "how many" you use, mind giving three examples
> where using all caps macro names would have made a difference?
> I sincerely doubt that the case used in identifiers would make a
> whole lot of a difference.

You have missed my point then.  We have many security vulnerabilities
because we have deceptive code, and fix for that is to prevent the code
being deceptive.  This is going to positive code quality effort on our
behalf, because the status quo is currently terrible.

Most notably, XSA-212 just gone, where the root of the vulnerability is
that "guest_handle_okay(base_ptr, array_element)" doesn't consider its
second parameter, and degrades to checking just base_ptr.

I accept that, in this case, capitalising the macro wouldn't help, but
that is because its deceptive nature is in its naming, not because it
behaves in a way contrary to a C function.

> As a possible alternative, was it considered to pass pointers
> here as before, using __builtin_object_size() on them instead of
> the sizeof() above, and making the macros inline functions?

I have never tried using it in anger, but looking into it, it degrades
to (size_t)-1 in the case the compiler can't statically work out the
correct value.  As a result, you'd end up with a function which has
gets() semantics (in the case that the compiler can't work out what's
going on).  I don't recommend we use any constructs like this.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Borislav Petkov]

On Tue, Apr 25, 2017 at 08:34:34PM +0200, Juergen Gross wrote:
> And what happens when there is a scheduling event right here?
> __switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong
> path.

So the whole thing we're doing right now is wrong: set bit and then
clear bit.

We should not set the bit at all and there won't be any window to get it
wrong.

So can we do something like this instead:

if (!cpu_has(c, X86_FEATURE_XENPV))
set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);

or is XENPV the wrong thing to test?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

Re: [Xen-devel] [PATCH v3 0/2][XTF] xtf/vpmu VPMU tests

[Andrew Cooper]

On 24/04/17 18:54, Mohit Gambhir wrote:
> Mohit Gambhir (2):
>   xtf/vpmu: Add Intel PMU MSR addresses
>   xtf/vpmu: MSR read/write tests for VPMU
>
>  arch/x86/include/arch/msr-index.h |  11 +
>  tests/vpmu/Makefile   |   9 +
>  tests/vpmu/main.c | 504 
> ++
>  3 files changed, 524 insertions(+)
>  create mode 100644 tests/vpmu/Makefile
>  create mode 100644 tests/vpmu/main.c
>

Independently from the content of this series, how have you found the
XTF to use?  Any issues or unexpected corner cases which can be improved?

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/2][XTF] xtf/vpmu: MSR read/write tests for VPMU

[Andrew Cooper]

On 24/04/17 18:54, Mohit Gambhir wrote:
> This patch tests VPMU functionality in the hypervisor on Intel machines.
> The tests write to all valid bits in the MSRs that get exposed to the guests
> when VPMU is enabled. The tests also write invalid values to the bits
> that should be masked and expect the wrmsr call to fault.
>
> The tests are currently unsupported for AMD machines and PV guests.
>
> Signed-off-by: Mohit Gambhir 
> ---
>  tests/vpmu/Makefile |   9 +
>  tests/vpmu/main.c   | 504 
> 
>  2 files changed, 513 insertions(+)
>  create mode 100644 tests/vpmu/Makefile
>  create mode 100644 tests/vpmu/main.c
>
> diff --git a/tests/vpmu/Makefile b/tests/vpmu/Makefile
> new file mode 100644
> index 000..1eaf436
> --- /dev/null
> +++ b/tests/vpmu/Makefile
> @@ -0,0 +1,9 @@
> +include $(ROOT)/build/common.mk
> +
> +NAME  := vpmu
> +CATEGORY  := utility

utilities don't get run automatically.  Is this intentional?  If it
isn't, what is the plan for making it automatically run?  vpmu is still
disabled by default in all branches due to the security vulnerabilities,
so even if this vpmu test was automatically run, it would skip due to
vpmu not being visible.

As a tangent, I wonder if it would be a useful to have a separate
category for incomplete tests, but which are still useful to have for
manual running.

> +TEST-ENVS := $(ALL_ENVIRONMENTS)

You build for all environments, but then have PV unilaterally skip. 
Again, is this intentional?

For HVM, why all environments?  does PMU have any interaction with the
operating or paging mode in use at the time of the samples?

> +
> +obj-perenv += main.o
> +
> +include $(ROOT)/build/gen.mk
> diff --git a/tests/vpmu/main.c b/tests/vpmu/main.c
> new file mode 100644
> index 000..ed00953
> --- /dev/null
> +++ b/tests/vpmu/main.c
> @@ -0,0 +1,504 @@
> +/**
> + * @file tests/vpmu/main.c
> + * @ref test-vpmu
> + *
> + * @page test-vpmu vpmu
> + *
> + * Test MSRs exposed by VPMU for various versions of Architectural 
> Performance
> + * Monitoring Unit

This needs rather more information.  What tests are performed?  Take a
look at http://xenbits.xen.org/docs/xtf/test-index.html, particularly
the functional tests.

> + *
> + * @see tests/vpmu/main.c
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define EVENT_UOPS_RETIRED   0x004101c2
> +#define EVENT_UOPS_RETIRED_ANYTHREAD 0x006101c2
> +#define FIXED_CTR_CTL_BITS   4
> +#define FIXED_CTR_ENABLE 0x000A
> +#define FIXED_CTR_ENABLE_ANYTHREAD   0x000E
> +#define IA32_PERFEVENTSELx_ENABLE_ANYTHREAD  (1ull << 21)
> +#define IA32_PERFEVENTSELx_ENABLE_PCB(1ull << 19)
> +#define IA32_DEBUGCTL_Freeze_LBR_ON_PMI  (1ull << 11)
> +#define IA32_DEBUGCTL_Freeze_PerfMon_On_PMI  (1ull << 12)
> +
> +const char test_title[] = "Test vpmu";
> +
> +static void get_intel_pmu_version(uint8_t *v, uint8_t *ng, uint8_t *nf,
> +  uint8_t *ngb)
> +{

IMO, It looks like the logic would be easier to follow if this wasn't
broken out of test_main().

> +/* Inter Software Development Manual Vol 2A
> + * Table 3-8  Information Returned by CPUID Instruction */

Please follow Xen Hypervisor coding style.  Therefore,

/* Single line comments like this please. */

and

/*
 * Multi-line comments
 * like this please.
 */

> +
> +uint32_t leaf = 0x0a, subleaf = 0;
> +
> +uint32_t eax, ebx, ecx, edx;
> +
> +cpuid_count(leaf, subleaf, , , , );

You need to check max_leaf >= 0x0a before this is valid to do.  I have
just pushed a change which exposes max_leaf and max_extd_leaf from the
boot-time cpuid collection logic, which you can use.

> +
> +/* Extract the version ID - EAX 7:0 */
> +*v =  (eax & 0xff);
> +
> +/* Extract number of general purpose counter regs - EAX 15:8 */
> +*ng = (eax >> 8) & 0xff;
> +
> +/* Extract number of fixed function counter regs - EDX 4:0 */
> +*nf = edx & 0x1f;
> +
> +/* Extract number of bits in general purpose counter registers bits */
> +*ngb = (eax >> 16)  & 0xff;
> +}
> +
> +static bool test_valid_msr_write(uint32_t idx, uint64_t wval)
> +{
> +const char *pfx = "Error: test_valid_msr_write:";
> +
> +uint64_t rval = 0;

I don't see much value with spacing these declarations out.

> +
> +printk("Writing 0x%" PRIx64 " to MSR 0x%x\n", wval, idx);

%#x is shorter than 0x%x when you don't care about the width of the
number printed.

However, it is generally easier to read the logs when numbers like this
are printed at full width,

> +
> +if( wrmsr_safe(idx, wval) )
> +{
> +xtf_error("%s wrmsr for MSR 0x%x resulted in a fault!\n", pfx, idx);

If you are expecting the write to succeed and it doesn't, that is a test
failure, rather than an error (which is used to signify something
expected going wrong).

The trailing ! is unnecessary in the 

[Xen-devel] [PATCH 17/21] xen/9pfs: build and register Xen 9pfs backend

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/Makefile.objs| 1 +
 hw/xen/xen_backend.c | 3 +++
 include/hw/xen/xen_backend.h | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/hw/9pfs/Makefile.objs b/hw/9pfs/Makefile.objs
index 32197e6..cab5e94 100644
--- a/hw/9pfs/Makefile.objs
+++ b/hw/9pfs/Makefile.objs
@@ -5,5 +5,6 @@ common-obj-y += coth.o cofs.o codir.o cofile.o
 common-obj-y += coxattr.o 9p-synth.o
 common-obj-$(CONFIG_OPEN_BY_HANDLE) +=  9p-handle.o
 common-obj-y += 9p-proxy.o
+common-obj-$(CONFIG_XEN) += xen-9p-backend.o
 
 obj-y += virtio-9p-device.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index d34c49e..c85f163 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -583,6 +583,9 @@ void xen_be_register_common(void)
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("qdisk", _blkdev_ops);
+#ifdef CONFIG_VIRTFS
+xen_be_register("9pfs", _9pfs_ops);
+#endif
 #ifdef CONFIG_USB_LIBUSB
 xen_be_register("qusb", _usb_ops);
 #endif
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 30811a1..852c2ea 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -47,6 +47,9 @@ extern struct XenDevOps xen_console_ops;  /* 
xen_console.c */
 extern struct XenDevOps xen_kbdmouse_ops; /* xen_framebuffer.c */
 extern struct XenDevOps xen_framebuffer_ops;  /* xen_framebuffer.c */
 extern struct XenDevOps xen_blkdev_ops;   /* xen_disk.c*/
+#ifdef CONFIG_VIRTFS
+extern struct XenDevOps xen_9pfs_ops;   /* xen-9p-backend.c*/
+#endif
 extern struct XenDevOps xen_netdev_ops;   /* xen_nic.c */
 #ifdef CONFIG_USB_LIBUSB
 extern struct XenDevOps xen_usb_ops;  /* xen-usb.c */
-- 
1.9.1


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d7dd4f0a0678c458005ea40acba70984c58bcb20
baseline version:
 ovmf d5a67b3da18f815c83593d9329a353ec3a739d66

Last test of basis71229  2017-04-25 10:19:58 Z0 days
Testing same since71231  2017-04-25 14:18:45 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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


Push not applicable.


commit d7dd4f0a0678c458005ea40acba70984c58bcb20
Author: Jiaxin Wu 
Date:   Fri Apr 21 12:56:05 2017 +0800

MdeModulePkg/Ip4Dxe: Refine the IPv4 configuration help info

Below value indicate whether network address configured successfully
or not:
Network Device List->MAC->IPv4 Network Configuration->Configured.

This patch is to refine its help info.

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin 
Reviewed-by: Ye Ting 

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

[Xen-devel] [PATCH 20/21] move xen-hvm.c to hw/i386/xen/

[Stefano Stabellini]

From: Anthony Xu 

move xen-hvm.c to hw/i386/xen/

Signed-off -by: Anthony Xu 
Reviewed-by: Stefano Stabellini 
---
 Makefile.target   |3 +-
 hw/i386/xen/Makefile.objs |2 +-
 hw/i386/xen/trace-events  |   11 +
 hw/i386/xen/xen-hvm.c | 1429 +
 stubs/Makefile.objs   |1 +
 stubs/xen-hvm.c   |   63 ++
 trace-events  |   11 -
 xen-hvm-stub.c|   63 --
 xen-hvm.c | 1429 -
 9 files changed, 1506 insertions(+), 1506 deletions(-)
 create mode 100644 hw/i386/xen/xen-hvm.c
 create mode 100644 stubs/xen-hvm.c
 delete mode 100644 xen-hvm-stub.c
 delete mode 100644 xen-hvm.c

diff --git a/Makefile.target b/Makefile.target
index 48c027f..d5ff0c7 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -150,8 +150,7 @@ obj-y += migration/ram.o migration/savevm.o
 LIBS := $(libs_softmmu) $(LIBS)
 
 # xen support
-obj-$(CONFIG_XEN_I386) += xen-hvm.o xen-mapcache.o
-obj-$(call lnot,$(CONFIG_XEN_I386)) += xen-hvm-stub.o
+obj-$(CONFIG_XEN_I386) += xen-mapcache.o
 
 # Hardware support
 ifeq ($(TARGET_NAME), sparc64)
diff --git a/hw/i386/xen/Makefile.objs b/hw/i386/xen/Makefile.objs
index 801a68d..daf4f53 100644
--- a/hw/i386/xen/Makefile.objs
+++ b/hw/i386/xen/Makefile.objs
@@ -1 +1 @@
-obj-y += xen_platform.o xen_apic.o xen_pvdevice.o
+obj-y += xen_platform.o xen_apic.o xen_pvdevice.o xen-hvm.o
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index 321fe60..f25d622 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -4,3 +4,14 @@ xen_platform_log(char *s) "xen platform: %s"
 # hw/i386/xen/xen_pvdevice.c
 xen_pv_mmio_read(uint64_t addr) "WARNING: read from Xen PV Device MMIO space 
(address %"PRIx64")"
 xen_pv_mmio_write(uint64_t addr) "WARNING: write to Xen PV Device MMIO space 
(address %"PRIx64")"
+
+# xen-hvm.c
+xen_ram_alloc(unsigned long ram_addr, unsigned long size) "requested: %#lx, 
size %#lx"
+xen_client_set_memory(uint64_t start_addr, unsigned long size, bool log_dirty) 
"%#"PRIx64" size %#lx, log_dirty %i"
+handle_ioreq(void *req, uint32_t type, uint32_t dir, uint32_t df, uint32_t 
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) 
"I/O=%p type=%d dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d 
size=%d"
+handle_ioreq_read(void *req, uint32_t type, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p read 
type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
+handle_ioreq_write(void *req, uint32_t type, uint32_t df, uint32_t 
data_is_ptr, uint64_t addr, uint64_t data, uint32_t count, uint32_t size) 
"I/O=%p write type=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d 
size=%d"
+cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p pio dir=%d 
df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
+cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) 
"I/O=%p pio read reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
+cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t 
size) "I/O=%p pio write reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
+cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy 
dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
new file mode 100644
index 000..b1c05ff
--- /dev/null
+++ b/hw/i386/xen/xen-hvm.c
@@ -0,0 +1,1429 @@
+/*
+ * Copyright (C) 2010   Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "qemu/osdep.h"
+
+#include "cpu.h"
+#include "hw/pci/pci.h"
+#include "hw/i386/pc.h"
+#include "hw/i386/apic-msidef.h"
+#include "hw/xen/xen_common.h"
+#include "hw/xen/xen_backend.h"
+#include "qmp-commands.h"
+
+#include "sysemu/char.h"
+#include "qemu/error-report.h"
+#include "qemu/range.h"
+#include "sysemu/xen-mapcache.h"
+#include "trace.h"
+#include "exec/address-spaces.h"
+
+#include 
+#include 
+#include 
+
+//#define DEBUG_XEN_HVM
+
+#ifdef DEBUG_XEN_HVM
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, "xen: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+static MemoryRegion ram_memory, ram_640k, ram_lo, ram_hi;
+static MemoryRegion *framebuffer;
+static bool xen_in_migration;
+
+/* Compatibility with older version */
+
+/* This allows QEMU to build on a system that has Xen 4.5 or earlier
+ * installed. 

[Xen-devel] [PATCH 21/21] move xen-mapcache.c to hw/i386/xen/

[Stefano Stabellini]

From: Anthony Xu 

move xen-mapcache.c to hw/i386/xen/

Signed-off -by: Anthony Xu 
Reviewed-by: Stefano Stabellini 
---
 Makefile.target|   3 -
 default-configs/i386-softmmu.mak   |   1 -
 default-configs/x86_64-softmmu.mak |   1 -
 hw/i386/xen/Makefile.objs  |   2 +-
 hw/i386/xen/trace-events   |   6 +
 hw/i386/xen/xen-mapcache.c | 459 +
 trace-events   |   5 -
 xen-mapcache.c | 459 -
 8 files changed, 466 insertions(+), 470 deletions(-)
 create mode 100644 hw/i386/xen/xen-mapcache.c
 delete mode 100644 xen-mapcache.c

diff --git a/Makefile.target b/Makefile.target
index d5ff0c7..a535980 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -149,9 +149,6 @@ obj-y += dump.o
 obj-y += migration/ram.o migration/savevm.o
 LIBS := $(libs_softmmu) $(LIBS)
 
-# xen support
-obj-$(CONFIG_XEN_I386) += xen-mapcache.o
-
 # Hardware support
 ifeq ($(TARGET_NAME), sparc64)
 obj-y += hw/sparc64/
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 029e952..d2ab2f6 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -39,7 +39,6 @@ CONFIG_TPM_TIS=$(CONFIG_TPM)
 CONFIG_MC146818RTC=y
 CONFIG_PCI_PIIX=y
 CONFIG_WDT_IB700=y
-CONFIG_XEN_I386=$(CONFIG_XEN)
 CONFIG_ISA_DEBUG=y
 CONFIG_ISA_TESTDEV=y
 CONFIG_VMPORT=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index d1d7432..9bde2f1 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -39,7 +39,6 @@ CONFIG_TPM_TIS=$(CONFIG_TPM)
 CONFIG_MC146818RTC=y
 CONFIG_PCI_PIIX=y
 CONFIG_WDT_IB700=y
-CONFIG_XEN_I386=$(CONFIG_XEN)
 CONFIG_ISA_DEBUG=y
 CONFIG_ISA_TESTDEV=y
 CONFIG_VMPORT=y
diff --git a/hw/i386/xen/Makefile.objs b/hw/i386/xen/Makefile.objs
index daf4f53..be9d10c 100644
--- a/hw/i386/xen/Makefile.objs
+++ b/hw/i386/xen/Makefile.objs
@@ -1 +1 @@
-obj-y += xen_platform.o xen_apic.o xen_pvdevice.o xen-hvm.o
+obj-y += xen_platform.o xen_apic.o xen_pvdevice.o xen-hvm.o xen-mapcache.o
diff --git a/hw/i386/xen/trace-events b/hw/i386/xen/trace-events
index f25d622..547438d 100644
--- a/hw/i386/xen/trace-events
+++ b/hw/i386/xen/trace-events
@@ -15,3 +15,9 @@ cpu_ioreq_pio(void *req, uint32_t dir, uint32_t df, uint32_t 
data_is_ptr, uint64
 cpu_ioreq_pio_read_reg(void *req, uint64_t data, uint64_t addr, uint32_t size) 
"I/O=%p pio read reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
 cpu_ioreq_pio_write_reg(void *req, uint64_t data, uint64_t addr, uint32_t 
size) "I/O=%p pio write reg data=%#"PRIx64" port=%#"PRIx64" size=%d"
 cpu_ioreq_move(void *req, uint32_t dir, uint32_t df, uint32_t data_is_ptr, 
uint64_t addr, uint64_t data, uint32_t count, uint32_t size) "I/O=%p copy 
dir=%d df=%d ptr=%d port=%#"PRIx64" data=%#"PRIx64" count=%d size=%d"
+
+# xen-mapcache.c
+xen_map_cache(uint64_t phys_addr) "want %#"PRIx64
+xen_remap_bucket(uint64_t index) "index %#"PRIx64
+xen_map_cache_return(void* ptr) "%p"
+
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
new file mode 100644
index 000..31debdf
--- /dev/null
+++ b/hw/i386/xen/xen-mapcache.c
@@ -0,0 +1,459 @@
+/*
+ * Copyright (C) 2011   Citrix Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "qemu/osdep.h"
+
+#include 
+
+#include "hw/xen/xen_backend.h"
+#include "sysemu/blockdev.h"
+#include "qemu/bitmap.h"
+
+#include 
+
+#include "sysemu/xen-mapcache.h"
+#include "trace.h"
+
+
+//#define MAPCACHE_DEBUG
+
+#ifdef MAPCACHE_DEBUG
+#  define DPRINTF(fmt, ...) do { \
+fprintf(stderr, "xen_mapcache: " fmt, ## __VA_ARGS__); \
+} while (0)
+#else
+#  define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
+#if HOST_LONG_BITS == 32
+#  define MCACHE_BUCKET_SHIFT 16
+#  define MCACHE_MAX_SIZE (1UL<<31) /* 2GB Cap */
+#else
+#  define MCACHE_BUCKET_SHIFT 20
+#  define MCACHE_MAX_SIZE (1UL<<35) /* 32GB Cap */
+#endif
+#define MCACHE_BUCKET_SIZE (1UL << MCACHE_BUCKET_SHIFT)
+
+/* This is the size of the virtual address space reserve to QEMU that will not
+ * be use by MapCache.
+ * From empirical tests I observed that qemu use 75MB more than the
+ * max_mcache_size.
+ */
+#define NON_MCACHE_MEMORY_SIZE (80 * 1024 * 1024)
+
+typedef struct MapCacheEntry {
+hwaddr paddr_index;
+uint8_t *vaddr_base;
+unsigned long *valid_mapping;
+uint8_t lock;
+hwaddr size;
+struct MapCacheEntry *next;
+} MapCacheEntry;
+
+typedef struct MapCacheRev {
+uint8_t *vaddr_req;
+hwaddr paddr_index;
+hwaddr size;
+QTAILQ_ENTRY(MapCacheRev) next;
+} MapCacheRev;
+
+typedef struct MapCache {
+

[Xen-devel] [PULL 0/21] Please pull xen-20170421-v2-tag for 2.10

[Stefano Stabellini]

Added a fix for the clang build, see
alpine.DEB.2.10.1704251014320.2875@sstabellini-ThinkPad-X260


The following changes since commit 55a19ad8b2d0797e3a8fe90ab99a9bb713824059:

  Update version for v2.9.0-rc1 release (2017-03-21 17:13:29 +)

are available in the git repository at:

  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20170421-v2-tag

for you to fetch changes up to 28b99f473bda682385da944b0404aedbe11ea0dc:

  move xen-mapcache.c to hw/i386/xen/ (2017-04-25 11:04:34 -0700)


Xen 2017/04/21 + fix


Anthony Xu (3):
  move xen-common.c to hw/xen/
  move xen-hvm.c to hw/i386/xen/
  move xen-mapcache.c to hw/i386/xen/

Juergen Gross (2):
  xen: use 5 digit xen versions
  configure: use pkg-config for obtaining xen version

Paul Durrant (7):
  xen: make use of xen_xc implicit in xen_common.h inlines
  xen: rename xen_modified_memory() to xen_hvm_modified_memory()
  xen: create wrappers for all other uses of xc_hvm_XXX() functions
  configure: detect presence of libxendevicemodel
  xen: use libxendevicemodel when available
  xen: use libxendevice model to restrict operations
  xen: additionally restrict xenforeignmemory operations

Stefano Stabellini (9):
  xen: import ring.h from xen
  9p: introduce a type for the 9p header
  xen/9pfs: introduce Xen 9pfs backend
  xen/9pfs: connect to the frontend
  xen/9pfs: receive requests from the frontend
  xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal
  xen/9pfs: send responses back to the frontend
  xen/9pfs: build and register Xen 9pfs backend
  add xen-9p-backend to MAINTAINERS under Xen

 MAINTAINERS  |   1 +
 Makefile.target  |   6 -
 configure| 164 +
 default-configs/i386-softmmu.mak |   1 -
 default-configs/x86_64-softmmu.mak   |   1 -
 hw/9pfs/9p.h |   6 +
 hw/9pfs/Makefile.objs|   1 +
 hw/9pfs/virtio-9p-device.c   |   6 +-
 hw/9pfs/xen-9p-backend.c | 440 
 hw/9pfs/xen-9pfs.h   |  21 ++
 hw/block/xen_blkif.h |   2 +-
 hw/block/xen_disk.c  |   2 +-
 hw/i386/xen/Makefile.objs|   2 +-
 hw/i386/xen/trace-events |  17 +
 xen-hvm.c => hw/i386/xen/xen-hvm.c   |  59 ++--
 xen-mapcache.c => hw/i386/xen/xen-mapcache.c |   2 +-
 hw/i386/xen/xen_platform.c   |   2 +-
 hw/usb/xen-usb.c |   2 +-
 hw/xen/Makefile.objs |   2 +-
 hw/xen/trace-events  |   1 +
 xen-common.c => hw/xen/xen-common.c  |  11 +
 hw/xen/xen_backend.c |   5 +-
 include/exec/ram_addr.h  |   4 +-
 include/hw/xen/io/ring.h | 482 +++
 include/hw/xen/xen.h |   3 +-
 include/hw/xen/xen_backend.h |   5 +-
 include/hw/xen/xen_common.h  | 345 +++
 qemu-options.hx  |   7 +
 stubs/Makefile.objs  |   2 +
 xen-common-stub.c => stubs/xen-common.c  |   0
 xen-hvm-stub.c => stubs/xen-hvm.c|   2 +-
 trace-events |  16 -
 vl.c |   8 +
 33 files changed, 1435 insertions(+), 193 deletions(-)
 create mode 100644 hw/9pfs/xen-9p-backend.c
 create mode 100644 hw/9pfs/xen-9pfs.h
 rename xen-hvm.c => hw/i386/xen/xen-hvm.c (96%)
 rename xen-mapcache.c => hw/i386/xen/xen-mapcache.c (99%)
 rename xen-common.c => hw/xen/xen-common.c (91%)
 create mode 100644 include/hw/xen/io/ring.h
 rename xen-common-stub.c => stubs/xen-common.c (100%)
 rename xen-hvm-stub.c => stubs/xen-hvm.c (94%)

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

[Xen-devel] [PATCH 10/21] xen: import ring.h from xen

[Stefano Stabellini]

Do not use the ring.h header installed on the system. Instead, import
the header into the QEMU codebase. This avoids problems when QEMU is
built against a Xen version too old to provide all the ring macros.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
---
 hw/block/xen_blkif.h |   2 +-
 hw/usb/xen-usb.c |   2 +-
 include/hw/xen/io/ring.h | 482 +++
 3 files changed, 484 insertions(+), 2 deletions(-)
 create mode 100644 include/hw/xen/io/ring.h

diff --git a/hw/block/xen_blkif.h b/hw/block/xen_blkif.h
index 3300b6f..3e6e1ea 100644
--- a/hw/block/xen_blkif.h
+++ b/hw/block/xen_blkif.h
@@ -1,7 +1,7 @@
 #ifndef XEN_BLKIF_H
 #define XEN_BLKIF_H
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 #include 
 
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
index 8e676e6..370b3d9 100644
--- a/hw/usb/xen-usb.c
+++ b/hw/usb/xen-usb.c
@@ -33,7 +33,7 @@
 #include "qapi/qmp/qint.h"
 #include "qapi/qmp/qstring.h"
 
-#include 
+#include "hw/xen/io/ring.h"
 #include 
 
 /*
diff --git a/include/hw/xen/io/ring.h b/include/hw/xen/io/ring.h
new file mode 100644
index 000..abbca47
--- /dev/null
+++ b/include/hw/xen/io/ring.h
@@ -0,0 +1,482 @@
+/**
+ * ring.h
+ * 
+ * Shared producer-consumer ring macros.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Tim Deegan and Andrew Warfield November 2004.
+ */
+
+#ifndef __XEN_PUBLIC_IO_RING_H__
+#define __XEN_PUBLIC_IO_RING_H__
+
+/*
+ * When #include'ing this header, you need to provide the following
+ * declaration upfront:
+ * - standard integers types (uint8_t, uint16_t, etc)
+ * They are provided by stdint.h of the standard headers.
+ *
+ * In addition, if you intend to use the FLEX macros, you also need to
+ * provide the following, before invoking the FLEX macros:
+ * - size_t
+ * - memcpy
+ * - grant_ref_t
+ * These declarations are provided by string.h of the standard headers,
+ * and grant_table.h from the Xen public headers.
+ */
+
+#if __XEN_INTERFACE_VERSION__ < 0x00030208
+#define xen_mb()  mb()
+#define xen_rmb() rmb()
+#define xen_wmb() wmb()
+#endif
+
+typedef unsigned int RING_IDX;
+
+/* Round a 32-bit unsigned constant down to the nearest power of two. */
+#define __RD2(_x)  (((_x) & 0x0002) ? 0x2  : ((_x) & 0x1))
+#define __RD4(_x)  (((_x) & 0x000c) ? __RD2((_x)>>2)<<2: __RD2(_x))
+#define __RD8(_x)  (((_x) & 0x00f0) ? __RD4((_x)>>4)<<4: __RD4(_x))
+#define __RD16(_x) (((_x) & 0xff00) ? __RD8((_x)>>8)<<8: __RD8(_x))
+#define __RD32(_x) (((_x) & 0x) ? __RD16((_x)>>16)<<16 : __RD16(_x))
+
+/*
+ * Calculate size of a shared ring, given the total available space for the
+ * ring and indexes (_sz), and the name tag of the request/response structure.
+ * A ring contains as many entries as will fit, rounded down to the nearest 
+ * power of two (so we can mask with (size-1) to loop around).
+ */
+#define __CONST_RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - offsetof(struct _s##_sring, ring)) / \
+   sizeof(((struct _s##_sring *)0)->ring[0])))
+/*
+ * The same for passing in an actual pointer instead of a name tag.
+ */
+#define __RING_SIZE(_s, _sz) \
+(__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0])))
+
+/*
+ * Macros to make the correct C datatypes for a new kind of ring.
+ * 
+ * To make a new ring datatype, you need to have two message structures,
+ * let's say request_t, and response_t already defined.
+ *
+ * In a header where you want the ring datatype declared, you then do:
+ *
+ * DEFINE_RING_TYPES(mytag, request_t, response_t);
+ *
+ * These expand out to give you a set of types, as you can see below.
+ * The most important of these are:
+ * 
+ * mytag_sring_t  - The shared ring.
+ * 

[Xen-devel] [PATCH 19/21] move xen-common.c to hw/xen/

[Stefano Stabellini]

From: Anthony Xu 

move xen-common.c to hw/xen/

Signed-off -by: Anthony Xu 
Reviewed-by: Stefano Stabellini 
---
 Makefile.target  |   2 -
 hw/xen/Makefile.objs |   2 +-
 hw/xen/xen-common.c  | 169 +++
 stubs/Makefile.objs  |   1 +
 stubs/xen-common.c   |  14 +
 xen-common-stub.c|  14 -
 xen-common.c | 169 ---
 7 files changed, 185 insertions(+), 186 deletions(-)
 create mode 100644 hw/xen/xen-common.c
 create mode 100644 stubs/xen-common.c
 delete mode 100644 xen-common-stub.c
 delete mode 100644 xen-common.c

diff --git a/Makefile.target b/Makefile.target
index 7df2b8c..48c027f 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -150,9 +150,7 @@ obj-y += migration/ram.o migration/savevm.o
 LIBS := $(libs_softmmu) $(LIBS)
 
 # xen support
-obj-$(CONFIG_XEN) += xen-common.o
 obj-$(CONFIG_XEN_I386) += xen-hvm.o xen-mapcache.o
-obj-$(call lnot,$(CONFIG_XEN)) += xen-common-stub.o
 obj-$(call lnot,$(CONFIG_XEN_I386)) += xen-hvm-stub.o
 
 # Hardware support
diff --git a/hw/xen/Makefile.objs b/hw/xen/Makefile.objs
index 4be3ec9..64a70bc 100644
--- a/hw/xen/Makefile.objs
+++ b/hw/xen/Makefile.objs
@@ -1,5 +1,5 @@
 # xen backend driver support
-common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o xen_pvdev.o
+common-obj-$(CONFIG_XEN) += xen_backend.o xen_devconfig.o xen_pvdev.o 
xen-common.o
 
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen-host-pci-device.o
 obj-$(CONFIG_XEN_PCI_PASSTHROUGH) += xen_pt.o xen_pt_config_init.o 
xen_pt_graphics.o xen_pt_msi.o
diff --git a/hw/xen/xen-common.c b/hw/xen/xen-common.c
new file mode 100644
index 000..ae76150
--- /dev/null
+++ b/hw/xen/xen-common.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (C) 2014   Citrix Systems UK Ltd.
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ * Contributions after 2012-01-13 are licensed under the terms of the
+ * GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include "qemu/osdep.h"
+#include "hw/xen/xen_backend.h"
+#include "qmp-commands.h"
+#include "sysemu/char.h"
+#include "sysemu/accel.h"
+#include "migration/migration.h"
+
+//#define DEBUG_XEN
+
+#ifdef DEBUG_XEN
+#define DPRINTF(fmt, ...) \
+do { fprintf(stderr, "xen: " fmt, ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) \
+do { } while (0)
+#endif
+
+xc_interface *xen_xc;
+xenforeignmemory_handle *xen_fmem;
+xendevicemodel_handle *xen_dmod;
+
+static int store_dev_info(int domid, Chardev *cs, const char *string)
+{
+struct xs_handle *xs = NULL;
+char *path = NULL;
+char *newpath = NULL;
+char *pts = NULL;
+int ret = -1;
+
+/* Only continue if we're talking to a pty. */
+if (strncmp(cs->filename, "pty:", 4)) {
+return 0;
+}
+pts = cs->filename + 4;
+
+/* We now have everything we need to set the xenstore entry. */
+xs = xs_open(0);
+if (xs == NULL) {
+fprintf(stderr, "Could not contact XenStore\n");
+goto out;
+}
+
+path = xs_get_domain_path(xs, domid);
+if (path == NULL) {
+fprintf(stderr, "xs_get_domain_path() error\n");
+goto out;
+}
+newpath = realloc(path, (strlen(path) + strlen(string) +
+strlen("/tty") + 1));
+if (newpath == NULL) {
+fprintf(stderr, "realloc error\n");
+goto out;
+}
+path = newpath;
+
+strcat(path, string);
+strcat(path, "/tty");
+if (!xs_write(xs, XBT_NULL, path, pts, strlen(pts))) {
+fprintf(stderr, "xs_write for '%s' fail", string);
+goto out;
+}
+ret = 0;
+
+out:
+free(path);
+xs_close(xs);
+
+return ret;
+}
+
+void xenstore_store_pv_console_info(int i, Chardev *chr)
+{
+if (i == 0) {
+store_dev_info(xen_domid, chr, "/console");
+} else {
+char buf[32];
+snprintf(buf, sizeof(buf), "/device/console/%d", i);
+store_dev_info(xen_domid, chr, buf);
+}
+}
+
+
+static void xenstore_record_dm_state(struct xs_handle *xs, const char *state)
+{
+char path[50];
+
+if (xs == NULL) {
+fprintf(stderr, "xenstore connection not initialized\n");
+exit(1);
+}
+
+snprintf(path, sizeof (path), "device-model/%u/state", xen_domid);
+if (!xs_write(xs, XBT_NULL, path, state, strlen(state))) {
+fprintf(stderr, "error recording dm state\n");
+exit(1);
+}
+}
+
+
+static void xen_change_state_handler(void *opaque, int running,
+ RunState state)
+{
+if (running) {
+/* record state running */
+xenstore_record_dm_state(xenstore, "running");
+}
+}
+
+static int xen_init(MachineState *ms)
+{
+xen_xc = xc_interface_open(0, 0, 0);
+if (xen_xc == NULL) {
+xen_pv_printf(NULL, 0, "can't open xen interface\n");
+ 

[Xen-devel] [PATCH 13/21] xen/9pfs: connect to the frontend

[Stefano Stabellini]

Write the limits of the backend to xenstore. Connect to the frontend.
Upon connection, allocate the rings according to the protocol
specification.

Initialize a QEMUBH to schedule work upon receiving an event channel
notification from the frontend.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 182 ++-
 1 file changed, 181 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index da8ae18..03dd881 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -17,8 +17,41 @@
 #include "qemu/config-file.h"
 #include "fsdev/qemu-fsdev.h"
 
+#define VERSIONS "1"
+#define MAX_RINGS 8
+#define MAX_RING_ORDER 8
+
+typedef struct Xen9pfsRing {
+struct Xen9pfsDev *priv;
+
+int ref;
+xenevtchn_handle   *evtchndev;
+int evtchn;
+int local_port;
+int ring_order;
+struct xen_9pfs_data_intf *intf;
+unsigned char *data;
+struct xen_9pfs_data ring;
+
+struct iovec *sg;
+QEMUBH *bh;
+
+/* local copies, so that we can read/write PDU data directly from
+ * the ring */
+RING_IDX out_cons, out_size, in_cons;
+bool inprogress;
+} Xen9pfsRing;
+
 typedef struct Xen9pfsDev {
 struct XenDevice xendev;  /* must be first */
+V9fsState state;
+char *path;
+char *security_model;
+char *tag;
+char *id;
+
+int num_rings;
+Xen9pfsRing *rings;
 } Xen9pfsDev;
 
 static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
@@ -67,22 +100,169 @@ static int xen_9pfs_init(struct XenDevice *xendev)
 return 0;
 }
 
+static void xen_9pfs_bh(void *opaque)
+{
+}
+
+static void xen_9pfs_evtchn_event(void *opaque)
+{
+}
+
 static int xen_9pfs_free(struct XenDevice *xendev)
 {
-return -1;
+int i;
+Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
+
+g_free(xen_9pdev->id);
+g_free(xen_9pdev->tag);
+g_free(xen_9pdev->path);
+g_free(xen_9pdev->security_model);
+
+for (i = 0; i < xen_9pdev->num_rings; i++) {
+if (xen_9pdev->rings[i].data != NULL) {
+xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
+xen_9pdev->rings[i].data,
+(1 << xen_9pdev->rings[i].ring_order));
+}
+if (xen_9pdev->rings[i].intf != NULL) {
+xengnttab_unmap(xen_9pdev->xendev.gnttabdev,
+xen_9pdev->rings[i].intf,
+1);
+}
+if (xen_9pdev->rings[i].evtchndev > 0) {
+qemu_set_fd_handler(xenevtchn_fd(xen_9pdev->rings[i].evtchndev),
+NULL, NULL, NULL);
+xenevtchn_unbind(xen_9pdev->rings[i].evtchndev,
+ xen_9pdev->rings[i].local_port);
+}
+if (xen_9pdev->rings[i].bh != NULL) {
+qemu_bh_delete(xen_9pdev->rings[i].bh);
+}
+}
+g_free(xen_9pdev->rings);
+return 0;
 }
 
 static int xen_9pfs_connect(struct XenDevice *xendev)
 {
+int i;
+Xen9pfsDev *xen_9pdev = container_of(xendev, Xen9pfsDev, xendev);
+V9fsState *s = _9pdev->state;
+QemuOpts *fsdev;
+
+if (xenstore_read_fe_int(_9pdev->xendev, "num-rings",
+ _9pdev->num_rings) == -1 ||
+xen_9pdev->num_rings > MAX_RINGS || xen_9pdev->num_rings < 1) {
+return -1;
+}
+
+xen_9pdev->rings = g_malloc0(xen_9pdev->num_rings * sizeof(Xen9pfsRing));
+for (i = 0; i < xen_9pdev->num_rings; i++) {
+char *str;
+int ring_order;
+
+xen_9pdev->rings[i].priv = xen_9pdev;
+xen_9pdev->rings[i].evtchn = -1;
+xen_9pdev->rings[i].local_port = -1;
+
+str = g_strdup_printf("ring-ref%u", i);
+if (xenstore_read_fe_int(_9pdev->xendev, str,
+ _9pdev->rings[i].ref) == -1) {
+goto out;
+}
+g_free(str);
+str = g_strdup_printf("event-channel-%u", i);
+if (xenstore_read_fe_int(_9pdev->xendev, str,
+ _9pdev->rings[i].evtchn) == -1) {
+goto out;
+}
+g_free(str);
+
+xen_9pdev->rings[i].intf =  xengnttab_map_grant_ref(
+xen_9pdev->xendev.gnttabdev,
+xen_9pdev->xendev.dom,
+xen_9pdev->rings[i].ref,
+PROT_READ | PROT_WRITE);
+if (!xen_9pdev->rings[i].intf) {
+goto out;
+}
+ring_order = xen_9pdev->rings[i].intf->ring_order;
+if (ring_order > MAX_RING_ORDER) {
+goto out;
+}
+xen_9pdev->rings[i].ring_order = ring_order;
+xen_9pdev->rings[i].data = xengnttab_map_domain_grant_refs(
+xen_9pdev->xendev.gnttabdev,
+(1 << ring_order),
+xen_9pdev->xendev.dom,
+

[Xen-devel] [PATCH 16/21] xen/9pfs: send responses back to the frontend

[Stefano Stabellini]

Once a request is completed, xen_9pfs_push_and_notify gets called. In
xen_9pfs_push_and_notify, update the indexes (data has already been
copied to the sg by the common code) and send a notification to the
frontend.

Schedule the bottom-half to check if we already have any other requests
pending.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 9068703..9c7f41a 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -180,6 +180,25 @@ static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
 
 static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
 {
+RING_IDX prod;
+Xen9pfsDev *priv = container_of(pdu->s, Xen9pfsDev, state);
+Xen9pfsRing *ring = >rings[pdu->tag % priv->num_rings];
+
+g_free(ring->sg);
+ring->sg = NULL;
+
+ring->intf->out_cons = ring->out_cons;
+xen_wmb();
+
+prod = ring->intf->in_prod;
+xen_rmb();
+ring->intf->in_prod = prod + pdu->size;
+xen_wmb();
+
+ring->inprogress = false;
+xenevtchn_notify(ring->evtchndev, ring->local_port);
+
+qemu_bh_schedule(ring->bh);
 }
 
 static const struct V9fsTransport xen_9p_transport = {
-- 
1.9.1


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

[Xen-devel] [PATCH 15/21] xen/9pfs: implement in/out_iov_from_pdu and vmarshal/vunmarshal

[Stefano Stabellini]

Implement xen_9pfs_init_in/out_iov_from_pdu and
xen_9pfs_pdu_vmarshal/vunmarshall by creating new sg pointing to the
data on the ring.

This is safe as we only handle one request per ring at any given time.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 99 +++-
 1 file changed, 97 insertions(+), 2 deletions(-)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 8820e8f..9068703 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -54,12 +54,81 @@ typedef struct Xen9pfsDev {
 Xen9pfsRing *rings;
 } Xen9pfsDev;
 
+static void xen_9pfs_in_sg(Xen9pfsRing *ring,
+   struct iovec *in_sg,
+   int *num,
+   uint32_t idx,
+   uint32_t size)
+{
+RING_IDX cons, prod, masked_prod, masked_cons;
+
+cons = ring->intf->in_cons;
+prod = ring->intf->in_prod;
+xen_rmb();
+masked_prod = xen_9pfs_mask(prod, XEN_FLEX_RING_SIZE(ring->ring_order));
+masked_cons = xen_9pfs_mask(cons, XEN_FLEX_RING_SIZE(ring->ring_order));
+
+if (masked_prod < masked_cons) {
+in_sg[0].iov_base = ring->ring.in + masked_prod;
+in_sg[0].iov_len = masked_cons - masked_prod;
+*num = 1;
+} else {
+in_sg[0].iov_base = ring->ring.in + masked_prod;
+in_sg[0].iov_len = XEN_FLEX_RING_SIZE(ring->ring_order) - masked_prod;
+in_sg[1].iov_base = ring->ring.in;
+in_sg[1].iov_len = masked_cons;
+*num = 2;
+}
+}
+
+static void xen_9pfs_out_sg(Xen9pfsRing *ring,
+struct iovec *out_sg,
+int *num,
+uint32_t idx)
+{
+RING_IDX cons, prod, masked_prod, masked_cons;
+
+cons = ring->intf->out_cons;
+prod = ring->intf->out_prod;
+xen_rmb();
+masked_prod = xen_9pfs_mask(prod, XEN_FLEX_RING_SIZE(ring->ring_order));
+masked_cons = xen_9pfs_mask(cons, XEN_FLEX_RING_SIZE(ring->ring_order));
+
+if (masked_cons < masked_prod) {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = ring->out_size;
+*num = 1;
+} else {
+if (ring->out_size >
+(XEN_FLEX_RING_SIZE(ring->ring_order) - masked_cons)) {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = XEN_FLEX_RING_SIZE(ring->ring_order) -
+masked_cons;
+out_sg[1].iov_base = ring->ring.out;
+out_sg[1].iov_len = ring->out_size -
+(XEN_FLEX_RING_SIZE(ring->ring_order) -
+ masked_cons);
+*num = 2;
+} else {
+out_sg[0].iov_base = ring->ring.out + masked_cons;
+out_sg[0].iov_len = ring->out_size;
+*num = 1;
+}
+}
+}
+
 static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
  size_t offset,
  const char *fmt,
  va_list ap)
 {
-return 0;
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+struct iovec in_sg[2];
+int num;
+
+xen_9pfs_in_sg(_9pfs->rings[pdu->tag % xen_9pfs->num_rings],
+   in_sg, , pdu->idx, ROUND_UP(offset + 128, 512));
+return v9fs_iov_vmarshal(in_sg, num, offset, 0, fmt, ap);
 }
 
 static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
@@ -67,13 +136,29 @@ static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
const char *fmt,
va_list ap)
 {
-return 0;
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+struct iovec out_sg[2];
+int num;
+
+xen_9pfs_out_sg(_9pfs->rings[pdu->tag % xen_9pfs->num_rings],
+out_sg, , pdu->idx);
+return v9fs_iov_vunmarshal(out_sg, num, offset, 0, fmt, ap);
 }
 
 static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
struct iovec **piov,
unsigned int *pniov)
 {
+Xen9pfsDev *xen_9pfs = container_of(pdu->s, Xen9pfsDev, state);
+Xen9pfsRing *ring = _9pfs->rings[pdu->tag % xen_9pfs->num_rings];
+int num;
+
+g_free(ring->sg);
+
+ring->sg = g_malloc0(sizeof(*ring->sg) * 2);
+xen_9pfs_out_sg(ring, ring->sg, , pdu->idx);
+*piov = ring->sg;
+*pniov = num;
 }
 
 static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
@@ -81,6 +166,16 @@ static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
   unsigned int *pniov,
   size_t size)
 {
+Xen9pfsDev *xen_9pfs = 

[Xen-devel] [PATCH 12/21] xen/9pfs: introduce Xen 9pfs backend

[Stefano Stabellini]

Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
Xen backend and add struct V9fsTransport to register as v9fs transport.

All functions are empty stubs for now.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 96 
 hw/9pfs/xen-9pfs.h   | 21 +++
 2 files changed, 117 insertions(+)
 create mode 100644 hw/9pfs/xen-9p-backend.c
 create mode 100644 hw/9pfs/xen-9pfs.h

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
new file mode 100644
index 000..da8ae18
--- /dev/null
+++ b/hw/9pfs/xen-9p-backend.c
@@ -0,0 +1,96 @@
+/*
+ * Xen 9p backend
+ *
+ * Copyright Aporeto 2017
+ *
+ * Authors:
+ *  Stefano Stabellini 
+ *
+ */
+
+#include "qemu/osdep.h"
+
+#include "hw/hw.h"
+#include "hw/9pfs/9p.h"
+#include "hw/xen/xen_backend.h"
+#include "hw/9pfs/xen-9pfs.h"
+#include "qemu/config-file.h"
+#include "fsdev/qemu-fsdev.h"
+
+typedef struct Xen9pfsDev {
+struct XenDevice xendev;  /* must be first */
+} Xen9pfsDev;
+
+static ssize_t xen_9pfs_pdu_vmarshal(V9fsPDU *pdu,
+ size_t offset,
+ const char *fmt,
+ va_list ap)
+{
+return 0;
+}
+
+static ssize_t xen_9pfs_pdu_vunmarshal(V9fsPDU *pdu,
+   size_t offset,
+   const char *fmt,
+   va_list ap)
+{
+return 0;
+}
+
+static void xen_9pfs_init_out_iov_from_pdu(V9fsPDU *pdu,
+   struct iovec **piov,
+   unsigned int *pniov)
+{
+}
+
+static void xen_9pfs_init_in_iov_from_pdu(V9fsPDU *pdu,
+  struct iovec **piov,
+  unsigned int *pniov,
+  size_t size)
+{
+}
+
+static void xen_9pfs_push_and_notify(V9fsPDU *pdu)
+{
+}
+
+static const struct V9fsTransport xen_9p_transport = {
+.pdu_vmarshal = xen_9pfs_pdu_vmarshal,
+.pdu_vunmarshal = xen_9pfs_pdu_vunmarshal,
+.init_in_iov_from_pdu = xen_9pfs_init_in_iov_from_pdu,
+.init_out_iov_from_pdu = xen_9pfs_init_out_iov_from_pdu,
+.push_and_notify = xen_9pfs_push_and_notify,
+};
+
+static int xen_9pfs_init(struct XenDevice *xendev)
+{
+return 0;
+}
+
+static int xen_9pfs_free(struct XenDevice *xendev)
+{
+return -1;
+}
+
+static int xen_9pfs_connect(struct XenDevice *xendev)
+{
+return 0;
+}
+
+static void xen_9pfs_alloc(struct XenDevice *xendev)
+{
+}
+
+static void xen_9pfs_disconnect(struct XenDevice *xendev)
+{
+}
+
+struct XenDevOps xen_9pfs_ops = {
+.size   = sizeof(Xen9pfsDev),
+.flags  = DEVOPS_FLAG_NEED_GNTDEV,
+.alloc  = xen_9pfs_alloc,
+.init   = xen_9pfs_init,
+.initialise = xen_9pfs_connect,
+.disconnect = xen_9pfs_disconnect,
+.free   = xen_9pfs_free,
+};
diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
new file mode 100644
index 000..2d6ef78
--- /dev/null
+++ b/hw/9pfs/xen-9pfs.h
@@ -0,0 +1,21 @@
+/*
+ * Xen 9p backend
+ *
+ * Copyright Aporeto 2017
+ *
+ * Authors:
+ *  Stefano Stabellini 
+ *
+ * This work is licensed under the terms of the GNU GPL version 2 or
+ * later. See the COPYING file in the top-level directory.
+ *
+ */
+
+#include 
+#include "hw/xen/io/ring.h"
+
+/*
+ * Do not merge into xen-9p-backend.c: clang doesn't allow unused static
+ * inline functions in c files.
+ */
+DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
-- 
1.9.1


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

[Xen-devel] [PATCH 18/21] add xen-9p-backend to MAINTAINERS under Xen

[Stefano Stabellini]

Signed-off-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
CC: gr...@kaod.org
CC: anthony.per...@citrix.com
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 779c429..420505e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -327,6 +327,7 @@ L: xen-de...@lists.xenproject.org
 S: Supported
 F: xen-*
 F: */xen*
+F: hw/9pfs/xen-9p-backend.c
 F: hw/char/xen_console.c
 F: hw/display/xenfb.c
 F: hw/net/xen_nic.c
-- 
1.9.1


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

[Xen-devel] [PATCH 14/21] xen/9pfs: receive requests from the frontend

[Stefano Stabellini]

Upon receiving an event channel notification from the frontend, schedule
the bottom half. From the bottom half, read one request from the ring,
create a pdu and call pdu_submit to handle it.

For now, only handle one request per ring at a time.

Signed-off-by: Stefano Stabellini 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/xen-9p-backend.c | 50 
 1 file changed, 50 insertions(+)

diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
index 03dd881..8820e8f 100644
--- a/hw/9pfs/xen-9p-backend.c
+++ b/hw/9pfs/xen-9p-backend.c
@@ -100,12 +100,62 @@ static int xen_9pfs_init(struct XenDevice *xendev)
 return 0;
 }
 
+static int xen_9pfs_receive(Xen9pfsRing *ring)
+{
+P9MsgHeader h;
+RING_IDX cons, prod, masked_prod, masked_cons;
+V9fsPDU *pdu;
+
+if (ring->inprogress) {
+return 0;
+}
+
+cons = ring->intf->out_cons;
+prod = ring->intf->out_prod;
+xen_rmb();
+
+if (xen_9pfs_queued(prod, cons, XEN_FLEX_RING_SIZE(ring->ring_order)) <
+sizeof(h)) {
+return 0;
+}
+ring->inprogress = true;
+
+masked_prod = xen_9pfs_mask(prod, XEN_FLEX_RING_SIZE(ring->ring_order));
+masked_cons = xen_9pfs_mask(cons, XEN_FLEX_RING_SIZE(ring->ring_order));
+
+xen_9pfs_read_packet((uint8_t *) , ring->ring.out, sizeof(h),
+ masked_prod, _cons,
+ XEN_FLEX_RING_SIZE(ring->ring_order));
+
+/* cannot fail, because we only handle one request per ring at a time */
+pdu = pdu_alloc(>priv->state);
+pdu->size = le32_to_cpu(h.size_le);
+pdu->id = h.id;
+pdu->tag = le32_to_cpu(h.tag_le);
+ring->out_size = le32_to_cpu(h.size_le);
+ring->out_cons = cons + le32_to_cpu(h.size_le);
+
+qemu_co_queue_init(>complete);
+pdu_submit(pdu);
+
+return 0;
+}
+
 static void xen_9pfs_bh(void *opaque)
 {
+Xen9pfsRing *ring = opaque;
+xen_9pfs_receive(ring);
 }
 
 static void xen_9pfs_evtchn_event(void *opaque)
 {
+Xen9pfsRing *ring = opaque;
+evtchn_port_t port;
+
+port = xenevtchn_pending(ring->evtchndev);
+xenevtchn_unmask(ring->evtchndev, port);
+
+qemu_bh_schedule(ring->bh);
 }
 
 static int xen_9pfs_free(struct XenDevice *xendev)
-- 
1.9.1


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

[Xen-devel] [PATCH 09/21] configure: use pkg-config for obtaining xen version

[Stefano Stabellini]

From: Juergen Gross 

Instead of trying to guess the Xen version to use by compiling various
test programs first just ask the system via pkg-config. Only if it
can't return the version fall back to the test program scheme.

If configure is being called with dedicated flags for the Xen libraries
use those instead of the pkg-config output. This will avoid breaking
an in-tree Xen build of an old Xen version while a new Xen version is
installed on the build machine: pkg-config would pick up the installed
Xen config files as the Xen tree wouldn't contain any of them.

Signed-off-by: Juergen Gross 
Signed-off-by: Stefano Stabellini 
Tested-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
---
 configure | 159 ++
 1 file changed, 88 insertions(+), 71 deletions(-)

diff --git a/configure b/configure
index 271bea8..3133ef8 100755
--- a/configure
+++ b/configure
@@ -1975,30 +1975,46 @@ fi
 # xen probe
 
 if test "$xen" != "no" ; then
-  xen_libs="-lxenstore -lxenctrl -lxenguest"
-  xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
+  # Check whether Xen library path is specified via --extra-ldflags to avoid
+  # overriding this setting with pkg-config output. If not, try pkg-config
+  # to obtain all needed flags.
+
+  if ! echo $EXTRA_LDFLAGS | grep tools/libxc > /dev/null && \
+ $pkg_config --exists xencontrol ; then
+xen_ctrl_version="$(printf '%d%02d%02d' \
+  $($pkg_config --modversion xencontrol | sed 's/\./ /g') )"
+xen=yes
+xen_pc="xencontrol xenstore xenguest xenforeignmemory xengnttab"
+xen_pc="$xen_pc xenevtchn xendevicemodel"
+QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
+libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
+LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
+  else
 
-  # First we test whether Xen headers and libraries are available.
-  # If no, we are done and there is no Xen support.
-  # If yes, more tests are run to detect the Xen version.
+xen_libs="-lxenstore -lxenctrl -lxenguest"
+xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
 
-  # Xen (any)
-  cat > $TMPC < $TMPC <
 int main(void) {
   return 0;
 }
 EOF
-  if ! compile_prog "" "$xen_libs" ; then
-# Xen not found
-if test "$xen" = "yes" ; then
-  feature_not_found "xen" "Install xen devel"
-fi
-xen=no
+if ! compile_prog "" "$xen_libs" ; then
+  # Xen not found
+  if test "$xen" = "yes" ; then
+feature_not_found "xen" "Install xen devel"
+  fi
+  xen=no
 
-  # Xen unstable
-  elif
-  cat > $TMPC < $TMPC <
@@ -2011,13 +2027,13 @@ int main(void) {
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
-then
-xen_stable_libs="-lxendevicemodel $xen_stable_libs"
-xen_ctrl_version=40900
-xen=yes
-  elif
-  cat > $TMPC < $TMPC < $TMPC < $TMPC < $TMPC < $TMPC <
 #include 
 int main(void) {
@@ -2133,14 +2149,14 @@ int main(void) {
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs"
-then
-xen_ctrl_version=40700
-xen=yes
-
-  # Xen 4.6
-  elif
-  cat > $TMPC < $TMPC <
 #include 
 #include 
@@ -2161,14 +2177,14 @@ int main(void) {
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs"
-then
-xen_ctrl_version=40600
-xen=yes
-
-  # Xen 4.5
-  elif
-  cat > $TMPC < $TMPC <
 #include 
 #include 
@@ -2188,13 +2204,13 @@ int main(void) {
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs"
-then
-xen_ctrl_version=40500
-xen=yes
+compile_prog "" "$xen_libs"
+  then
+  xen_ctrl_version=40500
+  xen=yes
 
-  elif
-  cat > $TMPC < $TMPC <
 #include 
 #include 
@@ -2213,24 +2229,25 @@ int main(void) {
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs"
-then
-xen_ctrl_version=40200
-xen=yes
+compile_prog "" "$xen_libs"
+  then
+  xen_ctrl_version=40200
+  xen=yes
 
-  else
-if test "$xen" = "yes" ; then
-  feature_not_found "xen (unsupported version)" \
-"Install a supported xen (xen 4.2 or newer)"
+else
+  if test "$xen" = "yes" ; then
+feature_not_found "xen (unsupported version)" \
+  "Install a supported xen (xen 4.2 or newer)"
+  fi
+  xen=no
 fi
-xen=no
-  fi
 
-  if test "$xen" = yes; then
-if test $xen_ctrl_version -ge 40701  ; then
-  libs_softmmu="$xen_stable_libs $libs_softmmu"
+if test "$xen" = yes; then
+  if test $xen_ctrl_version -ge 40701  ; then
+libs_softmmu="$xen_stable_libs $libs_softmmu"
+  fi
+  libs_softmmu="$xen_libs $libs_softmmu"
 fi
-libs_softmmu="$xen_libs $libs_softmmu"
   fi
 fi
 
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH 04/21] configure: detect presence of libxendevicemodel

[Stefano Stabellini]

From: Paul Durrant 

This patch adds code in configure to set CONFIG_XEN_CTRL_INTERFACE_VERSION
to a new value of 490 if libxendevicemodel is present in the build
environment.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Anthony Perard 
Reviewed-by: Stefano Stabellini 
---
 configure | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 3291603..e333547 100755
--- a/configure
+++ b/configure
@@ -1976,7 +1976,7 @@ fi
 
 if test "$xen" != "no" ; then
   xen_libs="-lxenstore -lxenctrl -lxenguest"
-  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
+  xen_stable_libs="-lxencall -lxenforeignmemory -lxengnttab -lxenevtchn"
 
   # First we test whether Xen headers and libraries are available.
   # If no, we are done and there is no Xen support.
@@ -1999,6 +1999,25 @@ EOF
   # Xen unstable
   elif
   cat > $TMPC <
+int main(void) {
+  xendevicemodel_handle *xd;
+
+  xd = xendevicemodel_open(0, 0);
+  xendevicemodel_close(xd);
+
+  return 0;
+}
+EOF
+  compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+then
+xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+xen_ctrl_version=490
+xen=yes
+  elif
+  cat > $TMPC 

[Xen-devel] [PATCH 05/21] xen: use libxendevicemodel when available

[Stefano Stabellini]

From: Paul Durrant 

This patch modifies the wrapper functions in xen_common.h to use the
new xendevicemodel interface if it is available along with compatibility
code to use the old libxenctrl interface if it is not.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Anthony Perard 
Reviewed-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 203 +---
 xen-common.c|   8 ++
 2 files changed, 178 insertions(+), 33 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 31cf25f..b1f5f53 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -26,48 +26,184 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
+
+typedef xc_interface xendevicemodel_handle;
+
+static inline xendevicemodel_handle *xendevicemodel_open(
+struct xentoollog_logger *logger, unsigned int open_flags)
+{
+return xen_xc;
+}
+
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
+
+static inline int xendevicemodel_create_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
+ioservid_t *id)
+{
+return xc_hvm_create_ioreq_server(dmod, domid, handle_bufioreq,
+  id);
+}
+
+static inline 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,
+evtchn_port_t *bufioreq_port)
+{
+return xc_hvm_get_ioreq_server_info(dmod, domid, id, ioreq_pfn,
+bufioreq_pfn, bufioreq_port);
+}
+
+static inline int xendevicemodel_map_io_range_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
+uint64_t start, uint64_t end)
+{
+return xc_hvm_map_io_range_to_ioreq_server(dmod, domid, id, is_mmio,
+   start, end);
+}
+
+static inline int xendevicemodel_unmap_io_range_from_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int is_mmio,
+uint64_t start, uint64_t end)
+{
+return xc_hvm_unmap_io_range_from_ioreq_server(dmod, domid, id, is_mmio,
+   start, end);
+}
+
+static inline int xendevicemodel_map_pcidev_to_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
+uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
+{
+return xc_hvm_map_pcidev_to_ioreq_server(dmod, domid, id, segment,
+ bus, device, function);
+}
+
+static inline int xendevicemodel_unmap_pcidev_from_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id,
+uint16_t segment, uint8_t bus, uint8_t device, uint8_t function)
+{
+return xc_hvm_unmap_pcidev_from_ioreq_server(dmod, domid, id, segment,
+ bus, device, function);
+}
+
+static inline int xendevicemodel_destroy_ioreq_server(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id)
+{
+return xc_hvm_destroy_ioreq_server(dmod, domid, id);
+}
+
+static inline int xendevicemodel_set_ioreq_server_state(
+xendevicemodel_handle *dmod, domid_t domid, ioservid_t id, int enabled)
+{
+return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
+}
+
+#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
+
+static inline int xendevicemodel_set_pci_intx_level(
+xendevicemodel_handle *dmod, domid_t domid, uint16_t segment,
+uint8_t bus, uint8_t device, uint8_t intx, unsigned int level)
+{
+return xc_hvm_set_pci_intx_level(dmod, domid, segment, bus, device,
+ intx, level);
+}
+
+static inline int xendevicemodel_set_isa_irq_level(
+xendevicemodel_handle *dmod, domid_t domid, uint8_t irq,
+unsigned int level)
+{
+return xc_hvm_set_isa_irq_level(dmod, domid, irq, level);
+}
+
+static inline int xendevicemodel_set_pci_link_route(
+xendevicemodel_handle *dmod, domid_t domid, uint8_t link, uint8_t irq)
+{
+return xc_hvm_set_pci_link_route(dmod, domid, link, irq);
+}
+
+static inline int xendevicemodel_inject_msi(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t msi_addr,
+uint32_t msi_data)
+{
+return xc_hvm_inject_msi(dmod, domid, msi_addr, msi_data);
+}
+
+static inline int xendevicemodel_track_dirty_vram(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t first_pfn,
+uint32_t nr, unsigned long *dirty_bitmap)
+{
+return xc_hvm_track_dirty_vram(dmod, domid, first_pfn, nr,
+   dirty_bitmap);
+}
+
+static inline int xendevicemodel_modified_memory(
+xendevicemodel_handle *dmod, domid_t domid, uint64_t first_pfn,
+

[Xen-devel] [PATCH 02/21] xen: rename xen_modified_memory() to xen_hvm_modified_memory()

[Stefano Stabellini]

From: Paul Durrant 

This patch is a purely cosmetic change that avoids a name collision in
a subsequent patch.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
Reviewed-by: Stefano Stabellini 
---
 include/exec/ram_addr.h | 4 ++--
 include/hw/xen/xen.h| 2 +-
 xen-hvm-stub.c  | 2 +-
 xen-hvm.c   | 2 +-
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index b05dc84..2964730 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -260,7 +260,7 @@ static inline void 
cpu_physical_memory_set_dirty_range(ram_addr_t start,
 
 rcu_read_unlock();
 
-xen_modified_memory(start, length);
+xen_hvm_modified_memory(start, length);
 }
 
 #if !defined(_WIN32)
@@ -314,7 +314,7 @@ static inline void 
cpu_physical_memory_set_dirty_lebitmap(unsigned long *bitmap,
 
 rcu_read_unlock();
 
-xen_modified_memory(start, pages << TARGET_PAGE_BITS);
+xen_hvm_modified_memory(start, pages << TARGET_PAGE_BITS);
 } else {
 uint8_t clients = tcg_enabled() ? DIRTY_CLIENTS_ALL : 
DIRTY_CLIENTS_NOCODE;
 /*
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 09c2ce5..2b1733b 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -43,7 +43,7 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory);
 
 void xen_ram_alloc(ram_addr_t ram_addr, ram_addr_t size,
struct MemoryRegion *mr, Error **errp);
-void xen_modified_memory(ram_addr_t start, ram_addr_t length);
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length);
 
 void xen_register_framebuffer(struct MemoryRegion *mr);
 
diff --git a/xen-hvm-stub.c b/xen-hvm-stub.c
index c500325..3ca6c51 100644
--- a/xen-hvm-stub.c
+++ b/xen-hvm-stub.c
@@ -50,7 +50,7 @@ void xen_register_framebuffer(MemoryRegion *mr)
 {
 }
 
-void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 }
 
diff --git a/xen-hvm.c b/xen-hvm.c
index dbb8c66..edf4983 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1391,7 +1391,7 @@ void xen_shutdown_fatal_error(const char *fmt, ...)
 qemu_system_shutdown_request();
 }
 
-void xen_modified_memory(ram_addr_t start, ram_addr_t length)
+void xen_hvm_modified_memory(ram_addr_t start, ram_addr_t length)
 {
 if (unlikely(xen_in_migration)) {
 int rc;
-- 
1.9.1


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

[Xen-devel] [PATCH 03/21] xen: create wrappers for all other uses of xc_hvm_XXX() functions

[Stefano Stabellini]

From: Paul Durrant 

This patch creates inline wrapper functions in xen_common.h for all open
coded calls to xc_hvm_XXX() functions outside of xen_common.h so that use
of xen_xc can be made implicit. This again is in preparation for the move
to using libxendevicemodel.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
Reviewed-by: Stefano Stabellini 
---
 hw/i386/xen/xen_platform.c  |  2 +-
 include/hw/xen/xen_common.h | 44 
 xen-hvm.c   | 27 +--
 3 files changed, 58 insertions(+), 15 deletions(-)

diff --git a/hw/i386/xen/xen_platform.c b/hw/i386/xen/xen_platform.c
index 6010f35..1419fc9 100644
--- a/hw/i386/xen/xen_platform.c
+++ b/hw/i386/xen/xen_platform.c
@@ -195,7 +195,7 @@ static void platform_fixed_ioport_writeb(void *opaque, 
uint32_t addr, uint32_t v
 case 0: /* Platform flags */ {
 hvmmem_type_t mem_type = (val & PFFLAG_ROM_LOCK) ?
 HVMMEM_ram_ro : HVMMEM_ram_rw;
-if (xc_hvm_set_mem_type(xen_xc, xen_domid, mem_type, 0xc0, 0x40)) {
+if (xen_set_mem_type(xen_domid, mem_type, 0xc0, 0x40)) {
 DPRINTF("unable to change ro/rw state of ROM memory area!\n");
 } else {
 s->flags = val & PFFLAG_ROM_LOCK;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 1e08b98..31cf25f 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -26,6 +26,50 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
+static inline int xen_set_mem_type(domid_t domid, hvmmem_type_t type,
+   uint64_t first_pfn, uint32_t nr)
+{
+return xc_hvm_set_mem_type(xen_xc, domid, type, first_pfn, nr);
+}
+
+static inline int xen_set_pci_intx_level(domid_t domid, uint16_t segment,
+ uint8_t bus, uint8_t device,
+ uint8_t intx, unsigned int level)
+{
+return xc_hvm_set_pci_intx_level(xen_xc, domid, segment, bus, device,
+ intx, level);
+}
+
+static inline int xen_set_pci_link_route(domid_t domid, uint8_t link,
+ uint8_t irq)
+{
+return xc_hvm_set_pci_link_route(xen_xc, domid, link, irq);
+}
+
+static inline int xen_inject_msi(domid_t domid, uint64_t msi_addr,
+ uint32_t msi_data)
+{
+return xc_hvm_inject_msi(xen_xc, domid, msi_addr, msi_data);
+}
+
+static inline int xen_set_isa_irq_level(domid_t domid, uint8_t irq,
+unsigned int level)
+{
+return xc_hvm_set_isa_irq_level(xen_xc, domid, irq, level);
+}
+
+static inline int xen_track_dirty_vram(domid_t domid, uint64_t first_pfn,
+   uint32_t nr, unsigned long *bitmap)
+{
+return xc_hvm_track_dirty_vram(xen_xc, domid, first_pfn, nr, bitmap);
+}
+
+static inline int xen_modified_memory(domid_t domid, uint64_t first_pfn,
+  uint32_t nr)
+{
+return xc_hvm_modified_memory(xen_xc, domid, first_pfn, nr);
+}
+
 /* Xen 4.2 through 4.6 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 471
 
diff --git a/xen-hvm.c b/xen-hvm.c
index edf4983..4b928cf 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -125,8 +125,8 @@ int xen_pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 
 void xen_piix3_set_irq(void *opaque, int irq_num, int level)
 {
-xc_hvm_set_pci_intx_level(xen_xc, xen_domid, 0, 0, irq_num >> 2,
-  irq_num & 3, level);
+xen_set_pci_intx_level(xen_domid, 0, 0, irq_num >> 2,
+   irq_num & 3, level);
 }
 
 void xen_piix_pci_write_config_client(uint32_t address, uint32_t val, int len)
@@ -141,7 +141,7 @@ void xen_piix_pci_write_config_client(uint32_t address, 
uint32_t val, int len)
 }
 v &= 0xf;
 if (((address + i) >= 0x60) && ((address + i) <= 0x63)) {
-xc_hvm_set_pci_link_route(xen_xc, xen_domid, address + i - 0x60, 
v);
+xen_set_pci_link_route(xen_domid, address + i - 0x60, v);
 }
 }
 }
@@ -156,7 +156,7 @@ int xen_is_pirq_msi(uint32_t msi_data)
 
 void xen_hvm_inject_msi(uint64_t addr, uint32_t data)
 {
-xc_hvm_inject_msi(xen_xc, xen_domid, addr, data);
+xen_inject_msi(xen_domid, addr, data);
 }
 
 static void xen_suspend_notifier(Notifier *notifier, void *data)
@@ -168,7 +168,7 @@ static void xen_suspend_notifier(Notifier *notifier, void 
*data)
 
 static void xen_set_irq(void *opaque, int irq, int level)
 {
-xc_hvm_set_isa_irq_level(xen_xc, xen_domid, irq, level);
+xen_set_isa_irq_level(xen_domid, irq, level);
 }
 
 qemu_irq *xen_interrupt_controller_init(void)
@@ -481,10 +481,10 @@ static void xen_set_memory(struct MemoryListener 
*listener,
section->mr, 

[Xen-devel] [PATCH 11/21] 9p: introduce a type for the 9p header

[Stefano Stabellini]

Use the new type in virtio-9p-device.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Greg Kurz 
Reviewed-by: Philippe Mathieu-Daudé 
CC: anthony.per...@citrix.com
CC: jgr...@suse.com
CC: Aneesh Kumar K.V 
CC: Greg Kurz 
---
 hw/9pfs/9p.h   | 6 ++
 hw/9pfs/virtio-9p-device.c | 6 +-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/hw/9pfs/9p.h b/hw/9pfs/9p.h
index b7e8362..5312d8a 100644
--- a/hw/9pfs/9p.h
+++ b/hw/9pfs/9p.h
@@ -119,6 +119,12 @@ static inline char *rpath(FsContext *ctx, const char *path)
 typedef struct V9fsPDU V9fsPDU;
 struct V9fsState;
 
+typedef struct {
+uint32_t size_le;
+uint8_t id;
+uint16_t tag_le;
+} QEMU_PACKED P9MsgHeader;
+
 struct V9fsPDU
 {
 uint32_t size;
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
index 27a4a32..3782f43 100644
--- a/hw/9pfs/virtio-9p-device.c
+++ b/hw/9pfs/virtio-9p-device.c
@@ -46,11 +46,7 @@ static void handle_9p_output(VirtIODevice *vdev, VirtQueue 
*vq)
 VirtQueueElement *elem;
 
 while ((pdu = pdu_alloc(s))) {
-struct {
-uint32_t size_le;
-uint8_t id;
-uint16_t tag_le;
-} QEMU_PACKED out;
+P9MsgHeader out;
 
 elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
 if (!elem) {
-- 
1.9.1


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

[Xen-devel] [PATCH 07/21] xen: use libxendevice model to restrict operations

[Stefano Stabellini]

From: Paul Durrant 

This patch adds a command-line option (-xen-domid-restrict) which will
use the new libxendevicemodel API to restrict devicemodel [1] operations
to the specified domid. (Such operations are not applicable to the xenpv
machine type).

This patch also adds a tracepoint to allow successful enabling of the
restriction to be monitored.

[1] I.e. operations issued by libxendevicemodel. Operation issued by other
xen libraries (e.g. libxenforeignmemory) are currently still unrestricted
but this will be rectified by subsequent patches.

Signed-off-by: Paul Durrant 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/trace-events |  1 +
 include/hw/xen/xen.h|  1 +
 include/hw/xen/xen_common.h | 20 
 qemu-options.hx |  7 +++
 vl.c|  8 
 xen-hvm.c   |  8 
 6 files changed, 45 insertions(+)

diff --git a/hw/xen/trace-events b/hw/xen/trace-events
index c4fb6f1..5615dce 100644
--- a/hw/xen/trace-events
+++ b/hw/xen/trace-events
@@ -11,3 +11,4 @@ xen_map_portio_range(uint32_t id, uint64_t start_addr, 
uint64_t end_addr) "id: %
 xen_unmap_portio_range(uint32_t id, uint64_t start_addr, uint64_t end_addr) 
"id: %u start: %#"PRIx64" end: %#"PRIx64
 xen_map_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
 xen_unmap_pcidev(uint32_t id, uint8_t bus, uint8_t dev, uint8_t func) "id: %u 
bdf: %02x.%02x.%02x"
+xen_domid_restrict(int err) "err: %u"
diff --git a/include/hw/xen/xen.h b/include/hw/xen/xen.h
index 2b1733b..7efcdaa 100644
--- a/include/hw/xen/xen.h
+++ b/include/hw/xen/xen.h
@@ -21,6 +21,7 @@ enum xen_mode {
 
 extern uint32_t xen_domid;
 extern enum xen_mode xen_mode;
+extern bool xen_domid_restrict;
 
 extern bool xen_allowed;
 
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index fa990a0..0fcbba8 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -151,6 +151,13 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
+static inline int xendevicemodel_restrict(
+xendevicemodel_handle *dmod, domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
@@ -206,6 +213,19 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 return xendevicemodel_modified_memory(xen_dmod, domid, first_pfn, nr);
 }
 
+static inline int xen_restrict(domid_t domid)
+{
+int rc = xendevicemodel_restrict(xen_dmod, domid);
+
+trace_xen_domid_restrict(errno);
+
+if (errno == ENOTTY) {
+return 0;
+}
+
+return rc;
+}
+
 /* Xen 4.2 through 4.6 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
 
diff --git a/qemu-options.hx b/qemu-options.hx
index 99af8ed..2043371 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3354,6 +3354,11 @@ DEF("xen-attach", 0, QEMU_OPTION_xen_attach,
 "-xen-attach attach to existing xen domain\n"
 "xend will use this when starting QEMU\n",
 QEMU_ARCH_ALL)
+DEF("xen-domid-restrict", 0, QEMU_OPTION_xen_domid_restrict,
+"-xen-domid-restrict restrict set of available xen operations\n"
+"to specified domain id. (Does not affect\n"
+"xenpv machine type).\n",
+QEMU_ARCH_ALL)
 STEXI
 @item -xen-domid @var{id}
 @findex -xen-domid
@@ -3366,6 +3371,8 @@ Warning: should not be used when xend is in use (XEN 
only).
 @findex -xen-attach
 Attach to existing xen domain.
 xend will use this when starting QEMU (XEN only).
+@findex -xen-domid-restrict
+Restrict set of available xen operations to specified domain id (XEN only).
 ETEXI
 
 DEF("no-reboot", 0, QEMU_OPTION_no_reboot, \
diff --git a/vl.c b/vl.c
index 0b4ed52..f46e070 100644
--- a/vl.c
+++ b/vl.c
@@ -205,6 +205,7 @@ static NotifierList machine_init_done_notifiers =
 bool xen_allowed;
 uint32_t xen_domid;
 enum xen_mode xen_mode = XEN_EMULATE;
+bool xen_domid_restrict;
 
 static int has_defaults = 1;
 static int default_serial = 1;
@@ -3933,6 +3934,13 @@ int main(int argc, char **argv, char **envp)
 }
 xen_mode = XEN_ATTACH;
 break;
+case QEMU_OPTION_xen_domid_restrict:
+if (!(xen_available())) {
+error_report("Option not supported for this target");
+exit(1);
+}
+xen_domid_restrict = true;
+break;
 case QEMU_OPTION_trace:
 g_free(trace_file);
 trace_file = trace_opt_parse(optarg);
diff --git a/xen-hvm.c b/xen-hvm.c
index 4b928cf..335e263 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1226,6 +1226,14 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
  

[Xen-devel] [PATCH 06/21] xen: use 5 digit xen versions

[Stefano Stabellini]

From: Juergen Gross 

Today qemu is using e.g. the value 480 for Xen version 4.8.0. As some
Xen version tests are using ">" relations this scheme will lead to
problems when Xen version 4.10.0 is being reached.

Instead of the 3 digit schem use a 5 digit scheme (e.g. 40800 for
version 4.8.0).

Signed-off-by: Juergen Gross 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
---
 configure   | 16 
 hw/block/xen_disk.c |  2 +-
 include/hw/xen/xen_common.h | 22 +++---
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/configure b/configure
index e333547..271bea8 100755
--- a/configure
+++ b/configure
@@ -2014,7 +2014,7 @@ EOF
   compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
 then
 xen_stable_libs="-lxendevicemodel $xen_stable_libs"
-xen_ctrl_version=490
+xen_ctrl_version=40900
 xen=yes
   elif
   cat > $TMPC < $TMPC < $TMPC <= 480
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40800
 
 static void ioreq_free_copy_buffers(struct ioreq *ioreq)
 {
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index b1f5f53..fa990a0 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -26,7 +26,7 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 490
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
 
 typedef xc_interface xendevicemodel_handle;
 
@@ -36,7 +36,7 @@ static inline xendevicemodel_handle *xendevicemodel_open(
 return xen_xc;
 }
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40500
 
 static inline int xendevicemodel_create_ioreq_server(
 xendevicemodel_handle *dmod, domid_t domid, int handle_bufioreq,
@@ -99,7 +99,7 @@ static inline int xendevicemodel_set_ioreq_server_state(
 return xc_hvm_set_ioreq_server_state(dmod, domid, id, enabled);
 }
 
-#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 450 */
+#endif /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40500 */
 
 static inline int xendevicemodel_set_pci_intx_level(
 xendevicemodel_handle *dmod, domid_t domid, uint16_t segment,
@@ -151,7 +151,7 @@ static inline int xendevicemodel_set_mem_type(
 return xc_hvm_set_mem_type(dmod, domid, mem_type, first_pfn, nr);
 }
 
-#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 490 */
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
 #include 
@@ -207,7 +207,7 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 }
 
 /* Xen 4.2 through 4.6 */
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 471
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
 
 typedef xc_interface xenforeignmemory_handle;
 typedef xc_evtchn xenevtchn_handle;
@@ -248,7 +248,7 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
-#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 471 */
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40701 */
 
 #include 
 #include 
@@ -284,7 +284,7 @@ static inline int xen_get_vmport_regs_pfn(xc_interface *xc, 
domid_t dom,
 #endif
 
 /* Xen before 4.6 */
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 460
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40600
 
 #ifndef HVM_IOREQSRV_BUFIOREQ_ATOMIC
 #define HVM_IOREQSRV_BUFIOREQ_ATOMIC 2
@@ -330,7 +330,7 @@ static inline int xen_get_default_ioreq_server_info(domid_t 
dom,
 }
 
 /* Xen before 4.5 */
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40500
 
 #ifndef HVM_PARAM_BUFIOREQ_EVTCHN
 #define HVM_PARAM_BUFIOREQ_EVTCHN 26
@@ -569,7 +569,7 @@ static inline int xen_set_ioreq_server_state(domid_t dom,
 
 #endif
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 460
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40600
 static inline int xen_xc_domain_add_to_physmap(xc_interface *xch, uint32_t 
domid,
unsigned int space,
unsigned long idx,
@@ -592,7 +592,7 @@ static inline int xen_xc_domain_add_to_physmap(xc_interface 
*xch, uint32_t domid
 #endif
 
 #ifdef CONFIG_XEN_PV_DOMAIN_BUILD
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40700
 static inline int xen_domain_create(xc_interface *xc, uint32_t ssidref,
 xen_domain_handle_t handle, uint32_t flags,
 uint32_t *pdomid)
@@ -611,7 +611,7 @@ static inline int xen_domain_create(xc_interface *xc, 
uint32_t ssidref,
 
 /* Xen before 4.8 */
 
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 480
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40800
 
 
 typedef void *xengnttab_grant_copy_segment_t;
-- 
1.9.1


___
Xen-devel mailing list
Xen-devel@lists.xen.org

[Xen-devel] [PATCH 01/21] xen: make use of xen_xc implicit in xen_common.h inlines

[Stefano Stabellini]

From: Paul Durrant 

Doing this will make the transition to using the new libxendevicemodel
interface less intrusive on the callers of these functions, since using
the new library will require a change of handle.

NOTE: The patch also moves the 'externs' for xen_xc and xen_fmem from
  xen_backend.h to xen_common.h, and the declarations from
  xen_backend.c to xen-common.c, which is where they belong.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony Perard 
Reviewed-by: Stefano Stabellini 
---
 hw/xen/xen_backend.c |  2 -
 include/hw/xen/xen_backend.h |  2 -
 include/hw/xen/xen_common.h  | 90 +++-
 xen-common.c |  3 ++
 xen-hvm.c| 20 +-
 5 files changed, 60 insertions(+), 57 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 6c21c37..d34c49e 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -43,8 +43,6 @@ BusState *xen_sysbus;
 /* - */
 
 /* public */
-xc_interface *xen_xc = NULL;
-xenforeignmemory_handle *xen_fmem = NULL;
 struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
 
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index 4f4799a..30811a1 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -14,8 +14,6 @@
 OBJECT_CHECK(XenDevice, (obj), TYPE_XENBACKEND)
 
 /* variables */
-extern xc_interface *xen_xc;
-extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
 extern DeviceState *xen_sysdev;
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index dce76ee..1e08b98 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -20,6 +20,8 @@
 #include "qemu/queue.h"
 #include "hw/xen/trace.h"
 
+extern xc_interface *xen_xc;
+
 /*
  * We don't support Xen prior to 4.2.0.
  */
@@ -73,6 +75,8 @@ static inline void *xenforeignmemory_map(xc_interface *h, 
uint32_t dom,
 
 #endif
 
+extern xenforeignmemory_handle *xen_fmem;
+
 void destroy_hvm_domain(bool reboot);
 
 /* shutdown/destroy current domain because of an error */
@@ -107,8 +111,7 @@ static inline int xen_get_vmport_regs_pfn(xc_interface *xc, 
domid_t dom,
 
 #endif
 
-static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
-domid_t dom,
+static inline int xen_get_default_ioreq_server_info(domid_t dom,
 xen_pfn_t *ioreq_pfn,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t
@@ -117,7 +120,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 unsigned long param;
 int rc;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_IOREQ_PFN, );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
 return -1;
@@ -125,7 +128,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 *ioreq_pfn = param;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
 return -1;
@@ -133,7 +136,7 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 *bufioreq_pfn = param;
 
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+rc = xc_get_hvm_param(xen_xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
   );
 if (rc < 0) {
 fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
@@ -156,63 +159,64 @@ static inline int 
xen_get_default_ioreq_server_info(xc_interface *xc,
 
 typedef uint16_t ioservid_t;
 
-static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
+static inline void xen_map_memory_section(domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
 {
 }
 
-static inline void xen_unmap_memory_section(xc_interface *xc, domid_t dom,
+static inline void xen_unmap_memory_section(domid_t dom,
 ioservid_t ioservid,
 MemoryRegionSection *section)
 {
 }
 
-static inline void xen_map_io_section(xc_interface *xc, domid_t dom,
+static inline void xen_map_io_section(domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
 {
 }
 
-static inline void xen_unmap_io_section(xc_interface *xc, domid_t dom,
+static inline void xen_unmap_io_section(domid_t 

[Xen-devel] [PATCH 08/21] xen: additionally restrict xenforeignmemory operations

[Stefano Stabellini]

From: Paul Durrant 

Commit f0f272baf3a7 "xen: use libxendevice model to restrict operations"
added a command-line option (-xen-domid-restrict) to limit operations
using the libxendevicemodel API to a specified domid. The commit also
noted that the restriction would be extended to cover operations issued
via other xen libraries by subsequent patches.

My recent Xen patch [1] added a call to the xenforeignmemory API to allow
it to be restricted. This patch now makes use of that new call when the
-xen-domid-restrict option is passed.

[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5823d6eb

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 134 ++--
 1 file changed, 78 insertions(+), 56 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 0fcbba8..e00ddd7 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -26,6 +26,58 @@ extern xc_interface *xen_xc;
  * We don't support Xen prior to 4.2.0.
  */
 
+/* Xen 4.2 through 4.6 */
+#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
+
+typedef xc_interface xenforeignmemory_handle;
+typedef xc_evtchn xenevtchn_handle;
+typedef xc_gnttab xengnttab_handle;
+
+#define xenevtchn_open(l, f) xc_evtchn_open(l, f);
+#define xenevtchn_close(h) xc_evtchn_close(h)
+#define xenevtchn_fd(h) xc_evtchn_fd(h)
+#define xenevtchn_pending(h) xc_evtchn_pending(h)
+#define xenevtchn_notify(h, p) xc_evtchn_notify(h, p)
+#define xenevtchn_bind_interdomain(h, d, p) xc_evtchn_bind_interdomain(h, d, p)
+#define xenevtchn_unmask(h, p) xc_evtchn_unmask(h, p)
+#define xenevtchn_unbind(h, p) xc_evtchn_unbind(h, p)
+
+#define xengnttab_open(l, f) xc_gnttab_open(l, f)
+#define xengnttab_close(h) xc_gnttab_close(h)
+#define xengnttab_set_max_grants(h, n) xc_gnttab_set_max_grants(h, n)
+#define xengnttab_map_grant_ref(h, d, r, p) xc_gnttab_map_grant_ref(h, d, r, p)
+#define xengnttab_unmap(h, a, n) xc_gnttab_munmap(h, a, n)
+#define xengnttab_map_grant_refs(h, c, d, r, p) \
+xc_gnttab_map_grant_refs(h, c, d, r, p)
+#define xengnttab_map_domain_grant_refs(h, c, d, r, p) \
+xc_gnttab_map_domain_grant_refs(h, c, d, r, p)
+
+#define xenforeignmemory_open(l, f) xen_xc
+#define xenforeignmemory_close(h)
+
+static inline void *xenforeignmemory_map(xc_interface *h, uint32_t dom,
+ int prot, size_t pages,
+ const xen_pfn_t arr[/*pages*/],
+ int err[/*pages*/])
+{
+if (err)
+return xc_map_foreign_bulk(h, dom, prot, arr, err, pages);
+else
+return xc_map_foreign_pages(h, dom, prot, arr, pages);
+}
+
+#define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
+
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40701 */
+
+#include 
+#include 
+#include 
+
+#endif
+
+extern xenforeignmemory_handle *xen_fmem;
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40900
 
 typedef xc_interface xendevicemodel_handle;
@@ -158,6 +210,13 @@ static inline int xendevicemodel_restrict(
 return -1;
 }
 
+static inline int xenforeignmemory_restrict(
+xenforeignmemory_handle *fmem, domid_t domid)
+{
+errno = ENOTTY;
+return -1;
+}
+
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 40900 */
 
 #undef XC_WANT_COMPAT_DEVICEMODEL_API
@@ -215,69 +274,32 @@ static inline int xen_modified_memory(domid_t domid, 
uint64_t first_pfn,
 
 static inline int xen_restrict(domid_t domid)
 {
-int rc = xendevicemodel_restrict(xen_dmod, domid);
+int rc;
 
-trace_xen_domid_restrict(errno);
+/* Attempt to restrict devicemodel operations */
+rc = xendevicemodel_restrict(xen_dmod, domid);
+trace_xen_domid_restrict(rc ? errno : 0);
 
-if (errno == ENOTTY) {
-return 0;
+if (rc < 0) {
+/*
+ * If errno is ENOTTY then restriction is not implemented so
+ * there's no point in trying to restrict other types of
+ * operation, but it should not be treated as a failure.
+ */
+if (errno == ENOTTY) {
+return 0;
+}
+
+return rc;
 }
 
-return rc;
-}
-
-/* Xen 4.2 through 4.6 */
-#if CONFIG_XEN_CTRL_INTERFACE_VERSION < 40701
-
-typedef xc_interface xenforeignmemory_handle;
-typedef xc_evtchn xenevtchn_handle;
-typedef xc_gnttab xengnttab_handle;
-
-#define xenevtchn_open(l, f) xc_evtchn_open(l, f);
-#define xenevtchn_close(h) xc_evtchn_close(h)
-#define xenevtchn_fd(h) xc_evtchn_fd(h)
-#define xenevtchn_pending(h) xc_evtchn_pending(h)
-#define xenevtchn_notify(h, p) xc_evtchn_notify(h, p)
-#define xenevtchn_bind_interdomain(h, d, p) xc_evtchn_bind_interdomain(h, d, p)
-#define xenevtchn_unmask(h, p) xc_evtchn_unmask(h, p)
-#define xenevtchn_unbind(h, p) xc_evtchn_unbind(h, p)
-
-#define 

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Juergen Gross]

On 25/04/17 20:24, Borislav Petkov wrote:
> On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote:
>> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
>> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test
>> cpu_caps_cleared to not have disabled this bit.
>>
>> This bug/feature bit is kind of special as it will be used very early
>> when switching threads. Setting the bit and clearing it a little bit
>> later leaves a critical window where things can go wrong. This time
>> window has enlarged a little bit by using setup_clear_cpu_cap() instead
>> of the hypervisor's set_cpu_features callback. It seems this larger
>> window now makes it rather easy to hit the problem.
>>
>> The proper solution is to never set the bit in case of Xen.
>>
>> Signed-off-by: Juergen Gross 
>> ---
>>  arch/x86/kernel/cpu/amd.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index c36140d788fe..f659b6f534b7 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -800,7 +800,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>>  set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
>>  
>>  /* AMD CPUs don't reset SS attributes on SYSRET */
>> -set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>> +if (!test_bit(X86_BUG_SYSRET_SS_ATTRS,
>> +  (unsigned long *)cpu_caps_cleared))
>> +set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>>  }
> 
> Hold on, AFAICT we have this order:
> 
> c_init() -> init_amd() sets X86_BUG_SYSRET_SS_ATTRS

And what happens when there is a scheduling event right here?
__switch_to() will see X86_BUG_SYSRET_SS_ATTRS set and take a wrong
path.

> init_hypervisor->x86_hyper->set_cpu_features-> clear_cpu_bug(c, 
> X86_BUG_SYSRET_SS_ATTRS);

And now (with setup_clear_cpu_cap()) the bit is cleared a little bit
later. And all should be good. But it isn't.

> 
> and all is good.
> 
> And I remember seeing a patchset doing some xen cpuid cleanup so I'm
> assuming you're doing setup_clear_cpu_cap() now? And now we have to wag
> the dog?

No, now the time window with X86_BUG_SYSRET_SS_ATTRS set is so long we
actually see the problem happening.


Juergen

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

Re: [Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

[Ian Jackson]

Anthony PERARD writes ("Re: [OSSTEST PATCH] ts-openstack-deploy: Set http 
proxy"):
> The patch itself looks good, but I think http_proxy_envsettings only set
> http_proxy, twice, but does not set https_proxy.

Indeed.  See my patch "proxy config: Actually set https_proxy too"
posted today, when I tripped over this too.

> For this patch:
> Reviewed-by: Anthony PERARD 

Thanks.  I'm running more tests with the https mitm cert env setting
you suggested.

Ian.

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

Re: [Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Borislav Petkov]

On Tue, Apr 25, 2017 at 08:00:14PM +0200, Juergen Gross wrote:
> When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
> on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test
> cpu_caps_cleared to not have disabled this bit.
> 
> This bug/feature bit is kind of special as it will be used very early
> when switching threads. Setting the bit and clearing it a little bit
> later leaves a critical window where things can go wrong. This time
> window has enlarged a little bit by using setup_clear_cpu_cap() instead
> of the hypervisor's set_cpu_features callback. It seems this larger
> window now makes it rather easy to hit the problem.
> 
> The proper solution is to never set the bit in case of Xen.
> 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/kernel/cpu/amd.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c36140d788fe..f659b6f534b7 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -800,7 +800,9 @@ static void init_amd(struct cpuinfo_x86 *c)
>   set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
>  
>   /* AMD CPUs don't reset SS attributes on SYSRET */
> - set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
> + if (!test_bit(X86_BUG_SYSRET_SS_ATTRS,
> +   (unsigned long *)cpu_caps_cleared))
> + set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
>  }

Hold on, AFAICT we have this order:

c_init() -> init_amd() sets X86_BUG_SYSRET_SS_ATTRS
init_hypervisor->x86_hyper->set_cpu_features-> clear_cpu_bug(c, 
X86_BUG_SYSRET_SS_ATTRS);

and all is good.

And I remember seeing a patchset doing some xen cpuid cleanup so I'm
assuming you're doing setup_clear_cpu_cap() now? And now we have to wag
the dog?

Confused.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

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

[Xen-devel] [seabios test] 107663: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a

version targeted for testing:
 seabios  19fdcca467ad3436d68ef88899b4dcd78154a9c6
baseline version:
 seabios  5fbf246bdb9c1ee3f474d3f343e2a79db060c93c

Last test of basis   106986  2017-03-30 01:56:45 Z   26 days
Testing same since   107663  2017-04-25 17:17:46 Z0 days1 attempts


People who touched revisions under test:
  Julius Werner 

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-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm blocked 
 test-amd64-amd64-qemuu-nested-amdblocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked 
 test-amd64-amd64-xl-qemuu-winxpsp3   blocked 
 test-amd64-i386-xl-qemuu-winxpsp3blocked 



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

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

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

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


Not pushing.


commit 19fdcca467ad3436d68ef88899b4dcd78154a9c6
Author: Julius Werner 
Date:   Wed Apr 19 15:36:09 2017 -0700

coreboot: Adapt to upstream CBMEM console changes

coreboot's CBMEM console format changed with
https://review.coreboot.org/#/c/18301. This patch adapts the SeaBIOS
implementation to 

[Xen-devel] [libvirt test] 107640: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  5efa7f2a4bf2e316ca74b5baad053a18cffd00b9
baseline version:
 libvirt  b2763f189c5b306a685021b4fede9e2cee8528de

Last test of basis   107613  2017-04-23 04:21:10 Z2 days
Testing same since   107640  2017-04-25 04:21:01 Z0 days1 attempts


People who touched revisions under test:
  Erik Skultety 
  Michal Privoznik 
  Roman Bogorodskiy 
  Yi Wang 
  Yuri Chornoivan 

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



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

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

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

Re: [Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

[Anthony PERARD]

On Tue, Apr 25, 2017 at 04:14:32PM +0100, Ian Jackson wrote:
> This allows ./stack.sh to access the global internet.
> 
> CC: Anthony PERARD 
> Signed-off-by: Ian Jackson 
> ---
>  ts-openstack-deploy | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/ts-openstack-deploy b/ts-openstack-deploy
> index a1c974f..d4c041d 100755
> --- a/ts-openstack-deploy
> +++ b/ts-openstack-deploy
> @@ -137,8 +137,11 @@ END
>  }
>  
>  sub deploy() {
> +my $httpproxy = http_proxy_envsettings($ho);
> +
>  target_cmd($ho, <  set -e
> +$httpproxy
>  cd $builddir/devstack
>  ./stack.sh
>  END

The patch itself looks good, but I think http_proxy_envsettings only set
http_proxy, twice, but does not set https_proxy.

For this patch:
Reviewed-by: Anthony PERARD 

-- 
Anthony PERARD

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

[Xen-devel] [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

[Juergen Gross]

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set
on AMD cpus. Xen will disable this via setup_clear_cpu_cap(), so test
cpu_caps_cleared to not have disabled this bit.

This bug/feature bit is kind of special as it will be used very early
when switching threads. Setting the bit and clearing it a little bit
later leaves a critical window where things can go wrong. This time
window has enlarged a little bit by using setup_clear_cpu_cap() instead
of the hypervisor's set_cpu_features callback. It seems this larger
window now makes it rather easy to hit the problem.

The proper solution is to never set the bit in case of Xen.

Signed-off-by: Juergen Gross 
---
 arch/x86/kernel/cpu/amd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index c36140d788fe..f659b6f534b7 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -800,7 +800,9 @@ static void init_amd(struct cpuinfo_x86 *c)
set_cpu_cap(c, X86_FEATURE_3DNOWPREFETCH);
 
/* AMD CPUs don't reset SS attributes on SYSRET */
-   set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
+   if (!test_bit(X86_BUG_SYSRET_SS_ATTRS,
+ (unsigned long *)cpu_caps_cleared))
+   set_cpu_bug(c, X86_BUG_SYSRET_SS_ATTRS);
 }
 
 #ifdef CONFIG_X86_32
-- 
2.12.0


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

Re: [Xen-devel] [PATCH 01/10] xen/arm: vpl011: Add pl011 uart emulation in Xen

[Stefano Stabellini]

On Tue, 25 Apr 2017, Bhupinder Thakur wrote:
> On 20 April 2017 at 00:10, Stefano Stabellini  wrote:
> > We don't have a formal protocol spec for PV console, but if we had, it
> > would say that the frontend (Xen in this case) should send notifications
> > every time there is new data to write. Thus, once per character in this
> > case.
> >
> > I would start with a dumb implementation like that, simply notify the
> > other end every time. Then, in a separate patch, we can consider
> > introducing optimizations, which need to be well explained.
> >
> Ok. I will add this optimisation as a separate patch later.
> 
> >
> > Regarding the optimization you introduced in this patch, delaying write
> > notifications until we receive a notification from xenconsoled, how many
> > notifications from xen to xenconsoled does it actually save? xenconsoled
> > is going to send a notification for every read: we might end up sending
> > the same number of notifications, only delayed.
> >
> >
> In the PV console design, the events from the guest are sent to
> xenconsole for every chunk of data. Since in the pl011 emulation, the
> data comes in bytes only, it would generate lot of events to
> xenconsole. To reduce the flurry of events, this optimisation was
> added.
> 
> Xenconsole sends an event in the following conditions:
> 
> 1. There is data available for Xen to process
> 2. It has finished processing the data and Xen can send more data
> 
> In the 2nd case, xenconsole will keep reading the data from the ring
> buffer until it goes empty. At that point, it would send an event to
> Xen. Between sending of this event and processing of this event by
> Xen, there could be more data added for the xenconsole to process.
> While handling an event, the Xen will check for that condition and if
> there is data to be processed by xenconsole, it would send an event.
> 
> Also sending delayed events helps with the rate limit check in
> xenconsole. If there are too many events, they maybe masked by
> xenconsole. I could test whether this rate limit check is really
> getting hit with and without this optimisation.

I understand the idea behind, my question is whether this approach was
actually verified by any scientific measurements. Did you run a test
to count how many notifications were skipped thanks to this
optimization? If so, what was the scenario? How many notifications were
saved? If you didn't run a test, I suggest you do :-)


> >>
> >> Since this code is under LOCK, the IN and OUT ring buffers will not be
> >> updated by the guest. Specifically, the following transitions are
> >> ruled out:
> >>
> >> IN ring buffer
> >> non-empty > empty (as the reader is blocked due to lock)
> >>
> >> OUT ring buffer
> >> not-full > full (as writer is blocked due to lock).
> >>
> >> So the code inside the IF block remains valid even if the buffer state 
> >> changes.
> >> For the IN ring buffer it can go from non-empty to full. Similarly for
> >> OUT ring buffer it can go from FULL to empty.
> >>
> >> Also checking the latest buffer index (instead of checking buffer
> >> index read as local variables) allows to update the pl011 state at the
> >> earliest.
> >
> > I understand that the IN state shouldn't change. However, like you say,
> > the OUT state can change between the VPL011_OUT_RING_FULL and the
> > VPL011_OUT_RING_EMPTY checks.
> >
> > It is a bad idea to try to write lockless code against a potentially
> > changing state. It is already hard enough without adding that
> > complexity; the other end can find ways to cause problems. Please take
> > a snapshot of the out indexes and use the local variables, rather than
> > "intf", to do the checks.
> >
> I will use local variables to do these checks.
> 
> 
> Regards,
> Bhupinder
> 

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

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

[Mohit Gambhir]

On 04/25/2017 11:24 AM, Andrew Cooper wrote:

On 24/04/17 18:54, Mohit Gambhir wrote:

This patch adds Intel PMU MSR addresses as macros for VPMU testing

Signed-off-by: Mohit Gambhir 
---
  arch/x86/include/arch/msr-index.h | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/arch/x86/include/arch/msr-index.h 
b/arch/x86/include/arch/msr-index.h
index 2e90079..3a79025 100644
--- a/arch/x86/include/arch/msr-index.h
+++ b/arch/x86/include/arch/msr-index.h
@@ -38,6 +38,17 @@
  #define MSR_GS_BASE 0xc101
  #define MSR_SHADOW_GS_BASE  0xc102
  
+#define MSR_IA32_PMC(n) (0x00c1 + (n))

+#define MSR_IA32_PERFEVTSEL(n)  (0x0186 + (n))
+#define MSR_IA32_DEBUGCTL0x01d9

I have just recently pushed the LBR/TSX test case, which adds DEBUGCTL.

OK

+#define MSR_IA32_FIXED_CTR(n)   (0x0309 + (n))
+#define MSR_IA32_PERF_CAPABILITIES   0x0345
+#define MSR_IA32_FIXED_CTR_CTRL  0x038d
+#define MSR_IA32_PERF_GLOBAL_CTRL0x038f
+#define MSR_IA32_PERF_GLOBAL_STATUS  0x038e
+#define MSR_IA32_PERF_GLOBAL_OVF_CTRL0x0390
+#define MSR_IA32_A_PMC(n)   (0x04c1 + (n))

Please drop the IA32 infixes.  They only add extra clutter.  Please also
keep the entire file sorted by MSR index, which will require splitting
this block into two.

OK

What is the difference between (what will be) MSR_PMC() and MSR_A_PMC() ?
MSR_A_PMCx are alias addresses to MSR_PMCx that are used for full-width 
read/write access while
MSR_PMCx can only be used for 32 bit read/writes. You can take a look at 
Intel SDM Vol 3B section 18.2.5

"Full-Width Write to Performance Counter Registers" for details.


~Andrew

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



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

Re: [Xen-devel] [PATCH 1/2] xen/arm, arm64: fix xen_dma_ops after 815dd18 "Consolidate get_dma_ops..."

[Stefano Stabellini]

On Tue, 25 Apr 2017, Julien Grall wrote:
> Hi Stefano,
> 
> On 24/04/17 20:16, Stefano Stabellini wrote:
> > Given the outstanding regression we need to fix as soon as possible,
> > I'll queue these patches on the xentip tree for 4.12.
> 
> It looks like there is another rc for 4.11. I am wondering whether you could
> try to send a pull request to Linus so it can be fixed in 4.11?

No, especially without input from Russell.

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

Re: [Xen-devel] [Qemu-devel] [PULL 0/21] Please pull xen-20170421-tag for 2.10

[Stefano Stabellini]

On Tue, 25 Apr 2017, Markus Armbruster wrote:
> Stefano Stabellini  writes:
> 
> > On Mon, 24 Apr 2017, Peter Maydell wrote:
> >> On 24 April 2017 at 22:25, Stefano Stabellini  
> >> wrote:
> >> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> >> > new file mode 100644
> >> > index 000..18f0ec0
> >> > --- /dev/null
> >> > +++ b/hw/9pfs/xen-9pfs.h
> >> > @@ -0,0 +1,14 @@
> >> > +/*
> >> > + * Xen 9p backend
> >> > + *
> >> > + * Copyright Aporeto 2017
> >> > + *
> >> > + * Authors:
> >> > + *  Stefano Stabellini 
> >> > + *
> >> > + */
> >> 
> >> Trivial file, but I prefer it if we have a brief license
> >> statement in every file, just to be clear (it might
> >> accumulate more code later).
> >
> > Sure
> >
> >> > +
> >> > +#include 
> >> > +#include "hw/xen/io/ring.h"
> >> > +
> >> > +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
> >> 
> >> Is it worth a comment to dissuade people from thinking they can
> >> inline the file back into xen-9p-backend.c ?
> >
> > Thanks for the quick review! Here you go:
> >
> >
> > diff --git a/hw/9pfs/xen-9p-backend.c b/hw/9pfs/xen-9p-backend.c
> > index 7e962aa..9c7f41a 100644
> > --- a/hw/9pfs/xen-9p-backend.c
> > +++ b/hw/9pfs/xen-9p-backend.c
> > @@ -13,12 +13,9 @@
> >  #include "hw/hw.h"
> >  #include "hw/9pfs/9p.h"
> >  #include "hw/xen/xen_backend.h"
> > -#include "hw/xen/io/ring.h"
> > +#include "hw/9pfs/xen-9pfs.h"
> >  #include "qemu/config-file.h"
> >  #include "fsdev/qemu-fsdev.h"
> > -#include 
> > -
> > -DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
> >  
> >  #define VERSIONS "1"
> >  #define MAX_RINGS 8
> > diff --git a/hw/9pfs/xen-9pfs.h b/hw/9pfs/xen-9pfs.h
> > new file mode 100644
> > index 000..6e33d77
> > --- /dev/null
> > +++ b/hw/9pfs/xen-9pfs.h
> > @@ -0,0 +1,21 @@
> > +/*
> > + * Xen 9p backend
> > + *
> > + * Copyright Aporeto 2017
> > + *
> > + * Authors:
> > + *  Stefano Stabellini 
> > + *
> > + * This work is licensed under the terms of the GNU GPL version 2.
> 
> Any particular reason for "version 2" instead of "version 2 or later"?

Habit: both Linux and Xen are v2 only. I didn't realize that QEMU is "or
later". Also, personally I don't like the "or later" clause for a number
of reasons that is best not to discuss in this thread :-)

But I'll go with whatever is easier for the project. I'll add "or later"
and merge this change into patch #12.

 
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +#include 
> > +#include "hw/xen/io/ring.h"
> > +
> > +/*
> > + * Do not merge into xen-9p-backend.c: clang doesn't allow unused static
> > + * inline functions in c files.
> > + */
> > +DEFINE_XEN_FLEX_RING_AND_INTF(xen_9pfs);
> 

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

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

[Andrew Cooper]

On 24/04/17 18:54, Mohit Gambhir wrote:
> This patch adds Intel PMU MSR addresses as macros for VPMU testing
>
> Signed-off-by: Mohit Gambhir 
> ---
>  arch/x86/include/arch/msr-index.h | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/include/arch/msr-index.h 
> b/arch/x86/include/arch/msr-index.h
> index 2e90079..3a79025 100644
> --- a/arch/x86/include/arch/msr-index.h
> +++ b/arch/x86/include/arch/msr-index.h
> @@ -38,6 +38,17 @@
>  #define MSR_GS_BASE 0xc101
>  #define MSR_SHADOW_GS_BASE  0xc102
>  
> +#define MSR_IA32_PMC(n) (0x00c1 + (n))
> +#define MSR_IA32_PERFEVTSEL(n)  (0x0186 + (n))
> +#define MSR_IA32_DEBUGCTL0x01d9

I have just recently pushed the LBR/TSX test case, which adds DEBUGCTL.

> +#define MSR_IA32_FIXED_CTR(n)   (0x0309 + (n))
> +#define MSR_IA32_PERF_CAPABILITIES   0x0345
> +#define MSR_IA32_FIXED_CTR_CTRL  0x038d
> +#define MSR_IA32_PERF_GLOBAL_CTRL0x038f
> +#define MSR_IA32_PERF_GLOBAL_STATUS  0x038e
> +#define MSR_IA32_PERF_GLOBAL_OVF_CTRL0x0390
> +#define MSR_IA32_A_PMC(n)   (0x04c1 + (n))

Please drop the IA32 infixes.  They only add extra clutter.  Please also
keep the entire file sorted by MSR index, which will require splitting
this block into two.

What is the difference between (what will be) MSR_PMC() and MSR_A_PMC() ?

~Andrew

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

[Xen-devel] [distros-debian-snapshot test] 71228: tolerable trouble: blocked/broken/fail/pass

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail blocked 
in 71200
 test-amd64-i386-i386-daily-netboot-pvgrub 10 guest-start   fail like 71200
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 guest-start fail like 71200
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 71200
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71200
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 71200
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71200

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass

baseline version:
 flight   71200

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   pass
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   pass
 test-amd64-amd64-amd64-current-netinst-pygrubpass
 test-amd64-i386-amd64-current-netinst-pygrub pass
 test-amd64-amd64-i386-current-netinst-pygrub pass
 test-amd64-i386-i386-current-netinst-pygrub  pass
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

[Julien Grall]

On 25/04/17 16:00, Andrew Cooper wrote:

On 25/04/17 10:04, Jan Beulich wrote:

Stub invocations need to have the space the stub occupies as an input,
to prevent the compiler from re-ordering (or omitting) writes to it.

Signed-off-by: Jan Beulich 


Reviewed-by: Andrew Cooper 


Release-acked-by: Julien Grall 





--
Julien Grall

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

Re: [Xen-devel] [PATCH] x86emul: correct stub invocation constraints

[Andrew Cooper]

On 25/04/17 10:04, Jan Beulich wrote:
> Stub invocations need to have the space the stub occupies as an input,
> to prevent the compiler from re-ordering (or omitting) writes to it.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86/32on64: properly honor add-to-physmap-batch's size

[Andrew Cooper]

On 25/04/17 10:03, Jan Beulich wrote:
> Commit 407a3c00ff ("compat/memory: fix build with old gcc") "fixed" a
> build issue by switching to the use of uninitialized data. Due to
> - the bounding of the uninitialized data item
> - the accessed area being outside of Xen space
> - arguments being properly verified by the native hypercall function
> this is not a security issue.
>
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

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

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

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
> new file mode 100644
> index 00..dd03cffd0b
> --- /dev/null
> +++ b/xen/arch/x86/hvm/domain.c
> @@ -0,0 +1,326 @@
> +/*
> + * HVM domain specific functions.
> + *
> + * Copyright (C) 2017 Citrix Systems R
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms and conditions of the GNU General Public
> + * License, version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public
> + * License along with this program; If not, see 
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +static inline int check_segment(struct segment_register *reg,

The inline can be dropped.  This isn't a header file.

Otherwise, Reviewed-by: Andrew Cooper 

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

[Xen-devel] [linux-4.9 test] 107639: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-xsm   19 guest-start/debian.repeat  fail pass in 107633
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
107633

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 107358
 test-amd64-amd64-xl-rtds  9 debian-install   fail REGR. vs. 107358

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-xsm   6 xen-boot fail  like 107358
 test-armhf-armhf-xl-rtds  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-xsm  6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt-raw  6 xen-boot fail  like 107358
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail like 107358
 test-armhf-armhf-xl-vhd   6 xen-boot fail  like 107358
 test-armhf-armhf-libvirt  6 xen-boot fail  like 107358
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 107358
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-rtds 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-rtds 13 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 12 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-arm64-arm64-xl-xsm  12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-arm64-arm64-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linux2f5e58ec793f56f9ac1c6736b4638a4b81d6f099
baseline version:
 linux37feaf8095d352014555b82adb4a04609ca17d3f

Last test of basis   107358  2017-04-10 19:42:52 Z   14 days
Failing since107396  2017-04-12 11:15:19 Z   13 days   24 attempts
Testing same since   107582  2017-04-21 10:48:51 Z4 days7 attempts


People who touched revisions under test:
  Adrian Hunter 
  Al Viro 
  Alan Stern 
  Alberto Aguirre 
  Alex Deucher 
  Alex Williamson 
  Alex Wood 
  Alexander Polakov 
  Alexander Polyakov 
  Alexandre Belloni 
  Amit Pundir 
  Andrew Morton 
  Andrey Konovalov 
  Andrey Smetanin 
  Andy Gross 
  Andy Lutomirski 

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> - fail:
> -pv_domain_destroy(d);
> -
> -return rc;
> -}
> -
> +void paravirt_ctxt_switch_from(struct vcpu *v);
> +void paravirt_ctxt_switch_to(struct vcpu *v);
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
> @@ -1919,7 +1717,8 @@ static void save_segments(struct vcpu *v)
>  
>  #define switch_kernel_stack(v) ((void)0)
>  
> -static void paravirt_ctxt_switch_from(struct vcpu *v)
> +/* Needed by PV guests */
> +void paravirt_ctxt_switch_from(struct vcpu *v)
>  {

Could these be moved up to avoid the forward declarations above?

> diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
> index ea94599438..2737824e81 100644
> --- a/xen/arch/x86/pv/Makefile
> +++ b/xen/arch/x86/pv/Makefile
> @@ -1,2 +1,3 @@
>  obj-y += hypercall.o
>  obj-bin-y += dom0_build.init.o
> +obj-y += domain.o
> diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> new file mode 100644
> index 00..562c3d03f5
> --- /dev/null
> +++ b/xen/arch/x86/pv/domain.c
> @@ -0,0 +1,232 @@
> +/**
> + * arch/x86/pv/domain.c
> + *
> + * PV domain handling
> + */
> +
> +/*
> + *  Copyright (C) 1995  Linus Torvalds
> + *
> + *  Pentium III FXSR, SSE support
> + *  Gareth Hughes , May 2000
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static void noreturn continue_nonidle_domain(struct vcpu *v)
> +{
> +check_wakeup_from_wait();
> +mark_regs_dirty(guest_cpu_user_regs());
> +reset_stack_and_jump(ret_from_intr);
> +}
> +
> +static int setup_compat_l4(struct vcpu *v)
> +{
> +struct page_info *pg;
> +l4_pgentry_t *l4tab;
> +
> +pg = alloc_domheap_page(v->domain, MEMF_no_owner);
> +if ( pg == NULL )
> +return -ENOMEM;
> +
> +/* This page needs to look like a pagetable so that it can be shadowed */

.

> +pg->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;

More spaces please.

> +
> +l4tab = __map_domain_page(pg);
> +clear_page(l4tab);

I know this patch is only code motion, but I really think it would be
safer to defer the type_info update until after we have cleared the page.

> +init_guest_l4_table(l4tab, v->domain, 1);
> +unmap_domain_page(l4tab);
> +
> +v->arch.guest_table = pagetable_from_page(pg);
> +v->arch.guest_table_user = v->arch.guest_table;
> +
> +return 0;
> +}
> +
> +static void release_compat_l4(struct vcpu *v)
> +{
> +if ( !pagetable_is_null(v->arch.guest_table) )
> +free_domheap_page(pagetable_get_page(v->arch.guest_table));
> +v->arch.guest_table = pagetable_null();
> +v->arch.guest_table_user = pagetable_null();
> +}
> +
> +int switch_compat(struct domain *d)
> +{
> +struct vcpu *v;
> +int rc;
> +
> +if ( is_hvm_domain(d) || d->tot_pages != 0 )
> +return -EACCES;
> +if ( is_pv_32bit_domain(d) )
> +return 0;
> +
> +d->arch.has_32bit_shinfo = 1;
> +if ( is_pv_domain(d) )
> +d->arch.is_32bit_pv = 1;

This is_pv_domain() is redundant.  I expect this was fallout from
ripping PVH out.

> +
> +for_each_vcpu( d, v )
> +{
> +rc = setup_compat_arg_xlat(v);
> +if ( !rc )
> +rc = setup_compat_l4(v);
> +
> +if ( rc )
> +goto undo_and_fail;

This is odd structuring.  Care to rearrange it with two goto's, rather
than inverting the first rc check?

> +}
> +
> +domain_set_alloc_bitsize(d);
> +recalculate_cpuid_policy(d);
> +
> +d->arch.x87_fip_width = 4;
> +
> +return 0;
> +
> + undo_and_fail:
> +d->arch.is_32bit_pv = d->arch.has_32bit_shinfo = 0;
> +for_each_vcpu( d, v )
> +{
> +free_compat_arg_xlat(v);
> +release_compat_l4(v);
> +}
> +
> +return rc;
> +}
> +
> +static int pv_create_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> +{
> +return create_perdomain_mapping(d, GDT_VIRT_START(v),
> +1 << GDT_LDT_VCPU_SHIFT,

This should be 1u, when introduced in patch 1.

> +d->arch.pv_domain.gdt_ldt_l1tab, NULL);
> +}
> +
> +static void pv_destroy_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> +{
> +destroy_perdomain_mapping(d, GDT_VIRT_START(v), 1 << GDT_LDT_VCPU_SHIFT);
> +}
> +
> +void pv_vcpu_destroy(struct vcpu *v)
> +{
> +if ( is_pv_32bit_vcpu(v) )
> +{
> +free_compat_arg_xlat(v);
> +release_compat_l4(v);
> +}
> +
> +pv_destroy_gdt_ldt_l1tab(v->domain, v);
> +xfree(v->arch.pv_vcpu.trap_ctxt);
> +v->arch.pv_vcpu.trap_ctxt = NULL;
> +}
> +
> +int pv_vcpu_initialise(struct vcpu *v)
> +{
> +struct domain *d = v->domain;
> +int rc;
> +
> +ASSERT(!is_idle_domain(d));
> +
> +spin_lock_init(>arch.pv_vcpu.shadow_ldt_lock);
> +
> +rc = pv_create_gdt_ldt_l1tab(d, v);
> +if ( rc )
> +   

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

[Sander Eikelenboom]

>> (XEN) [2017-04-25 10:25:24.891] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x10, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.902] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x18, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.914] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x28, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.925] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x30, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.937] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x48, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.949] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x50, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.961] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x58, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.974] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x60, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.986] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x68, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:24.999] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x88, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.012] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x90, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.025] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x92, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.038] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x98, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.051] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x9a, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.065] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa0, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.078] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa2, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.092] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa3, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.106] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa4, type = 0x5, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.120] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa5, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.135] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xa8, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.149] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xb0, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.164] AMD-Vi: Setup I/O page table: device id = 
>>>> 0xb2, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.179] AMD-Vi: Skipping host bridge :00:18.0
>>>> (XEN) [2017-04-25 10:25:25.194] AMD-Vi: Skipping host bridge :00:18.1
>>>> (XEN) [2017-04-25 10:25:25.209] AMD-Vi: Skipping host bridge :00:18.2
>>>> (XEN) [2017-04-25 10:25:25.223] AMD-Vi: Skipping host bridge :00:18.3
>>>> (XEN) [2017-04-25 10:25:25.238] AMD-Vi: Skipping host bridge :00:18.4
>>>> (XEN) [2017-04-25 10:25:25.253] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x400, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.268] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x500, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2017-04-25 10:25:25.283] AMD-Vi: Setup I/O page table: device id = 
>>>> 0x608, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>>> (XEN) [2

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

[Oleksandr Tyshchenko]

Hi, Wei

On Tue, Apr 25, 2017 at 6:23 PM, Wei Liu  wrote:
> On Wed, Apr 19, 2017 at 07:26:44PM +0100, Julien Grall wrote:
>> Hi Oleksandr,
>>
>> Please CC the appropriate maintainers for all the components you modify.
>>
>> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
>> > From: Oleksandr Tyshchenko 
>> >
>> > This flag is intended to let Xen know that the guest has devices
>> > which will most likely be used for passthrough.
>> > The primary aim of this knowledge is to help the IOMMUs that don't
>> > share page tables with the CPU be ready before P2M code starts
>> > updating IOMMU mapping.
>> > So, if this flag is set the unshared IOMMUs will populate their
>> > page tables at the domain creation time and thereby will be able
>> > to handle IOMMU mapping updates from *the very beginning*.
>> >
>
> If it is not able to do so since the very beginning, what will happen?
IOMMU page faults will occur if passthroughed/protected devices try to
do DMA since
the corresponding memory mapping won't be present in IOMMU page table.
If we don't populate IOMMU page table (with setting need_iommu flag)
during domain creation time we will lose memory mapping (at least
domain RAM).
Unfortunately, we can't restore this memory mapping on ARM unlike x86.
I would like to say that it is true for non-shared IOMMUs only. For
shared IOMMU (SMMU) we don't have such problem.

>
> Let me explain where I'm coming from:
>
> 1. if not populating the iommu page table causes Xen to malfunction
>(crash?), it is a bug. It should be fixed without involvement
>from toolstack.
> 2. if this is an optimasation, can't we not always populate iommu pt
>hence no new flag is needed?
>
> Overall I'm not too convinced a new flag is needed.
We don't want to always populate IOMMU page table since it might be
just wasting CPU and memory resources if no devices are assigned to
domain. That's why we need this hint.

>
> Wei.



-- 
Regards,

Oleksandr Tyshchenko

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  637b0d1d1a02b0563cd1966bee800e9e5617e9fa
baseline version:
 xtf  36d926fe0e9b7db39965f430cdb4c5f1daf4eef3

Last test of basis   107657  2017-04-25 13:14:48 Z0 days
Testing same since   107659  2017-04-25 14:44:52 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

[Jan Beulich]

>>> On 25.04.17 at 17:14,  wrote:
> On 25/04/17 15:54, Vijay Kilari wrote:
>> On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall  wrote:
>>
>> By setting 1, we are enabling acpi_numa by default. If not enabled, the
>> below
>> call has check srat_disabled() before proceeding fails.
>
>
>
> My understanding is on x86 acpi_numa is disabled by default and will be
> enabled if they are able to parse the SRAT. So why are you changing the
> behavior for x86?


 acpi_numa = 0 means it is enabled by default on x86.
>>>
>>>
>>> In acpi_scan_nodes:
>>>
>>> if (acpi_numa <= 0)
>>>   return -1;
>>>
>>> So it does not seem that 0 means enabled.
>>
>> IMO, In x86
>>  -1 means disabled
>>   0 enabled but not numa initialized
>>   1 enabled and numa initialized.
>>
>> I clubbed 0 & 1.
> 
>  From your description 0 and 1 have different meaning, so I don't see 
> how you can merge them that easily without any explanation.
> 
> Anyway, I will leave x86 maintainers give their opinion here.

I'm pretty certain this needs to remain a tristate.

Jan


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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3864 host-build-prep   fail REGR. vs. 71224
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 71224

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-xsm 13 saverestore-support-checkfail   like 71224
 test-armhf-armhf-libvirt 13 saverestore-support-checkfail   like 71224
 test-armhf-armhf-libvirt-raw 12 saverestore-support-checkfail   like 71224
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 71224
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 71224

Tests which did not succeed, but are not blocking:
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-winxpsp3  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 

Re: [Xen-devel] [PATCH for-next v2 09/10] x86/domain: move PV specific code to pv/domain.c

[Wei Liu]

On Tue, Apr 25, 2017 at 03:52:06PM +0100, Andrew Cooper wrote:
> On 25/04/17 14:52, Wei Liu wrote:
> > - fail:
> > -pv_domain_destroy(d);
> > -
> > -return rc;
> > -}
> > -
> > +void paravirt_ctxt_switch_from(struct vcpu *v);
> > +void paravirt_ctxt_switch_to(struct vcpu *v);
> >  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> > struct xen_arch_domainconfig *config)
> >  {
> > @@ -1919,7 +1717,8 @@ static void save_segments(struct vcpu *v)
> >  
> >  #define switch_kernel_stack(v) ((void)0)
> >  
> > -static void paravirt_ctxt_switch_from(struct vcpu *v)
> > +/* Needed by PV guests */
> > +void paravirt_ctxt_switch_from(struct vcpu *v)
> >  {
> 
> Could these be moved up to avoid the forward declarations above?
> 

Yes and frankly this is going to require more brain power to review, but
I'm not the one who reviews this so I don't care. ;p

> > diff --git a/xen/arch/x86/pv/Makefile b/xen/arch/x86/pv/Makefile
> > index ea94599438..2737824e81 100644
> > --- a/xen/arch/x86/pv/Makefile
> > +++ b/xen/arch/x86/pv/Makefile
> > @@ -1,2 +1,3 @@
> >  obj-y += hypercall.o
> >  obj-bin-y += dom0_build.init.o
> > +obj-y += domain.o
> > diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c
> > new file mode 100644
> > index 00..562c3d03f5
> > --- /dev/null
> > +++ b/xen/arch/x86/pv/domain.c
> > @@ -0,0 +1,232 @@
[...]
> > +
> > +static int pv_create_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> > +{
> > +return create_perdomain_mapping(d, GDT_VIRT_START(v),
> > +1 << GDT_LDT_VCPU_SHIFT,
> 
> This should be 1u, when introduced in patch 1.
> 

Will fix.

As for other issues you point out, it is rather easier to review and
test if I write separate patches for all of them. Expect more patches.


> > +
> 
> #ifdef CONFIG_PV
> 
> > +void pv_vcpu_destroy(struct vcpu *v);
> > +int pv_vcpu_initialise(struct vcpu *v);
> > +void pv_domain_destroy(struct domain *d);
> > +int pv_domain_initialise(struct domain *d, unsigned int domcr_flags,
> > + struct xen_arch_domainconfig *config);
> 
> #else
> 
> static inline void pv_vcpu_destroy(struct vcpu *v) {};
> static inline int pv_vcpu_initialise(struct vcpu *v) { return
> -EOPNOTSUPP; };
> static inline void pv_domain_destroy(struct domain *d) {};
> static inline int pv_domain_initialise(struct domain *d, unsigned int
> domcr_flags,
>   struct xen_arch_domainconfig
> *config) { return -EOPNOTSUPP; }
> 
> #endif
> 
> Please can we try to make new code compatible with eventually turning
> off CONFIG_PV and CONFIG_HVM.
> 

My original plan was to do that in next stage. But I'm also ok with
doing it now.

Wei.

> ~Andrew
> 
> > +
> > +#endif /* __X86_PV_DOMAIN_H__ */
> 

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

Re: [Xen-devel] [PATCH for-next v2 08/10] x86/domain: factor out pv_domain_initialise

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> Lump everything PV related in arch_domain_create into
> pv_domain_initialise.
>
> Though domcr_flags and config are not necessary, the new function is
> given those to match hvm counterpart.
>
> Since it cleans up after itself there is no need to clean up in
> arch_domain_create in case of failure. Remove the initialiser of rc in
> arch_domain_create.
>
> No functional change.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [RFC PATCH 9/9] xen: Add use_iommu flag to createdomain domctl

[Wei Liu]

On Wed, Apr 19, 2017 at 07:26:44PM +0100, Julien Grall wrote:
> Hi Oleksandr,
> 
> Please CC the appropriate maintainers for all the components you modify.
> 
> On 15/03/17 20:05, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko 
> > 
> > This flag is intended to let Xen know that the guest has devices
> > which will most likely be used for passthrough.
> > The primary aim of this knowledge is to help the IOMMUs that don't
> > share page tables with the CPU be ready before P2M code starts
> > updating IOMMU mapping.
> > So, if this flag is set the unshared IOMMUs will populate their
> > page tables at the domain creation time and thereby will be able
> > to handle IOMMU mapping updates from *the very beginning*.
> > 

If it is not able to do so since the very beginning, what will happen?

Let me explain where I'm coming from:

1. if not populating the iommu page table causes Xen to malfunction
   (crash?), it is a bug. It should be fixed without involvement
   from toolstack.
2. if this is an optimasation, can't we not always populate iommu pt
   hence no new flag is needed?

Overall I'm not too convinced a new flag is needed.

Wei.

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

[Xen-devel] [OSSTEST PATCH] ts-openstack-deploy: Set http proxy

[Ian Jackson]

This allows ./stack.sh to access the global internet.

CC: Anthony PERARD 
Signed-off-by: Ian Jackson 
---
 ts-openstack-deploy | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-openstack-deploy b/ts-openstack-deploy
index a1c974f..d4c041d 100755
--- a/ts-openstack-deploy
+++ b/ts-openstack-deploy
@@ -137,8 +137,11 @@ END
 }
 
 sub deploy() {
+my $httpproxy = http_proxy_envsettings($ho);
+
 target_cmd($ho, <

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck 11 guest-start fail REGR. vs. 59254
 test-armhf-armhf-xl  11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-libvirt 11 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-arndale  11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254
 test-armhf-armhf-libvirt-xsm 11 guest-start   fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 59254

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-armhf-armhf-libvirt-raw  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-multivcpu 11 guest-start  fail  never pass
 test-arm64-arm64-xl  11 guest-start  fail   never pass
 test-arm64-arm64-xl-xsm  11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-xsm 11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-arm64-arm64-xl-credit2  11 guest-start  fail   never pass
 test-arm64-arm64-xl-rtds 11 guest-start  fail   never pass
 test-arm64-arm64-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 linux8f9cedc76fc7d9bc916127f8fe1287a249891d40
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  656 days
Failing since 59348  2015-07-10 04:24:05 Z  655 days  407 attempts
Testing same since   107638  2017-04-25 01:49:56 Z0 days1 attempts


8176 people touched revisions under test,
not listing them all

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

[Xen-devel] [OSSTEST PATCH 1/3] mg-repro-setup: Cope with flights referencing other builds

[Ian Jackson]

We attempted to do this by trying to adjust build runvars only if they
didn't have a `.'.  But cs-adjust-flight runvar-build-set has special
handling for : it is always qualified with the flight.

So change the match to look for the current flight number.

Signed-off-by: Ian Jackson 
---
 mg-repro-setup | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mg-repro-setup b/mg-repro-setup
index 0b3137a..4f2fe54 100755
--- a/mg-repro-setup
+++ b/mg-repro-setup
@@ -199,7 +199,7 @@ if $skipcapture; then adjrunvar skip_testids 
"capture-logs*"; fi
 
 ./cs-adjust-flight $flight \
copy-jobs $example_flight $job  \
-   runvar-build-set . '/buildjob$' '^[^\.]+$' $example_flight  \
+   runvar-build-set . '/buildjob$' "^$flight\\." $example_flight \
"${adjusts[@]}"
 
 progress "executing ..."
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 2/3] proxy config: Actually set https_proxy too

[Ian Jackson]

05406e5aaffb "proxy config: Set https_proxy too" was ineffective
because in d22b80bb "proxy config: Factor out http_proxy_envsettings"
the variable name $var was not substituted into the new
supposedly-more-general shell rune, which consequently lacked the
appropriate generality.

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

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d482e1d..19bdd23 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -1911,7 +1911,7 @@ sub http_proxy_envsettings ($) {
 return unless $proxy;
 my @script;
 foreach my $var (qw(http_proxy https_proxy)) {
-push @script, "http_proxy=$proxy", "export http_proxy";
+push @script, "$var=$proxy", "export $var";
 }
 return (join '; ', @script).';';
 }
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 3/3] mg-hosts: -l: print subtask info too

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 mg-allocate | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/mg-allocate b/mg-allocate
index 2dfbdb1..4f02ce5 100755
--- a/mg-allocate
+++ b/mg-allocate
@@ -612,13 +612,19 @@ END
  qw(restype resname shareix));
my $restype = $c->{restype};
my $resname = $c->{resname};
+my $prshare;
if ($restype eq 'share-host') {
-   print "S/$resname";
+   $prshare = "S/$resname";
} elsif ($restype eq 'host') {
-   print "$resname";
+   $prshare = "$resname";
} elsif ($restype eq 'share-flight') {
-   print "F/$resname";
+   $prshare = "F/$resname";
}
+if ($c->{subtask}) {
+printf "%-20s  %s", $prshare, $c->{subtask};
+} else {
+print $prshare;
+}
print "\n";
}
 db_retry_abort();
-- 
2.1.4


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

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

[Julien Grall]

On 25/04/17 15:54, Vijay Kilari wrote:

On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall  wrote:


By setting 1, we are enabling acpi_numa by default. If not enabled, the
below
call has check srat_disabled() before proceeding fails.




My understanding is on x86 acpi_numa is disabled by default and will be
enabled if they are able to parse the SRAT. So why are you changing the
behavior for x86?



acpi_numa = 0 means it is enabled by default on x86.



In acpi_scan_nodes:

if (acpi_numa <= 0)
  return -1;

So it does not seem that 0 means enabled.


IMO, In x86
 -1 means disabled
  0 enabled but not numa initialized
  1 enabled and numa initialized.

I clubbed 0 & 1.


From your description 0 and 1 have different meaning, so I don't see 
how you can merge them that easily without any explanation.


Anyway, I will leave x86 maintainers give their opinion here.



I was referring to below code in x86 where in acpi_numa = 0 means
srat_disabled() returns false. Which means acpi_numa is enabled implicitly.

int srat_disabled(void)
{
  return numa_off || acpi_numa < 0;
}

When I changed acpi_numa to bool, it is initialized to 1 and changed
below code.

bool srat_disabled(void)
{
return numa_off || acpi_numa == 0;
}

Also this srat_disabed() is used in acpi_numa_memory_affinity_init which is
called from acpi_numa_init() before calling acpi_scan_nodes().




--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 1/2][XTF] xtf/vpmu: Add Intel PMU MSR addresses

[Mohit Gambhir]

On 04/25/2017 04:36 AM, Jan Beulich wrote:

On 24.04.17 at 19:54,  wrote:

--- a/arch/x86/include/arch/msr-index.h
+++ b/arch/x86/include/arch/msr-index.h
@@ -38,6 +38,17 @@
  #define MSR_GS_BASE 0xc101
  #define MSR_SHADOW_GS_BASE  0xc102
  
+#define MSR_IA32_PMC(n) (0x00c1 + (n))

+#define MSR_IA32_PERFEVTSEL(n)  (0x0186 + (n))
+#define MSR_IA32_DEBUGCTL0x01d9

This still sits in the middle of PMU ones, despite not being purely
PMU related.

Jan
Its actually already defined in that file as MSR_DEBUGCTL so I am just 
going to remove this redefinition.


Mohit

+#define MSR_IA32_FIXED_CTR(n)   (0x0309 + (n))
+#define MSR_IA32_PERF_CAPABILITIES   0x0345
+#define MSR_IA32_FIXED_CTR_CTRL  0x038d
+#define MSR_IA32_PERF_GLOBAL_CTRL0x038f
+#define MSR_IA32_PERF_GLOBAL_STATUS  0x038e
+#define MSR_IA32_PERF_GLOBAL_OVF_CTRL0x0390
+#define MSR_IA32_A_PMC(n)   (0x04c1 + (n))





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

Re: [Xen-devel] [RFC PATCH v2 04/25] x86: NUMA: Add accessors for acpi_numa, numa_off and numa_fake variables

[Vijay Kilari]

On Tue, Apr 25, 2017 at 5:58 PM, Julien Grall  wrote:
>
>
> On 25/04/17 13:20, Vijay Kilari wrote:
>>
>> On Tue, Apr 25, 2017 at 5:34 PM, Julien Grall 
>> wrote:
>>>
>>> Hello Vijay,
>>>
>>> On 25/04/17 07:54, Vijay Kilari wrote:


 On Thu, Apr 20, 2017 at 9:29 PM, Julien Grall 
 wrote:
>
>
> Hi Vijay,
>
> On 28/03/17 16:53, vijay.kil...@gmail.com wrote:
>>
>>
>>
>> From: Vijaya Kumar K 
>>
>> Add accessor functions for acpi_numa and numa_off static
>> variables. Init value of acpi_numa is set 1 instead of 0.
>
>
>
>
> Please explain why you change the acpi_numa value from 0 to 1.



 previously acpi_numa was s8 and are using 0 and -1 values. I have made
 it bool and set
 the initial value to 1.
>>>
>>>
>>>
>>> Are you sure? With a quick grep I spot it sounds like acpi_numa can have
>>> the
>>> value 0, -1, 1.
>>>
>>
>> Hmm.. But I don't see use of having 0, -1 and 1. But I don't see any use
>> of
>> having 3 values to say enable or disable.
>
>
> Then explain why in the commit message and don't let people discover. If you
> have not done it, I would recommend to read:
>
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
>
>>

 By setting 1, we are enabling acpi_numa by default. If not enabled, the
 below
 call has check srat_disabled() before proceeding fails.
>>>
>>>
>>>
>>> My understanding is on x86 acpi_numa is disabled by default and will be
>>> enabled if they are able to parse the SRAT. So why are you changing the
>>> behavior for x86?
>>
>>
>> acpi_numa = 0 means it is enabled by default on x86.
>
>
> In acpi_scan_nodes:
>
> if (acpi_numa <= 0)
>   return -1;
>
> So it does not seem that 0 means enabled.

IMO, In x86
 -1 means disabled
  0 enabled but not numa initialized
  1 enabled and numa initialized.

I clubbed 0 & 1.

I was referring to below code in x86 where in acpi_numa = 0 means
srat_disabled() returns false. Which means acpi_numa is enabled implicitly.

int srat_disabled(void)
{
  return numa_off || acpi_numa < 0;
}

When I changed acpi_numa to bool, it is initialized to 1 and changed
below code.

bool srat_disabled(void)
{
return numa_off || acpi_numa == 0;
}

Also this srat_disabed() is used in acpi_numa_memory_affinity_init which is
called from acpi_numa_init() before calling acpi_scan_nodes().

>
>>
>>>

 acpi_numa_memory_affinity_init(const struct acpi_srat_mem_affinity *ma)
 {
 

 if ( srat_disabled() )
 return;

 }

>
> Also, I am not sure to understand the benefits of those helpers. Why do
> you
> need them? Why not using the global variable directly, this will avoid
> to
> call a function just for returning a value...



 These helpers are used by both common code and arch specific code later.
 Hence made these global variables as static and added helpers
>>>
>>>
>>>
>>> The variables were global so they could already be used anywhere.
>>>
>>> Furthermore, those helpers are not even inlined, so everytime you want to
>>> access read acpi_numa you have to do a branch then a memory access.
>>>
>>> So what is the point to do that?
>>
>>
>> I agree with making inline. But I don't think there is any harm in making
>> them
>> static and adding helpers.
>
>
> But why? Why don't you keep the code as it is? You modify code without any
> justification and not for the better.
>
> Cheers,
>
> --
> Julien Grall

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

Re: [Xen-devel] [PATCH for-next v2 06/10] x86/domain: push some code down to hvm_domain_initialise

[Wei Liu]

On Tue, Apr 25, 2017 at 03:15:03PM +0100, Andrew Cooper wrote:
> On 25/04/17 14:52, Wei Liu wrote:
> > We want to have a single entry point to initialise hvm guest.  Now the
> > timing to set hap bit and create per domain mapping is deferred, but
> > that's not a problem.
> 
> This wording is a little odd to read.  How about "To do this, the
> setting of hap_enabled and creation of the per domain mappings is
> deferred, but..." ?
> 

No problem.

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

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

[Wei Liu]

On Tue, Apr 25, 2017 at 03:08:23PM +0100, Andrew Cooper wrote:
> On 25/04/17 14:52, Wei Liu wrote:
> > Move PV specific vcpu initialisation code to said function, but leave
> > the only line needed by idle domain in vcpu_initialise.
> >
> > Use pv_vcpu_destroy in error path to simplify code. It is safe to do so
> > because the destruction function accepts partially initialised vcpu
> > struct.
> >
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/domain.c | 99 
> > ++-
> >  1 file changed, 50 insertions(+), 49 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index cde0917f5b..38fc4f5d8b 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -398,6 +398,50 @@ static void pv_destroy_gdt_ldt_l1tab(struct domain *d, 
> > struct vcpu *v)
> >  destroy_perdomain_mapping(d, GDT_VIRT_START(v), 1 << 
> > GDT_LDT_VCPU_SHIFT);
> >  }
> >  
> > +static void pv_vcpu_destroy(struct vcpu *v);
> 
> If in the previous patch, you create pv_vcpu_destroy() earlier than
> vcpu_initialise(), you wouldn't need this forward declaration here.
> 

Yeah I know. I chose to rearranged them in the patch that moved pv code
instead, because rebasing huge chunk of code is error-prone.

> Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> No functional change.
>
> Signed-off-by: Wei Liu 
> ---
> v2:
> 1. reset fields
> 2. destroy perdomain mapping

You are introducing an additional destroy_perdomain_mapping(), and
freeing of the cpuidmasks into this path.  Functionally it is fine, but
it needs calling out in the commit message as to why it is safe to do.

>
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/domain.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index fd5d47ab3d..952e05366a 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d, 
> uint32_t emflags)
>  return true;
>  }
>  
> +static void pv_domain_destroy(struct domain *d)
> +{
> +destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
> +  GDT_LDT_MBYTES << (20 - PAGE_SHIFT));

Please could we have a newline here...

> +xfree(d->arch.pv_domain.cpuidmasks);
> +d->arch.pv_domain.cpuidmasks = NULL;

And here, just to visually separate the different parts.

~Andrew

> +free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> +d->arch.pv_domain.gdt_ldt_l1tab = NULL;
> +}
> +
>  int arch_domain_create(struct domain *d, unsigned int domcr_flags,
> struct xen_arch_domainconfig *config)
>  {
> @@ -712,10 +722,8 @@ int arch_domain_create(struct domain *d, unsigned int 
> domcr_flags,
>  paging_final_teardown(d);
>  free_perdomain_mappings(d);
>  if ( is_pv_domain(d) )
> -{
> -xfree(d->arch.pv_domain.cpuidmasks);
> -free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> -}
> +pv_domain_destroy(d);
> +
>  return rc;
>  }
>  
> @@ -735,10 +743,7 @@ void arch_domain_destroy(struct domain *d)
>  
>  free_perdomain_mappings(d);
>  if ( is_pv_domain(d) )
> -{
> -free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
> -xfree(d->arch.pv_domain.cpuidmasks);
> -}
> +pv_domain_destroy(d);
>  
>  free_xenheap_page(d->shared_info);
>  cleanup_domain_irq_mapping(d);


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  8829d12ac0f9e3f7b01f276cd966c5a39497da92
baseline version:
 xen  99704f26360ee8d4f85081c6c50ce64f47961f6d

Last test of basis   107631  2017-04-24 14:09:35 Z1 days
Testing same since   107650  2017-04-25 13:02:12 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Julien Grall 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=8829d12ac0f9e3f7b01f276cd966c5a39497da92
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
8829d12ac0f9e3f7b01f276cd966c5a39497da92
+ branch=xen-unstable-smoke
+ revision=8829d12ac0f9e3f7b01f276cd966c5a39497da92
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.8-testing
+ '[' x8829d12ac0f9e3f7b01f276cd966c5a39497da92 = 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
++ : 

Re: [Xen-devel] EFI + tboot + Xen

[Ross Philipson]

On 04/17/2017 06:05 PM, Rich Persaud wrote:
> On Apr 14, 2017, at 16:43, Daniel Kiper  > wrote:
> 
>> On Fri, Apr 14, 2017 at 04:17:54PM +0100, Andrew Cooper wrote:
>>> On 14/04/2017 15:54, Daniel Kiper wrote:
 Hey,

 Has anybody tried to run EFI + tboot + Xen?
 I have a feeling that it does not work because
 tboot shuts down EFI boot services. However,
 even if it works then efibootmgr is unusable
 due to lack of EFI runtime services. Do we care?
 Is it possible to make it work with full blown
 EFI infrastructure available for Xen?
>>>
>>> Judging by
>>> http://hg.code.sf.net/p/tboot/code/file/9352e6391332/tboot/common/boot.S#l83
>>> it will be grub exiting boot services.  tboot needs rather more
>>> multiboot2 knowledge before it could participate in a hand-off to Xen
>>> while keeping boot services active.
>>
>> Sure, it is not a problem. However, I was told that it was (not) done
>> deliberately because we cannot trust EFI due to lack of its measurement.
>> I am not sure it is true or not. I though that somebody played with tboot
>> and Xen and has some knowledge in that area. Anyway, I will investigate
>> this further. However, any knowledge sharing is greatly appreciated.
> 
> On the OpenXT project, Ross Philipson has an early PoC:
> https://github.com/rossphilipson/efi-tboot
> 
> From the README:
> ---
> 
> EFI TBOOT is mostly a proof of concept at this point. It is not currently
> functional. It can be built and installed as an EFI boot loader. It only works
> in conjunction with Xen at the moment. The current development work is being
> done on Fedora 25 x64. The status as of March 14, 2017 is: 
> 
> 
> - EFI TBOOT will boot, but it needs a few key strokes to get going (this is 
> for
> debugging purposes). 
> 
> - EFI TBOOT will relocate itself to EFI runtime memory and setup a shared
> runtime variable with Xen. 
> 
> - EFI related configuration setup is done as well as standard TBOOT pre- 
> launch
> configuration. 
> 
> - Xen is launched and has code to call EFI TBOOT back after EBS. 
> 
> - EFI TBOOT then does the SENTER successfully in the callback. 
> 
> - The post launch entry point is reached but the switch back to long mode is 
> not
> working
> 
> ---
> 
> 
> Rich
> 

So this project is a proof of concept at the moment. Currently the readme is out
of date (I will fix that). The SENTER returns correctly now and rebuilds the
world to get back into long mode. It then calls into the post launch function in
tboot.c and does a bit more before dying because it is incomplete.

Anyway I will work on fixing the readme with more details on what it is all 
about.

-- 
Ross Philipson

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

Re: [Xen-devel] [PATCH for-next v2 06/10] x86/domain: push some code down to hvm_domain_initialise

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> We want to have a single entry point to initialise hvm guest.  Now the
> timing to set hap bit and create per domain mapping is deferred, but
> that's not a problem.

This wording is a little odd to read.  How about "To do this, the
setting of hap_enabled and creation of the per domain mappings is
deferred, but..." ?

>
> No functional change.
>
> Signed-off-by: Wei Liu 

Otherwise, Reviewed-by: Andrew Cooper 

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

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

[Wei Liu]

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

No functional change.

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

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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xtf  36d926fe0e9b7db39965f430cdb4c5f1daf4eef3
baseline version:
 xtf  e399b894f042d3f50d07a8619f7d7e7de410351d

Last test of basis   107372  2017-04-11 18:14:06 Z   13 days
Testing same since   107657  2017-04-25 13:14:48 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   pass
 test-xtf-amd64-amd64-2   pass
 test-xtf-amd64-amd64-3   pass
 test-xtf-amd64-amd64-4   pass
 test-xtf-amd64-amd64-5   pass



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH for-next v2 05/10] x86/domain: factor out pv_vcpu_initialise

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> Move PV specific vcpu initialisation code to said function, but leave
> the only line needed by idle domain in vcpu_initialise.
>
> Use pv_vcpu_destroy in error path to simplify code. It is safe to do so
> because the destruction function accepts partially initialised vcpu
> struct.
>
> Signed-off-by: Wei Liu 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/domain.c | 99 
> ++-
>  1 file changed, 50 insertions(+), 49 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index cde0917f5b..38fc4f5d8b 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -398,6 +398,50 @@ static void pv_destroy_gdt_ldt_l1tab(struct domain *d, 
> struct vcpu *v)
>  destroy_perdomain_mapping(d, GDT_VIRT_START(v), 1 << GDT_LDT_VCPU_SHIFT);
>  }
>  
> +static void pv_vcpu_destroy(struct vcpu *v);

If in the previous patch, you create pv_vcpu_destroy() earlier than
vcpu_initialise(), you wouldn't need this forward declaration here.

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Resend: Linux 4.11-rc7: kernel BUG at drivers/xen/events/events_base.c:1221

[Juergen Gross]

gt;> (XEN) [2017-04-25 10:25:24.999] AMD-Vi: Setup I/O page table: device id = 
>>> 0x88, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.012] AMD-Vi: Setup I/O page table: device id = 
>>> 0x90, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.025] AMD-Vi: Setup I/O page table: device id = 
>>> 0x92, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.038] AMD-Vi: Setup I/O page table: device id = 
>>> 0x98, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.051] AMD-Vi: Setup I/O page table: device id = 
>>> 0x9a, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.065] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa0, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.078] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa2, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.092] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa3, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.106] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa4, type = 0x5, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.120] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa5, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.135] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa8, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.149] AMD-Vi: Setup I/O page table: device id = 
>>> 0xb0, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.164] AMD-Vi: Setup I/O page table: device id = 
>>> 0xb2, type = 0x7, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.179] AMD-Vi: Skipping host bridge :00:18.0
>>> (XEN) [2017-04-25 10:25:25.194] AMD-Vi: Skipping host bridge 0000:00:18.1
>>> (XEN) [2017-04-25 10:25:25.209] AMD-Vi: Skipping host bridge :00:18.2
>>> (XEN) [2017-04-25 10:25:25.223] AMD-Vi: Skipping host bridge :00:18.3
>>> (XEN) [2017-04-25 10:25:25.238] AMD-Vi: Skipping host bridge :00:18.4
>>> (XEN) [2017-04-25 10:25:25.253] AMD-Vi: Setup I/O page table: device id = 
>>> 0x400, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.268] AMD-Vi: Setup I/O page table: device id = 
>>> 0x500, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.283] AMD-Vi: Setup I/O page table: device id = 
>>> 0x608, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.299] AMD-Vi: Setup I/O page table: device id = 
>>> 0x610, type = 0x2, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.315] AMD-Vi: Setup I/O page table: device id = 
>>> 0x700, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.331] AMD-Vi: Setup I/O page table: device id = 
>>> 0x800, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.347] AMD-Vi: Setup I/O page table: device id = 
>>> 0x900, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.363] AMD-Vi: Setup I/O page table: device id = 
>>> 0x901, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.379] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa00, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.396] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa01, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.413] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa02, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.430] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa03, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.447] AMD-Vi: Setup I/O page table: device id = 
>>> 0xa04, type = 0x1, root table = 0x441ddb000, domain = 0, paging mode = 3
>>> (XEN) [2017-04-25 10:25:25.465] AMD-Vi

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf d7dd4f0a0678c458005ea40acba70984c58bcb20
baseline version:
 ovmf d5a67b3da18f815c83593d9329a353ec3a739d66

Last test of basis   107641  2017-04-25 04:53:13 Z0 days
Testing same since   107645  2017-04-25 10:46:12 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH for-next v2 02/10] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

[Wei Liu]

On Tue, Apr 25, 2017 at 02:56:01PM +0100, Andrew Cooper wrote:
> On 25/04/17 14:52, Wei Liu wrote:
> > This patch encapsulates the perdomain creation and destruction into
> > helper functions and use them where appropriate.
> >
> > Since destroy_perdomain_mapping is idempotent, it is safe to call the
> > destruction function multiple times.
> >
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/domain.c | 23 ---
> >  1 file changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 90e2b1f82a..1f76d034a7 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
> > @@ -387,6 +387,18 @@ int switch_compat(struct domain *d)
> >  return rc;
> >  }
> >  
> > +static int pv_create_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> > +{
> > +return create_perdomain_mapping(d, GDT_VIRT_START(v),
> > +1 << GDT_LDT_VCPU_SHIFT,
> > +d->arch.pv_domain.gdt_ldt_l1tab, NULL);
> > +}
> > +
> > +static void pv_destroy_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> > +{
> > +destroy_perdomain_mapping(d, GDT_VIRT_START(v), 1 << 
> > GDT_LDT_VCPU_SHIFT);
> > +}
> 
> What is the point of passing both d and v?  Isn't d always v->domain ?
> 

Yes you're right.

> Otherwise, LGTM.

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

Re: [Xen-devel] [PATCH] x86/32on64: properly honor add-to-physmap-batch's size

[Julien Grall]

Hi,

On 25/04/17 14:54, Wei Liu wrote:

On Tue, Apr 25, 2017 at 03:03:42AM -0600, Jan Beulich wrote:

Commit 407a3c00ff ("compat/memory: fix build with old gcc") "fixed" a
build issue by switching to the use of uninitialized data. Due to
- the bounding of the uninitialized data item
- the accessed area being outside of Xen space
- arguments being properly verified by the native hypercall function
this is not a security issue.

Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Jan Beulich 


Reviewed-by: Wei Liu 


Release-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 for-next v2 04/10] x86/domain: factor out pv_vcpu_destroy

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> The function is made idempotent on purpose.
>
> No functional change.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-next v2 03/10] x86/domain: make release_compact_l4 NULL tolerant

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> Push the check in caller down to that function so that it becomes
> idempotent.
>
> No functional change.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-next v2 02/10] x86/domain: provide pv_{create, destroy}_gdt_ldt_l1tab and use them

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> This patch encapsulates the perdomain creation and destruction into
> helper functions and use them where appropriate.
>
> Since destroy_perdomain_mapping is idempotent, it is safe to call the
> destruction function multiple times.
>
> Signed-off-by: Wei Liu 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/domain.c | 23 ---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 90e2b1f82a..1f76d034a7 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -387,6 +387,18 @@ int switch_compat(struct domain *d)
>  return rc;
>  }
>  
> +static int pv_create_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> +{
> +return create_perdomain_mapping(d, GDT_VIRT_START(v),
> +1 << GDT_LDT_VCPU_SHIFT,
> +d->arch.pv_domain.gdt_ldt_l1tab, NULL);
> +}
> +
> +static void pv_destroy_gdt_ldt_l1tab(struct domain *d, struct vcpu *v)
> +{
> +destroy_perdomain_mapping(d, GDT_VIRT_START(v), 1 << GDT_LDT_VCPU_SHIFT);
> +}

What is the point of passing both d and v?  Isn't d always v->domain ?

Otherwise, LGTM.

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

Re: [Xen-devel] [PATCH] x86/32on64: properly honor add-to-physmap-batch's size

[Wei Liu]

On Tue, Apr 25, 2017 at 03:03:42AM -0600, Jan Beulich wrote:
> Commit 407a3c00ff ("compat/memory: fix build with old gcc") "fixed" a
> build issue by switching to the use of uninitialized data. Due to
> - the bounding of the uninitialized data item
> - the accessed area being outside of Xen space
> - arguments being properly verified by the native hypercall function
> this is not a security issue.
> 
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Jan Beulich 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-next v2 01/10] x86/mm: make free_perdomain_mappings idempotent

[Andrew Cooper]

On 25/04/17 14:52, Wei Liu wrote:
> Signed-off-by: Wei Liu 

Reviewed-by: Andrew Cooper 

> ---
> Cc: Tim Deegan 
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> ---
>  xen/arch/x86/mm.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
> index bd68e56dc7..cdef5c49c4 100644
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -6503,9 +6503,14 @@ void destroy_perdomain_mapping(struct domain *d, 
> unsigned long va,
>  
>  void free_perdomain_mappings(struct domain *d)
>  {
> -l3_pgentry_t *l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
> +l3_pgentry_t *l3tab;
>  unsigned int i;
>  
> +if ( !d->arch.perdomain_l3_pg )
> +return;
> +
> +l3tab = __map_domain_page(d->arch.perdomain_l3_pg);
> +
>  for ( i = 0; i < PERDOMAIN_SLOTS; ++i)
>  if ( l3e_get_flags(l3tab[i]) & _PAGE_PRESENT )
>  {
> @@ -6544,6 +6549,7 @@ void free_perdomain_mappings(struct domain *d)
>  
>  unmap_domain_page(l3tab);
>  free_domheap_page(d->arch.perdomain_l3_pg);
> +d->arch.perdomain_l3_pg = NULL;
>  }
>  
>  #ifdef MEMORY_GUARD


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

[Xen-devel] [PATCH for-next v2 07/10] x86/domain: factor out pv_domain_destroy

[Wei Liu]

No functional change.

Signed-off-by: Wei Liu 
---
v2:
1. reset fields
2. destroy perdomain mapping

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/domain.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index fd5d47ab3d..952e05366a 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -536,6 +536,16 @@ static bool emulation_flags_ok(const struct domain *d, 
uint32_t emflags)
 return true;
 }
 
+static void pv_domain_destroy(struct domain *d)
+{
+destroy_perdomain_mapping(d, GDT_LDT_VIRT_START,
+  GDT_LDT_MBYTES << (20 - PAGE_SHIFT));
+xfree(d->arch.pv_domain.cpuidmasks);
+d->arch.pv_domain.cpuidmasks = NULL;
+free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
+d->arch.pv_domain.gdt_ldt_l1tab = NULL;
+}
+
 int arch_domain_create(struct domain *d, unsigned int domcr_flags,
struct xen_arch_domainconfig *config)
 {
@@ -712,10 +722,8 @@ int arch_domain_create(struct domain *d, unsigned int 
domcr_flags,
 paging_final_teardown(d);
 free_perdomain_mappings(d);
 if ( is_pv_domain(d) )
-{
-xfree(d->arch.pv_domain.cpuidmasks);
-free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
-}
+pv_domain_destroy(d);
+
 return rc;
 }
 
@@ -735,10 +743,7 @@ void arch_domain_destroy(struct domain *d)
 
 free_perdomain_mappings(d);
 if ( is_pv_domain(d) )
-{
-free_xenheap_page(d->arch.pv_domain.gdt_ldt_l1tab);
-xfree(d->arch.pv_domain.cpuidmasks);
-}
+pv_domain_destroy(d);
 
 free_xenheap_page(d->shared_info);
 cleanup_domain_irq_mapping(d);
-- 
2.11.0


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