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
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
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
>>> 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
_
>>> 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
>>> 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
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
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
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
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
>
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
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
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
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).
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
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
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
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 @
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
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
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
>>
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
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
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
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
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
+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
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
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
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
> >
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
>>> 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
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
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é
> >
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
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
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
>>> 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
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
>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,
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
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
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
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
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
... 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
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
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
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
... 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
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
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
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
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
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
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:
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
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
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
... 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.
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
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
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
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
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:
... 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
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
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
-
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 +
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
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
... 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
>>> 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
> -
>>> 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
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/
>>> 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
>>> 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
>>> 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
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
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-
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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,
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
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
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
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
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.
>>
>>
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
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
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
>>> 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
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
>>> 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'
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
>>> 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
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_
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 - 100 of 180 matches
Mail list logo
