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

2017-01-04 Thread osstest service owner
flight 104023 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104023/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9a9fa14e5c15d459e7f143c67d5d88f4b10be2ea baseline version: ovmf ab50ab6ea159821d780be

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

2017-01-04 Thread Platform Team regression test user
This run is configured for baseline tests only. flight 68313 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/68313/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf ab50ab6ea159821d780be60759874dcf38835d1b baseline v

Re: [Xen-devel] [PATCH] uapi: use wildcards to list files

2017-01-04 Thread Nicolas Dichtel
Le 03/01/2017 à 22:37, Arnd Bergmann a écrit : > On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote: >> Regularly, when a new header is created in include/uapi/, the developer >> forgets to add it in the corresponding Kbuild file. This error is usually >> detected after the release is

Re: [Xen-devel] [PATCH v4] x86/apicv: fix RTC periodic timer and apicv issue

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 02:58, wrote: > """ > intack.vector is the highest priority vector. So we set eoi_exit_bitmap > for intack.vector - give a chance to post periodic time interrupts when > periodic time interrupts become the highest one. > """ Sounds fine. Jan _

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

2017-01-04 Thread Jan Beulich
>>> On 03.01.17 at 18:29, wrote: > On 03/01/17 16:19, Jan Beulich wrote: > On 03.01.17 at 16:22, wrote: >>> On 03/01/17 13:10, Jan Beulich wrote: --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -1039,6 +1039,17 @@ static int hvmemul_cmpxchg( retur

Re: [Xen-devel] [PATCH v6 12/12] docs: Describe PVHv2's VCPU hotplug procedure

2017-01-04 Thread Jan Beulich
>>> On 03.01.17 at 20:33, wrote: > On 01/03/2017 11:58 AM, Jan Beulich wrote: > On 03.01.17 at 15:04, wrote: >>> --- a/docs/misc/hvmlite.markdown >>> +++ b/docs/misc/hvmlite.markdown >>> @@ -75,3 +75,14 @@ info structure that's passed at boot time (field > rsdp_paddr). >>> >>> Description

Re: [Xen-devel] [PATCH v5 04/14] tables.h: add linker table support

2017-01-04 Thread Andy Shevchenko
On Tue, Jan 3, 2017 at 11:25 PM, Luis R. Rodriguez wrote: > On Thu, Dec 22, 2016 at 03:58:18PM +0200, Andy Shevchenko wrote: >> On Wed, 2016-12-21 at 18:38 -0800, Luis R. Rodriguez wrote: >> > +#define LINKTABLE_FOR_EACH(pointer, tbl) >> >> Hmm... SOMEONE LIKES CAPITAL LETTERS FOR everything, righ

[Xen-devel] [PATCH] tools/libxl: include scheduler parameters in the output of xl list -l

2017-01-04 Thread Roger Pau Monne
Signed-off-by: Roger Pau Monné Reported-by: Fatih Acar --- Cc: Ian Jackson Cc: Wei Liu --- This should be backported to all supported stable branches (4.6, 4.7, 4.8). --- tools/libxl/libxl.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl

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

2017-01-04 Thread osstest service owner
flight 104027 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/104027/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen e03d4e867456cf4e288aee79b04da05d3626c242 baseline version: xen ee52

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

2017-01-04 Thread Tim Deegan
At 02:22 -0700 on 04 Jan (1483496577), Jan Beulich wrote: > >>> On 03.01.17 at 18:29, wrote: > > On 03/01/17 16:19, Jan Beulich wrote: > > On 03.01.17 at 16:22, wrote: > >>> On 03/01/17 13:10, Jan Beulich wrote: > --- a/xen/arch/x86/hvm/emulate.c > +++ b/xen/arch/x86/hvm/emulate.c >

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

2017-01-04 Thread osstest service owner
flight 104026 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104026/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 61e947457e42320bd15e2f488742996359ca5420 baseline version: ovmf 9a9fa14e5c15d459e7f14

[Xen-devel] [PATCH v2 0/2] x86emul: use unambiguous register names

2017-01-04 Thread Jan Beulich
This (together with the still pending VMX patch) concludes part I of the renaming project. The split of the changes here from what will be in part II is to limit code churn, i.e. namely to avoid touching the same line of code twice where possible. 1: make _PRE_EFLAGS() tolerate first argument bein

[Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Jan Beulich
While this may appear to introduce a truncation issue, the high 32 bits get zapped already anyway (early in _PRE_EFLAGS() as well as in _POST_EFLAGS()). Once a subsequent patch switches to use proper 32-bit EFLAGS operands, we'll in fact end up with more correct code, as that zeroing of the upper h

[Xen-devel] [PATCH v2 2/2] x86emul: use unambiguous register names

2017-01-04 Thread Jan Beulich
This is in preparation of eliminating the mis-naming of 64-bit fields with 32-bit register names (eflags instead of rflags etc). Note that the result is not fully consistent until after at least one more patch is in place, primarily to limit patch size (by trying to not touch the same line twice).

[Xen-devel] [PATCH 0/2] x86: mwait-idle improvements from Linux 4.10-rc

2017-01-04 Thread Jan Beulich
1: add CPU model 0x4a (Atom Z34xx series) 2: add Knights Mill CPUID Signed-off-by: Jan Beulich ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 09/13] libxl: Update xenstore on VCPU hotplug for all guest types

2017-01-04 Thread Wei Liu
On Fri, Dec 16, 2016 at 06:18:35PM -0500, Boris Ostrovsky wrote: > Currently HVM guests that use upstream qemu do not update xenstore's > availability entry for VCPUs. While it is not strictly necessary for > hotplug to work, xenstore end up reflecting actual status of VCPUs. > > Signed-off-by: Bo

[Xen-devel] [PATCH 1/2] x86/mwait-idle: add CPU model 0x4a (Atom Z34xx series)

2017-01-04 Thread Jan Beulich
Add CPU ID for Atom Z34xx processors. Datasheets indicate support for this, detailed information about potential quirks or limitations are missing, though. So we just reuse the definition from official BSP code. Signed-off-by: Andy Shevchenko Signed-off-by: Len Brown [Linux commit: 5e7ec268fd48d

[Xen-devel] [PATCH 2/2] x86/mwait-idle: add Knights Mill CPUID

2017-01-04 Thread Jan Beulich
Add Knights Mill (KNM) to the list of CPUIDs supported by mwait-idle. Signed-off-by: Piotr Luc Signed-off-by: Len Brown [Linux commit: a2c1bc645e87346150516b3abf1933ed29d0f48b] Signed-off-by: Jan Beulich --- a/xen/arch/x86/cpu/mwait-idle.c +++ b/xen/arch/x86/cpu/mwait-idle.c @@ -946,6 +946,7 @

Re: [Xen-devel] [PATCH v5 10/13] tools: Call XEN_DOMCTL_acpi_access on PVH VCPU hotplug

2017-01-04 Thread Wei Liu
On Fri, Dec 16, 2016 at 06:18:36PM -0500, Boris Ostrovsky wrote: > Provide libxc interface for accessing ACPI via XEN_DOMCTL_acpi_access. > > When a VCPU is hot-(un)plugged to/from a PVH guest update VCPU map > by writing to ACPI's XEN_ACPI_CPU_MAP register and then set GPE0 > status bit in GPE0.s

Re: [Xen-devel] [PATCH v6 08/12] libxl: Update xenstore on VCPU hotplug for all guest types

2017-01-04 Thread Wei Liu
On Tue, Jan 03, 2017 at 09:04:12AM -0500, Boris Ostrovsky wrote: > Currently HVM guests that use upstream qemu do not update xenstore's > availability entry for VCPUs. While it is not strictly necessary for > hotplug to work, xenstore ends up not reflecting actual status of > VCPUs. We should fix t

Re: [Xen-devel] [PATCH] x86/HVM: restrict permitted instructions during special purpose emulation

2017-01-04 Thread Andrew Cooper
On 04/01/17 10:10, Tim Deegan wrote: > At 02:22 -0700 on 04 Jan (1483496577), Jan Beulich wrote: > On 03.01.17 at 18:29, wrote: >>> On 03/01/17 16:19, Jan Beulich wrote: >>> On 03.01.17 at 16:22, wrote: > On 03/01/17 13:10, Jan Beulich wrote: >> --- a/xen/arch/x86/hvm/emulate.c >>

Re: [Xen-devel] [PATCH 0/2] x86: mwait-idle improvements from Linux 4.10-rc

2017-01-04 Thread Andrew Cooper
On 04/01/17 10:25, Jan Beulich wrote: > 1: add CPU model 0x4a (Atom Z34xx series) > 2: add Knights Mill CPUID > > Signed-off-by: Jan Beulich > Acked-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Andrew Cooper
On 04/01/17 10:22, Jan Beulich wrote: > While this may appear to introduce a truncation issue, the high 32 bits > get zapped already anyway (early in _PRE_EFLAGS() as well as in > _POST_EFLAGS()). Once a subsequent patch switches to use proper 32-bit > EFLAGS operands, we'll in fact end up with mor

Re: [Xen-devel] [PATCH v2 2/2] x86emul: use unambiguous register names

2017-01-04 Thread Andrew Cooper
On 04/01/17 10:23, Jan Beulich wrote: > This is in preparation of eliminating the mis-naming of 64-bit fields > with 32-bit register names (eflags instead of rflags etc). > > Note that the result is not fully consistent until after at least one > more patch is in place, primarily to limit patch siz

Re: [Xen-devel] [xl restore and migrating problem - hardware compatibility]

2017-01-04 Thread Wei Liu
On Wed, Dec 28, 2016 at 02:50:07PM +, Julien Grall wrote: > (Adding Ian and Wei) > > Hi Andrew, > > On 23/12/16 17:00, Andrew Cooper wrote: > >On 23/12/16 16:32, Ing. Ricardo Brisighelli wrote: > >>Hi, i'm gentoo user and try with xen 4.6.3 and 4.7.1 in both version > >>have the > >>same prob

Re: [Xen-devel] [PATCH] tools/libxl: include scheduler parameters in the output of xl list -l

2017-01-04 Thread Wei Liu
On Wed, Jan 04, 2017 at 09:55:59AM +, Roger Pau Monne wrote: > Signed-off-by: Roger Pau Monné > Reported-by: Fatih Acar > --- > Cc: Ian Jackson > Cc: Wei Liu > --- > This should be backported to all supported stable branches (4.6, 4.7, 4.8). > --- > tools/libxl/libxl.c | 10 ++ > 1

Re: [Xen-devel] [RFC] Xen PV Drivers Lifecycle

2017-01-04 Thread Wei Liu
+1 for this in principle. I have no further comment to make. :-) Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] Xen Community Call on new PV protocols, 11th Jan 9AM PST

2017-01-04 Thread Wei Liu
On Wed, Dec 21, 2016 at 02:29:17PM -0800, Stefano Stabellini wrote: > Hi all, > > the 4.9 development cycle is open, and we a number of new outstanding PV > driver protocols on the agenda. I published a proposal on the lifecycle > of PV drivers that might help speed up the process. I suggest we ha

Re: [Xen-devel] [PATCH] tools/libxl: include scheduler parameters in the output of xl list -l

2017-01-04 Thread Roger Pau Monne
On Wed, Jan 04, 2017 at 11:08:51AM +, Wei Liu wrote: > On Wed, Jan 04, 2017 at 09:55:59AM +, Roger Pau Monne wrote: > > Signed-off-by: Roger Pau Monné > > Reported-by: Fatih Acar > > --- > > Cc: Ian Jackson > > Cc: Wei Liu > > --- > > This should be backported to all supported stable br

Re: [Xen-devel] [PATCH] tools/libxl: include scheduler parameters in the output of xl list -l

2017-01-04 Thread Wei Liu
On Wed, Jan 04, 2017 at 11:20:41AM +, Roger Pau Monne wrote: > On Wed, Jan 04, 2017 at 11:08:51AM +, Wei Liu wrote: > > On Wed, Jan 04, 2017 at 09:55:59AM +, Roger Pau Monne wrote: > > > Signed-off-by: Roger Pau Monné > > > Reported-by: Fatih Acar > > > --- > > > Cc: Ian Jackson > >

Re: [Xen-devel] Xen Community Call on new PV protocols, 11th Jan 9AM PST

2017-01-04 Thread Oleksandr Andrushchenko
On 01/04/2017 01:19 PM, Wei Liu wrote: On Wed, Dec 21, 2016 at 02:29:17PM -0800, Stefano Stabellini wrote: Hi all, the 4.9 development cycle is open, and we a number of new outstanding PV driver protocols on the agenda. I published a proposal on the lifecycle of PV drivers that might help spe

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 11:56, wrote: > On 04/01/17 10:22, Jan Beulich wrote: >> While this may appear to introduce a truncation issue, the high 32 bits >> get zapped already anyway (early in _PRE_EFLAGS() as well as in >> _POST_EFLAGS()). Once a subsequent patch switches to use proper 32-bit >> EFLAGS

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Andrew Cooper
On 04/01/17 11:38, Jan Beulich wrote: On 04.01.17 at 11:56, wrote: >> On 04/01/17 10:22, Jan Beulich wrote: >>> While this may appear to introduce a truncation issue, the high 32 bits >>> get zapped already anyway (early in _PRE_EFLAGS() as well as in >>> _POST_EFLAGS()). Once a subsequent pa

Re: [Xen-devel] [PATCH] tools/libxl: include scheduler parameters in the output of xl list -l

2017-01-04 Thread Roger Pau Monne
On Wed, Jan 04, 2017 at 11:35:54AM +, Wei Liu wrote: > On Wed, Jan 04, 2017 at 11:20:41AM +, Roger Pau Monne wrote: > > On Wed, Jan 04, 2017 at 11:08:51AM +, Wei Liu wrote: > > > On Wed, Jan 04, 2017 at 09:55:59AM +, Roger Pau Monne wrote: > > > > Signed-off-by: Roger Pau Monné > >

Re: [Xen-devel] [PATCHv6 00/11] CONFIG_DEBUG_VIRTUAL for arm64

2017-01-04 Thread Will Deacon
On Tue, Jan 03, 2017 at 03:25:53PM -0800, Laura Abbott wrote: > On 01/03/2017 02:56 PM, Florian Fainelli wrote: > > On 01/03/2017 09:21 AM, Laura Abbott wrote: > >> Happy New Year! > >> > >> This is a very minor rebase from v5. It only moves a few headers around. > >> I think this series should be

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Andrew Cooper
On 04/01/17 11:42, Andrew Cooper wrote: > On 04/01/17 11:38, Jan Beulich wrote: > On 04.01.17 at 11:56, wrote: >>> On 04/01/17 10:22, Jan Beulich wrote: While this may appear to introduce a truncation issue, the high 32 bits get zapped already anyway (early in _PRE_EFLAGS() as well a

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Andrew Cooper
On 04/01/17 11:46, Andrew Cooper wrote: > On 04/01/17 11:42, Andrew Cooper wrote: >> On 04/01/17 11:38, Jan Beulich wrote: >> On 04.01.17 at 11:56, wrote: On 04/01/17 10:22, Jan Beulich wrote: > While this may appear to introduce a truncation issue, the high 32 bits > get zapped a

Re: [Xen-devel] [PATCH v2 1/2] x86emul: make _PRE_EFLAGS() tolerate first argument being 32-bit

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 12:51, wrote: > On 04/01/17 11:46, Andrew Cooper wrote: >> On 04/01/17 11:42, Andrew Cooper wrote: >>> On 04/01/17 11:38, Jan Beulich wrote: >>> On 04.01.17 at 11:56, wrote: > On 04/01/17 10:22, Jan Beulich wrote: >> As this adds an instruction, the question is whet

Re: [Xen-devel] Possible improvement to Xen Security Response Process

2017-01-04 Thread James Bulpin
On Tue, 2016-12-13 at 08:42, Jan Beulich wrote: On 12.12.16 at 18:11, wrote: >> I'll join in the bunfight with a stronger proposal (noting in passing >> that according to https://xenbits.xen.org/xsa/ we are now expecting 5 >> consecutive weeks of XSA announcements): >> 1) Where practical, X

[Xen-devel] [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue

2017-01-04 Thread Xuquan (Quan Xu)
>From 9c23e1ff3eb75d71d691778a2e83421f645902fb Mon Sep 17 00:00:00 2001 From: Quan Xu Date: Wed, 4 Jan 2017 20:03:31 +0800 Subject: [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue When Xen apicv is enabled, wall clock time is faster on Windows7-32 guest with high payload (with 2vCPU,

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

2017-01-04 Thread osstest service owner
flight 104022 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/104022/ Failures :-/ but no regressions. Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail REGR. vs. 104015 test-armhf-armhf-libvirt-xs

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

2017-01-04 Thread osstest service owner
flight 104028 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/104028/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 7cb63c870bac7a986936aeb6e70b22ebf80d4ba9 baseline version: ovmf 61e947457e42320bd15e2

[Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

2017-01-04 Thread George Dunlap
The Xen Security Team has dealt with a number of issues recently where it wasn't exactly clear whether we should issue an advisory or not: the Xen Security Response Process only mentiones "'vulnerabilities", without specifying what constitutes a vulnerability. Issuing advisories has a cost: It cos

[Xen-devel] [PATCH 03/27] x86/cpuid: Introduce struct cpuid_policy

2017-01-04 Thread Andrew Cooper
struct cpuid_policy will eventually be a complete replacement for the cpuids[] array, with a fixed layout and named fields to allow O(1) access to specific information. For now, the CPUID content is capped at the 0xd and 0x801c leaves, which matches the maximum policy that the toolstack will g

[Xen-devel] [PATCH 02/27] x86/cpuid: Introduce guest_cpuid() and struct cpuid_leaf

2017-01-04 Thread Andrew Cooper
Longterm, pv_cpuid() and hvm_cpuid() will be merged into a single guest_cpuid(), which is also capable of working outside of current context. To aid this transtion, introduce guest_cpuid() with the intended API, which simply defers back to pv_cpuid() or hvm_cpuid() as appropriate. Introduce struc

[Xen-devel] [PATCH 09/27] x86/cpuid: Dispatch cpuid_hypervisor_leaves() from guest_cpuid()

2017-01-04 Thread Andrew Cooper
... rather than from the legacy path. Update the API to match guest_cpuid(), and remove its dependence on current. Make use of guest_cpuid() unconditionally zeroing res to avoid repeated re-zeroing. To use a const struct domain, domain_cpuid() needs to be const-corrected. Signed-off-by: Andrew

[Xen-devel] [PATCH 05/27] x86/cpuid: Allocate a CPUID policy for every domain

2017-01-04 Thread Andrew Cooper
Introduce init_domain_cpuid_policy() to allocate an appropriate cpuid policy for the domain (currently the domains maximum applicable policy), and call it during domain construction. init_guest_cpuid() now needs calling before dom0 is constructed. Signed-off-by: Andrew Cooper --- CC: Jan Beulich

[Xen-devel] [PATCH 04/27] x86/cpuid: Move featuresets into struct cpuid_policy

2017-01-04 Thread Andrew Cooper
Featuresets will eventually live only once in a struct cpuid_policy, but lots of code currently uses the global featuresets as a linear bitmap. Remove the existing global *_featureset bitmaps, replacing them with *_policy objects containing named featureset words and a fs[] linear bitmap. Two new

[Xen-devel] [PATCH 01/27] x86/cpuid: Untangle the include hierachy

2017-01-04 Thread Andrew Cooper
The use of X86_FEATURES_ONLY was shortlived in Linux for the same problem encountered here. The following series needs to add extra includes to asm/cpuid.h, which breaks the build elsewhere given the current hierachy. Move the feature definitions into a separate header file, which also matches th

[Xen-devel] [PATCH 08/27] x86/hvm: Dispatch cpuid_viridian_leaves() from guest_cpuid()

2017-01-04 Thread Andrew Cooper
... rather than from the legacy path. Update the API to match guest_cpuid(), and remove its dependence on current. One check against EFER_SVME is replaced with the more appropriate cpu_has_svm, when determining whether MSR bitmaps are available. Make use of guest_cpuid() unconditionally zeroing

[Xen-devel] [PATCH 00/27] xen/x86: Per-domain CPUID policies

2017-01-04 Thread Andrew Cooper
Hello, Presented herewith is the first part of improvement work to support full per-domain CPUID policies. More work is pending on top of this series. This series is available in git form from: http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=shortlog;h=refs/heads/xen-cpuid-v1 T

[Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

2017-01-04 Thread Andrew Cooper
Introduce recalculate_cpuid_policy() which clamps a CPUID policy based on the domains current restrictions. Recalculate on domain creation immediately after copying the appropriate policy, when switching a PV guest to being compat, and when the toolstack sets CPUID policy data. This needs sanitis

[Xen-devel] [PATCH 06/27] x86/domctl: Make XEN_DOMCTL_set_address_size singleshot

2017-01-04 Thread Andrew Cooper
Toolstacks (including some out-of-tree ones) use XEN_DOMCTL_set_address_size at most once per domain, and it ends up having a destructive effect on the available CPUID policy for a domain. To avoid ordering issues between altering the policy via domctl, and the constructive effects which would hav

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

2017-01-04 Thread George Dunlap
On Wed, Jan 4, 2017 at 12:36 PM, George Dunlap wrote: > 4. The security team will only issue an advisory if there is a known > combination of software in which the vulnerability can be exploited. > > In most cases, the software which contains the bug is also the target > of the attack: that is, a

[Xen-devel] [PATCH 14/27] x86/pv: Improve pv_cpuid() using named features

2017-01-04 Thread Andrew Cooper
This avoids refering back to domain_cpuid() or native CPUID to obtain information which is directly available. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/traps.c | 22 +- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git a/xen/arch/x86/traps

[Xen-devel] [PATCH 21/27] x86/cpuid: Calculate appropriate max_leaf values for the global policies

2017-01-04 Thread Andrew Cooper
Derive host_policy from raw_policy, and {pv,hvm}_max_policy from host_policy. Clamp the raw values to the maximum we will offer to guests. This simplifies the PV and HVM policy calculations, removing the need for an intermediate linear host_featureset bitmap. Signed-off-by: Andrew Cooper --- CC:

[Xen-devel] [PATCH 11/27] x86/hvm: Improve hvm_efer_valid() using named features

2017-01-04 Thread Andrew Cooper
Pick the appropriate cpuid_policy object rather than using hvm_cpuid() or boot_cpu_data. This breaks the dependency on current. As data is read straight out of cpuid_policy, there is no need to work around the fact that X86_FEATURE_SYSCALL might be clear because of the dynamic adjustment in hvm_c

[Xen-devel] [PATCH 16/27] x86/svm: Improvements using named features

2017-01-04 Thread Andrew Cooper
This avoids calling into hvm_cpuid() to obtain information which is directly available. In particular, this avoids the need to overload flag_dr_dirty because of hvm_cpuid() being unavailable svm_save_dr() Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Boris Ostrovsky CC: Suravee Suthikul

[Xen-devel] [PATCH 15/27] x86/hvm: Improve CPUID and MSR handling using named features

2017-01-04 Thread Andrew Cooper
This avoids hvm_cpuid() recursing into itself, and the MSR paths using hvm_cpuid() to obtain information which is directly available. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 95 +++--- 1 file changed, 29 insertion

[Xen-devel] [PATCH 18/27] x86/pv: Use per-domain policy information in pv_cpuid()

2017-01-04 Thread Andrew Cooper
... rather than performing runtime adjustments. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/traps.c | 44 1 file changed, 12 insertions(+), 32 deletions(-) diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c index f19e015.

[Xen-devel] [PATCH 20/27] x86/cpuid: Drop the temporary linear feature bitmap from struct cpuid_policy

2017-01-04 Thread Andrew Cooper
With most uses of the *_featureset API removed, the remaining uses are only during XEN_SYSCTL_get_cpu_featureset, init_guest_cpuid(), and recalculate_cpuid_policy(), none of which are hot paths. Drop the temporary infrastructure, and have the current users recreate the linear bitmap using cpuid_po

[Xen-devel] [PATCH 24/27] x86/hvm: Use guest_cpuid() rather than hvm_cpuid()

2017-01-04 Thread Andrew Cooper
More work is required before maxphysaddr can be read straight out of the cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so update the code to use the newer interface. Use the behaviour of max_leaf handling (returning all zeros) to avoid a double call into guest_cpuid(). Si

[Xen-devel] [PATCH 10/27] x86/cpuid: Introduce named feature bitmaps

2017-01-04 Thread Andrew Cooper
Use anonymous unions to access the feature leaves as complete words, and by named individual feature. A feature name is introduced for every architectural X86_FEATURE_*, other than the dynamically calculated values such as APIC, OSXSAVE and OSPKE. No functional change. Signed-off-by: Andrew Coop

[Xen-devel] [PATCH 27/27] x86/cpuid: Alter the legacy-path prototypes to match guest_cpuid()

2017-01-04 Thread Andrew Cooper
This allows the compiler to have a far easier time inlining the legacy paths into guest_cpuid(), and avoids the need to have a full struct cpu_user_regs in the guest_cpuid() stack frame. Signed-off-by: Andrew Cooper --- CC: Jan Beulich Here and elsewhere, it is becomes very obvious that the PVH

[Xen-devel] [PATCH 12/27] x86/hvm: Improve CR4 verification using named features

2017-01-04 Thread Andrew Cooper
Alter the function to return the valid CR4 bits, rather than the invalid CR4 bits. This will allow reuse in other areas of code. Pick the appropriate cpuid_policy object rather than using hvm_cpuid() or boot_cpu_data. This breaks the dependency on current. Signed-off-by: Andrew Cooper --- CC:

[Xen-devel] [PATCH 17/27] x86/pv: Use per-domain policy information when calculating the cpumasks

2017-01-04 Thread Andrew Cooper
... rather than dynamically claming against the PV maximum policy. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/domctl.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c index c7e74dd..c1a4d00 100

[Xen-devel] [PATCH 25/27] x86/svm: Use guest_cpuid() rather than hvm_cpuid()

2017-01-04 Thread Andrew Cooper
More work is required before LWP details can be read straight out of the cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so update the code to use the newer interface. Signed-off-by: Andrew Cooper --- CC: Jan Beulich CC: Boris Ostrovsky CC: Suravee Suthikulpanit --- xen

[Xen-devel] [PATCH 22/27] x86/cpuid: Perform max_leaf calculations in guest_cpuid()

2017-01-04 Thread Andrew Cooper
Clamp the toolstack-providied max_leaf values in recalculate_cpuid_policy(), causing the per-domain policy to have guest-accurate data. Have guest_cpuid() exit early if a requested leaf is out of range, rather than falling into the legacy path. Signed-off-by: Andrew Cooper --- CC: Jan Beulich -

[Xen-devel] [PATCH 23/27] x86/cpuid: Move all leaf 7 handling into guest_cpuid()

2017-01-04 Thread Andrew Cooper
All per-domain policy data concerning leaf 7 is accurate. Handle it all in guest_cpuid() by reading out of the raw array block, and introduing a dynamic adjustment for OSPKE. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c| 41 +

[Xen-devel] [PATCH 26/27] x86/cpuid: Effectively remove pv_cpuid() and hvm_cpuid()

2017-01-04 Thread Andrew Cooper
All callers of pv_cpuid() and hvm_cpuid() (other than guest_cpuid() legacy path) have been removed from the codebase. Move them into cpuid.c to avoid any further use, leaving guest_cpuid() as the sole API to use. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/cpuid.c

[Xen-devel] [PATCH 13/27] x86/vvmx: Use hvm_cr4_guest_valid_bits() to calculate MSR_IA32_VMX_CR4_FIXED1

2017-01-04 Thread Andrew Cooper
Reuse the logic in hvm_cr4_guest_valid_bits() instead of duplicating it. This fixes a bug to do with the handling of X86_CR4_PCE. The RDPMC instruction predate the architectural performance feature, and has been around since the P6. X86_CR4_PCE is like X86_CR4_TSD and only controls whether RDPMC

[Xen-devel] [PATCH 19/27] x86/hvm: Use per-domain policy information in hvm_cpuid()

2017-01-04 Thread Andrew Cooper
... rather than performing runtime adjustments. Signed-off-by: Andrew Cooper --- CC: Jan Beulich --- xen/arch/x86/hvm/hvm.c | 113 +++-- 1 file changed, 44 insertions(+), 69 deletions(-) diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c in

Re: [Xen-devel] [PATCH v5] x86/apicv: fix RTC periodic timer and apicv issue

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:21, wrote: > --- a/xen/arch/x86/hvm/vmx/intr.c > +++ b/xen/arch/x86/hvm/vmx/intr.c > @@ -312,13 +312,14 @@ void vmx_intr_assist(void) > unsigned int i, n; > > /* > -* Set eoi_exit_bitmap for periodic timer interrup to cause > EOI-induced VM > -

Re: [Xen-devel] Possible improvement to Xen Security Response Process

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 12:58, wrote: > On Tue, 2016-12-13 at 08:42, Jan Beulich wrote: > On 12.12.16 at 18:11, wrote: >>> I'll join in the bunfight with a stronger proposal (noting in passing >>> that according to https://xenbits.xen.org/xsa/ we are now expecting 5 >>> consecutive weeks of XSA

Re: [Xen-devel] Possible improvement to Xen Security Response Process

2017-01-04 Thread James Bulpin
On Wed, 2017-01-04 at 13:02, Jan Beulich wrote: On 04.01.17 at 12:58, wrote: >> On Tue, 2016-12-13 at 08:42, Jan Beulich wrote: >> On 12.12.16 at 18:11, wrote: I'll join in the bunfight with a stronger proposal (noting in passing that according to https://xenbits.xen.org/xsa/

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:36, wrote: > 4. The security team will only issue an advisory if there is a known > combination of software in which the vulnerability can be exploited. > > In most cases, the software which contains the bug is also the target > of the attack: that is, a bug in Xen allows an

Re: [Xen-devel] [PATCH 2/2] x86/cpu: Improvements to get_cpu_vendor()

2017-01-04 Thread Jan Beulich
>>> On 03.01.17 at 13:06, wrote: > --- a/xen/arch/x86/cpu/cpu.h > +++ b/xen/arch/x86/cpu/cpu.h > @@ -1,9 +1,13 @@ > /* attempt to consolidate cpu attributes */ > struct cpu_dev { > - char* c_vendor; > + charc_vendor[8]; > > - /* some have two possibilities for cpuid string

Re: [Xen-devel] [PATCH 01/27] x86/cpuid: Untangle the include hierachy

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > The use of X86_FEATURES_ONLY was shortlived in Linux for the same problem > encountered here. The following series needs to add extra includes to > asm/cpuid.h, which breaks the build elsewhere given the current hierachy. > > Move the feature definitions into a

Re: [Xen-devel] [PATCH v5 09/13] libxl: Update xenstore on VCPU hotplug for all guest types

2017-01-04 Thread Boris Ostrovsky
On 01/04/2017 05:34 AM, Wei Liu wrote: > On Fri, Dec 16, 2016 at 06:18:35PM -0500, Boris Ostrovsky wrote: >> Currently HVM guests that use upstream qemu do not update xenstore's >> availability entry for VCPUs. While it is not strictly necessary for >> hotplug to work, xenstore end up reflecting ac

Re: [Xen-devel] [RFC] netif: staging grants for requests

2017-01-04 Thread Wei Liu
Hey! Thanks for writing this detailed document! On Wed, Dec 14, 2016 at 06:11:12PM +, Joao Martins wrote: > Hey, > > Back in the Xen hackaton '16 networking session there were a couple of ideas > brought up. One of them was about exploring permanently mapped grants between > xen-netback/xen-

Re: [Xen-devel] [PATCH 02/27] x86/cpuid: Introduce guest_cpuid() and struct cpuid_leaf

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > Jan: I note that this patch texturally conflicts with your register renaming > series. And, not just texturally, the SSE/AVX moves series still awaiting your review. > @@ -17,6 +18,8 @@ uint32_t __read_mostly raw_featureset[FSCAPINTS]; > uint32_t __read_mostly

Re: [Xen-devel] [PATCH 03/27] x86/cpuid: Introduce struct cpuid_policy

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > struct cpuid_policy will eventually be a complete replacement for the cpuids[] > array, with a fixed layout and named fields to allow O(1) access to specific > information. > > For now, the CPUID content is capped at the 0xd and 0x801c leaves, which > matche

Re: [Xen-devel] [PATCH 04/27] x86/cpuid: Move featuresets into struct cpuid_policy

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > +static void __init calculate_host_policy(void) > { > -unsigned int max, tmp; > - > -max = cpuid_eax(0); > - > -if ( max >= 1 ) > -cpuid(0x1, &tmp, &tmp, > - &raw_featureset[FEATURESET_1c], > - &raw_featureset[FEATUR

Re: [Xen-devel] [PATCH 05/27] x86/cpuid: Allocate a CPUID policy for every domain

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > --- a/xen/include/asm-x86/domain.h > +++ b/xen/include/asm-x86/domain.h > @@ -340,6 +340,9 @@ struct arch_domain > /* Is PHYSDEVOP_eoi to automatically unmask the event channel? */ > bool_t auto_unmask; > > +/* CPUID Policy. */ > +struct cpuid

Re: [Xen-devel] [PATCH 06/27] x86/domctl: Make XEN_DOMCTL_set_address_size singleshot

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > Toolstacks (including some out-of-tree ones) use XEN_DOMCTL_set_address_size > at most once per domain, and it ends up having a destructive effect on the > available CPUID policy for a domain. > > To avoid ordering issues between altering the policy via domctl,

Re: [Xen-devel] [PATCH 02/27] x86/cpuid: Introduce guest_cpuid() and struct cpuid_leaf

2017-01-04 Thread Andrew Cooper
On 04/01/17 14:01, Jan Beulich wrote: > >> @@ -17,6 +18,8 @@ uint32_t __read_mostly raw_featureset[FSCAPINTS]; >> uint32_t __read_mostly pv_featureset[FSCAPINTS]; >> uint32_t __read_mostly hvm_featureset[FSCAPINTS]; >> >> +#define EMPTY_LEAF (struct cpuid_leaf){} > Perhaps another pair of paren

Re: [Xen-devel] RFC: Adding a section to the Xen security policy about what constitutes a vulnerability

2017-01-04 Thread George Dunlap
On Wed, Jan 4, 2017 at 1:16 PM, Jan Beulich wrote: On 04.01.17 at 13:36, wrote: >> 4. The security team will only issue an advisory if there is a known >> combination of software in which the vulnerability can be exploited. >> >> In most cases, the software which contains the bug is also the

Re: [Xen-devel] [PATCH 16/27] x86/svm: Improvements using named features

2017-01-04 Thread Boris Ostrovsky
On 01/04/2017 07:39 AM, Andrew Cooper wrote: > This avoids calling into hvm_cpuid() to obtain information which is directly > available. In particular, this avoids the need to overload flag_dr_dirty > because of hvm_cpuid() being unavailable svm_save_dr() "unavailabe in" (or from) > > Signed-off

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

2017-01-04 Thread Wei Liu
On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote: > Hi, > > today the XS_RESTRICT wire command of Xenstore is supported by > oxenstored only to drop the privilege of a connection to that of the > domid given as a parameter to the command. > > Using this mechanism with Xenstore runnin

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

2017-01-04 Thread Juergen Gross
On 04/01/17 15:59, Wei Liu wrote: > On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote: >> Hi, >> >> today the XS_RESTRICT wire command of Xenstore is supported by >> oxenstored only to drop the privilege of a connection to that of the >> domid given as a parameter to the command. >> >>

Re: [Xen-devel] [PATCH 03/27] x86/cpuid: Introduce struct cpuid_policy

2017-01-04 Thread Andrew Cooper
On 04/01/17 14:22, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> struct cpuid_policy will eventually be a complete replacement for the >> cpuids[] >> array, with a fixed layout and named fields to allow O(1) access to specific >> information. >> >> For now, the CPUID content is capped a

Re: [Xen-devel] [PATCH 00/11] Convert a few docs/misc pages into man pages

2017-01-04 Thread Wei Liu
On Fri, Dec 09, 2016 at 05:17:03PM +0100, Cédric Bosdonnat wrote: > As pointed out in Ian and Andrew's emails on my recent docs improvement > attempt, getting the documents from docs/misc referenced in man pages > as man pages would would make these pages more visible for users. This > would also n

Re: [Xen-devel] [PATCH 04/27] x86/cpuid: Move featuresets into struct cpuid_policy

2017-01-04 Thread Andrew Cooper
On 04/01/17 14:35, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> +static void __init calculate_host_policy(void) >> { >> -unsigned int max, tmp; >> - >> -max = cpuid_eax(0); >> - >> -if ( max >= 1 ) >> -cpuid(0x1, &tmp, &tmp, >> - &raw_featureset[FEATURE

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > +void recalculate_cpuid_policy(struct domain *d) > +{ > +struct cpuid_policy *p = d->arch.cpuid; > +const struct cpuid_policy *max = > +is_pv_domain(d) ? &pv_max_policy : &hvm_max_policy; > +uint32_t fs[FSCAPINTS], max_fs[FSCAPINTS]; > +un

Re: [Xen-devel] Xenstore domains and XS_RESTRICT

2017-01-04 Thread Wei Liu
On Wed, Jan 04, 2017 at 04:05:03PM +0100, Juergen Gross wrote: > On 04/01/17 15:59, Wei Liu wrote: > > On Wed, Dec 07, 2016 at 08:44:31AM +0100, Juergen Gross wrote: > >> Hi, > >> > >> today the XS_RESTRICT wire command of Xenstore is supported by > >> oxenstored only to drop the privilege of a con

Re: [Xen-devel] [PATCH 08/27] x86/hvm: Dispatch cpuid_viridian_leaves() from guest_cpuid()

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > One check against EFER_SVME is replaced with the more appropriate cpu_has_svm, > when determining whether MSR bitmaps are available. I don't think this is correct - start_svm() may fail, in which case the CPUID flag doesn't get cleared, yet EFER.SVME also doesn'

Re: [Xen-devel] [PATCH 25/27] x86/svm: Use guest_cpuid() rather than hvm_cpuid()

2017-01-04 Thread Boris Ostrovsky
On 01/04/2017 07:39 AM, Andrew Cooper wrote: > More work is required before LWP details can be read straight out of the > cpuid_policy block, but in the meantime hvm_cpuid() wants to disappear so > update the code to use the newer interface. > > Signed-off-by: Andrew Cooper Reviewed-by: Boris Ost

Re: [Xen-devel] [PATCH 09/27] x86/cpuid: Dispatch cpuid_hypervisor_leaves() from guest_cpuid()

2017-01-04 Thread Jan Beulich
>>> On 04.01.17 at 13:39, wrote: > --- a/xen/arch/x86/cpuid.c > +++ b/xen/arch/x86/cpuid.c > @@ -332,6 +332,9 @@ void guest_cpuid(const struct vcpu *v, unsigned int leaf, > case 0x4000 ... 0x40ff: > if ( is_viridian_domain(d) ) > return cpuid_viridian_leaves(v, l

Re: [Xen-devel] [PATCH 07/27] x86/cpuid: Recalculate a domains CPUID policy when appropriate

2017-01-04 Thread Andrew Cooper
On 04/01/17 15:01, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> +void recalculate_cpuid_policy(struct domain *d) >> +{ >> +struct cpuid_policy *p = d->arch.cpuid; >> +const struct cpuid_policy *max = >> +is_pv_domain(d) ? &pv_max_policy : &hvm_max_policy; >> +uint32_

Re: [Xen-devel] [PATCH 08/27] x86/hvm: Dispatch cpuid_viridian_leaves() from guest_cpuid()

2017-01-04 Thread Andrew Cooper
On 04/01/17 15:24, Jan Beulich wrote: On 04.01.17 at 13:39, wrote: >> One check against EFER_SVME is replaced with the more appropriate >> cpu_has_svm, >> when determining whether MSR bitmaps are available. > I don't think this is correct - start_svm() may fail, in which case > the CPUID fla

  1   2   >