On 03.05.2023 20:58, Andrew Cooper wrote:
> Loading microcode can cause new features to appear.
Or disappear (LWP)? While I don't think we want to panic() in this
case (we do on the S3 resume path when recheck_cpu_features() fails
on the BSP), it would seem to me that we want to go a step further
On 28/04/2023 19:55, Ayan Kumar Halder wrote:
>
>
> The DT functions (dt_read_number(), device_tree_get_reg(), fdt_get_mem_rsv())
> currently accept or return 64-bit values.
>
> In future when we support 32-bit physical address, these DT functions are
> expected to accept/return 32-bit or 64-
On 03.05.23 16:39, Juergen Gross wrote:
On 03.05.23 12:18, Julien Grall wrote:
On 05/04/2023 08:03, Juergen Gross wrote:
+static void domain_acc_valid_max(struct domain *d, enum accitem what,
+ unsigned int val)
+{
+ assert(what < ARRAY_SIZE(d->acc));
+ assert(what < ARRAY
On 28/04/2023 19:55, Ayan Kumar Halder wrote:
>
>
> dt_device_get_address() can accept uint64_t only for address and size.
> However, the address/size denotes physical addresses. Thus, they should
> be represented by 'paddr_t'.
> Consequently, we introduce a wrapper for dt_device_get_address()
On 28/04/2023 19:55, Ayan Kumar Halder wrote:
>
>
> Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
> SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
> writeq_relaxed_non_atomic() to write to it instead of invoking
> writel_relaxed() twice for lower half and upper half o
On 03.05.2023 19:14, Tamas K Lengyel wrote:
>> @@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
>>
>> state:
>> if ( reset_state )
>> +{
>> rc = copy_settings(d, pd);
>> +/* TBD: What to do here with -ERESTART? */
>
> Ideally we could avoid hitting code-p
On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
> --- a/xen/include/xen/sched.h
> +++ b/xen/include/xen/sched.h
> @@ -438,12 +438,14 @@ struct domain
>
> struct grant_table *grant_table;
>
> +#ifdef CONFIG_HAS_PIRQ
> /*
> * Interrupt to event-channel mappings and ot
On 04.05.2023 09:44, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -438,12 +438,14 @@ struct domain
>>
>> struct grant_table *grant_table;
>>
>> +#ifdef CONFIG_HAS_PIRQ
>> /
flight 180519 xen-unstable real [real]
flight 180526 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180519/
http://logs.test-lab.xenproject.org/osstest/logs/180526/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 04/05/2023 8:08 am, Jan Beulich wrote:
> On 03.05.2023 20:58, Andrew Cooper wrote:
>> Loading microcode can cause new features to appear.
> Or disappear (LWP)? While I don't think we want to panic() in this
> case (we do on the S3 resume path when recheck_cpu_features() fails
> on the BSP), it w
On 03.05.2023 18:31, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -4,6 +4,37 @@
> #include
> #include
>
> +/*
> + * RISC-V64 Layout:
> + *
> + * From the riscv-privileged doc:
> + * When mapping between narrower and wid
On Thu, May 04, 2023 at 09:50:27AM +0200, Jan Beulich wrote:
> On 04.05.2023 09:44, Roger Pau Monné wrote:
> > On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
> >> --- a/xen/include/xen/sched.h
> >> +++ b/xen/include/xen/sched.h
> >> @@ -438,12 +438,14 @@ struct domain
> >>
> >>
On 04.05.2023 10:08, Andrew Cooper wrote:
> On 04/05/2023 8:08 am, Jan Beulich wrote:
>> On 03.05.2023 20:58, Andrew Cooper wrote:
>>> Loading microcode can cause new features to appear.
>> Or disappear (LWP)? While I don't think we want to panic() in this
>> case (we do on the S3 resume path when
On 04.05.2023 10:13, Roger Pau Monné wrote:
> On Thu, May 04, 2023 at 09:50:27AM +0200, Jan Beulich wrote:
>> On 04.05.2023 09:44, Roger Pau Monné wrote:
>>> On Wed, May 03, 2023 at 05:33:05PM +0200, Jan Beulich wrote:
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -4
On Thu, May 04, 2023 at 09:08:02AM +0100, Andrew Cooper wrote:
> On 04/05/2023 8:08 am, Jan Beulich wrote:
> > On 03.05.2023 20:58, Andrew Cooper wrote:
> >> Loading microcode can cause new features to appear.
> > Or disappear (LWP)? While I don't think we want to panic() in this
> > case (we do on
On 03/05/2023 18:43, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 03/05/2023 17:49, Ayan Kumar Halder wrote:
On 03/05/2023 08:40, Julien Grall wrote:
Hi,
Hi Julien,
Title: Did you mean "Enable spin table"?
Yes, that would be more concrete.
On 02/05/2023 11:58, Ayan Kumar Halder wrote:
Hi Stewart,
> On 3 May 2023, at 21:18, Stewart Hildebrand
> wrote:
>
> When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the
> following warning:
>
> arch/arm/pci/pci-host-common.c: In function ‘pci_host_common_probe’:
> arch/arm/pci/pci-host-common.c:238:26: warning: compar
On 04.05.2023 10:22, Roger Pau Monné wrote:
> On Thu, May 04, 2023 at 09:08:02AM +0100, Andrew Cooper wrote:
>> On 04/05/2023 8:08 am, Jan Beulich wrote:
>>> On 03.05.2023 20:58, Andrew Cooper wrote:
Loading microcode can cause new features to appear.
>>> Or disappear (LWP)? While I don't thin
On 04/05/2023 10:07 am, Jan Beulich wrote:
> On 04.05.2023 10:22, Roger Pau Monné wrote:
>> On Thu, May 04, 2023 at 09:08:02AM +0100, Andrew Cooper wrote:
>>> On 04/05/2023 8:08 am, Jan Beulich wrote:
On 03.05.2023 20:58, Andrew Cooper wrote:
> Loading microcode can cause new features to a
Hi Stefano,
> The tiny "xen,iommu-el2-v1" driver could be backported to the stable
> trees, I would imagine. Otherwise, do you have another suggestion?
There is stub IOMMU driver already merged to the Linux Kernel:
Commit 1ca55d50e50c74747a7b8846dac306fbe5ac4cf5 ("xen/grant-dma-iommu:
Introduc
Hi Stewart,
On 3 May 2023, at 8:18 pm, Stewart Hildebrand
wrote:
When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the
following warning:
arch/arm/pci/pci-host-common.c: In function ‘pci_host_common_probe’:
arch/arm/pci/pci-host-common.c:238:26: warning: comparison is always
Hi,
On 04/05/2023 09:59, Bertrand Marquis wrote:
Hi Stewart,
On 3 May 2023, at 21:18, Stewart Hildebrand wrote:
When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the
following warning:
arch/arm/pci/pci-host-common.c: In function ‘pci_host_common_probe’:
arch/arm/pci/pci-h
On 04/05/2023 9:17 am, Jan Beulich wrote:
> On 04.05.2023 10:08, Andrew Cooper wrote:
>> On 04/05/2023 8:08 am, Jan Beulich wrote:
>>> On 03.05.2023 20:58, Andrew Cooper wrote:
Loading microcode can cause new features to appear.
>>> Or disappear (LWP)? While I don't think we want to panic() in
Loading microcode can cause new features to appear. This has happened
routinely since Spectre/Meltdown, and even the presence of new status bits can
sometimes mean the administrator has no further actions to perform.
Conversely, loading microcode can occasionally cause features to disappear.
As w
On 28.04.23 11:50, Hou Wenlong wrote:
From: Brian Gerst
From: Brian Gerst
If the compiler supports it, use a standard per-cpu variable for the
stack protector instead of the old fixed location. Keep the fixed
location code for compatibility with older compilers.
[Hou Wenlong: Disable it on
Hi,
> On 4 May 2023, at 12:10, Julien Grall wrote:
>
> Hi,
>
> On 04/05/2023 09:59, Bertrand Marquis wrote:
>> Hi Stewart,
>>> On 3 May 2023, at 21:18, Stewart Hildebrand
>>> wrote:
>>>
>>> When building with EXTRA_CFLAGS_XEN_CORE="-Wtype-limits", we observe the
>>> following warning:
>>>
>
On Thu, May 04, 2023 at 11:26:07AM +0100, Andrew Cooper wrote:
> Loading microcode can cause new features to appear. This has happened
> routinely since Spectre/Meltdown, and even the presence of new status bits can
> sometimes mean the administrator has no further actions to perform.
>
> Convers
On 04/05/2023 11:47 am, Roger Pau Monné wrote:
> On Thu, May 04, 2023 at 11:26:07AM +0100, Andrew Cooper wrote:
>> Loading microcode can cause new features to appear. This has happened
>> routinely since Spectre/Meltdown, and even the presence of new status bits
>> can
>> sometimes mean the admin
On 01.05.2023 21:30, Jason Andryuk wrote:
> Export feature_detect as intel_feature_detect so it can be re-used by
> HWP.
>
> Signed-off-by: Jason Andryuk
Acked-by: Jan Beulich
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/7Vv6erX9dwCazMfCZ4Hbnf8b/ and you can
edit to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
On 02/05/2023, 11:23, Roger Pau Monné wrote:
> On Tue, May 02, 2023 at 12:18:06PM +0200, Jan Beulich wrote:
> > On 02.05.2023 12:10, Roger Pau Monné wrote:
> > > On Wed, Apr 26, 2023 at 02:55:20PM +, Ruben Hakobyan wrote:
> > >> Xen reserves a constant number of pages that can be used for mappi
On Thu, May 4, 2023 at 3:44 AM Jan Beulich wrote:
>
> On 03.05.2023 19:14, Tamas K Lengyel wrote:
> >> @@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
> >>
> >> state:
> >> if ( reset_state )
> >> +{
> >> rc = copy_settings(d, pd);
> >> +/* TBD: What to
Nothing in x86/bitops uses anything from x86/cpufeatureset, and it is creating
problems when trying to untangle other aspects of feature handling.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/include/asm/bitops.h | 1 -
1 file changed, 1 de
On 01.05.2023 21:30, Jason Andryuk wrote:
> For cpufreq=xen:hwp, placing the option inside the governor wouldn't
> work. Users would have to select the hwp-internal governor to turn off
> hwp support.
I'm afraid I don't understand this, and you'll find a comment towards
this further down. Even wh
Allow the use of Cppcheck version above 2.7, exception for 2.8 which
is known and documented do be broken.
Signed-off-by: Luca Fancellu
---
xen/scripts/xen_analysis/cppcheck_analysis.py | 20 +++
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/xen/scripts/xen_analy
Currently Cppcheck has a limitation that prevents to use make with
parallel build and have a parallel Cppcheck invocation on each
translation unit (the .c files), because of spurious internal errors.
The issue comes from the fact that when using the build directory,
Cppcheck saves temporary files
This serie includes a fix for a limitation of xen-analysis.py that when using
cppcheck and make parallel build, it was spuriously failing.
The second patch is enabling the tool to accept cppcheck version above 2.7
(excluding 2.8 for the reasons described in the documentation).
The final one is a
repository in the reports
Currently the cppcheck report entries shows the relative file path
from the /xen folder of the repository instead of the base folder.
In order to ease the checks, for example, when looking a git diff
output and the report, use the repository folder as base.
Signed-off-by
Hi Andrew,
> On 14 Apr 2023, at 10:58, Jens Wiklander wrote:
>
> 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 ( !ff
On 04/05/2023 2:12 pm, Luca Fancellu wrote:
> Allow the use of Cppcheck version above 2.7, exception for 2.8 which
> is known and documented do be broken.
>
> Signed-off-by: Luca Fancellu
> ---
> xen/scripts/xen_analysis/cppcheck_analysis.py | 20 +++
> 1 file changed, 16 insertio
On 04.05.2023 15:07, Andrew Cooper wrote:
> Nothing in x86/bitops uses anything from x86/cpufeatureset, and it is creating
> problems when trying to untangle other aspects of feature handling.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
> CC: Wei Liu
> ---
>
On Mon, Mar 27, 2023 at 05:13:25PM +0100, George Dunlap wrote:
> A recent xentrace highlighted an unhandled corner case in the vcpu
> "start-of-day" logic, if the trace starts after the last running ->
> non-running transition, but before the first non-running -> running
> transition. Because star
On Mon, Mar 27, 2023 at 05:13:26PM +0100, George Dunlap wrote:
> For now, mainly just do volume analysis and get rid of the warnings.
>
> Signed-off-by: George Dunlap
Acked-by: Anthony PERARD
--
Anthony PERARD
flight 180522 qemu-mainline real [real]
flight 180529 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180522/
http://logs.test-lab.xenproject.org/osstest/logs/180529/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
On 04/05/2023 2:20 pm, Jan Beulich wrote:
> On 04.05.2023 15:07, Andrew Cooper wrote:
>> Nothing in x86/bitops uses anything from x86/cpufeatureset, and it is
>> creating
>> problems when trying to untangle other aspects of feature handling.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Jan Be
> On 4 May 2023, at 14:19, Andrew Cooper wrote:
>
> On 04/05/2023 2:12 pm, Luca Fancellu wrote:
>> Allow the use of Cppcheck version above 2.7, exception for 2.8 which
>> is known and documented do be broken.
>>
>> Signed-off-by: Luca Fancellu
>> ---
>> xen/scripts/xen_analysis/cppcheck_analy
02.05.2023 17:37, Jason Andryuk wrote:
xen_9pfs_free can't use gnttabdev since it is already closed and NULL-ed
out when free is called. Do the teardown in _disconnect(). This
matches the setup done in _connect().
Ping?
/mjt
flight 180525 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 8 xen-boot fail REGR. vs. 180278
build-arm64-pvops
Hi,
[ snipped for brevity, report summary:
XAPI daemon in domU tries to write to a non-existent xenstore node in a
non-XAPI dom0 ]
On 12 Apr 2023 18:41, Yann Dirson wrote:
Is there anything besides XAPI using this node, or the other data
published by xe-daemon?
On my vanilla Xen (ie. non-XA
On 03/05/2023 14:08, Julien Grall wrote:
>
>
> Hi,
>
> On 28/04/2023 18:55, Ayan Kumar Halder wrote:
>> In the callback functions invoked by dt_for_each_range() ie
>> handle_pci_range(),
>> map_range_to_domain(), 'u64' should be replaced with 'uint64_t' as the data
>> type
>> for the paramet
On 28/04/2023 19:55, Ayan Kumar Halder wrote:
>
>
> handle_pci_range() and map_range_to_domain() take addr and len as uint64_t
> parameters. Then frame numbers are obtained from addr and len by right
> shifting
> with PAGE_SHIFT. The frame numbers are expressed using unsigned long.
>
> Now i
On 04.05.2023 14:50, Tamas K Lengyel wrote:
> On Thu, May 4, 2023 at 3:44 AM Jan Beulich wrote:
>> On 03.05.2023 19:14, Tamas K Lengyel wrote:
@@ -1974,7 +2046,10 @@ int mem_sharing_fork_reset(struct domain
state:
if ( reset_state )
+{
rc = copy_se
This serie is dependent on this patch:
https://patchwork.kernel.org/project/xen-devel/patch/20230504131245.2985400-4-luca.fance...@arm.com/
--
Add a new tool, diff-report.py that can be used to make diff between
reports generated by xen-analysis.py tool.
Currently this tool supports the Xen cppcheck text report format in
its operations.
The tool prints every finding that is in the report passed with -r
(check report) which is not in the
Add a feature to the diff-report.py script that improves the comparison
between two analysis report, one from a baseline codebase and the other
from the changes applied to the baseline.
The comparison between reports of different codebase is an issue because
entries in the baseline could have been
On 03/05/2023 14:35, Julien Grall wrote:
>
>
> On 03/05/2023 13:20, Julien Grall wrote:
>> Hi,
>>
>> On 28/04/2023 18:55, Ayan Kumar Halder wrote:
>>> Restructure the code so that one can use pa_range_info[] table for both
>>> ARM_32 as well as ARM_64.
>>>
>>> Also, removed the hardcoding for
Hi Ayan,
On 4 May 2023, at 8:37 am, Michal Orzel wrote:
On 28/04/2023 19:55, Ayan Kumar Halder wrote:
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_r
On 01.05.2023 21:30, Jason Andryuk wrote:
> When using HWP, some of the returned data is not applicable. In that
> case, we should just omit it to avoid confusing the user. So switch to
> printing the base and turbo frequencies since those are relevant to HWP.
> Similarly, stop printing the CPU f
On Wed, Mar 29, 2023 at 12:22:16PM +0200, Jan Beulich wrote:
> I don't view a variable of this name as suitable for exporting, the more
We could rename it.
> that it carries entirely redundant information. The reasons for its
The patch replace building_out_of_srctree with abs_objtree and
abs_src
On Wed, Mar 29, 2023 at 12:23:37PM +0200, Jan Beulich wrote:
> This symlink is getting in the way of using e.g. "find" on the xen/
> subtree, and it isn't really needed when not building out-of-tree:
> The one use that there was can easily be avoided.
>
> Signed-off-by: Jan Beulich
Reviewed-by:
On 04.05.2023 16:49, Anthony PERARD wrote:
> On Wed, Mar 29, 2023 at 12:22:16PM +0200, Jan Beulich wrote:
>> I don't view a variable of this name as suitable for exporting, the more
>
> We could rename it.
>
>> that it carries entirely redundant information. The reasons for its
>
> The patch rep
On 5/4/23 15:58, zithro wrote:
> Hi,
>
> [ snipped for brevity, report summary:
> XAPI daemon in domU tries to write to a non-existent xenstore node in
> a non-XAPI dom0 ]
>
> On 12 Apr 2023 18:41, Yann Dirson wrote:
>> Is there anything besides XAPI using this node, or the other data
>> publish
Presumably by copy-and-paste we've accumulated a number of instances of
$(@D)/$(@F), which really is nothing else than $@. The split form only
needs using when we want to e.g. insert a leading . at the beginning of
the file name portion of the full name.
Signed-off-by: Jan Beulich
--- a/xen/arch
flight 180524 libvirt real [real]
flight 180533 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180524/
http://logs.test-lab.xenproject.org/osstest/logs/180533/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-
On Thu, May 4, 2023 at 9:11 AM Jan Beulich wrote:
>
> On 01.05.2023 21:30, Jason Andryuk wrote:
> > For cpufreq=xen:hwp, placing the option inside the governor wouldn't
> > work. Users would have to select the hwp-internal governor to turn off
> > hwp support.
>
> I'm afraid I don't understand th
On Thu, May 4, 2023 at 10:35 AM Jan Beulich wrote:
>
> On 01.05.2023 21:30, Jason Andryuk wrote:
> > When using HWP, some of the returned data is not applicable. In that
> > case, we should just omit it to avoid confusing the user. So switch to
> > printing the base and turbo frequencies since t
On 04/05/2023 5:16 pm, Jan Beulich wrote:
> Presumably by copy-and-paste we've accumulated a number of instances of
> $(@D)/$(@F), which really is nothing else than $@. The split form only
> needs using when we want to e.g. insert a leading . at the beginning of
> the file name portion of the full
This patch series makes the TPM version, for which the ACPI library probes,
configurable, and then add support for TPM version 2.
Changes from version 3:
* Omit tpm_version 0 case, to fallback to 1.2, previously intended for
compatibility for unknown code.
* Add checks for xenstore tpm_version
This patch introduces an optional TPM 2 interface definition to the ACPI table,
which is to be used as part of a vTPM 2 implementation.
Signed-off-by: Jennifer Herbert
Reviewed-by: Jason Andryuk
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Andrew Cooper
CC: Roger Pau Monné
CC: Jason Andryuk
This patch makes the TPM version, for which the ACPI library probes,
configurable.
If acpi_config.tpm_verison is set to 1, it indicates that 1.2 (TCPA) should be
probed.
I have also added to hvmloader an option to allow setting this new config,
which can
be triggered by setting the platform/tpm_
On 04 May 2023 17:59, Yann Dirson wrote:
On 5/4/23 15:58, zithro wrote:
Hi,
[ snipped for brevity, report summary:
XAPI daemon in domU tries to write to a non-existent xenstore node in
a non-XAPI dom0 ]
On 12 Apr 2023 18:41, Yann Dirson wrote:
Is there anything besides XAPI using this node,
Michael!
On Thu, Apr 27 2023 at 14:48, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Friday, April 14, 2023 4:44
> PM
>
> I smoke-tested several Linux guest configurations running on Hyper-V,
> using the "kernel/git/tglx/devel.git hotplug" tree as updated on April 26th.
> No functional iss
flight 180532 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180532/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4b02045f86d6aac8a617bf3f65f9cb2146630ce3
baseline version:
ovmf d6b42ed7ed1b0c4584097
From: Thomas Gleixner
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
From: Thomas Gleixner
When TSC is synchronized across sockets then there is no reason to
calibrate 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 per socket.
Signed-off-by: Thomas Gl
From: Thomas Gleixner
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|
From: Thomas Gleixner
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 c
From: Thomas Gleixner
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 a
Hi!
This is version 2 of the reworked parallel bringup series. Version 1 can be
found here:
https://lore.kernel.org/lkml/20230414225551.858160...@linutronix.de
Background
--
The reason why people are interested in parallel bringup is to shorten the
(kexec) reboot time of cloud server
From: Thomas Gleixner
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
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
From: Thomas Gleixner
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.
From: Thomas Gleixner
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
---
arc
From: Thomas Gleixner
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/
From: Thomas Gleixner
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 functio
From: Thomas Gleixner
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
From: Thomas Gleixner
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 change
From: Thomas Gleixner
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 | 26 ++
1 file changed, 2 insertions(+), 24 d
From: Thomas Gleixner
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 +
From: Thomas Gleixner
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
From: Thomas Gleixner
Implement the validation function which tells the core code whether
parallel bringup is possible.
The only condition for now is that the kernel does not run in an encrypted
guest as these will trap the RDMSR via #VC, which cannot be handled at that
point in early startup.
From: Thomas Gleixner
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
From: Thomas Gleixner
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
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
From: Thomas Gleixner
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
From: Thomas Gleixner
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 int
From: Thomas Gleixner
For parallel CPU brinugp it's required to read the APIC ID in the low level
startup code. The virtual APIC base address is a constant because its a
fix-mapped address. Exposing that constant which is composed via macros to
assembly code is non-trivial dues to header inclusio
From: Thomas Gleixner
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/ar
From: Thomas Gleixner
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.
From: David Woodhouse
In parallel startup mode the APs are kicked alive by the control CPU
quickly after each other and run through the early startup code in
parallel. The real-mode startup code is already serialized with a
bit-spinlock to protect the real-mode stack.
In parallel startup mode th
1 - 100 of 158 matches
Mail list logo
