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
