flight 187986 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187986/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-freebsd11-amd64 21 guest-start/freebsd.repeat fail in
187979 pass in 187986
test-amd64-
...
> Due to the non-negligible impact of PIE, perhaps some kind of
> CONFIG_PIE config definition should be introduced, so the assembly
> code would be able to choose optimal asm sequence when PIE and non-PIE
> is requested?
I wouldn't have thought that performance mattered in the asm code
that r
On Sun, Oct 6, 2024 at 1:37 AM H. Peter Anvin wrote:
>
> On 10/5/24 01:31, Uros Bizjak wrote:
> >>
> >> movq $sym to leaq sym(%rip) which you said ought to be smaller (and in
> >> reality appears to be the same size, 7 bytes) seems like a no-brainer
> >> and can be treated as a code quality issue
On Sun, Oct 6, 2024 at 2:00 AM Linus Torvalds
wrote:
>
> On Sat, 5 Oct 2024 at 16:37, H. Peter Anvin wrote:
> >
> > Sadly, that is not correct; neither gcc nor clang uses lea:
>
> Looking around, this may be intentional. At least according to Agner,
> several cores do better at "mov immediate" co
flight 187985 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187985/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187970
test-amd64-amd64-xl-qemuu-win7-amd64
Convert the microcode loading functions to take struct boot_info, and then
using struct boot_module to map and check for microcode. To keep the changes
focused, continue using the struct mod to hold the reference to the microcode
that is used by the late microcode logic.
Signed-off-by: Daniel P. S
With construct_dom0 consuming struct boot_domain, continue passing the
structure down to dom0_construct_pv.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/dom0_build.c | 2 +-
xen/arch/x86/include/asm/dom0_build.h | 5 ++--
xen/arch/x86/pv/dom0_build.c | 43 --
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
---
xen/arch/x86/include/asm/bootinfo.h | 1 +
xen/arch/x86/setup.c| 2 +-
xen/include/xsm/xsm.h | 1
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 have to be rescanned to
find the boot module post-relocation, so the cache copy can be
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 to be transition by
this commit is module relocation.
Signed-off-by: Daniel P. Smith
-
This commit introduces the start and size fields to struct boot_module and adds
a corresponding bootstrap mapping function, bootstrap_map_bm.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 2 ++
xen/arch/x86/include/asm/setup.h| 2 ++
xen/arch/x86/setup.c
To begin moving toward allowing the hypervisor to construct more than one
domain at boot, a container is needed for a domain's build information.
Introduce a new header, , that contains the initial
struct boot_domain that encapsulate the build information for a domain.
No functional change intend
With construct_dom0 consuming struct boot_domain, continue passing the
structure down to dom0_construct_pvh.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/dom0_build.c | 2 +-
xen/arch/x86/hvm/dom0_build.c | 31 +--
xen/arch/x86/include/asm/dom0_bui
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 --
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/include/asm
With all consumers of module_map converted, remove usage of it
by the microcode loading logic.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/cpu/microcode/core.c| 22 +-
xen/arch/x86/include/asm/microcode.h | 6 ++
xen/arch/x86/setup.c | 4 ++--
3
This changes both the kernel and ramdisk parameters over to struct
boot_module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/dom0_build.c | 3 +--
xen/arch/x86/hvm/dom0_build.c | 11 +--
xen/arch/x86/include/asm/dom0_build.h | 7 +++
3 files changed, 9 insert
Move kextra into struct boot_info, thus no longer needed to be passed as a
parameter to create_dom0.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 1 +
xen/arch/x86/setup.c| 12 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git
The construct_dom0 function is converted to consume struct boot_module
instances for the kernel and ramdisk. With this change, it is no longer
necessary for the internal use of struct mod by create_dom0, so they are
changed to struct boot_module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/d
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 transition
from struct mod fields to struct boot_module fields. The second is to allow
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 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index
This will introduce a new struct boot_module to provide a rich state
representation around modules provided by the boot loader. Support is for 64
boot modules, one held in reserve for Xen, and up to 63 can be provided by the
boot loader. The array of struct boot_modules will be accessible via a
ref
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-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 25 -
1 file
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 be used by consumers
of boot modules, such as domain construction.
Signed-off-by: Dan
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 either by convention or
configuration.
Signed-off-by: Daniel P. Smith
---
xen/arch/
This eliminates usage of early_mod by discard_initial_images
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index b3b6e6f38622..e9e3da3204f1 100644
--- a/xen/arch/x86/se
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_domain instead
of these four parameters.
Signed-off-by: Daniel P. Smith
---
xen/arch
Store a reference to the created domain in struct boot_domain.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootdomain.h | 3 +++
xen/arch/x86/setup.c | 15 +++
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/include/asm/b
The purpose of struct boot_module is to encapsulate the state of boot module as
it is processed by Xen. Locating boot module state struct boot_module reduces
the number of global variables as well as the number of state variables that
must be passed around. It also lays the groundwork for hyperlaun
This changes the type for the image parameter of dom0_construct_pv to be struct
boot_module. Removing the usage of early_mod field for kernel module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/dom0_build.c | 3 +--
xen/arch/x86/include/asm/dom0_build.h | 7 +++
xen/arch/x8
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 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 90acd4180441..
Locate the first unclaimed struct boot_module and mark it as ramdisk. If there
are any remaining unclaimed struct boot_module instances, report to the
console. In the change, the new boot module iterator is used to find the
initrd index, which returns a signed int. Switch initrdidx from unsigned to
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 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index
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 usage of early_mod field for
ramdisk module.
Signed-off-by: Daniel P. Smith
---
xe
Any direct usages of struct mod have been transitioned, remove the remaining
references to early_mod fields.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 31 +++
1 file changed, 11 insertions(+), 20 deletions(-)
diff --git a/xen/arch/x86/setup.c b/xen/ar
With all references to mod field removed, remove the mod field from struct
boot_module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 3 ---
xen/arch/x86/setup.c| 3 ---
2 files changed, 6 deletions(-)
diff --git a/xen/arch/x86/include/asm/bootinfo.h
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/setup.c | 36 +---
1 file changed, 17 insertions(+), 19 del
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
---
xen/arch/x86/setup.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions
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..b3b6e6f38622 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -276,8 +276,6 @@ c
This changes both the kernel and ramdisk parameters over to struct boot_module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/hvm/dom0_build.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_b
Provide an iterator to go through boot module array searching based on type.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/bootinfo.h
b/xen/arch/x86/include/a
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.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 2 ++
xen/a
To start transitioning consider_modules() over to struct boot_module, begin
with taking the array of struct boot_modules but use the temporary struct
element mod.
No functional change intended.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/setup.c | 16
1 file changed, 8 inse
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.c | 19 +--
2 files changed, 14 inser
The Boot Modules for Hyperlaunch series is an effort to split out preliminary
changes necessary for the introduction of the Hyperlaunch domain builder
logic. These preliminary changes revolve around introducing the struct
boot_module and struct boot_domain structures. This includes converting the
d
Transition the incoming boot loader name to be held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 2 ++
xen/arch/x86/setup.c| 16
2 files changed, 10 insertions(+), 8 deletions(-)
d
Transition Xen's command line to being held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith
Acked-by: Andrew Cooper
---
xen/arch/x86/include/asm/bootinfo.h | 1 +
xen/arch/x86/setup.c| 20
2 files changed, 13 insertions(+
From: Christopher Clark
An initial step towards a non-multiboot internal representation of boot
modules for common code, starting with x86 setup and converting the fields
that are accessed for the startup calculations.
Introduce a new header, , and populate it with a new boot_info
structure init
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 ramdisk, and a
placeholder for itself, are updated as being consumed at the time of bei
Remove the use of struct mod to hold the reference for the microcode,
converting the code to work with a struct boot_module.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/cpu/microcode/core.c | 31 +++
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/
Transition the memory map info to be held in struct boot_info.
No functional change intended.
Signed-off-by: Daniel P. Smith
---
xen/arch/x86/include/asm/bootinfo.h | 5 +
xen/arch/x86/setup.c| 12 +---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a
On October 6, 2024 12:17:40 PM PDT, Uros Bizjak wrote:
>On Sun, Oct 6, 2024 at 8:01 PM David Laight wrote:
>>
>> ...
>> > Due to the non-negligible impact of PIE, perhaps some kind of
>> > CONFIG_PIE config definition should be introduced, so the assembly
>> > code would be able to choose optimal
On Sun, Oct 6, 2024 at 8:01 PM David Laight wrote:
>
> ...
> > Due to the non-negligible impact of PIE, perhaps some kind of
> > CONFIG_PIE config definition should be introduced, so the assembly
> > code would be able to choose optimal asm sequence when PIE and non-PIE
> > is requested?
>
> I wou
52 matches
Mail list logo
