On 16.04.2025 21:05, Oleksii Kurochko wrote:
> On 4/15/25 2:46 PM, Jan Beulich wrote:
>> On 08.04.2025 17:57, Oleksii Kurochko wrote:
>>> Introduce interrupt controller descriptor for host APLIC to describe
>>> the low-lovel hardare. It includes implementation of the following
>>> functions:
>>>
+ Rahul
On Wed, 16 Apr 2025, Andrew Cooper wrote:
> cpu_to_le64() is about to become a macro, at which point the #ifdef in the
> middle of it becomes undefined behaviour.
>
> Use a logcal variable to prepare strtab, where the #ifdef is fine to use.
>
> No functional change.
>
> Signed-off-by: A
On Wed, 16 Apr 2025, Andrew Cooper wrote:
> With the common code moved fully onto xen/byteorder.h, clean up the dregs.
>
> Sort includes in some files while swapping over to xen/byteorder.h.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
On Wed, 16 Apr 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Add test runner script qemu-xtf.sh which is allows any XTF x86 test to be
> easily executed. Test runner is invoked from the qemu-smoke* jobs with the
> hardcoded parameters.
>
> Each x86 XTF job lead time is reduced a bit sinc
On Wed, 16 Apr 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Hook arm64 QEMU configuration to qemu-xtf.sh and use new script in arm64 CI
> jobs.
>
> Signed-off-by: Denis Mukhin
Reviewed-by: Stefano Stabellini
> ---
> automation/gitlab-ci/test.yaml| 4 +-
> automati
On Wed, 16 Apr 2025, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Introduce new CI job to run x86 XTF argo test under QEMU to smoke test argo
> feature functionality in upstream CI.
>
> The new job lead time is ~30s, limit max job duration to 60s.
>
> Signed-off-by: Denis Mukhin
> ---
> au
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 is
Dear all,
we discovered a bug in hvm64 x86 Xen. Using the attached xtf test we are
able to trigger an assert in arch/x86/hvm/emulate.c:
if ( (hvmemul_ctxt->ctxt.regs->eflags & X86_EFLAGS_DF) && (reps > 1) )
{
/*
* x86_emulate() clips the repetition count to ensure we don't wrap
On Wed, 16 Apr 2025, Michal Orzel wrote:
> Just like for RISCV and PPC, the earlier we enable the CI build the
> better.
>
> Signed-off-by: Michal Orzel
Reviewed-by: Stefano Stabellini
> ---
> Changes in v2:
> - add Arm32 job given recently committed series
>
> Pipeline:
> https://gitlab.co
On Tue, 15 Apr 2025, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> This patch adds Xen XSM policy loading support.
>
> The configuration file XEN_POLICY specifies Xen hypervisor
> XSM policy binary to load.
>
> Signed-off-by: Grygorii Strashko
> ---
> changes in v2:
> - fix conditiona
On Wed, 16 Apr 2025, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> The current code in generate_uboot_images() does not detect arm64 properly
> and always generates ARM u-boot image, because below command
> file -L $XEN
> returns string which may contain "Aarch64" or "ARM64", and, in th
On Wed, 16 Apr 2025, Julien Grall wrote:
> (+ Rahul)
>
> On 16/04/2025 17:37, Mykyta Poturai wrote:
> > On 16.04.25 01:40, Stefano Stabellini wrote:
> > > On Mon, 14 Apr 2025, Julien Grall wrote:
> > > > Hi Mykyta,
> > > >
> > > > On 14/04/2025 18:51, Mykyta Poturai wrote:
> > > > > This series a
Add a 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, a
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
When creating a hardware domain, have the dom0less code call
construct_hwdom() which is shared with the dom0 code. The hardware
domain requires building that best matches the dom0 build path. Re-use
it to keep them in sync.
The device tree node of the dom0less config is now passed into
construct
Store the result of finding a "multiboot,device-tree" node. This will
simplity adding hardware domain checks.
Signed-off-by: Jason Andryuk
Reviewed-by: Stefano Stabellini
---
v5:
No change
v4:
Add Stefano R-b
v3:
New
Could be squashed into the next patch, but this helps make the next one
cle
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.
The assignment of d->cdf is moved later so CDF_hardware is added for the
late_
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
On 4/15/25 2:46 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
Introduce interrupt controller descriptor for host APLIC to describe
the low-lovel hardare. It includes implementation of the following functions:
- aplic_irq_startup()
- aplic_irq_shutdown()
- aplic_irq_e
On 2025-04-15 08:05, Jan Beulich wrote:
On 14.04.2025 20:01, Alejandro Vallejo wrote:
On Mon Apr 14, 2025 at 4:05 PM BST, Jan Beulich wrote:
On 14.04.2025 15:37, Alejandro Vallejo wrote:
On Thu Apr 10, 2025 at 11:42 AM BST, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
+/*
From: Grygorii Strashko
The current code in generate_uboot_images() does not detect arm64 properly
and always generates ARM u-boot image, because below command
file -L $XEN
returns string which may contain "Aarch64" or "ARM64", and, in the later
case, the current code will mistakenly identify Xe
Hi Julien,
> On 14 Apr 2025, at 12:48, Julien Grall wrote:
>
> Hi Luca,
>
> On 11/04/2025 23:56, Luca Fancellu wrote:
>> Introduce the MPU memory mapping flags in asm/page.h.
>> Signed-off-by: Luca Fancellu
>> ---
>> xen/arch/arm/include/asm/page.h | 25 +
>> 1 file ch
On 2025-04-16 13:58, Andrew Cooper wrote:
cpu_to_le64() is about to become a macro, at which point the #ifdef in
the
middle of it becomes undefined behaviour.
Use a logcal variable to prepare strtab, where the #ifdef is fine to
use.
No functional change.
Signed-off-by: Andrew Cooper
for
On 16.04.25 17:26, Alejandro Vallejo wrote:
On Wed Apr 16, 2025 at 11:44 AM BST, Grygorii Strashko wrote:
On 16.04.25 04:03, Stefano Stabellini wrote:
On Mon, 14 Apr 2025, Grygorii Strashko wrote:
From: Grygorii Strashko
The current code in generate_uboot_images() does not detect arm64
On 16/04/2025 2:44 pm, Jan Beulich wrote:
> For the X86EMUL_EXCEPTION case the repeat count must be correctly
> propagated back. Since for the recursive invocation we use a local
> helper variable, its value needs copying to the caller's one.
>
> While there also correct the off-by-1 range in the c
On 15.04.2025 18:54, Stewart Hildebrand wrote:
> In preparation for translating virtual PCI bus topology (where a pdev
> lookup will be needed in the vPCI I/O handlers), acquire d->pci_lock in
> the vPCI I/O handlers.
I find it concerning that the locked regions (it's a domain-wide lock
after all)
On 14.04.2025 11:51, Mykyta Poturai wrote:
> From: Mykyta Poturai
>
> Add the second version of inject_msi DM op, which allows to specify
> the source_id of an MSI interrupt. This is needed for correct MSI
> injection on ARM.
If this is about Arm, why does x86 also gain (incomplete) handling?
>
V/r,
Daniel P. Smith
Apertus Solutions, LLC
On 4/16/25 10:06, Jan Beulich wrote:
On 16.04.2025 16:00, Daniel P. Smith wrote:
V/r,
Daniel P. Smith
Apertus Solutions, LLC
On 4/16/25 09:33, Jan Beulich wrote:
On 16.04.2025 15:02, Daniel P. Smith wrote:
On 4/10/25 16:56, Jason Andryuk wrote
On Wed Apr 16, 2025 at 11:44 AM BST, Grygorii Strashko wrote:
>
>
> On 16.04.25 04:03, Stefano Stabellini wrote:
>> On Mon, 14 Apr 2025, Grygorii Strashko wrote:
>>> From: Grygorii Strashko
>>>
>>> The current code in generate_uboot_images() does not detect arm64 properly
>>> and always generates
On 16.04.2025 16:19, Daniel P. Smith wrote:
> On 4/16/25 09:54, Jan Beulich wrote:
>> On 16.04.2025 15:42, Daniel P. Smith wrote:
>>>
>>> On 4/10/25 08:08, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
> From: "Daniel P. Smith"
>
> Introduce the `cpus` property,
On 16.04.2025 16:12, Daniel P. Smith wrote:
> On 4/16/25 09:41, Jan Beulich wrote:
>> On 16.04.2025 15:37, Daniel P. Smith wrote:
>>> On 4/10/25 08:03, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
> @@ -212,6 +213,39 @@ static int __init process_domain_node(
>
On 16.04.2025 16:09, Daniel P. Smith wrote:
> On 4/16/25 09:38, Jan Beulich wrote:
>> On 16.04.2025 15:32, Daniel P. Smith wrote:
>>> On 4/10/25 07:57, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/domain-builder/fdt.c
> +++ b/xen/arch/x86/domain
On 16.04.2025 16:00, Daniel P. Smith wrote:
>
>
> V/r,
> Daniel P. Smith
> Apertus Solutions, LLC
>
> On 4/16/25 09:33, Jan Beulich wrote:
>> On 16.04.2025 15:02, Daniel P. Smith wrote:
>>> On 4/10/25 16:56, Jason Andryuk wrote:
On 2025-04-10 11:01, Jan Beulich wrote:
> On 10.04.2025 15
On 4/16/25 09:54, Alejandro Vallejo wrote:
On Wed Apr 16, 2025 at 2:42 PM BST, Daniel P. Smith wrote:
On 4/10/25 08:08, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
From: "Daniel P. Smith"
Introduce the `cpus` property, named as such for dom0less compatibility, that
repr
V/r,
Daniel P. Smith
Apertus Solutions, LLC
On 4/16/25 09:41, Jan Beulich wrote:
On 16.04.2025 15:37, Daniel P. Smith wrote:
On 4/10/25 08:03, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
@@ -212,6 +213,39 @@ static int __init process_domain_node(
else
On 4/16/25 09:38, Jan Beulich wrote:
On 16.04.2025 15:32, Daniel P. Smith wrote:
On 4/10/25 07:57, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -193,6 +193,25 @@ static int __init process_dom
V/r,
Daniel P. Smith
Apertus Solutions, LLC
On 4/16/25 09:33, Jan Beulich wrote:
On 16.04.2025 15:02, Daniel P. Smith wrote:
On 4/10/25 16:56, Jason Andryuk wrote:
On 2025-04-10 11:01, Jan Beulich wrote:
On 10.04.2025 15:09, Daniel P. Smith wrote:
On 4/9/25 02:24, Jan Beulich wrote:
On 0
On 4/16/25 09:54, Jan Beulich wrote:
On 16.04.2025 15:42, Daniel P. Smith wrote:
On 4/10/25 08:08, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
From: "Daniel P. Smith"
Introduce the `cpus` property, named as such for dom0less compatibility, that
represents the maximum
On 16.04.2025 13:58, Andrew Cooper wrote:
> From: Lin Liu
>
> These wrappers simply hide a deference, which adds to the cognitive complexity
> of reading the code. As such, they're not going to be included in the new
> byteswap infrastructure.
>
> No functional change.
>
> Signed-off-by: Lin L
On Wed Apr 16, 2025 at 2:42 PM BST, Daniel P. Smith wrote:
>
> On 4/10/25 08:08, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> From: "Daniel P. Smith"
>>>
>>> Introduce the `cpus` property, named as such for dom0less compatibility,
>>> that
>>> represents the maximum num
On 16.04.2025 15:42, Daniel P. Smith wrote:
>
> On 4/10/25 08:08, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> From: "Daniel P. Smith"
>>>
>>> Introduce the `cpus` property, named as such for dom0less compatibility,
>>> that
>>> represents the maximum number of vpcus t
On Wed, Apr 16, 2025 at 01:41:51PM +0100, Matthew Wilcox wrote:
> On Wed, Apr 16, 2025 at 02:07:20PM +0200, Petr Vaněk wrote:
> > I have discovered a regression introduced in commit a9b3c355c2e6
> > ("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") [1,2] in
> > kernel version 6.14. The p
On 16.04.2025 15:52, Jan Beulich wrote:
> On 15.04.2025 23:52, Manuel Andreas wrote:
>> my fuzzing infrastructure discovered that an assert in
>> x86_emulate_wrapper is able to be triggered by an HVM domain executing a
>> specially crafted repeating movs instruction.
>>
>> Specifically, if the em
On 15.04.2025 23:52, Manuel Andreas wrote:
> my fuzzing infrastructure discovered that an assert in
> x86_emulate_wrapper is able to be triggered by an HVM domain executing a
> specially crafted repeating movs instruction.
>
> Specifically, if the emulation of the rep movs instruction triggers a
For the X86EMUL_EXCEPTION case the repeat count must be correctly
propagated back. Since for the recursive invocation we use a local
helper variable, its value needs copying to the caller's one.
While there also correct the off-by-1 range in the comment ahead of the
function (strictly speaking for
On 4/10/25 08:08, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
From: "Daniel P. Smith"
Introduce the `cpus` property, named as such for dom0less compatibility, that
represents the maximum number of vpcus to allocate for a domain. In the device
Nit: vcpus
I agree with
On 16.04.2025 15:37, Daniel P. Smith wrote:
> On 4/10/25 08:03, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> @@ -212,6 +213,39 @@ static int __init process_domain_node(
>>> else
>>> printk("PV\n");
>>> }
>>> +else if ( str
On 16.04.2025 15:32, Daniel P. Smith wrote:
> On 4/10/25 07:57, Jan Beulich wrote:
>> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>>> --- a/xen/arch/x86/domain-builder/fdt.c
>>> +++ b/xen/arch/x86/domain-builder/fdt.c
>>> @@ -193,6 +193,25 @@ static int __init process_domain_node(
>>>
On 4/10/25 08:03, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
@@ -212,6 +213,39 @@ static int __init process_domain_node(
else
printk("PV\n");
}
+else if ( strncmp(prop_name, "memory", name_len) == 0 )
+{
+
On 16.04.2025 15:02, Daniel P. Smith wrote:
> On 4/10/25 16:56, Jason Andryuk wrote:
>> On 2025-04-10 11:01, Jan Beulich wrote:
>>> On 10.04.2025 15:09, Daniel P. Smith wrote:
On 4/9/25 02:24, Jan Beulich wrote:
> On 08.04.2025 18:07, Alejandro Vallejo wrote:
>> From: "Daniel P. Smith"
On 4/10/25 07:57, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
--- a/xen/arch/x86/domain-builder/fdt.c
+++ b/xen/arch/x86/domain-builder/fdt.c
@@ -193,6 +193,25 @@ static int __init process_domain_node(
bd->domid = (domid_t)val;
printk(" domid: %d
On 4/15/25 07:59, Alejandro Vallejo wrote:
On Tue Apr 15, 2025 at 7:17 AM BST, Jan Beulich wrote:
On 14.04.2025 19:27, Alejandro Vallejo wrote:
On Mon Apr 14, 2025 at 6:06 PM BST, Alejandro Vallejo wrote:
On Thu Apr 10, 2025 at 12:34 PM BST, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro
> On 16 Apr 2025, at 14:10, Orzel, Michal wrote:
>
>
>
> On 16/04/2025 14:57, Luca Fancellu wrote:
>> Hi Michal,
>>
>
>> +}
>> +
>> +/* Set limit address of MPU protection region(pr_t). */
>> +static inline void pr_set_limit(pr_t *pr, paddr_t limit)
>> +{
>
On 16/04/2025 14:57, Luca Fancellu wrote:
> Hi Michal,
>
>>>
> +}
> +
> +/* Set limit address of MPU protection region(pr_t). */
> +static inline void pr_set_limit(pr_t *pr, paddr_t limit)
> +{
> +pr->prlar.reg.limit = ((limit - 1) >> MPU_REGION_SHIFT);
Why
On 4/10/25 16:56, Jason Andryuk wrote:
On 2025-04-10 11:01, Jan Beulich wrote:
On 10.04.2025 15:09, Daniel P. Smith wrote:
On 4/9/25 02:24, Jan Beulich wrote:
On 08.04.2025 18:07, Alejandro Vallejo wrote:
From: "Daniel P. Smith"
To begin moving toward allowing the hypervisor to construct mo
On 16.04.25 14:07, Petr Vaněk wrote:
Hi all,
I have discovered a regression introduced in commit a9b3c355c2e6
("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") [1,2] in
kernel version 6.14. The problem occurs when the x86 kernel is
configured with CONFIG_DEBUG_VM_PGFLAGS=y and is run
Hi Michal,
>>
>>>
+}
+
+/* Set limit address of MPU protection region(pr_t). */
+static inline void pr_set_limit(pr_t *pr, paddr_t limit)
+{
+pr->prlar.reg.limit = ((limit - 1) >> MPU_REGION_SHIFT);
>>> Why -1? AFAIR these registers take inclusive addresses, so
On 16/04/2025 14:31, Luca Fancellu wrote:
> Hi Michal,
>
>> On 16 Apr 2025, at 11:50, Orzel, Michal wrote:
>>
>>
>>
>> On 11/04/2025 16:56, Luca Fancellu wrote:
>>> Introduce few utility function to manipulate and handle the
>>> pr_t type.
>>>
>>> Signed-off-by: Luca Fancellu
>>> ---
>>> xen/
On Wed, Apr 16, 2025 at 02:07:20PM +0200, Petr Vaněk wrote:
> I have discovered a regression introduced in commit a9b3c355c2e6
> ("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") [1,2] in
> kernel version 6.14. The problem occurs when the x86 kernel is
> configured with CONFIG_DEBUG_VM_P
Hi Michal,
> On 16 Apr 2025, at 11:50, Orzel, Michal wrote:
>
>
>
> On 11/04/2025 16:56, Luca Fancellu wrote:
>> Introduce few utility function to manipulate and handle the
>> pr_t type.
>>
>> Signed-off-by: Luca Fancellu
>> ---
>> xen/arch/arm/include/asm/mpu.h | 40
On 4/16/25 07:58, Andrew Cooper wrote:
Sort the includes while at it.
No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Daniel P. Smith
Hi all,
I have discovered a regression introduced in commit a9b3c355c2e6
("asm-generic: pgalloc: provide generic __pgd_{alloc,free}") [1,2] in
kernel version 6.14. The problem occurs when the x86 kernel is
configured with CONFIG_DEBUG_VM_PGFLAGS=y and is run as a PV Dom0 in Xen
4.19.1. During the
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
Reviewed-by: Oleksii Kurochko
---
CC: Anthony PERAR
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
It turns out that msi.h has not needed byteorder.h since the use of
__{BIG,LITTLE}_ENDIAN_BITFIELD was dropped in commit d58f3941ce3f ("x86/MSI:
use standard C types in structures/unions").
No functional change.
Signed-of
From: Lin Liu
It is no longer used.
Signed-off-by: Lin Liu
Reviewed-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
CC: Shawn Anastasio
CC: Oleksii Kurochko
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
Sort includes in some files while swapping over to xen/byteorder.h.
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:
From: Lin Liu
This file has its own implementation of swap bytes. Clean up
the code with xen/byteswap.h.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Mo
The diffstat speaks for itself.
Compared to v6, one patch (TMEM) committed, one new patch (drivers/smmu-v3) to
fix a MISRA regression, and the __{BIG,LITTLE}_ENDIAN_BITFIELD logic is
retained. See individual patches for details.
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/177
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC
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. It was a local
modification when the logic was imported from Linux, because Xen didn't have a
suitable helper.
The new infrastructure doe
Sort the includes. Drop useless includes of xen/types.h
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
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
CC: Shawn Anastasio
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
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
CC: Shawn Anastasio
CC: O
Sort the includes while at it.
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
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC:
From: Lin Liu
unaligned.h already inlcudes byteorder.h, so most can simply be dropped.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano
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 swab??()
directly. It needs updating at the same time.
Signed-off-by:
From: Lin Liu
The current swab??() infrastructure is unecesserily complicated, and can be
replaced entirely with compiler builtins.
All supported compilers provide __BYTE_ORDER__ and __builtin_bswap??().
Nothing in Xen cares about the values of __{BIG,LITTLE}_ENDIAN; just that one
of them is de
cpu_to_le64() is about to become a macro, at which point the #ifdef in the
middle of it becomes undefined behaviour.
Use a logcal variable to prepare strtab, where the #ifdef is fine to use.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beu
On 16.04.2025 12:44, Oleksii Kurochko wrote:
>
> On 4/15/25 12:07 PM, Jan Beulich wrote:
>> On 14.04.2025 17:56, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/mm.c
>>> +++ b/xen/arch/riscv/mm.c
>>> @@ -31,20 +31,30 @@ unsigned long __ro_after_init phys_offset; /* =
>>> load_start - XEN_VIRT_ST
Hi Mykyta,
On 14/03/2025 22:34, Mykyta Poturai wrote:
From: Rahul Singh
When ITS is enabled and PCI devices that are behind an SMMU generate an
MSI interrupt, SMMU fault will be observed as there is currently no
mapping in p2m table for the ITS translation register (GITS_TRANSLATER).
A mappin
On 11/04/2025 16:56, Luca Fancellu wrote:
> Introduce few utility function to manipulate and handle the
> pr_t type.
>
> Signed-off-by: Luca Fancellu
> ---
> xen/arch/arm/include/asm/mpu.h | 40 ++
> 1 file changed, 40 insertions(+)
>
> diff --git a/xen/arch/a
On 4/15/25 12:07 PM, Jan Beulich wrote:
On 14.04.2025 17:56, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -31,20 +31,30 @@ unsigned long __ro_after_init phys_offset; /* = load_start
- XEN_VIRT_START */
#define LOAD_TO_LINK(addr) ((unsigned long)(addr) - phys
On 16.04.25 04:03, Stefano Stabellini wrote:
On Mon, 14 Apr 2025, Grygorii Strashko wrote:
From: Grygorii Strashko
The current code in generate_uboot_images() does not detect arm64 properly
and always generates ARM u-boot image. This causes Xen boot issues.
Fix it by searching for "ARM64"
(+ Rahul)
On 16/04/2025 17:37, Mykyta Poturai wrote:
On 16.04.25 01:40, Stefano Stabellini wrote:
On Mon, 14 Apr 2025, Julien Grall wrote:
Hi Mykyta,
On 14/04/2025 18:51, Mykyta Poturai wrote:
This series adds the base support for MSI injection on Arm. This is
needed to streamline virtio-pci
On 16.04.2025 12:15, Oleksii Kurochko wrote:
> On 4/14/25 12:04 PM, Jan Beulich wrote:
>> On 08.04.2025 17:57, Oleksii Kurochko wrote:
>>> +rc = dt_property_read_u32(node, "msi-parent", &imsic_phandle);
>>> +if ( !rc )
>>> +panic("%s: IDC mode not supported\n", node->full_name);
>>>
On Wed, Apr 16, 2025 at 11:15:21AM +0100, Andrew Cooper wrote:
> On 16/04/2025 12:48 am, Stefano Stabellini wrote:
> > On Mon, 14 Apr 2025, Andrew Cooper wrote:
> >> Right now, the argo artefacts are a pile of files which the test has to
> >> turn
> >> back into something which resembles a filesys
On 10/04/2025 16:54, Jan Beulich wrote:
> First, they all start out zeroed. There's no point doing an initial
> cpumask_clear() on them.
>
> Next, only cpu_online_map may be altered post-boot, and even that only
> rarely. Add respective placement attributes.
>
> Finally, cpu_present_map really
On 16/04/2025 12:48 am, Stefano Stabellini wrote:
> On Mon, 14 Apr 2025, Andrew Cooper wrote:
>> Right now, the argo artefacts are a pile of files which the test has to turn
>> back into something which resembles a filesystem. Furthermore, because we do
>> not build modules for the main kernel, it
On 4/14/25 12:04 PM, Jan Beulich wrote:
On 08.04.2025 17:57, Oleksii Kurochko wrote:
--- a/xen/arch/riscv/aplic.c
+++ b/xen/arch/riscv/aplic.c
@@ -9,19 +9,112 @@
* Copyright (c) 2024-2025 Vates
*/
+#include
#include
#include
#include
+#include
#include
#include
+#incl
On 16/04/2025 12:48 am, Stefano Stabellini wrote:
>> diff --git a/automation/scripts/qubes-x86-64.sh
>> b/automation/scripts/qubes-x86-64.sh
>> index c4be71464246..e2376cb51cb4 100755
>> --- a/automation/scripts/qubes-x86-64.sh
>> +++ b/automation/scripts/qubes-x86-64.sh
>> @@ -164,16 +164,13 @@ $
On 15.04.2025 23:52, Manuel Andreas wrote:
> Dear all,
>
> my fuzzing infrastructure discovered that an assert in
> x86_emulate_wrapper is able to be triggered by an HVM domain executing a
> specially crafted repeating movs instruction.
That's
/* All cases returning X86EMUL_EXCEPTION shoul
By observation GNU ld 2.25 may emit file symbols for .data.read_mostly
when linking xen.efi. Due to the nature of file symbols in COFF symbol
tables (see the code comment) the symbols_offsets[] entries for such
symbols would cause assembler warnings regarding value truncation. Of
course the resulti
On 16.04.25 01:40, Stefano Stabellini wrote:
> On Mon, 14 Apr 2025, Julien Grall wrote:
>> Hi Mykyta,
>>
>> On 14/04/2025 18:51, Mykyta Poturai wrote:
>>> This series adds the base support for MSI injection on Arm. This is
>>> needed to streamline virtio-pci interrupt triggering.
>>>
>>> With this
On 16.04.2025 10:38, Penny, Zheng wrote:
> [Public]
>
> Hi,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Wednesday, April 16, 2025 2:37 PM
>> To: Penny, Zheng
>> Cc: Stabellini, Stefano ; xen-
>> de...@lists.xenproject.org
>> Subject: Re: [PATCH v2 10/19] xen/sysctl: introduce
On 16.04.2025 10:29, Andrew Cooper wrote:
> On 15/04/2025 4:32 pm, Roger Pau Monne wrote:
>> diff --git a/xen/include/xen/io.h b/xen/include/xen/io.h
>> new file mode 100644
>> index ..4495a04c403e
>> --- /dev/null
>> +++ b/xen/include/xen/io.h
>> @@ -0,0 +1,68 @@
>> +/* SPDX-License-Id
[Public]
Hi,
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, April 16, 2025 2:37 PM
> To: Penny, Zheng
> Cc: Stabellini, Stefano ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v2 10/19] xen/sysctl: introduce CONFIG_PM_STATS
>
> On 16.04.2025 05:54, Penny, Zheng wr
On 15/04/2025 4:32 pm, Roger Pau Monne wrote:
> diff --git a/xen/include/xen/io.h b/xen/include/xen/io.h
> new file mode 100644
> index ..4495a04c403e
> --- /dev/null
> +++ b/xen/include/xen/io.h
> @@ -0,0 +1,68 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * IO related ro
Just like for RISCV and PPC, the earlier we enable the CI build the
better.
Signed-off-by: Michal Orzel
---
Changes in v2:
- add Arm32 job given recently committed series
Pipeline:
https://gitlab.com/xen-project/people/morzel/xen/-/pipelines/1771015642
---
automation/gitlab-ci/build.yaml | 20
On Wed, Apr 16, 2025 at 06:20:50AM +, Chen, Jiqian wrote:
> On 2025/4/15 21:45, Roger Pau Monné wrote:
> > On Wed, Apr 09, 2025 at 02:45:28PM +0800, Jiqian Chen wrote:
> >> +
> >> +for ( unsigned int i = 0; i < ARRAY_SIZE(vpci->msix->table); i++ )
> >> +if ( vpci->msix->table[i] )
1 - 100 of 111 matches
Mail list logo
