On Fri, Dec 20, 2024 at 02:48:52AM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Dec 19, 2024 at 05:14:52PM +0100, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > It crashes on boot like below, most of the times. But sometimes (rarely)
> > it manages to stay alive. Below I'm pasting few of
Introduce the ability to assign capabilities to a domain via its definition in
device tree. The first capability enabled to select is the control domain
capability. The capability property is a bitfield in both the device tree and
`struct boot_domain`.
Signed-off-by: Daniel P. Smith
Reviewed-by:
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
tree, it will be encoded as a u32 value.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jason Andryuk
---
Changes since v1:
- switched from ma
Add the ability to detect both a formal hyperlaunch device tree or a dom0less
device tree. If the hyperlaunch device tree is found, then count the number of
domain entries, reporting an error if more than one is found.
Signed-off-by: Daniel P. Smith
---
Changes since v1:
- corrected typo in error
Add three properties, memory, mem-min, and mem-max, to the domain node device
tree parsing to define the memory allocation for a domain. All three fields are
expressed in kb and written as a u64 in the device tree entries.
Signed-off-by: Daniel P. Smith
---
Changes since v1
- moved common fdt par
If a command line is not provided through the bootloader's mechanism, e.g.
muiltboot module string field, then use one from the device tree if present.
The device tree command line is located in the bootargs property of the
`multiboot,kernel` node.
Signed-off-by: Daniel P. Smith
Reviewed-by: Jaso
Hyperlaunch domain builder will be the consolidated boot time domain building
logic framework. Introduces the config option to enable this domain builder to
and turn on the ability to load the domain configuration via a flattened device
tree.
Signed-off-by: Daniel P. Smith
---
Changes since v1:
-
Look for a subnode of type `multiboot,kernel` within a domain node. If found,
process the reg property for the MB1 module index. If the bootargs property is
present and there was not an MB1 string, then use the command line from the
device tree definition.
Signed-off-by: Daniel P. Smith
Reviewed-
Introduce the domain builder which is capable of consuming a device tree as the
first boot module. If it finds a device tree as the first boot module, it will
set its type to BOOTMOD_FDT. This change only detects the boot module and
continues to boot with slight change to the boot convention that t
Enable selecting the mode in which the domain will be built and ran. This
includes:
- whether it will be either a 32/64 bit domain
- if it will be run as a PV or HVM domain
- and if it will require a device model (not applicable for dom0)
In the device tree, this will be represented as a bit map
Look for a subnode of type `multiboot,ramdisk` within a domain node. If
found, process the reg property for the MB1 module index.
Signed-off-by: Daniel P. Smith
---
Changes since v1:
- switch to nested else/if
- dropped ternary name selection
---
xen/arch/x86/domain-builder/fdt.c | 26 ++
Introduce the ability to specify the desired domain id for the domain
definition. The domain id will be populated in the domid property of the domain
node in the device tree configuration.
Signed-off-by: Daniel P. Smith
---
Changes since v1
- coding style changes
- moved comment with code movemen
Add a container for the "cooked" command line for a domain. This provides for
the backing memory to be directly associated with the domain being constructed.
This is done in anticipation that the domain construction path may need to be
invoked multiple times, thus ensuring each instance had a disti
Currently, the inclusion of libfdt is controlled by the CONFIG_HAS_DEVICE_TREE
kconfig flag. This flag also changes behavior in a few places, such as boot
module processing for XSM. To support the ability to include libfdt without
changing these behaviors, introduce CONFIG_LIB_DEVICE_TREE. The incl
The Hyperlaunch device tree for dom0 series is the second split out for the
introduction of the Hyperlaunch domain builder logic. These changes focus on
introducing the ability to express a domain configuration that is then used to
populate the struct boot_domain structure for dom0. This ability to
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
Reviewed-by: J
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.
Add a kernel and ramdisk boo
On 12/11/24 12:59, Daniel P. Smith wrote:
On 11/25/24 19:03, Jason Andryuk wrote:
On 2024-11-23 13:20, Daniel P. Smith wrote:
Add three properties, memory, mem-min, and mem-max, to the domain
node device
tree parsing to define the memory allocation for a domain. All three
fields are
expressed
18 matches
Mail list logo
