Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS

[Dario Faggioli]

On Fri, 2015-10-30 at 19:00 -0400, Meng Xu wrote:
> Hi Dario,
>
Hi,

> > This is fixed as follows:
> >  - take the lock in the hook implementations, in specific
> >schedulers' code;
> >  - avoid calling insert_vcpu(), for the idle vCPU, in
> >schedule_cpu_switch(). In fact, idle vCPUs are set to run
> >immediately, and the various schedulers won't insert them
> >in their runqueues anyway, even when explicitly asked to.
> > 
> > While there, still in schedule_cpu_switch(), locking with
> > _irq() is enough (there's no need to do *_irqsave()).
> > 
> > Signed-off-by: Dario Faggioli 
> > ---

> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > index 6f71e0d..e16bd3a 100644
> > --- a/xen/common/sched_credit.c
> > +++ b/xen/common/sched_credit.c
> > @@ -903,10 +903,16 @@ static void
> >  csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
> >  {
> >  struct csched_vcpu *svc = vc->sched_priv;
> > +spinlock_t *lock;
> > +unsigned long flags;
> > +
> > +lock = vcpu_schedule_lock_irqsave(vc, &flags);
> 
> 
> This is inconsistent with the commit log.
>
Mmm... no, the changelog speaks about schedule_cpu_switch(), not this
functions.

For this function, the conversion from _irqsave() to _irq() is done
later in the series, when the call to insert_vcpu() is removed from the
boot path, and hence does not require IRQs to be disabled when called
(and the changelog of that later patch explains this).

> I also checked the
> 
> branch rel/sched/fix-vcpu-ins-rem-v2 in your repo., it is the
> following code:
> 
> lock = vcpu_schedule_lock_irq(vc, &flags);
> 
> I guess maybe you forgot to change it in this commit but change it
> the
> following commit?
> 
No, this is one of the few thing that changed between v2 and v3.

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



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

[Xen-devel] Revisit VT-d asynchronous flush issue

[Tian, Kevin]

Let's start a new thread with a summary of previous discussion, and 
then our latest experiment data and updated proposal.

>From previous discussions, it's suggested that a spin model is accepted, 
only when spin timeout doesn't exceed the order of a scheduling time 
slice, or other blocking operations like what WBINVD might take. 
Otherwise async-flush model is preferred to prevent misbehaving guests 
taking long spins if possible, to impact whole system.

Below are some thresholds to be considered:

1) scheduling time slice in Credit is 1ms.

2) WBINVD cost is 4.6ms in worst case on an IVT platform (32 cores, 
10GB NIC assigned to the VM, running iperf). Detail data is append in 
the bottom. Actual cost varies on different platforms, due to different 
cache size/layout. For example, we also heard from other colleagues 
about 10ms level cost on another platform.

3) PCI SIG strongly recommends that Completion Timeout mechanism
not expire in less than 10ms (PCIe 3.0 spec, 7.8.15, Device Capabilities
2 Register). It means CPU MMIO read might already take >10ms which 
we just didn't note.

Based on above information, at least we can think a timeout range
between [1ms, 10ms] would likely not introduce bad system behavior. 
Or conservatively, we can define the spin timeout default as 1ms, 
while allowing boot-time override up to 10ms for more flexibility.

Then regarding to VT-d flush:

- For context/iotlb/iec flush, our measurements show worst cases
<10us. We also confirmed with hardware team, that 1ms is large 
enough for IOMMU internal flush.

- For ATS device-TLB flush, PCI spec defines up to 60s, but:

* Our hardware team confirms that 1ms should be enough for 
integrated PCI devices w/ ATS.

* for discrete PCI devices w/ ATS, it's uncertain whether 1ms 
or 10ms is too restrictive to them, but there are only a few devices
now in the market. 

Based on above information, we propose to continue spin-timeout
model w/ some adjustment, which fixes current timeout concern
and also allows limited ATS support in a light way:

1) reduce spin timeout to 1ms, which can be boot-time changed
up to 10ms.

2) if timeout expires, kill the VM which the target device is assigned 
to. Optionally hypervisor may mark device non-assignable.

It works for devices w/o ATS. It works for integrated devices w/ ATS.
It might or might not work for discrete devices w/ ATS, but we can
re-evaluate the gain vs. software complexity of async flush until we 
see many discrete devices breaking the timeout assumptions in the 
future.

Thoughts?



Min(us) Max(us) Average(us)
context 5.245.495.36
iotlb   1.902.072.03
iec 5.547.866.58
wbinvd  2721.42 4655.71 3571.43

Platform info:
1. Base Board Information
Manufacturer: Intel Corporation
Product Name: S2600CP
Version: E99552-561

2. CPU:
cpu family : 6
model : 62
model name : Genuine Intel(R) CPU  @ 2.80GHz

Thanks
Kevin

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

Re: [Xen-devel] ovmf fail to compile

[Wei Liu]

On Mon, Nov 02, 2015 at 07:27:32AM +, Hao, Xudong wrote:
> Hi,
> 
> Does anyone meet build OVMF failure? The ovmf is xen default repo: 
> http://xenbits.xen.org/git-http/ovmf.git, with latest commit 
> af9785a9ed61daea52b47f0bf448f1f228beee1e, and OS is X86_64 RHEL6.6.
> 
> 
> ...
> make[1]: *** 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/OvmfPkg/Sec/SecMain/DEBUG/SecMain.dll]
>  Error 1
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/OvmfPkg/Sec/SecMain]
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/MdeModulePkg/Universal/PCD/Pei/Pcd]
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/MdeModulePkg/Core/Pei/PeiMain]
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/IntelFrameworkModulePkg/Universal/StatusCode/Pei/StatusCodePei]
> 
> 
> build.py...
> : error 7000: Failed to execute command
>make tbuild 
> [/home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/Build/OvmfX64/DEBUG_GCC44/X64/MdeModulePkg/Core/DxeIplPeim/DxeIpl]
> 
> 
> build.py...
> : error F002: Failed to build module
>
> /home/nightly/builds_xen_unstable/xen-src-bf0d4923-20151029/tools/firmware/ovmf-dir/OvmfPkg/Sec/SecMain.inf
>  [X64, GCC44, DEBUG]
> 

It could be there are bugs that break gcc-4.4 build. Unfortunately the
log above doesn't show much information.

BTW we updated OVMF changeset in Config.mk recently. Did you start your
build from a fresh clone?


Wei.

> 
> Best Regards
> Xudong


> ___
> 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] Contributing to Outreachy (Dec '15 - March '16)

[Wei Liu]

Hi Aastha

On Fri, Oct 30, 2015 at 11:40:51PM +0530, Aastha Yadav wrote:
> Hi,
> 
> I am an Outreachy (Dec '15 - March '16) applicant. I have a background in
> C, C++, Python, bash and Unix like systems. I also have knowledge of
> operating systems and networking.
> 
> I know it's late, but I am interested in contributing to the Xen project
> for this round of Outreachy, if possible. If the interns have not been
> finalized, can I participate in this round ? Also, can someone please point
> me to the relevant sources ?
> 

I'm afraid you already missed this round.

We do have other rounds later next year. We will also try to apply for
Google Summer of Code. You're welcome to apply next year.

Wei.

> -- 
> Thanks & Regards,
> Aastha Yadav

> ___
> 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] [linux-3.14 test] 63336: regressions - FAIL

[Ian Campbell]

On Wed, 2015-10-28 at 18:12 +, Julien Grall wrote:
> Hi,
> 
> On 28/10/15 17:31, osstest service owner wrote:
> > flight 63336 linux-3.14 real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/63336/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  build-armhf-pvops 5 kernel-build  fail REGR.
> > vs. 62648
> 
> > + make -j4 INSTALL_PATH=/home/osstest/build.63336.build-armhf
> > -pvops/dist/boot INSTALL_MOD_PATH=/home/osstest/build.63336.build-armhf
> > -pvops/dist modules_install dtbs_install
> > make: *** No rule to make target `dtbs_install'.  Stop.
> > make: *** Waiting for unfinished jobs
> 
> This is not a Linux regression but a bug introduced in osstest
> by d4dba6183d616b1d4f9826834318db48eb8ec5d6 "ts-kernel-build:
> Include dtbs in dist file"
> 
> As said by the commit message the target dtbs_install has
> been introduced post-3.14. It also says that we only test
> 3.16 and onwards on ARM. However this job seems to prove
> the contrary.

Yes, I had forgotten at the time that we can run on 3.14 in the Cambridge
instance, which I rediscovered when writing this osstest patch:

commit 54f237784d4b3cbf2f05ed5835798536b5c5d17e
Author: Ian Campbell 
Date:   Mon Oct 5 16:57:37 2015 +0100

make-flight: Don't bother testing linux-3.10 on ARM.

The earliest version which boots on the hardware in the colo is v3.16+
from the current linux-arm-xen branch.

However in the h/w in the Cambridge instance works ok with linux-3.14
and linux-3.16.

We already skip linux branches 3.4 and earlier, so just add 3.10 too.

Signed-off-by: Ian Campbell 
Acked-by: Ian Jackson 

> So shall we disable 3.14 job for ARM for once and all?

Given the above failure I don't think the ability to test the 3.14 kernels
on the Cambridge instance is all that valuable. So yes, I think we should
drop ARM from the linux-3.14 flights.

We should also force push 3.14 if the above was the only failure.

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

[Xen-devel] [X-POST from xen-users] DomU Sync I/O

[Simone Ricci]

Good morning everyone,

while trying out xenserver there was a thing that caught my attention: 
apparently every I/O done in the guest magically ends being async toward the 
storage (amongst other things I tried dd with oflags=sync). The storage BOX 
exports the LUNs via FC, with writeback cache enabled. The very same dd command 
issued from dom0, targeted to the same storage (onto an LV manually created on 
the SR VG) acts correctly, i.e. I see SCSI command 0x35 (SYNCHRONIZE CACHE) 
issued to the target after every single block (confirmed via quick-n-dirty 
dtrace script, storage is a zfs-based appliance); that doesn't happen for the 
I/O issued from the guest.

In my point of view, this is a big issue which may compromise data integrity in 
the event of a power failure or a generic HW fault in the storage BOX, which 
may lead to guest filesystems corruption due to the possibility of journal 
becoming corrupt. As a workaround I can obviously disable writeback cache on 
the target, but that leads to unwarranted performance loss (because every 
single I/O becomes synchronous, even there's no need to). Am I missing 
something ?

Some hypothesis I made:

- tapblk3 drops sync cache commands from the guest
- xen_blkfront into the domU ignores sync I/O semantics

I'm running version 6.5.0-90233c.

Any thoughts ?

BR,
Simone.

P.S: I already tried writing in the appropriate forum (the xenserver one), but 
without luck…I’m feeling a bit hopeless.
P.P.S: My apologize for the cross posting, but again I’m clueless.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

[Ian Campbell]

On Fri, 2015-10-23 at 17:55 +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection
> -step: Linky linky revision graph"):
> > On 23/10/15 17:46, Ian Jackson wrote:
> > > Yes, indeed.  It appears that your browser is rather poor :-).  (Most
> > > are...)
> > 
> > How is yours configured then, to do something sensible with a git://
> > uri ?
> 
> I did say most browsers were poor :-).
> 
> ISTM that this information is better than nothing.

For reasons best known to itself my version of firefox doesn't offer me the
"copy link location" option when right clicking these :-(

Otherwise I would suggest that the correct format would be "
" such that after copying the URL "git fetch " just does
the right thing(tm).

But the fact I can now highlight and copy the rev from the graph is very
valuable IMHO.

I'd be minded to suggest that the default HTML ought to include the SVG by
default.

Ian.

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

Re: [Xen-devel] [PATCH] cpufreq: allow ordinary boolean options to be passed on the command line

[Jan Beulich]

>>> On 30.10.15 at 20:22,  wrote:
> On 30/10/15 17:49, Jan Beulich wrote:
>> I was quite surprised to find "cpufreq=off" not doing what one would
>> expect it to do. Fix this.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/docs/misc/xen-command-line.markdown
>> +++ b/docs/misc/xen-command-line.markdown
>> @@ -391,11 +391,12 @@ If set, force use of the performance cou
>>  available support.
>>  
>>  ### cpufreq
>> -> `= dom0-kernel | none | 
>> xen[,[powersave|performance|ondemand|userspace][,][,[][,[verbose`
>> +> `= none | {{  | xen } 
>> [:[powersave|performance|ondemand|userspace][,][,[][,[verbose}
>>  | dom0-kernel`
> 
> If I am reading the parsing correctly below, the insertion if ':' is to
> match the previous behaviour? (or have I missed something?)

We've always supported , and : there. I do think that documenting
comma here is bad (since it's also used as the separator between
sub-options), and hence I've taken the opportunity to make this
match other command line options (where we generally use colon
for separation of main and sub-options).

Jan


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

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

[Jan Beulich]

>>> On 30.10.15 at 20:05,  wrote:
> On 30/10/15 17:46, Jan Beulich wrote:
>> Rather than issuing a (mostly) useless separate message, rely on
>> domain_crash() providing enough data, and leverage the line number
>> information it prints.
>>
>> Signed-off-by: Jan Beulich 
> 
> The messages are not completely useless, and they do save a round-trip
> to the debug symbols (which can be a very long RTT when dealing with
> customers).
> 
> I agree that moving the domain_crash()'s is a good idea, but can we get
> away with just demoing the gprintk()s to gdprintk()s ?

How would that aid with the customer case (who wouldn't normally run
debug hypervisors)?

Jan


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

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

[Jan Beulich]

>>> On 30.10.15 at 20:05,  wrote:
> On 30/10/15 17:46, Jan Beulich wrote:
>> Rather than issuing a (mostly) useless separate message, rely on
>> domain_crash() providing enough data, and leverage the line number
>> information it prints.
>>
>> Signed-off-by: Jan Beulich 
> 
> The messages are not completely useless, and they do save a round-trip
> to the debug symbols (which can be a very long RTT when dealing with
> customers).

Oh, also: Why would looking at the debug symbols be needed? You
get file name and line number printed.

Jan


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

Re: [Xen-devel] Question about XEN Hypervisor MSR capability exposion to VMs

[Andrew Cooper]

On 31/10/15 02:53, Liuyingdong wrote:
> Hi All
>
> We encountered a blue screen problem when live migrate
> Win8.1/Win2012R2 64bit VM from V3 processor to non-V3
> processor sandbox, KVM does not has this problem.
>
> After looking into the MSR capabilities, we found XEN
> hypervisor exposed bit 39 and bit 18 to the VM, from
> Intel manual bit 39 refers to reserve bit and should
> not be set, bit 18 refers to MWAIT/MONITOR capability,
> from my understanding it should not exposed to the VM
> too.
> BTW, KVM does not expose bit 18/39 to the VM.
>
> Below is the boot message:
> (XEN) read msr: ecx=c083, msr_value=0xf80028ddf240
> (XEN) read msr: ecx=1a0, msr_value=0x4000801889
> ~
> (XEN) write msr:msr=4071, msr_value=0x100082f
> (XEN) write msr:msr=4070, msr_value=0x0
> (XEN) write msr:msr=4071, msr_value=0x200082f
> (XEN) write msr:msr=4070, msr_value=0x0
> (XEN) read msr: ecx=17, msr_value=0x0
> (XEN) write msr:msr=8b, msr_value=0x0
> (XEN) read msr: ecx=8b, msr_value=0x2d
>

Xen currently does not make any attempt to level MSRs (it is unfortunate
that this area has been overlooked).

I have also encountered windows BSODs for this - 0x109 Critical
Structure Corruption I am guessing?

I am currently working on fixes to CPUID levelling (as it is more
important than MSRs at the moment), but have plans to fix MSR levelling
after that.

~Andrew

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

Re: [Xen-devel] [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[Dario Faggioli]

[Trimming the Cc list, and adding George, which I did not realize he 
 was not there!]

On Fri, 2015-10-30 at 11:00 -0600, Jan Beulich wrote:
> > > > On 30.10.15 at 17:33,  wrote:

> > Are you saying that we shouldn't make the change at all? Or that we
> > should make the change and also turn the BUG_ON() (the one that is
> > left
> > in place) into an ASSERT()? Or that we should not mark the function
> > as
> > 'inline'?
> 
> No, I'm suggesting that instead of this change the BUG_ON() (or
> perhaps both and also others) should be converted to ASSERT().
> 
I'm all in favour of turning these two (if both are staying) BUG_ON()s
in ASSERT()s.

What I especially don't like of the function right now, is that by
looking at the prototype, and at least at some of the call sites, it
feels like it is possible to insert a vCPU v in the runqueue of an
arbitrary pCPU, while that must always happens in v->processor's
runqueue. That is why I'd like to be able to remove that cpu argument.

Perhaps avoiding inlining can really be considered? Looking at history,
the function was shorter and called less times when originally
developed and marked as such. I'm not sure that's still a good thing...

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



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

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

[Andrew Cooper]

On 02/11/15 10:56, Jan Beulich wrote:
 On 30.10.15 at 20:05,  wrote:
>> On 30/10/15 17:46, Jan Beulich wrote:
>>> Rather than issuing a (mostly) useless separate message, rely on
>>> domain_crash() providing enough data, and leverage the line number
>>> information it prints.
>>>
>>> Signed-off-by: Jan Beulich 
>> The messages are not completely useless, and they do save a round-trip
>> to the debug symbols (which can be a very long RTT when dealing with
>> customers).
>>
>> I agree that moving the domain_crash()'s is a good idea, but can we get
>> away with just demoing the gprintk()s to gdprintk()s ?
> How would that aid with the customer case (who wouldn't normally run
> debug hypervisors)?

I suppose it wouldn't in the general case.

XenServer now ships both regular and debug hypervisors to short circuit
the first RTT when dealing with host crashes.  A side effect is that
guest crashes can be diagnosed more easily by switching to the debug
hypervisor.

~Andrew

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

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

[Andrew Cooper]

On 02/11/15 10:57, Jan Beulich wrote:
 On 30.10.15 at 20:05,  wrote:
>> On 30/10/15 17:46, Jan Beulich wrote:
>>> Rather than issuing a (mostly) useless separate message, rely on
>>> domain_crash() providing enough data, and leverage the line number
>>> information it prints.
>>>
>>> Signed-off-by: Jan Beulich 
>> The messages are not completely useless, and they do save a round-trip
>> to the debug symbols (which can be a very long RTT when dealing with
>> customers).
> Oh, also: Why would looking at the debug symbols be needed? You
> get file name and line number printed.

Any file patched will end up having a slide on the line number.  The use
of the debug symbols is necessary to confirm, especially in cases like
this where there are multiple possibilities close to each other.

~Andrew

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

Re: [Xen-devel] [linux-3.14 test] 63336: regressions - FAIL

[Julien Grall]

Hi Ian,

On 02/11/15 10:17, Ian Campbell wrote:
>> So shall we disable 3.14 job for ARM for once and all?
> 
> Given the above failure I don't think the ability to test the 3.14 kernels
> on the Cambridge instance is all that valuable. So yes, I think we should
> drop ARM from the linux-3.14 flights.

+1

> 
> We should also force push 3.14 if the above was the only failure.

This was the only blocking failure. The rest is under tolerable:

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-rumpuserxen-i386 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62648
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62648
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62648
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62648
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62648

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] cpufreq: allow ordinary boolean options to be passed on the command line

[Andrew Cooper]

On 02/11/15 10:54, Jan Beulich wrote:
 On 30.10.15 at 20:22,  wrote:
>> On 30/10/15 17:49, Jan Beulich wrote:
>>> I was quite surprised to find "cpufreq=off" not doing what one would
>>> expect it to do. Fix this.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/docs/misc/xen-command-line.markdown
>>> +++ b/docs/misc/xen-command-line.markdown
>>> @@ -391,11 +391,12 @@ If set, force use of the performance cou
>>>  available support.
>>>  
>>>  ### cpufreq
>>> -> `= dom0-kernel | none | 
>>> xen[,[powersave|performance|ondemand|userspace][,][,[][,[verbose`
>>> +> `= none | {{  | xen } 
>>> [:[powersave|performance|ondemand|userspace][,][,[][,[verbose}
>>>  | dom0-kernel`
>> If I am reading the parsing correctly below, the insertion if ':' is to
>> match the previous behaviour? (or have I missed something?)
> We've always supported , and : there. I do think that documenting
> comma here is bad (since it's also used as the separator between
> sub-options), and hence I've taken the opportunity to make this
> match other command line options (where we generally use colon
> for separation of main and sub-options).

Agreed.

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH] x86: make compat_iret() domain crash cases distinguishable

[Jan Beulich]

>>> On 02.11.15 at 12:10,  wrote:
> On 02/11/15 10:57, Jan Beulich wrote:
> On 30.10.15 at 20:05,  wrote:
>>> On 30/10/15 17:46, Jan Beulich wrote:
 Rather than issuing a (mostly) useless separate message, rely on
 domain_crash() providing enough data, and leverage the line number
 information it prints.

 Signed-off-by: Jan Beulich 
>>> The messages are not completely useless, and they do save a round-trip
>>> to the debug symbols (which can be a very long RTT when dealing with
>>> customers).
>> Oh, also: Why would looking at the debug symbols be needed? You
>> get file name and line number printed.
> 
> Any file patched will end up having a slide on the line number.  The use
> of the debug symbols is necessary to confirm, especially in cases like
> this where there are multiple possibilities close to each other.

But with version control and proper release numbering you ought to
be able to tell the exact state of the sources at the time the package
got built?

Jan


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

[Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

[Ross Lagerwall]

Previously, xenconsoled's daemonize function would do nothing if its
parent process is init (as it is under systemd but not sysv init).
This is confusing. Instead, always daemonize when asked to, but use the
"interactive" switch when running from the systemd service.

Because a pidfile is only written when daemonizing, drop the pidfile
parameters from the service file (systemd keeps track of the pids
anyway).

Signed-off-by: Ross Lagerwall 
---
 tools/console/daemon/utils.c   | 4 
 tools/hotplug/Linux/systemd/xenconsoled.service.in | 3 +--
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/tools/console/daemon/utils.c b/tools/console/daemon/utils.c
index dbb3b12..644f6af 100644
--- a/tools/console/daemon/utils.c
+++ b/tools/console/daemon/utils.c
@@ -52,10 +52,6 @@ void daemonize(const char *pidfile)
int i;
char buf[100];
 
-   if (getppid() == 1) {
-   return;
-   }
-
if ((pid = fork()) > 0) {
exit(0);
} else if (pid == -1) {
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in 
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cd282bf..8e333b1 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -10,10 +10,9 @@ Environment=XENCONSOLED_ARGS=
 Environment=XENCONSOLED_TRACE=none
 Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
 EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
-PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
 ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid 
--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled -i --log=${XENCONSOLED_TRACE} 
--log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
 
 [Install]
 WantedBy=multi-user.target
-- 
2.4.3


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

Re: [Xen-devel] [PATCH v4 00/10] xen-block: multi hardware-queues/rings support

[Julien Grall]

Hi Bob,

On 02/11/15 04:21, Bob Liu wrote:
> ---
> v4:
>  * Rebase to v4.3-rc7

xentip/for-linus-4.4 [1] contains a lot of change in xen-blkfront,
mainly to add support of 64KB page granularity.

I would advise you to rebase your series know as some part of the code
may have changed.

Regards,

[1]
https://git.kernel.org/cgit/linux/kernel/git/xen/tip.git/log/?h=for-linus-4.4

-- 
Julien Grall

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

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

[Andrew Cooper]

On 02/11/15 08:03, Tian, Kevin wrote:
> Let's start a new thread with a summary of previous discussion, and 
> then our latest experiment data and updated proposal.
>
> From previous discussions, it's suggested that a spin model is accepted, 
> only when spin timeout doesn't exceed the order of a scheduling time 
> slice, or other blocking operations like what WBINVD might take. 
> Otherwise async-flush model is preferred to prevent misbehaving guests 
> taking long spins if possible, to impact whole system.
>
> Below are some thresholds to be considered:
>
> 1) scheduling time slice in Credit is 1ms.

1ms is the minimum scheduling timeslice.  30ms is the current default
(not that this should affect the following reasoning).

>
> 2) WBINVD cost is 4.6ms in worst case on an IVT platform (32 cores, 
> 10GB NIC assigned to the VM, running iperf). Detail data is append in 
> the bottom. Actual cost varies on different platforms, due to different 
> cache size/layout. For example, we also heard from other colleagues 
> about 10ms level cost on another platform.
>
> 3) PCI SIG strongly recommends that Completion Timeout mechanism
> not expire in less than 10ms (PCIe 3.0 spec, 7.8.15, Device Capabilities
> 2 Register). It means CPU MMIO read might already take >10ms which 
> we just didn't note.
>
> Based on above information, at least we can think a timeout range
> between [1ms, 10ms] would likely not introduce bad system behavior. 
> Or conservatively, we can define the spin timeout default as 1ms, 
> while allowing boot-time override up to 10ms for more flexibility.
>
> Then regarding to VT-d flush:
>
> - For context/iotlb/iec flush, our measurements show worst cases
> <10us. We also confirmed with hardware team, that 1ms is large 
> enough for IOMMU internal flush.
>
> - For ATS device-TLB flush, PCI spec defines up to 60s, but:
>
>   * Our hardware team confirms that 1ms should be enough for 
> integrated PCI devices w/ ATS.
>
>   * for discrete PCI devices w/ ATS, it's uncertain whether 1ms 
> or 10ms is too restrictive to them, but there are only a few devices
> now in the market. 
>
> Based on above information, we propose to continue spin-timeout
> model w/ some adjustment, which fixes current timeout concern
> and also allows limited ATS support in a light way:
>
> 1) reduce spin timeout to 1ms, which can be boot-time changed
> up to 10ms.

If this is going to be command line configurable, don't have an upper limit.

Given the uncertainty with external devices, it might be necessary to
experiment with timeouts greater than 10ms.

>
> 2) if timeout expires, kill the VM which the target device is assigned 
> to. Optionally hypervisor may mark device non-assignable.
>
> It works for devices w/o ATS. It works for integrated devices w/ ATS.
> It might or might not work for discrete devices w/ ATS, but we can
> re-evaluate the gain vs. software complexity of async flush until we 
> see many discrete devices breaking the timeout assumptions in the 
> future.
>
> Thoughts?

As presented, this is probably an improvement, but I am concerning with
the case of external devices.

Then again, as none of this currently works at all, we are not in a
worse state.

~Andrew

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

Re: [Xen-devel] [PATCH] Handles the error returned by the xc_dom_allocate function

[Ian Campbell]

On Mon, 2015-10-26 at 10:40 +, Wei Liu wrote:

> > +   return -1;
> 
> And, please set rv to a proper error code (presumably ENOMEM)

Please don't, xc_* functions should return -1 or NULL and set errno on
failure. (libxc error reporting is a bit of a mess, but this is the
intention).

So the caller here can assume that errno has already been set to something
appropriate (probably ENOMEM) and it is fine to translate the NULL into a 
-1 since the overall function returns an int not a pointer.

>  and use goto err, otherwise you're leaking xs_fd.

This is good advise and implies that rv should be set to -1 before the
goto.


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

Re: [Xen-devel] [PATCH v3] dom variable error handled in Xenstore

[Ian Campbell]

On Fri, 2015-10-30 at 15:28 +0100, Dario Faggioli wrote:
> On Thu, 2015-10-29 at 20:28 +0530, Lasya Venneti wrote:
> > 
> > 
> > On 29 October 2015 at 15:41, Dario Faggioli <
> > dario.faggi...@citrix.com> wrote:
> > > On Thu, 2015-10-29 at 10:07 +, Wei Liu wrote:
> 
> > > > As for xc_dom_allocate, the only failure path at the moment is
> > > malloc
> > > > failure, which would be appropriate to use ENOMEM to represent.
> > > > 
> > > > However if it causes too many faffs, you can just set rv to -1
> > > and
> > > > return to caller. I think the main point is to handle the error,
> > > > either
> > > > -1 or ENOMEM is fine by me.
> > > > 
> > > Agreed but, I personally prefer -1, for consistency. :-)
> > > 
> > So should I proceed with -1? In that case I don't need to add the
> > header...
> >  
> If you're still up for this (and for the other patch, which would be
> great!), yes, go for -1.

Per my reply to v1 (still catching up on email backlog) yes, -1 is the
correct thing to use here. ENOMEM is actively wrong.

Ian.

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

Re: [Xen-devel] [PATCH] xen: credit1: on vCPU wakeup, kick away current only if makes sense

[George Dunlap]

On 29/10/15 10:57, Dario Faggioli wrote:
> In fact, when waking up a vCPU, __runq_tickle() is called
> to allow the new vCPU to run on a pCPU (which one, depends
> on the relationship between the priority of the new vCPU,
> and the ones of the vCPUs that are already running).
> 
> If there is no idle processor on which the new vCPU can
> run (e.g., because of pinning/affinity), we try to migrate
> away the vCPU that is currently running on the new vCPU's
> processor (i.e., the processor on which the vCPU is waking
> up).
> 
> Now, trying to migrate a vCPU has the effect of pushing it
> through a
> 
>  running --> offline --> runnable
> 
> transition, which, in turn, has the following negative
> effects:
> 
>  1) Credit1 counts that as a wakeup, and it BOOSTs the
> vCPU, even if it is a CPU-bound one, which wouldn't
> normally have deserved boosting. This can prevent
> legit IO-bound vCPUs to get ahold of the processor
> until such spurious boosting expires, hurting the
> performance!
> 
>  2) since the vCPU is fails the vcpu_runnable() test
> (within the call to csched_schedule() that follows
> the wakeup, as a consequence of tickling) the
> scheduling rate-limiting mechanism is also fooled,
> i.e., the context switch happens even if less than
> the minimum execution amount of time passed.
> 
> In particular, 1) has been reported to cause the following
> issue:
> 
>  * VM-IO: 1-vCPU pinned to a pCPU, running netperf
>  * VM-CPU: 1-vCPU pinned the the same pCPU, running a busy
>CPU loop
>  ==> Only VM-I/O: throughput is 806.64 Mbps
>  ==> VM-I/O + VM-CPU: throughput is 166.50 Mbps
> 
> This patch solves (for the above scenario) the problem
> by checking whether or not it makes sense to try to
> migrate away the vCPU currently running on the processor.
> In fact, if there aren't idle processors where such a vCPU
> can execute. attempting the migration is just futile
> (harmful, actually!).
> 
> With this patch, in the above configuration, results are:
> 
>  ==> Only VM-I/O: throughput is 807.18 Mbps
>  ==> VM-I/O + VM-CPU: throughput is 731.66 Mbps
> 
> Reported-by: Kun Suo 
> Signed-off-by: Dario Faggioli 
> Tested-by: Kun Suo 

I'm getting a bit worried about how long the path is to actually wake up
a vcpu; if this only affected the "pin" case, then I might say it wasn't
worth it.  But it looks to me like this could be a consistent pattern on
any system where there was consistently no idlers available; so at this
point it's probably better to have than not:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Ian Campbell]

On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> The xenbus thread didn't send notification to other end when it expected
> more data or consumed responses, which led to stalling the ring from
> time to time.
> 
> This is the culprit that guest was less responsive when using stubdom
> because the device model was stalled.
> 
> Fix this by sending notification to the other end at the right places.

Could any of this code benefit from using the various macros in ring.h
which produce or consume entries on the ring and return a _notify bit?

> 
> Signed-off-by: Wei Liu 
> ---
> Cc: Ian Campbell 
> Cc: Ian Jackson 
> Cc: Samuel Thibault 
> 
> With this path I can migrate a guest with stubdom a few thousand times
> without any issue, while before I could easily trigger time out
> within a few iterations. This should make OSSTest stubdom test case more
> reliable.
> 
> Ian J, this is a patch suitable for backporting to 4.6. It's good time
> to branch mini-os now.
> ---
>  xenbus/xenbus.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/xenbus/xenbus.c b/xenbus/xenbus.c
> index 4613ed6..7451161 100644
> --- a/xenbus/xenbus.c
> +++ b/xenbus/xenbus.c
> @@ -205,8 +205,10 @@ static void xenbus_thread_func(void *ign)
>  prod = xenstore_buf->rsp_prod;
>  DEBUG("Rsp_cons %d, rsp_prod %d.\n", xenstore_buf->rsp_cons,
>  xenstore_buf->rsp_prod);
> -if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> sizeof(msg))
> +if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> sizeof(msg)) {
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  break;
> +}
>  rmb();
>  memcpy_from_ring(xenstore_buf->rsp,
>  &msg,
> @@ -217,8 +219,10 @@ static void xenbus_thread_func(void *ign)
>  xenstore_buf->rsp_prod - xenstore_buf->rsp_cons,
>  msg.req_id);
>  if (xenstore_buf->rsp_prod - xenstore_buf->rsp_cons <
> -sizeof(msg) + msg.len)
> +sizeof(msg) + msg.len) {
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  break;
> +}
>  
>  DEBUG("Message is good.\n");
>  
> @@ -265,6 +269,9 @@ static void xenbus_thread_func(void *ign)
>  xenstore_buf->rsp_cons += msg.len + sizeof(msg);
>  wake_up(&req_info[msg.req_id].waitq);
>  }
> +
> +wmb();
> +notify_remote_via_evtchn(start_info.store_evtchn);
>  }
>  }
>  }

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

Re: [Xen-devel] [PATCH 1/4] x86/PoD: Make p2m_pod_empty_cache() restartable

[George Dunlap]

On 30/10/15 18:33, Andrew Cooper wrote:
> This avoids a long running operation when destroying a domain with a
> large PoD cache.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 


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

[Xen-devel] [PATCH v9] run QEMU as non-root

[Stefano Stabellini]

Try to use "xen-qemudepriv-domid$domid" first, then
"xen-qemudepriv-shared" and root if everything else fails.

The uids need to be manually created by the user or, more likely, by the
xen package maintainer.

Expose a device_model_user setting in libxl_domain_build_info, so that
opinionated callers, such as libvirt, can set any user they like. Do not
fall back to root if device_model_user is set. Users can also set
device_model_user by hand in the xl domain config file.

QEMU is going to setuid and setgid to the user ID and the group ID of
the specified user, soon after initialization, before starting to deal
with any guest IO.

To actually secure QEMU when running in Dom0, we need at least to
deprivilege the privcmd and xenstore interfaces, this is just the first
step in that direction.

Signed-off-by: Stefano Stabellini 

---

Changes in v9:
- add a device_model_user option to the xl domain config file

Changes in v8:
- no need to pass the -runas option if the user requested for root
- return ERROR_FAIL from libxl__dm_runas_helper in case of errors
- return NULL from libxl__build_device_model_args_new if libxl__dm_runas_helper 
failed
- fix line too long
- remove setting errno
- replace retry goto loop, with a while loop
- const char * as argument to libxl__dm_runas_helper
- fix comment

Changes in v7:
- do not fall back to root if the user explicitly set
b_info->device_model_user.

Changes in v6:
- add device_model_user to libxl_domain_build_info
- improve doc
- improve wording in commit message

Changes in v5:
- improve wording in doc
- fix wording in warning message
- fix example in doc
- drop xen-qemudepriv-$domname

Changes in v4:
- rename qemu-deprivilege to qemu-deprivilege.txt
- add a note about qemu-deprivilege.txt to INSTALL
- instead of xen-qemudepriv-base + $domid, try xen-qemudepriv-domid$domid
- introduce libxl__dm_runas_helper to make the code nicer

Changes in v3:
- clarify doc
- handle errno == ERANGE
---
 INSTALL  |7 +
 docs/man/xl.cfg.pod.5|5 
 tools/libxl/libxl.h  |5 
 tools/libxl/libxl_dm.c   |   67 +-
 tools/libxl/libxl_internal.h |5 
 tools/libxl/libxl_types.idl  |1 +
 tools/libxl/xl_cmdimpl.c |3 ++
 7 files changed, 92 insertions(+), 1 deletion(-)

diff --git a/INSTALL b/INSTALL
index 56e2950..b7e426c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -304,6 +304,13 @@ systemctl enable xendomains.service
 systemctl enable xen-watchdog.service
 
 
+QEMU Deprivilege
+
+It is recommended to run QEMU as non-root.
+See docs/misc/qemu-deprivilege.txt for an explanation on what you need
+to do at installation time to run QEMU as a dedicated user.
+
+
 History of options
 ==
 
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index d422924..615822a 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -1785,6 +1785,11 @@ Pass additional arbitrary options on the device-model 
command line for
 an HVM device model only. Each element in the list is passed as an
 option to the device-model.
 
+=item B
+
+Run the device model as user "username", instead of
+xen-qemudepriv-domid$domid or xen-qemudepriv-shared or root.
+
 =back
 
 =head2 Keymaps
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index fa5aedd..108e8fa 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -204,6 +204,11 @@
  */
 #define LIBXL_HAVE_BUILDINFO_ARM_GIC_VERSION 1
 
+/* libxl_domain_build_info has device_model_user to specify the user to
+ * run the device model with. See docs/misc/qemu-deprivilege.txt.
+ */
+#define LIBXL_HAVE_DEVICE_MODEL_USER 1
+
 /*
  * libxl ABI compatibility
  *
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 89b3bb7..0f1fdcc 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -19,6 +19,8 @@
 
 #include "libxl_internal.h"
 #include 
+#include 
+#include 
 
 static const char *libxl_tapif_script(libxl__gc *gc)
 {
@@ -700,6 +702,36 @@ static char *dm_spice_options(libxl__gc *gc,
 return opt;
 }
 
+/* return 1 if the user was found, 0 if it was not, -1 on error */
+static int libxl__dm_runas_helper(libxl__gc *gc, const char *username)
+{
+struct passwd pwd, *user = NULL;
+char *buf = NULL;
+long buf_size;
+int ret;
+
+buf_size = sysconf(_SC_GETPW_R_SIZE_MAX);
+if (buf_size < 0) {
+LOGE(ERROR, "sysconf(_SC_GETPW_R_SIZE_MAX) returned error %ld",
+buf_size);
+return ERROR_FAIL;
+}
+
+while (1) {
+buf = libxl__realloc(gc, buf, buf_size);
+ret = getpwnam_r(username, &pwd, buf, buf_size, &user);
+if (ret == ERANGE) {
+buf_size += 128;
+continue;
+}
+if (ret != 0)
+return ERROR_FAIL;
+if (user != NULL)
+return 1;
+return 0;
+}
+}
+
 static int libxl__build_device_model_args_new(libxl__gc *gc,
 

Re: [Xen-devel] [PATCH] sched_credit: Remove cpu argument to __runq_insert()

[Wei Liu]

On Fri, Oct 30, 2015 at 06:01:36PM +0100, Dario Faggioli wrote:
> On Fri, 2015-10-30 at 22:20 +0530, Harmandeep Kaur wrote:
> > On Fri, Oct 30, 2015 at 10:16 PM, Dario Faggioli <
> > dario.faggi...@citrix.com> wrote:
> > > The list of people you Cc-ed, is not really accurate. In fact, Ian
> > > Campbell and Ian Jackson are toolstack maintainers, and even Jan,
> > > Keir
> > > and Tim, although they are hypervisors maintainers, should not need
> > > to
> > > be bothered by a patch touching only sched_credit.c.
> > > 
> > > Have a look at the MAINTAINERS file and at
> > > scripts/get_maintainer.pl.
> >  
> > I did ./scripts/get_maintainer.pl -f xen/common/. 
> >
> Why the "-f xen/common/." ?  I've never used it like that, so I don't
> know what output should have been expected from it.
> 

That's useful when you want to derive list of maintainers from a file.

The actual rune Harmandeep needs should be

  ./scripts/get_maintainer.pl -f xen/common/sched_credit.c

Using "." makes that script point to "The rest" maintainers. There is a
note in the help string of that script:

Notes:
  Using "-f directory" may give unexpected results ...

Wei.

> What I usually do is `cat  | ./scripts/get_maintainer.pl', and
> most of the time the answer I get makes sense.
> 
> Regards,
> Dario
> -- 
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



> ___
> 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] [PATCH 0/4] xen/public: arm: rework set_xen_guest_handle_raw

[Jan Beulich]

>>> On 30.10.15 at 19:13,  wrote:
> This series is based on the patch sent by Jan Beulich to drop
> get_xen_guest_handle [2]. But I wasn't able to apply it cleanly on
> unstable, so I've provided a branch with this patch and this series:
> 
> git://xenbits.xen.org/people/julieng/xen-unstable.git branch guest-handle-v1

Odd - the patch still appears to apply fine to current staging.

Jan


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

Re: [Xen-devel] [PATCH] xen: credit1: on vCPU wakeup, kick away current only if makes sense

[Dario Faggioli]

On Mon, 2015-11-02 at 12:03 +, George Dunlap wrote:
> On 29/10/15 10:57, Dario Faggioli wrote:

> > In particular, 1) has been reported to cause the following
> > issue:
> > 
> >  * VM-IO: 1-vCPU pinned to a pCPU, running netperf
> >  * VM-CPU: 1-vCPU pinned the the same pCPU, running a busy
> >CPU loop
> >  ==> Only VM-I/O: throughput is 806.64 Mbps
> >  ==> VM-I/O + VM-CPU: throughput is 166.50 Mbps
> > 
> > This patch solves (for the above scenario) the problem
> > by checking whether or not it makes sense to try to
> > migrate away the vCPU currently running on the processor.
> > In fact, if there aren't idle processors where such a vCPU
> > can execute. attempting the migration is just futile
> > (harmful, actually!).
> > 
> > With this patch, in the above configuration, results are:
> > 
> >  ==> Only VM-I/O: throughput is 807.18 Mbps
> >  ==> VM-I/O + VM-CPU: throughput is 731.66 Mbps
> > 
> > Reported-by: Kun Suo 
> > Signed-off-by: Dario Faggioli 
> > Tested-by: Kun Suo 
> 
> I'm getting a bit worried about how long the path is to actually wake
> up
> a vcpu; if this only affected the "pin" case, then I might say it
> wasn't
> worth it.  
>
Same here. That's why I started looking at a solution that was more
general that the pinned scenario, for which it wasn't worth adding
complexity in the wakeup path.

I've got a patch for that almost ready (avoiding boosting in case of
wakeups induced by a migration).

However, while working on that, I realized...

> But it looks to me like this could be a consistent pattern on
> any system where there was consistently no idlers available; so at
> this
> point it's probably better to have than not:
> 
...exactly this. I.e., it's not only the pinned case. Even 'free' 
vCPUs, or vCPUs with arbitrary large affinities, if the system is busy,
can incur into this sort of spurious migration attempts, with takes
time (migrate-->pick-->wake-->tickle-->rescheduling), and yet leaves
the situation unchanged (with the fix I'm preparing; without, it causes
the reported anomaly).

At that point, this, and the boosting after migration, became two
orthogonal issues, both needing fixing. :-/

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



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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Ian Campbell]

On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote:
> When oxenstored wrote to the ring, it wrote a chunk of contiguous data.
> Originally when it tried to write across ring boundary, it returned a
> short-write when there is still room.  That led to stalling mini-os's
> xenstore thread at times.

What is a "short-write" in this context?

Given data bytes 0..M I assumed it is only writing bytes 0..N and not
N+1..M because the ring boundary is at N. But what is it writing to the
->prod ring pointer N or M?

AIUI writing N should be allowed by the ring protocol, the client should
keep looking for more data until it has a complete request.

Writing M would be a server error.

Ian.


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

Re: [Xen-devel] [PATCH 3/4] xen/public: Don't expose XEN_GUEST_HANDLE_PARAM outside of the hypervisor

[Jan Beulich]

>>> On 30.10.15 at 19:13,  wrote:
> A XEN_GUEST_HANDLE_PARAM is used to represent a guest pointer passed as
> an hypercall register. It will always be the size of a native register.
> 
> This is only used in Xen for type-safety, the guest will directly pass a
> pointer in the hypercall parameter.
> 
> Note that for ARM we only hide XEN_GUEST_HANDLE_PARAM. The type
> __guest_handle_param_* is still exposed because it would result to
> duplicating the macro to create the type. I find this solution more
> difficult to read.
> 
> Signed-off-by: Julien Grall 

With the comment coding style issue (missing full stop) fixed
Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 0/4] xen/public: arm: rework set_xen_guest_handle_raw

[Julien Grall]

On 02/11/15 13:42, Jan Beulich wrote:
 On 30.10.15 at 19:13,  wrote:
>> This series is based on the patch sent by Jan Beulich to drop
>> get_xen_guest_handle [2]. But I wasn't able to apply it cleanly on
>> unstable, so I've provided a branch with this patch and this series:
>>
>> git://xenbits.xen.org/people/julieng/xen-unstable.git branch guest-handle-v1
> 
> Odd - the patch still appears to apply fine to current staging.

FWIW:

julien@chilopoda:~/works/xen> git am /tmp/\[PATCH\]\ drop\ 
get_xen_guest_handle\(\).eml
Applying: drop get_xen_guest_handle()
error: patch failed: xen/arch/x86/sysctl.c:31
error: xen/arch/x86/sysctl.c: patch does not apply
error: patch failed: xen/arch/x86/x86_64/cpu_idle.c:21
error: xen/arch/x86/x86_64/cpu_idle.c: patch does not apply
error: patch failed: xen/include/public/arch-arm.h:195
error: xen/include/public/arch-arm.h: patch does not apply
error: patch failed: xen/include/public/arch-x86/xen.h:54
error: xen/include/public/arch-x86/xen.h: patch does not apply
Patch failed at 0001 drop get_xen_guest_handle()
The copy of the patch that failed is found in:
   /home/julien/works/xen/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

-- 
Julien Grall

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

[Xen-devel] [VOTE] Release cycle scheme

[Wei Liu]

Hi committers,

There doesn't seem to be consensus on how release cycle should be
managed. In the survey [0] about release cycle there were following
proposed schemes:

#1. 6 months release cycle + current stable release scheme
#2. 6 months release cycle + LTS scheme
#3. 6 months release cycle + extended security support
#4. 9 months release cycle + current stable release scheme (no change
at all)

And the tally:

#1  #2  #3  #4
George  +1  +2  -2
Dario   +1  +2  -2
Stefano +1  +2  -2
Ian C   +1  +1  +1  -1
Olaf+1   0  +1   0
Juergen  0  -1  +1
Ian J   +2  +1  +1  -2
Andrew  +1  +1  -1
Jan -1  -1   0  +1


There are comments made by individuals that couldn't be clearly
represent in tally. The most acceptable option to stable tree
maintainers is #1.

So I propose we use the following scheme:

- 6 months release cycle from unstable branch.
  - 4 months development.
  - 2 months freeze.
  - Eat into next cycle if doesn't release on time.
- Fixed cut-off date: the Fridays of the week in which the last day of
  March and September falls.
- No more freeze exception, but heads-up mails about freeze will be
  sent a few weeks before hand.
- Stable branch maintained for 18 months full support plus 18 months
  security support. No mixed maintainership for stable trees.


Please vote to ack or nack this proposal.


Thanks
Wei.

[0]: <20151012173222.ge2...@zion.uk.xensource.com>

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Ian Campbell]

On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote:
> This requires adjustments to the tool generating the symbol table and
> its as well as nm's invocation.
> 
> Note: Not warning about duplicate symbols in the EFI case for now, as
> a binutils bug causes misnamed file name entries to appear in EFI
> binaries' symbol tables when the file name is longer than 18 chars.
> (Not doing so also avoids other duplicates getting printed twice.)
> 
> Signed-off-by: Jan Beulich 
> ---
> v2: Also special case file names with directory part (along with
> object ones). Mirror xen-syms linking changes to ARM, but for now
> without generating warnings.

Thanks for taking care of ARM. I assume "without generating warnings"
differs from the x86 behaviour? Is there some followup which us ARM folks
ought to be looking into making?

Ian.

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

Re: [Xen-devel] Ping: [PATCH] use clear_domain_page() instead of open coding it

[Ian Campbell]

On Mon, 2015-10-26 at 07:06 -0600, Jan Beulich wrote:
> > > > On 19.10.15 at 16:51,  wrote:
> 
> "REST" maintainers, could I please get an ack or otherwise on this
> common code change?
> 
> Thanks, Jan
> 
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -1959,22 +1959,16 @@ __initcall(pagealloc_keyhandler_init);
> >  
> >  void scrub_one_page(struct page_info *pg)
> >  {
> > -void *p;
> > -
> >  if ( unlikely(pg->count_info & PGC_broken) )
> >  return;
> >  
> > -p = __map_domain_page(pg);
> > -
> >  #ifndef NDEBUG
> >  /* Avoid callers relying on allocations returning zeroed pages. */
> > -memset(p, 0xc2, PAGE_SIZE);
> > +unmap_domain_page(memset(__map_domain_page(pg), 0xc2, PAGE_SIZE));

I'm not madly keep on this clever nesting of the map/memset/unmap and would
have preferred a more localised void *p (or a memset_domain_page helper
maybe), but I don't mind enough to block this over:

Acked-by: Ian Campbell 

> >  #else
> >  /* For a production build, clear_page() is the fastest way to
> > scrub. */
> > -clear_page(p);
> > +clear_domain_page(_mfn(page_to_mfn(pg)));
> >  #endif
> > -
> > -unmap_domain_page(p);
> >  }
> >  
> >  static void dump_heap(unsigned char key)
> 
> 
> 

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

Re: [Xen-devel] [PATCH 3/4] xen/public: Don't expose XEN_GUEST_HANDLE_PARAM outside of the hypervisor

[Stefano Stabellini]

On Mon, 2 Nov 2015, Jan Beulich wrote:
> >>> On 30.10.15 at 19:13,  wrote:
> > A XEN_GUEST_HANDLE_PARAM is used to represent a guest pointer passed as
> > an hypercall register. It will always be the size of a native register.
> > 
> > This is only used in Xen for type-safety, the guest will directly pass a
> > pointer in the hypercall parameter.
> > 
> > Note that for ARM we only hide XEN_GUEST_HANDLE_PARAM. The type
> > __guest_handle_param_* is still exposed because it would result to
> > duplicating the macro to create the type. I find this solution more
> > difficult to read.
> > 
> > Signed-off-by: Julien Grall 
> 
> With the comment coding style issue (missing full stop) fixed
> Acked-by: Jan Beulich 

Same here

Acked-by: Stefano Stabellini 

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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

[Jan Beulich]

>>> On 30.10.15 at 19:33,  wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned")
>  static bool_t __initdata opt_hap_enabled = 1;
>  boolean_param("hap", opt_hap_enabled);
>  
> +bool_t opt_pod_enabled = 1;

__read_mostly?

> --- a/xen/common/memory.c
> +++ b/xen/common/memory.c
> @@ -818,6 +818,10 @@ long do_memory_op(unsigned long cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg)
>  if ( unlikely(start_extent >= reservation.nr_extents) )
>  return start_extent;
>  
> +if ( unlikely(!opt_pod_enabled) &&
> + (reservation.mem_flags & XENMEMF_populate_on_demand) )
> +return start_extent;

A few lines down we can see that XENMEMF_populate_on_demand
gets honored only for XENMEM_populate_physmap. Perhaps you
shouldn't fail the other two which ignore the flag anyway? And
perhaps you should also fold this into the existing check?

Also I don't think this is going to build on ARM.

Jan


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

Re: [Xen-devel] [PATCH] drop get_xen_guest_handle()

[Ian Campbell]

On Tue, 2015-10-27 at 02:04 -0600, Jan Beulich wrote:
> Its use in the tools (and its apparent abuse in the hypervisor) are
> long gone.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Jan Beulich]

>>> On 02.11.15 at 14:47,  wrote:
> On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote:
>> This requires adjustments to the tool generating the symbol table and
>> its as well as nm's invocation.
>> 
>> Note: Not warning about duplicate symbols in the EFI case for now, as
>> a binutils bug causes misnamed file name entries to appear in EFI
>> binaries' symbol tables when the file name is longer than 18 chars.
>> (Not doing so also avoids other duplicates getting printed twice.)
>> 
>> Signed-off-by: Jan Beulich 
>> ---
>> v2: Also special case file names with directory part (along with
>> object ones). Mirror xen-syms linking changes to ARM, but for now
>> without generating warnings.
> 
> Thanks for taking care of ARM. I assume "without generating warnings"
> differs from the x86 behaviour? Is there some followup which us ARM folks
> ought to be looking into making?

Not right now I would say. As mentioned elsewhere, without
xSplice as a goal I don't see much use in the having those warnings.

Jan


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

Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

[Ian Campbell]

On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
> Recent ld warns about libxenlight.so's dependency libraries not being
> available, which can be easily avoided by not just passing the raw
> library name on ld's command line.

> In the course of checking how things fit together (I originally
> suspected the warning to come from the linking of xl) I also noticed a
> stray L in SHLIB_libxenguest, which gets removed at once.

Looks like I (unwittingly) fixed this aspect in

http://lists.xen.org/archives/html/xen-devel/2015-10/msg02256.html
too. I can easily rebase.

Since you have a pickier ld than me I wonder if you would mind trying my patch 
out on top of yours too?

> Signed-off-by: Jan Beulich 

Acked-by: Ian Campbell 

> --- a/tools/Rules.mk
> +++ b/tools/Rules.mk
> @@ -40,7 +40,7 @@ SHLIB_libxenctrl  = -Wl,-rpath-link=$(XE
>  
>  CFLAGS_libxenguest = -I$(XEN_LIBXC)/include $(CFLAGS_xeninclude)
>  LDLIBS_libxenguest = $(XEN_LIBXC)/libxenguest$(libextension)
> -SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
> +SHLIB_libxenguest  = -Wl,-rpath-link=$(XEN_LIBXC)
>  
>  CFLAGS_libxenstore = -I$(XEN_XENSTORE)/include $(CFLAGS_xeninclude)
>  LDLIBS_libxenstore = $(XEN_XENSTORE)/libxenstore$(libextension)
> --- a/tools/libxl/Makefile
> +++ b/tools/libxl/Makefile
> @@ -41,7 +41,7 @@ LDFLAGS += $(PTHREAD_LDFLAGS)
>  LIBXL_LIBS += $(PTHREAD_LIBS)
>  LIBXL_LIBS += $(LIBXL_LIBS-y)
>  
> -LIBXLU_LIBS = libxenlight.so
> +LIBXLU_LIBS = $(LDLIBS_libxenlight)
>  
>  LIBXL_OBJS-y = osdeps.o libxl_paths.o libxl_bootloader.o flexarray.o
>  ifeq ($(LIBXL_BLKTAP),y)
> 
> 
> 

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

Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion

[George Dunlap]

On 30/10/15 18:33, Andrew Cooper wrote:
> p2m_pod_demand_populate() can be entered repeatedly during a single path
> through the hypervisor, e.g. on a toolstack batch map operation.
> 
> The domain might be crashed, but the interface currently lacks a way of
> passing an error back through the generic p2m layer.
> 
> Longterm the p2m layer needs reworking to allow errors to be returned, but in
> the short term, avoid repeatedly re-sweeping the domain after it has already
> been crashed from PoD exhaustion.
> 
> Signed-off-by: Andrew Cooper 
> ---
> CC: Jan Beulich 
> CC: George Dunlap 
> ---
>  xen/arch/x86/mm/p2m-pod.c | 3 ++-
>  xen/include/asm-x86/p2m.h | 2 ++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
> index be15cf3..6fb054f 100644
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -1048,7 +1048,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, 
> unsigned long gfn,
>  /* This check is done with the pod lock held.  This will make sure that
>   * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
>   * won't start until we're done. */
> -if ( unlikely(d->is_dying) )
> +if ( unlikely(d->is_dying) || p2m->pod.dead )

So after getting lost in a maze of twisty passages, it looks like
"d->is_dying" might be the wrong thing to check here.  d->is_dying is
*only* set, AFAICT, in two places:
 - in domain_kill(), which is only called for XEN_DOMCTL_destroydomain
 - in domain_create(), if the creation failed for some reason.

Would it make more sense to check d->is_shutting_down instead?

Having some sort of pod-specific flag seems like the wrong solution.

 -George


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

Re: [Xen-devel] [PATCH 3/4] x86/mm: Return -ESRCH for an invalid foreign domid

[George Dunlap]

On 30/10/15 18:33, Andrew Cooper wrote:
> For consistency with all other invalid domid handling.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 


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

Re: [Xen-devel] Revisit VT-d asynchronous flush issue

[Jan Beulich]

>>> On 02.11.15 at 09:03,  wrote:
> Based on above information, we propose to continue spin-timeout
> model w/ some adjustment, which fixes current timeout concern
> and also allows limited ATS support in a light way:
> 
> 1) reduce spin timeout to 1ms, which can be boot-time changed
> up to 10ms.
> 
> 2) if timeout expires, kill the VM which the target device is assigned 
> to. Optionally hypervisor may mark device non-assignable.
> 
> It works for devices w/o ATS. It works for integrated devices w/ ATS.
> It might or might not work for discrete devices w/ ATS, but we can
> re-evaluate the gain vs. software complexity of async flush until we 
> see many discrete devices breaking the timeout assumptions in the 
> future.
> 
> Thoughts?

Yes, let's take this approach as a first step at least.

Jan


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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Andrew Cooper]

On 02/11/15 13:44, Ian Campbell wrote:
> On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote:
>> When oxenstored wrote to the ring, it wrote a chunk of contiguous data.
>> Originally when it tried to write across ring boundary, it returned a
>> short-write when there is still room.  That led to stalling mini-os's
>> xenstore thread at times.
> What is a "short-write" in this context?
>
> Given data bytes 0..M I assumed it is only writing bytes 0..N and not
> N+1..M because the ring boundary is at N. But what is it writing to the
> ->prod ring pointer N or M?

Prod gets incremented by N in this case.

>
> AIUI writing N should be allowed by the ring protocol, the client should
> keep looking for more data until it has a complete request.
>
> Writing M would be a server error.

Correct, and this is what is happening.

The server (believes) that the ring is full, when it is not.  It waits
for the client to make more space in the ring, while the client is
waiting for the server to complete its message in the ring, thus stalling.

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH] build_clone: git clean newly cloned trees

[Ian Campbell]

On Thu, 2015-10-29 at 16:01 +, Andrew Cooper wrote:
> On 29/10/15 15:57, Ian Jackson wrote:
> > This may seem redundant, however:
> > 
> > git does not track empty directories.  So it can happen that a
> > directory is created as part of `git clone', but is empty in the
> > revision switched to with `git checkout'.
> > 
> > In this situation, the tree we are going to build ought not to contain
> > this directory, because that directory will not (in general) be
> > produced, eg when the revision being switched to becomes master.
> > 
> > We can use git clean to produce a working tree whose contents -
> > including the presence or absence of empty directories - depends only
> > on the commit we are trying to check out, and not on the previous
> > states of the git history or working tree.
> > 
> > For example, if a directory is made empty (ie, deleted, since git does
> > not distinguish) in xen.git#staging, osstest's clones of
> > xen.git#master will produce the directory, but `git checkout' of
> > staging won't delete it.  If the xen.git build system mistakenly
> > depends on this directory, we won't detect this until the deletion
> > reaches master.  This situation actually occurred with xen.git#598e97f
> > "tools/python: remove broken xl binding" (fixed in b261366f).
> > 
> > Signed-off-by: Ian Jackson 
> > CC: Andrew Cooper 
> 
> Reviewed-by: Andrew Cooper 

Acked-by: Ian Campbell 



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

[Xen-devel] [xen-unstable baseline-only test] 38238: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-pygrub 20 guest-start/debian.repeat fail blocked in 38227
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 38227
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 38227
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38227

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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  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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  e294a0c3af9f4443dc692b180fb1771b1cb075e8
baseline version:
 xen  b261366f10eb150458d28aa728d399d0a781997e

Last test of basis38227  2015-10-30 08:20:16 Z3 days
Testing same since38238  2015-11-02 05:50:17 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Julien Grall 

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-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl   

Re: [Xen-devel] [PATCH XEN v4 01/23] tools/Rules.mk: Properly handle libraries with recursive dependencies.

[Ian Campbell]

On Thu, 2015-10-29 at 16:27 +, Wei Liu wrote:
> On Wed, Oct 21, 2015 at 04:23:08PM +0100, Ian Campbell wrote:
> > In tree libraries which link against other in tree libraries in a way
> > which is opaque to their callers need special handling, specifically
> > correct use of -Wl,-rpath-link for the recusively used libraries.
> > 
> > Currently this is rather simple, but up coming changes are going to
> > introduce transitive dependencies more than 1 step deep.
> > 
> > Introduce a SHDEPS idiom to contain all the recursive deps for a
> > library and include those in both LDLIBS (for linking) and SHLIB (for
> > recursive uses).
> > 
> > Try and document the whole thing.
> > 
> > Signed-off-by: Ian Campbell 
> > Acked-by: Ian Jackson 
> 
> Acked-by: Wei Liu 
> 
> >  
> >  CFLAGS_libxenguest = -I$(XEN_LIBXC)/include $(CFLAGS_xeninclude)
> > -LDLIBS_libxenguest = $(XEN_LIBXC)/libxenguest$(libextension)
> > -SHLIB_libxenguest  = -Wl,-rpath-link=L$(XEN_LIBXC)
> > +SHDEPS_libxenguest =
> > +LDLIBS_libxenguest = $(SHDEPS_libxenguest)
> > $(XEN_LIBXC)/libxenguest$(libextension)
> > +SHLIB_libxenguest  = $(SHDEPS_libxenguest) -Wl,-rpath
> > -link=L$(XEN_LIBXC)
> >  
> 
> There is an extra "L" preceding XEN_LIBXC. Jan spotted and fixed it in
> one of his patch.

Gah, I just replied to Jan claiming to have (inadvertently) spotted this,
but I didn't do so at all! Oh well..


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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Ian Campbell]

On Mon, 2015-11-02 at 14:10 +, Andrew Cooper wrote:
> On 02/11/15 13:44, Ian Campbell wrote:
> > On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote:
> > > When oxenstored wrote to the ring, it wrote a chunk of contiguous
> > > data.
> > > Originally when it tried to write across ring boundary, it returned a
> > > short-write when there is still room.  That led to stalling mini-os's
> > > xenstore thread at times.
> > What is a "short-write" in this context?
> > 
> > Given data bytes 0..M I assumed it is only writing bytes 0..N and not
> > N+1..M because the ring boundary is at N. But what is it writing to the
> > ->prod ring pointer N or M?
> 
> Prod gets incremented by N in this case.
> 
> > 
> > AIUI writing N should be allowed by the ring protocol, the client
> > should
> > keep looking for more data until it has a complete request.
> > 
> > Writing M would be a server error.
> 
> Correct, and this is what is happening.

The first or second? Your first comment suggests the first, but your second
binds most closely to the second.

> The server (believes) that the ring is full, when it is not.  It waits
> for the client to make more space in the ring, while the client is
> waiting for the server to complete its message in the ring, thus
> stalling.

That makes sense, thanks.

I think this needs to be spelled out more fully in the commit message, in
particular "server thinks ring is full when it is not" is the most relevant
thing, the short write is just how we arrived there.

Ian.

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

Re: [Xen-devel] [PATCH] libxlu: avoid linker warnings

[Ian Campbell]

On Mon, 2015-11-02 at 14:01 +, Ian Campbell wrote:
> On Thu, 2015-10-29 at 04:05 -0600, Jan Beulich wrote:
> > Recent ld warns about libxenlight.so's dependency libraries not being
> > available, which can be easily avoided by not just passing the raw
> > library name on ld's command line.
> 
> > In the course of checking how things fit together (I originally
> > suspected the warning to come from the linking of xl) I also noticed a
> > stray L in SHLIB_libxenguest, which gets removed at once.
> 
> Looks like I (unwittingly) fixed this aspect in

Actually, no I didn't.

> http://lists.xen.org/archives/html/xen-devel/2015-10/msg02256.html
> too. I can easily rebase.

easily rebase> that remains the case.



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

Re: [Xen-devel] [PATCH] oxenstored: fix short-write issue

[Andrew Cooper]

On 02/11/15 14:24, Ian Campbell wrote:
> On Mon, 2015-11-02 at 14:10 +, Andrew Cooper wrote:
>> On 02/11/15 13:44, Ian Campbell wrote:
>>> On Tue, 2015-10-27 at 17:10 +, Wei Liu wrote:
 When oxenstored wrote to the ring, it wrote a chunk of contiguous
 data.
 Originally when it tried to write across ring boundary, it returned a
 short-write when there is still room.  That led to stalling mini-os's
 xenstore thread at times.
>>> What is a "short-write" in this context?
>>>
>>> Given data bytes 0..M I assumed it is only writing bytes 0..N and not
>>> N+1..M because the ring boundary is at N. But what is it writing to the
>>> ->prod ring pointer N or M?
>> Prod gets incremented by N in this case.
>>
>>> AIUI writing N should be allowed by the ring protocol, the client
>>> should
>>> keep looking for more data until it has a complete request.
>>>
>>> Writing M would be a server error.
>> Correct, and this is what is happening.
> The first or second? Your first comment suggests the first, but your second
> binds most closely to the second.

Oops yes.  Writing M would be an error.  Prod currently gets incremented
by N.

>
>> The server (believes) that the ring is full, when it is not.  It waits
>> for the client to make more space in the ring, while the client is
>> waiting for the server to complete its message in the ring, thus
>> stalling.
> That makes sense, thanks.
>
> I think this needs to be spelled out more fully in the commit message, in
> particular "server thinks ring is full when it is not" is the most relevant
> thing, the short write is just how we arrived there.

This patch here is buggy, and superseeded by one of mine which attempts
to fix the C stubs.

I need to post a v2.

~Andrew

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

Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion

[Andrew Cooper]

On 02/11/15 14:07, George Dunlap wrote:
> On 30/10/15 18:33, Andrew Cooper wrote:
>> p2m_pod_demand_populate() can be entered repeatedly during a single path
>> through the hypervisor, e.g. on a toolstack batch map operation.
>>
>> The domain might be crashed, but the interface currently lacks a way of
>> passing an error back through the generic p2m layer.
>>
>> Longterm the p2m layer needs reworking to allow errors to be returned, but in
>> the short term, avoid repeatedly re-sweeping the domain after it has already
>> been crashed from PoD exhaustion.
>>
>> Signed-off-by: Andrew Cooper 
>> ---
>> CC: Jan Beulich 
>> CC: George Dunlap 
>> ---
>>  xen/arch/x86/mm/p2m-pod.c | 3 ++-
>>  xen/include/asm-x86/p2m.h | 2 ++
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
>> index be15cf3..6fb054f 100644
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -1048,7 +1048,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, 
>> unsigned long gfn,
>>  /* This check is done with the pod lock held.  This will make sure that
>>   * even if d->is_dying changes under our feet, p2m_pod_empty_cache() 
>>   * won't start until we're done. */
>> -if ( unlikely(d->is_dying) )
>> +if ( unlikely(d->is_dying) || p2m->pod.dead )
> So after getting lost in a maze of twisty passages, it looks like
> "d->is_dying" might be the wrong thing to check here.  d->is_dying is
> *only* set, AFAICT, in two places:
>  - in domain_kill(), which is only called for XEN_DOMCTL_destroydomain
>  - in domain_create(), if the creation failed for some reason.

d->is_dying indicates that the domains resources are starting to be torn
down.  It is the correct check here.

>
> Would it make more sense to check d->is_shutting_down instead?

A domain resume hypercall can clear d->is_shutting_down, making it an
inappropriate check.

>
> Having some sort of pod-specific flag seems like the wrong solution.

All of this patch is the wrong solution, but is necessary until the
generic p2m interface can properly represent errors.

~Andrew

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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

[Ian Campbell]

On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote:
> > > > On 30.10.15 at 19:33,  wrote:
> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned")
> >  static bool_t __initdata opt_hap_enabled = 1;
> >  boolean_param("hap", opt_hap_enabled);
> >  
> > +bool_t opt_pod_enabled = 1;
> 
> __read_mostly?
> 
> > --- a/xen/common/memory.c
> > +++ b/xen/common/memory.c
> > @@ -818,6 +818,10 @@ long do_memory_op(unsigned long cmd,
> > XEN_GUEST_HANDLE_PARAM(void) arg)
> >  if ( unlikely(start_extent >= reservation.nr_extents) )
> >  return start_extent;
> >  
> > +if ( unlikely(!opt_pod_enabled) &&
> > + (reservation.mem_flags & XENMEMF_populate_on_demand) )
> > +return start_extent;
> 
> A few lines down we can see that XENMEMF_populate_on_demand
> gets honored only for XENMEM_populate_physmap. Perhaps you
> shouldn't fail the other two which ignore the flag anyway?

Setting an unexpected flag surely ought to be an error? Admittedly that
particular ship may have sailed WRT this public ABI.

>  And
> perhaps you should also fold this into the existing check?
> 
> Also I don't think this is going to build on ARM.

Because opt_pod_enabled is on x86 only, I suppose.

I wouldn't be averse to a "const bool_t opt_pod_enabled = 0" in some
convenient place, seems better than the alternative of ifdefs around here.

Ian.


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

[Xen-devel] [distros-debian-sid test] 38239: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-amd64-sid-netboot-pygrub 13 guest-saverestore fail blocked in 
38212
 test-amd64-i386-i386-sid-netboot-pvgrub 10 guest-start   fail blocked in 38212

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-sid-netboot-pygrub 11 migrate-support-check fail never 
pass
 test-armhf-armhf-armhf-sid-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-amd64-amd64-amd64-sid-netboot-pvgrub 13 guest-saverestore fail never pass

baseline version:
 flight   38212

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-sid-netboot-pvgrubfail
 test-amd64-i386-i386-sid-netboot-pvgrub  fail
 test-amd64-i386-amd64-sid-netboot-pygrub fail
 test-armhf-armhf-armhf-sid-netboot-pygrubpass
 test-amd64-amd64-i386-sid-netboot-pygrub pass



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

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

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


Push not applicable.


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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

[Andrew Cooper]

On 02/11/15 14:32, Ian Campbell wrote:
> On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote:
> On 30.10.15 at 19:33,  wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -92,6 +92,9 @@ unsigned long __section(".bss.page_aligned")
>>>  static bool_t __initdata opt_hap_enabled = 1;
>>>  boolean_param("hap", opt_hap_enabled);
>>>  
>>> +bool_t opt_pod_enabled = 1;
>> __read_mostly?
>>
>>> --- a/xen/common/memory.c
>>> +++ b/xen/common/memory.c
>>> @@ -818,6 +818,10 @@ long do_memory_op(unsigned long cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>  if ( unlikely(start_extent >= reservation.nr_extents) )
>>>  return start_extent;
>>>  
>>> +if ( unlikely(!opt_pod_enabled) &&
>>> + (reservation.mem_flags & XENMEMF_populate_on_demand) )
>>> +return start_extent;
>> A few lines down we can see that XENMEMF_populate_on_demand
>> gets honored only for XENMEM_populate_physmap. Perhaps you
>> shouldn't fail the other two which ignore the flag anyway?
> Setting an unexpected flag surely ought to be an error? Admittedly that
> particular ship may have sailed WRT this public ABI.
>
>>  And
>> perhaps you should also fold this into the existing check?
>>
>> Also I don't think this is going to build on ARM.

Oops - I forgot to check for that, but you are correct.

> Because opt_pod_enabled is on x86 only, I suppose.
>
> I wouldn't be averse to a "const bool_t opt_pod_enabled = 0" in some
> convenient place, seems better than the alternative of ifdefs around here.

I will see what I can do.

~Andrew

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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

[Jan Beulich]

>>> On 02.11.15 at 15:32,  wrote:
> On Mon, 2015-11-02 at 06:53 -0700, Jan Beulich wrote:
>> > > > On 30.10.15 at 19:33,  wrote:
>> > --- a/xen/common/memory.c
>> > +++ b/xen/common/memory.c
>> > @@ -818,6 +818,10 @@ long do_memory_op(unsigned long cmd,
>> > XEN_GUEST_HANDLE_PARAM(void) arg)
>> >  if ( unlikely(start_extent >= reservation.nr_extents) )
>> >  return start_extent;
>> >  
>> > +if ( unlikely(!opt_pod_enabled) &&
>> > + (reservation.mem_flags & XENMEMF_populate_on_demand) )
>> > +return start_extent;
>> 
>> A few lines down we can see that XENMEMF_populate_on_demand
>> gets honored only for XENMEM_populate_physmap. Perhaps you
>> shouldn't fail the other two which ignore the flag anyway?
> 
> Setting an unexpected flag surely ought to be an error? Admittedly that
> particular ship may have sailed WRT this public ABI.

Without that latter aspect I would certainly answer the question
with "Yes".

Jan


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

Re: [Xen-devel] [PATCH] timer-op: demote a debugging message to really be debugging only

[Ian Campbell]

On Fri, 2015-10-30 at 18:58 +, Andrew Cooper wrote:
> On 30/10/15 17:42, Jan Beulich wrote:
> > The issue the message points out may have been of relevance during the
> > early days, but shouldn't anymore.
> > 
> > Signed-off-by: Jan Beulich 
> 
> Reviewed-by: Andrew Cooper 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH v3 2/6] xen: sched: fix locking for insert_vcpu() in credit1 and RTDS

[Meng Xu]

Hi Dario,

>> > This is fixed as follows:
>> >  - take the lock in the hook implementations, in specific
>> >schedulers' code;
>> >  - avoid calling insert_vcpu(), for the idle vCPU, in
>> >schedule_cpu_switch(). In fact, idle vCPUs are set to run
>> >immediately, and the various schedulers won't insert them
>> >in their runqueues anyway, even when explicitly asked to.
>> >
>> > While there, still in schedule_cpu_switch(), locking with
>> > _irq() is enough (there's no need to do *_irqsave()).
>> >
>> > Signed-off-by: Dario Faggioli 
>> > ---
>
>> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
>> > index 6f71e0d..e16bd3a 100644
>> > --- a/xen/common/sched_credit.c
>> > +++ b/xen/common/sched_credit.c
>> > @@ -903,10 +903,16 @@ static void
>> >  csched_vcpu_insert(const struct scheduler *ops, struct vcpu *vc)
>> >  {
>> >  struct csched_vcpu *svc = vc->sched_priv;
>> > +spinlock_t *lock;
>> > +unsigned long flags;
>> > +
>> > +lock = vcpu_schedule_lock_irqsave(vc, &flags);
>>
>>
>> This is inconsistent with the commit log.
>>
> Mmm... no, the changelog speaks about schedule_cpu_switch(), not this
> functions.
>
> For this function, the conversion from _irqsave() to _irq() is done
> later in the series, when the call to insert_vcpu() is removed from the
> boot path, and hence does not require IRQs to be disabled when called
> (and the changelog of that later patch explains this).
>
>> I also checked the
>>
>> branch rel/sched/fix-vcpu-ins-rem-v2 in your repo., it is the
>> following code:
>>
>> lock = vcpu_schedule_lock_irq(vc, &flags);
>>
>> I guess maybe you forgot to change it in this commit but change it
>> the
>> following commit?
>>
> No, this is one of the few thing that changed between v2 and v3.
>
> Regards,
> Dario

Thanks for the explanation! Then the patch looks good to me, at least
for RTDS scheduler. :-)

Best,

Meng


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

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Ian Campbell]

On Mon, 2015-11-02 at 06:55 -0700, Jan Beulich wrote:
> > > > On 02.11.15 at 14:47,  wrote:
> > On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote:
> > > This requires adjustments to the tool generating the symbol table and
> > > its as well as nm's invocation.
> > > 
> > > Note: Not warning about duplicate symbols in the EFI case for now, as
> > > a binutils bug causes misnamed file name entries to appear in EFI
> > > binaries' symbol tables when the file name is longer than 18 chars.
> > > (Not doing so also avoids other duplicates getting printed twice.)
> > > 
> > > Signed-off-by: Jan Beulich 
> > > ---
> > > v2: Also special case file names with directory part (along with
> > > object ones). Mirror xen-syms linking changes to ARM, but for now
> > > without generating warnings.
> > 
> > Thanks for taking care of ARM. I assume "without generating warnings"
> > differs from the x86 behaviour? Is there some followup which us ARM
> > folks
> > ought to be looking into making?
> 
> Not right now I would say. As mentioned elsewhere, without
> xSplice as a goal I don't see much use in the having those warnings.

OK, thanks.




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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Jan Beulich]

>>> On 02.11.15 at 15:54,  wrote:
> On Mon, 2015-11-02 at 06:55 -0700, Jan Beulich wrote:
>> > > > On 02.11.15 at 14:47,  wrote:
>> > On Mon, 2015-10-26 at 05:49 -0600, Jan Beulich wrote:
>> > > This requires adjustments to the tool generating the symbol table and
>> > > its as well as nm's invocation.
>> > > 
>> > > Note: Not warning about duplicate symbols in the EFI case for now, as
>> > > a binutils bug causes misnamed file name entries to appear in EFI
>> > > binaries' symbol tables when the file name is longer than 18 chars.
>> > > (Not doing so also avoids other duplicates getting printed twice.)
>> > > 
>> > > Signed-off-by: Jan Beulich 
>> > > ---
>> > > v2: Also special case file names with directory part (along with
>> > > object ones). Mirror xen-syms linking changes to ARM, but for now
>> > > without generating warnings.
>> > 
>> > Thanks for taking care of ARM. I assume "without generating warnings"
>> > differs from the x86 behaviour? Is there some followup which us ARM
>> > folks
>> > ought to be looking into making?
>> 
>> Not right now I would say. As mentioned elsewhere, without
>> xSplice as a goal I don't see much use in the having those warnings.
> 
> OK, thanks.

So since you're on it - can I get an ack (or otherwise)? Perhaps
also on patch 2?

Thanks, Jan


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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote:
> On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> > The xenbus thread didn't send notification to other end when it expected
> > more data or consumed responses, which led to stalling the ring from
> > time to time.
> > 
> > This is the culprit that guest was less responsive when using stubdom
> > because the device model was stalled.
> > 
> > Fix this by sending notification to the other end at the right places.
> 
> Could any of this code benefit from using the various macros in ring.h
> which produce or consume entries on the ring and return a _notify bit?
> 

The bug is it doesn't send notification at all. The existing code in
Linux doesn't seem to care about mitigating notifications -- xenbus is
supposed to exchange small amount of information anyway so whether a few
more notifications are sent is not essential. I think it would be better
if we follow something that works at this stage.

The use of ring macro can be considered an improvement but not
essential to fix the bug. It can be considered as improvement in the
future.

Wei.

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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Ian Campbell]

On Mon, 2015-11-02 at 15:00 +, Wei Liu wrote:
> On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote:
> > On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> > > The xenbus thread didn't send notification to other end when it
> > > expected
> > > more data or consumed responses, which led to stalling the ring from
> > > time to time.
> > > 
> > > This is the culprit that guest was less responsive when using stubdom
> > > because the device model was stalled.
> > > 
> > > Fix this by sending notification to the other end at the right
> > > places.
> > 
> > Could any of this code benefit from using the various macros in ring.h
> > which produce or consume entries on the ring and return a _notify bit?
> > 
> 
> The bug is it doesn't send notification at all. The existing code in
> Linux doesn't seem to care about mitigating notifications -- xenbus is
> supposed to exchange small amount of information anyway so whether a few
> more notifications are sent is not essential. I think it would be better
> if we follow something that works at this stage.
> 
> The use of ring macro can be considered an improvement but not
> essential to fix the bug. It can be considered as improvement in the
> future.

My reason for suggesting it was more that we trust that those macros are
already correct, compared with needing to reason from scratch about the
open coded version used in this code which is what appeared to be going on.

Ian.

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

Re: [Xen-devel] [PATCH v2 1/5] symbols: prefix static symbols with their source file names

[Ian Campbell]

On Mon, 2015-11-02 at 07:58 -0700, Jan Beulich wrote:

> So since you're on it - can I get an ack (or otherwise)? Perhaps
> also on patch 2?

That being "compat: enforce distinguishable file names in symbol table" ?

TBH I had considered that to be x86 specific (despite where the code might
live). I'll go take a look now though.

Ian.

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

Re: [Xen-devel] [PATCH 1/4] xen/public: arm: Clarify the name of guest handle structures

[Stefano Stabellini]

On Fri, 30 Oct 2015, Julien Grall wrote:
> Currently it's hard to know which __guest_handle* is associated to a
> guest handle or a guest handle param.
> 
> Rename the types to match the usage. I.e
> * __guest_handle is renamed to __guest_handle_param as it's used for
> hypercall parameters.
> * __guest_handle_64 is renamed to __guest_handle as it's used for
> guest handle in structure field stored in memory.
> 
> Signed-off-by: Julien Grall 

Acked-by: Stefano Stabellini 


> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
>  xen/include/public/arch-arm.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 6322548..35839db 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -171,9 +171,9 @@
>  #ifndef __ASSEMBLY__
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type)  \
>  typedef union { type *p; unsigned long q; } \
> -__guest_handle_ ## name;\
> +__guest_handle_param_ ## name;  \
>  typedef union { type *p; uint64_aligned_t q; }  \
> -__guest_handle_64_ ## name;
> +__guest_handle_ ## name;
>  
>  /*
>   * XEN_GUEST_HANDLE represents a guest pointer, when passed as a field
> @@ -186,9 +186,9 @@
>  ___DEFINE_XEN_GUEST_HANDLE(name, type);   \
>  ___DEFINE_XEN_GUEST_HANDLE(const_##name, const type)
>  #define DEFINE_XEN_GUEST_HANDLE(name)   __DEFINE_XEN_GUEST_HANDLE(name, name)
> -#define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
> +#define __XEN_GUEST_HANDLE(name)__guest_handle_ ## name
>  #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
> -#define XEN_GUEST_HANDLE_PARAM(name)__guest_handle_ ## name
> +#define XEN_GUEST_HANDLE_PARAM(name)__guest_handle_param_ ## name
>  #define set_xen_guest_handle_raw(hnd, val)  \
>  do {\
>  typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

[Stefano Stabellini]

On Fri, 30 Oct 2015, Julien Grall wrote:
> __guest_handle_param is used to represent a guest pointer stored pass as
> an hypercall parameters. They are the same size as the native register
> for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64.
> 
> As the __guest_handle_param will always be the size of a native
> pointer, there is no need to have a union with an unsigned long.
> 
> Note that unsigned long may be not equivalent to the size of a pointer
> on ARM64. It depends whether the software is build using the LP64 or
> LLP64 data model. The size of an unsigned long in the latter will be
> 32-bit.
> 
> Signed-off-by: Julien Grall 

Obviously this is going to break set_xen_guest_handle_raw. I don't think
this cannot be committed separately to the change to
set_xen_guest_handle_raw.


> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
>  xen/include/public/arch-arm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 35839db..477254f 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -170,7 +170,7 @@
>  
>  #ifndef __ASSEMBLY__
>  #define ___DEFINE_XEN_GUEST_HANDLE(name, type)  \
> -typedef union { type *p; unsigned long q; } \
> +typedef struct { type *p; } \
>  __guest_handle_param_ ## name;  \
>  typedef union { type *p; uint64_aligned_t q; }  \
>  __guest_handle_ ## name;
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH 4/4] x86/PoD: Command line option to prohibit any PoD operations

[George Dunlap]

On 30/10/15 18:33, Andrew Cooper wrote:
> PoD is only needed to cover a corner case with memory overcommit
> (rebooting a ballooned down VM with insufficient host RAM available).
> 
> Its use comes with a performance hit, and inoperability with other
> technologies such as PCI Passthrough.
> 
> Offer a command line option for administrators who want to be certain
> that PoD is not in use for their VMs.
> 
> Signed-off-by: Andrew Cooper 

With the arm build addressed:

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

[Julien Grall]

Hi Stefano,

On 02/11/15 15:19, Stefano Stabellini wrote:
> On Fri, 30 Oct 2015, Julien Grall wrote:
>> __guest_handle_param is used to represent a guest pointer stored pass as
>> an hypercall parameters. They are the same size as the native register
>> for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64.
>>
>> As the __guest_handle_param will always be the size of a native
>> pointer, there is no need to have a union with an unsigned long.
>>
>> Note that unsigned long may be not equivalent to the size of a pointer
>> on ARM64. It depends whether the software is build using the LP64 or
>> LLP64 data model. The size of an unsigned long in the latter will be
>> 32-bit.
>>
>> Signed-off-by: Julien Grall 
> 
> Obviously this is going to break set_xen_guest_handle_raw. I don't think
> this cannot be committed separately to the change to
> set_xen_guest_handle_raw.

Well, all the usage of set_xen_guest_handle_raw within the hypervisor
are in compat and kexec which is not built for ARM.

Furthermore, after this series set_xen_guest_handle_raw won't work
anymore with a guest_handle_param.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Ian Campbell]

On Mon, 2015-10-26 at 05:50 -0600, Jan Beulich wrote:
> To make it possible to tell apart the static symbols in files built a
> second for compat guest support, arrange for their source file names to

^ time ?

> be prefixed by a suitable path. We can't do this without explicit .file
> directives, since gcc has always been stripping paths from file names
> handed to the internally generated .file directive. However, we can
> leverage __FILE__ if we make sure the second instance gets compiled out
> of other than the very directory the wrapper sits in.
> 
> Where suitable, remove the long redundant explicit inclusions of
> xen/config.h at once.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -86,8 +86,7 @@ AFLAGS-$(clang) += -no-integrate
>  ALL_OBJS := $(ALL_OBJS-y)
>  
>  # Get gcc to generate the dependencies for us.
> -CFLAGS-y += -MMD -MF .$(@F).d
> -DEPS = .*.d
> +CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
>  
>  CFLAGS += $(CFLAGS-y)
>  
> @@ -103,6 +102,14 @@ LDFLAGS += $(LDFLAGS-y)
>  
>  include Makefile
>  
> +DEPS = .*.d
> +define gendep
> +ifneq ($(1),$(subst /,:,$(1)))
> +DEPS += $(dir $(1)).$(basename $(notdir $(1))).d
> +endif
> +endef
> +$(foreach o,$(filter-out %/,$(obj-y)),$(eval $(call gendep,$(o

Is this generating a .subdir.file.d for each subdir/file.o in obj-y?

This is as a consequence of now building subdir/file.o from the parent
directory instead of recursing for some subset of files?

It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile
building some files directly and xen/arch/x86/Makefile to be building
another subset of those files via x86_64/FOO.o. Even more so that other
than compat.o I can't see what makes many affected files (e.g. mm.o or
platform_hypercall.o) special in this regard.

Does all of that fall out from a desire to reuse __FILE__? If so I'm
inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
would seem likely to me to end up less strange (but maybe you tried that
and it was worse?).

> +
>  # Ensure each subdirectory has exactly one trailing slash.
>  subdir-n := $(patsubst %,%/,$(patsubst %/,%,$(subdir-n) $(subdir-)))
>  subdir-y := $(patsubst %,%/,$(patsubst %/,%,$(subdir-y)))
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -13,7 +13,7 @@ obj-y += bitops.o
>  obj-bin-y += bzimage.init.o
>  obj-bin-y += clear_page.o
>  obj-bin-y += copy_page.o
> -obj-y += compat.o
> +obj-y += compat.o x86_64/compat.o
>  obj-$(CONFIG_KEXEC) += crash.o
>  obj-y += debug.o
>  obj-y += delay.o
> @@ -25,7 +25,6 @@ obj-y += domain_page.o
>  obj-y += e820.o
>  obj-y += extable.o
>  obj-y += flushtlb.o
> -obj-y += platform_hypercall.o
>  obj-y += i387.o
>  obj-y += i8259.o
>  obj-y += io_apic.o
> @@ -37,14 +36,15 @@ obj-y += microcode_amd.o
>  obj-y += microcode_intel.o
>  # This must come after the vendor specific files.
>  obj-y += microcode.o
> -obj-y += mm.o
> +obj-y += mm.o x86_64/mm.o
>  obj-y += monitor.o
>  obj-y += mpparse.o
>  obj-y += nmi.o
>  obj-y += numa.o
>  obj-y += pci.o
>  obj-y += percpu.o
> -obj-y += physdev.o
> +obj-y += physdev.o x86_64/physdev.o
> +obj-y += platform_hypercall.o x86_64/platform_hypercall.o
>  obj-y += psr.o
>  obj-y += setup.o
>  obj-y += shutdown.o
> --- a/xen/arch/x86/x86_64/Makefile
> +++ b/xen/arch/x86/x86_64/Makefile
> @@ -2,7 +2,6 @@ subdir-y += compat
>  
>  obj-bin-y += entry.o
>  obj-bin-y += gpr_switch.o
> -obj-y += mm.o
>  obj-y += traps.o
>  obj-y += machine_kexec.o
>  obj-y += pci.o
> @@ -10,10 +9,7 @@ obj-y += acpi_mmcfg.o
>  obj-y += mmconf-fam10h.o
>  obj-y += mmconfig_64.o
>  obj-y += mmconfig-shared.o
> -obj-y += compat.o
>  obj-y += domain.o
> -obj-y += physdev.o
> -obj-y += platform_hypercall.o
>  obj-y += cpu_idle.o
>  obj-y += cpufreq.o
>  obj-bin-y += kexec_reloc.o
> --- a/xen/arch/x86/x86_64/compat.c
> +++ b/xen/arch/x86/x86_64/compat.c
> @@ -2,7 +2,8 @@
>   * compat.c
>   */
>  
> -#include 
> +asm(".file \"" __FILE__ "\"");
> +
>  #include 
>  #include 
>  #include 
> --- a/xen/arch/x86/x86_64/mm.c
> +++ b/xen/arch/x86/x86_64/mm.c
> @@ -16,7 +16,8 @@
>   * with this program; If not, see .
>   */
>  
> -#include 
> +asm(".file \"" __FILE__ "\"");
> +
>  #include 
>  #include 
>  #include 
> --- a/xen/arch/x86/x86_64/physdev.c
> +++ b/xen/arch/x86/x86_64/physdev.c
> @@ -2,7 +2,8 @@
>   * physdev.c
>   */
>  
> -#include 
> +asm(".file \"" __FILE__ "\"");
> +
>  #include 
>  #include 
>  #include 
> --- a/xen/arch/x86/x86_64/platform_hypercall.c
> +++ b/xen/arch/x86/x86_64/platform_hypercall.c
> @@ -2,7 +2,8 @@
>   * platform_hypercall.c
>   */
>  
> -#include 
> +asm(".file \"" __FILE__ "\"");
> +
>  #include 
>  #include 
>  
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -63,7 +63,7 @@ obj-$(perfc)   += perfc.o
>  obj-$(crash_debug) += gdbstub.o
>  obj-$(xenoprof)+= xenoprof.o
>  
> -subdir-$(CONFIG_COMPAT) += compat
> +obj-$(CONFIG_COMPAT) += $(addprefix

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

[Ian Campbell]

On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote:
> Hi Stefano,
> 
> On 02/11/15 15:19, Stefano Stabellini wrote:
> > On Fri, 30 Oct 2015, Julien Grall wrote:
> > > __guest_handle_param is used to represent a guest pointer stored pass
> > > as
> > > an hypercall parameters. They are the same size as the native
> > > register
> > > for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64.
> > > 
> > > As the __guest_handle_param will always be the size of a native
> > > pointer, there is no need to have a union with an unsigned long.
> > > 
> > > Note that unsigned long may be not equivalent to the size of a
> > > pointer
> > > on ARM64. It depends whether the software is build using the LP64 or
> > > LLP64 data model. The size of an unsigned long in the latter will be
> > > 32-bit.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Obviously this is going to break set_xen_guest_handle_raw. I don't
> > think
> > this cannot be committed separately to the change to
> > set_xen_guest_handle_raw.
> 
> Well, all the usage of set_xen_guest_handle_raw within the hypervisor
> are in compat and kexec which is not built for ARM.

Shall we drop it from ARM then?

It can always be added back when it is needed (or the code in question
reworked to avoid the need).

> 
> Furthermore, after this series set_xen_guest_handle_raw won't work
> anymore with a guest_handle_param.
> 
> Regards,
> 

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

[Xen-devel] [linux-3.4 test] 63404: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 62277
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 62277
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 62277

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-amd64-pvgrub  3 host-install(3) broken in 63294 pass in 63404
 test-amd64-i386-qemuu-rhel6hvm-amd 3 host-install(3) broken in 63294 pass in 
63404
 test-amd64-amd64-xl-qemuu-winxpsp3 3 host-install(3) broken in 63294 pass in 
63404
 test-amd64-i386-xl-xsm3 host-install(3)  broken in 63310 pass in 63404
 test-amd64-amd64-xl-qcow2 3 host-install(3)  broken in 63310 pass in 63404
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken in 
63310 pass in 63404
 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 63310 pass in 
63404
 test-amd64-amd64-xl-credit2   3 host-install(3)  broken in 63324 pass in 63404
 test-amd64-i386-qemut-rhel6hvm-amd 3 host-install(3) broken in 63324 pass in 
63404
 test-amd64-i386-xl-raw3 host-install(3)  broken in 63324 pass in 63404
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 3 host-install(3) broken 
in 63324 pass in 63404
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 3 host-install(3) broken in 63324 
pass in 63404
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63310 pass in 63294
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail pass in 
63228
 test-amd64-amd64-xl-rtds  6 xen-bootfail pass in 63228
 test-amd64-amd64-i386-pvgrub  6 xen-bootfail pass in 63294
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail pass in 63310
 test-amd64-i386-pair 10 xen-boot/dst_host   fail pass in 63310
 test-amd64-i386-pair  9 xen-boot/src_host   fail pass in 63310
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_host  fail pass in 63310
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_host  fail pass in 63310
 test-amd64-amd64-amd64-pvgrub  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot   fail pass in 63324
 test-amd64-amd64-xl-qcow2 6 xen-bootfail pass in 63338
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host   fail pass in 63374
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host   fail pass in 63374

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 62277
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 62277
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63228 blocked in 62277
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 63324 like 62277
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62277
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62277
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 62277

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 63228 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  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  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

[Julien Grall]

On 02/11/15 15:35, Ian Campbell wrote:
> On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 02/11/15 15:19, Stefano Stabellini wrote:
>>> On Fri, 30 Oct 2015, Julien Grall wrote:
 __guest_handle_param is used to represent a guest pointer stored pass
 as
 an hypercall parameters. They are the same size as the native
 register
 for the architecture. It will be 32-bit on ARM32 and 64-bit on ARM64.

 As the __guest_handle_param will always be the size of a native
 pointer, there is no need to have a union with an unsigned long.

 Note that unsigned long may be not equivalent to the size of a
 pointer
 on ARM64. It depends whether the software is build using the LP64 or
 LLP64 data model. The size of an unsigned long in the latter will be
 32-bit.

 Signed-off-by: Julien Grall 
>>>
>>> Obviously this is going to break set_xen_guest_handle_raw. I don't
>>> think
>>> this cannot be committed separately to the change to
>>> set_xen_guest_handle_raw.
>>
>> Well, all the usage of set_xen_guest_handle_raw within the hypervisor
>> are in compat and kexec which is not built for ARM.
> 
> Shall we drop it from ARM then?

No. Sorry it wasn't clear on my previous mail, I was only speaking about
the usage of set_xen_guest_handle_raw on a XEN_GUEST_HANDLE_PARAM.

set_xen_guest_handle_raw is used by the guest/toolstack to set a pointer
in a structure. All those usages are done with a GUEST_HANDLE and not a
GUEST_HANDLE_PARAM.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 2/4] xen/public: arm: Rework __guest_handle_param*

[Ian Campbell]

On Mon, 2015-11-02 at 15:39 +, Julien Grall wrote:
> On 02/11/15 15:35, Ian Campbell wrote:
> > On Mon, 2015-11-02 at 15:24 +, Julien Grall wrote:
> > > Hi Stefano,
> > > 
> > > On 02/11/15 15:19, Stefano Stabellini wrote:
> > > > On Fri, 30 Oct 2015, Julien Grall wrote:
> > > > > __guest_handle_param is used to represent a guest pointer stored
> > > > > pass
> > > > > as
> > > > > an hypercall parameters. They are the same size as the native
> > > > > register
> > > > > for the architecture. It will be 32-bit on ARM32 and 64-bit on
> > > > > ARM64.
> > > > > 
> > > > > As the __guest_handle_param will always be the size of a native
> > > > > pointer, there is no need to have a union with an unsigned long.
> > > > > 
> > > > > Note that unsigned long may be not equivalent to the size of a
> > > > > pointer
> > > > > on ARM64. It depends whether the software is build using the LP64
> > > > > or
> > > > > LLP64 data model. The size of an unsigned long in the latter will
> > > > > be
> > > > > 32-bit.
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > 
> > > > Obviously this is going to break set_xen_guest_handle_raw. I don't
> > > > think
> > > > this cannot be committed separately to the change to
> > > > set_xen_guest_handle_raw.
> > > 
> > > Well, all the usage of set_xen_guest_handle_raw within the hypervisor
> > > are in compat and kexec which is not built for ARM.
> > 
> > Shall we drop it from ARM then?
> 
> No. Sorry it wasn't clear on my previous mail, I was only speaking about
> the usage of set_xen_guest_handle_raw on a XEN_GUEST_HANDLE_PARAM.
> 
> set_xen_guest_handle_raw is used by the guest/toolstack to set a pointer
> in a structure. All those usages are done with a GUEST_HANDLE and not a
> GUEST_HANDLE_PARAM.

Ah yes, if I'd have thought about it I could have worked that out myself,
sorry.

Ian.

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

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Wei Liu]

On Mon, Nov 02, 2015 at 03:08:26PM +, Ian Campbell wrote:
> On Mon, 2015-11-02 at 15:00 +, Wei Liu wrote:
> > On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote:
> > > On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> > > > The xenbus thread didn't send notification to other end when it
> > > > expected
> > > > more data or consumed responses, which led to stalling the ring from
> > > > time to time.
> > > > 
> > > > This is the culprit that guest was less responsive when using stubdom
> > > > because the device model was stalled.
> > > > 
> > > > Fix this by sending notification to the other end at the right
> > > > places.
> > > 
> > > Could any of this code benefit from using the various macros in ring.h
> > > which produce or consume entries on the ring and return a _notify bit?
> > > 
> > 
> > The bug is it doesn't send notification at all. The existing code in
> > Linux doesn't seem to care about mitigating notifications -- xenbus is
> > supposed to exchange small amount of information anyway so whether a few
> > more notifications are sent is not essential. I think it would be better
> > if we follow something that works at this stage.
> > 
> > The use of ring macro can be considered an improvement but not
> > essential to fix the bug. It can be considered as improvement in the
> > future.
> 
> My reason for suggesting it was more that we trust that those macros are
> already correct, compared with needing to reason from scratch about the
> open coded version used in this code which is what appeared to be going on.
> 

I don't think macros help here. Xenstore initialisation doesn't follow
conventional frontend and backend drivers, so the macros don't really
apply to it -- not without some refactoring.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

[Stefano Stabellini]

On Fri, 30 Oct 2015, Julien Grall wrote:
> The current implementation of set_xen_guest_handle_raw is using the
> keyword "typeof" which is not part of C spec.
> 
> Furthermore, when the guest handle is defined in ARM32 guest, the
> pointer will always be smaller than the handle. Based on the C99 spec
> [1] 6.2.6.1#7, the bits that do not correspond to the member written
> will take unspecified value.
> 
> Finally, based on the defect report #283 [2], the behavior of writing
> from one member and reading from another is not clear.
> 
> We don't hit the problems for Xen and the toolstack because they are
> both built with strict aliasing disabled. However, this may not be true
> for any software using those headers.
> 
> We want to rewrite the macro set_xen_guest_handle_raw based on the
> following constraint:
> 1) typeof should not be used
> 2) the parameters of the macros should only be interpreted one time
> 3) the bits unused by the pointer should be zeroed
> 
> So we to have to zeroed the top 32-bit (for ARM32) and set the pointer
> in a single expression. This means that we have to use a 64-bit access
> via the field '.q' represent an uint64_t. Because of that we loose the
> type safety provided by the field '.p' storing the pointer. Two compile
> time checks have been added to ensure the validity of the handle and the
> data stored.
> 
> While we don't provide a generic macro to get the guest pointer from the
> handle, Xen obviously uses the guest pointer. As Xen is build with strict
> aliasing disabled, we don't have to worry to set and get the value in the
> union using different field. To avoid future issue, comments has been
> added in the public header and Xen guest access to explain the problem
> and why it works.
> 
> Note that set_xen_guest_handle_raw won't work with guest handle param.
> But this is fine as this kind of handle is only used within the
> hypervisor and updating the guest pointer for ARM guest will require
> more care. FWIW, the caller of set_xen_guest_handle_raw in the
> hypervisor are in compat code and kexec. None of them of build for ARM
> today.
> 
> Finally while we modify asm-arm/guest_access.h, fix a typo.
> 
> [1] http://cs.nyu.edu/courses/spring13/CSCI-GA.2110-001/downloads/C99.pdf
> [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> Cc: Ian Jackson 
> Cc: Jan Beulich 
> Cc: Keir Fraser 
> Cc: Tim Deegan 
> ---
>  xen/include/asm-arm/guest_access.h | 10 ++
>  xen/include/public/arch-arm.h  | 19 ++-
>  2 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/include/asm-arm/guest_access.h 
> b/xen/include/asm-arm/guest_access.h
> index 5876988..fd2a849 100644
> --- a/xen/include/asm-arm/guest_access.h
> +++ b/xen/include/asm-arm/guest_access.h
> @@ -4,6 +4,16 @@
>  #include 
>  #include 
>  
> +/*
> + * Some of the macros within this file are using the field ".p" of the
> + * guest handle.
> + *
> + * While set_xen_guest_handle is always setting the handle using 64-bit
> + * access, the value is retrieved using the field ".p" which is 32-bit
> + * on ARM32 and 64-bit on ARM64. However, it's safe to use as Xen is built
> + * with strict aliasing disabled.
> + */
> +
>  /* Guests have their own comlete address space */
>  #define access_ok(addr,size) (1)
>  
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index b278bc0..390f6f3 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -193,11 +193,20 @@
>  #define XEN_GUEST_HANDLE_PARAM(name)__guest_handle_param_ ## name
>  #endif
>  
> -#define set_xen_guest_handle_raw(hnd, val)  \
> -do {\
> -typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> -_sxghr_tmp->q = 0;  \
> -_sxghr_tmp->p = val;\
> +/*
> + * Macro to set a guest pointer in the handle.
> + *
> + * Note that it's not possible to implement safely a macro to retrieve the
> + * handle unless the guest is built with strict aliasing disabling.
> + * Hence, we don't provide a such macro in the public headers.
> + */
> +#define set_xen_guest_handle_raw(hnd, val)  \
> +do {\
> +/* Check if the handle is 64-bit (i.e 8-byte) */\
> +(void) sizeof(struct { int : -!!(sizeof (hnd) != 8); });\
> +/* Check if the type of val is compatible with the handle */\
> +(void) sizeof((val) != (hnd).p);\
> +(hnd).q = (uint64_t)(uintptr_t)(val);   \
>  } while ( 0 )

Honestly I would be OK with having a typeof in the public headers to
avoid this code, which is much harder to follow. Why don't we do
something like the following:

Re: [Xen-devel] [PATCH MINI-OS] xenbus: notify the other end when necessary

[Ian Campbell]

On Mon, 2015-11-02 at 15:53 +, Wei Liu wrote:
> On Mon, Nov 02, 2015 at 03:08:26PM +, Ian Campbell wrote:
> > On Mon, 2015-11-02 at 15:00 +, Wei Liu wrote:
> > > On Mon, Nov 02, 2015 at 12:14:50PM +, Ian Campbell wrote:
> > > > On Mon, 2015-10-26 at 09:47 +, Wei Liu wrote:
> > > > > The xenbus thread didn't send notification to other end when it
> > > > > expected
> > > > > more data or consumed responses, which led to stalling the ring
> > > > > from
> > > > > time to time.
> > > > > 
> > > > > This is the culprit that guest was less responsive when using
> > > > > stubdom
> > > > > because the device model was stalled.
> > > > > 
> > > > > Fix this by sending notification to the other end at the right
> > > > > places.
> > > > 
> > > > Could any of this code benefit from using the various macros in
> > > > ring.h
> > > > which produce or consume entries on the ring and return a _notify
> > > > bit?
> > > > 
> > > 
> > > The bug is it doesn't send notification at all. The existing code in
> > > Linux doesn't seem to care about mitigating notifications -- xenbus
> > > is
> > > supposed to exchange small amount of information anyway so whether a
> > > few
> > > more notifications are sent is not essential. I think it would be
> > > better
> > > if we follow something that works at this stage.
> > > 
> > > The use of ring macro can be considered an improvement but not
> > > essential to fix the bug. It can be considered as improvement in the
> > > future.
> > 
> > My reason for suggesting it was more that we trust that those macros
> > are
> > already correct, compared with needing to reason from scratch about the
> > open coded version used in this code which is what appeared to be going
> > on.
> > 
> 
> I don't think macros help here. Xenstore initialisation doesn't follow
> conventional frontend and backend drivers, so the macros don't really
> apply to it -- not without some refactoring.

AH, ok then.


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

Re: [Xen-devel] [PATCH v2 2/5] compat: enforce distinguishable file names in symbol table

[Jan Beulich]

>>> On 02.11.15 at 16:20,  wrote:
> On Mon, 2015-10-26 at 05:50 -0600, Jan Beulich wrote:
>> To make it possible to tell apart the static symbols in files built a
>> second for compat guest support, arrange for their source file names to
> 
> ^ time ?

Oh, yes, of course.

>> --- a/xen/Rules.mk
>> +++ b/xen/Rules.mk
>> @@ -86,8 +86,7 @@ AFLAGS-$(clang) += -no-integrate
>>  ALL_OBJS := $(ALL_OBJS-y)
>>  
>>  # Get gcc to generate the dependencies for us.
>> -CFLAGS-y += -MMD -MF .$(@F).d
>> -DEPS = .*.d
>> +CFLAGS-y += -MMD -MF $(@D)/.$(@F).d
>>  
>>  CFLAGS += $(CFLAGS-y)
>>  
>> @@ -103,6 +102,14 @@ LDFLAGS += $(LDFLAGS-y)
>>  
>>  include Makefile
>>  
>> +DEPS = .*.d
>> +define gendep
>> +ifneq ($(1),$(subst /,:,$(1)))
>> +DEPS += $(dir $(1)).$(basename $(notdir $(1))).d
>> +endif
>> +endef
>> +$(foreach o,$(filter-out %/,$(obj-y)),$(eval $(call gendep,$(o
> 
> Is this generating a .subdir.file.d for each subdir/file.o in obj-y?

Actually a subdir/.file.d, but other than this minor difference - yes.

> This is as a consequence of now building subdir/file.o from the parent
> directory instead of recursing for some subset of files?

Yes.

> It seems quite inconsistent to me to have xen/arch/x86/x86_64/Makefile
> building some files directly and xen/arch/x86/Makefile to be building
> another subset of those files via x86_64/FOO.o. Even more so that other
> than compat.o I can't see what makes many affected files (e.g. mm.o or
> platform_hypercall.o) special in this regard.

The platform_hypercall one is quite obvious, because
x86_64/platform_hypercall.c just includes platform_hypercall.c
(which is the general pattern we're dealing with here). For mm.c
it was just prompted by actual collisions seen.

> Does all of that fall out from a desire to reuse __FILE__? If so I'm
> inclined to suggest that -DBUILD_FILENAME_PREFIX="compat/" or whatever
> would seem likely to me to end up less strange (but maybe you tried that
> and it was worse?).

Yes to the first question. And no, I didn't try the alternative you
suggest, but discarded it as the uglier variant from the beginning.
In particular I dislike (parts of) file names to be specified on the
command line, rather than getting derived from what we have
anyway.

Considering that Andrew was fine with the x86 parts, I'd want to
change the approach (the x86 side of which I understand is of
particular concern to you) only if you're convinced this alternative
approach is sufficiently much better.

Jan


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

Re: [Xen-devel] [PATCH 4/4] xen/public: arm: rework the macro set_xen_guest_handle_raw

[Jan Beulich]

>>> On 02.11.15 at 16:55,  wrote:
> Honestly I would be OK with having a typeof in the public headers to
> avoid this code, which is much harder to follow. Why don't we do
> something like the following:
> 
> 
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index 9a96401..e676ffb 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -189,11 +189,12 @@
>  #define __XEN_GUEST_HANDLE(name)__guest_handle_64_ ## name
>  #define XEN_GUEST_HANDLE(name)  __XEN_GUEST_HANDLE(name)
>  #define XEN_GUEST_HANDLE_PARAM(name)__guest_handle_ ## name
> +#define barrier() __asm__ __volatile__("": : :"memory")
>  #define set_xen_guest_handle_raw(hnd, val)  \
>  do {\
> -typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> -_sxghr_tmp->q = 0;  \
> -_sxghr_tmp->p = val;\
> +*((uint64_aligned_t *)&(hnd)) = 0;  \
> +barrier();  \
> +(hnd).p = val;  \
>  } while ( 0 )

Because __asm__ again is an extension?

Jan


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

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

[George Dunlap]

On 30/10/15 17:39, Jan Beulich wrote:
> Since calling the function isn't cheap, try to avoid the call when we
> know up front it won't help; see the code comment for details on those
> conditions.
> 
> Signed-off-by: Jan Beulich 
> 
> --- a/xen/arch/x86/mm/p2m-pod.c
> +++ b/xen/arch/x86/mm/p2m-pod.c
> @@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
>  if ( unlikely(d->is_dying) )
>  goto out_unlock;
>  
> -recount:
>  pod = nonpod = ram = 0;
>  
>  /* Figure out if we need to steal some freed memory for our cache */
> @@ -562,15 +561,20 @@ recount:
>  goto out_entry_check;
>  }
>  
> -/* Try to grab entire superpages if possible.  Since the common case is 
> for drivers
> - * to pass back singleton pages, see if we can take the whole page back 
> and mark the
> - * rest PoD. */
> -if ( steal_for_cache
> - && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
> -{
> -/* Since order may be arbitrary, we may have taken more or less
> - * than we were actually asked to; so just re-count from scratch */
> -goto recount;
> +/*
> + * Try to grab entire superpages if possible.  Since the common case is 
> for
> + * drivers to pass back singleton pages, see if we can take the whole 
> page
> + * back and mark the rest PoD.
> + * No need to do this though if
> + * - order >= SUPERPAGE_ORDER (the loop below will take care of this)
> + * - not all of the pages were RAM (now knowing order < SUPERPAGE_ORDER)
> + */
> +if ( steal_for_cache && order < SUPERPAGE_ORDER && (ram >> order) &&
> + p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES - 1)) )
> +{
> +pod += ram;
> +nonpod -= ram;
> +ram = 0;

+1 for the idea; a couple of comments:

* I think it would be clearer to use "(ram == 1 << order)" instead of
"ram >> order".  I understand (ram >> order) will be non-zero only if
ram == 1 << order, but why make people spend brain cycles trying to
figure that out?

* If we're going to assume that "ram >> order" implies "all the entries
are ram", and furthermore that a positive return value implies "all ram
was changed to pod", wouldn't it be better to do something like the
following?

  pod = 1 << order
  nonpod = ram = 0

This would be more clearly correct if we change the comparison to ram ==
1 << order.

* steal_for_cache may now be wrong.  I realize that since now ram == 0
that all the subsequent "steal_for_cache" expressions will end up as
"false" anyway, but leaving invariants in an invalid state is sort of
asking for trouble.

I'd prefer you just update steal_for_cache; but if not, at least leave a
comment there saying that it may be wrong and why it doesn't matter.

Thanks,
 -George

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

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

[Wei Liu]

On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote:
> Previously, xenconsoled's daemonize function would do nothing if its
> parent process is init (as it is under systemd but not sysv init).
> This is confusing. Instead, always daemonize when asked to, but use the
> "interactive" switch when running from the systemd service.
> 
> Because a pidfile is only written when daemonizing, drop the pidfile
> parameters from the service file (systemd keeps track of the pids
> anyway).
> 
> Signed-off-by: Ross Lagerwall 
> ---
>  tools/console/daemon/utils.c   | 4 
>  tools/hotplug/Linux/systemd/xenconsoled.service.in | 3 +--
>  2 files changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/tools/console/daemon/utils.c b/tools/console/daemon/utils.c
> index dbb3b12..644f6af 100644
> --- a/tools/console/daemon/utils.c
> +++ b/tools/console/daemon/utils.c
> @@ -52,10 +52,6 @@ void daemonize(const char *pidfile)
>   int i;
>   char buf[100];
>  
> - if (getppid() == 1) {
> - return;
> - }
> -

Er, I never noticed this before. And code archeology doesn't tell me why
it was written like this either.

>   if ((pid = fork()) > 0) {
>   exit(0);
>   } else if (pid == -1) {
> diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in 
> b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> index cd282bf..8e333b1 100644
> --- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
> +++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
> @@ -10,10 +10,9 @@ Environment=XENCONSOLED_ARGS=
>  Environment=XENCONSOLED_TRACE=none
>  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
>  EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
> -PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
>  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
>  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
> -ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid 
> --log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
> +ExecStart=@sbindir@/xenconsoled -i --log=${XENCONSOLED_TRACE} 
> --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
>  

To the best of my knowledge this seems to conform with man 7 daemon in
Linux, "New-Style Daemons" session:

"For developing a new-style daemon, none of the initialization steps
recommended for SysV daemons need to be implemented. New-style init
systems such as systemd make all of them redundant. Moreover, since some
of these steps interfere with process monitoring, file descriptor
passing and other functionality of the init system, it is recommended
not to execute them when run as new-style service."

So the use of "-i" seems justified.

I will wait for some input from Ian and Ian.

Wei.

>  [Install]
>  WantedBy=multi-user.target
> -- 
> 2.4.3

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

[Xen-devel] [linux-3.16 test] 63429: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-credit2  18 guest-localmigrate/x10   fail   like 62695
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62695
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62695
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 62695

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-multivcpu 18 guest-localmigrate/x10   fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   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-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-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-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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  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-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linuxe25b6bafc0accd7c59e131e1099ab22852e36777
baseline version:
 linuxe775020ec970a901190f1172e52d0bf2fb2b2ddd

Last test of basis62695  2015-10-06 11:14:59 Z   27 days
Testing same since63377  2015-10-30 14:14:30 Z3 days2 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adrian Hunter 
  Al Viro 
  Alex Williamson 
  Alexander Couzens 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Aneesh Kumar K.V 
  Arad, Ronen 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Benjamin Herrenschmidt 
  Bjorn Helgaas 
  Borislav Petkov 
  Carl Frederik Werner 
  Catalin Marinas 
  Charles Keepax 
  Chas Williams <3ch...@gmail.com>
  Christoph Biedl 
  Christoph Lameter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David S. Miller 
  David Woodhouse 
  David Woodhouse 
  Davidlohr Bueso 
  Dirk Brandewie 
  Dirk Mueller 
  Dirk Müller 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric W. Biederman 
  Eryu Guan 
  Fabiano Fidêncio 
  Filipe Manana 
  Geert Uytterhoeven 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Nikolaus Schaller 
  Ingo Molnar 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jani Nikula 
  Jann Horn 
  Jarkko Nikula 
  Jason Wang 
  Jeff Mahoney 
  Jenny Derzhavetz 
  Jiri Benc 
  Joe Pe

Re: [Xen-devel] [PATCH] x86/HAP: use %pv printk() format where suitable

[George Dunlap]

On 30/10/15 17:50, Jan Beulich wrote:
> Signed-off-by: Jan Beulich 

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

[Ross Lagerwall]

On 11/02/2015 04:37 PM, Wei Liu wrote:

On Mon, Nov 02, 2015 at 11:17:38AM +, Ross Lagerwall wrote:

Previously, xenconsoled's daemonize function would do nothing if its
parent process is init (as it is under systemd but not sysv init).
This is confusing. Instead, always daemonize when asked to, but use the
"interactive" switch when running from the systemd service.

Because a pidfile is only written when daemonizing, drop the pidfile
parameters from the service file (systemd keeps track of the pids
anyway).

Signed-off-by: Ross Lagerwall 
---
  tools/console/daemon/utils.c   | 4 
  tools/hotplug/Linux/systemd/xenconsoled.service.in | 3 +--
  2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/tools/console/daemon/utils.c b/tools/console/daemon/utils.c
index dbb3b12..644f6af 100644
--- a/tools/console/daemon/utils.c
+++ b/tools/console/daemon/utils.c
@@ -52,10 +52,6 @@ void daemonize(const char *pidfile)
int i;
char buf[100];

-   if (getppid() == 1) {
-   return;
-   }
-


Er, I never noticed this before. And code archeology doesn't tell me why
it was written like this either.


The fact that the service type was set to simple rather than forking was 
a sign...





if ((pid = fork()) > 0) {
exit(0);
} else if (pid == -1) {
diff --git a/tools/hotplug/Linux/systemd/xenconsoled.service.in 
b/tools/hotplug/Linux/systemd/xenconsoled.service.in
index cd282bf..8e333b1 100644
--- a/tools/hotplug/Linux/systemd/xenconsoled.service.in
+++ b/tools/hotplug/Linux/systemd/xenconsoled.service.in
@@ -10,10 +10,9 @@ Environment=XENCONSOLED_ARGS=
  Environment=XENCONSOLED_TRACE=none
  Environment=XENCONSOLED_LOG_DIR=@XEN_LOG_DIR@/console
  EnvironmentFile=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xencommons
-PIDFile=@XEN_RUN_DIR@/xenconsoled.pid
  ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
  ExecStartPre=/bin/mkdir -p ${XENCONSOLED_LOG_DIR}
-ExecStart=@sbindir@/xenconsoled --pid-file @XEN_RUN_DIR@/xenconsoled.pid 
--log=${XENCONSOLED_TRACE} --log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS
+ExecStart=@sbindir@/xenconsoled -i --log=${XENCONSOLED_TRACE} 
--log-dir=${XENCONSOLED_LOG_DIR} $XENCONSOLED_ARGS



To the best of my knowledge this seems to conform with man 7 daemon in
Linux, "New-Style Daemons" session:

"For developing a new-style daemon, none of the initialization steps
recommended for SysV daemons need to be implemented. New-style init
systems such as systemd make all of them redundant. Moreover, since some
of these steps interfere with process monitoring, file descriptor
passing and other functionality of the init system, it is recommended
not to execute them when run as new-style service."

So the use of "-i" seems justified.



If a service needs to listen on a port or something and other services 
need to depend on it, then the preferred method would be using something 
like sd_notify. A less satisfactory approach would be to use forking, 
and then only writing the pidfile after the port is opened.


In this case, I don't think xenconsoled has any of these requirements so 
using Type=simple and keeping it in the foreground is the correct thing 
to do.


--
Ross Lagerwall

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

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

[Jan Beulich]

>>> On 02.11.15 at 17:29,  wrote:
> On 30/10/15 17:39, Jan Beulich wrote:
>> Since calling the function isn't cheap, try to avoid the call when we
>> know up front it won't help; see the code comment for details on those
>> conditions.
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> --- a/xen/arch/x86/mm/p2m-pod.c
>> +++ b/xen/arch/x86/mm/p2m-pod.c
>> @@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
>>  if ( unlikely(d->is_dying) )
>>  goto out_unlock;
>>  
>> -recount:
>>  pod = nonpod = ram = 0;
>>  
>>  /* Figure out if we need to steal some freed memory for our cache */
>> @@ -562,15 +561,20 @@ recount:
>>  goto out_entry_check;
>>  }
>>  
>> -/* Try to grab entire superpages if possible.  Since the common case is 
> for drivers
>> - * to pass back singleton pages, see if we can take the whole page back 
> and mark the
>> - * rest PoD. */
>> -if ( steal_for_cache
>> - && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
>> -{
>> -/* Since order may be arbitrary, we may have taken more or less
>> - * than we were actually asked to; so just re-count from scratch */
>> -goto recount;
>> +/*
>> + * Try to grab entire superpages if possible.  Since the common case is 
> for
>> + * drivers to pass back singleton pages, see if we can take the whole 
> page
>> + * back and mark the rest PoD.
>> + * No need to do this though if
>> + * - order >= SUPERPAGE_ORDER (the loop below will take care of this)
>> + * - not all of the pages were RAM (now knowing order < SUPERPAGE_ORDER)
>> + */
>> +if ( steal_for_cache && order < SUPERPAGE_ORDER && (ram >> order) &&
>> + p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES - 1)) )
>> +{
>> +pod += ram;
>> +nonpod -= ram;
>> +ram = 0;
> 
> +1 for the idea; a couple of comments:
> 
> * I think it would be clearer to use "(ram == 1 << order)" instead of
> "ram >> order".  I understand (ram >> order) will be non-zero only if
> ram == 1 << order, but why make people spend brain cycles trying to
> figure that out?

Because I originally thought it makes the CPU spend less cycles
on the calculation. But that I think about it again, I guess I was
wrong (I would have been right only when order > 0 and the
compiler would be able to prove this and it would actually make
use of the knowledge using the status flags from the shift
instead of doing a subsequent test to get those flags set).

So - yes, will do.

> * If we're going to assume that "ram >> order" implies "all the entries
> are ram", and furthermore that a positive return value implies "all ram
> was changed to pod", wouldn't it be better to do something like the
> following?
> 
>   pod = 1 << order
>   nonpod = ram = 0
> 
> This would be more clearly correct if we change the comparison to ram ==
> 1 << order.

Well, yes, I can do that too. Here I really tried to avoid establishing
an unnecessary dependency between the if() condition and the body
(i.e. with how it is, the condition could change quite a bit without the
calculations getting wrong, whereas with what you want the
restrictions would be more tight).

> * steal_for_cache may now be wrong.  I realize that since now ram == 0
> that all the subsequent "steal_for_cache" expressions will end up as
> "false" anyway, but leaving invariants in an invalid state is sort of
> asking for trouble.
> 
> I'd prefer you just update steal_for_cache; but if not, at least leave a
> comment there saying that it may be wrong and why it doesn't matter.

I'll see whether updating is reasonably straightforward.

Jan


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

Re: [Xen-devel] [PATCH] xenconsoled: Remove unexpected daemonize behavior

[Ian Jackson]

Ross Lagerwall writes ("[PATCH] xenconsoled: Remove unexpected daemonize 
behavior"):
> Previously, xenconsoled's daemonize function would do nothing if its
> parent process is init (as it is under systemd but not sysv init).
> 
> This is confusing.

It's quite bogglesome, indeed.

> Instead, always daemonize when asked to, but use the
> "interactive" switch when running from the systemd service.
> 
> Because a pidfile is only written when daemonizing, drop the pidfile
> parameters from the service file (systemd keeps track of the pids
> anyway).

Acked-by: Ian Jackson 

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH] x86/PoD: tighten conditions for checking super page

[George Dunlap]

On 02/11/15 16:50, Jan Beulich wrote:
 On 02.11.15 at 17:29,  wrote:
>> On 30/10/15 17:39, Jan Beulich wrote:
>>> Since calling the function isn't cheap, try to avoid the call when we
>>> know up front it won't help; see the code comment for details on those
>>> conditions.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -522,7 +522,6 @@ p2m_pod_decrease_reservation(struct doma
>>>  if ( unlikely(d->is_dying) )
>>>  goto out_unlock;
>>>  
>>> -recount:
>>>  pod = nonpod = ram = 0;
>>>  
>>>  /* Figure out if we need to steal some freed memory for our cache */
>>> @@ -562,15 +561,20 @@ recount:
>>>  goto out_entry_check;
>>>  }
>>>  
>>> -/* Try to grab entire superpages if possible.  Since the common case 
>>> is 
>> for drivers
>>> - * to pass back singleton pages, see if we can take the whole page 
>>> back 
>> and mark the
>>> - * rest PoD. */
>>> -if ( steal_for_cache
>>> - && p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES-1)))
>>> -{
>>> -/* Since order may be arbitrary, we may have taken more or less
>>> - * than we were actually asked to; so just re-count from scratch */
>>> -goto recount;
>>> +/*
>>> + * Try to grab entire superpages if possible.  Since the common case 
>>> is 
>> for
>>> + * drivers to pass back singleton pages, see if we can take the whole 
>> page
>>> + * back and mark the rest PoD.
>>> + * No need to do this though if
>>> + * - order >= SUPERPAGE_ORDER (the loop below will take care of this)
>>> + * - not all of the pages were RAM (now knowing order < 
>>> SUPERPAGE_ORDER)
>>> + */
>>> +if ( steal_for_cache && order < SUPERPAGE_ORDER && (ram >> order) &&
>>> + p2m_pod_zero_check_superpage(p2m, gpfn & ~(SUPERPAGE_PAGES - 1)) )
>>> +{
>>> +pod += ram;
>>> +nonpod -= ram;
>>> +ram = 0;
>>
>> +1 for the idea; a couple of comments:
>>
>> * I think it would be clearer to use "(ram == 1 << order)" instead of
>> "ram >> order".  I understand (ram >> order) will be non-zero only if
>> ram == 1 << order, but why make people spend brain cycles trying to
>> figure that out?
> 
> Because I originally thought it makes the CPU spend less cycles
> on the calculation. But that I think about it again, I guess I was
> wrong (I would have been right only when order > 0 and the
> compiler would be able to prove this and it would actually make
> use of the knowledge using the status flags from the shift
> instead of doing a subsequent test to get those flags set).
> 
> So - yes, will do.
> 
>> * If we're going to assume that "ram >> order" implies "all the entries
>> are ram", and furthermore that a positive return value implies "all ram
>> was changed to pod", wouldn't it be better to do something like the
>> following?
>>
>>   pod = 1 << order
>>   nonpod = ram = 0
>>
>> This would be more clearly correct if we change the comparison to ram ==
>> 1 << order.
> 
> Well, yes, I can do that too. Here I really tried to avoid establishing
> an unnecessary dependency between the if() condition and the body
> (i.e. with how it is, the condition could change quite a bit without the
> calculations getting wrong, whereas with what you want the
> restrictions would be more tight).

Well in fact, one of the reasons I made my suggestion is because there
*is* a dependency between the if() condition and the body.  If you take
out (order < SUPERPAGE_ORDER), then (ram >> order) isn't a correct check
any more; and (for example) if order == SUPERPAGE_ORDER+1, then
subtracting ram is incorrect.  I wanted to make it more obvious.

Thanks,
 -George

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  990ea04ebedf543156dc2afa980061eb6645c390
baseline version:
 xen  e294a0c3af9f4443dc692b180fb1771b1cb075e8

Last test of basis63364  2015-10-29 16:00:57 Z4 days
Testing same since63484  2015-11-02 15:37:37 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Kun Suo 
  Wei Liu 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH RFC] vmalloc/vzalloc: Add memflags parameter.

[Konrad Rzeszutek Wilk]

And use it amongst the callers of this function.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/mm/hap/hap.c   | 2 +-
 xen/arch/x86/mm/shadow/common.c | 2 +-
 xen/common/domain.c | 2 +-
 xen/common/domctl.c | 2 +-
 xen/common/grant_table.c| 3 ++-
 xen/common/vmap.c   | 8 
 xen/include/asm-x86/domain.h| 4 ++--
 xen/include/xen/vmap.h  | 4 ++--
 8 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/mm/hap/hap.c b/xen/arch/x86/mm/hap/hap.c
index e9c0080..acc5219 100644
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -86,7 +86,7 @@ int hap_track_dirty_vram(struct domain *d,
 }
 
 rc = -ENOMEM;
-dirty_bitmap = vzalloc(size);
+dirty_bitmap = vzalloc(size, MEMF_node(domain_to_node(d)));
 if ( !dirty_bitmap )
 goto out;
 
diff --git a/xen/arch/x86/mm/shadow/common.c b/xen/arch/x86/mm/shadow/common.c
index bad355b..4169083 100644
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -3491,7 +3491,7 @@ int shadow_track_dirty_vram(struct domain *d,
 if ( !nr )
 goto out;
 
-dirty_bitmap = vzalloc(dirty_size);
+dirty_bitmap = vzalloc(dirty_size, MEMF_node(domain_to_node(d)));
 if ( dirty_bitmap == NULL )
 {
 rc = -ENOMEM;
diff --git a/xen/common/domain.c b/xen/common/domain.c
index b0378aa..55a94d4 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1223,7 +1223,7 @@ long do_vcpu_op(int cmd, unsigned int vcpuid, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 if ( v->vcpu_info == &dummy_vcpu_info )
 return -EINVAL;
 
-if ( (ctxt = alloc_vcpu_guest_context()) == NULL )
+if ( (ctxt = alloc_vcpu_guest_context(MEMF_node(domain_to_node(d 
== NULL )
 return -ENOMEM;
 
 if ( copy_from_guest(ctxt, arg, 1) )
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 46b967e..b874b01 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -492,7 +492,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
  < sizeof(struct compat_vcpu_guest_context));
 #endif
 ret = -ENOMEM;
-if ( (c.nat = alloc_vcpu_guest_context()) == NULL )
+if ( (c.nat = alloc_vcpu_guest_context(MEMF_node(domain_to_node(d 
== NULL )
 break;
 
 #ifdef CONFIG_COMPAT
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index c92abda..b86286f 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -3200,7 +3200,8 @@ grant_table_create(
 }
 
 /* Tracking of mapped foreign frames table */
-t->maptrack = vzalloc(max_maptrack_frames * sizeof(*t->maptrack));
+t->maptrack = vzalloc(max_maptrack_frames * sizeof(*t->maptrack),
+  MEMF_node(domain_to_node(d)));
 if ( t->maptrack == NULL )
 goto no_mem_2;
 
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index c57239f..fd295b1 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -216,7 +216,7 @@ void vunmap(const void *va)
 vm_free(va);
 }
 
-void *vmalloc(size_t size)
+void *vmalloc(size_t size, unsigned int memflags)
 {
 mfn_t *mfn;
 size_t pages, i;
@@ -232,7 +232,7 @@ void *vmalloc(size_t size)
 
 for ( i = 0; i < pages; i++ )
 {
-pg = alloc_domheap_page(NULL, 0);
+pg = alloc_domheap_page(NULL, memflags);
 if ( pg == NULL )
 goto error;
 mfn[i] = _mfn(page_to_mfn(pg));
@@ -252,9 +252,9 @@ void *vmalloc(size_t size)
 return NULL;
 }
 
-void *vzalloc(size_t size)
+void *vzalloc(size_t size, unsigned int memflags)
 {
-void *p = vmalloc(size);
+void *p = vmalloc(size, memflags);
 int i;
 
 if ( p == NULL )
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index f1d7ed6..a98bf3b 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -577,9 +577,9 @@ void domain_cpuid(struct domain *d,
 
 #define domain_max_vcpus(d) (is_hvm_domain(d) ? HVM_MAX_VCPUS : MAX_VIRT_CPUS)
 
-static inline struct vcpu_guest_context *alloc_vcpu_guest_context(void)
+static inline struct vcpu_guest_context *alloc_vcpu_guest_context(unsigned int 
memflags)
 {
-return vmalloc(sizeof(struct vcpu_guest_context));
+return vmalloc(sizeof(struct vcpu_guest_context), memflags);
 }
 
 static inline void free_vcpu_guest_context(struct vcpu_guest_context *vgc)
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 5671ac8..f24a29e 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -11,8 +11,8 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
  unsigned int nr, unsigned int align, unsigned int flags);
 void *vmap(const mfn_t *mfn, unsigned int nr);
 void vunmap(const void *);
-void *vmalloc(size_t size);
-void *vzalloc(size_t size);
+void *vmalloc(size_t size, unsigned int memflags);
+void *vzalloc(size_t size, unsigned i

[Xen-devel] [PATCH RFC] domain: Compile with lock_profile=y enabled.

[Konrad Rzeszutek Wilk]

Our 'struct domain' has when lock profiling is enabled is bigger than
one page.

We can't use vmap nor vzalloc as both of those stash the
physical address in struct page which makes the assumptions
in 'arch_init_memory' trip over ASSERTs.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/arch/x86/domain.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 4420cfc..a85b994 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -237,6 +237,7 @@ struct domain *alloc_domain_struct(void)
 #ifdef CONFIG_BIGMEM
 const unsigned int bits = 0;
 #else
+int order = get_order_from_bytes(sizeof(*d));
 /*
  * We pack the PDX of the domain structure into a 32-bit field within
  * the page_info structure. Hence the MEMF_bits() restriction.
@@ -247,10 +248,12 @@ struct domain *alloc_domain_struct(void)
  bits = _domain_struct_bits();
 #endif
 
-BUILD_BUG_ON(sizeof(*d) > PAGE_SIZE);
-d = alloc_xenheap_pages(0, MEMF_bits(bits));
+d = alloc_xenheap_pages(order, MEMF_bits(bits));
 if ( d != NULL )
-clear_page(d);
+{
+for ( ; order >= 0; order-- )
+clear_page((void *)d + PAGE_SIZE*order);
+}
 return d;
 }
 
-- 
2.1.0


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

Re: [Xen-devel] [PATCH] xen: fix the check of e_pfn in xen_find_pfn_range

[David Vrabel]

On 27/10/15 19:19, Konrad Rzeszutek Wilk wrote:
> From: Zhenzhong Duan 
> 
> On some NUMA system, after dom0 up, we see below warning even if there are
> enough pfn ranges that could be used for remapping:
> "Unable to find available pfn range, not remapping identity pages"
> 
> Fix it to avoid getting a memory region of zero size in xen_find_pfn_range.

Applied to for-linus-4.4, thanks.

David

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

[Xen-devel] [xen-4.5-testing test] 63437: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   like 63358
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 63358
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63358
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 63358
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 63358

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   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  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt 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-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  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  423d2cd814e8460d5ea8bd191a770f3c48b3947c
baseline version:
 xen  d3063bb2b118da2e84707f26a8d173c85a5d8f05

Last test of basis63358  2015-10-29 13:11:46 Z4 days
Testing same since63378  2015-10-30 14:14:34 Z3 days2 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-x

[Xen-devel] [PATCH 0/3] Futher cpuid handling cleanup

[Andrew Cooper]

Andrew Cooper (3):
  xen/x86: Correct {a,m}perf check in generic_identify()
  xen/x86: Query for paddr_bits in early_cpu_detect()
  xen/x86: Cleanup of early cpuid handling

 xen/arch/x86/cpu/common.c | 76 +++
 1 file changed, 38 insertions(+), 38 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] xen/x86: Cleanup of early cpuid handling

[Andrew Cooper]

Use register names for variables, rather than their content for leaf 1.
Reduce the number of cpuid instructions issued.  Also drop some trailing
whitespace.

No functional change.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpu/common.c | 69 +++
 1 file changed, 34 insertions(+), 35 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index ac8a258..c71fb13 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -180,7 +180,7 @@ static inline u32 phys_pkg_id(u32 cpuid_apic, int index_msb)
 static void __init early_cpu_detect(void)
 {
struct cpuinfo_x86 *c = &boot_cpu_data;
-   u32 cap4, tfms, cap0, misc;
+   u32 eax, ebx, ecx, edx;
 
c->x86_cache_alignment = 32;
 
@@ -192,21 +192,21 @@ static void __init early_cpu_detect(void)
 
c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_early);
 
-   cpuid(0x0001, &tfms, &misc, &cap4, &cap0);
-   c->x86 = (tfms >> 8) & 15;
-   c->x86_model = (tfms >> 4) & 15;
+   cpuid(0x0001, &eax, &ebx, &ecx, &edx);
+   c->x86 = (eax >> 8) & 15;
+   c->x86_model = (eax >> 4) & 15;
if (c->x86 == 0xf)
-   c->x86 += (tfms >> 20) & 0xff;
+   c->x86 += (eax >> 20) & 0xff;
if (c->x86 >= 0x6)
-   c->x86_model += ((tfms >> 16) & 0xF) << 4;
-   c->x86_mask = tfms & 15;
-   cap0 &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
-   cap4 &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
-   if (cap0 & cpufeat_mask(X86_FEATURE_CLFLSH))
-   c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8;
+   c->x86_model += ((eax >> 16) & 0xF) << 4;
+   c->x86_mask = eax & 15;
+   edx &= ~cleared_caps[cpufeat_word(X86_FEATURE_FPU)];
+   ecx &= ~cleared_caps[cpufeat_word(X86_FEATURE_XMM3)];
+   if (edx & cpufeat_mask(X86_FEATURE_CLFLSH))
+   c->x86_cache_alignment = ((ebx >> 8) & 0xff) * 8;
/* Leaf 0x1 capabilities filled in early for Xen. */
-   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = cap0;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = cap4;
+   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
 
if ( cpuid_eax(0x8000) >= 0x8008 )
paddr_bits = cpuid_eax(0x8008) & 0xff;
@@ -214,29 +214,29 @@ static void __init early_cpu_detect(void)
 
 static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
 {
-   u32 tfms, capability, excap, ebx;
+   u32 eax, ebx, ecx, edx, tmp;
 
/* Get vendor name */
cpuid(0x, &c->cpuid_level,
  (int *)&c->x86_vendor_id[0],
  (int *)&c->x86_vendor_id[8],
  (int *)&c->x86_vendor_id[4]);
-   
+
c->x86_vendor = get_cpu_vendor(c->x86_vendor_id, gcv_host_late);
/* Initialize the standard set of capabilities */
/* Note that the vendor-specific code below might override */
-   
+
/* Intel-defined flags: level 0x0001 */
-   cpuid(0x0001, &tfms, &ebx, &excap, &capability);
-   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = capability;
-   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = excap;
-   c->x86 = (tfms >> 8) & 15;
-   c->x86_model = (tfms >> 4) & 15;
+   cpuid(0x0001, &eax, &ebx, &ecx, &edx);
+   c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = edx;
+   c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = ecx;
+   c->x86 = (eax >> 8) & 15;
+   c->x86_model = (eax >> 4) & 15;
if (c->x86 == 0xf)
-   c->x86 += (tfms >> 20) & 0xff;
+   c->x86 += (eax >> 20) & 0xff;
if (c->x86 >= 0x6)
-   c->x86_model += ((tfms >> 16) & 0xF) << 4;
-   c->x86_mask = tfms & 15;
+   c->x86_model += ((eax >> 16) & 0xF) << 4;
+   c->x86_mask = eax & 15;
c->apicid = phys_pkg_id((ebx >> 24) & 0xFF, 0);
c->phys_proc_id = c->apicid;
if ( cpu_has(c, X86_FEATURE_CLFLSH) )
@@ -249,12 +249,12 @@ static void __cpuinit generic_identify(struct cpuinfo_x86 
*c)
/* AMD-defined flags: level 0x8001 */
c->extended_cpuid_level = cpuid_eax(0x8000);
if ( (c->extended_cpuid_level & 0x) == 0x8000 ) {
-   if ( c->extended_cpuid_level >= 0x8001 ) {
-   c->x86_capability[cpufeat_word(X86_FEATURE_SYSCALL)]
-   = cpuid_edx(0x8001);
-   c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)]
-   = cpuid_ecx(0x8001);
-   }
+   if ( c->extended_cpuid_level >= 0x8001 )
+   cpuid(0x8001, &tmp,
+ 
&c->x86_capability[cpufeat_word(X86_FEATURE_LAHF_LM)],
+ 
&c->x86

[Xen-devel] [PATCH 1/3] xen/x86: Correct {a, m}perf check in generic_identify()

[Andrew Cooper]

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpu/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 653b052..02f2504 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -239,7 +239,7 @@ static void __cpuinit generic_identify(struct cpuinfo_x86 
*c)
if ( cpu_has(c, X86_FEATURE_CLFLSH) )
c->x86_clflush_size = ((ebx >> 8) & 0xff) * 8;
 
-   if ( (c->cpuid_level > CPUID_PM_LEAF) &&
+   if ( (c->cpuid_level >= CPUID_PM_LEAF) &&
 (cpuid_ecx(CPUID_PM_LEAF) & CPUID6_ECX_APERFMPERF_CAPABILITY) )
set_bit(X86_FEATURE_APERFMPERF, c->x86_capability);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 2/3] xen/x86: Query for paddr_bits in early_cpu_detect()

[Andrew Cooper]

It is __read_mostly, so repeatedly writing to it is suboptiomal.  As the
MTRRs have already been set up, nothing good will come from its value
changing across CPUs.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/cpu/common.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c
index 02f2504..ac8a258 100644
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -207,6 +207,9 @@ static void __init early_cpu_detect(void)
/* Leaf 0x1 capabilities filled in early for Xen. */
c->x86_capability[cpufeat_word(X86_FEATURE_FPU)] = cap0;
c->x86_capability[cpufeat_word(X86_FEATURE_XMM3)] = cap4;
+
+   if ( cpuid_eax(0x8000) >= 0x8008 )
+   paddr_bits = cpuid_eax(0x8008) & 0xff;
 }
 
 static void __cpuinit generic_identify(struct cpuinfo_x86 *c)
@@ -254,8 +257,6 @@ static void __cpuinit generic_identify(struct cpuinfo_x86 
*c)
}
if ( c->extended_cpuid_level >= 0x8004 )
get_model_name(c); /* Default name */
-   if ( c->extended_cpuid_level >= 0x8008 )
-   paddr_bits = cpuid_eax(0x8008) & 0xff;
}
 
/* Might lift BIOS max_leaf=3 limit. */
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v3 1/6] xen: sched: fix locking of remove_vcpu() in credit1

[George Dunlap]

On 29/10/15 23:04, Dario Faggioli wrote:
> In fact, csched_vcpu_remove() (i.e., the credit1
> implementation of remove_vcpu()) manipulates runqueues,
> so holding the runqueue lock is necessary.
> 
> Also, while there, *_lock_irq() (for the private lock) is
> enough, there is no need to *_lock_irqsave().
> 
> Signed-off-by: Dario Faggioli 
> Reviewed-by: Andrew Cooper 
> ---
> Cc: George Dunlap 
> Cc: Jan Beulich 
> ---
> Changes from the other series:
>  * split the patch (wrt the original patch, in the original
>series), and take care, in this one, only of remove_vcpu();
>  * removed pointless parentheses.
> ---
>  xen/common/sched_credit.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index b8f28fe..6f71e0d 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -926,7 +926,7 @@ csched_vcpu_remove(const struct scheduler *ops, struct 
> vcpu *vc)
>  struct csched_private *prv = CSCHED_PRIV(ops);
>  struct csched_vcpu * const svc = CSCHED_VCPU(vc);
>  struct csched_dom * const sdom = svc->sdom;
> -unsigned long flags;
> +spinlock_t *lock;
>  
>  SCHED_STAT_CRANK(vcpu_remove);
>  
> @@ -936,15 +936,19 @@ csched_vcpu_remove(const struct scheduler *ops, struct 
> vcpu *vc)
>  vcpu_unpause(svc->vcpu);
>  }
>  
> +lock = vcpu_schedule_lock_irq(vc);
> +
>  if ( __vcpu_on_runq(svc) )
>  __runq_remove(svc);
>  
> -spin_lock_irqsave(&(prv->lock), flags);
> +vcpu_schedule_unlock_irq(lock, vc);

Actually, at this point the domain should be either paused or in the
middle of being destroyed, so it shouldn't be possible for the vcpu to
be on the runqueue, should it?  Should we instead change that if() to an
ASSERT(!__vcpu_on_runqueue(svc))?

 -George


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

Re: [Xen-devel] [PATCH v3 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

[George Dunlap]

On 29/10/15 23:04, Dario Faggioli wrote:
> schedule_cpu_switch() is meant to be only used for moving
> pCPUs from a cpupool to no cpupool, and from there back
> to a cpupool, *not* to move them directly from one cpupool
> to another.
> 
> This is something that is reflected in the way it is
> implemented, and should be kept in mind when looking at
> it. However, that is not that clear, by just the look of
> it.
> 
> Make it more evident by:
>  - adding commentary and ASSERT()s;
>  - update the cpupool per-CPU variable (mapping pCPUs to
>pools) directly in schedule_cpu_switch(), rather than
>in various places in cpupool.c.
> 
> Signed-off-by: Dario Faggioli 
> Acked-by: Juergen Gross 

Reviewed-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v3 6/6] xen: sched: get rid of the per domain vCPU list in Credit2

[George Dunlap]

On 29/10/15 23:04, Dario Faggioli wrote:
> As, curently, there is no reason for bothering having
> it and keeping it updated.
> 
> In fact, it is only used for dumping and changing
> vCPUs parameters, but that can be achieved easily with
> for_each_vcpu.
> 
> While there, improve alignment of comments, ad
> add a const qualifier to a pointer, making things
> more consistent with what happens everywhere else
> in the source file.
> 
> This also allows us to kill one of the remaining
> FIXMEs in the code, which is always good.
> 
> Signed-off-by: Dario Faggioli 

Acked-by: George Dunlap 


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

Re: [Xen-devel] [PATCH v3 5/6] xen: sched: get rid of the per domain vCPU list in RTDS

[George Dunlap]

On 29/10/15 23:04, Dario Faggioli wrote:
> As, curently, there is no reason for bothering having
> it and keeping it updated.
> 
> In fact, it is only used for dumping and changing
> vCPUs parameters, but that can be achieved easily with
> for_each_vcpu.
> 
> While there, take care of the case when
> XEN_DOMCTL_SCHEDOP_getinfo is called but no vCPUs have
> been allocated yet (by returning the default scheduling
> parameters).
> 
> Signed-off-by: Dario Faggioli 
> Reviewed-by: Meng Xu 

(FYI I don't think this needs my Ack)


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

[Xen-devel] [xen-4.6-testing test] 63449: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-multivcpu  3 host-install(3) broken in 63379 pass in 63449
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
pass in 63379
 test-armhf-armhf-xl-credit2  11 guest-start fail pass in 63379

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail in 63379 blocked in 63359

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 63379 never 
pass
 test-armhf-armhf-xl-credit2  12 migrate-support-check fail in 63379 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 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 17 guest-stop 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-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  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-amd64-amd64-libvirt-xsm 12 migrate-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-xl-rtds 16 guest-start/debian.repeatfail   never pass

version targeted for testing:
 xen  40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2
baseline version:
 xen  bdc9fdf9d468cb94ca0fbed1b969c20bf173dc9b

Last test of basis63359  2015-10-29 13:14:25 Z4 days
Testing same since63379  2015-10-30 17:09:57 Z3 days2 attempts


People who touched revisions under test:
  Ian Jackson 

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-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-amd64-pvgrub  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-pygrub   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-ovmf-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-ovmf-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-intel  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-debianhvm-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-i386-rumpuserxen-i386  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-debianhvm-amd64  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-xl-raw6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  6 xen-boot fail REGR. vs. 60684
 test-amd64-i386-freebsd10-i386  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl-qcow2 6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-xl-pvh-amd   6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-winxpsp3  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-xl-qemuu-winxpsp3  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-rumpuserxen-amd64  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. 
vs. 60684
 test-amd64-amd64-xl-multivcpu  6 xen-boot fail REGR. vs. 60684
 test-amd64-amd64-i386-pvgrub  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemut-rhel6hvm-amd  6 xen-bootfail REGR. vs. 60684
 test-amd64-amd64-xl-credit2   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-qemuu-rhel6hvm-amd  6 xen-bootfail REGR. vs. 60684
 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-win7-amd64  6 xen-boot   fail REGR. vs. 60684
 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
60684
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-libvirt-xsm  6 xen-boot  fail REGR. vs. 60684
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-xsm   6 xen-boot  fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684
 test-amd64-i386-libvirt-pair  9 xen-boot/src_host fail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail RE

[Xen-devel] [linux-3.16 baseline-only test] 38240: regressions - trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 38135

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 3 host-install(3) broken 
REGR. vs. 38135
 test-amd64-amd64-xl-credit2  18 guest-localmigrate/x10   fail   like 38135
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38135

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   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-intel 11 guest-start  fail  never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   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  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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-multivcpu 18 guest-localmigrate/x10   fail  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-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-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10   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
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linuxe25b6bafc0accd7c59e131e1099ab22852e36777
baseline version:
 linuxe775020ec970a901190f1172e52d0bf2fb2b2ddd

Last test of basis38135  2015-10-08 04:52:45 Z   25 days
Testing same since38240  2015-11-02 16:53:01 Z0 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Conole 
  Adrian Hunter 
  Al Viro 
  Alex Williamson 
  Alexander Couzens 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Vagin 
  Andy Lutomirski 
  Andy Shevchenko 
  Aneesh Kumar K.V 
  Arad, Ronen 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Benjamin Herrenschmidt 
  Bjorn Helgaas 
  Borislav Petkov 
  Carl Frederik Werner 
  Catalin Marinas 
  Charles Keepax 
  Chas Williams <3ch...@gmail.com>
  Christoph Biedl 
  Christoph Lameter 
  Darren Hart 
  Dave Airlie 
  David Howells 
  David S. Miller 
  David Woodhouse 
  David Woodhouse 
  Davidlohr Bueso 
  Dirk Brandewie 
  Dirk Mueller 
  Dirk Müller 
  Dmitry Vyukov 
  Eric Dumazet 
  Eric W. Biederman 
  Eryu Guan 
  Fabiano Fidêncio 
  Filipe Manana 
  Geert Uytterhoeven 
  Grazvydas Ignotas 
  Greg Kroah-Hartman 
  Guenter Roeck 
  Guillaume Nault 
  H. Nikolaus Schaller 
  Ingo Molnar 
  James Chapman 
  James Hogan 
  Jan Kara 
  Jani Nikula 
  Jann Horn 
  Jarkko Nikula 
  Jason Wang 
  Jeff Mahoney 
  Jenny Derzhavetz 
  Jiri Benc 
  Joe Perches 
  Johan Hovold 
  John