On 25.02.2025 23:45, Andrew Cooper wrote:
> A CALL with 0 displacement is handled specially, and is why this logic
> functions even with CET Shadow Stacks active. Nevertheless a rip-relative LEA
> is the more normal way of doing this in 64bit code.
>
> The retrieval of flags modifies the stack po
On 26.02.2025 00:02, Andrew Cooper wrote:
> The final hunk is `(struct vcpu *)v` in disguise, expressed using a runtime
> pointer chase through memory and a technicality of the C type system to work
> around the fact that get_hvm_registers() strictly requires a mutable pointer.
>
> For anyone inte
On 25.02.2025 23:32, Andrew Cooper wrote:
> They are out of place in traps.c, and only have a single caller each. Make
> them static inside msr.c.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 25.02.2025 23:31, Andrew Cooper wrote:
> It's out of place in traps.c, and only has a single caller. Make it static
> inside cpuid.c.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 26.02.2025 04:27, Shawn Anastasio wrote:
> From: Andrew Cooper
>
> Also enable -fno-sanitize=alignment like x86 since support for unaligned
> accesses is guaranteed by the ISA and the existing OPAL setup code
> relies on it.
>
> Signed-off-by: Andrew Cooper
> Signed-off-by: Shawn Anastasio
On 25.02.2025 23:01, Andrew Cooper wrote:
> On 28/10/2024 1:18 pm, Jan Beulich wrote:
>> On 24.10.2024 15:22, Andrew Cooper wrote:
>>> This was true in the K10 days, but even back then the match registers were
>>> really payload data rather than header data.
>>>
>>> But, it's really model specific
On Wed, Feb 26, 2025 at 4:46 AM Petr Beneš wrote:
>
> This is just a wild guess and it might be wrong. But clearly,
> something weird is happening around IPI during the xl save process
> that Windows doesn't like.
>
After carefully examining the crashdumps I have finally found the issue.
I looked
On Wed, Feb 26, 2025 at 4:23 AM Petr Beneš wrote:
> I finally managed to capture a few non-corrupted crashdumps.
> The cause of crash always points to the same symbol:
> nt!KiIpiProcessRequests+0x193
It appears that the Windows likes to manage its own IPI - i.e.
KiIpiSendRequest stores the reques
Extend Andrew's UBSAN enablement work to ppc.
Changes in v2:
- Drop opal.c unaligned access patch
- Enable -fno-sanitize=alignment like x86 does
Andrew Cooper (1):
PPC: Activate UBSAN in testing
automation/gitlab-ci/build.yaml | 3 +++
xen/arch/ppc/Kconfig | 1 +
xen/
From: Andrew Cooper
Also enable -fno-sanitize=alignment like x86 since support for unaligned
accesses is guaranteed by the ISA and the existing OPAL setup code
relies on it.
Signed-off-by: Andrew Cooper
Signed-off-by: Shawn Anastasio
---
Changes in v2:
- Add -fno-sanitize=alignment flag per
On Wed, Feb 26, 2025 at 3:29 AM Petr Beneš wrote:
>
> and frustratingly, the generated MEMORY.DMP is corrupted.
>
I finally managed to capture a few non-corrupted crashdumps.
The cause of crash always points to the same symbol:
nt!KiIpiProcessRequests+0x193
Crashdump#1
00 f802`0867ad90 :
On 2/21/25 2:15 PM, Andrew Cooper wrote:
> Sorry, the other thing to say is that if PPC is generally fine with
> unaligned accesses, then you might want to follow what x86 does.
>
> We use -fno-sanitize=alignment generally, because there's a whole pile
> of things which are misaigned and spec'd th
On Wed, Feb 26, 2025 at 1:50 AM Marek Marczykowski-Górecki
wrote:
>
> This is domain crash.
> Anything interesting on the console log of that domain (if it has some
> debug logs there...), or maybe in xl dmesg?
>
> --
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
I figured.
There are few places which check pv_shim console under CONFIG_PV_SHIM or
CONFIG_X86 in xen console driver.
Instead of inconsistent #ifdef-ing, introduce and use consoled_is_enabled() in
switch_serial_input() and __serial_rx().
PV shim case is fixed in __serial_rx() - should be under 'pv_shim &&
p
On Tue, Feb 25, 2025 at 11:59:38PM +0100, Petr Beneš wrote:
> On Thu, Feb 20, 2025 at 9:14 AM Jan Beulich wrote:
> >
> > Just one thing - to (hopefully) get a better understanding of the origin of
> > those errors, you may want to increase verbosity of the "xl save", e.g.
> > "xl -vvv save".
> >
>
The final hunk is `(struct vcpu *)v` in disguise, expressed using a runtime
pointer chase through memory and a technicality of the C type system to work
around the fact that get_hvm_registers() strictly requires a mutable pointer.
For anyone interested, this is one reason why C cannot optimise any
On Thu, Feb 20, 2025 at 9:14 AM Jan Beulich wrote:
>
> Just one thing - to (hopefully) get a better understanding of the origin of
> those errors, you may want to increase verbosity of the "xl save", e.g.
> "xl -vvv save".
>
> Jan
Here's an output of this command, that failed:
xl -vvv save win10-
A CALL with 0 displacement is handled specially, and is why this logic
functions even with CET Shadow Stacks active. Nevertheless a rip-relative LEA
is the more normal way of doing this in 64bit code.
The retrieval of flags modifies the stack pointer so needs to state a
dependency on the stack po
Hi Andrew,
On 25/02/2025 22:20, Andrew Cooper wrote:
There are currently two users, and lib.h is included everywhere.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Julien Grall
Cheers,
--
Julien Grall
They are out of place in traps.c, and only have a single caller each. Make
them static inside msr.c.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/include/asm/processor.h | 3 --
xen/arch/x86/msr.c | 73
It's out of place in traps.c, and only has a single caller. Make it static
inside cpuid.c.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/cpuid.c | 136 +++
xen/arch/x86/include/asm/processor
parse_ucode() is abnormal compared to similar parsing elsewhere in Xen.
Invert the ucode_mod_forced check with respect to the "scan" and integer
handling, so we can warn the user when we've elected to ignore the parameters,
and yield -EINVAL for any unrecognised list element.
Rewrite the ucode= c
Yet more fixes from the overhaul. This fixes cmdline parsing, rewrites the
cmdline docs for clarity, then drops a cmdline option which is of dubious
value.
No practical change.
Andrew Cooper (2):
x86/ucode: Adjust parse_ucode() to match other list handling
x86/ucode: Drop the ucode=nmi optio
This option is active by default, and despite what the documentation suggests
about choosing ucode=no-nmi, it only controls whether the primary threads move
into NMI context.
Sibling threads unconditionally move into NMI context, which is confirmed by
an in-code comment.
Not discussed is the fact
Hi Luca,
On 06/02/2025 15:01, Luca Fancellu wrote:
Hi Ayan,
On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
For AArch32, refer to ARM DDI 0568A.c ID110520.
MPU_REGION_SHIFT is same between AArch32 and AArch64 (HPRBAR).
Also, NUM_MPU_REGIONS_SHIFT is same between AArch32 and AArch64
(HMPUIR
There are currently two users, and lib.h is included everywhere.
No functional change.
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: Volodymyr Babchuk
CC: Bertrand Marquis
This will ma
On 28/10/2024 1:18 pm, Jan Beulich wrote:
> On 24.10.2024 15:22, Andrew Cooper wrote:
>> This was true in the K10 days, but even back then the match registers were
>> really payload data rather than header data.
>>
>> But, it's really model specific data, and these days typically part of the
>> sig
On Tue, Feb 25, 2025 at 02:03:53PM +, Frediano Ziglio wrote:
> On XenServer on Windows machine a platform device with ID 2 instead of
> 1 is used.
> This device is mainly identical to device 1 but due to some Windows
> update behaviour it was decided to use a device with a different ID.
> This
Hello, Jan!
On 24.02.25 12:55, Jan Beulich wrote:
On 23.02.2025 08:42, Oleksandr Andrushchenko wrote:
On 20.02.25 03:34, Stefano Stabellini wrote:
On Wed, 19 Feb 2025, Oleksandr Andrushchenko wrote:
Yes, I do agree. But only if we talk about having an automated
code style check now (which is
On 25.02.2025 16:40, Andrew Cooper wrote:
> On 25/02/2025 9:07 am, Jan Beulich wrote:
>> On 24.02.2025 17:05, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -819,6 +819,7 @@ void load_system_tables(void)
>>> * support using ARRAY_SIZE agains
On 25.02.2025 17:20, Andrew Cooper wrote:
> On 25/02/2025 2:33 pm, Jan Beulich wrote:
>> On 25.02.2025 13:54, Andrew Cooper wrote:
>>> On 25/02/2025 9:00 am, Jan Beulich wrote:
On 24.02.2025 17:05, Andrew Cooper wrote:
> Having variables named idt_table[] and idt_tables[] is not ideal.
>>>
Hi,
On 06/02/2025 14:48, Luca Fancellu wrote:
On 4 Feb 2025, at 19:23, Ayan Kumar Halder wrote:
All the EL2 MMU specific registers in head.S are enclosed within CONFIG_MMU.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/arm32/head.S | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen
On 25/02/2025 2:33 pm, Jan Beulich wrote:
> On 25.02.2025 13:54, Andrew Cooper wrote:
>> On 25/02/2025 9:00 am, Jan Beulich wrote:
>>> On 24.02.2025 17:05, Andrew Cooper wrote:
Having variables named idt_table[] and idt_tables[] is not ideal.
Use X86_IDT_VECTORS and remove IDT_ENTRIE
Hi Ayan,
On 04/02/2025 19:23, Ayan Kumar Halder wrote:
Similar to "xen/arm: mpu: Define Xen start address for MPU systems", added
Can you provide the commit ID? Also, we tend to use present for
describing changes, so s/added/add/
a build assertion to ensure that the page size is 4KB.
Sign
On 25/02/2025 3:00 pm, Jan Beulich wrote:
> There's no need to access the static array twice per iteration, even
> more so when that's effectively open-coding array_access_nospec().
> Along with renaming the "new type" variable, rename the "old type" one
> as well, to clarify which one is which.
>
On 25/02/2025 9:07 am, Jan Beulich wrote:
> On 24.02.2025 17:05, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -819,6 +819,7 @@ void load_system_tables(void)
>> * support using ARRAY_SIZE against per-cpu variables.
>> */
>> struct
There's no need to access the static array twice per iteration, even
more so when that's effectively open-coding array_access_nospec().
Along with renaming the "new type" variable, rename the "old type" one
as well, to clarify which one is which.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm
Entities building domains are expected to deal with higher order
allocation attempts (for populating a new domain) failing. If we set
aside a reservation for DMA, try to avoid taking higher order pages from
that reserve pool. Instead favor order-0 ones which often can still be
supplied from higher
On 25.02.2025 13:54, Andrew Cooper wrote:
> On 25/02/2025 9:00 am, Jan Beulich wrote:
>> On 24.02.2025 17:05, Andrew Cooper wrote:
>>> Having variables named idt_table[] and idt_tables[] is not ideal.
>>>
>>> Use X86_IDT_VECTORS and remove IDT_ENTRIES. State the size of bsp_idt[] in
>>> idt.h so t
On XenServer on Windows machine a platform device with ID 2 instead of
1 is used.
This device is mainly identical to device 1 but due to some Windows
update behaviour it was decided to use a device with a different ID.
This causes compatibility issues with Linux which expects, if Xen
is detected, t
Hi,
On 25/02/2025 11:10, Jan Beulich wrote:
On 25.02.2025 12:08, Jan Beulich wrote:
On 25.02.2025 12:05, Mykyta Poturai wrote:
On 10.02.25 12:46, Jan Beulich wrote:
On 10.02.2025 11:30, Mykyta Poturai wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -238,6 +238,14 @@ int
Hi,
On 21/02/2025 11:19, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 11:53 schrieb Tomi Valkeinen:
Hi,
On 20/02/2025 12:05, Thomas Zimmermann wrote:
Hi
Am 20.02.25 um 10:18 schrieb Tomi Valkeinen:
[...]
+ * Color modes of 10, 12, 15, 30 and 64 are only supported for use by
+ * legacy user s
On 25/02/2025 9:00 am, Jan Beulich wrote:
> On 24.02.2025 17:05, Andrew Cooper wrote:
>> Having variables named idt_table[] and idt_tables[] is not ideal.
>>
>> Use X86_IDT_VECTORS and remove IDT_ENTRIES. State the size of bsp_idt[] in
>> idt.h so that load_system_tables() and cpu_smpboot_alloc()
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) execution contro
... to fields in the capability/controls struct: Take the opportunity
and split the two halves into separate EPT and VPID fields.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v3: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v3: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) exe
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) exe
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) exe
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) exe
... to a field in the capability/controls struct.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -162,7 +162,6 @@ static int cf_check parse_ept_param_runt
/* Dynamic (run-time adjusted) exe
... to a field in the capability/controls struct. Use an instance of
that struct also in vmx_init_vmcs_config().
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v4: Re-base.
v3: Add initializer to vmx_init_vmcs_config() new local var.
v2: New.
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xe
... to a struct field, which is then going to be accompanied by other
capability/control data presently living in individual variables. As
this structure isn't supposed to be altered post-boot, put it in
.data.ro_after_init right away.
Suggested-by: Roger Pau Monné
Signed-off-by: Jan Beulich
Ack
It's effectively redundant with vmx_basic_msr. For the #define
replacement to work, struct vmcs_struct's respective field name also
needs to change: Drop the not really meaningful "vmcs_" prefix from it.
Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
---
v2: New.
--- a/xen/arch/x86/hvm/vm
__init{const,data}_cf_clobber can have an effect only for pointers
actually populated in the respective tables. While not the case for SVM
right now, VMX installs a number of pointers only under certain
conditions. Hence the respective functions would have their ENDBR purged
only when those conditi
01: x86/HVM: improve CET-IBT pruning of ENDBR
02: VMX: drop vmcs_revision_id
03: VMX: convert vmx_basic_msr
04: VMX: convert vmx_pin_based_exec_control
05: VMX: convert vmx_cpu_based_exec_control
06: VMX: convert vmx_secondary_exec_control
07: VMX: convert vmx_tertiary_exec_control
08: VMX: convert
Ping? Especially ...
On 04.02.25 12:33, Juergen Gross wrote:
Xenstored is using libxenctrl for only one purpose: to get information
about state of domains.
This patch series is removing that dependency by introducing a new
stable interface which can be used by xenstored instead.
There was a RF
On 25.02.2025 12:08, Jan Beulich wrote:
> On 25.02.2025 12:05, Mykyta Poturai wrote:
>> On 10.02.25 12:46, Jan Beulich wrote:
>>> On 10.02.2025 11:30, Mykyta Poturai wrote:
--- a/xen/include/xen/iommu.h
+++ b/xen/include/xen/iommu.h
@@ -238,6 +238,14 @@ int iommu_do_dt_domctl(struct
On 25.02.2025 12:05, Mykyta Poturai wrote:
> On 10.02.25 12:46, Jan Beulich wrote:
>> On 10.02.2025 11:30, Mykyta Poturai wrote:
>>> --- a/xen/include/xen/iommu.h
>>> +++ b/xen/include/xen/iommu.h
>>> @@ -238,6 +238,14 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl,
>>> struct domain *d,
>>>
On 10.02.25 12:46, Jan Beulich wrote:
> On 10.02.2025 11:30, Mykyta Poturai wrote:
>> --- a/xen/include/xen/iommu.h
>> +++ b/xen/include/xen/iommu.h
>> @@ -238,6 +238,14 @@ int iommu_do_dt_domctl(struct xen_domctl *domctl,
>> struct domain *d,
>>*/
>> int iommu_remove_dt_device(struct dt_dev
On 25/02/2025 8:15 am, Roger Pau Monné wrote:
> On Mon, Feb 24, 2025 at 03:42:36PM +, Andrew Cooper wrote:
>> This reduces the Clone step from ~50s to ~3s.
>>
>> Signed-off-by: Andrew Cooper
> Nice, didn't know that existed.
>
> Acked-by: Roger Pau Monné
Thanks. I found it by chance while t
Rule 8.2 states: "Function types shall be in prototype form with
named parameters".
The parameter name is missing from the function pointer type
that constitutes the first parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
Reviewed-by: Juergen Gross
Rule 7.2 states: "A u or U suffix shall be applied to all integer
constants that are represented in an unsigned type".
Some PM_* constants are unsigned quantities, despite some
of them being representable in a signed type, so a 'U' suffix
should be present.
No functional change.
Signed-off-by: N
The Xen configurations for the ARM64 and X86_64 ECLAIR analyses
is currently held in fixed files under
'automation/eclair_analysis/xen_{arm,x86}_config'. The values
of the configuration options there are susceptible to going stale
due to configuration option changes.
To enhance maintainability, th
The initial configuration for the ECLAIR MISRA C analysis integration into Xen
consisted of two fixed configuration files (one for arm64 and one for x86_64).
This approach shows its downsides as configuration options may change over time.
To address this issues, the configuration can be derived fr
On 2/25/25 8:59 AM, Jan Beulich wrote:
On 20.02.2025 18:44, Oleksii Kurochko wrote:
When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1),
it indicates that a mapping is being destroyed/modifyed.
In the case when modifying or destroying a mapping, it is necessary to
search
On 2/25/25 8:13 AM, Jan Beulich wrote:
On 24.02.2025 19:25, Oleksii Kurochko wrote:
@@ -25,6 +30,8 @@ The format is based on [Keep a
Changelog](https://keepachangelog.com/en/1.0.0/)
interrupts instead of logical destination mode.
### Added
+ - Support device passthrough when dom0
On 24.02.2025 17:05, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -819,6 +819,7 @@ void load_system_tables(void)
>* support using ARRAY_SIZE against per-cpu variables.
>*/
> struct tss_page *tss_page = &this_cpu(tss_page);
> +
On 24.02.2025 17:05, Andrew Cooper wrote:
> Having variables named idt_table[] and idt_tables[] is not ideal.
>
> Use X86_IDT_VECTORS and remove IDT_ENTRIES. State the size of bsp_idt[] in
> idt.h so that load_system_tables() and cpu_smpboot_alloc() can use sizeof()
> rather than opencoding the c
On 24.02.2025 17:05, Andrew Cooper wrote:
> Observant readers may have noticed that the FRED spec has another 8 bits of
> space reserved immediately following the vector field.
>
> Make the existing constant more precise.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
I don't mind
On 24.02.2025 17:05, Andrew Cooper wrote:
> Logic concerning the IDT is somewhat different to the other system tables, and
> in particular ought not to be in asm/processor.h. Collect it together a new
> header.
>
> While doing so, make a few minor adjustments:
>
> * Make set_ist() use volatile
On Mon, Feb 24, 2025 at 03:42:36PM +, Andrew Cooper wrote:
> This reduces the Clone step from ~50s to ~3s.
>
> Signed-off-by: Andrew Cooper
Nice, didn't know that existed.
Acked-by: Roger Pau Monné
Thanks, Roger.
On 23.02.2025 00:58, dm...@proton.me wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -46,6 +46,7 @@
>
> #ifdef CONFIG_X86
> #include
> +#include
> #endif
This change isn't needed. It's the purpose of asm/guest.h to
include, among other headers, asm/pv/shim.h.
> @@ -562,
On 20.02.2025 18:44, Oleksii Kurochko wrote:
> When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1),
> it indicates that a mapping is being destroyed/modifyed.
>
> In the case when modifying or destroying a mapping, it is necessary to
> search until a leaf node is found, inste
73 matches
Mail list logo
