Hi George,
> -Original Message-
> From: George Dunlap
> Sent: Friday, March 11, 2022 5:47 AM
> To: xen-de...@lists.xen.org
> Cc: George Dunlap ; Henry Wang
> ; Wei Liu ; Andrew Cooper
> ; Jan Beulich ; Roger Pau
> Monne ; Stefano Stabellini ;
> Juli
Hi,
> -Original Message-
> From: Xen-devel On Behalf Of
> Marco Solieri
> Sent: Saturday, March 5, 2022 1:47 AM
> To: xen-devel@lists.xenproject.org
> Cc: Marco Solieri ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Julien Grall ; Stefano
> Stabellini ; Wei Liu ; Marco Solieri
> ; An
no configuration is
> provided by the user, all the available colors supported by the
> hardware will be assigned to dom0.
>
> Signed-off-by: Luca Miccio
> Signed-off-by: Marco Solieri
For the first 10 commits:
Tested-by: Henry Wang
> ---
> xen/arch/arm/coloring.c
lly currently returns -EILSEQ because
> there is no specific check for lenght == 0.
>
> Add a check now.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Henry Wang
> ---
> xen/common/device_tree.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
unctionality as I do not have the board :))
So, for this series:
Tested-by: Henry Wang
> ---
> xen/drivers/char/Kconfig | 8 +
> xen/drivers/char/Makefile | 1 +
> xen/drivers/char/imx-lpuart.c | 275
> ++
> xen/include/xen/imx-lp
Hi Stefano,
> -Original Message-
> From: Xen-devel On Behalf Of
> Stefano Stabellini
> Sent: Friday, April 8, 2022 8:11 AM
> To: xen-devel@lists.xenproject.org
> Cc: sstabell...@kernel.org; jul...@xen.org; andrew.coop...@citrix.com;
> george.dun...@citrix.com; jbeul...@suse.com; w...@xen.
Hi Julien and Stefano,
> -Original Message-
> From: Julien Grall
> >
> > For the patch I don't have any comments, but I think here we've got
> > a typo: s/messahe/message. I think it is ok to fix while committing this
> > patch so this is just a kind reminder :))
>
> Anything after --- w
eries.
Sorry for the late response, the previous e-mail that you directly
"to"ed me fell through the cracks somehow.
Acked-by: Henry Wang
Since you also mentioned the changelog entry, I will take a note of this
series and we can have a discussion about adding it when we do the
next Xe
Hi Jan,
> -Original Message-
> From: Jan Beulich
> > Since you also mentioned the changelog entry, I will take a note of this
> > series and we can have a discussion about adding it when we do the
> > next Xen release (4.17). Would that sound ok with you?
>
> "Adding it" where? Maybe you
. Thankfully, we know in advance which
> IRQs will be used for passthrough to be able to choose non-clashed
> ones.
>
> Signed-off-by: Julien Grall
> Signed-off-by: Oleksandr Tyshchenko
> Tested-by: Jiamei Xie
> Reviewed-by: Henry Wang
> ---
> @Jiamei, @Henry I decide
Hi Elliott,
> -Original Message-
> From: Xen-devel On Behalf Of
> Elliott Mitchell
> Sent: Friday, November 12, 2021 12:28 PM
> To: Stefano Stabellini ; Julien Grall
> Cc: xen-devel@lists.xenproject.org
> Subject: ACPI/UEFI support for Xen/ARM status?
>
> I've been busy with another par
while waiting for the CPU to show up. Allow to try
> + * again later.
> + */
> + return 0;
> +
> default:
>
> /* Should not happen. Famous last words. */
> --
> 2.33.1
>
Reviewed-by: Henry Wang
Kind regards,
Henry
t; /*
> * Ignore the following error codes:
> * - EBADF: Indicate the current device is not a pci device.
> diff --git a/xen/include/asm-arm/device.h b/xen/include/asm-arm/device.h
> index 3782660751b6..086dde13eb6b 100644
> --- a/xen/include/asm-arm/devi
section is added, describing the definition of
reserved Xenheap memory and the method of enabling the reserved
Xenheap memory through device tree on AArch64 at boot time.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
---
For reviewers:
The name of the device tree property was chosen because
series is sent as RFC for comments from the
community. The first patch introduces the reserved Xenheap and the
device tree processing code. The second patch adds the implementation of
the reserved Xenheap pages handling in boot and heap allocator on Arm64.
Henry Wang (2):
docs, xen/arm: Introduce
the
heap allocator at `end_boot_allocator()`.
If the reserved Xenheap is disabled, we stick to the current page
allocation strategy at boot time.
Also, this commit removes some unneeded brackets in `setup_mm`
following the Xen coding style.
Signed-off-by: Henry Wang
---
xen/arch/arm/bootfdt.c
Hi Julien,
Thanks very much for your time reading the series and your feedback. Please
find the inline reply below.
> -Original Message-
> From: Julien Grall
> Sent: Saturday, February 26, 2022 4:09 AM
> To: Henry Wang ; xen-devel@lists.xenproject.org;
> sstabell...@
Hi Julien,
> -Original Message-
> From: Julien Grall
> On 28/02/2022 07:12, Henry Wang wrote:
> > Hi Julien,
>
> Hi Henry,
>
> >> -Original Message-
> >> From: Julien Grall
> >> Hi Henry,
> >>
> >>
Hi Jan, Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [xen-unstable-smoke bisection] complete build-amd64-libvirt
>
> Hi Jan,
>
> On 01/08/2022 10:06, Jan Beulich wrote:
> > On 01.08.2022 10:43, Julien Grall wrote:
> >> If we don't force push, we have two solutions:
>
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: [PATCH] ChangeLog: mention IOMMU superpage support
>
> Signed-off-by: Jan Beulich
Thanks for the patch,
Acked-by: Henry Wang
Kind regards,
Henry
Hi all,
This email is a weekly reminder about the Xen 4.17 release. The last posting
date for Xen 4.17 is Fri Aug 12, 2022. If you want your features to be included
for the release, please make sure they are posted for the first time before
**Fri Aug 12, 2022**.
Kind regards,
Henry
Hi Jason,
> -Original Message-
> From: Jason Andryuk
> Subject: [PATCH v2 13/13] CHANGELOG: Add Intel HWP entry
>
> Signed-off-by: Jason Andryuk
Thanks for the patch,
Acked-by: Henry Wang
Kind regards,
Henry
Hi Jason,
> -Original Message-
> From: Jason Andryuk
> For v3, I'll move to the existing section while keeping Henry's Ack.
Thank you. Keeping the Ack is ok to me.
Kind regards,
Henry
>
> Regards,
> Jason
; (XEN) 1ST[0x001] = 0x4015ff7f
> (XEN) 2ND[0x01f] = 0x00500000bfe00f7d
>
> Signed-off-by: Julien Grall
Reviewed-by: Henry Wang
Kind regards,
Henry
ort.
>
> For data abort, the HSR will be set properly and so replace the call
> to do_unexpected_trap() with do_trap_hyp_sync() to dispatch the error.
>
> Signed-off-by: Julien Grall
I think this patch looks good to me so:
Reviewed-by: Henry Wang
But it seems tha
Hi all,
As planned, we are now 3 weeks from feature freeze date (Fri Sep 2, 2022).
Below is the current status of series from last two months. I've grouped
them to blocks for easier search. If I missed your series, please let me know,
thanks!
** Blocker List **:
1. Patch: x86: enable interrupts a
Hi Jan,
Thanks for your patience and detailed review of the list.
> -Original Message-
> From: Jan Beulich
> Subject: Re: Xen 4.17: Current status of series floating in ML
>
> On 15.08.2022 07:46, Henry Wang wrote:
> > 11. vpci: first series in preparation for
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: Xen 4.17: Current status of series floating in ML
> On 15/08/2022 06:46, Henry Wang wrote:
> > Hi all,
>
> Hi Henry,
>
> Thanks for the list!
No problem, always feel good
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: Xen 4.17: Current status of series floating in ML
> >>> ** Blocker List **:
> >>> 2. tools/xenstore: add some new features to the documentation
> >>> https://patchwork.kernel.org/project/xen-devel/list/?series=665064
> >>
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH 7/7] xen/arm32: traps: Dump more information for
> hypervisor data abort
> Hmmm... I dropped a patch from the series and it looks like I didn't
> properly clean the directory before doing that. Please ignore patch
the variables will still be accessible
> because the region permission is not updated.
>
> Address that, but moving the sections .data.ro_after_init
> out of .data and then mark the region read-only once we finish
> to boot.
>
> Signed-off-by: Julien Grall
Tested-by: Henry Wang
Kind regards,
Henry
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: [PATCH v3 0/5] x86/mwait-idle: (remaining) SPR + (new) ADL
> support
>
> Henry,
>
> On 18.08.2022 15:02, Jan Beulich wrote:
> > New changes have appeared in the meantime, in particular one partly
> undoing
> > what we still
Hi,
This email is sent to discuss the possible Release Candidates (RCs) for
Xen 4.17 release. We are still 1+ month away from where they start but
we can start early to gather opinions from all stakeholders.
I checked the RC schedule when Xen 4.16 was released. The RCs were prepared
after the Cod
`setup_mm()`.
Henry Wang (2):
docs, xen/arm: Introduce reserved heap memory
xen/arm: Handle reserved heap pages in boot and heap allocator
docs/misc/arm/device-tree/booting.txt | 46
xen/arch/arm/bootfdt.c| 51 +
xen/arch/arm/domain_build.c
()`.
If the reserved heap is disabled, we stick to current page allocation
strategy at boot time.
Also, take the chance to correct a "double not" print in Arm32
`setup_mm()`.
Signed-off-by: Henry Wang
---
With reserved heap enabled, for Arm64, naming of global variables such
as `xenheap
added, describing the definition of reserved
heap memory and the method of enabling the reserved heap memory through
device tree at boot time.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
---
The name of the device tree property was chosen because we want to
reuse as much as the device tree
Hi Michal,
It is great to hear from you! Hope you are doing well.
> -Original Message-
> From: Michal Orzel
> Subject: Re: [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory
> Hi Henry,
> > +to parts of RAM reserved in the beginning for heap. The memory is
> reserved by
> I think
> I'll give it a little for Henry to possibly release-ack this, but since
> strictly speaking this is a bug fix, I think it could also go in without
> (as long as not actually objected to, of course).
Thanks for informing. Yeah definitely no problem from my side, so:
Acked-by: Henry Wang # For the 4.17 release
Kind regards,
Henry
>
> Jan
Hi Stefano and Michal,
> -Original Message-
> From: Stefano Stabellini
> Sent: Tuesday, August 30, 2022 8:47 AM
> To: Henry Wang
> Cc: Michal Orzel ; xen-devel@lists.xenproject.org;
> Stefano Stabellini ; Julien Grall ;
> Bertrand Marquis ; Wei Chen
> ; Volodymyr
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Subject: Re: [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory
>
> On Wed, 24 Aug 2022, Henry Wang wrote:
> > ---
> > The name of the device tree property was chosen because we want to
>
Hi Michal,
Sorry about the late reply - I had a couple of days off. Thank you very
much for the review! I will add my reply and answer some of your
questions below.
> -Original Message-
> From: Michal Orzel
> Subject: Re: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and
> heap
Hi Michal,
> -Original Message-
> From: Michal Orzel
> >> +printk("Checking for reserved heap in /chosen\n");
> >> +if ( address_cells < 1 || size_cells < 1 )
> > address_cells and size_cells cannot be negative so you could just check
> if
> > there are 0.
Hi Michal,
> -Original Message-
> From: Michal Orzel
> >>>
> >> Did you consider putting reserved_heap into bootinfo structure?
> >
> > Actually I did, but I saw current bootinfo only contains some structs so
> > I was not sure if this is the preferred way, but since you are raising this
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> > +paddr_t reserved_heap_start = ~0, reserved_heap_end = 0,
>
> INVALID_PADDR or ~0ULL
Ack.
>
> > /*
> > * If the user has not requested otherwise via the command line
> > * then locate the xenheap usin
Hi Michal,
> -Original Message-
> From: Michal Orzel
> >> This is totally fine. What I mean is that the check you introduced does not
> >> correspond
> >> to the panic message below. In case of reserved heap, its size is selected
> by
> >> the user.
> >> "Not enough space for xenheap" mea
Hi Michal,
> -Original Message-
> From: Michal Orzel
> >
> > Oh I think get your point. Let me try to explain myself and thanks for your
> > patience :))
> >
> > The reserved heap region defined in the device tree should be used for
> both
> > Xenheap and domain heap, so if we reserved a
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> > > and we can automatically calculate xenheap_pages in a single line.
> >
> > Here I am a little bit confused. Sorry to ask but could you please explain
> > a little bit more about why we can calculate the xenheap_pages in a s
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Subject: RE: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and
> heap allocator
>
> On Tue, 30 Aug 2022, Henry Wang wrote:
> > > -Original Message-
> > > From: Michal O
Hi Stefano,
> -Original Message-
> From: Henry Wang
> I am not sure about that, since we already have
> heap_pages = reserved_heap ? reserved_heap_pages : ram_pages;
>
> the heap_pages is supposed to contain domheap_pages + xenheap_pages
> based on the reserved heap
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> > > But also it looks like that on arm32 we have specific requirements for
> > > Xen heap:
> > >
> > > * - must be 32 MiB aligned
> > > * - must not include Xen itself or the boot modules
> > > * - must be at
Hi Arm maintainers,
> -Original Message-
> Hi Henry,
>
> On 30/08/2022 08:11, Henry Wang wrote:
> >
> > Hi Michal,
> >
> > Sorry about the late reply - I had a couple of days off. Thank you very
> > much for the review! I will add my reply a
Hi Bertrand,
> -Original Message-
> From: Bertrand Marquis
> > On 1 Sep 2022, at 02:03, Henry Wang wrote:
> >
> > Hi Arm maintainers,
> >
> >> -Original Message-
> >> Hi Henry,
> >>
> >> On 30/08/2022 08:11, He
Hi Julien,
> -Original Message-
> From: Julien Grall
> >> +paddr_t reserved_heap_start = ~0, reserved_heap_end = 0,
> >
> > INVALID_PADDR or ~0ULL
>
> I would strongly prefer the former. It is more difficult to understand
> what's the value means in the latter.
Thanks for the input.
Hi Bertrand,
> -Original Message-
> From: Bertrand Marquis
> Subject: Push 4.17 Feature freeze and Code freeze one week later
>
> Hi,
>
> Seeing that we have lots of series quite advanced in review but not already
> merged, could we push
> both Feature freeze and Code freeze deadline on
Hi Julien,
Thanks for your review.
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH 2/2] xen/arm: Handle reserved heap pages in boot and
> heap allocator
>
> Hi Henry,
>
> On 24/08/2022 08:31, Henry Wang wrote:
> > This commit
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory
>
> Hi Henry,
>
> > Also, this commit introduces the logic to parse the reserved heap
> > configuation in device tree by reusing the device tree entry definition
Hi Julien,
> -Original Message-
> From: Julien Grall
> >> This code is now becoming quite confusing to understanding. This loop is
> >> meant to map the xenheap. If I follow your documentation, it would
> mean
> >> that only the reserved region should be mapped.
> >
> > Yes I think this i
Hi Julien,
> -Original Message-
> From: Julien Grall
> > Thanks for the clarification. I checked the code and found the xenheap_*
> > variables are:
> > xenheap_virt_start, xenheap_virt_end, xenheap_mfn_start,
> > xenheap_mfn_end, xenheap_base_pdx.
> >
> > For clarification, do we need to
Hi Julien,
> -Original Message-
> Subject: Re: [PATCH 1/2] docs, xen/arm: Introduce reserved heap memory
>
> Hi Henry,
>
> On 02/09/2022 02:28, Henry Wang wrote:
> >> This is technically a change in behavior for Xen (we would panic rather
> >>
Hi all,
As the feature freeze date is around the corner (Sep. 9, 2022) and we are
currently summarizing the series for the release, here are the list of series
pending in the mailing list. Please add the ones that I probably missed.
Thank you very much!
Note that the blocker, automation, Arm list
Hi Michal,
> -Original Message-
> From: Michal Orzel
> > 2. automation: Test a pv network interface under dom0less enhanced
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> hwork.kernel.org%2Fproject%2Fxen-
> devel%2Flist%2F%3Fseries%3D666128&data=05%7C01%7Cm
reserved_heap_start variable.
- Decouple the arm32 reserved heap too small size check with region
end check.
- Reuse the arm32 original xenheap finding logic with the new helper
to make sure xenheap on arm32 is contiguous.
Henry Wang (4):
docs, xen/arm: Introduce reserved heap memory
xen/arm
.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
---
Changes from v1 to v2:
- Rename the device tree property to xen,static-heap to avoid confusion.
- Change of commit msg and doc wording, correct typo in commit msg.
- Do not change the process_chosen_node() return type.
- Add an empty line in
ed to access the RAM easily.
On Arm32, only the xenheap is direct mapped today. So the renaming
to "directmap_*" would be still valid for Arm32.
No functional change is intended.
Signed-off-by: Henry Wang
---
Changes from v1 to v2:
- New commit.
---
xen/arch/arm/include/asm/config.h |
correct a "double not" print in Arm32
`setup_mm()` and replace the open-coding address ~0 by INVALID_PADDR.
Signed-off-by: Henry Wang
---
Changes from v1 to v2:
- Move the global bool `reserved_heap` to bootinfo.
- Replace the open open-coding address ~0 by INVALID_PADDR.
- Do not us
type.
Signed-off-by: Henry Wang
---
Changes from v1 to v2:
- New commit.
---
xen/arch/arm/bootfdt.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 5af71dc8ba..3796a4bd75 100644
--- a/xen
Hi Julien and Michal,
> -Original Message-
> From: Julien Grall
> >> Changes from v1 to v2:
> >> - New commit.
> >> ---
> >
> > The patch looks good but I think it should be put as the first one in the
> series
> > as this is a natural prerequisite for the introduction of the reserved hea
Hi Michal,
> -Original Message-
> From: Michal Orzel
> > +typedef enum {
> > +MEMBANK_MEMORY,
> > +MEMBANK_XEN_DOMAIN, /* whether the memory bank is bound to a
> Xen domain. */
> > +MEMBANK_RSVD_HEAP, /* whether the memory bank is reserved as
> heap. */
> > +} membank_type;
>
Hi Anthony,
> -Original Message-
> From: Anthony PERARD
> Subject: Re: Xen 4.17 release: Current status before the feature freeze
>
> On Mon, Sep 05, 2022 at 03:44:33AM +0000, Henry Wang wrote:
> > ** Blocker List **:
> > 2. The fix of libvirt after the
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> Subject: Re: [PATCH v2 1/4] docs, xen/arm: Introduce reserved heap memory
>
> On Mon, 5 Sep 2022, Henry Wang wrote:
> > This commit introduces the reserved heap memory, which is parts of RAM
> > r
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v2 1/4] docs, xen/arm: Introduce reserved heap memory
>
> Hi Henry,
>
> On 05/09/2022 08:26, Henry Wang wrote:
> > This commit introduces the reserved heap memory, which is parts
Hi Julien,
Thanks for your comments, I added my reply and some of the questions
that I am not 100% sure inline below.
> -Original Message-
> From: Julien Grall
> Hi Henry,
> > +
> > +/*
> > + * Find the contiguous xenheap region that fits in the reserved heap region
> with
>
> There mig
Michal Orzel wrote:
> >> On 05/09/2022 09:26, Henry Wang wrote:
> >>>
> >>> diff --git a/xen/arch/arm/include/asm/setup.h
> b/xen/arch/arm/include/asm/setup.h
> >>> index 5815ccf8c5..d0cc556833 100644
> >>> --- a/xen/arch/ar
Hi Julien,
Thanks for the clarification and your patience. For the
populate_boot_allocator() change, I attached my change in the end,
and personally I would like to hear your opinion before sending v3
since we now have limited time.
> -Original Message-
> From: Julien Grall
> >>> +
Hi Jan,
> -Original Message-
> From: Jan Beulich
> > Acked-by: Henry Wang # For the 4.17 release
>
> I've translated this to Release-acked-by: (as was used for earlier releases).
Thanks for letting me know this! I will keep in mind and use this in the futur
Hi Andrew,
(+ Anthony as I believe he is the toolstack maintainer)
> -Original Message-
> From: Andrew Cooper
> Subject: Re: [for-4.17 PATCH] acpi: Add TPM2 interface definition and make
> the TPM version configurable.
>
> On 30/08/2022 21:27, Jennifer Herbert wrote:
> > This patch intr
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Subject: Re: Xen 4.17 release: Current status before the feature freeze
>
> On 05.09.2022 05:44, Henry Wang wrote:
> > ** x86 **:
> > 1. [v2] x86: show_hvm_stack() requires enabled interrupts
> > https:/
Hi Julien,
> -Original Message-
> From: Julien Grall
> > I agree we need to require 64KB alignment, and currently we are following
> > this because we are doing 32MB alignment.
> Hmmm... I think we are talking about two different things here. What I
> am referring to is the alignment of t
Hi all,
> -Original Message-
> Subject: Xen 4.17 release: Current status before the feature freeze
>
> Hi all,
>
> As the feature freeze date is around the corner (Sep. 9, 2022) and we are
> currently summarizing the series for the release, here are the list of series
> pending in the ma
type.
Signed-off-by: Henry Wang
---
Changes from v2 to v3:
- Adjust the order of this patch, make it the #1.
Changes from v1 to v2:
- New commit.
---
xen/arch/arm/bootfdt.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch
t;.
- Change of wording in comments.
- int i -> unsigned int i.
- Avoid extra indentation by reverting the check of MEMBANK_RSVD_HEAP.
- Use MB(32).
- Drop unnecessary panic and unused variables.
- Avoid the ternary operation in assigning the heap_pages.
- Rework populate_boot_allocator() for static he
, the
memory will be marked as static heap type.
A documentation section is added, describing the definition of static
heap memory and the method of enabling the static heap memory through
device tree at boot time.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
Acked-by: Stefano Stabellini
ed to access the RAM easily.
On Arm32, only the xenheap is direct mapped today. So the renaming
to "directmap_*" would be still valid for Arm32.
No functional change is intended.
Signed-off-by: Henry Wang
---
Changes from v2 to v3:
- Adjust the order of this patch, make it #3.
Chang
ouble not" print in Arm32
`setup_mm()` and replace the open-coding address ~0 by INVALID_PADDR.
Signed-off-by: Henry Wang
---
Changes from v2 to v3:
- Adjustment of the terminology change to "static heap".
- Change of wording in comments.
- int i -> unsigned int i.
- Avoid extra i
Hi Julien,
> -Original Message-
> From: Julien Grall
> > -/* find first memory range not bound to a Xen domain */
> > -for ( i = 0; i < mem->nr_banks && mem->bank[i].xen_domain; i++ )
> > +/* find first memory range not bound to a Xen domain nor heap */
>
> This comment could
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v3 3/4] xen/arm: mm: Rename xenheap_* variable to
> directmap_*
>
> Hi Henry,
>
> On 07/09/2022 09:36, Henry Wang wrote:
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
&g
Hi Julien,
> -Original Message-
> From: Julien Grall
> >>> @@ -609,7 +609,7 @@ void __init setup_xenheap_mappings(unsigned
> >> long base_mfn,
> >>
> >> I think the function also want to be renamed to match the code below.
> >
> > Hmmm, renaming the name to "setup_directmap_mappings" woul
Hi Julien,
> -Original Message-
> > How about
> > /*
> > * For Arm32, set up the xenheap: up to 1GB of contiguous,
> > * always-mapped memory. Base must be 32MB aligned and size
> > * a multiple of 32MB.
> > * For Arm64, set up the directmap area of memory.
>
> One remark. I would
>
> On 07/09/2022 09:36, Henry Wang wrote:
> > +- xen,static-heap
> > +
> > +Property under the top-level "chosen" node. It specifies the address
> > +and size of Xen static heap memory. Note that at least a 64KB
> > +alignment is required.
Hi Michal,
> -Original Message-
> From: Michal Orzel
> > I am not convinced by the arguments on not using #address-cells and will
> > leave that one to Stefano
> >
> > But in any case we should only add one pair here for sure, as you say the
> > only implication is to add a couple of 0 in
Hi Bertrand and Michal,
I don't want to spam the email so I just reply here...
> -Original Message-
> From: Bertrand Marquis
> But in any case we should only add one pair here for sure, as you say
> the
> only implication is to add a couple of 0 in the worst case.
> >>> I agree
Hi Julien,
> -Original Message-
> From: Julien Grall
> > I think I've addressed all comments from Julien regarding my series,
>
> If it is not too late for you would you be able to resend your series
> without the 'address-cells'/'size-cells' change? This will give me the
> opportunity t
.
Changes from v3 to v4:
- Change and update of wording in comments.
- Add the static heap feature in SUPPORT.md as tech preview.
- Also rename the setup_xenheap_mappings() function name and
printed messages inside the function.
- Add Acked-by and reviewed-by.
Henry Wang (4):
xen/arm: bootfdt: Make
type.
Signed-off-by: Henry Wang
Reviewed-by: Michal Orzel
Acked-by: Julien Grall
---
Changes from v3 to v4:
- Add Reviewed-by from Michal and Acked-by from Julien.
Changes from v2 to v3:
- Adjust the order of this patch, make it the #1.
Changes from v1 to v2:
- New commit.
---
xen/arch/arm
, the
memory will be marked as static heap type.
A documentation section is added, describing the definition of static
heap memory and the method of enabling the static heap memory through
device tree at boot time.
Signed-off-by: Henry Wang
Signed-off-by: Penny Zheng
Acked-by: Stefano Stabellini
ouble not" print in Arm32
`setup_mm()` and replace the open-coding address ~0 by INVALID_PADDR.
Signed-off-by: Henry Wang
Reviewed-by: Julien Grall
---
Changes from v3 to v4:
- Add Julien's Reviewed-by.
Changes from v2 to v3:
- Adjustment of the terminology change to "static heap"
ed to access the RAM easily.
On Arm32, only the xenheap is direct mapped today. So the renaming
to "directmap_*" would be still valid for Arm32.
No functional change is intended.
Signed-off-by: Henry Wang
---
Changes from v3 to v4:
- Also rename the setup_xenheap_mappings() function name and
Hi Stefano,
> -Original Message-
> From: Stefano Stabellini
> > I would not block this series on the renaming for existing property (what
> > matter is the new ones are consistent with the discussion). The renaming
> could
> > be done afterwards. I would even say post the feature freeze o
Hi Julien,
> -Original Message-
> From: Julien Grall
> > +- #xen,static-heap-address-cells and #xen,static-heap-size-cells
> > +
> > +Specify the number of cells used for the address and size of the
> > +"xen,static-heap" property under "chosen".
>
> Logging here just because it
Hi Julien,
> -Original Message-
> From: Julien Grall
> Subject: Re: [PATCH v4 3/4] xen/arm: mm: Rename xenheap_* variable to
> directmap_*
>
> Hi Henry,
>
> On 07/09/2022 15:35, Henry Wang wrote:
> > With the static heap setup, keep u
1 - 100 of 1164 matches
Mail list logo
