Hi Henry,
On Thu, Apr 13, 2023 at 1:49 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 16/22] xen/arm: ffa: add ABI structs for sharing
> > memory
> >
> > Adds the ABI structs used by function FFA_MEM_SHARE and friends for
> > sharing memory.
> >
> >
Hi Henry,
On Thu, Apr 13, 2023 at 1:53 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 03/22] tools: add Arm FF-A mediator
> >
> > Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
> > guest is trusted to use FF-A.
> >
> > Signed-o
Hi,
On Thu, Apr 13, 2023 at 3:24 PM Julien Grall wrote:
>
> Hi,
>
> On 13/04/2023 08:14, Jens Wiklander wrote:
> > +static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
> > + uint8_t msg)
> > +{
> > +uint32_t exp_resp = FFA_MSG_FLAG_FRAMEW
Hi Jens,
> On 14 Apr 2023, at 10:19, Jens Wiklander wrote:
>
> Hi,
>
> On Thu, Apr 13, 2023 at 3:24 PM Julien Grall wrote:
>>
>> Hi,
>>
>> On 13/04/2023 08:14, Jens Wiklander wrote:
>>> +static int32_t ffa_direct_req_send_vm(uint16_t sp_id, uint16_t vm_id,
>>> +
Hi Luca,
> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>
> SVE has a new exception class with code 0x19, introduce the new code
> and handle the exception.
>
> Signed-off-by: Luca Fancellu
With the comments from Julien handled you can add my:
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
flight 180251 qemu-mainline real [real]
flight 180257 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180251/
http://logs.test-lab.xenproject.org/osstest/logs/180257/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Luca,
> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>
> Currently x86 defines a Xen command line argument dom0= where
> there can be specified dom0 controlling sub-options, to use it also
> on Arm, move the code that loops through the list of arguments from
> x86 to the common code and fro
Hi,
On Thu, Apr 13, 2023 at 3:27 PM Andrew Cooper wrote:
>
> On 13/04/2023 1:26 pm, Julien Grall wrote:
> >> +static int ffa_domain_init(struct domain *d)
> >> +{
> >> +struct ffa_ctx *ctx;
> >> +
> >> +if ( !ffa_version )
> >> +return -ENODEV;
> >> +
> >> +ctx = xzalloc(struc
Hi Henry,
On Thu, Apr 13, 2023 at 1:16 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > Subject: [XEN PATCH v8 09/22] xen/arm: ffa: add direct request support
> >
> > Adds support for sending a FF-A direct request. Checks that the SP also
> > supports handling a 32-bit direc
On Thu, Apr 13, 2023 at 3:44 PM Bertrand Marquis
wrote:
>
> Hi,
>
> > On 13 Apr 2023, at 15:27, Julien Grall wrote:
> >
> >
> >
> > On 13/04/2023 14:20, Bertrand Marquis wrote:
> >> Hi Julien,
> >>> On 13 Apr 2023, at 15:15, Julien Grall wrote:
> >>>
> >>> Hi,
> >>>
> >>> On 13/04/2023 08:14, Je
Hi Henry,
On Thu, Apr 13, 2023 at 3:53 PM Henry Wang wrote:
>
> Hi Jens,
>
> > -Original Message-
> > From: Jens Wiklander
> > Subject: Re: [XEN PATCH v8 05/22] xen/arm: ffa: add flags for
> > FFA_PARTITION_INFO_GET
> > > > +#define FFA_PART_PROP_DIRECT_REQ_RECV BIT(0, U)
> > > > +#def
Hello,
We finally had the broken PDU replaced in the osstest colo, and the
armhf boxes are operational again (those are the arndales and the
cubietrucks).
I've run some ad-hoc tests on them and they look fine. I plan to bless
them before the end of the day.
As usual, keep and eye on any failures
On Thu, Apr 13, 2023 at 04:00:09PM +0100, Andrew Cooper wrote:
> The Long Mode consistency checks exist to "ensure that the processor does not
> enter an undefined mode or state that results in unpredictable behavior". APM
> Vol2 Table 14-5 "Long-Mode Consistency Checks" lists them, but there is n
On 14/04/2023 11:31 am, Roger Pau Monné wrote:
> On Thu, Apr 13, 2023 at 04:00:09PM +0100, Andrew Cooper wrote:
>> The Long Mode consistency checks exist to "ensure that the processor does not
>> enter an undefined mode or state that results in unpredictable behavior".
>> APM
>> Vol2 Table 14-5 "
> On 13 Apr 2023, at 20:52, Julien Grall wrote:
>
> Hi Luca,
>
> On 13/04/2023 15:05, Luca Fancellu wrote:
>>> On 13 Apr 2023, at 14:30, Julien Grall wrote:
>>>
>>>
>>>
>>> On 13/04/2023 14:24, Luca Fancellu wrote:
Hi Julien,
>>>
>>> Hi Luca,
>>>
>> @@ -594,6 +597,7 @@ int arch
flight 180253 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180253/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180230
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Bertrand,
On Fri, Apr 14, 2023 at 10:29 AM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> > On 14 Apr 2023, at 10:19, Jens Wiklander wrote:
> >
> > Hi,
> >
> > On Thu, Apr 13, 2023 at 3:24 PM Julien Grall wrote:
> >>
> >> Hi,
> >>
> >> On 13/04/2023 08:14, Jens Wiklander wrote:
> >>> +static int32
Hi Julien,
On Thu, Apr 13, 2023 at 11:00 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 13/04/2023 08:14, Jens Wiklander wrote:
> > Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
> > Partition in secure world.
> >
> > [1] https://developer.arm.com/documentation/den0077/latest
Hi Julien,
On Thu, Apr 13, 2023 at 10:57 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 13/04/2023 08:14, Jens Wiklander wrote:
> > Adds a comments with a list of unsupported FF-A interfaces and
> > limitations in the implemented FF-A interfaces.
> >
> > Signed-off-by: Jens Wiklander
> > ---
> > x
> On 13 Apr 2023, at 13:47, Bertrand Marquis wrote:
>
> Hi Luca,
>
>> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>>
>> Enable Xen to handle the SVE extension, add code in cpufeature module
>> to handle ZCR SVE register, disable trapping SVE feature on system
>> boot only when SVE resour
Hi Luca,
> On 14 Apr 2023, at 15:28, Luca Fancellu wrote:
>
>
>
>> On 13 Apr 2023, at 13:47, Bertrand Marquis wrote:
>>
>> Hi Luca,
>>
>>> On 12 Apr 2023, at 11:49, Luca Fancellu wrote:
>>>
>>> Enable Xen to handle the SVE extension, add code in cpufeature module
>>> to handle ZCR SVE reg
From: Josh Poimboeuf
The paravirt_patch_site struct has 12 bytes of data and 4 bytes of
padding, for a total of 16 bytes. However, when laying out the structs
in the .parainstructions section, the vmlinux script only aligns before
each struct's data, not after. So the last entry doesn't have th
flight 180261 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180261/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c9fb11f92f52e06bcb1279b467a3b2667757be44
baseline version:
ovmf 55b67b6950e648338adfe
On 14/04/2023 4:19 pm, Roger Pau Monne wrote:
> From: Josh Poimboeuf
>
> The paravirt_patch_site struct has 12 bytes of data and 4 bytes of
> padding, for a total of 16 bytes. However, when laying out the structs
> in the .parainstructions section, the vmlinux script only aligns before
> each str
flight 180255 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180255/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt 15 migrate-s
Hi Luca,
On 14/04/2023 12:07, Luca Fancellu wrote:
On 13 Apr 2023, at 20:52, Julien Grall wrote:
Hi Luca,
On 13/04/2023 15:05, Luca Fancellu wrote:
On 13 Apr 2023, at 14:30, Julien Grall wrote:
On 13/04/2023 14:24, Luca Fancellu wrote:
Hi Julien,
Hi Luca,
@@ -594,6 +597,7 @@ in
Hi Henry,
On 4/13/23 7:09 PM, Henry Wang wrote:
Hi Vikram,
-Original Message-
Subject: [XEN][PATCH v5 12/17] common/device_tree: Add rwlock for dt_host
Dynamic programming ops will modify the dt_host and there might be other
function which are browsing the dt_host at the same time
Hi Michal,
On 4/13/23 2:19 AM, Michal Orzel wrote:
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
Remove __init from following function to access during runtime:
1. map_irq_to_domain()
2. handle_device_interrupt()
s/interrupt/interrupts/ since there is no handle_device_inter
Hi,
Julien & Michal, thanks for comments.
On 4/13/23 3:03 AM, Julien Grall wrote:
Hi,
On 11/04/2023 20:16, Vikram Garhwal wrote:
Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to unflatten_device_tree().
2. Remove static function type
Hi Michal,
On 4/13/23 6:11 AM, Michal Orzel wrote:
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
Rename overlay_get_target() to fdt_overlay_target_offset() and remove static
function type.
This is done to get the target path for the overlay nodes which is very useful
in many cases. F
Hi Michal,
On 4/13/23 6:40 AM, Michal Orzel wrote:
Hi Vikram,
On 11/04/2023 21:16, Vikram Garhwal wrote:
Add device_tree_find_node_by_path() to find a matching node with path for a
dt_device_node.
Reason behind this function:
Each time overlay nodes are added using .dtbo, a new fdt(memc
Hi,
On 14/04/2023 18:51, Vikram Garhwal wrote:
On 4/13/23 3:03 AM, Julien Grall wrote:
Hi,
On 11/04/2023 20:16, Vikram Garhwal wrote:
Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to unflatten_device_tree().
2. Remove static functio
flight 180262 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180262/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 797f526ae2a83811b0ccbde0138c65a9f137eba5
baseline version:
ovmf c9fb11f92f52e06bcb127
Hi,
On 4/14/23 11:09 AM, Julien Grall wrote:
Hi,
On 14/04/2023 18:51, Vikram Garhwal wrote:
On 4/13/23 3:03 AM, Julien Grall wrote:
Hi,
On 11/04/2023 20:16, Vikram Garhwal wrote:
Following changes are done to __unflatten_device_tree():
1. __unflatten_device_tree() is renamed to
unflat
I've been digging into VMX internals and I see why MMIO emulation pretty much
requires x86 instruction emulation. Even the Linux KVM code borrowed Xen's
emulation...
Thus, I'm trying to understand Xen's x86 emulation implementation...
How was it developed? (x86 instruction handling is incredibly
This is a collection of fixes needed to build the hypervisor with -Og for arm64.
I build-tested this with the following command:
make -j $(nproc) \
EXTRA_CFLAGS_XEN_CORE="-Og" \
XEN_TARGET_ARCH=arm64 \
CROSS_COMPILE=aarch64-none-linux-gnu- \
dist-xen
Stewart Hildebrand (3):
xe
When building the hypervisor with -Og, we run into a __bad_cmpxchg link error:
aarch64-none-linux-gnu-ld: prelink.o: in function `__int_cmpxchg':
.../xen/./arch/arm/include/asm/arm64/cmpxchg.h:117: undefined reference to
`__bad_cmpxchg'
aarch64-none-linux-gnu-ld: .../xen/./arch/arm/include/asm/ar
When building the hypervisor with -Og, we encounter the following error:
arch/arm/domain_build.c: In function ‘make_cpus_node’:
arch/arm/domain_build.c:2040:12: error: ‘clock_valid’ may be used uninitialized
[-Werror=maybe-uninitialized]
2040 | if ( clock_valid )
|^
arc
When building the hypervisor for arm64 with -Og, we encounter a (false)
uninitialized use warning:
arch/arm/efi/boot.c: In function ‘efi_start’:
arch/arm/efi/boot.c:1468:9: error: ‘argc’ may be used uninitialized
[-Werror=maybe-uninitialized]
1468 | efi_arch_handle_cmdline(argc ? *argv :
flight 180258 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180258/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 180231
test-amd64-amd64-xl-qemuu-ws16-amd6
On 14/04/2023 7:33 pm, Alex Olson wrote:
> I've been digging into VMX internals and I see why MMIO emulation pretty much
> requires x86 instruction emulation. Even the Linux KVM code borrowed Xen's
> emulation...
>
> Thus, I'm trying to understand Xen's x86 emulation implementation...
>
> How was
The list was not being initialized, which could result in a crash in
vpci_remove_device if no list items were added.
Signed-off-by: Stewart Hildebrand
---
xen/drivers/vpci/msix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
index 25bde77
flight 180263 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180263/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 180256 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180256/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-xl-multivcpu
When TSC is synchronized across sockets then there is no reason in
calibrating the delay for the first CPU which comes up on a socket.
Just reuse the existing calibration value.
This removes 100ms pointlessly wasted time from CPU hotplug.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/smpb
This is used in the SEV play_dead() implementation to re-online CPUs. But
that has nothing to do with CPU0.
Signed-off-by: Thomas Gleixner
Cc: Tom Lendacky
---
arch/x86/include/asm/cpu.h |2 +-
arch/x86/kernel/callthunks.c |2 +-
arch/x86/kernel/head_32.S| 10 +-
arch/x8
Make topology_phys_to_logical_pkg_die() static as it's only used in
smpboot.c and fixup the kernel-doc warnings for both functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/topology.h |3 ---
arch/x86/kernel/smpboot.c | 10 ++
2 files changed, 6 insertions(+),
No point in keeping them around.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/smpboot.c |4 ++--
kernel/cpu.c |2 +-
kernel/smp.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@
Hi!
This is a complete rework of the parallel bringup patch series (V17)
https://lore.kernel.org/lkml/20230328195758.1049469-1-usama.a...@bytedance.com
to address the issues which were discovered in review:
1) The X86 microcode loader serialization requirement
https://lore.kernel.org
From: David Woodhouse
There are four logical parts to what native_cpu_up() does on the BSP (or
on the controlling CPU for a later hotplug):
1) Wake the AP by sending the INIT/SIPI/SIPI sequence.
2) Wait for the AP to make it as far as wait_for_master_cpu() which
sets that CPU's bit in cpu
This was introduced with commit e1c467e69040 ("x86, hotplug: Wake up CPU0
via NMI instead of INIT, SIPI, SIPI") to eventually support physical
hotplug of CPU0:
"We'll change this code in the future to wake up hard offlined CPU0 if
real platform and request are available."
11 years later this h
This was introduced together with commit e1c467e69040 ("x86, hotplug: Wake
up CPU0 via NMI instead of INIT, SIPI, SIPI") to eventually support
physical hotplug of CPU0:
"We'll change this code in the future to wake up hard offlined CPU0 if
real platform and request are available."
11 years lat
cpu_callout_mask is used for the stop machine based MTRR/PAT init.
In preparation of moving the BP/AP synchronization to the core hotplug
code, use a private CPU mask for cacheinfo and manage it in the
starting/dying hotplug state.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/cacheinf
Now that the CPU0 hotplug cruft is gone, the only user is AMD SEV.
Signed-off-by: Thomas Gleixner
Cc: Tom Lendacky
---
arch/x86/kernel/callthunks.c |2 +-
arch/x86/kernel/head_32.S| 14 --
arch/x86/kernel/head_64.S|2 +-
3 files changed, 2 insertions(+), 16 deletio
Spin-waiting on the control CPU until the AP reaches the TSC
synchronization is just a waste especially in the case that there is no
synchronization required.
As the synchronization has to run with interrupts disabled the control CPU
part can just be done from a SMP function call. The upcoming AP
The synchronization of the AP with the control CPU is a SMP boot problem
and has nothing to do with cpu_init().
Open code cpu_init_secondary() in start_secondary() and move
wait_for_master_cpu() into the SMP boot code.
No functional change.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/a
The usage is in smpboot.c and not in the CPU initialization code.
The XEN_PV usage of cpu_callout_mask is obsolete as cpu_init() not longer
waits and cacheinfo has its own CPU mask now, so cpu_callout_mask can be
made static too.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/cpumask.h
Now that TSC synchronization is SMP function call based there is no reason
to wait for the AP to be set in smp_callin_mask. The control CPU waits for
the AP to set itself in the online mask anyway.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/smpboot.c | 61 +++---
Now that the core code drops sparse_irq_lock after the idle thread
synchronized, it's pointless to wait for the AP to mark itself online.
Whether the control CPU runs in a wait loop or sleeps in the core code
waiting for the online operation to complete makes no difference.
Signed-off-by: Thomas
No point in this conditional voodoo. Un-initializing the lock mechanism is
safe to be called unconditionally even if it was already invoked when the
CPU died.
Remove the invocation of xen_smp_intr_free() as that has been already
cleaned up in xen_cpu_dead_hvm().
Signed-off-by: Thomas Gleixner
Cc
Now that the core code drops sparse_irq_lock after the idle thread
synchronized, it's pointless to wait for the AP to mark itself online.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/smpboot.c | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
--- a/arch/x8
There is no harm to hold sparse_irq lock until the upcoming CPU completes
in cpuhp_online_idle(). This allows to remove cpu_online() synchronization
from architecture code.
Signed-off-by: Thomas Gleixner
---
kernel/cpu.c | 28 +++-
1 file changed, 19 insertions(+), 9 de
Implement the validation function which tells the core code whether
parallel bringup is possible:
1) Valid CPUID leaf for APIC ID retrieval. For non x2APIC systmms leaf
0x1 is sufficient, otherwise leaf 0xb or 0x1f must be available.
2) Prevent parallel bringup on encrypted guests as thi
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Russell King
Cc: Arnd Bergmann
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm/Kconfig |1 +
arch/arm/include/asm/smp.h |2 +-
a
Switch to the CPU hotplug core state tracking and synchronization
mechanim. This unfortunately requires to add dead reporting to the non CPS
platforms as CPS is the only user, but it allows an overall consolidation
of this functionality.
No functional change intended.
Signed-off-by: Thomas Gleixn
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Catalin Marinas
Cc: Will Deacon
Cc: linux-arm-ker...@lists.infradead.org
---
arch/arm64/Kconfig |1 +
arch/arm64/include/asm/smp.h |2
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: "James E.J. Bottomley"
Cc: Helge Deller
Cc: linux-par...@vger.kernel.org
---
arch/parisc/Kconfig |1 +
arch/parisc/kernel/process.c |4
There is often significant latency in the early stages of CPU bringup, and
time is wasted by waking each CPU (e.g. with SIPI/INIT/INIT on x86) and
then waiting for it to respond before moving on to the next.
Allow a platform to enable parallel setup which brings all to be onlined
CPUs up to the CP
The bring up logic of a to be onlined CPU consists of several parts, which
are considered to be a single hotplug state:
1) Control CPU issues the wake-up
2) To be onlined CPU starts up, does the minimal initialization,
reports to be alive and waits for release into the complete bring-up.
From: David Woodhouse
Rework the real-mode startup code to allow for APs to be brought up in
parallel. This is in two parts:
1. Introduce a bit-spinlock to prevent them from all using the real
mode stack at the same time.
2. Avoid needing to use the global smpboot_control variable to pass
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Paul Walmsley
Cc: Palmer Dabbelt
Cc: linux-ri...@lists.infradead.org
---
arch/riscv/Kconfig |1 +
arch/riscv/include/asm/smp.h|
Make the primary thread tracking CPU mask based in preparation for simpler
handling of parallel bootup.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/apic.h |2 --
arch/x86/include/asm/topology.h | 19 +++
arch/x86/kernel/apic/apic.c | 20 +--
All users converted to the hotplug core mechanism.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h |2 -
kernel/smpboot.c| 75
2 files changed, 77 deletions(-)
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -193,8 +19
Save the extended topology leaf number if it exists and is valid in
preparation of parallel CPU bringup.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/topology.h |1 +
arch/x86/kernel/cpu/topology.c |3 +++
2 files changed, 4 insertions(+)
--- a/arch/x86/include/asm/topology.
Switch to the CPU hotplug core state tracking and synchronization
mechanim. No functional change intended.
Signed-off-by: Thomas Gleixner
Cc: Guo Ren
Cc: linux-c...@vger.kernel.org
---
arch/csky/Kconfig |1 +
arch/csky/include/asm/smp.h |2 +-
arch/csky/kernel/smp.c |
From: David Woodhouse
Commit dce1ca0525bf ("sched/scs: Reset task stack state in bringup_cpu()")
ensured that the shadow call stack and KASAN poisoning were removed from
a CPU's stack each time that CPU is brought up, not just once.
This is not incorrect. However, with parallel bringup the idle
The early detection stores the extended topology leaf number which is
required for parallel hotplug.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/amd.c |2 ++
1 file changed, 2 insertions(+)
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -692,6 +692,8 @@ static
No more users.
Signed-off-by: Thomas Gleixner
---
include/linux/cpu.h |2 -
kernel/smpboot.c| 90
2 files changed, 92 deletions(-)
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -184,8 +184,6 @@ void arch_cpu_idle_enter(void
The x86 CPU bringup state currently does AP wake-up, wait for AP to
respond and then release it for full bringup.
It is safe to be split into a wake-up and and a separate wait+release
state.
Provide the required functions and enable the split CPU bringup, which
prepares for parallel bringup, wher
The CPU state tracking and synchronization mechanism in smpboot.c is
completely independent of the hotplug code and all logic around it is
implemented in architecture specific code.
Except for the state reporting of the AP there is absolutely nothing
architecture specific and the sychronization an
The new AP state tracking and synchronization mechanism in the CPU hotplug
core code allows to remove quite some x86 specific code:
1) The AP alive synchronization based on cpumasks
2) The decision whether an AP can be brought up again
Signed-off-by: Thomas Gleixner
Cc: Juergen Gross
Cc: B
From: David Woodhouse
Enable parallel bringup for SEV-ES guests. The APs can't actually execute
the CPUID instruction directly during early startup, but they can make the
GHCB call directly instead, just as the #VC trap handler would do.
Thanks to Sabin for talking me through the way this works.
The prior check has && vs || mixups, making it tautologically false and thus
providing no safety at all. There are boundary errors too.
First start with a comment describing how the .altinstructions and
.altinstr_replacement sections interact, and perform suitable cross-checking.
Second, rewrite
flight 180264 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180264/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 broken
Tests which did not s
Hi Stewart,
> -Original Message-
> Subject: [PATCH 1/3] xen/arm: mark __guest_cmpxchg always_inline
>
> When building the hypervisor with -Og, we run into a __bad_cmpxchg link
> error:
>
> aarch64-none-linux-gnu-ld: prelink.o: in function `__int_cmpxchg':
> .../xen/./arch/arm/include/asm
Hi Stewart,
> -Original Message-
> Subject: [PATCH 3/3] xen/arm: fix unitialized use warning
>
> When building the hypervisor with -Og, we encounter the following error:
>
> arch/arm/domain_build.c: In function ‘make_cpus_node’:
> arch/arm/domain_build.c:2040:12: error: ‘clock_valid’ may
flight 180265 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180265/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-amd64-amd64-xl-qemuu-debianhvm-i386-
87 matches
Mail list logo
