Signed-off-by: Yang Zhong
---
xen/arch/x86/x86_emulate/x86_emulate.c | 21 +
xen/include/asm-x86/cpufeature.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c
b/xen/arch/x86/x86_emulate/x86_emulate.c
index 54a2756..2d331ea
The previous vpclmulqdq only support AVX128.
Icelake added AVX256 support.
Signed-off-by: Yang Zhong
---
xen/arch/x86/x86_emulate/x86_emulate.c | 10 --
xen/include/asm-x86/cpufeature.h | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/x86_emulate/
Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
need expose to guest.
The bit definition:
CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
CPUID.(EAX=7,ECX=0):ECX[bit 09] VAES
CPUID.(EAX
The new cpu features in intel icelake: AVX512VBMI2/GFNI/VAES/
AVX512VNNI/AVX512BITALG/VPCLMULQDQ.
v4: changes from Jan's comments in v3
patch 1:
simd_size set issue.
remove else.
add vex.w exception check.
gfni insns comments issue.
double blank lines issue.
The previous aes insns only support legacy and AVX128.
Icelake added AVX256 support.
Signed-off-by: Yang Zhong
---
xen/arch/x86/x86_emulate/x86_emulate.c | 17 -
xen/include/asm-x86/cpufeature.h | 1 +
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/xen/arc
flight 117560 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117560/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 6 kernel-build fail REGR. vs. 117255
build-i386-pvops
>>> On 03.01.18 at 09:26, wrote:
> Intel IceLake cpu has added new cpu features: AVX512VBMI2/GFNI/
> VAES/AVX512VNNI/AVX512BITALG/VPCLMULQDQ. Those new cpu features
> need expose to guest.
>
> The bit definition:
> CPUID.(EAX=7,ECX=0):ECX[bit 06] AVX512VBMI2
> CPUID.(EAX=7,ECX=0):ECX[bit 08] GFNI
>>> On 22.12.17 at 10:09, wrote:
> On 12/05/2017 11:07 AM, Jan Beulich wrote:
> On 04.12.17 at 16:45, wrote:
On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote:
> This patch adds the old value param and the onchangeonly option
> to the VM_EVENT_REASON_MOV_TO_MSR ev
On 01/03/2018 12:00 PM, Jan Beulich wrote:
On 22.12.17 at 10:09, wrote:
>> On 12/05/2017 11:07 AM, Jan Beulich wrote:
>> On 04.12.17 at 16:45, wrote:
> On Fri, Oct 13, 2017 at 03:50:57PM +0300, Alexandru Isaila wrote:
>> This patch adds the old value param and the onchangeonly o
flight 117598 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117598/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 971d299c04df379734d10c44d637433e9e564f36
baseline version:
xen 1b33
flight 117541 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117541/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win10-i386 broken
test-amd64-i386-xl-qemut-ws16-
>>> On 02.01.18 at 16:56, wrote:
> When booting Xen via UEFI the Xen config file can contain multiple sections
> each describing different boot options. It is currently only possible to
> choose
> which section to boot with if Xen is started through an EFI Shell.
Is this true? I thought that EFI
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> Set comment and indentation style to be consistent with linux coding style
> and the rest of the file, as suggested by Peter Zijlstra
>
> Signed-off-by: Michel Lespinasse
> Cc: Andrea Arcangeli
> Acked-by: David Woodhouse
> Cc: R
flight 117575 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117575/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf bade68b7087acd6b5ca6310a7460faeea48e4b1c
baseline version:
xtf 167052779c0546e99aadd2
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> When looking to fetch a node's sibling, we went through a sequence of:
> - check if node is the parent's left child
> - if it is, then fetch the parent's right child
>
> This can be replaced with:
> - fetch the parent's right child
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> Add __rb_change_child() as an inline helper function to replace code that
> would otherwise be duplicated 4 times in the source.
>
> No changes to binary size or speed.
>
> Signed-off-by: Michel Lespinasse
> Reviewed-by: Rik van R
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> In rb_erase, move the easy case (node to erase has no more than
> 1 child) first. I feel the code reads easier that way.
>
> Signed-off-by: Michel Lespinasse
> Reviewed-by: Rik van Riel
> Cc: Peter Zijlstra
> Cc: Andrea Arcangeli
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> An interesting observation for rb_erase() is that when a node has
> exactly one child, the node must be black and the child must be red.
> An interesting consequence is that removing such a node can be done by
> simply replacing it w
>>> On 21.11.17 at 16:20, wrote:
> From: Michel Lespinasse
>
> Various minor optimizations in rb_erase():
> - Avoid multiple loading of node->__rb_parent_color when computing parent
> and color information (possibly not in close sequence, as there might
> be further branches in the algorithm
>>> On 21.11.17 at 16:20, wrote:
> From: Wei Yang
>
> In case 1, it passes down the BLACK color from G to p and u, and maintains
> the color of n. By doing so, it maintains the black height of the sub-tree.
>
> While in the comment, it marks the color of n to BLACK. This is a typo
> and not c
flight 73828 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/73828/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i3
By using a static inline stub in private.h for OS where this functionality
is not implemented, the various duplicate stubs in the OS-specific source
modules can be avoided.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Acked-by: Wei Liu
---
Cc: Ian Jackson
v4:
- Removed extraneous
...to allow the calling domain to prevent translation of specified l1e
value.
Despite what the comment in public/xen.h might imply, specifying a
command value of MMU_NORMAL_PT_UPDATE will not simply update an l1e with
the specified value. Instead, mod_l1_entry() tests whether foreign_dom
has PG_tr
This patch re-works much of the ioreq server initialization and teardown
code:
- The hvm_map/unmap_ioreq_gfn() functions are expanded to call through
to hvm_alloc/free_ioreq_gfn() rather than expecting them to be called
separately by outer functions.
- Several functions now test the validity o
A subsequent patch will introduce a new scheme to allow an emulator to
map ioreq server pages directly from Xen rather than the guest P2M.
This patch lays the groundwork for that change by deferring mapping of
gfns until their values are requested by an emulator. To that end, the
pad field of the
This patch adjusts the ioreq server code to use type-safe gfn_t values
where possible. No functional change.
Signed-off-by: Paul Durrant
Reviewed-by: Roger Pau Monné
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
---
xen/arch/x86/hvm/ioreq.c | 44 +++
... XENMEM_resource_ioreq_server
This patch adds support for a new resource type that can be mapped using
the XENMEM_acquire_resource memory op.
If an emulator makes use of this resource type then, instead of mapping
gfns, the IOREQ server will allocate pages from the heap. These pages
will never
This series introduces support for direct mapping of guest resources.
The resources are:
- IOREQ server pages
- Grant tables
v17:
- Make sure ioreq page free-ing is done at domain destruction
v16:
- Fix default ioreq server code and verified with qemu trad
v15:
- Correct page ownership of i
Certain memory resources associated with a guest are not necessarily
present in the guest P2M.
This patch adds the boilerplate for new memory op to allow such a resource
to be priv-mapped directly, by either a PV or HVM tools domain.
NOTE: Whilst the new op is not intrinsicly specific to the x86
A previous patch introduced a new HYPERVISOR_memory_op to acquire guest
resources for direct priv-mapping.
This patch adds new functionality into libxenforeignmemory to make use
of a new privcmd ioctl [1] that uses the new memory op to make such
resources available via mmap(2).
[1]
http://xenbit
A subsequent patch will remove the current implicit limitation on creation
of ioreq servers which is due to the allocation of gfns for the ioreq
structures and buffered ioreq ring.
It will therefore be necessary to introduce an explicit limit and, since
this limit should be small, it simplifies th
This patch allows grant table frames to be mapped using the
XENMEM_acquire_resource memory op.
NOTE: This patch expands the on-stack mfn_list array in acquire_resource()
but it is still small enough to remain on-stack.
Signed-off-by: Paul Durrant
Reviewed-by: Jan Beulich
---
Cc: Andrew Co
A previous patch added support for priv-mapping guest resources directly
(rather than having to foreign-map, which requires P2M modification for
HVM guests).
This patch makes use of the new API to seed the guest grant table unless
the underlying infrastructure (i.e. privcmd) doesn't support it, in
flight 117600 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117600/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
> -Original Message-
> From: Alex Braunegg [mailto:alex.braun...@gmail.com]
> Sent: 28 December 2017 19:32
> To: 'Michael Collins' ; 'Juergen Gross'
> ; xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Wei Liu
> Subject: RE: [Xen-devel] [BUG] kernel bug encountered at drivers/net/xen-
>
This patch adds the old value param and the onchangeonly option
to the VM_EVENT_REASON_MOV_TO_MSR event.
The param was added to the vm_event_mov_to_msr struct and to the
hvm_monitor_msr function. Finally I've changed the bool_t param
to a bool for the hvm_msr_write_intercept function.
Signed-off-
flight 117604 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117604/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 03.01.18 at 13:19, wrote:
> +static void hvm_free_ioreq_mfn(struct hvm_ioreq_server *s, bool buf)
> +{
> +struct domain *d = s->domain;
> +struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> +
> +if ( !iorp->page )
> +return;
> +
> +page_list_add_tail(ior
On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich wrote:
On 02.01.18 at 16:56, wrote:
>> When booting Xen via UEFI the Xen config file can contain multiple sections
>> each describing different boot options. It is currently only possible to
>> choose
>> which section to boot with if Xen is starte
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 January 2018 15:48
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel@lists.xenproject.org;
> Konrad Rzeszutek Wilk ; Tim (Xen.org
flight 117535 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu broken
test-amd64-i386-xl-qemut-ws16-amd64
>>> On 03.01.18 at 17:04, wrote:
> On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich wrote:
> On 02.01.18 at 16:56, wrote:
>>> +if ( elo->Attributes & LOAD_OPTION_ACTIVE )
>>
>> Without any other (earlier) check, how can you reliably tell this
>> being a pointer to EFI_LOAD_OPTION from it
>>> On 03.01.18 at 17:06, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 03 January 2018 15:48
>> To: Paul Durrant
>> Cc: JulienGrall ; Andrew Cooper
>> ; Wei Liu ; George
>> Dunlap ; Ian Jackson ;
>> Stefano Stabellini ; xen-devel@lists.xenproject.
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 03 January 2018 16:41
> To: Paul Durrant
> Cc: StefanoStabellini ; Wei Liu
> ; Andrew Cooper ; Tim
> (Xen.org) ; George Dunlap ;
> JulienGrall ; xen-devel@lists.xenproj
On Wed, Jan 3, 2018 at 9:36 AM, Jan Beulich wrote:
On 03.01.18 at 17:04, wrote:
>> On Wed, Jan 3, 2018 at 4:20 AM, Jan Beulich wrote:
>> On 02.01.18 at 16:56, wrote:
+if ( elo->Attributes & LOAD_OPTION_ACTIVE )
>>>
>>> Without any other (earlier) check, how can you reliabl
>>> On 03.01.18 at 09:26, wrote:
> @@ -7741,6 +7752,16 @@ x86_emulate(
> op_bytes = 16;
> goto simd_0f3a_common;
>
> +case X86EMUL_OPC_66(0x0f3a, 0xce): /* gf2p8affineqb
> $imm8,xmm/m128,xmm,xmm */
> +case X86EMUL_OPC_VEX_66(0x0f3a, 0xce): /* vgf2p8affineqb
> $imm
>>> On 03.01.18 at 17:48, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> >>> On 03.01.18 at 17:06, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: 03 January 2018 15:48
>> >> >>> On 03.0
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 03 January 2018 17:05
> To: Paul Durrant
> Cc: JulienGrall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Wei Liu
> ; StefanoStabellini ; xen-
> de...@lists.xenproject.org; Tim (Xen.org)
> Subject: RE: [Xen-d
flight 117606 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117606/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 117581 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117581/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64 broken
test-amd64-
On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
> Hi,
>
> I've been working on transitioning a number of Windows guests under HVM
> from using QEMU traditional to QEMU upstream as is recommended in the
> documentation. When I move these guests, the PCI subtree for Xen
> devices chan
> How easy is it to trigger this? I'm assuming, from the original description,
> that I can probably trigger it by forcibly terminating a running domain and
> then trying to restart it.
For me the trigger was just having 2 VM's running and then within 24 hr's one
would crash with the debug data
flight 117584 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117584/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not suc
flight 117549 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117549/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xtf broken
build-amd64-pvop
## Paul Durrant (paul.durr...@citrix.com):
> How easy is it to trigger this? I'm assuming, from the original
> description, that I can probably trigger it by forcibly terminating
> a running domain and then trying to restart it.
As Alex said: in the "common cases" (like his and mine) it seems to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-254
Information leak via side effects of speculative execution
ISSUE DESCRIPTION
=
Processors give the illusion of a sequence of instructions executed
one-by-one. However, in o
On 01/03/2018 11:57 AM, Anthony PERARD wrote:
> On Wed, Dec 20, 2017 at 11:40:03AM -0600, Kevin Stange wrote:
>> Hi,
>>
>> I've been working on transitioning a number of Windows guests under HVM
>> from using QEMU traditional to QEMU upstream as is recommended in the
>> documentation. When I move
flight 117557 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117557/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit2 broken
test-amd64-i386-qemu
Due to the foreshortening of the embargo, I've posted what is currently
available. I have yet to complete all the feedback from v6 review, but what
is here should be functionally correct, if a little rough around the edges.
*Important:*
In addition to this software series, you will need the foll
No practical change at the moment, but future changes will need to react
irrespective of guest type.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
xen/arch/x86/domain.c| 12
xen/arch/x86/domctl.c| 4 ++--
xen/arch/x86/hvm/hvm.c
It will shortly be used for more than just changing the vendor.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
---
v3:
* Drop forward declaration of vmx_update_guest_vendor()
---
xen/arch/x86/domctl.c | 17 ++---
xen/arch/x86/hvm/hvm.c|
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Acked-by: Jan Beulich
---
xen/include/asm-x86/alternative-asm.h | 31 +++
xen/include/asm-x86/alternative.h | 13 +++--
2 files changed, 34 insertions(+), 10 deletions(-)
create mode 100644 xen/include/as
To help creating alternative frames in assembly.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v3:
* Drop the now-unused ALTERNATIVE_2
* Use .L\@ rather than opencoded numbers
v4:
* Extra @progbits
* Reinstate ALTERNATIVE_2
---
xen/include/asm-x86/alternative-asm.h | 46
Use -mindirect-branch=thunk-extern/-mindirect-branch-register when available.
To begin with, use the retpoline thunk. Later work will add alternative
thunks which can be selected at boot time.
Signed-off-by: Andrew Cooper
---
v4:
* New
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/Rul
This reduces the number of code gadgets which can be attacked with arbitrary
guest-controlled GPR values.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
xen/include/asm-x86/asm_defns.h | 16
1 file changed, 16 insertions(+)
diff --git a/xen/inc
Results in a more predictable (i.e. linear) memory access pattern.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
xen/include/asm-x86/asm_defns.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --gi
Save all GPRs on entry to Xen.
The entry_int82() path is via a DPL1 gate, only usable by 32bit PV guests, so
can get away with only saving the 32bit registers. All other entrypoints can
be reached from 32 or 64bit contexts.
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
---
tools/tests/x86
No practical change.
One side effect in debug builds is that %rbp is inverted in the manner
expected by the stack unwinder to indicate a interrupt frame.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Wei Liu
---
xen/arch/x86/hvm/svm/entry.S | 22 --
xe
Instead of gaining yet another top level boolean, introduce a more generic
cpuid= option. Also introduce a helper function to parse a generic boolean
value.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
v3:
* New
v4:
* Rename "xen-cpuid" to "cpuid"
* Adjust comment in parse_boolean()
---
This logic is not as clear as it could be. Add some comments to help.
Rearrange the asm block in __prepare_to_wait() to separate the GPR
saving/restoring from the internal logic.
While tweaking, add an unreachable() following the jmp in
check_wakeup_from_wait().
No functional change.
Signed-of
This property is required for the AMD's recommended mitigation for Branch
Target Injection, but Xen needs to cope with being unable to detect or modify
the MSR.
Signed-off-by: Andrew Cooper
---
v4:
* New
v5:
* Use mnemonics.
---
xen/arch/x86/cpu/amd.c| 35 ++
Signed-off-by: Andrew Cooper
---
v4:
* New
v5:
* Whitespace fixes
---
docs/misc/xen-command-line.markdown | 6 ++-
xen/arch/x86/spec_ctrl.c| 103 ++--
2 files changed, 104 insertions(+), 5 deletions(-)
diff --git a/docs/misc/xen-command-line.markdo
ret instructions are unconditionally speculated based on values in the RSB.
If any path in Xen executes more ret than call instructions, speculation can
start following a guest controlled RSB entry.
There is at least one path (wake from waitqueue) which can end up executing
more ret than call inst
Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Reviewed-by: Jan Beulich
---
xen/arch/x86/domctl.c | 2 ++
xen/arch/x86/hvm/hvm.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index 5973d9f..72b4489 100644
--- a/xen/arch/x86/domctl.c
+++
For performance reasons, HVM guests should have direct access to these MSRs
when possible.
Signed-off-by: Andrew Cooper
---
v4:
* Redo almost from scratch to support AMD
v6:
* Allow direct access to PRED_CMD for IBPB
---
xen/arch/x86/domctl.c | 19 +++
xen/arch/x86/hvm/svm
Introduce CALL_THUNK and JMP_THUNK which either degrade to a normal indirect
branch, or dispatch to the __x86.indirect_thunk.* symbols.
Update all the manual indirect branches in to use the new thunks. The
indirect branches in the early boot and kexec path are left intact as we can't
use the comp
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v4:
* Adjust for AMD changes
---
docs/misc/xen-command-line.markdown | 5 -
xen/arch/x86/domain.c | 3 +++
xen/arch/x86/spec_ctrl.c| 13 ++---
xen/include/asm-x86/cpufeature.h| 1 +
4 files ch
Depending on hardware and microcode availability, we will want to replace
IND_THUNK_REPOLINE with other implementations.
For AMD hardware, choose IND_THUNK_LFENCE in preference to retpoline if lfence
is known to be (or was successfully made) dispatch serialising.
Signed-off-by: Andrew Cooper
---
Nothing very interesting at the moment, but the logic will grow as new
mitigations are added.
Signed-off-by: Andrew Cooper
---
v3:
* New
v4:
* Drop the else-clause printk
* Rebase over AMD additions
---
xen/arch/x86/Makefile | 1 +
xen/arch/x86/setup.c| 3 ++
xen/arch/
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
v3:
* Brackets around && (.. & ..) operation
* Extend host to uint32_t for the benefit of the asm code.
v4:
* Extend MSR_PRED_CMD availability logic for AMD.
---
xen/arch/x86/msr.c| 35 +++
xen/i
On contemporary hardware, setting IBRS/STIBP has a performance impact on
adjacent hyperthreads. It is therefore recommended to clear the setting
before becoming idle, to avoid an idle core preventing adjacent userspace
execution from running at full performance.
Care must be taken to ensure there
Signed-off-by: Andrew Cooper
---
v3:
* Spelling corrections
v4:
* Rebase over AMD changes
v6:
* Fix cpuid_policy_updated() to not corrupt vp->spec_ctrl.host on migrate, or
on older versions of Xen where feature flags start as 0 rather than the
domain maximum.
---
xen/arch/x86/domain.c
With all infrastructure in place, it is now safe to let guests see and use
these features. Allow AMD's IBPB to be set even on Intel hardware, so the
toolstack can express "IBPB only" to guests.
This also requires updating the libxc logic to understand the e8b feature
leaf, which has the side effe
Set or clear IBRS in Xen context, and appropriate guest values in guest
context. See the documentation in asm-x86/spec_ctrl_asm.h for details.
Two semi-unrelated bugfixes are that various asm_defn.h macros have a hidden
dependency on PAGE_SIZE, which results in an assembler error if used in a
.ma
Contemporary processors are gaining Indirect Branch Controls via microcode
updates. Intel are introducing one bit to indicate IBRS and IBPB support, and
a second bit for STIBP. AMD are introducing IPBP only, so enumerate it with a
separate bit.
Furthermore, depending on compiler and microcode av
On 1/3/18 6:15 PM, Andrew Cooper wrote:
> Contemporary processors are gaining Indirect Branch Controls via microcode
> updates. Intel are introducing one bit to indicate IBRS and IBPB support, and
> a second bit for STIBP. AMD are introducing IPBP only, so enumerate it with a
> separate bit.
s/I
On 04/01/2018 01:14, Doug Goldstein wrote:
> On 1/3/18 6:15 PM, Andrew Cooper wrote:
>> Contemporary processors are gaining Indirect Branch Controls via microcode
>> updates. Intel are introducing one bit to indicate IBRS and IBPB support,
>> and
>> a second bit for STIBP. AMD are introducing IP
On Wed, Jan 3, 2018 at 5:14 PM, Doug Goldstein wrote:
> On 1/3/18 6:15 PM, Andrew Cooper wrote:
>> Contemporary processors are gaining Indirect Branch Controls via microcode
>> updates. Intel are introducing one bit to indicate IBRS and IBPB support,
>> and
>> a second bit for STIBP. AMD are in
flight 117585 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117585/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel broken
test-amd64-amd64-libvirt
On Wed, Jan 03, 2018 at 01:46:09AM -0700, Jan Beulich wrote:
> > --- a/xen/include/public/arch-x86/cpufeatureset.h
> > +++ b/xen/include/public/arch-x86/cpufeatureset.h
> > @@ -228,6 +228,12 @@ XEN_CPUFEATURE(AVX512VBMI,6*32+ 1) /*A AVX-512
> > Vector Byte Manipulation Ins
> > XEN_CPUFEATUR
On Wed, Jan 03, 2018 at 01:38:13AM -0700, Jan Beulich wrote:
> >>> On 03.01.18 at 09:26, wrote:
> > The new cpu features in intel icelake: AVX512VBMI2/GFNI/VAES/
> > AVX512VNNI/AVX512BITALG/VPCLMULQDQ.
>
> Could you please play by patch submission rules: They are to be
> sent _to_ the list, with
On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> The current check refuses the hot-plugged memory that falls in one
> unused PDX group, which should be allowed.
>
Reviewed-by: Chao Peng
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> ---
> xen/arch/x86
On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> cleanup_frame_table() initializes the entire newly added frame table
> to all -1's. If it's called after extend_frame_table() failed to map
> the entire frame table, the initialization will hit a page fault.
>
> Move the cleanup of partial
On Thu, 2017-12-07 at 18:09 +0800, Haozhong Zhang wrote:
> ... to make its behavior the same as C standard (e.g., C99 and C11).
>
> Signed-off-by: Haozhong Zhang
> ---
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Ian Jackson
> Cc: Wei Liu
> ---
> tools/firmware/hvmloader/util.c | 7 +++
>
flight 117586 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/117586/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm broken
test-amd64-amd64-livepatch
95 matches
Mail list logo
