Hi Ayan,
On 10/09/2024 14:42, Ayan Kumar Halder wrote:
On 09/09/2024 15:45, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 09/09/2024 11:29, Ayan Kumar Halder wrote:
On 08/09/2024 22:13, Julien Grall wrote:
Hi,
Hi Julien,
On 02/09/2024 15:48, Ayan Kumar Halder wrote:
I will rephrase this as ...
"Used to set customized address at which which Xen will be linked
on MPU systems. This address must be aligned to a page size.
0xFFFFFFFF is used as the default value to indicate that user hasn't
customized this address."
Reading this comment, I would like to ask some clarification. In the
context of the MPU how do you define a page size? The definition is
pretty clear when using the MMU because the granularity if defined
by the HW. But for the MPU, it is a bit blur. Is it still 4KB? If
so, is it actually realistic (we don't have that many MPU regions)?
From ARM DDI 0600A.d ID120821, C1.1.1 Protection regions
"Protection regions have a minimum size of 64 bytes."
Thus, I would infer that the minimum page size (in context of MPU) is
64 bytes.
> > Also, if you see the register fields of PRBAR and PRLAR, the lower 6
yes.
bits are 0 extended to provide the address.
So, may be I should say
".... address must be aligned to the minimum region size (ie 64
bytes). 0xFFFFFFFF is used ...."
Let me know if this sounds ok.
So what you provided is a minimum size/alignment of a region from the
HW point of view. How about Xen? Will it be able to cope if Xen is
booted at a 64-byte alignment?
Asking because it is unclear how the allocator will work with the MPU.
Are we going to continue to allocate 4KB chunk at the time? Will it be
smaller/larger?
MPU will work with static memory allocation only. It can allocate a
fixed number of regions using PRBAR and PRLAR. We can make the addresses
to be page aligned (ie 4KB) so that it is in parity with MMU. And we
will keep the page size as 4 KB. It makes sense to use the same page
size to do the allocation irrespective of MPU or MMU. Also, it helps to
keep a large part of the code as common.
TL;DR: I think we can use different chunk size (I find "page" confusing
in the context of the MPU) and still sharing a large part of Xen. For
now, I would be ok to use the same size. In the future, it would be
beneficial to change it.
Now the longer answer. Looking at the specification, the architecture
allows up to 128 regions. So the chance we will want to share a 4KB RAM
region at the time is close to zero.
Yet we would still have one struct page_info per 4KB chunk to carry the
metadata. This is not only going to be a waste of memory but also
requires extra work. So to me it would make more sense to track larger
chunk (maybe 2MB).
Now regarding the change necessary in Xen. I think we can divide it in
two parts:
* Allocation within region
* Frame in the public interface
For the first part, Xen on Arm is now mainly page agnostic. So you could
bump the PAGE_SIZE (barring the public interface see below) without any
trouble. You may have to deal with extra memory wasted when using
alloc_*heap_page*(). But that could be easily solved by using xmalloc()
and/or introduce new wrappers.
For the frame definition in the public interface. So far, a frame covers
4KB (same as Xen page granularity) and this is bake into OSes (Xen
doesn't have a way to return the page granularity used). So for the MMU,
you sadly can't easily increase the page granularity used by Xen...
However for the MPU I think this is a different story. The bulk of the
interface using frame number (such as increase/decrease memory) are not
applicable for the MPU or would be unusable/severely limited (e.g grant
table) given the number of MPU regions available.
Anyway, I am probably thinking quite far ahead :). For now, I am fine if
you want to use 4KB chunk. So in the Kconfig you could write "Xen start
address should be 4KB aligned" (let's not mention page).
Cheers,
--
Julien Grall
