Re: [PATCH v1 2/4] xen/arm: mpu: Define Xen start address for MPU systems

[Ayan Kumar Halder <ayankuma@xxxxxxx>]

On 10/09/2024 22:34, Julien Grall wrote:
> Hi Ayan,
Hi Julien,
> 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.
Thanks for the detailed explaination. :) Yes, the initial MPU support 
will be limited to booting of domains in dom0less mode. IOW, support for 
grant tables will not be a part of the initial set of patches.
> 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).
Yes, I will use these words. When we get Xen up and running on R52 and 
R82 (with the basic features), then we can revisit this.
- Ayan