After merging the 32-bit and 64-bit versions of the code that invokes
the PCI I/O protocol methods to preserve PCI ROM images in commit
2c3625cb9fa2 ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() ...")
there are still separate code paths for 32-bit and 64-bit, where the only
differ
The linux-efi subsystem uses typedefs with the _t suffix to declare
data structures that originate in the UEFI spec. Our type mangling
for mixed mode depends on this convention, so rename the UGA drawing
protocols to allow efi_call_proto() to be used with them in a
subsequent patch.
Signed-off-by:
The UGA draw protocol discovery routine looks for a EFI handle that has
both the UGA draw protocol and the PCI I/O protocol installed. It checks
for the latter by calling handle_protocol() and pass it a PCI I/O
protocol pointer variable by reference, but fails to initialize it to
NULL, which means
The UEFI spec does not permit runtime services to be called
reentrantly, and so it is up to the OS to provide proper locking
around such calls.
For the native case, this was fixed a long time ago, but for the
mixed mode case, no locking is done whatsoever. Note that the calls
are made with preempt
This series contains some fixes and cleanups for mixed-mode UEFI on x86.
Patch #1 adds the missing locking in the runtime service wrapper code for
mixed mode. This was found by inspection rather than having been reported
but could be a candidate for -stable nonetheless.
Patch #2 merges the remain
There are a couple of places in the x86 EFI stub code where we select
between 32-bit and 64-bit versions of the support routines based on
the value of efi_early->is64. Referencing that field directly is a
bad idea, since it prevents the compiler from inferring that this
field can never be true on a
The two versions of setup_uga##() are mostly identical, with the
exception of the size of EFI_HANDLE. So let's merge the two, and
pull the implementation into the calling function setup_uga().
Note that the 64-bit version was only mixed-mode safe by accident:
it only calls the get_mode() method of
Hi,
On 12-07-18 14:21, Ard Biesheuvel wrote:
This series contains some fixes and cleanups for mixed-mode UEFI on x86.
Patch #1 adds the missing locking in the runtime service wrapper code for
mixed mode. This was found by inspection rather than having been reported
but could be a candidate for
On 12 July 2018 at 16:26, Hans de Goede wrote:
> Hi,
>
> On 12-07-18 14:21, Ard Biesheuvel wrote:
>>
>> This series contains some fixes and cleanups for mixed-mode UEFI on x86.
>>
>> Patch #1 adds the missing locking in the runtime service wrapper code for
>> mixed mode. This was found by inspecti
Hi Ard,
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> As noted by Ian, many DMI based quirks for x86 ACPI machines disable
> features that can also be disabled via the kernel command line. Similarly,
> a quirk is under discussion for a arm64 ACPI machine [0] that explodes
> whe
> On 12 Jul 2018, at 19:01, Will Deacon wrote:
>
> Hi Ard,
>
>> On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
>> As noted by Ian, many DMI based quirks for x86 ACPI machines disable
>> features that can also be disabled via the kernel command line. Similarly,
>> a quirk is un
On Thu, 2018-07-12 at 18:01 +0100, Will Deacon wrote:
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> >Especially for UEFI systems, if upgrading
> > firmware is a reasonable prerequisite for being able to upgrade to the
> > latest
Is it?
Ther
Hi Ard,
On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
> account
To me this seems an overly complicated interface to the kernel, and
still doesn't in itself solve the problem at hand -- make the
generic distro kernel with APE
Hi Ard,
> This series contains some fixes and cleanups for mixed-mode UEFI on x86.
>
> Patch #1 adds the missing locking in the runtime service wrapper code for
> mixed
> mode. This was found by inspection rather than having been reported but could
> be a candidate for -stable nonetheless.
>
>
> The UEFI spec does not permit runtime services to be called reentrantly, and
> so
> it is up to the OS to provide proper locking around such calls.
>
> For the native case, this was fixed a long time ago, but for the mixed mode
> case,
> no locking is done whatsoever. Note that the calls are m
On 13 July 2018 at 03:59, Prakhya, Sai Praneeth
wrote:
> Hi Ard,
>
>> This series contains some fixes and cleanups for mixed-mode UEFI on x86.
>>
>> Patch #1 adds the missing locking in the runtime service wrapper code for
>> mixed
>> mode. This was found by inspection rather than having been rep
On 13 July 2018 at 04:01, Prakhya, Sai Praneeth
wrote:
>> The UEFI spec does not permit runtime services to be called reentrantly, and
>> so
>> it is up to the OS to provide proper locking around such calls.
>>
>> For the native case, this was fixed a long time ago, but for the mixed mode
>> cas
> >> Patch #6 helps unused code paths to be optimized away on
> >> configurations that don't need them (32-bit only and 64-bit only)
> >
> > I have tested this patch set on qemu and I see mixed mode kernel not
> > booting.
> > My test setup is:
> > Running qemu-system-x86_64 with 32 bit OVMF and x
On 13 July 2018 at 00:22, Geoff Levand wrote:
> Hi Ard,
>
> On 07/04/2018 08:49 AM, Ard Biesheuvel wrote:
>> efi/libstub: taken contents of LinuxExtraArgs UEFI variable into
>> account
>
> To me this seems an overly complicated interface to the kernel, and
> still doesn't in itself solve the
19 matches
Mail list logo
