I had missed this conversation, but Ard pointed me at it yesterday, so
I'll chime in now.
Ard, you are correct that SetVirtualAddressMap() is optional in the
spec and we could simply not call it. By a strict reading of the spec
that is completely valid. However, the problem is not with the spec,
i
On Wed, Aug 06, 2014 at 04:15:23PM +0100, Ard Biesheuvel wrote:
> On 6 August 2014 16:36, Will Deacon wrote:
> > On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
> >> #define efi_call_virt(f, ...)
> >>\
> >> ({
On 6 August 2014 16:36, Will Deacon wrote:
> On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
>> There are 2 interesting pieces of information in the UEFI spec section 2.3.6
>> regarding the mapping of runtime regions:
>> (a) the firmware should not request a virtual mapping for con
On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
> There are 2 interesting pieces of information in the UEFI spec section 2.3.6
> regarding the mapping of runtime regions:
> (a) the firmware should not request a virtual mapping for configuration
> tables,
> even though they are
On 31 July 2014 17:02, Mark Salter wrote:
> On Thu, 2014-07-31 at 16:11 +0200, Ard Biesheuvel wrote:
>> There are 2 interesting pieces of information in the UEFI spec section 2.3.6
>> regarding the mapping of runtime regions:
>> (a) the firmware should not request a virtual mapping for configurati
On Thu, 2014-07-31 at 16:11 +0200, Ard Biesheuvel wrote:
> There are 2 interesting pieces of information in the UEFI spec section 2.3.6
> regarding the mapping of runtime regions:
> (a) the firmware should not request a virtual mapping for configuration
> tables,
> even though they are marked
There are 2 interesting pieces of information in the UEFI spec section 2.3.6
regarding the mapping of runtime regions:
(a) the firmware should not request a virtual mapping for configuration tables,
even though they are marked as EfiRuntimeServicesData;
(b) calling SetVirtualAddressMap() is opt
