[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UEFI support in ARM DomUs





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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.