Re: UEFI support in ARM DomUs

[Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>]

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.

>>
>> Cheers,
>>
> Thanks for helping with this