Re: UEFI support in ARM DomUs

[Julien Grall <julien@xxxxxxx>]

On 22/06/2020 14:56, Oleksandr Andrushchenko wrote:
> On 6/19/20 4:29 PM, Oleksandr Andrushchenko wrote:
> > On 6/19/20 4:15 PM, Julien Grall wrote:
> > > On 19/06/2020 14:06, Oleksandr Andrushchenko wrote:
> > > > On 6/19/20 3:59 PM, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 19/06/2020 13:51, Oleksandr Andrushchenko wrote:
> > > > > > On 6/19/20 3:47 PM, Julien Grall wrote:
> > > > > > > They will not be available from the fdt, but you can retrieve them with an 
> > > > > > > hypervisor call (see HVM_PARAM_STORE_PFN, HVM_PARAM_CONSOLE_PFN).
> > > > > > Yes, and it used in the relevant pieces of code (hyp calls)
> > > > > > > One question though, why do you need to map them in advance? Couldn't you map 
> > > > > > > them on demand?
> > > > > > Well, we need to at least estimate the pg_table size so we can reserve and 
> > > > > > allocate memory later,
> > > > > Oh, so U-boot doesn't support runtime page-table table allocation. Is that 
> > > > > right?
> > > > As per my understanding no, we provide a memory map and the tables are 
> > > > allocated beforehand
> > > Ok :(.
> > >
> > > > > > so I have to provide memory range from either by coding a constant or looking 
> > > > > > into the devtree at
> > > > > >
> > > > > > hypervisor { reg = <>; }. It is a bit tricky though
> > > > > Looking for a node in the device-tree shouldn't be too difficult given that you 
> > > > > have fdt_* available.
> > > > >
> > > > > However, please not that <reg> doesn't refer to the guest magic pages. Instead, 
> > > > > it provides a region you can use for mapping the grant-table frames
> > > > Indeed, this is in my case 0x38000000, but the magic is at 0x39000000
> > > >
> > > > So, I need the memory range set up beforehand, but I can't as there is no cute 
> > > > way to get that.
> > > >
> > > > Of course, I can issue a hyp call to get HVM_PARAM_CONSOLE_PFN and use it as 
> > > > the base address,
> > > >
> > > > but this smells like a hack. I can call other HVM_PARAM_ to get their pfns and 
> > > > set up the memory regions,
> > > >
> > > > but this looks a bit weird.
> > > Why is it weird? In general, you only want to map exactly what you need. Not 
> > > less, not more.
> > >
> > > In your situation, you only care about two pages, the console page and the 
> > > xenstore page. The rest shouldn't be mapped.
> > Ok, so I'll try get pfns for HVM_PARAM_CONSOLE_PFN + XENSTORE_PFN_OFFSET via 
> > hyp call and map those
> > > > I need that constant badly ;)
> > > No you don't ;).
> We have managed to make use of the relevant hypercalls to get the PFNs, but for 
> that
>
> we need to maintain the caches as this happens (the calls) when MMU is not yet
>
> setup and is in the process of.
Glad to hear it works. Yes, that's unfortunately the drawback of using 
hypercalls with MMU off. But at least you make U-boot more generic :).
Cheers,

--
Julien Grall