Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]

[Jan Beulich]

>>> Ian Jackson  04/14/16 8:12 PM >>>
>Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:
>> And btw., considering that Konrad has already posted a revert patch,
>> and I have ack-ed that one, this could now go in right away (and the
>> discussion could either be settled or start over).
>
>I don't see that patch you describe in my inbox, but maybe I have
>missed it.

Patches 1 and 2 of the most recent v8.1 series.

>If that reversion is proposed, following a request for a 2nd/3rd
>opinion from me and George, and given the discussion so far, I think
>that patch ought to have been CC'd to me and George.
>
>I don't think it would be appropriate to commit a revert except as
>part of a series which introduces an replacement way of providing the
>needed functionality - at least, enough functionality that in practice
>a plausibly long build-id can be retrieved.

For one, the revert wouldn't revert that functionality, as that didn't even go
in yet.

>If you want the original reverted, I think it is up to you, Jan, to
>provide (or procure) such a replacement.

And with that (albeit not just because of it not being in yet at all), I don't 
see
why this would be the case. I think there's some general disagreement here,
which with the hackathon around the corner we probably should just get
sorted out in person there.

Jan


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

Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.

[Jan Beulich]

>>> George Dunlap  04/15/16 1:23 PM >>>
>On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich  wrote:
>>>Sure, mistakes happen; but I hope it's not being to controversial to
>>>say that in general, the procedure should be arranged such that the
>>>person who makes the mistake is the one who has to do deal with the
>>>most consequences from the mistake, not the people around him.  I
>>>mean, if you asked a bartender for a bottle of beer, and after he'd
>>>already opened it you said, "Oh sorry, I actually wanted a cider", it
>>>would be fair enough for the bartender to ask you to pay for the beer,
>>>rather than eating it*, wouldn't it? :-)
>>
>> Sure. And I think that's what I've done.

To be fair, I think this was too broad a statement: I had indeed asked Konrad
to collect the replacement ack. Yet on second thought I really can't see
what's wrong with withdraing an ack - just like a patch can be withdrawn, that
should be possible for an ack too. And if the patch has already gone in, no
matter whether the patch itself or the ack got withdrawn, the patch imo should
then be reverted. I agree that's not something spelled out anywhere, so my
opinion here is based on solely general considerations of mine.

>When Konrad asked for further input on the patch and then didn't get
>any in a few days, you responded, "It looks like it will have to be
>reverted then." As I've said, I think that's the wrong way round --
>it's not that the commit is reverted unless someone else acks it; it's
>that the commit stays unless someone acks your reversion.  If you had
>posted a patch (probably RFC) requesting to revert the change in favor
>of a different one, then it would have been more obvious that the
>burden was on you to get the reversion Acked, rather than on Konrad to
>get the existing commit re-acked.

I agree on the process aspect (albeit among the few cases where things
needed reverting, I think there was a non-negligible amount of such where
the revert was requested quite informally), but that's relatively moot with me
not agreeing on the premises it builds upon.

>>>Well Ian and I have already given our opinions -- Ian thinks moving to
>>>a clean interface and deprecating the old one is in general a good
>>>thing, and doesn't look too painful in this case.  I don't really see
>>>a problem with using a large fixed size, but I don't fundamentally see
>>>a problem with moving to a new clean interface either.  Given that
>>>Andy has a strong aversion to the way things are, if you had only a
>>>mild distaste rather than a  strong objection to the new hypercall, it
>>>would probably make sense to go with the new hypercall.
>>>
>>>If you do have a strong objection, then maybe we could try to convince
>>>Andy to accept adding subops with different calling semantics to the
>>>existing hypercall.  But I would still think the burden of persuasion
>>>is primarily on you.
>>
>>  I do not have a strong objection, or else I would have converted my ack
>> into a nak instead of just withdrawing it. I just dislike the duplication, 
>> and
>> hence I'm not happy with me now being the one having approved it to go
>> in. Hence the request for a replacement ack (or whatever else referee
>> decision).
>
>Well this makes it sound like you're saying that you were asking us to
>save you from having to appear to have approved of a patch that you
>didn't like.  Which doesn't sound very nice. :-)

I'm sorry if it's being understood that way. My intention really was to avoid
the revert in case a replacement ack can be obtained. Otherwise, following
my way of thinking outlined above, the patch should have been reverted
right away. Yet I seem to be the only one here thinking this way...

>But I wonder if something slightly different is going on.  Forgive me
>for trying to guess at motivations here, but I think it may be
>helpful.  I'm often in the situation where my gut objects to a patch
>that other coders I respect think is fine; and often a few years down
>the road, I look back and agree that it's fine as well.  In other
>words, I know that sometimes my own objections turn out to be
>unreasonable; and that in any case, working with other people you
>sometimes have to compromise.  But on the other hand, I've also had
>the experience of giving in and accepting patches that later I regret,
>or that other people come back and say, "This was a terrible idea, you
>should have stood up for it more."
>
>So in the moment -- particularly, as you say, under time pressure --
>how do you determine if objecting to the patch is being unreasonable
>and obstructive, or if assenting to the patch is failing your duty as
>a maintainer to prevent bad code, and is a decision you'll regret
>later?
>
>Was it perhaps actually the case that your internal reasoning was
>along the lines of, "Actually, adding a new hypercall seems like a bad
>idea.  But since Andrew strongly disagrees, maybe I'm being
>unreasonable.  Or, maybe it really is a bad idea and he's being
>unreasonable.  W

Re: [Xen-devel] [PATCH v3 1/5] xentrace: Common Support for get_pg_owner/put_pg_owner on ARM and x86

[Jan Beulich]

>>> Ben Sanda  04/14/16 10:03 PM >>>
>>> +void put_pg_owner(struct domain *pg_owner) {
>>> +rcu_unlock_domain(pg_owner);
>>> +}
> I cannot see why this then can't just become an inline function.
>
>I investigated this but making put_pg_owner() static inline creates a
>circular dependency on rcu_unlock_domain(), which is also a static
>inline function. The two functions are in different header files and
>this creates a dependency on the one header being included by the
>other, which, depending on how C files include them, creates an
>implicit definition error by the compiler. For now I will leave the
>function as is.

While generally macros are undesirable in place of inline functions,
with the type checking aspect not being relevant here (both functions
have identically typed parameters), using a #define here instead of an
out of line call to a function which does nothing other than adjust the
preempt count seems warranted if the include dependency can't be
addressed in a satisfactory manner.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 91545
 build-i386-rumpuserxen6 xen-buildfail   like 91545
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 91545
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 91545
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 91545
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91545
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 91545

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-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-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f3a7ca02400d1c416e97451b4aebfaf608fc8192
baseline version:
 xen  f3a7ca02400d1c416e97451b4aebfaf608fc8192

Last test of basis91660  2016-04-16 17:39:07 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16908 days0 attempts

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-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops   

Re: [Xen-devel] [PATCH v8.1] xSplice v1 design and implementation.

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/15/16 2:55 AM >>>
>On Thu, Apr 14, 2016 at 09:17:14AM -0600, Jan Beulich wrote:
>> >>> Andrew Cooper  04/14/16 5:14 PM >>>
>> >On 14/04/16 15:26, Konrad Rzeszutek Wilk wrote:
>> >> @@ -312,8 +307,8 @@ struct xsplice_patch_func {
>> >>  };  
>> >>  
>> >>  
>> >> -The size of the structure is 64 bytes or 52 bytes if compiled under 
>> >> 32-bit
>> >> -hypervisors.
>> >> +The size of the structure is 64 bytes on 64-bit hypervisors. It will be
>> >> +52 on 32-bit hypervisors.
>> >
>> >I would go further an explicitly declare this API unstable, as patches
>> >must be built against an exact hypervisor source.  This also gives us
>> >leaway in the future.
>
>It will present a problem to the xsplice-tools.git which are outside
>the tree. Right now they have their own header file (which mirrors this
>one). But if we make it unstable and start mucking around then folks
>using the tool would need to pass parameters for 'what version' is
>this.
>
>I would rather not have this happen - and now that we do not need
>the #ifdef BITS_PER_LONG we can also remove the __XEN__ conditional.

I don't think that's the case: The mere use of pointer types in there makes it
so the type shouldn't be exposed to entities executing outside of hypervisor
context.

Jan


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

Re: [Xen-devel] [PATCH v8.1 04/27] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/15/16 4:29 AM >>>
>On Thu, Apr 14, 2016 at 10:36:46AM -0600, Jan Beulich wrote:
>> >>> Konrad Rzeszutek Wilk  04/14/16 12:05 AM >>>
>> > @@ -460,6 +461,11 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
>> > u_sysctl)
>> > ret = tmem_control(&op->u.tmem_op);
>> > break;
>> > 
>> > +case XEN_SYSCTL_xsplice_op:
>> > +ret = xsplice_op(&op->u.xsplice);
>> > +copyback = (ret == -ENOSYS || ret == -EOPNOTSUPP) ? 0 : 1;
>> 
>> Why use a conditional expression here when its condition already is a 
>> boolean one
>> just needing negating?
>
>B/c I thought you would want it this way.
>
>I changed it to
>
>466 if ( ret != -ENOSYS && ret != -EOPNOTSUPP )
>467 copyback = 1;

That's fine too.

>But I don't think this what you meant by 'negating'? As in:
>
>copyback = !rc ?
>
>But one of the subops returns the number of items and we definitly
>want copyback=1 for that.

What I mean with "negating" was

copyback = (ret != -ENOSYS && ret != -EOPNOTSUPP);

>> > +spin_lock(&payload_lock);
>> > +
>> > +found = find_payload(n);
>> > +if ( IS_ERR(found) )
>> > +{
>> > +rc = PTR_ERR(found);
>> > +goto out;
>> > +}
>> > +else if ( found )
>> > +{
>> > +rc = -EEXIST;
>> > +goto out;
>> > +}
>> > +
>> > +data = xzalloc(struct payload);
>> 
>> I generally advocate for not doing allocations with locks held, and I don't 
>> think
>> it would severely complicate the code here doing so.
>
>I can certainly unlock and then lock again (when adding
>it to the list).

That would create a race again afaict. Instead what I have been trying to hint
at is that the allocation should be done before taking the lock, freeing the 
object
again if in the end it turned out it's not going to be needed. Hence the 
referral to
possibly complicating the code.

Jan


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

Re: [Xen-devel] x86 patch ping

[Jan Beulich]

>>> Andrew Cooper  04/15/16 7:12 PM >>>
>On 08/04/16 13:10, Jan Beulich wrote:
>> http://lists.xen.org/archives/html/xen-devel/2016-03/msg02167.html
>> (with the 1st patch having gone in already)
>
>Apologies for the delay on this.  I now have results in.
>
>The 64bit performance hit is within the noise (as expected) but sadly,

Thanks - at least something good here.

>the performance impact of v3 on 32bit guests is even worse than previous
>rounds.
>
>From lmbench:
>
>mmap() has an 85% latency hit.
>pagefaults (on /local/scratch) gets a 78% hit.
>pipe latency gets a 58% hit.
>process fork()/exit() gets a 47% hit.
>
>In each of these cases, that is about 20% worse that previous measurements.

I have to admit that I have a _very_ hard time seeing why the most recent
adjustments would have made things worse.

>As it currently stands, we really can't justify taking the fix in its
>current form.

Which raises the question of alternatives. Fact is that we're having a problem
to solve, and no solution getting things back to architecturally correct 
behavior
other than this one. Which makes me wonder whether we shouldn't take the
change irrespective of its performance effect, provided that performance goes
back up if people use "no-smep" and/or "no-smap" as appropriate. (Specifying
to use these options to restore architecturally correct behavior is, imo, not an
acceptable thing to do, but suggesting their use to get performance back for
those who value security less than performance imo is an option.)

Jan


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

[Xen-devel] [linux-3.18 test] 91675: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-win7-amd64 20 leak-check/check fail in 91420 REGR. 
vs. 86513

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 90979 
pass in 91675
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail in 90979 
pass in 91675
 test-amd64-amd64-xl-qemuu-win7-amd64 20 leak-check/check fail in 90979 pass in 
91675
 test-armhf-armhf-xl-arndale   6 xen-boot   fail in 90979 pass in 91675
 test-armhf-armhf-xl-vhd   9 debian-di-install  fail in 90979 pass in 91675
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail in 91420 pass in 91675
 test-armhf-armhf-xl-rtds 11 guest-startfail in 91420 pass in 91675
 test-armhf-armhf-xl-rtds 16 guest-start.2   fail pass in 90979
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop   fail pass in 91420

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 86513
 build-i386-rumpuserxen6 xen-buildfail   like 86513
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86513
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86513

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

version targeted for testing:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis86513  2016-03-17 21:21:40 Z   30 days
Testing same since89247  2016-04-06 22:15:59 Z   10 days9 attempts


People who touched revisions under test:
  Alex Deucher 
  Avery Pennarun 
  Catalin Marinas 
  Chris Bainbridge 
  Emmanuel Grumbach 
  Felix Fietkau 
  Grygorii Strashko 
  James Hogan 
  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 91479
 build-i386-libvirt5 libvirt-build fail REGR. vs. 91479
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 91479

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z2 days
Failing since 91597  2016-04-16 04:20:46 Z1 days2 attempts
Testing same since91722  2016-04-17 04:32:32 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Erik Skultety 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard W.M. Jones 

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  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-armhf-armhf-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] [PATCH for-4.7 0/5] build: fixes for building Xen with clang

[Jan Beulich]

>>> Roger Pau Monne  04/15/16 8:29 PM >>>
>I've also noticed that Xen always sets "-no-integrated-as" when using clang,
>because previous versions (<3.8.0) didn't support .code16/.code32/.code64
>in inline asm. This is solved at least in version 3.8.0 (haven't tested
>older versions). The problem now to switch to the integrated clang assembler
>is the usage of the rept instructions in some files in conjunction with
>labels:
>
>entry.S:403:15: error: unexpected token in '.rept' directive
>.rept 48 -((.-compat_hypercall_table)/8)
>^
>entry.S:405:14: error: unmatched '.endr' directive
>.endr
>[...]
>The entry.S file this errors come from is xen/arch/x86/x86_64/compat/entry.S
>
>If anyone has any clever ideas about how to replace those instructions with
>compatible ones, I'm more than willing to listen. AFAICT, this is the last
>issue that prevents Xen from switch to the integrated clang assembler on
>newer clang versions.

The question first of all is: What is it that is "unexpected" to their built-in
assembler? If they don't tolerate expressions involving the subtraction of
two addresses (or even expressions at all), then I'm afraid there's not much
we can do other than wait for them making their assembler more flexible.

Jan


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

[Xen-devel] [xen-unstable-coverity test] 91751: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed
version targeted for testing:
 xen  f3a7ca02400d1c416e97451b4aebfaf608fc8192
baseline version:
 xen  ac703c285a4fbfcb85c19364ea0c67780bf16c2d

Last test of basis91245  2016-04-13 09:56:13 Z4 days
Testing same since91751  2016-04-17 09:26:14 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Ian Jackson 
  Jan Beulich 
  Olaf Hering 
  Roger Pau Monne 
  Roger Pau Monné 
  Vitaly Kuznetsov 
  Wei Liu 

jobs:
 coverity-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=xen-unstable-coverity
+ revision=f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
xen-unstable-coverity f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ branch=xen-unstable-coverity
+ revision=f3a7ca02400d1c416e97451b4aebfaf608fc8192
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.6-testing
+ '[' xf3a7ca02400d1c416e97451b4aebfaf608fc8192 = 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/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 44336

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

version targeted for testing:
 qemuuc7b45f12828c1ba7105dbc029c63d7de68eaa91c
baseline version:
 qemuubc8995cafa0c36b9e4be682e9a60d59484b33500

Last test of basis44336  2016-04-16 05:49:17 Z1 days
Testing same since44340  2016-04-17 02:01:58 Z0 days1 attempts


People who touched revisions under test:
  Artyom Tarasenko 
  Marc-André Lureau 
  Mark Cave-Ayland 
  Markus Armbruster 
  Peter Maydell 

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

[Xen-devel] The order of contents saved in "/var/run/xenstored/db" is reversed

[Sunguodong]

Hi all,

I have a question about oxenstored, please help if someone knows.
Oxenstored saves store information to "/var/run/xenstored/db" when it quits, 
but the contents is reversed.
For example, 
before restart oxenstored, the output of 'xenstore-ls -f' is:
...
/local/domain/0/memory/target = "8388608"
/local/domain/0/memory/static-max = "4294967292"
/local/domain/0/memory/freemem-slack = "0"
...
after restart oxenstored, the output is:
...
/local/domain/0/memory/freemem-slack = "0"
/local/domain/0/memory/static-max = "4294967292"
/local/domain/0/memory/target = "8388608"
...

I found why when I read the code:
When a new element is added to node list, it is added to the head of the list, 
so the newest element will always be saved first, and then restored first.

Then question is:
1.What is the reason for this, is this done on purpose?
2.What is the impact of doing so if I save the store information in the 
original order(first come first saved, and first saved first restored ^_^)?

Looking forward to your reply, thank you!

Regards,
Jason

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

[Xen-devel] Xen Memory de-duplication

[Maryam Masoudian]

Hi,

I have some questions about memory de-duplication in xen.
Firstly, I want to know if this feature is available in Xen .
If it is, how can I enable it in Xen 4.6 HVM mode.

Also, if I want to do some logging or other action whenever a COW happens
on shared memory, where should I add my codes? (is the /xen/memshr folder
containing the memory de-duplication code)?

Regards,
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Memory de-duplication

[Wei Liu]

On Sun, Apr 17, 2016 at 03:55:00PM +0430, Maryam Masoudian wrote:
> Hi,
> 
> I have some questions about memory de-duplication in xen.
> Firstly, I want to know if this feature is available in Xen .
> If it is, how can I enable it in Xen 4.6 HVM mode.
> 
> Also, if I want to do some logging or other action whenever a COW happens
> on shared memory, where should I add my codes? (is the /xen/memshr folder
> containing the memory de-duplication code)?
> 

I don't seem to find xen/memshr, only tools/memshr -- that's the tool
for manipulating memory sharing. You might want to look into hypervsior
code arch/x86/mm/mem_sharing.c.

Note that memory sharing is not actively maintained so you might
encounter all sorts of problems and on your own to solve them.

Wei.

> Regards,

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


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

Re: [Xen-devel] The order of contents saved in "/var/run/xenstored/db" is reversed

[Wei Liu]

On Sun, Apr 17, 2016 at 10:28:24AM +, Sunguodong wrote:
> Hi all,
> 
> I have a question about oxenstored, please help if someone knows.
> Oxenstored saves store information to "/var/run/xenstored/db" when it quits, 
> but the contents is reversed.
> For example, 
> before restart oxenstored, the output of 'xenstore-ls -f' is:
> ...
> /local/domain/0/memory/target = "8388608"
> /local/domain/0/memory/static-max = "4294967292"
> /local/domain/0/memory/freemem-slack = "0"
> ...
> after restart oxenstored, the output is:
> ...
> /local/domain/0/memory/freemem-slack = "0"
> /local/domain/0/memory/static-max = "4294967292"
> /local/domain/0/memory/target = "8388608"
> ...
> 
> I found why when I read the code:
> When a new element is added to node list, it is added to the head of the 
> list, so the newest element will always be saved first, and then restored 
> first.
> 
> Then question is:
> 1.What is the reason for this, is this done on purpose?
> 2.What is the impact of doing so if I save the store information in the 
> original order(first come first saved, and first saved first restored ^_^)?
> 

Why do you care much about what order they appear in the output? I don't
think the tools should make assumption on the order they appear and the
order doesn't matter.

In any case, if you need to have consistent view:

 xenstore-ls -f | sort

Wei.


> Looking forward to your reply, thank you!
> 
> Regards,
> Jason
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 15 guest-localmigrate   fail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 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-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 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-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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 pas

Re: [Xen-devel] Xen Memory de-duplication

[Maryam Masoudian]

Well, yes memshr is at tools/memshr .
Then , after modifying this c file, should I compile Xen from scratch?
And is the sharing feature enabled by default in Xen 4.6 ? If not, how to
enable it?


On Sun, Apr 17, 2016 at 4:45 PM, Wei Liu  wrote:

> On Sun, Apr 17, 2016 at 03:55:00PM +0430, Maryam Masoudian wrote:
> > Hi,
> >
> > I have some questions about memory de-duplication in xen.
> > Firstly, I want to know if this feature is available in Xen .
> > If it is, how can I enable it in Xen 4.6 HVM mode.
> >
> > Also, if I want to do some logging or other action whenever a COW happens
> > on shared memory, where should I add my codes? (is the /xen/memshr folder
> > containing the memory de-duplication code)?
> >
>
> I don't seem to find xen/memshr, only tools/memshr -- that's the tool
> for manipulating memory sharing. You might want to look into hypervsior
> code arch/x86/mm/mem_sharing.c.
>
> Note that memory sharing is not actively maintained so you might
> encounter all sorts of problems and on your own to solve them.
>
> Wei.
>
> > Regards,
>



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

Re: [Xen-devel] Xen Memory de-duplication

[Wei Liu]

Please don't top post.

On Sun, Apr 17, 2016 at 06:28:15PM +0430, Maryam Masoudian wrote:
> Well, yes memshr is at tools/memshr .
> Then , after modifying this c file, should I compile Xen from scratch?

No, you only need to compile the tools -- or, just that tool.

> And is the sharing feature enabled by default in Xen 4.6 ? If not, how to
> enable it?
> 

The hypervisor code is compiled in by default on x86_64 in 4.6.

Wei.

> 
> On Sun, Apr 17, 2016 at 4:45 PM, Wei Liu  wrote:
> 
> > On Sun, Apr 17, 2016 at 03:55:00PM +0430, Maryam Masoudian wrote:
> > > Hi,
> > >
> > > I have some questions about memory de-duplication in xen.
> > > Firstly, I want to know if this feature is available in Xen .
> > > If it is, how can I enable it in Xen 4.6 HVM mode.
> > >
> > > Also, if I want to do some logging or other action whenever a COW happens
> > > on shared memory, where should I add my codes? (is the /xen/memshr folder
> > > containing the memory de-duplication code)?
> > >
> >
> > I don't seem to find xen/memshr, only tools/memshr -- that's the tool
> > for manipulating memory sharing. You might want to look into hypervsior
> > code arch/x86/mm/mem_sharing.c.
> >
> > Note that memory sharing is not actively maintained so you might
> > encounter all sorts of problems and on your own to solve them.
> >
> > Wei.
> >
> > > Regards,
> >
> 
> 
> 
> >
> > > ___
> > > Xen-devel mailing list
> > > Xen-devel@lists.xen.org
> > > http://lists.xen.org/xen-devel
> >
> >

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 619e6cf19fa1ab98878972e109d0c579f37388cd
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  131 days
Failing since 65593  2015-12-08 23:44:51 Z  130 days  149 attempts
Testing same since91514  2016-04-15 14:53:46 Z2 days4 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

[Xen-devel] [linux-3.18 bisection] complete test-amd64-i386-xl-qemut-win7-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-win7-amd64
testid leak-check/check

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

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  a6f2cdb633bf519244a16674031b8034b581ba7f
  Bug not present: d0540cbd4a9065b043ae5a26bb28b798f77a085b
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/91781/


  commit a6f2cdb633bf519244a16674031b8034b581ba7f
  Author: Paul Durrant 
  Date:   Thu Mar 17 13:50:39 2016 +0100
  
  x86/hvm/viridian: keep APIC assist page mapped...
  
  ... for the lifetime of the domain.
  
  If Xen is to make use of the APIC assist enlightenment then a persistent
  mapping needs to be kept, rather than the temporary one which is currently
  used only to initialize the page content.
  
  This patch also adds a comment block at the top of the source with
  information on the latest version of the spec. from Microsoft and the
  current URL where it may be found.
  
  Signed-off-by: Paul Durrant 
  Reviewed-by: Andrew Cooper 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-3.18/test-amd64-i386-xl-qemut-win7-amd64.leak-check--check
 --summary-out=tmp/91781.bisection-summary --basis-template=86513 
--blessings=real,real-bisect linux-3.18 test-amd64-i386-xl-qemut-win7-amd64 
leak-check/check
Searching for failure / basis pass:
 91420 fail [host=italia1] / 86513 [host=chardonnay0] 85493 [host=fiano0] 66698 
[host=huxelrebe1] template as basis? using template as basis.
Failure / basis pass flights: 91420 / 86513
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: linux 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
Basis pass d439e869d612dd7a338ac75a4afc3646a5e67370 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
efc904263f483026672a5cdf3ccf9be8c4fdaa31
Generating revisions with ./adhoc-revtuple-generator  
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git#d439e869d612dd7a338ac75a4afc3646a5e67370-b36eba9b4dd4344ed51b8f644049aeac606ccff2
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-21f6526d1da331611ac5fe12967549d1a04e149b
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e
 
git://xenbits.xen.org/xen.git#efc904263f483026672a5cdf3ccf9be8c4fdaa31-a6f2cdb633bf519244a16674031b8034b581ba7f
Loaded 2002 nodes in revision graph
Searching for test results:
 86513 [host=chardonnay0]
 89247 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 89339 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 90846 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 90979 fail b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 91131 pass d439e869d612dd7a338ac75a4afc3646a5e67370 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
efc904263f483026672a5cdf3ccf9be8c4fdaa31
 91130 blocked b36eba9b4dd4344ed51b8f644049aeac606ccff2 
c530a

[Xen-devel] [linux-mingo-tip-master test] 91725: regressions - FAIL

[osstest service owner]

flight 91725 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/91725/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-xsm  15 guest-localmigratefail REGR. vs. 60684
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-xl-multivcpu 17 guest-localmigrate/x10   fail REGR. vs. 60684
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 60684
 test-amd64-amd64-libvirt 15 guest-saverestore.2   fail REGR. vs. 60684
 test-amd64-amd64-xl  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-xl-credit2  15 guest-localmigratefail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm 14 guest-saverestore fail REGR. vs. 60684
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 15 guest-localmigratefail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 60684
 test-amd64-i386-xl-xsm   15 guest-localmigrate   fail blocked in 60684
 test-amd64-i386-xl   15 guest-localmigrate   fail blocked in 60684
 test-amd64-amd64-libvirt-pair 22 guest-migrate/dst_host/src_host fail blocked 
in 60684
 test-amd64-i386-pair  22 guest-migrate/dst_host/src_host fail blocked in 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684
 test-amd64-i386-libvirt  14 guest-saverestorefail   like 60684
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 60684
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 60684
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 60684
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 60684

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux0db6774ba37ddda1141159e45aac3c723221da79
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  248 days
Failing since 60712  2015-08-15 18:33:48 Z  245 days  187 attempts
Testing same since91725  2016-04-17 05:30:52 Z0 days1 attempts

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
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  fail
 test-amd64-i386-xl   fail
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 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-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm 

[Xen-devel] xen cpu scheduler internals

[tutu sky]

Hi,
I know that scheduling is done via two main functions and their effective 
interaction:
one 'schedule()' in schedule.c and another 'do_schedule(...)', which is 
specific for every scheduling policy.
my question is that (although it may seem clear and very common for kernel 
developers, but not as mush for me):
when a vcpu is selected to run on a specific cpu, what is the policy for 
choosing cpu (pcpu)?
I see smp_processor_id() very frequent, and in my suppose, the current cpu is 
the cpu which is used for scheduling (i just think so).

if i need to choose and find more than one cpu for running my tasks on, what 
should i do in scheduler context?

Thanks and regards.

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

[Xen-devel] [PATCH V4] vm_event: Allow subscribing to write events for specific MSR-s

[Razvan Cojocaru]

Previously, subscribing to MSR write events was an all-or-none
approach, with special cases for introspection MSR-s. This patch
allows the vm_event consumer to specify exactly what MSR-s it is
interested in, and as a side-effect gets rid of the
vmx_introspection_force_enabled_msrs[] special case.
This replaces the previously posted "xen: Filter out MSR write
events" patch.

Signed-off-by: Razvan Cojocaru 
Acked-by: Wei Liu 

---
Changes since V3:
 - Fixed high MSR range.
 - Added comment about where to find MSR indices to xenctrl.h.
 - Added Wei Liu's ack.
---
 tools/libxc/include/xenctrl.h  |  9 +++-
 tools/libxc/xc_monitor.c   |  6 +--
 xen/arch/x86/hvm/event.c   |  3 +-
 xen/arch/x86/hvm/hvm.c |  3 +-
 xen/arch/x86/hvm/vmx/vmcs.c| 26 ++-
 xen/arch/x86/hvm/vmx/vmx.c | 10 ++--
 xen/arch/x86/monitor.c | 95 +-
 xen/arch/x86/vm_event.c|  9 
 xen/include/asm-x86/domain.h   |  4 +-
 xen/include/asm-x86/hvm/hvm.h  |  8 ++--
 xen/include/asm-x86/hvm/vmx/vmcs.h |  7 ---
 xen/include/asm-x86/monitor.h  |  8 
 xen/include/public/domctl.h|  5 +-
 13 files changed, 126 insertions(+), 67 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index f5a034a..3216e48 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2183,8 +2183,13 @@ int xc_monitor_get_capabilities(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
  uint16_t index, bool enable, bool sync,
  bool onchangeonly);
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture);
+/*
+ * A list of MSR indices can usually be found in /usr/include/asm/msr-index.h.
+ * Please consult the Intel/AMD manuals for more information on
+ * non-architectural indices.
+ */
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable);
 int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_software_breakpoint(xc_interface *xch, domid_t domain_id,
bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b1705dd..78131b2 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -86,8 +86,8 @@ int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, &domctl);
 }
 
-int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
-  bool extended_capture)
+int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, uint32_t msr,
+  bool enable)
 {
 DECLARE_DOMCTL;
 
@@ -96,7 +96,7 @@ int xc_monitor_mov_to_msr(xc_interface *xch, domid_t 
domain_id, bool enable,
 domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
 : XEN_DOMCTL_MONITOR_OP_DISABLE;
 domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_MSR;
-domctl.u.monitor_op.u.mov_to_msr.extended_capture = extended_capture;
+domctl.u.monitor_op.u.mov_to_msr.msr = msr;
 
 return do_domctl(xch, &domctl);
 }
diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 56c5514..9c17f37 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -57,9 +57,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned long value, 
unsigned long old)
 void hvm_event_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
-struct arch_domain *ad = &curr->domain->arch;
 
-if ( ad->monitor.mov_to_msr_enabled )
+if ( monitor_is_msr_enabled(curr->domain, msr) )
 {
 vm_event_request_t req = {
 .reason = VM_EVENT_REASON_MOV_TO_MSR,
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index f24126d..447e3c2 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3695,7 +3695,6 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 bool_t mtrr;
 unsigned int edx, index;
 int ret = X86EMUL_OKAY;
-struct arch_domain *currad = ¤t->domain->arch;
 
 HVMTRACE_3D(MSR_WRITE, msr,
(uint32_t)msr_content, (uint32_t)(msr_content >> 32));
@@ -3703,7 +3702,7 @@ int hvm_msr_write_intercept(unsigned int msr, uint64_t 
msr_content,
 hvm_cpuid(1, NULL, NULL, NULL, &edx);
 mtrr = !!(edx & cpufeat_mask(X86_FEATURE_MTRR));
 
-if ( may_defer && unlikely(currad->monitor.mov_to_msr_enabled) )
+if ( may_defer && unlikely(monitor_is_msr_enabled(v->domain, msr)) )
 {
 ASSERT(v->arch.vm_event);
 
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8284281..24ad906 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -37,6 +3

Re: [Xen-devel] [PATCH V4] vm_event: Allow subscribing to write events for specific MSR-s

[Tamas K Lengyel]

On Sun, Apr 17, 2016 at 1:15 PM, Razvan Cojocaru 
wrote:

> Previously, subscribing to MSR write events was an all-or-none
> approach, with special cases for introspection MSR-s. This patch
> allows the vm_event consumer to specify exactly what MSR-s it is
> interested in, and as a side-effect gets rid of the
> vmx_introspection_force_enabled_msrs[] special case.
> This replaces the previously posted "xen: Filter out MSR write
> events" patch.
>
> Signed-off-by: Razvan Cojocaru 
> Acked-by: Wei Liu 
>

Acked-by: Tamas K Lengyel 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.7 1/5] build: make HOSTCC conditional on the value of clang

[Jan Beulich]

>>> Roger Pau Monne  04/15/16 8:27 PM >>>
>Previously HOSTCC was always hardcoded to gcc

So what is the goal here? Be able to build on a gcc-free system? Or else, how
does it matter what compiler build elements get built with?

>--- a/Config.mk
>+++ b/Config.mk
>@@ -36,7 +36,6 @@ CONFIG_$(XEN_OS) := y
 >SHELL ?= /bin/sh
 >
 ># Tools to run on system hosting the build
>-HOSTCC  = gcc
 >HOSTCFLAGS  = -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer
 >HOSTCFLAGS += -fno-strict-aliasing
 >
>@@ -50,8 +49,10 @@ DESTDIR ?= /
 >clang ?= n
 >ifeq ($(clang),n)
 >gcc := y
>+HOSTCC = gcc
 >else
 >gcc := n
>+HOSTCC = clang
 >endif
 
 In particular I wonder what this means for cross builds, where someone may
have installed e.g. only a cross variant of clang.

That said, I'm not really opposed to the change (as it seems to be at least an
incremental improvement), I only wonder whether some more thought (and
change) is needed here.

Jan


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

Re: [Xen-devel] [PATCH v8.1 08/27] arm/x86/vmap: Add vmalloc_xen, vfree_xen and vm_init_type

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/14/16 12:03 AM >>>
>Signed-off-by: Konrad Rzeszutek Wilk 
>Suggested-by: Jan Beulich 
>Acked-by: Julien Grall  [ARM]
>Reviewed-by: Andrew Cooper 

Is that really the case? I think it was Andrew who suggested to not expose a
second variant of vfree(), as the address type can be inferred from the address.

>@@ -52,27 +55,30 @@ void *vm_alloc(unsigned int nr, unsigned int align)
 >else if ( align & (align - 1) )
 >align &= -align;
 >
>+if ( !vm_base[t] )
>+return NULL;

How about ASSERT()ing that t is in range before using it as an array index?

With the address/type parameter redundancy dropped at the very least from
the non-internal functions, I think everything else here is fine.

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3)  broken pass in 91660
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 91660

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 91545
 build-amd64-rumpuserxen   6 xen-buildfail   like 91660
 build-i386-rumpuserxen6 xen-buildfail   like 91660
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 91660
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 91660
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 91660
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 91660
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 91660

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 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-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   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-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 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-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  f3a7ca02400d1c416e97451b4aebfaf608fc8192
baseline version:
 xen  f3a7ca02400d1c416e97451b4aebfaf608fc8192

Last test of basis91745  2016-04-17 08:23:39 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16908 days0 attempts

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-oldkern 

Re: [Xen-devel] [PATCH v8.1 10/27] xsplice: Add helper elf routines

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/14/16 12:03 AM >>>
>+static int elf_verify_strtab(const struct xsplice_elf_sec *sec)
>+{
>+ const Elf_Shdr *s;
>+ const uint8_t *contents;

Considering it's a string table, perhaps better const char *?

>+ s = sec->sec;
>+
>+ if ( s->sh_type != SHT_STRTAB )
>+ return -EINVAL;
>+
>+ if ( !s->sh_size )
>+ return -EOPNOTSUPP;

Why not also -EINVAL? I don't think the standard permits empty string table
sections.

>+ contents = (const uint8_t *)sec->data;

Pointless cast.

>+static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
>+{
>+ struct xsplice_elf_sec *sec;
>+ unsigned int i;
>+ Elf_Off delta;
>+ int rc;
>+
>+ /* xsplice_elf_load sanity checked e_shnum. */
>+ sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
>+ if ( !sec )
>+ {
>+ dprintk(XENLOG_ERR, XSPLICE"%s: Could not allocate memory for section 
>table!\n",
>+ elf->name);
>+ return -ENOMEM;
>+ }
>+
>+ elf->sec = sec;
>+
>+ delta = elf->hdr->e_shoff + elf->hdr->e_shnum * elf->hdr->e_shentsize;

I think Andrew had asked this before - are we not worried of overflow here?

>+ if ( delta > elf->len )
>+ {
>+ dprintk(XENLOG_ERR, XSPLICE "%s: Section table is past end of payload!\n",
>+ elf->name);
>+ return -EINVAL;
>+ }
>+
>+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
>+ {
>+ delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
>+
>+ sec[i].sec = (void *)data + delta;

Casting away constness is one of the main reasons I complain about casts in
general. If you really need to modify some fields in the section header, you 
should
imo cast away constness just there. But even better would be if you left the
section header alone.

>+ delta = sec[i].sec->sh_offset;
>+
>+ /*
>+ * N.B. elf_resolve_section_names, elf_get_sym skip this check as
>+ * we do it here.
>+ */
>+ if ( delta && (delta + sec[i].sec->sh_size > elf->len) )

Allowing delta to be zero here seems suspicious: Are you doing that because
some sections come without data (and hence without offset)? In that case you'd
better skip the check on those section types (e.g. SHT_NOBITS) only. In fact
the offset being below the end of the ELF header would likely indicate a broken
image.

>+ /* Name is populated in xsplice_elf_sections_name. */

Stale function name afaict.

>+ /*
>+ * elf->symtab->sec->sh_link would point to the right section
>+ * but we hadn't finished parsing all the sections.
>+ */
>+ if ( elf->symtab->sec->sh_link > elf->hdr->e_shnum )

>= (and I know I had asked before to check all these bounds checks for off
by one errors)

>+ if ( !elf->symtab->sec->sh_size ||
>+ elf->symtab->sec->sh_entsize < sizeof(Elf_Sym) )

|| sh_size % sh_entsize

>+ /*
>+ * There can be multiple SHT_STRTAB (.shstrtab, .strtab) so pick one
>+ * associated with the symbol table.
>+ */

... pick the one ...

>+static int elf_resolve_section_names(struct xsplice_elf *elf, const void 
>*data)
>+{
>+ const char *shstrtab;
>+ unsigned int i;
>+ Elf_Off offset, delta;
>+ struct xsplice_elf_sec *sec;
>+ int rc;
>+
>+ /*
>+ * The elf->sec[0 -> e_shnum] structures have been verified by
>+ * elf_resolve_sections. Find file offset for section string table
>+ * (normally called .shstrtab)
>+ */
>+ sec = &elf->sec[elf->hdr->e_shstrndx];
>+
>+ rc = elf_verify_strtab(sec);
>+ if ( rc )
>+ {
>+ dprintk(XENLOG_ERR, XSPLICE "%s: Section string table is corrupted\n",
>+ elf->name);
>+ return rc;
>+ }
>+
>+ /* Verified in elf_resolve_sections but just in case. */
>+ offset = sec->sec->sh_offset;
>+ ASSERT(offset < elf->len && (offset + sec->sec->sh_size <= elf->len));
>+
>+ shstrtab = data + offset;
>+
>+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
>+ {
>+ delta = elf->sec[i].sec->sh_name;
>+
>+ if ( delta && delta >= sec->sec->sh_size )
>+ {
>+ dprintk(XENLOG_ERR, XSPLICE "%s: shstrtab [%u] data is past end of 
>payload!\n",
>+ elf->name, i);

Isn't this redundant with the check in elf_resolve_sections()? Or is this needed
because the one here runs before that other one?

>+static int elf_get_sym(struct xsplice_elf *elf, const void *data)
>+{
>+ const struct xsplice_elf_sec *symtab_sec, *strtab_sec;
>+ struct xsplice_elf_sym *sym;
>+ unsigned int i, delta, offset, nsym;
>+
>+ symtab_sec = elf->symtab;
>+ strtab_sec = elf->strtab;
>+
>+ /* Pointers arithmetic to get file offset. */
>+ offset = strtab_sec->data - data;
>+
>+ /* Checked already in elf_resolve_sections, but just in case. */
>+ ASSERT(offset == strtab_sec->sec->sh_offset);
>+ ASSERT(offset < elf->len && (offset + strtab_sec->sec->sh_size <= elf->len));
>+
>+ /* symtab_sec->data was computed in elf_resolve_sections. */
>+ ASSERT((symtab_sec->sec->sh_offset + data) == symtab_sec->data);
>+
>+ /* No need to check values as elf_resolve_sections did it. */
>+ nsym = symtab_sec->sec->sh_size / symtab_sec->sec->sh_entsize;
>+
>+ sym = xmalloc_array(struct xsplice_elf_sym, nsym);
>+ if ( !sym )
>+ {
>+ dprintk(XENLOG_ERR, XSPLICE "%s: Could not allocate memory for symbols\n",
>+ elf->name);
>+ return -ENOMEM;
>+ }
>+

[Xen-devel] [linux-3.18 test] 91757: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail in 91675 pass in 91757
 test-armhf-armhf-xl-rtds 16 guest-start.2  fail in 91675 pass in 91757
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 15 guest-localmigrate/x10 fail 
pass in 91675
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 91675

Regressions which are regarded as allowable (not blocking):
 build-amd64-rumpuserxen   6 xen-buildfail   like 86513
 build-i386-rumpuserxen6 xen-buildfail   like 86513
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86513
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 86513

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

version targeted for testing:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis86513  2016-03-17 21:21:40 Z   30 days
Testing same since89247  2016-04-06 22:15:59 Z   10 days   10 attempts


People who touched revisions under test:
  Alex Deucher 
  Avery Pennarun 
  Catalin Marinas 
  Chris Bainbridge 
  Emmanuel Grumbach 
  Felix Fietkau 
  Grygorii Strashko 
  James Hogan 
  Johannes Berg 
  Jouni Malinen 
  Konstantin Khlebnikov 
  Liad Kaufman 
  Lokesh Vutla 
  Marc Kleine-Budde 
  Mark Brown 
  Markos Chandras 
  Maximilain Schneider 
  Maximilian Schneider 
  Michael S. Tsirkin 
  Miklos Szeredi 
  Mugunthan V N 
  Nicholas Bellinger 
  Paolo Bonzini 
  Paul Mackerras 
  Paul Walmsley 
  Radim Krčmář 
  Ralf Baechle 
  Rui Wang 
  Sasha Levin 
  Steven Rostedt (Red Hat) 
  Steven Rostedt 
  Sudeep Holla 
  Sudip Mukherjee 
  Takashi Iwai 
  Tony Lindgren 
  Will Deacon 

jobs:
 build-amd64-xsm  

[Xen-devel] [libvirt bisection] complete build-i386-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-i386-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  e744065679ccba8471d28b2cf6e93f443cd20c8c
  Bug not present: 744d74fafd0048c01a2b5cc18d1b03917ece8886
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/91813/


  commit e744065679ccba8471d28b2cf6e93f443cd20c8c
  Author: Jim Fehlig 
  Date:   Thu Apr 14 16:10:32 2016 -0600
  
  libxl: use LIBXL_API_VERSION 0x040200
  
  To ensure the libvirt libxl driver will build with future versions
  of Xen where the libxl API may change in incompatible ways,
  explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
  does use new libxl APIs that have been added since Xen 4.2, but
  currently it does not make use of any changes made to existing
  APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
  The version can be bumped if/when the libxl driver consumes the
  changed APIs.
  
  Further details can be found in the following discussion thread
  
  https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html
  Signed-off-by: Jim Fehlig 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-i386-libvirt.libvirt-build 
--summary-out=tmp/91813.bisection-summary --basis-template=91479 
--blessings=real,real-bisect libvirt build-i386-libvirt libvirt-build
Searching for failure / basis pass:
 91722 fail [host=huxelrebe0] / 91479 [host=baroque1] 91380 [host=elbling0] 
91230 [host=fiano0] 91073 ok.
Failure / basis pass flights: 91722 / 91073
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
f3a7ca02400d1c416e97451b4aebfaf608fc8192
Basis pass ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9-727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae
 
git://git.sv.gnu.org/gnulib.git#6cc32c63e80bc1a30c521b2f07f2b54909b59892-6cc32c63e80bc1a30c521b2f07f2b54909b59892
 
git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-21f6526d1da331611ac5fe12967549d1a04e149b
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-316a862e5534249a6e6d876b4e203342d3fb870e
 
git://xenbits.xen.org/xen.git#a6f2cdb633bf519244a16674031b8034b581ba7f-f3a7ca02400d1c416e97451b4aebfaf608fc8192
Loaded 2001 nodes in revision graph
Searching for test results:
 90991 [host=nocera0]
 91073 pass ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 91230 [host=fiano0]
 91380 [host=elbling0]
 91479 [host=baroque1]
 91597 fail irrelevant
 91717 pass irrelevant
 91711 pass ad584cbb6cfd4a13dfe6bb80650edbebc7fba8a9 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
a6f2cdb633bf519244a16674031b8034b581ba7f
 91715 fail irrelevant
 91731 pass irrelevant
 91720 pass irrelevant
 91728 pass irrelevant
 91732 pass irrelevant
 91735 pass irrelevant
 91739 pass irrelevant
 91742 fail irrelevant
 91744 pass irrelevant
 91722 fail 727a3c5860ef5e1fb8878da9d44c6e5e33a4f4ae 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
f3a7ca02400d1c416e97451b4aebfaf608fc8192
 91749 fail irrelevant
 91776 pass 4bbac0f9b9fa681bc6dba34515e32942c5b3f4c7 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
ac703c285a4fbfcb85c19364ea0c67780bf16c2d
 91752 pass irrelevant
 91780 pass a91177c8f7b432e67d2e232650d7debbbfc694da 
6cc32c63

[Xen-devel] [PATCH] libxl: fix old style declarations

[Wei Liu]

Fix errors like:

/local/work/xen.git/dist/install/usr/local/include/libxl_uuid.h:59:1: error: 
'static' is not at beginning of declaration [-Werror=old-style-declaration]
 void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst,
 ^
/local/work/xen.git/dist/install/usr/local/include/libxl_uuid.h:59:1: error: 
'inline' is not at beginning of declaration [-Werror=old-style-declaration]

/local/work/xen.git/dist/install/usr/local/include/libxl.h:1233:1: error: 
'static' is not at beginning of declaration [-Werror=old-style-declaration]
 int static inline libxl_domain_create_restore_0x040200(
 ^
Signed-off-by: Wei Liu 
---
Cc: Ian Jackson 
---
 tools/libxl/libxl.h  | 4 ++--
 tools/libxl/libxl_uuid.h | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 3fc5c48..8ff5f31 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1230,7 +1230,7 @@ int libxl_domain_create_restore(libxl_ctx *ctx, 
libxl_domain_config *d_config,
 
 #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040400
 
-int static inline libxl_domain_create_restore_0x040200(
+static inline int libxl_domain_create_restore_0x040200(
 libxl_ctx *ctx, libxl_domain_config *d_config,
 uint32_t *domid, int restore_fd,
 const libxl_asyncop_how *ao_how,
@@ -1254,7 +1254,7 @@ int static inline libxl_domain_create_restore_0x040200(
 #elif defined(LIBXL_API_VERSION) && LIBXL_API_VERSION >= 0x040400 \
  && LIBXL_API_VERSION < 0x040700
 
-int static inline libxl_domain_create_restore_0x040400(
+static inline int libxl_domain_create_restore_0x040400(
 libxl_ctx *ctx, libxl_domain_config *d_config,
 uint32_t *domid, int restore_fd,
 const libxl_domain_restore_params *params,
diff --git a/tools/libxl/libxl_uuid.h b/tools/libxl/libxl_uuid.h
index 994320d..17c8b97 100644
--- a/tools/libxl/libxl_uuid.h
+++ b/tools/libxl/libxl_uuid.h
@@ -56,7 +56,7 @@ int libxl_uuid_from_string(libxl_uuid *uuid, const char *in);
 void libxl_uuid_copy(libxl_ctx *ctx_opt, libxl_uuid *dst,
  const libxl_uuid *src);
 #if defined(LIBXL_API_VERSION) && LIBXL_API_VERSION < 0x040500
-void static inline libxl_uuid_copy_0x040400(libxl_uuid *dst,
+static inline void libxl_uuid_copy_0x040400(libxl_uuid *dst,
 const libxl_uuid *src)
 {
 libxl_uuid_copy(NULL, dst, src);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v11 01/17] Xen: ACPI: Hide UART used by Xen

[Rafael J. Wysocki]

On Thu, Apr 7, 2016 at 2:03 PM, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> ACPI 6.0 introduces a new table STAO to list the devices which are used
> by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
> UART is used by Xen. So here it hides UART from Dom0.
>
> CC: "Rafael J. Wysocki"  (supporter:ACPI)
> CC: Len Brown  (supporter:ACPI)
> CC: linux-a...@vger.kernel.org (open list:ACPI)
> Signed-off-by: Shannon Zhao 

Acked-by: Rafael J. Wysocki 

> ---
>  drivers/acpi/scan.c | 74 
> +
>  1 file changed, 74 insertions(+)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 5f28cf7..cfc73fe 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -46,6 +46,13 @@ DEFINE_MUTEX(acpi_device_lock);
>  LIST_HEAD(acpi_wakeup_device_list);
>  static DEFINE_MUTEX(acpi_hp_context_lock);
>
> +/*
> + * The UART device described by the SPCR table is the only object which needs
> + * special-casing. Everything else is covered by ACPI namespace paths in STAO
> + * table.
> + */
> +static u64 spcr_uart_addr;
> +
>  struct acpi_dep_data {
> struct list_head node;
> acpi_handle master;
> @@ -1453,6 +1460,41 @@ static int acpi_add_single_object(struct acpi_device 
> **child,
> return 0;
>  }
>
> +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
> +   void *context)
> +{
> +   struct resource *res = context;
> +
> +   if (acpi_dev_resource_memory(ares, res))
> +   return AE_CTRL_TERMINATE;
> +
> +   return AE_OK;
> +}
> +
> +static bool acpi_device_should_be_hidden(acpi_handle handle)
> +{
> +   acpi_status status;
> +   struct resource res;
> +
> +   /* Check if it should ignore the UART device */
> +   if (!(spcr_uart_addr && acpi_has_method(handle, METHOD_NAME__CRS)))
> +   return false;
> +
> +   /*
> +* The UART device described in SPCR table is assumed to have only one
> +* memory resource present. So we only look for the first one here.
> +*/
> +   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> +acpi_get_resource_memory, &res);
> +   if (ACPI_FAILURE(status) || res.start != spcr_uart_addr)
> +   return false;
> +
> +   acpi_handle_info(handle, "The UART device @%pa in SPCR table will be 
> hidden\n",
> +&res.start);
> +
> +   return true;
> +}
> +
>  static int acpi_bus_type_and_status(acpi_handle handle, int *type,
> unsigned long long *sta)
>  {
> @@ -1466,6 +1508,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
> int *type,
> switch (acpi_type) {
> case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
> case ACPI_TYPE_DEVICE:
> +   if (acpi_device_should_be_hidden(handle))
> +   return -ENODEV;
> +
> *type = ACPI_BUS_TYPE_DEVICE;
> status = acpi_bus_get_status_handle(handle, sta);
> if (ACPI_FAILURE(status))
> @@ -1916,9 +1961,24 @@ static int acpi_bus_scan_fixed(void)
> return result < 0 ? result : 0;
>  }
>
> +static void __init acpi_get_spcr_uart_addr(void)
> +{
> +   acpi_status status;
> +   struct acpi_table_spcr *spcr_ptr;
> +
> +   status = acpi_get_table(ACPI_SIG_SPCR, 0,
> +   (struct acpi_table_header **)&spcr_ptr);
> +   if (ACPI_SUCCESS(status))
> +   spcr_uart_addr = spcr_ptr->serial_port.address;
> +   else
> +   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
> missing\n");
> +}
> +
>  int __init acpi_scan_init(void)
>  {
> int result;
> +   acpi_status status;
> +   struct acpi_table_stao *stao_ptr;
>
> acpi_pci_root_init();
> acpi_pci_link_init();
> @@ -1934,6 +1994,20 @@ int __init acpi_scan_init(void)
>
> acpi_scan_add_handler(&generic_device_handler);
>
> +   /*
> +* If there is STAO table, check whether it needs to ignore the UART
> +* device in SPCR table.
> +*/
> +   status = acpi_get_table(ACPI_SIG_STAO, 0,
> +   (struct acpi_table_header **)&stao_ptr);
> +   if (ACPI_SUCCESS(status)) {
> +   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
> +   printk(KERN_INFO PREFIX "STAO Name List not yet 
> supported.");
> +
> +   if (stao_ptr->ignore_uart)
> +   acpi_get_spcr_uart_addr();
> +   }
> +
> mutex_lock(&acpi_scan_lock);
> /*
>  * Enumerate devices in the ACPI namespace.
> --
> 2.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.htm

Re: [Xen-devel] [PATCH v11 01/17] Xen: ACPI: Hide UART used by Xen

[Rafael J. Wysocki]

On Fri, Apr 15, 2016 at 8:43 AM, Shannon Zhao  wrote:
> Hi Rafael，
>
> Could you please give your comments on this patch? Thanks in advanced!

I was traveling last week, sorry for the slow response.

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 619e6cf19fa1ab98878972e109d0c579f37388cd
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  131 days
Failing since 65593  2015-12-08 23:44:51 Z  131 days  150 attempts
Testing same since91514  2016-04-15 14:53:46 Z2 days5 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl-xsm  17 guest-localmigrate/x10fail REGR. vs. 59254
 test-amd64-amd64-xl-credit2  14 guest-saverestore fail REGR. vs. 59254
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 59254
 test-amd64-amd64-xl  14 guest-saverestore fail REGR. vs. 59254
 test-amd64-amd64-xl-multivcpu 14 guest-saverestorefail REGR. vs. 59254
 test-amd64-i386-xl   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-i386-xl-xsm   15 guest-localmigratefail REGR. vs. 59254
 test-amd64-amd64-pair  22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-amd64-i386-pair   22 guest-migrate/dst_host/src_host fail REGR. vs. 59254
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 59254
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds 17 guest-localmigrate/x10fail REGR. vs. 59254
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 59254
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail baseline 
untested
 test-amd64-i386-libvirt-pair 22 guest-migrate/dst_host/src_host fail baseline 
untested
 test-armhf-armhf-xl-vhd   9 debian-di-install   fail baseline untested
 test-amd64-i386-libvirt-xsm  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-amd64-libvirt-xsm 14 guest-saverestorefail blocked in 59254
 test-amd64-amd64-libvirt 15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-libvirt  15 guest-saverestore.2  fail blocked in 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254

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

version targeted for testing:
 linuxb9f5dba225aede4518

Re: [Xen-devel] abstract model of IOMMU unmaping/mapping failures

[Xu, Quan]

On April 15, 2016 10:03pm,  wrote:
> On 31/03/16 10:06, Xu, Quan wrote:
> > All,
> >
> > Here is a summary of my investigation of the abstract model:
> >
> > Below policies are adopted when deciding whether to rollback a callchain:
> >
> > 1. Domain will be crashed immediately within iommu_{,un}map_page,
> > treated as a fatal error (with the exception of the hardware one).
> > Whether to rollback depends on the need of hardware domain;
> >
> > 2. For hardware domain, roll back on a best effort basis. When
> > rollback is not feasible (in early initialization phase or trade-off
> > of complexity), at least unmap upon maps error and then throw out
> > error message;
> >
> > Below are a detail analysis of all existing callers on IOMMU interfaces 
> > (8-11
> needs more discussions):
> 
> Hey Quan,
> 
> I only reviewed the p2m-related ones (5-10), but I agree with your and Jan's
> conclusions.  Thanks for doing this legwork.
> 
George,
That's good. thanks for your review.
I will send out this patch set soon.

Quan

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 619e6cf19fa1ab98878972e109d0c579f37388cd
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  131 days
Failing since 65593  2015-12-08 23:44:51 Z  131 days  151 attempts
Testing same since91514  2016-04-15 14:53:46 Z2 days6 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michał Zegan 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian, Feng 
  Vladislav Vovchenko 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zeng, Star 
  Zhang Lubo 
  Zhang, Chao B 
  Zhang, Lubo 
  Zhangfei Gao 

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 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail



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

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

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

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


Not pushing.

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

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

Re: [Xen-devel] Where and How the P2M table and M2P table create?

[Zhang, Chunyu]

hi

this may help you。。。


hvm_vcpu_initialise 
  - .vcpu_initialise  = vmx_vcpu_initialise,
　　- vmx_create_vmcs
　　  - construct_vmcs
　　- if ( paging_mode_hap(d) )
　　  {
　　 struct p2m_domain *p2m = p2m_get_hostp2m(d);
　　 struct ept_data *ept = &p2m->ept;
　　
　　 ept->asr  = pagetable_get_pfn(p2m_get_pagetable(p2m));
　　 __vmwrite(EPT_POINTER, ept_get_eptp(ept));
　　   }

main --> main_create --> create_domain --> libxl_domain_create_new 
--> do_domain_create --> initiate_domain_create -->  libxl__bootloader_run
 --> libxl__device_disk_local_initiate_detach --> local_device_detach_cb 
--> bootloader_local_detached_cb --> domcreate_bootloader_done --> 
libxl__domain_build
 --> libxl__build_hvm --> libxl__build_dom --> xc_dom_boot_mem_init -->
 meminit_hvm
  --> xc_domain_populate_physmap 
 -->  err = do_memory_op(xch, XENMEM_populate_physmap, &reservation);


- do_memory_op(xch, XENMEM_populate_physmap, &reservation)  (memory.c)
  - populate_physmap
　　- is_domain_direct_mapped
　　   - mfn = gpfn
　　   - put_page
　　- else
　　 - page = alloc_domheap_pages(d, a->extent_order, a->memflags);
　　 - mfn = page_to_mfn(page);
　　 - guest_physmap_add_page(d, gpfn, mfn, a->extent_order);
　　 - guest_physmap_add_entry(d, gfn, mfn, page_order, p2m_ram_rw)
　　   /* First, remove m->p mappings for existing p->m mappings */
　　   -  for ( i = 0; i < (1UL << page_order); i++ )
　　  -  omfn = p2m->get_entry(p2m, gfn + i, &ot, &a, 0, NULL, NULL);
　　 - mfn = _mfn(ept_entry->mfn)  
　　  -  set_gpfn_from_mfn
　　 - _set_gpfn_from_mfn(mfn, pfn)
　　   - machine_to_phys_mapping[(mfn)] = (entry) 
　　   /* Then, look for m->p mappings for this range and deal with them */
　　   /* Now, actually do the two-way mapping */
　　   -   rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
　　   p2m->default_access);
　　   -set_gpfn_from_mfn(mfn+i, gfn+i);   
>Hi,alls,
>
>As we know,in xen ,when create shadow page table and EPT page table,we need 
>the p2m and m2p.I want to know when are the p2m been created.Was it created at 
>the time of the creation of the domainU？Or at the beginning is a empty table 
>and in the subsequent gradually established?
>
>And how was it been created?
>
>Thanks!
>
>

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

Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to XEN

[Zhenzhong Duan]

On 2016/4/12 11:35, Zhenzhong Duan wrote:

On 2016/4/11 19:27, Wei Liu wrote:

On Mon, Apr 11, 2016 at 09:42:57AM +0800, Zhenzhong Duan wrote:
It's tool's duty to pass a correct cpumap to XEN. On a host with 
less than

64
CPUS, it just shows below error.

[root@localhost /]# xm vcpu-pin 3 all all
Error: Cannot pin vcpu: 0 to cpu: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 
11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 
30, 31,
32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 
49, 50,

51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63] - (22, 'Invalid
argument')


This error clearly shows that the upper layer is not passing down the
right cpumap. So this example along won't convince me to that this is a
bug in python binding. It's free to reject input that it deems wrong.

I guess the question is more or less what should it do in such
situation. So ...


The fix make it same as in xl code.


Is there reference to this? I guess the commit message  or mail thread
will shed more light on the expected behaviour.

Calling path:
main_vcpupin->cpurange_parse->update_cpumap_range->libxl_bitmap_set

void libxl_bitmap_set(libxl_bitmap *bitmap, int bit)
{
if (bit >= bitmap->size * 8)
return;
bitmap->map[bit / 8] |= 1 << (bit & 7);
}

I referenced above code. It just ignore the cpu number beyond the max 
CPU count rather than raise an error.

Any further comments?

thanks
zduan

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

[Xen-devel] [linux-3.18 baseline-only test] 44341: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44341 linux-3.18 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44341/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 17 guest-start/debianhvm.repeat 
fail REGR. vs. 44259

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 44259
 build-amd64-rumpuserxen   6 xen-buildfail   like 44259

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

version targeted for testing:
 linuxb36eba9b4dd4344ed51b8f644049aeac606ccff2
baseline version:
 linuxd439e869d612dd7a338ac75a4afc3646a5e67370

Last test of basis44259  2016-03-18 19:26:08 Z   30 days
Testing same since44341  2016-04-17 21:51:16 Z0 days1 attempts


People who touched revisions under test:
  Alex Deucher 
  Avery Pennarun 
  Catalin Marinas 
  Chris Bainbridge 
  Emmanuel Grumbach 
  Felix Fietkau 
  Grygorii Strashko 
  James Hogan 
  Johannes Berg 
  Jouni Malinen 
  Konstantin Khlebnikov 
  Liad Kaufman 
  Lokesh Vutla 
  Marc Kleine-Budde 
  Mark Brown 
  Markos Chandras 
  Maximilain Schneider 
  Maximilian Schneider 
  Michael S. Tsirkin 
  Miklos Szeredi 
  Mugunthan V N 
  Nicholas Bellinger 
  Paolo Bonzini 
  Paul Mackerras 
  Paul Walmsley 
  Radim Krčmář 
  Ralf Baechle 
  Rui Wang 
  Sasha Levin 
  Steven Rostedt (Red Hat) 
  Steven Rostedt 
  Sudeep Holla 
  Sudip Mukherjee 
  Takashi Iwai 
  Tony Lindgren 
  Will Deacon 

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

Re: [Xen-devel] [PATCH v8.1 10/27] xsplice: Add helper elf routines

[Konrad Rzeszutek Wilk]

. snip..
> >+static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
> >+{
> >+ struct xsplice_elf_sec *sec;
> >+ unsigned int i;
> >+ Elf_Off delta;
> >+ int rc;
> >+
> >+ /* xsplice_elf_load sanity checked e_shnum. */
> >+ sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
> >+ if ( !sec )
> >+ {
> >+ dprintk(XENLOG_ERR, XSPLICE"%s: Could not allocate memory for section 
> >table!\n",
> >+ elf->name);
> >+ return -ENOMEM;
> >+ }
> >+
> >+ elf->sec = sec;
> >+
> >+ delta = elf->hdr->e_shoff + elf->hdr->e_shnum * elf->hdr->e_shentsize;
> 
> I think Andrew had asked this before - are we not worried of overflow here?

Yes. That ends up being checked in xsplice_header_check. Added comment
here.

> 
> >+ if ( delta > elf->len )
> >+ {
> >+ dprintk(XENLOG_ERR, XSPLICE "%s: Section table is past end of payload!\n",
> >+ elf->name);
> >+ return -EINVAL;
> >+ }
> >+
> >+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
> >+ {
> >+ delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
> >+
> >+ sec[i].sec = (void *)data + delta;
> 
> Casting away constness is one of the main reasons I complain about casts in
> general. If you really need to modify some fields in the section header, you 
> should
> imo cast away constness just there. But even better would be if you left the

In earlier reviews you said that casting away constness in
function would be a big no no.

> section header alone.

I modify  sec[i].sec->sh_entsize in calc_section
> 
> >+ delta = sec[i].sec->sh_offset;
> >+
> >+ /*
> >+ * N.B. elf_resolve_section_names, elf_get_sym skip this check as
> >+ * we do it here.
> >+ */
> >+ if ( delta && (delta + sec[i].sec->sh_size > elf->len) )
> 
> Allowing delta to be zero here seems suspicious: Are you doing that because
> some sections come without data (and hence without offset)? In that case you'd
> better skip the check on those section types (e.g. SHT_NOBITS) only. In fact
> the offset being below the end of the ELF header would likely indicate a 
> broken
> image.

The loop (earlier) had started at 0 so the delta could have been zero.
Anyhow that not being the case anymore I will just do:

if ( !delta )
return -EINVAL;
> 
> >+ /* Name is populated in xsplice_elf_sections_name. */
> 
> Stale function name afaict.
> 
> >+ /*
> >+ * elf->symtab->sec->sh_link would point to the right section
> >+ * but we hadn't finished parsing all the sections.
> >+ */
> >+ if ( elf->symtab->sec->sh_link > elf->hdr->e_shnum )
> 
> >= (and I know I had asked before to check all these bounds checks for off
> by one errors)
> 
> >+ if ( !elf->symtab->sec->sh_size ||
> >+ elf->symtab->sec->sh_entsize < sizeof(Elf_Sym) )
> 
> || sh_size % sh_entsize
> 
> >+ /*
> >+ * There can be multiple SHT_STRTAB (.shstrtab, .strtab) so pick one
> >+ * associated with the symbol table.
> >+ */
> 
> ... pick the one ...
> 
> >+static int elf_resolve_section_names(struct xsplice_elf *elf, const void 
> >*data)
> >+{
> >+ const char *shstrtab;
> >+ unsigned int i;
> >+ Elf_Off offset, delta;
> >+ struct xsplice_elf_sec *sec;
> >+ int rc;
> >+
> >+ /*
> >+ * The elf->sec[0 -> e_shnum] structures have been verified by
> >+ * elf_resolve_sections. Find file offset for section string table
> >+ * (normally called .shstrtab)
> >+ */
> >+ sec = &elf->sec[elf->hdr->e_shstrndx];
> >+
> >+ rc = elf_verify_strtab(sec);
> >+ if ( rc )
> >+ {
> >+ dprintk(XENLOG_ERR, XSPLICE "%s: Section string table is corrupted\n",
> >+ elf->name);
> >+ return rc;
> >+ }
> >+
> >+ /* Verified in elf_resolve_sections but just in case. */
> >+ offset = sec->sec->sh_offset;
> >+ ASSERT(offset < elf->len && (offset + sec->sec->sh_size <= elf->len));
> >+
> >+ shstrtab = data + offset;
> >+
> >+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
> >+ {
> >+ delta = elf->sec[i].sec->sh_name;
> >+
> >+ if ( delta && delta >= sec->sec->sh_size )
> >+ {
> >+ dprintk(XENLOG_ERR, XSPLICE "%s: shstrtab [%u] data is past end of 
> >payload!\n",
> >+ elf->name, i);
> 
> Isn't this redundant with the check in elf_resolve_sections()? Or is this 
> needed
> because the one here runs before that other one?

We don't verify sh_name in elf_resolve_sections.

This is where we check that sh_name is within the shstrtab.

> 
> >+static int elf_get_sym(struct xsplice_elf *elf, const void *data)
> >+{
> >+ const struct xsplice_elf_sec *symtab_sec, *strtab_sec;
> >+ struct xsplice_elf_sym *sym;
> >+ unsigned int i, delta, offset, nsym;
> >+
> >+ symtab_sec = elf->symtab;
> >+ strtab_sec = elf->strtab;
> >+
> >+ /* Pointers arithmetic to get file offset. */
> >+ offset = strtab_sec->data - data;
> >+
> >+ /* Checked already in elf_resolve_sections, but just in case. */
> >+ ASSERT(offset == strtab_sec->sec->sh_offset);
> >+ ASSERT(offset < elf->len && (offset + strtab_sec->sec->sh_size <= 
> >elf->len));
> >+
> >+ /* symtab_sec->data was computed in elf_resolve_sections. */
> >+ ASSERT((symtab_sec->sec->sh_offset + data) == symtab_sec->data);
> >+
> >+ /* No need to check va

Re: [Xen-devel] [PATCH v8.1 11/27] xsplice: Implement payload loading

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/14/16 12:04 AM >>>
>--- a/xen/arch/x86/Makefile
>+++ b/xen/arch/x86/Makefile
>@@ -64,6 +64,7 @@ obj-y += vm_event.o
 >obj-y += xstate.o
 >
 >obj-$(crash_debug) += gdbstub.o
>+obj-$(CONFIG_XSPLICE) += xsplice.o
 
 This should be added in the main section, somewhere ahead of the xstate.o
still visible in context.

>+int arch_xsplice_perform_rela(struct xsplice_elf *elf,
>+  const struct xsplice_elf_sec *base,
>+  const struct xsplice_elf_sec *rela)
>+{
>+const Elf_RelA *r;
>+unsigned int symndx, i;
>+uint64_t val;
>+uint8_t *dest;
>+
>+if ( !rela->sec->sh_entsize || !rela->sec->sh_size ||
>+ rela->sec->sh_entsize != sizeof(Elf_RelA) )

< and again missing the sh_size % sh_entsize check. Plus an empty relocation
section is in no way invalid.

>+for ( i = 0; i < (rela->sec->sh_size / rela->sec->sh_entsize); i++ )
>+{
>+r = rela->data + i * rela->sec->sh_entsize;
>+if ( (unsigned long)r > (unsigned long)(elf->hdr + elf->len) )
>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Relative entry %u in %s is past 
>end!\n",
>+elf->name, i, rela->name);

With sections having got verified already, I don't see the point of this check.

>+symndx = ELF64_R_SYM(r->r_info);
>+if ( symndx > elf->nsym )

>=

>+{
>+dprintk(XENLOG_ERR, XSPLICE "%s: Relative symbol wants symbol@%u 
>which is past end!\n",

"Relative relocation wants ..."

>+dest = base->load_addr + r->r_offset;

I'm sure I've commented on this before: What if r_offset points outside the
section being relocated?

>+val = r->r_addend + elf->sym[symndx].sym->st_value;
>+
>+switch ( ELF64_R_TYPE(r->r_info) )
>+{
>+case R_X86_64_NONE:
>+break;
>+
>+case R_X86_64_64:
>+*(uint64_t *)dest = val;
>+break;
>+
>+case R_X86_64_PLT32:
>+/*
>+ * Xen uses -fpic which normally uses PLT relocations
>+ * except that it sets visibility to hidden which means
>+ * that they are not used.  However, when gcc cannot
>+ * inline memcpy it emits memcpy with default visibility
>+ * which then creates a PLT relocation.  It can just be
>+ * treated the same as R_X86_64_PC32.
>+ */
>+/* Fall through */

Same here, just to repeat an earlier review comment: This second comment isn't
really useful.

>+case R_X86_64_PC32:
>+val -= (uint64_t)dest;
>+*(uint32_t *)dest = val;

int32_t

>+if ( (s64)val != *(s32 *)dest )

int64_t and int32_t please (for consistency); I actually doubt the cast on the 
left
side is really needed at all.

>+void *arch_xsplice_alloc_payload(unsigned int pages)
>+{
>+unsigned int i;
>+void *p;
>+
>+ASSERT(pages);
>+
>+p = vmalloc_xen(pages * PAGE_SIZE);
>+WARN_ON(!p);

Why? If at all, a dprintk() in the else to ...

>+if ( p )
>+{
>+/* By default they are PAGE_HYPERVISOR aka PAGE_HYPERVISOR_RWX.*/
>+for ( i = 0; i < pages; i++ )
>+clear_page(p + (i * PAGE_SIZE) );
>+}

... this.

>+int arch_xsplice_secure(void *va, unsigned int pages, enum va_type type)

const void *va

>+{
>+unsigned long start = (unsigned long)va;
>+int flag;

unsigned int flags;

>+
>+ASSERT(va);
>+ASSERT(pages);
>+
>+if ( type == XSPLICE_VA_RX ) /* PAGE_HYPERVISOR_RX */
>+flag = _PAGE_PRESENT;
>+else if ( type == XSPLICE_VA_RW ) /* PAGE_HYPERVISOR_RW */
>+flag = _PAGE_RW | _PAGE_NX | _PAGE_PRESENT;
>+else /* PAGE_HYPERVISOR_RO */
>+flag = _PAGE_NX | _PAGE_PRESENT;

According to the most recent version of that patch, shouldn't you use the 
values in
the comments here instead of the open coded variants?

>+void arch_xsplice_free_payload(void *va)
>+{
>+vfree_xen(va);
>+}

What is the idea behind having this hook (instead of generic code just calling
vfree_xen() [or really just vfree()])?

>@@ -29,6 +30,13 @@ struct payload {
 >uint32_t state;  /* One of the XSPLICE_STATE_*. */
 >int32_t rc;  /* 0 or -XEN_EXX. */
 >struct list_head list;   /* Linked to 'payload_list'. */
>+void *text_addr; /* Virtual address of .text. */
>+size_t text_size;/* .. and its size. */
>+void *rw_addr;   /* Virtual address of .data. */
>+size_t rw_size;  /* .. and its size (if any). */
>+void *ro_addr;   /* Virtual address of .rodata. */
>+size_t ro_size;  /* .. and its size (if any). */

And again the question: Do these pointers really need to be non-const?

>+ size_t pages; /* Total pages for [text,rw,ro]_addr */

Why size_t and not just unsigned int?

>+static void

Re: [Xen-devel] [PATCH v8.1 10/27] xsplice: Add helper elf routines

[Jan Beulich]

>>> Konrad Rzeszutek Wilk  04/18/16 7:55 AM >>>
>> >+ if ( delta > elf->len )
>> >+ {
>> >+ dprintk(XENLOG_ERR, XSPLICE "%s: Section table is past end of payload!\n",
>> >+ elf->name);
>> >+ return -EINVAL;
>> >+ }
>> >+
>> >+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
>> >+ {
>> >+ delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
>> >+
>> >+ sec[i].sec = (void *)data + delta;
>> 
>> Casting away constness is one of the main reasons I complain about casts in
>> general. If you really need to modify some fields in the section header, you 
>> should
>> imo cast away constness just there. But even better would be if you left the
>
>In earlier reviews you said that casting away constness in
>function would be a big no no.

Exactly. Yet what do you do above?

>> section header alone.
>
>I modify  sec[i].sec->sh_entsize in calc_section

See the comment there (in the next patch it was, I think).

>> 
>> >+ delta = sec[i].sec->sh_offset;
>> >+
>> >+ /*
>> >+ * N.B. elf_resolve_section_names, elf_get_sym skip this check as
>> >+ * we do it here.
>> >+ */
>> >+ if ( delta && (delta + sec[i].sec->sh_size > elf->len) )
>> 
>> Allowing delta to be zero here seems suspicious: Are you doing that because
>> some sections come without data (and hence without offset)? In that case 
>> you'd
>> better skip the check on those section types (e.g. SHT_NOBITS) only. In fact
>> the offset being below the end of the ELF header would likely indicate a 
>> broken
>> image.
>
>The loop (earlier) had started at 0 so the delta could have been zero.
>Anyhow that not being the case anymore I will just do:
>
>if ( !delta )
>return -EINVAL;

As said, I'd suggest making this even more strict by checking at least against
the ELF header size.

>> >+ if ( elf->hdr->e_shoff > elf->len )
>> >+ {
>> >+ dprintk(XENLOG_ERR, XSPLICE "%s: Bogus e_shoff!\n", elf->name);
>> >+ return -EINVAL;
>> >+ }
>> 
>> If this check is needed, then >=. But I think it should be redundant with 
>> the more
>> complete one in elf_resolve_sections().
>
>This is the overflow check Andrew asked for.

I don't think so - there's no overflow being checked for here at all, this is
just a within bounds check. Just compare with the other one.

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 91479
 build-i386-libvirt5 libvirt-build fail REGR. vs. 91479
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 91479

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  c81bba4f6f925eda28e64bc6593e916f852db99e
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z3 days
Failing since 91597  2016-04-16 04:20:46 Z2 days3 attempts
Testing same since91860  2016-04-18 04:24:15 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Cole Robinson 
  Erik Skultety 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Martin Kletzander 
  Maxim Nestratov 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 

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  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-armhf-armhf-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

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


Not pushing.

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

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