On Mon, 31 Mar 2025, Jan Beulich wrote:
> On 28.03.2025 00:34, Stefano Stabellini wrote:
> > --- a/xen/common/bitmap.c
> > +++ b/xen/common/bitmap.c
> > @@ -52,7 +52,7 @@ static void clamp_last_byte(uint8_t *bp, unsigned int
> > nbits)
> > unsigned int remainder = nbits % 8;
> >
> >
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, April 1, 2025 2:38 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Anthony PERARD ;
> Orzel, Michal ; Julien Grall ; Roger
> Pau Monné ; Stefano Stabellini ;
> xen-devel@lists.xenproject.org
> Subject: Re: [PAT
On Mon, Mar 31, 2025 at 09:34:24PM +, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Use %pd in all logs issued from arch_domain_create().
>
> Also, expand error message in arch_domain_create() under
> !emulation_flags_ok() case to help debugging.
>
> Signed-off-by: Denis Mukhin
> ---
> T
Adding Q suffixes to FXSAVE/FXRSTOR did break the 32-bit build. Don't go
back though, as the hand-coded 0x48 there weren't quite right either for
the 32-bit case (they might well cause confusion when looking at the
disassembly). Instead arrange for the compiler to DCE respective asm()-s,
by short-c
On 01.04.2025 03:17, Volodymyr Babchuk wrote:
> Changes in v3:
> - Correct code style ("do {")
> - Add comment describing why we need do { } while loop.
>I prefer to leave do {} while because Nicola Vetrini
>said that this approach might help with MISRA Rule 9.1
>without needing an ex
On 31/03/2025 9:22 am, Xin Li (Intel) wrote:
> __wrmsr() is the lowest level primitive MSR write API, and its direct
> use is NOT preferred. Use its wrapper function native_wrmsrl() instead.
>
> No functional change intended.
>
> Signed-off-by: Xin Li (Intel)
The critical piece of information yo
Hi,
I'm finding it necessary to expose a domain's domid and capabilities to
the domain itself.
On x86, SIF_privileged and SIF_hardware allow a domain to know its
privileges through start_info. ARM does not have start_info, and
xenstore domain status is not exposed.
Xen sets XENFEAT_dom0 f
This is Intel i7-7567U in NUC 7i7BNH. This one is an older one, with no
firmware updates (last update from 2023) and no microcode udpates
either. While this firmware supports UEFI, network boot works only in
legacy mode - thus legacy is used here (via iPXE, instead of grub2.efi).
Testing legacy boo
Hardware runners that use legacy boot use iPXE instead of grub2. Create
boot.ipxe for those too - with exact same options.
Signed-off-by: Marek Marczykowski-Górecki
---
Right now this applies to KBL (hw3) runner. And not many more, as newer
systems support UEFI network boot.
---
automation/scrip
On March 31, 2025 2:45:43 PM PDT, Andrew Cooper
wrote:
>On 31/03/2025 9:22 am, Xin Li (Intel) wrote:
>> __wrmsr() is the lowest level primitive MSR write API, and its direct
>> use is NOT preferred. Use its wrapper function native_wrmsrl() instead.
>>
>> No functional change intended.
>>
>> Sign
From: Denis Mukhin
Move domain ID allocation during domain creation to a dedicated
function domid_alloc().
Allocation algorithm:
- If an explicit domain ID is provided, verify its availability and
use it if ID is unused;
- Otherwise, perform an exhaustive search for the first available ID
wi
From: Denis Mukhin
Add new flag in domain structure for marking permission to intercept
the physical console input by the domain.
Update console input switch logic accordingly.
Signed-off-by: Denis Mukhin
---
Changes since v1:
- dropped change in __serial_rx()
---
xen/arch/arm/vpl011.c |
From: Denis Mukhin
Update the symbol name in preparation for the semantic change
to the physical console input owner domain identifier.
No functional change.
Signed-off-by: Denis Mukhin
---
Changes since v1:
- keep the original console_focus description
---
xen/drivers/char/console.c | 16 +++
On 3/31/25 13:41, Andrew Cooper wrote:
That is replace the MSR write to disable speculative execution with a
non-serialized WRMSR? Doesn't that mean the WRMSRNS is speculative?
MSR_SPEC_CTRL is explicitly non-serialising, even with a plain WRMSR.
non-serialising != non-speculative.
Although
The little endian implementation of bitmap_to_xenctl_bitmap leads to
unnecessary xmallocs and xfrees. Given that Xen only supports little
endian architectures, it is worth optimizing.
This patch removes the need for the xmalloc on little endian
architectures.
Remove clamp_last_byte as it is only
On Mon, 31 Mar 2025, Stefano Stabellini wrote:
> On Mon, 31 Mar 2025, Jan Beulich wrote:
> > On 28.03.2025 00:34, Stefano Stabellini wrote:
> > > --- a/xen/common/bitmap.c
> > > +++ b/xen/common/bitmap.c
> > > @@ -52,7 +52,7 @@ static void clamp_last_byte(uint8_t *bp, unsigned int
> > > nbits)
> >
On 3/31/2025 1:32 PM, H. Peter Anvin wrote:
On March 31, 2025 3:17:30 AM PDT, Ingo Molnar wrote:
* Xin Li (Intel) wrote:
- __wrmsr (MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3, val >> 32);
+ native_wrmsrl(MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3);
This is an improvement.
-
Putting a few bytes ahead of page tables isn't very efficient; there's
a gap almost worth a full page. To avoid re-ordering of items in the
source file, simply put the few small items in sub-section 1, for them
to end up after the page tables, followed (in the final binary) by non-
page-aligned ite
On Mon, Mar 31, 2025 at 01:22:46AM -0700, Xin Li (Intel) wrote:
> Signed-off-by: Xin Li (Intel)
> ---
> arch/x86/include/asm/msr-index.h | 6 ++
> arch/x86/kvm/vmx/vmenter.S | 28
> 2 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x8
To allocate the xenstore event channel and initialize the grant table
entry, the xenstore domid is neeed. A dom0 is created before the domUs,
so it is normally available through hardware_domain. With capabilities
and dom0less, the xenstore domain may not be created first.
Keep the population of
The hardware domain is unable to seed a control domain, but we want the
control domain to use xenstore. Rely on the hypervisor to seed dom0less
grant table entries for Xenstore, so this seeding is unnecessary.
However, that only works for the new xenstore late init. The legacy
protocol which use
Add capabilities property to dom0less to allow building a
disaggregated system. Only a single hardware domain and single xenstore
domain can be specified. Multiple control domains are possible.
Introduce bootfdt.h to contain these constants.
When using the hardware or xenstore capabilities, adj
xenstored maps other domains' xenstore pages. Currently this relies on
init-dom0less or xl to seed the grants from Dom0. With split
hardware/control/xenstore domains, this is problematic since we don't
want the hardware domain to be able to map other domains' resources
without their permission.
From: "Daniel P. Smith"
Add and use a new internal create domain flag to specify the hardware
domain. This removes the hardcoding of domid 0 as the hardware domain.
This allows more flexibility with domain creation.
Signed-off-by: Daniel P. Smith
Signed-off-by: Jason Andryuk
---
v2:
() aroun
This series implements separation of dom0 into separate hardware and
control domains. It uses the capabilities idea from Hyperlaunch -
hardware, control, and xenstore. It's been tested with dom1 as
control, dom2 as a domU, and dom3 as hardware and xenstore.
To keep things more managable, this v
On March 31, 2025 1:27:23 PM PDT, Konrad Rzeszutek Wilk
wrote:
>On Mon, Mar 31, 2025 at 01:22:46AM -0700, Xin Li (Intel) wrote:
>> Signed-off-by: Xin Li (Intel)
>> ---
>> arch/x86/include/asm/msr-index.h | 6 ++
>> arch/x86/kvm/vmx/vmenter.S | 28
>> 2 fi
On Monday, March 24th, 2025 at 4:32 PM, Stefano Stabellini
wrote:
>
>
> On Mon, 24 Mar 2025, Denis Mukhin wrote:
>
> > On Monday, March 24th, 2025 at 6:51 AM, Andrew Cooper
> > andrew.coop...@citrix.com wrote:
> >
> > > On 20/03/2025 11:05 pm, dm...@proton.me wrote:
> > >
> > > > Add new m
From: Denis Mukhin
Introduce XEN_X86_EMU_BASELINE and XEN_X86_EMU_OPTIONAL to simplify
d->arch.emulation_flags management in the code.
Signed-off-by: Denis Mukhin
---
tools/python/xen/lowlevel/xc/xc.c | 4 +---
xen/include/public/arch-x86/xen.h | 7 +++
2 files changed, 8 insertions(+), 3
From: Denis Mukhin
Define per-architecture emulation_flags for configuring in-hypervisor
emulators.
Print d->arch.emulation_flags from 'q' keyhandler for better traceability
while debugging in-hypervisor hardware emulators.
Simplify the x86's emulation_flags description and make it consistent
w
From: Denis Mukhin
Rewrite emulation_flags_ok() using XEN_X86_EMU_{OPTIONAL,BASELINE}
to simplify future modifications.
Signed-off-by: Denis Mukhin
---
Came in the context of NS16550 emulator v3 series:
https://lore.kernel.org/xen-devel/20250103-vuart-ns8250-v3-v1-0-c5d36b31d...@ford.com/
A
Condition coverage, also known as MC/DC (modified condition/decision
coverage) is a coverage metric that tracks separate outcomes in
boolean expressions.
This patch adds CONFIG_CONDITION_COVERAGE option to enable MC/DC for
GCC. Clang is not supported right now.
Signed-off-by: Volodymyr Babchuk
This series enables MC/DC for Xen when building with GCC.
Condition coverage, also known as MC/DC (modified condition/decision
coverage) is a coverage metric that tracks separate outcomes in
boolean expressions. This metric is used in critical software
components, so it natural to collect it for X
While building xen with GCC 14.2.1 with "-fcondition-coverage" option,
the compiler produces a false positive warning:
arch/x86/irq.c: In function ‘create_irq’:
arch/x86/irq.c:281:11: error: ‘desc’ may be used uninitialized
[-Werror=maybe-uninitialized]
281 | ret = init_one_irq_desc(d
gcc 14 (with patch "Add condition coverage (MC/DC)") introduced 9th
gcov counter. Also this version can call new merge function
__gcov_merge_ior(), so we need a new stub for it.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Jan Beulich
---
Changes in v3:
- Added Jan's R-b tag
Changes is v2:
From: Denis Mukhin
Update the name to emphasize the physical console input switch to a
new owner domain following the naming notation in the console driver.
No functional change.
Signed-off-by: Denis Mukhin
---
Changes since v1:
- rename console_switch_focus() to console_switch_input()
---
xe
Hi Jan,
On 31/03/2025 17:14, Jan Beulich wrote:
On 31.03.2025 17:20, Oleksii Kurochko wrote:
A randconfig job failed with the following issue:
riscv64-linux-gnu-ld: Xen too large for early-boot assumptions
The reason is that enabling the UBSAN config increased the size of
the Xen binary.
I
On 30.03.2025 11:29, Julien Grall wrote:
> On 27/03/2025 23:34, Stefano Stabellini wrote:
>> The little endian implementation of bitmap_to_xenctl_bitmap leads to
>> unnecessary xmallocs and xfrees. Given that Xen only supports little
>> endian architectures, it is worth optimizing.
>>
>> This patch
On 28.03.2025 19:39, Julien Grall wrote:
> Hi Jan,
>
> On 13/03/2025 08:07, Jan Beulich wrote:
>> Locally override SYM_PUSH_SECTION() to retain the intended section
>> association.
>>
>> Signed-off-by: Jan Beulich
>> Tested-by: Luca Fancellu # arm
>> ---
>> v7: New.
>>
>> --- a/xen/arch/arm/arm3
* Xin Li (Intel) wrote:
> - __wrmsr (MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3, val >> 32);
> + native_wrmsrl(MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3);
This is an improvement.
> - __wrmsr (MSR_IA32_PQR_ASSOC, rmid_p, plr->closid);
> + native_wrmsrl(MSR_IA32_PQR_ASSOC, (u64
On 28.03.2025 18:36, Andrew Cooper wrote:
> In a 64bit-clean environment, blowfish fails:
>
> make[6]: Leaving directory
> '/builddir/build/BUILD/xen-4.19.1/tools/tests/x86_emulator'
> In file included from /usr/include/features.h:535,
>from /usr/include/bits/libc-header-
Passing the -dumpversion option to gcc may only print the major version
(for 4.x.y it printed major and minor, which in nowaday's scheme is then
indeed just 5 for 5.x).
Fixes: 40458f752550 ("Xen: Update compiler baseline checks")
Signed-off-by: Jan Beulich
--- a/Config.mk
+++ b/Config.mk
@@ -125
On 31.03.2025 14:01, Jan Beulich wrote:
> Passing the -dumpversion option to gcc may only print the major version
> (for 4.x.y it printed major and minor, which in nowaday's scheme is then
> indeed just 5 for 5.x).
I meanwhile notice that my self-built compilers print 3 digits, so there
really is
On 28.03.2025 14:44, Andrew Cooper wrote:
> From: Lin Liu
>
> This needs to be done in several steps, because of common vs arch issues.
> Start by using the new common infastructure inside the arch infrastructure.
>
> libelf-private.h is awkward, and the only thing in Xen using swabXX()
> direct
On Mon, Mar 31, 2025 at 02:45:05PM +0100, Andrew Cooper wrote:
> On 31/03/2025 2:16 pm, Marek Marczykowski-Górecki wrote:
> > On Fri, Mar 14, 2025 at 02:19:19PM -0700, Stefano Stabellini wrote:
> >> On Fri, 14 Mar 2025, Marek Marczykowski-Górecki wrote:
> >>> This is AMD Zen2 (Ryzen 5 4500U specifi
On 31/03/2025 9:32 am, Jan Beulich wrote:
> On 28.03.2025 14:44, Andrew Cooper wrote:
>> From: Lin Liu
>>
>> The current swab??() infrastructure is unecesserily complicated, and can be
>> repated entirely with compiler builtins.
>>
>> All supported compilers provide __BYTE_ORDER__ and __builtin_bs
On 28.03.2025 14:44, Andrew Cooper wrote:
> From: Lin Liu
>
> unaligned.h already inlcudes byteorder.h, so most can simply be dropped.
>
> No functional change.
>
> Signed-off-by: Lin Liu
Nit: Again missing your own S-o-b?
Acked-by: Jan Beulich
Jan
On 31.03.2025 15:59, Andrew Cooper wrote:
> On 31/03/2025 9:32 am, Jan Beulich wrote:
>> On 28.03.2025 14:44, Andrew Cooper wrote:
>>> +#if defined(__LITTLE_ENDIAN)
>>> +
>>> +# define cpu_to_le64(x) (uint64_t)(x)
>>> +# define le64_to_cpu(x) (uint64_t)(x)
>>> +# define cpu_to_le32(x) (uint32_t)(x)
On 31/03/2025 8:42 am, Jan Beulich wrote:
> On 28.03.2025 14:44, Andrew Cooper wrote:
>> There is a singular user. It's unlikely we'll gain a big-endian build of
>> Xen,
>> but it's far more unlikely that bitfields will differ from main endianness.
> Just one point: While endian-ness in general i
On 28.03.2025 14:44, Andrew Cooper wrote:
> Sort the includes. Drop useless includes of xen/types.h
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Use infrastructure from xen/linkage.h instead of the custom legacy
macros that we're in the process of phasing out.
Signed-off-by: Jan Beulich
---
I wasn't quite sure whether to also convert __page_tables_{start,end}
right here (to LABEL()).
--- a/xen/arch/x86/boot/x86_64.S
+++ b/xen/arch/x86/bo
On 31/03/2025 3:26 pm, Jan Beulich wrote:
> Use infrastructure from xen/linkage.h instead of the custom legacy
> macros that we're in the process of phasing out.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
On 3/28/25 2:44 PM, Andrew Cooper wrote:
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
The use of byteorder.h in io.h appears to have been copy&paste from ARM. It's
not needed, but macros and types are.
No functional change.
Signed-off-by: Andrew Cooper
Reviewe
On 28.03.2025 14:44, Andrew Cooper wrote:
> There is a singular user. It's unlikely we'll gain a big-endian build of Xen,
> but it's far more unlikely that bitfields will differ from main endianness.
Just one point: While endian-ness in general is dictated by hardware, endian-
ness of bitfields i
Now pmu_msr_{read,write}() just do pmu_msr_chk_emulated(), so remove
them and call pmu_msr_chk_emulated() directly.
Suggested-by: H. Peter Anvin (Intel)
Signed-off-by: Xin Li (Intel)
---
arch/x86/xen/enlighten_pv.c | 17 ++---
arch/x86/xen/pmu.c | 24 ---
Also add support for the immediate form MSR write support.
Originally-by: H. Peter Anvin (Intel)
Signed-off-by: Xin Li (Intel)
---
arch/x86/include/asm/fred.h | 2 +-
arch/x86/include/asm/msr.h| 340 ++
arch/x86/include/asm/paravirt.h | 22
The immediate form of MSR access instructions are primarily motivated
by performance, not code size: by having the MSR number in an immediate,
it is available *much* earlier in the pipeline, which allows the
hardware much more leeway about how a particular MSR is handled.
Use a scattered CPU featu
Add the instruction opcodes used by the immediate form WRMSRNS/RDMSR
to x86-opcode-map.
Signed-off-by: Xin Li (Intel)
---
arch/x86/lib/x86-opcode-map.txt | 5 +++--
tools/arch/x86/lib/x86-opcode-map.txt | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/x86/lib/
__rdmsr() is the lowest level primitive MSR read API, and its direct
use is NOT preferred. Use its wrapper function native_rdmsrl() instead.
No functional change intended.
Signed-off-by: Xin Li (Intel)
---
arch/x86/coco/sev/core.c | 2 +-
arch/x86/events/amd/brs.c
Signed-off-by: Xin Li (Intel)
---
arch/x86/mm/extable.c | 59 ++-
1 file changed, 41 insertions(+), 18 deletions(-)
diff --git a/arch/x86/mm/extable.c b/arch/x86/mm/extable.c
index eb9331240a88..56138c0762b7 100644
--- a/arch/x86/mm/extable.c
+++ b/arch/x8
Signed-off-by: Xin Li (Intel)
---
arch/x86/include/asm/msr.h | 18 ++
1 file changed, 2 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 121597fc5d41..da4f2f6d127f 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/incl
__wrmsr() is the lowest level primitive MSR write API, and its direct
use is NOT preferred. Use its wrapper function native_wrmsrl() instead.
No functional change intended.
Signed-off-by: Xin Li (Intel)
---
arch/x86/events/amd/brs.c | 2 +-
arch/x86/include/asm/apic.h
On 30/03/2025 23:06, Julien Grall wrote:
>
>
> Hi Ayan,
>
> On 30/03/2025 19:03, Ayan Kumar Halder wrote:
>> Added a new file prepare_xen_region.inc to hold the common earlyboot MPU
>> regions
>> configurations across arm64 and arm32.
>
> While I understand the desire to consolidate the cod
On 28.03.2025 14:44, Andrew Cooper wrote:
> From: Lin Liu
>
> The current swab??() infrastructure is unecesserily complicated, and can be
> repated entirely with compiler builtins.
>
> All supported compilers provide __BYTE_ORDER__ and __builtin_bswap??().
>
> Nothing in Xen cares about the val
On 28.03.2025 14:44, Andrew Cooper wrote:
> From: Lin Liu
>
> In divmod.c, additionally swap xen/lib.h for xen/macros.h as only ABS() is
> needed.
>
> In find-next-bit.c, ext2 has nothing to do with this logic.
While I agree here, ...
> Despite the
> comments, it was a local modification when
On 31.03.2025 10:43, Roger Pau Monné wrote:
> On Mon, Mar 31, 2025 at 07:26:20AM +, Chen, Jiqian wrote:
>> On 2025/3/27 17:25, Roger Pau Monné wrote:
>>> On Thu, Mar 27, 2025 at 03:32:12PM +0800, Jiqian Chen wrote:
--- a/xen/drivers/vpci/vpci.c
+++ b/xen/drivers/vpci/vpci.c
@@ -3
On Mon, Mar 31, 2025 at 08:13:50AM +, Chen, Jiqian wrote:
> On 2025/3/27 20:44, Roger Pau Monné wrote:
> > On Thu, Mar 27, 2025 at 03:32:14PM +0800, Jiqian Chen wrote:
> >> When init_msi() fails, the new codes will try to hide MSI
> >> capability, so it can't rely on vpci_deassign_device() to
>
On Sun, 2025-03-30 at 17:48 -0400, Michael S. Tsirkin wrote:
> On Sun, Mar 30, 2025 at 10:27:58PM +0100, David Woodhouse wrote:
> > On 30 March 2025 18:06:47 BST, "Michael S. Tsirkin" wrote:
> > > > It's basically just allowing us to expose through PCI, what I believe
> > > > we can already do for
On 2025/3/31 16:53, Roger Pau Monné wrote:
> On Mon, Mar 31, 2025 at 08:13:50AM +, Chen, Jiqian wrote:
>> On 2025/3/27 20:44, Roger Pau Monné wrote:
>>> On Thu, Mar 27, 2025 at 03:32:14PM +0800, Jiqian Chen wrote:
When init_msi() fails, the new codes will try to hide MSI
capability, s
On 30/03/2025 20:03, Ayan Kumar Halder wrote:
> Enabled early booting of Armv8-R AArch32 based systems.
>
> This patch serie with
> https://patchwork.kernel.org/project/xen-devel/cover/20250316192445.2376484-1-luca.fance...@arm.com/
> will enable build on Xen on Armv8-R AArch32 for MPU.
>
> Pa
We can now easily use __SIZEOF_LONG__ instead. For this to also work in
the test harness, move hvmloader's STR() to common-macros.h.
Signed-off-by: Jan Beulich
---
Quite likely libxl{,u}_internal.h's STRINGIFY() could then also be
replaced.
--- a/xen/arch/x86/x86_emulate/private.h
+++ b/xen/arch
Since the ARGS macros are no longer used in the MSR read/write API
implementation, move them after their definitions.
Signed-off-by: Xin Li (Intel)
---
arch/x86/include/asm/msr.h | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/x86/inc
On 31.03.2025 17:22, Andrew Cooper wrote:
> On 31/03/2025 1:06 pm, Jan Beulich wrote:
>> On 31.03.2025 14:01, Jan Beulich wrote:
>>> Passing the -dumpversion option to gcc may only print the major version
>>> (for 4.x.y it printed major and minor, which in nowaday's scheme is then
>>> indeed just 5
On 31/03/2025 4:55 pm, Jan Beulich wrote:
> Adding Q suffixes to FXSAVE/FXRSTOR did break the 32-bit build. Don't go
> back though, as the hand-coded 0x48 there weren't quite right either for
> the 32-bit case (they might well cause confusion when looking at the
> disassembly). Instead arrange for
On 27.03.25 00:33, Julien Grall wrote:
Hello Julien
> Hi,
>
> On 26/03/2025 08:57, Orzel, Michal wrote:
>>
>>
>> On 25/03/2025 17:54, Oleksandr Tyshchenko wrote:
>>>
>>>
>>> On 25.03.25 18:09, Julien Grall wrote:
>>>
>>>
Hi Oleksandr,
>>>
>>> Hello Julien
>>>
On 25/03/2025 16:05
xen-acpi-processor functions under a PVH dom0 with only a
xen_initial_domain() runtime check. Change the Kconfig dependency from
PV dom0 to generic dom0 to reflect that.
Suggested-by: Jan Beulich
Signed-off-by: Jason Andryuk
---
drivers/xen/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 del
On 24.01.24 22:25, Andrew Cooper wrote:
> On 14/01/2024 10:01 am, Mykyta Poturai wrote:
>> diff --git a/tools/include/xendevicemodel.h b/tools/include/xendevicemodel.h
>> index 797e0c6b29..4833e55bce 100644
>> --- a/tools/include/xendevicemodel.h
>> +++ b/tools/include/xendevicemodel.h
>> @@ -236,6
On 30/03/2025 22:06, Julien Grall wrote:
Hi Ayan,
Hi Julien/Michal,
Michal - I agree to use {READ/WRTIE}_SYSREG_ASM() instead of LOAD/STORE.
I need your thoughts on the following.
On 30/03/2025 19:03, Ayan Kumar Halder wrote:
Added a new file prepare_xen_region.inc to hold the common ear
* Xin Li (Intel) wrote:
> __rdmsr() is the lowest level primitive MSR read API, and its direct
> use is NOT preferred. Use its wrapper function native_rdmsrl()
> instead.
This description is very misleading. As of today, native_rdmsrl()
doesn't exist in-tree, so it cannot be 'preferred' in
On Mon, Mar 31, 2025 at 09:32:02AM +, Chen, Jiqian wrote:
> On 2025/3/31 16:43, Roger Pau Monné wrote:
> > On Mon, Mar 31, 2025 at 07:26:20AM +, Chen, Jiqian wrote:
> >> On 2025/3/27 17:25, Roger Pau Monné wrote:
> >>> On Thu, Mar 27, 2025 at 03:32:12PM +0800, Jiqian Chen wrote:
> #e
On Fri, Mar 14, 2025 at 02:19:19PM -0700, Stefano Stabellini wrote:
> On Fri, 14 Mar 2025, Marek Marczykowski-Górecki wrote:
> > This is AMD Zen2 (Ryzen 5 4500U specifically), in a HP Probook 445 G7.
> >
> > This one has working S3, so add a test for it here.
> >
> > Signed-off-by: Marek Marczyko
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
On 31/03/2025 1:06 pm, Jan Beulich wrote:
> On 31.03.2025 14:01, Jan Beulich wrote:
>> Passing the -dumpversion option to gcc may only print the major version
>> (for 4.x.y it printed major and minor, which in nowaday's scheme is then
>> indeed just 5 for 5.x).
> I meanwhile notice that my self-bui
From: Kees Cook
[ Upstream commit 1c3dfc7c6b0f551fdca3f7c1f1e4c73be8adb17d ]
When a character array without a terminating NUL character has a static
initializer, GCC 15's -Wunterminated-string-initialization will only
warn if the array lacks the "nonstring" attribute[1]. Mark the arrays
with __n
On 31.03.2025 17:20, Oleksii Kurochko wrote:
> A randconfig job failed with the following issue:
> riscv64-linux-gnu-ld: Xen too large for early-boot assumptions
>
> The reason is that enabling the UBSAN config increased the size of
> the Xen binary.
>
> Increase XEN_VIRT_SIZE to reserve enough
A randconfig job failed with the following issue:
riscv64-linux-gnu-ld: Xen too large for early-boot assumptions
The reason is that enabling the UBSAN config increased the size of
the Xen binary.
Increase XEN_VIRT_SIZE to reserve enough space, allowing both UBSAN
and GCOV to be enabled together
91 matches
Mail list logo
