date:20171011

Re: [Xen-devel] [PATCH v4] x86: psr: support co-exist features' values setting

2017-10-11 Thread Chao Peng

On Wed, 2017-10-11 at 09:55 +0800, Yi Sun wrote:
> The whole value array is transferred into 'do_write_psr_msrs'. Then,
> we can
> write all features values on the cos id into MSRs.
> 
> Because multiple features may co-exist, we need handle all features to
> write
> values of them into a COS register with new COS ID. E.g:
> 1. L3 CAT and L2 CAT co-exist.
> 2. Dom1 and Dom2 share the same COS ID (2). The L3 CAT CBM of Dom1 is
> 0x1ff,
>    the L2 CAT CBM of Dom1 is 0x1f.
> 3. User wants to change L2 CBM of Dom1 to be 0xf. Because COS ID 2 is
>    used by Dom2 too, we have to pick a new COS ID 3. The values of
> Dom1 on
>    COS ID 3 are all default values as below:
>    -
>    | COS 3 |
>    -
>    L3 CAT  | 0x7ff |
>    -
>    L2 CAT  | 0xff  |
>    -
> 4. After setting, the L3 CAT CBM value of Dom1 should be kept and the
> new L2
>    CAT CBM is set. So, the values on COS ID 3 should be below.
>    -
>    | COS 3 |
>    -
>    L3 CAT  | 0x1ff |
>    -
>    L2 CAT  | 0xf   |
>    -
> 
> Signed-off-by: Yi Sun 
> ---
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Julien Grall 
> 
> v4:
> - remove init of 'result'.
>   (suggested by Roger Pau Monné)
> - remove 'features' in 'cos_write_info' and get socket info in
>   'do_write_psr_msrs' to get features array.
>   (suggested by Jan Beulich)
> - fix a typo in commit message.
>   (suggested by Kent R. Spillner)
> v3:
> - add 'result' in 'cos_write_info' to return error code.
>   (suggested by Roger Pau Monné)
> v2:
> - fix issues in commit message.
>   (suggested by Roger Pau Monné)
> - remove unnecessary local variable 'val_array'.
>   (suggested by Roger Pau Monné)
> ---
>  xen/arch/x86/psr.c | 62 +++
> ---
>  1 file changed, 36 insertions(+), 26 deletions(-)
> 
> diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
> index daa2aeb..a812124 100644
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -,25 +,48 @@ static unsigned int get_socket_cpu(unsigned
> int socket)
>  struct cos_write_info
>  {
>  unsigned int cos;
> -struct feat_node *feature;
>  const uint32_t *val;
> -const struct feat_props *props;
> +unsigned int array_len;
> +int result;
>  };
>  
>  static void do_write_psr_msrs(void *data)
>  {
> -const struct cos_write_info *info = data;
> -struct feat_node *feat = info->feature;
> -const struct feat_props *props = info->props;
> -unsigned int i, cos = info->cos, cos_num = props->cos_num;
> +struct cos_write_info *info = data;
> +unsigned int i, index = 0, cos = info->cos;
> +struct psr_socket_info *socket_info =
> +get_socket_info(cpu_to_socket(smp_process
> or_id()));
>  
> -for ( i = 0; i < cos_num; i++ )
> +/*
> + * Iterate all featuers to write different value (not same as
> MSR) for
> + * each feature.
> + */
> +for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
>  {
> -if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
> +struct feat_node *feat = socket_info->features[i];
> +const struct feat_props *props = feat_props[i];
> +unsigned int cos_num, j;
> +
> +if ( !feat || !props )
> +continue;
> +
> +cos_num = props->cos_num;
> +if ( info->array_len < index + cos_num )
> +{
> +info->result = -ENOSPC;
> +return;

This will have side effect (You may have run write_msr for some features
already) when you return the error. It probably will not cause logic
error here, there is performance penalty however (writing MSR and
sending IPI).

Another thing is this error is a real error that we want to propagate to
user? E.g, I don't quite understand in which case the condition can
happen? If this is only a program error then ASSERT can be used.

Chao
> +}
> +
> +for ( j = 0; j < cos_num; j++ )
>  {
> -feat->cos_reg_val[cos * cos_num + i] = info->val[i];
> -props->write_msr(cos, info->val[i], props->type[i]);
> +if ( feat->cos_reg_val[cos * cos_num + j] != info-
> >val[index + j] )
> +{
> +feat->cos_reg_val[cos * cos_num + j] = info-
> >val[index + j];
> +props->write_msr(cos, info->val[index + j], props-
> >type[j]);
> +}
>  }
> +
> +index += cos_num;
>  }
>  }
>  
> @@ -1137,30 +1160,17 @@ static int write_psr_msrs(unsigned int socket,
> unsigned int cos,
>    const uint32_t val[], unsigned int
> array_len,
>    enum psr_feat_type feat_type)
>  {
> -int ret;
>  struct psr_socket_info *info = get_socket_info(socket);
>  struct cos_write_info data =
>  {
>

[Xen-devel] [Intel-gfx] [GVT-g] [ANNOUNCE] 2017-Q3 release of XenGT (Intel GVT-g for Xen)

2017-10-11 Thread Xu, Terrence

Hi all,

We are pleased to announce an update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel processor
graphics. A virtual GPU instance is maintained for each VM, with part of
performance critical resources directly assigned. The capability of running
native graphics driver inside a VM, without hypervisor intervention in
performance critical paths, achieves a good balance among performance, feature,
and sharing capability. GVT-g for Xen hypervisor is XenGT.

Repositories
- Xen : https://github.com/01org/igvtg-xen (tag: 2017-q3-xengt-stable-4.9)
- Kernel: https://github.com/01org/gvt-linux/ (tag: 2017-q3-gvt-stable-4.12)
- Qemu: https://github.com/01org/igvtg-qemu (tag: 2017-q3-stable-2.9.0)

This update consists of:
- Kernel version upgraded to 4.12 from 4.11.
- Live migration feature preliminary supported.
- QoS feature preliminary supported.
- IOMMU feature supported.
- OVMF feature supported.
- VGPU reset feature optimization, with related issues be fixed.
- Supported server platforms: Intel(r) Xeon(r) E3_v4, E3_v5 and E3_v6 with
Intel Graphics processor, E3_v6 is new supported platform.
- Supported client platforms: Intel(r) Core(tm) 5th generation (code name:
Broadwell), 6th generation (code name: Skylake) and 7th generation (code name:
Kabylake), 7th generation is new supported platform.
- Validated Guest OS: Windows7 32bit, Window7 64bit, Windows8.1 64bit,
Windows10 64bit and Linux.
- GVT-g only supports remote display not local display by this release.
- Remote protocol: only guest-side remoting protocol is supported, host-side
remoting connection like SPICE is working in progress. For example, user can
use X11VNC for Guest Linux VM or TightVNC for Guest Windows VM.

Limitation or known issues:
- GVT-g can support maximum 7 Guest VMs due to host graphics resource
limitation. When user runs 7 VMs simultaneously, host OS can only run in text
mode.
- In order to support Guest Windows7 32bit VM, user is recommended to
configure vgt_low_gm_sz=128 / 256 / 512 in HVM file because Guest Windows7
32bit VM needs more graphics resource than other Guest VM.
- In order to support Guest VM high resolution and screen resolution
adjustable in Guest Windows8.1 64bit VM and Guest Windows10 64bit VM, user is
recommended to configure vgt_low_gm_sz=64 / 128 / 256 / 512 in HVM file to get
larger VM aperture size.
- Some 3rd party applications/tools like 3DMark which including special
DirectX12 feature test ,it will trigger Guest VM GPU reset.
- In corner case, Guest Windows 7 32bit VM may be killed automatically by
Xen when Guest VM runs into TDR. This issues happens only on Broadwell
platform. The workaround is to disable part of viridian feature in Guest VM hvm
file by adding viridian=["all", "!apic_assist"].
- In corner case, Linux Guest VM may GPU hang while running special
Intel-GPU-Tools test case on it.
- For live migration feature, we cannot migrate Guest Windows VM when Guest
VM memory is 2048M or 4096M, user is recommended to configure Guest VM memory
to 1024MB.

Setup guide:
https://github.com/01org/gvt-linux/wiki/GVTg_Setup_Guide

This is the first GVT-g community release based on new Upstream architecture
design, refer to the following document for new architecture introduction:
https://01.org/igvt-g/documentation/intel-gvt-g-new-architecture-introduction

Please subscribe to join the mailing list if you want to learn more about GVT-g
project:
https://lists.01.org/mailman/listinfo/igvt-g
Please subscribe to join the mailing list if you want to contribute/review
latest GVT-g upstream patches:
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

Official GVT-g portal:
https://01.org/igvt-g

More information about background, architecture and others about Intel GVT-g,
can be found at:
https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf
http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt

Note:
The XenGT project should be considered a work in progress. As such it is not a
complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the XenGT project.

Thanks
Terrence
Tel: +86-21-6116 5390
MP: +86-1356 4367 024
Mail: terrence...@intel.com

___
GVT-g mailing list
igv...@lists.01.org
https://lists.01.org/mailman/listinfo/igvt-g

___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Xen-devel] [PATCH v4] x86: psr: support co-exist features' values setting

2017-10-11 Thread Yi Sun

On 17-10-11 14:59:23, Chao Peng wrote:
> On Wed, 2017-10-11 at 09:55 +0800, Yi Sun wrote:
> >  static void do_write_psr_msrs(void *data)
> >  {
> > -const struct cos_write_info *info = data;
> > -struct feat_node *feat = info->feature;
> > -const struct feat_props *props = info->props;
> > -unsigned int i, cos = info->cos, cos_num = props->cos_num;
> > +struct cos_write_info *info = data;
> > +unsigned int i, index = 0, cos = info->cos;
> > +struct psr_socket_info *socket_info =
> > +get_socket_info(cpu_to_socket(smp_process
> > or_id()));
> >  
> > -for ( i = 0; i < cos_num; i++ )
> > +/*
> > + * Iterate all featuers to write different value (not same as
> > MSR) for
> > + * each feature.
> > + */
> > +for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
> >  {
> > -if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
> > +struct feat_node *feat = socket_info->features[i];
> > +const struct feat_props *props = feat_props[i];
> > +unsigned int cos_num, j;
> > +
> > +if ( !feat || !props )
> > +continue;
> > +
> > +cos_num = props->cos_num;
> > +if ( info->array_len < index + cos_num )
> > +{
> > +info->result = -ENOSPC;
> > +return;
> 
> This will have side effect (You may have run write_msr for some features
> already) when you return the error. It probably will not cause logic
> error here, there is performance penalty however (writing MSR and
> sending IPI).
> 
> Another thing is this error is a real error that we want to propagate to
> user? E.g, I don't quite understand in which case the condition can
> happen? If this is only a program error then ASSERT can be used.
> 
Thanks! If error happens, this error is a program error. So, an ASSERT here
is better.

> Chao

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

[Xen-devel] [xen-unstable-smoke test] 114332: regressions - FAIL

2017-10-11 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 114299

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

version targeted for testing:
 xen  f17d2cd2ffeda70aba8788910e9d088415562c8b
baseline version:
 xen  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z0 days
Failing since114308  2017-10-10 23:01:10 Z0 days3 attempts
Testing same since   114318  2017-10-11 02:19:34 Z0 days2 attempts


People who touched revisions under test:
  Andre Przywara 
  Julien Grall 
  Stefano Stabellini 

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



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

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

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

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


Not pushing.


commit f17d2cd2ffeda70aba8788910e9d088415562c8b
Author: Andre Przywara 
Date:   Sat Oct 7 01:06:40 2017 +0100

ARM: sunxi: support more Allwinner SoCs

So far we only supported the Allwinner A20 SoC. Add support for most
of the other virtualization capable Allwinner SoCs by:
- supporting the watchdog in newer (sun8i) SoCs
- getting the watchdog address from DT
- adding compatible strings for other 32-bit SoCs
- adding compatible strings for 64-bit SoCs

As all 64-bit SoCs support system reset via PSCI, we don't use the
platform specific reset routine there. Should the 32-bit SoCs start to
properly support the PSCI 0.2 SYSTEM_RESET call, we will use it for them
automatically, as we try PSCI first, then fall back to platform reset.

Signed-off-by: Andre Przywara 
Signed-off-by: Stefano Stabellini 
Reviewed-by: Stefano Stabellini 

commit e2dfe4a037b0c6ccfd2375e4b60668109a0118e5
Author: Julien Grall 
Date:   Mon Oct 9 14:23:41 2017 +0100

xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one

This will help to consolidate the page-table code and avoid different
path depending on the action to perform.

Signed-off-by: Julien Grall 
Reviewed-by: Andre Przywara 
Reviewed-by: Stefano Stabellini 
Reviewed-by: Konrad Rzeszutek Wilk 

commit 6b88beed40c756aaff018d286f4de31351240a93
Author: Julien Grall 
Date:   Mon Oct 9 14:23:40 2017 +0100

xen/arm: mm: Handle permission flags when adding a new mapping

Currently, all the new mappings will be read-write non-executable. Allow the
caller to use other permissions.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 

commit 28f2ad440a08908010abec43b7ccc3283051e943
Author: Julien Grall 
Date:   Mon Oct 9 14:23:39 2017 +0100

xen/arm: mm: Embed permission in the flags

Currently, it is not possible to specify the permission of a new
mapping. It would be necessary to use the function modify_xen_mappings
with a different set of flags.

Introduce a couple of new flags for the permissions (Non-eXecutable,
Read-Only) and also provides definition that combine the memory attribute
and permission for common combinations.

PAGE_HYPERVISOR is now an alias to PAGE_HYPERVISOR_RW (read-write,
non-executable mappings). This does not affect the current mapping using
PAGE_HYPERVISOR because Xen is currently forcing all the mapping to be
non-executable by default (see mfn_to_xen_entry).

A follow-up patch will change modify_xen_mappings to use the new flags.

Signed-off-by: Julien Grall 
Reviewed-by: Stefano Stabellini 
Signed-off-by: Stefano Stabellini 

commit 5f3edb5f32e511b915d173403d0b7b5ea38e00ad
Author: Julien Grall 
Date:   Mon Oct 9 14:23:38 2017 +0100

xen/arm: page: Describe the layout of flags used to update page tables

Re: [Xen-devel] [xen-unstable-smoke test] 114332: regressions - FAIL

2017-10-11 Thread Roger Pau Monné

Adding Julien and Stefano.

On Wed, Oct 11, 2017 at 07:17:59AM +, osstest service owner wrote:
> flight 114332 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/114332/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 
> 114299

Seems like Xen is not able to start on the Exynos or Cubietrucks
anymore:

Oct 11 06:52:11.479093 
U-Boot 2014.10-7-g0052a7d (Sep 29 2015 - 10:21:38) for ARNDALE
Oct 11 06:52:11.487075 
Oct 11 06:52:11.487090 
CPU:Exynos5250@1000MHz
Oct 11 06:52:11.487106 
Oct 11 06:52:11.487118 
Board: Arndale
Oct 11 06:52:11.487132 
I2C:   i2c_init: failed to init bus 0 for speed = 10
Oct 11 06:52:11.495063 
ready
Oct 11 06:52:11.495078 
DRAM:  2 GiB
Oct 11 06:52:11.495092 
trace: copying 000ab188 bytes of early data from 5000 to beff
Oct 11 06:52:11.511080 
trace: enabled
Oct 11 06:52:11.551032 
MMC:   EXYNOS DWMMC: 0, EXYNOS DWMMC: 1
Oct 11 06:52:11.911146 
i2c_init: failed to init bus 0 for speed = 10
Oct 11 06:52:11.967154 
In:serial
Oct 11 06:52:11.967185 
Out:   serial
Oct 11 06:52:11.967211 
Err:   serial
Oct 11 06:52:11.967236 
SCSI:  ARNDALE SCSI INIT
Oct 11 06:52:11.975119 
Target spinup took 0 ms.
Oct 11 06:52:11.983147 
AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode
Oct 11 06:52:11.983188 
flags: ncq stag pm led clo only pmp pio slum part ccc apst 
Oct 11 06:52:11.991155 
Net:   Net Initialization Skipped
Oct 11 06:52:11.991189 
No ethernet found.
Oct 11 06:52:11.991216 
Hostname: arndale-westfield
Oct 11 06:52:11.999141 
Hit any key to stop autoboot:  2  1  0 
Oct 11 06:52:13.919168 
(Re)start USB...
Oct 11 06:52:13.919223 
USB0:   USB EHCI 1.00
Oct 11 06:52:13.927090 
scanning bus 0 for devices... 4 USB Device(s) found
Oct 11 06:52:19.523158 
   scanning usb for storage devices... 0 Storage Device(s) found
Oct 11 06:52:19.531073 
   scanning usb for ethernet devices... 1 Ethernet Device(s) found
Oct 11 06:52:19.971149 
Waiting for Ethernet connection... done.
Oct 11 06:52:21.571140 
BOOTP broadcast 1
Oct 11 06:52:21.571189 
BOOTP broadcast 2
Oct 11 06:52:22.619159 
DHCP client bound to address 172.16.144.45 (1092 ms)
Oct 11 06:52:22.627153 
Using asx0 device
Oct 11 06:52:22.627188 
TFTP from server 172.16.144.3; our IP address is 172.16.144.45
Oct 11 06:52:22.635136 
Filename 'pxelinux.0'.
Oct 11 06:52:22.635157 
Load address: 0x43e0
Oct 11 06:52:22.635173 
Loading: *##
Oct 11 06:52:22.651084 
 1.8 MiB/s
Oct 11 06:52:22.651119 
done
Oct 11 06:52:22.651144 
Bytes transferred = 26474 (676a hex)
Oct 11 06:52:22.651177 
missing environment variable: pxeuuid
Oct 11 06:52:22.659068 
Retrieving file: pxelinux.cfg/AC10902D
Oct 11 06:52:22.659103 
Using asx0 device
Oct 11 06:52:22.659161 
TFTP from server 172.16.144.3; our IP address is 172.16.144.45
Oct 11 06:52:22.667076 
Filename 'pxelinux.cfg/AC10902D'.
Oct 11 06:52:22.675051 
Load address: 0x5100
Oct 11 06:52:22.675082 
Loading: *#
Oct 11 06:52:22.675106 
 15.6 KiB/s
Oct 11 06:52:22.675131 
done
Oct 11 06:52:22.675153 
Bytes transferred = 65 (41 hex)
Oct 11 06:52:22.683067 
Config file found
Oct 11 06:52:22.683096 
Ignoring unknown command: serial
Oct 11 06:52:22.683124 
1:  local
Oct 11 06:52:22.691033 
scanning bus for devices...
Oct 11 06:52:22.691064 
  Device 0: (0:0) Vendor: ATA Prod.: HGST HTS545050A7 Rev: GG2O
Oct 11 06:52:22.715075 
Type: Hard Disk
Oct 11 06:52:22.723062 
Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
Oct 11 06:52:22.723100 
Found 1 device(s).
Oct 11 06:52:22.723126 
Oct 11 06:52:22.723147 
SCSI device 0: 
Oct 11 06:52:22.731046 
Device 0: (0:0) Vendor: ATA Prod.: HGST HTS545050A7 Rev: GG2O
Oct 11 06:52:22.731093 
Type: Hard Disk
Oct 11 06:52:22.739063 
Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
Oct 11 06:52:22.739100 
... is now current device
Oct 11 06:52:22.747037 
Scanning scsi 0...
Oct 11 06:52:22.747066 
Found U-Boot script /boot.scr
Oct 11 06:52:22.907117 
1710 bytes read in 34 ms (48.8 KiB/s)
Oct 11 06:52:22.947138 
## Executing script at 5000
Oct 11 06:52:22.955124 
Loading dtbs/4.9.20+/exynos5250-arndale.dtb
Oct 11 06:52:22.955175 
43128 bytes read in 1186 ms (35.2 KiB/s)
Oct 11 06:52:24.115168 
917512 bytes read in 111 ms (7.9 MiB/s)
Oct 11 06:52:24.251222 
Loaded xen-4.10-unstable to 0x4100 (e0008)
Oct 11 06:52:24.259243 
command line: conswitch=x watchdog noreboot console=dtuart dtuart=serial2 
dom0_mem=512M,max:512M
Oct 11 06:52:24.267256 
6798760 bytes read in 305 ms (21.3 MiB/s)
Oct 11 06:52:24.587101 
Loaded vmlinuz-4.9.20+ to 0x4200 (67bda8)
Oct 11 06:52:24.595066 
command line: ro root=/dev/mapper/arndale--westfield--vg-root rootdelay=3 ro 
root=/dev/mapper/arndale--westfield--vg-root rootdelay=3 console=hvc0 
clk_ignore_unused clk_ignore_unused
Oct 11 06:52:24.61

Re: [Xen-devel] [PATCH 1/1] sched/cputime: do not decrease steal time after live migration on xen

2017-10-11 Thread Dongli Zhang

Hi Stanislaw and Peter,

On 10/10/2017 08:42 PM, Stanislaw Gruszka wrote:
> On Tue, Oct 10, 2017 at 12:59:26PM +0200, Ingo Molnar wrote:
>>
>> (Cc:-ed more gents involved in kernel/sched/cputime.c work. Full patch 
>> quoted 
>> below.)
>>
>> * Dongli Zhang  wrote:
>>
>>> After guest live migration on xen, steal time in /proc/stat
>>> (cpustat[CPUTIME_STEAL]) might decrease because steal returned by
>>> paravirt_steal_clock() might be less than this_rq()->prev_steal_time.
>>>
>>> For instance, steal time of each vcpu is 335 before live migration.
>>>
>>> cpu  198 0 368 200064 1962 0 0 1340 0 0
>>> cpu0 38 0 81 50063 492 0 0 335 0 0
>>> cpu1 65 0 97 49763 634 0 0 335 0 0
>>> cpu2 38 0 81 50098 462 0 0 335 0 0
>>> cpu3 56 0 107 50138 374 0 0 335 0 0
>>>
>>> After live migration, steal time is reduced to 312.
>>>
>>> cpu  200 0 370 200330 1971 0 0 1248 0 0
>>> cpu0 38 0 82 50123 500 0 0 312 0 0
>>> cpu1 65 0 97 49832 634 0 0 312 0 0
>>> cpu2 39 0 82 50167 462 0 0 312 0 0
>>> cpu3 56 0 107 50207 374 0 0 312 0 0
>>>
>>> The code in this patch is borrowed from do_stolen_accounting() which has
>>> already been removed from linux source code since commit ecb23dc6 ("xen:
>>> add steal_clock support on x86").
>>>
>>> Similar and more severe issue would impact prior linux 4.8-4.10 as
>>> discussed by Michael Las at
>>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest.
>>> Unlike the issue discussed by Michael Las which would overflow steal time
>>> and lead to 100% st usage in top command for linux 4.8-4.10, the issue for
>>> linux 4.11+ would only decrease but not overflow steal time after live
>>> migration.
>>>
>>> References: 
>>> https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
>>> Signed-off-by: Dongli Zhang 
>>> ---
>>>  kernel/sched/cputime.c | 13 ++---
>>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
>>> index 14d2dbf..57d09cab 100644
>>> --- a/kernel/sched/cputime.c
>>> +++ b/kernel/sched/cputime.c
>>> @@ -238,10 +238,17 @@ static __always_inline u64 
>>> steal_account_process_time(u64 maxtime)
>>>  {
>>>  #ifdef CONFIG_PARAVIRT
>>> if (static_key_false(¶virt_steal_enabled)) {
>>> -   u64 steal;
>>> +   u64 steal, steal_time;
>>> +   s64 steal_delta;
>>> +
>>> +   steal_time = paravirt_steal_clock(smp_processor_id());
>>> +   steal = steal_delta = steal_time - this_rq()->prev_steal_time;
>>> +
>>> +   if (unlikely(steal_delta < 0)) {
>>> +   this_rq()->prev_steal_time = steal_time;
> 
> I don't think setting prev_steal_time to smaller value is right
> thing to do.

If we do not set prev_steal_time to smaller steal (obtained from
paravirt_steal_clock()), it will take a while for kernel to wait for new steal
to catch up with this_rq()->prev_steal_time, and cpustat[CPUTIME_STEAL] will
stay unchanged until steal is more than this_rq()->prev_steal_time again. Do you
think it is fine?

If it is fine, I will try to limit the fix to xen specific code in
driver/xen/time.c so that we would not taint kernel/sched/cputime.c, as Peter
has asked why not just fix up paravirt_steal_time() on migration.

Thank you very much!

Dongli Zhang

> 
> Beside, I don't think we need to check for overflow condition for
> cputime variables (it will happen after 279 years :-). So instead
> of introducing signed steal_delta variable I would just add
> below check, which should be sufficient to fix the problem:
> 
>   if (unlikely(steal <= this_rq()->prev_steal_time))
>   return 0;
> 
> Thanks
> Stanislaw
> 

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

Re: [Xen-devel] [linux-3.18 bisection] complete test-amd64-amd64-xl-pvh-intel

2017-10-11 Thread Roger Pau Monné

On Wed, Oct 11, 2017 at 04:54:40AM +, osstest service owner wrote:
> branch xen-unstable
> xenbranch xen-unstable
> job test-amd64-amd64-xl-pvh-intel
> testid guest-start
> 
> Tree: linux 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
> Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
> Tree: qemuu git://xenbits.xen.org/qemu-xen.git
> Tree: xen git://xenbits.xen.org/xen.git
> 
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  c7dfe4ac58dd9c8678126b78da961b233a49f3f9
>   Bug not present: 3c44f8ed44ab559c7e5b58316751bea53adfd83b
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/114323/
> 
> 
>   commit c7dfe4ac58dd9c8678126b78da961b233a49f3f9
>   Author: Roger Pau Monne 
>   Date:   Fri Sep 22 16:25:06 2017 +0100
>   
>   xl: introduce a domain type option
>   
>   Introduce a new type option to xl configuration files in order to
>   specify the domain type. This supersedes the current builder option.
>   
>   The new option is documented in the xl.cfg man page, and the previous
>   builder option is marked as deprecated.
>   
>   Signed-off-by: Roger Pau Monn?? 
>   Acked-by: Ian Jackson 

This branch will have to be force pushed, together with the 4.9 one
AFAICT. This test succeed previously because we where testing a classic
PV guest instead of a PVH one.

Roger.

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

[Xen-devel] [PATCH v5] x86: psr: support co-exist features' values setting

2017-10-11 Thread Yi Sun

The whole value array is transferred into 'do_write_psr_msrs'. Then, we can
write all features values on the cos id into MSRs.

Because multiple features may co-exist, we need handle all features to write
values of them into a COS register with new COS ID. E.g:
1. L3 CAT and L2 CAT co-exist.
2. Dom1 and Dom2 share the same COS ID (2). The L3 CAT CBM of Dom1 is 0x1ff,
   the L2 CAT CBM of Dom1 is 0x1f.
3. User wants to change L2 CBM of Dom1 to be 0xf. Because COS ID 2 is
   used by Dom2 too, we have to pick a new COS ID 3. The values of Dom1 on
   COS ID 3 are all default values as below:
   -
   | COS 3 |
   -
   L3 CAT  | 0x7ff |
   -
   L2 CAT  | 0xff  |
   -
4. After setting, the L3 CAT CBM value of Dom1 should be kept and the new L2
   CAT CBM is set. So, the values on COS ID 3 should be below.
   -
   | COS 3 |
   -
   L3 CAT  | 0x1ff |
   -
   L2 CAT  | 0xf   |
   -

Signed-off-by: Yi Sun 
---
CC: Jan Beulich 
CC: Andrew Cooper 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Julien Grall 

v5:
- remove 'result' and use an ASSERT to handle error case.
  (suggested by Chao Peng)
v4:
- remove init of 'result'.
  (suggested by Roger Pau Monné)
- remove 'features' in 'cos_write_info' and get socket info in
  'do_write_psr_msrs' to get features array.
  (suggested by Jan Beulich)
- fix a typo in commit message.
  (suggested by Kent R. Spillner)
v3:
- add 'result' in 'cos_write_info' to return error code.
  (suggested by Roger Pau Monné)
v2:
- fix issues in commit message.
  (suggested by Roger Pau Monné)
- remove unnecessary local variable 'val_array'.
  (suggested by Roger Pau Monné)
---
 xen/arch/x86/psr.c | 55 +-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
index daa2aeb..8936cf7 100644
--- a/xen/arch/x86/psr.c
+++ b/xen/arch/x86/psr.c
@@ -,25 +,43 @@ static unsigned int get_socket_cpu(unsigned int socket)
 struct cos_write_info
 {
 unsigned int cos;
-struct feat_node *feature;
 const uint32_t *val;
-const struct feat_props *props;
+unsigned int array_len;
 };
 
 static void do_write_psr_msrs(void *data)
 {
-const struct cos_write_info *info = data;
-struct feat_node *feat = info->feature;
-const struct feat_props *props = info->props;
-unsigned int i, cos = info->cos, cos_num = props->cos_num;
+struct cos_write_info *info = data;
+unsigned int i, index = 0, cos = info->cos;
+struct psr_socket_info *socket_info =
+get_socket_info(cpu_to_socket(smp_processor_id()));
 
-for ( i = 0; i < cos_num; i++ )
+/*
+ * Iterate all featuers to write different value (not same as MSR) for
+ * each feature.
+ */
+for ( i = 0; i < ARRAY_SIZE(feat_props); i++ )
 {
-if ( feat->cos_reg_val[cos * cos_num + i] != info->val[i] )
+struct feat_node *feat = socket_info->features[i];
+const struct feat_props *props = feat_props[i];
+unsigned int cos_num, j;
+
+if ( !feat || !props )
+continue;
+
+cos_num = props->cos_num;
+ASSERT(info->array_len >= index + cos_num);
+
+for ( j = 0; j < cos_num; j++ )
 {
-feat->cos_reg_val[cos * cos_num + i] = info->val[i];
-props->write_msr(cos, info->val[i], props->type[i]);
+if ( feat->cos_reg_val[cos * cos_num + j] != info->val[index + j] )
+{
+feat->cos_reg_val[cos * cos_num + j] = info->val[index + j];
+props->write_msr(cos, info->val[index + j], props->type[j]);
+}
 }
+
+index += cos_num;
 }
 }
 
@@ -1137,30 +1155,17 @@ static int write_psr_msrs(unsigned int socket, unsigned 
int cos,
   const uint32_t val[], unsigned int array_len,
   enum psr_feat_type feat_type)
 {
-int ret;
 struct psr_socket_info *info = get_socket_info(socket);
 struct cos_write_info data =
 {
 .cos = cos,
-.feature = info->features[feat_type],
-.props = feat_props[feat_type],
+.val = val,
+.array_len = array_len,
 };
 
 if ( cos > info->features[feat_type]->cos_max )
 return -EINVAL;
 
-/* Skip to the feature's value head. */
-ret = skip_prior_features(&array_len, feat_type);
-if ( ret < 0 )
-return ret;
-
-val += ret;
-
-if ( array_len < feat_props[feat_type]->cos_num )
-return -ENOSPC;
-
-data.val = val;
-
 if ( socket == cpu_to_socket(smp_processor_id()) )
 do_write_psr_msrs(&data);
 else
-- 
1.9.1


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

1 2 3 >

1 - 100 of 201 matches

Mail list logo