Both callsites call them as a pair, and the buildid really is as much a part
of the version as the changeset.
This involves rearranging console_init_preirq() to ensure xen_build_init() is
ahead of print_version().
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC
: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Ross Lagerwall
Both the code diffstat, and the binary on x86 speaks for themselves:
add/remove: 1/2 grow/shrink: 0/6 up/down: 4/-348 (-344)
Function
Mostly for patch 2.
Andrew Cooper (2):
xen/version: Fold print_build_id() into print_version()
xen/version: Remove xen_build_id() and export the variable instead
xen/common/kernel.c| 14 --
xen/common/keyhandler.c| 1 -
xen/common/livepatch.c | 23
On 30/07/2025 5:40 pm, Teddy Astie wrote:
> When settings HVM_PARAM_IDENT_PT, skip domain pausing when :
> - there is no vcpu
> - unrestricted guest capability is used
>
> Signed-off-by: Teddy Astie
> ---
> xen/arch/x86/hvm/hvm.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff
On 30/07/2025 3:06 pm, Dmytro Prokopchuk1 wrote:
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index e78179fcb8..fba75be2ee 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -86,6 +86,14 @@ Deviations related to MISRA C:2012 Rules:
> ge
and repeate the failed tests list and the
> end.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Andrew Cooper
On 28/07/2025 6:03 am, Jiqian Chen wrote:
> vpci_remove_register() only supports removing a register in a time,
> but the follow-on changes need to remove all registers within a range.
> So, refactor it to support removing all registers in a given region.
>
> And it is no issue to remove a non exis
On 30/07/2025 10:50 am, Jan Beulich wrote:
> On 28.07.2025 07:03, Jiqian Chen wrote:
>> +static int vpci_ext_capability_hide(
>> +const struct pci_dev *pdev, unsigned int cap)
>> +{
>> +const unsigned int offset = pci_find_ext_capability(pdev->sbdf, cap);
>> +struct vpci_register *r, *p
On 29/07/2025 3:44 pm, Jan Beulich wrote:
> On 29.07.2025 16:29, Andrew Cooper wrote:
>> On 29/07/2025 3:26 pm, Jan Beulich wrote:
>>> This was needed only for generic_swap(), which disappeared in
>>> 8cb0341a61fa ("xen/sort: Switch to an extern inline implementati
ing this shows one path now needing braces, and one path in
evtchn_bind_pirq() where the expanded form simplies back to no delta, as it
follows an unconditional clear of info->evtchn.
No functional change; The compiled hypervisors are the same.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERA
On 29/07/2025 10:24 pm, Dmytro Prokopchuk1 wrote:
> Signed-off-by: Dmytro Prokopchuk
> ---
> xen/arch/arm/dm.c | 2 +-
> xen/arch/arm/domctl.c | 2 +-
> xen/arch/arm/gic-vgic.c| 26 +++---
> xen/arch/arm/gic.c
On 29/07/2025 10:24 pm, Dmytro Prokopchuk1 wrote:
> Signed-off-by: Dmytro Prokopchuk
> ---
> xen/common/grant_table.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index cf131c43a1..9b8f0d87d3 100644
> ---
On 29/07/2025 10:24 pm, Dmytro Prokopchuk1 wrote:
> diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
> index c8c1bfa615..2efb5f5c78 100644
> --- a/xen/common/event_channel.c
> +++ b/xen/common/event_channel.c
> @@ -672,7 +672,7 @@ static int evtchn_bind_pirq(evtchn_bind_pirq_t *
On 29/07/2025 10:08 pm, Stewart Hildebrand wrote:
> On 7/29/25 04:32, Jan Beulich wrote:
>> On 28.07.2025 22:09, Andrew Cooper wrote:
>>> On 28/07/2025 8:52 pm, Stewart Hildebrand wrote:
>>>> In vcpu_create after scheduler data is allocated, if
>>>> vmtra
On 21/07/2025 9:37 am, Frediano Ziglio wrote:
> This change removes some pieve of code working around with
> some compiler warnings.
> No functional change.
>
> Signed-off-by: Frediano Ziglio
"Piece", although peeve would almost work in context. Can be fixed on
commit.
~Andrew
On 29/07/2025 8:21 pm, Andrew Cooper wrote:
> On 29/07/2025 12:01 pm, Juergen Gross wrote:
>> diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
>> index 77e0d377c5..f2c8b92d07 100644
>> --- a/tools/xenstored/lu.c
>> +++ b/tools/xenstored/lu.c
>> @@ -
On 29/07/2025 12:01 pm, Juergen Gross wrote:
> diff --git a/tools/xenstored/lu.c b/tools/xenstored/lu.c
> index 77e0d377c5..f2c8b92d07 100644
> --- a/tools/xenstored/lu.c
> +++ b/tools/xenstored/lu.c
> @@ -27,9 +27,11 @@ struct live_update *lu_status;
>
> struct lu_dump_state {
> void *buf
On 24/07/2025 12:04 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/arm/include/asm/Makefile
> b/xen/arch/arm/include/asm/Makefile
> index 4565baca6a4d..cec13c889dab 100644
> --- a/xen/arch/arm/include/asm/Makefile
> +++ b/xen/arch/arm/include/asm/Makefile
> @@ -5,6 +5,7 @@ generic-y += hardirq
On 29/07/2025 3:26 pm, Jan Beulich wrote:
> This was needed only for generic_swap(), which disappeared in
> 8cb0341a61fa ("xen/sort: Switch to an extern inline implementation").
>
> Signed-off-by: Jan Beulich
Oh, nice.
Acked-by: Andrew Cooper
I'd expect there to be
ndler().
>
> The ground work for run_in_exception_handler() removal was done under XSA-453:
> https://xenbits.xen.org/xsa/advisory-453.html
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Denis Mukhin
I wanted to do a before/after comparison, but interestingly I can't even
On 29/07/2025 1:29 am, Jason Andryuk wrote:
> On 2025-07-28 06:45, Andrew Cooper wrote:
>> On 28/07/2025 11:24 am, Marek Marczykowski-Górecki wrote:
>>> When running xl in a domU, it doesn't have access to the Xen command
>>> line. Before the non-truncating xc_xen
On 28/07/2025 9:09 pm, Andrew Cooper wrote:
> On 28/07/2025 8:52 pm, Stewart Hildebrand wrote:
>> In vcpu_create after scheduler data is allocated, if
>> vmtrace_alloc_buffer fails, it will jump to the wrong cleanup label
>> resulting in a memory leak. Correct the label.
>
On 28/07/2025 8:52 pm, Stewart Hildebrand wrote:
> In vcpu_create after scheduler data is allocated, if
> vmtrace_alloc_buffer fails, it will jump to the wrong cleanup label
> resulting in a memory leak. Correct the label.
>
> Fixes: 217dd79ee292 ("xen/domain: Add vmtrace_size domain creation param
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Daniel P. Smith
---
tools/flask/policy/modules/modules.conf | 2 +-
tools/flask/policy/modules/vm_role.cons | 4 ++--
tools/flask/policy/policy/mls | 2 +-
tools/flask/policy/policy/support
Having multiple values wrapped onto as few lines as practical is good for
space efficiency, but causes complex collisions for hypercall backports and
local policy changes. Reformat to use one value per line.
No functional change, only whitespace changes.
Signed-off-by: Andrew Cooper
---
CC
Most indentation is with tabs, but a few spaces have slipped in. Switch them
back to tabs.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Daniel P. Smith
---
tools/flask/policy/modules/xen.if | 28 ++--
1 file changed, 14 insertions(+), 14 deletions
Patch 3 intends to make it easier to maintain local changes to the flask
policy in a patchqueue. The prior patches are trivial cleanup.
No functional change. Only whitespace changes.
Andrew Cooper (3):
tools/flask: Strip trailing whitespace
tools/flask: Use tabs uniformly
tools/flask
Switch to the new fields.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 10 +-
xen/arch/x86/cpu/microcode/core.c | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/arch/x86
On 28/07/2025 11:38 am, Nicola Vetrini wrote:
> On 2025-07-28 11:36, Jan Beulich wrote:
>> On 25.07.2025 18:24, Dmytro Prokopchuk1 wrote:
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -142,6 +142,31 @@ Deviations related to MISRA C:2012 Rules:
>>> memmove.
>
On 28/07/2025 10:56 am, Jan Beulich wrote:
> On 27.07.2025 22:27, Dmytro Prokopchuk1 wrote:
>> Explicitly cast 'halt_this_cpu' when passing it
>> to 'smp_call_function' to match the required
>> function pointer type '(void (*)(void *info))'.
>>
>> Document and justify a MISRA C R11.1 deviation
>> (
On 28/07/2025 11:24 am, Marek Marczykowski-Górecki wrote:
> When running xl in a domU, it doesn't have access to the Xen command
> line. Before the non-truncating xc_xenver_cmdline(), it was always set
> with strdup, possibly of an empty string. Now it's NULL. Treat it the
> same as empty cmdline,
On 25/07/2025 4:06 pm, Edwin Török wrote:
> diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
> index 7be79c2d00..713311a1ac 100644
> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -160,6 +160,31 @@ static inline struct vcpu *choose_hwdom_vcpu(void)
> return ha
On 25/07/2025 4:06 pm, Edwin Török wrote:
> Linux already has a similar BUILD_BUG_ON.
> Currently this struct is ~224 bytes on x86-64.
>
> No functional change.
>
> Signed-off-by: Edwin Török
> ---
> xen/arch/x86/cpu/vpmu.c | 1 +
> xen/include/public/pmu.h | 3 +++
> 2 files changed, 4 insertio
, but that's easy enough to keep working as before.
Fixes: 6cdea3444eaf ("xen/arm: add Dom0 cache coloring support")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Carlo Nonat
the bogus const on it, and
remove the cast when freeing it.
No functional change.
Fixes: 6985aa5e0c3c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Ste
the logic to avoid the hypercall in the general case, leaving a
comment explaining why it is performed so early.
Fixes: 748bd725fbec ("tools: add support for cache coloring configuration")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien
: 6985aa5e0c3c ("xen: extend domctl interface for cache coloring")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Carlo Nonato
CC: Marco Solieri
Cache colouring is experimental
Found because XEN_DOMCTL_set_llc_colors failed in XenServer's HostUEFI Secure
Boot environment (which has additional checks on hypercalls). Everything else
came from trying to fix that.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1946483850
Andrew Cooper (4):
xen/cach
s each of these are unsigned quantities. This
can be fixed on commit.
Otherwise, Reviewed-by: Andrew Cooper
> +
> nrspin_unlock(&d->page_alloc_lock);
> }
>
> --
> 2.47.1
ject/people/anthonyper/xen/-/jobs/10785719529
>
> I haven't updated the container yet.
Very nice.
Reviewed-by: Andrew Cooper
That's rather more simple to integrate than I was expecting.
~Andrew
On 23/07/2025 3:21 pm, Jan Beulich wrote:
> On 23.07.2025 16:13, Andrew Cooper wrote:
>> On 23/07/2025 2:56 pm, Yann Sionneau wrote:
>>> xen.efi PE does not boot when loaded from shim or some patched
>>> downstream grub2.
>>>
>>> What happens is th
On 23/07/2025 2:56 pm, Yann Sionneau wrote:
> xen.efi PE does not boot when loaded from shim or some patched
> downstream grub2.
>
> What happens is the bootloader would honour the MEM_DISCARDABLE
> flag of the .reloc section meaning it would not load its content
> into memory.
>
> But Xen is parsi
On 23/07/2025 1:35 pm, Marek Marczykowski-Górecki wrote:
> Hi,
>
> There is yet another issue affecting Framework AMD... When I start a
> domU with XHCI controller attached (PCI passthrough), the whole host
> resets if there was an USB device plugged into it. I don't get any panic
> message (neithe
eld. In turn the struct pointer there can then be
> constified.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 23/07/2025 12:57 pm, Teddy Astie wrote:
> Le 23/07/2025 à 13:16, Andrew Cooper a écrit :
>> On 23/07/2025 10:05 am, Teddy Astie wrote:
>>> do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the indirection
>>> through the hypercall handler and use the functio
an Beulich
> ---
> This patch has been sent first at the security mailing list
> (secur...@xenproject.org)
> which asked me to publish it publicly due to it being actually safe in
> practice.
Having talked to AMD, we believe the algorithm Xen uses (and has done
since it's introduction) happens to be safe for microarchitectural reasons.
Reviewed-by: Andrew Cooper
~Andrew
On 23/07/2025 8:29 am, Jürgen Groß wrote:
> On 23.07.25 09:04, Jan Beulich wrote:
>> On 23.07.2025 08:55, Jürgen Groß wrote:
>>> On 23.07.25 08:43, Jan Beulich wrote:
On 23.07.2025 08:34, Jürgen Groß wrote:
> On 23.07.25 08:28, Jan Beulich wrote:
>> On 22.07.2025 02:19, Jason Andryuk w
Teddy Astie
> ---
> v2:
> - For SCHEDOP_block case: export and use vcpu_block_enable_events instead
You need to adjust the commit message for this change, now that you're
exporting vcpu_block_enable_events().
With that adjusted, Reviewed-by: Andrew Cooper
If there are no othe
On 23/07/2025 11:19 am, Grygorii Strashko wrote:
>
>
> On 23.07.25 12:16, Julien Grall wrote:
>> Hi,
>>
>> On 23/07/2025 08:58, Grygorii Strashko wrote:
>>> From: Grygorii Strashko
>>>
>>> Move vcpu_switch_to_aarch64_mode() in arch_vcpu_create() callback
>>> instead
>>> of calling it manually from
On 23/07/2025 8:58 am, Grygorii Strashko wrote:
> diff --git a/xen/arch/arm/include/asm/arm64/domain.h
> b/xen/arch/arm/include/asm/arm64/domain.h
> index 18402ae3ca0d..a014ab9967ac 100644
> --- a/xen/arch/arm/include/asm/arm64/domain.h
> +++ b/xen/arch/arm/include/asm/arm64/domain.h
> @@ -12,14 +
On 23/07/2025 8:58 am, Grygorii Strashko wrote:
> diff --git a/xen/arch/arm/include/asm/arm32/domain.h
> b/xen/arch/arm/include/asm/arm32/domain.h
> index 4d1251e9c128..c0a7fc35f38b 100644
> --- a/xen/arch/arm/include/asm/arm32/domain.h
> +++ b/xen/arch/arm/include/asm/arm32/domain.h
> @@ -3,6 +3,
On 22/07/2025 1:05 pm, Jason Andryuk wrote:
> On 2025-07-22 14:07, Teddy Astie wrote:
>> do_sched_op(SCHEDOP_yield) just calls vcpu_yield(). Remove the
>> indirection
>> through the hypercall handler and use the function directly.
>>
>> Perform the same for SCHEDOP_block.
>>
>> Not a functional cha
This moves the exception path to being out-of-line within the function, rather
than in the .fixup section, which improves backtraces.
Because the macro is used multiple times, the fault label needs declaring as
local.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC
igned-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/cpu/mwait-idle.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index e837cbf50eb3..f47fdfb
This snapshot is Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
the *_FAM6_ CPU #defines"), now that Xen has switched off the old constant
names.
Leave a comment identifying the exact revision Xen is using.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
Switch to the new fields and constants.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
I've intentionally not converted the tables with raw numbers yet. That's not
a mechanical change, and requires more care.
---
xen/arch/x86/spec_ct
Switch to the new fields and constants.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
This updates one related part in intel.c for ease of ordering subseuqent work.
---
xen/arch/x86/cpu-policy.c | 19 ---
xen/arch/x86/cpu/intel.c
This is a mechanical change to use the VFM constants rather than the
family-specific ones.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1934721940
Andrew Cooper (4):
x86/mwait-idle: Update vendor/family/model logic
x86/cpu-policy: Update vendor/family/model logic
x86
On 18/07/2025 4:12 pm, Alejandro Vallejo wrote:
> Otherwise compile-time errors ensue. It's a nonsensical configuration,
> but it's supriously triggered in randconfig jobs.
>
> Fixes: 8b5b49ceb3d9("x86: don't include domctl and alike in shim-excl...")
> Signed-off-by: Alejandro Vallejo
> ---
> xe
This is the next part of the VFM converstion, focusing on struct x86_cpu_id.
Some parts are already committed. See patches for details vs v1.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1934588566
Andrew Cooper (3):
x86/match-cpu: Improvements to x86_match_cpu()
x86
ical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* New
There is a marginal code generation improvement, because of not needing to
hold as many registers live over the loop termination check.
---
xen/arch/x86/cpu/common.c | 35 +--
change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Move deadline_match[] into check_deadline_errata() which produces a far
more legible diff.
* Check for TSC_DEADLINE early and skip the search on non-capable CPUs.
The bloat-o-meter summary shows that the use
.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Rebase over adjustments to x86_match_cpu().
* Switch name to X86_STEPPING_ANY, and use 0x to remove a conditional
from x86_match_cpu().
Combined with the previous patch, the code gener
On 18/07/2025 3:06 pm, Jan Beulich wrote:
> On 18.07.2025 12:55, Andrew Cooper wrote:
>> On 18/07/2025 11:23 am, Andrew Cooper wrote:
>>> On 18/07/2025 11:19 am, Jan Beulich wrote:
>>>> On 18.07.2025 12:07, Andrew Cooper wrote:
>>>>> With the a
On 18/07/2025 2:28 pm, Jan Beulich wrote:
>> uint16_t model;
> Whereas the model is strictly limited to 8 bits.
There is space in here, if we need it, but you can't shrink it without
breaking the check for the NULL entry (going back to the first
obfuscation).
>>> Breaki
o make the code more coherent.
>
> Signed-off-by: Frediano Ziglio
> ---
> Changes since v1:
> - reuse PrintStr instead of reusing PrintMessage.
> ---
FWIW, Reviewed-by: Andrew Cooper
On 18/07/2025 1:00 pm, Frediano Ziglio wrote:
> On Fri, Jul 18, 2025 at 12:12 PM Andrew Cooper
> wrote:
>> On 18/07/2025 10:41 am, Frediano Ziglio wrote:
>>> PrintMessage function print a message string followed by a
>>> new line.
>>> Move the functio
On 18/07/2025 10:41 am, Frediano Ziglio wrote:
> PrintMessage function print a message string followed by a
> new line.
> Move the function from ARM specific code to common code.
> Reuse it in EFI code.
> No functional changes.
>
> Signed-off-by: Frediano Ziglio
Please no.
Hiding \n (or \r\n) in
On 18/07/2025 11:23 am, Andrew Cooper wrote:
> On 18/07/2025 11:19 am, Jan Beulich wrote:
>> On 18.07.2025 12:07, Andrew Cooper wrote:
>>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>>> helper to match a specific stepping, and use
On 18/07/2025 6:53 am, Jan Beulich wrote:
> On 17.07.2025 21:39, Andrew Cooper wrote:
>> On 17/07/2025 9:11 am, Jan Beulich wrote:
>>> On 16.07.2025 19:31, Andrew Cooper wrote:
>>>> --- a/xen/arch/x86/cpu/common.c
>>>> +++ b/xen/arch/x86/cpu/common.c
On 18/07/2025 11:19 am, Jan Beulich wrote:
> On 18.07.2025 12:07, Andrew Cooper wrote:
>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>> helper to match a specific stepping, and use it to rework deadline_match[].
>>
>> Notably this
missing
ENDBR instructions owing to the lack of the cf_check attribute.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
v2:
* Move deadline_match[] into check_deadline_errata() which produces a far
more legible diff.
The bloat-o-meter summary shows
On 17/07/2025 9:31 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> --- a/xen/arch/x86/apic.c
>> +++ b/xen/arch/x86/apic.c
>> @@ -1051,64 +1051,32 @@ static void setup_APIC_timer(void)
>> local_irq_restore(flags);
>> }
>>
On 17/07/2025 10:33 am, Jan Beulich wrote:
> On 17.07.2025 11:02, Andrew Cooper wrote:
>> On 17/07/2025 9:26 am, Jan Beulich wrote:
>>> On 16.07.2025 19:31, Andrew Cooper wrote:
>>>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>>&g
On 17/07/2025 9:11 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -1003,13 +1003,15 @@ const struct x86_cpu_id *x86_match_cpu(const struct
>> x86_cpu_id table[])
>>
On 17/07/2025 8:44 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> --- a/xen/arch/x86/acpi/cpu_idle.c
>> +++ b/xen/arch/x86/acpi/cpu_idle.c
>> @@ -583,7 +583,6 @@ bool errata_c6_workaround(void)
>>
>> if ( unlikely(fix_need
On 17/07/2025 8:35 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> mwait-idle's ICPU() is the most convenient place to get started. Introduce
>> X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
>>
>> This involves ma
On 17/07/2025 8:23 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> Only 5 files use struct x86_cpu_id, so it should not be in processor.h. This
>> is in preparation to extend it with VFM support.
>>
>> No functional change.
>>
>> Sign
NEHALEM_EX is affected by the erratum too.
Change the comment to be the full text, rather than interpretation of it.
Fixes: 95807bcae47e ("C6 state with EOI issue fix for some Intel processors")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Pulled out of t
On 17/07/2025 9:26 am, Jan Beulich wrote:
> On 16.07.2025 19:31, Andrew Cooper wrote:
>> With the ability to match on steppings, introduce a new X86_MATCH_VFMS()
>> helper to match a specific stepping, and use it to rework deadline_match[].
> I'm fine with the patch in prin
missing
ENDBR instructions owing to the lack of the cf_check attribute.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
The bloat-o-meter summary shows that the use of functions really wasn't the
wisest idea:
add/remove: 0/3 grow/shrink: 1/2 up
mwait-idle's ICPU() is the most convenient place to get started. Introduce
X86_MATCH_CPU() and X86_MATCH_VFM() following their Linux counterparts.
This involves match-cpu.h including more headers, which in turn allows us to
drop a few.
No functional change.
Signed-off-by: Andrew Cooper
-
Only 5 files use struct x86_cpu_id, so it should not be in processor.h. This
is in preparation to extend it with VFM support.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/acpi/cpu_idle.c | 2 +-
xen/arch/x86/apic.c
This is the next part of the VFM converstion, focusing on struct x86_cpu_id.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1930706122
Andrew Cooper (6):
x86: Sort headers
x86: Break struct x86_cpu_id out of processor.h
x86/match-cpu: Introduce X86_MATCH_VFM() and convert
In intel.c, drop asm/mwait.h and asm/uaccess.h, neither of which are used.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/acpi/cpu_idle.c | 3 ++-
xen/arch/x86/apic.c | 25 -
xen/arch/x86/cpu
Architecturally, stepping is a 4-bit field, so a uint16_t suffices for a
bitmap of steppings.
In order to keep the size of struct x86_cpu_id the same, shrink the vendor and
family fields, neither of which need to be uint16_t in Xen.
No functional change.
Signed-off-by: Andrew Cooper
---
CC
This replaces raw model numbers (and comments in some cases) with names. For
probe_mwait_errata(), merge the comments with the table to make it easier to
see which erratum is which, and drop a stray "Problem" in LNL030.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan B
On 16/07/2025 2:56 pm, Jan Beulich wrote:
> On 16.07.2025 15:28, Andrew Cooper wrote:
>> This snapshot is prior to Linux commit db4001f9cc32 ("x86/cpu/vfm: Delete all
>> the *_FAM6_ CPU #defines") at the end of their conversion phase.
>>
>> In addition to non-
On 16/07/2025 2:47 pm, Jan Beulich wrote:
> On 16.07.2025 15:28, Andrew Cooper wrote:
>> Intel have run out of model space in Family 6 and will start using Family 19
>> starting with Diamond Rapids. Xen, like Linux, has model checking logic
>> which
>> will malfuncti
;m not sure of the value of keeping the "So far unknown" comment.
Also, can we please switch to Xen style as we're doing elsewhere in
these not-really-Linux-any-more files.
With that, Acked-by: Andrew Cooper
On 12/02/2024 12:53 pm, Jan Beulich wrote:
> Move logic independent of c->apicid's initialization status out of
> the if/else, leveraging that cpu_data[] now doesn't start out zero-
> initialized. Constify c and have it have an initializer.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 16/07/2025 2:28 pm, Andrew Cooper wrote:
> diff --git a/xen/arch/x86/include/asm/cpufeature.h
> b/xen/arch/x86/include/asm/cpufeature.h
> index ba2c1c1c7416..f8b85c0f9520 100644
> --- a/xen/arch/x86/include/asm/cpufeature.h
> +++ b/xen/arch/x86/include/asm/cpufeature.h
&
This form is shorer and more legible.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
As this is the first transformation, an anlysis of the code generation change:
before:
:
8b 05 4a 7e 09 00mov0x97e4a(%rip),%eax
ly deleted
in the past.
In cpufeature.h, provide VFM_* macros to transform constants to/from the
cpuinfo_x86 representation.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
I meant to object to deleting PHI at the time, but was too late. Just becau
ingle
constant, so it is harder to mismatch family and model checks.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/1930124712
Andrew Cooper (3):
x86: Rearrange struct cpuinfo_x86 to introduce a vfm field
x86/intel-family: Resync with Linux
x86/vtd: Switch model check to VFM
xen
together
as a single vfm field.
As we're cleaning up the logic, take the opportunity to introduce better
names, dropping the x86 prefix.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/include/asm/cpufeature.h
In udelay(), use cpu_relax() directly which, for better or worse, is the
common way to refer to the PAUSE instruction.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/delay.c | 2 +-
xen/arch/x86/include/asm
it was perhaps nice, but yielded guest-observable
> inconsistencies.)
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
This is one of the more messy parts of x86, and that's saying something.
> ---
> v2: Use emulate_2op_SrcV_srcmem() also for {L,T}ZCNT.
>
> --- a/xen/arch/
Ack. Sorry for forgetting this
On Wed, 9 Jul 2025, 10:44 Jan Beulich, wrote:
> While the change is fine on staging, where the toolchain baseline was
> moved, we need to remain compatible with older gas on stable branches
> for now.
>
> Fixes: fa254938f00a ("x86/idle: Move monitor()/mwait() wrap
ort
> 4: Add Meteorlake support
> 5: add Grand Ridge SoC support
> 6: add Sierra Forest SoC support
> 7: add Granite Rapids Xeon support
> 8: add Granite Rapids Xeon D support
> 9: add Clearwater Forest SoC support
Acked-by: Andrew Cooper
1 - 100 of 7338 matches
Mail list logo
