Hi Julien,
On 28/11/2023 18:52, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 28/11/2023 18:15, Michal Orzel wrote:
>>
>>
>> On 28/11/2023 18:09, Julien Grall wrote:
>>>
>>>
>>> On 28/11/2023 18:00, Michal Orzel wrote:
>&
On 28/11/2023 18:15, Andrew Cooper wrote:
>
>
> On 27/11/2023 2:41 pm, Michal Orzel wrote:
>> diff --git a/xen/common/ubsan/ubsan.c b/xen/common/ubsan/ubsan.c
>> index a3a80fa99eec..dd5ee0013648 100644
>> --- a/xen/common/ubsan/ubsan.c
>> +++ b/xen/common/u
On 28/11/2023 18:09, Julien Grall wrote:
>
>
> On 28/11/2023 18:00, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 28/11/2023 17:14, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 27/11/2023 15:41, Michal Orzel wrote:
Hi Julien,
On 28/11/2023 17:14, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 27/11/2023 15:41, Michal Orzel wrote:
>> Introduce the CONFIG_UBSAN_FATAL option to cater to scenarios where prompt
>> attention to undefined behavior issues, notably during CI test runs, is
Hi Luca,
On 28/11/2023 11:36, Luca Fancellu wrote:
>
>
>> On 24 Nov 2023, at 09:59, Luca Fancellu wrote:
>>
>> + CC Maintainers
>>
>>> On 24 Nov 2023, at 09:48, Luca Fancellu wrote:
>>>
>>> This serie aims to add more modularity to some feature that can be excluded
>>> without issues from the
Introduce the CONFIG_UBSAN_FATAL option to cater to scenarios where prompt
attention to undefined behavior issues, notably during CI test runs, is
essential. When enabled, this option causes Xen to panic upon detecting
UBSAN failure (as the last step in ubsan_epilogue()).
Signed-off-by: Michal
Hi,
On 17/11/2023 13:24, Oleksii Kurochko wrote:
>
>
> is common between Arm, PPC and RISC-V so it is
> moved to asm-generic.
>
> Signed-off-by: Oleksii Kurochko
Reviewed-by: Michal Orzel
~Michal
@@
> -#ifndef __ARCH_ARM_NUMA_H
> -#define __ARCH_ARM_NUMA_H
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ARCH_GENERIC_NUMA_H
> +#define __ARCH_GENERIC_NUMA_H
ASM_GENERIC ?
>
> -#include
> +#include
If this is for mfn_t, shouldn't this inclusion be moved under #ifndef ?
Apart from that:
Reviewed-by: Michal Orzel
~Michal
include/asm/altp2m.h
> b/xen/arch/arm/include/asm/altp2m.h
> deleted file mode 100644
> index df50cb2f09..00
> --- a/xen/arch/arm/include/asm/altp2m.h
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -/*
> - * Alternate p2m
> - *
> - * Copyright (c) 2014, Intel Corporation.
Shouldn't this copyright be moved to generic header as well?
Apart from that:
Reviewed-by: Michal Orzel
~Michal
tests with UBSAN enabled Xen, which would otherwise fail due to
incorrect image placement resulting in overlapping.
Signed-off-by: Michal Orzel
---
Before adding UBSAN CI tests, we still need to decide if we want to add support
to panic on UBSAN epilogue guarded by some config option or to just grep
it.
>
> Where spotted, fix code style issues.
>
> No functional change is intended.
>
> Signed-off-by: Luca Fancellu
> Reviewed-by: Michal Orzel
> ---
> Changes from v5:
> - remove unneeded include (Michal)
Including asm/kernel.h was indeed not required. Howev
be used by the function construct_dom0 instead of using directly
> process_shm, allowing some #ifdef to be removed.
>
> No functional changes are intended.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
~Michal
Hi Ayan,
On 22/11/2023 20:00, Ayan Kumar Halder wrote:
> Hi Amit/All,
>
> We came across this scenario and would be helpful if you can provide
> some pointers
>
>
> Linux running as Dom0 on Xen hypervisor with HVC_DCC = y and HVC_XEN = y
> on Arm64 platform.
>
> This causes a crash when
Hi,
On 21/11/2023 19:43, Julien Grall wrote:
>
>
> Hi,
>
> On 21/11/2023 18:13, Michal Orzel wrote:
>> On 21/11/2023 17:30, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 21/11/2023 09:45, Michal Orzel wrote:
>&g
Hi,
On 21/11/2023 19:31, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 17:18, Michal Orzel wrote:
>>
>>
>> On 21/11/2023 18:04, Julien Grall wrote:
>>>
>>>
>>> On 21/11/2023 17:00, Michal Orzel wrote:
>>>>
Hi Julien,
On 21/11/2023 17:30, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> Macros load_paddr and adr_l are equivalent when used before the MMU is
>> enabled, resulting in obtaining physical address of a symbol. The
On 21/11/2023 18:04, Julien Grall wrote:
>
>
> On 21/11/2023 17:00, Michal Orzel wrote:
>> Hi Julien,
>
> Hi,
>
>> On 21/11/2023 17:09, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 21/11/2023 09:45, Mic
Hi Julien,
On 21/11/2023 17:16, Julien Grall wrote:
>
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> Macro print_reg is used to print a value of a register passed as an
>> argument. While today it is only used from within the common head.S,
>> in the future we might
Hi Julien,
On 21/11/2023 17:09, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 21/11/2023 09:45, Michal Orzel wrote:
>> At the moment, the 'hex' string is placed right after the 'putn'
>> function in the .text section. This is because of the limited range
>&
Some cleanup and improvements for the assembly boot code to make the behavior
more consistent between arm32 and arm64.
Michal Orzel (3):
xen/arm64: head: Move earlyprintk 'hex' string to .rodata.str
xen/arm64: Move print_reg macro to asm/arm64/macros.h
xen/arm64/mmu: head: Replace
the earlyprintk messages will be part of .rodata
and the behavior will be consistent with what we already do on arm32.
Signed-off-by: Michal Orzel
---
xen/arch/arm/arm64/head.S | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64
load_paddr/adr_l is consistent between
arm32 and arm64, making it easier for developers to determine which one
to use and when.
Take the opportunity to fix a comment with incorrect function name.
Signed-off-by: Michal Orzel
---
xen/arch/arm/arm64/mmu/head.S | 8
1 file changed, 4
.
This way the behavior will be consistent with what we already do on arm32.
Signed-off-by: Michal Orzel
---
xen/arch/arm/arm64/head.S | 32 -
xen/arch/arm/include/asm/arm64/macros.h | 15
2 files changed, 19 insertions(+), 28 deletions(-)
diff
o retrieve the effective image size. Use this
value in add_size(), whenever it's bigger than the one obtained using
'stat -L'.
Signed-off-by: Michal Orzel
---
This patch together with 'bootz' support will allow us to enable testing Xen
on arm{32,64} in gitlab CI with UBSAN enabled.
---
scripts/uboot-scrip
Hi Julien,
On 20/11/2023 14:40, Julien Grall wrote:
>
>
> On 20/11/2023 07:34, Michal Orzel wrote:
>> Hi Luca,
>>
>> On 14/11/2023 10:03, Luca Fancellu wrote:
>>>
>>>
>>> Currently the dom0less feature code is mostly inside domain_build.c
&
+static inline void create_domUs(void) {}
> +static inline bool is_dom0less_mode(void)
> +{
> +return false;
> +}
> +
> +#endif /* CONFIG_DOM0LESS_BOOT */
> +
> #endif /* __ASM_DOM0LESS_BUILD_H_ */
>
> /*
> diff --git a/xen/arch/arm/include/asm/domain_build.h
> b/xen/arch/arm/include/asm/domain_build.h
> index da9e6025f37c..6df61fa1d587 100644
> --- a/xen/arch/arm/include/asm/domain_build.h
> +++ b/xen/arch/arm/include/asm/domain_build.h
> @@ -6,8 +6,10 @@
>
> typedef __be32 gic_interrupt_t[3];
>
> +#ifdef CONFIG_DOM0LESS_BOOT
AFAICT, guarding prototypes is not needed and we opt to avoid it. I'd remove it.
The remarks can be handled on commit (depending on the conflict with Henry's
series)
Reviewed-by: Michal Orzel
~Michal
by the function construct_dom0 instead of using directly
> process_shm, allowing some #ifdef to be removed.
>
> No functional changes are intended.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
~Michal
> Where spotted, fix code style issues.
>
> No functional change is intended.
>
> Signed-off-by: Luca Fancellu
Reviewed-by: Michal Orzel
with one remark...
> ---
> Changes from v4:
> - fixed name in inclusion macro __ASM_* instead of __ARM_*, fixed
>em
the assembly macros shared by head.S and mmu/head.S to
> macros.h.
>
> This is based on 6734327d76be ("xen/arm64: Split and move MMU-specific head.S
> to mmu/head.S").
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
with a few remarks...
> ---
>
> C
lated to MMU in MMU specific
> file and in order to support non MMU cpus in future.
>
> This is based on d2f8df5b3ede ("xen/arm64: head.S: Introduce
> enable_{boot,secondary}_cpu_mm()").
>
> Signed-off-by: Ayan Kumar Halder
> Reviewed-by: Michal Orzel
> Acked-by: Ju
without Linux kernel Image/zImage header. Otherwise, we can
use 'booti'/'bootz'.
Signed-off-by: Michal Orzel
---
README.md| 4 ++--
scripts/uboot-script-gen | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/README.md b/README.md
index fe5d2052cc69..3b4b16f1f7e4
Hi Luca,
On 13/11/2023 15:17, Luca Fancellu wrote:
>
>
>> On 13 Nov 2023, at 11:58, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> Apart from pending question on static event channels code movement, a few
>> NITs.
>
> Related to that, it seems t
Hi Luca,
Apart from pending question on static event channels code movement, a few NITs.
On 13/11/2023 10:08, Luca Fancellu wrote:
>
>
> Currently the dom0less feature code is mostly inside domain_build.c
> and setup.c, it is a feature that may not be useful to everyone so
> put the code in a
Hi Julien,
On 10/11/2023 10:27, Julien Grall wrote:
>
>
> Hi Stefano,
>
> On 10/11/2023 01:44, Stefano Stabellini wrote:
>> Reported-by: Brian Woods
>> Signed-off-by: Stefano Stabellini
>>
>> diff --git a/scripts/uboot-script-gen b/scripts/uboot-script-gen
>> index b284887..6e52da5 100755
>>
Hi,
On 10/11/2023 10:30, Luca Fancellu wrote:
>
>
>> On 10 Nov 2023, at 09:05, Luca Fancellu wrote:
>>
>> Hi Michal,
>>
+config DOM0LESS_BOOT
+ bool "Dom0less boot support" if EXPERT
+ depends on ARM
>>> You're in the Arm Kconfig, so there should be no need for
Hi Luca,
On 09/11/2023 10:06, Luca Fancellu wrote:
>
>
> Introduce a Kconfig for the dom0less feature, enabled by default,
> to be able to choose if the feature should be compiled or not.
>
> Provide static inline stubs when the option is disabled for the
> functions externally visible.
>
>
Hi Stefano,
On 10/11/2023 02:44, Stefano Stabellini wrote:
>
>
> Reported-by: Brian Woods
> Signed-off-by: Stefano Stabellini
Reviewed-by: Michal Orzel
~Michal
Hi Luca,
On 09/11/2023 10:06, Luca Fancellu wrote:
>
>
> Move static memory and static shared memory code in separate modules
> so that they are included only when the corresponding feature is
> enabled, doing that we modularise the features and we remove some
> ifdefs from the code to improve
Hi Luca,
On 09/11/2023 10:06, Luca Fancellu wrote:
>
>
> Currently the dom0less feature code is mostly inside domain_build.c
> and setup.c, it is a feature that may not be useful to everyone so
> put the code in a different compilation module in order to make it
> easier to disable the feature
Hi Ayan,
On 07/11/2023 12:02, Ayan Kumar Halder wrote:
>
>
> The MMU specific code in head.S will not be used on MPU systems.
> Instead of introducing more #ifdefs which will bring complexity
> to the code, move MMU related code to mmu/head.S and keep common
> code in head.S. Two notes while
lated to MMU in MMU specific
> file and in order to support non MMU cpus in future.
>
> This is based on d2f8df5b3ede ("xen/arm64: head.S: Introduce
> enable_{boot,secondary}_cpu_mm()").
>
> Signed-off-by: Ayan Kumar Halder
> Reviewed-by: Michal Orzel
> Acked-by: Ju
g:
void *foo = (void *)__UINTPTR_MAX__;
foo += 1;
UBSAN:
pointer operation underflowed to
Fixes: 4e3fb2fb47d6 ("ubsan: add clang 5.0 support")
Signed-off-by: Michal Orzel
---
xen/common/ubsan/ubsan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/com
Add it to the list next to other Arm serial drivers, so it does not fall
back to THE REST.
Signed-off-by: Michal Orzel
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a5a5f2bffb24..0fcf5a6f3671 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
Hi Ayan,
On 03/11/2023 18:34, Ayan Kumar Halder wrote:
>
>
> The MMU specific code in head.S will not be used on MPU systems.
> Instead of introducing more #ifdefs which will bring complexity
> to the code, move MMU related code to mmu/head.S and keep common
> code in head.S. Two notes while
u_mm:
> +mov r6, lr
> +
> +blcreate_page_tables
> +
> + /* Address in the runtime mapping to jump to after the MMU is
> enabled */
> +mov_w lr, 1f
> +b enable_mmu
> +1:
> +/* Return to the virtual address requested by the caller. */
I find this comment a bit misleading as it reads as if this instruction was
causing a return.
Apart from that, this change LGTM. Depending on the order of other arm32 head.S
patches:
Reviewed-by: Michal Orzel
~Michal
Hi Julien,
On 02/11/2023 00:30, Julien Grall wrote:
>
>
> From: Julien Grall
>
> The sequence to enable the MMU on arm32 is quite complex as we may need
> to jump to a temporary mapping to map Xen.
>
> Recently, we had one bug in the logic (see f5a49eb7f8b3 ("xen/arm32:
> head: Add mising
e_mapping_entry xen_fixmap, r0, r11, type=PT_DEV_L3
When building this patch, I'm getting a "Bad instruction" build error.
Quick look shows that you are trying to use the macro create_mapping_entry
before macro definition.
Unless, I'm using a different baseline (latest staging) than you, this needs to
be fixed.
Apart from that:
Reviewed-by: Michal Orzel
~Michal
887,6 @@ ENTRY(lookup_processor_type)
> * the __proc_info lists since we aren't running with the MMU on (and
> therefore,
> * we are not in correct address space). We have to calculate the offset.
In v2, I mentioned that this comment needs to be tweaked as well. We no longer
use load_paddr
thus we don't care about the offset. I would remove the comment starting from
"Note that...".
to avoid confusion or add a proper explanation if you want to keep it.
With that addressed:
Reviewed-by: Michal Orzel
~Michal
Hi Ayan,
On 26/10/2023 13:19, Julien Grall wrote:
>
>
> Hi,
>
> Title: This reads as you replace all adr_l with load_paddr. So how about:
>
> xen/arm32: head: Replace load_paddr with adr_l when they are equivalent
>
> On 26/10/2023 12:12, Ayan Kumar Halder wrote:
>> Before the MMU is turned
Hi Julien,
On 26/10/2023 10:40, Julien Grall wrote:
>
>
> Hi,
>
> On 25/10/2023 18:59, Michal Orzel wrote:
>> Hi Ayan,
>>
>> On 25/10/2023 19:03, Ayan Kumar Halder wrote:
>>> Before the MMU is turned on, the address returned for any symbol will
>
On 26/10/2023 09:22, Jun Nie wrote:
>
>
> Michal Orzel 于2023年10月26日周四 15:02写道：
>>
>> Hi,
>>
>> On 26/10/2023 07:46, Jun Nie wrote:
>>>
>>>
>>> Signed-off-by: Jun Nie
>>> ---
>>> xen/arch/arm/Kconfig.debug |
Hi,
On 26/10/2023 07:46, Jun Nie wrote:
>
>
> Signed-off-by: Jun Nie
> ---
> xen/arch/arm/Kconfig.debug | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kconfig.debug
> index 842d768280..fefe8ac4df 100644
> ---
Hi Ayan,
On 25/10/2023 19:03, Ayan Kumar Halder wrote:
> Before the MMU is turned on, the address returned for any symbol will always
> be
> physical address. Thus, one can use adr_l instead of load_paddr.
>
> create_table_entry() now takes an extra argument to denote if it is called
> after
>
On 25/10/2023 11:26, Jan Beulich wrote:
>
>
> On 25.10.2023 11:21, Michal Orzel wrote:
>> On 25/10/2023 11:10, Jan Beulich wrote:
>>> On 25.10.2023 10:28, Michal Orzel wrote:
>>>> At the moment, in order to use a different defconfig target tha
Hi,
On 25/10/2023 11:10, Jan Beulich wrote:
>
>
> On 25.10.2023 10:28, Michal Orzel wrote:
>> At the moment, in order to use a different defconfig target than default,
>> one needs to specify KBUILD_DEFCONFIG= on the command line.
>> Switch to weak assignment, so t
of KBUILD_DEFCONFIG variable in CI
build jobs that so far had no effect.
Note, that we will deviate from Linux in this regard.
Signed-off-by: Michal Orzel
---
In case of reluctance to this approach, we can always do:
make -C xen defconfig KBUILD_DEFCONFIG=${KBUILD_DEFCONFIG}
in automation/scripts/build
ows:
> +
> + Xen binary should be loaded in memory below 2 TiB.
> +
> There are no exception on 64-bit ARM.
This sentence needs to be dropped then.
With that:
Reviewed-by: Michal Orzel
~Michal
Hi Stefano,
Thanks!
On 23/10/2023 22:56, Stefano Stabellini wrote:
>
>
> Signed-off-by: Stefano Stabellini
Acked-by: Michal Orzel
~Michal
necessarily an iommus
>> property. In this case, we want to treat it the same as we currently handle
>> devices with an iommus property: don't pass the iommu related properties to
>> hwdom.
>>
>> [1]
>> https://www.kernel.org/doc/Documentation/devicetree/bindings/pci/pci
Hi,
On 18/10/2023 15:29, Jan Beulich wrote:
>
>
> On 18.10.2023 12:38, Manuel Bouyer wrote:
>> Hello,
>> With Xen 4.18, a PV domain running under pvshim doesn't get console input.
>> This is because the domain id in pvshim isn't 0 (and on x86 max_init_domid is
>> hardwired to 0), so
d with
> adr_l(). With that, load_paddr() can now be moved in arm64/mmu/head.S.
>
> For now, x20 is still unconditionally set. But this could change
> in the future if needed.
>
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
Side note:
Looking at all the uses of l
guest issues (e.g. trap on attempt to access MMIO
not mapped in P2M). Fix it.
Fixes: 669ecdf8d6cd ("xen/arm: copy dtb fragment to guest dtb")
Signed-off-by: Michal Orzel
---
@Henry:
This is a bug fix, so I think we should have it in 4.18 given the possible
consequences I described in
o
> prepare/enable/disable")
I don't think a fixes tag applies here given that 2TB was just a number we
believed is enough
and all of this is platform dependent. This can be dropped on commit if
committer agrees.
> Reported-by: Alexey Klimov
> Signed-off-by: Leo Yan
Reviewed-by: Michal Orzel
~Michal
disabled memory regions sent to the kernel and the kernel
> cannot use the disabled memory nodes any longer.
>
> Since this patch adds checking device node's status in the
> device_tree_get_meminfo() function, except it checks for memory nodes
> and reserved memory nodes, it also su
Hi Julien, Henry,
On 10/10/2023 16:48, Julien Grall wrote:
>
>
> (+ Henry)
>
> Hi Michal,
>
> On 29/09/2023 08:38, Julien Grall wrote:
>> Hi Michal,
>>
>> On 28/09/2023 13:34, Michal Orzel wrote:
>>> Generic timer dt node property "clock
The list is out of date and does not specify all the hypercalls/sub-ops
we support, so update it.
Signed-off-by: Michal Orzel
Release-acked-by: Henry Wang
Acked-by: Julien Grall
---
Changes in v2:
- explicitly list dm_op sub-ops
- add Julien's Ab, Henry's Rab
---
xen/include/public/arch
Hello,
On 06/10/2023 14:31, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 06/10/2023 11:20, Michal Orzel wrote:
>> On 06/10/2023 12:11, Julien Grall
Hi Julien,
On 06/10/2023 12:11, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 06/10/2023 08:51, Michal Orzel wrote:
>> The list is out of date and does not specify all the hypercalls/sub-ops
>> we support, so update it.
>>
>> Signed-off-by: Michal Orzel
&g
Hi Julien,
On 06/10/2023 11:43, Julien Grall wrote:
>
>
> On 05/10/2023 21:15, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 05/10/2023 18:54, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
>&
The list is out of date and does not specify all the hypercalls/sub-ops
we support, so update it.
Signed-off-by: Michal Orzel
---
xen/include/public/arch-arm.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch
Update public headers and hypercall-abi doc as a consequence of commit
2f531c122e95 ("x86: limit number of hypercall parameters to 5").
Signed-off-by: Michal Orzel
---
docs/guest-guide/x86/hypercall-abi.rst | 8
xen/include/public/arch-x86/xen-x86_32.h | 2 +-
xen/include/p
Update hypercalls related docs before the release to avoid confusion.
@Henry:
Updating docs has no risks and is beneficial for the users, so it would be
good to have it in 4.18.
Michal Orzel (2):
x86: Clarify that up to 5 hypercall parameters are supported
xen/public: arch-arm: Update list
Hi Julien,
On 05/10/2023 18:54, Julien Grall wrote:
>
>
> From: Julien Grall
>
> Per ACPI 6.5 section 5.2.25 ("Generic Timer Description Table (GTDT)"),
> the fields "Secure EL1 Timer GSIV/Flags" are optional and an OS running
> in non-secure world is meant to ignore the values.
>
> However,
Hi Luca,
On 03/10/2023 09:44, Luca Fancellu wrote:
>
>
> Given that code movement is painful from a git history perspective, and
> given that we have to move dom0less code to xen/common anyway to make
> it available to RISC-V and also x86, could we do it in one shot here?
On 03/10/2023 09:28, Michal Orzel wrote:
>
>
> Hi Oleg, Stefano
>
> On 03/10/2023 02:13, Stefano Stabellini wrote:
>> Hi Oleg,
>>
>> You are getting this output:
>>
>>> (XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
&g
Hi Oleg, Stefano
On 03/10/2023 02:13, Stefano Stabellini wrote:
> Hi Oleg,
>
> You are getting this output:
>
>> (XEN) d0v0 Forwarding AES operation: 3254779951 136bb000 ->
>> f000
>
> Which means that the guest physical address is 0x136bb000 and
> the translated
Hi Leo,
On 28/09/2023 16:37, Leo Yan wrote:
>
>
> Hi Michal, Julien,
>
> On Wed, Sep 27, 2023 at 02:49:23PM +0200, Michal Orzel wrote:
>
> [...]
>
>> Either way is fine. The advantage of placing the check in boot_fdt_info() is
>> that we can have a singl
function, except it checks for memory nodes
> and reserved memory nodes, it also supports status for static memory
> and static heap.
>
> Suggested-by: Michal Orzel
> Signed-off-by: Leo Yan
> ---
>
> Changes from v1:
> - Renamed function to device_tree_node_
ven further, we operate
under assumption that the frequency must be at least 1KHz (i.e. cpu_khz
not 0) in order for Xen to boot. Therefore, introduce a new helper
validate_timer_frequency() to verify this assumption and use it to check
the frequency obtained either from dt property or from sysreg.
Signed
Hi Julien,
On 27/09/2023 13:01, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 26/09/2023 09:36, Michal Orzel wrote:
>> On 26/09/2023 07:33, Leo Yan wrote:
>>>
>>>
>>> During the Linux kernel booting, an error is reported by the Xen
>>&g
Hi Luca,
On 26/09/2023 11:52, Luca Fancellu wrote:
>
>
>> On 26 Sep 2023, at 06:33, Leo Yan wrote:
>>
>> During the Linux kernel booting, an error is reported by the Xen
>> hypervisor:
>>
>> (XEN) arch/arm/p2m.c:2202: d0v0: Failing to acquire the MFN 0x1a02dc
>>
>> The kernel attempts to use
Hello,
On 26/09/2023 07:33, Leo Yan wrote:
>
>
> During the Linux kernel booting, an error is reported by the Xen
> hypervisor:
>
> (XEN) arch/arm/p2m.c:2202: d0v0: Failing to acquire the MFN 0x1a02dc
>
> The kernel attempts to use an invalid memory frame number, which can be
> converted
On 19/09/2023 12:21, Jan Beulich wrote:
>
>
> On 19.09.2023 11:53, GitLab wrote:
>>
>>
>> Pipeline #1009404353 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/xen )
>> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>>
>> Commit: ea36ac0d (
>>
Hello,
On 20/09/2023 12:03, Leo Yan wrote:
>
>
> Hi Julien,
>
> On Mon, Sep 18, 2023 at 08:26:21PM +0100, Julien Grall wrote:
>
> [...]
>
>> ... from my understanding reserved-memory are just normal memory that are
>> set aside for a specific purpose. So Xen has to create a 'memory' node
Hi Stewart,
On 13/09/2023 15:31, Stewart Hildebrand wrote:
> On 9/13/23 03:27, Michal Orzel wrote:
>> Hi Stewart,
>>
>> On 12/09/2023 22:43, Stewart Hildebrand wrote:
>>> There is a corner case where the filesizes of the xen and Linux kernel
>>> images
or the presence of an arm64 kernel image header, and get the effective
> image size from the header. Use the effective image size for calculating the
> next load address and for populating the size in the /chosen/dom*/reg
> property.
>
> Signed-off-by: Stewart Hildebrand
The patch work
dt binding in place.
Signed-off-by: Michal Orzel
---
Changes in v2:
- update commit msg with better reasoning
---
xen/arch/arm/domain_build.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 29dcbb8a2ee6.
Hi Julien,
On 12/09/2023 12:03, Julien Grall wrote:
>
>
> On 11/09/2023 16:09, Michal Orzel wrote:
>>
>>
>> On 11/09/2023 16:48, Julien Grall wrote:
>>> Caution: This message originated from an External Source. Use proper
>>> caution when openi
Hi Stefano,
On 12/09/2023 01:21, Stefano Stabellini wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Mon, 11 Sep 2023, Michal Orzel wrote:
>> On 11/09/2023 16:4
On 11/09/2023 16:48, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 11/09/2023 15:01, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 11/
Hi Julien,
On 11/09/2023 15:14, Julien Grall wrote:
>
>
> Hi,
>
> On 11/09/2023 13:34, Michal Orzel wrote:
>> Host device tree nodes under /chosen with compatible string
>> "xen,evtchn-v1", "xen,domain-shared-memory-v1" are Xen specific an
Host device tree nodes under /chosen with compatible string
"xen,evtchn-v1", "xen,domain-shared-memory-v1" are Xen specific and not
meant to be exposed to hardware domain. The same applies to
"xen,static-heap" property. Skip them from being included into hwdom
/chose
Hi Penny,
On 11/09/2023 12:39, Penny Zheng wrote:
>
>
> Hi Michal
>
> On 2023/9/11 17:40, Michal Orzel wrote:
>> Hi Penny,
>>
>> On 11/09/2023 06:04, Penny Zheng wrote:
>>>
>>>
>>> In case there is a /reserved-memory node already pre
Hi Penny,
On 11/09/2023 06:04, Penny Zheng wrote:
>
>
> In case there is a /reserved-memory node already present in the host dtb,
> current Xen codes would create yet another /reserved-memory node specially
s/codes/code/
> for the static shm in Dom0 Device Tree.
>
> Xen will use
Hi Penny,
On 11/09/2023 06:04, Penny Zheng wrote:
>
>
> Function parameters {addr_cells,size_cells} are stale parameters in
> assign_shared_memory, so we shall remove them.
>
> Signed-off-by: Penny Zheng
Reviewed-by: Michal Orzel
~Michal
Hi Penny,
On 11/09/2023 06:04, Penny Zheng wrote:
>
>
> There are some unsolving issues on current 4.17 static shared memory
> feature[1], including:
> - In order to avoid keeping growing 'membank', having the shared memory
> info in separate structures is preferred.
> - Missing implementation
it.
Take the opportunity to switch to %pd specifier to print domain id in
a consolidated way.
Fixes: 7e5c4a8b86f1 ("xen/arm: Implement device tree node removal
functionalities")
Signed-off-by: Michal Orzel
---
After this patch (and the one for xl), we are left with one issue breaking
On 06/09/2023 10:42, Jan Beulich wrote:
>
>
> On 06.09.2023 10:36, Michal Orzel wrote:
>> main_dt_overlay() makes a call to libxl_dt_overlay() which is for now
>> only compiled for Arm. This causes the build failure as reported by
>> gitlab CI and OSSTEST. Fix
guard so that the code will not need to be modified again
if other architecture gain support for this feature.
Fixes: 61765a07e3d8 ("tools/xl: Add new xl command overlay for device tree
overlay support")
Reported-by: Jan Beulich
Signed-off-by: Michal Orzel
---
There are still other p
On 06/09/2023 09:57, Jan Beulich wrote:
>
>
> On 06.09.2023 09:32, Michal Orzel wrote:
>>
>>
>> On 06/09/2023 08:55, Jan Beulich wrote:
>>>
>>>
>>> On 06.09.2023 03:16, Vikram Garhwal wrote:
>>>> --- a/tools/xl/xl_vmcontrol.c
201 - 300 of 1233 matches
Mail list logo
