On 09.10.2024 21:44, Stewart Hildebrand wrote:
> On 8/28/24 06:36, Jan Beulich wrote:
>> On 27.08.2024 05:59, Stewart Hildebrand wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -341,6 +341,8 @@ static struct pci_dev *alloc_pdev(struct pci_seg *pseg,
>>
flight 188026 qemu-upstream-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188026/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 183557
test-amd64-amd64-xl-qe
Hi Oleksandr,
> On 9 Oct 2024, at 19:20, Oleksandr Tyshchenko wrote:
>
>
>
> On 09.10.24 09:36, Bertrand Marquis wrote:
>> Hi Oleksandr,
>
> Hello Bertrand
>
>
>>> On 8 Oct 2024, at 20:53, Oleksandr Tyshchenko wrote:
>>>
>>>
>>>
>>> On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
>>
On 10.10.24 00:46, Stefano Stabellini wrote:
On Wed, 9 Oct 2024, Jan Beulich wrote:
On 09.10.2024 08:20, Jiqian Chen wrote:
Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev")
adds a weak reverse dependency to the config XEN_PRIVCMD definition, its
purpose is to pass the co
On 10/9/2024 14:05, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
>
> hw/amd and how/intel enable the
On 10/9/24 11:38, Greg Kroah-Hartman wrote:
On Wed, Oct 09, 2024 at 10:35:16AM +0200, Philipp Stanner wrote:
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a
On 10/9/2024 14:05, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
>
> hw/amd and how/intel enable the
On Wed, Oct 9, 2024 at 4:15 PM Andrii Sultanov
wrote:
>
> xsd_glue_dev packaging is inconsistent with the rest of OCaml packages
> and isn't actually necessary. .a is needed alongside compiled bytecode
Being singular, should not be "The .a is needed "... ?
Or are there multiple archive files?
>
On 10/9/24 11:53, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
--- a/xen/arch/x86/include/asm/bootinfo.h
+++ b/xen/arch/x86/include/asm/bootinfo.h
@@ -54,8 +54,24 @@ struct boot_info {
struct boot_module mods[MAX_NR_BOOTMODS + 1];
};
-#endif /* __XEN_X86_BOOTINFO_H__
On 10/9/24 11:39, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
This commit introduces the start and size fields to struct boot_module and adds
a corresponding bootstrap mapping function, bootstrap_map_bm.
Which then is left with no caller. Misra doesn't like unreachable code.
On 10/9/24 11:38, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
From: Andrew Cooper
Using an interface based on addresses directly, not modules.
No functional change.
Signed-off-by: Andrew Cooper
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/setup.h | 1 +
On 10/9/24 11:30, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -311,6 +311,10 @@ static struct boot_info __init
*multiboot_fill_boot_info(unsigned long mbi_p)
for ( i = 0; i <= bi->nr_modules; i++ )
bi->m
On 10/9/24 11:29, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
@@ -2061,8 +2067,9 @@ void asmlinkage __init noreturn __start_xen(unsigned long
mbi_p)
* We're going to setup domain0 using the module(s) that we stashed safely
* above our heap. The second module, if
On 10/9/24 11:22, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
@@ -639,20 +639,20 @@ static uint64_t __init consider_modules(
for ( i = 0; i < nr_mods ; ++i )
{
-uint64_t start = (uint64_t)mod[i].mod_start << PAGE_SHIFT;
-uint64_t end = start + P
On 10/9/24 11:17, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
@@ -302,6 +304,13 @@ static struct boot_info __init
*multiboot_fill_boot_info(unsigned long mbi_p)
bi->memmap_length = mbi->mmap_length;
}
+/*
+ * This will iterate over all modules to i
On 10/9/24 11:13, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -296,6 +296,12 @@ static struct boot_info __init
*multiboot_fill_boot_info(unsigned long mbi_p)
else
bi->cmdline = "";
+if ( mbi->flag
On 10/9/24 11:07, Jan Beulich wrote:
On 06.10.2024 23:49, Daniel P. Smith wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -285,6 +285,9 @@ static struct boot_info __init
*multiboot_fill_boot_info(unsigned long mbi_p)
bi->nr_modules = (mbi->flags & MBI_MODULES) ? mbi->mo
On 10/8/24 15:56, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
With construct_dom0 consuming struct boot_domain, continue passing the
structure down to dom0_construct_pvh.
Signed-off-by: Daniel P. Smith
diff --git a/xen/arch/x86/hvm/dom0_build.c
b/xen/arch/x86/hvm/dom0_b
On 10/8/24 15:54, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
With construct_dom0 consuming struct boot_domain, continue passing the
structure down to dom0_construct_pv.
Signed-off-by: Daniel P. Smith
diff --git a/xen/arch/x86/pv/dom0_build.c b/xen/arch/x86/pv/dom0_buil
On 10/8/24 15:47, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
A struct boot_domain now encapsulates the domain reference, kernel,
ramdisk,
and command line for the domain being constructed. As a result of this
encapsulation, construct_dom0 can now take a single struct boot_
On 10/8/24 15:48, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Store a reference to the created domain in struct boot_domain.
Signed-off-by: Daniel P. Smith
---
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index f250638edf09..e6a231bd2d42 100644
--- a/xen/arc
On 10/8/24 16:05, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Add a container for the "cooked" command line for a domain.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootdomain.h | 4
xen/arch/x86/setup.c | 18 --
On 10/8/24 15:36, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Add a domid field to struct boot_domain to hold the assigned domain id
for the
domain. During initialization, ensure all instances of struct
boot_domain have
the invalid domid to ensure that the domid must be set
On Fri, Oct 4, 2024 at 9:17 AM Frediano Ziglio
wrote:
>
> Updated headers related to ARGO.
>
> Signed-off-by: Frediano Ziglio
Acked-by: Christopher Clark
> ---
> xen/include/xen/argo.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> ---
> Changes since v2:
> - exclude missing pu
On 10/9/24 02:53, Jan Beulich wrote:
On 08.10.2024 21:15, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Any direct usages of struct mod have been transitioned, remove the remaining
references to early_mod fields.
This is unclear, please try to re-word. "struct mod" and "ea
On 10/8/24 15:15, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Any direct usages of struct mod have been transitioned, remove the
remaining
references to early_mod fields.
This is unclear, please try to re-word. "struct mod" and "early_mod"
don't exist.
Ack.
Signed-o
On 10/8/24 15:04, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 30a139074833..b3b6e6f
On 10/8/24 14:52, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
The variable initial_images is used for tracking the boot modules
passed in by
the boot loader. Convert to a struct boot_module and adjust the code
that uses
it accordingly.
Signed-off-by: Daniel P. Smith
---
On 10/8/24 14:30, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
This changes the type for the initrd parameter of dom0_construct_pv to
be struct
boot_module. This conversion requires several adjustments throughout
dom0_construct_pv
to account for the type change. Removes the
On 10/8/24 13:08, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Add a char pointer field, cmdline, to struct boot_module to hold the
address
pointed to by the string field of struct mod. This removes the need to
use the
early_mod field to get to the dom0 kernel command line.
On 10/8/24 12:52, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
This commit changes create_dom0 to no longer take the individual
components and
take struct boot_info instead. Internally, it is changed to locate the
kernel
and ramdisk details from struct boot_info.
Signed-of
On Wed, 9 Oct 2024, Jan Beulich wrote:
> On 09.10.2024 08:20, Jiqian Chen wrote:
> > Commit 2fae6bb7be32 ("xen/privcmd: Add new syscall to get gsi from dev")
> > adds a weak reverse dependency to the config XEN_PRIVCMD definition, its
> > purpose is to pass the combination of compilation that CONFI
flight 188022 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188022/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 20 leak-check/check fail REGR. vs. 187961
Tests which are failing
flight 188037 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188037/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da1c6dd62a19361186739a00a4f86d7cf630708c
baseline version:
ovmf 7bac0a940e905941487c3
On 01/10/2024 1:37 pm, Alejandro Vallejo wrote:
> diff --git a/xen/lib/x86/policy.c b/xen/lib/x86/policy.c
> index f033d22785be..63bc96451d2c 100644
> --- a/xen/lib/x86/policy.c
> +++ b/xen/lib/x86/policy.c
> @@ -15,7 +15,16 @@ int x86_cpu_policies_are_compatible(const struct
> cpu_policy *host,
>
On 8/27/24 09:20, Roger Pau Monné wrote:
> On Mon, Aug 26, 2024 at 11:59:28PM -0400, Stewart Hildebrand wrote:
>> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
>> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
> ^ was?
Yep
>> a
flight 188035 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188035/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 8/28/24 06:36, Jan Beulich wrote:
> On 27.08.2024 05:59, Stewart Hildebrand wrote:
>> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
>> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
>> and changed from pcidevs_lock() to read_lock(&d->pci_lock). H
On 09.10.24 10:26, Julien Grall wrote:
Hi,
Hello Julien
On 07/10/2024 19:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-off-by: Oleksandr Tyshchenko
---
Based on:
[PATCH] docs
On 10/8/24 12:46, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
The ramdisk loading is the last user of module_map, remove
its usage and any remaining remnants of module_map.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 11 +--
1 file changed, 5 inser
On 09.10.2024 10:35, Philipp Stanner wrote:
> Hi all,
>
> this series removes a problematic feature from pci_intx(). That function
> sometimes implicitly uses devres for automatic cleanup. We should get
> rid of this implicit behavior.
>
> To do so, a pci_intx() version that is always-managed, an
On Wed Oct 9, 2024 at 3:45 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > --- a/xen/include/xen/lib/x86/cpu-policy.h
> > +++ b/xen/include/xen/lib/x86/cpu-policy.h
> > @@ -542,6 +542,22 @@ int x86_cpu_policies_are_compatible(const struct
> > cpu_policy *host,
> >
On Wed Oct 9, 2024 at 3:53 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > Implements the helper for mapping vcpu_id to x2apic_id given a valid
> > topology in a policy. The algo is written with the intention of
> > extending it to leaves 0x1f and extended 0x26 in the
On 10/8/24 12:36, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 2 +-
xen/include/xsm/xsm.h | 9 +++--
xen/xsm/xsm_core.c | 6 ++
xen/xsm/xsm_policy.c | 5 +
4 files changed, 7 insertions(+), 15
On 10/8/24 12:30, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
With all consumers of module_map converted, remove usage of it
by the microcode loading logic.
Signed-off-by: Daniel P. Smith
@@ -202,19 +201,18 @@ static void __init microcode_scan_module(
}
}
-stati
On 10/8/24 12:13, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Iterate through the unclaimed struct boot_module to see if any are an
XSM FLASK
policy. If one is located, mark it as an xsm policy.
Signed-off-by: Daniel P. Smith
@@ -161,6 +162,14 @@ int __init xsm_multibo
On 09.10.24 09:36, Bertrand Marquis wrote:
Hi Oleksandr,
Hello Bertrand
On 8 Oct 2024, at 20:53, Oleksandr Tyshchenko wrote:
On 08.10.24 09:17, Bertrand Marquis wrote:
Hi,
Hello Bertrand
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add co
On Wed Oct 9, 2024 at 3:25 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > @@ -148,7 +148,7 @@ static struct acpi_20_madt *construct_madt(struct
> > acpi_ctxt *ctxt,
> > lapic->length = sizeof(*lapic);
> > /* Processor ID must match processor-objec
Hi,
On Wed Oct 9, 2024 at 3:03 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > Make it so the APs expose their own APIC IDs in a LUT. We can use that
> > LUT to populate the MADT, decoupling the algorithm that relates CPU IDs
> > and APIC IDs from hvmloader.
> >
> >
On 2024-10-09 12:04, Ard Biesheuvel wrote:
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel bo
flight 188030 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188030/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed Oct 9, 2024 at 2:28 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> > If toolstack were to upload LAPIC contexts as part of domain creation it
>
> If it were to - yes. But it doesn't, an peeking ahead in the series I also
> couldn't spot this changing. Hence I do
On 09/10/2024 3:05 pm, Juergen Gross wrote:
> Instead of adding all or no Xen library (controlled by CONFIG_XC),
"libraries".
But better grammar would be "Instead of Xen libraries being all or none
(..."
Can fix on commit.
~Andrew
Hi,
On Wed Oct 9, 2024 at 2:12 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > @@ -311,18 +310,15 @@ void guest_cpuid(const struct vcpu *v, uint32_t leaf,
> >
> > case 0xb:
> > /*
> > - * In principle, this leaf is Intel-only. In practice, it
Juergen Gross, le mer. 09 oct. 2024 16:05:54 +0200, a ecrit:
> Instead of adding all or no Xen library (controlled by CONFIG_XC),
> support a dedicated config option for each library instead,
> defaulting to disabled.
>
> As it is no longer needed now, drop the CONFIG_XC support.
>
> Signed-off-b
On 10/8/24 11:56, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
To track if the microcode boot module was loaded, a copy of the boot
module is
kept. The size element of this copy is set to zero as the indicator
that the
microcode was loaded. A side effect is that the modules
On Tue Oct 8, 2024 at 4:41 PM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > While doing this, factor out checks common to architectural and hidden
> > state.
> >
> > Signed-off-by: Alejandro Vallejo
> > Reviewed-by: Roger Pau Monné
> > --
> > Last reviewed in the to
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
Since commit
d9ec1158056b ("x86/boot/64: Use RIP_REL_REF() to assign 'phys_base'")
phys_base is assigned directly rather than added to, so it is no longer
necessary to clear it after use.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So ca
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
The limit field in a GDT descriptor is an inclusive bound, and therefore
one less than the size of the covered range.
Reviewed-by: Jason Andryuk
Tested-by: Jason Andryuk
Signed-off-by: Ard Biesheuvel
---
arch/x86/platform/pvh/head.S | 2 +-
1 file changed, 1 insertion(+)
From: Ard Biesheuvel
This series was broken out of the series I sent recently [0], after
Jason pointed out that my Xen startup code changes conflict with his
changes to make the PVH startup code position independent.
Jason's work reduces the delta of my changes, and given that my other
series wi
Hi,
On Wed Oct 9, 2024 at 10:40 AM BST, Jan Beulich wrote:
> On 01.10.2024 14:37, Alejandro Vallejo wrote:
> > --- a/xen/lib/x86/policy.c
> > +++ b/xen/lib/x86/policy.c
> > @@ -15,7 +15,16 @@ int x86_cpu_policies_are_compatible(const struct
> > cpu_policy *host,
> > #define FAIL_MSR(m) \
> >
On 06.10.2024 23:49, Daniel P. Smith wrote:
> --- a/xen/arch/x86/include/asm/bootinfo.h
> +++ b/xen/arch/x86/include/asm/bootinfo.h
> @@ -54,8 +54,24 @@ struct boot_info {
> struct boot_module mods[MAX_NR_BOOTMODS + 1];
> };
>
> -#endif /* __XEN_X86_BOOTINFO_H__ */
> +static inline int __in
On 06.10.2024 23:49, Daniel P. Smith wrote:
> This commit introduces the start and size fields to struct boot_module and
> adds
> a corresponding bootstrap mapping function, bootstrap_map_bm.
Which then is left with no caller. Misra doesn't like unreachable code.
Jan
> On 9 Oct 2024, at 16:15, Andrii Sultanov wrote:
>
> xsd_glue_dev packaging is inconsistent with the rest of OCaml packages
> and isn't actually necessary. .a is needed alongside compiled bytecode
> files during linking and was missed in the initial oxenstore plugin
> work.
>
> Specify OCAML
On 06.10.2024 23:49, Daniel P. Smith wrote:
> From: Andrew Cooper
>
> Using an interface based on addresses directly, not modules.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> Signed-off-by: Daniel P. Smith
> ---
> xen/arch/x86/include/asm/setup.h | 1 +
> xen/arch/x86/setup
On 07.10.2024 22:02, Jason Andryuk wrote:
> On 2024-10-06 17:49, Daniel P. Smith wrote:
>> The existing startup code employs various ad-hoc state tracking about certain
>> boot module types by each area of the code. A boot module flags is added to
>> enable tracking these different states. The fir
On 06.10.2024 23:49, Daniel P. Smith wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -311,6 +311,10 @@ static struct boot_info __init
> *multiboot_fill_boot_info(unsigned long mbi_p)
> for ( i = 0; i <= bi->nr_modules; i++ )
> bi->mods[i].mod = &mods[i];
This l
On 06.10.2024 23:49, Daniel P. Smith wrote:
> @@ -2061,8 +2067,9 @@ void asmlinkage __init noreturn __start_xen(unsigned
> long mbi_p)
> * We're going to setup domain0 using the module(s) that we stashed
> safely
> * above our heap. The second module, if present, is an initrd ramdisk.
On 06.10.2024 23:49, Daniel P. Smith wrote:
> @@ -639,20 +639,20 @@ static uint64_t __init consider_modules(
>
> for ( i = 0; i < nr_mods ; ++i )
> {
> -uint64_t start = (uint64_t)mod[i].mod_start << PAGE_SHIFT;
> -uint64_t end = start + PAGE_ALIGN(mod[i].mod_end);
> +
On 06.10.2024 23:49, Daniel P. Smith wrote:
> @@ -302,6 +304,13 @@ static struct boot_info __init
> *multiboot_fill_boot_info(unsigned long mbi_p)
> bi->memmap_length = mbi->mmap_length;
> }
>
> +/*
> + * This will iterate over all modules to include an extra mb module,
>
xsd_glue_dev packaging is inconsistent with the rest of OCaml packages
and isn't actually necessary. .a is needed alongside compiled bytecode
files during linking and was missed in the initial oxenstore plugin
work.
Specify OCAMLCFLAGS along with OCAMLOPTFLAGS.
Signed-off-by: Andrii Sultanov
---
Following the work on stabilizing some interfaces used by oxenstored
to allow bringing it out of the xen tree, there are some additional
fixes needed around packaging the plugin interface.
With these changes, I was able to get the spec repo to build and the
forked oxenstored to launch properly on
On 06.10.2024 23:49, Daniel P. Smith wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -296,6 +296,12 @@ static struct boot_info __init
> *multiboot_fill_boot_info(unsigned long mbi_p)
> else
> bi->cmdline = "";
>
> +if ( mbi->flags & MBI_MEMMAP )
> +{
>
On 06.10.2024 23:49, Daniel P. Smith wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -285,6 +285,9 @@ static struct boot_info __init
> *multiboot_fill_boot_info(unsigned long mbi_p)
>
> bi->nr_modules = (mbi->flags & MBI_MODULES) ? mbi->mods_count : 0;
>
> +bi->l
On 07.10.2024 19:57, Jason Andryuk wrote:
> On 2024-10-06 17:49, Daniel P. Smith wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/include/asm/bootinfo.h
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * Copyright (c) 2024 Christopher Clark
>> + * Copyright (c) 2024
On 10/8/24 08:50, Jason Andryuk wrote:
On 2024-10-07 17:22, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
@@ -205,20 +204,18 @@ static void __init microcode_scan_module(
}
static void __init microcode_grab_module(
- unsigned long *module_map,
- const multiboot_info_
On 10/7/24 17:22, Jason Andryuk wrote:
@@ -822,8 +819,8 @@ static int __init early_update_cache(const void
*data, size_t len)
return rc;
}
-int __init microcode_init_cache(unsigned long *module_map,
- const struct multiboot_info *mbi)
+int __init microcode_
On 09.10.2024 15:45, Oleksii Kurochko wrote:
> Implement the virt_to_maddr() function to convert virtual addresses
> to machine addresses. The function includes checks for valid address
> ranges, specifically the direct mapping region (DIRECTMAP_VIRT_START)
> and the Xen's Linkage (XEN_VIRT_START)
On 01.10.2024 14:38, Alejandro Vallejo wrote:
> Implements the helper for mapping vcpu_id to x2apic_id given a valid
> topology in a policy. The algo is written with the intention of
> extending it to leaves 0x1f and extended 0x26 in the future.
>
> Toolstack doesn't set leaf 0xb and the HVM defau
flight 188018 xen-unstable real [real]
flight 188032 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/188018/
http://logs.test-lab.xenproject.org/osstest/logs/188032/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
On 10/7/24 17:06, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Allow the tracking of when a boot module has been consumed by a
handler in the
hypervisor independent of when it is claimed. The instances where the
hypervisor does nothing beyond claiming, the dom0 kernel, dom0
On 01.10.2024 14:38, Alejandro Vallejo wrote:
> --- a/xen/include/xen/lib/x86/cpu-policy.h
> +++ b/xen/include/xen/lib/x86/cpu-policy.h
> @@ -542,6 +542,22 @@ int x86_cpu_policies_are_compatible(const struct
> cpu_policy *host,
> const struct cpu_policy *guest,
On 10/7/24 16:44, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
Use struct boot_module fields, start and size, when calculating the
relocation
address and size. It also ensures that early_mod references are kept
in sync.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/se
flight 188031 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188031/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7bac0a940e905941487c3a2f2f5fb6ee43ff040a
baseline version:
ovmf fd619ec4608564fe6cf5b
On 09.10.24 01:46, Stefano Stabellini wrote:
Hello Stefano
On Tue, 8 Oct 2024, Oleksandr Tyshchenko wrote:
On 7 Oct 2024, at 20:55, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Add common requirements for a physical device assignment to Arm64
and AMD64 PVH domains.
Signed-of
On Wed, Oct 9, 2024 at 2:34 PM Jan Beulich wrote:
>
> On 09.10.2024 15:20, Andrew Cooper wrote:
> > On 09/10/2024 10:21 am, Jan Beulich wrote:
> >> In {big,little}_endian.h the changes are entirely mechanical, except for
> >> dealing with casting away of const from pointers-to-const on lines
> >>
On 10/7/24 16:31, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
When a boot module is relocated, ensure struct boot_module start and size
fields are updated along with early_mod.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 7 +--
1 file changed, 5 insert
On 10/9/24 10:29, Jan Beulich wrote:
On 09.10.2024 16:23, Daniel P. Smith wrote:
On 10/7/24 15:34, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1341,15 +1341,15 @@ void asmlinkage __init noreturn
__start_xen(unsigned
On 09.10.2024 16:23, Daniel P. Smith wrote:
> On 10/7/24 15:34, Jason Andryuk wrote:
>> On 2024-10-06 17:49, Daniel P. Smith wrote:
>>> --- a/xen/arch/x86/setup.c
>>> +++ b/xen/arch/x86/setup.c
>>> @@ -1341,15 +1341,15 @@ void asmlinkage __init noreturn
>>> __start_xen(unsigned long mbi_p)
>>>
On 10/7/24 16:02, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
The existing startup code employs various ad-hoc state tracking about
certain
boot module types by each area of the code. A boot module flags is
added to
enable tracking these different states. The first state t
On 10/7/24 15:50, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
This commit introduces module types of xen, kernel, and ramdisk to
allow boot
module detect code to tag the purpose of a boot module. This reduces
the need
for hard coded order assumptions and global variables to
On 01.10.2024 14:38, Alejandro Vallejo wrote:
> @@ -148,7 +148,7 @@ static struct acpi_20_madt *construct_madt(struct
> acpi_ctxt *ctxt,
> lapic->length = sizeof(*lapic);
> /* Processor ID must match processor-object IDs in the DSDT. */
> lapic->acpi_processor_id = i;
>
On 10/7/24 15:34, Jason Andryuk wrote:
On 2024-10-06 17:49, Daniel P. Smith wrote:
To allow a slow conversion of x86 over to struct boot_module, start with
replacing all references to struct mod to the early_mod element of struct
boot_module. These serves twofold, first to allow the incremental
On 09/10/2024 7:04 am, Jan Beulich wrote:
> On 08.10.2024 18:37, Andrew Cooper wrote:
>> On 08/10/2024 5:00 pm, Jan Beulich wrote:
>>> It's not unnecessary (as the earlier commit claimed): The integrated
>>> assembler of Clang up to 11 complains about an "invalid operand for
>>> instruction".
>>>
>
Instead of adding all or no Xen library (controlled by CONFIG_XC),
support a dedicated config option for each library instead,
defaulting to disabled.
As it is no longer needed now, drop the CONFIG_XC support.
Signed-off-by: Juergen Gross
---
V2:
- merge patches of the V1 series (Samuel Thibault
On 01.10.2024 14:38, Alejandro Vallejo wrote:
> Make it so the APs expose their own APIC IDs in a LUT. We can use that
> LUT to populate the MADT, decoupling the algorithm that relates CPU IDs
> and APIC IDs from hvmloader.
>
> While at this also remove ap_callin, as writing the APIC ID may serve
On 10/9/24 05:23, Jan Beulich wrote:
... by uint32_t.
Signed-off-by: Jan Beulich
---
Uses of bool_val look suspicious; I looked at them because by its name
I would have hoped I can switch it to bool instead.
--- a/xen/xsm/flask/ss/conditional.h
+++ b/xen/xsm/flask/ss/conditional.h
@@ -29,8 +29
1 - 100 of 175 matches
Mail list logo
