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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf e8a70885d8f34533b6dd69878fe95a249e9af086
baseline version:
 ovmf 2cf9ecd2262e4098171fa27c97b56d483f5cf3b4

Last test of basis   101297  2016-10-05 22:45:55 Z0 days
Testing same since   101303  2016-10-06 04:53:09 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 

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=e8a70885d8f34533b6dd69878fe95a249e9af086
+ . ./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 
e8a70885d8f34533b6dd69878fe95a249e9af086
+ branch=ovmf
+ revision=e8a70885d8f34533b6dd69878fe95a249e9af086
+ . ./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.7-testing
+ '[' xe8a70885d8f34533b6dd69878fe95a249e9af086 = 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.g

[Xen-devel] [ovmf baseline-only test] 67810: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm   2 hosts-allocate  broken REGR. vs. 67793
 build-amd64   2 hosts-allocate  broken REGR. vs. 67793
 build-amd64-pvops 2 hosts-allocate  broken REGR. vs. 67793
 build-i386-pvops  2 hosts-allocate  broken REGR. vs. 67793
 build-i386-xsm2 hosts-allocate  broken REGR. vs. 67793
 build-i3862 hosts-allocate  broken REGR. vs. 67793

Regressions which are regarded as allowable (not blocking):
 build-i386-xsm3 capture-logs   broken blocked in 67793
 build-i3863 capture-logs   broken blocked in 67793
 build-i386-pvops  3 capture-logs   broken blocked in 67793
 build-amd64-xsm   3 capture-logs   broken blocked in 67793
 build-amd64-pvops 3 capture-logs   broken blocked in 67793
 build-amd64   3 capture-logs   broken blocked in 67793

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

version targeted for testing:
 ovmf 2cf9ecd2262e4098171fa27c97b56d483f5cf3b4
baseline version:
 ovmf c0b7e2b2bfc2748112607bfe83fc99cf48c97b48

Last test of basis67793  2016-10-04 03:50:13 Z2 days
Testing same since67810  2016-10-06 04:46:28 Z0 days1 attempts


People who touched revisions under test:
  Tapan Shah 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

broken-step build-amd64-xsm hosts-allocate
broken-step build-amd64 hosts-allocate
broken-step build-amd64-pvops hosts-allocate
broken-step build-i386-pvops hosts-allocate
broken-step build-i386-xsm hosts-allocate
broken-step build-i386 hosts-allocate
broken-step build-i386-xsm capture-logs
broken-step build-i386 capture-logs
broken-step build-i386-pvops capture-logs
broken-step build-amd64-xsm capture-logs
broken-step build-amd64-pvops capture-logs
broken-step build-amd64 capture-logs

Push not applicable.


commit 2cf9ecd2262e4098171fa27c97b56d483f5cf3b4
Author: Tapan Shah 
Date:   Wed Oct 5 13:58:05 2016 -0700

ShellPkg: Move UnicodeCollation2 Protcol locate out of UefiShellLib 
constructor

Move gEfiUnicodeCollation2ProtocolGuid protocol outside of UefiShellLib 
constructor
function.
Locate gEfiUnicodeCollation2ProtocolGuid protocol in ShellOpenFileByName() 
which
consumes this protocol API.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Tapan Shah 
Reviewed-by: Jaben Carsey 

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

Re: [Xen-devel] Xen Code Review Dashboard - Outreachy Program Project

[Lars Kurth]

Kevin,
I just wanted to make sure that you checked you are eligible for Outreachy
Lars

> On 6 Oct 2016, at 02:08, tevin.k.mall...@gmail.com wrote:
> 
> Hi Jesus,
>  
> 10:30am EST on Friday the 7th sounds great. I’ll get started on my task and 
> bring any questions I may have to the IRC meeting. I’ll keep Friday clear 
> just incase we need to adjust our meeting time to included Lars as well.  
> Thank you for your time. 
>  
> -Tevin K. Mallory  
>  
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised

[Martin Kletzander]

On Wed, Oct 05, 2016 at 06:06:29PM -0600, Jim Fehlig wrote:

On 10/04/2016 11:02 AM, Ian Jackson wrote:

Currently, osstest wrongly thinks that ARM can do save/restore,
because `virsh help' does mention the save command (on all
architectures).

Additionally, check the virth capabilities xpath
   /capabilities/host/migration_features
to try to see whether this host supports migration.

I am not sure if this is the right path to check.  Perhaps
   /capabilities/host/migration_features/live
is more correct, but this may be wrong if Xen comes to support save/restore
on ARM, but not live migration (but perhaps libvirt cannot express this
distinction in which case perhaps it's right after all).


Looking at the capabilities generation code again, I see that
virCapabilitiesNew() takes 'offlineMigrate' and 'liveMigrate' parameters. I
assume offline in this context means save, copy, restore. Martin, is that
assumption correct?



The thing is that it's not documented.  I can't even say "enough", it's
more like "at all".  You can have a look at it:

 https://libvirt.org/formatcaps.html

It doesn't even talk about , just , but
I guess that's the same thing.

Since offline migration (as in migrating a domain between hosts without
being running) is not that used in the code and talked about, I'm
guessing offline means save restore.  Looking at the history it was
added before the "offline" migration, so it probably means
save/restore.  To avoid confusion, I would suggest we add either
 or rather  (the naming is not important) and document
what it means.  And then you can use it exactly how you'd like.  And
you'll be also sure it means what you need it to mean ;)  The patches
will be straigh-forward, let me know if I can help anyhow.


If so, I think the saverestore_check() below can look for
/capabilities/host/migration_features. The migration check in 1/2 can look for
/capabilities/host/migration_features/live. Is it fair to assume save/restore is
available when live migration is supported?



With that you could straight check for  and  ;)

Martin


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 101250
 test-amd64-i386-xl-raw9 debian-di-installfail REGR. vs. 101250
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail REGR. vs. 101250

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

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

version targeted for testing:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9
baseline version:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4

Last test of basis   101250  2016-10-04 02:36:21 Z2 days
Failing since101254  2016-10-04 13:18:43 Z1 days3 attempts
Testing same since   101300  2016-10-06 03:27:49 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  casionwoo 
  Ian Jackson 
  Jan Beulich 
  JEUNGWOO, YOO 
  Wei Liu 

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

Re: [Xen-devel] [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised

[Ian Jackson]

Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt 
save/restore when migration not advertised"):
> Since offline migration (as in migrating a domain between hosts without
> being running) is not that used in the code and talked about, I'm
> guessing offline means save restore.  Looking at the history it was
> added before the "offline" migration, so it probably means
> save/restore.  To avoid confusion, I would suggest we add either
>  or rather  (the naming is not important) and document
> what it means.  And then you can use it exactly how you'd like.  And
> you'll be also sure it means what you need it to mean ;)  The patches
> will be straigh-forward, let me know if I can help anyhow.

Except that the point of the exercise is to detect which features are
supported in which versions.  Whatever I do in osstest needs to work
with older libvirt versions, which do not report
  /capabilities/host/migration_features/save
even on x86, where it is supported.  I suppose I could detect
  /capabilities/host/migration_features/live
and assume that save/restore was supported (since it's unlikely that
live migration would be supported but not save/restore).

So for now I think I need to use
  /capabilities/host/migration_features
as a proxy for save/restore ?

Ian.

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

Re: [Xen-devel] Clarification regarding MEM_ACCESS_* flags usage

[Razvan Cojocaru]

On 10/05/2016 11:54 PM, Julien Grall wrote:
> 
> 
> On 05/10/2016 13:23, Tamas K Lengyel wrote:
>> Hi Julien,
>> It is expected that certain combinations of mem_access flags will put
>> the domain into unstable condition, resulting in a crash or a hang. As
>> Razvan mentioned, on x86 we can end up triggering EPT misconfiguration
>> with the wrong set of flags. The user of the API is expected to know
>> what he/she is doing in this regard, we don't do any enforcements or
>> sanity checking on the Xen side.
>>
>> As to the issue you describe, indeed that can happen. If the user marks
>> a pagetable area non-readable/non-writable and the way ARM reports a
>> walk for an instruction-fetch as an execute violation when it traps, it
>> will hang the VM in a continuous violation state as no execute-violation
>> was requested to be triggered on the gfn by the user. There are other
>> situations where this can happen, as on ARM there is no such thing as
>> execute-only memory, so any time the user requests memory to be
>> execute-only or writable-executable will lead to problems like this -
>> instruction fetch violation when the user only requested
>> read-violations. But again, the users are expected to know what they are
>> doing and perform their own sanity checks as appropriate.
> 
> I think the problem I described is neither the fault of the user,
> neither a misconfiguration of the page table. Let me clarify it.
> 
> The user can purposefully restrict the access to stage-1 page table to
> detect when the OS is modifying them. By side effect, this will also
> impact the page table walker.
> 
> A prefetch abort (e.g when an error occurs when the processor is trying
> to load the instruction) can either occur during a stage-1 page table
> walk (e.g the underlying memory of stage-1 page table has been
> protected) or because the permission in the stage-2 entry has been
> restricted.
> 
> In the case of the latter, this will always be because the memory is not
> executable. However, for the former may happen if the page table walker
> (i.e the MMU) is reading/writing the entry.
> 
> However, Xen ARM today is always considering that a prefetch abort will
> happen because it was not possible to execute the instruction.
> 
> I requested clarification about the flags because we need to fix this
> valid issue. From the usage on ARM and in the vm event app, it is not
> clear how those flags should be used.

I understand. FWIW, I find it better to have the most precise type of
event sent, i.e. in your case if the application gets a read-only page
fault event it would then be able to do something about it (for example,
lift the restrictions on the page), whereas if it would get an execute
denied event in this case, allowing execution on that page would not
solve the issue and leave the guest in an infinite loop, as you say. The
problem here is that the application never gets a chance to do the right
thing even if it wants to, and is capable of that.

So I'm all for properly differentiating between these two cases, unless
the ARM SDM disagrees or there's some reason why this is unfeasible.


Thanks,
Razvan

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

Re: [Xen-devel] [OSSTEST PATCH 1/2] libvirt: Check migration capabilities using proper XML parser

[Ian Jackson]

Julien Grall writes ("Re: [OSSTEST PATCH 1/2] libvirt: Check migration 
capabilities using proper XML parser"):
> On 04/10/2016 10:05, Ian Jackson wrote:
> > Missing _.  I didn't test this again before sending it.  I'd still
> > like a review from libvirt (and Xen/ARM) folks.
> 
> I am not sure what kind of input you would need from Xen/ARM. This patch 
> set looks very libvirt specific.

It is.  Sorry to spam you with the whole thread.  The only thing I
need from Xen/ARM people is a sanity check that my understanding of
the current and likely future supported features is correct.

Thanks,
Ian.

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

[Xen-devel] [xen-4.5-testing baseline-only test] 67811: trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 2 hosts-allocate  broken REGR. vs. 67749
 build-amd64-prev  2 hosts-allocate  broken REGR. vs. 67749
 build-amd64-pvops 2 hosts-allocate  broken REGR. vs. 67749
 build-i3862 hosts-allocate  broken REGR. vs. 67749
 build-amd64   2 hosts-allocate  broken REGR. vs. 67749
 build-i386-pvops  2 hosts-allocate  broken REGR. vs. 67749
 build-i386-prev   2 hosts-allocate  broken REGR. vs. 67749
 build-armhf   2 hosts-allocate  broken REGR. vs. 67749
 build-amd64-xtf   2 hosts-allocate  broken REGR. vs. 67749

Regressions which are regarded as allowable (not blocking):
 build-i386-prev   3 capture-logs   broken blocked in 67749
 build-armhf-pvops 3 capture-logs   broken blocked in 67749
 build-i3863 capture-logs   broken blocked in 67749
 build-armhf   3 capture-logs   broken blocked in 67749
 build-amd64-prev  3 capture-logs   broken blocked in 67749
 build-amd64   3 capture-logs   broken blocked in 67749

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-11 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-winxpsp3  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd   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)   

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  c7d3cf2e3ba73e6e3eee36bd1d6ca2eed1fedc55
baseline version:
 libvirt  66bfc7cc61ca0f6ca8d57811024565d2c89f47f6

Last test of basis   101270  2016-10-05 04:23:38 Z1 days
Testing same since   101301  2016-10-06 04:22:57 Z0 days1 attempts


People who touched revisions under test:
  Jiri Denemark 
  John Ferlan 
  Laine Stump 
  Michal Privoznik 
  Nehal J Wani 
  Peter Krempa 

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



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=c7d3cf2e3ba73e6e3eee36bd1d6ca2eed1fedc55
+ . ./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 libvirt 
c7d3cf2e3ba73e6e3ee

Re: [Xen-devel] [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised

[Martin Kletzander]

On Thu, Oct 06, 2016 at 10:59:06AM +0100, Ian Jackson wrote:

Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt 
save/restore when migration not advertised"):

Since offline migration (as in migrating a domain between hosts without
being running) is not that used in the code and talked about, I'm
guessing offline means save restore.  Looking at the history it was
added before the "offline" migration, so it probably means
save/restore.  To avoid confusion, I would suggest we add either
 or rather  (the naming is not important) and document
what it means.  And then you can use it exactly how you'd like.  And
you'll be also sure it means what you need it to mean ;)  The patches
will be straigh-forward, let me know if I can help anyhow.


Except that the point of the exercise is to detect which features are
supported in which versions.  Whatever I do in osstest needs to work
with older libvirt versions, which do not report
 /capabilities/host/migration_features/save
even on x86, where it is supported.  I suppose I could detect
 /capabilities/host/migration_features/live
and assume that save/restore was supported (since it's unlikely that
live migration would be supported but not save/restore).

So for now I think I need to use
 /capabilities/host/migration_features
as a proxy for save/restore ?



Well then, unfortunately you do.

Also, looking at how the code is structured, if you have live migration
but don't have save/restore, you won't have  there
at all.


Ian.


signature.asc
Description: Digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[George Dunlap]

On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:
 On 05.10.16 at 15:32,  wrote:
>> Here it comes xl dmesg with Xen booted with e820-verbose=true
>
> I have to admit that the only way I can see
>
> (XEN) Initial Xen-e820 RAM map:
> (XEN)   - 0009ec00 (usable)
> (XEN)  0009ec00 - 000a (reserved)
> (XEN)  000e - 0010 (reserved)
> (XEN)  0010 - 79cbe000 (usable)
> (XEN)  79cbe000 - bcd2f000 (reserved)
> (XEN)  bcd2f000 - bce7f000 (ACPI NVS)
> (XEN)  bce7f000 - bceff000 (ACPI data)
> (XEN)  bceff000 - bfa0 (reserved)
> (XEN)  f800 - fc00 (reserved)
> (XEN)  fec0 - fec01000 (reserved)
> (XEN)  fed08000 - fed09000 (reserved)
> (XEN)  fed1 - fed18000 (reserved)
> (XEN)  fed18000 - fed19000 (reserved)
> (XEN)  fed19000 - fed1a000 (reserved)
> (XEN)  fed1c000 - fed2 (reserved)
> (XEN)  fee0 - fee01000 (reserved)
> (XEN)  ffc0 - 0001 (reserved)
> (XEN)  0001 - 00043e60 (reserved)
>
> having all those reserved regions above 2Gb is for the boot
> loader to behave oddly. Since Linux and Xen use different paths
> in the boot loader, one can't really draw conclusions from Linux
> getting to see a better memory map.

Do you have any suggestions for how to check whether it really is the
bootloader?

Leonardo, are you using grub2 or a different bootloader?

 -George

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

Re: [Xen-devel] Xen Code Review Dashboard - Outreachy Program Project

[tevin.k.mallory]

Hi Jesus,

10:30am EST on Friday the 7th sounds great. I’ll get started on my task and 
bring any questions I may have to the IRC meeting. I’ll keep Friday clear just 
incase we need to adjust our meeting time to included Lars as well.  
Thank you for your time. 

-Tevin K. Mallory  


Sent from Mail for Windows 10

From: Jesus M. Gonzalez-Barahona
Sent: Wednesday, October 5, 2016 6:04 PM
To: tevin.k.mall...@gmail.com
Cc: xen-de...@lists.xenproject.org
Subject: Re: Xen Code Review Dashboard - Outreachy Program Project

On Tue, 2016-10-04 at 20:18 -0400, tevin.k.mall...@gmail.com wrote:
> Hello Jesus!
>  
> Thank you for taking the time out of your busy schedule to responded.
> I would love a summary of the small contribution over email, as this
> will allow me to get started on the project sooner. I am located in
> Florida USA, on Eastern Daylight Time and available anytime on
> October 6th to discuss details. If you have certain times that work
> best for you I can easily adjust my schedule. Just let me know when
> you would like to chat via IRC and I will be there. For the most part
> my schedule is very flexible, I am always available on Mondays,
> Tuesdays and Thursdays at anytime. Thank you once again and I look
> forward to hearing from you.

OK, here we are. With respect to the project in general, I assume
you're familiar with

https://wiki.xenproject.org/wiki/Outreach_Program_Projects#Xen_Code_Rev
iew_Dashboard

Right?

The main aim of the project is to reproduce all the process up to
having something like https://xen.biterg.io/ But using only GrimoireLab
tools

http://grimoirelab.github.io

Now it is using a mixture of MetricsGrimoire and custom scripts

The first step is to get information both from mailing lists and git
repositories using Perceval, and storing it in ElasticSearch. Later,
there are some scripts that should be ported to use this ElasticSearch
data (instead of the SQL data they are using now). With that, produce
the ElasticSearch indexes for the dashboard. Then, if possible, improve
the dashbosrd and make it more useful for the Xen community

Now, about the microtask.

I guess you know you can start with one microtask to show that you are
likely to be the right person for this project, according to Outreachy
requirements.

In this case, the microtask would be getting data from a mailing list
with Perceval. The mailing list is xen-devel. You get its archives
analyzed by Perceval, and store the resulting raw index in
ElasticSearch.

Once you're good with this, you do the same for the Xen git repo

And once you're good with this, you write an script which produces a
new index with some information for each commit, plus the branch in
which it was committed

Mboxes are at

https://lists.xenproject.org/archives/html/mbox/

They are then named xen-devel--, e.g. xen-devel-2016-09

You can write a little script using wget or curl to downoad several of
them at once. To begin with, you can start with some of them (say 5-10)

The code contribution result of the microtask would be the
identification of the branches, based on the output of Perceval / git

The setup would be you getting all the info from some mboxes in
ElasticSearch, a git repo in ElasticSearch, and a simple index,
combined of both plus branches information, again in ElasticSearch

Once you have those in Elasticsearch, just produce the result of
querying some of the items in ElasticSearch with curl, and the code for
the identification of branches. All of this can be stored in a git
repository for verification.

I can support you via irc and email if you have any trouble.

We're compiling some information on how to use GrimoireLib in

https://jgbarah.gitbooks.io/grimoirelab-training

Maybe that's a good place to start.

Is all of this ok with you?

Jesus.

-- 
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[blallo]

Andrew Cooper:

On 05/10/16 14:02, George Dunlap wrote:

On 05/10/16 13:52, bla...@riseup.net wrote:

George Dunlap:

On Wed, Oct 5, 2016 at 11:16 AM,   wrote:

Hi all,
I have been wondering if I could manage to make Xen function on my
laptop, using as dom0 my Arch Linux installation. As far as I understood
there is no currently supported package in the AUR nor, obviously, in
the official repos. What to do? Compile it by myself! I went under all
the process, in particular

% PYTHON="/usr/bin/python2" ./configure --enable-stubdom \
   --enable-systemd --prefix=/usr

% PYTHON="/usr/bin/python2" NO_WERROR=1 make dist

% sudo PYTHON="/usr/bin/python2" NO_WERROR=1 make install

After that I manually added a grub entry to boot into my dom0
chainbooted by Xen.

And it seemed I succeeded, as far as I manage to boot into my system.
Everything seem to work, except that if I look at the features of my
system

% sudo xl info

I get a discouraging indication on the total amount of ram I have on my
system

total_memory   : 1948
free_memory: 120

while the total memory is (as measured from Arch booted without Xen)

% free -m
   total   used free shared  buff/cache  available
   Mem:15924   8756 2206 737 49616100
   Swap:   819108191

What to do? I am very new to Xen, how can I debug it?

Thanks for your report.  Can you please attach the full output of "xl
info", as well as the output of "xl dmesg"?

Thanks,
-George

I attach the output of xl info, xl dmesg in dom0 *and* dmesg in a normal
Arch Linux boot (without Xen).

That's quite strange -- the e820 maps reported by Linux and Xen appear
to be almost completely different:

(XEN) Xen-e820 RAM map:
(XEN)   - 0009ec00 (usable)
(XEN)  0009ec00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 79cbe000 (usable)
(XEN)  79cbe000 - bcd2f000 (reserved)
(XEN)  bcd2f000 - bce7f000 (ACPI NVS)
(XEN)  bce7f000 - bceff000 (ACPI data)
(XEN)  bceff000 - bfa0 (reserved)
(XEN)  f800 - fc00 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fed08000 - fed09000 (reserved)
(XEN)  fed1 - fed1a000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ffc0 - 00043e60 (reserved)

BIOS-e820: [mem 0x-0x00057fff] usable
BIOS-e820: [mem 0x00058000-0x00058fff] reserved
BIOS-e820: [mem 0x00059000-0x0008bfff] usable
BIOS-e820: [mem 0x0008c000-0x000b] reserved
BIOS-e820: [mem 0x000e-0x000f] reserved
BIOS-e820: [mem 0x0010-0x7b82dfff] usable
BIOS-e820: [mem 0x7b82e000-0x7ba2] reserved
BIOS-e820: [mem 0x7ba3-0xba1fcfff] usable
BIOS-e820: [mem 0xba1fd000-0xba3fcfff] type 20
BIOS-e820: [mem 0xba3fd000-0xbcd2efff] reserved
BIOS-e820: [mem 0xbcd2f000-0xbce7efff] ACPI NVS
BIOS-e820: [mem 0xbce7f000-0xbcefefff] ACPI data
BIOS-e820: [mem 0xbceff000-0xbcef] usable
BIOS-e820: [mem 0xbcf0-0xbf9f] reserved
BIOS-e820: [mem 0xf80f8000-0xf80f8fff] reserved
BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
BIOS-e820: [mem 0x0001-0x00043e5f] usable

With the key thing being that Xen's version has the range from ~2G-3G
and 4G-17G as 'reserved', while Linux's version has those ranges as
'usable'.

Jan / Andy, any idea what's going on here?


Not specifically.  Can you boot with e820-verbose on the Xen command
line, which will provide more information?



Here it comes xl dmesg with Xen booted with e820-verbose=true

Thanks

--
Leonardo
 __  ___  _   _ ___  
 \ \/ /___ _ __   | || | |___  / _ \ 
  \  // _ \ '_ \  | || |_   / / | | |
  /  \  __/ | | | |__   _| / /| |_| |
 /_/\_\___|_| |_||_|(_)_/(_)___/ 
 
(XEN) Xen version 4.7.0 (root@) (gcc (GCC) 6.2.1 20160830) debug=n Thu Sep 29 
15:21:36 CEST 2016
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.02~beta3
(XEN) Command line: e820-verbose=true
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 0 EDD information structures
(XEN) Initial Xen-e820 RAM map:
(XEN)   - 0009ec00 (usable)
(XEN)  0009ec00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 79cbe000 (usable)
(XEN)  79cbe000 - bcd2f000 (reserved)
(XEN)  bcd2f00

Re: [Xen-devel] Xen Code Review Dashboard - Outreachy Program Project

[tevin.k.mallory]

Hello Jesus!

Thank you for taking the time out of your busy schedule to responded. I would 
love a summary of the small contribution over email, as this will allow me to 
get started on the project sooner. I am located in Florida USA, on Eastern 
Daylight Time and available anytime on October 6th to discuss details. If you 
have certain times that work best for you I can easily adjust my schedule. Just 
let me know when you would like to chat via IRC and I will be there. For the 
most part my schedule is very flexible, I am always available on Mondays, 
Tuesdays and Thursdays at anytime. Thank you once again and I look forward to 
hearing from you. 

-Tevin K. Mallory

Sent from Mail for Windows 10

From: Jesus M. Gonzalez-Barahona___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[Blallo]

I'm using grub2. After the lunch break I can post the full grub menu entry and 
the exact version of grub2.


On 6 October 2016 12:55:16 CEST, George Dunlap  wrote:
>On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:
> On 05.10.16 at 15:32,  wrote:
>>> Here it comes xl dmesg with Xen booted with e820-verbose=true
>>
>> I have to admit that the only way I can see
>>
>> (XEN) Initial Xen-e820 RAM map:
>> (XEN)   - 0009ec00 (usable)
>> (XEN)  0009ec00 - 000a (reserved)
>> (XEN)  000e - 0010 (reserved)
>> (XEN)  0010 - 79cbe000 (usable)
>> (XEN)  79cbe000 - bcd2f000 (reserved)
>> (XEN)  bcd2f000 - bce7f000 (ACPI NVS)
>> (XEN)  bce7f000 - bceff000 (ACPI data)
>> (XEN)  bceff000 - bfa0 (reserved)
>> (XEN)  f800 - fc00 (reserved)
>> (XEN)  fec0 - fec01000 (reserved)
>> (XEN)  fed08000 - fed09000 (reserved)
>> (XEN)  fed1 - fed18000 (reserved)
>> (XEN)  fed18000 - fed19000 (reserved)
>> (XEN)  fed19000 - fed1a000 (reserved)
>> (XEN)  fed1c000 - fed2 (reserved)
>> (XEN)  fee0 - fee01000 (reserved)
>> (XEN)  ffc0 - 0001 (reserved)
>> (XEN)  0001 - 00043e60 (reserved)
>>
>> having all those reserved regions above 2Gb is for the boot
>> loader to behave oddly. Since Linux and Xen use different paths
>> in the boot loader, one can't really draw conclusions from Linux
>> getting to see a better memory map.
>
>Do you have any suggestions for how to check whether it really is the
>bootloader?
>
>Leonardo, are you using grub2 or a different bootloader?
>
> -George

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

[Xen-devel] Xen Code Review Dashboard - Outreachy Program Project

[tevin.k.mallory]

Hello Xen Project Team!
My name is Tevin Mallory, I am graduate student with a knack for data analytics 
and a deep interest in coding. I wish to take a moment to introduce myself to 
you by email to say hello. I´m enthusiastic about applying to join this team as 
an Outreachy intern and look forward to contacting everyone.  I have included 
the project I am interested in joining below:

SKILLS NEEDED: SQL, JAVA/JAVASCRIPT, HTML5/XML SKILLS, BASIC SOFTWARE DESIGN 
KNOWLEDGE (WORKING WITH THE MENTORS)
DESCRIPTION: THE CODE REVIEW PROCESS IN XEN IS BEING ANALYSED USING 
METRICSGRIMOIRE TOOLS (CORRELATING EMAIL BASED REVIEWS WITH GIT COMMITS IN XEN 
PROJECT TREES TO COVER THE ENTIRE WORKFLOW). THE DATA IS THEN STORED IN AN SQL 
DATABASE AND VISUALISED USING A KIBANA BASED DASHBOARD AND SOME CUSTOM REPORTS 
(E.G. [1]). THE MAIN OBJECTIVES OF THIS PROJECT IS TO EXTEND THE EXISTING 
TOOLS, TO
TO PRODUCE A PERCEVAL-BASED SCRIPT TO ANALYSE THE CODE REVIEW MESSAGES IN XEN 
(INSTEAD OF THE ORIGINAL MLSTATS/CVSANALY-BASED SCRIPTS). THIS WOULD INCLUDE 
TAKING THE OUTPUT OF OUR CURRENT PROTOTYPE SCRIPTS, AND CONVERTING THEM INTO A 
MORE MATURE SCRIPT, USING INFORMATION PRODUCED BY PERCEVAL.
TO ENRICH THAT INFORMATION AS IS NEEDED, BASED ON EXISTING CUSTOM REPORTS, TO 
PRODUCE THE ELASTICSEARCH INDEXES THAT WE USE FOR THE DASHBOARDS.
IF TIME, TO WORK WITH THE XEN PROJECT DEVELOPER COMMUNITY ON EXTENDING THE 
DASHBOARDS THEMSELVES (NOTE THAT THIS PART MAY NOT BE NEEDED AND DEPENDS ON 
ENGAGEMENT WITH THE DEVELOPER COMMUNITIES' NEEDS).
IF TIME, WE COULD CONSIDER TESTING/EXTENDING THE HEURISTICS DEVELOPED FOR XEN 
PROJECT TO WORK WITH OTHER LINUX-RELATED PROJECTS, AND MAYBE LINUX ITSELF.
 I have coded a website for a small business using HTML5, CSS and same 
JavaScript. I plan to start a career in marketing research analytics and have 
learn to use SQL. However I am still at the beginner level in fully utilizing 
it and would love the opportunity to develop my skills in this project.  I 
would love further discuss ways in which I can get involved with this project, 
maybe I can receive a task making a code contribution. I know there is an IRC 
for this project and was wonder if you would prefer me to contact you all 
though that, instead of email.  Please and thank you for your time. You can 
reach me at 
tevin.k.mall...@gmail.com and my GitHub: https://github.com/CodeCaster-MoonT . 
 
Sincerely,
Tevin K. Mallory 


Sent from Mail for Windows 10

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

[Xen-devel] [distros-debian-wheezy test] 67812: trouble: blocked/broken

[Platform Team regression test user]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   2 hosts-allocate  broken REGR. vs. 67783
 build-amd64-pvops 2 hosts-allocate  broken REGR. vs. 67783
 build-i3862 hosts-allocate  broken REGR. vs. 67783
 build-amd64   2 hosts-allocate  broken REGR. vs. 67783
 build-armhf-pvops 2 hosts-allocate  broken REGR. vs. 67783
 build-i386-pvops  2 hosts-allocate  broken REGR. vs. 67783

Regressions which are regarded as allowable (not blocking):
 build-i3863 capture-logs   broken blocked in 67783
 build-i386-pvops  3 capture-logs   broken blocked in 67783
 build-armhf-pvops 3 capture-logs   broken blocked in 67783
 build-amd64-pvops 3 capture-logs   broken blocked in 67783
 build-armhf   3 capture-logs   broken blocked in 67783
 build-amd64   3 capture-logs   broken blocked in 67783

Tests which did not succeed, but are not blocking:
 test-amd64-i386-i386-wheezy-netboot-pvgrub  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub  1 build-check(1) blocked n/a
 test-amd64-i386-amd64-wheezy-netboot-pygrub  1 build-check(1)  blocked n/a

baseline version:
 flight   67783

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub blocked 
 test-amd64-i386-i386-wheezy-netboot-pvgrub   blocked 
 test-amd64-i386-amd64-wheezy-netboot-pygrub  blocked 
 test-amd64-amd64-i386-wheezy-netboot-pygrub  blocked 



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 v2 03/30] xen/x86: fix parameters and return value of *_set_allocation functions

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 09:05:43AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Roger Pau Monne
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: George Dunlap ; Andrew Cooper
> > ; Tim (Xen.org) ; Jan Beulich
> > ; boris.ostrov...@oracle.com; Roger Pau Monne
> > 
> > Subject: [Xen-devel] [PATCH v2 03/30] xen/x86: fix parameters and return
> > value of *_set_allocation functions
> > 
> > Return should be an int, and the number of pages should be an unsigned
> > long.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: George Dunlap 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Tim Deegan 
> > ---
> >  xen/arch/x86/mm/hap/hap.c   |  6 +++---
> >  xen/arch/x86/mm/shadow/common.c |  7 +++
> >  xen/include/asm-x86/domain.h| 12 ++--
> >  3 files changed, 12 insertions(+), 13 deletions(-)
> > 
> > diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
> > index 3218fa2..b6d2c61 100644
> > --- a/xen/arch/x86/mm/hap/hap.c
> > +++ b/xen/arch/x86/mm/hap/hap.c
> > @@ -325,7 +325,7 @@ static void hap_free_p2m_page(struct domain *d,
> > struct page_info *pg)
> >  static unsigned int
> >  hap_get_allocation(struct domain *d)
> >  {
> > -unsigned int pg = d->arch.paging.hap.total_pages
> > +unsigned long pg = d->arch.paging.hap.total_pages
> >  + d->arch.paging.hap.p2m_pages;
> 
> You are modifying this calculation (by including hap.p2m_pages as well as 
> hap.total_pages) so the comment should probably mention this.

I think your mail reader is fooling you, the '+' was already there before my 
change (and in fact I haven't even touched that line).
 
> > 
> >  return ((pg >> (20 - PAGE_SHIFT))
> > @@ -334,8 +334,8 @@ hap_get_allocation(struct domain *d)
> > 
> >  /* Set the pool of pages to the required number of pages.
> >   * Returns 0 for success, non-zero for failure. */
> > -static unsigned int
> > -hap_set_allocation(struct domain *d, unsigned int pages, int *preempted)
> > +static int
> > +hap_set_allocation(struct domain *d, unsigned long pages, int
> > *preempted)
> >  {
> >  struct page_info *pg;
> > 
> > diff --git a/xen/arch/x86/mm/shadow/common.c
> > b/xen/arch/x86/mm/shadow/common.c
> > index 21607bf..d3cc2cc 100644
> > --- a/xen/arch/x86/mm/shadow/common.c
> > +++ b/xen/arch/x86/mm/shadow/common.c
> > @@ -1613,9 +1613,8 @@ shadow_free_p2m_page(struct domain *d, struct
> > page_info *pg)
> >   * Input will be rounded up to at least shadow_min_acceptable_pages(),
> >   * plus space for the p2m table.
> >   * Returns 0 for success, non-zero for failure. */
> > -static unsigned int sh_set_allocation(struct domain *d,
> > -  unsigned int pages,
> > -  int *preempted)
> > +static int sh_set_allocation(struct domain *d, unsigned long pages,
> > + int *preempted)
> >  {
> >  struct page_info *sp;
> >  unsigned int lower_bound;
> > @@ -1692,7 +1691,7 @@ static unsigned int sh_set_allocation(struct domain
> > *d,
> >  /* Return the size of the shadow pool, rounded up to the nearest MB */
> >  static unsigned int shadow_get_allocation(struct domain *d)
> >  {
> > -unsigned int pg = d->arch.paging.shadow.total_pages
> > +unsigned long pg = d->arch.paging.shadow.total_pages
> >  + d->arch.paging.shadow.p2m_pages;
> 
> Same here.
> 
> >  return ((pg >> (20 - PAGE_SHIFT))
> >  + ((pg & ((1 << (20 - PAGE_SHIFT)) - 1)) ? 1 : 0));
> 
> OMG. Is there no rounding macro you can use for this?

Hm, I don't think there's any, and the code was already there (I haven't 
added this), so I will just leave it as-is.

Thanks, Roger.

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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[Konrad Rzeszutek Wilk]

On Thu, Oct 06, 2016 at 12:59:13PM +0200, Blallo wrote:
> I'm using grub2. After the lunch break I can post the full grub menu entry 
> and the exact version of grub2.

Cc-ing Daniel (who is now an GRUB2 maintainer).

Is this by chance an EFI box?And you are booting using EFI GRUB2?
> 
> 
> On 6 October 2016 12:55:16 CEST, George Dunlap  
> wrote:
> >On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:
> > On 05.10.16 at 15:32,  wrote:
> >>> Here it comes xl dmesg with Xen booted with e820-verbose=true
> >>
> >> I have to admit that the only way I can see
> >>
> >> (XEN) Initial Xen-e820 RAM map:
> >> (XEN)   - 0009ec00 (usable)
> >> (XEN)  0009ec00 - 000a (reserved)
> >> (XEN)  000e - 0010 (reserved)
> >> (XEN)  0010 - 79cbe000 (usable)
> >> (XEN)  79cbe000 - bcd2f000 (reserved)
> >> (XEN)  bcd2f000 - bce7f000 (ACPI NVS)
> >> (XEN)  bce7f000 - bceff000 (ACPI data)
> >> (XEN)  bceff000 - bfa0 (reserved)
> >> (XEN)  f800 - fc00 (reserved)
> >> (XEN)  fec0 - fec01000 (reserved)
> >> (XEN)  fed08000 - fed09000 (reserved)
> >> (XEN)  fed1 - fed18000 (reserved)
> >> (XEN)  fed18000 - fed19000 (reserved)
> >> (XEN)  fed19000 - fed1a000 (reserved)
> >> (XEN)  fed1c000 - fed2 (reserved)
> >> (XEN)  fee0 - fee01000 (reserved)
> >> (XEN)  ffc0 - 0001 (reserved)
> >> (XEN)  0001 - 00043e60 (reserved)
> >>
> >> having all those reserved regions above 2Gb is for the boot
> >> loader to behave oddly. Since Linux and Xen use different paths
> >> in the boot loader, one can't really draw conclusions from Linux
> >> getting to see a better memory map.
> >
> >Do you have any suggestions for how to check whether it really is the
> >bootloader?
> >
> >Leonardo, are you using grub2 or a different bootloader?
> >
> > -George
> 
> -- 
> Leonardo

> ___
> 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] xen/x86: Update topology map for PV VCPUs

[Jan Beulich]

>>> On 05.10.16 at 19:09,  wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
> 
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV guests the latter may point to a
> non-existing node, causing logical_pkg_ids to be set to -1.
> 
> Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
> to index its arrays and therefore in this case will point to index
> 65535 (since logical_pkg_id is a u16). This could lead to either a
> crash or may actually access random memory location.

Another clear indication that such fields should never be touched
(and hence consumers either be fixed or disabled) when running as
PV guest under Xen.

Jan


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

[Xen-devel] [OSSTEST PATCH 2/3] ms-planner: Improve an error message

[Ian Jackson]

Signed-off-by: Ian Jackson 
---
 ms-planner | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ms-planner b/ms-planner
index 8106544..22f9806 100755
--- a/ms-planner
+++ b/ms-planner
@@ -331,7 +331,7 @@ END
my ($reso, $shareix) = ($`, $1);
 
my $share= $currentshare{$reso};
-   die Dumper($reskey, $reso, $shareix,
+   die "BAD SHARE ".Dumper($reskey, $reso, $shareix,
   $plan->{Allocations}{$reskey}, $currentshare{$reso})
unless !!$share == !!$shareix;
 
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/3] ms-planner: Ignore freely-shareable resources

[Ian Jackson]

Resource shares with no resource_sharing entry are freely shareable
and do not need the planning system.  Indeed, they currently break the
planner.

Signed-off-by: Ian Jackson 
---
 ms-planner | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ms-planner b/ms-planner
index bce6e13..8106544 100755
--- a/ms-planner
+++ b/ms-planner
@@ -71,6 +71,12 @@ sub allocations ($$) {
ON owntaskid = taskid
WHERE NOT (tasks.type='magic' AND
tasks.refkey='allocatable')
+  AND NOT (resources.restype like 'share-%'
+   AND NOT EXISTS (
+ SELECT 1 FROM resource_sharing sh
+ WHERE sh.restype = substring(resources.restype from 7)
+   AND sh.resname = resources.resname
+  ))
 END
 $resources_q->execute();
while (my $row= $resources_q->fetchrow_hashref()) {
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 3/3] sg-report-flight: Avoid some warnings when reporting unexecuted jobs

[Ian Jackson]

If no steps in a job are executed, there can be a failure with a
synthetic step row, containing a stepno of ''.  This causes a perl
warning when compared with <=>:
  Argument "" isn't numeric in numeric comparison (<=>) at ./sg-report-flight 
line 774.

Fix this by replacing falseish values with 0.

Bug introduced in 0e09a8b00ec6 "sg-report-flight: Report earlier,
earlier step failures".

Signed-off-by: Ian Jackson 
---
 sg-report-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sg-report-flight b/sg-report-flight
index dbb17be..c66525b 100755
--- a/sg-report-flight
+++ b/sg-report-flight
@@ -774,7 +774,7 @@ END
 
 @failures= sort {
$a->{DurationEstimate} <=> $b->{DurationEstimate}
-   or $a->{Step}{stepno} <=> $b->{Step}{stepno}
+   or ($a->{Step}{stepno} || 0) <=> ($b->{Step}{stepno} || 0)
# stepno is sequential only within each job, so strictly
# speaking this is not really a valid comparison: we will
# usually be comparing failed steps in different jobs.  But
-- 
2.1.4


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

[Xen-devel] [ovmf baseline-only test] 67814: tolerable trouble: blocked/broken

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-xsm   3 host-install(3)   broken baseline untested
 build-i386-pvops  3 host-install(3)   broken baseline untested
 build-amd64   3 host-install(3)   broken baseline untested
 build-i3863 host-install(3)   broken baseline untested
 build-i386-xsm3 host-install(3)   broken baseline untested
 build-amd64-pvops 3 host-install(3)   broken baseline untested

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

version targeted for testing:
 ovmf e8a70885d8f34533b6dd69878fe95a249e9af086
baseline version:
 ovmf 2cf9ecd2262e4098171fa27c97b56d483f5cf3b4

Last test of basis67810  2016-10-06 04:46:28 Z0 days
Testing same since67814  2016-10-06 09:46:01 Z0 days1 attempts


People who touched revisions under test:
  Maurice Ma 

jobs:
 build-amd64-xsm  broken  
 build-i386-xsm   broken  
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 



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

broken-step build-amd64-xsm host-install(3)
broken-step build-i386-pvops host-install(3)
broken-step build-amd64 host-install(3)
broken-step build-i386 host-install(3)
broken-step build-i386-xsm host-install(3)
broken-step build-amd64-pvops host-install(3)

Push not applicable.


commit e8a70885d8f34533b6dd69878fe95a249e9af086
Author: Maurice Ma 
Date:   Tue Oct 4 17:02:24 2016 -0700

IntelFsp2Pkg/Tools: Add PE32 section rebasing support

The current SplitFspBin.py can only support TE image format
rebasing in an FSP binary. This patch adds PE32 image format
rebasing support.

Cc: Jiewen Yao 
Cc: Giri P Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma 
Reviewed-by: Satya Yarlagadda 

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

Re: [Xen-devel] [PATCH for-4.8] libelf: fix symtab/strtab loading for 32bit domains

[Jan Beulich]

>>> On 05.10.16 at 18:17,  wrote:
> On Wed, Oct 05, 2016 at 09:51:06AM -0600, Jan Beulich wrote:
>> >>> On 05.10.16 at 17:11,  wrote:
>> > +/*
>> > + * Load the section headers.
>> > + *
>> > + * NB: this _must_ be done one by one, and taking the bitness into 
>> > account,
>> > + * so that the guest can treat this as an array of type 
>> > Elf{32/64}_Shdr.
>> > + */
>> > +shdr_size = elf_64bit(elf) ? sizeof(Elf64_Shdr) : sizeof(Elf32_Shdr);
>> > +for ( i = 0; i < ELF_BSDSYM_SECTIONS; i++ )
>> > +{
>> > +if ( elf_64bit(elf) )
>> > +shdr = &header.elf_header.section[i].e64;
>> > +else
>> > +shdr = &header.elf_header.section[i].e32;
>> > +
>> > +rc = elf_load_image(elf, header_base + ehdr_size + shdr_size * i,
>> > +ELF_REALPTR2PTRVAL(shdr), shdr_size, 
>> > shdr_size);
>> 
>> You shouldn't read shdr_size bytes here, but only sizeof() ones.
> 
> Well, shdr_size is just the result of a sizeof.

Oh, I didn't even spot that - it makes things worse: The value gets
retrieved correctly earlier on.

Jan


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

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Jan Beulich]

>>> On 05.10.16 at 20:30,  wrote:
> On 30/09/2016 02:46, Jan Beulich wrote:
> On 29.09.16 at 23:42,  wrote:
>>> +#else
>>> +static void __init free_ebmalloc_unused_mem(void)
>>> +{
>>> +}
>>> +#endif
>>
>> Did you build test this for ARM? The function ought to be unused,
>> as ...
>>
>>> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
>>>  } *extra, *extra_head = NULL;
>>>  #endif
>>>
>>> +free_ebmalloc_unused_mem();
>>
>> ... the whole function here doesn't get built on ARM.
>>
>> Julien - we're still awaiting your input on general aspects here.
> 
> efi_init_memory would need to be called during Xen boot on ARM. I am not 
> sure where as I we don't yet have runtime support on ARM.
> 
> Other than that, the patch looks good to me.

But that wasn't the question. My goal is to have as little code
inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
as much of this new code as possible outside of such conditionals.
So the question really is whether that alternative approach would
be fine with you, or what problems you might see.

Jan


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

[Xen-devel] [PATCH] x86: defer not-present segment checks

[Jan Beulich]

Following on from commits 5602e74c60 ("x86emul: correct loading of
%ss") and bdb860d01c ("x86/HVM: correct segment register loading during
task switch") the point of the non-.present checks needs to be refined:
#NP (and its #SS companion), other than suggested by the various
instruction pages in Intel's SDM, gets checked for only after all type
and permission checks. The only checks getting done even later are the
64-bit specific ones for system descriptors (which we don't support
yet).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2754,14 +2754,6 @@ static int hvm_load_segment_selector(
 do {
 desc = *pdesc;
 
-/* Segment present in memory? */
-if ( !(desc.b & _SEGMENT_P) )
-{
-fault_type = (seg != x86_seg_ss) ? TRAP_no_segment
- : TRAP_stack_error;
-goto unmap_and_fail;
-}
-
 /* LDT descriptor is a system segment. All others are code/data. */
 if ( (desc.b & (1u<<12)) == ((seg == x86_seg_ldtr) << 12) )
 goto unmap_and_fail;
@@ -2806,6 +2798,14 @@ static int hvm_load_segment_selector(
 goto unmap_and_fail;
 break;
 }
+
+/* Segment present in memory? */
+if ( !(desc.b & _SEGMENT_P) )
+{
+fault_type = (seg != x86_seg_ss) ? TRAP_no_segment
+ : TRAP_stack_error;
+goto unmap_and_fail;
+}
 } while ( !(desc.b & 0x100) && /* Ensure Accessed flag is set */
   writable && /* except if we are to discard writes */
   (cmpxchg(&pdesc->b, desc.b, desc.b | 0x100) != desc.b) );
@@ -2892,12 +2892,6 @@ void hvm_task_switch(
 if ( tr.attr.fields.g )
 tr.limit = (tr.limit << 12) | 0xfffu;
 
-if ( !tr.attr.fields.p )
-{
-hvm_inject_hw_exception(TRAP_no_segment, tss_sel & 0xfff8);
-goto out;
-}
-
 if ( tr.attr.fields.type != ((taskswitch_reason == TSW_iret) ? 0xb : 0x9) )
 {
 hvm_inject_hw_exception(
@@ -2906,6 +2900,12 @@ void hvm_task_switch(
 goto out;
 }
 
+if ( !tr.attr.fields.p )
+{
+hvm_inject_hw_exception(TRAP_no_segment, tss_sel & 0xfff8);
+goto out;
+}
+
 if ( tr.limit < (sizeof(tss)-1) )
 {
 hvm_inject_hw_exception(TRAP_invalid_tss, tss_sel & 0xfff8);
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1311,7 +1311,7 @@ protmode_load_seg(
 struct { uint32_t a, b; } desc;
 uint8_t dpl, rpl;
 int cpl = get_cpl(ctxt, ops);
-uint32_t new_desc_b, a_flag = 0x100;
+uint32_t a_flag = 0x100;
 int rc, fault_type = EXC_GP;
 
 if ( cpl < 0 )
@@ -1352,13 +1352,6 @@ protmode_load_seg(
  &desc, sizeof(desc), ctxt)) )
 return rc;
 
-/* Segment present in memory? */
-if ( !(desc.b & (1u<<15)) )
-{
-fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
-goto raise_exn;
-}
-
 if ( !is_x86_user_segment(seg) )
 {
 /* System segments must have S flag == 0. */
@@ -1410,7 +1403,8 @@ protmode_load_seg(
 /* LDT system segment? */
 if ( (desc.b & (15u<<8)) != (2u<<8) )
 goto raise_exn;
-goto skip_accessed_flag;
+a_flag = 0;
+break;
 case x86_seg_tr:
 /* Available TSS system segment? */
 if ( (desc.b & (15u<<8)) != (9u<<8) )
@@ -1428,18 +1422,26 @@ protmode_load_seg(
 break;
 }
 
+/* Segment present in memory? */
+if ( !(desc.b & (1u<<15)) )
+{
+fault_type = seg != x86_seg_ss ? EXC_NP : EXC_SS;
+goto raise_exn;
+}
+
 /* Ensure Accessed flag is set. */
-new_desc_b = desc.b | a_flag;
-if ( !(desc.b & a_flag) &&
- ((rc = ops->cmpxchg(
- x86_seg_none, desctab.base + (sel & 0xfff8) + 4,
- &desc.b, &new_desc_b, 4, ctxt)) != 0) )
-return rc;
+if ( a_flag && !(desc.b & a_flag) )
+{
+uint32_t new_desc_b = desc.b | a_flag;
 
-/* Force the Accessed flag in our local copy. */
-desc.b |= a_flag;
+if ( (rc = ops->cmpxchg(x86_seg_none, desctab.base + (sel & 0xfff8) + 
4,
+&desc.b, &new_desc_b, 4, ctxt)) != 0 )
+return rc;
+
+/* Force the Accessed flag in our local copy. */
+desc.b = new_desc_b;
+}
 
- skip_accessed_flag:
 sreg->base = (((desc.b <<  0) & 0xff00u) |
   ((desc.b << 16) & 0x00ffu) |
   ((desc.a >> 16) & 0xu));


x86: defer not-present segment checks

Following on from commits 5602e74c60 ("x86emul: correct loading of
%ss") and bdb860d01c ("x86/HVM: correct segment register loading during
task switch") the point of the non-.present checks needs to be refined:
#NP (and its #SS companion), other than suggested by the various
instruction pages 

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[blallo]

Konrad Rzeszutek Wilk:

On Thu, Oct 06, 2016 at 12:59:13PM +0200, Blallo wrote:

I'm using grub2. After the lunch break I can post the full grub menu entry and 
the exact version of grub2.


Cc-ing Daniel (who is now an GRUB2 maintainer).

Is this by chance an EFI box?And you are booting using EFI GRUB2?



On 6 October 2016 12:55:16 CEST, George Dunlap  wrote:
>On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:
> On 05.10.16 at 15:32,  wrote:
>>> Here it comes xl dmesg with Xen booted with e820-verbose=true
>>
>> I have to admit that the only way I can see
>>
>> (XEN) Initial Xen-e820 RAM map:
>> (XEN)   - 0009ec00 (usable)
>> (XEN)  0009ec00 - 000a (reserved)
>> (XEN)  000e - 0010 (reserved)
>> (XEN)  0010 - 79cbe000 (usable)
>> (XEN)  79cbe000 - bcd2f000 (reserved)
>> (XEN)  bcd2f000 - bce7f000 (ACPI NVS)
>> (XEN)  bce7f000 - bceff000 (ACPI data)
>> (XEN)  bceff000 - bfa0 (reserved)
>> (XEN)  f800 - fc00 (reserved)
>> (XEN)  fec0 - fec01000 (reserved)
>> (XEN)  fed08000 - fed09000 (reserved)
>> (XEN)  fed1 - fed18000 (reserved)
>> (XEN)  fed18000 - fed19000 (reserved)
>> (XEN)  fed19000 - fed1a000 (reserved)
>> (XEN)  fed1c000 - fed2 (reserved)
>> (XEN)  fee0 - fee01000 (reserved)
>> (XEN)  ffc0 - 0001 (reserved)
>> (XEN)  0001 - 00043e60 (reserved)
>>
>> having all those reserved regions above 2Gb is for the boot
>> loader to behave oddly. Since Linux and Xen use different paths
>> in the boot loader, one can't really draw conclusions from Linux
>> getting to see a better memory map.
>
>Do you have any suggestions for how to check whether it really is the
>bootloader?
>
>Leonardo, are you using grub2 or a different bootloader?
>
> -George


Hi everybody,
I'm amazed at and grateful for your interest in my issue. It is an efi
system and the grub2 version is:

% grub-install -V
grub-install (GRUB) 2.02~beta3

The menu entry is obtained by the following script in /etc/grub.d/

/etc/grub.d/43_custom_xen

It's attached (largely mutuated by the one I use to boot the Arch Kernel
without Xen)

I do apologize for the top quoting in the preceding mail: I was on my
mobile.


Greetings

--
Leonardo
#! /bin/sh

set -e

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

Re: [Xen-devel] [PATCH Altp2m cleanup v8] Move altp2m specific functions to altp2m files.

[Jan Beulich]

>>> On 04.10.16 at 20:13,  wrote:
> v8 of this patch.
> No change since v4 since we've just focused on patch #1 in this series.

Well, not exactly: I did repeatedly mention that comments made
there should be applied to the other parts of the original series.
Anyway...

> @@ -66,6 +67,62 @@ altp2m_vcpu_destroy(struct vcpu *v)
>  }
>  
>  /*
> + * altp2m_domain_init(struct domain *d))

I don't see the point of repeating the name in the comment here. In
any event there's a stray closing parenthesis.

> + *  allocate and initialize memory for altp2m portion of domain
> + *
> + *  returns < 0 on error
> + *  returns 0 on no operation (success)
> + *  returns > 0 on success

I can't spot any case of this.

> + */
> +int
> +altp2m_domain_init(struct domain *d)
> +{
> +int rc;
> +unsigned int i;
> +
> +if ( d == NULL)

Missing blank.

> +return 0;
> +
> +if ( !hvm_altp2m_supported() )
> +return 0;
> +
> +/* Init alternate p2m data. */
> +if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> +return -ENOMEM;
> +
> +for ( i = 0; i < MAX_EPTP; i++ )
> +d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +{
> +rc = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> +if ( rc != 0 )
> +   return rc;
> +}
> +
> +d->arch.altp2m_active = 0;
> +
> +return rc;
> +}
> +
> +void
> +altp2m_domain_teardown(struct domain *d)
> +{
> +unsigned int i;
> +
> +if ( !hvm_altp2m_supported() )
> +return;
> +
> +d->arch.altp2m_active = 0;
> +
> +free_xenheap_page(d->arch.altp2m_eptp);
> +d->arch.altp2m_eptp = NULL;
> +
> +for ( i = 0; i < MAX_ALTP2M; i++ )
> +p2m_teardown(d->arch.altp2m_p2m[i]);

As said before - I think you want to switch these two steps around,
even if right now their order if benign. This would (a) mirror the
order used during init (read: doing the inverse here) and (b) make
sure code called out of p2m_teardown() could still access the other
data structure if need be.

> @@ -499,26 +500,17 @@ int hap_enable(struct domain *d, u32 mode)
> goto out;
>  }
>  
> -if ( hvm_altp2m_supported() )
> +if ( (rv = altp2m_domain_init(d)) < 0 )
>  {
> -/* Init alternate p2m data */
> -if ( (d->arch.altp2m_eptp = alloc_xenheap_page()) == NULL )
> -{
> -rv = -ENOMEM;
> -goto out;
> +for (i = 0; i < MAX_NESTEDP2M; i++) {

Coding style.

> +p2m_teardown(d->arch.nested_p2m[i]);
>  }
>  
> -for ( i = 0; i < MAX_EPTP; i++ )
> -d->arch.altp2m_eptp[i] = mfn_x(INVALID_MFN);
> -
> -for ( i = 0; i < MAX_ALTP2M; i++ )
> -{
> -rv = p2m_alloc_table(d->arch.altp2m_p2m[i]);
> -if ( rv != 0 )
> -   goto out;
> -}
> +if ( d->arch.paging.hap.total_pages != 0 )
> +hap_teardown(d, NULL);
>  
> -d->arch.altp2m_active = 0;
> +p2m_teardown(p2m_get_hostp2m(d));
> +goto out;
>  }

The portions of code removed in this hunk went into
altp2m_domain_init(). The additions, however, are unexplained in
the commit message and I'm not convinced they actually properly
deal with the previously missing error cleanup. In particular I don't
see how partial success of altp2m_domain_init() is being dealt with.

Also I continue to be of the opinion that most of the changes below
here could actually be in a separate patch.

> @@ -197,8 +197,8 @@ static void p2m_teardown_altp2m(struct domain *d)
>  if ( !d->arch.altp2m_p2m[i] )
>  continue;
>  p2m = d->arch.altp2m_p2m[i];
> -d->arch.altp2m_p2m[i] = NULL;
>  p2m_free_one(p2m);
> +d->arch.altp2m_p2m[i] = NULL;

I think I've been puzzled by this change before, and I continue to
be. If this is a necessary change for something, it should be
mentioned in the commit message.

Jan

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

Re: [Xen-devel] [Resend PATCH 1/2] Xen/Keyhandler: Make keyhandler always run in tasklet

[Jan Beulich]

>>> On 30.09.16 at 04:19,  wrote:
> @@ -87,10 +89,10 @@ void handle_keypress(unsigned char key, struct 
> cpu_user_regs *regs)
>  if ( key >= ARRAY_SIZE(key_table) || !(h = &key_table[key])->fn )
>  return;
>  
> -if ( !in_irq() || h->irq_callback )
> +if ( h->irq_callback )

Please make subject/description reflect this: You don't _always_
force the use of the tasklet.

And then I don't think we want the debugkey sysctl get processed
asynchronously - the sysctl should complete only when the key has
been fully handled, in order to not interfere with a subsequent one
(namely the one retrieving the log buffer).

Jan


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

Re: [Xen-devel] [Resend PATCH 2/2] Xen/timer: Process softirq during dumping timer info

[Jan Beulich]

>>> On 30.09.16 at 04:19,  wrote:
> --- a/xen/common/timer.c
> +++ b/xen/common/timer.c
> @@ -530,6 +530,7 @@ static void dump_timerq(unsigned char key)
>  {
>  ts = &per_cpu(timers, i);
>  
> +process_pending_softirqs();
>  printk("CPU%02d:\n", i);
>  spin_lock_irqsave(&ts->lock, flags);
>  for ( j = 1; j <= GET_HEAP_SIZE(ts->heap); j++ )

Hmm - is that enough when there are many timers on one CPU? But
well, adding something inside the lock region would of course make
things quite a bit harder, so I guess this has to be enough for now.

Jan


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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[blallo]

Konrad Rzeszutek Wilk:

On Thu, Oct 06, 2016 at 12:59:13PM +0200, Blallo wrote:

I'm using grub2. After the lunch break I can post the full grub menu entry and 
the exact version of grub2.


Cc-ing Daniel (who is now an GRUB2 maintainer).

Is this by chance an EFI box?And you are booting using EFI GRUB2?



On 6 October 2016 12:55:16 CEST, George Dunlap  wrote:
>On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:
> On 05.10.16 at 15:32,  wrote:
>>> Here it comes xl dmesg with Xen booted with e820-verbose=true
>>
>> I have to admit that the only way I can see
>>
>> (XEN) Initial Xen-e820 RAM map:
>> (XEN)   - 0009ec00 (usable)
>> (XEN)  0009ec00 - 000a (reserved)
>> (XEN)  000e - 0010 (reserved)
>> (XEN)  0010 - 79cbe000 (usable)
>> (XEN)  79cbe000 - bcd2f000 (reserved)
>> (XEN)  bcd2f000 - bce7f000 (ACPI NVS)
>> (XEN)  bce7f000 - bceff000 (ACPI data)
>> (XEN)  bceff000 - bfa0 (reserved)
>> (XEN)  f800 - fc00 (reserved)
>> (XEN)  fec0 - fec01000 (reserved)
>> (XEN)  fed08000 - fed09000 (reserved)
>> (XEN)  fed1 - fed18000 (reserved)
>> (XEN)  fed18000 - fed19000 (reserved)
>> (XEN)  fed19000 - fed1a000 (reserved)
>> (XEN)  fed1c000 - fed2 (reserved)
>> (XEN)  fee0 - fee01000 (reserved)
>> (XEN)  ffc0 - 0001 (reserved)
>> (XEN)  0001 - 00043e60 (reserved)
>>
>> having all those reserved regions above 2Gb is for the boot
>> loader to behave oddly. Since Linux and Xen use different paths
>> in the boot loader, one can't really draw conclusions from Linux
>> getting to see a better memory map.
>
>Do you have any suggestions for how to check whether it really is the
>bootloader?
>
>Leonardo, are you using grub2 or a different bootloader?



Hi everybody,
first of all, thanks for all the effort you're putting in this issue of
mine. Secondly, I apologize for the top quoting of my last email: I was
on my mobile.

Konrad, yes, I boot using efi grub2. The version is

% grub-install -V
grub-install (GRUB) 2.02~beta3

as obtained from the Arch repos.

I attach the custom /etc/grub.d/ script I use to generate the grub menu
entry for Xen booting. It is largely taken by the original one I use to
boot into the ordinary Arch kernel.


Greetings

--
Leonardo

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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[blallo]

bla...@riseup.net:

Konrad Rzeszutek Wilk:

On Thu, Oct 06, 2016 at 12:59:13PM +0200, Blallo wrote:

I'm using grub2. After the lunch break I can post the full grub menu entry and 
the exact version of grub2.


Cc-ing Daniel (who is now an GRUB2 maintainer).

Is this by chance an EFI box?And you are booting using EFI GRUB2?



On 6 October 2016 12:55:16 CEST, George Dunlap  wrote:

On Wed, Oct 5, 2016 at 3:01 PM, Jan Beulich  wrote:

On 05.10.16 at 15:32,  wrote:

Here it comes xl dmesg with Xen booted with e820-verbose=true


I have to admit that the only way I can see

(XEN) Initial Xen-e820 RAM map:
(XEN)   - 0009ec00 (usable)
(XEN)  0009ec00 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 79cbe000 (usable)
(XEN)  79cbe000 - bcd2f000 (reserved)
(XEN)  bcd2f000 - bce7f000 (ACPI NVS)
(XEN)  bce7f000 - bceff000 (ACPI data)
(XEN)  bceff000 - bfa0 (reserved)
(XEN)  f800 - fc00 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fed08000 - fed09000 (reserved)
(XEN)  fed1 - fed18000 (reserved)
(XEN)  fed18000 - fed19000 (reserved)
(XEN)  fed19000 - fed1a000 (reserved)
(XEN)  fed1c000 - fed2 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ffc0 - 0001 (reserved)
(XEN)  0001 - 00043e60 (reserved)

having all those reserved regions above 2Gb is for the boot
loader to behave oddly. Since Linux and Xen use different paths
in the boot loader, one can't really draw conclusions from Linux
getting to see a better memory map.


Do you have any suggestions for how to check whether it really is the
bootloader?

Leonardo, are you using grub2 or a different bootloader?



Hi everybody,
first of all, thanks for all the effort you're putting in this issue of
mine. Secondly, I apologize for the top quoting of my last email: I was
on my mobile.

Konrad, yes, I boot using efi grub2. The version is

% grub-install -V
grub-install (GRUB) 2.02~beta3

as obtained from the Arch repos.

I attach the custom /etc/grub.d/ script I use to generate the grub menu
entry for Xen booting. It is largely taken by the original one I use to
boot into the ordinary Arch kernel.



Sorry, forgot to attach the file :)

Here it is.

--
Leonardo




#! /bin/sh

set -e

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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[blallo]

bla...@riseup.net:

bla...@riseup.net:

Konrad Rzeszutek Wilk:

On Thu, Oct 06, 2016 at 12:59:13PM +0200, Blallo wrote:

I'm using grub2. After the lunch break I can post the full grub menu entry and 
the exact version of grub2.


Cc-ing Daniel (who is now an GRUB2 maintainer).

Is this by chance an EFI box?And you are booting using EFI GRUB2?

Hi everybody,
first of all, thanks for all the effort you're putting in this issue of
mine. Secondly, I apologize for the top quoting of my last email: I was
on my mobile.

Konrad, yes, I boot using efi grub2. The version is

% grub-install -V
grub-install (GRUB) 2.02~beta3

as obtained from the Arch repos.

I attach the custom /etc/grub.d/ script I use to generate the grub menu
entry for Xen booting. It is largely taken by the original one I use to
boot into the ordinary Arch kernel.



Sorry, forgot to attach the file :)

Here it is.



Worth to mention that, despite the "echo" in the menu entry seem to
suggest that I'm chainbooting a grsec-patched kernel and initrd, they
are not. They are indeed the ordinary Arch 4.7 kernel and initrd.
I tried to boot the grsec versios, but Xen failed.
Anyway, this is the subject of a new thread :)

Sorry for the number of emails :)


Greetings

--
Leonardo

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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[Jan Beulich]

>>> On 06.10.16 at 14:39,  wrote:
> I'm amazed at and grateful for your interest in my issue. It is an efi
> system 

In this case please retry using xen.efi instead of indirecting via
grub.efi. See http://xenbits.xen.org/docs/unstable/misc/efi.html
for what you may need to set up. If that works we can be pretty
certain that the (beta) version of grub2 you use fools up xen.gz
at least as far as the memory map goes.

Jan


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

Re: [Xen-devel] [Xen-users] xl info displays less ram than the total available

[Daniel Kiper]

On Thu, Oct 06, 2016 at 02:58:57PM +0200, bla...@riseup.net wrote:

[...]

>   multiboot /xen.gz
>   echo'Loading Xen with linux-grsec...'
>   module  /vmlinuz-linux root=/dev/mapper/leonovo-rootvol rw  
> cryptdevice=UUID=02bbde36-5fda-478f-a54f-b6f495e24961:leonovo 
> root=/dev/mapper/leonovo-rootvol
>   echo'Loading initial ramdisk to launch dom0 (linux-grsec)...'
>   module  /initramfs-linux.img

Forget about multiboot on EFI platforms. It does not work.
At least with Xen. Please load xen.efi binary directly
(as Jan suggested) or if you wish GRUB2 then you must use
relevant patches for Xen and GRUB2. Check this threads for
more details:
  - http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00299.html
  - https://lists.xen.org/archives/html/xen-devel/2016-09/msg03330.html

Daniel

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

[Xen-devel] [GIT PULL] xen: features and fixes for 4.9-rc0

[David Vrabel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Linus,

Please git pull the following tag:

 git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-4.9-rc0-tag

xen: features and fixes for 4.9-rc0

- - Switch to new CPU hotplug mechanism.
- - Support driver_override in pciback.
- - Require vector callback for HVM guests (the alternate mechanism via
  the platform device has been broken for ages).

Thanks.

David

 arch/x86/include/asm/xen/events.h  |  11 
 arch/x86/pci/xen.c |   2 +-
 arch/x86/xen/enlighten.c   |  94 -
 arch/x86/xen/grant-table.c |   2 +-
 arch/x86/xen/platform-pci-unplug.c |   2 +-
 arch/x86/xen/pmu.c |   7 ++-
 arch/x86/xen/smp.c |  53 +++--
 arch/x86/xen/smp.h |  13 +
 arch/x86/xen/time.c|   5 --
 drivers/xen/events/events_base.c   |  26 +++--
 drivers/xen/events/events_fifo.c   |  34 ---
 drivers/xen/platform-pci.c |  64 
 drivers/xen/sys-hypervisor.c   |  12 ++--
 drivers/xen/xen-pciback/pci_stub.c | 117 +
 include/linux/cpuhotplug.h |   2 +
 include/xen/xen.h  |   3 +-
 16 files changed, 208 insertions(+), 239 deletions(-)

Boris Ostrovsky (5):
  xen/x86: Move irq allocation from Xen smp_op.cpu_up()
  hotplug: Prevent alloc/free of irq descriptors during cpu up/down (again)
  xen/x86: Convert to hotplug state machine
  xen/x86: Initialize per_cpu(xen_vcpu, 0) a little earlier
  xen/x86: Update topology map for PV VCPUs

Colin Ian King (1):
  x86/xen: add missing \n at end of printk warning message

Juergen Gross (5):
  xen: rename xen_pmu_init() in sys-hypervisor.c
  xen: Make VPMU init message look less scary
  xen/pciback: simplify pcistub device handling
  xen/pciback: avoid multiple entries in slot list
  xen/pciback: support driver_override

KarimAllah Ahmed (1):
  xen: Remove event channel notification through Xen PCI platform device

Markus Elfring (1):
  xen/grant-table: Use kmalloc_array() in arch_gnttab_valloc()

Sebastian Andrzej Siewior (1):
  xen/events: Convert to hotplug state machine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX9ltNAAoJEFxbo/MsZsTRjW4H/Rl5NJOyDQ4Kl7So0ScUhB4Z
vZZfTTo9UcQZKBFNQeMgCScI69UYDXr9Uu6h/XqFEiJXzN/QvGoJkrSxYVNqQORp
O6Ncz87zccAMM5vz7VrTtob2QIpkphfRsgG1NemlUeHZHUeu3gJdsk79PIOPCd3Q
BBPK6UKycHl9gwvK3vXDQLJqa6AoqSBsy8FiSiFxWXXi/j0qP+C2dxTErHyeWhXE
bEc4Fitk7sn9ASlPxZMZ+gQNUa3lvcM63VoFi9WSivHThcQdlPwVtk7iIwwggpy7
AXeIgs5me2QjLoRGbX9vFXAqrbgALR8vE1wYc7/NemZJua6yekDh8nmgOk24wmk=
=KGnZ
-END PGP SIGNATURE-

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

Re: [Xen-devel] [PATCH] xen/x86: Update topology map for PV VCPUs

[David Vrabel]

On 05/10/16 18:09, Boris Ostrovsky wrote:
> Early during boot topology_update_package_map() computes
> logical_pkg_ids for all present processors.
> 
> Later, when processors are brought up, identify_cpu() updates
> these values based on phys_pkg_id which is a function of
> initial_apicid. On PV guests the latter may point to a
> non-existing node, causing logical_pkg_ids to be set to -1.
> 
> Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
> to index its arrays and therefore in this case will point to index
> 65535 (since logical_pkg_id is a u16). This could lead to either a
> crash or may actually access random memory location.
> 
> As a workaround, we recompute topology during CPU bringup to reset
> logical_pkg_id to a valid value.
> 
> (The reason for initial_apicid being bogus is because it is
> initial_apicid of the processor from which the guest is launched.
> This value is CPUID(1).EBX[31:24])

Applied to for-linus-4.9, thanks.

David

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

Re: [Xen-devel] New Outreachy Applicant

[Ronald Rojas]

On Wed, Oct 05, 2016 at 06:44:08PM +0100, George Dunlap wrote:
> On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap  
> wrote:
> > Thanks for this -- if you're up for it, let me see what kinds of next
> > steps you can do (obviously when you have the opportunity).
> 
> So there are a couple of things we could do next.
> 
> * If you want a simple change that you can use to get experience with
> sending patches to the list:
> 
> There are a number of instances in tools/libxl/xl_cmdimpl.c where
> where domid is listed as uint32_t (or libxl_domid), but the printf
> specifier is used as '%d'.  Change this to '%u'.
> 
> * If you want an investigation to do:
> 
> At least a couple of times I've accidentally run a golang program with
> libxl functionality on a system that wasn't running Xen (i.e., I'd
> rebooted onto Linux baremetal).  Instead of throwing an error, as you
> would expect, it crashed with a SEGV.
> 
> Try to reproduce this bug, and see if you can fix it.
> 
> * If you want to dive into the project:
> 
> I can send you my most recent version of libxl.go (which has a few
> more things implemented).  Modify it so that it builds as a package (I
> think "xenproject.org/xenlight" is probably the best name), and wire
> it into the build system in tools/golang/xenlight, and installs into
> $prefix/share/gocode/src/xenproject.org/.
> 
> The key thing with the last one is not to get too bogged down in
> systems you're not familiar with -- if you get stuck ask for help
> relatively quickly; and if it's turning into a mess, I can just do the
> Makefile side of things so that you can get to the actual Go side of
> the project.
> 
> What do you think?

I think I would prefer to do the first task and then the last task. I 
have not used stgit so I think it would be beneficial to do that first
and then I can dive into the project. 
I will probably do the first task on either Sunday or Monday, depending
on when I can start working on it. The packaging task seems much more 
difficult and I really only have a significant amount of time to work 
on this during the weekend, so it'll probably take 1 or 2 more weeks 
to complete that. 
In the meantime I think it would be helpful to look at the makefile 
of another subproject from xen so I could get some inspiration on how 
structure this new project. Is there any Makefile that you think I 
should look at? If not I'll just read through a couple of files in xen
and try to follow a similar style. 

Does that sound like a good plan?
 
Ronald Rojas

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

Re: [Xen-devel] [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for hardware domain

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 10:02:27AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne [mailto:roger@citrix.com]
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> > ; Paul Durrant ; Jan
> > Beulich ; Andrew Cooper
> > 
> > Subject: [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for
> > hardware domain
> > 
> > This is very similar to the PCI trap used for the traditional PV(H) Dom0.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Paul Durrant 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/hvm/io.c | 72
> > ++-
> >  xen/arch/x86/traps.c  | 39 ---
> >  xen/drivers/passthrough/pci.c | 39 +++
> >  xen/include/xen/pci.h |  2 ++
> >  4 files changed, 112 insertions(+), 40 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c index
> > 1e7a5f9..31d54dc 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -247,12 +247,79 @@ static int dpci_portio_write(const struct
> > hvm_io_handler *handler,
> >  return X86EMUL_OKAY;
> >  }
> > 
> > +static bool_t hw_dpci_portio_accept(const struct hvm_io_handler
> > *handler,
> > +const ioreq_t *p) {
> > +if ( (p->addr == 0xcf8 && p->size == 4) || (p->addr & 0xfffc) == 0xcfc)
> > +{
> > +return 1;
> > +}
> > +
> > +return 0;
> 
> Why not just return the value of the boolean expression?

Thanks, fixed.
 
> > +}
> > +
> > +static int hw_dpci_portio_read(const struct hvm_io_handler *handler,
> > +uint64_t addr,
> > +uint32_t size,
> > +uint64_t *data) {
> > +struct domain *currd = current->domain;
> > +
> > +if ( addr == 0xcf8 )
> > +{
> > +ASSERT(size == 4);
> > +*data = currd->arch.pci_cf8;
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +ASSERT((addr & 0xfffc) == 0xcfc);
> 
> You could do 'addr &= 3' and simplify the expressions below.

Fixed.
 
> > +size = min(size, 4 - ((uint32_t)addr & 3));
> > +if ( size == 3 )
> > +size = 2;
> > +if ( pci_cfg_ok(currd, addr & 3, size, NULL) )
> 
> Is this the right place to do the check. Can this not be done in the accept 
> op?

In the intercept op we don't know if the operation is a read or a write, and 
pci_cfg_ok seems to do more than a check, it calls pci_conf_write_intercept. 

> > +*data = pci_conf_read(currd->arch.pci_cf8, addr & 3, size);
> > +
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +static int hw_dpci_portio_write(const struct hvm_io_handler *handler,
> > +uint64_t addr,
> > +uint32_t size,
> > +uint64_t data) {
> > +struct domain *currd = current->domain;
> > +uint32_t data32;
> > +
> > +if ( addr == 0xcf8 )
> > +{
> > +ASSERT(size == 4);
> > +currd->arch.pci_cf8 = data;
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +ASSERT((addr & 0xfffc) == 0xcfc);
> 
> 'addr &= 3' again here.

Thanks.

Roger.

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

[Xen-devel] [RFC PATCH 6/8] Config.mk: expand cc-ver a bit

[Wei Liu]

... so that we can do other comparisons as well.

No functional change.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/Config.mk b/Config.mk
index 3c3ff68..a97036e 100644
--- a/Config.mk
+++ b/Config.mk
@@ -112,17 +112,17 @@ endef
 
 cc-options-add = $(foreach o,$(3),$(call cc-option-add,$(1),$(2),$(o)))
 
-# cc-ver: Check compiler is at least specified version. Return boolean 'y'/'n'.
-# Usage: ifeq ($(call cc-ver,$(CC),0x030400),y)
+# cc-ver: Check compiler against the version requirement. Return boolean 
'y'/'n'.
+# Usage: ifeq ($(call cc-ver,$(CC),-ge,0x030400),y)
 cc-ver = $(shell if [ $$((`$(1) -dumpversion | awk -F. \
-   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) -ge $$(($(2))) ]; \
+   '{ printf "0x%02x%02x%02x", $$1, $$2, $$3}'`)) $(2) $$(($(3))) ]; \
then echo y; else echo n; fi ;)
 
 # cc-ver-check: Check compiler is at least specified version, else fail.
 # Usage: $(call cc-ver-check,CC,0x030400,"Require at least gcc-3.4")
 cc-ver-check = $(eval $(call cc-ver-check-closure,$(1),$(2),$(3)))
 define cc-ver-check-closure
-ifeq ($$(call cc-ver,$$($(1)),$(2)),n)
+ifeq ($$(call cc-ver,$$($(1)),-ge,$(2)),n)
 override $(1) = echo "*** FATAL BUILD ERROR: "$(3) >&2; exit 1;
 cc-option := n
 endif
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 2/8] xen: delete gcno files in clean target

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/Makefile b/xen/Makefile
index c511330..80fff6d 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -117,6 +117,7 @@ _clean: delete-unfresh-files
$(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
$(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
SRCARCH=$(SRCARCH) clean
find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
+   find . -name "*.gcno" -exec rm -f {} \;
rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
$(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
rm -f include/asm-*/asm-offsets.h
rm -f .banner
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 3/8] xen, tools: rip out old gcov implementation

[Wei Liu]

The internal data structure and code are tied to an old gcov format.
It's easier to just redo everything from scratch.

Salvage the reusable parts: leave xen/common/gcov and an empty Makefile
there, leave gcov support in Kconfig but mark that as broken. Also
reserve the sysctl number for later use (but delete relevant sysctl
structures).

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 tools/misc/Makefile |   6 --
 tools/misc/xencov.c | 147 -
 tools/misc/xencov_split | 188 
 xen/Kconfig.debug   |   1 +
 xen/common/gcov/Makefile|   2 -
 xen/common/gcov/gcov.c  | 225 
 xen/common/sysctl.c |   7 --
 xen/include/public/gcov.h   | 115 --
 xen/include/public/sysctl.h |  38 +---
 xen/include/xen/gcov.h  |  93 --
 10 files changed, 2 insertions(+), 820 deletions(-)
 delete mode 100644 tools/misc/xencov.c
 delete mode 100755 tools/misc/xencov_split
 delete mode 100644 xen/common/gcov/gcov.c
 delete mode 100644 xen/include/public/gcov.h
 delete mode 100644 xen/include/xen/gcov.h

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 8152f7b..5ba6672 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -13,7 +13,6 @@ CFLAGS += $(CFLAGS_libxenstore)
 INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
 INSTALL_BIN-$(CONFIG_X86)  += xen-detect
 INSTALL_BIN+= xencons
-INSTALL_BIN+= xencov_split
 INSTALL_BIN += $(INSTALL_BIN-y)
 
 # Everything to be installed in regular sbin/
@@ -25,7 +24,6 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN   += xen-ringwatch
 INSTALL_SBIN   += xen-tmem-list-parse
-INSTALL_SBIN   += xencov
 INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
@@ -43,7 +41,6 @@ TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) 
$(INSTALL_PRIVBIN)
 TARGETS_COPY += xen-bugtool
 TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
-TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
 
 # Everything which needs to be built
@@ -105,7 +102,4 @@ xen-livepatch: xen-livepatch.o
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
-xencov: xencov.o
-   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
-
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
deleted file mode 100644
index 2aafb1d..000
--- a/tools/misc/xencov.c
+++ /dev/null
@@ -1,147 +0,0 @@
-/*
- * xencov: handle test coverage information from Xen.
- *
- * Copyright (c) 2013, Citrix Systems R&D Ltd.
- *
- * 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 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 
-#include 
-
-static xc_interface *gcov_xch = NULL;
-
-static void gcov_init(void)
-{
-gcov_xch = xc_interface_open(NULL, NULL, 0);
-if ( !gcov_xch )
-err(1, "opening interface");
-}
-
-int gcov_get_info(int op, struct xen_sysctl *sys, struct xc_hypercall_buffer 
*ptr)
-{
-struct xen_sysctl_coverage_op *cov;
-DECLARE_HYPERCALL_BUFFER_ARGUMENT(ptr);
-
-memset(sys, 0, sizeof(*sys));
-sys->cmd = XEN_SYSCTL_coverage_op;
-
-cov = &sys->u.coverage_op;
-cov->cmd = op;
-set_xen_guest_handle(cov->u.raw_info, ptr);
-
-return xc_sysctl(gcov_xch, sys);
-}
-
-static void gcov_read(const char *fn, int reset)
-{
-struct xen_sysctl sys;
-uint32_t total_len;
-DECLARE_HYPERCALL_BUFFER(uint8_t, p);
-FILE *f;
-int op = reset ? XEN_SYSCTL_COVERAGE_read_and_reset :
- XEN_SYSCTL_COVERAGE_read;
-
-/* get total length */
-if ( gcov_get_info(XEN_SYSCTL_COVERAGE_get_total_size, &sys, NULL) < 0 )
-err(1, "getting total length");
-total_len = sys.u.coverage_op.u.total_size;
-fprintf(stderr, "returned %u bytes\n", (unsigned) total_len);
-
-/* safe check */
-if ( total_len > 16u * 1024u * 1024u )
-errx(1, "coverage size too big %u bytes\n", total_len);
-
-/* allocate */
-p = xc_hypercal

[Xen-devel] [RFC PATCH 0/8] Rework gcov support in Xen

[Wei Liu]

The original implementation of gcov support in Xen has several
limitations:

1. The internal data structures are tied to gcc 3.4 format.
2. The sysctl interface is tied to gcc 3.4 format.
3. The gcov type definition is wrong, doesn't work with 32 bit
   hypervisor, which means arm32 wouldn't work.

Since the hypervisor interface is sysctl, we have the liberty to not
care about backward compatibility. This series completely rewrites the
gcov support inside Xen.

1. Support both gcc 3.4 and 4.7 format, configurable via Kconfig.
2. The sysctl interface is not tied to particular gcc format version.
3. Should work with arm32.

I have tested using both formats on x86. I was able to get gcov to
recognise the extracted data. I haven't really analyse the data in
detail though.

The patch series mostly consists of two parts. The meat is in the
first few patches. A few other patches are added to make available
automatic format detection.

There are still some rough edges, but I feel that this is good enough to post
so that people can review the sysctl interface.

Wei.

Wei Liu (8):
  Kconfig: add BROKEN config
  xen: delete gcno files in clean target
  xen, tools: rip out old gcov implementation
  gcov: add new interface and 3.4 and 4.7 format support
  gcov: userspace tools to extract and split gcov data
  Config.mk: expand cc-ver a bit
  Config.mk: introduce cc-ifversion
  gcov: provide the capability to select gcov format automatically

 Config.mk   |  13 +-
 tools/misc/Makefile |   2 +-
 tools/misc/xencov.c | 111 +++---
 tools/misc/xencov_split | 288 ---
 xen/Kconfig |   3 +
 xen/Kconfig.debug   |  30 +++-
 xen/Makefile|   1 +
 xen/common/gcov/Makefile|   7 +-
 xen/common/gcov/gcc_3_4.c   | 363 
 xen/common/gcov/gcc_4_7.c   | 201 
 xen/common/gcov/gcov.c  | 305 -
 xen/common/gcov/gcov.h  |  36 +
 xen/common/gcov/gcov_base.c |  64 
 xen/common/sysctl.c |   7 +-
 xen/include/public/gcov.h   | 115 --
 xen/include/public/sysctl.h |  59 ---
 xen/include/xen/gcov.h  |  94 +---
 17 files changed, 1070 insertions(+), 629 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 delete mode 100644 xen/include/public/gcov.h

-- 
2.1.4


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

[Xen-devel] [RFC PATCH 8/8] gcov: provide the capability to select gcov format automatically

[Wei Liu]

And make it the default in Kconfig.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug| 9 -
 xen/common/gcov/Makefile | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index a8eb668..03a58a7 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -38,10 +38,17 @@ config GCOV
 choice
prompt "Specify Gcov format"
depends on GCOV
-   default GCOV_FORMAT_4_7
+   default GCOV_FORMAT_AUTODETECT
---help---
The gcov format is determined by gcc version.
 
+   If unsure, choose "Autodetect".
+
+config GCOV_FORMAT_AUTODETECT
+   bool "Autodetect"
+   ---help---
+   Automatically select gcov format based on GCC version.
+
 config GCOV_FORMAT_4_7
bool "GCC 4.7 format"
---help---
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index 03ac1e5..c778334 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -1,3 +1,5 @@
 obj-y += gcov_base.o gcov.o
 obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
 obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
+obj-$(CONFIG_GCOV_FORMAT_AUTODETECT) += $(call cc-ifversion, -ge, 0x040700, \
+   gcc_4_7.o, gcc_3_4.o)
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 7/8] Config.mk: introduce cc-ifversion

[Wei Liu]

It returns different string depending on compiler version.

No user yet.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 Config.mk | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Config.mk b/Config.mk
index a97036e..d5834cd 100644
--- a/Config.mk
+++ b/Config.mk
@@ -128,6 +128,11 @@ define cc-ver-check-closure
 endif
 endef
 
+# cc-ifversion: Check compiler version and take branch accordingly
+# Usage $(call cc-ifversion, -lt, 0x040700, string_if_y, string_if_n)
+cc-ifversion = $(shell [ $(call cc-ver,$(CC),$(1),$(2)) = "y" ] \
+   && echo $(3) || echo $(4))
+
 # Require GCC v4.1+
 check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1")
 $(eval $(check-y))
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 4/8] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

A new sysctl interface for passing gcov data back to userspace. The new
interface uses a customised record file format. The new sysctl reuses
original sysctl number but renames the op to gcov_op.

Both gcc 3.4 and 4.7 format are supported. The code is rewritten so that
a new format can be easily added in the future.  Version specific code
is grouped into different files. The format one needs to use can be
picked via Kconfig. The default format is 4.7 format.

Userspace programs to handle extracted data will come in a later patch.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
---
 xen/Kconfig.debug   |  24 ++-
 xen/common/gcov/Makefile|   3 +
 xen/common/gcov/gcc_3_4.c   | 363 
 xen/common/gcov/gcc_4_7.c   | 201 
 xen/common/gcov/gcov.c  | 254 +++
 xen/common/gcov/gcov.h  |  36 +
 xen/common/gcov/gcov_base.c |  64 
 xen/common/sysctl.c |   8 +
 xen/include/public/sysctl.h |  37 -
 xen/include/xen/gcov.h  |   9 ++
 10 files changed, 993 insertions(+), 6 deletions(-)
 create mode 100644 xen/common/gcov/gcc_3_4.c
 create mode 100644 xen/common/gcov/gcc_4_7.c
 create mode 100644 xen/common/gcov/gcov.c
 create mode 100644 xen/common/gcov/gcov.h
 create mode 100644 xen/common/gcov/gcov_base.c
 create mode 100644 xen/include/xen/gcov.h

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 056d5da..a8eb668 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -30,16 +30,30 @@ config FRAME_POINTER
 
 config GCOV
bool "Gcov Support"
-   depends on BROKEN
---help---
  Enable gcov (a test coverage program in GCC) support.
 
- Currently the data structure and hypercall interface are tied
- to GCC 3.4 gcov format. You need to have a version of GCC
- that is compatible with that format to make gcov work.
-
  If unsure, say N here.
 
+choice
+   prompt "Specify Gcov format"
+   depends on GCOV
+   default GCOV_FORMAT_4_7
+   ---help---
+   The gcov format is determined by gcc version.
+
+config GCOV_FORMAT_4_7
+   bool "GCC 4.7 format"
+   ---help---
+   Select this option to use the format specified in GCC 4.7.
+
+config GCOV_FORMAT_3_4
+   bool "GCC 3.4 format"
+   ---help---
+   Select this option to use the format specified in GCC 3.4.
+
+endchoice
+
 config LOCK_PROFILE
bool "Lock Profiling"
---help---
diff --git a/xen/common/gcov/Makefile b/xen/common/gcov/Makefile
index e69de29..03ac1e5 100644
--- a/xen/common/gcov/Makefile
+++ b/xen/common/gcov/Makefile
@@ -0,0 +1,3 @@
+obj-y += gcov_base.o gcov.o
+obj-$(CONFIG_GCOV_FORMAT_3_4) += gcc_3_4.o
+obj-$(CONFIG_GCOV_FORMAT_4_7) += gcc_4_7.o
diff --git a/xen/common/gcov/gcc_3_4.c b/xen/common/gcov/gcc_3_4.c
new file mode 100644
index 000..540fbaf
--- /dev/null
+++ b/xen/common/gcov/gcc_3_4.c
@@ -0,0 +1,363 @@
+/*
+ *  This code provides functions to handle gcc's profiling data format
+ *  introduced with gcc 3.4. Future versions of gcc may change the gcov
+ *  format (as happened before), so all format-specific information needs
+ *  to be kept modular and easily exchangeable.
+ *
+ *  This file is based on gcc-internal definitions. Functions and data
+ *  structures are defined to be compatible with gcc counterparts.
+ *  For a better understanding, refer to gcc source: gcc/gcov-io.h.
+ *
+ *Copyright IBM Corp. 2009
+ *Author(s): Peter Oberparleiter 
+ *
+ *Uses gcc-internal data definitions.
+ *
+ *  Imported from Linux and modified for Xen by
+ *Wei Liu 
+ */
+
+
+#include 
+
+#include "gcov.h"
+
+#define GCOV_COUNTERS 5
+
+static struct gcov_info *gcov_info_head;
+
+/**
+ * struct gcov_fn_info - profiling meta data per function
+ * @ident: object file-unique function identifier
+ * @checksum: function checksum
+ * @n_ctrs: number of values per counter type belonging to this function
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time.
+ */
+struct gcov_fn_info
+{
+unsigned int ident;
+unsigned int checksum;
+unsigned int n_ctrs[0];
+};
+
+/**
+ * struct gcov_ctr_info - profiling data per counter type
+ * @num: number of counter values for this type
+ * @values: array of counter values for this type
+ * @merge: merge function for counter values of this type (unused)
+ *
+ * This data is generated by gcc during compilation and doesn't change
+ * at run-time with the exception of the values array.
+ */
+struct gcov_ctr_info
+{
+unsigned int num;
+gcov_type *values;
+void (*merge)(gcov_type *, unsigned int);
+};
+
+/**
+ * struct gcov_info - profiling data per object file
+ * @version: gcov version magic indicating the gcc version used for compilation
+ * @next: list head for a singly-linked

[Xen-devel] [RFC PATCH 1/8] Kconfig: add BROKEN config

[Wei Liu]

Used to hide feature that is completely broken.

Signed-off-by: Wei Liu 
---
Cc: Andrew Cooper 
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Konrad Rzeszutek Wilk 
Cc: Stefano Stabellini 
Cc: Tim Deegan 
Cc: Wei Liu 
Cc: Doug Goldstein 
---
 xen/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xen/Kconfig b/xen/Kconfig
index 0fe7a1a..942001e 100644
--- a/xen/Kconfig
+++ b/xen/Kconfig
@@ -12,6 +12,9 @@ config ARCH
string
option env="ARCH"
 
+config BROKEN
+   bool
+
 source "arch/$SRCARCH/Kconfig"
 
 config XEN_FULLVERSION
-- 
2.1.4


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

[Xen-devel] [RFC PATCH 5/8] gcov: userspace tools to extract and split gcov data

[Wei Liu]

Provide two tools: a small C program to extract data from hypervisor and
a python script to split data into multiple files.

The file xencov.c is salvaged and modified from the original xencov.c.

Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/misc/Makefile |   6 ++
 tools/misc/xencov.c | 148 
 tools/misc/xencov_split | 100 
 3 files changed, 254 insertions(+)
 create mode 100644 tools/misc/xencov.c
 create mode 100755 tools/misc/xencov_split

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 5ba6672..c029401 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -13,6 +13,7 @@ CFLAGS += $(CFLAGS_libxenstore)
 INSTALL_BIN-$(CONFIG_X86)  += xen-cpuid
 INSTALL_BIN-$(CONFIG_X86)  += xen-detect
 INSTALL_BIN+= xencons
+INSTALL-BIN+= xencov_split
 INSTALL_BIN += $(INSTALL_BIN-y)
 
 # Everything to be installed in regular sbin/
@@ -24,6 +25,7 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
 INSTALL_SBIN   += xen-ringwatch
 INSTALL_SBIN   += xen-tmem-list-parse
+INSTALL_SBIN   += xencov
 INSTALL_SBIN   += xenlockprof
 INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
@@ -41,6 +43,7 @@ TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) 
$(INSTALL_PRIVBIN)
 TARGETS_COPY += xen-bugtool
 TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
+TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
 
 # Everything which needs to be built
@@ -102,4 +105,7 @@ xen-livepatch: xen-livepatch.o
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
+xencov: xencov.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 -include $(DEPS)
diff --git a/tools/misc/xencov.c b/tools/misc/xencov.c
new file mode 100644
index 000..d83bc66
--- /dev/null
+++ b/tools/misc/xencov.c
@@ -0,0 +1,148 @@
+/*
+ * xencov: extract test coverage information from Xen.
+ *
+ * Copyright (c) 2013, 2016, Citrix Systems R&D Ltd.
+ *
+ * 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 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 
+#include 
+
+static xc_interface *xch = NULL;
+
+int gcov_sysctl(int op, struct xen_sysctl *sysctl,
+struct xc_hypercall_buffer *buf, uint32_t buf_size)
+{
+DECLARE_HYPERCALL_BUFFER_ARGUMENT(buf);
+
+memset(sysctl, 0, sizeof(*sysctl));
+sysctl->cmd = XEN_SYSCTL_gcov_op;
+
+sysctl->u.gcov_op.cmd = op;
+sysctl->u.gcov_op.size = buf_size;
+set_xen_guest_handle(sysctl->u.gcov_op.buffer, buf);
+
+return xc_sysctl(xch, sysctl);
+}
+
+static void gcov_read(const char *fn)
+{
+struct xen_sysctl sys;
+uint32_t total_len;
+DECLARE_HYPERCALL_BUFFER(uint8_t, p);
+FILE *f;
+
+if (gcov_sysctl(XEN_SYSCTL_GCOV_get_size, &sys, NULL, 0) < 0)
+err(1, "getting total length");
+total_len = sys.u.gcov_op.size;
+
+/* Shouldn't exceed a few hundred kilobytes */
+if (total_len > 8u * 1024u * 1024u)
+errx(1, "gcov data too big %u bytes\n", total_len);
+
+p = xc_hypercall_buffer_alloc(xch, p, total_len);
+if (!p)
+err(1, "allocating buffer");
+
+memset(p, 0, total_len);
+if (gcov_sysctl(XEN_SYSCTL_GCOV_read, &sys, HYPERCALL_BUFFER(p),
+total_len) < 0)
+err(1, "getting gcov data");
+
+if (!strcmp(fn, "-"))
+f = stdout;
+else
+f = fopen(fn, "w");
+
+if (!f)
+err(1, "opening output file");
+
+if (fwrite(p, 1, total_len, f) != total_len)
+err(1, "writing gcov data to file");
+
+if (f != stdout)
+fclose(f);
+
+xc_hypercall_buffer_free(xch, p);
+}
+
+static void gcov_reset(void)
+{
+struct xen_sysctl sys;
+
+if (gcov_sysctl(XEN_SYSCTL_GCOV_reset, &sys, NULL, 0) < 0)
+err(1, "resetting gcov information");
+}
+
+static void usage(int exit_code)
+{
+FILE *out = exit_code ? stderr : stdout;
+
+fprintf(out, "xencov {reset|read} []\n"
+"\treset   reset information\n"
+"\treadread information from xen to filename\n"
+"\tfilenameoptional filename (default output)\n"
+);
+exit(exit_code);
+}
+
+int main(in

Re: [Xen-devel] [RFC PATCH 2/8] xen: delete gcno files in clean target

[Wei Liu]

On Thu, Oct 06, 2016 at 03:55:25PM +0100, Andrew Cooper wrote:
> On 06/10/16 15:37, Wei Liu wrote:
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> > Cc: Wei Liu 
> > ---
> >  xen/Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/xen/Makefile b/xen/Makefile
> > index c511330..80fff6d 100644
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -117,6 +117,7 @@ _clean: delete-unfresh-files
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
> > $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
> > SRCARCH=$(SRCARCH) clean
> > find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
> > +   find . -name "*.gcno" -exec rm -f {} \;
> 
> It would be a little more efficient to add `-o -name "*.gcno"` to the
> previous find invocation than to introduce a second.
> 

Sure. I have no idea why I didn't do that.

> ~Andrew
> 
> > rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
> > $(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
> > rm -f include/asm-*/asm-offsets.h
> > rm -f .banner
> 

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

Re: [Xen-devel] [RFC PATCH 2/8] xen: delete gcno files in clean target

[Andrew Cooper]

On 06/10/16 15:37, Wei Liu wrote:
> Signed-off-by: Wei Liu 
> ---
> Cc: Andrew Cooper 
> Cc: George Dunlap 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Konrad Rzeszutek Wilk 
> Cc: Stefano Stabellini 
> Cc: Tim Deegan 
> Cc: Wei Liu 
> ---
>  xen/Makefile | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/xen/Makefile b/xen/Makefile
> index c511330..80fff6d 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -117,6 +117,7 @@ _clean: delete-unfresh-files
>   $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
>   $(MAKE) -f $(BASEDIR)/tools/kconfig/Makefile.kconfig ARCH=$(ARCH) 
> SRCARCH=$(SRCARCH) clean
>   find . \( -name "*.o" -o -name ".*.d" \) -exec rm -f {} \;
> + find . -name "*.gcno" -exec rm -f {} \;

It would be a little more efficient to add `-o -name "*.gcno"` to the
previous find invocation than to introduce a second.

~Andrew

>   rm -f include/asm $(TARGET) $(TARGET).gz $(TARGET).efi 
> $(TARGET).efi.map $(TARGET)-syms $(TARGET)-syms.map *~ core
>   rm -f include/asm-*/asm-offsets.h
>   rm -f .banner


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

[Xen-devel] [PATCH net] xen-netback: make sure that hashes are not send to unaware frontends

[Paul Durrant]

In the case when a frontend only negotiates a single queue with xen-
netback it is possible for a skbuff with a s/w hash to result in a
hash extra_info segment being sent to the frontend even when no hash
algorithm has been configured. (The ndo_select_queue() entry point makes
sure the hash is not set if no algorithm is configured, but this entry
point is not called when there is only a single queue). This can result
in a frontend that isunable to handle extra_info segments being given
such a segment, causing it to crash.

This patch fixes the problem by gating whether the extra_info is sent
not only on the presence of a s/w hash, but also on whether the hash
algorithm has been configured.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 13 ++---
 drivers/net/xen-netback/netback.c   | 23 ++-
 2 files changed, 16 insertions(+), 20 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index fb50c6d..1034139 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -149,17 +149,8 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
-   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
-
-   /* Make sure there is no hash information in the socket
-* buffer otherwise it would be incorrectly forwarded
-* to the frontend.
-*/
-   skb_clear_hash(skb);
-
-   return index;
-   }
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+   return fallback(dev, skb) % dev->real_num_tx_queues;
 
xenvif_set_skb_hash(vif, skb);
 
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 3d0c989..2cd4a8e 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,10 @@ static bool xenvif_rx_ring_slots_available(struct 
xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+   /* Assume the frontend is capable of handling the hash
+* extra_info at this point. This will only ever lead to an
+* accurate value or over-estimation.
+*/
if (skb->sw_hash)
needed++;
 
@@ -378,9 +382,8 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
*queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
-   /* xenvif_set_skb_hash() will have either set a s/w
-* hash or cleared the hash depending on
-* whether the the frontend wants a hash for this skb.
+   /* xenvif_rx_action() will have cleared any hash if
+* the frontend is not capable of handling it.
 */
.hash_present = skb->sw_hash,
};
@@ -593,6 +596,14 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
   && (skb = xenvif_rx_dequeue(queue)) != NULL) {
queue->last_rx_time = jiffies;
 
+   /* If there is no hash algorithm configured make sure
+* there is no hash information in the socket buffer
+* otherwise it would be incorrectly forwarded to the
+* frontend.
+*/
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
+   skb_clear_hash(skb);
+
XENVIF_RX_CB(skb)->meta_slots_used = xenvif_gop_skb(skb, &npo, 
queue);
 
__skb_queue_tail(&rxq, skb);
@@ -667,12 +678,6 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
}
 
if (skb->sw_hash) {
-   /* Since the skb got here via xenvif_select_queue()
-* we know that the hash has been re-calculated
-* according to a configuration set by the frontend
-* and therefore we know that it is legitimate to
-* pass it to the frontend.
-*/
if (resp->flags & XEN_NETRXF_extra_info)
extra->flags |= XEN_NETIF_EXTRA_FLAG_MORE;
else
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 10:54:54AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne [mailto:roger@citrix.com]
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> > ; Jan Beulich ; Andrew Cooper
> > ; Paul Durrant 
> > Subject: [PATCH v2 20/30] xen/x86: add the basic infrastructure to import
> > QEMU passthrough code
> > 
> > Most of this code has been picked up from QEMU and modified so it can be
> > plugged into the internal Xen IO handlers. The structure of the handlers has
> > been keep quite similar to QEMU, so existing handlers can be imported
> > without a lot of effort.
> > 
> 
> If you lifted code from QEMU then one assumes there is no problem with 
> license, but do you need to amend copyrights for any of the files where you 
> put the code?

License is GPL 2, same as Xen. For copyrights I have to admit I have no 
idea. The code is not imported as-is for obvious reasons, but the logic is 
mostly the same. I don't mind adding the copyright holders for all the code 
I've imported, they are:

Copyright (c) 2007, Neocleus Corporation.
Copyright (c) 2007, Intel Corporation.

With different authors depending on the file. Adding Lars, Ian and George 
since they have more experience with copyrights.

> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Paul Durrant 
> > ---
> >  docs/misc/xen-command-line.markdown |   8 +
> >  xen/arch/x86/hvm/hvm.c  |   2 +
> >  xen/arch/x86/hvm/io.c   | 621
> > 
> >  xen/include/asm-x86/hvm/domain.h|   4 +
> >  xen/include/asm-x86/hvm/io.h| 176 ++
> >  xen/include/xen/pci.h   |   5 +
> >  6 files changed, 816 insertions(+)
> > 
> > diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-
> > command-line.markdown
> > index 59d7210..78130c8 100644
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -670,6 +670,14 @@ Flag that makes a 64bit dom0 boot in PVH mode. No
> > 32bit support at present.
> > 
> >  Flag that makes a dom0 boot in PVHv2 mode.
> > 
> > +### dom0permissive
> > +> `= `
> > +
> > +> Default: `true`
> > +
> > +Select mode of PCI pass-through when using a PVHv2 Dom0, either
> > permissive or
> > +not.
> > +
> >  ### dtuart (ARM)
> >  > `= path [:options]`
> > 
> > diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> > index a291f82..bc4f7bc 100644
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -632,6 +632,8 @@ int hvm_domain_initialise(struct domain *d)
> >  goto fail1;
> >  }
> >  memset(d->arch.hvm_domain.io_bitmap, ~0, HVM_IOBITMAP_SIZE);
> > +INIT_LIST_HEAD(&d->arch.hvm_domain.pt_devices);
> > +rwlock_init(&d->arch.hvm_domain.pt_lock);
> >  }
> >  else
> >  d->arch.hvm_domain.io_bitmap = hvm_io_bitmap;
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> > index 31d54dc..7de1de3 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -46,6 +46,10 @@
> >  #include 
> >  #include 
> > 
> > +/* Set permissive mode for HVM Dom0 PCI pass-through by default */
> > +static bool_t opt_dom0permissive = 1;
> > +boolean_param("dom0permissive", opt_dom0permissive);
> > +
> >  void send_timeoffset_req(unsigned long timeoff)
> >  {
> >  ioreq_t p = {
> > @@ -258,12 +262,403 @@ static bool_t hw_dpci_portio_accept(const struct
> > hvm_io_handler *handler,
> >  return 0;
> >  }
> > 
> > +static struct hvm_pt_device *hw_dpci_get_device(struct domain *d)
> > +{
> > +uint8_t bus, slot, func;
> > +uint32_t addr;
> > +struct hvm_pt_device *dev;
> > +
> > +/* Decode bus, slot and func. */
> > +addr = CF8_BDF(d->arch.pci_cf8);
> > +bus = PCI_BUS(addr);
> > +slot = PCI_SLOT(addr);
> > +func = PCI_FUNC(addr);
> > +
> > +list_for_each_entry( dev, &d->arch.hvm_domain.pt_devices, entries )
> > +{
> > +if ( dev->pdev->seg != 0 || dev->pdev->bus != bus ||
> > + dev->pdev->devfn != PCI_DEVFN(slot,func) )
> > +continue;
> > +
> > +return dev;
> > +}
> > +
> > +return NULL;
> > +}
> > +
> > +/* Dispatchers */
> > +
> > +/* Find emulate register group entry */
> > +struct hvm_pt_reg_group *hvm_pt_find_reg_grp(struct hvm_pt_device
> > *d,
> > + uint32_t address)
> > +{
> > +struct hvm_pt_reg_group *entry = NULL;
> > +
> > +/* Find register group entry */
> > +list_for_each_entry( entry, &d->register_groups, entries )
> > +{
> > +/* check address */
> > +if ( (entry->base_offset <= address)
> > + && ((entry->base_offset + entry->size) > address) )
> > +return entry;
> > +}
> > +
> > +/* Group entry not found */
> > +return NULL;
> > +

Re: [Xen-devel] [PATCH v2 16/30] xen/x86: parse Dom0 kernel for PVHv2

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> +start_info.modlist_paddr = last_addr;
> +start_info.nr_modules = 1;
> +last_addr += sizeof(mod);

How can this be unconditionally 1? It is certainly possible to boot
without initrd.

Jan


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

Re: [Xen-devel] New Outreachy Applicant

[George Dunlap]

On 06/10/16 15:26, Ronald Rojas wrote:
> On Wed, Oct 05, 2016 at 06:44:08PM +0100, George Dunlap wrote:
>> On Tue, Oct 4, 2016 at 3:23 PM, George Dunlap  
>> wrote:
>>> Thanks for this -- if you're up for it, let me see what kinds of next
>>> steps you can do (obviously when you have the opportunity).
>>
>> So there are a couple of things we could do next.
>>
>> * If you want a simple change that you can use to get experience with
>> sending patches to the list:
>>
>> There are a number of instances in tools/libxl/xl_cmdimpl.c where
>> where domid is listed as uint32_t (or libxl_domid), but the printf
>> specifier is used as '%d'.  Change this to '%u'.
>>
>> * If you want an investigation to do:
>>
>> At least a couple of times I've accidentally run a golang program with
>> libxl functionality on a system that wasn't running Xen (i.e., I'd
>> rebooted onto Linux baremetal).  Instead of throwing an error, as you
>> would expect, it crashed with a SEGV.
>>
>> Try to reproduce this bug, and see if you can fix it.
>>
>> * If you want to dive into the project:
>>
>> I can send you my most recent version of libxl.go (which has a few
>> more things implemented).  Modify it so that it builds as a package (I
>> think "xenproject.org/xenlight" is probably the best name), and wire
>> it into the build system in tools/golang/xenlight, and installs into
>> $prefix/share/gocode/src/xenproject.org/.
>>
>> The key thing with the last one is not to get too bogged down in
>> systems you're not familiar with -- if you get stuck ask for help
>> relatively quickly; and if it's turning into a mess, I can just do the
>> Makefile side of things so that you can get to the actual Go side of
>> the project.
>>
>> What do you think?
> 
> I think I would prefer to do the first task and then the last task. I 
> have not used stgit so I think it would be beneficial to do that first
> and then I can dive into the project. 
> I will probably do the first task on either Sunday or Monday, depending
> on when I can start working on it. The packaging task seems much more 
> difficult and I really only have a significant amount of time to work 
> on this during the weekend, so it'll probably take 1 or 2 more weeks 
> to complete that. 
> In the meantime I think it would be helpful to look at the makefile 
> of another subproject from xen so I could get some inspiration on how 
> structure this new project. Is there any Makefile that you think I 
> should look at? If not I'll just read through a couple of files in xen
> and try to follow a similar style. 
> 
> Does that sound like a good plan?

Yes, that sounds good.

I should make it clear --  nobody *expects* work from you until such
time you're being paid. :-)  Doing small tasks (like the %d -> %u
change) helps us get a better idea what your capabilities are, and so
can be helpful for the decision-making process.  But it won't be counted
against you if you don't do any more small tasks; and it *definitely*
won't be counted against you if you don't do the large things.

I've talked about next steps for the larger project because you
expressed an interest in them.  They're there to do if you *want* to,
and if you have time, but it's on a strictly voluntary basis, and you
should absolutely prioritize your schoolwork.

Pressuring people into working for free with the vague promise of
something in the future is usually dishonest, and you should be wary of
anyone trying it on you.

Hope that makes sense. :-)

Let me take a look at a simple example you could use to "wire-in"
something to the build system.

 -George

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

Re: [Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> The logic used to setup the CPUID leaves is extremely simplistic (and
> probably wrong for hardware different than mine). I'm not sure what's the
> best way to deal with this, the code that currently sets the CPUID leaves
> for HVM guests lives in libxc, maybe moving it xen/common would be better?

Yeah, a pre-populated array of leaves certainly won't do.

> +rc = arch_set_info_hvm_guest(v, &cpu_ctx);
> +if ( rc )
> +{
> +printk("Unable to setup Dom0 BSP context: %d\n", rc);
> +return rc;
> +}
> +clear_bit(_VPF_down, &v->pause_flags);

Even if it may not matter right away, I think you want to clear this
flag later, after having completed all setup.

> +for ( i = 0; i < ARRAY_SIZE(cpuid_leaves); i++ )
> +{
> +d->arch.cpuids[i].input[0] = cpuid_leaves[i].index;
> +d->arch.cpuids[i].input[1] = cpuid_leaves[i].count;
> +if ( d->arch.cpuids[i].input[1] == XEN_CPUID_INPUT_UNUSED )
> +cpuid(d->arch.cpuids[i].input[0], &d->arch.cpuids[i].eax,
> +  &d->arch.cpuids[i].ebx, &d->arch.cpuids[i].ecx,
> +  &d->arch.cpuids[i].edx);
> +else
> +cpuid_count(d->arch.cpuids[i].input[0], 
> d->arch.cpuids[i].input[1],
> +&d->arch.cpuids[i].eax, &d->arch.cpuids[i].ebx,
> +&d->arch.cpuids[i].ecx, &d->arch.cpuids[i].edx);

Why this if/else? It is always fine to use cpuid_count().

Jan


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

Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> FWIW, I think that the current approach that I've used in order to craft the
> MADT is not the best one, IMHO it would be better to place the MADT at the
> end of the E820_ACPI region (expanding it's size one page), and modify the
> XSDT/RSDT in order to point to it, that way we avoid shadowing any other
> ACPI data that might be at the same page as the native MADT (and that needs
> to be modified by Dom0).

I agree with the idea of placing MADT elsewhere, but I don't think you
can rely on E820_ACPI to have room to grow into right after its end.

> @@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
>  #define HVM_VM86_TSS_SIZE   128
>  
>  static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
> +static unsigned int __initdata acpi_intr_overrrides = 0;
> +static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;

Pointless initializers.

> +static void __init acpi_zap_table_signature(char *name)
> +{
> +struct acpi_table_header *table;
> +acpi_status status;
> +union {
> +char str[ACPI_NAME_SIZE];
> +uint32_t bits;
> +} signature;
> +char tmp;
> +int i;
> +
> +status = acpi_get_table(name, 0, &table);
> +if ( ACPI_SUCCESS(status) )
> +{
> +memcpy(&signature.str[0], &table->signature[0], ACPI_NAME_SIZE);
> +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
> +{
> +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
> +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
> +signature.str[i] = tmp;
> +}
> +write_atomic((uint32_t*)&table->signature[0], signature.bits);
> +}
> +}

Together with moving MADT elsewhere we should also move
XSDT/RSDT, at which point we can simply avoid copying the
pointers for tables we don't want Dom0 to see (and down the
road we also have the option of adding tables).

The downside to both approaches is that this once again is a
black-listing model, i.e. new structure types we may need to
also suppress will remain visible to Dom0 until a patched
hypervisor would become available.

> +static int __init hvm_setup_acpi(struct domain *d)
> +{
> +struct vcpu *saved_current, *v = d->vcpu[0];
> +unsigned long pfn, nr_pages;
> +uint64_t size, start_addr, end_addr;
> +uint64_t madt_addr[2] = { 0, 0 };
> +struct acpi_table_header *table;
> +struct acpi_table_madt *madt;
> +struct acpi_madt_io_apic *io_apic;
> +struct acpi_madt_local_apic *local_apic;
> +acpi_status status;
> +int rc, i;
> +
> +printk("** Setup ACPI tables **\n");
> +
> +/* ZAP the HPET, SLIT, SRAT, MPST and PMTT tables. */
> +acpi_zap_table_signature(ACPI_SIG_HPET);
> +acpi_zap_table_signature(ACPI_SIG_SLIT);
> +acpi_zap_table_signature(ACPI_SIG_SRAT);
> +acpi_zap_table_signature(ACPI_SIG_MPST);
> +acpi_zap_table_signature(ACPI_SIG_PMTT);
> +
> +/* Map ACPI tables 1:1 */
> +for ( i = 0; i < d->arch.nr_e820; i++ )
> +{
> +if ( d->arch.e820[i].type != E820_ACPI &&
> + d->arch.e820[i].type != E820_NVS )
> +continue;
> +
> +pfn = PFN_DOWN(d->arch.e820[i].addr);
> +nr_pages = DIV_ROUND_UP(d->arch.e820[i].size, PAGE_SIZE);
> +
> +rc = modify_mmio_11(d, pfn, nr_pages, true);
> +if ( rc )
> +{
> +printk(
> +"Failed to map ACPI region %#lx - %#lx into Dom0 memory 
> map\n",

Please keep the format string on the printk line.

> +   pfn, pfn + nr_pages);
> +return rc;
> +}
> +}
> +/*
> + * Since most memory maps provided by hardware are wrong, make sure each
> + * top-level table is properly mapped into Dom0.
> + */

Please be more specific here - wrong in which way? Not all ACPI tables
living in one of the two E820 type regions? But see also below.

In any event you need to be more careful here: Mapping ordinary RAM
1:1 into Dom0 can't end well. Also, once working with a cloned XSDT you
won't need to cover tables here which have got hidden from Dom0.

> +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> +{
> +pfn = PFN_DOWN(acpi_gbl_root_table_list.tables[i].address);
> +nr_pages = DIV_ROUND_UP(acpi_gbl_root_table_list.tables[i].length,
> +PAGE_SIZE);
> +rc = modify_mmio_11(d, pfn, nr_pages, true);
> +if ( rc )
> +{
> +printk(
> +"Failed to map ACPI region %#lx - %#lx into Dom0 memory 
> map\n",
> +   pfn, pfn + nr_pages);
> +return rc;
> +}
> +}
> +
> +/*
> + * Special treatment for memory < 1MB:
> + *  - Copy the data in e820 regions marked as RAM (BDA, EBDA...).

Copy? What if some of it needs to get modified to interact with
firmware? I think you'd be better off mapping everything Xen
doesn't use into Dom0, and only mapping fresh RAM pages

Re: [Xen-devel] [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 11:10:44AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne [mailto:roger@citrix.com]
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> > ; Paul Durrant ; Jan
> > Beulich ; Andrew Cooper
> > 
> > Subject: [PATCH v2 22/30] xen/x86: support PVHv2 Dom0 BAR remapping
> > 
> > Add handlers to detect attemps from a PVHv2 Dom0 to change the position
> > of the PCI BARs and properly remap them.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Paul Durrant 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/hvm/io.c |   2 +
> >  xen/drivers/passthrough/pci.c | 307
> > ++
> >  xen/include/asm-x86/hvm/io.h  |  19 +++
> >  xen/include/xen/pci.h |   3 +
> >  4 files changed, 331 insertions(+)
> > 
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c index
> > 7de1de3..4db0266 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -862,6 +862,8 @@ static int hvm_pt_add_register(struct hvm_pt_device
> > *dev,  }
> > 
> >  static struct hvm_pt_handler_init *hwdom_pt_handlers[] = {
> > +&hvm_pt_bar_init,
> > +&hvm_pt_vf_bar_init,
> >  };
> > 
> >  int hwdom_add_device(struct pci_dev *pdev) diff --git
> > a/xen/drivers/passthrough/pci.c b/xen/drivers/passthrough/pci.c index
> > 6d831dd..60c9e74 100644
> > --- a/xen/drivers/passthrough/pci.c
> > +++ b/xen/drivers/passthrough/pci.c
> > @@ -633,6 +633,313 @@ static int pci_size_bar(unsigned int seg, unsigned
> > int bus, unsigned int slot,
> >  return 0;
> >  }
> > 
> > +static bool bar_reg_is_vf(uint32_t real_offset, uint32_t
> > +handler_offset) {
> > +if ( real_offset - handler_offset == PCI_SRIOV_BAR )
> > +return true;
> > +else
> > +return false;
> > +}
> > +
> 
> Return the bool expression rather than the if-then-else?

Done.
 
> > +static int bar_reg_init(struct hvm_pt_device *s,
> > +struct hvm_pt_reg_handler *handler,
> > +uint32_t real_offset, uint32_t *data) {
> > +uint8_t seg, bus, slot, func;
> > +uint64_t addr, size;
> > +uint32_t val;
> > +unsigned int index = handler->offset / 4;
> > +bool vf = bar_reg_is_vf(real_offset, handler->offset);
> > +struct hvm_pt_bar *bars = (vf ? s->vf_bars : s->bars);
> > +int num_bars = (vf ? PCI_SRIOV_NUM_BARS : s->num_bars);
> > +int rc;
> > +
> > +if ( index >= num_bars )
> > +{
> > +*data = HVM_PT_INVALID_REG;
> > +return 0;
> > +}
> > +
> > +seg = s->pdev->seg;
> > +bus = s->pdev->bus;
> > +slot = PCI_SLOT(s->pdev->devfn);
> > +func = PCI_FUNC(s->pdev->devfn);
> > +val = pci_conf_read32(seg, bus, slot, func, real_offset);
> > +
> > +if ( index > 0 && bars[index - 1].type == HVM_PT_BAR_MEM64_LO )
> > +bars[index].type = HVM_PT_BAR_MEM64_HI;
> > +else if ( (val & PCI_BASE_ADDRESS_SPACE) ==
> > PCI_BASE_ADDRESS_SPACE_IO )
> > +{
> > +bars[index].type = HVM_PT_BAR_UNUSED;
> > +}
> > +else if ( (val & PCI_BASE_ADDRESS_MEM_TYPE_MASK) ==
> > +  PCI_BASE_ADDRESS_MEM_TYPE_64 )
> > +bars[index].type = HVM_PT_BAR_MEM64_LO;
> > +else
> > +bars[index].type = HVM_PT_BAR_MEM32;
> > +
> > +if ( bars[index].type == HVM_PT_BAR_MEM32 ||
> > + bars[index].type == HVM_PT_BAR_MEM64_LO )
> > +{
> > +/* Size the BAR and map it. */
> > +rc = pci_size_bar(seg, bus, slot, func, real_offset - 
> > handler->offset,
> > +  num_bars, &index, &addr, &size);
> > +if ( rc )
> > +{
> > +printk_pdev(s->pdev, XENLOG_ERR, "unable to size BAR#%d\n",
> > +index);
> > +return rc;
> > +}
> > +
> > +if ( size == 0 )
> > +bars[index].type = HVM_PT_BAR_UNUSED;
> > +else
> > +{
> > +printk_pdev(s->pdev, XENLOG_DEBUG,
> > +"Mapping BAR#%u: %#lx size: %u\n", index, addr, 
> > size);
> > +rc = modify_mmio_11(s->pdev->domain, PFN_DOWN(addr),
> > +DIV_ROUND_UP(size, PAGE_SIZE), true);
> > +if ( rc )
> > +{
> > +printk_pdev(s->pdev, XENLOG_ERR,
> > +"failed to map BAR#%d into memory map: %d\n",
> > +index, rc);
> > +return rc;
> > +}
> > +}
> > +}
> > +
> > +*data = bars[index].type == HVM_PT_BAR_UNUSED ?
> > HVM_PT_INVALID_REG : val;
> > +return 0;
> > +}
> > +
> > +/* Only allow writes to check the size of the BARs */ static int
> > +allow_bar_write(struct hvm_pt_bar *bar, struct hvm_pt_reg *reg,
> > +   struct pci_dev *pdev, uint32_t val) {
> > +uint32_t mask;
> 

Re: [Xen-devel] [PATCH v2 19/30] xen/dcpi: add a dpci passthrough handler for hardware domain

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2076,45 +2076,6 @@ static bool_t admin_io_okay(unsigned int port, 
> unsigned int bytes,
>  return ioports_access_permitted(d, port, port + bytes - 1);
>  }
>  
> -static bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
> - unsigned int size, uint32_t *write)

I don't follow why you move this ...

> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -966,6 +966,45 @@ void pci_check_disable_device(u16 seg, u8 bus, u8 devfn)
>   PCI_COMMAND, cword & ~PCI_COMMAND_MASTER);
>  }
>  
> +bool_t pci_cfg_ok(struct domain *currd, unsigned int start,
> + unsigned int size, uint32_t *write)

here. After all ...

> +{
> +uint32_t machine_bdf;
> +
> +if ( !is_hardware_domain(currd) )
> +return 0;
> +
> +if ( !CF8_ENABLED(currd->arch.pci_cf8) )
> +return 1;
> +
> +machine_bdf = CF8_BDF(currd->arch.pci_cf8);

... concepts like I/O ports in general and ports CF8 / CFC in particular
are x86-specific. If this really needs moving at all, it should stay in an
x86-specific file.

Jan


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

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> Most of this code has been picked up from QEMU and modified so it can be
> plugged into the internal Xen IO handlers. The structure of the handlers has
> been keep quite similar to QEMU, so existing handlers can be imported
> without a lot of effort.

Without looking at the code in any detail, the question that Paul has
raised really needs to be answered first: Why pass-through code
when Dom0 has access to (almost) all devices by default anyway?

Jan


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

Re: [Xen-devel] [PATCH v2 21/30] xen/pci: split code to size BARs from pci_add_device

[Jan Beulich]

>>> On 27.09.16 at 17:57,  wrote:
> Because it's also going to be used by other code.

If you want to make use of this for general purpose sizing, simply
moving the existing code is not enough. For one I/O port BARs
don't get handled (as SR-IOV devices aren't allowed to have such).
And then I'm afraid there are a number of quirks to work around,
so some code may need to be lifted from Linux. While it may be
legitimate to not do this right here, it should be done before this
code gets used for other than SR-IOV, and having peeked into the
next patch I didn't find you doing any adjustments.

> +ret = pci_size_bar(seg, bus, slot, func, pos + PCI_SRIOV_BAR,
> +   PCI_SRIOV_NUM_BARS, &i, &addr,
> +   &pdev->vf_rlen[i]);
> +if ( ret )
> +printk_pdev(pdev, XENLOG_WARNING,
> +"failed to size SR-IOV BAR%u\n", i);
>  }
>  }

Just one remark on the code itself: With "addr" being of no interest
to this caller (afaics), I think it would be prudent to make this an
optional parameter (and pass NULL here).

Jan


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

Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Andrew Cooper]

On 06/10/16 16:40, Jan Beulich wrote:
 On 27.09.16 at 17:57,  wrote:
>> FWIW, I think that the current approach that I've used in order to craft the
>> MADT is not the best one, IMHO it would be better to place the MADT at the
>> end of the E820_ACPI region (expanding it's size one page), and modify the
>> XSDT/RSDT in order to point to it, that way we avoid shadowing any other
>> ACPI data that might be at the same page as the native MADT (and that needs
>> to be modified by Dom0).
> I agree with the idea of placing MADT elsewhere, but I don't think you
> can rely on E820_ACPI to have room to grow into right after its end.
>
>> @@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
>>  #define HVM_VM86_TSS_SIZE   128
>>  
>>  static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
>> +static unsigned int __initdata acpi_intr_overrrides = 0;
>> +static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;
> Pointless initializers.
>
>> +static void __init acpi_zap_table_signature(char *name)
>> +{
>> +struct acpi_table_header *table;
>> +acpi_status status;
>> +union {
>> +char str[ACPI_NAME_SIZE];
>> +uint32_t bits;
>> +} signature;
>> +char tmp;
>> +int i;
>> +
>> +status = acpi_get_table(name, 0, &table);
>> +if ( ACPI_SUCCESS(status) )
>> +{
>> +memcpy(&signature.str[0], &table->signature[0], ACPI_NAME_SIZE);
>> +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
>> +{
>> +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
>> +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
>> +signature.str[i] = tmp;
>> +}
>> +write_atomic((uint32_t*)&table->signature[0], signature.bits);
>> +}
>> +}
> Together with moving MADT elsewhere we should also move
> XSDT/RSDT, at which point we can simply avoid copying the
> pointers for tables we don't want Dom0 to see (and down the
> road we also have the option of adding tables).
>
> The downside to both approaches is that this once again is a
> black-listing model, i.e. new structure types we may need to
> also suppress will remain visible to Dom0 until a patched
> hypervisor would become available.

If we are providing a new XSDT/RSDT, we can have full control over the
tables dom0 sees.  Pointers to existing tables should only be entered
into the new XSDT/RSDT if Xen explicitly knows the table & version.

We will have to be diligent at keeping on top of new versions of the
ACPI spec, but everything like this should be whitelist based.  (This is
also the same model I trying to move the CPUID/MSR infrastructure towards).

~Andrew

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

Re: [Xen-devel] [PATCH v2 26/30] xen/x86: add PCIe emulation

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 11:46:25AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Roger Pau Monne [mailto:roger@citrix.com]
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau Monne
> > ; Paul Durrant ; Jan
> > Beulich ; Andrew Cooper
> > 
> > Subject: [PATCH v2 26/30] xen/x86: add PCIe emulation
> > 
> > Add a new MMIO handler that traps accesses to PCIe regions, as discovered
> > by
> > Xen from the MCFG ACPI table. The handler used is the same as the one
> > used
> > for accesses to the IO PCI configuration space.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: Paul Durrant 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > ---
> >  xen/arch/x86/hvm/io.c | 177
> > --
> >  1 file changed, 171 insertions(+), 6 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> > index 779babb..088e3ec 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -46,6 +46,8 @@
> >  #include 
> >  #include 
> > 
> > +#include "../x86_64/mmconfig.h"
> > +
> >  /* Set permissive mode for HVM Dom0 PCI pass-through by default */
> >  static bool_t opt_dom0permissive = 1;
> >  boolean_param("dom0permissive", opt_dom0permissive);
> > @@ -363,7 +365,7 @@ static int hvm_pt_pci_config_access_check(struct
> > hvm_pt_device *d,
> >  }
> > 
> >  static int hvm_pt_pci_read_config(struct hvm_pt_device *d, uint32_t addr,
> > -  uint32_t *data, int len)
> > +  uint32_t *data, int len, bool pcie)
> >  {
> >  uint32_t val = 0;
> >  struct hvm_pt_reg_group *reg_grp_entry = NULL;
> > @@ -377,7 +379,7 @@ static int hvm_pt_pci_read_config(struct
> > hvm_pt_device *d, uint32_t addr,
> >  unsigned int func = PCI_FUNC(d->pdev->devfn);
> > 
> >  /* Sanity checks. */
> > -if ( hvm_pt_pci_config_access_check(d, addr, len) )
> > +if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
> >  return X86EMUL_UNHANDLEABLE;
> > 
> >  /* Find register group entry. */
> > @@ -468,7 +470,7 @@ static int hvm_pt_pci_read_config(struct
> > hvm_pt_device *d, uint32_t addr,
> >  }
> > 
> >  static int hvm_pt_pci_write_config(struct hvm_pt_device *d, uint32_t addr,
> > -uint32_t val, int len)
> > +uint32_t val, int len, bool pcie)
> >  {
> >  int index = 0;
> >  struct hvm_pt_reg_group *reg_grp_entry = NULL;
> > @@ -485,7 +487,7 @@ static int hvm_pt_pci_write_config(struct
> > hvm_pt_device *d, uint32_t addr,
> >  unsigned int func = PCI_FUNC(d->pdev->devfn);
> > 
> >  /* Sanity checks. */
> > -if ( hvm_pt_pci_config_access_check(d, addr, len) )
> > +if ( !pcie && hvm_pt_pci_config_access_check(d, addr, len) )
> >  return X86EMUL_UNHANDLEABLE;
> > 
> >  /* Find register group entry. */
> > @@ -677,7 +679,7 @@ static int hw_dpci_portio_read(const struct
> > hvm_io_handler *handler,
> >  if ( dev != NULL )
> >  {
> >  reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
> > -rc = hvm_pt_pci_read_config(dev, reg, &data32, size);
> > +rc = hvm_pt_pci_read_config(dev, reg, &data32, size, false);
> >  if ( rc == X86EMUL_OKAY )
> >  {
> >  read_unlock(&currd->arch.hvm_domain.pt_lock);
> > @@ -722,7 +724,7 @@ static int hw_dpci_portio_write(const struct
> > hvm_io_handler *handler,
> >  if ( dev != NULL )
> >  {
> >  reg = (currd->arch.pci_cf8 & 0xfc) | (addr & 0x3);
> > -rc = hvm_pt_pci_write_config(dev, reg, data32, size);
> > +rc = hvm_pt_pci_write_config(dev, reg, data32, size, false);
> >  if ( rc == X86EMUL_OKAY )
> >  {
> >  read_unlock(&currd->arch.hvm_domain.pt_lock);
> > @@ -1002,6 +1004,166 @@ static const struct hvm_io_ops
> > hw_dpci_portio_ops = {
> >  .write = hw_dpci_portio_write
> >  };
> > 
> > +static struct acpi_mcfg_allocation *pcie_find_mmcfg(unsigned long addr)
> > +{
> > +int i;
> > +
> > +for ( i = 0; i < pci_mmcfg_config_num; i++ )
> > +{
> > +unsigned long start, end;
> > +
> > +start = pci_mmcfg_config[i].address;
> > +end = pci_mmcfg_config[i].address +
> > +  ((pci_mmcfg_config[i].end_bus_number + 1) << 20);
> > +if ( addr >= start && addr < end )
> > +return &pci_mmcfg_config[i];
> > +}
> > +
> > +return NULL;
> > +}
> > +
> > +static struct hvm_pt_device *hw_pcie_get_device(unsigned int seg,
> > +unsigned int bus,
> > +unsigned int slot,
> > +unsigned int func)
> > +{
> > +struct hvm_pt_device *dev;
> > +struct domain *d = current->domain;
> > +
> > +list_for_each_entry( 

Re: [Xen-devel] [PATCH v2 20/30] xen/x86: add the basic infrastructure to import QEMU passthrough code

[Lars Kurth]

On 06/10/2016 17:08, "Roger Pau Monne"  wrote:

>On Mon, Oct 03, 2016 at 10:54:54AM +0100, Paul Durrant wrote:
>> > -Original Message-
>> > From: Roger Pau Monne [mailto:roger@citrix.com]
>> > Sent: 27 September 2016 16:57
>> > To: xen-de...@lists.xenproject.org
>> > Cc: konrad.w...@oracle.com; boris.ostrov...@oracle.com; Roger Pau
>>Monne
>> > ; Jan Beulich ; Andrew Cooper
>> > ; Paul Durrant 
>> > Subject: [PATCH v2 20/30] xen/x86: add the basic infrastructure to
>>import
>> > QEMU passthrough code
>> > 
>> > Most of this code has been picked up from QEMU and modified so it can
>>be
>> > plugged into the internal Xen IO handlers. The structure of the
>>handlers has
>> > been keep quite similar to QEMU, so existing handlers can be imported
>> > without a lot of effort.
>> > 
>> 
>> If you lifted code from QEMU then one assumes there is no problem with
>>license, but do you need to amend copyrights for any of the files where
>>you put the code?
>
>License is GPL 2, same as Xen. For copyrights I have to admit I have no
>idea. The code is not imported as-is for obvious reasons, but the logic
>is 
>mostly the same. I don't mind adding the copyright holders for all the
>code 
>I've imported, they are:
>
>Copyright (c) 2007, Neocleus Corporation.
>Copyright (c) 2007, Intel Corporation.

For imported code, you should keep the (c) header as is, adapt the coding
style, and then add a
Copyright (c) 2016, ... if you are making significant modifications


You should also create a README.source file (or add to one in that part of
the tree), which tracks where the code came from (e.g. QEMU in this case,
referring to the source file), such that it becomes easier if someone
needs to go back at some point. The commit message should also contain
that information.

Lars

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

Re: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to PVHv2 Dom0

[Roger Pau Monne]

On Mon, Oct 03, 2016 at 11:57:13AM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> > Roger Pau Monne
> > Sent: 27 September 2016 16:57
> > To: xen-de...@lists.xenproject.org
> > Cc: boris.ostrov...@oracle.com; Roger Pau Monne 
> > Subject: [Xen-devel] [PATCH v2 28/30] xen/x86: add MSI-X emulation to
> > PVHv2 Dom0
> > 
> > This requires adding handlers to the PCI configuration space, plus a MMIO
> > handler for the MSI-X table, the PBA is left mapped directly into the guest.
> > The implementation is based on the one already found in the passthrough
> > code from QEMU.
> > 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Paul Durrant 
> > Jan Beulich 
> > Andrew Cooper 
> > ---
> >  xen/arch/x86/hvm/io.c |   2 +
> >  xen/arch/x86/hvm/vmsi.c   | 498
> > ++
> >  xen/drivers/passthrough/pci.c |   6 +-
> >  xen/include/asm-x86/hvm/io.h  |  26 +++
> >  xen/include/asm-x86/msi.h |   4 +-
> >  5 files changed, 534 insertions(+), 2 deletions(-)
> > 
> > diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
> > index 088e3ec..11b7313 100644
> > --- a/xen/arch/x86/hvm/io.c
> > +++ b/xen/arch/x86/hvm/io.c
> > @@ -867,6 +867,7 @@ static struct hvm_pt_handler_init
> > *hwdom_pt_handlers[] = {
> >  &hvm_pt_bar_init,
> >  &hvm_pt_vf_bar_init,
> >  &hvm_pt_msi_init,
> > +&hvm_pt_msix_init,
> >  };
> > 
> >  int hwdom_add_device(struct pci_dev *pdev)
> > @@ -1176,6 +1177,7 @@ void register_dpci_portio_handler(struct domain
> > *d)
> >  {
> >  handler->ops = &hw_dpci_portio_ops;
> >  register_mmio_handler(d, &pcie_mmio_ops);
> > +register_mmio_handler(d, &vmsix_mmio_ops);
> 
> Again, this is a somewhat counterintuitive place to make this call.

Done, I've moved it to hvm_domain_initialise together with the PCIe MMIO 
handlers.

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

Re: [Xen-devel] Xen Code Review Dashboard - Outreachy Program Project

[tevin.k.mallory]

Hello Lars, 
I have checked the eligibility for Outreachy program and I meet all the 
requirements. I am a 25 year-old African American male whom is a newcomer to 
the free and open source community and a resident of United States. I am not 
enrolled in school full-time and I don’t have a full time job. Therefore, I am 
available to work the full-time 40hours a week required for the internship. I 
have also never been a past participant of Outreachy programs or Google Summer 
of Code internships. Thank you for taking the time to reach out and contact me. 
 

-Tevin (with a “ T ”) Mallory 

Sent from Mail for Windows 10

From: Lars Kurth
Sent: Thursday, October 6, 2016 5:30 AM
To: tevin.k.mall...@gmail.com
Cc: Jesus M. Gonzalez-Barahona; Xen-Devel@Lists. Xenproject. Org
Subject: Re: Xen Code Review Dashboard - Outreachy Program Project

Kevin,
I just wanted to make sure that you checked you are eligible for Outreachy
Lars

On 6 Oct 2016, at 02:08, tevin.k.mall...@gmail.com wrote:

Hi Jesus,
 
10:30am EST on Friday the 7th sounds great. I’ll get started on my task and 
bring any questions I may have to the IRC meeting. I’ll keep Friday clear just 
incase we need to adjust our meeting time to included Lars as well.  
Thank you for your time. 
 
-Tevin K. Mallory  
 

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

[Xen-devel] [OSSTEST PATCH 2/2] mg-allocate: Provide command line way to list allocated resources

[Ian Jackson]

Freely shareable resources don't appear in the plan, and the plan is
not always immediately updated, and is generally not always a
convenient interface.  Provide a command line way to list allocated
resources.

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

diff --git a/mg-allocate b/mg-allocate
index ef57bb8..3b3fa72 100755
--- a/mg-allocate
+++ b/mg-allocate
@@ -2,6 +2,7 @@
 #
 # usage:
 #  ./mg-allocate [] ...
+#  ./mg-allocate [-l] [-l] [-l]
 #
 #  syntax:
 #   [!][/][/]  type defaults to 'host'
@@ -45,6 +46,15 @@
 #  as if they were free.  This allows us to steal
 #  resources from other tasks.  May be repeated.
 #
+#   -l | --listInstead of allocating (or deallocating), simply list
+#  allocated resources.
+#
+#  -l: resources owned by this task (this user).
+#  -ll: resources owned by all tasks
+#  -lll: include "administrative" resources
+#
+#  Not compatible with other options.
+#
 #  must exist (and be in a format valid for OSSTEST_TASK).
 
 # This is part of "osstest", an automated testing framework for Xen.
@@ -77,6 +87,7 @@ $|=1;
 
 our $tid;
 our %magictask;
+our $list_only;
 our $donate_spec;
 our $donate_taskid;
 our @steal_specs;
@@ -491,6 +502,9 @@ while (@ARGV && $ARGV[0] =~ m/^[-0-9]/) {
  1);
 } elsif (s/^\-U/-/) {
 $ENV{OSSTEST_RESOURCE_PRIORITY} //= -100;
+} elsif (s/^\-l/-/ || s/^--list$/--/) {
+   $list_only++;
+   die "-l may be repeated only thrice\n" if $list_only > 3;
 } elsif (s/^--as$/-/) {
die "--as needs task\n" unless @ARGV;
$ENV{OSSTEST_TASK} = shift @ARGV;
@@ -506,6 +520,84 @@ while (@ARGV && $ARGV[0] =~ m/^[-0-9]/) {
 }
 }
 
+$list_only = 1 if !@ARGV;
+
+if ($list_only) {
+die "-l (--list) specified (or implied) with other options or arguments\n"
+   if $donate_spec || @steal_specs || @ARGV || $duration;
+
+db_retry($dbh_tests, [], sub {
+   my $resbasetypeqtxt = prepare(fetchrow_hashref()) {
+   if ($c->{resbasetype} ne $resbasetype) {
+   printf "= %s =\n", $c->{resbasetype};
+   $resbasetype = $c->{resbasetype};
+   }
+   if ($c->{owntaskid} ne $tid) {
+   my ($spec,$desc) = task_spec_desc($c);
+   printf "-- %s -- %s --\n", $spec, $desc;
+   $tid = $c->{owntaskid};
+   }
+   printf " %-40s ", (join "/", map { $c->{$_} }
+ qw(restype resname shareix));
+   my $restype = $c->{restype};
+   my $resname = $c->{resname};
+   if ($restype eq 'share-host') {
+   print "S/$resname";
+   } elsif ($restype eq 'host') {
+   print "$resname";
+   } elsif ($restype eq 'share-flight') {
+   print "F/$resname";
+   }
+   print "\n";
+   }
+db_retry_abort();
+});
+exit 0;
+}
+
 if (defined $donate_spec) {
 die "--donate specified with deallocations, too confusing\n"
if grep { m/^!/ } @ARGV;
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/2] Executive: Break out task_spec_desc (no functional change)

[Ian Jackson]

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

diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index 137eb44..14f75b3 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -45,7 +45,7 @@ BEGIN {
 $VERSION = 1.00;
 @ISA = qw(Exporter);
 @EXPORT  = qw(grabrepolock_reexec
-  findtask findtask_spec @all_lock_tables
+  task_spec_desc findtask findtask_spec @all_lock_tables
   restrictflight_arg restrictflight_cond
   report_run_getinfo report_altcolour
   report_altchangecolour
@@ -524,6 +524,20 @@ END
 
 our $taskid;
 
+sub task_spec_desc ($) {
+my ($row) = @_; # NB row maybe modifed, to fill in username and comment
+# => ($newspec, $desc);
+
+foreach my $k (qw(username comment)) {
+next if defined $row->{$k};
+$row->{$k}= "[no $k]";
+}
+
+my $newspec = "$row->{taskid} $row->{type} $row->{refkey}";
+my $desc = "$row->{username} $row->{comment}";
+return ($newspec,$desc);
+}
+
 sub findtask_spec ($$) {
 my ($spec, $why) = @_;
 
@@ -556,13 +570,8 @@ END
 die "task $what dead" unless $row->{live};
 $q->finish();
 
-foreach my $k (qw(username comment)) {
-next if defined $row->{$k};
-$row->{$k}= "[no $k]";
-}
-
-my $newspec= "$row->{taskid} $row->{type} $row->{refkey}";
-logm("${why}task $newspec: $row->{username} $row->{comment}");
+my ($newspec, $desc) = task_spec_desc($row);
+logm("${why}task $newspec: $desc");
 
 $taskid= $row->{taskid};
 
-- 
2.1.4


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

[Xen-devel] [PATCH v1 0/1] xen/arm: Disable the Cortex-a53-edac

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

The Cortex-A53 EDAC (Error Detection And Correction) Linux driver
uses the implementation defined CPUMERRSR register.
Xen traps but does not yet handle accesses to this reg so dom0 panics
on an undefined instruction at boot.

For Xen-4.8, this patchs disables the A53 EDAC module by removing it from
the device tree.

For Xen-4.9 we may want to allow dom0 to access these regs.

Comments welcome!

Best regards,
Edgar

Edgar E. Iglesias (1):
  xen/arm: Disable the Cortex-a53-edac

 xen/arch/arm/domain_build.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.5.0


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

[Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Disable the Cortex-a53-edac. Xen currently does not yet
handle reads/writes to the implementation defined CPUMERRSR
register.

Signed-off-by: Edgar E. Iglesias 
---
 xen/arch/arm/domain_build.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ce97359..e8a400c 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1188,6 +1188,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 DT_MATCH_COMPATIBLE("arm,psci-1.0"),
 DT_MATCH_COMPATIBLE("arm,cortex-a7-pmu"),
 DT_MATCH_COMPATIBLE("arm,cortex-a15-pmu"),
+DT_MATCH_COMPATIBLE("arm,cortex-a53-edac"),
 DT_MATCH_COMPATIBLE("arm,armv8-pmuv3"),
 DT_MATCH_PATH("/cpus"),
 DT_MATCH_TYPE("memory"),
-- 
2.5.0


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

Re: [Xen-devel] Clarification regarding MEM_ACCESS_* flags usage

[Tamas K Lengyel]

On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru 
wrote:

> On 10/05/2016 11:54 PM, Julien Grall wrote:
> >
> >
> > On 05/10/2016 13:23, Tamas K Lengyel wrote:
> >> Hi Julien,
> >> It is expected that certain combinations of mem_access flags will put
> >> the domain into unstable condition, resulting in a crash or a hang. As
> >> Razvan mentioned, on x86 we can end up triggering EPT misconfiguration
> >> with the wrong set of flags. The user of the API is expected to know
> >> what he/she is doing in this regard, we don't do any enforcements or
> >> sanity checking on the Xen side.
> >>
> >> As to the issue you describe, indeed that can happen. If the user marks
> >> a pagetable area non-readable/non-writable and the way ARM reports a
> >> walk for an instruction-fetch as an execute violation when it traps, it
> >> will hang the VM in a continuous violation state as no execute-violation
> >> was requested to be triggered on the gfn by the user. There are other
> >> situations where this can happen, as on ARM there is no such thing as
> >> execute-only memory, so any time the user requests memory to be
> >> execute-only or writable-executable will lead to problems like this -
> >> instruction fetch violation when the user only requested
> >> read-violations. But again, the users are expected to know what they are
> >> doing and perform their own sanity checks as appropriate.
> >
> > I think the problem I described is neither the fault of the user,
> > neither a misconfiguration of the page table. Let me clarify it.
> >
> > The user can purposefully restrict the access to stage-1 page table to
> > detect when the OS is modifying them. By side effect, this will also
> > impact the page table walker.
> >
> > A prefetch abort (e.g when an error occurs when the processor is trying
> > to load the instruction) can either occur during a stage-1 page table
> > walk (e.g the underlying memory of stage-1 page table has been
> > protected) or because the permission in the stage-2 entry has been
> > restricted.
> >
> > In the case of the latter, this will always be because the memory is not
> > executable. However, for the former may happen if the page table walker
> > (i.e the MMU) is reading/writing the entry.
> >
> > However, Xen ARM today is always considering that a prefetch abort will
> > happen because it was not possible to execute the instruction.
> >
> > I requested clarification about the flags because we need to fix this
> > valid issue. From the usage on ARM and in the vm event app, it is not
> > clear how those flags should be used.
>
> I understand. FWIW, I find it better to have the most precise type of
> event sent, i.e. in your case if the application gets a read-only page
> fault event it would then be able to do something about it (for example,
> lift the restrictions on the page), whereas if it would get an execute
> denied event in this case, allowing execution on that page would not
> solve the issue and leave the guest in an infinite loop, as you say. The
> problem here is that the application never gets a chance to do the right
> thing even if it wants to, and is capable of that.
>
> So I'm all for properly differentiating between these two cases, unless
> the ARM SDM disagrees or there's some reason why this is unfeasible.
>

The issue I see here is that if the CPU itself traps as an instruction
fetch violation because the pagetable was unreadable, then sending out a
vm_event with a MEM_ACCESS_* type other then what the hardware reported
will complicate things significantly. It would require the mem_access
system in Xen to further check when there is no violating mem_access X
setting found to check if all pages used for translating the PC were
readable or not. This would require us to walk through the currently active
pagetable and check if any of those have a restricted mem_access setting,
and if one is found send out a notification with MEM_ACCESS_R flag set.
This is pretty complicated considering all the different page types the OS
could use. I rather not move this logic into Xen but have the user
implement it if it is needed. For example, if the user wants to make the
pages where pagetables reside unreadable with mem_access then would also
have to mark all pages contained in that pagetable non-executable with
mem_access. So since the current setup can be worked with, I rather not
complicated the Xen side and just have it accurately report the trap as it
received it from the CPU itself.

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

Re: [Xen-devel] [OSSTEST PATCH 2/2] libvirt: Do not attempt save/restore when migration not advertised

[Ian Jackson]

Martin Kletzander writes ("Re: [OSSTEST PATCH 2/2] libvirt: Do not attempt 
save/restore when migration not advertised"):
> Well then, unfortunately you do.
> 
> Also, looking at how the code is structured, if you have live migration
> but don't have save/restore, you won't have  there
> at all.

Right.  OK, thanks.  I will add the patch below to my osstest queue.

Ian.

From 5330ff9222e4e611505149945eef7dc074b4f9b5 Mon Sep 17 00:00:00 2001
In-Reply-To: <20161006104255.GP16414@wheatley>
References: <20161006104255.GP16414@wheatley>
From: Ian Jackson 
Date: Thu, 6 Oct 2016 17:38:29 +0100
Subject: [OSSTEST PATCH 3/2] libvirt: Check 
/capabilities/host/migration_features/live for live migration
Cc: libvir-l...@redhat.com

libvirt is capable of advertising this separately from
/capabilities/host/migration_features, so if save/restore is supported
but live migration is not, this will do the right thing.

We would have preferred libvirt to advertise
  /capabilities/host/migration_features/save
or something, but it doesn't right now, so we continue to use
  /capabilities/host/migration_features
to detect save/restore support.

If libvirt changes its feature presentation, then at some future point
we should change osstest too.

Signed-off-by: Ian Jackson 
CC: Martin Kletzander 
CC: Jim Fehlig 
---
 Osstest/Toolstack/libvirt.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index 250fe47..81e724d 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -93,7 +93,8 @@ sub migrate_check ($$) {
 # local migration is not supported
 $rc = 1;
 } else {
-   $rc = $self->check_capability('/capabilities/host/migration_features');
+   $rc = $self->check_capability
+   ('/capabilities/host/migration_features/live');
 }
 
 logm("rc=$rc");
-- 
2.1.4


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

Re: [Xen-devel] Clarification regarding MEM_ACCESS_* flags usage

[Julien Grall]

On 06/10/2016 09:39, Tamas K Lengyel wrote:



On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru
mailto:rcojoc...@bitdefender.com>> wrote:

On 10/05/2016 11:54 PM, Julien Grall wrote:
>
>
> On 05/10/2016 13:23, Tamas K Lengyel wrote:
>> Hi Julien,
>> It is expected that certain combinations of mem_access flags will put
>> the domain into unstable condition, resulting in a crash or a
hang. As
>> Razvan mentioned, on x86 we can end up triggering EPT
misconfiguration
>> with the wrong set of flags. The user of the API is expected to know
>> what he/she is doing in this regard, we don't do any enforcements or
>> sanity checking on the Xen side.
>>
>> As to the issue you describe, indeed that can happen. If the user
marks
>> a pagetable area non-readable/non-writable and the way ARM reports a
>> walk for an instruction-fetch as an execute violation when it
traps, it
>> will hang the VM in a continuous violation state as no
execute-violation
>> was requested to be triggered on the gfn by the user. There are other
>> situations where this can happen, as on ARM there is no such thing as
>> execute-only memory, so any time the user requests memory to be
>> execute-only or writable-executable will lead to problems like this -
>> instruction fetch violation when the user only requested
>> read-violations. But again, the users are expected to know what
they are
>> doing and perform their own sanity checks as appropriate.
>
> I think the problem I described is neither the fault of the user,
> neither a misconfiguration of the page table. Let me clarify it.
>
> The user can purposefully restrict the access to stage-1 page table to
> detect when the OS is modifying them. By side effect, this will also
> impact the page table walker.
>
> A prefetch abort (e.g when an error occurs when the processor is
trying
> to load the instruction) can either occur during a stage-1 page table
> walk (e.g the underlying memory of stage-1 page table has been
> protected) or because the permission in the stage-2 entry has been
> restricted.
>
> In the case of the latter, this will always be because the memory
is not
> executable. However, for the former may happen if the page table
walker
> (i.e the MMU) is reading/writing the entry.
>
> However, Xen ARM today is always considering that a prefetch abort
will
> happen because it was not possible to execute the instruction.
>
> I requested clarification about the flags because we need to fix this
> valid issue. From the usage on ARM and in the vm event app, it is not
> clear how those flags should be used.

I understand. FWIW, I find it better to have the most precise type of
event sent, i.e. in your case if the application gets a read-only page
fault event it would then be able to do something about it (for example,
lift the restrictions on the page), whereas if it would get an execute
denied event in this case, allowing execution on that page would not
solve the issue and leave the guest in an infinite loop, as you say. The
problem here is that the application never gets a chance to do the right
thing even if it wants to, and is capable of that.

So I'm all for properly differentiating between these two cases, unless
the ARM SDM disagrees or there's some reason why this is unfeasible.


The issue I see here is that if the CPU itself traps as an instruction
fetch violation because the pagetable was unreadable, then sending out a
vm_event with a MEM_ACCESS_* type other then what the hardware reported
will complicate things significantly. It would require the mem_access
system in Xen to further check when there is no violating mem_access X
setting found to check if all pages used for translating the PC were
readable or not. This would require us to walk through the currently
active pagetable and check if any of those have a restricted mem_access
setting, and if one is found send out a notification with MEM_ACCESS_R
flag set. This is pretty complicated considering all the different page
types the OS could use. I rather not move this logic into Xen but have
the user implement it if it is needed. For example, if the user wants to
make the pages where pagetables reside unreadable with mem_access then
would also have to mark all pages contained in that pagetable
non-executable with mem_access. So since the current setup can be worked
with, I rather not complicated the Xen side and just have it accurately
report the trap as it received it from the CPU itself.


You still don't get my point. The fact that the traps is an instruction 
fetch violation is valid because the stage-1 page table walk happened 
whilst the processor was trying to fetch the instruction.


If the trap happened because of the stage-1 page table walk fault, the 
t

Re: [Xen-devel] Clarification regarding MEM_ACCESS_* flags usage

[Tamas K Lengyel]

On Thu, Oct 6, 2016 at 11:10 AM, Julien Grall  wrote:

>
>
> On 06/10/2016 09:39, Tamas K Lengyel wrote:
>
>>
>>
>> On Thu, Oct 6, 2016 at 3:59 AM, Razvan Cojocaru
>> mailto:rcojoc...@bitdefender.com>> wrote:
>>
>> On 10/05/2016 11:54 PM, Julien Grall wrote:
>> >
>> >
>> > On 05/10/2016 13:23, Tamas K Lengyel wrote:
>> >> Hi Julien,
>> >> It is expected that certain combinations of mem_access flags will
>> put
>> >> the domain into unstable condition, resulting in a crash or a
>> hang. As
>> >> Razvan mentioned, on x86 we can end up triggering EPT
>> misconfiguration
>> >> with the wrong set of flags. The user of the API is expected to
>> know
>> >> what he/she is doing in this regard, we don't do any enforcements
>> or
>> >> sanity checking on the Xen side.
>> >>
>> >> As to the issue you describe, indeed that can happen. If the user
>> marks
>> >> a pagetable area non-readable/non-writable and the way ARM reports
>> a
>> >> walk for an instruction-fetch as an execute violation when it
>> traps, it
>> >> will hang the VM in a continuous violation state as no
>> execute-violation
>> >> was requested to be triggered on the gfn by the user. There are
>> other
>> >> situations where this can happen, as on ARM there is no such thing
>> as
>> >> execute-only memory, so any time the user requests memory to be
>> >> execute-only or writable-executable will lead to problems like
>> this -
>> >> instruction fetch violation when the user only requested
>> >> read-violations. But again, the users are expected to know what
>> they are
>> >> doing and perform their own sanity checks as appropriate.
>> >
>> > I think the problem I described is neither the fault of the user,
>> > neither a misconfiguration of the page table. Let me clarify it.
>> >
>> > The user can purposefully restrict the access to stage-1 page table
>> to
>> > detect when the OS is modifying them. By side effect, this will also
>> > impact the page table walker.
>> >
>> > A prefetch abort (e.g when an error occurs when the processor is
>> trying
>> > to load the instruction) can either occur during a stage-1 page
>> table
>> > walk (e.g the underlying memory of stage-1 page table has been
>> > protected) or because the permission in the stage-2 entry has been
>> > restricted.
>> >
>> > In the case of the latter, this will always be because the memory
>> is not
>> > executable. However, for the former may happen if the page table
>> walker
>> > (i.e the MMU) is reading/writing the entry.
>> >
>> > However, Xen ARM today is always considering that a prefetch abort
>> will
>> > happen because it was not possible to execute the instruction.
>> >
>> > I requested clarification about the flags because we need to fix
>> this
>> > valid issue. From the usage on ARM and in the vm event app, it is
>> not
>> > clear how those flags should be used.
>>
>> I understand. FWIW, I find it better to have the most precise type of
>> event sent, i.e. in your case if the application gets a read-only page
>> fault event it would then be able to do something about it (for
>> example,
>> lift the restrictions on the page), whereas if it would get an execute
>> denied event in this case, allowing execution on that page would not
>> solve the issue and leave the guest in an infinite loop, as you say.
>> The
>> problem here is that the application never gets a chance to do the
>> right
>> thing even if it wants to, and is capable of that.
>>
>> So I'm all for properly differentiating between these two cases,
>> unless
>> the ARM SDM disagrees or there's some reason why this is unfeasible.
>>
>>
>> The issue I see here is that if the CPU itself traps as an instruction
>> fetch violation because the pagetable was unreadable, then sending out a
>> vm_event with a MEM_ACCESS_* type other then what the hardware reported
>> will complicate things significantly. It would require the mem_access
>> system in Xen to further check when there is no violating mem_access X
>> setting found to check if all pages used for translating the PC were
>> readable or not. This would require us to walk through the currently
>> active pagetable and check if any of those have a restricted mem_access
>> setting, and if one is found send out a notification with MEM_ACCESS_R
>> flag set. This is pretty complicated considering all the different page
>> types the OS could use. I rather not move this logic into Xen but have
>> the user implement it if it is needed. For example, if the user wants to
>> make the pages where pagetables reside unreadable with mem_access then
>> would also have to mark all pages contained in that pagetable
>> non-executable with mem_access. So since the current setup can be worked
>> with, I rather not complicated th

[Xen-devel] Want to update osstest to use Linux 4.1 but it does not work :-/

[Ian Jackson]

The main Xen Project osstest instance is still using Linux 3.14 which
is ancient.  It would be nice to update to something newer.  4.1 was
suggested.

However, I went to look at the most recent test results for the Linux
4.1 branch.  It can't start guests reliably:

osstest service owner writes ("[linux-4.1 test] 101004: tolerable FAIL - 
PUSHED"):
> flight 101004 linux-4.1 real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/101004/
> 
> Failures :-/ but no regressions.
> 
> Tests which are failing intermittently (not blocking):
>  test-armhf-armhf-xl-credit2  11 guest-start   fail in 101001 pass in 101004
>  test-armhf-armhf-libvirt-qcow2  6 xen-boot fail pass in 101001
>  test-amd64-amd64-xl  19 guest-start/debian.repeat  fail pass in 101001
>  test-amd64-amd64-libvirt-xsm 17 guest-start/debian.repeat fail pass in 101001

The Debian guest (jessie, seems to be running systemd) prints:

[0m] A start job is running for dev-xvda1.device (1min 29s / 1min 30s)
[0m] Timed out waiting for device dev-xvda1.device.

We also have this:

[ 3.447337] systemd-udevd[952]: segfault at 5644df9ce000 ip
7f34a1d99761 sp 7ffc65870538 error 4 in
libblkid.so.1.1.0[7f34a1d77000+3b000]

Here are the full logs.

http://logs.test-lab.xenproject.org/osstest/logs/101004/test-amd64-amd64-xl/info.html

Is there a known problem with Linux 4.1 as a PV disk backend ?

Ian.

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

[Xen-devel] [OSSTEST PATCH] make-flight: XTF: honour $bfi (ie build flight)

[Ian Jackson]

If make-flight is run with a $buildflight argument, it does not create
any build jobs.  The test jobs are supposed to refer to the build jobs.

This was not done correctly for the XTF tests.  Add the missing ${bfi}.

Signed-off-by: Ian Jackson 
CC: Wei Liu 
---
 make-flight | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 9b47999..3a95cfa 100755
--- a/make-flight
+++ b/make-flight
@@ -454,7 +454,7 @@ do_xtf_tests () {
   for i in `seq 1 5`; do
   job_create_test test-xtf-$xenarch-$dom0arch-$i \
test-xtf xl $xenarch $dom0arch\
-xtfbuildjob=build-$xenarch-xtf   \
+xtfbuildjob=${bfi}build-$xenarch-xtf   \
 xen_boot_append='hvm_fep=1'  \
 all_hostflags=$most_hostflags,diverse-xtf-x86
   done
-- 
2.1.4


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

[Xen-devel] [qemu-mainline test] 101309: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 qemuua65b6f27ce65e2e4f771f69d549ffa455a4d543a
baseline version:
 qemuubbc4c3f4f3c624e2de64fdcb79f4dd8c1a508e9d

Last test of basis   101269  2016-10-05 01:18:25 Z1 days
Testing same since   101309  2016-10-06 10:12:36 Z0 days1 attempts


People who touched revisions under test:
  Dr. David Alan Gilbert 
  Peter Maydell 
  Wanpeng Li 

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

Re: [Xen-devel] [OSSTEST PATCH] make-flight: XTF: honour $bfi (ie build flight)

[Wei Liu]

On Thu, Oct 06, 2016 at 07:41:45PM +0100, Ian Jackson wrote:
> If make-flight is run with a $buildflight argument, it does not create
> any build jobs.  The test jobs are supposed to refer to the build jobs.
> 
> This was not done correctly for the XTF tests.  Add the missing ${bfi}.
> 
> Signed-off-by: Ian Jackson 
> CC: Wei Liu 

Reviewed-by: Wei Liu 

> ---
>  make-flight | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/make-flight b/make-flight
> index 9b47999..3a95cfa 100755
> --- a/make-flight
> +++ b/make-flight
> @@ -454,7 +454,7 @@ do_xtf_tests () {
>for i in `seq 1 5`; do
>job_create_test test-xtf-$xenarch-$dom0arch-$i \
> test-xtf xl $xenarch $dom0arch\
> -xtfbuildjob=build-$xenarch-xtf   \
> +xtfbuildjob=${bfi}build-$xenarch-xtf   \
>  xen_boot_append='hvm_fep=1'  \
>  all_hostflags=$most_hostflags,diverse-xtf-x86
>done
> -- 
> 2.1.4
> 

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

[Xen-devel] [xen-unstable test] 101310: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-raw   9 debian-di-install fail in 101300 pass in 101310
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 101300 pass in 101310
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 
guest-localmigrate/x10 fail in 101300 pass in 101310
 test-amd64-i386-libvirt  11 guest-startfail pass in 101300

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

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

version targeted for testing:
 xen  9f5eff08a6a6f58645fb48382c843973674042c9
baseline version:
 xen  40277cded320efa32b86c0c9f01e33145eab5ee4

Last test of basis   101250  2016-10-04 02:36:21 Z2 days
Failing since101254  2016-10-04 13:18:43 Z2 days4 attempts
Testing same since   101300  2016-10-06 03:27:49 Z0 days2 attempts


People who touched revisions under test:
  Anthony PERARD 
  casionwoo 
  Ian Jackson 
  Jan Beulich 
  JEUNGWOO, YOO 
  Wei Liu 

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

Re: [Xen-devel] [PATCH v2 net-next 0/7] xen-netback: guest rx side refactor

[David Miller]

From: Paul Durrant 
Date: Tue, 4 Oct 2016 10:29:11 +0100

> This series refactors the guest rx side of xen-netback:
> 
> - The code is moved into its own source module.
> 
> - The prefix variant of GSO handling is retired (since it is no longer
>   in common use, and alternatives exist).
> 
> - The code is then simplified and modifications made to improve
>   performance.
> 
> v2:
> - Rebased onto refreshed net-next

Series applied, thanks.

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

[Xen-devel] [qemu-mainline test] 101317: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 101309
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101309
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101309

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   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-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass

version targeted for testing:
 qemuue902754e3d0890945ddcc1b33748ed73762ddb8d
baseline version:
 qemuua65b6f27ce65e2e4f771f69d549ffa455a4d543a

Last test of basis   101309  2016-10-06 10:12:36 Z0 days
Testing same since   101317  2016-10-06 19:45:44 Z0 days1 attempts


People who touched revisions under test:
  Avinesh Kumar 
  David Gibson 
  Felipe Franciosi 
  Greg Kurz 
  Laurent Vivier 
  Nikunj A Dadhania 
  Peter Maydell 
  Rajalakshmi Srinivasaraghavan 
  Ravi Bangoria 
  Thomas Huth 

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

[Xen-devel] [qemu-mainline baseline-only test] 67834: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl  11 guest-start fail baseline untested
 test-armhf-armhf-libvirt 11 guest-start fail baseline untested
 test-amd64-amd64-i386-pvgrub 10 guest-start fail baseline untested
 test-amd64-amd64-amd64-pvgrub 10 guest-startfail baseline untested
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail baseline 
untested

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-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-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   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-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass

version targeted for testing:
 qemuua65b6f27ce65e2e4f771f69d549ffa455a4d543a
baseline version:
 qemuubbc4c3f4f3c624e2de64fdcb79f4dd8c1a508e9d

Last test of basis67806  2016-10-05 18:15:13 Z1 days
Testing same since67834  2016-10-06 19:45:23 Z0 days1 attempts


People who touched revisions under test:
  Dr. David Alan Gilbert 
  Peter Maydell 
  Wanpeng Li 

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

Re: [Xen-devel] [PATCH net] xen-netback: make sure that hashes are not send to unaware frontends

[David Miller]

From: Paul Durrant 
Date: Thu, 6 Oct 2016 15:47:10 +0100

> In the case when a frontend only negotiates a single queue with xen-
> netback it is possible for a skbuff with a s/w hash to result in a
> hash extra_info segment being sent to the frontend even when no hash
> algorithm has been configured. (The ndo_select_queue() entry point makes
> sure the hash is not set if no algorithm is configured, but this entry
> point is not called when there is only a single queue). This can result
> in a frontend that isunable to handle extra_info segments being given
> such a segment, causing it to crash.
> 
> This patch fixes the problem by gating whether the extra_info is sent
> not only on the presence of a s/w hash, but also on whether the hash
> algorithm has been configured.
> 
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 

This doesn't apply cleanly to the current 'net' tree, please respin.

Thanks.

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