Hi Stefano,
On Tue, 4 Feb 2025 at 17:57, Stefano Stabellini
wrote:
> On Tue, 4 Feb 2025, Julien Grall wrote:
> > On Tue, 4 Feb 2025 at 11:46, Teddy Astie wrote:
> > If the hardware supports it, there is a alternative (still being
> > drafted) interface
On Tue, 4 Feb 2025 at 11:46, Teddy Astie wrote:
> If the hardware supports it, there is a alternative (still being
> drafted) interface to allow the guest to directly provide native
> pagetables.
>
> This is exposed through the "_nested" subcommands, there is no
> implementation of this feature i
On Wed, 29 Jan 2025 at 12:49, Bertrand Marquis
wrote:
> Hi Julien,
>
> Welcome back :-)
I am not fully back yet but I have a bit of spare time to go through
xen-devel :).
>
> > On 29 Jan 2025, at 16:33, Julien Grall
> wrote:
> >
> > Hi,
> >
>
Hi,
On Tue, 14 Jan 2025 at 16:50, Ayan Kumar Halder
wrote:
> We have written the requirements for some of the commands of the
> XEN_VERSION
> hypercall.
>
> Signed-off-by: Ayan Kumar Halder
> ---
> .../design-reqs/arm64/version_hypercall.rst | 33
> .../reqs/design-reqs/version_hype
of the former, are equally aligned. Therefore modify the check to
> compare alignments obtained via alignof not to rely on hardcoded
> values.
>
> Fixes: 2209c1e35b47 ("xen/arm: Introduce a generic way to access memory
> bank structures")
> Signed-off-by: Michal Orzel
>
Hi Michal,
On Mon, 27 Jan 2025 at 14:15, Michal Orzel wrote:
> > I think it needs to be rephrased to make clear the alignment of struct
> membanks should be the same as struct membank.
> Shouldn't this check therefore be changed to:
> BUILD_BUG_ON(alignof(struct membanks) != alignof(struct memb
On Mon, 27 Jan 2025 at 09:52, Michal Orzel wrote:
>
>
> On 27/01/2025 12:19, Julien Grall wrote:
> >
> >
> >
> >
> >
> > On Mon, 27 Jan 2025 at 07:46, Michal Orzel <mailto:michal.or...@amd.com>> wrote:
> >
> > On Arm32
On Mon, 27 Jan 2025 at 07:46, Michal Orzel wrote:
> On Arm32, when CONFIG_PHYS_ADDR_T_32 is set, a build failure is observed:
> common/device-tree/bootfdt.c: In function 'build_assertions':
> ./include/xen/macros.h:47:31: error: static assertion failed:
> "!(alignof(struct membanks) != 8)"
>4
ly.
Marco, Michal, can you have a look? Ideally, this should be fixed for 4.20.
Cheers,
--
Julien Grall
Hi,
Replying your last two replies in the same thread.
On 24/12/2024 03:41, Sergiy Kibrik wrote:
18.12.24 12:05, Julien Grall:
> yes, I had to assign devices to hardware domain manually.
I think it would be easier for the user to say "This is my hardware
domain" and let Xen a
Hi Michal,
On 23/12/2024 11:43, Michal Orzel wrote:
On 23/12/2024 11:45, Julien Grall wrote:
Hi,
On 23/12/2024 10:42, Michal Orzel wrote:
On 23/12/2024 11:06, Julien Grall wrote:
Hi Michal,
On 23/12/2024 07:58, Michal Orzel wrote:
On 20/12/2024 16:19, Luca Fancellu wrote
Hi,
On 23/12/2024 10:42, Michal Orzel wrote:
On 23/12/2024 11:06, Julien Grall wrote:
Hi Michal,
On 23/12/2024 07:58, Michal Orzel wrote:
On 20/12/2024 16:19, Luca Fancellu wrote:
Commit a14593e3995a ("xen/device-tree: Allow region overlapping with
/memreserve/ ranges") in
d argue it needs a fixes tag (even though this is a
latent bug) or at least a backport request.
Cheers,
--
Julien Grall
On 18/12/2024 10:05, Julien Grall wrote:
On 18/12/2024 09:52, Sergiy Kibrik wrote:
hi Julien,
17.12.24 14:42, Julien Grall:
Hi,
Can you clarify why this is an RFC?
The code for LATE_HWDOM support on ARM seems to be already in place
and working, yet I'm not sure that
On 18/12/2024 09:52, Sergiy Kibrik wrote:
hi Julien,
17.12.24 14:42, Julien Grall:
Hi,
Can you clarify why this is an RFC?
The code for LATE_HWDOM support on ARM seems to be already in place and
working, yet I'm not sure that such configuration is ready to be exposed
for users
p
Allows the creation of a dedicated hardware domain distinct from
domain 0 that manages devices without needing access to other
Cheers,
--
Julien Grall
On 16/12/2024 08:06, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 13 Dec 2024, at 23:57, Julien Grall wrote:
Hi Bertrand,
On 27/11/2024 16:07, Bertrand Marquis wrote:
Create a bitmap to store which feature is supported or not by the
firmware and use it to filter which calls are
r <<
GITS_BASER_OUTER_CACHEABILITY_SHIFT;
-base_attr |= GIC_BASER_CACHE_RaWaWb << GITS_BASER_INNER_CACHEABILITY_SHIFT;
+base_attr |= gicv3_its_get_cacheability() <<
GITS_BASER_INNER_CACHEABILITY_SHIFT;
its->cbaser = base_attr;
base_attr |= 0ULL << GITS_BASER_PAGE_SIZE_SHIFT;/* 4K pages */
[...]
--
Julien Grall
committing): s/reoder/reorder
Cheers,
--
Julien Grall
t are not permitted to use IOMMU.
Signed-off-by: Michal Orzel
With one remark below:
Acked-by: Julien Grall
---
This is a prerequisite patch for LLC coloring series patch 3.
For dom0 LLC coloring, we just need to pass resmem and gnttab in mem_banks.
---
xen/arch/arm/domain_build.c
Hi Michal,
On 07/12/2024 15:04, Michal Orzel wrote:
On 06/12/2024 19:37, Julien Grall wrote:
Hi,
Sorry for the late answer.
On 05/12/2024 09:40, Michal Orzel wrote:
On 02/12/2024 17:59, Carlo Nonato wrote:
Cache coloring requires Dom0 not to be direct-mapped because of its non
here I left a comment. This could possibly be handled on
commit.
Cheers,
--
Julien Grall
Hi Andrew,
Reviving this thread as we are preparing for Xen 4.20.
On 16/07/2024 07:57, Jan Beulich wrote:
On 15.07.2024 18:58, Julien Grall wrote:
On 15/07/2024 17:46, Andrew Cooper wrote:
Signed-off-by: Andrew Cooper
With one remark below:
Reviewed-by: Julien Grall
---
CC: Jan
From: Julien Grall
OSSTest was turned off a few weeks ago. So we don't need any steps
related to OSSTest when branching off to a new Xen version.
Signed-off-by: Julien Grall
---
Do we need any specific steps for gitlab CI?
---
docs/process/branching-checklist.txt
From: Julien Grall
Hi all,
As we approach Xen 4.20, update the branching checklist to match
the current state of affair.
Cheers,
Julien Grall (2):
docs/process: branching-checklist: Update the steps to generate the
docs
docs/process: branching-checklist: Remove any reference to
From: Julien Grall
The loop in xenbits-docs-all.sh has been rewritten to use a range rather
than listing all the branch one by one. So update the steps accordingly.
Signed-off-by: Julien Grall
---
docs/process/branching-checklist.txt | 9 -
1 file changed, 4 insertions(+), 5 deletions
o the line
length.
Moved also frametable_virt_end since it is used only on MMU
systems.
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
if ( !mfn_valid(maddr_to_mfn(s)) ||
+ !mfn_valid(maddr_to_mfn(e)) )
+continue;
-mi->nr_mods = 0;
+fw_unreserved_regions(s, e, init_domheap_pages, 0);
+}
-remove_early_mappings();
+mi->nr_mods = 0;
+}
}
Cheers,
--
Julien Grall
series.
Cheers,
--
Julien Grall
ion is not permitted.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Luca Fancellu
Acked-by: Julien Grall
Cheers,
--
Julien Grall
tempt to make the function as generic as possible in the first
iteration:
https://paste.debian.net/1338334/
This looks better, but I wonder why we need still need to exclude the
static regions? Wouldn't it be sufficient to exclude just reserved regions?
For coloring, you could define your own add_free_regions and only pass RSVD and
GNTTAB banks to be excluded.
As said before, I still wait for other Arm maintainers to provide their own
opinion.
~Michal
--
Julien Grall
Hi Carlo,
On 03/12/2024 11:37, Carlo Nonato wrote:
On Tue, Dec 3, 2024 at 11:36 AM Julien Grall wrote:
On 03/12/2024 10:08, Carlo Nonato wrote:
Hi Julien,
On Mon, Dec 2, 2024 at 10:44 PM Julien Grall wrote:
Hi Carlo,
[...]
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm
On Tue, 3 Dec 2024 at 22:00, Andrew Cooper wrote:
>
> On 30/11/2024 1:10 am, Volodymyr Babchuk wrote:
> > diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> > index 2e27af4560..f855e97e25 100644
> > --- a/xen/arch/arm/setup.c
> > +++ b/xen/arch/arm/setup.c
> > @@ -341,6 +342,8 @@ void asml
On 03/12/2024 13:34, Ayan Kumar Halder wrote:
On 02/12/2024 20:53, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 27/11/2024 18:39, Ayan Kumar Halder wrote:
CONFIG_EARLY_UART_SIZE is introduced to let user provide physical
size of
early UART. Unlike MMU where we map a page in the virtual
On 03/12/2024 10:08, Carlo Nonato wrote:
Hi Julien,
On Mon, Dec 2, 2024 at 10:44 PM Julien Grall wrote:
Hi Carlo,
[...]
diff --git a/xen/arch/arm/arm64/mmu/mm.c b/xen/arch/arm/arm64/mmu/mm.c
index 671eaadbc1..3732d5897e 100644
--- a/xen/arch/arm/arm64/mmu/mm.c
+++ b/xen/arch/arm/arm64
On 02/12/2024 15:36, Ayan Kumar Halder wrote:
On 30/11/2024 17:45, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 18/11/2024 12:12, Ayan Kumar Halder wrote:
+/*
+ * Macro to prepare and set a EL2 MPU memory region.
+ * We will also create an according MPU memory region entry, which
+ * is a
style:
}
else if
{
...
}
else
{
...
}
+pte.pt.ro = 1;
+pte.pt.xn = 1;
+} else {
+pte.pt.xn = 1;
+pte.pt.ro = 0;
+}
+
+write_pte(entry, pte);
+}
+
+ /*
+ * We modified live page-tables. Ensure the TLBs are invalidated
+ * before setting enforcing the WnX permissions.
+ */
+flush_xen_tlb_local();
+
+xen_pt_enforce_wnx();
}
Cheers,
--
Julien Grall
Halder
Acked-by: Julien Grall
Cheers,
--
Julien Grall
e 4-3, Armv8 architecture memory types (nGnRE - Corresponds to Device in
Armv7 architecture). Also, it is mapped as outer shareable, RW at EL2 only
I don't quite understand why you mention Armv7 here. The code you modify
below is 64-bit so Armv8 only.
The code itself LGTM.
Cheers,
--
Julien Grall
within the committers on whether we can drop the "or later" for existing
code. So I would suggest to keep the same license.
The rest LGTM.
Cheers,
--
Julien Grall
-by: Julien Grall
Cheers,
--
Julien Grall
Hi Jan,
On 02/12/2024 07:52, Jan Beulich wrote:
On 30.11.2024 18:15, Julien Grall wrote:
On 29/11/2024 22:12, Volodymyr Babchuk wrote:
Jan Beulich writes:
On 29.11.2024 02:49, Volodymyr Babchuk wrote:
--- a/config/arm64.mk
+++ b/config/arm64.mk
@@ -5,6 +5,10 @@ CONFIG_XEN_INSTALL_SUFFIX
Hi Jan,
On 27/11/2024 11:09, Jan Beulich wrote:
On 27.11.2024 11:55, Julien Grall wrote:
From: Julien Grall
All the code in arch/arm32/lib/ where copied from Linux 3.16
and never re-synced since then.
A few years ago, Linux got rid of __memzero() because the implementation
is very similar
ssibly to:
"
output:
sel: Next available index in the MPU
"
I will commit the series once we agree on the wording.
Cheers,
--
Julien Grall
change between compilers. So should we set the triplet properly (e.g.
arch64-arm-none-eabi) or maybe let the user specify it via CROSS_COMPILE?
Regarding -march=armv8-a, if you want to keep it, then I think it should
be outside of the 'if' because this could also apply for GCC.
Cheers,
--
Julien Grall
. I can't see why this can't be appropriate for
toolstack. I.e. what bad can happen when building the toolstack.
In the future, we may want to build the tools for Armv8-M. So I think
the -march should also applies for the toolstack.
Cheers,
--
Julien Grall
() which happens later.
So I think it should be called a bit further down and gain a comment to
about the call dependencies.
Cheers,
--
Julien Grall
ing_static_heap”, @Julien would you be ok with that?
I think using_static_heap() should be defined in xen/mm.h as well
because we expect everyone to use using_static_heap() rather than
static_heap.
This is to avoid adding #ifdef for every user.
Cheers,
--
Julien Grall
ng `select GENERIC_UART_INIT`
to CONFIG_ARM.
Signed-off-by: Oleksii Kurochko
Acked-by: Julien Grall
And committed.
Cheers,
--
Julien Grall
Hi,
On 16/11/2024 10:18, Julien Grall wrote:
On 14/11/2024 10:28, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
current code will stop Xen to boot since it will find that the
latter range
Hi Jan,
On 26/11/2024 08:02, Jan Beulich wrote:
On 25.11.2024 23:17, Julien Grall wrote:
--- a/xen/arch/arm/include/asm/page.h
+++ b/xen/arch/arm/include/asm/page.h
@@ -144,6 +144,12 @@ extern size_t dcache_line_bytes;
#define copy_page(dp, sp) memcpy(dp, sp, PAGE_SIZE)
+#define
Hi,
On 26/11/2024 08:41, Jan Beulich wrote:
On 25.11.2024 21:15, Julien Grall wrote:
Hi Jan,
Sorry for the late answer.
On 01/10/2024 16:16, Jan Beulich wrote:
No functional change, albeit all globals now become hidden, and aliasing
symbols (__aeabi_{u,}idiv) as well as __memzero lose their
From: Julien Grall
All the code in arch/arm32/lib/ where copied from Linux 3.16
and never re-synced since then.
A few years ago, Linux got rid of __memzero() because the implementation
is very similar to memset(p,0,n) and the current use of __memzero()
interferes with optimization. See full
r_page
+
+#define scrub_page_hot(page) memset(page, SCRUB_BYTE_PATTERN, PAGE_SIZE)
+#define scrub_page_cold scrub_page_hot
This block seems to be common between all the arch but x86. Should we
add an header in asm generic?
The rest looks fine to me.
Cheers,
--
Julien Grall
declare it. Constify its parameter at the same time.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
)get_random()) << 32;
+}
+
+#else
+
+static inline void boot_stack_chk_guard_setup(void) {}
+
+#endif /* CONFIG_STACKPROTECTOR */
+
+#endif /* XEN__STACK_PROTECTOR_H */
+
Cheers,
--
Julien Grall
Hi Jan,
On 01/10/2024 16:18, Jan Beulich wrote:
They're no longer used. This also makes it unnecessary to #undef two of
them in the linker script.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
SH_SECTION(name, attr)
Are you suggesting the code in arch/*/head.S has a latent bug?
The rest lgtm to me pending the clarification.
Cheers,
--
Julien Grall
registers and return
*/
+END(__context_switch)
/*
* Local variables:
Cheers,
--
Julien Grall
he ".word 0" was added before Linux used git.
However, it looks like Linux replace __memzero with memset() 6 years ago
on arm32. So maybe we should get rid of it? This would at least avoid
worrying on the purpose of ".word 0".
The rest of the patch looks good to me.
Cheers,
--
Julien Grall
Hi Oleksii,
On 19/11/2024 09:43, oleksii.kuroc...@gmail.com wrote:
Hi Julien,
On Sat, 2024-11-16 at 10:11 +, Julien Grall wrote:
Hi Oleksii,
On 15/11/2024 12:48, Oleksii Kurochko wrote:
Rename the file containing uart_init() to enable reuse across other
architectures that utilize device
x27;t we move this function as well?
Cheers,
--
Julien Grall
MEMF_no_owner flag is used.
This will be useful also when NUMA will be supported on Arm.
Signed-off-by: Carlo Nonato
Acked-by: Julien Grall
I have committed this patch because it seems to be standalone.
Cheers,
--
Julien Grall
panic("Unable to map RW the init text section (rc = %d)\n", rc);
/*
* From now on, init will not be used for execution anymore,
Cheers,
--
Julien Grall
ic inline bool xen_is_using_staticheap(void)
... we could have xen_is_using_staticheap() != static_heap.
+{
+#ifdef CONFIG_STATIC_MEMORY
+return static_heap;
+#else
+return false;
+#endif
+}
+
#endif /* XEN_BOOTFDT_H */
Cheers,
--
Julien Grall
ction.
Signed-off-by: Luca Fancellu
Acked-by: Julien Grall
Cheers,
--
Julien Grall
register
*
* Preserves \virt
* Clobbers \tbl, \tmp1, \tmp2
*
* Note that all parameters using registers should be distinct.
*/
--
Julien Grall
.
In Arm, there is no clean way to disable SMP. As of now, we wish to support
MPU on UNP only. So, we have defined the default range of NR_CPUs to be 1 for
MPU.
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Luca Fancellu
Acked-by: Julien Grall
Cheers,
--
Julien Grall
aving multiple consumers of
VIRQ_DOM_EXC would be great. I have some scalability concern because now
we would end up to have to update N bitmap every time. So we would need
to put a limit to N. I don't think there is a good limit...
So overall, I am not entirely convinced it is worth the trouble.
Cheers,
--
Julien Grall
(see https://en.wikipedia.org/wiki/Xorshift).
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
---
V1:
- make unique_id local to function (Jan Beulich)
- add lock (Julien Grall)
- add comment (Julien Grall)
---
xen/common/domain.c | 20
xen/include/xen/sched.h
S_DEVICE_TREE
+void intc_dt_preinit(void);
+#else
+static inline void intc_dt_preinit(void) { }
+#endif
+
#define dt_prop_cmp(s1, s2) strcmp((s1), (s2))
#define dt_node_cmp(s1, s2) strcasecmp((s1), (s2))
#define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2))
Cheers,
--
Julien Grall
: Add DT reserve map regions to
bootinfo.reserved_mem")
Reported-by: Shawn Anastasio
Reported-by: Grygorii Strashko
Signed-off-by: Luca Fancellu
Reviewed-by: Julien Grall
I will give a few days for the others to review and Shawn to comment
whether it fixes his issue (I can't remember if it was already done).
Cheers,
--
Julien Grall
uart.c
+ *
+ * Generic uart retrieved via the device tree or ACPI
+ *
+ * Julien Grall
+ * Copyright (c) 2013 Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Soft
passthrough).
How do you want to write it ?
This is probably a better question for Bertrand. I don't know how market
requirements are usually described. I was making a comparison with the
other where you explicitely listed the expected resources (e.g. CPU,
Memory, device).
Cheers,
--
J
On 14/11/2024 12:22, Michal Orzel wrote:
On 14/11/2024 13:04, Julien Grall wrote:
Hi Michal,
On 14/11/2024 11:48, Michal Orzel wrote:
On 14/11/2024 11:31, Julien Grall wrote:
Looking at the code, I think /memreserve/ and /reserved-memory are not
mapped in Xen and everything in
Hi Michal,
On 14/11/2024 11:48, Michal Orzel wrote:
On 14/11/2024 11:31, Julien Grall wrote:
Looking at the code, I think /memreserve/ and /reserved-memory are not
mapped in Xen and everything in /reserved-memory is mapped to dom0.
Why do we forward /reserved-memory to dom0 fdt but
Hi Stefano,
On 13/11/2024 22:41, Stefano Stabellini wrote:
On Wed, 13 Nov 2024, Julien Grall wrote:
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
On 06/11/2024 15:07
Hi Michal,
On 14/11/2024 07:18, Michal Orzel wrote:
On 13/11/2024 23:41, Stefano Stabellini wrote:
On Wed, 13 Nov 2024, Julien Grall wrote:
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50
lieve this is the case here. So there is no excuses to try to
take short cut...
Cheers,
--
Julien Grall
Hi,
On 13/11/2024 15:40, Michal Orzel wrote:
On 13/11/2024 15:40, Julien Grall wrote:
Hi,
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
Hi Michal,
On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
There are
Hi,
On 13/11/2024 14:19, Michal Orzel wrote:
On 13/11/2024 14:50, Julien Grall wrote:
Hi Michal,
On 06/11/2024 15:07, Michal Orzel wrote:
On 06/11/2024 14:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved
On 13/11/2024 14:33, Luca Fancellu wrote:
Hi Julien,
Hi,
On 13 Nov 2024, at 14:01, Julien Grall wrote:
Hi Luca,
On 06/11/2024 13:41, Luca Fancellu wrote:
There are some cases where the device tree exposes a memory range
in both /memreserve/ and reserved-memory node, in this case the
start,
- paddr_t region_size);
+paddr_t region_size,
+enum membank_type allow_match_type);
struct bootmodule *add_boot_module(bootmodule_kind kind,
paddr_t start, paddr_t size, bool domU);
Cheers,
--
Julien Grall
an observation or part of a specification?
Cheers,
--
Julien Grall
--
+
+`XenProd~static_domains_configuration~1`
+
+Description:
+Xen shall support specifying the resources required for a domain.
+
+Rationale:
+
+Comments:
+
+Rationale:
+
+Covers:
+ - `XenMkt~static_vm_definition~1`
+
+Needs:
+ - XenSwdgn
\ No newline at end of file
Missing a newline.
--
Julien Grall
rm. I am not sure if this is
still case. Stefano?
[0] https://lore.kernel.org/xen-devel/20240806124815.53492-1-jul...@xen.org/
Cheers,
--
Julien Grall
Hi Ayan,
On 11/11/2024 13:24, Ayan Kumar Halder wrote:
On 11/11/2024 11:12, Julien Grall wrote:
Hi,
Hi Julien,
On 08/11/2024 19:59, Ayan Kumar Halder wrote:
From: Penny Zheng
In Xen, SMMU subsystem is supported for MMU system only. The reason
being SMMU
driver uses the same page tables
GE_MASK))
@@ -22,6 +40,7 @@
#define TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS \
(TEMPORARY_FIXMAP_ADDR(FIX_CONSOLE) + (CONFIG_EARLY_UART_BASE_ADDRESS &
~PAGE_MASK))
+#endif /* CONFIG_MMU */
And finally
#else
# error ...
#endif
#endif /* !CONFIG_EARLY_PRINTK */
> > #endif
--
Julien Grall
tal stage and should not be used in
Cheers,
--
Julien Grall
propose to add "struct domain *d" as the first parameter to make it
more abstract from Xen internals.
I am not sure to understand why we would want the call to be more
abstract. This function should *only* act on the vCPU currently loaded.
So it makes sense to use "current->domain".
Cheers,
--
Julien Grall
in arm-uart.c is the ACPI initialize. I guess at the
some point this will be needed for other architectures. I think it would
be more suitable if the file is renamed, maybe uart-init.c?
Cheers,
--
Julien Grall
: Stefano Stabellini
It is now committed.
Cheers,
--
Julien Grall
ommitted the first 3 patches. I think the others need a respin.
Cheers,
--
Julien Grall
2, x3, x4, x5
-ret
+blenable_mpu
+mov lr, x6
+ret
You should not need to save/restore 'lr'. You could write:
b enable_mpu
So when enable_mpu returns, it will go back to the caller of
enable_boot_cpu_mm.
With that fixed:
Acked-by: Julien Grall
Cheers,
--
Julien Grall
e may build Xen with the wrong flags for the
MPU port?
Cheers,
--
Julien Grall
trigger the error (on alignment check) and thereby prompt
user to set the start address.
Also updated config.h so that it includes mpu/layout.h when CONFIG_MPU is
defined.
Signed-off-by: Wei Chen
Signed-off-by: Jiamei.Xie
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Julien Grall
Cheers
("xen: arm64: initial build + config changes, start of day
code")
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Julien Grall
Cheers,
--
Julien Grall
On 30/10/2024 10:08, Luca Fancellu wrote:
Hi Julien,
On 30 Oct 2024, at 09:52, Julien Grall wrote:
On Wed, 30 Oct 2024 at 09:17, Luca Fancellu wrote:
Hi Ayan,
While I rebased the branch on top of your patches, I saw you’ve changed the
number of regions
mapped at boot time, can I ask why
On Wed, 30 Oct 2024 at 09:17, Luca Fancellu wrote:
>
> Hi Ayan,
>
> While I rebased the branch on top of your patches, I saw you’ve changed the
> number of regions
> mapped at boot time, can I ask why?
I have asked the change. If you look at the layout...
>
> Compared to
> https://patchwork.ke
Hi,
On 24/10/2024 09:02, Ayan Kumar Halder wrote:
On 23/10/2024 17:30, Julien Grall wrote:
On 23/10/2024 17:18, Julien Grall wrote:
On 23/10/2024 17:13, Julien Grall wrote:
On 23/10/2024 17:06, Ayan Kumar Halder wrote:
Hi Luca/Julien,
On 22/10/2024 17:31, Luca Fancellu wrote:
Hi
1 - 100 of 5894 matches
Mail list logo
