date:20170808

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 2913ebb2b550f50a14f105e26995dd095e627ba4
baseline version:
 ovmf 9e2a8e928995c3b1bb664b73fd59785055c6b5f6

Last test of basis   112522  2017-08-08 18:17:12 Z0 days
Testing same since   112525  2017-08-09 01:19:55 Z0 days1 attempts


People who touched revisions under test:
  Jiaxin Wu 
  Wu Jiaxin 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=2913ebb2b550f50a14f105e26995dd095e627ba4
+ . ./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 
2913ebb2b550f50a14f105e26995dd095e627ba4
+ branch=ovmf
+ revision=2913ebb2b550f50a14f105e26995dd095e627ba4
+ . ./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.9-testing
+ '[' x2913ebb2b550f50a14f105e26995dd095e627ba4 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git

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

2017-08-08 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9e2a8e928995c3b1bb664b73fd59785055c6b5f6
baseline version:
 ovmf 4cf3f37c87ba1f9d58072444bd735e40e4779e70

Last test of basis71951  2017-08-08 17:47:30 Z0 days
Testing same since71952  2017-08-09 01:17:17 Z0 days1 attempts


People who touched revisions under test:
  Dhiru Kholia 
  Laszlo Ersek 

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 9e2a8e928995c3b1bb664b73fd59785055c6b5f6
Author: Laszlo Ersek 
Date:   Sun Aug 6 11:20:02 2017 +0200

OvmfPkg/AcpiPlatformDxe: short-circuit the transfer of an empty S3_CONTEXT

In commit 805762252733 ("OvmfPkg/AcpiPlatformDxe: save fw_cfg boot script
with QemuFwCfgS3Lib", 2017-02-23), we replaced the explicit S3 boot script
manipulation in TransferS3ContextToBootScript() with a call to
QemuFwCfgS3CallWhenBootScriptReady(). (Passing AppendFwCfgBootScript() as
callback.)

QemuFwCfgS3CallWhenBootScriptReady() checks for fw_cfg DMA up-front, and
bails with RETURN_NOT_FOUND if fw_cfg DMA is missing.

(This is justified as the goal of QemuFwCfgS3Lib is to "enable[] driver
modules [...] to produce fw_cfg DMA operations that are to be replayed at
S3 resume time".)

In turn, if QemuFwCfgS3CallWhenBootScriptReady() fails, then
OvmfPkg/AcpiPlatformDxe rolls back any earlier linker/loader script
processing, and falls back to the built-in ACPI tables.

(This is also justified because failure to save WRITE_POINTER commands for
replaying at S3 resume implies failure to process the linker/loader script
comprehensively.)

Calling QemuFwCfgS3CallWhenBootScriptReady() from
TransferS3ContextToBootScript() *unconditionally* is wrong however. For
the case when the linker/loader script contains no WRITE_POINTER commands,
the call perpetuated an earlier side effect, and introduced another one:

(1) On machine types that provide fw_cfg DMA (i.e., 2.5+),
QemuFwCfgS3CallWhenBootScriptReady() would succeed, and allocate
workspace for the boot script opcodes in reserved memory. However, no
opcodes would actually be produced in the AppendFwCfgBootScript()
callback, due to lack of any WRITE_POINTER commands.

This waste of reserved memory had been introduced in earlier commit
df73df138d9d ("OvmfPkg/AcpiPlatformDxe: replay
QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09).

(2) On machine types that lack fw_cfg DMA (i.e., 2.4 and earlier),
TransferS3ContextToBootScript() would now fail the linker/loader
script for no reason.

(Note that QEMU itself prevents adding devices that depend on
WRITE_POINTER if the machine type lacks fw_cfg DMA:

$ qemu-system-x86_64 -M pc-q35-2.4 -device vmgenid

qemu-system-x86_64: -device vmgenid: vmgenid requires DMA write
support in fw_cfg, which this machine type does not provide)

Short-circuit an empty S3_CONTEXT in TransferS3ContextToBootScript() by
dropping S3_CONTEXT on the floor. This is compatible with the current
contract of the function as it constitutes a transfer of ownership.

Regression (2) was found and reported by Dhiru Kholia as an OSX guest boot
failure on the "pc-q35-2.4" machine type:


http://mid.mail-archive.com/CANO7a6x6EaWNZ8y=MvLU=w_ljrlxsero3nmsghvaye0aucc...@mail.gmail.com

Dhiru bisected the issue to commit 805762252733.

Cc: Dhiru Kholia

Re: [Xen-devel] [RFC v2 04/12] x86: implement data structure and CPU init flow for MBA.

2017-08-08 Thread Yi Sun

On 17-08-09 09:09:10, Chao Peng wrote:
> 
> > @@ -71,7 +78,6 @@ enum psr_feat_type {
> >  /*
> >   * This structure represents one feature.
> >   * cos_max - The max COS registers number got through CPUID.
> > - * cbm_len - The length of CBM got through CPUID.
> 
> As you are moving instead of removing the code, the comment can also
> move together with the code (but not get deleted). But if the remove is
> on your purpose (which sounds acceptable to me) then it's another thing.
> 
Ok, will move the comment.

> >   * cos_reg_val - Array to store the values of COS registers. One
> > entry stores
> >   *   the value of one COS register.
> >   *   For L3 CAT and L2 CAT, one entry corresponds to one
> > COS_ID.
> > @@ -80,9 +86,21 @@ enum psr_feat_type {
> >   *   cos_reg_val[1] (Code).
> >   */
> >  struct feat_node {
> > -/* cos_max and cbm_len are common values for all features so far.
> > */
> > +/* cos_max is common values for all features so far. */
> >  unsigned int cos_max;
> > -unsigned int cbm_len;
> > +
> > +/* Feature specific HW info. */
> > +union {
> > +struct {
> > +unsigned int cbm_len;
> > +} cat_info;
> > +
> > +struct {
> > +unsigned int thrtl_max;
> > +unsigned int linear;
> > +} mba_info;
> > +};
> > +
> >  uint32_t cos_reg_val[MAX_COS_REG_CNT];
> >  };
> >  
> >  /* CAT common functions implementation. */
> > -static int cat_init_feature(const struct cpuid_leaf *regs,
> > -struct feat_node *feat,
> > -struct psr_socket_info *info,
> > -enum psr_feat_type type)
> > +static int init_alloc_features(const struct cpuid_leaf *regs,
> 
> You still initialize the feature one by one, right? In that case
> 'features' should keep as 'feature'. Also I'm not sure which degree we
> can share the code between CAT and MBA. If not much but just bring many
> switch-cases and ifs then I tend to introduce a totally new
> mba_init_feature().
> 
Ok, a new 'mba_init_feature()' seems good.

> 
> > @@ -1439,12 +1508,25 @@ static void psr_cpu_init(void)
> >  
> >  feat = feat_l2_cat;
> >  feat_l2_cat = NULL;
> > -if ( !cat_init_feature(, feat, info, FEAT_TYPE_L2_CAT) )
> > +if ( !init_alloc_features(, feat, info,
> > FEAT_TYPE_L2_CAT) )
> >  feat_props[FEAT_TYPE_L2_CAT] = _cat_props;
> >  else
> >  feat_l2_cat = feat;
> >  }
> >  
> > +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, );
> 
> Can we cache this sub leaf 0? Currently we call this for every
> allocation feature which in my mind is unnecessary.
> 
Good suggestion to optimize codes. Will do it.

> > +if ( regs.b & PSR_RESOURCE_TYPE_MBA )
> > +{
> > +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 3, );
> > +
> > +feat = feat_mba;
> > +feat_mba = NULL;
> > +if ( !init_alloc_features(, feat, info, FEAT_TYPE_MBA) )
> > +feat_props[FEAT_TYPE_MBA] = _props;
> > +else
> > +feat_mba = feat;
> > +}
> > +
> >  info->feat_init = true;
> 
> Chao

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

[Xen-devel] [PATCH] cpufreq: only stop ondemand governor if already started

2017-08-08 Thread Christopher Clark

Avoid panic in cpufreq_gov_stop.

Only execute the CPUFREQ_GOV_STOP logic if the governor has
actually been started.

Patch originated in OpenXT.

Signed-off-by: Christopher Clark 
---
 xen/drivers/cpufreq/cpufreq_ondemand.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c
b/xen/drivers/cpufreq/cpufreq_ondemand.c
index 7fdba03..fe6c63d 100644
--- a/xen/drivers/cpufreq/cpufreq_ondemand.c
+++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
@@ -273,6 +273,10 @@ int cpufreq_governor_dbs(struct cpufreq_policy
*policy, unsigned int event)
 break;

 case CPUFREQ_GOV_STOP:
+if ( !this_dbs_info->enable )
+/* Already not enabled */
+break;
+
 dbs_timer_exit(this_dbs_info);
 dbs_enable--;

-- 
2.7.4

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   5 host-build-prep  fail REGR. vs. 112456
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112456
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112456

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112456
 build-arm64   2 hosts-allocate  broken like 112456
 build-arm64-pvops 2 hosts-allocate  broken like 112456
 build-arm64   3 capture-logsbroken like 112456
 build-arm64-pvops 3 capture-logsbroken like 112456
 build-arm64-xsm   3 capture-logsbroken like 112456
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112456
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuue42590c22a3b88f1cfcb7288f477b38200f5ae8c
baseline version:
 qemuuac44ed2afb7c60255e989b163301479f5b4ecd04

Last test of basis   112456  2017-08-05 00:17:41 Z4 days
Failing since112506  2017-08-07 09:39:19 Z1 days3 attempts
Testing same since   112521  2017-08-08 17:52:58 Z0 days1 attempts


People who touched revisions under test:
  Alberto Garcia 
  Aleksandr Bezzubikov 
  Cleber Rosa 
  Cornelia Huck 
  Daniel P. Berrange 
  Denis V. Lunev 
  Dr. David Alan Gilbert 
  Eric Auger 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Hannes Reinecke 
  Hannes Reinecke 
  Jeff Cody

Re: [Xen-devel] [RFC v2 07/12] x86: implement set value flow for MBA.

2017-08-08 Thread Chao Peng


>  /* write_msr is used to write out feature MSR register. */
>  void (*write_msr)(unsigned int cos, uint32_t val, enum
> psr_val_type type);
> +
> +/*
> + * check_change_val is used to check if input val fulfills SDM
> requirement.
> + * Change it to valid value if SDM allows.
> + */
> +bool (*check_change_val)(const struct feat_node *feat, unsigned
> long *val);

I understand you need check the value and also potentially change the
value in certain case, but the naming here sounds not so good.

check_value? accept_value? or any other better solutions?

>  } *feat_props[FEAT_TYPE_NUM];
>  
>  /*
>  
> +static bool cat_check_change_val(const struct feat_node *feat,
> + unsigned long *cbm)

and keep this as cat_check_cbm(),

> 
> +static bool mba_check_change_val(const struct feat_node *feat,
> + unsigned long *thrtl)

and this becomes mba_check_thrtl()?

Chao

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

Re: [Xen-devel] [RFC v2 05/12] x86: implement get hw info flow for MBA.

2017-08-08 Thread Chao Peng


> diff --git a/xen/include/asm-x86/psr.h b/xen/include/asm-x86/psr.h
> index 551ccf3..81da1c2 100644
> --- a/xen/include/asm-x86/psr.h
> +++ b/xen/include/asm-x86/psr.h
> @@ -38,7 +38,9 @@
>  /* Used by psr_get_info() */
>  #define PSR_INFO_IDX_COS_MAX0
>  #define PSR_INFO_IDX_CAT_CBM_LEN1
> +#define PSR_INFO_IDX_MBA_THRTL_MAX  1
>  #define PSR_INFO_IDX_CAT_FLAG   2
> +#define PSR_INFO_IDX_MBA_LINEAR 2

Sorting by feature instead of by index sounds more reasonable to me.

>  #define PSR_INFO_ARRAY_SIZE 3
>  
>  struct psr_cmt_l3 {
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 44d64f5..457ce9c 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -745,6 +745,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_sysctl_pcitopoinfo_t);
>  
>  #define XEN_SYSCTL_PSR_CAT_get_l3_info   0
>  #define XEN_SYSCTL_PSR_CAT_get_l2_info   1
> +#define XEN_SYSCTL_PSR_MBA_get_info  2
>  struct xen_sysctl_psr_alloc_op {
>  uint32_t cmd;   /* IN: XEN_SYSCTL_PSR_CAT_* */
>  uint32_t target;/* IN */
> @@ -755,6 +756,13 @@ struct xen_sysctl_psr_alloc_op {
>  #define XEN_SYSCTL_PSR_CAT_L3_CDP   (1u << 0)
>  uint32_t flags; /* OUT: CAT flags */
>  } cat_info;
> +
> +struct {
> +uint32_t thrtl_max; /* OUT: Maximum throttle */
> +uint32_t cos_max;   /* OUT: Maximum COS */
> +#define XEN_SYSCTL_PSR_MBA_LINEAR  (1u << 0)
> +uint32_t linear;/* OUT: Linear mode */

Just like CAT, rename to 'flags' so it can be extended easily in the
future?

Chao

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm  17 guest-start.2fail REGR. vs. 112496
 build-armhf-xsm  5 host-build-prep fail in 112511 REGR. vs. 112496

Tests which are failing intermittently (not blocking):
 test-xtf-amd64-amd64-34 host-install(4)  broken pass in 112511
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail in 112511 pass 
in 112519

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stopfail REGR. vs. 112447

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 112511 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 112511 n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112496
 build-arm64-pvops 2 hosts-allocate  broken like 112496
 build-arm64   2 hosts-allocate  broken like 112496
 build-arm64-xsm   3 capture-logsbroken like 112496
 build-arm64-pvops 3 capture-logsbroken like 112496
 build-arm64   3 capture-logsbroken like 112496
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 112511 
like 112423
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 112511 like 
112475
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112460
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 112496
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 112496
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112496
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112496
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112496
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112496
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13

[Xen-devel] [PATCH] x86/tboot: tboot_shutdown: disable interrupts after map_pages_to_xen

2017-08-08 Thread Christopher Clark

Move the point where interrupts are disabled in tboot_shutdown
to slightly later, to after the call to map_pages_to_xen.

This patch originated in OpenXT with the following report:

"Disabling interrupts early causes debug assertions.

This is only seen with debug builds but since it causes assertions it is
probably a bigger problem. It clearly says in map_pages_to_xen that it
should not be called with interrupts disabled. Moved disabling to just
after that call."

The Xen code comment ahead of map_pages_to_xen notes that the CPU cache
flushing in map_pages_to_xen differs depending on whether interrupts are
enabled or not. The flush logic with interrupts enabled is more
conservative, flushing all CPUs' TLBs/caches, rather than just local.
This is just before the tboot memory integrity MAC calculation is performed
in the case of entering S3.

Original patch author credit: Ross Philipson.

Signed-off-by: Christopher Clark 
---
 xen/arch/x86/tboot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/tboot.c b/xen/arch/x86/tboot.c
index cc26821..59d7c47 100644
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -341,8 +341,6 @@ void tboot_shutdown(uint32_t shutdown_type)

 g_tboot_shared->shutdown_type = shutdown_type;

-local_irq_disable();
-
 /* Create identity map for tboot shutdown code. */
 /* do before S3 integrity because mapping tboot may change xenheap */
 map_base = PFN_DOWN(g_tboot_shared->tboot_base);
@@ -357,6 +355,10 @@ void tboot_shutdown(uint32_t shutdown_type)
 return;
 }

+/* Disable interrupts as early as possible but not prior to */
+/* calling map_pages_to_xen */
+local_irq_disable();
+
 /* if this is S3 then set regions to MAC */
 if ( shutdown_type == TB_SHUTDOWN_S3 )
 {
-- 
2.7.4

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

Re: [Xen-devel] [RFC v2 04/12] x86: implement data structure and CPU init flow for MBA.

2017-08-08 Thread Chao Peng


> @@ -71,7 +78,6 @@ enum psr_feat_type {
>  /*
>   * This structure represents one feature.
>   * cos_max - The max COS registers number got through CPUID.
> - * cbm_len - The length of CBM got through CPUID.

As you are moving instead of removing the code, the comment can also
move together with the code (but not get deleted). But if the remove is
on your purpose (which sounds acceptable to me) then it's another thing.

>   * cos_reg_val - Array to store the values of COS registers. One
> entry stores
>   *   the value of one COS register.
>   *   For L3 CAT and L2 CAT, one entry corresponds to one
> COS_ID.
> @@ -80,9 +86,21 @@ enum psr_feat_type {
>   *   cos_reg_val[1] (Code).
>   */
>  struct feat_node {
> -/* cos_max and cbm_len are common values for all features so far.
> */
> +/* cos_max is common values for all features so far. */
>  unsigned int cos_max;
> -unsigned int cbm_len;
> +
> +/* Feature specific HW info. */
> +union {
> +struct {
> +unsigned int cbm_len;
> +} cat_info;
> +
> +struct {
> +unsigned int thrtl_max;
> +unsigned int linear;
> +} mba_info;
> +};
> +
>  uint32_t cos_reg_val[MAX_COS_REG_CNT];
>  };
>  
> @@ -161,6 +179,7 @@ static DEFINE_PER_CPU(struct psr_assoc,
> psr_assoc);
>   */
>  static struct feat_node *feat_l3;
>  static struct feat_node *feat_l2_cat;
> +static struct feat_node *feat_mba;
>  
>  /* Common functions */
>  #define cat_default_val(len) (0x >> (32 - (len)))
> @@ -274,22 +293,22 @@ static bool psr_check_cbm(unsigned int cbm_len,
> unsigned long cbm)
>  }
>  
>  /* CAT common functions implementation. */
> -static int cat_init_feature(const struct cpuid_leaf *regs,
> -struct feat_node *feat,
> -struct psr_socket_info *info,
> -enum psr_feat_type type)
> +static int init_alloc_features(const struct cpuid_leaf *regs,

You still initialize the feature one by one, right? In that case
'features' should keep as 'feature'. Also I'm not sure which degree we
can share the code between CAT and MBA. If not much but just bring many
switch-cases and ifs then I tend to introduce a totally new
mba_init_feature().


> @@ -1439,12 +1508,25 @@ static void psr_cpu_init(void)
>  
>  feat = feat_l2_cat;
>  feat_l2_cat = NULL;
> -if ( !cat_init_feature(, feat, info, FEAT_TYPE_L2_CAT) )
> +if ( !init_alloc_features(, feat, info,
> FEAT_TYPE_L2_CAT) )
>  feat_props[FEAT_TYPE_L2_CAT] = _cat_props;
>  else
>  feat_l2_cat = feat;
>  }
>  
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 0, );

Can we cache this sub leaf 0? Currently we call this for every
allocation feature which in my mind is unnecessary.

> +if ( regs.b & PSR_RESOURCE_TYPE_MBA )
> +{
> +cpuid_count_leaf(PSR_CPUID_LEVEL_CAT, 3, );
> +
> +feat = feat_mba;
> +feat_mba = NULL;
> +if ( !init_alloc_features(, feat, info, FEAT_TYPE_MBA) )
> +feat_props[FEAT_TYPE_MBA] = _props;
> +else
> +feat_mba = feat;
> +}
> +
>  info->feat_init = true;

Chao

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

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 9e2a8e928995c3b1bb664b73fd59785055c6b5f6
baseline version:
 ovmf 4cf3f37c87ba1f9d58072444bd735e40e4779e70

Last test of basis   112518  2017-08-08 08:21:39 Z0 days
Testing same since   112522  2017-08-08 18:17:12 Z0 days1 attempts


People who touched revisions under test:
  Dhiru Kholia 
  Laszlo Ersek 

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=9e2a8e928995c3b1bb664b73fd59785055c6b5f6
+ . ./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 
9e2a8e928995c3b1bb664b73fd59785055c6b5f6
+ branch=ovmf
+ revision=9e2a8e928995c3b1bb664b73fd59785055c6b5f6
+ . ./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.9-testing
+ '[' x9e2a8e928995c3b1bb664b73fd59785055c6b5f6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ :

Re: [Xen-devel] [PATCH v1 1/3] xen:rtds: towards work conserving RTDS

On Tue, Aug 8, 2017 at 3:52 PM, Dario Faggioli
 wrote:
> On Tue, 2017-08-08 at 12:06 -0700, Meng Xu wrote:
>> On Tue, Aug 8, 2017 at 10:57 AM, Dario Faggioli
>>  wrote:
>> > On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
>> > >
>> > > diff --git a/xen/include/public/domctl.h
>> > > b/xen/include/public/domctl.h
>> > > index 0669c31..ba5daa9 100644
>> > > --- a/xen/include/public/domctl.h
>> > > +++ b/xen/include/public/domctl.h
>> > > @@ -360,6 +360,9 @@ typedef struct xen_domctl_sched_credit2 {
>> > >  typedef struct xen_domctl_sched_rtds {
>> > >  uint32_t period;
>> > >  uint32_t budget;
>> > > +#define _XEN_DOMCTL_SCHED_RTDS_extratime 0
>> > > +#define
>> > > XEN_DOMCTL_SCHED_RTDS_extratime  (1U<<_XEN_DOMCTL_SCHED_RTDS_extr
>> > > atim
>> > > e)
>> > > +uint32_t flags;
>> > >
>> >
>> > I'd add a one liner comment above the flag definition, as, for
>> > instance, how things are done in createdomain:
>>
>> Sure.
>>
>> How about comment:
>> /* Does this VCPU get extratime beyond reserved time? */
>>
> 'Can this vCPU execute beyond its reserved amount of time?'
>
>> >
>> > struct xen_domctl_createdomain {
>> > /* IN parameters */
>> > uint32_t ssidref;
>> > xen_domain_handle_t handle;
>> >  /* Is this an HVM guest (as opposed to a PVH or PV guest)? */
>> > #define _XEN_DOMCTL_CDF_hvm_guest 0
>> > #define
>> > XEN_DOMCTL_CDF_hvm_guest  (1U<<_XEN_DOMCTL_CDF_hvm_guest)
>> >  /* Use hardware-assisted paging if available? */
>> > #define _XEN_DOMCTL_CDF_hap   1
>> > #define XEN_DOMCTL_CDF_hap(1U<<_XEN_DOMCTL_CDF_hap)
>> >
>> > Also, consider shortening the name (e.g., by contracting the
>> > SCHED_RTDS
>> > part; it does not matter if it's not 100% equal to what's in
>> > sched_rt.c, I think).
>>
>>
>> How about shorten it to XEN_DOMCTL_RTDS_extra or
>> XEN_DOMCTL_RTDS_extratime?
>>
> Personally, I'd go for XEN_DOMCTL_SCHEDRT_extra (or _extratime, or
> _extrat).

OK. I can go with  XEN_DOMCTL_SCHEDRT_extra.

Thanks,

Meng

---
Meng Xu
PhD Candidate 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 v1 3/3] xl: enable per-VCPU extratime flag for RTDS

On Tue, Aug 8, 2017 at 3:24 PM, Dario Faggioli
 wrote:
> On Tue, 2017-08-08 at 12:16 -0700, Meng Xu wrote:
>> On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli
>>  wrote:
>> > On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
>> > >
>> > > As to (1), if users want to set some VCPUs with extratime flag
>> > > set
>> > > and
>> > > some with extratime flag clear, there are two types of input:
>> > > (a) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -e 0 -v 2 -p 1
>> > > -b
>> > > 4000 -e 1 -v 5 -p 1 -b 4000 -e 0
>> > > (b) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -v 2 -p 1 -b
>> > > 4000 -e
>> > > 1 -v 5 -p 1 -b 4000
>> > > I felt that the style (a) is more intuitive and the input
>> > > commands
>> > > have very static pattern, i.e., each vcpu must have -v -p -b -e
>> > > options set.
>> > >
>> >
>> > Exactly, I do think that (b) is indeed a better user interface.
>> >
>> With the approach (b), what I have in my mind was: if users do not
>> use
>> -e option for a vcpu index, the vcpu will have its extratime flag
>> cleared.
>> If not-setting -e option for a VCPU means using the current extratime
>> value for the VCPU, then how should users clear the extratime flag
>> for
>> a VCPU?
>>
> Yeah, I know... Well, it's an hard interface to get right.
>
> So, I think, considering how things currently work for budget and
> period, I guess I'm fine with the -e switch taking a 0/1 value.
>
> I've checked how it was in SEDF, and it was like that in there too
> (see, e.g. commit 1583cdd1fdded49698503a699c5868643051e391).
>
>> If you look at the -p and -b option for the xl sched-rtds, we will
>> find that users will have to first read both parameters of a VCPU
>> even
>> if they only want to change the value for one parameter, either -p or
>> -b. We don't allow users to specify -p or -b without an input value.
>>
> Yes. Which I now remember as something I've never really liked. But
> again, it's an interface which is a bit hard to get right. And it's
> certainly not this patch series' job to change it.
>
> So, let's stick with it. Thanks for bearing with me. :-)

No problem at all. :-)
I also checked the SEDF scheduler's commands while I was working on
this patch version.
I felt that keeping the same format for the -p, -b and -e options is a
better idea.

>
>
> I now want to bring something new on the table, though: what should the
> default be?
>
> I mean, what do we expect most people to want, e.g., at domain creation
> time, if they don't include an 'extratime=1' in their config file
> (actually, I don't think it's even possible to do that! :-O) ?
>
> I believe that --kind of unlikely wrt what happens in the real-time
> research and papers-- most users would expect a work conserving
> scheduler, unless they specify otherwise.
>
> As in, they hopefully will enjoy being able to reserve some CPU
> bandwidth in a very precise and deterministic way, for their vCPUs. But
> I don't think they see as a good thing the fact that those vCPUs stops
> running at some point, even if the system is idle.
>
> Also, I think we really should set dom0 to be in extratime mode.
>
> Therefore, I think I would set extratime as on by default in both Xen
> an xl. What do you think?
>

Right now, the domain is created with its VCPUs' extratime flag on. So
by default, extratime is set on in Xen.

I'm not sure what do you suggest setting the extratime flag on by default in xl?
Did you mean if users do not input -e option, the extratime flag will
be set as on?
If so, users may get confused IMHO. Some users may think not setting
-e option indicating clear the extratime flag, while some who
carefully read the instruction of the commands know the xl set the
extratime flag by default if -e option is not provided.

Thanks,

Meng

---
Meng Xu
PhD Candidate 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 v1 0/3] Towards work-conserving RTDS

On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
> This series of patches make RTDS scheduler work-conserving
> without breaking real-time guarantees.
> VCPUs with extratime flag set can get extra time
> from the unreserved system resource.
> System administrators can decide which VCPUs have extratime flag set.
> 
> Example:
> Set the extratime bit of all VCPUs of domain 1:
> # xl sched-rtds -d 1 -v all -p 1 -b 2000 -e 1
> Each VCPU of domain 1 will be guaranteed to have 2000ms every 1ms
> (if the system is schedulable).
> If there is a CPU having no work to do,
> domain 1's VCPUs will be scheduled onto the CPU,
> even though the VCPUs have got 2000ms in 1ms.
> 
> Clear the extra bit of all VCPUs of domain 1:
> # xl sched-rtds -d 1 -v all -p 1 -b 2000 -e 0
> 
> Set/Clear the extratime bit of one specific VCPU of domain 1:
> # xl sched-rtds -d 1 -v 1 -p 1 -b 2000 -e 1
> # xl sched-rtds -d 1 -v 1 -p 1 -b 2000 -e 0
> 
Oh, BTW, can you please update 'docs/features/sched_rtds.pandoc' too?

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 v1 1/3] xen:rtds: towards work conserving RTDS

On Tue, 2017-08-08 at 12:06 -0700, Meng Xu wrote:
> On Tue, Aug 8, 2017 at 10:57 AM, Dario Faggioli
>  wrote:
> > On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
> > > 
> > > diff --git a/xen/include/public/domctl.h
> > > b/xen/include/public/domctl.h
> > > index 0669c31..ba5daa9 100644
> > > --- a/xen/include/public/domctl.h
> > > +++ b/xen/include/public/domctl.h
> > > @@ -360,6 +360,9 @@ typedef struct xen_domctl_sched_credit2 {
> > >  typedef struct xen_domctl_sched_rtds {
> > >  uint32_t period;
> > >  uint32_t budget;
> > > +#define _XEN_DOMCTL_SCHED_RTDS_extratime 0
> > > +#define
> > > XEN_DOMCTL_SCHED_RTDS_extratime  (1U<<_XEN_DOMCTL_SCHED_RTDS_extr
> > > atim
> > > e)
> > > +uint32_t flags;
> > > 
> > 
> > I'd add a one liner comment above the flag definition, as, for
> > instance, how things are done in createdomain:
> 
> Sure.
> 
> How about comment:
> /* Does this VCPU get extratime beyond reserved time? */
> 
'Can this vCPU execute beyond its reserved amount of time?'

> > 
> > struct xen_domctl_createdomain {
> > /* IN parameters */
> > uint32_t ssidref;
> > xen_domain_handle_t handle;
> >  /* Is this an HVM guest (as opposed to a PVH or PV guest)? */
> > #define _XEN_DOMCTL_CDF_hvm_guest 0
> > #define
> > XEN_DOMCTL_CDF_hvm_guest  (1U<<_XEN_DOMCTL_CDF_hvm_guest)
> >  /* Use hardware-assisted paging if available? */
> > #define _XEN_DOMCTL_CDF_hap   1
> > #define XEN_DOMCTL_CDF_hap(1U<<_XEN_DOMCTL_CDF_hap)
> > 
> > Also, consider shortening the name (e.g., by contracting the
> > SCHED_RTDS
> > part; it does not matter if it's not 100% equal to what's in
> > sched_rt.c, I think).
> 
> 
> How about shorten it to XEN_DOMCTL_RTDS_extra or
> XEN_DOMCTL_RTDS_extratime?
> 
Personally, I'd go for XEN_DOMCTL_SCHEDRT_extra (or _extratime, or
_extrat).

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 v1 3/3] xl: enable per-VCPU extratime flag for RTDS

On Tue, 2017-08-08 at 12:16 -0700, Meng Xu wrote:
> On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli
>  wrote:
> > On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
> > > 
> > > As to (1), if users want to set some VCPUs with extratime flag
> > > set
> > > and
> > > some with extratime flag clear, there are two types of input:
> > > (a) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -e 0 -v 2 -p 1
> > > -b
> > > 4000 -e 1 -v 5 -p 1 -b 4000 -e 0
> > > (b) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -v 2 -p 1 -b
> > > 4000 -e
> > > 1 -v 5 -p 1 -b 4000
> > > I felt that the style (a) is more intuitive and the input
> > > commands
> > > have very static pattern, i.e., each vcpu must have -v -p -b -e
> > > options set.
> > > 
> > 
> > Exactly, I do think that (b) is indeed a better user interface.
> > 
> With the approach (b), what I have in my mind was: if users do not
> use
> -e option for a vcpu index, the vcpu will have its extratime flag
> cleared.
> If not-setting -e option for a VCPU means using the current extratime
> value for the VCPU, then how should users clear the extratime flag
> for
> a VCPU? 
>
Yeah, I know... Well, it's an hard interface to get right.

So, I think, considering how things currently work for budget and
period, I guess I'm fine with the -e switch taking a 0/1 value.

I've checked how it was in SEDF, and it was like that in there too
(see, e.g. commit 1583cdd1fdded49698503a699c5868643051e391).

> If you look at the -p and -b option for the xl sched-rtds, we will
> find that users will have to first read both parameters of a VCPU
> even
> if they only want to change the value for one parameter, either -p or
> -b. We don't allow users to specify -p or -b without an input value.
> 
Yes. Which I now remember as something I've never really liked. But
again, it's an interface which is a bit hard to get right. And it's
certainly not this patch series' job to change it.

So, let's stick with it. Thanks for bearing with me. :-)

I now want to bring something new on the table, though: what should the
default be?

I mean, what do we expect most people to want, e.g., at domain creation
time, if they don't include an 'extratime=1' in their config file
(actually, I don't think it's even possible to do that! :-O) ?

I believe that --kind of unlikely wrt what happens in the real-time
research and papers-- most users would expect a work conserving
scheduler, unless they specify otherwise.

As in, they hopefully will enjoy being able to reserve some CPU
bandwidth in a very precise and deterministic way, for their vCPUs. But
I don't think they see as a good thing the fact that those vCPUs stops
running at some point, even if the system is idle.

Also, I think we really should set dom0 to be in extratime mode.

Therefore, I think I would set extratime as on by default in both Xen
an xl. What do you think?

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

[Xen-devel] [linux-3.18 test] 112517: trouble: blocked/broken/fail/pass

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-pvops 3 capture-logs   broken REGR. vs. 112102

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl   7 xen-boot   fail pass in 112494

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 112102
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 112102
 build-arm64   2 hosts-allocate broken REGR. vs. 112102

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 112102
 build-arm64   3 capture-logs  broken blocked in 112102
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 112494 blocked in 
112102
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail in 112494 like 112085
 test-armhf-armhf-xl 13 migrate-support-check fail in 112494 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 112494 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 112085
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112102
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 112102
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112102
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112102
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14

[Xen-devel] [PATCH v7 4/9] mm: Scrub pages in alloc_heap_pages() if needed

When allocating pages in alloc_heap_pages() first look for clean pages. If none
is found then retry, take pages marked as unscrubbed and scrub them.

Note that we shouldn't find unscrubbed pages in alloc_heap_pages() yet. However,
this will become possible when we stop scrubbing from free_heap_pages() and
instead do it from idle loop.

Since not all allocations require clean pages (such as xenheap allocations)
introduce MEMF_no_scrub flag that callers can set if they are willing to
consume unscrubbed pages.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/common/page_alloc.c | 33 +
 xen/include/xen/mm.h|  4 +++-
 2 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 5920e87..7fa8896 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -706,6 +706,7 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 nodemask_t nodemask = d ? d->node_affinity : node_online_map;
 unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
+bool use_unscrubbed = (memflags & MEMF_no_scrub);
 
 if ( node == NUMA_NO_NODE )
 {
@@ -737,8 +738,20 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 
 /* Find smallest order which can satisfy the request. */
 for ( j = order; j <= MAX_ORDER; j++ )
+{
 if ( (pg = page_list_remove_head((node, zone, j))) )
-return pg;
+{
+/*
+ * We grab single pages (order=0) even if they are
+ * unscrubbed. Given that scrubbing one page is fairly 
quick
+ * it is not worth breaking higher orders.
+ */
+if ( (order == 0) || use_unscrubbed ||
+ pg->u.free.first_dirty == INVALID_DIRTY_IDX)
+return pg;
+page_list_add_tail(pg, (node, zone, j));
+}
+}
 } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */
 
 if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE )
@@ -822,6 +835,10 @@ static struct page_info *alloc_heap_pages(
 }
 
 pg = get_free_buddy(zone_lo, zone_hi, order, memflags, d);
+/* Try getting a dirty buddy if we couldn't get a clean one. */
+if ( !pg && !(memflags & MEMF_no_scrub) )
+pg = get_free_buddy(zone_lo, zone_hi, order,
+memflags | MEMF_no_scrub, d);
 if ( !pg )
 {
 /* No suitable memory blocks. Fail the request. */
@@ -867,7 +884,15 @@ static struct page_info *alloc_heap_pages(
 for ( i = 0; i < (1 << order); i++ )
 {
 /* Reference count must continuously be zero for free pages. */
-BUG_ON(pg[i].count_info != PGC_state_free);
+BUG_ON((pg[i].count_info & ~PGC_need_scrub) != PGC_state_free);
+
+if ( test_bit(_PGC_need_scrub, [i].count_info) )
+{
+if ( !(memflags & MEMF_no_scrub) )
+scrub_one_page([i]);
+node_need_scrub[node]--;
+}
+
 pg[i].count_info = PGC_state_inuse;
 
 if ( !(memflags & MEMF_no_tlbflush) )
@@ -1743,7 +1768,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned 
int memflags)
 ASSERT(!in_irq());
 
 pg = alloc_heap_pages(MEMZONE_XEN, MEMZONE_XEN,
-  order, memflags, NULL);
+  order, memflags | MEMF_no_scrub, NULL);
 if ( unlikely(pg == NULL) )
 return NULL;
 
@@ -1793,7 +1818,7 @@ void *alloc_xenheap_pages(unsigned int order, unsigned 
int memflags)
 if ( !(memflags >> _MEMF_bits) )
 memflags |= MEMF_bits(xenheap_bits);
 
-pg = alloc_domheap_pages(NULL, order, memflags);
+pg = alloc_domheap_pages(NULL, order, memflags | MEMF_no_scrub);
 if ( unlikely(pg == NULL) )
 return NULL;
 
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 503b92e..e1f9c42 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -248,7 +248,9 @@ struct npfec {
 #define  MEMF_no_tlbflush (1U<<_MEMF_no_tlbflush)
 #define _MEMF_no_icache_flush 7
 #define  MEMF_no_icache_flush (1U<<_MEMF_no_icache_flush)
-#define _MEMF_node8
+#define _MEMF_no_scrub8
+#define  MEMF_no_scrub(1U<<_MEMF_no_scrub)
+#define _MEMF_node16
 #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
 #define  MEMF_node(n) n) + 1) & MEMF_node_mask) << _MEMF_node)
 #define  MEMF_get_node(f) f) >> _MEMF_node) - 1) & MEMF_node_mask)
-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 1/9] mm: Clean up free_heap_pages()

Make buddy merging part of free_heap_pages() a bit more readable.

Signed-off-by: Boris Ostrovsky 
---
Changes in v7:
* New in this version (this used to be part of patch 2, splitting
  into separate patch)

 xen/common/page_alloc.c | 29 ++---
 1 file changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 8bcef6a..330f8ed 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -977,24 +977,31 @@ static void free_heap_pages(
 
 if ( (page_to_mfn(pg) & mask) )
 {
+struct page_info *predecessor = pg - mask;
+
 /* Merge with predecessor block? */
-if ( !mfn_valid(_mfn(page_to_mfn(pg-mask))) ||
- !page_state_is(pg-mask, free) ||
- (PFN_ORDER(pg-mask) != order) ||
- (phys_to_nid(page_to_maddr(pg-mask)) != node) )
+if ( !mfn_valid(_mfn(page_to_mfn(predecessor))) ||
+ !page_state_is(predecessor, free) ||
+ (PFN_ORDER(predecessor) != order) ||
+ (phys_to_nid(page_to_maddr(predecessor)) != node) )
 break;
-pg -= mask;
-page_list_del(pg, (node, zone, order));
+
+page_list_del(predecessor, (node, zone, order));
+
+pg = predecessor;
 }
 else
 {
+struct page_info *successor = pg + mask;
+
 /* Merge with successor block? */
-if ( !mfn_valid(_mfn(page_to_mfn(pg+mask))) ||
- !page_state_is(pg+mask, free) ||
- (PFN_ORDER(pg+mask) != order) ||
- (phys_to_nid(page_to_maddr(pg+mask)) != node) )
+if ( !mfn_valid(_mfn(page_to_mfn(successor))) ||
+ !page_state_is(successor, free) ||
+ (PFN_ORDER(successor) != order) ||
+ (phys_to_nid(page_to_maddr(successor)) != node) )
 break;
-page_list_del(pg + mask, (node, zone, order));
+
+page_list_del(successor, (node, zone, order));
 }
 
 order++;
-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 9/9] mm: Make sure pages are scrubbed

Add a debug Kconfig option that will make page allocator verify
that pages that were supposed to be scrubbed are, in fact, clean.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
---
 xen/Kconfig.debug   |  7 ++
 xen/common/page_alloc.c | 63 -
 2 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
index 689f297..195d504 100644
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -114,6 +114,13 @@ config DEVICE_TREE_DEBUG
  logged in the Xen ring buffer.
  If unsure, say N here.
 
+config SCRUB_DEBUG
+   bool "Page scrubbing test"
+   default DEBUG
+   ---help---
+ Verify that pages that need to be scrubbed before being allocated to
+ a guest are indeed scrubbed.
+
 endif # DEBUG || EXPERT
 
 endmenu
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 675ac0d..83eaffb 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -170,6 +170,10 @@ boolean_param("bootscrub", opt_bootscrub);
 static unsigned long __initdata opt_bootscrub_chunk = MB(128);
 size_param("bootscrub_chunk", opt_bootscrub_chunk);
 
+#ifdef CONFIG_SCRUB_DEBUG
+static bool __read_mostly boot_scrub_done;
+#endif
+
 /*
  * Bit width of the DMA heap -- used to override NUMA-node-first.
  * allocation strategy, which can otherwise exhaust low memory.
@@ -698,6 +702,43 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+/* SCRUB_PATTERN needs to be a repeating series of bytes. */
+#ifndef NDEBUG
+#define SCRUB_PATTERN0xc2c2c2c2c2c2c2c2ULL
+#else
+#define SCRUB_PATTERN0ULL
+#endif
+#define SCRUB_BYTE_PATTERN   (SCRUB_PATTERN & 0xff)
+
+static void poison_one_page(struct page_info *pg)
+{
+#ifdef CONFIG_SCRUB_DEBUG
+mfn_t mfn = _mfn(page_to_mfn(pg));
+uint64_t *ptr;
+
+ptr = map_domain_page(mfn);
+*ptr = ~SCRUB_PATTERN;
+unmap_domain_page(ptr);
+#endif
+}
+
+static void check_one_page(struct page_info *pg)
+{
+#ifdef CONFIG_SCRUB_DEBUG
+mfn_t mfn = _mfn(page_to_mfn(pg));
+const uint64_t *ptr;
+unsigned int i;
+
+if ( !boot_scrub_done )
+return;
+
+ptr = map_domain_page(mfn);
+for ( i = 0; i < PAGE_SIZE / sizeof (*ptr); i++ )
+ASSERT(ptr[i] == SCRUB_PATTERN);
+unmap_domain_page(ptr);
+#endif
+}
+
 static void check_and_stop_scrub(struct page_info *head)
 {
 if ( head->u.free.scrub_state == BUDDY_SCRUBBING )
@@ -932,6 +973,9 @@ static struct page_info *alloc_heap_pages(
  * guest can control its own visibility of/through the cache.
  */
 flush_page_to_ram(page_to_mfn([i]), !(memflags & 
MEMF_no_icache_flush));
+
+if ( !(memflags & MEMF_no_scrub) )
+check_one_page([i]);
 }
 
 spin_unlock(_lock);
@@ -1295,7 +1339,10 @@ static void free_heap_pages(
 set_gpfn_from_mfn(mfn + i, INVALID_M2P_ENTRY);
 
 if ( need_scrub )
+{
 pg[i].count_info |= PGC_need_scrub;
+poison_one_page([i]);
+}
 }
 
 avail[node][zone] += 1 << order;
@@ -1655,7 +1702,12 @@ static void init_heap_pages(
 nr_pages -= n;
 }
 
+#ifndef CONFIG_SCRUB_DEBUG
 free_heap_pages(pg + i, 0, false);
+#else
+free_heap_pages(pg + i, 0, boot_scrub_done);
+#endif
+   
 }
 }
 
@@ -1921,6 +1973,10 @@ void __init scrub_heap_pages(void)
 
 printk("done.\n");
 
+#ifdef CONFIG_SCRUB_DEBUG
+boot_scrub_done = true;
+#endif
+
 /* Now that the heap is initialized, run checks and set bounds
  * for the low mem virq algorithm. */
 setup_low_mem_virq();
@@ -2194,12 +2250,16 @@ void free_domheap_pages(struct page_info *pg, unsigned 
int order)
 
 spin_unlock_recursive(>page_alloc_lock);
 
+#ifndef CONFIG_SCRUB_DEBUG
 /*
  * Normally we expect a domain to clear pages before freeing them,
  * if it cares about the secrecy of their contents. However, after
  * a domain has died we assume responsibility for erasure.
  */
 scrub = !!d->is_dying;
+#else
+scrub = true;
+#endif
 }
 else
 {
@@ -2291,7 +2351,8 @@ void scrub_one_page(struct page_info *pg)
 
 #ifndef NDEBUG
 /* Avoid callers relying on allocations returning zeroed pages. */
-unmap_domain_page(memset(__map_domain_page(pg), 0xc2, PAGE_SIZE));
+unmap_domain_page(memset(__map_domain_page(pg),
+ SCRUB_BYTE_PATTERN, PAGE_SIZE));
 #else
 /* For a production build, clear_page() is the fastest way to scrub. */
 clear_domain_page(_mfn(page_to_mfn(pg)));
-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 5/9] mm: Scrub memory from idle loop

Instead of scrubbing pages during guest destruction (from
free_heap_pages()) do this opportunistically, from the idle loop.

We might come to scrub_free_pages()from idle loop while another CPU
uses mapcache override, resulting in a fault while trying to do
__map_domain_page() in scrub_one_page(). To avoid this, make mapcache
vcpu override a per-cpu variable.

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Jan Beulich 
Reviewed-by: Dario Faggioli 
---
CC: Dario Faggioli 
---
 xen/arch/arm/domain.c  |   8 ++-
 xen/arch/x86/domain.c  |   8 ++-
 xen/arch/x86/domain_page.c |   6 +--
 xen/common/page_alloc.c| 119 -
 xen/include/xen/mm.h   |   1 +
 5 files changed, 124 insertions(+), 18 deletions(-)

diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 2dc8b0a..d7961bb 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -51,7 +51,13 @@ void idle_loop(void)
 /* Are we here for running vcpu context tasklets, or for idling? */
 if ( unlikely(tasklet_work_to_do(cpu)) )
 do_tasklet();
-else
+/*
+ * Test softirqs twice --- first to see if should even try scrubbing
+ * and then, after it is done, whether softirqs became pending
+ * while we were scrubbing.
+ */
+else if ( !softirq_pending(cpu) && !scrub_free_pages() &&
+!softirq_pending(cpu) )
 {
 local_irq_disable();
 if ( cpu_is_haltable(cpu) )
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index baaf815..9b4b959 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -122,7 +122,13 @@ static void idle_loop(void)
 /* Are we here for running vcpu context tasklets, or for idling? */
 if ( unlikely(tasklet_work_to_do(cpu)) )
 do_tasklet();
-else
+/*
+ * Test softirqs twice --- first to see if should even try scrubbing
+ * and then, after it is done, whether softirqs became pending
+ * while we were scrubbing.
+ */
+else if ( !softirq_pending(cpu) && !scrub_free_pages()  &&
+!softirq_pending(cpu) )
 pm_idle();
 do_softirq();
 /*
diff --git a/xen/arch/x86/domain_page.c b/xen/arch/x86/domain_page.c
index 71baede..0783c1e 100644
--- a/xen/arch/x86/domain_page.c
+++ b/xen/arch/x86/domain_page.c
@@ -18,12 +18,12 @@
 #include 
 #include 
 
-static struct vcpu *__read_mostly override;
+static DEFINE_PER_CPU(struct vcpu *, override);
 
 static inline struct vcpu *mapcache_current_vcpu(void)
 {
 /* In the common case we use the mapcache of the running VCPU. */
-struct vcpu *v = override ?: current;
+struct vcpu *v = this_cpu(override) ?: current;
 
 /*
  * When current isn't properly set up yet, this is equivalent to
@@ -59,7 +59,7 @@ static inline struct vcpu *mapcache_current_vcpu(void)
 
 void __init mapcache_override_current(struct vcpu *v)
 {
-override = v;
+this_cpu(override) = v;
 }
 
 #define mapcache_l2_entry(e) ((e) >> PAGETABLE_ORDER)
diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 7fa8896..b886983 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1013,15 +1013,86 @@ static int reserve_offlined_page(struct page_info *head)
 return count;
 }
 
-static void scrub_free_pages(unsigned int node)
+static nodemask_t node_scrubbing;
+
+/*
+ * If get_node is true this will return closest node that needs to be scrubbed,
+ * with appropriate bit in node_scrubbing set.
+ * If get_node is not set, this will return *a* node that needs to be scrubbed.
+ * node_scrubbing bitmask will no be updated.
+ * If no node needs scrubbing then NUMA_NO_NODE is returned.
+ */
+static unsigned int node_to_scrub(bool get_node)
 {
-struct page_info *pg;
-unsigned int zone;
+nodeid_t node = cpu_to_node(smp_processor_id()), local_node;
+nodeid_t closest = NUMA_NO_NODE;
+u8 dist, shortest = 0xff;
 
-ASSERT(spin_is_locked(_lock));
+if ( node == NUMA_NO_NODE )
+node = 0;
 
-if ( !node_need_scrub[node] )
-return;
+if ( node_need_scrub[node] &&
+ (!get_node || !node_test_and_set(node, node_scrubbing)) )
+return node;
+
+/*
+ * See if there are memory-only nodes that need scrubbing and choose
+ * the closest one.
+ */
+local_node = node;
+for ( ; ; )
+{
+do {
+node = cycle_node(node, node_online_map);
+} while ( !cpumask_empty(_to_cpumask(node)) &&
+  (node != local_node) );
+
+if ( node == local_node )
+break;
+
+if ( node_need_scrub[node] )
+{
+if ( !get_node )
+return node;
+
+dist = __node_distance(local_node, node);
+
+/*
+ *

[Xen-devel] [PATCH v7 8/9] mm: Print number of unscrubbed pages in 'H' debug handler

Signed-off-by: Boris Ostrovsky 
Reviewed-by: Wei Liu 
---
 xen/common/page_alloc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 726f857..675ac0d 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -2314,6 +2314,13 @@ static void dump_heap(unsigned char key)
 printk("heap[node=%d][zone=%d] -> %lu pages\n",
i, j, avail[i][j]);
 }
+
+for ( i = 0; i < MAX_NUMNODES; i++ )
+{
+if ( !node_need_scrub[i] )
+continue;
+printk("Node %d has %lu unscrubbed pages\n", i, node_need_scrub[i]);
+}
 }
 
 static __init int register_heap_trigger(void)
-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 0/9] Memory scrubbing from idle loop


Changes in v7:
* Split free_heap_pages() buddy merge changes into a separate patch (patch 1)
* Changed type for page_info.u.free.need_tlbflush to bool:1
* Added BUILD_BUG_ON
* Adjusted datatype of temp variable in check_and_stop_scrub()
* Formatting changes

(see per-patch changes)

When a domain is destroyed the hypervisor must scrub domain's pages before
giving them to another guest in order to prevent leaking the deceased
guest's data. Currently this is done during guest's destruction, possibly
causing very lengthy cleanup process.

This series adds support for scrubbing released pages from idle loop,
making guest destruction significantly faster. For example, destroying a
1TB guest can now be completed in 40+ seconds as opposed to about 9 minutes
using existing scrubbing algorithm.

Briefly, the new algorithm places dirty pages at the end of heap's page list
for each node/zone/order to avoid having to scan full list while searching
for dirty pages. One processor form each node checks whether the node has any
dirty pages and, if such pages are found, scrubs them. Scrubbing itself
happens without holding heap lock so other users may access heap in the
meantime. If while idle loop is scrubbing a particular chunk of pages this
chunk is requested by the heap allocator, scrubbing is immediately stopped.

On the allocation side, alloc_heap_pages() first tries to satisfy allocation
request using only clean pages. If this is not possible, the search is
repeated and dirty pages are scrubbed by the allocator.

This series is somewhat based on earlier work by Bob Liu.

V1:
* Only set PGC_need_scrub bit for the buddy head, thus making it unnecessary
  to scan whole buddy
* Fix spin_lock_cb()
* Scrub CPU-less nodes
* ARM support. Note that I have not been able to test this, only built the
  binary
* Added scrub test patch (last one). Not sure whether it should be considered
  for committing but I have been running with it.

V2:
* merge_chunks() returns new buddy head
* scrub_free_pages() returns softirq pending status in addition to (factored 
out)
  status of unscrubbed memory
* spin_lock uses inlined spin_lock_cb()
* scrub debugging code checks whole page, not just the first word.

V3:
* Keep dirty bit per page
* Simplify merge_chunks() (now merge_and_free_buddy())
* When scrubbing memmory-only nodes try to find the closest node.

V4:
* Keep track of dirty pages in a buddy with page_info.u.free.first_dirty.
* Drop patch 1 (factoring out merge_and_free_buddy()) since there is only
  one caller now
* Drop patch patch 5 (from V3) since we are not breaking partially-scrubbed
  buddy anymore
* Extract search loop in alloc_heap_pages() into get_free_buddy() (patch 2)
* Add MEMF_no_scrub flag

V5:
* Make page_info.u.free and union and use bitfields there.
* Bug fixes

V6:
* Changed first_dirty tracking from pointer-based to index-based (patch 1)
* Added/modified a few ASSERT()s
* Moved/modifed a couple of comments
* Adjusted width of INVALID_DIRTY_IDX


Deferred:
* Per-node heap locks. In addition to (presumably) improving performance in
  general, once they are available we can parallelize scrubbing further by
  allowing more than one core per node to do idle loop scrubbing.
* AVX-based scrubbing
* Use idle loop scrubbing during boot.



Boris Ostrovsky (9):
  mm: Clean up free_heap_pages()
  mm: Place unscrubbed pages at the end of pagelist
  mm: Extract allocation loop from alloc_heap_pages()
  mm: Scrub pages in alloc_heap_pages() if needed
  mm: Scrub memory from idle loop
  spinlock: Introduce spin_lock_cb()
  mm: Keep heap accessible to others while scrubbing
  mm: Print number of unscrubbed pages in 'H' debug handler
  mm: Make sure pages are scrubbed

 xen/Kconfig.debug  |   7 +
 xen/arch/arm/domain.c  |   8 +-
 xen/arch/x86/domain.c  |   8 +-
 xen/arch/x86/domain_page.c |   6 +-
 xen/common/page_alloc.c| 607 ++---
 xen/common/spinlock.c  |   9 +-
 xen/include/asm-arm/mm.h   |  30 ++-
 xen/include/asm-x86/mm.h   |  31 ++-
 xen/include/xen/mm.h   |   5 +-
 xen/include/xen/spinlock.h |   8 +
 10 files changed, 612 insertions(+), 107 deletions(-)

-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 6/9] spinlock: Introduce spin_lock_cb()

While waiting for a lock we may want to periodically run some
code. This code may, for example, allow the caller to release
resources held by it that are no longer needed in the critical
section protected by the lock.

Specifically, this feature will be needed by scrubbing code where
the scrubber, while waiting for heap lock to merge back clean
pages, may be requested by page allocator (which is currently
holding the lock) to abort merging and release the buddy page head
that the allocator wants.

We could use spin_trylock() but since it doesn't take lock ticket
it may take long time until the lock is taken. Instead we add
spin_lock_cb() that allows us to grab the ticket and execute a
callback while waiting. This callback is executed on every iteration
of the spinlock waiting loop.

Since we may be sleeping in the lock until it is released we need a
mechanism that will make sure that the callback has a chance to run.
We add spin_lock_kick() that will wake up the waiter.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/common/spinlock.c  | 9 -
 xen/include/xen/spinlock.h | 8 
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 2a06406..3c1caae 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -129,7 +129,7 @@ static always_inline u16 observe_head(spinlock_tickets_t *t)
 return read_atomic(>head);
 }
 
-void _spin_lock(spinlock_t *lock)
+void inline _spin_lock_cb(spinlock_t *lock, void (*cb)(void *), void *data)
 {
 spinlock_tickets_t tickets = SPINLOCK_TICKET_INC;
 LOCK_PROFILE_VAR;
@@ -140,6 +140,8 @@ void _spin_lock(spinlock_t *lock)
 while ( tickets.tail != observe_head(>tickets) )
 {
 LOCK_PROFILE_BLOCK;
+if ( unlikely(cb) )
+cb(data);
 arch_lock_relax();
 }
 LOCK_PROFILE_GOT;
@@ -147,6 +149,11 @@ void _spin_lock(spinlock_t *lock)
 arch_lock_acquire_barrier();
 }
 
+void _spin_lock(spinlock_t *lock)
+{
+ _spin_lock_cb(lock, NULL, NULL);
+}
+
 void _spin_lock_irq(spinlock_t *lock)
 {
 ASSERT(local_irq_is_enabled());
diff --git a/xen/include/xen/spinlock.h b/xen/include/xen/spinlock.h
index c1883bd..91bfb95 100644
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -153,6 +153,7 @@ typedef struct spinlock {
 #define spin_lock_init(l) (*(l) = (spinlock_t)SPIN_LOCK_UNLOCKED)
 
 void _spin_lock(spinlock_t *lock);
+void _spin_lock_cb(spinlock_t *lock, void (*cond)(void *), void *data);
 void _spin_lock_irq(spinlock_t *lock);
 unsigned long _spin_lock_irqsave(spinlock_t *lock);
 
@@ -169,6 +170,7 @@ void _spin_lock_recursive(spinlock_t *lock);
 void _spin_unlock_recursive(spinlock_t *lock);
 
 #define spin_lock(l)  _spin_lock(l)
+#define spin_lock_cb(l, c, d) _spin_lock_cb(l, c, d)
 #define spin_lock_irq(l)  _spin_lock_irq(l)
 #define spin_lock_irqsave(l, f) \
 ({  \
@@ -190,6 +192,12 @@ void _spin_unlock_recursive(spinlock_t *lock);
 1 : ({ local_irq_restore(flags); 0; }); \
 })
 
+#define spin_lock_kick(l)   \
+({  \
+smp_mb();   \
+arch_lock_signal(); \
+})
+
 /* Ensure a lock is quiescent between two critical operations. */
 #define spin_barrier(l)   _spin_barrier(l)
 
-- 
1.8.3.1


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

[Xen-devel] [PATCH v7 7/9] mm: Keep heap accessible to others while scrubbing

Instead of scrubbing pages while holding heap lock we can mark
buddy's head as being scrubbed and drop the lock temporarily.
If someone (most likely alloc_heap_pages()) tries to access
this chunk it will signal the scrubber to abort scrub by setting
head's BUDDY_SCRUB_ABORT bit. The scrubber checks this bit after
processing each page and stops its work as soon as it sees it.

Signed-off-by: Boris Ostrovsky 
---
Changes in v7:
* Replaced page_info with typeof(head->u.free) in check_and_stop_scrub()
* Replaced 1UL with 1U in scrub_free_pages()
* Fixed formatting in asm-*/mm.h

 xen/common/page_alloc.c  | 110 +--
 xen/include/asm-arm/mm.h |  28 +++-
 xen/include/asm-x86/mm.h |  30 -
 3 files changed, 143 insertions(+), 25 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b886983..726f857 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -687,6 +687,7 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 {
 PFN_ORDER(pg) = order;
 pg->u.free.first_dirty = first_dirty;
+pg->u.free.scrub_state = BUDDY_NOT_SCRUBBING;
 
 if ( first_dirty != INVALID_DIRTY_IDX )
 {
@@ -697,6 +698,25 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
+static void check_and_stop_scrub(struct page_info *head)
+{
+if ( head->u.free.scrub_state == BUDDY_SCRUBBING )
+{
+typeof(head->u.free) pgfree;
+
+head->u.free.scrub_state = BUDDY_SCRUB_ABORT;
+spin_lock_kick();
+for ( ; ; )
+{
+/* Can't ACCESS_ONCE() a bitfield. */
+pgfree.val = ACCESS_ONCE(head->u.free.val);
+if ( pgfree.scrub_state != BUDDY_SCRUB_ABORT )
+break;
+cpu_relax();
+}
+}
+}
+
 static struct page_info *get_free_buddy(unsigned int zone_lo,
 unsigned int zone_hi,
 unsigned int order, unsigned int 
memflags,
@@ -741,14 +761,19 @@ static struct page_info *get_free_buddy(unsigned int 
zone_lo,
 {
 if ( (pg = page_list_remove_head((node, zone, j))) )
 {
+if ( pg->u.free.first_dirty == INVALID_DIRTY_IDX )
+return pg;
 /*
  * We grab single pages (order=0) even if they are
  * unscrubbed. Given that scrubbing one page is fairly 
quick
  * it is not worth breaking higher orders.
  */
-if ( (order == 0) || use_unscrubbed ||
- pg->u.free.first_dirty == INVALID_DIRTY_IDX)
+if ( (order == 0) || use_unscrubbed )
+{
+check_and_stop_scrub(pg);
 return pg;
+}
+
 page_list_add_tail(pg, (node, zone, j));
 }
 }
@@ -929,6 +954,7 @@ static int reserve_offlined_page(struct page_info *head)
 
 cur_head = head;
 
+check_and_stop_scrub(head);
 /*
  * We may break the buddy so let's mark the head as clean. Then, when
  * merging chunks back into the heap, we will see whether the chunk has
@@ -1079,6 +1105,29 @@ static unsigned int node_to_scrub(bool get_node)
 return closest;
 }
 
+struct scrub_wait_state {
+struct page_info *pg;
+unsigned int first_dirty;
+bool drop;
+};
+
+static void scrub_continue(void *data)
+{
+struct scrub_wait_state *st = data;
+
+if ( st->drop )
+return;
+
+if ( st->pg->u.free.scrub_state == BUDDY_SCRUB_ABORT )
+{
+/* There is a waiter for this buddy. Release it. */
+st->drop = true;
+st->pg->u.free.first_dirty = st->first_dirty;
+smp_wmb();
+st->pg->u.free.scrub_state = BUDDY_NOT_SCRUBBING;
+}
+}
+
 bool scrub_free_pages(void)
 {
 struct page_info *pg;
@@ -1101,25 +1150,53 @@ bool scrub_free_pages(void)
 do {
 while ( !page_list_empty((node, zone, order)) )
 {
-unsigned int i;
+unsigned int i, dirty_cnt;
+struct scrub_wait_state st;
 
 /* Unscrubbed pages are always at the end of the list. */
 pg = page_list_last((node, zone, order));
 if ( pg->u.free.first_dirty == INVALID_DIRTY_IDX )
 break;
 
+ASSERT(pg->u.free.scrub_state == BUDDY_NOT_SCRUBBING);
+pg->u.free.scrub_state = BUDDY_SCRUBBING;
+
+spin_unlock(_lock);
+
+dirty_cnt = 0;
+
 for ( i = pg->u.free.first_dirty; i < (1U << order); i++)
 {
 if ( test_bit(_PGC_need_scrub, [i].count_info) )

[Xen-devel] [PATCH v7 3/9] mm: Extract allocation loop from alloc_heap_pages()

This will make code a bit more readable, especially with changes that
will be introduced in subsequent patches.

Signed-off-by: Boris Ostrovsky 
Acked-by: Jan Beulich 
---
 xen/common/page_alloc.c | 139 +++-
 1 file changed, 77 insertions(+), 62 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index b857a44..5920e87 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -697,22 +697,15 @@ static void page_list_add_scrub(struct page_info *pg, 
unsigned int node,
 page_list_add(pg, (node, zone, order));
 }
 
-/* Allocate 2^@order contiguous pages. */
-static struct page_info *alloc_heap_pages(
-unsigned int zone_lo, unsigned int zone_hi,
-unsigned int order, unsigned int memflags,
-struct domain *d)
+static struct page_info *get_free_buddy(unsigned int zone_lo,
+unsigned int zone_hi,
+unsigned int order, unsigned int 
memflags,
+const struct domain *d)
 {
-unsigned int i, j, zone = 0, nodemask_retry = 0, first_dirty;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
-unsigned long request = 1UL << order;
+nodemask_t nodemask = d ? d->node_affinity : node_online_map;
+unsigned int j, zone, nodemask_retry = 0;
 struct page_info *pg;
-nodemask_t nodemask = (d != NULL ) ? d->node_affinity : node_online_map;
-bool_t need_tlbflush = 0;
-uint32_t tlbflush_timestamp = 0;
-
-/* Make sure there are enough bits in memflags for nodeID. */
-BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
 
 if ( node == NUMA_NO_NODE )
 {
@@ -728,34 +721,6 @@ static struct page_info *alloc_heap_pages(
 first_node = node;
 
 ASSERT(node < MAX_NUMNODES);
-ASSERT(zone_lo <= zone_hi);
-ASSERT(zone_hi < NR_ZONES);
-
-if ( unlikely(order > MAX_ORDER) )
-return NULL;
-
-spin_lock(_lock);
-
-/*
- * Claimed memory is considered unavailable unless the request
- * is made by a domain with sufficient unclaimed pages.
- */
-if ( (outstanding_claims + request >
-  total_avail_pages + tmem_freeable_pages()) &&
-  ((memflags & MEMF_no_refcount) ||
-   !d || d->outstanding_pages < request) )
-goto not_found;
-
-/*
- * TMEM: When available memory is scarce due to tmem absorbing it, allow
- * only mid-size allocations to avoid worst of fragmentation issues.
- * Others try tmem pools then fail.  This is a workaround until all
- * post-dom0-creation-multi-page allocations can be eliminated.
- */
-if ( ((order == 0) || (order >= 9)) &&
- (total_avail_pages <= midsize_alloc_zone_pages) &&
- tmem_freeable_pages() )
-goto try_tmem;
 
 /*
  * Start with requested node, but exhaust all node memory in requested 
@@ -767,17 +732,17 @@ static struct page_info *alloc_heap_pages(
 zone = zone_hi;
 do {
 /* Check if target node can support the allocation. */
-if ( !avail[node] || (avail[node][zone] < request) )
+if ( !avail[node] || (avail[node][zone] < (1UL << order)) )
 continue;
 
 /* Find smallest order which can satisfy the request. */
 for ( j = order; j <= MAX_ORDER; j++ )
 if ( (pg = page_list_remove_head((node, zone, j))) )
-goto found;
+return pg;
 } while ( zone-- > zone_lo ); /* careful: unsigned zone may wrap */
 
 if ( (memflags & MEMF_exact_node) && req_node != NUMA_NO_NODE )
-goto not_found;
+return NULL;
 
 /* Pick next node. */
 if ( !node_isset(node, nodemask) )
@@ -794,46 +759,96 @@ static struct page_info *alloc_heap_pages(
 {
 /* When we have tried all in nodemask, we fall back to others. */
 if ( (memflags & MEMF_exact_node) || nodemask_retry++ )
-goto not_found;
+return NULL;
 nodes_andnot(nodemask, node_online_map, nodemask);
 first_node = node = first_node(nodemask);
 if ( node >= MAX_NUMNODES )
-goto not_found;
+return NULL;
 }
 }
+}
+
+/* Allocate 2^@order contiguous pages. */
+static struct page_info *alloc_heap_pages(
+unsigned int zone_lo, unsigned int zone_hi,
+unsigned int order, unsigned int memflags,
+struct domain *d)
+{
+nodeid_t node;
+unsigned int i, buddy_order, zone, first_dirty;
+unsigned long request = 1UL << order;
+struct page_info *pg;
+bool need_tlbflush = false;
+uint32_t tlbflush_timestamp = 0;
+
+/* Make sure there are enough bits in memflags for nodeID. */
+BUILD_BUG_ON((_MEMF_bits - _MEMF_node) < (8 * sizeof(nodeid_t)));
+
+

[Xen-devel] [PATCH v7 2/9] mm: Place unscrubbed pages at the end of pagelist

.. so that it's easy to find pages that need to be scrubbed (those pages are
now marked with _PGC_need_scrub bit).

We keep track of the first unscrubbed page in a page buddy using first_dirty
field. For now it can have two values, 0 (whole buddy needs scrubbing) or
INVALID_DIRTY_IDX (the buddy does not need to be scrubbed). Subsequent patches
will allow scrubbing to be interrupted, resulting in first_dirty taking any
value.

Signed-off-by: Boris Ostrovsky 
---
Changes in v7
* Simplified tracking dirty pages in reserve_offlined_page() to match how
  it is done in alloc_heap_pages()
* Changed page_info.u.free.need_tlbflush definition to bool:1
* Added BUILD_BUG_ON() to make sure page_info.u stays within unsigned long

 xen/common/page_alloc.c  | 157 ---
 xen/include/asm-arm/mm.h |  18 +-
 xen/include/asm-x86/mm.h |  17 -
 3 files changed, 167 insertions(+), 25 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 330f8ed..b857a44 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -383,6 +383,8 @@ typedef struct page_list_head 
heap_by_zone_and_order_t[NR_ZONES][MAX_ORDER+1];
 static heap_by_zone_and_order_t *_heap[MAX_NUMNODES];
 #define heap(node, zone, order) ((*_heap[node])[zone][order])
 
+static unsigned long node_need_scrub[MAX_NUMNODES];
+
 static unsigned long *avail[MAX_NUMNODES];
 static long total_avail_pages;
 
@@ -678,13 +680,30 @@ static void check_low_mem_virq(void)
 }
 }
 
+/* Pages that need a scrub are added to tail, otherwise to head. */
+static void page_list_add_scrub(struct page_info *pg, unsigned int node,
+unsigned int zone, unsigned int order,
+unsigned int first_dirty)
+{
+PFN_ORDER(pg) = order;
+pg->u.free.first_dirty = first_dirty;
+
+if ( first_dirty != INVALID_DIRTY_IDX )
+{
+ASSERT(first_dirty < (1U << order));
+page_list_add_tail(pg, (node, zone, order));
+}
+else
+page_list_add(pg, (node, zone, order));
+}
+
 /* Allocate 2^@order contiguous pages. */
 static struct page_info *alloc_heap_pages(
 unsigned int zone_lo, unsigned int zone_hi,
 unsigned int order, unsigned int memflags,
 struct domain *d)
 {
-unsigned int i, j, zone = 0, nodemask_retry = 0;
+unsigned int i, j, zone = 0, nodemask_retry = 0, first_dirty;
 nodeid_t first_node, node = MEMF_get_node(memflags), req_node = node;
 unsigned long request = 1UL << order;
 struct page_info *pg;
@@ -798,12 +817,26 @@ static struct page_info *alloc_heap_pages(
 return NULL;
 
  found: 
+
+first_dirty = pg->u.free.first_dirty;
+
 /* We may have to halve the chunk a number of times. */
 while ( j != order )
 {
-PFN_ORDER(pg) = --j;
-page_list_add_tail(pg, (node, zone, j));
-pg += 1 << j;
+j--;
+page_list_add_scrub(pg, node, zone, j,
+(1U << j) > first_dirty ?
+first_dirty : INVALID_DIRTY_IDX);
+pg += 1U << j;
+
+if ( first_dirty != INVALID_DIRTY_IDX )
+{
+/* Adjust first_dirty */
+if ( first_dirty >= 1U << j )
+first_dirty -= 1U << j;
+else
+first_dirty = 0; /* We've moved past original first_dirty */
+}
 }
 
 ASSERT(avail[node][zone] >= request);
@@ -850,12 +883,20 @@ static int reserve_offlined_page(struct page_info *head)
 unsigned int node = phys_to_nid(page_to_maddr(head));
 int zone = page_to_zone(head), i, head_order = PFN_ORDER(head), count = 0;
 struct page_info *cur_head;
-int cur_order;
+unsigned int cur_order, first_dirty;
 
 ASSERT(spin_is_locked(_lock));
 
 cur_head = head;
 
+/*
+ * We may break the buddy so let's mark the head as clean. Then, when
+ * merging chunks back into the heap, we will see whether the chunk has
+ * unscrubbed pages and set its first_dirty properly.
+ */
+first_dirty = head->u.free.first_dirty;
+head->u.free.first_dirty = INVALID_DIRTY_IDX;
+
 page_list_del(head, (node, zone, head_order));
 
 while ( cur_head < (head + (1 << head_order)) )
@@ -866,6 +907,8 @@ static int reserve_offlined_page(struct page_info *head)
 if ( page_state_is(cur_head, offlined) )
 {
 cur_head++;
+if ( first_dirty != INVALID_DIRTY_IDX && first_dirty )
+first_dirty--;
 continue;
 }
 
@@ -892,9 +935,20 @@ static int reserve_offlined_page(struct page_info *head)
 {
 merge:
 /* We don't consider merging outside the head_order. */
-page_list_add_tail(cur_head, (node, zone, cur_order));
-PFN_ORDER(cur_head) = cur_order;
+page_list_add_scrub(cur_head, node, zone, cur_order,
+

Re: [Xen-devel] [PATCH 1/7] arm: traps: psci: use generic register accessors


Hi Andrew

On 08.08.17 23:37, Andrew Cooper wrote:

On 08/08/2017 21:08, Volodymyr Babchuk wrote:

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6cf9ee7..ed78b36 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1449,13 +1449,12 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
  }
  #endif
  
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)

+#define PSCI_ARG(reg,n) get_user_reg(reg, n)
+
  #ifdef CONFIG_ARM_64
-#define PSCI_RESULT_REG(reg) (reg)->x0
-#define PSCI_ARG(reg,n) (reg)->x##n
-#define PSCI_ARG32(reg,n) (uint32_t)( (reg)->x##n & 0x )
+#define PSCI_ARG32(reg,n) (uint32_t)(get_user_reg(reg, n) & 0x)


There is no need for the mask as well as the explicit (uint32_t) cast.
I'd recommend dropping the mask entirely.

Yes, I know this. But Julien asked me to keep this ([1])


If you insist on keeping the mask, then it should be 0xu or
0xull to be compliant with the C standard (A pedantic
compiler will complain that the literal is out of range of int).

Also as you are changing all of these macros, it would be nice to apply
correct style to them, by inserting spaces after all the commas.

Yep, will do. Thanks.


~Andrew


  #else
-#define PSCI_RESULT_REG(reg) (reg)->r0
-#define PSCI_ARG(reg,n) (reg)->r##n
  #define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
  #endif
  




[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113198.html

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

Re: [Xen-devel] [PATCH 4/4] arm: traps: handle SMC32 in check_conditional_instr()


Hi Julien,

On 28.07.17 23:37, Julien Grall wrote:

Hi,

On 07/28/2017 08:43 PM, Volodymyr Babchuk wrote:
On ARMv8 architecture SMC instruction in aarch32 state can be 
conditional.


version + paragraph please.

Also, ARMv8 supports both AArch32 and AArch64. As I said in my answer on 
"arm: smccc: handle SMCs/HVCs according to SMCCC" ([1]), This field 
exists for both architecture. I really don't want to tie the 32-bit port 
to ARMv7. We should be able to use ARMv8 too.

Not sure if I got this.

My ARM 7 ARM (ARM DDI 0406C.c ID051414 page B3-1431) say following:

"SMC instructions cannot be trapped if they fail their condition code 
check.

Therefore, the syndrome information for this exception does not include
conditionality information."

ARMv8 ARM (ARM DDI 0487A.k ID092916) says that SMC from aarch32 state can
be conditional and my patch checks this. But SMC from aarch64 state is
unconditional, so there are nothing to check. At least, when looking at
ISS encoding, i see imm16 field and RES0 field. No conditional flags.


Thus, we should not skip it while checking HSR.EC value. >
For this type of exception special coding of HSR.ISS is used. There is
additional flag to check before perfoming standart handling of CCVALID


performing standard


and COND fields.

Signed-off-by: Volodymyr Babchuk 
---
  xen/arch/arm/traps.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index eae2212..6a21763 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1717,8 +1717,20 @@ static int check_conditional_instr(struct 
cpu_user_regs *regs,

  int cond;
  /* Unconditional Exception classes */
+#ifdef CONFIG_ARM_32
  if ( hsr.ec == HSR_EC_UNKNOWN || hsr.ec >= 0x10 )
  return 1;
+#else
+if ( hsr.ec == HSR_EC_UNKNOWN || (hsr.ec >= 0x10 && hsr.ec != 
HSR_EC_SMC32))

+return 1;
+
+/*
+ * Special case for SMC32: we need to check CCKNOWNPASS before
+ * checking CCVALID


Missing full stop.


+ */
+if (hsr.ec == HSR_EC_SMC32 && hsr.cond.ccknownpass == 0)
+return 1;
+#endif
  /* Check for valid condition in hsr */
  cond = hsr.cond.ccvalid ? hsr.cond.cc : -1;



Cheers,

[1] https://lists.xen.org/archives/html/xen-devel/2017-07/msg01671.html;



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

Re: [Xen-devel] [PATCH 1/7] arm: traps: psci: use generic register accessors

On 08/08/2017 21:08, Volodymyr Babchuk wrote:
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 6cf9ee7..ed78b36 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1449,13 +1449,12 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
> unsigned int code)
>  }
>  #endif
>  
> +#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
> +#define PSCI_ARG(reg,n) get_user_reg(reg, n)
> +
>  #ifdef CONFIG_ARM_64
> -#define PSCI_RESULT_REG(reg) (reg)->x0
> -#define PSCI_ARG(reg,n) (reg)->x##n
> -#define PSCI_ARG32(reg,n) (uint32_t)( (reg)->x##n & 0x )
> +#define PSCI_ARG32(reg,n) (uint32_t)(get_user_reg(reg, n) & 
> 0x)

There is no need for the mask as well as the explicit (uint32_t) cast. 
I'd recommend dropping the mask entirely.

If you insist on keeping the mask, then it should be 0xu or
0xull to be compliant with the C standard (A pedantic
compiler will complain that the literal is out of range of int).

Also as you are changing all of these macros, it would be nice to apply
correct style to them, by inserting spaces after all the commas.

~Andrew

>  #else
> -#define PSCI_RESULT_REG(reg) (reg)->r0
> -#define PSCI_ARG(reg,n) (reg)->r##n
>  #define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
>  #endif
>  
>

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

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

2017-08-08 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4cf3f37c87ba1f9d58072444bd735e40e4779e70
baseline version:
 ovmf 6e414300b5f19d3045a0d21ad90ac2fe965478a5

Last test of basis71950  2017-08-08 08:17:55 Z0 days
Testing same since71951  2017-08-08 17:47:30 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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 4cf3f37c87ba1f9d58072444bd735e40e4779e70
Author: Star Zeng 
Date:   Tue Jul 18 16:32:16 2017 +0800

MdeModulePkg SerialDxe: Process timeout consistently in SerialRead

https://lists.01.org/pipermail/edk2-devel/2017-July/012385.html
reported the timeout processing in SerialRead is not consistent.

Since SerialPortPoll only checks the status of serial port and
returns immediately, and SerialPortRead does not really implement
a time out mechanism and will always wait for enough input,
it will cause below results:
1. If there is no serial input at all, this interface will return
timeout immediately without any waiting;
2. If there is A characters in serial port FIFO, and caller requires
A+1 characters, it will wait until a new input is coming and timeout
will not really occur.

This patch is to update SerialRead() to check SerialPortPoll() and
read data through SerialPortRead() one byte by one byte, and check
timeout against mSerialIoMode.Timeout if no input.

Cc: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
Reviewed-by: Ruiyu Ni 

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

[Xen-devel] [PATCH 1/7] arm: traps: psci: use generic register accessors

From: Volodymyr Babchuk 

There are standard functions set_user_reg() and get_user_reg(). We can
use them in PSCI_SET_RESULT()/PSCI_ARG() macroses instead of relying on
CONFIG_ARM_64 definition.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/traps.c | 38 +-
 1 file changed, 17 insertions(+), 21 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6cf9ee7..ed78b36 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1449,13 +1449,12 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 }
 #endif
 
+#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
+#define PSCI_ARG(reg,n) get_user_reg(reg, n)
+
 #ifdef CONFIG_ARM_64
-#define PSCI_RESULT_REG(reg) (reg)->x0
-#define PSCI_ARG(reg,n) (reg)->x##n
-#define PSCI_ARG32(reg,n) (uint32_t)( (reg)->x##n & 0x )
+#define PSCI_ARG32(reg,n) (uint32_t)(get_user_reg(reg, n) & 0x)
 #else
-#define PSCI_RESULT_REG(reg) (reg)->r0
-#define PSCI_ARG(reg,n) (reg)->r##n
 #define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
 #endif
 
@@ -1470,14 +1469,14 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 register_t fid = PSCI_ARG(regs,0);
 
 /* preloading in case psci_mode_check fails */
-PSCI_RESULT_REG(regs) = PSCI_INVALID_PARAMETERS;
+PSCI_SET_RESULT(regs, PSCI_INVALID_PARAMETERS);
 switch( fid )
 {
 case PSCI_cpu_off:
 {
 uint32_t pstate = PSCI_ARG32(regs,1);
 perfc_incr(vpsci_cpu_off);
-PSCI_RESULT_REG(regs) = do_psci_cpu_off(pstate);
+PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
 }
 break;
 case PSCI_cpu_on:
@@ -1485,36 +1484,36 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 uint32_t vcpuid = PSCI_ARG32(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 perfc_incr(vpsci_cpu_on);
-PSCI_RESULT_REG(regs) = do_psci_cpu_on(vcpuid, epoint);
+PSCI_SET_RESULT(regs, do_psci_cpu_on(vcpuid, epoint));
 }
 break;
 case PSCI_0_2_FN_PSCI_VERSION:
 perfc_incr(vpsci_version);
-PSCI_RESULT_REG(regs) = do_psci_0_2_version();
+PSCI_SET_RESULT(regs, do_psci_0_2_version());
 break;
 case PSCI_0_2_FN_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
-PSCI_RESULT_REG(regs) = do_psci_0_2_cpu_off();
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 break;
 case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
-PSCI_RESULT_REG(regs) = do_psci_0_2_migrate_info_type();
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 break;
 case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
 case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
 if ( psci_mode_check(current->domain, fid) )
-PSCI_RESULT_REG(regs) = do_psci_0_2_migrate_info_up_cpu();
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 break;
 case PSCI_0_2_FN_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
 do_psci_0_2_system_off();
-PSCI_RESULT_REG(regs) = PSCI_INTERNAL_FAILURE;
+PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 break;
 case PSCI_0_2_FN_SYSTEM_RESET:
 perfc_incr(vpsci_system_reset);
 do_psci_0_2_system_reset();
-PSCI_RESULT_REG(regs) = PSCI_INTERNAL_FAILURE;
+PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
 break;
 case PSCI_0_2_FN_CPU_ON:
 case PSCI_0_2_FN64_CPU_ON:
@@ -1524,8 +1523,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 register_t vcpuid = PSCI_ARG(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 register_t cid = PSCI_ARG(regs,3);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_cpu_on(vcpuid, epoint, cid);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
 }
 break;
 case PSCI_0_2_FN_CPU_SUSPEND:
@@ -1536,8 +1534,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 uint32_t pstate = PSCI_ARG32(regs,1);
 register_t epoint = PSCI_ARG(regs,2);
 register_t cid = PSCI_ARG(regs,3);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_cpu_suspend(pstate, epoint, cid);
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
 }
 break;
 case PSCI_0_2_FN_AFFINITY_INFO:
@@ -1547,8 +1544,7 @@ static void do_trap_psci(struct cpu_user_regs *regs)
 {
 register_t taff = PSCI_ARG(regs,1);
 uint32_t laff = PSCI_ARG32(regs,2);
-PSCI_RESULT_REG(regs) =
-do_psci_0_2_affinity_info(taff, laff);
+PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
 }
 break;
 case PSCI_0_2_FN_MIGRATE:
@@

[Xen-devel] [PATCH 7/7] arm: vsmc: remove 64 bit mode check in psci handler

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

 - Generic handler checks that 64 bit calls can be made only by
   64 bit guests.

 - SMCCC requires that 64-bit handler should support both 32 and 64 bit
   calls even if they originate from 64 bit caller.

This patch removes that extra check.

Also, as there are no more natural scope ( if { } ) to hold local variables,
paramters to do_psci_*() are taken right from SMC arguments, without storing
in intermediate local variables.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Stefano Stabellini 
---
Now this patch removes { } blocks completely. Not sure if I had to
split it into two separate patches.

---
 xen/arch/arm/vsmc.c | 45 ++---
 1 file changed, 10 insertions(+), 35 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index ea86eea..0fd4f5a 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -84,14 +84,6 @@ static bool handle_arch(struct cpu_user_regs *regs)
 return false;
 }
 
-/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^
-  ((fid & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT)) >>
-   ARM_SMCCC_CALL_CONV_SHIFT) );
-}
-
 /* PSCI 2.0 interface */
 static bool handle_ssc(struct cpu_user_regs *regs)
 {
@@ -113,8 +105,7 @@ static bool handle_ssc(struct cpu_user_regs *regs)
 return true;
 case PSCI_0_2_FUNC_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 return true;
 case PSCI_0_2_FUNC_SYSTEM_OFF:
 perfc_incr(vpsci_system_off);
@@ -128,40 +119,24 @@ static bool handle_ssc(struct cpu_user_regs *regs)
 return true;
 case PSCI_0_2_FUNC_CPU_ON:
 perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t vcpuid = PSCI_ARG(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
-}
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(PSCI_ARG(regs, 1),
+ PSCI_ARG(regs, 2),
+ PSCI_ARG(regs, 3)));
 return true;
 case PSCI_0_2_FUNC_CPU_SUSPEND:
 perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t pstate = PSCI_ARG32(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
-}
+PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(PSCI_ARG32(regs, 1),
+  PSCI_ARG(regs, 2),
+  PSCI_ARG(regs, 3)));
 return true;
 case PSCI_0_2_FUNC_AFFINITY_INFO:
 perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t taff = PSCI_ARG(regs,1);
-uint32_t laff = PSCI_ARG32(regs,2);
-PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
-}
+PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(PSCI_ARG(regs, 1),
+PSCI_ARG32(regs,2)));
 return true;
 case PSCI_0_2_FUNC_MIGRATE:
 perfc_incr(vpsci_cpu_migrate);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t tcpu = PSCI_ARG32(regs,1);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate(tcpu));
-}
+PSCI_SET_RESULT(regs, do_psci_0_2_migrate(PSCI_ARG32(regs, 1)));
 return true;
 case ARM_SMCCC_FUNC_CALL_COUNT:
 set_user_reg(regs, 0, SSC_SMCCC_FUNCTION_COUNT);
-- 
2.7.4


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

[Xen-devel] [PATCH 5/7] arm: traps: handle PSCI calls inside `smccc.c`

PSCI is part of HVC/SMC interface, so it should be handled in
appropriate place: `vsmc.c`. This patch just moves PSCI
handler calls from `traps.c` to `vsmc.c`.

PSCI is considered as two different "services" in terms of SMCCC.
Older PSCI 1.0 is treated as "architecture service", while never
PSCI 2.0 is defined as "standard secure service".

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 - Added do_trap_hvc() handler in vsmc.c


---
 xen/arch/arm/traps.c  | 124 ++--
 xen/arch/arm/vsmc.c   | 144 ++
 xen/include/asm-arm/vsmc.h|   1 +
 xen/include/public/arch-arm/smc.h |  10 ++-
 4 files changed, 160 insertions(+), 119 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b119dc0..7b296da 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -39,7 +39,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1446,119 +1445,6 @@ static void do_debug_trap(struct cpu_user_regs *regs, 
unsigned int code)
 }
 #endif
 
-#define PSCI_SET_RESULT(reg, val) set_user_reg(reg, 0, val)
-#define PSCI_ARG(reg,n) get_user_reg(reg, n)
-
-#ifdef CONFIG_ARM_64
-#define PSCI_ARG32(reg,n) (uint32_t)(get_user_reg(reg, n) & 0x)
-#else
-#define PSCI_ARG32(reg,n) PSCI_ARG(reg,n)
-#endif
-
-/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
-static void do_trap_psci(struct cpu_user_regs *regs)
-{
-register_t fid = PSCI_ARG(regs,0);
-
-/* preloading in case psci_mode_check fails */
-PSCI_SET_RESULT(regs, PSCI_INVALID_PARAMETERS);
-switch( fid )
-{
-case PSCI_cpu_off:
-{
-uint32_t pstate = PSCI_ARG32(regs,1);
-perfc_incr(vpsci_cpu_off);
-PSCI_SET_RESULT(regs, do_psci_cpu_off(pstate));
-}
-break;
-case PSCI_cpu_on:
-{
-uint32_t vcpuid = PSCI_ARG32(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-perfc_incr(vpsci_cpu_on);
-PSCI_SET_RESULT(regs, do_psci_cpu_on(vcpuid, epoint));
-}
-break;
-case PSCI_0_2_FN_PSCI_VERSION:
-perfc_incr(vpsci_version);
-PSCI_SET_RESULT(regs, do_psci_0_2_version());
-break;
-case PSCI_0_2_FN_CPU_OFF:
-perfc_incr(vpsci_cpu_off);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
-break;
-case PSCI_0_2_FN_MIGRATE_INFO_TYPE:
-perfc_incr(vpsci_migrate_info_type);
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
-break;
-case PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
-case PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
-perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
-break;
-case PSCI_0_2_FN_SYSTEM_OFF:
-perfc_incr(vpsci_system_off);
-do_psci_0_2_system_off();
-PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
-break;
-case PSCI_0_2_FN_SYSTEM_RESET:
-perfc_incr(vpsci_system_reset);
-do_psci_0_2_system_reset();
-PSCI_SET_RESULT(regs, PSCI_INTERNAL_FAILURE);
-break;
-case PSCI_0_2_FN_CPU_ON:
-case PSCI_0_2_FN64_CPU_ON:
-perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t vcpuid = PSCI_ARG(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_on(vcpuid, epoint, cid));
-}
-break;
-case PSCI_0_2_FN_CPU_SUSPEND:
-case PSCI_0_2_FN64_CPU_SUSPEND:
-perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t pstate = PSCI_ARG32(regs,1);
-register_t epoint = PSCI_ARG(regs,2);
-register_t cid = PSCI_ARG(regs,3);
-PSCI_SET_RESULT(regs, do_psci_0_2_cpu_suspend(pstate, epoint, 
cid));
-}
-break;
-case PSCI_0_2_FN_AFFINITY_INFO:
-case PSCI_0_2_FN64_AFFINITY_INFO:
-perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )
-{
-register_t taff = PSCI_ARG(regs,1);
-uint32_t laff = PSCI_ARG32(regs,2);
-PSCI_SET_RESULT(regs, do_psci_0_2_affinity_info(taff, laff));
-}
-break;
-case PSCI_0_2_FN_MIGRATE:
-case PSCI_0_2_FN64_MIGRATE:
-perfc_incr(vpsci_cpu_migrate);
-if ( psci_mode_check(current->domain, fid) )
-{
-uint32_t tcpu = PSCI_ARG32(regs,1);
-

[Xen-devel] [PATCH 6/7] arm: psci: use definitions provided by vsmc.h

vsmc.h provides definitions to construct SMC call function number according
to SMCCC. We don't need multiple definitions for one thing, and definitions
in vsmc.h are more generic than ones used in psci.h.

So psci.h will only provide function codes and whole SMC function number
will be constructed using generic macroses from vsmc.h.

This change also affects vsmc.c and seattle.c, because they both use PSCI
function numbers.

Signed-off-by: Volodymyr Babchuk 
---
This is new patch, suggested by Julien Grail.

---
 xen/arch/arm/platforms/seattle.c |  5 +++--
 xen/arch/arm/psci.c  | 12 ++--
 xen/arch/arm/vsmc.c  | 26 +
 xen/include/asm-arm/psci.h   | 41 ++--
 4 files changed, 41 insertions(+), 43 deletions(-)

diff --git a/xen/arch/arm/platforms/seattle.c b/xen/arch/arm/platforms/seattle.c
index 86dce91..679632d 100644
--- a/xen/arch/arm/platforms/seattle.c
+++ b/xen/arch/arm/platforms/seattle.c
@@ -19,6 +19,7 @@
 
 #include 
 #include 
+#include 
 
 static const char * const seattle_dt_compat[] __initconst =
 {
@@ -33,12 +34,12 @@ static const char * const seattle_dt_compat[] __initconst =
  */
 static void seattle_system_reset(void)
 {
-call_smc(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(PSCI_0_2_FUNC_SYSTEM_RESET), 0, 0, 0);
 }
 
 static void seattle_system_off(void)
 {
-call_smc(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(PSCI_0_2_FUNC_SYSTEM_OFF), 0, 0, 0);
 }
 
 PLATFORM_START(seattle, "SEATTLE")
diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
index 34ee97e..4b01131 100644
--- a/xen/arch/arm/psci.c
+++ b/xen/arch/arm/psci.c
@@ -31,9 +31,9 @@
  * (native-width) function ID.
  */
 #ifdef CONFIG_ARM_64
-#define PSCI_0_2_FN_NATIVE(name)   PSCI_0_2_FN64_##name
+#define PSCI_0_2_FN_NATIVE(n)   PSCI_0_2_FN64(n)
 #else
-#define PSCI_0_2_FN_NATIVE(name)   PSCI_0_2_FN_##name
+#define PSCI_0_2_FN_NATIVE(n)   PSCI_0_2_FN32(n)
 #endif
 
 uint32_t psci_ver;
@@ -48,13 +48,13 @@ int call_psci_cpu_on(int cpu)
 void call_psci_system_off(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(PSCI_0_2_FUNC_SYSTEM_OFF), 0, 0, 0);
 }
 
 void call_psci_system_reset(void)
 {
 if ( psci_ver > PSCI_VERSION(0, 1) )
-call_smc(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+call_smc(PSCI_0_2_FN32(PSCI_0_2_FUNC_SYSTEM_RESET), 0, 0, 0);
 }
 
 int __init psci_is_smc_method(const struct dt_device_node *psci)
@@ -144,7 +144,7 @@ int __init psci_init_0_2(void)
 }
 }
 
-psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
+psci_ver = call_smc(PSCI_0_2_FN32(PSCI_0_2_FUNC_PSCI_VERSION), 0, 0, 0);
 
 /* For the moment, we only support PSCI 0.2 and PSCI 1.x */
 if ( psci_ver != PSCI_VERSION(0, 2) && PSCI_VERSION_MAJOR(psci_ver) != 1 )
@@ -154,7 +154,7 @@ int __init psci_init_0_2(void)
 return -EOPNOTSUPP;
 }
 
-psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(CPU_ON);
+psci_cpu_on_nr = PSCI_0_2_FN_NATIVE(PSCI_0_2_FUNC_CPU_ON);
 
 printk(XENLOG_INFO "Using PSCI-%u.%u for SMP bringup\n",
PSCI_VERSION_MAJOR(psci_ver), PSCI_VERSION_MINOR(psci_ver));
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 718b30f..ea86eea 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -87,7 +87,9 @@ static bool handle_arch(struct cpu_user_regs *regs)
 /* helper function for checking arm mode 32/64 bit */
 static inline int psci_mode_check(struct domain *d, register_t fid)
 {
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
+return !( is_64bit_domain(d)^
+  ((fid & (ARM_SMCCC_SMC_64 << ARM_SMCCC_CALL_CONV_SHIFT)) >>
+   ARM_SMCCC_CALL_CONV_SHIFT) );
 }
 
 /* PSCI 2.0 interface */
@@ -97,34 +99,34 @@ static bool handle_ssc(struct cpu_user_regs *regs)
 
 switch ( ARM_SMCCC_FUNC_NUM(fid) )
 {
-case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_PSCI_VERSION):
+case PSCI_0_2_FUNC_PSCI_VERSION:
 perfc_incr(vpsci_version);
 PSCI_SET_RESULT(regs, do_psci_0_2_version());
 return true;
-case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_OFF):
+case PSCI_0_2_FUNC_CPU_OFF:
 perfc_incr(vpsci_cpu_off);
 PSCI_SET_RESULT(regs, do_psci_0_2_cpu_off());
 return true;
-case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_TYPE):
+case PSCI_0_2_FUNC_MIGRATE_INFO_TYPE:
 perfc_incr(vpsci_migrate_info_type);
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_type());
 return true;
-case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
+case PSCI_0_2_FUNC_MIGRATE_INFO_UP_CPU:
 perfc_incr(vpsci_migrate_info_up_cpu);
 if ( psci_mode_check(current->domain, fid) )
 PSCI_SET_RESULT(regs, do_psci_0_2_migrate_info_up_cpu());
 return true;
-case

[Xen-devel] [PATCH 2/7] arm: make processor-specific functions from traps.c globaly visible

From: Volodymyr Babchuk 

The following list of functions:

 - advance_pc()
 - check_conditional_instr()
 - inject_undef_exception()
 - inject_iabt_exception()
 - inject_dabt_exception()
 - inject_vabt_exception()

are now globaly visible. This change is needed becase we plan to handle SMCs
in different file and handler code needs to alter state of a guest.

Signed-off-by: Volodymyr Babchuk 
---
 xen/arch/arm/traps.c| 16 ++--
 xen/include/asm-arm/processor.h | 11 +++
 2 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ed78b36..0171c1c 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -616,8 +616,7 @@ static void inject_iabt64_exception(struct cpu_user_regs 
*regs,
 
 #endif
 
-static void inject_undef_exception(struct cpu_user_regs *regs,
-   const union hsr hsr)
+void inject_undef_exception(struct cpu_user_regs *regs, const union hsr hsr)
 {
 if ( is_32bit_domain(current->domain) )
 inject_undef32_exception(regs);
@@ -627,8 +626,7 @@ static void inject_undef_exception(struct cpu_user_regs 
*regs,
 #endif
 }
 
-static void inject_iabt_exception(struct cpu_user_regs *regs,
-  register_t addr,
+void inject_iabt_exception(struct cpu_user_regs *regs, register_t addr,
   int instr_len)
 {
 if ( is_32bit_domain(current->domain) )
@@ -639,8 +637,7 @@ static void inject_iabt_exception(struct cpu_user_regs 
*regs,
 #endif
 }
 
-static void inject_dabt_exception(struct cpu_user_regs *regs,
-  register_t addr,
+void inject_dabt_exception(struct cpu_user_regs *regs, register_t addr,
   int instr_len)
 {
 if ( is_32bit_domain(current->domain) )
@@ -652,7 +649,7 @@ static void inject_dabt_exception(struct cpu_user_regs 
*regs,
 }
 
 /* Inject a virtual Abort/SError into the guest. */
-static void inject_vabt_exception(struct cpu_user_regs *regs)
+void inject_vabt_exception(struct cpu_user_regs *regs)
 {
 const union hsr hsr = { .bits = regs->hsr };
 
@@ -1706,8 +1703,7 @@ static const unsigned short cc_map[16] = {
 0   /* NV */
 };
 
-static int check_conditional_instr(struct cpu_user_regs *regs,
-   const union hsr hsr)
+int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr)
 {
 unsigned long cpsr, cpsr_cond;
 int cond;
@@ -1752,7 +1748,7 @@ static int check_conditional_instr(struct cpu_user_regs 
*regs,
 return 1;
 }
 
-static void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
+void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
 {
 unsigned long itbits, cond, cpsr = regs->cpsr;
 
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1..6347048 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -686,6 +686,17 @@ void init_traps(void);
 
 void panic_PAR(uint64_t par);
 
+void advance_pc(struct cpu_user_regs *regs, const union hsr hsr);
+
+int check_conditional_instr(struct cpu_user_regs *regs, const union hsr hsr);
+
+void inject_undef_exception(struct cpu_user_regs *regs, const union hsr hsr);
+void inject_iabt_exception(struct cpu_user_regs *regs, register_t addr,
+   int instr_len);
+void inject_dabt_exception(struct cpu_user_regs *regs, register_t addr,
+   int instr_len);
+void inject_vabt_exception(struct cpu_user_regs *regs);
+
 void show_execution_state(struct cpu_user_regs *regs);
 void show_registers(struct cpu_user_regs *regs);
 //#define dump_execution_state() run_in_exception_handler(show_execution_state)
-- 
2.7.4


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

[Xen-devel] [PATCH 3/7] arm: traps: check if SMC was conditional before handling it

On certain ARM arhcitectures SMC instruction can be conditional
(ARM DDI 0487A.k page D7-1949) and we need to check if that
conditional was meet.

Signed-off-by: Volodymyr Babchuk 
---
This patch was separated from the next one

---
 xen/arch/arm/traps.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 0171c1c..e14e7c0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2773,6 +2773,12 @@ static void do_trap_smc(struct cpu_user_regs *regs, 
const union hsr hsr)
 {
 int rc = 0;
 
+if ( !check_conditional_instr(regs, hsr) )
+{
+advance_pc(regs, hsr);
+return;
+}
+
 if ( current->domain->arch.monitor.privileged_call_enabled )
 rc = monitor_smc();
 
-- 
2.7.4


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

[Xen-devel] [PATCH v3 0/7] Handle SMCs and HVCs in conformance with SMCCC

Hello all,

This is third version. Instead of 4 patches, there are 7 now.
As part of the series, I make some functions in traps.c
available globally, moved SMC conditional check into
separate patch, changed how PSCI functiond numbers are defined.

Per-patch changes are described in corresponding patch messages.


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

[Xen-devel] [PATCH 4/7] arm: smccc: handle SMCs according to SMCCC

SMCCC (SMC Call Convention) describes how to handle both HVCs and SMCs.
SMCCC states that both HVC and SMC are valid conduits to call to a different
firmware functions. Thus, for example PSCI calls can be made both by
SMC or HVC. Also SMCCC defines function number coding for such calls.
Besides functional calls there are query calls, which allows underling
OS determine version, UID and number of functions provided by service
provider.

This patch adds new file `vsmc.c`, which handles both generic SMCs
and HVC according to SMC. At this moment it implements only one
service: Standard Hypervisor Service.

Standard Hypervisor Service only supports query calls, so caller can
ask about hypervisor UID and determine that it is XEN running.

This change allows more generic handling for SMCs and HVCs and it can
be easily extended to support new services and functions.

But, before SMC is forwarded to standard SMCCC handler, it can be routed
to a domain monitor, if one is installed.

Signed-off-by: Volodymyr Babchuk 
Reviewed-by: Oleksandr Andrushchenko 
Reviewed-by: Oleksandr Tyshchenko 
---
 - Updated description to indicate that this patch affects only SMC call path.
 - added "xen_" prefix to definitions in include/public/arch-arm/smc.h
 - moved do_trap_smc() into vsmc.c from traps.c
 - replaced all tabs with spaces

---
 xen/arch/arm/Makefile |   1 +
 xen/arch/arm/traps.c  |  19 +-
 xen/arch/arm/vsmc.c   | 139 ++
 xen/include/asm-arm/vsmc.h|  94 ++
 xen/include/public/arch-arm/smc.h |  68 +++
 5 files changed, 303 insertions(+), 18 deletions(-)
 create mode 100644 xen/arch/arm/vsmc.c
 create mode 100644 xen/include/asm-arm/vsmc.h
 create mode 100644 xen/include/public/arch-arm/smc.h

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 49e1fb2..4efd01c 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_HAS_GICV3) += vgic-v3.o
 obj-$(CONFIG_HAS_ITS) += vgic-v3-its.o
 obj-y += vm_event.o
 obj-y += vtimer.o
+obj-y += vsmc.o
 obj-y += vpsci.o
 obj-y += vuart.o
 
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index e14e7c0..b119dc0 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -43,7 +43,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "decode.h"
 #include "vtimer.h"
@@ -2769,23 +2769,6 @@ static void do_trap_data_abort_guest(struct 
cpu_user_regs *regs,
 inject_dabt_exception(regs, info.gva, hsr.len);
 }
 
-static void do_trap_smc(struct cpu_user_regs *regs, const union hsr hsr)
-{
-int rc = 0;
-
-if ( !check_conditional_instr(regs, hsr) )
-{
-advance_pc(regs, hsr);
-return;
-}
-
-if ( current->domain->arch.monitor.privileged_call_enabled )
-rc = monitor_smc();
-
-if ( rc != 1 )
-inject_undef_exception(regs, hsr);
-}
-
 static void enter_hypervisor_head(struct cpu_user_regs *regs)
 {
 if ( guest_mode(regs) )
diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
new file mode 100644
index 000..5ef6167
--- /dev/null
+++ b/xen/arch/arm/vsmc.c
@@ -0,0 +1,139 @@
+/*
+ * xen/arch/arm/vsmc.c
+ *
+ * Generic handler for SMC and HVC calls according to
+ * ARM SMC calling convention
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Number of functions currently supported by Hypervisor Service. */
+#define XEN_SMCCC_FUNCTION_COUNT 3
+
+/* SMCCC interface for hypervisor. Tell about itself. */
+static bool handle_hypervisor(struct cpu_user_regs *regs)
+{
+switch ( ARM_SMCCC_FUNC_NUM(get_user_reg(regs, 0)) )
+{
+case ARM_SMCCC_FUNC_CALL_COUNT:
+set_user_reg(regs, 0, XEN_SMCCC_FUNCTION_COUNT);
+return true;
+case ARM_SMCCC_FUNC_CALL_UID:
+set_user_reg(regs, 0, XEN_SMCCC_UID.a[0]);
+set_user_reg(regs, 1, XEN_SMCCC_UID.a[1]);
+set_user_reg(regs, 2, XEN_SMCCC_UID.a[2]);
+set_user_reg(regs, 3, XEN_SMCCC_UID.a[3]);
+return true;
+case ARM_SMCCC_FUNC_CALL_REVISION:
+set_user_reg(regs, 0, XEN_SMCCC_MAJOR_REVISION);
+set_user_reg(regs, 1, XEN_SMCCC_MINOR_REVISION);
+return true;
+}
+return false;
+}
+
+/*
+ * vsmc_handle_call() - handle SMC/HVC call according to ARM SMCCC.
+ * returns true if that was valid SMCCC call (even if function number
+ * was unkown).
+ */
+static bool

Re: [Xen-devel] [PATCH v1 3/3] xl: enable per-VCPU extratime flag for RTDS

On Tue, Aug 8, 2017 at 9:09 AM, Dario Faggioli
 wrote:
> On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
>> On Sun, Aug 6, 2017 at 12:22 PM, Meng Xu 
>> wrote:
>> >
>> > diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
>> > index 2c71a9f..88933a4 100644
>> > --- a/tools/xl/xl_cmdtable.c
>> > +++ b/tools/xl/xl_cmdtable.c
>> > @@ -272,12 +272,13 @@ struct cmd_spec cmd_table[] = {
>> >  { "sched-rtds",
>> >_sched_rtds, 0, 1,
>> >"Get/set rtds scheduler parameters",
>> > -  "[-d  [-v[=VCPUID/all]] [-p[=PERIOD]] [-
>> > b[=BUDGET]]]",
>> > +  "[-d  [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]]
>> > [-e[=EXTRATIME]]]",
>> >"-d DOMAIN, --domain=DOMAIN Domain to modify\n"
>> >"-v VCPUID/all, --vcpuid=VCPUID/allVCPU to modify or
>> > output;\n"
>> >"   Using '-v all' to modify/output all vcpus\n"
>> >"-p PERIOD, --period=PERIOD Period (us)\n"
>> >"-b BUDGET, --budget=BUDGET Budget (us)\n"
>> > +  "-e EXTRATIME, --extratime=EXTRATIME EXTRATIME (1=yes,
>> > 0=no)\n"
>>
>> Hi Dario,
>>
>> I kept the EXTRATIME value for -e option because: (1) it may be more
>> intuitive for users; (2) it needs much less code change than the
>> input
>> style that does not need EXTRATIME value.
>>
> I'm of the opposite view.
>
> But again, it's tools' people views' that count. :-D
>
>> As to (1), if users want to set some VCPUs with extratime flag set
>> and
>> some with extratime flag clear, there are two types of input:
>> (a) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -e 0 -v 2 -p 1 -b
>> 4000 -e 1 -v 5 -p 1 -b 4000 -e 0
>> (b) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -v 2 -p 1 -b 4000 -e
>> 1 -v 5 -p 1 -b 4000
>> I felt that the style (a) is more intuitive and the input commands
>> have very static pattern, i.e., each vcpu must have -v -p -b -e
>> options set.
>>
> Exactly, I do think that (b) is indeed a better user interface.
>
> For instance, what if I want to change period and budget of vcpu 1 of
> domain 3, _without_ changing whether or not it can use the extra time.

With the approach (b), what I have in my mind was: if users do not use
-e option for a vcpu index, the vcpu will have its extratime flag
cleared.
If not-setting -e option for a VCPU means using the current extratime
value for the VCPU, then how should users clear the extratime flag for
a VCPU? Are you indicating the -e option has three meanings:
If -e option is set without value, keep the extratime value unchanged;
If -e option is set with value 0, clear the extratime value;
If -e option is set with value 1, set the extratime value.


If you look at the -p and -b option for the xl sched-rtds, we will
find that users will have to first read both parameters of a VCPU even
if they only want to change the value for one parameter, either -p or
-b. We don't allow users to specify -p or -b without an input value.

By looking at how -p and -b options are handled, I leaned to the
approach (a): users must input a value for the -e option,  similar to
how  the -p and -b options are handled.

>
> With (a), I don't think I can do that. Or at least, I'd have to either
> remember or check what extratime is right now, and pass that same value
> explicitly to `xl sched-rtds -d 3 -v 1 ...'.
>
> That does not look super user-friendly to me.
>
>> As to (2), if we go with -e without EXTRATIME, we will have to keep
>> track of the vcpu that has no -e option. I thought about this option,
>> we can pre-set the extratime value to false when -v option is
>> assigned:
>> case 'v':
>> ...
>> extratimes[v_index]  = 0;
>>
>> and set the extratimes[v_index] = 0 when -e is set.
>>
> Yes, something like that. Or, even better, use its current value.
>
> That would require calling libxl_vcpu_sched_params_get() (or, at times,
> libxl_vcpu_sched_params_get_all()), which I assumed you were doing
> already, while you apparently don't. Mmm...
>
>> This approach is not very neat in the code: we have to reallocate
>> memory for extratimes array when its size is not enough; we also have
>> to deal with the special case when -e is set before -v, such as the
>> command "xl sched-rtds -p 1 -b 4000 -e -v 0"
>>
> Err... sorry, there's code for reallocations in this patch already,
> isn't this the case?
>
> Also, it may be me, but I don't understand how this is different from
> how -b and -p are dealt with.
>
> Regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

Thanks,

Meng

-- 
---
Meng Xu
PhD Candidate 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 v1 1/3] xen:rtds: towards work conserving RTDS

On Tue, Aug 8, 2017 at 10:57 AM, Dario Faggioli
 wrote:
> On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
>> Make RTDS scheduler work conserving without breaking the real-time
>> guarantees.
>>
>> VCPU model:
>> Each real-time VCPU is extended to have an extratime flag
>> and a priority_level field.
>> When a VCPU's budget is depleted in the current period,
>> if it has extratime flag set,
>> its priority_level will increase by 1 and its budget will be
>> refilled;
>> othewrise, the VCPU will be moved to the depletedq.
>>
>> Scheduling policy is modified global EDF:
>> A VCPU v1 has higher priority than another VCPU v2 if
>> (i) v1 has smaller priority_leve; or
>> (ii) v1 has the same priority_level but has a smaller deadline
>>
>> Queue management:
>> Run queue holds VCPUs with extratime flag set and VCPUs with
>> remaining budget. Run queue is sorted in increasing order of VCPUs
>> priorities.
>> Depleted queue holds VCPUs which have extratime flag cleared and
>> depleted budget.
>> Replenished queue is not modified.
>>
>> Signed-off-by: Meng Xu 
>>
> This looks mostly good to me.
>
> There are only a couple of things left, in addition to the
> changlog+comment mention to how the 'spare bandwidth' distribution
> works, that we agreed upon in the other thread.
>
>> --- a/xen/common/sched_rt.c
>> +++ b/xen/common/sched_rt.c
>> @@ -245,6 +258,11 @@ static inline struct list_head *rt_replq(const
>> struct scheduler *ops)
>>  return _priv(ops)->replq;
>>  }
>>
>> +static inline bool has_extratime(const struct rt_vcpu *svc)
>> +{
>> +return (svc->flags & RTDS_extratime) ? 1 : 0;
>> +}
>> +
>>
> Cool... I like 'has_extratime()' soo much better as a name than what it
> was before! Thanks. :-)
>

:-)

>>  /*
>>   * Helper functions for manipulating the runqueue, the depleted
>> queue,
>>   * and the replenishment events queue.
>> @@ -274,6 +292,21 @@ vcpu_on_replq(const struct rt_vcpu *svc)
>>  }
>>
>>  /*
>> + * If v1 priority >= v2 priority, return value > 0
>> + * Otherwise, return value < 0
>> + */
>> +static s_time_t
>> +compare_vcpu_priority(const struct rt_vcpu *v1, const struct rt_vcpu
>> *v2)
>> +{
>> +int prio = v2->priority_level - v1->priority_level;
>> +
>> +if ( prio == 0 )
>> +return v2->cur_deadline - v1->cur_deadline;
>> +
> Indentation.

Oh, sorry. Will correct it.

>
>> @@ -423,15 +459,18 @@ rt_update_deadline(s_time_t now, struct rt_vcpu
>> *svc)
>>   */
>>  svc->last_start = now;
>>  svc->cur_budget = svc->budget;
>> +svc->priority_level = 0;
>>
>>  /* TRACE */
>>  {
>>  struct __packed {
>>  unsigned vcpu:16, dom:16;
>> +unsigned priority_level;
>>  uint64_t cur_deadline, cur_budget;
>>  } d;
>>
> Can you please, and in this very comment, update
> tools/xentrace/xenalyze.c and tools/xentrace/formats as well, to take
> into account this new field?

Sure. Will do in the next version.

>
>> diff --git a/xen/include/public/domctl.h
>> b/xen/include/public/domctl.h
>> index 0669c31..ba5daa9 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -360,6 +360,9 @@ typedef struct xen_domctl_sched_credit2 {
>>  typedef struct xen_domctl_sched_rtds {
>>  uint32_t period;
>>  uint32_t budget;
>> +#define _XEN_DOMCTL_SCHED_RTDS_extratime 0
>> +#define
>> XEN_DOMCTL_SCHED_RTDS_extratime  (1U<<_XEN_DOMCTL_SCHED_RTDS_extratim
>> e)
>> +uint32_t flags;
>>
> I'd add a one liner comment above the flag definition, as, for
> instance, how things are done in createdomain:

Sure.

How about comment:
/* Does this VCPU get extratime beyond reserved time? */

>
> struct xen_domctl_createdomain {
> /* IN parameters */
> uint32_t ssidref;
> xen_domain_handle_t handle;
>  /* Is this an HVM guest (as opposed to a PVH or PV guest)? */
> #define _XEN_DOMCTL_CDF_hvm_guest 0
> #define XEN_DOMCTL_CDF_hvm_guest  (1U<<_XEN_DOMCTL_CDF_hvm_guest)
>  /* Use hardware-assisted paging if available? */
> #define _XEN_DOMCTL_CDF_hap   1
> #define XEN_DOMCTL_CDF_hap(1U<<_XEN_DOMCTL_CDF_hap)
>
> Also, consider shortening the name (e.g., by contracting the SCHED_RTDS
> part; it does not matter if it's not 100% equal to what's in
> sched_rt.c, I think).


How about shorten it to XEN_DOMCTL_RTDS_extra or XEN_DOMCTL_RTDS_extratime?

>
> This, of course, is just my opinion, and final say belongs to
> maintainers of this public interface, which I think means 'THE REST',
> and most of them are not Cc-ed. Let me do that...

Thank you very much!

Best,

Meng

-- 
---
Meng Xu
PhD Candidate 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

[Xen-devel] [linux-linus test] 112514: regressions - trouble: blocked/broken/fail/pass

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-examine  7 reboot   fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-debianhvm-amd64  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qcow2 7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-vhd  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 110515
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-intel  7 xen-bootfail REGR. vs. 110515
 test-amd64-amd64-pygrub   7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 110515
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 110515
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 110515
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 110515
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 build-arm64-pvops 2 hosts-allocate broken REGR. vs. 110515
 build-arm64-xsm   2 hosts-allocate broken REGR. vs. 110515
 build-arm64   2 hosts-allocate broken REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   3 capture-logs  broken blocked in 110515
 build-arm64-pvops 3 capture-logs  broken blocked in 110515
 build-arm64   3 capture-logs  broken blocked in 110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110515
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13

Re: [Xen-devel] [PATCH v8 2/2] x86/monitor: Notify monitor if an emulation fails.

2017-08-08 Thread Tamas K Lengyel

On Tue, Aug 8, 2017 at 12:06 PM, Petre Pircalabu  wrote:

> If case of a vm_event with the emulate_flags set, if the instruction
> is not implemented by the emulator, the monitor should be notified instead
> of directly injecting a hw exception.
> This behavior can be used to re-execute an instruction not supported by
> the emulator using the real processor (e.g. altp2m) instead of just
> crashing.
>
> Signed-off-by: Petre Pircalabu 
>

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

[Xen-devel] [PATCH v8 0/2] Singlestep unimplemented x86emul instructions

2017-08-08 Thread Petre Pircalabu

This patchset implements a new way of handling the instructions unimplemented
in x86emul. Instead of inserting a hardware exception the monitor will
be notified and it will to try to single-step the faulty instruction using the
real processor and then resume execution of the normal instruction flow.

---
Changed since v1:
  * Removed the emulation kind check when calling hvm_inject_hw_exception

Changed since v2:
  * Removed a file added by mistake

Changed since v3:
  * Removed extra stray line
  * Added the _enabled suffix to the emul_unhandleable monitor option

Changed since v4
  * Fixed return expression of hvm_monitor_emul_unhandleable handle
  monitor_traps failures.
  * Removed stray parantheses.

Changed since v5:
  * Removed unnecessary "else" when calling hvm_monitor_emul_unhandleable.
  * Added extra line in arch_monitor_domctl_event.

Changed since v6:
  * add the distinction between unimplemented instructions and emulation 
failures.
  * changed "emul_unhandleable" event name to "emul_unimplemented"

Changed since v7:
  * Add "fall-through" comments to the switch statements (coverity)
  * Added X86EMUL_UNIMPLEMENTED to X86EMUL_UNHANDLEABLE checks the in functions
  referencing x86_emulate.
  * Improved comment describing X86EMUL_UNIMPLEMENTED.


Petre Pircalabu (2):
  x86emul: New return code for unimplemented instruction
  x86/monitor: Notify monitor if an emulation fails.

 tools/libxc/include/xenctrl.h  |  2 ++
 tools/libxc/xc_monitor.c   | 14 ++
 xen/arch/x86/hvm/emulate.c |  8 
 xen/arch/x86/hvm/io.c  |  2 ++
 xen/arch/x86/hvm/monitor.c | 17 +
 xen/arch/x86/hvm/vmx/realmode.c|  2 +-
 xen/arch/x86/mm/shadow/multi.c |  2 +-
 xen/arch/x86/monitor.c | 13 +
 xen/arch/x86/x86_emulate/x86_emulate.c |  8 
 xen/arch/x86/x86_emulate/x86_emulate.h |  6 ++
 xen/include/asm-x86/domain.h   |  1 +
 xen/include/asm-x86/hvm/monitor.h  |  1 +
 xen/include/asm-x86/monitor.h  |  3 ++-
 xen/include/public/domctl.h|  1 +
 xen/include/public/vm_event.h  |  2 ++
 15 files changed, 75 insertions(+), 7 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v8 2/2] x86/monitor: Notify monitor if an emulation fails.

2017-08-08 Thread Petre Pircalabu

If case of a vm_event with the emulate_flags set, if the instruction
is not implemented by the emulator, the monitor should be notified instead
of directly injecting a hw exception.
This behavior can be used to re-execute an instruction not supported by
the emulator using the real processor (e.g. altp2m) instead of just
crashing.

Signed-off-by: Petre Pircalabu 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_monitor.c  | 14 ++
 xen/arch/x86/hvm/emulate.c|  4 
 xen/arch/x86/hvm/monitor.c| 17 +
 xen/arch/x86/monitor.c| 13 +
 xen/include/asm-x86/domain.h  |  1 +
 xen/include/asm-x86/hvm/monitor.h |  1 +
 xen/include/asm-x86/monitor.h |  3 ++-
 xen/include/public/domctl.h   |  1 +
 xen/include/public/vm_event.h |  2 ++
 10 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index c7710b8..abb9cac 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2027,6 +2027,8 @@ int xc_monitor_debug_exceptions(xc_interface *xch, 
domid_t domain_id,
 int xc_monitor_cpuid(xc_interface *xch, domid_t domain_id, bool enable);
 int xc_monitor_privileged_call(xc_interface *xch, domid_t domain_id,
bool enable);
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+  bool enable);
 /**
  * This function enables / disables emulation for each REP for a
  * REP-compatible instruction.
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index b44ce93..8a76ec1 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -216,6 +216,20 @@ int xc_monitor_privileged_call(xc_interface *xch, domid_t 
domain_id,
 return do_domctl(xch, );
 }
 
+int xc_monitor_emul_unimplemented(xc_interface *xch, domid_t domain_id,
+  bool enable)
+{
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_monitor_op;
+domctl.domain = domain_id;
+domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
+: XEN_DOMCTL_MONITOR_OP_DISABLE;
+domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED;
+
+return do_domctl(xch, );
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 28133c0..64a17f1 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -14,12 +14,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2116,6 +2118,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
  */
 return;
 case X86EMUL_UNIMPLEMENTED:
+if ( hvm_monitor_emul_unimplemented() )
+return;
 /* fall-through */
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
index a7ccfc4..3551463 100644
--- a/xen/arch/x86/hvm/monitor.c
+++ b/xen/arch/x86/hvm/monitor.c
@@ -57,6 +57,23 @@ bool_t hvm_monitor_cr(unsigned int index, unsigned long 
value, unsigned long old
 return 0;
 }
 
+bool hvm_monitor_emul_unimplemented(void)
+{
+struct vcpu *curr = current;
+
+/*
+ * Send a vm_event to the monitor to signal that the current
+ * instruction couldn't be emulated.
+ */
+vm_event_request_t req = {
+.reason = VM_EVENT_REASON_EMUL_UNIMPLEMENTED,
+.vcpu_id  = curr->vcpu_id,
+};
+
+return curr->domain->arch.monitor.emul_unimplemented_enabled &&
+monitor_traps(curr, true, ) == 1;
+}
+
 void hvm_monitor_msr(unsigned int msr, uint64_t value)
 {
 struct vcpu *curr = current;
diff --git a/xen/arch/x86/monitor.c b/xen/arch/x86/monitor.c
index 706454f..e59f1f5 100644
--- a/xen/arch/x86/monitor.c
+++ b/xen/arch/x86/monitor.c
@@ -283,6 +283,19 @@ int arch_monitor_domctl_event(struct domain *d,
 break;
 }
 
+case XEN_DOMCTL_MONITOR_EVENT_EMUL_UNIMPLEMENTED:
+{
+bool old_status = ad->monitor.emul_unimplemented_enabled;
+
+if ( unlikely(old_status == requested_status) )
+return -EEXIST;
+
+domain_pause(d);
+ad->monitor.emul_unimplemented_enabled = requested_status;
+domain_unpause(d);
+break;
+}
+
 default:
 /*
  * Should not be reached unless arch_monitor_get_capabilities() is
diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h
index c10522b..091447d 100644
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -405,6 +405,7 @@ struct arch_domain
 unsigned int debug_exception_sync: 1;
 unsigned int cpuid_enabled   : 1;
 unsigned int

[Xen-devel] [PATCH v8 1/2] x86emul: New return code for unimplemented instruction

2017-08-08 Thread Petre Pircalabu

Enforce the distinction between an instruction not implemented by the
emulator and the failure to emulate that instruction by defining a new
return code, X86EMUL_UNIMPLEMENTED.

This value should only be used by the core emulator if it fails to decode
the current instruction, and not by any of the x86_emulate_ops
callbacks.

Signed-off-by: Petre Pircalabu 
---
 xen/arch/x86/hvm/emulate.c | 4 
 xen/arch/x86/hvm/io.c  | 2 ++
 xen/arch/x86/hvm/vmx/realmode.c| 2 +-
 xen/arch/x86/mm/shadow/multi.c | 2 +-
 xen/arch/x86/x86_emulate/x86_emulate.c | 8 
 xen/arch/x86/x86_emulate/x86_emulate.h | 6 ++
 6 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 3a8db21..28133c0 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -2044,6 +2044,8 @@ int hvm_emulate_one_mmio(unsigned long mfn, unsigned long 
gla)
 switch ( rc )
 {
 case X86EMUL_UNHANDLEABLE:
+/* fall-through */
+case X86EMUL_UNIMPLEMENTED:
 hvm_dump_emulation_state(XENLOG_G_WARNING, "MMCFG", );
 break;
 case X86EMUL_EXCEPTION:
@@ -2113,6 +2115,8 @@ void hvm_emulate_one_vm_event(enum emul_kind kind, 
unsigned int trapnr,
  * consistent with X86EMUL_RETRY.
  */
 return;
+case X86EMUL_UNIMPLEMENTED:
+/* fall-through */
 case X86EMUL_UNHANDLEABLE:
 hvm_dump_emulation_state(XENLOG_G_DEBUG, "Mem event", );
 hvm_inject_hw_exception(trapnr, errcode);
diff --git a/xen/arch/x86/hvm/io.c b/xen/arch/x86/hvm/io.c
index 214ab30..af4e1dc 100644
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -96,6 +96,8 @@ bool hvm_emulate_one_insn(hvm_emulate_validate_t *validate, 
const char *descr)
 switch ( rc )
 {
 case X86EMUL_UNHANDLEABLE:
+/* fall-through */
+case X86EMUL_UNIMPLEMENTED:
 hvm_dump_emulation_state(XENLOG_G_WARNING, descr, );
 return false;
 
diff --git a/xen/arch/x86/hvm/vmx/realmode.c b/xen/arch/x86/hvm/vmx/realmode.c
index 11bde58..fdbbee2 100644
--- a/xen/arch/x86/hvm/vmx/realmode.c
+++ b/xen/arch/x86/hvm/vmx/realmode.c
@@ -106,7 +106,7 @@ void vmx_realmode_emulate_one(struct hvm_emulate_ctxt 
*hvmemul_ctxt)
 if ( hvm_vcpu_io_need_completion(vio) || vio->mmio_retry )
 vio->io_completion = HVMIO_realmode_completion;
 
-if ( rc == X86EMUL_UNHANDLEABLE )
+if ( rc == X86EMUL_UNHANDLEABLE || rc == X86EMUL_UNIMPLEMENTED )
 {
 gdprintk(XENLOG_ERR, "Failed to emulate insn.\n");
 goto fail;
diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c
index c9c2252..85fb165 100644
--- a/xen/arch/x86/mm/shadow/multi.c
+++ b/xen/arch/x86/mm/shadow/multi.c
@@ -3486,7 +3486,7 @@ static int sh_page_fault(struct vcpu *v,
  * would be a good unshadow hint. If we *do* decide to unshadow-on-fault
  * then it must be 'failable': we cannot require the unshadow to succeed.
  */
-if ( r == X86EMUL_UNHANDLEABLE )
+if ( r == X86EMUL_UNHANDLEABLE || r == X86EMUL_UNIMPLEMENTED )
 {
 perfc_incr(shadow_fault_emulate_failed);
 #if SHADOW_OPTIMIZATIONS & SHOPT_FAST_EMULATION
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c 
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 2201852..480bad9 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -2577,7 +2577,7 @@ x86_decode(
 d = twobyte_table[0x3a].desc;
 break;
 default:
-rc = X86EMUL_UNHANDLEABLE;
+rc = X86EMUL_UNIMPLEMENTED;
 goto done;
 }
 }
@@ -2591,7 +2591,7 @@ x86_decode(
 }
 else
 {
-rc = X86EMUL_UNHANDLEABLE;
+rc = X86EMUL_UNIMPLEMENTED;
 goto done;
 }
 
@@ -2871,7 +2871,7 @@ x86_decode(
 
 default:
 ASSERT_UNREACHABLE();
-return X86EMUL_UNHANDLEABLE;
+return X86EMUL_UNIMPLEMENTED;
 }
 
 if ( ea.type == OP_MEM )
@@ -7717,7 +7717,7 @@ x86_emulate(
 
 default:
 cannot_emulate:
-rc = X86EMUL_UNHANDLEABLE;
+rc = X86EMUL_UNIMPLEMENTED;
 goto done;
 }
 
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.h 
b/xen/arch/x86/x86_emulate/x86_emulate.h
index 4ddf111..82812ca 100644
--- a/xen/arch/x86/x86_emulate/x86_emulate.h
+++ b/xen/arch/x86/x86_emulate/x86_emulate.h
@@ -133,6 +133,12 @@ struct x86_emul_fpu_aux {
   * Undefined behavior when used anywhere else.
   */
 #define X86EMUL_DONE   4
+ /*
+  * Current instruction is not implemented by the emulator.
+  * This value should only be returned by the core emulator if decode fails
+  * and not by any of the x86_emulate_ops callbacks.
+  */
+#define

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

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 4cf3f37c87ba1f9d58072444bd735e40e4779e70
baseline version:
 ovmf 6e414300b5f19d3045a0d21ad90ac2fe965478a5

Last test of basis   112512  2017-08-07 17:49:36 Z0 days
Testing same since   112518  2017-08-08 08:21:39 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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=4cf3f37c87ba1f9d58072444bd735e40e4779e70
+ . ./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 
4cf3f37c87ba1f9d58072444bd735e40e4779e70
+ branch=ovmf
+ revision=4cf3f37c87ba1f9d58072444bd735e40e4779e70
+ . ./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.9-testing
+ '[' x4cf3f37c87ba1f9d58072444bd735e40e4779e70 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osst...@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ :

[Xen-devel] [PATCH] common/page_alloc: Drop BOOT_BUG_ON()

Regular BUG_ON()'s work fine by this point on all architectures, so drop the
custom infrastructure.  Substitute BUG_ON(1) for BUG().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Stefano Stabellini 
CC: Julien Grall 
---
 xen/common/page_alloc.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c
index 8bcef6a..64fe951 100644
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -203,12 +203,6 @@ struct scrub_region {
 static struct scrub_region __initdata region[MAX_NUMNODES];
 static unsigned long __initdata chunk_size;
 
-static void __init boot_bug(int line)
-{
-panic("Boot BUG at %s:%d", __FILE__, line);
-}
-#define BOOT_BUG_ON(p) if ( p ) boot_bug(__LINE__);
-
 static void __init bootmem_region_add(unsigned long s, unsigned long e)
 {
 unsigned int i;
@@ -223,9 +217,8 @@ static void __init bootmem_region_add(unsigned long s, 
unsigned long e)
 if ( s < bootmem_region_list[i].e )
 break;
 
-BOOT_BUG_ON((i < nr_bootmem_regions) && (e > bootmem_region_list[i].s));
-BOOT_BUG_ON(nr_bootmem_regions ==
-(PAGE_SIZE / sizeof(struct bootmem_region)));
+BUG_ON((i < nr_bootmem_regions) && (e > bootmem_region_list[i].s));
+BUG_ON(nr_bootmem_regions == (PAGE_SIZE / sizeof(struct bootmem_region)));
 
 memmove(_region_list[i+1], _region_list[i],
 (nr_bootmem_regions - i) * sizeof(*bootmem_region_list));
@@ -328,7 +321,7 @@ unsigned long __init alloc_boot_pages(
 unsigned long pg, _e;
 unsigned int i = nr_bootmem_regions;
 
-BOOT_BUG_ON(!nr_bootmem_regions);
+BUG_ON(!nr_bootmem_regions);
 
 while ( i-- )
 {
@@ -362,8 +355,7 @@ unsigned long __init alloc_boot_pages(
 return pg;
 }
 
-BOOT_BUG_ON(1);
-return 0;
+BUG();
 }
 
 
-- 
2.1.4


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

[Xen-devel] [PATCH] xen/arm: Tighten memory attribute requirement for memory shared

Xen allows shared mapping to be Normal inner-cacheable with any inner cache
allocation strategy and no restriction of the outer-cacheability.

However, Xen is always mapping those region Normal Inner Write-Back
Outer Write-Back Inner-shareable. Per B2.8 "Mismatched memory
attributes" in ARM DDI 0487B.a, if the guest is not using the exact same
memory attributes (excluding any cache allocation hints) for the shared
region then the region will be accessed with mismatched attributes.

This will result to potential loss of coherency, and may impact the
performance.

Given that the ARM ARM strongly recommends to avoid using mismatched
attributes, we should impose shared region to be Normal Inner Write-Back
Outer Write-Back Inner-shareable.

Signed-off-by: Julien Grall 
---
 xen/include/public/arch-arm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index bd974fb13d..8f9d06ef7f 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -61,15 +61,15 @@
  *
  * All memory which is shared with other entities in the system
  * (including the hypervisor and other guests) must reside in memory
- * which is mapped as Normal Inner-cacheable. This applies to:
+ * which is mapped as Normal Inner Write-Back Outer Write-Back Inner-Shareable.
+ * This applies to:
  *  - hypercall arguments passed via a pointer to guest memory.
  *  - memory shared via the grant table mechanism (including PV I/O
  *rings etc).
  *  - memory shared with the hypervisor (struct shared_info, struct
  *vcpu_info, the grant table, etc).
  *
- * Any Inner cache allocation strategy (Write-Back, Write-Through etc)
- * is acceptable. There is no restriction on the Outer-cacheability.
+ * Any cache allocation hints are acceptable.
  */
 
 /*
-- 
2.11.0


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
112456
 test-armhf-armhf-libvirt-raw  6 xen-install  fail REGR. vs. 112456
 test-armhf-armhf-xl-multivcpu  7 xen-bootfail REGR. vs. 112456

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-pvops 2 hosts-allocate  broken like 112456
 build-arm64-xsm   2 hosts-allocate  broken like 112456
 build-arm64   2 hosts-allocate  broken like 112456
 build-arm64   3 capture-logsbroken like 112456
 build-arm64-pvops 3 capture-logsbroken like 112456
 build-arm64-xsm   3 capture-logsbroken like 112456
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112456
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 112456
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112456
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 112456
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 qemuuf22ab6cb0c47bd2a2785b7d58130949bd7d8d9af
baseline version:
 qemuuac44ed2afb7c60255e989b163301479f5b4ecd04

Last test of basis   112456  2017-08-05 00:17:41 Z3 days
Failing since112506  2017-08-07 09:39:19 Z1 days2 attempts
Testing same since   112516  2017-08-08 04:28:45 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Eric Auger 
  Peter Maydell 
  Richard Henderson 
  Stefan Hajnoczi 

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

Re: [Xen-devel] stage1-xen for Fedora

2017-08-08 Thread Rajiv Ranganath

Hi Stefano,

On Wed, Aug 2, 2017 at 12:15 AM, Stefano Stabellini
wrote:

[...]

> The main thing that will be different is the list of dependencies you
> need to install to build Xen. On Fedora it should be (I am using
> Raisin[1] as a reference):

Thank you for the pointer to Raisin.

I have managed to build stage1-xen on Fedora. This project is very
interesting. I have some questions regarding stage1-xen and containers
on Xen.

1. Is there a roadmap/design doc for containers primitives and container
standards that Xen community is looking to support?

The only documentation that I could find were presentations by you.
[1][2]

2. Now that OCI 1.0 is out, are there any plans to create a Xen based
OCI runtime? [3]

A Xen based OCI runtime that can work with containerd and cri-o would be
very interesting to us.

I was wondering if you have thoughts on how xen-stage1 could be evolved
to support rkt and also also a OCI runtime?

3. Are there plans to use PVHv2 guests instead of PV guests?

4. In the presentation I noticed PV Calls for Networking. However when I
did `rkt run ...`, it seems to use netback with vif-nat. How can I try
PV calls for networking?

[...]

> Let me know if you find any issues!

Following are the issues that I ran into -

1. `rkt rm ...` fails with `stage1/rootfs/gc` file not found error. I
think because of this the Xen host gets populated with a lot of
overlayfs mounts. I tried to manually clean up, but that failed too.

2. Upstream cni master seems to have reorganized its directory
structure. So, I had to pin the version to 0.3 to get the build to work.
I also had to manually get dhcp4 and dhcp4client packages. Perhaps we
can add a glide.lock file to lock down the dependencies. I can send a
patch for it.

> I would be very happy to take a patch (or pull request) for
> BUILDING.md to document how to do this on Fedora.

I have a somewhat "non-standard" setup for xen and qemu for Fedora. I'll
briefly describe the setup.

Xen is booted using EFI. This required building a custom binutils
package [4]. Both Xen and qemu are built with a non-standard prefix
(/opt/xen-unstable and /opt/qemu-stable), with RPATHs appropriately
adjusted.

Lastly I don't use systemd to manage Xen on Fedora. In the buildroot,
Xen is explicitly configured using --disable-systemd. We have a version
of runit package that we run under systemd. Runit then launches
xenstore, xenconsole, dom0 qemu disk backend. We frequently toggle
between upstart and systemd based distro, so using runit on both has
been very helpful.

If this setup is okay you, I can open up the Fedora variant of our tools
and packages and send patches to BUILDING.md.

Please let me know.

Thank you!

Best,
Rajiv

[1]:
https://xendeveloperanddesignsummit2017.sched.com/event/AjGx/keynote-secure-containers-with-xen-and-coreos-rkt-stefano-stabellini-aporeto
[2]:
https://docs.google.com/presentation/d/1dP_7myrUrtwQHnjgDtlMQkAxJNG6Se9SBl0tdaFIAYQ/edit?usp=sharing
[3]:
https://github.com/opencontainers/runtime-spec/blob/master/implementations.md
[4]: https://wiki.xenproject.org/wiki/Xen_EFI

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

Re: [Xen-devel] [RFC PATCH v1 0/7] IPMMU-VMSA support on ARM

2017-08-08 Thread Stefano Stabellini

On Tue, 8 Aug 2017, Julien Grall wrote:
> On 01/08/17 18:13, Oleksandr Tyshchenko wrote:
> > Hi, Julien
> > 
> > On Tue, Aug 1, 2017 at 3:27 PM, Julien Grall  wrote:
> > > On 26/07/17 16:09, Oleksandr Tyshchenko wrote:
> > > > 
> > > > From: Oleksandr Tyshchenko 
> > > > 
> > > > Hi, all.
> > > 
> > > 
> > > Hi,
> > > 
> > > Please CC maintainers and any relevant person on the cover letter. This is
> > > quite useful to have in the inbox.
> > Yes. I CCed guys who, I think, are/were involved in IPMMU-VMSA
> > development from Linux side +
> > IOMMU maintainers (mostly ARM). Sorry, if I missed someone or mistakenly
> > added.
> > 
> > > 
> > > > The purpose of this patch series is to add IPMMU-VMSA support to Xen on
> > > > ARM.
> > > > It is VMSA-compatible IOMMU that integrated in the newest Renesas R-Car
> > > > Gen3 SoCs (ARM).
> > > > And this IOMMU can't share the page table with the CPU since it doesn't
> > > > use the same page-table format
> > > > as the CPU on ARM therefore I name it "Non-shared" IOMMU.
> > > > This all means that current patch series must be based on "Non-shared"
> > > > IOMMU support [1]
> > > > for the IPMMU-VMSA to be functional inside Xen.
> > > > 
> > > > The IPMMU-VMSA driver as well as the ARM LPAE allocator were directly
> > > > ported from BSP for Linux the vendor provides:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-bsp.git
> > > > rcar-3.5.3
> > > 
> > > 
> > > I think this is probably a good starting point to discuss about IOMMU
> > > support in Xen. I skimmed through the patches and saw the words "rfc" and
> > > "ported from BSP".
> > Well, at the time of porting IPMMU-VMSA driver, BSP [1] had more
> > complete support than mainline [2]
> > and seems to have at the moment.
> > For example, mainline driver still has single IPMMU context while BSP
> > driver can have up to 8 contexts,
> > the maximum uTLBs mainline driver can handle is 32, but for BSP driver
> > this value was increased to 48, etc.
> > But, I see attempts to get all required support in [3]. So, when this
> > support reaches upsteam, I hope,
> > it won't be a big problem to rebase on mainline driver if we decide to
> > align with it.
> 
> My main concern here is this driver haven't had a thorough review by the Linux
> community.
> 
> When we ported the SMMUv{1,2} driver we knew the Linux community was happy
> with it and hence adapting for Xen was not a big deal. There are only few
> limited changes in the code from Linux.
> 
> Looking at patch #2, #6, #7, the changes don't seem limited in the code from
> Linux + it is a driver from a BSP. The code really needs to be very close to
> make the port from Linux really worth it.
> 
> Stefano do you have any opinion?

Yes, the fact that a driver is already in Linux gives us a guarantee
that it had been reviewed before. This driver doesn't come with that
guarantee, that means that one of us would have to review it. Otherwise,
we could take the contribution and mark it as "unsupported/experimental"
like we do for many new features until we think it is stable enough.

Regardless, I think you are right that there is no gain in trying to
make this patch series "compatible" with the original Linux driver,
because the driver isn't in Linux. We might as well take a clean
contribution to Xen without any #if 0.

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

Re: [Xen-devel] [PATCH 2/3] docs: add xen-release-management.pandoc

2017-08-08 Thread Lars Kurth

Wei

On 31/07/17 12:22, Wei Liu wrote:
> A document for the release manager.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Lars Kurth 

  Regards
  Lars


On 08/08/2017, 12:03, "Julien Grall"  wrote:

Hi Wei,

On 31/07/17 12:22, Wei Liu wrote:
> A document for the release manager.
>
> Signed-off-by: Wei Liu 

Reviewed-by: Julien Grall 

Cheers,

> ---
>  docs/process/xen-release-management.pandoc | 594 
+
>  1 file changed, 594 insertions(+)
>  create mode 100644 docs/process/xen-release-management.pandoc
>
> diff --git a/docs/process/xen-release-management.pandoc 
b/docs/process/xen-release-management.pandoc
> new file mode 100644
> index 00..afdf559429
> --- /dev/null
> +++ b/docs/process/xen-release-management.pandoc
> @@ -0,0 +1,594 @@
> +% Xen Release Management
> +% Wei Liu <>
> +% Revision 1
> +
> +# Motivation
> +
> +Over the years we have had different people signing up as the Release 
Manager
> +of Xen. It would be rather wasteful if every new Release Manager has to 
go over
> +everything and tripped over by the same mistakes again and again.
> +
> +This file intends to document the process of managing a Xen release. It 
is
> +mainly written for Release Manager, but other roles (contributors,
> +maintainers and committers) are also encouraged to read this document, so
> +that they can have an idea what to expect from the Release Manager.
> +
> +# Xen release cycle
> +
> +The Xen hypervisor project now releases twice a year, at the beginning of
> +June and the beginning of December. The actual release date depends on a 
lot
> +of factors.
> +
> +We can roughly divide one release into two periods. The development 
period
> +and the freeze period. The former is 4 months long and the latter is 
about 2
> +months long.
> +
> +During development period, contributors submit patches to be reviewed and
> +committed into xen.git. All feature patches must be committed before a 
date,
> +which is normally called the "cut-off date", after which the freeze 
period
> +starts. There will be a date before which all patches that wish to be 
merged
> +for the release should be posted -- it is normally called the "last 
posting
> +date" and it is normally two weeks before the "cut-off date".
> +
> +During freeze period, the tree is closed for new features. Only bug 
fixes are
> +accepted. This period can be shorter or longer than 2 months. If it ends 
up
> +longer than 2 months, it eats into the next development period.
> +
> +Here is a conjured up example (use ```cal 2017``` to get an idea):
> +
> +* Development period: 2017 June 11 - 2017 September 29
> +* the "cut-off date" is 2017 September 29
> +* the "last posting date" is 2017 September 15
> +* Freeze period: 2017 October 2 - 2017 December 7
> +* the anticipated release date is 2017 December 7
> +
> +# The different roles in a Xen release
> +
> +## Release Manager
> +
> +A trusted developer in the community that owns the release process. The 
major
> +goal of the Release Manager is to make sure a Xen release has high 
quality
> +and doesn't slip too much.
> +
> +The Release Manager will not see much workload during development 
period, but
> +expects to see increasing workload during the freeze period until the 
final
> +release. He or she is expected to keep track of issues, arrange RCs,
> +negotiate with relevant stakeholders, balance the need from various 
parties
> +and make difficult decisions when necessary.
> +
> +The Release Manager essentially owns xen-unstable branch during the 
freeze
> +period. The Committers will act on the wishes of the Release Manager 
during
> +that time.
> +
> +## Maintainers
> +
> +A group of trusted developers who are responsible for certain components 
in
> +xen.git. They are expected to respond to patches / questions with regard 
to
> +their components in a timely manner, especially during the freeze period.
> +
> +## Committers
> +
> +A group of trusted maintainers who can commit to xen.git. During the
> +development window they normally push things as they see fit. During the
> +freeze period they transfer xen-unstable branch ownership and act on the
> +wishes of the Release Manager. That normally means they need to have an
> +Release Ack in order to push a patch.
> +
> +## Contributors
> +
> +Contributors are also expected to respond quickly to any issues 
regarding the
> +code they submitted during development period.

Re: [Xen-devel] [PATCH v7 13/14] arm/mem_access: Add short-descriptor based gpt



On 08/08/2017 06:20 PM, Andrew Cooper wrote:
> On 08/08/17 16:28, Sergej Proskurin wrote:
>> On 08/08/2017 05:18 PM, Julien Grall wrote:
>>> On 08/08/17 16:17, Sergej Proskurin wrote:
 Hi Julien,


 On 07/18/2017 02:25 PM, Sergej Proskurin wrote:
> This commit adds functionality to walk the guest's page tables using
> the
> short-descriptor translation table format for both ARMv7 and ARMv8. The
> implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
> B3-1506.
>
> Signed-off-by: Sergej Proskurin 
> Acked-by: Julien Grall 
 As you have already Acked this patch I would like you to ask whether I
 should remove your Acked-by for now as I have extended the previous
 patch by additional casts of the pte.*.base fields to (paddr_t) as
 discussed in patch 00/14.
>>> I am fine with this, assuming this is the only change made.
>> The changes are limited to 4 similar casts to (paddr_t) in total and an
>> additional comment. Here are the only changes in this patch:
>>
>> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
>> index b258248322..7f34a2b1d3 100644
>> --- a/xen/arch/arm/guest_walk.c
>> +++ b/xen/arch/arm/guest_walk.c
>> @@ -112,7 +112,12 @@ static int guest_walk_sd(const struct vcpu *v,
>>   * level translation table does not need to be page aligned.
>>   */
>>  mask = GENMASK(19, 12);
>> -paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
>> +/*
>> + * Cast pte.walk.base to paddr_t to cope with C type promotion
>> of types
>> + * smaller than int. Otherwise pte.walk.base would be casted to
>> int and
>> + * subsequently sign extended, thus leading to a wrong value.
>> + */
>> +paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);
> Why not change the bitfield type from unsigned int to paddr_t ?
>
> The result is 100% less liable to go wrong in this way.
>

I absolutely agree :)

Julien, would that be ok for you if I changed the type of the base field
in short_desc_* structs accordingly? Or shall I remove your Acked-by for
this?

Thanks,
~Sergej

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

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

2017-08-08 Thread Stefano Stabellini

On Tue, 8 Aug 2017, Wei Liu wrote:
> On Tue, Aug 08, 2017 at 09:19:21AM -0700, Stefano Stabellini wrote:
> > On Tue, 8 Aug 2017, Wei Liu wrote:
> > > Ian and Stefano
> > > 
> > > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > > p9 instead of p9s. This causes problem for his work to rework device
> > > framework.
> > > 
> > > Given that p9fs was added only during last release and the only known
> > > external toolstack libvirt can't possibility use that, maybe we can
> > > rename p9 to p9s. Opinions?
> > 
> > stage1-xen uses it:
> > 
> > https://github.com/rkt/stage1-xen/blob/master/files/run
> > 
> 
> I think this should be fine -- xl shouldn't be affected. I didn't
> suggest we change the config option in xl, only in libxl idl.

In that case, stage1-xen would be unaffected.

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

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

On Tue, Aug 08, 2017 at 09:19:21AM -0700, Stefano Stabellini wrote:
> On Tue, 8 Aug 2017, Wei Liu wrote:
> > Ian and Stefano
> > 
> > Oleksandr discovered that the p9fs array in libxl_domain_config is name
> > p9 instead of p9s. This causes problem for his work to rework device
> > framework.
> > 
> > Given that p9fs was added only during last release and the only known
> > external toolstack libvirt can't possibility use that, maybe we can
> > rename p9 to p9s. Opinions?
> 
> stage1-xen uses it:
> 
> https://github.com/rkt/stage1-xen/blob/master/files/run
> 

I think this should be fine -- xl shouldn't be affected. I didn't
suggest we change the config option in xl, only in libxl idl.

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

Re: [Xen-devel] [PATCH v7 13/14] arm/mem_access: Add short-descriptor based gpt

On 08/08/17 16:28, Sergej Proskurin wrote:
>
> On 08/08/2017 05:18 PM, Julien Grall wrote:
>>
>> On 08/08/17 16:17, Sergej Proskurin wrote:
>>> Hi Julien,
>>>
>>>
>>> On 07/18/2017 02:25 PM, Sergej Proskurin wrote:
 This commit adds functionality to walk the guest's page tables using
 the
 short-descriptor translation table format for both ARMv7 and ARMv8. The
 implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
 B3-1506.

 Signed-off-by: Sergej Proskurin 
 Acked-by: Julien Grall 
>>> As you have already Acked this patch I would like you to ask whether I
>>> should remove your Acked-by for now as I have extended the previous
>>> patch by additional casts of the pte.*.base fields to (paddr_t) as
>>> discussed in patch 00/14.
>> I am fine with this, assuming this is the only change made.
> The changes are limited to 4 similar casts to (paddr_t) in total and an
> additional comment. Here are the only changes in this patch:
>
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index b258248322..7f34a2b1d3 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -112,7 +112,12 @@ static int guest_walk_sd(const struct vcpu *v,
>   * level translation table does not need to be page aligned.
>   */
>  mask = GENMASK(19, 12);
> -paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
> +/*
> + * Cast pte.walk.base to paddr_t to cope with C type promotion
> of types
> + * smaller than int. Otherwise pte.walk.base would be casted to
> int and
> + * subsequently sign extended, thus leading to a wrong value.
> + */
> +paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);

Why not change the bitfield type from unsigned int to paddr_t ?

The result is 100% less liable to go wrong in this way.

~Andrew

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

Re: [Xen-devel] Renaming p9 to p9s in libxl idl

2017-08-08 Thread Stefano Stabellini

On Tue, 8 Aug 2017, Wei Liu wrote:
> Ian and Stefano
> 
> Oleksandr discovered that the p9fs array in libxl_domain_config is name
> p9 instead of p9s. This causes problem for his work to rework device
> framework.
> 
> Given that p9fs was added only during last release and the only known
> external toolstack libvirt can't possibility use that, maybe we can
> rename p9 to p9s. Opinions?

stage1-xen uses it:

https://github.com/rkt/stage1-xen/blob/master/files/run

it would be a bit of a problem to change the name now, given that xen 4.9
was released with "p9" in it. We don't know who might be using it. I
think we have to keep handling "p9", possibly in addition to "p9s".

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

Re: [Xen-devel] [PATCH v1 3/3] xl: enable per-VCPU extratime flag for RTDS

On Sun, 2017-08-06 at 22:43 -0400, Meng Xu wrote:
> On Sun, Aug 6, 2017 at 12:22 PM, Meng Xu 
> wrote:
> > 
> > diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
> > index 2c71a9f..88933a4 100644
> > --- a/tools/xl/xl_cmdtable.c
> > +++ b/tools/xl/xl_cmdtable.c
> > @@ -272,12 +272,13 @@ struct cmd_spec cmd_table[] = {
> >  { "sched-rtds",
> >    _sched_rtds, 0, 1,
> >    "Get/set rtds scheduler parameters",
> > -  "[-d  [-v[=VCPUID/all]] [-p[=PERIOD]] [-
> > b[=BUDGET]]]",
> > +  "[-d  [-v[=VCPUID/all]] [-p[=PERIOD]] [-b[=BUDGET]]
> > [-e[=EXTRATIME]]]",
> >    "-d DOMAIN, --domain=DOMAIN Domain to modify\n"
> >    "-v VCPUID/all, --vcpuid=VCPUID/allVCPU to modify or
> > output;\n"
> >    "   Using '-v all' to modify/output all vcpus\n"
> >    "-p PERIOD, --period=PERIOD Period (us)\n"
> >    "-b BUDGET, --budget=BUDGET Budget (us)\n"
> > +  "-e EXTRATIME, --extratime=EXTRATIME EXTRATIME (1=yes,
> > 0=no)\n"
> 
> Hi Dario,
> 
> I kept the EXTRATIME value for -e option because: (1) it may be more
> intuitive for users; (2) it needs much less code change than the
> input
> style that does not need EXTRATIME value.
> 
I'm of the opposite view.

But again, it's tools' people views' that count. :-D

> As to (1), if users want to set some VCPUs with extratime flag set
> and
> some with extratime flag clear, there are two types of input:
> (a) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -e 0 -v 2 -p 1 -b
> 4000 -e 1 -v 5 -p 1 -b 4000 -e 0
> (b) xl sched-rtds -d 1 -v 1 -p 1 -b 4000 -v 2 -p 1 -b 4000 -e
> 1 -v 5 -p 1 -b 4000
> I felt that the style (a) is more intuitive and the input commands
> have very static pattern, i.e., each vcpu must have -v -p -b -e
> options set.
>
Exactly, I do think that (b) is indeed a better user interface.

For instance, what if I want to change period and budget of vcpu 1 of
domain 3, _without_ changing whether or not it can use the extra time. 

With (a), I don't think I can do that. Or at least, I'd have to either
remember or check what extratime is right now, and pass that same value
explicitly to `xl sched-rtds -d 3 -v 1 ...'.

That does not look super user-friendly to me.

> As to (2), if we go with -e without EXTRATIME, we will have to keep
> track of the vcpu that has no -e option. I thought about this option,
> we can pre-set the extratime value to false when -v option is
> assigned:
> case 'v':
> ...
> extratimes[v_index]  = 0;
> 
> and set the extratimes[v_index] = 0 when -e is set.
> 
Yes, something like that. Or, even better, use its current value.

That would require calling libxl_vcpu_sched_params_get() (or, at times,
libxl_vcpu_sched_params_get_all()), which I assumed you were doing
already, while you apparently don't. Mmm...

> This approach is not very neat in the code: we have to reallocate
> memory for extratimes array when its size is not enough; we also have
> to deal with the special case when -e is set before -v, such as the
> command "xl sched-rtds -p 1 -b 4000 -e -v 0"
> 
Err... sorry, there's code for reallocations in this patch already,
isn't this the case?

Also, it may be me, but I don't understand how this is different from
how -b and -p are dealt with.

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 00/25 v7] SBSA UART emulation support in Xen

Hi Bhupinder,

I gave another and I have a couple of comments.

Booting Linux with earlycon enabled take quite a while. I can see the
characters coming slower than on the minitel. It seems to be a bit
better after switching off the bootconsole. Overall Linux is taking ~20
times to boot with pl011 vs HVC console.

I do agree that pl011 is emulated and therefore you have to trap after
each character. But 20 times sounds far too much.

After that I tried to stress the emulation a bit with "find ." to get a
lot of output. And I noticed a lot of message similar to the one below
on xen console:

d6v0 vpl011: Unexpected OUT ring buffer full

Associated to that the character have been eaten resulting to non-sense log.

A bit above the printk printing this message, there are a comment saying:

/*
* It is expected that the ring is not full when this function is
called

* as the guest is expected to write to the data register only when the
* TXFF flag is not set.
* In case the guest does write even when the TXFF flag is set then the
* data will be silently dropped.
*/

I am quite surprised that Linux is not looking at the TXFF flags. So
this needs some investigation.

Cheers,

On 07/08/17 09:52, Bhupinder Thakur wrote:

SBSA UART emulation for guests in Xen
==
Linaro has published VM System specification for ARM Processors, which
provides a set of guidelines for both guest OS and hypervisor implementations,
such that building OS images according to these guidelines guarantees
that those images can also run on hypervisors compliant with this specification.

One of the spec requirements is that the hypervisor must provide an
emulated SBSA UART as a serial console which meets the minimum requirements in
SBSA UART as defined in appendix B of the following
ARM Server Base Architecture Document:

https://static.docs.arm.com/den0029/a/Server_Base_System_Architecture_v3_1_ARM_DEN_0029A.pdf.

This feature allows the Xen guests to use SBSA compliant UART as
as a console.

Note that SBSA UART is a subset of full featured ARM pl011 UART and
supports only a subset of registers as mentioned below. It does not support
rx/tx DMA.

Currently, Xen supports paravirtualized (aka PV console) and an emulated serial
consoles. This feature will expose an emulated SBSA UART console to the
guest, which a user can access using xenconsole.

The device tree passed to the guest VM will contain the SBSA UART MMIO address
range and an irq for receiving rx/tx interrupts. The device tree format
is specified in Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt.

The Xen hypervisor will expose two types of interfaces to the backend and domU.

The interface exposed to domU will be an emulated SBSA UART by emulating the
access to the following registers by the guest.

- Data register (DR)- RW
- Raw interrupt status register (RIS) - RO
- Masked interrupt status register (MIS)- RO
- Interrupt Mask (IMSC) - RW
- Interrupt Clear (ICR) - WO

It will also inject the interrupts to the guest in the following
conditions:

- incoming data in the rx buffer for the guest
- there is space in the tx buffer for the guest to write more data

The interface exposed to the backend will be the same PV console interface,
which minimizes the changes required in xenconsole to support a new SBSA UART
console.

This interface has rx and tx ring buffers and an event channel for
sending/receiving events from the backend.

So essentially Xen handles the data on behalf of domU and the backend. Any data
written by domU is captured by Xen and written to the TX (OUT) ring buffer
and an event is raised to the backend to read the TX ring buffer.

Similarly on reciving an event from xenconsole, Xen injects an interrupt to
guest to
indicate there is data available in the RX (IN) ring buffer.

The SBSA UART state is completely captured in the set of registers
mentioned above and this state is updated everytime there is an event from
the backend or there is register read/write access from domU.

For example, if domU has masked the rx interrupt in the IMSC register, then Xen
will not inject an interrupt to guest and will just update the RIS register.
Once the interrupt is unmasked by guest, the interrupt will be delivered to the
guest.

Changes summary:

Xen Hypervisor
===

1. Add emulation code to emulate read/write access to SBSA UART registers and
interrupts:
- It emulates DR read/write by reading and writing from/to the IN and
OUT ring buffers and raising an event to dom0 when there is data in
the OUT ring buffer and injecting an interrupt to the guest when there
is data in the IN ring buffer.
- Other registers are related to interrupt management and essentially
control when interrupts are delivered to the guest.

2. Add a new domctl API to initialize SBSA UART emulation in Xen.

3. Enable SBSA UART emulation for a

[Xen-devel] [PATCH v2] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

We have limited number (slightly under NR_DYNAMIC_VECTORS=192) of IRQ
vectors that are available to each processor. Currently, when x2apic
cluster mode is used (which is default), each vector is shared among
all processors in the cluster. With many IRQs (as is the case on systems
with multiple SR-IOV cards) and few clusters (e.g. single socket)
there is a good chance that we will run out of vectors.

This patch tries to decrease vector sharing between processors by
assigning vector to a single processor if the assignment request (via
__assign_irq_vector()) comes without explicitly specifying which
processors are expected to share the interrupt. This typically happens
during boot time (or possibly PCI hotplug) when create_irq(NUMA_NO_NODE)
is called. When __assign_irq_vector() is called from
set_desc_affinity() which provides sharing mask, vector sharing will
continue to be performed, as before.

This patch to some extent mirrors Linux commit d872818dbbee
("x86/apic/x2apic: Use multiple cluster members for the irq destination
only with the explicit affinity").

Note that this change still does not guarantee that we never run out of
vectors. For example, on a single core system we will be effectively
back to the single cluster/socket case of original code.

Signed-off-by: Boris Ostrovsky 
---
Changes in v2:
* Instead of relying on having mask set to TARGET_CPUS as indication that the
caller doesn't care about how vectors are shared allow passing NULL mask to
__assign_irq_vector() (and then to vector_allocation_cpumask()).


 xen/arch/x86/genapic/delivery.c  | 6 --
 xen/arch/x86/genapic/x2apic.c| 6 +-
 xen/arch/x86/irq.c   | 9 +
 xen/include/asm-x86/genapic.h| 9 ++---
 xen/include/asm-x86/mach-generic/mach_apic.h | 3 ++-
 5 files changed, 22 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/genapic/delivery.c b/xen/arch/x86/genapic/delivery.c
index ced92a1..3cb65d2 100644
--- a/xen/arch/x86/genapic/delivery.c
+++ b/xen/arch/x86/genapic/delivery.c
@@ -30,7 +30,8 @@ void __init clustered_apic_check_flat(void)
printk("Enabling APIC mode:  Flat.  Using %d I/O APICs\n", nr_ioapics);
 }
 
-const cpumask_t *vector_allocation_cpumask_flat(int cpu)
+const cpumask_t *vector_allocation_cpumask_flat(int cpu,
+const cpumask_t *cpumask)
 {
return _online_map;
 } 
@@ -58,7 +59,8 @@ void __init clustered_apic_check_phys(void)
printk("Enabling APIC mode:  Phys.  Using %d I/O APICs\n", nr_ioapics);
 }
 
-const cpumask_t *vector_allocation_cpumask_phys(int cpu)
+const cpumask_t *vector_allocation_cpumask_phys(int cpu,
+const cpumask_t *cpumask)
 {
return cpumask_of(cpu);
 }
diff --git a/xen/arch/x86/genapic/x2apic.c b/xen/arch/x86/genapic/x2apic.c
index 5fffb31..b12d529 100644
--- a/xen/arch/x86/genapic/x2apic.c
+++ b/xen/arch/x86/genapic/x2apic.c
@@ -72,8 +72,12 @@ static void __init clustered_apic_check_x2apic(void)
 {
 }
 
-static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu)
+static const cpumask_t *vector_allocation_cpumask_x2apic_cluster(int cpu,
+const cpumask_t *cpumask)
 {
+if ( !cpumask )
+return cpumask_of(cpu);
+
 return per_cpu(cluster_cpus, cpu);
 }
 
diff --git a/xen/arch/x86/irq.c b/xen/arch/x86/irq.c
index 57e6c18..a0385a3 100644
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -450,11 +450,12 @@ static int __assign_irq_vector(
 static int current_vector = FIRST_DYNAMIC_VECTOR, current_offset = 0;
 int cpu, err, old_vector;
 cpumask_t tmp_mask;
+const cpumask_t *initial_mask = mask ?: TARGET_CPUS;
 vmask_t *irq_used_vectors = NULL;
 
 old_vector = irq_to_vector(irq);
 if (old_vector > 0) {
-cpumask_and(_mask, mask, _online_map);
+cpumask_and(_mask, initial_mask, _online_map);
 if (cpumask_intersects(_mask, desc->arch.cpu_mask)) {
 desc->arch.vector = old_vector;
 return 0;
@@ -476,7 +477,7 @@ static int __assign_irq_vector(
 else
 irq_used_vectors = irq_get_used_vector_mask(irq);
 
-for_each_cpu(cpu, mask) {
+for_each_cpu(cpu, initial_mask) {
 int new_cpu;
 int vector, offset;
 
@@ -484,7 +485,7 @@ static int __assign_irq_vector(
 if (!cpu_online(cpu))
 continue;
 
-cpumask_and(_mask, vector_allocation_cpumask(cpu),
+cpumask_and(_mask, vector_allocation_cpumask(cpu, mask),
 _online_map);
 
 vector = current_vector;
@@ -550,7 +551,7 @@ int assign_irq_vector(int irq, const cpumask_t *mask)
 BUG_ON(irq >= nr_irqs || irq <0);
 
 spin_lock_irqsave(_lock, flags);
-ret = __assign_irq_vector(irq, desc, mask ?: TARGET_CPUS);
+ret = __assign_irq_vector(irq, desc, mask);
 if (!ret) {
 ret = desc->arch.vector;
 cpumask_copy(desc->affinity, desc->arch.cpu_mask);
diff --git a/xen/include/asm-x86/genapic.h

Re: [Xen-devel] [PATCH v4 7/9] vpci/msi: add MSI handlers

2017-08-08 Thread Roger Pau Monné

On Wed, Aug 02, 2017 at 07:34:28AM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne  06/30/17 5:01 PM >>>
> >+int vpci_msi_arch_enable(struct vpci_arch_msi *arch, struct pci_dev *pdev,
> >+ uint64_t address, uint32_t data, unsigned int 
> >vectors)
> >+{
> >+struct msi_info msi_info = {
> >+.seg = pdev->seg,
> >+.bus = pdev->bus,
> >+.devfn = pdev->devfn,
> >+.entry_nr = vectors,
> >+};
> >+unsigned int i;
> >+int rc;
> >+
> >+ASSERT(arch->pirq == -1);
> 
> Please introduce a #define for the -1 here, to allow easily matching up
> producer and consumer side(s).

I've added a define for INVALID_PIRQ to xen/irq.h.

> >+/* Get a PIRQ. */
> >+rc = allocate_and_map_msi_pirq(pdev->domain, -1, >pirq,
> >+   MAP_PIRQ_TYPE_MULTI_MSI, _info);
> >+if ( rc )
> >+{
> >+dprintk(XENLOG_ERR, "%04x:%02x:%02x.%u: failed to map PIRQ: %d\n",
> >+pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> >+PCI_FUNC(pdev->devfn), rc);
> >+return rc;
> >+}
> >+
> >+for ( i = 0; i < vectors; i++ )
> >+{
> >+xen_domctl_bind_pt_irq_t bind = {
> >+.machine_irq = arch->pirq + i,
> >+.irq_type = PT_IRQ_TYPE_MSI,
> >+.u.msi.gvec = msi_vector(data) + i,
> >+.u.msi.gflags = msi_flags(data, address),
> >+};
> >+
> >+pcidevs_lock();
> >+rc = pt_irq_create_bind(pdev->domain, );
> >+if ( rc )
> >+{
> >+dprintk(XENLOG_ERR,
> >+"%04x:%02x:%02x.%u: failed to bind PIRQ %u: %d\n",
> >+pdev->seg, pdev->bus, PCI_SLOT(pdev->devfn),
> >+PCI_FUNC(pdev->devfn), arch->pirq + i, rc);
> >+spin_lock(>domain->event_lock);
> >+unmap_domain_pirq(pdev->domain, arch->pirq);
> 
> Don't you also need to undo the pt_irq_create_bind() calls here for all prior
> successful iterations?

Yes, unmap_domain_pirq calls pirq_guest_force_unbind but better not
resort to that.

> >+int vpci_msi_arch_disable(struct vpci_arch_msi *arch, struct pci_dev *pdev,
> >+  unsigned int vectors)
> >+{
> >+unsigned int i;
> >+
> >+ASSERT(arch->pirq != -1);
> >+
> >+for ( i = 0; i < vectors; i++ )
> >+{
> >+xen_domctl_bind_pt_irq_t bind = {
> >+.machine_irq = arch->pirq + i,
> >+.irq_type = PT_IRQ_TYPE_MSI,
> >+};
> >+
> >+pcidevs_lock();
> >+pt_irq_destroy_bind(pdev->domain, );
> 
> While I agree that the loop should continue of this fails, I'm not convinced
> you should entirely ignore the return value here.

I've added a printk in order to aid debug.

> >+/* Handlers for the MSI control field (PCI_MSI_FLAGS). */
> >+static void vpci_msi_control_read(struct pci_dev *pdev, unsigned int reg,
> >+  union vpci_val *val, void *data)
> >+{
> >+const struct vpci_msi *msi = data;
> >+
> >+/* Set multiple message capable. */
> >+val->u16 = MASK_INSR(fls(msi->max_vectors) - 1, PCI_MSI_FLAGS_QMASK);
> 
> The comment is somewhat misleading - whether the device is multi-message
> capable depends on msi->max_vectors.

Better "Set the number of supported messages"?

> >+if ( msi->enabled ) {
> 
> Style.
> 
> >+val->u16 |= PCI_MSI_FLAGS_ENABLE;
> >+val->u16 |= MASK_INSR(fls(msi->vectors) - 1, PCI_MSI_FLAGS_QSIZE);
> 
> Why is reading back the proper value here dependent upon MSI being
> enabled?

Right, I've now slightly changed this to always store the number of
enabled vectors, regardless of whether the MSI enable bit is set or
not.

> >...
> >+ error:
> >+ASSERT(ret);
> >+xfree(msi);
> >+return ret;
> >+}
> 
> Don't you also need to unregister address handlers you've registered?

vpci_add_handlers already takes care of cleaning up the register
handlers on failure.

> >+void vpci_dump_msi(void)
> >+{
> >+struct domain *d;
> >+
> >+for_each_domain ( d )
> >+{
> >+const struct pci_dev *pdev;
> >+
> >+if ( !has_vpci(d) )
> >+continue;
> >+
> >+printk("vPCI MSI information for guest %u\n", d->domain_id);
> 
> "... for Dom%d" or "... for d%d" please.
> 
> >...
> >+if ( msi->masking )
> >+printk("mask=%#032x\n", msi->mask);
> 
> Why 30 hex digits? And generally # should be used only when not blank or
> zero padding the value (as field width includes the 0x prefix).

Ouch, that should be 8, not 32.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v1 2/3] libxl: enable per-VCPU extratime flag for RTDS

On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
> Modify libxl_vcpu_sched_params_get/set and sched_rtds_vcpu_get/set
> functions to support per-VCPU extratime flag
> 
> Signed-off-by: Meng Xu 
> 
Reviewed-by: Dario Faggioli 

Of course, if the flag name in domctl.h change, this will have to
change as well. If that's the only thing changing, you can keep the
tag.

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 v7 13/14] arm/mem_access: Add short-descriptor based gpt



On 08/08/2017 05:18 PM, Julien Grall wrote:
>
>
> On 08/08/17 16:17, Sergej Proskurin wrote:
>> Hi Julien,
>>
>>
>> On 07/18/2017 02:25 PM, Sergej Proskurin wrote:
>>> This commit adds functionality to walk the guest's page tables using
>>> the
>>> short-descriptor translation table format for both ARMv7 and ARMv8. The
>>> implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
>>> B3-1506.
>>>
>>> Signed-off-by: Sergej Proskurin 
>>> Acked-by: Julien Grall 
>>
>> As you have already Acked this patch I would like you to ask whether I
>> should remove your Acked-by for now as I have extended the previous
>> patch by additional casts of the pte.*.base fields to (paddr_t) as
>> discussed in patch 00/14.
>
> I am fine with this, assuming this is the only change made.

The changes are limited to 4 similar casts to (paddr_t) in total and an
additional comment. Here are the only changes in this patch:

diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
index b258248322..7f34a2b1d3 100644
--- a/xen/arch/arm/guest_walk.c
+++ b/xen/arch/arm/guest_walk.c
@@ -112,7 +112,12 @@ static int guest_walk_sd(const struct vcpu *v,
  * level translation table does not need to be page aligned.
  */
 mask = GENMASK(19, 12);
-paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
+/*
+ * Cast pte.walk.base to paddr_t to cope with C type promotion
of types
+ * smaller than int. Otherwise pte.walk.base would be casted to
int and
+ * subsequently sign extended, thus leading to a wrong value.
+ */
+paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);

 /* Access the guest's memory to read only one PTE. */
 ret = access_guest_memory_by_ipa(d, paddr, ,
sizeof(short_desc_t), false);
@@ -125,7 +130,7 @@ static int guest_walk_sd(const struct vcpu *v,
 if ( pte.pg.page ) /* Small page. */
 {
 mask = (1ULL << L2DESC_SMALL_PAGE_SHIFT) - 1;
-*ipa = (pte.pg.base << L2DESC_SMALL_PAGE_SHIFT) | (gva & mask);
+*ipa = ((paddr_t)pte.pg.base << L2DESC_SMALL_PAGE_SHIFT) |
(gva & mask);

 /* Set execute permissions associated with the small page. */
 if ( !pte.pg.xn )
@@ -134,7 +139,7 @@ static int guest_walk_sd(const struct vcpu *v,
 else /* Large page. */
 {
 mask = (1ULL << L2DESC_LARGE_PAGE_SHIFT) - 1;
-*ipa = (pte.lpg.base << L2DESC_LARGE_PAGE_SHIFT) | (gva &
mask);
+*ipa = ((paddr_t)pte.lpg.base << L2DESC_LARGE_PAGE_SHIFT) |
(gva & mask);

 /* Set execute permissions associated with the large page. */
 if ( !pte.lpg.xn )
@@ -152,7 +157,7 @@ static int guest_walk_sd(const struct vcpu *v,
 if ( !pte.sec.supersec ) /* Section */
 {
 mask = (1ULL << L1DESC_SECTION_SHIFT) - 1;
-*ipa = (pte.sec.base << L1DESC_SECTION_SHIFT) | (gva & mask);
+*ipa = ((paddr_t)pte.sec.base << L1DESC_SECTION_SHIFT) |
(gva & mask);
 }
 else /* Supersection */
 {

Thanks,
~Sergej

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

Re: [Xen-devel] [PATCH v7 13/14] arm/mem_access: Add short-descriptor based gpt




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

Hi Julien,


On 07/18/2017 02:25 PM, Sergej Proskurin wrote:

This commit adds functionality to walk the guest's page tables using the
short-descriptor translation table format for both ARMv7 and ARMv8. The
implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
B3-1506.

Signed-off-by: Sergej Proskurin 
Acked-by: Julien Grall 


As you have already Acked this patch I would like you to ask whether I
should remove your Acked-by for now as I have extended the previous
patch by additional casts of the pte.*.base fields to (paddr_t) as
discussed in patch 00/14.


I am fine with this, assuming this is the only change made.



Thanks,
~Sergej



--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 13/14] arm/mem_access: Add short-descriptor based gpt

Hi Julien,

On 07/18/2017 02:25 PM, Sergej Proskurin wrote:
> This commit adds functionality to walk the guest's page tables using the
> short-descriptor translation table format for both ARMv7 and ARMv8. The
> implementation is based on ARM DDI 0487B-a J1-6002 and ARM DDI 0406C-b
> B3-1506.
>
> Signed-off-by: Sergej Proskurin 
> Acked-by: Julien Grall 

As you have already Acked this patch I would like you to ask whether I
should remove your Acked-by for now as I have extended the previous
patch by additional casts of the pte.*.base fields to (paddr_t) as
discussed in patch 00/14.

Thanks,
~Sergej

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

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

On Tue, Aug 08, 2017 at 09:51:36AM -0500, Venu Busireddy wrote:
> I will implement all your above suggestions in v4.
> 
> > I think a bigger question is whether you agree with Ian's comments
> > regarding API design and whether you have more questions?
> 
> Ian suggested that I document the use of the API (about the event loop),
> and I believe I addressed it. I don't have any more questions. Just
> waiting for Ian's "Ack", or more comments.
> 

Ian is currently away and won't be back till August 28 iirc. I suggest
you wait for him to comment. I am not quite sure what he asked for.

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

[Xen-devel] Renaming p9 to p9s in libxl idl

Ian and Stefano

Oleksandr discovered that the p9fs array in libxl_domain_config is name
p9 instead of p9s. This causes problem for his work to rework device
framework.

Given that p9fs was added only during last release and the only known
external toolstack libvirt can't possibility use that, maybe we can
rename p9 to p9s. Opinions?

Wei.

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

Re: [Xen-devel] [PATCH v4 06/13] libxl: change p9 to use generec add function

On Tue, Aug 08, 2017 at 03:39:23PM +0300, Oleksandr Grytsov wrote:
> On Fri, Aug 4, 2017 at 2:53 PM, Wei Liu  wrote:
> > On Wed, Aug 02, 2017 at 02:37:10PM +0300, Oleksandr Grytsov wrote:
> > [...]
> >> >> >> From other side this rename touches only internals changes: no 
> >> >> >> changes
> >> >> >> in config file
> >> >> >> or CLI interface.
> >> >> >>
> >> >> >
> >> >> > As said, the framework need to be ready to deal with PCI anyway.
> >> >> >
> >> >> > What sort of issues do you foresee here?
> >> >>
> >> >> Do you mean in case to rework PCI to use the device framework?
> >> >>
> >> >
> >> > No, I mean adding the new hook. You said "handle irregular device name
> >> > looks not so good"
> >>
> >> As for me when only internal name of structure or fields are changed
> >> then it should not break anyone configs, setup etc.
> >> Creating hooks in this case makes code hard to read and maintain.
> >>
> >
> > I think you missed my points:
> >
> > 1. libxl types generated from libxl_types.idl aren't just used by xl.
> > Some applications will use libxl types directly. Not breaking xl config
> > doesn't mean not breaking other toolstacks like libvirt. In this
> > particular case, I think we might be able to change p9 to p9s because it
> > is only released a few months back because the only other known
> > toolstack that uses libxl can't possibly use that field at the moment.
> > But Ian might disagree.
> 
> I got it. I think that we have to change p9 to p9s ASAP to avoid future hooks.
> 
> > 2. There is another type, pci dev, that has been there since forever. We
> > need a hook to deal with it, we can't rename it.
> >
> 
> For PCI all hooks are already there (DEFINE_DEVICE_TYPE_STRUCT_X
> to handle pcidev and pci). Also I didn't change PCI fields, names etc.
> In libxl_domain_config it is already pcidevs. So, we are safe with PCI.
> Sorry I don't understand your concern about PCI. Or I miss something?

Yes I think we're covered there. That macro only covers the case
where new characters are appended.

I was thinking maybe we should have something that deal with new names
weather they are longer or shorter than expected.

But I see now it is probably better to rename the p9 device. I will send
out an email asking for opinions.

> 
> > 1 and 2 are orthogonal. 2 is a hard requirement.
> 
> 
> -- 
> Best Regards,
> Oleksandr Grytsov.

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

Re: [Xen-devel] [PATCH v7 00/14] arm/mem_access: Walk guest page tables in SW if mem_access is active


On 08/08/2017 04:58 PM, Andrew Cooper wrote:
> On 08/08/17 15:47, Sergej Proskurin wrote:
>> Hi Julien,
>>
>>> The patch belows solve my problem:
>>>
>>> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
>>> index b258248322..6ca994e438 100644
>>> --- a/xen/arch/arm/guest_walk.c
>>> +++ b/xen/arch/arm/guest_walk.c
>>> @@ -112,7 +112,7 @@ static int guest_walk_sd(const struct vcpu *v,
>>>   * level translation table does not need to be page aligned.
>>>   */
>>>  mask = GENMASK(19, 12);
>>> -paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
>>> +paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);
>>>  
>>>  /* Access the guest's memory to read only one PTE. */
>>>  ret = access_guest_memory_by_ipa(d, paddr, , 
>>> sizeof(short_desc_t), false);
>>>
>>> This is because pte.walk.base is encoded on unsigned int:22 bits. A shift 
>>> by 10 will not
>>> fit an integer, and my compiler seems to promote it to "signed long long". 
>>> Hence the bogus
>>> address.
>>>
>> Thats quite an interesting phenomenon :) I have just played around with
>> this and it does indeed appear that the value is casted to a signed
>> result! What I don't yet understand is the following: An unsigned int
>> with the length of 22 bit should actually exactly fit an integer after a
>> left shift of 10 (or do I miss s.th.?).
> C type promotion ftw!
>
> All integral types smaller than int are promoted to int before any
> operations on them.  This includes things like unsigned char/short etc.
>
> Then, the type is promoted to match that of the other operand, which
> might be a wider type (e.g. long) or an unsigned version of the same type.

Thanks Andrew, I did not know that!

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v7 00/14] arm/mem_access: Walk guest page tables in SW if mem_access is active

On 08/08/17 15:47, Sergej Proskurin wrote:
> Hi Julien,
>
>> The patch belows solve my problem:
>>
>> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
>> index b258248322..6ca994e438 100644
>> --- a/xen/arch/arm/guest_walk.c
>> +++ b/xen/arch/arm/guest_walk.c
>> @@ -112,7 +112,7 @@ static int guest_walk_sd(const struct vcpu *v,
>>   * level translation table does not need to be page aligned.
>>   */
>>  mask = GENMASK(19, 12);
>> -paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
>> +paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);
>>  
>>  /* Access the guest's memory to read only one PTE. */
>>  ret = access_guest_memory_by_ipa(d, paddr, , 
>> sizeof(short_desc_t), false);
>>
>> This is because pte.walk.base is encoded on unsigned int:22 bits. A shift by 
>> 10 will not
>> fit an integer, and my compiler seems to promote it to "signed long long". 
>> Hence the bogus
>> address.
>>
>
> Thats quite an interesting phenomenon :) I have just played around with
> this and it does indeed appear that the value is casted to a signed
> result! What I don't yet understand is the following: An unsigned int
> with the length of 22 bit should actually exactly fit an integer after a
> left shift of 10 (or do I miss s.th.?).

C type promotion ftw!

All integral types smaller than int are promoted to int before any
operations on them.  This includes things like unsigned char/short etc.

Then, the type is promoted to match that of the other operand, which
might be a wider type (e.g. long) or an unsigned version of the same type.

~Andrew

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

Re: [Xen-devel] [PATCH v1 1/3] xen:rtds: towards work conserving RTDS

On Sun, 2017-08-06 at 12:22 -0400, Meng Xu wrote:
> Make RTDS scheduler work conserving without breaking the real-time
> guarantees.
> 
> VCPU model:
> Each real-time VCPU is extended to have an extratime flag
> and a priority_level field.
> When a VCPU's budget is depleted in the current period,
> if it has extratime flag set,
> its priority_level will increase by 1 and its budget will be
> refilled;
> othewrise, the VCPU will be moved to the depletedq.
> 
> Scheduling policy is modified global EDF:
> A VCPU v1 has higher priority than another VCPU v2 if
> (i) v1 has smaller priority_leve; or
> (ii) v1 has the same priority_level but has a smaller deadline
> 
> Queue management:
> Run queue holds VCPUs with extratime flag set and VCPUs with
> remaining budget. Run queue is sorted in increasing order of VCPUs
> priorities.
> Depleted queue holds VCPUs which have extratime flag cleared and
> depleted budget.
> Replenished queue is not modified.
> 
> Signed-off-by: Meng Xu 
> 
This looks mostly good to me.

There are only a couple of things left, in addition to the
changlog+comment mention to how the 'spare bandwidth' distribution
works, that we agreed upon in the other thread.

> --- a/xen/common/sched_rt.c
> +++ b/xen/common/sched_rt.c 
> @@ -245,6 +258,11 @@ static inline struct list_head *rt_replq(const
> struct scheduler *ops)
>  return _priv(ops)->replq;
>  }
>  
> +static inline bool has_extratime(const struct rt_vcpu *svc)
> +{
> +return (svc->flags & RTDS_extratime) ? 1 : 0;
> +}
> +
>
Cool... I like 'has_extratime()' soo much better as a name than what it
was before! Thanks. :-)

>  /*
>   * Helper functions for manipulating the runqueue, the depleted
> queue,
>   * and the replenishment events queue.
> @@ -274,6 +292,21 @@ vcpu_on_replq(const struct rt_vcpu *svc)
>  }
>  
>  /*
> + * If v1 priority >= v2 priority, return value > 0
> + * Otherwise, return value < 0
> + */
> +static s_time_t
> +compare_vcpu_priority(const struct rt_vcpu *v1, const struct rt_vcpu
> *v2)
> +{
> +int prio = v2->priority_level - v1->priority_level;
> +
> +if ( prio == 0 )
> +return v2->cur_deadline - v1->cur_deadline;
> +
Indentation.

> @@ -423,15 +459,18 @@ rt_update_deadline(s_time_t now, struct rt_vcpu
> *svc)
>   */
>  svc->last_start = now;
>  svc->cur_budget = svc->budget;
> +svc->priority_level = 0;
>  
>  /* TRACE */
>  {
>  struct __packed {
>  unsigned vcpu:16, dom:16;
> +unsigned priority_level;
>  uint64_t cur_deadline, cur_budget;
>  } d;
>
Can you please, and in this very comment, update
tools/xentrace/xenalyze.c and tools/xentrace/formats as well, to take
into account this new field?

> diff --git a/xen/include/public/domctl.h
> b/xen/include/public/domctl.h
> index 0669c31..ba5daa9 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -360,6 +360,9 @@ typedef struct xen_domctl_sched_credit2 {
>  typedef struct xen_domctl_sched_rtds {
>  uint32_t period;
>  uint32_t budget;
> +#define _XEN_DOMCTL_SCHED_RTDS_extratime 0
> +#define
> XEN_DOMCTL_SCHED_RTDS_extratime  (1U<<_XEN_DOMCTL_SCHED_RTDS_extratim
> e)
> +uint32_t flags;
>
I'd add a one liner comment above the flag definition, as, for
instance, how things are done in createdomain:

struct xen_domctl_createdomain {
/* IN parameters */
uint32_t ssidref;
xen_domain_handle_t handle;
 /* Is this an HVM guest (as opposed to a PVH or PV guest)? */
#define _XEN_DOMCTL_CDF_hvm_guest 0
#define XEN_DOMCTL_CDF_hvm_guest  (1U<<_XEN_DOMCTL_CDF_hvm_guest)
 /* Use hardware-assisted paging if available? */
#define _XEN_DOMCTL_CDF_hap   1
#define XEN_DOMCTL_CDF_hap(1U<<_XEN_DOMCTL_CDF_hap)

Also, consider shortening the name (e.g., by contracting the SCHED_RTDS
part; it does not matter if it's not 100% equal to what's in
sched_rt.c, I think).

This, of course, is just my opinion, and final say belongs to
maintainers of this public interface, which I think means 'THE REST',
and most of them are not Cc-ed. Let me do that...

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 24/25 v7] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree

2017-08-08 Thread Bhupinder Thakur

Hi Julien,


>>
>> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
>> index a33d3c9..6629852 100644
>> --- a/tools/libxl/libxl_arm.c
>> +++ b/tools/libxl/libxl_arm.c
>> @@ -43,11 +43,29 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
>>  {
>>  uint32_t nr_spis = 0;
>>  unsigned int i;
>> +uint32_t vuart_irq = 0;
>> +
>> +/*
>> + * If pl011 vuart is enabled then increment the nr_spis to allow
>> allocation
>> + * of SPI VIRQ for pl011.
>> + */
>> +if (d_config->b_info.arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART) {
>> +nr_spis += (GUEST_VPL011_SPI - 32) + 1;
>> +vuart_irq = GUEST_VPL011_SPI;
>> +}
>>
>>  for (i = 0; i < d_config->b_info.num_irqs; i++) {
>>  uint32_t irq = d_config->b_info.irqs[i];
>>  uint32_t spi;
>>
>> +/*
>> + * The user specified irq should not conflict with the vpl011
>> irq.
>> + */
>
>
> I am sorry but in the changelog you wrote: "Add a comment explaining why
> user specified IRQ should not conflict with vpl011 SPI". But you still don't
> explain why... And I still don't see the TODO requested on v6.

ok. So should I mention that if there is a conflict then that
interrupt would not be received correctly by the guest as user expects
certain
behaviour on receiving the specified IRQ?

Can you please elaborate what is the TODO in this case?

>
>> +if (irq == vuart_irq) {
>
>
> Hmmm if vUART is not enabled you would compare to 0. And I don't think we
> should make this assumption in the code. This would also give a random error
> to the user.
>
I thought that since this is an SPI interrupt it would start with at least 32.

> It would be better if you introduce a local boolean vuart_enabled to know
> whether you need to check the conflict.

ok. I will add a boolean variable.

Regards,
Bhupinder

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

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

2017-08-08 Thread Venu Busireddy

On 2017-08-08 15:33:01 +0100, Wei Liu wrote:
> On Mon, Aug 07, 2017 at 06:54:56PM -0500, Venu Busireddy wrote:
> > Implement the callback function to handle unrecoverable AER errors, and
> > also the public APIs that can be used to register/unregister the handler.
> > When an AER error occurs, the handler will forcibly remove the erring
> > PCIe device from the guest.
> > 
> > Signed-off-by: Venu Busireddy 
> > ---
> >  tools/libxl/libxl.h  | 14 +++
> >  tools/libxl/libxl_event.h| 13 +++
> >  tools/libxl/libxl_internal.h |  7 
> >  tools/libxl/libxl_pci.c  | 90 
> > 
> >  4 files changed, 124 insertions(+)
> > 
> > diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> > index 7cf0f31..c5af0aa 100644
> > --- a/tools/libxl/libxl.h
> > +++ b/tools/libxl/libxl.h
> > @@ -1044,6 +1044,20 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
> > const libxl_mac *src);
> >   */
> >  #define LIBXL_HAVE_QED 1
> >  
> > +/* LIBXL_HAVE_REG_AER_EVENTS_HANDLER
> > + *
> > + * If it is defined, libxl has a library function called
> > + * libxl_reg_aer_events_handler.
> > + */
> > +#define LIBXL_HAVE_REG_AER_EVENTS_HANDLER 1
> > +
> > +/* LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER
> > + *
> > + * If it is defined, libxl has a library function called
> > + * libxl_unreg_aer_events_handler.
> > + */
> > +#define LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER 1
> > +
> 
> You can consolidate both into
> 
> LIBLX_HAVE_AER_EVENTS_HANDLER
> 
> >  typedef char **libxl_string_list;
> >  void libxl_string_list_dispose(libxl_string_list *sl);
> >  int libxl_string_list_length(const libxl_string_list *sl);
> > diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> > index 1ea789e..1aea906 100644
> > --- a/tools/libxl/libxl_event.h
> > +++ b/tools/libxl/libxl_event.h
> > @@ -184,6 +184,19 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
> > libxl_evgen_domain_death*);
> > * may generate only a DEATH event.
> > */
> >  
> > +typedef struct libxl__aer_watch libxl_aer_watch;
> > +int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch **)
> > +LIBXL_EXTERNAL_CALLERS_ONLY;
> > +  /*
> > +   * Registers a handler to handle the occurrence of unrecoverable AER 
> > errors.
> > +   * This function depends on the calling application running the libxl's
> > +   * internal event loop. Toolstacks that do not use libxl's internal
> > +   * event loop must arrange to have their own event loop created and enter
> > +   * libxl (say, call libxl_event_wait()), to enable the event to be 
> > processed.
> > +   */
> > +void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch 
> > *)
> > +LIBXL_EXTERNAL_CALLERS_ONLY;
> > +
> >  typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
> >  int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char 
> > *vdev,
> >  libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index afe6652..2b74286 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -352,6 +352,13 @@ struct libxl__ev_child {
> >  LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
> >  };
> >  
> > +/*
> > + * Structure used for AER event handling.
> > + */
> > +struct libxl__aer_watch {
> > +uint32_t domid;
> > +libxl__ev_xswatch watch;
> > +};
> >  
> >  /*
> >   * evgen structures, which are the state we use for generating
> > diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> > index 65ad5e5..feedf27 100644
> > --- a/tools/libxl/libxl_pci.c
> > +++ b/tools/libxl/libxl_pci.c
> > @@ -1678,6 +1678,96 @@ static int libxl_device_pci_compare(libxl_device_pci 
> > *d1,
> >  return COMPARE_PCI(d1, d2);
> >  }
> >  
> > +static void aer_backend_watch_callback(libxl__egc *egc,
> > +   libxl__ev_xswatch *watch,
> > +   const char *watch_path,
> > +   const char *event_path)
> > +{
> > +EGC_GC;
> > +libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
> > +int rc;
> > +uint32_t dom, bus, dev, fn;
> > +uint32_t domid = aer_ws->domid;
> > +char *p, *path;
> > +const char *aerFailedSBDF;
> > +libxl_device_pci pcidev;
> > +
> > +/* Extract the backend directory. */
> > +path = libxl__strdup(gc, event_path);
> > +p = strrchr(path, '/');
> > +if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
> > +return;
> > +/* Truncate the string so it points to the backend directory. */
> > +*p = '\0';
> > +
> > +/* Fetch the value of the failed PCI device. */
> > +rc = libxl__xs_read_checked(gc, XBT_NULL,
> > +GCSPRINTF("%s/aerFailedSBDF", path), );
> > +if (rc || !aerFailedSBDF)
> > +

Re: [Xen-devel] [PATCH v7 00/14] arm/mem_access: Walk guest page tables in SW if mem_access is active

Hi Julien,

> The patch belows solve my problem:
>
> diff --git a/xen/arch/arm/guest_walk.c b/xen/arch/arm/guest_walk.c
> index b258248322..6ca994e438 100644
> --- a/xen/arch/arm/guest_walk.c
> +++ b/xen/arch/arm/guest_walk.c
> @@ -112,7 +112,7 @@ static int guest_walk_sd(const struct vcpu *v,
>   * level translation table does not need to be page aligned.
>   */
>  mask = GENMASK(19, 12);
> -paddr = (pte.walk.base << 10) | ((gva & mask) >> 10);
> +paddr = ((paddr_t)pte.walk.base << 10) | ((gva & mask) >> 10);
>  
>  /* Access the guest's memory to read only one PTE. */
>  ret = access_guest_memory_by_ipa(d, paddr, , 
> sizeof(short_desc_t), false);
>
> This is because pte.walk.base is encoded on unsigned int:22 bits. A shift by 
> 10 will not
> fit an integer, and my compiler seems to promote it to "signed long long". 
> Hence the bogus
> address.
>


Thats quite an interesting phenomenon :) I have just played around with
this and it does indeed appear that the value is casted to a signed
result! What I don't yet understand is the following: An unsigned int
with the length of 22 bit should actually exactly fit an integer after a
left shift of 10 (or do I miss s.th.?).

Anyway, thanks for the patch! V8 containing this change will follow soon.

Thanks,
~Sergej



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

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

On Tue, Aug 08, 2017 at 03:33:01PM +0100, Wei Liu wrote:
> > +
> > +int libxl_reg_aer_events_handler(libxl_ctx *ctx,
> > + uint32_t domid,
> > + libxl_aer_watch **aer_ws_out)
> 
> Afaict libxl_aer_watch is an opaque type to external caller, so this
> won't work, right?
> 

Oh, it is a pointer to a pointer, so the storage size is known.

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

Re: [Xen-devel] Xen is not booting with updated kernel 4.13 rc3 from UEFI shell

2017-08-08 Thread Juergen Gross

On 08/08/17 16:26, Asharaf Perinchikkal wrote:
> Hi All,
> 
> I am attaching xen boot log when xen fail to boot with updated kernel
> from UEFI shell.
> It show an error when kernel start booting..
> 
> N) ***
> (XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
> (XEN) This option is intended to aid debugging of Xen by ensuring
> (XEN) that all output is synchronously delivered on the serial line.
> (XEN) However it can introduce SIGNIFICANT latencies and affect
> (XEN) timekeeping. It is NOT recommended for production use!
> (XEN) ***
> (XEN) 3... 2... 1...
> (XEN*) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch
> input to Xen)
> (XEN) Freed 2048kB init memory
> mapping kernel into physical memory
> about to get started...
> (XEN) d0v0 Unhandled invalid opcode fault/trap [#6, ec=]
> (XEN) domain_crash_sync called from entry.S: fault at 82d080345f28
> entry.o#create_bounce_frame+0x135/0x14d
> (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> (XEN) [ Xen-4.9.0 x86_64 debug=n Tainted: C ]
> (XEN) CPU: 0
> (XEN) RIP: e033:[]

Can you please try to find the dom0 kernel source file/line related to
this address? addr2line should be able to help.


Juergen

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

Re: [Xen-devel] [PATCH v3 1/2] libxl: Implement the handler to handle unrecoverable AER errors

On Mon, Aug 07, 2017 at 06:54:56PM -0500, Venu Busireddy wrote:
> Implement the callback function to handle unrecoverable AER errors, and
> also the public APIs that can be used to register/unregister the handler.
> When an AER error occurs, the handler will forcibly remove the erring
> PCIe device from the guest.
> 
> Signed-off-by: Venu Busireddy 
> ---
>  tools/libxl/libxl.h  | 14 +++
>  tools/libxl/libxl_event.h| 13 +++
>  tools/libxl/libxl_internal.h |  7 
>  tools/libxl/libxl_pci.c  | 90 
> 
>  4 files changed, 124 insertions(+)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 7cf0f31..c5af0aa 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1044,6 +1044,20 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst, 
> const libxl_mac *src);
>   */
>  #define LIBXL_HAVE_QED 1
>  
> +/* LIBXL_HAVE_REG_AER_EVENTS_HANDLER
> + *
> + * If it is defined, libxl has a library function called
> + * libxl_reg_aer_events_handler.
> + */
> +#define LIBXL_HAVE_REG_AER_EVENTS_HANDLER 1
> +
> +/* LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER
> + *
> + * If it is defined, libxl has a library function called
> + * libxl_unreg_aer_events_handler.
> + */
> +#define LIBXL_HAVE_UNREG_AER_EVENTS_HANDLER 1
> +

You can consolidate both into

LIBLX_HAVE_AER_EVENTS_HANDLER

>  typedef char **libxl_string_list;
>  void libxl_string_list_dispose(libxl_string_list *sl);
>  int libxl_string_list_length(const libxl_string_list *sl);
> diff --git a/tools/libxl/libxl_event.h b/tools/libxl/libxl_event.h
> index 1ea789e..1aea906 100644
> --- a/tools/libxl/libxl_event.h
> +++ b/tools/libxl/libxl_event.h
> @@ -184,6 +184,19 @@ void libxl_evdisable_domain_death(libxl_ctx *ctx, 
> libxl_evgen_domain_death*);
> * may generate only a DEATH event.
> */
>  
> +typedef struct libxl__aer_watch libxl_aer_watch;
> +int libxl_reg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch **)
> +LIBXL_EXTERNAL_CALLERS_ONLY;
> +  /*
> +   * Registers a handler to handle the occurrence of unrecoverable AER 
> errors.
> +   * This function depends on the calling application running the libxl's
> +   * internal event loop. Toolstacks that do not use libxl's internal
> +   * event loop must arrange to have their own event loop created and enter
> +   * libxl (say, call libxl_event_wait()), to enable the event to be 
> processed.
> +   */
> +void libxl_unreg_aer_events_handler(libxl_ctx *, uint32_t, libxl_aer_watch *)
> +LIBXL_EXTERNAL_CALLERS_ONLY;
> +
>  typedef struct libxl__evgen_disk_eject libxl_evgen_disk_eject;
>  int libxl_evenable_disk_eject(libxl_ctx *ctx, uint32_t domid, const char 
> *vdev,
>  libxl_ev_user, libxl_evgen_disk_eject **evgen_out);
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index afe6652..2b74286 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -352,6 +352,13 @@ struct libxl__ev_child {
>  LIBXL_LIST_ENTRY(struct libxl__ev_child) entry;
>  };
>  
> +/*
> + * Structure used for AER event handling.
> + */
> +struct libxl__aer_watch {
> +uint32_t domid;
> +libxl__ev_xswatch watch;
> +};
>  
>  /*
>   * evgen structures, which are the state we use for generating
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index 65ad5e5..feedf27 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -1678,6 +1678,96 @@ static int libxl_device_pci_compare(libxl_device_pci 
> *d1,
>  return COMPARE_PCI(d1, d2);
>  }
>  
> +static void aer_backend_watch_callback(libxl__egc *egc,
> +   libxl__ev_xswatch *watch,
> +   const char *watch_path,
> +   const char *event_path)
> +{
> +EGC_GC;
> +libxl_aer_watch *aer_ws = CONTAINER_OF(watch, *aer_ws, watch);
> +int rc;
> +uint32_t dom, bus, dev, fn;
> +uint32_t domid = aer_ws->domid;
> +char *p, *path;
> +const char *aerFailedSBDF;
> +libxl_device_pci pcidev;
> +
> +/* Extract the backend directory. */
> +path = libxl__strdup(gc, event_path);
> +p = strrchr(path, '/');
> +if ((p == NULL) || (strcmp(p, "/aerFailedSBDF") != 0))
> +return;
> +/* Truncate the string so it points to the backend directory. */
> +*p = '\0';
> +
> +/* Fetch the value of the failed PCI device. */
> +rc = libxl__xs_read_checked(gc, XBT_NULL,
> +GCSPRINTF("%s/aerFailedSBDF", path), );
> +if (rc || !aerFailedSBDF)
> +return;
> +sscanf(aerFailedSBDF, "%x:%x:%x.%x", , , , );
> +
> +libxl_device_pci_init();
> +pcidev_struct_fill(, dom, bus, dev, fn, 0);
> +/* Forcibly remove the device from the guest */
> +rc = libxl__device_pci_remove_common(gc, domid, , 1);
> +if (rc)
> +LOGD(ERROR,

Re: [Xen-devel] Xen is not booting with updated kernel 4.13 rc3 from UEFI shell

2017-08-08 Thread Asharaf Perinchikkal

Hi All,

I am attaching xen boot log when xen fail to boot with updated kernel from UEFI 
shell.
It show an error when kernel start booting..

N) ***
(XEN) WARNING: CONSOLE OUTPUT IS SYNCHRONOUS
(XEN) This option is intended to aid debugging of Xen by ensuring
(XEN) that all output is synchronously delivered on the serial line.
(XEN) However it can introduce SIGNIFICANT latencies and affect
(XEN) timekeeping. It is NOT recommended for production use!
(XEN) ***
(XEN) 3... 2... 1...
(XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to 
Xen)
(XEN) Freed 2048kB init memory
mapping kernel into physical memory
about to get started...
(XEN) d0v0 Unhandled invalid opcode fault/trap [#6, ec=]
(XEN) domain_crash_sync called from entry.S: fault at 82d080345f28 
entry.o#create_bounce_frame+0x135/0x14d
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) [ Xen-4.9.0 x86_64 debug=n Tainted: C ]
(XEN) CPU: 0
(XEN) RIP: e033:[]
(XEN) RFLAGS: 0206 EM: 1 CONTEXT: pv guest (d0v0)
(XEN) rax:  rbx:  rcx: 99e132d7
(XEN) rdx: 99e14000 rsi: 99e132d6 rdi: 
(XEN) rbp: 82203d40 rsp: 82203cb8 r8: 

Request your support to resolve this issue

Regards
Asharaf P.

From: Jan Beulich [jbeul...@suse.com]
Sent: Thursday, August 03, 2017 7:29 PM
To: Asharaf Perinchikkal
Cc: xen-de...@lists.xenproject.org; Anoop Babu
Subject: Re: [Xen-devel] Xen is not booting with updated kernel 4.13 rc3 from 
UEFI shell

>>> Asharaf Perinchikkal  08/03/17 3:30 
>>> PM >>>
>We have lunched a guest with AGL(Automotive Grade Linux).But its performance
>very low. To overcome this limitation we have updated our host (Dom0) kernel to
>4.13 rc3. Now the xen is not booting with updated kernel from UEFI shell. 
>Ubuntu
>alone is working fine with kernel 4.13 rc3..
>
>Request your support to resolve this issue.

Support is not being provided on this list. Did you mean to post to xen-users?
Alternatively, did you forget to include technical details (serial logs etc)? 
Also
from the little bit of information you give this rather sounds like a Linux side
issue ...

Jan

---Disclaimer-- This e-mail contains PRIVILEGED AND 
CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If 
you are not the intended recipient, please notify the sender by e-mail and 
delete the original message. Opinions, conclusions and other information in 
this transmission that do not relate to the official business of QuEST Global 
and/or its subsidiaries, shall be understood as neither given nor endorsed by 
it. Any statements made herein that are tantamount to contractual obligations, 
promises, claims or commitments shall not be binding on the Company unless 
followed by written confirmation by an authorized signatory of the Company. 
---


Start boot option, Press  or  to enter setup page(5 Sec).

Re: [Xen-devel] [PATCH 25/25 v7] xen/arm: vpl011: Update documentation for vuart console support


Hi,

On 07/08/17 09:53, Bhupinder Thakur wrote:

1. Update documentation for a new vuart option added.
2. Update documentation about SPI irq reserved for vuart.

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 
---

CC: Ian Jackson 
CC: Wei Liu 
CC: Andrew Cooper 
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Julien Grall 

Changes since v6:
- Added a new section for vuart usage.
- I have retained the reviewed-by/acked-by tags as this is a limited change. 
Kindly
  review.

Changes since v4:
- Minor change to rename "pl011" to "sbsa_uart". Since it is a minor change I 
have
  retained the reviewed-by and acked-by tags.

 docs/man/xl.cfg.pod.5.in | 12 
 docs/misc/console.txt| 44 +---
 2 files changed, 45 insertions(+), 11 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 79cb2ea..8a38cf7 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -1105,6 +1105,9 @@ Allow a guest to access specific physical IRQs.
 It is recommended to only use this option for trusted VMs under
 administrator's control.

+If vuart console is enabled then irq 32 is reserved for it. See
+L to know how to enable vuart console.
+
 =item

Re: [Xen-devel] [PATCH 24/25 v7] xen/arm: vpl011: Add a pl011 uart DT node in the guest device tree




On 07/08/17 09:53, Bhupinder Thakur wrote:

The SBSA UART node format is as specified in
Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt and given below:

ARM SBSA defined generic UART
--
This UART uses a subset of the PL011 registers and consequently lives
in the PL011 driver. It's baudrate and other communication parameters
cannot be adjusted at runtime, so it lacks a clock specifier here.

Required properties:
- compatible: must be "arm,sbsa-uart"
- reg: exactly one register range
- interrupts: exactly one interrupt specifier
- current-speed: the (fixed) baud rate set by the firmware

Currently the baud rate of 115200 has been selected as a default value,
which is one of the valid baud rate settings. Higher baud rate was
selected since an emulated pl011 can support any valid baud rate without
any limitation of the hardware.

A check is added to ensure that user specified irq does not conflict with
the SPI assgined to vpl011. If there is a conflict then it flags an error.

Signed-off-by: Bhupinder Thakur 
Reviewed-by: Stefano Stabellini 
Acked-by: Wei Liu 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

Changes since v6:
- Added a comment explaining why user specified IRQ should not conflict with 
vpl011
  SPI.
- Checking the vuart type explicitly against vpl011 enum type.
- Removed uart-compat string and using "arm,sbsa-uart" string directly.
- I have retained the reviewed-by/acked-by tags as these are minor changes.

 tools/libxl/libxl_arm.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index a33d3c9..6629852 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -43,11 +43,29 @@ int libxl__arch_domain_prepare_config(libxl__gc *gc,
 {
 uint32_t nr_spis = 0;
 unsigned int i;
+uint32_t vuart_irq = 0;
+
+/*
+ * If pl011 vuart is enabled then increment the nr_spis to allow allocation
+ * of SPI VIRQ for pl011.
+ */
+if (d_config->b_info.arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART) {
+nr_spis += (GUEST_VPL011_SPI - 32) + 1;
+vuart_irq = GUEST_VPL011_SPI;
+}

 for (i = 0; i < d_config->b_info.num_irqs; i++) {
 uint32_t irq = d_config->b_info.irqs[i];
 uint32_t spi;

+/*
+ * The user specified irq should not conflict with the vpl011 irq.
+ */


I am sorry but in the changelog you wrote: "Add a comment explaining why 
user specified IRQ should not conflict with vpl011 SPI". But you still 
don't explain why... And I still don't see the TODO requested on v6.



+if (irq == vuart_irq) {


Hmmm if vUART is not enabled you would compare to 0. And I don't think 
we should make this assumption in the code. This would also give a 
random error to the user.


It would be better if you introduce a local boolean vuart_enabled to 
know whether you need to check the conflict.



+LOG(ERROR, "Physical IRQ %u conflicting with pl011 SPI\n", irq);
+return ERROR_FAIL;
+}
+
 if (irq < 32)
 continue;

@@ -590,6 +608,38 @@ static int make_hypervisor_node(libxl__gc *gc, void *fdt,
 return 0;
 }

+static int make_vpl011_uart_node(libxl__gc *gc, void *fdt,
+ const struct arch_info *ainfo,
+ struct xc_dom_image *dom)
+{
+int res;
+gic_interrupt intr;
+
+res = fdt_begin_node(fdt, "sbsa-pl011");
+if (res) return res;
+
+res = fdt_property_compat(gc, fdt, 1, "arm,sbsa-uart");
+if (res) return res;
+
+res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
+1,
+GUEST_PL011_BASE, GUEST_PL011_SIZE);
+if (res) return res;
+
+set_interrupt(intr, GUEST_VPL011_SPI, 0xf, DT_IRQ_TYPE_LEVEL_HIGH);
+
+res = fdt_property_interrupts(gc, fdt, , 1);
+if (res) return res;
+
+/* Use a default baud rate of 115200. */
+fdt_property_u32(fdt, "current-speed", 115200);
+
+res = fdt_end_node(fdt);
+if (res) return res;
+
+return 0;
+}
+
 static const struct arch_info *get_arch_info(libxl__gc *gc,
  const struct xc_dom_image *dom)
 {
@@ -889,6 +939,9 @@ next_resize:
 FDT( make_timer_node(gc, fdt, ainfo, xc_config->clock_frequency) );
 FDT( make_hypervisor_node(gc, fdt, vers) );

+if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART)
+FDT( make_vpl011_uart_node(gc, fdt, ainfo, dom) );
+
 if (pfdt)
 FDT( copy_partial_fdt(gc, fdt, pfdt) );




Cheers,

--
Julien Grall

___
Xen-devel mailing list

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

On 08/08/2017 09:28 AM, Andrew Cooper wrote:
> On 08/08/17 14:25, Boris Ostrovsky wrote:
>> On 08/08/2017 05:48 AM, Jan Beulich wrote:
>> Andrew Cooper  08/07/17 7:19 PM >>>
 More than once, we've discussed freeing up the legacy PIC range of
 vectors, and freeing up the unallocated vectors in 0xfx.
>>> And that's something I would prefer over the change proposed here,
>>> albeit I realize that the amount of vectors to recover isn't that large.
>> That would only net us 32 vectors at the most. That probably wouldn't be
>> sufficient in many cases where we are currently having vector shortage.
>> Unfortunately I don't have access to my failing system to say how may
>> vectors I was short but I believe it was more than that.
> Indeed, which is why I haven't actually undertaken the work.  It doesn't
> come close to solving the problem.
>
>> (I am also not sure I understand what is meant by "freeing". Where are
>> they going?)
> By "freeing", I mean "available for general irq use" rather than being
> reserved and unused in the system.
>


OK, so it's then definitely less than 32 vectors that would become
available.

I will send v2 of this patch.

-boris

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

Re: [Xen-devel] [PATCH v2 0/3] fix xen hvm guest with kaslr enabled

On 08/08/2017 02:46 AM, Juergen Gross wrote:
> On 28/07/17 12:23, Juergen Gross wrote:
>> This patch series fixes a regression introduced in 4.13-rc1: A Xen
>> HVM guest with KASLR enabled wouldn't boot any longer due to the usage
>> of __va() before kernel_randomize_memory() was called.
>>
>> Changes in V2:
>> - patch 1: test for x86_hyper being not NULL
>>
>> Juergen Gross (3):
>>   x86: provide an init_mem_mapping hypervisor hook
>>   xen: split up xen_hvm_init_shared_info()
>>   xen: fix hvm guest with kaslr enabled
>>
>>  arch/x86/include/asm/hypervisor.h | 10 +++
>>  arch/x86/mm/init.c|  3 ++
>>  arch/x86/xen/enlighten_hvm.c  | 59 
>> ---
>>  3 files changed, 50 insertions(+), 22 deletions(-)
>>
> Could I have some feedback, please?
>
> I'd like to get this regression fixed in 4.13.
>
> In case nobody objects this week I'll just add the patches to the Xen
> tree for rc5.


As I said before I think .init_mem_mapping() could live in
x86_platform_ops() but this works too, so

Reviewed-by: Boris Ostrovsky 

But this still wants x86 maintainers' ACK.


-boris

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

Re: [Xen-devel] [PATCH 06/25 v7] xen/arm: vpl011: Add a new domctl API to initialize vpl011


Hi Bhupinder,

On 07/08/17 09:52, Bhupinder Thakur wrote:

diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index 5e1fc60..784ec7f 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -44,6 +44,13 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
   libxl_domain_build_info *info,
   struct xc_dom_image *dom);

+/* perform any pending hardware initialization */
+_hidden
+int libxl__arch_build_dom_finish(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom,
+ libxl__domain_build_state *state);
+
 /* build vNUMA vmemrange with arch specific information */
 _hidden
 int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
index d842d88..a33d3c9 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -1038,6 +1038,27 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc 
*gc,
 return 0;
 }

+int libxl__arch_build_dom_finish(libxl__gc *gc,
+ libxl_domain_build_info *info,
+ struct xc_dom_image *dom,
+ libxl__domain_build_state *state)
+{
+int ret = 0;
+
+if (info->arch_arm.vuart == LIBXL_VUART_TYPE_SBSA_UART) {


NIT: You could avoid on level of indentation if you do:

if ( info->arch_arm.vuart != LIBXL_VUART_TYPE_SBSA_UART )
  return 0;




+ret = xc_dom_vuart_init(CTX->xch,
+XEN_DOMCTL_VUART_TYPE_VPL011,
+dom->guest_domid,
+dom->console_domid,
+dom->vuart_gfn,
+>vuart_port);
+if (ret < 0)
+LOG(ERROR, "xc_dom_vuart_init failed\n");
+}
+
+return ret;
+}
+
 int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,
   uint32_t domid,
   libxl_domain_build_info *info,


[...]


diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index db6838d..c7f650e 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -5,9 +5,11 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -119,6 +121,46 @@ long arch_do_domctl(struct xen_domctl *domctl, struct 
domain *d,
 d->disable_migrate = domctl->u.disable_migrate.disable;
 return 0;

+case XEN_DOMCTL_vuart_op:
+{
+int rc;
+struct xen_domctl_vuart_op *vuart_op = >u.vuart_op;
+
+switch(vuart_op->cmd)
+{
+case XEN_DOMCTL_VUART_OP_INIT:
+
+if ( !d->creation_finished )
+{
+if (vuart_op->type == XEN_DOMCTL_VUART_TYPE_VPL011)


Coding style.


+{
+struct vpl011_init_info info;


The indentation is wrong.


+
+info.console_domid = vuart_op->console_domid;
+info.gfn = _gfn(vuart_op->gfn);
+
+rc = domain_vpl011_init(d, );
+if ( !rc )
+{
+vuart_op->evtchn = info.evtchn;
+rc = __copy_to_guest(u_domctl, domctl, 1);
+}
+}
+else
+rc = -EINVAL;


I think this one should be -EOPNOTSUPP.


+}
+else
+rc = - EPERM;


Can we please avoid the number of nested if? Maybe by introducing a 
function to handle the domctl.



+
+break;
+
+default:
+rc = -EINVAL;


Same here.


+break;
+}
+
+return rc;
+}
 default:
 {
 int rc;


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 22/25 v7] xen/arm: vpl011: Add support for vuart console in xenconsole

On Mon, Aug 07, 2017 at 02:23:14PM +0530, Bhupinder Thakur wrote:
> This patch finally adds the support for vuart console. It adds
> two new fields in the console initialization:
> 
> - optional
> - use_gnttab
> 
> optional flag tells whether the console is optional.
> 
> use_gnttab tells whether the ring buffer should be allocated using
> grant table.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

> @@ -665,7 +689,9 @@ static int console_create_ring(struct console *con)
>   if (ring_ref != con->ring_ref && con->ring_ref != -1)
>   console_unmap_interface(con);
>  
> - if (!con->interface && xgt_handle) {
> + if (!con->interface &&
> + xgt_handle &&
> + con->use_gnttab) {

You can join all these to one line.

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

Re: [Xen-devel] [PATCH 21/25 v7] xen/arm: vpl011: Add support for multiple consoles in xenconsole

On Mon, Aug 07, 2017 at 02:23:13PM +0530, Bhupinder Thakur wrote:
> This patch adds the support for multiple consoles and introduces the
> iterator functions to operate on multiple consoles.
> 

Please check all the functions called by the iterator functions to make
sure they have properly guarded against partially constructed states and
uninitialised states. If they don't have such property, they need to be
changed before this patch. If they already have such property, say so in
the commit message.

And some comments below.

> This patch is in preparation to support a new vuart console.
> 
> Signed-off-by: Bhupinder Thakur 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> 
> Changes since v5:
> - Split this patch in multiple smaller patches.
> 
> Changes since v4:
> - Changes to make event channel handling per console rather than per domain.
> 
> Changes since v3:
> - The changes in xenconsole have been split into four patches. This is the 
> third patch.
> 
>  tools/console/daemon/io.c | 156 
> --
>  1 file changed, 122 insertions(+), 34 deletions(-)
> 
> diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
> index 71465a0..f60312d 100644
> --- a/tools/console/daemon/io.c
> +++ b/tools/console/daemon/io.c
> @@ -90,12 +90,14 @@ struct buffer {
>  };
>  
>  struct console {
> + char *ttyname;
>   int master_fd;
>   int master_pollfd_idx;
>   int slave_fd;
>   int log_fd;
>   struct buffer buffer;
>   char *xspath;
> + char *log_suffix;
>   int ring_ref;
>   xenevtchn_handle *xce_handle;
>   int xce_pollfd_idx;
> @@ -107,21 +109,107 @@ struct console {
>   struct domain *d;
>  };
>  
> +struct console_data {

console_type?

> + char *xsname;
> + char *ttyname;
> + char *log_suffix;
> +};
> +
> +static struct console_data console_data[] = {
> + {
> + .xsname = "/console",
> + .ttyname = "tty",
> + .log_suffix = "",
> + },
> +};
> +
> +#define MAX_CONSOLE (sizeof(console_data)/sizeof(struct console_data))

NUM_CONSOLE_TYPE?

I think we can already have multiple PV consoles, so the original name
you proposed is confusing.

> +
>  struct domain {
>   int domid;
>   bool is_dead;
>   unsigned last_seen;
>   struct domain *next;
> - struct console console;
> + struct console console[MAX_CONSOLE];
>  };
>  
>  static struct domain *dom_head;
>  
> +typedef void (*VOID_ITER_FUNC_ARG1)(struct console *);
> +typedef bool (*BOOL_ITER_FUNC_ARG1)(struct console *);
> +typedef int (*INT_ITER_FUNC_ARG1)(struct console *);
> +typedef void (*VOID_ITER_FUNC_ARG2)(struct console *,  void *);
> +typedef int (*INT_ITER_FUNC_ARG3)(struct console *,
> +   struct domain *dom, void **);
> +
>  static inline bool console_enabled(struct console *con)
>  {
>   return con->local_port != -1;
>  }
>  
> +static inline void console_iter_void_arg1(struct domain *d,
> +   VOID_ITER_FUNC_ARG1 iter_func)
> +{
> + int i = 0;

unsigned int here and in other functions.

> + struct console *con = >console[0];
> +
> + for (i = 0; i < MAX_CONSOLE; i++, con++) {
> + iter_func(con);
> + }
> +}
> +
[...]
> +
> +static inline int console_iter_int_arg1(struct domain *d,
> + INT_ITER_FUNC_ARG1 iter_func)
> +{
> + int i = 0;
> + struct console *con = >console[0];
> +
> + for (i = 0; i < MAX_CONSOLE; i++, con++) {
> + if (iter_func(con))
> + return 1;

Do you maybe want to return the return value of your iterator function?
Otherwise I don't see a point for this function to return int -- using
bool is fine.

And please document what return value means what.

> + }
> + return 0;
> +}
> +
> +static inline int console_iter_int_arg3(struct domain *d,
> + INT_ITER_FUNC_ARG3 iter_func,
> + void **iter_data)
> +{
> + int i = 0;
> + struct console *con = >console[0];
> +
> + for (i = 0; i < MAX_CONSOLE; i++, con++) {
> + if (iter_func(con, d, iter_data))
> + return 1;
> + }
> + return 0;
> +}
> +
>  static int write_all(int fd, const char* buf, size_t len)
>  {
>   while (len) {
> @@ -336,7 +424,7 @@ static int create_console_log(struct console *con)
>   return -1;
>   }
>  
> - snprintf(logfile, PATH_MAX-1, "%s/guest-%s.log", log_dir, data);
> + snprintf(logfile, PATH_MAX-1, "%s/guest-%s%s.log", log_dir, data, 
> con->log_suffix);

Line too long.

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

[Xen-devel] [libvirt test] 112515: tolerable trouble: blocked/broken/pass - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate  broken like 112499
 build-arm64-pvops 2 hosts-allocate  broken like 112499
 build-arm64   2 hosts-allocate  broken like 112499
 build-arm64   3 capture-logsbroken like 112499
 build-arm64-xsm   3 capture-logsbroken like 112499
 build-arm64-pvops 3 capture-logsbroken like 112499
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 112499
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 112499
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 112499
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  e756333daca3c95e6b84d1fb778f834392cf12ba
baseline version:
 libvirt  404d3632b974dfec4fb60471be7d8c2ab52c983a

Last test of basis   112499  2017-08-07 04:20:15 Z1 days
Testing same since   112515  2017-08-08 04:26:54 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Michal Privoznik 
  Sri Ramanujam 

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



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

Logs, config files, etc. are available at

Re: [Xen-devel] [PATCH 06/25 v7] xen/arm: vpl011: Add a new domctl API to initialize vpl011


Hi,

On 08/08/17 14:30, Wei Liu wrote:

On Tue, Aug 08, 2017 at 02:11:08PM +0100, Wei Liu wrote:

+else
+rc = -EINVAL;


Indentation.


Ignore this please.


You were right, the indentation is wrong :). It is 8 spaces rather than 4.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 04/25 v7] xen/arm: vpl011: Add support for vuart in libxl




On 08/08/17 14:38, Julien Grall wrote:

Hi Bhupinder,

On 07/08/17 09:52, Bhupinder Thakur wrote:

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289..90eaa20 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -306,6 +306,11 @@
 #define LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE 1

 /*
+ * LIBXL_HAVE_VUART indicates that the toolstack supports virtual UART.
+ */
+#define LIBXL_HAVE_VUART 1


Now that we decide to implement vUART only for ARM, I think the comment
I made on v1 still stands. I.e that you give the impression this is
supported for all architectures. But this is not true.


To complete, I would follow what we did for gic_version:

LIBXL_HAVE_BUILDINFO_ARM_VUART


--
Julien Grall

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

Re: [Xen-devel] [PATCH 04/25 v7] xen/arm: vpl011: Add support for vuart in libxl


Hi Bhupinder,

On 07/08/17 09:52, Bhupinder Thakur wrote:

diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 229e289..90eaa20 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -306,6 +306,11 @@
 #define LIBXL_HAVE_BUILDINFO_HVM_ACPI_LAPTOP_SLATE 1

 /*
+ * LIBXL_HAVE_VUART indicates that the toolstack supports virtual UART.
+ */
+#define LIBXL_HAVE_VUART 1


Now that we decide to implement vUART only for ARM, I think the comment 
I made on v1 still stands. I.e that you give the impression this is 
supported for all architectures. But this is not true.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH v3 2/3] x86/vlapic: Keep timer running when switching between one-shot and periodic mode

If we take TSC-deadline mode timer out of the picture, the Intel SDM
does not say that the timer is disable when the timer mode is change,
either from one-shot to periodic or vice versa.

After this patch, the timer is no longer disarmed on change of mode, so
the counter (TMCCT) keeps counting down.

So what does a write to LVTT changes ? On baremetal, the change of mode
is probably taken into account only when the counter reach 0. When this
happen, LVTT is use to figure out if the counter should restard counting
down from TMICT (so periodic mode) or stop counting (if one-shot mode).

This also mean that if the counter reach 0 and the mode is one-shot, a
change to periodic would not restart the timer. This is achieve by
setting vlapic->timer_last_update=0.

This patch is based on observation of the behavior of the APIC timer on
baremetal as well as check that they does not go against the description
written in the Intel SDM.

Signed-off-by: Anthony PERARD 
---
Changes in V3:
- new argument for vlapic_update_timer: tmict_updated.
  To avoid setting timer_last_update twice when TMICT is been updated.
- use values of period and delta to calculate timer_last_update only
  when register other than TMICT are been updated
---
 xen/arch/x86/hvm/vlapic.c | 52 +++
 1 file changed, 39 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 587ef8defe..7a5fbb40cd 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -520,7 +520,8 @@ static uint32_t vlapic_get_tmcct(struct vlapic *vlapic)
 counter_passed = ((hvm_get_guest_time(v) - vlapic->timer_last_update)
   / (APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor));
 
-if ( tmict != 0 )
+/* If timer_last_update is 0, then TMCCT should return 0 as well.  */
+if ( tmict && vlapic->timer_last_update )
 {
 if ( vlapic_lvtt_period(vlapic) )
 counter_passed %= tmict;
@@ -675,28 +676,47 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void *data)
  * It expect the new value of LVTT to be set *after* being called, with this
  * new values passed as parameter (only APIC_TIMER_MODE_MASK bits matter).
  */
-static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt)
+static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
+bool tmict_updated)
 {
-uint64_t period;
-bool is_periodic;
+uint64_t period, delta = 0;
+bool is_oneshot, is_periodic;
 
 is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_PERIODIC;
+is_oneshot = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_ONESHOT;
 
 period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
 * APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
 
-if ( period )
+/* Calculate the next time the timer should trigger an interrupt. */
+if ( tmict_updated )
+delta = period;
+else if ( period && vlapic->timer_last_update )
 {
-TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
+uint64_t time_passed = hvm_get_guest_time(current)
+- vlapic->timer_last_update;
+
+/* This depends of the previous mode, if a new mode is being set */
+if ( vlapic_lvtt_period(vlapic) )
+time_passed %= period;
+if ( time_passed < period )
+delta = period - time_passed;
+}
+
+if ( delta && (is_oneshot || is_periodic) )
+{
+TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
 TRC_PAR_LONG(is_periodic ? period : 0),
 vlapic->pt.irq);
 
-create_periodic_time(current, >pt, period,
+create_periodic_time(current, >pt, delta,
  is_periodic ? period : 0, vlapic->pt.irq,
  is_periodic ? vlapic_pt_cb : NULL,
  >timer_last_update);
 
 vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
+if ( !tmict_updated )
+vlapic->timer_last_update -= period - delta;
 
 HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
 "bus cycle is %uns, "
@@ -709,6 +729,12 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
uint32_t lvtt)
 {
 TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
 destroy_periodic_time(>pt);
+/*
+ * From now, TMCCT should return 0 until TMICT is set again.
+ * This is because the timer mode was one-shot when the counter reach 0
+ * or just because the timer is disable.
+ */
+vlapic->timer_last_update = 0;
 }
 }
 
@@ -776,16 +802,16 @@ static void vlapic_reg_write(struct vcpu *v,
 break;
 
 case APIC_LVTT: /* LVT Timer Reg */
-if ( (vlapic_get_reg(vlapic, offset) & APIC_TIMER_MODE_MASK) !=
- (val & APIC_TIMER_MODE_MASK) )
+if (

[Xen-devel] [PATCH v3 0/3] Rework vlapic timer to behave more like real-hardware

Hi,

When developing PVH for OVMF, I've used the lapic timer. It turns out that the
way it is used by OVMF did not work with Xen [1]. I tried to find out how
real-hw behave, and write a XTF tests [2]. And this patch series tries to fix
the behavior of the vlapic timer.

The OVMF driver for the APIC timer initialize the timer like this:
  write to TMICT (initial counter)
  write to TMDCR (divide configuration)
  enable the timer (this may change timer mode from one-shot to periodic)
It turns out that TMICT is set to 0 on the last step, but OVMF expect the timer
to run.

Here is some description of the APIC timer, base on observation as well as read
of the Intel SDM. The description is also patch of patch description
(reworded).

Maybe a way of thinking how the APIC timer is evaluated, is to think of how
hardward will do it. There is a counter TMCCT which always keeps counting down.

Setting TMICT also set TMCCT, nothing else matter.
Setting LVTT does not change anything right away.
Setting TMDCR does not change much.

Now TMCCT keeps counting down, by a value related to TMDCR.
Once, TMCCT reach 0, it is only at this time that LVTT is taken into account.
Is there an interrupt to deliver? Should the timer restart counting from the
value in TMICT?

In the Intel SDM, there is the word "disarm" of the timer used. I guess the
easier way to disarm the APIC timer (when in periodic or one-shot) is to set
TMICT to 0. But if we take TSC-Deadline mode out of the picture, there is
nothing in the manual that say that the timer is disarm or stopped when
changing timer mode (there is only two modes left, period and one-shot).

As for the TSC-deadline timer mode, observation shown that changing to it (or
from it) does reset and disarm both timers, so effectively TMICT and the
tscdeadline are set to 0.

There is a XTF patch series that check the emulation of the vlapic timer.
"[XTF PATCH V2 0/3] Testing vlapic timer"

This patch series can be found at:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
tag: vlapic-timer-v3

Changes in V3:
- details in patches.

Changes in V2:
- patches have been reworked.
- vlapic_update_timer does not care anymore which register is been changed.
- more comments, hopefully also better.

Thanks,

[1] https://lists.xenproject.org/archives/html/xen-devel/2016-12/msg00959.html
[2] v1: 
https://lists.xenproject.org/archives/html/xen-devel/2017-03/msg02533.html
v2: look for "[XTF PATCH V2 0/3] Testing vlapic timer"

Anthony PERARD (3):
  x86/vlapic: Introduce vlapic_update_timer
  x86/vlapic: Keep timer running when switching between one-shot and
periodic mode
  x86/vlapic: Apply change to TDCR right away to the timer

 xen/arch/x86/hvm/vlapic.c | 126 ++
 1 file changed, 94 insertions(+), 32 deletions(-)

-- 
Anthony PERARD


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

[Xen-devel] [PATCH v3 1/3] x86/vlapic: Introduce vlapic_update_timer

There should not be any functionality change with this patch.

This function is used when the APIC_TMICT register is updated.

vlapic_update_timer is introduce as it will be use also when the
registers APIC_LVTT and APIC_TDCR are updated.

Signed-off-by: Anthony PERARD 
---
Changes in V3:
- removed variable delta, which had the same value as period.
---
 xen/arch/x86/hvm/vlapic.c | 72 ++-
 1 file changed, 46 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 4320c6e30a..587ef8defe 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -668,6 +668,50 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void *data)
 vcpu_vlapic(v)->hw.tdt_msr = 0;
 }
 
+/*
+ * This function is used when a register related to the APIC timer is updated.
+ * It expects the new value for the register TMICT to be set *before*
+ * being called.
+ * It expect the new value of LVTT to be set *after* being called, with this
+ * new values passed as parameter (only APIC_TIMER_MODE_MASK bits matter).
+ */
+static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt)
+{
+uint64_t period;
+bool is_periodic;
+
+is_periodic = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_PERIODIC;
+
+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
+
+if ( period )
+{
+TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
+TRC_PAR_LONG(is_periodic ? period : 0),
+vlapic->pt.irq);
+
+create_periodic_time(current, >pt, period,
+ is_periodic ? period : 0, vlapic->pt.irq,
+ is_periodic ? vlapic_pt_cb : NULL,
+ >timer_last_update);
+
+vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
+
+HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
+"bus cycle is %uns, "
+"initial count %u, period %"PRIu64"ns",
+APIC_BUS_CYCLE_NS,
+vlapic_get_reg(vlapic, APIC_TMICT),
+period);
+}
+else
+{
+TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
+destroy_periodic_time(>pt);
+}
+}
+
 static void vlapic_reg_write(struct vcpu *v,
  unsigned int offset, uint32_t val)
 {
@@ -764,37 +808,13 @@ static void vlapic_reg_write(struct vcpu *v,
 break;
 
 case APIC_TMICT:
-{
-uint64_t period;
-
 if ( !vlapic_lvtt_oneshot(vlapic) && !vlapic_lvtt_period(vlapic) )
 break;
 
 vlapic_set_reg(vlapic, APIC_TMICT, val);
-if ( val == 0 )
-{
-TRACE_0D(TRC_HVM_EMUL_LAPIC_STOP_TIMER);
-destroy_periodic_time(>pt);
-break;
-}
 
-period = (uint64_t)APIC_BUS_CYCLE_NS * val * vlapic->hw.timer_divisor;
-TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(period),
- TRC_PAR_LONG(vlapic_lvtt_period(vlapic) ? period : 0LL),
- vlapic->pt.irq);
-create_periodic_time(current, >pt, period, 
- vlapic_lvtt_period(vlapic) ? period : 0,
- vlapic->pt.irq,
- vlapic_lvtt_period(vlapic) ? vlapic_pt_cb : NULL,
- >timer_last_update);
-vlapic->timer_last_update = vlapic->pt.last_plt_gtime;
-
-HVM_DBG_LOG(DBG_LEVEL_VLAPIC,
-"bus cycle is %uns, "
-"initial count %u, period %"PRIu64"ns",
-APIC_BUS_CYCLE_NS, val, period);
-}
-break;
+vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT));
+break;
 
 case APIC_TDCR:
 vlapic_set_tdcr(vlapic, val & 0xb);
-- 
Anthony PERARD


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

[Xen-devel] [PATCH v3 3/3] x86/vlapic: Apply change to TDCR right away to the timer

The description in the Intel SDM of how the divide configuration
register is used: "The APIC timer frequency will be the processor's bus
clock or core crystal clock frequency divided by the value specified in
the divide configuration register."

Observation of baremetal shown that when the TDCR is change, the TMCCT
does not change or make a big jump in value, but the rate at which it
count down change.

The patch update the emulation to APIC timer to so that a change to the
divide configuration would be reflected in the value of the counter and
when the next interrupt is triggered.

Signed-off-by: Anthony PERARD 
---
Changes in V3:
- do the calculation when the divisor is change only if delta is !0.
---
 xen/arch/x86/hvm/vlapic.c | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index 7a5fbb40cd..4bfc53eab7 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -672,12 +672,13 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void *data)
 /*
  * This function is used when a register related to the APIC timer is updated.
  * It expects the new value for the register TMICT to be set *before*
- * being called.
+ * being called, and the previous value of the divisor (calculated from TDCR)
+ * to be passed as argument.
  * It expect the new value of LVTT to be set *after* being called, with this
  * new values passed as parameter (only APIC_TIMER_MODE_MASK bits matter).
  */
 static void vlapic_update_timer(struct vlapic *vlapic, uint32_t lvtt,
-bool tmict_updated)
+bool tmict_updated, uint32_t old_divisor)
 {
 uint64_t period, delta = 0;
 bool is_oneshot, is_periodic;
@@ -686,7 +687,7 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
uint32_t lvtt,
 is_oneshot = (lvtt & APIC_TIMER_MODE_MASK) == APIC_TIMER_MODE_ONESHOT;
 
 period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
-* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
+* APIC_BUS_CYCLE_NS * old_divisor;
 
 /* Calculate the next time the timer should trigger an interrupt. */
 if ( tmict_updated )
@@ -705,6 +706,13 @@ static void vlapic_update_timer(struct vlapic *vlapic, 
uint32_t lvtt,
 
 if ( delta && (is_oneshot || is_periodic) )
 {
+if ( vlapic->hw.timer_divisor != old_divisor )
+{
+period = (uint64_t)vlapic_get_reg(vlapic, APIC_TMICT)
+* APIC_BUS_CYCLE_NS * vlapic->hw.timer_divisor;
+delta = delta * vlapic->hw.timer_divisor / old_divisor;
+}
+
 TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(delta),
 TRC_PAR_LONG(is_periodic ? period : 0),
 vlapic->pt.irq);
@@ -810,7 +818,7 @@ static void vlapic_reg_write(struct vcpu *v,
 }
 vlapic->pt.irq = val & APIC_VECTOR_MASK;
 
-vlapic_update_timer(vlapic, val, false);
+vlapic_update_timer(vlapic, val, false, vlapic->hw.timer_divisor);
 
 /* fallthrough */
 case APIC_LVTTHMR:  /* LVT Thermal Monitor */
@@ -839,15 +847,23 @@ static void vlapic_reg_write(struct vcpu *v,
 
 vlapic_set_reg(vlapic, APIC_TMICT, val);
 
-vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT), true);
+vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT), true,
+vlapic->hw.timer_divisor);
 break;
 
 case APIC_TDCR:
+{
+uint32_t current_divisor = vlapic->hw.timer_divisor;
+
 vlapic_set_tdcr(vlapic, val & 0xb);
+
+vlapic_update_timer(vlapic, vlapic_get_reg(vlapic, APIC_LVTT), false,
+current_divisor);
 HVM_DBG_LOG(DBG_LEVEL_VLAPIC_TIMER, "timer divisor is %#x",
 vlapic->hw.timer_divisor);
 break;
 }
+}
 }
 
 static int vlapic_write(struct vcpu *v, unsigned long address,
-- 
Anthony PERARD


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

Re: [Xen-devel] [PATCH 19/25 v7] xen/arm: vpl011: Add a new console_open_log function in xenconsole

On Mon, Aug 07, 2017 at 02:23:11PM +0530, Bhupinder Thakur wrote:
> This patch introduces a console_open_log console_cleanup function. This 
> function
> opens the console log file.
> 
> Signed-off-by: Bhupinder Thakur 
> Reviewed-by: Stefano Stabellini 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 06/25 v7] xen/arm: vpl011: Add a new domctl API to initialize vpl011

On Tue, Aug 08, 2017 at 02:11:08PM +0100, Wei Liu wrote:
> > +else
> > +rc = -EINVAL;
> 
> Indentation.

Ignore this please.

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

Re: [Xen-devel] [PATCH 18/25 v7] xen/arm: vpl011: Add a new console_cleanup function in xenconsole

On Mon, Aug 07, 2017 at 02:23:10PM +0530, Bhupinder Thakur wrote:
> This patch introduces a new console_cleanup function. This function
> frees up the console resources.
> 
> Signed-off-by: Bhupinder Thakur 
> Reviewed-by: Stefano Stabellini 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

On 08/08/17 14:25, Boris Ostrovsky wrote:
> On 08/08/2017 05:48 AM, Jan Beulich wrote:
> Andrew Cooper  08/07/17 7:19 PM >>>
>>> More than once, we've discussed freeing up the legacy PIC range of
>>> vectors, and freeing up the unallocated vectors in 0xfx.
>> And that's something I would prefer over the change proposed here,
>> albeit I realize that the amount of vectors to recover isn't that large.
> That would only net us 32 vectors at the most. That probably wouldn't be
> sufficient in many cases where we are currently having vector shortage.
> Unfortunately I don't have access to my failing system to say how may
> vectors I was short but I believe it was more than that.

Indeed, which is why I haven't actually undertaken the work.  It doesn't
come close to solving the problem.

> (I am also not sure I understand what is meant by "freeing". Where are
> they going?)

By "freeing", I mean "available for general irq use" rather than being
reserved and unused in the system.

~Andrew

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

Re: [Xen-devel] [PATCH] x86/apic/x2apic: Share IRQ vector between cluster members only when no cpumask is specified

On 08/08/2017 05:48 AM, Jan Beulich wrote:
 Andrew Cooper  08/07/17 7:19 PM >>>
>> More than once, we've discussed freeing up the legacy PIC range of
>> vectors, and freeing up the unallocated vectors in 0xfx.
> And that's something I would prefer over the change proposed here,
> albeit I realize that the amount of vectors to recover isn't that large.

That would only net us 32 vectors at the most. That probably wouldn't be
sufficient in many cases where we are currently having vector shortage.
Unfortunately I don't have access to my failing system to say how may
vectors I was short but I believe it was more than that.

(I am also not sure I understand what is meant by "freeing". Where are
they going?)

-boris

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

Re: [Xen-devel] [PATCH v7 00/14] arm/mem_access: Walk guest page tables in SW if mem_access is active