Re: [PATCH v3 09/23] hw/uefi: add var-service-core.c

[Alexander Graf <graf@amazon.com>]

On 14.02.25 08:55, Gerd Hoffmann wrote:
>    Hi,
>
>>> How do your patches pick the transfer mode?  Is that dictated by the
>>> host?  Or is the guest free to choose?  In case of the latter:  How does
>>> the guest decide what to do?
>> In our version, the guest gets to pick. It defaults to the DMA interface
>> unless it detects that it's running either the macOS logic (a case you can
>> ignore for now) or is running with SEV-SNP.
>>
>> I think for the upstream interface, it would be best to have the host
>> indicate which one it recommends the guest to use. That way you can force
>> the fallback path without requiring tedious edk2 changes.
> I'm more thinking about a hard switch, i.e. the host would support only
> the one or the other.  That way we'll go need less register space,
> because we'll need either the buffer location register (dma mode) or the
> pio transfer register (pio mode) but not both at the same time so they
> can share the location.


The nice thing about supporting both in the hypervisor and advertising 
preference is that a minimal guest firmware could choose to only support 
the safe one. Given the simplicity of the DMA protocol, it's not a hill 
I will die on though :).

I also like to have dedicated register spaces per component. So even if 
you choose to make it a hard split, I think we're better off with 4k at 
0xfef10000 for control and 64k at 0xfef20000 for the buffer for example. 
Even in the buffer case, you need some control registers. And you want 
to leave the door open to making the buffer space be a direct RAM map, 
which means you want to make it a page granule of the largest typical 
page size (64k).


>
>>> 0xfef1000 seems to be free, which is kida fun b/c of the 'ef1' in the
>>> address.
>> True, I love it! :)
>>
>> It's not enough address space to fit the full 64k buffer though, right?
>> Would all of 0xfef00000 be free by chance? Then you could just direct map
>> the transfer buffer there.
> All of 0xfef00000 is 1M, i.e. 16 x 64k.


Oh, there was a missing 0! So the target space is really 64k right now 
(0xfef10000).


Alex