On Mon, 19 May, at 11:02:55PM, Daniel Kiper wrote:
>
> It is correct. As I said earlier: in case of !efi_enabled(EFI_DIRECT) some
> structures are created artificially and they live in virtual address space.
> So that is why they should not be mapped.
So, exploring Jan's idea, is it not possible
>>> On 19.05.14 at 22:46, wrote:
> On Mon, May 19, 2014 at 02:30:45PM +0100, Jan Beulich wrote:
>> >>> On 16.05.14 at 22:41, wrote:
>> > @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
>> >efi_unmap_memmap();
>> > }
>> >
>> > +static void __init __iomem *efi_early_ioremap(resou
On Mon, May 19, 2014 at 04:58:32PM +0100, David Vrabel wrote:
> On 16/05/14 21:41, Daniel Kiper wrote:
> > Introduce EFI_DIRECT flag. If it is set this means that Linux
> > Kernel has direct access to EFI infrastructure. If not then
> > kernel runs on EFI platform but it has not direct control
> >
On Mon, May 19, 2014 at 02:30:45PM +0100, Jan Beulich wrote:
> >>> On 16.05.14 at 22:41, wrote:
> > @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
> > efi_unmap_memmap();
> > }
> >
> > +static void __init __iomem *efi_early_ioremap(resource_size_t phys_addr,
> > +
On 16/05/14 21:41, Daniel Kiper wrote:
> Introduce EFI_DIRECT flag. If it is set this means that Linux
> Kernel has direct access to EFI infrastructure. If not then
> kernel runs on EFI platform but it has not direct control
> on EFI stuff. This functionality is used in Xen dom0.
This is backwards
>>> On 16.05.14 at 22:41, wrote:
> @@ -457,6 +460,21 @@ void __init efi_free_boot_services(void)
> efi_unmap_memmap();
> }
>
> +static void __init __iomem *efi_early_ioremap(resource_size_t phys_addr,
> + unsigned long size)
> +{
> +
Introduce EFI_DIRECT flag. If it is set this means that Linux
Kernel has direct access to EFI infrastructure. If not then
kernel runs on EFI platform but it has not direct control
on EFI stuff. This functionality is used in Xen dom0.
Signed-off-by: Daniel Kiper
---
arch/x86/kernel/setup.c |
7 matches
Mail list logo
