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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952
baseline version:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a

Last test of basis   100533  2016-08-17 13:20:04 Z0 days
Testing same since   100537  2016-08-17 22:15:49 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Lars Kurth 

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

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

[Platform Team regression test user]

This run is configured for baseline tests only.

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

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

Last test of basis67542  2016-08-16 20:18:00 Z1 days
Testing same since67550  2016-08-17 08:19:21 Z0 days1 attempts


People who touched revisions under test:
  Chao Zhang 
  Zhang, Chao B 

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



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

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

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


Push not applicable.


commit fd4d9c6495109979eb17779e07666c7c11c79c6a
Author: Zhang, Chao B 
Date:   Tue Aug 16 10:21:42 2016 +0800

SecurityPkg: AuthVariableLib: Fix inconsistent CertDB case

  2 steps are used to create/delete a time based variable.
  For create
 step 1: Insert Signer Cert to CertDB.
 Step 2: Insert Payload to Variable.
  For delete
 step 1: Delete Variable.
 Step 2: Delete Cert from CertDB.
  System may breaks between step 1 & step 2, so CertDB may contains useless
Cert in the next reboot. AuthVariableLib choose to sync consistent state
between CertDB & Time Auth Variable on initialization. However, it doesn't
apply Time Auth attribute check. Now add it.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
Reviewed-by: Fu Siyuan 
Reviewed-by: Zeng Star 

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Lan, Tianyu]

On 8/17/2016 8:42 PM, Paul Durrant wrote:

-Original Message-
From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
Lan, Tianyu
Sent: 17 August 2016 13:06
To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun
Nakajima; Stefano Stabellini
Cc: Anthony Perard; xuqu...@huawei.com; xen-
de...@lists.xensource.com; Ian Jackson; Roger Pau Monne
Subject: [Xen-devel] Xen virtual IOMMU high level design doc

Hi All:
  The following is our Xen vIOMMU high level design for detail
discussion. Please have a look. Very appreciate for your comments.
This design doesn't cover changes when root port is moved to hypervisor.
We may design it later.


Content:
==
=
1. Motivation of vIOMMU
1.1 Enable more than 255 vcpus
1.2 Support VFIO-based user space driver
1.3 Support guest Shared Virtual Memory (SVM)
2. Xen vIOMMU Architecture
2.1 2th level translation overview
2.2 Interrupt remapping overview
3. Xen hypervisor
3.1 New vIOMMU hypercall interface


Would it not have been better to build on the previously discussed (and mostly 
agreed) PV IOMMU interface? (See 
https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01428.html). An 
RFC implementation series was also posted 
(https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01441.html).

  Paul



Hi Paul:
Thanks for your input. Glance the patchset and it introduces hypercall
"HYPERVISOR_iommu_op". The hypercall just works for PV IOMMU now. We may
abstract it and make it work for both PV and Virtual IOMMU.



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

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

[Doug Goldstein]

On 8/17/16 7:49 AM, Jan Beulich wrote:
 On 17.08.16 at 01:28,  wrote:
>> There can only ever be one mtrr_if now and that is the generic
>> implementation
> 
> This is only true when taking into consideration that cpu_has_mtrr
> is #define-d to 1 right now. I'm not sure that's actually a good
> assumption (especially when think about running Xen itself
> virtualized, or possibly adding a mode of operation where no MTRRs
> are to be used). But if we want to keep it that way, then I'd suggest
> this patch should include removing cpu_has_mtrr (which will then
> show to the reviewers that the checks of mtrr_if against NULL
> indeed are dead code.

Sure I can remove cpu_has_mtrr that would certainly make it cleaner. Is
it ok with you and Andrew to make the assumption that we'll always have
MTRRs (until the day we don't like you described)?

> 
>> @@ -569,22 +561,19 @@ struct mtrr_value {
>>  void __init mtrr_bp_init(void)
>>  {
>>  if (cpu_has_mtrr) {
>> -mtrr_if = _mtrr_ops;
>>  size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
>>  size_and_mask = ~size_or_mask & 0xf0ULL;
>>  }
>>  
>> -if (mtrr_if) {
>> -set_num_var_ranges();
>> -init_table();
>> -if (use_intel())
>> -get_mtrr_state();
>> -}
>> +set_num_var_ranges();
>> +init_table();
>> +if (use_intel())
>> +get_mtrr_state();
>>  }
> 
> Please don't break indentation style.

Sad panda. This file has tabs. Sorry I missed that.

> 
>> --- a/xen/arch/x86/cpu/mtrr/mtrr.h
>> +++ b/xen/arch/x86/cpu/mtrr/mtrr.h
>> @@ -63,8 +63,8 @@ extern void set_mtrr_ops(const struct mtrr_ops *);
>>  extern u64 size_or_mask, size_and_mask;
>>  extern const struct mtrr_ops *mtrr_if;
>>  
>> -#define is_cpu(vnd) (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
>> -#define use_intel() (mtrr_if && mtrr_if->use_intel_if == 1)
>> +#define is_cpu(vnd) (X86_VENDOR_INTEL == X86_VENDOR_##vnd)
>> +#define use_intel() (1)
> 
> Is the latter really useful to keep then?

Would you like me to squash patch 4 into this or make a note in the
commit message that further clean ups are coming?

--
Doug Goldstein



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

Re: [Xen-devel] [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static

[Doug Goldstein]

On 8/17/16 7:36 AM, Jan Beulich wrote:
 On 17.08.16 at 01:28,  wrote:
>> For the functions that make up the interface to the MTRR code, drop the
>> static keyword and prefix them all with mtrr for improved clarity when
>> they're called outside this file. This also required adjusting or
>> providing function prototypes to make them callable.
> 
> I can see why you want to do this for non-static functions, but I can't
> see why static ones would need to get altered (unless you mean to call
> them directly in subsequent patches, in which case the rationale above
> should be adjusted). Nor can I see why the two functions previously
> having been non-static can't simply be made static, without changing
> their names, as the patch demonstrates that they don't have callers
> in other CUs.
> 
> Jan
> 

I've added:

Future changes will directly call these functions instead of using the
indirect call through the ops structure.

Does that work?

-- 
Doug Goldstein



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

Re: [Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

[Meng Xu]

On Wed, Aug 17, 2016 at 1:18 PM, Dario Faggioli
 wrote:
>
> As far as {csched, csched2, rt}_schedule() are concerned,
> an "empty" event, would already make it easier to read and
> understand a trace.
>
> But while there, add a few useful information, like
> if the cpu that is going through the scheduler has
> been tickled or not, if it is currently idle, etc
> (they vary, on a per-scheduler basis).
>
> For Credit1 and Credit2, add a record about when
> rate-limiting kicks in too.
>
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
> Cc: Meng Xu 
> Cc: Anshul Makkar 
> ---
>  xen/common/sched_credit.c  |7 +++
>  xen/common/sched_credit2.c |   38 +-
>  xen/common/sched_rt.c  |   15 +++
>  3 files changed, 59 insertions(+), 1 deletion(-)
>


> diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
> index 41c61a7..903dbd8 100644
> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c
> @@ -160,6 +160,7 @@
>  #define TRC_RTDS_BUDGET_BURN  TRC_SCHED_CLASS_EVT(RTDS, 3)
>  #define TRC_RTDS_BUDGET_REPLENISH TRC_SCHED_CLASS_EVT(RTDS, 4)
>  #define TRC_RTDS_SCHED_TASKLETTRC_SCHED_CLASS_EVT(RTDS, 5)
> +#define TRC_RTDS_SCHEDULE TRC_SCHED_CLASS_EVT(RTDS, 6)
>
>  static void repl_timer_handler(void *data);
>
> @@ -1035,6 +1036,20 @@ rt_schedule(const struct scheduler *ops, s_time_t now, 
> bool_t tasklet_work_sched
>  struct rt_vcpu *snext = NULL;
>  struct task_slice ret = { .migrated = 0 };
>
> +/* TRACE */
> +{
> +struct __packed {
> +unsigned cpu:17, tasklet:8, tickled:4, idle:4;
> +} d;
> +d.cpu = cpu;
> +d.tasklet = tasklet_work_scheduled;
> +d.tickled = cpumask_test_cpu(cpu, >tickled);
> +d.idle = is_idle_vcpu(current);
> +__trace_var(TRC_RTDS_SCHEDULE, 1,
> +sizeof(d),
> +(unsigned char *));
> +}

I have two questions here:
1) IMHO, the trace should be wrapped by the if (
unlikely(tb_init_done) ) {} statement as done in sched_credit2.c.
Otherwise, we always enable the tracing which may hurt the
performance, I think.

2) Why does the cpu field here use 17 bits instead of 16 bits as used
in credit2?
This may be a typo I guess (since you are trying to align the
structure to 32 bits I guess ;-) )?
In addition, I'm wondering if uint16 is better than unsigned? I'm not
that confident if unsigned type will always have 16 bits on all types
of machines?

Thanks,

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
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

[Dario Faggioli]

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote:
> The last 4 patches, still for Credit2, are optimizations, either wrt
> existing
> code, or wrt new code introduced in this series. I've chosen to keep
> them
> separate to make reviewing/understanding new code easier. In fact,
> although
> they look pretty simple, the soft-affinity code was pretty complex
> already, and
> even these simple optimization, if done all at once, would have made
> the
> reviewer's life (unnecessary) tougher.
> 
About this.

I've run the benchmarks with and without these performance optimization
patches, in order to assess their effect as good as I could.

The baseline on top of which I was applying the series is different
from the one used to produce the other numbers reported in the cover
letter, so what's shown there and what I show here is not directly
comparable (but that's not a problem).

Given the nature of the improvements, I've run more iterations of each
configuration of the benchmarks (i.e., 15 iterations instead of 5) to
get more stable results.

Here's my findings:

++
|    CREDIT1, for reference      |
++
|               | MAKEXEN IPERF  |
|---||
|no dom0 load   | 28.353  11.793 |
|with dom0 load | 43.955  10.932*|
++
++
|   CREDIT2, until patch 20      |
++
|               | MAKEXEN IPERF  |
|---| ---|
|no dom0 load   | 28.367  11.716 |
|with dom0 load | 40.591  10.645 |
++
|+
|    CREDIT2, full series        |
++
|               | MAKEXEN IPERF  |
|---||
|no dom0 load   | 27.597* 12.059*|
|with dom0 load | 39.706* 10.609 |
||

 * marks the best results

So:
 - apart from a glitch on "IPERF with dom0 load", Credit2 with the 
   full series applied is confirmed to be the best. About the glitch:
    - wrt the fact that Credit1 is better, we also have other evidences
      that network throughput could be a bit of a weak spot of Credit2
      versus Credit1 so far (although, we have to admit, they're
      pretty close), and we already have ideas on how to try improve
      the situation;
    - wrt the role played by optimization patches, well, results are
      basically the same.
 - The performance optimization patches do have an (positive!) impact.
 - In case of "no dom0 load, it's actually thanks to the optimization
   patches that Credit2 beats Credit1.

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



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

Re: [Xen-devel] [PATCH 02/24] xen: credit1: fix mask to be used for tickling in Credit1

[Dario Faggioli]

On Wed, 2016-08-17 at 19:17 +0200, Dario Faggioli wrote:
> If there are idle pcpus inside the waking vcpu's
> soft-affinity mask, we should really tickle one
> of them (this is one of the purposes of the
> __runq_tickle() function itself!), not just
> any idle pcpu.
> 
> The issue has been introduced in 02ea5031825d
> ("credit1: properly deal with pCPUs not in any cpupool"),
> where the usage of idle_mask is changed, without
> updating the bottom of the function, where it
> is also referenced.
> 
> Signed-off-by: Dario Faggioli 
> ---
> Cc: George Dunlap 
>
Oops!

Sorry George, got your email address wrong for this one.
Dario

> Cc: Anshul Makkar 
> Cc: David Vrabel 
> ---
> David, a while ago you asked what could have been that was causing
> awful
> results for Credit1, for CPU bound workloads, in the overloaded
> scenario of one
> of my benchmarks. I think the bug fixed either here or in next patch
> (but I'd
> be rather sure it's this one) is where the problem was. :-)
> ---
>  xen/common/sched_credit.c |5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> index 6eccf09..3d4f223 100644
> --- a/xen/common/sched_credit.c
> +++ b/xen/common/sched_credit.c
> @@ -454,11 +454,12 @@ static inline void __runq_tickle(struct
> csched_vcpu *new)
>  if ( opt_tickle_one_idle )
>  {
>  this_cpu(last_tickle_cpu) =
> -cpumask_cycle(this_cpu(last_tickle_cpu),
> _mask);
> +cpumask_cycle(this_cpu(last_tickle_cpu),
> +  cpumask_scratch_cpu(cpu));
>  __cpumask_set_cpu(this_cpu(last_tickle_cpu),
> );
>  }
>  else
> -cpumask_or(, , _mask);
> +cpumask_or(, ,
> cpumask_scratch_cpu(cpu));
>  }
>  
>  /* Did we find anyone? */
> 
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH 0/2] tools/libs: don't use alloca(3)

[Dario Faggioli]

On Wed, 2016-08-17 at 15:33 +0100, Wei Liu wrote:
> Wei Liu (2):
>   libs/gnttab: do not use alloca(3)
>   libs/foreignmemory: do not use alloca(3)
> 
FWIW, both patches:

Reviewed-by: Dario Faggioli 

Out of curiosity, I've tried to figure out what the advantage was in
using alloca() instead of mmap(), in case of mappings smaller than
PAGE_SIZE (did also a small bit of archaeology but that didn't help
either).

Oh, well.

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



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

Re: [Xen-devel] unable start xen in hikey

[Kamenee Arumugam]

Hi Chen,

My previous issue was resolved when i used hi6220-hikey.dtb from this
source: https://github.com/kuscsik/device-linaro-hikey-kernel. When I
download linux kernel, there doesn't seems to contain hi6220-hikey.dtb.

But now it got stuck while loading Dom0 and below are log traces:


(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 7a037000
(XEN) Loading ramdisk from boot module @ 0ae0
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x004000-0x006000 (512MB)
(XEN) Grant table range: 0x0005c0-0x0005c54000
(XEN) Loading zImage from 7a037000 to
4008-40ce8c00
(XEN) Loading dom0 initrd from 0ae0 to
0x4820-0x48a0
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x4800-0x4800af11
(XEN) Scrubbing Free RAM on 1 nodes using 8 CPUs
(XEN) ..done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: Errors and warnings
(XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings)
(XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input
to Xen)
(XEN) Freed 284kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d0v2: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d0v3: vGICD: unhandled word write 0x to ICACTIVER0

It just hang there after the last line above.
I have looked into those messages " d0v3: vGICD: unhandled word write
0x to ICACTIVER0"  and linux kernel already taking care to ignore
it. Therefore, I believe this is not contributing to there hang here. Any
idea on this issue?

Thanks,
Kamenee


On Wed, Aug 10, 2016 at 9:11 PM, Chenxiao Zhao 
wrote:

> You should compile kernel first. Please follow the "Getting Started" page
> on 96boards
>
> On 8/10/2016 7:07 AM, Kamenee Arumugam wrote:
>
>> Hi Chen,
>>
>> I have tried to flash UEFI in my board with latest one but still facing
>> the same issue. Regarding to use dtb file from kernel source, I couldnt
>> find hi6220-hikey.dtb in my source kernel. i am downloading my kernel
>> source from
>> here: https://github.com/96boards/linux/tree/android-hikey-linaro-4.1
>>
>> I only could find hi6220-hikey.dts file in the kernel source. Therefore
>> download from other github but which is correct one that i need to use?
>> In case, I am using incorrect kernel source, pls point to me to correct
>> one if you aware of?
>>
>> Thanks,
>> Kamenee
>>
>> On Thu, Aug 4, 2016 at 11:06 PM, Chenxiao Zhao > > wrote:
>>
>> The xen.cfg file seems fine to me. I suggest you try to use the dtb
>> file compiled from the kernel source and update UEFI bootloader on
>> hikey board to the latest version.
>>
>> hope this could help.
>>
>> On 8/4/2016 11:02 PM, Kamenee Arumugam wrote:
>>
>> I have already pass hi6220-key.dtb in my xen.cfg:
>>
>> options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x
>> dtuart=/smb/uart@f7113000
>> kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
>> dtb=hi6220-hikey.dtb
>>
>> I download the hi6220-hikey.dtb from this site:
>> https://android.googlesource.com/device/linaro/hikey-kernel/
>> +/f117fa12746b59aa0a1a4d6335145e58935c422b/hi6220-hikey.dtb
>> > /+/f117fa12746b59aa0a1a4d6335145e58935c422b/hi6220-hikey.dtb>
>>
>>
>> Firstly, I build kernel using the command below:
>>
>> make -j24 Image hi6220-hikey.dtb
>>
>> I placed hikey6220-hikey.dtb in linux directory level. I also
>> copied the
>> dtb into sd before booting up. Please correct me if my steps are
>> wrong.
>>
>>
>> On Thu, Aug 4, 2016 at 3:27 AM, Chenxiao Zhao
>> 
>> > >> wrote:
>>
>> you have to pass hi6220-key.dtb to xen.
>>
>> On Thu, Aug 4, 2016 at 2:15 AM Kamenee Arumugam
>> 
>> >>
>> wrote:
>>
>> Hi all,
>>
>> I am unable to start xen in hikey successfully but
>> getting to
>> this prompt message:
>>
>>
>> >/Xen 4.7.0 (c/s Mon Jun 20 11:38:15 2016 +0100
>> git:9a6cc4f) EFI

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a
baseline version:
 xen  a55ad65d3a30d5b3a026a7481ce05f28065920f0

Last test of basis   100488  2016-08-15 01:58:52 Z2 days
Failing since100492  2016-08-15 10:43:55 Z2 days4 attempts
Testing same since   100518  2016-08-16 19:11:11 Z1 days2 attempts


People who touched revisions under test:
  Jan Beulich 

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

[Xen-devel] [distros-debian-squeeze test] 67547: tolerable FAIL

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
66959
 test-amd64-amd64-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 
66959
 test-amd64-i386-i386-squeeze-netboot-pygrub 9 debian-di-install fail like 66959
 test-amd64-i386-amd64-squeeze-netboot-pygrub 9 debian-di-install fail like 
66959

baseline version:
 flight   66959

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubfail
 test-amd64-i386-amd64-squeeze-netboot-pygrub fail
 test-amd64-amd64-i386-squeeze-netboot-pygrub fail
 test-amd64-i386-i386-squeeze-netboot-pygrub  fail



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

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

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


Push not applicable.


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

[Xen-devel] [linux-3.14 baseline-only test] 67546: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 66970
 build-amd64-rumpuserxen   6 xen-buildfail   like 66970
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66970
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66970
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66970
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66970

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 linuxc0e754d6bff2367d1de98e637285c8efbd1680ea
baseline version:
 linuxb8b6a72089869dee41bd9f29e86bbcf6501e5524

Last test of basis66970  2016-08-11 09:50:48 Z6 days
Testing same since67546  2016-08-17 04:50:00 Z0 days1 attempts


People who touched revisions under test:
  Alan Stern 
  Alexandru Cornea 
  Andrew Morton 
  Andy Lutomirski 
  Beniamino Galvani 
  Bjørn Mork 
  Charles (Chas) Williams 
  Chas Williams <3ch...@gmail.com>
  Chas Williams 
  Christoph Hellwig 
  Dave Weinstein 
  David Howells 
  David S. Miller 
  Doug Ledford 
  Eric Dumazet 
  Fabian Frederick 
  Greg Kroah-Hartman 
  Herbert Xu 
  Hugh Dickins 
  Ingo Molnar 
  Jack Wang 
  James Bottomley 
  James E.J. Bottomley 
  Jan Kara 
  Jan Kara 
  Jason Gunthorpe 
  Jens Axboe 
  John Johansen 
  Karl Heiss 
  Linus Torvalds 
  Luis Henriques 
  Martin K. Petersen 
  Miklos Szeredi 
  Neal Cardwell 
  Phil Turnbull 
  Ralf Baechle 
  Seth Arnold 
  Soheil Hassas Yeganeh 
  Tejun Heo 
  Theodore Ts'o 
  Vegard Nossum 
  Wei Fang 
  Yuchung Cheng 

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

[Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

[Konrad Rzeszutek Wilk]

Hey Jan, et. al.,

One of the interesting things about XSA 154 fix ("x86: enforce consistent
cachability of MMIO mappings") is that when certain applications (mcelog)
are trying to map /dev/mmap and lurk in ISA regions - we get:

[   49.399053] WARNING: CPU: 0 PID: 2471 at arch/x86/mm/pat.c:913 
untrack_pfn+0x93/0xc0()
[   49.399055] Modules linked in: bnx2fc fcoe libfcoe libfc 8021q mrp garp stp 
llc bonding dm_multipath vfat fat iTCO_wdt iTCO_vendor_support pcspkr 
ipmi_devintf ipmi_si ipmi_msghandler sb_edac edac_core i2c_i801 i2c_core 
lpc_ich mfd_core shpchp ioatdma sg ext4 jbd2 mbcache sr_mod cdrom sd_mod 
usb_storage ahci libahci megaraid_sas qla2xxx scsi_transport_fc crc32c_intel 
be2iscsi bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi ipv6 cxgb3 libiscsi_tcp 
qla4xxx iscsi_boot_sysfs libiscsi scsi_transport_iscsi ixgbe dca ptp pps_core 
vxlan udp_tunnel ip6_udp_tunnel mdio dm_mirror dm_region_hash dm_log dm_mod
[   49.399131] CPU: 0 PID: 2471 Comm: mcelog Not tainted 4.1
[   49.399134] Hardware name: Oracle Corporation SUN SERVER X4-2   
/ASSY,MB,X4-2, 1U  , BIOS 25030100 04/15/2015
[   49.399138]   880074673c28 816c66f0 

[   49.399143]  0391 880074673c68 81084745 
880074673c78
[   49.399148]  88014b625db0  880074673d58 
7f39290ab000
[   49.399152] Call Trace:
[   49.399166]  [] dump_stack+0x63/0x83
[   49.399175]  [] warn_slowpath_common+0x95/0xe0
[   49.399180]  [] warn_slowpath_null+0x1a/0x20
[   49.399183]  [] untrack_pfn+0x93/0xc0
[   49.399190]  [] unmap_single_vma+0xa9/0x100
[   49.399194]  [] unmap_vmas+0x54/0xa0
[   49.399199]  [] exit_mmap+0x9a/0x150
[   49.399204]  [] mmput+0x73/0x110
[   49.399208]  [] dup_mm+0x105/0x110
[   49.399213]  [] copy_process+0x11ed/0x1240
[   49.399218]  [] do_fork+0x79/0x280
[   49.399226]  [] ? syscall_trace_enter_phase1+0x153/0x180
[   49.399231]  [] SyS_clone+0x16/0x20
[   49.399235]  [] system_call_fastpath+0x12/0x71
[   49.399239] ---[ end trace a61cd3d271a53a54 ]---

The reason is that Linux kernel assumes that the range from 640KB -> 1MB can
be mapped as write-back (see is_new_memtype_allowed and 
x86_platform.is_untracked_pat_range).
But we enforce the uncached mode and Linux complains.

With the mmio-relax=1, Linux gets its way and is happy.

With the patch below:

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 70a38c1..e5ff5a5 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -288,6 +287,12 @@ static void __init xen_banner(void)
   version >> 16, version & 0x, extra.extraversion,
   xen_feature(XENFEAT_mmu_pt_update_preserve_ad) ? " 
(preserve-AD)" : "");
 }
+
+static bool xen_ignore(u64 s, u64 e)
+{
+   return false;
+}
+
 /* Check if running on Xen version (major, minor) or later */
 bool
 xen_running_on_version_or_later(unsigned int major, unsigned int minor)
@@ -1563,7 +1570,7 @@ asmlinkage __visible void __init xen_start_kernel(void)
x86_init.resources.memory_setup = xen_memory_setup;
x86_init.oem.arch_setup = xen_arch_setup;
x86_init.oem.banner = xen_banner;
-
+   x86_platform.is_untracked_pat_range = xen_ignore;
xen_init_time_ops();
 
/*

Things work much better - as we don't treat the 640KB->1MB region specially.

Anyhow what I am wondering:

 a) Should we add a edge case in the hypervisor to allow multiple mappings
   for this region? I am thinking no.. but it sounds like mapping ISA region
   as WB is safe even in baremetal?

 b) Or would it be better to let Linux do its thing and treat 640KB->1MB
   as uncached instead of writeback?

   Looking at the kernel it assumes that WB is ok for 640KB->1MB.
   The comment says:
   " /* Low ISA region is always mapped WB in page table. No need to track *"

   which is probably true on baremetal. But with Xen PV:

 856 /* 
 
 857  * In domU, the ISA region is normal, usable memory, but we
 
 858  * reserve ISA memory anyway because too many things poke  
 
 859  * about in there. 
 
 860  */
 
 861 e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - 
ISA_START_ADDRESS, 
 862 E820_RESERVED); 

   which would imply we don't have any page table mappings.

   And then the quick fix I provided above looks like the right solution?


CC-ing Boris, Daniel, Juergen, Steve, and Chuck.

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

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Andrew Cooper]

On 17/08/2016 20:57, Julien Grall wrote:
> Hi Konrad,
>
> On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:
>> On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
>>> On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
>
> [...]
>
 diff --git a/xen/common/Makefile b/xen/common/Makefile
 index 22806b6..fe83653 100644
 --- a/xen/common/Makefile
 +++ b/xen/common/Makefile
 @@ -82,6 +82,6 @@ subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt

  .PHONY: tests
  tests:
 -ifeq ($(XEN_TARGET_ARCH),x86_64)
 +ifneq ($(XEN_TARGET_ARCH),arm32)
  $(MAKE) -f $(BASEDIR)/Rules.mk -C test livepatch
  endif
 diff --git a/xen/common/test/Makefile b/xen/common/test/Makefile
 index 23dff1d..3eed6dd 100644
 --- a/xen/common/test/Makefile
 +++ b/xen/common/test/Makefile
 @@ -1,5 +1,11 @@
  include $(XEN_ROOT)/Config.mk

 +ifeq ($(XEN_TARGET_ARCH),x86_64)
 +OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
 +else
>>>
>>> Is there any reason to fallback on arm64 flags by default? Would not
>>> it be
>>> better to have an else if here?
>>>
 +OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64
>>
>> I presume you are referring to this comment. I am not sure how you would
>> identify whether the elf64-littleaarch64 is not part of the OBJCOPY?
>>
>> Oh I guess you can: objcopy --info
>>
>> Or are you saying just use 'arm64' instead of 'aarch64' ?
>
> I was suggesting to do
>
> ifeq ($(XEN_TARGET_ARCH),x86_64))
> OBJCOPY_MAGIC := ...
> endif
> ifeq ($(XEN_TARGET_ARCH),arm64))
> OBJCOPY_MAGIC := ...
> endif

You can chain "else ifeq" together like this in a makefile to avoid most
of those endif's

~Andrew

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

Re: [Xen-devel] [PATCH v2 5/6] xen/arm: traps: Avoid unnecessary VA -> IPA translation in abort handlers

[Shanker Donthineni]

On 08/17/2016 06:11 AM, Julien Grall wrote:

On 17/08/16 03:19, Shanker Donthineni wrote:

Hi Julien,


Hello Shanker,


On 07/27/2016 12:09 PM, Julien Grall wrote:

Translating a VA to a IPA is expensive. Currently, Xen is assuming that
HPFAR_EL2 is only valid when the stage-2 data/instruction abort 
happened

during a translation table walk of a first stage translation (i.e S1PTW
is set).

However, based on the ARM ARM (D7.2.34 in DDI 0487A.j), the register is
also valid when the data/instruction abort occured for a translation
fault.

With this change, the VA -> IPA translation will only happen for
permission faults that are not related to a translation table of a
first stage translation.

Signed-off-by: Julien Grall 

---
 Changes in v2:
 - Use fsc in the switch in do_trap_data_abort_guest
---
  xen/arch/arm/traps.c | 24 
  1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ea105f2..83a30fa 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2382,13 +2382,28 @@ static inline paddr_t get_faulting_ipa(vaddr_t
gva)
  return ipa;
  }

+static inline bool hpfar_is_valid(bool s1ptw, uint8_t fsc)
+{
+/*
+ * HPFAR is valid if one of the following cases are true:
+ *  1. the stage 2 fault happen during a stage 1 page table walk
+ *  (the bit ESR_EL2.S1PTW is set)
+ *  2. the fault was due to a translation fault
+ *
+ * Note that technically HPFAR is valid for other cases, but they
+ * are currently not supported by Xen.
+ */
+return s1ptw || (fsc == FSC_FLT_TRANS);


Yes, XEN is not supporting the stage 2 access flag but we should handle
a stage 2 address size fault.


The function hpfar_is_valid indicates whether the register HPFAR is 
valid. If the function returns false, Xen will use the hardware do the 
translation.


It will only lead to a waste of cycle but this is fine as the address 
size fault is not a hot path for now.



I think we should do some thing like to below to match ARM ARM.

return s1ptw || (fsc != FSC_FLT_PERM);


This does not match the ARM ARM, with this check you consider that 
HPFAR will be valid for all the fault but permission ones which is not 
true.


I purposefully choose a white list because it is safer to use the 
hardware to do the translation more often than the invert.


So I don't see why we should handle stage 2 access flag with the 
current Xen. If you still disagree, please explain why with a concrete 
example.




Agree with you, I have suggested the above change because I saw the same 
check in Linux KVM.
As per ARM ARM, it should be 'return s1ptw || (fsc == FSC_FLT_TRANS) || 
(fsc == FSC_FLT_ACCESS) || (fsc == 0x00)';



Regards,



--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.


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

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Julien Grall]

Hi Konrad,

On 17/08/2016 20:00, Konrad Rzeszutek Wilk wrote:

On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:

On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:


[...]


diff --git a/xen/common/Makefile b/xen/common/Makefile
index 22806b6..fe83653 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -82,6 +82,6 @@ subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt

 .PHONY: tests
 tests:
-ifeq ($(XEN_TARGET_ARCH),x86_64)
+ifneq ($(XEN_TARGET_ARCH),arm32)
$(MAKE) -f $(BASEDIR)/Rules.mk -C test livepatch
 endif
diff --git a/xen/common/test/Makefile b/xen/common/test/Makefile
index 23dff1d..3eed6dd 100644
--- a/xen/common/test/Makefile
+++ b/xen/common/test/Makefile
@@ -1,5 +1,11 @@
 include $(XEN_ROOT)/Config.mk

+ifeq ($(XEN_TARGET_ARCH),x86_64)
+OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
+else


Is there any reason to fallback on arm64 flags by default? Would not it be
better to have an else if here?


+OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64


I presume you are referring to this comment. I am not sure how you would
identify whether the elf64-littleaarch64 is not part of the OBJCOPY?

Oh I guess you can: objcopy --info

Or are you saying just use 'arm64' instead of 'aarch64' ?


I was suggesting to do

ifeq ($(XEN_TARGET_ARCH),x86_64))
OBJCOPY_MAGIC := ...
endif
ifeq ($(XEN_TARGET_ARCH),arm64))
OBJCOPY_MAGIC := ...
endif




+endif
+
 CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
 CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')

@@ -54,7 +60,7 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o note.o
 .PHONY: note.o
 note.o:
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
$(BASEDIR)/xen-syms $@.bin
-   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   --rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin

@@ -65,7 +71,7 @@ note.o:
 .PHONY: hello_world_note.o
 hello_world_note.o: $(LIVEPATCH)
$(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
$@.bin
-   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
+   $(OBJCOPY) $(OBJCOPY_MAGIC) \
   --rename-section=.data=.livepatch.depends -S $@.bin $@
rm -f $@.bin

diff --git a/xen/common/test/xen_hello_world_func.c 
b/xen/common/test/xen_hello_world_func.c
index 03d6b84..0e1a722 100644
--- a/xen/common/test/xen_hello_world_func.c
+++ b/xen/common/test/xen_hello_world_func.c
@@ -6,14 +6,17 @@
 #include 

 #include 
+#ifdef CONFIG_X86
 #include 
 #include 

 static unsigned long *non_canonical_addr = (unsigned long 
*)0xdeadULL;
+#endif

 /* Our replacement function for xen_extra_version. */
 const char *xen_hello_world(void)
 {
+#ifdef CONFIG_X86
 unsigned long tmp;
 int rc;

@@ -24,7 +27,9 @@ const char *xen_hello_world(void)
  */
 rc = __get_user(tmp, non_canonical_addr);
 BUG_ON(rc != -EFAULT);
-
+#else
+ asm(ALTERNATIVE("nop", "nop", 1));


Why the hardcoded 1 here? I am wondering if we should introduce a new
capability "LIVEPATCH_TEST" which is enabled by default. So we can test that
the the alternative is working on all the platform. What do you think?


Sure, but I am not sure what number you would like? Perhaps 42 :-) ?


Unfortunately the number is an index in the bitmap, so we have to 
allocate them contiguously.


Also, this made me realize that the current implementation of 
apply_alternatives cannot work if we are patching outside the xen binary. :/


I need to have a think to see how we can handle any region.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 17/08/2016 19:57, Konrad Rzeszutek Wilk wrote:

+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+/* Save old one. */
+old_ptr = func->old_addr;
+memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
+
+if ( func->new_size )
+insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
+   (unsigned long)func->new_addr,
+   AARCH64_INSN_BRANCH_NOLINK);


The function aarch64_insn_gen_branch_imm will fail to create the branch if
the difference between old_addr and new_addr is greater than 128MB.

In this case, the function will return AARCH64_BREAK_FAULT which will crash
Xen when the instruction is executed.

I cannot find any sanity check in the hypervisor code. So are we trusting
the payload?


Ugh. This is a thorny one. I concur we need to check this - and better of
do it when we load the payload to make sure the distance is correct.

And that should also be on x86, so will spin of a seperate patch.

And in here add an ASSERT that the insn != AARCH64_BREAK_FAULT


It sounds good to me.

[...]


+
+modify_xen_mappings(start, start + pages * PAGE_SIZE, flags);
+
+return 0;
 }

 void __init arch_livepatch_init(void)
 {
+void *start, *end;
+
+start = (void *)LIVEPATCH_VMAP;
+end = start + MB(2);


Could you define the in config.h? So in the future we can rework more easily
the memory layout.


LIVEPATCH_VMAP_START and LIVEPATCH_VMAP_END ?


Something like that.






+
+vm_init_type(VMAP_XEN, start, end);
 }

 /*
diff --git a/xen/arch/arm/livepatch.h b/xen/arch/arm/livepatch.h
new file mode 100644
index 000..8c8d625
--- /dev/null
+++ b/xen/arch/arm/livepatch.h


I am not sure why this header is living in arch/arm/ and not
include/asm-arm/


@@ -0,0 +1,28 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#ifndef __XEN_ARM_LIVEPATCH_H__
+#define __XEN_ARM_LIVEPATCH_H__
+
+/* On ARM32,64 instructions are always 4 bytes long. */
+#define PATCH_INSN_SIZE 4
+
+/*
+ * The va of the hypervisor .text region. We need this as the
+ * normal va are write protected.
+ */
+extern void *vmap_of_xen_text;
+
+#endif /* __XEN_ARM_LIVEPATCH_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 06c67bc..e3f3f37 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -15,10 +15,12 @@

 #define PATCH_INSN_SIZE 5

-void arch_livepatch_quiesce(void)
+int arch_livepatch_quiesce(void)
 {
 /* Disable WP to allow changes to read-only pages. */
 write_cr0(read_cr0() & ~X86_CR0_WP);
+
+return 0;
 }

 void arch_livepatch_revive(void)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 51afa24..2fc76b6 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -222,7 +222,7 @@ endmenu
 config LIVEPATCH
bool "Live patching support (TECH PREVIEW)"
default n
-   depends on X86 && HAS_BUILD_ID = "y"
+   depends on (X86 || ARM_64) && HAS_BUILD_ID = "y"
---help---
  Allows a running Xen hypervisor to be dynamically patched using
  binary patches without rebooting. This is primarily used to binarily
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 9c45270..af9443d 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -682,7 +682,7 @@ static int prepare_payload(struct payload *payload,
   sizeof(*region->frame[i].bugs);
 }

-#ifndef CONFIG_ARM
+#ifndef CONFIG_ARM_32


I would prefer if you use CONFIG_ALTERNATIVE rather than CONFIG_ARM_32.


That is not exposed on x86 thought.

I can expose HAVE_ALTERNATIVE on x86 and use that instead.


True. I would like to avoid using  CONFIG_ARM_* in the common code as it 
is a call to forget to remove the #ifdef when ARM32 will gain 
alternative patching.


You are the maintainer of this code, so it is your call :).

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Julien Grall]

On 17/08/2016 02:50, Konrad Rzeszutek Wilk wrote:

+int arch_livepatch_perform_rela(struct livepatch_elf *elf,
+const struct livepatch_elf_sec *base,
+const struct livepatch_elf_sec *rela)
+{

.. snip..

+switch ( ELF64_R_TYPE(r->r_info) ) {
+/* Data */
+case R_AARCH64_ABS64:
+if ( r->r_offset + sizeof(uint64_t) > base->sec->sh_size )
+goto bad_offset;


As you borrow the code from Linux, could we keep the abstraction with
reloc_data and defer the overflow check? It would avoid to have the same if
in multiple place in this code.


The above 'if' conditional is a check to make sure that we don't
go past the section (sh_size). In other words it is a boundary check to
make sure the Elf file is not messed up.


Oh, Linux does not do those check. Sorry I though it was done. So I am 
fine with that.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 9/9] livepatch: tests: Make them compile under ARM64

[Konrad Rzeszutek Wilk]

On Wed, Aug 17, 2016 at 07:29:12PM +0100, Julien Grall wrote:
> Hi Konrad,
> 
> On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:
> > We need to two things:
> > 1) Wrap the platform-specific objcopy paramters in defines
> 
> s/paramters/parameters/
> 
> >The input and output parmeters for $(OBJCOPY) are different
> 
> Ditto.
> 
> >based on the platforms. As such provide them in the
> >OBJCOPY_MAGIC define and use that.
> > 
> > 2) The alternative is a bit different and there are no
> >exceptions under ARM.
> > 
> > We are not yet attempting to build them under ARM32 so
> > that is still ifdefed out.
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > 
> > ---
> > Cc: Andrew Cooper 
> > Cc: George Dunlap 
> > Cc: Ian Jackson 
> > Cc: Jan Beulich 
> > Cc: Konrad Rzeszutek Wilk 
> > Cc: Stefano Stabellini 
> > Cc: Tim Deegan 
> > Cc: Wei Liu 
> > 
> > v1: First submission
> > ---
> >  xen/common/Makefile|  2 +-
> >  xen/common/test/Makefile   | 10 --
> >  xen/common/test/xen_hello_world_func.c |  7 ++-
> >  3 files changed, 15 insertions(+), 4 deletions(-)
> > 
> > diff --git a/xen/common/Makefile b/xen/common/Makefile
> > index 22806b6..fe83653 100644
> > --- a/xen/common/Makefile
> > +++ b/xen/common/Makefile
> > @@ -82,6 +82,6 @@ subdir-$(CONFIG_HAS_DEVICE_TREE) += libfdt
> > 
> >  .PHONY: tests
> >  tests:
> > -ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +ifneq ($(XEN_TARGET_ARCH),arm32)
> > $(MAKE) -f $(BASEDIR)/Rules.mk -C test livepatch
> >  endif
> > diff --git a/xen/common/test/Makefile b/xen/common/test/Makefile
> > index 23dff1d..3eed6dd 100644
> > --- a/xen/common/test/Makefile
> > +++ b/xen/common/test/Makefile
> > @@ -1,5 +1,11 @@
> >  include $(XEN_ROOT)/Config.mk
> > 
> > +ifeq ($(XEN_TARGET_ARCH),x86_64)
> > +OBJCOPY_MAGIC := -I binary -O elf64-x86-64 -B i386:x86-64
> > +else
> 
> Is there any reason to fallback on arm64 flags by default? Would not it be
> better to have an else if here?
> 
> > +OBJCOPY_MAGIC := -I binary -O elf64-littleaarch64 -B aarch64

I presume you are referring to this comment. I am not sure how you would
identify whether the elf64-littleaarch64 is not part of the OBJCOPY?

Oh I guess you can: objcopy --info

Or are you saying just use 'arm64' instead of 'aarch64' ?

> > +endif
> > +
> >  CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
> >  CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
> > 
> > @@ -54,7 +60,7 @@ $(LIVEPATCH): xen_hello_world_func.o xen_hello_world.o 
> > note.o
> >  .PHONY: note.o
> >  note.o:
> > $(OBJCOPY) -O binary --only-section=.note.gnu.build-id 
> > $(BASEDIR)/xen-syms $@.bin
> > -   $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +   $(OBJCOPY) $(OBJCOPY_MAGIC) \
> >--rename-section=.data=.livepatch.depends -S $@.bin $@
> > rm -f $@.bin
> > 
> > @@ -65,7 +71,7 @@ note.o:
> >  .PHONY: hello_world_note.o
> >  hello_world_note.o: $(LIVEPATCH)
> > $(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(LIVEPATCH) 
> > $@.bin
> > -   $(OBJCOPY)  -I binary -O elf64-x86-64 -B i386:x86-64 \
> > +   $(OBJCOPY) $(OBJCOPY_MAGIC) \
> >--rename-section=.data=.livepatch.depends -S $@.bin $@
> > rm -f $@.bin
> > 
> > diff --git a/xen/common/test/xen_hello_world_func.c 
> > b/xen/common/test/xen_hello_world_func.c
> > index 03d6b84..0e1a722 100644
> > --- a/xen/common/test/xen_hello_world_func.c
> > +++ b/xen/common/test/xen_hello_world_func.c
> > @@ -6,14 +6,17 @@
> >  #include 
> > 
> >  #include 
> > +#ifdef CONFIG_X86
> >  #include 
> >  #include 
> > 
> >  static unsigned long *non_canonical_addr = (unsigned long 
> > *)0xdeadULL;
> > +#endif
> > 
> >  /* Our replacement function for xen_extra_version. */
> >  const char *xen_hello_world(void)
> >  {
> > +#ifdef CONFIG_X86
> >  unsigned long tmp;
> >  int rc;
> > 
> > @@ -24,7 +27,9 @@ const char *xen_hello_world(void)
> >   */
> >  rc = __get_user(tmp, non_canonical_addr);
> >  BUG_ON(rc != -EFAULT);
> > -
> > +#else
> > + asm(ALTERNATIVE("nop", "nop", 1));
> 
> Why the hardcoded 1 here? I am wondering if we should introduce a new
> capability "LIVEPATCH_TEST" which is enabled by default. So we can test that
> the the alternative is working on all the platform. What do you think?

Sure, but I am not sure what number you would like? Perhaps 42 :-) ?

> 
> > +#endif
> >  return "Hello World";
> >  }
> -- 
> Julien Grall

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

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Konrad Rzeszutek Wilk]

> > +void arch_livepatch_apply_jmp(struct livepatch_func *func)
> > +{
> > +uint32_t insn;
> > +uint32_t *old_ptr;
> > +uint32_t *new_ptr;
> > +
> > +BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
> > +BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn));
> > +
> > +ASSERT(vmap_of_xen_text);
> > +
> > +/* Save old one. */
> > +old_ptr = func->old_addr;
> > +memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
> > +
> > +if ( func->new_size )
> > +insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
> > +   (unsigned long)func->new_addr,
> > +   AARCH64_INSN_BRANCH_NOLINK);
> 
> The function aarch64_insn_gen_branch_imm will fail to create the branch if
> the difference between old_addr and new_addr is greater than 128MB.
> 
> In this case, the function will return AARCH64_BREAK_FAULT which will crash
> Xen when the instruction is executed.
> 
> I cannot find any sanity check in the hypervisor code. So are we trusting
> the payload?

Ugh. This is a thorny one. I concur we need to check this - and better of
do it when we load the payload to make sure the distance is correct.

And that should also be on x86, so will spin of a seperate patch.

And in here add an ASSERT that the insn != AARCH64_BREAK_FAULT


.. snip..
> > -/* On ARM32,64 instructions are always 4 bytes long. */
> > -#define PATCH_INSN_SIZE 4
> 
> Rather than moving again PATCH_INSN_SIZE in this patch. Can you directly
> move it in patch [1]?

Sure.
> 
> > +void *vmap_of_xen_text;
> > 
> >  int arch_verify_insn_length(unsigned long len)
> >  {
> >  return len != PATCH_INSN_SIZE;
> >  }
> > 
> > -void arch_livepatch_quiesce(void)
> > +int arch_livepatch_quiesce(void)
> 
> It would have been nice to move the prototype change out of this patch to
> keep it "straight forward".

OK.
> 
> >  {
> > +mfn_t text_mfn;
> > +unsigned int text_order;
> > +
> > +if ( vmap_of_xen_text )
> > +return -EINVAL;
> > +
> > +text_mfn = _mfn(virt_to_mfn(_stext));
> > +text_order = get_order_from_bytes(_end - _start);
> 
> It is a bit odd that you use _stext before and the _start. But I won't
> complain as I did the same in alternatives.c :/.

Heheh.
> 
> However, I think it should be enough to remap _stext -> _etext. I had to map
> all the Xen binary for the alternatives because we may patch the init text.

I agree.
> 
> I forgot to mention it in the code, so I will send a patch to update it.

OK.
> 
> > +
> > +/*
> > + * The text section is read-only. So re-map Xen to be able to patch
> > + * the code.
> > + */
> > +vmap_of_xen_text = __vmap(_mfn, 1 << text_order, 1, 1, 
> > PAGE_HYPERVISOR,
> > +  VMAP_DEFAULT);
> > +
> > +if ( !vmap_of_xen_text )
> > +{
> > +printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of hypervisor! 
> > (order=%u)\n",
> > +   text_order);
> > +return -ENOMEM;
> > +}
> > +return 0;
> >  }
> > 
> >  void arch_livepatch_revive(void)
> >  {
> > +/*
> > + * Nuke the instruction cache. It has been cleaned before in
> 
> I guess you want to replace "It" by "Data cache" otherwise it does not make
> much sense.
> 
> > + * arch_livepatch_apply_jmp.
> 
> What about the payload? It may contain instructions, so we need to ensure
> that all the data reached the memory.
> 
> > + */
> > +invalidate_icache();
> > +
> > +if ( vmap_of_xen_text )
> > +vunmap(vmap_of_xen_text);
> > +
> > +vmap_of_xen_text = NULL;
> > +
> > +/*
> > + * Need to flush the branch predicator for ARMv7 as it may be
> 
> s/predicator/predictor/
> 
> > + * architecturally visible to the software (see B2.2.4 in ARM DDI 
> > 0406C.b).
> > + */
> > +flush_xen_text_tlb_local();
> 
> I am a bit confused. In your comment you mention the branch but flush the
> TLBs. The two are not related.
> 
> However, I would prefer the branch predictor to be flushed directly in
> invalidate_icache by calling BPIALLIS. This is because flushing the cache
> means that you likely want to flush the branch predictor too.

OK.
> 
> >  }
> > 
> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
> >  {
> > -return -ENOSYS;
> > -}
> > -
> > -void arch_livepatch_apply_jmp(struct livepatch_func *func)
> > -{
> > -}
> > +if ( func->old_size < PATCH_INSN_SIZE )
> > +return -EINVAL;
> > 
> > -void arch_livepatch_revert_jmp(const struct livepatch_func *func)
> > -{
> > +return 0;
> >  }
> > 
> >  void arch_livepatch_post_action(void)
> >  {
> > +/* arch_livepatch_revive has nuked the instruction cache. */
> >  }
> > 
> >  void arch_livepatch_mask(void)
> >  {
> > +/* Mask System Error (SError) */
> > +local_abort_disable();
> >  }
> > 
> >  void arch_livepatch_unmask(void)
> >  {
> > -}
> > -
> > -int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
> > 

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:

[...]


diff --git a/xen/arch/arm/arm64/livepatch.c b/xen/arch/arm/arm64/livepatch.c
new file mode 100644
index 000..e348942
--- /dev/null
+++ b/xen/arch/arm/arm64/livepatch.c
@@ -0,0 +1,247 @@
+/*
+ *  Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include "../livepatch.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+void arch_livepatch_apply_jmp(struct livepatch_func *func)
+{
+uint32_t insn;
+uint32_t *old_ptr;
+uint32_t *new_ptr;
+
+BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
+BUILD_BUG_ON(PATCH_INSN_SIZE != sizeof(insn));
+
+ASSERT(vmap_of_xen_text);
+
+/* Save old one. */
+old_ptr = func->old_addr;
+memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
+
+if ( func->new_size )
+insn = aarch64_insn_gen_branch_imm((unsigned long)func->old_addr,
+   (unsigned long)func->new_addr,
+   AARCH64_INSN_BRANCH_NOLINK);


The function aarch64_insn_gen_branch_imm will fail to create the branch 
if the difference between old_addr and new_addr is greater than 128MB.


In this case, the function will return AARCH64_BREAK_FAULT which will 
crash Xen when the instruction is executed.


I cannot find any sanity check in the hypervisor code. So are we 
trusting the payload?



+else
+insn = aarch64_insn_gen_nop();
+
+new_ptr = func->old_addr - (void *)_start + vmap_of_xen_text;
+
+/* PATCH! */
+*(new_ptr) = cpu_to_le32(insn);
+
+clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr));
+}
+
+void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+{
+uint32_t *new_ptr;
+uint32_t insn;
+
+memcpy(, func->opaque, PATCH_INSN_SIZE);
+
+new_ptr = (uint32_t *)func->old_addr - (u32 *)_start + vmap_of_xen_text;
+
+/* PATCH! */
+*(new_ptr) = cpu_to_le32(insn);
+
+clean_and_invalidate_dcache_va_range(new_ptr, sizeof(*new_ptr));
+}
+
+int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
+{
+const Elf_Ehdr *hdr = elf->hdr;
+
+if ( hdr->e_machine != EM_AARCH64 ||
+ hdr->e_ident[EI_CLASS] != ELFCLASS64 )
+{
+dprintk(XENLOG_ERR, LIVEPATCH "%s: Unsupported ELF Machine type!\n",
+elf->name);
+return -EOPNOTSUPP;
+}
+
+return 0;
+}
+


[...]


diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 20bb2ba..607ee59 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -55,6 +56,11 @@ void idle_loop(void)

 do_tasklet();
 do_softirq();
+/*
+ * We MUST be last (or before dsb, wfi). Otherwise after we get the
+ * softirq we would execute dsb,wfi (and sleep) and not patch.
+ */
+check_for_livepatch_work();
 }
 }

diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 3093554..19f6033 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -1,56 +1,93 @@
 /*
  *  Copyright (C) 2016 Citrix Systems R Ltd.
  */
+


Spurious change?


+#include "livepatch.h"
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+
+#include 

-/* On ARM32,64 instructions are always 4 bytes long. */
-#define PATCH_INSN_SIZE 4


Rather than moving again PATCH_INSN_SIZE in this patch. Can you directly 
move it in patch [1]?



+void *vmap_of_xen_text;

 int arch_verify_insn_length(unsigned long len)
 {
 return len != PATCH_INSN_SIZE;
 }

-void arch_livepatch_quiesce(void)
+int arch_livepatch_quiesce(void)


It would have been nice to move the prototype change out of this patch 
to keep it "straight forward".



 {
+mfn_t text_mfn;
+unsigned int text_order;
+
+if ( vmap_of_xen_text )
+return -EINVAL;
+
+text_mfn = _mfn(virt_to_mfn(_stext));
+text_order = get_order_from_bytes(_end - _start);


It is a bit odd that you use _stext before and the _start. But I won't 
complain as I did the same in alternatives.c :/.


However, I think it should be enough to remap _stext -> _etext. I had to 
map all the Xen binary for the alternatives because we may patch the 
init text.


I forgot to mention it in the code, so I will send a patch to update it.


+
+/*
+ * The text section is read-only. So re-map Xen to be able to patch
+ * the code.
+ */
+vmap_of_xen_text = __vmap(_mfn, 1 << text_order, 1, 1, 
PAGE_HYPERVISOR,
+  VMAP_DEFAULT);
+
+if ( !vmap_of_xen_text )
+{
+printk(XENLOG_ERR LIVEPATCH "Failed to setup vmap of hypervisor! 
(order=%u)\n",
+   text_order);
+return -ENOMEM;
+}
+return 0;
 }

 void arch_livepatch_revive(void)
 {
+/*
+ * Nuke the instruction cache. It has been cleaned before in

[Xen-devel] [PATCH] x86: Add a tboot Kconfig option

[Derek Straka]

Allows for the conditional inclusion of tboot related functionality via Kconfig

The default configuration for the new CONFIG_TBOOT option is 'y', so the
behavior out of the box remains unchanged.  The addition of the option allows
advanced users to disable system behaviors associated with tboot at compile
time rather than relying on the run-time detection and configuration.

Signed-off-by: Derek Straka 
---
 xen/Rules.mk|  2 +-
 xen/arch/x86/Makefile   |  2 +-
 xen/common/Kconfig  | 11 +++
 xen/include/asm-x86/tboot.h | 12 
 4 files changed, 25 insertions(+), 2 deletions(-)

diff --git a/xen/Rules.mk b/xen/Rules.mk
index ebe1dc0..12d3184 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@ -44,7 +44,7 @@ ALL_OBJS-y   += $(BASEDIR)/common/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/drivers/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/xsm/built_in.o
 ALL_OBJS-y   += $(BASEDIR)/arch/$(TARGET_ARCH)/built_in.o
-ALL_OBJS-$(CONFIG_X86)   += $(BASEDIR)/crypto/built_in.o
+ALL_OBJS-$(CONFIG_TBOOT)   += $(BASEDIR)/crypto/built_in.o
 
 CFLAGS += -nostdinc -fno-builtin -fno-common
 CFLAGS += -Werror -Wredundant-decls -Wno-pointer-arith
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index b18f033..5b9e9da 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -62,7 +62,7 @@ obj-y += trace.o
 obj-y += traps.o
 obj-y += usercopy.o
 obj-y += x86_emulate.o
-obj-y += tboot.o
+obj-$(CONFIG_TBOOT) += tboot.o
 obj-y += hpet.o
 obj-y += vm_event.o
 obj-y += xstate.o
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 51afa24..cb9a92a 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -218,6 +218,17 @@ config SCHED_DEFAULT
 
 endmenu
 
+# Enable/Disable tboot support
+config TBOOT
+   bool "Xen tboot support"
+   default y
+   depends on X86
+   ---help---
+ Allows support for Trusted Boot using the Intel(R) Trusted Execution
+ Technology (TXT)
+
+ If unsure, say Y.
+
 # Enable/Disable live patching support
 config LIVEPATCH
bool "Live patching support (TECH PREVIEW)"
diff --git a/xen/include/asm-x86/tboot.h b/xen/include/asm-x86/tboot.h
index d242862..977e509 100644
--- a/xen/include/asm-x86/tboot.h
+++ b/xen/include/asm-x86/tboot.h
@@ -119,6 +119,7 @@ typedef struct __packed {
 
 extern tboot_shared_t *g_tboot_shared;
 
+#ifdef CONFIG_TBOOT
 void tboot_probe(void);
 void tboot_shutdown(uint32_t shutdown_type);
 int tboot_in_measured_env(void);
@@ -127,6 +128,17 @@ int tboot_parse_dmar_table(acpi_table_handler 
dmar_handler);
 int tboot_s3_resume(void);
 void tboot_s3_error(int error);
 int tboot_wake_ap(int apicid, unsigned long sipi_vec);
+#else
+static inline void tboot_probe(void) {}
+static inline void tboot_shutdown(uint32_t shutdown_type) {}
+static inline int tboot_in_measured_env(void) {return 0;}
+static inline int tboot_protect_mem_regions(void) {return 1;}
+static inline int tboot_parse_dmar_table(acpi_table_handler dmar_handler) 
{return acpi_table_parse(ACPI_SIG_DMAR, dmar_handler);}
+static inline int tboot_s3_resume(void) { return 0; }
+
+static inline void tboot_s3_error(int error) {}
+static inline int tboot_wake_ap(int apicid, unsigned long sipi_vec) {return 1;}
+#endif /* CONFIG_TBOOT */
 
 #endif /* __TBOOT_H__ */
 
-- 
1.9.1


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 7503cd70fb864a5663edb121c9b2488b4c69e7f5
baseline version:
 ovmf 584fcb7de28b710dfcd4fbe8fe1d574c593f3009

Last test of basis   100531  2016-08-17 11:43:50 Z0 days
Testing same since   100534  2016-08-17 13:44:54 Z0 days1 attempts


People who touched revisions under test:
  Jeff Fan 
  Laszlo Ersek 
  Michael Kinney 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=7503cd70fb864a5663edb121c9b2488b4c69e7f5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
7503cd70fb864a5663edb121c9b2488b4c69e7f5
+ branch=ovmf
+ revision=7503cd70fb864a5663edb121c9b2488b4c69e7f5
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x7503cd70fb864a5663edb121c9b2488b4c69e7f5 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [PATCH 24/24] xen: credit2: try to avoid tickling cpus subject to ratelimiting

[Dario Faggioli]

With context switching ratelimiting enabled, the following
pattern is quite common in a scheduling trace:

 0.000845622 |||.x||| d32768v12 csched2:runq_insert d0v13, position 0
 0.000845831 |||.x||| d32768v12 csched2:runq_tickle_new d0v13, 
processor = 12, credit = 10135529
 0.000846546 |||.x||| d32768v12 csched2:burn_credits d2v7, credit = 
2619231, delta = 255937
 [1] 0.000846739 |||.x||| d32768v12 csched2:runq_tickle cpu 12
 [...]
 [2] 0.000850597 x||| d32768v12 csched2:schedule cpu 12, rq# 1, 
busy, SMT busy, tickled
 0.000850760 x||| d32768v12 csched2:burn_credits d2v7, credit = 
2614028, delta = 5203
 [3] 0.000851022 x||| d32768v12 csched2:ratelimit triggered
 [4] 0.000851614 x||| d32768v12 runstate_continue d2v7 
running->running

Basically, what happens is that runq_tickle() realizes
d0v13 should preempt d2v7, running on cpu 12, as it
has higher credits (10135529 vs. 2619231). It therefore
tickles cpu 12 [1], which, in turn, schedules [2].

But --surprise surprise-- d2v7 has run for less than the
ratelimit interval [3], and hence it is _not_ preempted,
and continues to run. This indeed looks fine. Actually,
this is what ratelimiting is there for. Note, however,
that:
 1) we interrupted cpu 12 for nothing;
 2) what if, say on cpu 8, there is a vcpu that has:
+ less credit than d0v13 (so d0v13 can well
  preempt it),
+ more credit than d2v7 (that's why it was not
  selected to be preempted),
+ run for more than the ratelimiting interval
  (so it can really be scheduled out)?

This patch tries to figure out whether the situation
is the one described at 2) and, if it is, tickles 8 (in
the example above) instead of 12.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |   31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index f03ecce..3bb764d 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -146,6 +146,8 @@
 #define CSCHED2_MIGRATE_RESIST   ((opt_migrate_resist)*MICROSECS(1))
 /* How much to "compensate" a vcpu for L2 migration */
 #define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
+/* How tolerant we should be when peeking at runtime of vcpus on other cpus */
+#define CSCHED2_RATELIMIT_TICKLE_TOLERANCE MICROSECS(50)
 /* How big of a bias we should have against a yielding vcpu */
 #define CSCHED2_YIELD_BIAS   ((opt_yield_bias)*MICROSECS(1))
 #define CSCHED2_YIELD_BIAS_MIN   CSCHED2_MIN_TIMER
@@ -972,6 +974,27 @@ static inline bool_t soft_aff_check_preempt(unsigned int 
bs, unsigned int cpu)
 return !cpumask_test_cpu(cpu, cpumask_scratch);
 }
 
+/*
+ * What we want to know is whether svc, which we assume to be running on some
+ * pcpu, can be interrupted and preempted. So fat, the only reason because of
+ * which a preemption would be deferred is context switch ratelimiting, so
+ * check for that.
+ *
+ * Use a caller provided value of ratelimit, instead of the scheduler's own
+ * prv->ratelimit_us so the caller can play some tricks, if he wants (which,
+ * as a matter of fact, he does, by applying the tolerance).
+ */
+static inline bool_t is_preemptable(const struct csched2_vcpu *svc,
+s_time_t now, s_time_t ratelimit)
+{
+s_time_t runtime;
+
+ASSERT(svc->vcpu->is_running);
+runtime = now - svc->vcpu->runstate.state_entry_time;
+
+return runtime > ratelimit;
+}
+
 void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, 
s_time_t);
 
 /*
@@ -997,6 +1020,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 s_time_t lowest = (1<<30);
 unsigned int bs, cpu = new->vcpu->processor;
 struct csched2_runqueue_data *rqd = RQD(ops, cpu);
+s_time_t ratelimit = MICROSECS(CSCHED2_PRIV(ops)->ratelimit_us) -
+ CSCHED2_RATELIMIT_TICKLE_TOLERANCE;
 cpumask_t mask, skip_mask;
 struct csched2_vcpu * cur;
 
@@ -1104,7 +1129,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 (unsigned char *));
 }
 
-if ( cur->credit < new->credit )
+if ( cur->credit < new->credit &&
+ is_preemptable(cur, now, ratelimit) )
 {
 SCHED_STAT_CRANK(tickled_busy_cpu);
 ipid = cpu;
@@ -1155,7 +1181,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 (unsigned char *));
 }
 
-if ( cur->credit < lowest )
+if ( cur->credit < lowest &&
+ is_preemptable(cur, now, 

[Xen-devel] [PATCH 23/24] xen: credit2: optimize runq_tickle() a little bit

[Dario Faggioli]

By not looking at the same cpu (to check whether
we want to preempt who's running there) twice, if
the vcpu being woken up has both soft and hard
affinity.

In fact, all the cpus that are part of both soft
affinity and hard-affinity (of the waking vcpu)
are checked during the soft-affinity balancing
step. If none turns out to be suitable, e.g.,
because they're running vcpus with higher credits,
there's no point in re-checking them, only to
re-assess the same, during the hard-affinity
step.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |   43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 6963872..f03ecce 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -997,7 +997,7 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 s_time_t lowest = (1<<30);
 unsigned int bs, cpu = new->vcpu->processor;
 struct csched2_runqueue_data *rqd = RQD(ops, cpu);
-cpumask_t mask;
+cpumask_t mask, skip_mask;
 struct csched2_vcpu * cur;
 
 ASSERT(new->rqd == rqd);
@@ -1017,6 +1017,13 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 (unsigned char *));
 }
 
+/*
+ * Cpus that end up in this mask, have been already checked during the
+ * soft-affinity step, and need not to be checked again when doing hard
+ * affinity.
+ */
+cpumask_clear(_mask);
+
 for_each_affinity_balance_step( bs )
 {
 /*
@@ -1073,7 +1080,8 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 cpumask_andnot(, >active, >idle);
 cpumask_andnot(, , >tickled);
 cpumask_and(, , cpumask_scratch);
-if ( cpumask_test_cpu(cpu, ) )
+if ( cpumask_test_cpu(cpu, ) &&
+ !cpumask_test_cpu(cpu, _mask) )
 {
 cur = CSCHED2_VCPU(curr_on_cpu(cpu));
 
@@ -1102,13 +1110,26 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 ipid = cpu;
 goto tickle;
 }
+
+/*
+ * If we're here, cpu is just not a valid candidate for being
+ * tickled. Set its bit in skip_mask, to avoid calling
+ * burn_credits() and check its current vcpu for preemption
+ * twice.
+ */
+__cpumask_set_cpu(cpu, _mask);
 }
 }
 
 for_each_cpu(i, )
 {
-/* Already looked at this one above */
-if ( i == cpu )
+/*
+ * Already looked at these ones above, either because it's the
+ * cpu where new was running before, or because we are at the
+ * hard-affinity step, and we checked this during the
+ * soft-affinity one
+ */
+if ( i == cpu || cpumask_test_cpu(i, _mask) )
 continue;
 
 cur = CSCHED2_VCPU(curr_on_cpu(i));
@@ -1139,6 +1160,20 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 ipid = i;
 lowest = cur->credit;
 }
+
+/*
+ * No matter if i is the new lowest or not. We've run
+ * burn_credits() on it, and we've checked it for preemption.
+ *
+ * If we are at soft-affinity balancing step, and i is indeed
+ * the lowest, it will be tickled (and we exit the function).
+ * If it is not the lowest among the cpus in the soft-affinity
+ * mask, it can't be the lowest among the cpus in the hard
+ * affinity mask (assuming we'll actually do the second
+ * balancing step), as hard-affinity is a superset of soft
+ * affinity, and therefore we can flag it to be skipped.
+ */
+__cpumask_set_cpu(i, _mask);
 }
 }
 


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

[Xen-devel] [PATCH 22/24] xen: credit2: "relax" CSCHED2_MAX_TIMER

[Dario Faggioli]

Credit2 is already event based, rather than tick
based. This means, the time at which the (i+1)-eth
scheduling decision needs to happen is computed
during the i-eth scheduling decision, and a timer
is set accordingly.

If there's nothing imminent (or, the most imminent
event is really really really far away), it is
ok to say "well, let's double-check things in
a little bit anyway", but such 'little bit' does
not need to be too little, as, most likely, it's
just pure overhead.

The current period, for this "safety catch"-alike
timer is 2ms, which indeed is high, but it can
well be higher. In fact, benchmarks show that
setting it to 10ms --combined with other
optimizations-- does actually improve performance.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 21b1f91..6963872 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -152,7 +152,7 @@
 /* Reset: Value below which credit will be reset. */
 #define CSCHED2_CREDIT_RESET 0
 /* Max timer: Maximum time a guest can be run for. */
-#define CSCHED2_MAX_TIMERMILLISECS(2)
+#define CSCHED2_MAX_TIMERCSCHED2_CREDIT_INIT
 
 
 #define CSCHED2_IDLE_CREDIT (-(1<<30))


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

[Xen-devel] [PATCH 21/24] xen: credit2: optimize runq_candidate() a little bit

[Dario Faggioli]

By factoring into one (at the top) all the checks
to see whether current is the idle vcpu, and mark
it as unlikely().

In fact, if current is idle, all the logic for
dealing with yielding, context switching rate
limiting and soft-affinity, is just pure overhead,
and we better rush checking the runq and pick some
vcpu up.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |   18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ab0122b..21b1f91 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2730,10 +2730,18 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  * if scurr is yielding, when comparing its credits with other vcpus in
  * the runqueue, act like those other vcpus had yield_bias more credits.
  */
-int yield_bias = __test_and_clear_bit(__CSFLAG_vcpu_yield, >flags) ?
- CSCHED2_YIELD_BIAS : 0;
+int yield_bias = 0;
 bool_t cpu_in_soft_aff = 1;
 
+if ( unlikely(is_idle_vcpu(scurr->vcpu)) )
+{
+snext = scurr;
+goto check_runq;
+}
+
+if ( __test_and_clear_bit(__CSFLAG_vcpu_yield, >flags) )
+yield_bias = CSCHED2_YIELD_BIAS;
+
 /*
  * Return the current vcpu if it has executed for less than ratelimit.
  * Adjuststment for the selected vcpu's credit and decision
@@ -2748,7 +2756,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  * has been cleared already above.
  */
 if ( !yield_bias &&
- prv->ratelimit_us && !is_idle_vcpu(scurr->vcpu) &&
+ prv->ratelimit_us &&
  vcpu_runnable(scurr->vcpu) &&
  (now - scurr->vcpu->runstate.state_entry_time) <
   MICROSECS(prv->ratelimit_us) )
@@ -2769,8 +2777,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 return scurr;
 }
 
-if ( !is_idle_vcpu(scurr->vcpu) &&
- has_soft_affinity(scurr->vcpu, scurr->vcpu->cpu_hard_affinity) )
+if ( has_soft_affinity(scurr->vcpu, scurr->vcpu->cpu_hard_affinity) )
 {
 affinity_balance_cpumask(scurr->vcpu, BALANCE_SOFT_AFFINITY,
  cpumask_scratch);
@@ -2804,6 +2811,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 else
 snext = CSCHED2_VCPU(idle_vcpu[cpu]);
 
+ check_runq:
 list_for_each( iter, >runq )
 {
 struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, 
runq_elem);


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

[Xen-devel] [PATCH 20/24] xen: credit2: kick away vcpus not running within their soft-affinity

[Dario Faggioli]

If, during scheduling, we realize that the current vcpu
is running outside of its own soft-affinity, it would be
preferable to send it somewhere else.

Of course, that may not be possible, and if we're too
strict, we risk having vcpus sit in runqueues, even if
there are idle pcpus (violating work-conservingness).
In fact, what about there are no pcpus, from the soft
affinity mask of the vcpu in question, where it can
run?

To make sure we don't fall in the above described trap,
only actually de-schedule the vcpu if there are idle and
not already tickled cpus from its soft affinity where it
can run immediately.

If there is (at least one) of such cpus, we let current
be preempted, so that csched2_context_saved() will put
it back in the runq, and runq_tickle() will wake (one
of) the cpu.

If there is not even one, we let current run where it is,
as running outside its soft-affinity is still better than
not running at all.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |   34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3722f46..ab0122b 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2732,6 +2732,7 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  */
 int yield_bias = __test_and_clear_bit(__CSFLAG_vcpu_yield, >flags) ?
  CSCHED2_YIELD_BIAS : 0;
+bool_t cpu_in_soft_aff = 1;
 
 /*
  * Return the current vcpu if it has executed for less than ratelimit.
@@ -2768,8 +2769,37 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 return scurr;
 }
 
-/* Default to current if runnable, idle otherwise */
-if ( vcpu_runnable(scurr->vcpu) )
+if ( !is_idle_vcpu(scurr->vcpu) &&
+ has_soft_affinity(scurr->vcpu, scurr->vcpu->cpu_hard_affinity) )
+{
+affinity_balance_cpumask(scurr->vcpu, BALANCE_SOFT_AFFINITY,
+ cpumask_scratch);
+cpu_in_soft_aff = cpumask_test_cpu(cpu, cpumask_scratch);
+/* Idle and not-tickled cpus from scurr's soft-affinity. */
+cpumask_and(cpumask_scratch, cpumask_scratch, >idle);
+cpumask_andnot(cpumask_scratch, cpumask_scratch, >tickled);
+}
+
+/*
+ * If scurr is runnable, and this cpu is in its soft-affinity, default to
+ * it. We also default to it, even if cpu is not in its soft-affinity, if
+ * there aren't any idle and not tickled cpu in its soft-affinity. In
+ * fact, we don't want to risk leaving scurr in the runq and this cpu idle
+ * only because it running outside of its soft-affinity.
+ *
+ * On the other hand, if cpu is not in scurr's soft-affinity, and there
+ * looks to be better options, go for them. That happens by defaulting to
+ * idle here, which means scurr will be preempted, put back in runq, and
+ * one of those idle and not tickled cpus from its soft affinity will be
+ * tickled to pick it up.
+ *
+ * If scurr does not have a valid soft-affinity, we allow it to continue
+ * run here (that's why cpu_in_soft_aff is initialized to 1).
+ *
+ * Of course, we also default to idle also if scurr is not runnable.
+ */
+if ( vcpu_runnable(scurr->vcpu) &&
+ (cpu_in_soft_aff || cpumask_empty(cpumask_scratch)) )
 snext = scurr;
 else
 snext = CSCHED2_VCPU(idle_vcpu[cpu]);


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

[Xen-devel] [PATCH 18/24] xen: credit2: soft-affinity awareness fallback_cpu() and cpu_pick()

[Dario Faggioli]

For get_fallback_cpu(), by putting in place the "usual"
two steps (soft affinity step and hard affinity step)
loop. We just move the core logic of the function inside
the body of the loop itself.

For csched2_cpu_pick(), what is important is to find
the runqueue with the least average load. Currently,
we do that by looping on all runqueues and checking,
well, their load. For soft affinity, we want to know
which one is the runqueue with the least load, among
the ones where the vcpu would prefer to be assigned.

We find both the least loaded runqueue among the soft
affinity "friendly" ones, and the overall least loaded
one, in the same pass.

(Also, kill a spurious ';' when defining MAX_LOAD.)

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |  136 
 1 file changed, 111 insertions(+), 25 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 3aef1b4..2d7228a 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -506,34 +506,68 @@ void smt_idle_mask_clear(unsigned int cpu, cpumask_t 
*mask)
 }
 
 /*
- * When a hard affinity change occurs, we may not be able to check some
- * (any!) of the other runqueues, when looking for the best new processor
- * for svc (as trylock-s in csched2_cpu_pick() can fail). If that happens, we
- * pick, in order of decreasing preference:
- *  - svc's current pcpu;
- *  - another pcpu from svc's current runq;
- *  - any cpu.
+ * In csched2_cpu_pick(), it may not be possible to actually look at remote
+ * runqueues (the trylock-s on their spinlocks can fail!). If that happens,
+ * we pick, in order of decreasing preference:
+ *  1) svc's current pcpu, if it is part of svc's soft affinity;
+ *  2) a pcpu in svc's current runqueue that is also in svc's soft affinity;
+ *  3) just one valid pcpu from svc's soft affinity;
+ *  4) svc's current pcpu, if it is part of svc's hard affinity;
+ *  5) a pcpu in svc's current runqueue that is also in svc's hard affinity;
+ *  6) just one valid pcpu from svc's hard affinity
+ *
+ * Of course, 1, 2 and 3 makes sense only if svc has a soft affinity. Also
+ * note that at least 6 is guaranteed to _always_ return at least one pcpu.
  */
 static int get_fallback_cpu(struct csched2_vcpu *svc)
 {
 int cpu;
+unsigned int bs;
 
-if ( likely(cpumask_test_cpu(svc->vcpu->processor,
- svc->vcpu->cpu_hard_affinity)) )
-return svc->vcpu->processor;
+for_each_affinity_balance_step( bs )
+{
+if ( bs == BALANCE_SOFT_AFFINITY &&
+ !has_soft_affinity(svc->vcpu, svc->vcpu->cpu_hard_affinity) )
+continue;
 
-cpumask_and(cpumask_scratch, svc->vcpu->cpu_hard_affinity,
->rqd->active);
-cpu = cpumask_first(cpumask_scratch);
-if ( likely(cpu < nr_cpu_ids) )
-return cpu;
+affinity_balance_cpumask(svc->vcpu, bs, cpumask_scratch);
 
-cpumask_and(cpumask_scratch, svc->vcpu->cpu_hard_affinity,
-cpupool_domain_cpumask(svc->vcpu->domain));
+/*
+ * This is cases 1 or 4 (depending on bs): if v->processor is (still)
+ * in our affinity, go for it, for cache betterness.
+ */
+if ( likely(cpumask_test_cpu(svc->vcpu->processor,
+ cpumask_scratch)) )
+return svc->vcpu->processor;
 
-ASSERT(!cpumask_empty(cpumask_scratch));
+/*
+ * This is cases 2 or 5 (depending on bsp): v->processor isn't there
+ * any longer, check if we at least can stay in our current runq.
+ */
+cpumask_and(cpumask_scratch, cpumask_scratch,
+>rqd->active);
+cpu = cpumask_first(cpumask_scratch);
+if ( likely(cpu < nr_cpu_ids) )
+return cpu;
 
-return cpumask_first(cpumask_scratch);
+/*
+ * This is cases 3 or 6 (depending on bs): last stand, just one valid
+ * pcpu from our soft affinity, if we have one and if there's any. In
+ * fact, if we are doing soft-affinity, it is possible that we fail,
+ * which means we stay in the loop and look for hard affinity. OTOH,
+ * if we are at the hard-affinity balancing step, it's guaranteed that
+ * there is at least one valid cpu, and therefore we are sure that we
+ * return it, and never really exit the loop.
+ */
+cpumask_and(cpumask_scratch, cpumask_scratch,
+cpupool_domain_cpumask(svc->vcpu->domain));
+ASSERT(!cpumask_empty(cpumask_scratch) || bs == BALANCE_SOFT_AFFINITY);
+cpu = cpumask_first(cpumask_scratch);
+if ( likely(cpu < nr_cpu_ids) )
+return cpu;
+}
+BUG_ON(1);
+return -1;
 }
 
 /*
@@ -1561,14 

[Xen-devel] [PATCH 19/24] xen: credit2: soft-affinity awareness in load balancing

[Dario Faggioli]

We want is soft-affinity to play a role in load
balancing, i.e., when deciding whether or not to
push this vcpu from here to there, and/or pull that
other vcpu from there to here.

A way of doing that, is considering the following
(for both pushes and pulls, just with the roles of
current an new runqueues inverted):
 - how much affinity does the vcpu have with
   its current runq?
 - how much affinity will the vcpu it have with
   its new runq?

We call this 'degree of soft-affinity' of a vcpu
to a runq, and define it as, informally speaking,
a quantity that is proportional to the fraction of
pcpus of a runq that a vcpu has soft-affinity with.

Then, we use this 'degree of soft-affinity' to
compute a value that is used as a modifier of the
baseline --purely load based-- results of the load
balancer, we apply it (potentially, with a scaling
factor), and use the modified result for the actual
load balancing decision.

This modifier based approach is chosen because it
integrates well into the existing load balancing
framework, it is modular and can easily accommodate
further extensions.

A note on performance and optimization: since we
call (potentially) call consider() O(nr_vcpus^2)
times, we absolutely need that it is lean and
quick. Therefore, a bunch of things are
pre-calculated outside of it. This makes things
look less encapsulated and clean, but at the same
time, makes the code faster (and this is a critical
path, so we want it fast!).

Finally, this patch does not interfere with the
load balancing triggering logic. This is to say
that vcpus running outside of their soft-affinity
_don't_ trigger additional load balancing point.
Early numbers show that this is ok, but it well
may be the case that we will want to introduce
something like that at some point.

(Oh, and while there, just a couple of style fixes
are also done.)

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |  359 
 1 file changed, 326 insertions(+), 33 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 2d7228a..3722f46 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1786,19 +1786,21 @@ csched2_cpu_pick(const struct scheduler *ops, struct 
vcpu *vc)
 return new_cpu;
 }
 
-/* Working state of the load-balancing algorithm */
+/* Working state of the load-balancing algorithm. */
 typedef struct {
-/* NB: Modified by consider() */
+/* NB: Modified by consider(). */
 s_time_t load_delta;
 struct csched2_vcpu * best_push_svc, *best_pull_svc;
-/* NB: Read by consider() */
+/* NB: Read by consider() (and the various consider_foo() functions). */
 struct csched2_runqueue_data *lrqd;
-struct csched2_runqueue_data *orqd;  
+struct csched2_runqueue_data *orqd;
+bool_t push_has_soft_aff, pull_has_soft_aff;
+s_time_t push_soft_aff_load, pull_soft_aff_load;
 } balance_state_t;
 
-static void consider(balance_state_t *st, 
- struct csched2_vcpu *push_svc,
- struct csched2_vcpu *pull_svc)
+static inline s_time_t consider_load(balance_state_t *st,
+ struct csched2_vcpu *push_svc,
+ struct csched2_vcpu *pull_svc)
 {
 s_time_t l_load, o_load, delta;
 
@@ -1821,11 +1823,166 @@ static void consider(balance_state_t *st,
 if ( delta < 0 )
 delta = -delta;
 
+return delta;
+}
+
+/*
+ * Load balancing and soft-affinity.
+ *
+ * When trying to figure out whether or not it's best to move a vcpu from
+ * one runqueue to another, we must keep soft-affinity in mind. Intuitively
+ * we would want to know the following:
+ *  - 'how much' affinity does the vcpu have with its current runq?
+ *  - 'how much' affinity will it have with its new runq?
+ *
+ * But we certainly need to be more precise about how much it is that 'how
+ * much'! Let's start with some definitions:
+ *
+ *  - let v be a vcpu, running in runq I, with soft-affinity to vi
+ *pcpus of runq I, and soft affinity with vj pcpus of runq J;
+ *  - let k be another vcpu, running in runq J, with soft-affinity to kj
+ *pcpus of runq J, and with ki pcpus of runq I;
+ *  - let runq I have Ci pcpus, and runq J Cj pcpus;
+ *  - let vcpu v have an average load of lv, and k an average load of lk;
+ *  - let runq I have an average load of Li, and J an average load of Lj.
+ *
+ * We also define the following::
+ *
+ *  - lvi = lv * (vi / Ci)  as the 'perceived load' of v, when running
+ *  in runq i;
+ *  - lvj = lv * (vj / Cj)  as the 'perceived load' of v, it running
+ *  in runq j;
+ *  - the same for k, mutatis mutandis.
+ *
+ * Idea is that vi/Ci (i.e., the ratio of the number of cpus of a runq that
+ * a vcpu has 

[Xen-devel] [PATCH 15/24] xl: allow to set the ratelimit value online for Credit2

[Dario Faggioli]

Last part of the wiring necessary for allowing to
change the value of the ratelimit_us parameter online,
for Credit2 (like it is already for Credit1).

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: George Dunlap 
---
 docs/man/xl.pod.1.in  |9 
 tools/libxl/xl_cmdimpl.c  |   91 +
 tools/libxl/xl_cmdtable.c |2 +
 3 files changed, 86 insertions(+), 16 deletions(-)

diff --git a/docs/man/xl.pod.1.in b/docs/man/xl.pod.1.in
index 1adf322..013591b 100644
--- a/docs/man/xl.pod.1.in
+++ b/docs/man/xl.pod.1.in
@@ -1089,6 +1089,15 @@ to 65535 and the default is 256.
 
 Restrict output to domains in the specified cpupool.
 
+=item B<-s>, B<--schedparam>
+
+Specify to list or set pool-wide scheduler parameters.
+
+=item B<-r RLIMIT>, B<--ratelimit_us=RLIMIT>
+
+Attempts to limit the rate of context switching. It is basically the same
+as B<--ratelimit_us> in B
+
 =back
 
 =item B [I]
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7f961e3..5bdeda8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -6452,8 +6452,29 @@ static int sched_credit_pool_output(uint32_t poolid)
 return 0;
 }
 
-static int sched_credit2_domain_output(
-int domid)
+static int sched_credit2_params_set(int poolid,
+libxl_sched_credit2_params *scinfo)
+{
+if (libxl_sched_credit2_params_set(ctx, poolid, scinfo)) {
+fprintf(stderr, "libxl_sched_credit2_params_set failed.\n");
+return 1;
+}
+
+return 0;
+}
+
+static int sched_credit2_params_get(int poolid,
+libxl_sched_credit2_params *scinfo)
+{
+if (libxl_sched_credit2_params_get(ctx, poolid, scinfo)) {
+fprintf(stderr, "libxl_sched_credit2_params_get failed.\n");
+return 1;
+}
+
+return 0;
+}
+
+static int sched_credit2_domain_output(int domid)
 {
 char *domname;
 libxl_domain_sched_params scinfo;
@@ -6478,6 +6499,22 @@ static int sched_credit2_domain_output(
 return 0;
 }
 
+static int sched_credit2_pool_output(uint32_t poolid)
+{
+libxl_sched_credit2_params scparam;
+char *poolname = libxl_cpupoolid_to_name(ctx, poolid);
+
+if (sched_credit2_params_get(poolid, ))
+printf("Cpupool %s: [sched params unavailable]\n", poolname);
+else
+printf("Cpupool %s: ratelimit=%dus\n",
+   poolname, scparam.ratelimit_us);
+
+free(poolname);
+
+return 0;
+}
+
 static int sched_rtds_domain_output(
 int domid)
 {
@@ -6577,17 +6614,6 @@ static int sched_rtds_pool_output(uint32_t poolid)
 return 0;
 }
 
-static int sched_default_pool_output(uint32_t poolid)
-{
-char *poolname;
-
-poolname = libxl_cpupoolid_to_name(ctx, poolid);
-printf("Cpupool %s:\n",
-   poolname);
-free(poolname);
-return 0;
-}
-
 static int sched_domain_output(libxl_scheduler sched, int (*output)(int),
int (*pooloutput)(uint32_t), const char 
*cpupool)
 {
@@ -6833,17 +6859,22 @@ int main_sched_credit2(int argc, char **argv)
 {
 const char *dom = NULL;
 const char *cpupool = NULL;
+int ratelimit = 0;
 int weight = 256;
+bool opt_s = false;
+bool opt_r = false;
 bool opt_w = false;
 int opt, rc;
 static struct option opts[] = {
 {"domain", 1, 0, 'd'},
 {"weight", 1, 0, 'w'},
+{"schedparam", 0, 0, 's'},
+{"ratelimit_us", 1, 0, 'r'},
 {"cpupool", 1, 0, 'p'},
 COMMON_LONG_OPTS
 };
 
-SWITCH_FOREACH_OPT(opt, "d:w:p:", opts, "sched-credit2", 0) {
+SWITCH_FOREACH_OPT(opt, "d:w:p:r:s", opts, "sched-credit2", 0) {
 case 'd':
 dom = optarg;
 break;
@@ -6851,6 +6882,13 @@ int main_sched_credit2(int argc, char **argv)
 weight = strtol(optarg, NULL, 10);
 opt_w = true;
 break;
+case 's':
+opt_s = true;
+break;
+case 'r':
+ratelimit = strtol(optarg, NULL, 10);
+opt_r = true;
+break;
 case 'p':
 cpupool = optarg;
 break;
@@ -6866,10 +6904,31 @@ int main_sched_credit2(int argc, char **argv)
 return EXIT_FAILURE;
 }
 
-if (!dom) { /* list all domain's credit scheduler info */
+if (opt_s) {
+libxl_sched_credit2_params scparam;
+uint32_t poolid = 0;
+
+if (cpupool) {
+if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool,
+ , NULL) ||
+!libxl_cpupoolid_is_valid(ctx, poolid)) {
+fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
+return EXIT_FAILURE;
+}
+}
+
+if (!opt_r) { /* Output scheduling parameters */
+if (sched_credit2_pool_output(poolid))
+return 

[Xen-devel] [PATCH 17/24] xen: credit2: soft-affinity awareness in runq_tickle()

[Dario Faggioli]

This is done by means of the "usual" two steps loop:
 - soft affinity balance step;
 - hard affinity balance step.

The entire logic implemented in runq_tickle() is
applied, during the first step, considering only the
CPUs in the vcpu's soft affinity. In the second step,
we fall back to use all the CPUs from its hard
affinity (as it is doing now, without this patch).

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |  243 
 1 file changed, 157 insertions(+), 86 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 0d83bd7..3aef1b4 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -902,6 +902,42 @@ __runq_remove(struct csched2_vcpu *svc)
 list_del_init(>runq_elem);
 }
 
+/*
+ * During the soft-affinity step, only actually preempt someone if
+ * he does not have soft-affinity with cpu (while we have).
+ *
+ * BEWARE that this uses cpumask_scratch, trowing away what's in there!
+ */
+static inline bool_t soft_aff_check_preempt(unsigned int bs, unsigned int cpu)
+{
+struct csched2_vcpu * cur = CSCHED2_VCPU(curr_on_cpu(cpu));
+
+/*
+ * If we're doing hard-affinity, always check whether to preempt cur.
+ * If we're doing soft-affinity, but cur doesn't have one, check as well.
+ */
+if ( bs == BALANCE_HARD_AFFINITY ||
+ !has_soft_affinity(cur->vcpu, cur->vcpu->cpu_hard_affinity) )
+return 1;
+
+/*
+ * We're doing soft-affinity, and we know that the current vcpu on cpu
+ * has a soft affinity. We now want to know whether cpu itself is in
+ * such affinity. In fact, since we now that new (in runq_tickle()) is:
+ *  - if cpu is not in cur's soft-affinity, we should indeed check to
+ *see whether new should preempt cur. If that will be the case, that
+ *would be an improvement wrt respecting soft affinity;
+ *  - if cpu is in cur's soft-affinity, we leave it alone and (in
+ *runq_tickle()) move on to another cpu. In fact, we don't want to
+ *be too harsh with someone which is running within its soft-affinity.
+ *This is safe because later, if we don't fine anyone else during the
+ *soft-affinity step, we will check cpu for preemption anyway, when
+ *doing hard-affinity.
+ */
+affinity_balance_cpumask(cur->vcpu, BALANCE_SOFT_AFFINITY, 
cpumask_scratch);
+return !cpumask_test_cpu(cpu, cpumask_scratch);
+}
+
 void burn_credits(struct csched2_runqueue_data *rqd, struct csched2_vcpu *, 
s_time_t);
 
 /*
@@ -925,7 +961,7 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 {
 int i, ipid = -1;
 s_time_t lowest = (1<<30);
-unsigned int cpu = new->vcpu->processor;
+unsigned int bs, cpu = new->vcpu->processor;
 struct csched2_runqueue_data *rqd = RQD(ops, cpu);
 cpumask_t mask;
 struct csched2_vcpu * cur;
@@ -947,109 +983,144 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 (unsigned char *));
 }
 
-/*
- * First of all, consider idle cpus, checking if we can just
- * re-use the pcpu where we were running before.
- *
- * If there are cores where all the siblings are idle, consider
- * them first, honoring whatever the spreading-vs-consolidation
- * SMT policy wants us to do.
- */
-if ( unlikely(sched_smt_power_savings) )
-cpumask_andnot(, >idle, >smt_idle);
-else
-cpumask_copy(, >smt_idle);
-cpumask_and(, , new->vcpu->cpu_hard_affinity);
-i = cpumask_test_or_cycle(cpu, );
-if ( i < nr_cpu_ids )
+for_each_affinity_balance_step( bs )
 {
-SCHED_STAT_CRANK(tickled_idle_cpu);
-ipid = i;
-goto tickle;
-}
+/*
+ * First things first: if we are at the first (soft affinity) step,
+ * but new doesn't have a soft affinity, skip this step.
+ */
+if ( bs == BALANCE_SOFT_AFFINITY &&
+ !has_soft_affinity(new->vcpu, new->vcpu->cpu_hard_affinity) )
+continue;
 
-/*
- * If there are no fully idle cores, check all idlers, after
- * having filtered out pcpus that have been tickled but haven't
- * gone through the scheduler yet.
- */
-cpumask_andnot(, >idle, >tickled);
-cpumask_and(, , new->vcpu->cpu_hard_affinity);
-i = cpumask_test_or_cycle(cpu, );
-if ( i < nr_cpu_ids )
-{
-SCHED_STAT_CRANK(tickled_idle_cpu);
-ipid = i;
-goto tickle;
-}
+affinity_balance_cpumask(new->vcpu, bs, cpumask_scratch);
 
-/*
- * Otherwise, look for the non-idle (and non-tickled) processors with
- * the lowest credit, among the ones new is allowed to run on. Again,
- * the 

[Xen-devel] [PATCH 16/24] xen: sched: factor affinity helpers out of sched_credit.c

[Dario Faggioli]

make it possible to use the various helpers from other
schedulers, e.g., for implementing soft affinity within
them.

Since we are touching the code, also make it start using
variables called v for struct_vcpu*, as it is preferrable.

No functional change intended.

Signed-off-by: Dario Faggioli 
Signed-off-by: Justin T. Weaver 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit.c  |   98 +++-
 xen/include/xen/sched-if.h |   65 +
 2 files changed, 80 insertions(+), 83 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 14b207d..5d5bba9 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -137,27 +137,6 @@
 #define TRC_CSCHED_SCHEDULE  TRC_SCHED_CLASS_EVT(CSCHED, 9)
 #define TRC_CSCHED_RATELIMIT TRC_SCHED_CLASS_EVT(CSCHED, 10)
 
-
-/*
- * Hard and soft affinity load balancing.
- *
- * Idea is each vcpu has some pcpus that it prefers, some that it does not
- * prefer but is OK with, and some that it cannot run on at all. The first
- * set of pcpus are the ones that are both in the soft affinity *and* in the
- * hard affinity; the second set of pcpus are the ones that are in the hard
- * affinity but *not* in the soft affinity; the third set of pcpus are the
- * ones that are not in the hard affinity.
- *
- * We implement a two step balancing logic. Basically, every time there is
- * the need to decide where to run a vcpu, we first check the soft affinity
- * (well, actually, the && between soft and hard affinity), to see if we can
- * send it where it prefers to (and can) run on. However, if the first step
- * does not find any suitable and free pcpu, we fall back checking the hard
- * affinity.
- */
-#define CSCHED_BALANCE_SOFT_AFFINITY0
-#define CSCHED_BALANCE_HARD_AFFINITY1
-
 /*
  * Boot parameters
  */
@@ -287,53 +266,6 @@ __runq_remove(struct csched_vcpu *svc)
 list_del_init(>runq_elem);
 }
 
-
-#define for_each_csched_balance_step(step) \
-for ( (step) = 0; (step) <= CSCHED_BALANCE_HARD_AFFINITY; (step)++ )
-
-
-/*
- * Hard affinity balancing is always necessary and must never be skipped.
- * But soft affinity need only be considered when it has a functionally
- * different effect than other constraints (such as hard affinity, cpus
- * online, or cpupools).
- *
- * Soft affinity only needs to be considered if:
- * * The cpus in the cpupool are not a subset of soft affinity
- * * The hard affinity is not a subset of soft affinity
- * * There is an overlap between the soft affinity and the mask which is
- *   currently being considered.
- */
-static inline int __vcpu_has_soft_affinity(const struct vcpu *vc,
-   const cpumask_t *mask)
-{
-return !cpumask_subset(cpupool_domain_cpumask(vc->domain),
-   vc->cpu_soft_affinity) &&
-   !cpumask_subset(vc->cpu_hard_affinity, vc->cpu_soft_affinity) &&
-   cpumask_intersects(vc->cpu_soft_affinity, mask);
-}
-
-/*
- * Each csched-balance step uses its own cpumask. This function determines
- * which one (given the step) and copies it in mask. For the soft affinity
- * balancing step, the pcpus that are not part of vc's hard affinity are
- * filtered out from the result, to avoid running a vcpu where it would
- * like, but is not allowed to!
- */
-static void
-csched_balance_cpumask(const struct vcpu *vc, int step, cpumask_t *mask)
-{
-if ( step == CSCHED_BALANCE_SOFT_AFFINITY )
-{
-cpumask_and(mask, vc->cpu_soft_affinity, vc->cpu_hard_affinity);
-
-if ( unlikely(cpumask_empty(mask)) )
-cpumask_copy(mask, vc->cpu_hard_affinity);
-}
-else /* step == CSCHED_BALANCE_HARD_AFFINITY */
-cpumask_copy(mask, vc->cpu_hard_affinity);
-}
-
 static void burn_credits(struct csched_vcpu *svc, s_time_t now)
 {
 s_time_t delta;
@@ -398,18 +330,18 @@ static inline void __runq_tickle(struct csched_vcpu *new)
  * Soft and hard affinity balancing loop. For vcpus without
  * a useful soft affinity, consider hard affinity only.
  */
-for_each_csched_balance_step( balance_step )
+for_each_affinity_balance_step( balance_step )
 {
 int new_idlers_empty;
 
-if ( balance_step == CSCHED_BALANCE_SOFT_AFFINITY
- && !__vcpu_has_soft_affinity(new->vcpu,
-  new->vcpu->cpu_hard_affinity) )
+if ( balance_step == BALANCE_SOFT_AFFINITY
+ && !has_soft_affinity(new->vcpu,
+   new->vcpu->cpu_hard_affinity) )
 continue;
 
 /* Are there idlers suitable for new (for this balance step)? */
-csched_balance_cpumask(new->vcpu, balance_step,
-   

[Xen-devel] [PATCH 13/24] libxc: improve error handling of xc Credit1 and Credit2 helpers

[Dario Faggioli]

In fact, libxc wrappers should, on error, set errno and
return -1.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/xc_csched.c  |   27 +++
 tools/libxc/xc_csched2.c |   15 +--
 2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/tools/libxc/xc_csched.c b/tools/libxc/xc_csched.c
index bf03bfc..139fc16 100644
--- a/tools/libxc/xc_csched.c
+++ b/tools/libxc/xc_csched.c
@@ -37,7 +37,10 @@ xc_sched_credit_domain_set(
 domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
 domctl.u.scheduler_op.u.credit = *sdom;
 
-return do_domctl(xch, );
+if ( do_domctl(xch, ) )
+return -1;
+
+return 0;
 }
 
 int
@@ -47,18 +50,18 @@ xc_sched_credit_domain_get(
 struct xen_domctl_sched_credit *sdom)
 {
 DECLARE_DOMCTL;
-int err;
 
 domctl.cmd = XEN_DOMCTL_scheduler_op;
 domctl.domain = (domid_t) domid;
 domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
 domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_getinfo;
 
-err = do_domctl(xch, );
-if ( err == 0 )
-*sdom = domctl.u.scheduler_op.u.credit;
+if ( do_domctl(xch, ) )
+return -1;
+
+*sdom = domctl.u.scheduler_op.u.credit;
 
-return err;
+return 0;
 }
 
 int
@@ -67,7 +70,6 @@ xc_sched_credit_params_set(
 uint32_t cpupool_id,
 struct xen_sysctl_credit_schedule *schedule)
 {
-int rc;
 DECLARE_SYSCTL;
 
 sysctl.cmd = XEN_SYSCTL_scheduler_op;
@@ -77,11 +79,12 @@ xc_sched_credit_params_set(
 
 sysctl.u.scheduler_op.u.sched_credit = *schedule;
 
-rc = do_sysctl(xch, );
+if ( do_sysctl(xch, ) )
+return -1;
 
 *schedule = sysctl.u.scheduler_op.u.sched_credit;
 
-return rc;
+return 0;
 }
 
 int
@@ -90,7 +93,6 @@ xc_sched_credit_params_get(
 uint32_t cpupool_id,
 struct xen_sysctl_credit_schedule *schedule)
 {
-int rc;
 DECLARE_SYSCTL;
 
 sysctl.cmd = XEN_SYSCTL_scheduler_op;
@@ -98,9 +100,10 @@ xc_sched_credit_params_get(
 sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT;
 sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_getinfo;
 
-rc = do_sysctl(xch, );
+if ( do_sysctl(xch, ) )
+return -1;
 
 *schedule = sysctl.u.scheduler_op.u.sched_credit;
 
-return rc;
+return 0;
 }
diff --git a/tools/libxc/xc_csched2.c b/tools/libxc/xc_csched2.c
index 5b62a5f..12c95e6 100644
--- a/tools/libxc/xc_csched2.c
+++ b/tools/libxc/xc_csched2.c
@@ -37,7 +37,10 @@ xc_sched_credit2_domain_set(
 domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_putinfo;
 domctl.u.scheduler_op.u.credit2 = *sdom;
 
-return do_domctl(xch, );
+if ( do_domctl(xch, ) )
+return -1;
+
+return 0;
 }
 
 int
@@ -47,18 +50,18 @@ xc_sched_credit2_domain_get(
 struct xen_domctl_sched_credit2 *sdom)
 {
 DECLARE_DOMCTL;
-int err;
 
 domctl.cmd = XEN_DOMCTL_scheduler_op;
 domctl.domain = (domid_t) domid;
 domctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT2;
 domctl.u.scheduler_op.cmd = XEN_DOMCTL_SCHEDOP_getinfo;
 
-err = do_domctl(xch, );
-if ( err == 0 )
-*sdom = domctl.u.scheduler_op.u.credit2;
+if ( do_domctl(xch, ) )
+return -1;
+
+*sdom = domctl.u.scheduler_op.u.credit2;
 
-return err;
+return 0;
 }
 
 int


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

[Xen-devel] [PATCH 14/24] libxl: allow to set the ratelimit value online for Credit2

[Dario Faggioli]

This is the remaining part of the plumbing (the libxl
one) necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).

Note that, so far, we were rejecting (for Credit1) a
new value of zero, despite it is a pretty nice way to
ask for the rate limiting to be disabled, and the
hypervisor is already capable of dealing with it in
that way.

Therefore, we change things so that it is possible to
do so, both for Credit1 and Credit2

While there, fix the error handling path (make it
compliant with libxl's codying style) in Credit1
rate limiting related functions.

Signed-off-by: Dario Faggioli 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: George Dunlap 
---
 tools/libxl/libxl.c |  111 ++-
 tools/libxl/libxl.h |4 ++
 tools/libxl/libxl_types.idl |4 ++
 3 files changed, 95 insertions(+), 24 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6a50e49..d6a8d02 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5229,69 +5229,132 @@ static int sched_credit_domain_set(libxl__gc *gc, 
uint32_t domid,
 return 0;
 }
 
+static int sched_ratelimit_check(libxl__gc *gc, int ratelimit)
+{
+if (ratelimit != 0 &&
+(ratelimit <  XEN_SYSCTL_SCHED_RATELIMIT_MIN ||
+ ratelimit > XEN_SYSCTL_SCHED_RATELIMIT_MAX)) {
+LOG(ERROR, "Ratelimit out of range, valid range is from %d to %d",
+XEN_SYSCTL_SCHED_RATELIMIT_MIN, XEN_SYSCTL_SCHED_RATELIMIT_MAX);
+return ERROR_INVAL;
+}
+
+return 0;
+}
+
 int libxl_sched_credit_params_get(libxl_ctx *ctx, uint32_t poolid,
   libxl_sched_credit_params *scinfo)
 {
 struct xen_sysctl_credit_schedule sparam;
-int rc;
+int r, rc;
 GC_INIT(ctx);
 
-rc = xc_sched_credit_params_get(ctx->xch, poolid, );
-if (rc != 0) {
-LOGE(ERROR, "getting sched credit param");
-GC_FREE;
-return ERROR_FAIL;
+r = xc_sched_credit_params_get(ctx->xch, poolid, );
+if (r < 0) {
+LOGE(ERROR, "getting Credit scheduler parameters");
+rc = ERROR_FAIL;
+goto out;
 }
 
 scinfo->tslice_ms = sparam.tslice_ms;
 scinfo->ratelimit_us = sparam.ratelimit_us;
 
+rc = 0;
+ out:
 GC_FREE;
-return 0;
+return rc;
 }
 
 int libxl_sched_credit_params_set(libxl_ctx *ctx, uint32_t poolid,
   libxl_sched_credit_params *scinfo)
 {
 struct xen_sysctl_credit_schedule sparam;
-int rc=0;
+int r, rc;
 GC_INIT(ctx);
 
 if (scinfo->tslice_ms <  XEN_SYSCTL_CSCHED_TSLICE_MIN
 || scinfo->tslice_ms > XEN_SYSCTL_CSCHED_TSLICE_MAX) {
 LOG(ERROR, "Time slice out of range, valid range is from %d to %d",
 XEN_SYSCTL_CSCHED_TSLICE_MIN, XEN_SYSCTL_CSCHED_TSLICE_MAX);
-GC_FREE;
-return ERROR_INVAL;
+rc = ERROR_INVAL;
+goto out;
 }
-if (scinfo->ratelimit_us <  XEN_SYSCTL_SCHED_RATELIMIT_MIN
-|| scinfo->ratelimit_us > XEN_SYSCTL_SCHED_RATELIMIT_MAX) {
-LOG(ERROR, "Ratelimit out of range, valid range is from %d to %d",
-XEN_SYSCTL_SCHED_RATELIMIT_MIN, XEN_SYSCTL_SCHED_RATELIMIT_MAX);
-GC_FREE;
-return ERROR_INVAL;
+rc = sched_ratelimit_check(gc, scinfo->ratelimit_us);
+if (rc) {
+goto out;
 }
 if (scinfo->ratelimit_us > scinfo->tslice_ms*1000) {
 LOG(ERROR, "Ratelimit cannot be greater than timeslice");
-GC_FREE;
-return ERROR_INVAL;
+rc = ERROR_INVAL;
+goto out;
 }
 
 sparam.tslice_ms = scinfo->tslice_ms;
 sparam.ratelimit_us = scinfo->ratelimit_us;
 
-rc = xc_sched_credit_params_set(ctx->xch, poolid, );
-if ( rc < 0 ) {
-LOGE(ERROR, "setting sched credit param");
-GC_FREE;
-return ERROR_FAIL;
+r = xc_sched_credit_params_set(ctx->xch, poolid, );
+if ( r < 0 ) {
+LOGE(ERROR, "Setting Credit scheduler parameters");
+rc = ERROR_FAIL;
+goto out;
 }
 
 scinfo->tslice_ms = sparam.tslice_ms;
 scinfo->ratelimit_us = sparam.ratelimit_us;
 
+ out:
 GC_FREE;
-return 0;
+return rc;
+}
+
+int libxl_sched_credit2_params_get(libxl_ctx *ctx, uint32_t poolid,
+   libxl_sched_credit2_params *scinfo)
+{
+struct xen_sysctl_credit2_schedule sparam;
+int r, rc;
+GC_INIT(ctx);
+
+r = xc_sched_credit2_params_get(ctx->xch, poolid, );
+if (r < 0) {
+LOGE(ERROR, "getting Credit2 scheduler parameters");
+rc = ERROR_FAIL;
+goto out;
+}
+
+scinfo->ratelimit_us = sparam.ratelimit_us;
+
+rc = 0;
+ out:
+GC_FREE;
+return rc;
+}
+
+int libxl_sched_credit2_params_set(libxl_ctx *ctx, uint32_t poolid,
+   

[Xen-devel] [PATCH 12/24] xen: libxc: allow to set the ratelimit value online

[Dario Faggioli]

The main purpose of the patch is to provide the xen-libxc
plumbing necessary to be able to change the value of the
ratelimit_us parameter online, for Credit2 (like it is
already for Credit1).

While there:
 - mention in the Xen logs when rate limiting was enables
   and is being disabled (and vice-versa);
 - fix csched2_sys_cntl() which was always returning
   -EINVAL in the XEN_SYSCTL_SCHEDOP_putinfo case.

And also:
 - fix style of an if in csched_sys_cntl();
 - fix the style of the switch in csched2_sys_cntl();

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Jan Beulich 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/include/xenctrl.h |   32 ++
 tools/libxc/xc_csched2.c  |   44 +
 xen/common/sched_credit.c |   16 +--
 xen/common/sched_credit2.c|   38 ---
 xen/include/public/sysctl.h   |   17 +---
 5 files changed, 108 insertions(+), 39 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 560ce7b..7a50895 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -910,25 +910,31 @@ int xc_sched_credit_domain_get(xc_interface *xch,
uint32_t domid,
struct xen_domctl_sched_credit *sdom);
 int xc_sched_credit_params_set(xc_interface *xch,
-  uint32_t cpupool_id,
-  struct xen_sysctl_credit_schedule *schedule);
+   uint32_t cpupool_id,
+   struct xen_sysctl_credit_schedule *schedule);
 int xc_sched_credit_params_get(xc_interface *xch,
-  uint32_t cpupool_id,
-  struct xen_sysctl_credit_schedule *schedule);
+   uint32_t cpupool_id,
+   struct xen_sysctl_credit_schedule *schedule);
+
+int xc_sched_credit2_params_set(xc_interface *xch,
+uint32_t cpupool_id,
+struct xen_sysctl_credit2_schedule *schedule);
+int xc_sched_credit2_params_get(xc_interface *xch,
+uint32_t cpupool_id,
+struct xen_sysctl_credit2_schedule *schedule);
 int xc_sched_credit2_domain_set(xc_interface *xch,
-   uint32_t domid,
-   struct xen_domctl_sched_credit2 *sdom);
-
+uint32_t domid,
+struct xen_domctl_sched_credit2 *sdom);
 int xc_sched_credit2_domain_get(xc_interface *xch,
-   uint32_t domid,
-   struct xen_domctl_sched_credit2 *sdom);
+uint32_t domid,
+struct xen_domctl_sched_credit2 *sdom);
 
 int xc_sched_rtds_domain_set(xc_interface *xch,
-uint32_t domid,
-struct xen_domctl_sched_rtds *sdom);
+ uint32_t domid,
+ struct xen_domctl_sched_rtds *sdom);
 int xc_sched_rtds_domain_get(xc_interface *xch,
-uint32_t domid,
-struct xen_domctl_sched_rtds *sdom);
+ uint32_t domid,
+ struct xen_domctl_sched_rtds *sdom);
 int xc_sched_rtds_vcpu_set(xc_interface *xch,
uint32_t domid,
struct xen_domctl_schedparam_vcpu *vcpus,
diff --git a/tools/libxc/xc_csched2.c b/tools/libxc/xc_csched2.c
index ed99605..5b62a5f 100644
--- a/tools/libxc/xc_csched2.c
+++ b/tools/libxc/xc_csched2.c
@@ -60,3 +60,47 @@ xc_sched_credit2_domain_get(
 
 return err;
 }
+
+int
+xc_sched_credit2_params_set(
+xc_interface *xch,
+uint32_t cpupool_id,
+struct xen_sysctl_credit2_schedule *schedule)
+{
+DECLARE_SYSCTL;
+
+sysctl.cmd = XEN_SYSCTL_scheduler_op;
+sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT2;
+sysctl.u.scheduler_op.cmd = XEN_SYSCTL_SCHEDOP_putinfo;
+
+sysctl.u.scheduler_op.u.sched_credit2 = *schedule;
+
+if ( do_sysctl(xch, ) )
+return -1;
+
+*schedule = sysctl.u.scheduler_op.u.sched_credit2;
+
+return 0;
+}
+
+int
+xc_sched_credit2_params_get(
+xc_interface *xch,
+uint32_t cpupool_id,
+struct xen_sysctl_credit2_schedule *schedule)
+{
+DECLARE_SYSCTL;
+
+sysctl.cmd = XEN_SYSCTL_scheduler_op;
+sysctl.u.scheduler_op.cpupool_id = cpupool_id;
+sysctl.u.scheduler_op.sched_id = XEN_SCHEDULER_CREDIT2;
+sysctl.u.scheduler_op.cmd = 

[Xen-devel] [PATCH 11/24] tools: tracing: handle more scheduling related events.

[Dario Faggioli]

There are some scheduling related trace records that
are not being taken care of (and hence only dumped as
raw records).

Some of them are being introduced in this series, while
other were just neglected by previous patches.

Add support for them.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/xentrace/formats|8 
 tools/xentrace/xenalyze.c |  101 +
 2 files changed, 109 insertions(+)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index adff681..3488a06 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -42,6 +42,10 @@
 0x00022004  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:stolen_vcpu   [ 
dom:vcpu = 0x%(2)04x%(3)04x, from = %(1)d ]
 0x00022005  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:picked_cpu[ 
dom:vcpu = 0x%(1)04x%(2)04x, cpu = %(3)d ]
 0x00022006  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:tickle[ cpu = 
%(1)d ]
+0x00022007  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:boost [ 
dom:vcpu = 0x%(1)04x%(2)04x ]
+0x00022008  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:unboost   [ 
dom:vcpu = 0x%(1)04x%(2)04x ]
+0x00022009  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:schedule  [ cpu = 
%(1)d, tasklet_scheduled = %(2)d, was_idle = %(3)d ]
+0x0002200A  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:ratelimit [ 
dom:vcpu = 0x%(1)04x%(2)04x, runtime = %(3)d ]
 
 0x00022201  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tick
 0x00022202  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_pos   [ 
dom:vcpu = 0x%(1)08x, pos = %(2)d]
@@ -61,12 +65,16 @@
 0x00022210  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:load_check [ 
lrq_id[16]:orq_id[16] = 0x%(1)08x, delta = %(2)d ]
 0x00022211  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:load_balance   [ 
l_bavgload = 0x%(2)08x%(1)08x, o_bavgload = 0x%(4)08x%(3)08x, 
lrq_id[16]:orq_id[16] = 0x%(5)08x ]
 0x00022212  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:pick_cpu   [ 
b_avgload = 0x%(2)08x%(1)08x, dom:vcpu = 0x%(3)08x, rq_id[16]:new_cpu[16] = 
%(4)d ]
+0x00022213  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_candidate [ 
dom:vcpu = 0x%(1)08x, runq_pos = %(2)d tickled_cpu = %(3)d ]
+0x00022214  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:schedule   [ 
rq:cpu = 0x%(1)08x, tasklet[8]:idle[8]:smt_idle[8]:tickled[8] = %(2)08x ]
+0x00022215  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:ratelimit  [ 
dom:vcpu = 0x%(1)08x, runtime = %(2)d ]
 
 0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle[ cpu = 
%(1)d ]
 0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
 0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu 
= 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
 0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu 
= 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
+0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule  [ 
cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
 
 0x00041001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_create   [ dom = 
0x%(1)08x ]
 0x00041002  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_destroy  [ dom = 
0x%(1)08x ]
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 58a8d41..aaff1d9 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7590,6 +7590,50 @@ void sched_process(struct pcpu_info *p)
ri->dump_header, r->cpu);
 }
 break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 7): /* BOOST_START   */
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched: d%uv%u boosted\n",
+   ri->dump_header, r->domid, r->vcpuid);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 8): /* BOOST_END */
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched: d%uv%u unboosted\n",
+   ri->dump_header, r->domid, r->vcpuid);
+}
+break;
+case TRC_SCHED_CLASS_EVT(CSCHED, 9): /* SCHEDULE  */
+if(opt.dump_all) {
+struct {
+unsigned int cpu, tasklet, idle;
+} *r = (typeof(r))ri->d;
+
+printf(" %s csched:schedule cpu %u, %s%s\n",
+   ri->dump_header, r->cpu,
+   r->tasklet ? ", tasklet scheduled" : "",
+   r->idle ? ", idle" : 

[Xen-devel] [PATCH 10/24] xen: tracing: improve Credit2's tickle_check and burn_credits records

[Dario Faggioli]

In both Credit2's trace records relative to checking
whether we want to preempt a vcpu (in runq_tickle()),
and to credits being burn, make it explicit on which
pcpu the vcpu being considered is running.

Such information isn't currently available, not even
by looking at on which pcpu the events happen, as we
do both the above operation from a certain pcpu on
vcpus running on different pcpus.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/xentrace/formats |4 ++--
 tools/xentrace/xenalyze.c  |   15 +--
 xen/common/sched_credit2.c |6 --
 3 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 0de7990..adff681 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -45,9 +45,9 @@
 
 0x00022201  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tick
 0x00022202  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_pos   [ 
dom:vcpu = 0x%(1)08x, pos = %(2)d]
-0x00022203  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit burn[ 
dom:vcpu = 0x%(1)08x, credit = %(2)d, delta = %(3)d ]
+0x00022203  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit burn[ 
dom:vcpu = 0x%(1)08x, cpu = %(3)d, credit = %(2)d, delta = %(4)d ]
 0x00022204  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit_add
-0x00022205  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle_check   [ 
dom:vcpu = 0x%(1)08x, credit = %(2)d ]
+0x00022205  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle_check   [ 
dom:vcpu = 0x%(1)08x, cpu = %(2)d, credit = %(3)d ]
 0x00022206  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:tickle [ cpu = 
%(1)d ]
 0x00022207  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:credit_reset   [ 
dom:vcpu = 0x%(1)08x, cr_start = %(2)d, cr_end = %(3)d, mult = %(4)d ]
 0x00022208  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:sched_tasklet
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 0b697d0..58a8d41 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7607,24 +7607,27 @@ void sched_process(struct pcpu_info *p)
 case TRC_SCHED_CLASS_EVT(CSCHED2, 3): /* CREDIT_BURN   */
 if(opt.dump_all) {
 struct {
-unsigned int vcpuid:16, domid:16, credit;
+unsigned int vcpuid:16, domid:16, credit, cpu;
 int delta;
 } *r = (typeof(r))ri->d;
 
-printf(" %s csched2:burn_credits d%uv%u, credit = %u, delta = 
%d\n",
+printf(" %s csched2:burn_credits d%uv%u, "
+   "on cpu = %u, credit = %u, delta = %d\n",
ri->dump_header, r->domid, r->vcpuid,
-   r->credit, r->delta);
+   r->cpu, r->credit, r->delta);
 }
 break;
 case TRC_SCHED_CLASS_EVT(CSCHED2, 5): /* TICKLE_CHECK  */
 if(opt.dump_all) {
 struct {
 unsigned int vcpuid:16, domid:16;
-unsigned int credit;
+unsigned int cpu, credit;
 } *r = (typeof(r))ri->d;
 
-printf(" %s csched2:tickle_check d%uv%u, credit = %u\n",
-   ri->dump_header, r->domid, r->vcpuid, r->credit);
+printf(" %s csched2:tickle_check d%uv%u, "
+   "on cpu = %u, credits = %u\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->cpu, r->credit);
 }
 break;
 case TRC_SCHED_CLASS_EVT(CSCHED2, 6): /* TICKLE*/
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 164296b..c8396a8 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1027,11 +1027,12 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 {
 struct {
 unsigned vcpu:16, dom:16;
-unsigned credit;
+unsigned cpu, credit;
 } d;
 d.dom = cur->vcpu->domain->domain_id;
 d.vcpu = cur->vcpu->vcpu_id;
 d.credit = cur->credit;
+d.cpu = i;
 __trace_var(TRC_CSCHED2_TICKLE_CHECK, 1,
 sizeof(d),
 (unsigned char *));
@@ -1181,12 +1182,13 @@ void burn_credits(struct csched2_runqueue_data *rqd,
 {
 struct {
 unsigned vcpu:16, dom:16;
-unsigned credit;
+unsigned credit, cpu;
 int delta;
 } d;
 d.dom = svc->vcpu->domain->domain_id;
 d.vcpu = svc->vcpu->vcpu_id;
 d.credit = svc->credit;
+d.cpu = svc->vcpu->processor;
 d.delta = delta;
 __trace_var(TRC_CSCHED2_CREDIT_BURN, 1,
 sizeof(d),

[Xen-devel] [PATCH 09/24] xen/tools: tracing: improve tracing of context switches.

[Dario Faggioli]

Right now, two out of the three events related to
context switch (that is TRC_SCHED_SWITCH_INFPREV and
TRC_SCHED_SWITCH_INFNEXT) only report the domain id,
and not the vcpu id.

That's omitting a useful piece of information, and
even if we be figured that out by looking at other
records, that's unnecessarily complicated (especially
if working on a trace from a sctipt).

This changes both the tracing code in Xen and the parsing
code in tools at once, to avoid introducing transitional
regressions.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/xentrace/formats|4 ++--
 tools/xentrace/xenalyze.c |   17 +
 xen/common/schedule.c |8 
 3 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index caafb5f..0de7990 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -32,8 +32,8 @@
 0x0002800b  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  s_timer_fn
 0x0002800c  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  t_timer_fn
 0x0002800d  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  dom_timer_fn
-0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev[ old_domid 
= 0x%(1)08x, runtime = %(2)d ]
-0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ new_domid 
= 0x%(1)08x, time = %(2)d, r_time = %(3)d ]
+0x0002800e  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infprev[ dom:vcpu = 
0x%(1)04x%(2)04x, runtime = %(3)d ]
+0x0002800f  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  switch_infnext[ 
new_dom:vcpu = 0x%(1)04x%(2)04x, time = %(3)d, r_time = %(4)d ]
 0x00028010  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  domain_shutdown_code [ 
dom:vcpu = 0x%(1)04x%(2)04x, reason = 0x%(3)08x ]
 
 0x00022001  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched:sched_tasklet
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index 11763a8..0b697d0 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7501,28 +7501,29 @@ void sched_process(struct pcpu_info *p)
 case TRC_SCHED_SWITCH_INFPREV:
 if(opt.dump_all) {
 struct {
-unsigned int domid, runtime;
+unsigned int domid, vcpuid, runtime;
 } *r = (typeof(r))ri->d;
 
-printf(" %s sched_switch prev d%u, run for %u.%uus\n",
-   ri->dump_header, r->domid, r->runtime / 1000,
-   r->runtime % 1000);
+printf(" %s sched_switch prev d%uv%d, run for %u.%uus\n",
+   ri->dump_header, r->domid, r->vcpuid,
+   r->runtime / 1000, r->runtime % 1000);
 }
 break;
 case TRC_SCHED_SWITCH_INFNEXT:
 if(opt.dump_all)
 {
 struct {
-unsigned int domid, rsince;
+unsigned int domid, vcpuid, rsince;
 int slice;
 } *r = (typeof(r))ri->d;
 
-printf(" %s sched_switch next d%u", ri->dump_header, r->domid);
+printf(" %s sched_switch next d%uv%u", ri->dump_header,
+   r->domid, r->vcpuid);
 if ( r->rsince != 0 )
-printf(", was runnable for %u.%uus, ", r->rsince / 1000,
+printf(", was runnable for %u.%uus", r->rsince / 1000,
r->rsince % 1000);
 if ( r->slice > 0 )
-printf("next slice %u.%uus", r->slice / 1000,
+printf(", next slice %u.%uus", r->slice / 1000,
r->slice % 1000);
 printf("\n");
 }
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index abe063d..5b444c4 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1390,11 +1390,11 @@ static void schedule(void)
 return continue_running(prev);
 }
 
-TRACE_2D(TRC_SCHED_SWITCH_INFPREV,
- prev->domain->domain_id,
+TRACE_3D(TRC_SCHED_SWITCH_INFPREV,
+ prev->domain->domain_id, prev->vcpu_id,
  now - prev->runstate.state_entry_time);
-TRACE_3D(TRC_SCHED_SWITCH_INFNEXT,
- next->domain->domain_id,
+TRACE_4D(TRC_SCHED_SWITCH_INFNEXT,
+ next->domain->domain_id, next->vcpu_id,
  (next->runstate.state == RUNSTATE_runnable) ?
  (now - next->runstate.state_entry_time) : 0,
  next_slice.time);


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

[Xen-devel] [PATCH 08/24] xen: tracing: add trace records for schedule and rate-limiting.

[Dario Faggioli]

As far as {csched, csched2, rt}_schedule() are concerned,
an "empty" event, would already make it easier to read and
understand a trace.

But while there, add a few useful information, like
if the cpu that is going through the scheduler has
been tickled or not, if it is currently idle, etc
(they vary, on a per-scheduler basis).

For Credit1 and Credit2, add a record about when
rate-limiting kicks in too.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Meng Xu 
Cc: Anshul Makkar 
---
 xen/common/sched_credit.c  |7 +++
 xen/common/sched_credit2.c |   38 +-
 xen/common/sched_rt.c  |   15 +++
 3 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index ca04732..f9d3ac9 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -134,6 +134,8 @@
 #define TRC_CSCHED_TICKLETRC_SCHED_CLASS_EVT(CSCHED, 6)
 #define TRC_CSCHED_BOOST_START   TRC_SCHED_CLASS_EVT(CSCHED, 7)
 #define TRC_CSCHED_BOOST_END TRC_SCHED_CLASS_EVT(CSCHED, 8)
+#define TRC_CSCHED_SCHEDULE  TRC_SCHED_CLASS_EVT(CSCHED, 9)
+#define TRC_CSCHED_RATELIMIT TRC_SCHED_CLASS_EVT(CSCHED, 10)
 
 
 /*
@@ -1743,6 +1745,9 @@ csched_schedule(
 SCHED_STAT_CRANK(schedule);
 CSCHED_VCPU_CHECK(current);
 
+TRACE_3D(TRC_CSCHED_SCHEDULE, cpu, tasklet_work_scheduled,
+ is_idle_vcpu(current));
+
 runtime = now - current->runstate.state_entry_time;
 if ( runtime < 0 ) /* Does this ever happen? */
 runtime = 0;
@@ -1792,6 +1797,8 @@ csched_schedule(
 snext->start_time += now;
 perfc_incr(delay_ms);
 tslice = MICROSECS(prv->ratelimit_us) - runtime;
+TRACE_3D(TRC_CSCHED_RATELIMIT, scurr->vcpu->domain->domain_id,
+ scurr->vcpu->vcpu_id, runtime);
 ret.migrated = 0;
 goto out;
 }
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index c8e0ee7..164296b 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -55,6 +55,8 @@
 #define TRC_CSCHED2_LOAD_BALANCE TRC_SCHED_CLASS_EVT(CSCHED2, 17)
 #define TRC_CSCHED2_PICKED_CPU   TRC_SCHED_CLASS_EVT(CSCHED2, 19)
 #define TRC_CSCHED2_RUNQ_CANDIDATE   TRC_SCHED_CLASS_EVT(CSCHED2, 20)
+#define TRC_CSCHED2_SCHEDULE TRC_SCHED_CLASS_EVT(CSCHED2, 21)
+#define TRC_CSCHED2_RATELIMITTRC_SCHED_CLASS_EVT(CSCHED2, 22)
 
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be 
found at the
@@ -2293,7 +2295,22 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  vcpu_runnable(scurr->vcpu) &&
  (now - scurr->vcpu->runstate.state_entry_time) <
   MICROSECS(prv->ratelimit_us) )
+{
+if ( unlikely(tb_init_done) )
+{
+struct {
+unsigned vcpu:16, dom:16;
+unsigned runtime;
+} d;
+d.dom = scurr->vcpu->domain->domain_id;
+d.vcpu = scurr->vcpu->vcpu_id;
+d.runtime = now - scurr->vcpu->runstate.state_entry_time;
+__trace_var(TRC_CSCHED2_RATELIMIT, 1,
+sizeof(d),
+(unsigned char *));
+}
 return scurr;
+}
 
 /* Default to current if runnable, idle otherwise */
 if ( vcpu_runnable(scurr->vcpu) )
@@ -2383,6 +2400,7 @@ csched2_schedule(
 struct csched2_vcpu *snext = NULL;
 unsigned int snext_pos = 0;
 struct task_slice ret;
+bool_t tickled;
 
 SCHED_STAT_CRANK(schedule);
 CSCHED2_VCPU_CHECK(current);
@@ -2397,13 +2415,31 @@ csched2_schedule(
 BUG_ON(!is_idle_vcpu(scurr->vcpu) && scurr->rqd != rqd);
 
 /* Clear "tickled" bit now that we've been scheduled */
-if ( cpumask_test_cpu(cpu, >tickled) )
+tickled = cpumask_test_cpu(cpu, >tickled);
+if ( tickled )
 {
 __cpumask_clear_cpu(cpu, >tickled);
 cpumask_andnot(cpumask_scratch, >idle, >tickled);
 smt_idle_mask_set(cpu, cpumask_scratch, >smt_idle);
 }
 
+if ( unlikely(tb_init_done) )
+{
+struct {
+unsigned cpu:16, rq_id:16;
+unsigned tasklet:8, idle:8, smt_idle:8, tickled:8;
+} d;
+d.cpu = cpu;
+d.rq_id = c2r(ops, cpu);
+d.tasklet = tasklet_work_scheduled;
+d.idle = is_idle_vcpu(current);
+d.smt_idle = cpumask_test_cpu(cpu, >smt_idle);
+d.tickled = tickled;
+__trace_var(TRC_CSCHED2_SCHEDULE, 1,
+sizeof(d),
+(unsigned char *));
+}
+
 /* Update credits */
 burn_credits(rqd, scurr, now);
 
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 41c61a7..903dbd8 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -160,6 +160,7 @@
 #define TRC_RTDS_BUDGET_BURN  TRC_SCHED_CLASS_EVT(RTDS, 

[Xen-devel] [PATCH 07/24] xen: sched: don't rate limit context switches in case of yields

[Dario Faggioli]

In both Credit1 and Credit2, if a vcpu yields, let it...
well... yield!

In fact, context switch rate limiting has been primarily
introduced to avoid too heavy context switch rate due to
interrupts, and, in general, asynchronous events.

In a vcpu "voluntarily" yields, we really should let it
give up the cpu for a while. For instance, the reason may
be that it's about to start spinning, and there's few
point in forcing a vcpu to spin for (potentially) the
entire rate-limiting period.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit.c  |   20 +++
 xen/common/sched_credit2.c |   47 +++-
 2 files changed, 37 insertions(+), 30 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 3f439a0..ca04732 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1771,9 +1771,18 @@ csched_schedule(
  *   cpu and steal it.
  */
 
-/* If we have schedule rate limiting enabled, check to see
- * how long we've run for. */
-if ( !tasklet_work_scheduled
+/*
+ * If we have schedule rate limiting enabled, check to see
+ * how long we've run for.
+ *
+ * If scurr is yielding, however, we don't let rate limiting kick in.
+ * In fact, it may be the case that scurr is about to spin, and there's
+ * no point forcing it to do so until rate limiting expires.
+ *
+ * While there, take the chance for clearing the yield flag at once.
+ */
+if ( !test_and_clear_bit(CSCHED_FLAG_VCPU_YIELD, >flags)
+ && !tasklet_work_scheduled
  && prv->ratelimit_us
  && vcpu_runnable(current)
  && !is_idle_vcpu(current)
@@ -1808,11 +1817,6 @@ csched_schedule(
 }
 
 /*
- * Clear YIELD flag before scheduling out
- */
-clear_bit(CSCHED_FLAG_VCPU_YIELD, >flags);
-
-/*
  * SMP Load balance:
  *
  * If the next highest priority local runnable VCPU has already eaten
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 569174b..c8e0ee7 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2267,36 +2267,40 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 struct list_head *iter;
 struct csched2_vcpu *snext = NULL;
 struct csched2_private *prv = CSCHED2_PRIV(per_cpu(scheduler, cpu));
-int yield_bias = 0;
-
-/* Default to current if runnable, idle otherwise */
-if ( vcpu_runnable(scurr->vcpu) )
-{
-/*
- * The way we actually take yields into account is like this:
- * if scurr is yielding, when comparing its credits with other
- * vcpus in the runqueue, act like those other vcpus had yield_bias
- * more credits.
- */
-if ( unlikely(scurr->flags & CSFLAG_vcpu_yield) )
-yield_bias = CSCHED2_YIELD_BIAS;
-
-snext = scurr;
-}
-else
-snext = CSCHED2_VCPU(idle_vcpu[cpu]);
+/*
+ * The way we actually take yields into account is like this:
+ * if scurr is yielding, when comparing its credits with other vcpus in
+ * the runqueue, act like those other vcpus had yield_bias more credits.
+ */
+int yield_bias = __test_and_clear_bit(__CSFLAG_vcpu_yield, >flags) ?
+ CSCHED2_YIELD_BIAS : 0;
 
 /*
  * Return the current vcpu if it has executed for less than ratelimit.
  * Adjuststment for the selected vcpu's credit and decision
  * for how long it will run will be taken in csched2_runtime.
+ *
+ * Note that, if scurr is yielding, we don't let rate limiting kick in.
+ * In fact, it may be the case that scurr is about to spin, and there's
+ * no point forcing it to do so until rate limiting expires.
+ *
+ * To check whether we are yielding, it's enough to look at yield_bias
+ * (as CSCHED2_YIELD_BIAS can't be zero). Also, note that the yield flag
+ * has been cleared already above.
  */
-if ( prv->ratelimit_us && !is_idle_vcpu(scurr->vcpu) &&
+if ( !yield_bias &&
+ prv->ratelimit_us && !is_idle_vcpu(scurr->vcpu) &&
  vcpu_runnable(scurr->vcpu) &&
  (now - scurr->vcpu->runstate.state_entry_time) <
   MICROSECS(prv->ratelimit_us) )
 return scurr;
 
+/* Default to current if runnable, idle otherwise */
+if ( vcpu_runnable(scurr->vcpu) )
+snext = scurr;
+else
+snext = CSCHED2_VCPU(idle_vcpu[cpu]);
+
 list_for_each( iter, >runq )
 {
 struct csched2_vcpu * svc = list_entry(iter, struct csched2_vcpu, 
runq_elem);
@@ -2423,7 +2427,8 @@ csched2_schedule(
  */
 if ( tasklet_work_scheduled )
 {
-trace_var(TRC_CSCHED2_SCHED_TASKLET, 1, 0,  NULL);
+__clear_bit(__CSFLAG_vcpu_yield, >flags);
+trace_var(TRC_CSCHED2_SCHED_TASKLET, 1, 0, NULL);

[Xen-devel] [PATCH 06/24] xen: credit2: implement yield()

[Dario Faggioli]

When a vcpu explicitly yields it is usually giving
us an advice of "let someone else run and come back
to me in a bit."

Credit2 isn't, so far, doing anything when a vcpu
yields, which means an yield is basically a NOP (well,
actually, it's pure overhead, as it causes the scheduler
kick in, but the result is --at least 99% of the time--
that the very same vcpu that yielded continues to run).

Implement a "preempt bias", to be applied to yielding
vcpus. Basically when evaluating what vcpu to run next,
if a vcpu that has just yielded is encountered, we give
it a credit penalty, and check whether there is anyone
else that would better take over the cpu (of course,
if there isn't the yielding vcpu will continue).

The value of this bias can be configured with a boot
time parameter, and the default is set to 1 ms.

Also, add an yield performance counter, and fix the
style of a couple of comments.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
Note that this *only* consider the bias during the very scheduling decision
that retults from the vcpu calling yield. After that, the __CSFLAG_vcpu_yield
flag is reset, and during all furute scheduling decisions, the vcpu will
compete with the other ones with its own amount of credits.

Alternatively, we can actually _subtract_ some credits to a yielding vcpu.
That will sort of make the effect of a call to yield last in time.

I'm not sure which path is best. Personally, I like the subtract approach
(perhaps, with a smaller bias than 1ms), but I think the "one shot" behavior
implemented here is a good starting point. It is _something_, which is better
than nothing, which is what we have without this patch! :-) It's lightweight
(in its impact on the crediting algorithm, I mean), and benchmarks looks nice,
so I propose we go for this one, and explore the "permanent" --subtraction
based-- solution a bit more.
---
 docs/misc/xen-command-line.markdown |   10 ++
 xen/common/sched_credit2.c  |   62 +++
 xen/common/schedule.c   |2 +
 xen/include/xen/perfc_defn.h|1 +
 4 files changed, 68 insertions(+), 7 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 3a250cb..5f469b1 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1389,6 +1389,16 @@ Choose the default scheduler.
 ### sched\_credit2\_migrate\_resist
 > `= `
 
+### sched\_credit2\_yield\_bias
+> `= `
+
+> Default: `1000`
+
+Set how much a yielding vcpu will be penalized, in order to actually
+give a chance to run to some other vcpu. This is basically a bias, in
+favour of the non-yielding vcpus, expressed in microseconds (default
+is 1ms).
+
 ### sched\_credit\_tslice\_ms
 > `= `
 
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index a3d7beb..569174b 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -144,6 +144,9 @@
 #define CSCHED2_MIGRATE_RESIST   ((opt_migrate_resist)*MICROSECS(1))
 /* How much to "compensate" a vcpu for L2 migration */
 #define CSCHED2_MIGRATE_COMPENSATION MICROSECS(50)
+/* How big of a bias we should have against a yielding vcpu */
+#define CSCHED2_YIELD_BIAS   ((opt_yield_bias)*MICROSECS(1))
+#define CSCHED2_YIELD_BIAS_MIN   CSCHED2_MIN_TIMER
 /* Reset: Value below which credit will be reset. */
 #define CSCHED2_CREDIT_RESET 0
 /* Max timer: Maximum time a guest can be run for. */
@@ -181,11 +184,20 @@
  */
 #define __CSFLAG_runq_migrate_request 3
 #define CSFLAG_runq_migrate_request (1<<__CSFLAG_runq_migrate_request)
-
+/*
+ * CSFLAG_vcpu_yield: this vcpu was running, and has called vcpu_yield(). The
+ * scheduler is invoked to see if we can give the cpu to someone else, and
+ * get back to the yielding vcpu in a while.
+ */
+#define __CSFLAG_vcpu_yield 4
+#define CSFLAG_vcpu_yield (1<<__CSFLAG_vcpu_yield)
 
 static unsigned int __read_mostly opt_migrate_resist = 500;
 integer_param("sched_credit2_migrate_resist", opt_migrate_resist);
 
+static unsigned int __read_mostly opt_yield_bias = 1000;
+integer_param("sched_credit2_yield_bias", opt_yield_bias);
+
 /*
  * Useful macros
  */
@@ -1432,6 +1444,14 @@ out:
 }
 
 static void
+csched2_vcpu_yield(const struct scheduler *ops, struct vcpu *v)
+{
+struct csched2_vcpu * const svc = CSCHED2_VCPU(v);
+
+__set_bit(__CSFLAG_vcpu_yield, >flags);
+}
+
+static void
 csched2_context_saved(const struct scheduler *ops, struct vcpu *vc)
 {
 struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
@@ -2247,10 +2267,22 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 struct list_head *iter;
 struct csched2_vcpu *snext = NULL;
 struct csched2_private *prv = CSCHED2_PRIV(per_cpu(scheduler, cpu));
+int yield_bias 

[Xen-devel] [PATCH 01/24] xen: credit1: small optimization in Credit1's tickling logic.

[Dario Faggioli]

If, when vcpu x wakes up, there are no idle pcpus in x's
soft-affinity, we just go ahead and look at its hard
affinity. This basically means that, if, in __runq_tickle(),
new_idlers_empty is true, balance_step is equal to
CSCHED_BALANCE_HARD_AFFINITY, and that calling
csched_balance_cpumask() for whatever vcpu, would just
return the vcpu's cpu_hard_affinity.

Therefore, don't bother calling it (it's just pure
overhead) and use cpu_hard_affinity directly.

For this very reason, this patch should only be
a (slight) optimization, and entail no functional
change.

As a side note, it would make sense to do what the
patch does, even if we could be inside the
[[ new_idlers_empty && new->pri > cur->pri ]] if
with balance_step equal to CSCHED_BALANCE_SOFT_AFFINITY.
In fact, what is actually happening is:
 - vcpu x is waking up, and (since there aren't suitable
   idlers, and it's entitled for it) it is preempting
   vcpu y;
 - vcpu y's hard-affinity is a superset of its
   soft-affinity mask.

Therefore, it makes sense to use wider possible mask,
as by doing that, we maximize the probability of
finding an idle pcpu in there, to which we can send
vcpu y, which then will be able to run.

While there, also fix the comment, which included
an awkward parenthesis nesting.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: David Vrabel 
---
 xen/common/sched_credit.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 220ff0d..6eccf09 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -424,9 +424,9 @@ static inline void __runq_tickle(struct csched_vcpu *new)
 /*
  * If there are no suitable idlers for new, and it's higher
  * priority than cur, check whether we can migrate cur away.
- * (We have to do it indirectly, via _VPF_migrating, instead
+ * We have to do it indirectly, via _VPF_migrating (instead
  * of just tickling any idler suitable for cur) because cur
- * is running.)
+ * is running.
  *
  * If there are suitable idlers for new, no matter priorities,
  * leave cur alone (as it is running and is, likely, cache-hot)
@@ -435,9 +435,7 @@ static inline void __runq_tickle(struct csched_vcpu *new)
  */
 if ( new_idlers_empty && new->pri > cur->pri )
 {
-csched_balance_cpumask(cur->vcpu, balance_step,
-   cpumask_scratch_cpu(cpu));
-if ( cpumask_intersects(cpumask_scratch_cpu(cpu),
+if ( cpumask_intersects(cur->vcpu->cpu_hard_affinity,
 _mask) )
 {
 SCHED_VCPU_STAT_CRANK(cur, kicked_away);


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

[Xen-devel] [PATCH 05/24] xen: credit2: make tickling more deterministic

[Dario Faggioli]

Right now, the following scenario can occurr:
 - upon vcpu v wakeup, v itself is put in the runqueue,
   and pcpu X is tickled;
 - pcpu Y schedules (for whatever reason), sees v in
   the runqueue and picks it up.

This may seem ok (or even a good thing), but it's not.
In fact, if runq_tickle() decided X is where v should
run, it did it for a reason (load distribution, SMT
support, cache hotness, affinity, etc), and we really
should try as hard as possible to stick to that.

Of course, we can't be too strict, or we risk leaving
vcpus in the runqueue while there is available CPU
capacity. So, we only leave v in runqueue --for X to
pick it up-- if we see that X has been tickled and
has not scheduled yet, i.e., it will have a real chance
of actually select and schedule v.

If that is not the case, we schedule it on Y (or, at
least, we consider that), as running somewhere non-ideal
is better than not running at all.

The commit also adds performance counters for each of
the possible situations.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/common/sched_credit2.c   |   65 +++---
 xen/include/xen/perfc_defn.h |3 ++
 2 files changed, 64 insertions(+), 4 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 12dfd20..a3d7beb 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -54,6 +54,7 @@
 #define TRC_CSCHED2_LOAD_CHECK   TRC_SCHED_CLASS_EVT(CSCHED2, 16)
 #define TRC_CSCHED2_LOAD_BALANCE TRC_SCHED_CLASS_EVT(CSCHED2, 17)
 #define TRC_CSCHED2_PICKED_CPU   TRC_SCHED_CLASS_EVT(CSCHED2, 19)
+#define TRC_CSCHED2_RUNQ_CANDIDATE   TRC_SCHED_CLASS_EVT(CSCHED2, 20)
 
 /*
  * WARNING: This is still in an experimental phase.  Status and work can be 
found at the
@@ -398,6 +399,7 @@ struct csched2_vcpu {
 int credit;
 s_time_t start_time; /* When we were scheduled (used for credit) */
 unsigned flags;  /* 16 bits doesn't seem to play well with clear_bit() 
*/
+int tickled_cpu; /* cpu tickled for picking us up (-1 if none) */
 
 /* Individual contribution to load */
 s_time_t load_last_update;  /* Last time average was updated */
@@ -1049,6 +1051,10 @@ runq_tickle(const struct scheduler *ops, struct 
csched2_vcpu *new, s_time_t now)
 __cpumask_set_cpu(ipid, >tickled);
 smt_idle_mask_clear(ipid, >smt_idle);
 cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
+
+if ( unlikely(new->tickled_cpu != -1) )
+SCHED_STAT_CRANK(tickled_cpu_overwritten);
+new->tickled_cpu = ipid;
 }
 
 /*
@@ -1266,6 +1272,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
vcpu *vc, void *dd)
 ASSERT(svc->sdom != NULL);
 svc->credit = CSCHED2_CREDIT_INIT;
 svc->weight = svc->sdom->weight;
+svc->tickled_cpu = -1;
 /* Starting load of 50% */
 svc->avgload = 1ULL << (CSCHED2_PRIV(ops)->load_precision_shift - 1);
 svc->load_last_update = NOW() >> LOADAVG_GRANULARITY_SHIFT;
@@ -1273,6 +1280,7 @@ csched2_alloc_vdata(const struct scheduler *ops, struct 
vcpu *vc, void *dd)
 else
 {
 ASSERT(svc->sdom == NULL);
+svc->tickled_cpu = svc->vcpu->vcpu_id;
 svc->credit = CSCHED2_IDLE_CREDIT;
 svc->weight = 0;
 }
@@ -2233,7 +2241,8 @@ void __dump_execstate(void *unused);
 static struct csched2_vcpu *
 runq_candidate(struct csched2_runqueue_data *rqd,
struct csched2_vcpu *scurr,
-   int cpu, s_time_t now)
+   int cpu, s_time_t now,
+   unsigned int *pos)
 {
 struct list_head *iter;
 struct csched2_vcpu *snext = NULL;
@@ -2262,13 +2271,29 @@ runq_candidate(struct csched2_runqueue_data *rqd,
 
 /* Only consider vcpus that are allowed to run on this processor. */
 if ( !cpumask_test_cpu(cpu, svc->vcpu->cpu_hard_affinity) )
+{
+(*pos)++;
 continue;
+}
+
+/*
+ * If a vcpu is meant to be picked up by another processor, and such
+ * processor has not scheduled yet, leave it in the runqueue for him.
+ */
+if ( svc->tickled_cpu != -1 && svc->tickled_cpu != cpu &&
+ cpumask_test_cpu(svc->tickled_cpu, >tickled) )
+{
+(*pos)++;
+SCHED_STAT_CRANK(deferred_to_tickled_cpu);
+continue;
+}
 
 /* If this is on a different processor, don't pull it unless
  * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
 if ( svc->vcpu->processor != cpu
  && snext->credit + CSCHED2_MIGRATE_RESIST > svc->credit )
 {
+(*pos)++;
 SCHED_STAT_CRANK(migrate_resisted);
 continue;
 }
@@ -2280,9 +2305,26 @@ runq_candidate(struct 

[Xen-devel] [PATCH 04/24] xen: credit2: properly schedule migration of a running vcpu.

[Dario Faggioli]

If wanting to migrate a vcpu that is actually running,
we need to ask the scheduler to chime in as soon as
possible, to have the vcpu itself stopped and actually
moved.

Make sure this happens by, after setting all the relevant
flags, raising the scheduler softirq.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
---
 xen/common/sched_credit2.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index a5a744f..12dfd20 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -1667,6 +1667,7 @@ static void migrate(const struct scheduler *ops,
 svc->migrate_rqd = trqd;
 __set_bit(_VPF_migrating, >vcpu->pause_flags);
 __set_bit(__CSFLAG_runq_migrate_request, >flags);
+cpu_raise_softirq(svc->vcpu->processor, SCHEDULE_SOFTIRQ);
 SCHED_STAT_CRANK(migrate_requested);
 }
 else


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

[Xen-devel] [PATCH 03/24] xen: credit1: return the 'time remaining to the limit' as next timeslice.

[Dario Faggioli]

If vcpu x has run for 200us, and sched_ratelimit_us is
1000us, continue running x _but_ return 1000us-200us as
the next time slice. This way, next scheduling point will
happen in 800us, i.e., exactly at the point when x crosses
the threshold, and can be descheduled (if appropriate).

Right now (without this patch), we're always returning
sched_ratelimit_us (1000us, in the example above), which
means we're (potentially) allowing x to run more than
it should have been able to (even when considering rate
limiting into account).

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
---
 xen/common/sched_credit.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 3d4f223..3f439a0 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -1782,7 +1782,7 @@ csched_schedule(
 snext = scurr;
 snext->start_time += now;
 perfc_incr(delay_ms);
-tslice = MICROSECS(prv->ratelimit_us);
+tslice = MICROSECS(prv->ratelimit_us) - runtime;
 ret.migrated = 0;
 goto out;
 }


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

[Xen-devel] [PATCH 02/24] xen: credit1: fix mask to be used for tickling in Credit1

[Dario Faggioli]

If there are idle pcpus inside the waking vcpu's
soft-affinity mask, we should really tickle one
of them (this is one of the purposes of the
__runq_tickle() function itself!), not just
any idle pcpu.

The issue has been introduced in 02ea5031825d
("credit1: properly deal with pCPUs not in any cpupool"),
where the usage of idle_mask is changed, without
updating the bottom of the function, where it
is also referenced.

Signed-off-by: Dario Faggioli 
---
Cc: George Dunlap 
Cc: Anshul Makkar 
Cc: David Vrabel 
---
David, a while ago you asked what could have been that was causing awful
results for Credit1, for CPU bound workloads, in the overloaded scenario of one
of my benchmarks. I think the bug fixed either here or in next patch (but I'd
be rather sure it's this one) is where the problem was. :-)
---
 xen/common/sched_credit.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
index 6eccf09..3d4f223 100644
--- a/xen/common/sched_credit.c
+++ b/xen/common/sched_credit.c
@@ -454,11 +454,12 @@ static inline void __runq_tickle(struct csched_vcpu *new)
 if ( opt_tickle_one_idle )
 {
 this_cpu(last_tickle_cpu) =
-cpumask_cycle(this_cpu(last_tickle_cpu), _mask);
+cpumask_cycle(this_cpu(last_tickle_cpu),
+  cpumask_scratch_cpu(cpu));
 __cpumask_set_cpu(this_cpu(last_tickle_cpu), );
 }
 else
-cpumask_or(, , _mask);
+cpumask_or(, , cpumask_scratch_cpu(cpu));
 }
 
 /* Did we find anyone? */


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

[Xen-devel] [PATCH 00/24] sched: Credit1 and Credit2 improvements... and soft-affinity for Credit2!

[Dario Faggioli]

Hi everyone,

Here's another rather big scheduler-related series. The most of the content (as
usual, lately) is about Credit2, but there are other things, about tracing and
also about Credit1. In fact, this patch series introduces soft-affinity support
for Credit2.

The first 3 patches are indeed bugfixes and performance enhancements for
Credit1. I discovered them while comparing performance and behavior of the two
schedulers, Credit1 and Credit2. In particular, running a Xen build (first
column, lower==>better) and iperf from the VMs to the host (second column,
higher==>better) within 2 8 vCPUs VMs, concurrently, on a 16 vCPUs host,
without (first line) or with (second line) some other load in the system (i.e.,
12 dom0 vCPUs kept artificially busy), produced the following results:

 CREDIT1MAKEXEN IPERF
---
 baseline : 28.772  11.354 | (no dom0 load)
 patched  : 28.602+ 11.416+|
---|
 baseline : 52.852  10.995 | (with dom0 load)
 patched  : 43.788+ 10.405+|
---

 + marks the best results

So, the patch series improves the situation quite a bit, at least in CPU bound
workload (the Xen build) when running under overload. I suspect the
soft-affinity related bug in __runq_tickle() (fixed by patch 2) to be the
main responsible for this.

Patches 4 to 6 are improvements to Credit1, and patch 7 to both Credit1 and
Credit2.

Then, we find fixes for a few other random things, mostly about tracing, in
patches 8 - 11 (see individual descriptions), and some context switch ratelimit
enhancements (again for both Credit1 and Credit2, but mostly for Credit2), in
patches 12 - 15.

Afterwords, it comes the most important contribution, is the introduction of
the soft-affinity support in Credit2. This happens in steps --i.e., in patches
16 to 20. This approach of introducing the feature with such breakdown follows
what was discussed a while ago here. There's a lot of moving parts and, while
working on implementing this, and revisiting the discussion, I found the
suggestion from George toward this approach to still be a very good one.

Among the soft-affinity patches, 1 is just refactoring, 2 of them are rather
easy, as they sort of follow the same approach always used for implementing
soft-affinity (i.e., in Credit1), which is the two steps load balancing loop.
The 4th patch, the one that touches Credit2's load balancer, is the one that
likely deserves more attention. The basic idea in there is to integrate the
soft-affinity logic inside the Credit2 load balancing framework. I think I've
put enough info in the changelog, and don't want to clobber this spase with
that... But do feel free to ask.

The last 4 patches, still for Credit2, are optimizations, either wrt existing
code, or wrt new code introduced in this series. I've chosen to keep them
separate to make reviewing/understanding new code easier. In fact, although
they look pretty simple, the soft-affinity code was pretty complex already, and
even these simple optimization, if done all at once, would have made the
reviewer's life (unnecessary) tougher.

Numbers are quite good. Actually, they show a really nice picture, IMO. I want
to run more benchmarks, of course, but it looks like we're on the right path.
The benchmarks are the same as above. I'm using credit2_runqueue=socket as it's
proven (in quite a few other benchmarks that I'm not showing for brevity) the
best configuration, at least with my latest series applied (it's in staging
already).

 CREDIT2MAKEXEN IPERF
---
 baseline : 31.990  11.689 | (no dom0 load)
 patched  : 27.834+ 12.180+|
---|
 baseline : 44.628  10.329 | (with dom0 load)
 patched  : 40.272+ 10.904+|
---

 + marks the best results

So, patches are really really effective in this case. Now, what if we compare
unpatched and patched version of Credit1 and Credit2?  Here we are:

 UNPATCHED  MAKEXEN IPERF
---
 Credit1  : 28.772+ 11.354 | (no dom0 load)
 Credit2  : 31.990  11.689+|
---|
 Credit1  : 52.852  10.995+| (with dom0 load)
 Credit2  : 44.628+ 10.329 |
---

In this use case, the two VMs would fit each one in one node, and hence
soft-affinity can "make his magic", in Credit1 while in Credit2, without this
patch, there's no such thing, and hence Credit1, overall, wins the match. Yes,
Credit2 has an edge on IPERF in the 'no dom0 load' case, but result is very
tight anyway. And Credit1 also does bad in Xen build with load, but that's only
because of the bug.

 PATCHEDMAKEXEN IPERF
---
 Credit1  : 28.602  11.416 | (no dom0 load)
 Credit2  : 27.834+ 12.180+|
---|
 Credit1  : 43.788  10.405 | (with dom0 load)
 Credit2  : 40.272+ 10.904+|
---

OTOH, with this patch series in, i.e., with Credit2 also able to take advantage
of soft-affinity, the game changes. 

Re: [Xen-devel] [PATCH v1 6/9] livepatch: Initial ARM64 support.

[Julien Grall]

Hi Konrad,

On 15/08/16 16:17, Julien Grall wrote:

On 15/08/2016 01:07, Konrad Rzeszutek Wilk wrote:

+case R_AARCH64_ADR_PREL_PG_HI21:
+val = (val & ~0xfff) - ((u64)dest & ~0xfff);
+err = reloc_insn_imm(dest, val, 12, 21,
AARCH64_INSN_IMM_ADR);
+break;


Hmmm, I think we want to avoid the payload having
R_AARCH64_ADR_PREL_PG_HI21* relocations due to the erratum #843419 on
some Cortex-A53.

I haven't yet looked at how you build the payload, but this may also
affects the process to do it. I will give a look on it.


Actually, I am not sure I will have time to look at it during the next 
few weeks. Could you add a TODO for now?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

[Chris Patterson]

On Wed, Aug 17, 2016 at 10:29 AM, Jan Beulich  wrote:
 On 17.08.16 at 16:02,  wrote:
>> From: Chris Patterson 
>>
>> The uart generates an interrupt whenever the transmit holding register is
>> empty and UART_IER_ETHREI is set in UART_IER.  Currently, Xen's ns16550
>> driver does not currently mask this interrupt when transmit is stopped,
>> unlike other platforms such as Linux [1].
>>
>> Toggle UART_IER_ETHREI flag in the UART_IER according to the state dictated
>> by stop_tx and start_tx hooks.
>>
>> On the Tegra platform (forthcoming series), the reset via reading IIR does 
>> not
>> prevent re-assertion of THRE.  This causes Xen to hang in the interrupt
>> handler's while loop whenever there is no data to transmit.  This behavior 
>> (bug?)
>> is addressed by utilizing the start & stop tx hooks.
>
> Looks mostly okay from a technical pov, but there are a few minor
> (mostly style) issues.
>
>> [1] 
>> http://lxr.free-electrons.com/source/drivers/tty/serial/8250/8250_port.c?v=4.7#L1518
>
> I'd appreciate for such references to be to the canonical (i.e. Linus'es)
> tree.
>
>> @@ -813,6 +813,26 @@ static int __init ns16550_irq(struct serial_port *port)
>>  return ((uart->irq > 0) ? uart->irq : -1);
>>  }
>>
>> +static void ns16550_start_tx(struct serial_port *port)
>> +{
>> +struct ns16550 *uart = port->uart;
>> +unsigned int ier = ns_read_reg(uart, UART_IER);
>
> Please use u8 or unsigned char here, as is done elsewhere in the file.
>
>> +/* unmask transmit holding register empty interrupt if currently masked 
>> */
>
> Comment style: Upper case at the beginning; the full stop at the
> end has become optional recently.
>
>> +if (!(ier & UART_IER_ETHREI))
>
> Blanks missing inside the parentheses.
>
> Jan
>

ACK, will fix these in v2.  Thank you for the review.

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

Re: [Xen-devel] [PATCH v1 4/9] arm/mm: Introduce modify_xen_mappings

[Julien Grall]

Hi Konrad,

On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:

Which is only used by Livepatch code. The purpose behind
this call is to modify the page table entries flags.

Specifically the .ro and .nx flags. The current mechanism
puts cache attributes in the flags and the .ro and .nx are
locked down and assumed to be .ro=0, nx=1.

Livepatch needs .nx=0 and also .ro to be set to 1.

We introduce a new 'flags' where various bits determine
whether .ro and .nx bits are set or cleared. We can't use
an enum as the function prototype would diverge from x86.

Signed-off-by: Konrad Rzeszutek Wilk 
--
Cc: Ross Lagerwall 
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Andrew Cooper 
[Added as he wrote the x86 modify_xen_mappings version]

RFC: First submission.
v1: Add #defines to make it simpler to understand the bit-shifting.
---
 xen/arch/arm/mm.c  | 21 ++---
 xen/include/asm-arm/page.h | 11 +++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 4e256c2..520c0e0 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -836,6 +836,7 @@ static int create_xen_table(lpae_t *entry)
 enum xenmap_operation {
 INSERT,
 REMOVE,
+MODIFY,
 RESERVE
 };

@@ -881,14 +882,22 @@ static int create_xen_entries(enum xenmap_operation op,
 pte.pt.table = 1;
 write_pte([third_table_offset(addr)], pte);
 break;
+case MODIFY:
 case REMOVE:
 if ( !third[third_table_offset(addr)].pt.valid )
 {
-printk("create_xen_entries: trying to remove a non-existing 
mapping addr=%lx\n",
-   addr);
+printk("create_xen_entries: trying to %s a non-existing mapping 
addr=%lx\n",
+   op == REMOVE ? "remove" : "modify", addr);
 return -EINVAL;
 }
-pte.bits = 0;
+if ( op == REMOVE )
+pte.bits = 0;
+else
+{
+pte = third[third_table_offset(addr)];
+pte.pt.ro = PTE_RO_MASK(ai);
+pte.pt.xn = PTE_NX_MASK(ai);


I would like to see some sanity check for read-only and execute-never 
bit. For instance, ro = 0 and xn = 0 would lead to a crash later on 
because Xen is enabling SCTLR_EL2.WXN.


I think the other combinations should be fine.


+}
 write_pte([third_table_offset(addr)], pte);
 break;
 default:
@@ -922,6 +931,12 @@ void destroy_xen_mappings(unsigned long v, unsigned long e)
 create_xen_entries(REMOVE, v, 0, (e - v) >> PAGE_SHIFT, 0);
 }

+void modify_xen_mappings(unsigned long s, unsigned long e, unsigned int flags)


create_xen_entries may fail, don't you want to report the error to the 
caller?



+{
+ASSERT((flags & (PTE_NX | PTE_RO)) == flags);
+create_xen_entries(MODIFY, s, 0, (e - s) >> PAGE_SHIFT, flags);
+}
+
 enum mg { mg_clear, mg_ro, mg_rw, mg_rx };
 static void set_pte_flags_on_range(const char *p, unsigned long l, enum mg mg)
 {
diff --git a/xen/include/asm-arm/page.h b/xen/include/asm-arm/page.h
index 05d9f82..2f66740 100644
--- a/xen/include/asm-arm/page.h
+++ b/xen/include/asm-arm/page.h
@@ -66,6 +66,17 @@
 #define PAGE_HYPERVISOR_WC  (DEV_WC)

 /*
+ * Defines for changing the PTE .ro and .nx bits. This is only to be
+ * used with modify_xen_mappings.
+ */
+#define _PTE_NX_BIT 0U
+#define _PTE_RO_BIT 1U
+#define PTE_NX  (1U << _PTE_NX_BIT)
+#define PTE_RO  (1U << _PTE_RO_BIT)
+#define PTE_NX_MASK(x)  (((x) >> _PTE_NX_BIT) & 0x1U)
+#define PTE_RO_MASK(x)  (((x) >> _PTE_RO_BIT) & 0x1U)
+
+/*
  * Stage 2 Memory Type.
  *
  * These are valid in the MemAttr[3:0] field of an LPAE stage 2 page



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1 3/9] x86/arm64: Move the ALT_[ORIG|REPL]_PTR macros to header files.

[Julien Grall]

Hi Konrad,

On 15/08/16 00:07, Konrad Rzeszutek Wilk wrote:

That way common code can use the same macro to access
the most common attributes without much #ifdef.

Take advantage of it right away in the livepatch code.

Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: Stefano Stabellini 
Cc: Julien Grall 
Cc: Jan Beulich 
Cc: Andrew Cooper 

v1: First submission
---
 xen/arch/arm/alternative.c| 4 
 xen/common/livepatch.c| 4 ++--
 xen/include/asm-arm/alternative.h | 4 
 xen/include/asm-x86/alternative.h | 4 
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/alternative.c b/xen/arch/arm/alternative.c
index 8ee5a11..bf4101c 100644
--- a/xen/arch/arm/alternative.c
+++ b/xen/arch/arm/alternative.c
@@ -32,10 +32,6 @@
 #include 
 #include 

-#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
-#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
-#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
-
 extern const struct alt_instr __alt_instructions[], __alt_instructions_end[];

 struct alt_region {
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 3a22de2..9c45270 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -700,8 +700,8 @@ static int prepare_payload(struct payload *payload,

 for ( a = start; a < end; a++ )
 {
-const void *instr = >instr_offset + a->instr_offset;
-const void *replacement = >repl_offset + a->repl_offset;
+const void *instr = ALT_ORIG_PTR(a);
+const void *replacement = ALT_REPL_PTR(a);

 if ( (instr < region->start && instr >= region->end) ||
  (replacement < region->start && replacement >= region->end) )
diff --git a/xen/include/asm-arm/alternative.h 
b/xen/include/asm-arm/alternative.h
index 4287bac..58d5fa7 100644
--- a/xen/include/asm-arm/alternative.h
+++ b/xen/include/asm-arm/alternative.h
@@ -21,6 +21,10 @@ struct alt_instr {
u8  alt_len;/* size of new instruction(s), <= orig_len */
 };

+#define __ALT_PTR(a,f)  (u32 *)((void *)&(a)->f + (a)->f)
+#define ALT_ORIG_PTR(a) __ALT_PTR(a, orig_offset)
+#define ALT_REPL_PTR(a) __ALT_PTR(a, alt_offset)
+


alternative.h is a verbatim copy of the Linux one. So can you add a 
comment such as /* Xen: helpers used by the common code */?


Also this should be indented with hard tab as the file is following the 
Linux coding style.



 void __init apply_alternatives_all(void);
 int apply_alternatives(void *start, size_t length);

diff --git a/xen/include/asm-x86/alternative.h 
b/xen/include/asm-x86/alternative.h
index acaeded..b72c401 100644
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -23,6 +23,10 @@ struct alt_instr {
 u8  replacementlen; /* length of new instruction, <= instrlen */
 };

+#define __ALT_PTR(a,f)  (u8 *)((void *)&(a)->f + (a)->f)
+#define ALT_ORIG_PTR(a) __ALT_PTR(a, instr_offset)
+#define ALT_REPL_PTR(a) __ALT_PTR(a, repl_offset)
+
 extern void add_nops(void *insns, unsigned int len);
 /* Similar to apply_alternatives except it can be run with IRQs enabled. */
 extern void apply_alternatives_nocheck(struct alt_instr *start,



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 12/19] efi: introduce EFI_RS to ease control on runtime services usage

[Jan Beulich]

>>> On 06.08.16 at 01:04,  wrote:

Apart from the question of this probably better getting merged with
the previous patch ...

> --- a/xen/common/efi/boot.c
> +++ b/xen/common/efi/boot.c
> @@ -936,6 +936,10 @@ efi_start(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE 
> *SystemTable)
>  
>  __set_bit(EFI_BOOT, );
>  
> +#ifndef CONFIG_ARM /* Disabled until runtime services implemented. */
> +__set_bit(EFI_RS, );
> +#endif

... this needs to be paralleled by a __clear_bit() when "efi=no-rs"
was given (and then efi_rs_enable) should go away. Oh, looks
like that's the next patch, but I'd then again question the split.

> --- a/xen/include/xen/efi.h
> +++ b/xen/include/xen/efi.h
> @@ -12,6 +12,7 @@
>  struct efi {
>  unsigned long flags;/* Bit fields representing available EFI 
> features/properties */
>  #define EFI_BOOT 0   /* Were we booted from EFI? */
> +#define EFI_RS   2   /* Can we use runtime services? */

Why is this not the sequentially next number?

Jan


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  336d7239f8a703594f00e0d25ce0d1831f802952
baseline version:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a

Last test of basis   100515  2016-08-16 14:03:06 Z1 days
Testing same since   100535  2016-08-17 14:07:14 Z0 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  Jan Beulich 
  Lars Kurth 

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

Re: [Xen-devel] [PATCH v4 11/19] efi: create efi_enabled()

[Jan Beulich]

>>> On 06.08.16 at 01:04,  wrote:
> --- a/xen/arch/x86/domain_page.c
> +++ b/xen/arch/x86/domain_page.c
> @@ -36,7 +36,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
>   * domain's page tables but current may point at another domain's VCPU.
>   * Return NULL as though current is not properly set up yet.
>   */
> -if ( efi_enabled && efi_rs_using_pgtables() )
> +if ( efi_enabled(EFI_BOOT) && efi_rs_using_pgtables() )

This looks like it'll need to change again when you introduce EFI_RS.
What's wrong with introducing all three flags right away, to avoid
touching places like this multiple times?

> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -438,8 +438,8 @@ static void __init parse_video_info(void)
>  {
>  struct boot_video_info *bvi = (boot_vid_info);
>  
> -/* The EFI loader fills vga_console_info directly. */
> -if ( efi_enabled )
> +/* vga_console_info is filled directly on EFI platform. */
> +if ( efi_enabled(EFI_BOOT) )

Along the lines of the above - wouldn't this then also become
EFI_LOADER? I.e. another place needing to change multiple times?
And there are more below.

> @@ -40,6 +41,12 @@ int efi_runtime_call(struct xenpf_efi_runtime_call *);
>  int efi_compat_get_info(uint32_t idx, union compat_pf_efi_info *);
>  int efi_compat_runtime_call(struct compat_pf_efi_runtime_call *);
>  
> +/* Test whether the above defined EFI_* bits are enabled. */
> +static inline unsigned int efi_enabled(int feature)
> +{
> +return !!test_bit(feature, );
> +}

Why is this returning unsigned int, yet its argument plain int? Note that
we have proper bool now, so by making it return bool you won't even
need the !! anymore.

Jan


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

Re: [Xen-devel] [PATCH v4 10/19] efi: move efi struct initialization to xen/common/lib.c

[Jan Beulich]

>>> On 06.08.16 at 01:04,  wrote:
> A subsequent patch adds efi struct flags member which is used
> during runtime to differentiate between legacy BIOS and EFI
> platforms and multiboot2 and EFI native loader. So, efi symbol
> have to proper representation in ELF and PE Xen image. Hence,
> move efi struct initialization to xen/common/lib.c and remove
> efi symbol from ld script.
> 
> Signed-off-by: Daniel Kiper 
> ---
> v4 - suggestions/fixes:
>- move efi struct initialization to xen/common/lib.c
>  and drop one from xen/arch/x86/efi/stub.c
>  (suggested by Jan Beulich),

I recall I didn't like where you placed it last time round. I've just tried
to locate the old thread, but going back a whole year in the list archives
I was not able to find a mail with the title containing "move efi". Hence I
can only say what I think now, without reference to earlier remarks:
The struct currently isn't overly large, but I still don't see why non-EFI
builds need to include it instead of just the flags variable you mean to
introduce subsequently. And it's even less obvious what use it is on
platforms not even supporting EFI, i.e. ARM32.

> --- a/xen/common/lib.c
> +++ b/xen/common/lib.c
> @@ -1,4 +1,4 @@
> -
> +#include 
>  #include 
>  #include 
>  #include 

At least the visible section here is nicely sorted alphabetically, and I
don't think xen/efi.h absolutely needs to go first.

Jan


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

Re: [Xen-devel] [PATCH v4 09/19] x86: add multiboot2 protocol support

[Jan Beulich]

>>> On 06.08.16 at 01:04,  wrote:
> @@ -106,3 +121,119 @@ multiboot_info_t __stdcall *reloc(u32 mbi_in, u32 
> trampoline)
>  
>  return mbi_out;
>  }
> +
> +static multiboot_info_t *mbi2_mbi(u32 mbi_in)
> +{
> +const multiboot2_memory_map_t *mmap_src;
> +const multiboot2_tag_t *tag;
> +/* Do not complain that mbi_out_mods is not initialized. */
> +module_t *mbi_out_mods = NULL;

Please drop the comment.

> +memory_map_t *mmap_dst;
> +multiboot_info_t *mbi_out;
> +u32 ptr;
> +unsigned int i, mod_idx = 0;
> +
> +ptr = alloc_mem(sizeof(*mbi_out));
> +mbi_out = (multiboot_info_t *)ptr;
> +zero_mem(ptr, sizeof(*mbi_out));
> +
> +/* Skip Multiboot2 information fixed part. */
> +ptr = ALIGN_UP(mbi_in + sizeof(multiboot2_fixed_t), 
> MULTIBOOT2_TAG_ALIGN);
> +
> +/* Get the number of modules. */
> +for ( tag = (multiboot2_tag_t *)ptr;
> +  (u32)tag - mbi_in < ((multiboot2_fixed_t *)mbi_in)->total_size;
> +  tag = (multiboot2_tag_t *)ALIGN_UP((u32)tag + tag->size, 
> MULTIBOOT2_TAG_ALIGN) )

There's still a lot of casting here, but I agree it's not straightforward
to improve the situation.

> +if ( tag->type == MULTIBOOT2_TAG_TYPE_MODULE )
> +++mbi_out->mods_count;
> +else if ( tag->type == MULTIBOOT2_TAG_TYPE_END )
> +break;
> +
> +if ( mbi_out->mods_count )
> +{
> +mbi_out->flags = MBI_MODULES;
> +mbi_out->mods_addr = alloc_mem(mbi_out->mods_count * 
> sizeof(module_t));
> +mbi_out_mods = (module_t *)mbi_out->mods_addr;
> +}
> +
> +/* Skip Multiboot2 information fixed part. */
> +ptr = ALIGN_UP(mbi_in + sizeof(multiboot2_fixed_t), 
> MULTIBOOT2_TAG_ALIGN);
> +
> +/* Put all needed data into mbi_out. */
> +for ( tag = (multiboot2_tag_t *)ptr;
> +  (u32)tag - mbi_in < ((multiboot2_fixed_t *)mbi_in)->total_size;
> +  tag = (multiboot2_tag_t *)ALIGN_UP((u32)tag + tag->size, 
> MULTIBOOT2_TAG_ALIGN) )
> +switch ( tag->type )
> +{
> +case MULTIBOOT2_TAG_TYPE_BOOT_LOADER_NAME:
> +mbi_out->flags |= MBI_LOADERNAME;
> +ptr = get_mb2_string(tag, string, string);
> +mbi_out->boot_loader_name = copy_string(ptr);
> +break;
> +
> +case MULTIBOOT2_TAG_TYPE_CMDLINE:
> +mbi_out->flags |= MBI_CMDLINE;
> +ptr = get_mb2_string(tag, string, string);
> +mbi_out->cmdline = copy_string(ptr);
> +break;
> +
> +case MULTIBOOT2_TAG_TYPE_BASIC_MEMINFO:
> +mbi_out->flags |= MBI_MEMLIMITS;
> +mbi_out->mem_lower = get_mb2_data(tag, basic_meminfo, mem_lower);
> +mbi_out->mem_upper = get_mb2_data(tag, basic_meminfo, mem_upper);
> +break;
> +
> +case MULTIBOOT2_TAG_TYPE_MMAP:
> +mbi_out->flags |= MBI_MEMMAP;
> +mbi_out->mmap_length = get_mb2_data(tag, mmap, size);
> +mbi_out->mmap_length -= sizeof(multiboot2_tag_mmap_t);
> +mbi_out->mmap_length /= get_mb2_data(tag, mmap, entry_size);

Okay, here you use the entry size as provided by grub, allowing
compatibility even when the boot loader uses a newer layout (with
extra fields added to the end). However ...

> +mbi_out->mmap_length *= sizeof(memory_map_t);
> +
> +mbi_out->mmap_addr = alloc_mem(mbi_out->mmap_length);
> +
> +mmap_src = get_mb2_data(tag, mmap, entries);
> +mmap_dst = (memory_map_t *)mbi_out->mmap_addr;
> +
> +for ( i = 0; i < mbi_out->mmap_length / sizeof(memory_map_t); 
> i++ )
> +{
> +/* Init size member properly. */
> +mmap_dst[i].size = sizeof(memory_map_t);
> +mmap_dst[i].size -= sizeof(((memory_map_t){0}).size);
> +/* Now copy a given region data. */
> +mmap_dst[i].base_addr_low = (u32)mmap_src[i].addr;
> +mmap_dst[i].base_addr_high = (u32)(mmap_src[i].addr >> 32);
> +mmap_dst[i].length_low = (u32)mmap_src[i].len;
> +mmap_dst[i].length_high = (u32)(mmap_src[i].len >> 32);

... here you index an array of type multiboot2_memory_map_t.

Also note that in any event you should check that
entry_size >= sizeof(*mmap_src) (or, if you don't want [or need]
to go with the flexible model, ==).

> +typedef struct {
> +u32 type;
> +u32 size;
> +char string[0];

This is not a public header - please omit the 0 here and in a similar
place further down, as we're using all sorts of gcc extensions anyway.

Jan

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

[Xen-devel] [xen-4.5-testing baseline-only test] 67545: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemuu-rhel6hvm-amd 14 leak-check/checkfail REGR. vs. 66944
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install fail REGR. vs. 66944

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 66944
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 66944
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 66944
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail like 66944

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

version targeted for testing:
 xen  2ad058efbbe42035784d8b32b53e7708b05cf94c
baseline version:
 xen  08313b45bfc75fa4cbadb9d25a0561e5f5b2fee6

Last test of basis66944  2016-08-09 03:19:17 Z8 days
Testing same since67545  2016-08-17 00:48:45 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anil Madhavapeddy 
  Anthony PERARD 
  Bob Liu 
  Boris Ostrovsky 
  Daniel De Graaf 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Jason Andryuk 
  Juergen Gross 
  Konrad Rzeszutek Wilk 
  Marek Marczykowski-Górecki 
  Matthew Daley 
  Olaf Hering 
  Roger Pau Monne 
  Wei Liu 

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-qemuu-nested-amd 

[Xen-devel] [PATCH net-next] xen-netback: create a debugfs node for hash information

[Paul Durrant]

It is useful to be able to see the hash configuration when running tests.
This patch adds a debugfs node for that purpose.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---
 drivers/net/xen-netback/common.h |  4 +++
 drivers/net/xen-netback/hash.c   | 68 
 drivers/net/xen-netback/xenbus.c | 37 --
 3 files changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 84d6cbd..3a56268 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -412,4 +412,8 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, 
u32 len,
 
 void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
 
+#ifdef CONFIG_DEBUG_FS
+void xenvif_dump_hash_info(struct xenvif *vif, struct seq_file *m);
+#endif
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
index fb87cb3..282b16d 100644
--- a/drivers/net/xen-netback/hash.c
+++ b/drivers/net/xen-netback/hash.c
@@ -369,6 +369,74 @@ u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, 
u32 len,
return XEN_NETIF_CTRL_STATUS_SUCCESS;
 }
 
+#ifdef CONFIG_DEBUG_FS
+void xenvif_dump_hash_info(struct xenvif *vif, struct seq_file *m)
+{
+   unsigned int i;
+
+   switch (vif->hash.alg) {
+   case XEN_NETIF_CTRL_HASH_ALGORITHM_TOEPLITZ:
+   seq_puts(m, "Hash Algorithm: TOEPLITZ\n");
+   break;
+
+   case XEN_NETIF_CTRL_HASH_ALGORITHM_NONE:
+   seq_puts(m, "Hash Algorithm: NONE\n");
+   /* FALLTHRU */
+   default:
+   return;
+   }
+
+   if (vif->hash.flags) {
+   seq_puts(m, "\nHash Flags:\n");
+
+   if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV4)
+   seq_puts(m, "- IPv4\n");
+   if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP)
+   seq_puts(m, "- IPv4 + TCP\n");
+   if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV6)
+   seq_puts(m, "- IPv6\n");
+   if (vif->hash.flags & XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP)
+   seq_puts(m, "- IPv6 + TCP\n");
+   }
+
+   seq_puts(m, "\nHash Key:\n");
+
+   for (i = 0; i < XEN_NETBK_MAX_HASH_KEY_SIZE; ) {
+   unsigned int j, n;
+
+   n = 8;
+   if (i + n >= XEN_NETBK_MAX_HASH_KEY_SIZE)
+   n = XEN_NETBK_MAX_HASH_KEY_SIZE - i;
+
+   seq_printf(m, "[%2u - %2u]: ", i, i + n - 1);
+
+   for (j = 0; j < n; j++, i++)
+   seq_printf(m, "%02x ", vif->hash.key[i]);
+
+   seq_puts(m, "\n");
+   }
+
+   if (vif->hash.size != 0) {
+   seq_puts(m, "\nHash Mapping:\n");
+
+   for (i = 0; i < vif->hash.size; ) {
+   unsigned int j, n;
+
+   n = 8;
+   if (i + n >= vif->hash.size)
+   n = vif->hash.size - i;
+
+   seq_printf(m, "[%4u - %4u]: ", i, i + n - 1);
+
+   for (j = 0; j < n; j++, i++)
+   seq_printf(m, "%4u ", vif->hash.mapping[i]);
+
+   seq_puts(m, "\n");
+   }
+   }
+}
+#endif /* CONFIG_DEBUG_FS */
+
 void xenvif_init_hash(struct xenvif *vif)
 {
if (xenvif_hash_cache_size == 0)
diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c
index 6a31f26..bacf6e0 100644
--- a/drivers/net/xen-netback/xenbus.c
+++ b/drivers/net/xen-netback/xenbus.c
@@ -165,7 +165,7 @@ xenvif_write_io_ring(struct file *filp, const char __user 
*buf, size_t count,
return count;
 }
 
-static int xenvif_dump_open(struct inode *inode, struct file *filp)
+static int xenvif_io_ring_open(struct inode *inode, struct file *filp)
 {
int ret;
void *queue = NULL;
@@ -179,13 +179,35 @@ static int xenvif_dump_open(struct inode *inode, struct 
file *filp)
 
 static const struct file_operations xenvif_dbg_io_ring_ops_fops = {
.owner = THIS_MODULE,
-   .open = xenvif_dump_open,
+   .open = xenvif_io_ring_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
.write = xenvif_write_io_ring,
 };
 
+static int xenvif_read_ctrl(struct seq_file *m, void *v)
+{
+   struct xenvif *vif = m->private;
+
+   xenvif_dump_hash_info(vif, m);
+
+   return 0;
+}
+
+static int xenvif_ctrl_open(struct inode *inode, struct file *filp)
+{
+   return single_open(filp, xenvif_read_ctrl, inode->i_private);
+}
+
+static const struct file_operations xenvif_dbg_ctrl_ops_fops = {
+   .owner = THIS_MODULE,
+   .open = xenvif_ctrl_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+

Re: [Xen-devel] [PATCH v3 36/38] altp2m: Allow specifying external-only use-case

[Daniel De Graaf]

On 08/16/2016 06:17 PM, Sergej Proskurin wrote:

From: Tamas K Lengyel 

Currently setting altp2mhvm=1 in the domain configuration allows access to the
altp2m interface for both in-guest and external privileged tools. This poses
a problem for use-cases where only external access should be allowed, requiring
the user to compile Xen with XSM enabled to be able to appropriately restrict
access.

In this patch we deprecate the altp2mhvm domain configuration option and
introduce the altp2m option, which allows specifying if by default the altp2m
interface should be external-only. The information is stored in
HVM_PARAM_ALTP2M which we now define with specific XEN_ALTP2M_* modes.
If external_only mode is selected, the XSM check is shifted to use XSM_DM_PRIV
type check, thus restricting access to the interface by the guest itself. Note
that we keep the default XSM policy untouched. Users of XSM who wish to enforce
external_only mode for altp2m can do so by adjusting their XSM policy directly,
as this domain config option does not override an active XSM policy.

Also, as part of this patch we adjust the hvmop handler to require
HVM_PARAM_ALTP2M to be of a type other then disabled for all ops. This has been
previously only required for get/set altp2m domain state, all other options
were gated on altp2m_enabled. Since altp2m_enabled only gets set during set
altp2m domain state, this change introduces no new requirements to the other
ops but makes it more clear that it is required for all ops.

Signed-off-by: Tamas K Lengyel 
Signed-off-by: Sergej Proskurin 


Acked-by: Daniel De Graaf 

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

[Xen-devel] [PATCH 0/2] tools/libs: don't use alloca(3)

[Wei Liu]

Wei Liu (2):
  libs/gnttab: do not use alloca(3)
  libs/foreignmemory: do not use alloca(3)

 tools/libs/foreignmemory/linux.c | 21 +++--
 tools/libs/gnttab/linux.c| 19 ++-
 2 files changed, 13 insertions(+), 27 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/2] libs/foreignmemory: do not use alloca(3)

[Wei Liu]

The semantics of alloca(3) is not very nice. If the stack overflows,
program behaviour is undefined.

Remove the use of alloca(3) and always use mmap.

Signed-off-by: Wei Liu 
---
 tools/libs/foreignmemory/linux.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 423c744..316d988 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -17,7 +17,6 @@
  * Copyright 2006 Sun Microsystems, Inc.  All rights reserved.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -187,18 +186,13 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 xen_pfn_t *pfn;
 unsigned int pfn_arr_size = ROUNDUP((num * sizeof(*pfn)), PAGE_SHIFT);
 
-if ( pfn_arr_size <= PAGE_SIZE )
-pfn = alloca(num * sizeof(*pfn));
-else
+pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+if ( pfn == MAP_FAILED )
 {
-pfn = mmap(NULL, pfn_arr_size, PROT_READ | PROT_WRITE,
-   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
-if ( pfn == MAP_FAILED )
-{
-PERROR("mmap of pfn array failed");
-(void)munmap(addr, num << PAGE_SHIFT);
-return NULL;
-}
+PERROR("mmap of pfn array failed");
+(void)munmap(addr, num << PAGE_SHIFT);
+return NULL;
 }
 
 memcpy(pfn, arr, num * sizeof(*arr));
@@ -241,8 +235,7 @@ void *osdep_xenforeignmemory_map(xenforeignmemory_handle 
*fmem,
 break;
 }
 
-if ( pfn_arr_size > PAGE_SIZE )
-munmap(pfn, pfn_arr_size);
+munmap(pfn, pfn_arr_size);
 
 if ( rc == -ENOENT && i == num )
 rc = 0;
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] libs/gnttab: do not use alloca(3)

[Wei Liu]

The semantics of alloca(3) is not very nice. If the stack overflows,
program behaviour is undefined.

Remove the use of alloca(3) and always use mmap.

Signed-off-by: Wei Liu 
---
 tools/libs/gnttab/linux.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/tools/libs/gnttab/linux.c b/tools/libs/gnttab/linux.c
index 7b0fba4..535ce34 100644
--- a/tools/libs/gnttab/linux.c
+++ b/tools/libs/gnttab/linux.c
@@ -102,18 +102,12 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt,
 if (flags & XENGNTTAB_GRANT_MAP_SINGLE_DOMAIN)
 domids_stride = 0;
 
-if ( map_size <= PAGE_SIZE )
-map = alloca(sizeof(*map) +
- (count - 1) * sizeof(struct ioctl_gntdev_map_grant_ref));
-else
+map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
+   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
+if ( map == MAP_FAILED )
 {
-map = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
-   MAP_PRIVATE | MAP_ANON | MAP_POPULATE, -1, 0);
-if ( map == MAP_FAILED )
-{
-GTERROR(xgt->logger, "mmap of map failed");
-return NULL;
-}
+GTERROR(xgt->logger, "mmap of map failed");
+return NULL;
 }
 
 for ( i = 0; i < count; i++ )
@@ -187,8 +181,7 @@ void *osdep_gnttab_grant_map(xengnttab_handle *xgt,
 }
 
  out:
-if ( map_size > PAGE_SIZE )
-munmap(map, map_size);
+munmap(map, map_size);
 
 return addr;
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

[Jan Beulich]

>>> On 17.08.16 at 16:02,  wrote:
> From: Chris Patterson 
> 
> The uart generates an interrupt whenever the transmit holding register is
> empty and UART_IER_ETHREI is set in UART_IER.  Currently, Xen's ns16550
> driver does not currently mask this interrupt when transmit is stopped,
> unlike other platforms such as Linux [1].
> 
> Toggle UART_IER_ETHREI flag in the UART_IER according to the state dictated
> by stop_tx and start_tx hooks.
> 
> On the Tegra platform (forthcoming series), the reset via reading IIR does not
> prevent re-assertion of THRE.  This causes Xen to hang in the interrupt
> handler's while loop whenever there is no data to transmit.  This behavior 
> (bug?)
> is addressed by utilizing the start & stop tx hooks.

Looks mostly okay from a technical pov, but there are a few minor
(mostly style) issues.

> [1] 
> http://lxr.free-electrons.com/source/drivers/tty/serial/8250/8250_port.c?v=4.7#L1518

I'd appreciate for such references to be to the canonical (i.e. Linus'es)
tree.

> @@ -813,6 +813,26 @@ static int __init ns16550_irq(struct serial_port *port)
>  return ((uart->irq > 0) ? uart->irq : -1);
>  }
>  
> +static void ns16550_start_tx(struct serial_port *port)
> +{
> +struct ns16550 *uart = port->uart;
> +unsigned int ier = ns_read_reg(uart, UART_IER);

Please use u8 or unsigned char here, as is done elsewhere in the file.

> +/* unmask transmit holding register empty interrupt if currently masked 
> */

Comment style: Upper case at the beginning; the full stop at the
end has become optional recently.

> +if (!(ier & UART_IER_ETHREI))

Blanks missing inside the parentheses.

Jan


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

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

[Wei Liu]

On Wed, Aug 17, 2016 at 04:25:44PM +0200, Juergen Gross wrote:
> On 17/08/16 16:13, Wei Liu wrote:
> > On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> >> Fix two issues discovered by coverity.
> > 
> > I would update the commit message to make it contain more information.
> > 
> > Fix two issues discovered by Coverity:
> > 
> > 1. properl mark one switch case as fall-through
> > 2. unroll a loop that only executes once
> > 
> > CID: 1369623
> > CID: 1019001
> 
> Do you want me to resend or could you do that when committing?
> 

I can do it.

I will wait for Samuel's ack.

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

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

[Juergen Gross]

On 17/08/16 16:13, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
>> Fix two issues discovered by coverity.
> 
> I would update the commit message to make it contain more information.
> 
> Fix two issues discovered by Coverity:
> 
> 1. properl mark one switch case as fall-through
> 2. unroll a loop that only executes once
> 
> CID: 1369623
> CID: 1019001

Do you want me to resend or could you do that when committing?

> 
> 
>>
>> Signed-off-by: Juergen Gross 
> 
> Reviewed-by: Wei Liu 

Thanks,

Juergen

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

Re: [Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

[Wei Liu]

On Wed, Aug 17, 2016 at 03:39:59PM +0200, Juergen Gross wrote:
> Fix two issues discovered by coverity.

I would update the commit message to make it contain more information.

Fix two issues discovered by Coverity:

1. properl mark one switch case as fall-through
2. unroll a loop that only executes once

CID: 1369623
CID: 1019001


> 
> Signed-off-by: Juergen Gross 

Reviewed-by: Wei Liu 

> ---
>  lib/printf.c | 25 +++--
>  1 file changed, 11 insertions(+), 14 deletions(-)
> 
> diff --git a/lib/printf.c b/lib/printf.c
> index ad6a304..f9e9d68 100644
> --- a/lib/printf.c
> +++ b/lib/printf.c
> @@ -379,6 +379,7 @@ reswitch:   switch (ch = (u_char)*fmt++) {
>  padc = '0';
>  goto reswitch;
>  }
> +/* fallthrough */
>  case '1': case '2': case '3': case '4':
>  case '5': case '6': case '7': case '8': case '9':
>  for (n = 0;; ++fmt) {
> @@ -966,20 +967,16 @@ literal:
>  width = 1;
>  if (flags & SUPPRESS) {
>  size_t sum = 0;
> -for (;;) {
> -if ((n = inr) < width) {
> -sum += n;
> -width -= n;
> -inp += n;
> -if (sum == 0)
> -goto input_failure;
> -break;
> -} else {
> -sum += width;
> -inr -= width;
> -inp += width;
> -break;
> -}
> +if ((n = inr) < width) {
> +sum += n;
> +width -= n;
> +inp += n;
> +if (sum == 0)
> +goto input_failure;
> +} else {
> +sum += width;
> +inr -= width;
> +inp += width;
>  }
>  nread += sum;
>  } else {
> -- 
> 2.6.6
> 

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

[Xen-devel] [PATCH] ns16550: mask transmit holding register empty interrupt when tx is stopped

[Chris Patterson]

From: Chris Patterson 

The uart generates an interrupt whenever the transmit holding register is
empty and UART_IER_ETHREI is set in UART_IER.  Currently, Xen's ns16550
driver does not currently mask this interrupt when transmit is stopped,
unlike other platforms such as Linux [1].

Toggle UART_IER_ETHREI flag in the UART_IER according to the state dictated
by stop_tx and start_tx hooks.

On the Tegra platform (forthcoming series), the reset via reading IIR does not
prevent re-assertion of THRE.  This causes Xen to hang in the interrupt
handler's while loop whenever there is no data to transmit.  This behavior 
(bug?)
is addressed by utilizing the start & stop tx hooks.

This has been tested on various x86 PCs for any obvious signs of regressions.

[1] 
http://lxr.free-electrons.com/source/drivers/tty/serial/8250/8250_port.c?v=4.7#L1518

Signed-off-by: Chris Patterson 
---
 xen/drivers/char/ns16550.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c
index b2b5f56..cae7f1b 100644
--- a/xen/drivers/char/ns16550.c
+++ b/xen/drivers/char/ns16550.c
@@ -656,8 +656,8 @@ static void ns16550_setup_postirq(struct ns16550 *uart)
 ns_write_reg(uart,
  UART_MCR, UART_MCR_OUT2 | UART_MCR_DTR | UART_MCR_RTS);
 
-/* Enable receive and transmit interrupts. */
-ns_write_reg(uart, UART_IER, UART_IER_ERDAI | UART_IER_ETHREI);
+/* Enable receive interrupts. */
+ns_write_reg(uart, UART_IER, UART_IER_ERDAI);
 }
 
 if ( uart->irq >= 0 )
@@ -813,6 +813,26 @@ static int __init ns16550_irq(struct serial_port *port)
 return ((uart->irq > 0) ? uart->irq : -1);
 }
 
+static void ns16550_start_tx(struct serial_port *port)
+{
+struct ns16550 *uart = port->uart;
+unsigned int ier = ns_read_reg(uart, UART_IER);
+
+/* unmask transmit holding register empty interrupt if currently masked */
+if (!(ier & UART_IER_ETHREI))
+ns_write_reg(uart, UART_IER, ier | UART_IER_ETHREI);
+}
+
+static void ns16550_stop_tx(struct serial_port *port)
+{
+struct ns16550 *uart = port->uart;
+unsigned int ier = ns_read_reg(uart, UART_IER);
+
+/* mask off transmit holding register empty interrupt if currently 
unmasked */
+if (ier & UART_IER_ETHREI)
+ns_write_reg(uart, UART_IER, ier & ~UART_IER_ETHREI);
+}
+
 #ifdef CONFIG_ARM
 static const struct vuart_info *ns16550_vuart_info(struct serial_port *port)
 {
@@ -832,6 +852,8 @@ static struct uart_driver __read_mostly ns16550_driver = {
 .putc = ns16550_putc,
 .getc = ns16550_getc,
 .irq  = ns16550_irq,
+.start_tx = ns16550_start_tx,
+.stop_tx  = ns16550_stop_tx,
 #ifdef CONFIG_ARM
 .vuart_info   = ns16550_vuart_info,
 #endif
-- 
2.1.4


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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Wei Liu]

On Wed, Aug 17, 2016 at 03:03:44PM +0100, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote:
> > On 17/08/16 13:35, Wei Liu wrote:
> > > diff --git a/include/asm_macros.h b/include/asm_macros.h
> > > new file mode 100644
> > > index 000..15dd377
> > > --- /dev/null
> > > +++ b/include/asm_macros.h
> > > @@ -0,0 +1,36 @@
> > > +/*
> > > + * Macros for assembly files.
> > > + */
> > > +
> > > +#ifndef _ASM_MACRO_H_
> > > +#define _ASM_MACRO_H_
> > > +
> > > +#include 
> > 
> > This presumably should be , and a stub file
> > for ARM ?
> > 
> 
> Don't want to rearrange build system and directory hierarchy just yet.

Oops, I misunderstood. I think your suggestion on arch_asm_macros.h is
sensible.

Wei.

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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Wei Liu]

On Wed, Aug 17, 2016 at 03:01:07PM +0100, Andrew Cooper wrote:
> On 17/08/16 13:35, Wei Liu wrote:
> > diff --git a/include/asm_macros.h b/include/asm_macros.h
> > new file mode 100644
> > index 000..15dd377
> > --- /dev/null
> > +++ b/include/asm_macros.h
> > @@ -0,0 +1,36 @@
> > +/*
> > + * Macros for assembly files.
> > + */
> > +
> > +#ifndef _ASM_MACRO_H_
> > +#define _ASM_MACRO_H_
> > +
> > +#include 
> 
> This presumably should be , and a stub file
> for ARM ?
> 

Don't want to rearrange build system and directory hierarchy just yet.

Good point on ARM stub, though. I will add one for ARM.

Wei.

> ~Andrew

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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Andrew Cooper]

On 17/08/16 13:35, Wei Liu wrote:
> diff --git a/include/asm_macros.h b/include/asm_macros.h
> new file mode 100644
> index 000..15dd377
> --- /dev/null
> +++ b/include/asm_macros.h
> @@ -0,0 +1,36 @@
> +/*
> + * Macros for assembly files.
> + */
> +
> +#ifndef _ASM_MACRO_H_
> +#define _ASM_MACRO_H_
> +
> +#include 

This presumably should be , and a stub file
for ARM ?

~Andrew

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

Re: [Xen-devel] [Minios-devel] [MINIOS PATCH 3/4] x86: switch to use elfnote

[Juergen Gross]

On 17/08/16 14:35, Wei Liu wrote:
> Use the newer ELF note interface. The generated ELF notes results in
> equivalent configuration.
> 
> Also need to modify linker script to provide a note section.
> 
> Signed-off-by: Wei Liu 

Reviewed-by: Juergen Gross 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

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

version targeted for testing:
 qemuu5f0e775348082c355769a3df612e055abea61c06
baseline version:
 qemuuf3b9e787aee6ef7d216b616675db0f1c124da5e4

Last test of basis   100512  2016-08-16 09:06:33 Z1 days
Testing same since   100528  2016-08-17 07:58:34 Z0 days1 attempts


People who touched revisions under test:
  Chanho Park 
  Christian Borntraeger 
  Cornelia Huck 
  Daniel P. Berrange 
  Eduardo Habkost 
  Kevin Wolf 
  Marc-André Lureau 
  Max Reitz 
  Michal Privoznik 
  Peter Maydell 
  Peter Xu 
  Thomas Huth 

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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Andrew Cooper]

On 17/08/16 14:40, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
>> Hello,
>>
>> Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
>>> Ported from xtf.git.
>> What is xtf.git? Does it use the same BSD licencing?
>> To my knowledge this is coming from the linux kernel source.
> This:
> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=summary
>
> The official repository is not yet ready. That project is BSD licensed.
>
> Andrew, can you clarify whether you copied this from Linux by mistake?

This definitely isn't Linux.  Their version is unnecessarily complicated.

I wrote this code myself, but there are only so many ways of arranging
the construction of a legal note field in a readable way.

Arguably, my code actually looks closer to its FreeBSD equivalent than
Linux.

~Andrew

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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Wei Liu]

On Wed, Aug 17, 2016 at 02:40:09PM +0100, Wei Liu wrote:
> On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
> > Hello,
> > 
> > Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> > > Ported from xtf.git.
> > 
> > What is xtf.git? Does it use the same BSD licencing?
> > To my knowledge this is coming from the linux kernel source.
> 
> This:
> http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=summary
> 
> The official repository is not yet ready. That project is BSD licensed.
> 
> Andrew, can you clarify whether you copied this from Linux by mistake?
> 

Actually I think FreeBSD has similar construct in
i386/include/asmacros.h. We should be fine here.

Wei.

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

[Xen-devel] Ping: [PATCH v2 2/6] x86/time: correctly honor late clearing of TSC related feature flags

[Jan Beulich]

Ping?

>>> On 03.08.16 at 15:00,  wrote:
> As such clearing of flags may have an impact on the selected rendezvous
> function, handle such in a central place.
> 
> But don't allow such feature flags to be cleared during CPU hotplug:
> Platform and local system times may have diverged significantly by
> then, potentially causing noticably (even if only temporary) strange
> behavior. As we're anyway expecting only sufficiently similar CPUs to
> appear during hotplug, this shouldn't be introducing new limitations.
> 
> Reported-by: Joao Martins 
> Signed-off-by: Jan Beulich 
> Tested-by: Dario Faggioli 
> Tested-by: Joao Martins 
> 
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -1162,8 +1162,8 @@ static int mwait_idle_cpu_init(struct no
>   }
>  
>   if (state > 2 && !boot_cpu_has(X86_FEATURE_NONSTOP_TSC) &&
> - !pm_idle_save)
> - setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
> + !pm_idle_save && system_state < SYS_STATE_active)
> + clear_tsc_cap(X86_FEATURE_TSC_RELIABLE);
>  
>   cx = dev->states + dev->count;
>   cx->type = state;
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1353,6 +1353,24 @@ static void time_calibration(void *unuse
>   , 1);
>  }
>  
> +void __init clear_tsc_cap(unsigned int feature)
> +{
> +void (*rendezvous_fn)(void *) = time_calibration_std_rendezvous;
> +
> +if ( feature )
> +setup_clear_cpu_cap(feature);
> +
> +/* If we have constant-rate TSCs then scale factor can be shared. */
> +if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
> +{
> +/* If TSCs are not marked as 'reliable', re-sync during rendezvous. 
> */
> +if ( !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) )
> +rendezvous_fn = time_calibration_tsc_rendezvous;
> +}
> +
> +time_calibration_rendezvous_fn = rendezvous_fn;
> +}
> +
>  static struct {
>  s_time_t local_stime, master_stime;
>  } ap_bringup_ref;
> @@ -1478,7 +1496,7 @@ static int __init verify_tsc_reliability
>  {
>  printk("%s: TSC warp detected, disabling TSC_RELIABLE\n",
> __func__);
> -setup_clear_cpu_cap(X86_FEATURE_TSC_RELIABLE);
> +clear_tsc_cap(X86_FEATURE_TSC_RELIABLE);
>  }
>  }
>  
> @@ -1491,13 +1509,7 @@ int __init init_xen_time(void)
>  {
>  tsc_check_writability();
>  
> -/* If we have constant-rate TSCs then scale factor can be shared. */
> -if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
> -{
> -/* If TSCs are not marked as 'reliable', re-sync during rendezvous. 
> */
> -if ( !boot_cpu_has(X86_FEATURE_TSC_RELIABLE) )
> -time_calibration_rendezvous_fn = 
> time_calibration_tsc_rendezvous;
> -}
> +clear_tsc_cap(0);
>  
>  open_softirq(TIME_CALIBRATE_SOFTIRQ, local_time_calibration);
>  
> --- a/xen/include/asm-x86/time.h
> +++ b/xen/include/asm-x86/time.h
> @@ -70,6 +70,7 @@ void tsc_get_info(struct domain *d, uint
>  void force_update_vcpu_system_time(struct vcpu *v);
>  
>  int host_tsc_is_safe(void);
> +void clear_tsc_cap(unsigned int feature);
>  void cpuid_time_leaf(uint32_t sub_idx, uint32_t *eax, uint32_t *ebx,
>   uint32_t *ecx, uint32_t *edx);
>  




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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Wei Liu]

On Wed, Aug 17, 2016 at 02:56:00PM +0200, Samuel Thibault wrote:
> Hello,
> 
> Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> > Ported from xtf.git.
> 
> What is xtf.git? Does it use the same BSD licencing?
> To my knowledge this is coming from the linux kernel source.

This:
http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen-test-framework.git;a=summary

The official repository is not yet ready. That project is BSD licensed.

Andrew, can you clarify whether you copied this from Linux by mistake?

Wei.

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

[Xen-devel] Ping: Re: [PATCH] replace bogus -ENOSYS uses

[Jan Beulich]

>>> On 12.08.16 at 13:02,  wrote:

Ping:

 On 12.08.16 at 12:34,  wrote:
>> On 11/08/16 19:10, Andrew Cooper wrote:
>>> On 09/08/16 11:40, Jan Beulich wrote:
 --- a/xen/arch/x86/cpu/mtrr/main.c
 +++ b/xen/arch/x86/cpu/mtrr/main.c
 @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
printk(KERN_WARNING
   "mtrr: your processor doesn't support 
 write-combining\n");
 -  return -ENOSYS;
 +  return -EOPNOTSUPP;
>>> 
>>> Will this break the classic-xen MTRR code?  ISTR it was very picky, from
>>> the cpuid work.  Also, as some further cleanup, that printk should
>>> become a print-once.
>>> 
>>> The others look ok.
>> 
>> That does bring up a good general point though -- the return value is
>> part of the ABI.  Are you reasonably confident that none of the callers
>> will be confused when this return value changes?  If so, a note in the
>> commit message justifying this confidence would be helpful I think.
> 
> I don't think specific return values can be considered part of the
> ABI, or else we couldn't e.g. change the order in which certain
> checks get performed.
> 
> And then please also consider a hypothetical future hypervisor with
> the MTRR operations simply ripped out - that would return -ENOSYS
> or -EOPNOTSUPP then too, without a way for the caller to tell that
> more generic error condition from the more specific one here.

Does this address your concerns? I'm still hoping to get a formal
ack/nak on this one ...

Jan


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

[Xen-devel] [PATCH] mini-os: fix coverity issues in printf.c

[Juergen Gross]

Fix two issues discovered by coverity.

Signed-off-by: Juergen Gross 
---
 lib/printf.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/lib/printf.c b/lib/printf.c
index ad6a304..f9e9d68 100644
--- a/lib/printf.c
+++ b/lib/printf.c
@@ -379,6 +379,7 @@ reswitch:   switch (ch = (u_char)*fmt++) {
 padc = '0';
 goto reswitch;
 }
+/* fallthrough */
 case '1': case '2': case '3': case '4':
 case '5': case '6': case '7': case '8': case '9':
 for (n = 0;; ++fmt) {
@@ -966,20 +967,16 @@ literal:
 width = 1;
 if (flags & SUPPRESS) {
 size_t sum = 0;
-for (;;) {
-if ((n = inr) < width) {
-sum += n;
-width -= n;
-inp += n;
-if (sum == 0)
-goto input_failure;
-break;
-} else {
-sum += width;
-inr -= width;
-inp += width;
-break;
-}
+if ((n = inr) < width) {
+sum += n;
+width -= n;
+inp += n;
+if (sum == 0)
+goto input_failure;
+} else {
+sum += width;
+inr -= width;
+inp += width;
 }
 nread += sum;
 } else {
-- 
2.6.6


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

Re: [Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Samuel Thibault]

Hello,

Wei Liu, on Wed 17 Aug 2016 13:35:12 +0100, wrote:
> Ported from xtf.git.

What is xtf.git? Does it use the same BSD licencing?
To my knowledge this is coming from the linux kernel source.

> Signed-off-by: Wei Liu 
> ---
>  include/asm_macros.h | 36 
>  include/x86/asm_macros.h | 28 
>  2 files changed, 64 insertions(+)
>  create mode 100644 include/asm_macros.h
>  create mode 100644 include/x86/asm_macros.h
> 
> diff --git a/include/asm_macros.h b/include/asm_macros.h
> new file mode 100644
> index 000..15dd377
> --- /dev/null
> +++ b/include/asm_macros.h
> @@ -0,0 +1,36 @@
> +/*
> + * Macros for assembly files.
> + */
> +
> +#ifndef _ASM_MACRO_H_
> +#define _ASM_MACRO_H_
> +
> +#include 
> +
> +#ifdef __ASSEMBLY__
> +
> +#define ELFNOTE(name, type, desc)   \
> +.pushsection .note.name   ; \
> +.align 4  ; \
> +.long 2f - 1f   /* namesz */  ; \
> +.long 4f - 3f   /* descsz */  ; \
> +.long type  /* type   */  ; \
> +1:.asciz #name  /* name   */  ; \
> +2:.align 4; \
> +3:desc  /* desc   */  ; \
> +4:.align 4; \
> +.popsection
> +
> +#endif  /* __ASSEMBLY__ */
> +
> +#endif  /* _ASM_MACRO_H_ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> diff --git a/include/x86/asm_macros.h b/include/x86/asm_macros.h
> new file mode 100644
> index 000..e718e0b
> --- /dev/null
> +++ b/include/x86/asm_macros.h
> @@ -0,0 +1,28 @@
> +#ifndef _X86_ASM_MACRO_H_
> +#define _X86_ASM_MACRO_H_
> +
> +#ifdef  __ASSEMBLY__
> +# if defined(__x86_64__)
> +#  define _WORD .quad
> +# elif defined(__i386__)
> +#  define _WORD .long
> +# endif
> +#else
> +# if defined(__x86_64__)
> +#  define _WORD ".quad"
> +# elif defined(__i386__)
> +#  define _WORD ".long"
> +# endif
> +#endif
> +
> +#endif   /* _X86_ASM_MACRO_H_ */
> +
> +/*
> + * Local variables:
> + * mode: C
> + * c-file-style: "BSD"
> + * c-basic-offset: 4
> + * tab-width: 4
> + * indent-tabs-mode: nil
> + * End:
> + */
> -- 
> 2.1.4
> 

-- 
Samuel
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
(By Matt Welsh)

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

Re: [Xen-devel] [PATCH 9/9] x86/mtrr: use stdbool instead of int + define

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> --- a/xen/arch/x86/cpu/mtrr/generic.c
> +++ b/xen/arch/x86/cpu/mtrr/generic.c
> @@ -3,6 +3,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Is this really needed, with xen/types.h already including it?

> @@ -237,7 +238,7 @@ static void mtrr_wrmsr(unsigned int msr, uint64_t 
> msr_content)
>   * \param changed pointer which indicates whether the MTRR needed to be 
> changed
>   * \param msrwords pointer to the MSR values which the MSR should have
>   */
> -static void set_fixed_range(int msr, int * changed, unsigned int * msrwords)
> +static void set_fixed_range(int msr, bool * changed, unsigned int * msrwords)

Please drop the stray blanks while touching this.

> @@ -478,7 +479,7 @@ void mtrr_generic_set(unsigned int reg, unsigned long 
> base,
>   The base address of the region.
>   The size of the region. If this is 0 the region is disabled.
>   The type of the region.
> - If TRUE, do the change safely. If FALSE, safety measures should
> + If true, do the change safely. If false, safety measures should
>  be done externally.

Please drop this stale comment portion instead of adjusting it.

Jan


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 584fcb7de28b710dfcd4fbe8fe1d574c593f3009
baseline version:
 ovmf 490b048b5afec06b1c78e6723530dcebd8b21612

Last test of basis   100529  2016-08-17 08:15:21 Z0 days
Testing same since   100531  2016-08-17 11:43:50 Z0 days1 attempts


People who touched revisions under test:
  edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
  Gary Lin 
  Gary Lin [mailto:g...@suse.com]
  Wei, David 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH 8/9] x86/mtrr: drop unused func prototypes and struct

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> These weren't used so drop them.
> 
> Signed-off-by: Doug Goldstein 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 7/9] x86/mtrr: drop unused positive_have_wrcomb()

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> Unused function, gone.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Jan Beulich 

But perhaps worth getting folded into the one dropping have_wrcomb()
(the acks for both patches can be retained for the merged result).

Jan


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

Re: [Xen-devel] [PATCH 6/9] x86/mtrr: drop unused mtrr_ops struct

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> There are no users of the mtrr_ops struct or any of the callers on it so
> drop those.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 5/9] x86/mtrr: drop unused is_cpu() macro

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> --- a/xen/arch/x86/cpu/mtrr/generic.c
> +++ b/xen/arch/x86/cpu/mtrr/generic.c
> @@ -520,7 +520,7 @@ int mtrr_generic_validate_add_page(unsigned long base, 
> unsigned long size, unsig
>  
>   /*  For Intel PPro stepping <= 7, must be 4 MiB aligned 
>   and not touch 0x7000->0x7003 */
> - if (is_cpu(INTEL) && boot_cpu_data.x86 == 6 &&
> + if (boot_cpu_data.x86 == 6 &&
>   boot_cpu_data.x86_model == 1 &&
>   boot_cpu_data.x86_mask <= 7) {
>   if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {

Well, this check then was and is (a) wrong (regardless of the MTRR
flavor used the family/model/stepping check has to be CPU vendor
specific) and (b) dead code (we don't run on PPro-s anymore).
Please instead delete it altogether.

Jan


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

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

[osstest service owner]

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

Regressions :-(

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

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

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

version targeted for testing:
 xen  c4e7a67e3a109a3d507d2617b77017e40d59f04a
baseline version:
 xen  a55ad65d3a30d5b3a026a7481ce05f28065920f0

Last test of basis   100488  2016-08-15 01:58:52 Z2 days
Failing since100492  2016-08-15 10:43:55 Z2 days3 attempts
Testing same since   100518  2016-08-16 19:11:11 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

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 

Re: [Xen-devel] [PATCH 4/9] x86/mtrr: drop unnecessary use_intel() macro

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> The use_intel() macro always evaluates to true so don't bother using it.

Ah, here we go. But there are indentation issues again here.

Jan


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

Re: [Xen-devel] [PATCH 3/9] x86/mtrr: drop have_wrcomb() wrapper

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> The only call was always to the generic implementation.
> 
> Signed-off-by: Doug Goldstein 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [MINIOS PATCH 4/4] x86: use unified linker script

[Andrew Cooper]

On 17/08/16 13:35, Wei Liu wrote:
> diff --git a/arch/x86/minios-x86.lds.S b/arch/x86/minios-x86.lds.S
> new file mode 100644
> index 000..65650ab
> --- /dev/null
> +++ b/arch/x86/minios-x86.lds.S
> @@ -0,0 +1,133 @@
> +#if defined(__x86_64__)
> +
> +OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> +OUTPUT_ARCH(i386:x86-64)
> +
> +#elif defined(__i386__)
> +#undef i386
> +OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
> +OUTPUT_ARCH(i386)

While merging, it would be worth switching to the single-parameter form
of OUTPUT_FORMAT().  x86 does not exist in big-endian[1].

~Andrew

[1] despite what the OpenSSL authors might believe -
http://opensslrampage.org/post/83031733755/remove-support-for-big-endian-i386-and
or https://lwn.net/Articles/595697/

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

Re: [Xen-devel] [MINIOS PATCH 1/4] gitignore: ignore vim swap file

[Samuel Thibault]

Wei Liu, on Wed 17 Aug 2016 13:35:11 +0100, wrote:
> Signed-off-by: Wei Liu 

Reviewed-by: Samuel Thibault 

> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 1c655a0..f21cc46 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,6 +1,7 @@
>  *~
>  *.o
>  *.a
> +*.swp
>  include/list.h
>  mini-os
>  mini-os.gz
> -- 
> 2.1.4
> 

-- 
Samuel
Accroche-toi au terminal, j'enlève le shell...
 -+- nojhan -+-

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

Re: [Xen-devel] [PATCH 2/9] x86/mtrr: drop mtrr_if indirection

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> There can only ever be one mtrr_if now and that is the generic
> implementation

This is only true when taking into consideration that cpu_has_mtrr
is #define-d to 1 right now. I'm not sure that's actually a good
assumption (especially when think about running Xen itself
virtualized, or possibly adding a mode of operation where no MTRRs
are to be used). But if we want to keep it that way, then I'd suggest
this patch should include removing cpu_has_mtrr (which will then
show to the reviewers that the checks of mtrr_if against NULL
indeed are dead code.

> @@ -569,22 +561,19 @@ struct mtrr_value {
>  void __init mtrr_bp_init(void)
>  {
>   if (cpu_has_mtrr) {
> - mtrr_if = _mtrr_ops;
>   size_or_mask = ~((1ULL << (paddr_bits - PAGE_SHIFT)) - 1);
>   size_and_mask = ~size_or_mask & 0xf0ULL;
>   }
>  
> - if (mtrr_if) {
> - set_num_var_ranges();
> - init_table();
> - if (use_intel())
> - get_mtrr_state();
> - }
> +set_num_var_ranges();
> +init_table();
> +if (use_intel())
> +get_mtrr_state();
>  }

Please don't break indentation style.

> --- a/xen/arch/x86/cpu/mtrr/mtrr.h
> +++ b/xen/arch/x86/cpu/mtrr/mtrr.h
> @@ -63,8 +63,8 @@ extern void set_mtrr_ops(const struct mtrr_ops *);
>  extern u64 size_or_mask, size_and_mask;
>  extern const struct mtrr_ops *mtrr_if;
>  
> -#define is_cpu(vnd)  (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
> -#define use_intel()  (mtrr_if && mtrr_if->use_intel_if == 1)
> +#define is_cpu(vnd)  (X86_VENDOR_INTEL == X86_VENDOR_##vnd)
> +#define use_intel()  (1)

Is the latter really useful to keep then?

Jan


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

Re: [Xen-devel] [PATCH v3 31/38] altp2m: Introduce altp2m_switch_vcpu_altp2m_by_id

[Julien Grall]

On 17/08/16 13:37, Sergej Proskurin wrote:

On 08/17/2016 12:05 PM, Jan Beulich wrote:

On 17.08.16 at 00:17,  wrote:

 xen/arch/arm/altp2m.c| 32 
 xen/arch/x86/mm/altp2m.c |  6 ++
 xen/arch/x86/mm/p2m.c|  6 --
 xen/common/vm_event.c|  3 ++-
 xen/include/asm-arm/altp2m.h |  7 ---
 xen/include/asm-arm/p2m.h|  6 --
 xen/include/asm-x86/altp2m.h |  3 +++
 xen/include/asm-x86/p2m.h|  3 ---
 8 files changed, 47 insertions(+), 19 deletions(-)

The x86 parts of the change look really independent of the rest, so
you could have done yourself a favor by splitting this out, as then
the individual patches would each require separate acks rather than
the one patch here requiring an x86/mm one along with the ARM and
VM-event ones.

Jan



Ok, I will split the patch accordingly. Thank you.


I think it is worth to mention again that patches doing one logical 
thing (i.e moving code, renaming function) are easier to review compare 
to patch doing multiple one.


Regards,

--
Julien Grall

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

Re: [Xen-devel] [MINIOS PATCH 4/4] x86: use unified linker script

[Wei Liu]

On Wed, Aug 17, 2016 at 01:35:14PM +0100, Wei Liu wrote:
> There are only a few differences between i386 and x86-64 linker scripts.
> Unify them into one. Re-indent the file at the same time.
> 
> Construct a special rule in top-level directory to cope with the change.
> Ideally the build system should also be made more elegant, but
> overhauling the build system is out of scope of this patch.
> 
> Signed-off-by: Wei Liu 
[...]
> +/* newlib initialization functions */
> +#if defined(__x86_64__)
> +. = ALIGN(64 / 8);
> +#else /* __i386 __ */
> +. = ALIGN(64 / 8);

Oops, this should be 32 / 8.

Wei.

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

Re: [Xen-devel] Xen virtual IOMMU high level design doc

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Lan, Tianyu
> Sent: 17 August 2016 13:06
> To: Jan Beulich; Kevin Tian; Andrew Cooper; yang.zhang...@gmail.com; Jun
> Nakajima; Stefano Stabellini
> Cc: Anthony Perard; xuqu...@huawei.com; xen-
> de...@lists.xensource.com; Ian Jackson; Roger Pau Monne
> Subject: [Xen-devel] Xen virtual IOMMU high level design doc
> 
> Hi All:
>   The following is our Xen vIOMMU high level design for detail
> discussion. Please have a look. Very appreciate for your comments.
> This design doesn't cover changes when root port is moved to hypervisor.
> We may design it later.
> 
> 
> Content:
> ==
> =
> 1. Motivation of vIOMMU
>   1.1 Enable more than 255 vcpus
>   1.2 Support VFIO-based user space driver
>   1.3 Support guest Shared Virtual Memory (SVM)
> 2. Xen vIOMMU Architecture
>   2.1 2th level translation overview
>   2.2 Interrupt remapping overview
> 3. Xen hypervisor
>   3.1 New vIOMMU hypercall interface

Would it not have been better to build on the previously discussed (and mostly 
agreed) PV IOMMU interface? (See 
https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01428.html). An 
RFC implementation series was also posted 
(https://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01441.html).

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

Re: [Xen-devel] [PATCH v3 31/38] altp2m: Introduce altp2m_switch_vcpu_altp2m_by_id

[Sergej Proskurin]

Hi Jan,


On 08/17/2016 12:05 PM, Jan Beulich wrote:
 On 17.08.16 at 00:17,  wrote:
>>  xen/arch/arm/altp2m.c| 32 
>>  xen/arch/x86/mm/altp2m.c |  6 ++
>>  xen/arch/x86/mm/p2m.c|  6 --
>>  xen/common/vm_event.c|  3 ++-
>>  xen/include/asm-arm/altp2m.h |  7 ---
>>  xen/include/asm-arm/p2m.h|  6 --
>>  xen/include/asm-x86/altp2m.h |  3 +++
>>  xen/include/asm-x86/p2m.h|  3 ---
>>  8 files changed, 47 insertions(+), 19 deletions(-)
> The x86 parts of the change look really independent of the rest, so
> you could have done yourself a favor by splitting this out, as then
> the individual patches would each require separate acks rather than
> the one patch here requiring an x86/mm one along with the ARM and
> VM-event ones.
>
> Jan
>

Ok, I will split the patch accordingly. Thank you.

Best regards,
~Sergej

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

[Xen-devel] [MINIOS PATCH 0/4] x86: Use ELF notes and unfied linker script

[Wei Liu]

Wei Liu (4):
  gitignore: ignore vim swap file
  Introduce asm_macros.h
  x86: switch to use elfnote
  x86: use unified linker script

 .gitignore |   2 +
 Makefile   |   6 +-
 arch/x86/Makefile  |   1 +
 arch/x86/minios-x86.lds.S  | 133 +
 arch/x86/minios-x86_32.lds |  74 -
 arch/x86/minios-x86_64.lds |  74 -
 arch/x86/x86_32.S  |  17 +++---
 arch/x86/x86_64.S  |  15 ++---
 include/asm_macros.h   |  36 
 include/x86/asm_macros.h   |  28 ++
 10 files changed, 218 insertions(+), 168 deletions(-)
 create mode 100644 arch/x86/minios-x86.lds.S
 delete mode 100644 arch/x86/minios-x86_32.lds
 delete mode 100644 arch/x86/minios-x86_64.lds
 create mode 100644 include/asm_macros.h
 create mode 100644 include/x86/asm_macros.h

-- 
2.1.4


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

Re: [Xen-devel] [PATCH 1/9] x86/mtrr: prefix fns with mtrr and drop static

[Jan Beulich]

>>> On 17.08.16 at 01:28,  wrote:
> For the functions that make up the interface to the MTRR code, drop the
> static keyword and prefix them all with mtrr for improved clarity when
> they're called outside this file. This also required adjusting or
> providing function prototypes to make them callable.

I can see why you want to do this for non-static functions, but I can't
see why static ones would need to get altered (unless you mean to call
them directly in subsequent patches, in which case the rationale above
should be adjusted). Nor can I see why the two functions previously
having been non-static can't simply be made static, without changing
their names, as the patch demonstrates that they don't have callers
in other CUs.

Jan


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

[Xen-devel] [MINIOS PATCH 2/4] Introduce asm_macros.h

[Wei Liu]

Ported from xtf.git.

Signed-off-by: Wei Liu 
---
 include/asm_macros.h | 36 
 include/x86/asm_macros.h | 28 
 2 files changed, 64 insertions(+)
 create mode 100644 include/asm_macros.h
 create mode 100644 include/x86/asm_macros.h

diff --git a/include/asm_macros.h b/include/asm_macros.h
new file mode 100644
index 000..15dd377
--- /dev/null
+++ b/include/asm_macros.h
@@ -0,0 +1,36 @@
+/*
+ * Macros for assembly files.
+ */
+
+#ifndef _ASM_MACRO_H_
+#define _ASM_MACRO_H_
+
+#include 
+
+#ifdef __ASSEMBLY__
+
+#define ELFNOTE(name, type, desc)   \
+.pushsection .note.name   ; \
+.align 4  ; \
+.long 2f - 1f   /* namesz */  ; \
+.long 4f - 3f   /* descsz */  ; \
+.long type  /* type   */  ; \
+1:.asciz #name  /* name   */  ; \
+2:.align 4; \
+3:desc  /* desc   */  ; \
+4:.align 4; \
+.popsection
+
+#endif  /* __ASSEMBLY__ */
+
+#endif  /* _ASM_MACRO_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/include/x86/asm_macros.h b/include/x86/asm_macros.h
new file mode 100644
index 000..e718e0b
--- /dev/null
+++ b/include/x86/asm_macros.h
@@ -0,0 +1,28 @@
+#ifndef _X86_ASM_MACRO_H_
+#define _X86_ASM_MACRO_H_
+
+#ifdef  __ASSEMBLY__
+# if defined(__x86_64__)
+#  define _WORD .quad
+# elif defined(__i386__)
+#  define _WORD .long
+# endif
+#else
+# if defined(__x86_64__)
+#  define _WORD ".quad"
+# elif defined(__i386__)
+#  define _WORD ".long"
+# endif
+#endif
+
+#endif /* _X86_ASM_MACRO_H_ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.1.4


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