flight 168136 xen-4.16-testing real [real]
flight 168147 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168136/
http://logs.test-lab.xenproject.org/osstest/logs/168147/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
flight 168130 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168130/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168112
test-amd64-i386-xl-qemut-win7-amd64 19
On 14/02/2022 13:56, Jan Beulich wrote:
> On 14.02.2022 14:50, Andrew Cooper wrote:
>> On 14/02/2022 13:33, Jan Beulich wrote:
>>> On 14.02.2022 13:50, Andrew Cooper wrote:
From: Juergen Gross
When running as pv-shim the hypercall is modified today in order to
replace the funct
On 14/02/2022 14:38, Jan Beulich wrote:
> On 14.02.2022 15:15, Andrew Cooper wrote:
>> On 14/02/2022 13:43, Jan Beulich wrote:
>>> On 14.02.2022 14:10, Andrew Cooper wrote:
On 14/02/2022 12:50, Andrew Cooper wrote:
> CET Indirect Branch Tracking is a hardware feature designed to protect
>
On Wed, 16 Feb 2022, Luca Fancellu wrote:
> > On 16 Feb 2022, at 02:45, Stefano Stabellini wrote:
> >
> > On Tue, 15 Feb 2022, Luca Fancellu wrote:
> >> Introduce an architecture specific way to create different cpupools
> >> at boot time, this is particularly useful on ARM big.LITTLE system
> >>
On 15/02/2022 14:01, Jan Beulich wrote:
> On 14.02.2022 13:50, Andrew Cooper wrote:
>> --- a/xen/arch/x86/Kconfig
>> +++ b/xen/arch/x86/Kconfig
>> @@ -39,6 +39,11 @@ config HAS_AS_CET_SS
>> # binutils >= 2.29 or LLVM >= 6
>> def_bool $(as-instr,wrssq %rax$(comma)0;setssbsy)
>>
>> +confi
On Tue, 15 Feb 2022, Vincent Guittot wrote:
> On Tue, 8 Feb 2022 at 01:16, Stefano Stabellini
> wrote:
> >
> > On Mon, 7 Feb 2022, Alex Bennée wrote:
> > > Hi Stefano,
> > >
> > > Vincent gave an update on his virtio-scmi work at the last Stratos sync
> > > call and the discussion moved onto next
On 15/02/2022 14:13, Jan Beulich wrote:
> On 15.02.2022 14:43, Andrew Cooper wrote:
>> On 14/02/2022 13:38, Jan Beulich wrote:
>>> On 14.02.2022 13:50, Andrew Cooper wrote:
Control Flow Integrity schemes use toolchain and optionally hardware
support
to help protect against call/jump
On 2/16/22 13:25, Rafael J. Wysocki wrote:
> On Tue, Feb 15, 2022 at 11:00 PM Dmitry Osipenko wrote:
>>
>> 31.01.2022 02:36, Dmitry Osipenko пишет:
>>> Problem
>>> ---
>>>
>>> SoC devices require power-off call chaining functionality from kernel.
>>> We have a widely used restart chaining prov
flight 168129 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168129/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds18 guest-start/debian.repeat fail REGR. vs. 168124
Tests which did not succeed
flight 168131 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168131/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8a576733162bb72afb4d1eb3012b0aef8d265018
baseline version:
ovmf c28e376edc46e6db6e4a5
Hi Jan,
> On 16 Feb 2022, at 14:43, Jan Beulich wrote:
>
> On 16.02.2022 15:35, Bertrand Marquis wrote:
>> Hi Jan,
>>
>>> On 16 Feb 2022, at 14:03, Jan Beulich wrote:
>>>
>>> On 16.02.2022 14:57, Bertrand Marquis wrote:
> On 16 Feb 2022, at 12:23, George Dunlap wrote:
>> On Feb 16, 2
On 16/02/2022 11:32, Roger Pau Monné wrote:
On Wed, Feb 16, 2022 at 10:53:58AM +, Durrant, Paul wrote:
On 16/02/2022 10:30, Roger Pau Monne wrote:
Introduce a new arch specific field to report whether an emulator
supports the Extended Destination ID field, so that the hypervisor can
refrain
Hi Stefano,
On Mon, Feb 14, 2022 at 02:05:18PM -0800, Stefano Stabellini wrote:
> On Mon, 14 Feb 2022, Oleksii Moisieiev wrote:
> > Hi Bertrand,
> >
> > On Mon, Feb 14, 2022 at 11:27:21AM +, Bertrand Marquis wrote:
> > > Hi Oleksii,
> > >
> > > > On 14 Feb 2022, at 11:13, Oleksii Moisieiev
> On 16 Feb 2022, at 16:32, Dario Faggioli wrote:
>
> On Wed, 2022-02-16 at 12:37 +, Luca Fancellu wrote:
>>> On 16 Feb 2022, at 06:18, Juergen Gross wrote:
>>> On 15.02.22 18:56, Luca Fancellu wrote:
>
Yes, however I think the parser to handle everything by command
line wo
On Wed, 2022-02-16 at 12:37 +, Luca Fancellu wrote:
> > On 16 Feb 2022, at 06:18, Juergen Gross wrote:
> > On 15.02.22 18:56, Luca Fancellu wrote:
> > > >
> > > Yes, however I think the parser to handle everything by command
> > > line would
> > > be huge due to input sanitisation and not eas
Hello,
The following series adds retpoline support for clang builds, and also
allows the user to select whether to enable retpoline support at build
time via a new Kconfig option.
I've tried adding a suitable description to the Kconfig option, but I'm
sure there's room for improvement.
Thanks, R
Add a new Kconfig option under the "Speculative hardening" section
that allows selecting whether to enable retpoline. This depends on the
underlying compiler having retpoline support.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Fix description of option to
Current retpoline checks apply to GCC only, so make it obvious by
prefixing the Kconfig option with GCC. Keep the previous option as a
way to signal generic retpoline support regardless of the underlying
compiler.
No functional change intended.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beu
Detect whether the compiler supports clang retpoline option and enable
by default if available, just like it's done for gcc.
Note clang already disables jump tables when retpoline is enabled, so
there's no need to also pass the fno-jump-tables parameter. Also clang
already passes the return addres
On Wed, 2022-02-16 at 16:43 +0100, Jan Beulich wrote:
> On 16.02.2022 11:30, Roger Pau Monne wrote:
> > --- a/xen/include/public/arch-x86/cpuid.h
> > +++ b/xen/include/public/arch-x86/cpuid.h
> > @@ -102,6 +102,12 @@
> > #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2)
> > #define XEN_HVM_CPUID_V
On 16.02.2022 11:30, Roger Pau Monne wrote:
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -588,6 +588,7 @@ struct xen_domctl_bind_pt_irq {
> #define XEN_DOMCTL_VMSI_X86_DELIV_MASK 0x007000
> #define XEN_DOMCTL_VMSI_X86_TRIG_MASK0x008000
> #define XEN_DOMCTL_V
On 16.02.2022 11:30, Roger Pau Monne wrote:
> Such field uses bits 55:48, but for the purposes the register will be
> used use bits 55:49 instead. Bit 48 is used to signal an RTE entry is
> in remappable format which is not supported by the vIO-APIC.
Nit: The first sentence looks to have some stra
On 16.02.2022 11:30, Roger Pau Monne wrote:
> --- a/xen/include/public/arch-x86/cpuid.h
> +++ b/xen/include/public/arch-x86/cpuid.h
> @@ -102,6 +102,12 @@
> #define XEN_HVM_CPUID_IOMMU_MAPPINGS (1u << 2)
> #define XEN_HVM_CPUID_VCPU_ID_PRESENT (1u << 3) /* vcpu id is present in
> EBX */
> #d
From: Oleksandr Andrushchenko
vPCI MMIO handlers are accessing pdevs without protecting this access
with pcidevs_{lock|unlock}. This is not a problem as of now as these
are only used by Dom0. But, towards vPCI is used also for guests, we need
to properly protect pdev and pdev->vpci from being rem
From: Oleksandr Andrushchenko
Currently pcidevs lock is a global recursive spinlock which is fine for
the existing use cases. It is used to both protect pdev instances
themselves from being removed while in use and to make sure the update
of the relevant pdev properties is synchronized.
Moving t
From: Oleksandr Andrushchenko
modify_bars checks if the mapping of the BAR memory has already been
done when mapping other device's BARs or, while unmapping, are still
in use by other devices.
With the existing locking scheme it is possible that there are other
devices trying to do the same in p
From: Oleksandr Andrushchenko
A guest would be able to read and write those registers which are not
emulated and have no respective vPCI handlers, so it will be possible
for it to access the hardware directly.
In order to prevent a guest from reads and writes from/to the unhandled
registers make
From: Oleksandr Andrushchenko
Hello, all!
This is a yet another attempt to re-work the existing pci/vpci locking
scheme towards vPCI is going to be used for guests.
For more details on the previous attempts and their flaws please see [1], [2].
This work is based on the idea that it is possible
flight 168126 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168126/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail like 168121
test-amd64-amd64-xl-qemut-win7-amd64
On 16.02.2022 15:35, Bertrand Marquis wrote:
> Hi Jan,
>
>> On 16 Feb 2022, at 14:03, Jan Beulich wrote:
>>
>> On 16.02.2022 14:57, Bertrand Marquis wrote:
On 16 Feb 2022, at 12:23, George Dunlap wrote:
> On Feb 16, 2022, at 11:42 AM, Jan Beulich wrote:
> On 16.02.2022 12:34, Georg
Hi Jan,
> On 16 Feb 2022, at 14:03, Jan Beulich wrote:
>
> On 16.02.2022 14:57, Bertrand Marquis wrote:
>>> On 16 Feb 2022, at 12:23, George Dunlap wrote:
On Feb 16, 2022, at 11:42 AM, Jan Beulich wrote:
On 16.02.2022 12:34, George Dunlap wrote:
> I am opposed to overloading “ASS
On Wed, Feb 16, 2022 at 1:33 AM Oleksandr Andrushchenko
wrote:
>
> From: Oleksandr Andrushchenko
>
> vchan server creates XenStore entries to advertise its event channel and
> ring, but those are not removed after the server quits.
> Add additional cleanup step, so those are removed, so clients d
On 16.02.2022 12:26, Roger Pau Monné wrote:
> On Wed, Feb 16, 2022 at 10:47:52AM +0100, Jan Beulich wrote:
>> On 16.02.2022 10:02, Roger Pau Monne wrote:
>>> Detect whether the compiler supports clang retpoline option and enable
>>> by default if available, just like it's done for gcc.
>>>
>>> Note
On 16.02.2022 14:57, Bertrand Marquis wrote:
>> On 16 Feb 2022, at 12:23, George Dunlap wrote:
>>> On Feb 16, 2022, at 11:42 AM, Jan Beulich wrote:
>>> On 16.02.2022 12:34, George Dunlap wrote:
I am opposed to overloading “ASSERT” for this new kind of macro; I think
it would not only b
Hi,
> On 16 Feb 2022, at 12:23, George Dunlap wrote:
>
>
>
>> On Feb 16, 2022, at 11:42 AM, Jan Beulich wrote:
>>
>> On 16.02.2022 12:34, George Dunlap wrote:
>>
>>> I am opposed to overloading “ASSERT” for this new kind of macro; I think it
>>> would not only be unnecessarily confusing to
On 16.02.22 14:01, Luca Fancellu wrote:
On 16 Feb 2022, at 12:55, Juergen Gross wrote:
On 16.02.22 13:10, Luca Fancellu wrote:
On 16 Feb 2022, at 02:45, Stefano Stabellini wrote:
On Tue, 15 Feb 2022, Luca Fancellu wrote:
Introduce an architecture specific way to create different cpupools
> On 16 Feb 2022, at 12:55, Juergen Gross wrote:
>
> On 16.02.22 13:10, Luca Fancellu wrote:
>>> On 16 Feb 2022, at 02:45, Stefano Stabellini wrote:
>>>
>>> On Tue, 15 Feb 2022, Luca Fancellu wrote:
Introduce an architecture specific way to create different cpupools
at boot time, t
On 16.02.22 13:10, Luca Fancellu wrote:
On 16 Feb 2022, at 02:45, Stefano Stabellini wrote:
On Tue, 15 Feb 2022, Luca Fancellu wrote:
Introduce an architecture specific way to create different cpupools
at boot time, this is particularly useful on ARM big.LITTLE system
where there might be t
> On 16 Feb 2022, at 06:18, Juergen Gross wrote:
>
> On 15.02.22 18:56, Luca Fancellu wrote:
>>> On 15 Feb 2022, at 10:48, Juergen Gross wrote:
>>>
>>> On 15.02.22 11:15, Luca Fancellu wrote:
Introduce an architecture specific way to create different cpupools
at boot time, this is
On Tue, Feb 15, 2022 at 11:00 PM Dmitry Osipenko wrote:
>
> 31.01.2022 02:36, Dmitry Osipenko пишет:
> > Problem
> > ---
> >
> > SoC devices require power-off call chaining functionality from kernel.
> > We have a widely used restart chaining provided by restart notifier API,
> > but nothing f
> On Feb 16, 2022, at 11:42 AM, Jan Beulich wrote:
>
> On 16.02.2022 12:34, George Dunlap wrote:
>
>> I am opposed to overloading “ASSERT” for this new kind of macro; I think it
>> would not only be unnecessarily confusing to people not familiar with our
>> codebase, but it would be too easy
> On 16 Feb 2022, at 02:45, Stefano Stabellini wrote:
>
> On Tue, 15 Feb 2022, Luca Fancellu wrote:
>> Introduce an architecture specific way to create different cpupools
>> at boot time, this is particularly useful on ARM big.LITTLE system
>> where there might be the need to have different cp
Hi,
> On 16 Feb 2022, at 11:46, Julien Grall wrote:
>
> Hi,
>
> On 16/02/2022 10:44, Andrew Cooper wrote:
>> On 16/02/2022 03:46, Stefano Stabellini wrote:
>>> On Mon, 14 Feb 2022, Julien Grall wrote:
On 14/02/2022 12:50, Andrew Cooper wrote:
> There are exactly 3 callers of sort() in
On 16/02/2022 08:41, Jan Beulich wrote:
>>> Any zero-padding inserted anywhere by the linker can
>>> result in an immediately following ENDBR to be missed (because
>>> sequences of zeros resemble 2-byte insns).
>> I'm not sure this is a problem. This pass is looking for everything
>> that objdump
flight 168127 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168127/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c28e376edc46e6db6e4a551c94b6ac90df0d8d6e
baseline version:
ovmf 85589ddbf6f8c6dc75f73
Hi,
On 16/02/2022 10:44, Andrew Cooper wrote:
On 16/02/2022 03:46, Stefano Stabellini wrote:
On Mon, 14 Feb 2022, Julien Grall wrote:
On 14/02/2022 12:50, Andrew Cooper wrote:
There are exactly 3 callers of sort() in the hypervisor. Callbacks in a
tight
loop like this are problematic for per
On 16.02.2022 12:34, George Dunlap wrote:
>> On Feb 16, 2022, at 9:31 AM, Jan Beulich wrote:
>> On 16.02.2022 10:25, Bertrand Marquis wrote:
On 15 Feb 2022, at 21:00, Julien Grall wrote:
On 27/01/2022 14:34, Jan Beulich wrote:
> The increasing amount of constructs along the lines of
> On Feb 16, 2022, at 9:31 AM, Jan Beulich wrote:
>
> On 16.02.2022 10:25, Bertrand Marquis wrote:
>> Hi Jan, Julien,
>>
>>> On 15 Feb 2022, at 21:00, Julien Grall wrote:
>>>
>>> (+ Bertrand)
>>>
>>> Hi Jan,
>>>
>>> On 27/01/2022 14:34, Jan Beulich wrote:
The increasing amount of cons
On Wed, Feb 16, 2022 at 10:53:58AM +, Durrant, Paul wrote:
> On 16/02/2022 10:30, Roger Pau Monne wrote:
> > Introduce a new arch specific field to report whether an emulator
> > supports the Extended Destination ID field, so that the hypervisor can
> > refrain from exposing the feature if one
On Wed, Feb 16, 2022 at 10:47:52AM +0100, Jan Beulich wrote:
> On 16.02.2022 10:02, Roger Pau Monne wrote:
> > Detect whether the compiler supports clang retpoline option and enable
> > by default if available, just like it's done for gcc.
> >
> > Note clang already disables jump tables when retpo
flight 168124 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168124/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-thunderx 8 xen-boot fail in 168118 pass in 168124
test-amd64-i386-qemuu-rhel6hvm-a
On 16/02/2022 10:30, Roger Pau Monne wrote:
Introduce a new arch specific field to report whether an emulator
supports the Extended Destination ID field, so that the hypervisor can
refrain from exposing the feature if one of the emulators doesn't
support it.
Signed-off-by: Roger Pau Monné
---
C
On 16/02/2022 03:46, Stefano Stabellini wrote:
> On Mon, 14 Feb 2022, Julien Grall wrote:
>> On 14/02/2022 12:50, Andrew Cooper wrote:
>>> There are exactly 3 callers of sort() in the hypervisor. Callbacks in a
>>> tight
>>> loop like this are problematic for performance, especially with Spectre v
Introduce the CPUID flag to be used in order to signal the support for
using an extended destination ID in IO-APIC RTEs and MSI address
fields. Such format expands the maximum target APIC ID from 255 to
32768 without requiring the usage of interrupt remapping.
The design document describing the fe
Introduce a new arch specific field to report whether an emulator
supports the Extended Destination ID field, so that the hypervisor can
refrain from exposing the feature if one of the emulators doesn't
support it.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
R
Expose the feature if available for the domain.
Signed-off-by: Roger Pau Monné
---
Note: con not be committed ahead of the rest of the series.
---
Changes since v1:
- New in this version (split from previous patch).
---
xen/arch/x86/traps.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a
Both QEMU/KVM and HyperV support using bits 11:5 from the MSI address
field in order to store the high part of the target APIC ID. This
allows expanding the maximum APIC ID usable without interrupt
remapping support from 255 to 32768.
Note the interface used by QEMU for emulated devices (via the
X
Such field uses bits 55:48, but for the purposes the register will be
used use bits 55:49 instead. Bit 48 is used to signal an RTE entry is
in remappable format which is not supported by the vIO-APIC.
Use the extended destination ID to store the high bits from the
destination ID, thus expanding th
Hello,
The following series provide a tentative implementation of extended
destination ID support for HVM/PVH guests. A specification for the
feature can be found at:
http://david.woodhou.se/15-bit-msi.pdf
Patch 4 is the one I'm having more doubts about: it's the best thing I
could come up in or
flight 168128 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168128/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen e7c2017cf4a91ab6a0fea6adca2d9dd2ab1603b0
baseline version:
xen 8731
On 16.02.2022 10:02, Roger Pau Monne wrote:
> Detect whether the compiler supports clang retpoline option and enable
> by default if available, just like it's done for gcc.
>
> Note clang already disables jump tables when retpoline is enabled, so
> there's no need to also pass the fno-jump-tables
Hi Jan,
> On 16 Feb 2022, at 09:31, Jan Beulich wrote:
>
> On 16.02.2022 10:25, Bertrand Marquis wrote:
>> Hi Jan, Julien,
>>
>>> On 15 Feb 2022, at 21:00, Julien Grall wrote:
>>>
>>> (+ Bertrand)
>>>
>>> Hi Jan,
>>>
>>> On 27/01/2022 14:34, Jan Beulich wrote:
The increasing amount of
On 16.02.2022 10:02, Roger Pau Monne wrote:
> Current retpoline checks apply to GCC only, so make it obvious by
> prefixing the Kconfig option with GCC. Keep the previous option as a
> way to signal generic retpoline support regardless of the underlying
> compiler.
>
> No functional change intende
flight 168125 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168125/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 15.02.2022 21:26, Julien Grall wrote:
> (+ Jan)
>
> Hi Penny,
>
> I am CCing Jan to give him a chance to...
Thanks, but ...
> On 14/02/2022 03:19, Penny Zheng wrote:
>> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
>> index cfb0b47f13..24eb4cc7d3 100644
>> --- a/xen/includ
On 16.02.2022 10:25, Bertrand Marquis wrote:
> Hi Jan, Julien,
>
>> On 15 Feb 2022, at 21:00, Julien Grall wrote:
>>
>> (+ Bertrand)
>>
>> Hi Jan,
>>
>> On 27/01/2022 14:34, Jan Beulich wrote:
>>> The increasing amount of constructs along the lines of
>>> if ( !condition )
>>> {
>>>
On 16.02.2022 08:20, Juergen Gross wrote:
> On 15.02.22 22:13, Julien Grall wrote:
>> As a side note, should we also update SUPPORT.md?
>
> Good question.
I'm not sure here either - talking about individual hypercall sub-ops
seems overly small granularity to me for this kind of doc. Plus I
don't
Hi Stefano,
> On 16 Feb 2022, at 03:46, Stefano Stabellini wrote:
>
> On Mon, 14 Feb 2022, Julien Grall wrote:
>> On 14/02/2022 12:50, Andrew Cooper wrote:
>>> There are exactly 3 callers of sort() in the hypervisor. Callbacks in a
>>> tight
>>> loop like this are problematic for performance, e
Hi Jan, Julien,
> On 15 Feb 2022, at 21:00, Julien Grall wrote:
>
> (+ Bertrand)
>
> Hi Jan,
>
> On 27/01/2022 14:34, Jan Beulich wrote:
>> The increasing amount of constructs along the lines of
>> if ( !condition )
>> {
>> ASSERT_UNREACHABLE();
>> return;
>> }
>> i
On 16.02.2022 00:00, Andrew Cooper wrote:
> On 15/02/2022 16:53, Jan Beulich wrote:
>> On 14.02.2022 13:51, Andrew Cooper wrote:
>>> --- a/xen/common/efi/runtime.c
>>> +++ b/xen/common/efi/runtime.c
>>> @@ -21,6 +21,7 @@ struct efi_rs_state {
>>>* don't strictly need that.
>>>*/
>>> unsig
On Tue, Feb 15, 2022 at 03:08:21PM +, Anthony PERARD wrote:
> On Thu, Feb 03, 2022 at 03:32:11PM +0100, Roger Pau Monne wrote:
> > if (d_config->c_info.type != LIBXL_DOMAIN_TYPE_PV &&
> > -d_config->num_pcidevs && pod_enabled) {
> > +d_config->c_info.passthrough != LIBXL_PA
Hello,
The following series adds retpoline support for clang builds, and also
allows the user to select whether to enable retpoline support at build
time via a new Kconfig option.
I've tried adding a suitable description to the Kconfig option, but I'm
sure there's room for improvement.
Thanks, R
Add a new Kconfig option under the "Speculative hardening" section
that allows selecting whether to enable retpoline. This depends on the
underlying compiler having retpoline support.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/Kconfig | 4
xen/arch/x86/arc
Detect whether the compiler supports clang retpoline option and enable
by default if available, just like it's done for gcc.
Note clang already disables jump tables when retpoline is enabled, so
there's no need to also pass the fno-jump-tables parameter.
Reported-by: Jan Beulich
Signed-off-by: R
Current retpoline checks apply to GCC only, so make it obvious by
prefixing the Kconfig option with GCC. Keep the previous option as a
way to signal generic retpoline support regardless of the underlying
compiler.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/Kc
On 15.02.2022 21:58, Andrew Cooper wrote:
> On 15/02/2022 16:46, Jan Beulich wrote:
>> On 14.02.2022 13:51, Andrew Cooper wrote:
>>> CET-SS and CET-IBT can be independently controlled, so the configuration of
>>> MSR_S_CET can't be constant any more.
>>>
>>> Introduce xen_msr_s_cet_value(), mostly
On 15.02.2022 18:52, Andrew Cooper wrote:
> On 15/02/2022 15:12, Jan Beulich wrote:
>> On 14.02.2022 13:50, Andrew Cooper wrote:
>>> --- /dev/null
>>> +++ b/xen/tools/check-endbr.sh
>>> @@ -0,0 +1,76 @@
>>> +#!/bin/sh
>>> +
>>> +#
>>> +# Usage ./$0 xen-syms
>>> +#
>>> +
>>> +set -e
>>> +
>>> +OBJCO
> On 16 Feb 2022, at 06:13, Juergen Gross wrote:
>
> On 15.02.22 18:48, Luca Fancellu wrote:
>>> On 15 Feb 2022, at 10:33, Juergen Gross wrote:
>>>
>>> On 15.02.22 11:15, Luca Fancellu wrote:
With the introduction of boot time cpupools, Xen can create many
different cpupools at boo
79 matches
Mail list logo
