Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1222046 > unrolled thread

[PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

Back to article view | Back to linux.kernel

Contents

  [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-10 11:00 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 12:00 +0200
      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 12:30 +0200
        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 13:30 +0200
          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 13:50 +0200
            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 14:20 +0200
              Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-10 15:00 +0200
                Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 15:10 +0200
                  Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-10 15:40 +0200
              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 16:00 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Leif Lindholm <leif.lindholm@linaro.org> - 2015-09-10 16:20 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 16:50 +0200
                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-10 18:20 +0200
                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 18:30 +0200
                      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-11 14:50 +0200
                        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-11 15:20 +0200
                          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-11 15:40 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-11 17:50 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-14 11:00 +0200
                                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 11:10 +0200
                                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-14 11:40 +0200
                                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 11:40 +0200
                                      Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-14 12:40 +0200
                                        Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI  stub parameters Ard Biesheuvel <ard.biesheuvel@linaro.org> - 2015-09-14 13:20 +0200
                                          Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names  of EFI stub parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-14 13:40 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:40 +0200
                        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:30 +0200
                          Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-12 13:50 +0200
                            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-14 11:30 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-09-14 11:50 +0200
                              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Daniel Kiper <daniel.kiper@oracle.com> - 2015-09-14 14:30 +0200
                    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Ian Campbell <ian.campbell@citrix.com> - 2015-09-11 13:10 +0200
            Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 15:00 +0200
              Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-10 17:00 +0200
                Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters "Jan Beulich" <JBeulich@suse.com> - 2015-09-10 17:10 +0200
                  Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Mark Rutland <mark.rutland@arm.com> - 2015-09-11 18:40 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Andrew Turner <andrew@fubar.geek.nz> - 2015-09-10 13:50 +0200
      Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Julien Grall <julien.grall@citrix.com> - 2015-09-10 13:50 +0200
        Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub  parameters Roger Pau Monné <roger.pau@citrix.com> - 2015-09-10 14:10 +0200
          Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of  EFI stub parameters Julien Grall <julien.grall@citrix.com> - 2015-09-10 15:00 +0200
    Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters Shannon Zhao <zhaoshenglong@huawei.com> - 2015-09-17 14:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1223971

On 2015/9/14 17:09, Ard Biesheuvel wrote:
> On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> [..]
> 
>>
>> It only needs to apply following patch to fix a bug in Linux kernel when
>> mapping EFI_MEMORY_RUNTIME memory.
>>
> 
> Could you explain why you think efi_virtmap_init() should fail if
> there are no EFI_MEMORY_RUNTIME regions?
> 

My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
means we can't use runtime services and should not set the bit
EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
true, the bit will be set.

> The absence of such regions is allowed by the spec, so
> efi_virtmap_init() is correct imo to return success.
> 
Sorry, not well know about the spec. Could you point out where the spec
says this?

> If you are trying to work around the issue where Xen does not expose
> any Runtime Services regions, there is simply no way to do that and be
> still UEFI compliant. I have suggested before that we should perhaps
> tolerate this anyway, by considering the case where the EFI System
> Table has a NULL runtime services pointer. But rigging
> efi_virtmap_init() like this is really not the way to achieve that.
> 

-- 
Shannon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223986

(snip some cc's)

On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>
>
> On 2015/9/14 17:09, Ard Biesheuvel wrote:
>> On 14 September 2015 at 10:42, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> [..]
>>
>>>
>>> It only needs to apply following patch to fix a bug in Linux kernel when
>>> mapping EFI_MEMORY_RUNTIME memory.
>>>
>>
>> Could you explain why you think efi_virtmap_init() should fail if
>> there are no EFI_MEMORY_RUNTIME regions?
>>
>
> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
> means we can't use runtime services and should not set the bit
> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
> true, the bit will be set.
>

As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
for other reasons, don't rig efi_virtmap_init() to return false when
it shouldn't.

>> The absence of such regions is allowed by the spec, so
>> efi_virtmap_init() is correct imo to return success.
>>
> Sorry, not well know about the spec. Could you point out where the spec
> says this?
>

Well, I think it doesn't work that way. You are claiming that a memory
map without at least one EFI_MEMORY_RUNTIME constitutes an error
condition, so the burden is on you to provide a reference to the spec
that says you must have at least one such region.

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224015 — Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

>>> On 14.09.15 at 11:36, <ard.biesheuvel@linaro.org> wrote:
> On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>> means we can't use runtime services and should not set the bit
>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>> true, the bit will be set.
>>
> 
> As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
> for other reasons, don't rig efi_virtmap_init() to return false when
> it shouldn't.
> 
>>> The absence of such regions is allowed by the spec, so
>>> efi_virtmap_init() is correct imo to return success.
>>>
>> Sorry, not well know about the spec. Could you point out where the spec
>> says this?
>>
> 
> Well, I think it doesn't work that way. You are claiming that a memory
> map without at least one EFI_MEMORY_RUNTIME constitutes an error
> condition, so the burden is on you to provide a reference to the spec
> that says you must have at least one such region.

Sure, from a spec pov you're right. But where would runtime
services code/data live when there's not a single region marked
as needing a runtime mapping. IOW while the spec doesn't say
so, assuming no runtime services when there's not at least one
executable region with the runtime flag set could serve as a stop
gap measure against flawed firmware.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224033 — Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On 14 September 2015 at 12:39, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 14.09.15 at 11:36, <ard.biesheuvel@linaro.org> wrote:
>> On 14 September 2015 at 11:31, Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>> My understanding is that if there are no EFI_MEMORY_RUNTIME regions, it
>>> means we can't use runtime services and should not set the bit
>>> EFI_RUNTIME_SERVICES of efi.flags. But if efi_virtmap_init() return
>>> true, the bit will be set.
>>>
>>
>> As I said, if you don't want the EFI_RUNTIME_SERVICES bit to be set
>> for other reasons, don't rig efi_virtmap_init() to return false when
>> it shouldn't.
>>
>>>> The absence of such regions is allowed by the spec, so
>>>> efi_virtmap_init() is correct imo to return success.
>>>>
>>> Sorry, not well know about the spec. Could you point out where the spec
>>> says this?
>>>
>>
>> Well, I think it doesn't work that way. You are claiming that a memory
>> map without at least one EFI_MEMORY_RUNTIME constitutes an error
>> condition, so the burden is on you to provide a reference to the spec
>> that says you must have at least one such region.
>
> Sure, from a spec pov you're right. But where would runtime
> services code/data live when there's not a single region marked
> as needing a runtime mapping. IOW while the spec doesn't say
> so, assuming no runtime services when there's not at least one
> executable region with the runtime flag set could serve as a stop
> gap measure against flawed firmware.
>

That in itself is a fair point. But the argument being made was that
it is in itself a bug for no EFI_MEMORY_RUNTIME regions to exist,
while the actual purpose of the patch is to prevent the
RuntimeServices pointer from being dereferenced on platforms like Xen
that may not be able to implement them.

But actually, even in case of Xen, you will need some
EFI_MEMORY_RUNTIME regions anyway, since the f/w vendor field and the
config and runtime services table pointers are translated to virtual
addresses by the firmware, which means the OS needs to translate them
back to physical addresses in order to dereference them before the VA
mapping is up. (I still think not using SetVirtualAddressMap() at all
would be the best approach for arm64, but unfortunately, most of my
colleagues disagree with me)

-- 
Ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224039 — Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

>>> On 14.09.15 at 13:16, <ard.biesheuvel@linaro.org> wrote:
> (I still think not using SetVirtualAddressMap() at all
> would be the best approach for arm64, but unfortunately, most of my
> colleagues disagree with me)

Any reasons they have? I'm curious because we run x86 Xen without
using this function ...

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222963 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> It feels like this discussion is going in circles.
> 
> When we discussed this six months ago, we already concluded that,
> since UEFI is the only specified way that the presence of ACPI is
> advertised on an ARM system, we need to emulate UEFI to some extent.

My understanding from the last time I was present at such a discussion
was that the emulation was complete from the kernel's PoV (i.e. no
special case handling was required). 

Evidently I misunderstood.

One of the main points of rationale for requiring EFI was that we'd have
a well-defined system state as per the EFI (and ACPI) standards. We'd
know we had the EFI memory map, services, etc (with the memory map and
configuration tables being the most important elements). We didn't want
to have to try to reconcile a DT memory map and ACPI, for instance.

That is somewhat (though admitedly not entirely) broken if we require a
set of rules to be applied beyond what the standards mandate.  That is
broken if we require a non-standard set of rules to be applied, and
limits what we can do in the !Xen case.

> So we need the EFI system table to expose the UEFI configuration table
> that carries the ACPI root pointer.
> 
> Since ACPI support also relies on the UEFI memory map (I think?), we
> need that as well.
> 
> These two items are exactly what we pass via the UEFI DT properties,
> so we should indeed promote the current de-facto binding to a proper
> binding, and renaming the properties makes sense in that context.

I agree that we need to sort these out.

> I agree that this should also include a description of the expected
> state of the firmware, i.e., that ExitBootServices() has been called,
> and that the memory map has been populated with virtual address, which
> have been installed using SetVirtualAddressMap() if they differ from
> the physical addresses. (The current implementation on the kernel side
> is perfectly capable of dealing with a 1:1 mapping).
> 
> Beyond that, there is no point in pretending to be a full UEFI
> implementation, imo. Boot services are not required, nor are runtime
> services (only the current EFI init code on arm needs to be modified
> to deal with a NULL runtime services pointer)

I'm not keen on this because it involves applying Xen-specific caveats
atop of what the UEFI spec says (e.g. as runtime services might be NULL
under Xen). As the spec and Xen evolve, those caveats shift, and that's
going to be fragile for all users regardleses of Xen.

If Xen needs special-casing, then I'd rather that Xen were detected
first and provided us with what it knows is safe for us to use, rather
than we tip-toe around until we're sure Xen isn't present and/or doesn't
need additional constraints met.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222946 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> > > > C) When you could go:
> > > >
> > > >    DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI discovery
> > >
> > > I take you mean discovering Xen with the usual Xen hypervisor node on
> > > device tree. I think that C) is a good option actually. I like it. Not
> > > sure why we didn't think about this earlier. Is there anything EFI or
> > > ACPI which is needed before Xen support is discovered by
> > > arch/arm64/kernel/setup.c:setup_arch -> xen_early_init()?
> >
> > Currently lots (including the memory map). With the stuff to support
> > SPCR, the ACPI discovery would be moved before xen_early_init().
> >
> > > If not, we could just go for this. A lot of complexity would go away.
> >
> > I suspect this would still be fairly complex, but would at least prevent
> > the Xen-specific EFI handling from adversely affecting the native case.
> >
> > > > D) If you want to be generic:
> > > >    EFI -> EFI application -> EFI tables -> ACPI tables -> Xen-specific stuff
> > > >           \------------------------------------------/
> > > > 	   (virtualize these, provide shims to Dom0, but handle
> > > > 	    everything in Xen itself)
> > >
> > > I think that this is good in theory but could turn out to be a lot of
> > > work in practice. We could probably virtualize the RuntimeServices but
> > > the BootServices are troublesome.
> >
> > What's troublesome with the boot services?
> >
> > What can't be simulated?
> 
> How do you want to access bare metal EFI boot services from dom0 if they
> were shutdown long time ago before loading dom0 image?

I don't want to.

I asked "What can't be simulated?" because I assumed everything
necessary/mandatory could be simulated without needinng access to any
real EFI boot services.

As far as I can see all that's necessary is to provide a compatible
interface.

> What do you need from EFI boot services in dom0?

The ability to call ExitBootServices() and SetVirtualAddressMap() on a
_virtual_ address map for _virtual_ services provided by the hypervisor.
A console so that I can log things early on.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223391 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:

[...]

> > > What's troublesome with the boot services?
> > >
> > > What can't be simulated?
> >
> > How do you want to access bare metal EFI boot services from dom0 if they
> > were shutdown long time ago before loading dom0 image?
>
> I don't want to.
>
> I asked "What can't be simulated?" because I assumed everything
> necessary/mandatory could be simulated without needinng access to any
> real EFI boot services.
>
> As far as I can see all that's necessary is to provide a compatible
> interface.

Could you be more precise what do you need? Please enumerate. UEFI spec has
more than 2500 pages and I do not think that we need all stuff in dom0.

> > What do you need from EFI boot services in dom0?
>
> The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> _virtual_ address map for _virtual_ services provided by the hypervisor.

I am confused. Why do you need that? Please remember, EFI is owned and
operated by Xen hypervisor. dom0 does not have direct access to EFI.
All stuff required in dom0 is provided via hypercalls. If you need an
extra data form EFI in dom0 please extend currently exiting API. Do
not emulate whole EFI if you need one or a few things from spec.

> A console so that I can log things early on.

IIUC, log from dom0. Please use machinery provided by Xen hypervisor.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223968 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> 
> [...]
> 
> > > > What's troublesome with the boot services?
> > > >
> > > > What can't be simulated?
> > >
> > > How do you want to access bare metal EFI boot services from dom0 if they
> > > were shutdown long time ago before loading dom0 image?
> >
> > I don't want to.
> >
> > I asked "What can't be simulated?" because I assumed everything
> > necessary/mandatory could be simulated without needinng access to any
> > real EFI boot services.
> >
> > As far as I can see all that's necessary is to provide a compatible
> > interface.
> 
> Could you be more precise what do you need? Please enumerate. UEFI spec has
> more than 2500 pages and I do not think that we need all stuff in dom0.
> 
> > > What do you need from EFI boot services in dom0?
> >
> > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> > _virtual_ address map for _virtual_ services provided by the hypervisor.
> 
> I am confused. Why do you need that? Please remember, EFI is owned and
> operated by Xen hypervisor. dom0 does not have direct access to EFI.

Let's take a step back.

My objection here is to passing the Dom0 kernel properties as if it were
booted with direct access to a full UEFI, then later fixing that up
(when Xen is detected and we apply its hypercall EFI implementation).

If the kernel cannot use EFI natively, why pretend to the kernel that it
can? The hypercall implementation is _not_ EFI (though it provides
access to some services).

The two ways I can see providing Dom0 with EFI services are:

* Have Xen create shims for any services, in which any hypercalls live,
  and pass these to the kernel with a virtual system table. This keeps
  the interface to the kernel the same regardless of Xen.

* Have the kernel detect Xen EFI capability via Xen, without passing the
  usual native EFI parameters. This can then be installed into the
  kernel in a Xen-specific manner, and we know from the outset that
  Xen-specific caveats apply.

As per my original email, I'm not against the renaming of the stub
parameters if we standardise the rest of the details, but I believe
that's orthogonal to the Xen Dom0 case.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223990 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Mon, 14 Sep 2015, Mark Rutland wrote:
> On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> > 
> > [...]
> > 
> > > > > What's troublesome with the boot services?
> > > > >
> > > > > What can't be simulated?
> > > >
> > > > How do you want to access bare metal EFI boot services from dom0 if they
> > > > were shutdown long time ago before loading dom0 image?
> > >
> > > I don't want to.
> > >
> > > I asked "What can't be simulated?" because I assumed everything
> > > necessary/mandatory could be simulated without needinng access to any
> > > real EFI boot services.
> > >
> > > As far as I can see all that's necessary is to provide a compatible
> > > interface.
> > 
> > Could you be more precise what do you need? Please enumerate. UEFI spec has
> > more than 2500 pages and I do not think that we need all stuff in dom0.
> > 
> > > > What do you need from EFI boot services in dom0?
> > >
> > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> > > _virtual_ address map for _virtual_ services provided by the hypervisor.
> > 
> > I am confused. Why do you need that? Please remember, EFI is owned and
> > operated by Xen hypervisor. dom0 does not have direct access to EFI.
> 
> Let's take a step back.
> 
> My objection here is to passing the Dom0 kernel properties as if it were
> booted with direct access to a full UEFI, then later fixing that up
> (when Xen is detected and we apply its hypercall EFI implementation).
> 
> If the kernel cannot use EFI natively, why pretend to the kernel that it
> can? The hypercall implementation is _not_ EFI (though it provides
> access to some services).
> 
> The two ways I can see providing Dom0 with EFI services are:
> 
> * Have Xen create shims for any services, in which any hypercalls live,
>   and pass these to the kernel with a virtual system table. This keeps
>   the interface to the kernel the same regardless of Xen.

A not a fan of three-point estimates, so I am just going to say that
"this looks like a lot of work". Also emulating services is known to be
prone to errors.


> * Have the kernel detect Xen EFI capability via Xen, without passing the
>   usual native EFI parameters. This can then be installed into the
>   kernel in a Xen-specific manner, and we know from the outset that
>   Xen-specific caveats apply.

I prefer this approach by far. In the future we might have to move the
xen_early_init call earlier (before ACPI and EFI Runtime Services get
initialized).


> As per my original email, I'm not against the renaming of the stub
> parameters if we standardise the rest of the details, but I believe
> that's orthogonal to the Xen Dom0 case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224076 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Mon, Sep 14, 2015 at 10:25:19AM +0100, Mark Rutland wrote:
> On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel Kiper wrote:
> > On Fri, Sep 11, 2015 at 05:25:59PM +0100, Mark Rutland wrote:
> > > On Fri, Sep 11, 2015 at 01:46:43PM +0100, Daniel Kiper wrote:
> > > > On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> >
> > [...]
> >
> > > > > What's troublesome with the boot services?
> > > > >
> > > > > What can't be simulated?
> > > >
> > > > How do you want to access bare metal EFI boot services from dom0 if they
> > > > were shutdown long time ago before loading dom0 image?
> > >
> > > I don't want to.
> > >
> > > I asked "What can't be simulated?" because I assumed everything
> > > necessary/mandatory could be simulated without needinng access to any
> > > real EFI boot services.
> > >
> > > As far as I can see all that's necessary is to provide a compatible
> > > interface.
> >
> > Could you be more precise what do you need? Please enumerate. UEFI spec has
> > more than 2500 pages and I do not think that we need all stuff in dom0.
> >
> > > > What do you need from EFI boot services in dom0?
> > >
> > > The ability to call ExitBootServices() and SetVirtualAddressMap() on a
> > > _virtual_ address map for _virtual_ services provided by the hypervisor.
> >
> > I am confused. Why do you need that? Please remember, EFI is owned and
> > operated by Xen hypervisor. dom0 does not have direct access to EFI.
>
> Let's take a step back.
>
> My objection here is to passing the Dom0 kernel properties as if it were
> booted with direct access to a full UEFI, then later fixing that up
> (when Xen is detected and we apply its hypercall EFI implementation).
>
> If the kernel cannot use EFI natively, why pretend to the kernel that it
> can? The hypercall implementation is _not_ EFI (though it provides
> access to some services).
>
> The two ways I can see providing Dom0 with EFI services are:
>
> * Have Xen create shims for any services, in which any hypercalls live,
>   and pass these to the kernel with a virtual system table. This keeps
>   the interface to the kernel the same regardless of Xen.
>
> * Have the kernel detect Xen EFI capability via Xen, without passing the
>   usual native EFI parameters. This can then be installed into the
>   kernel in a Xen-specific manner, and we know from the outset that
>   Xen-specific caveats apply.

It works on x86 in that way and I suppose that it can work in that way on ARM too.
So, just go and reuse existing code. That is all.

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222718 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, 2015-09-10 at 17:10 +0100, Stefano Stabellini wrote:

> > C) When you could go:
> > 
> >    DT -> Discover Xen -> Xen-specific stuff -> Xen-specific EFI/ACPI
> > discovery
> 
> I take you mean discovering Xen with the usual Xen hypervisor node on
> device tree.

There may be other options, such as ARM defining an architectural mechanism
to do early detection of hypervisors e.g. by defining some bit in some
hypervisor controllable register (MPIDR?) to say "a hypervisor is present"
and defining an hvc or smc call which can be used to ask which one it is.

Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222175 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

>>> On 10.09.15 at 13:37, <stefano.stabellini@eu.citrix.com> wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
>> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
>> create pages of RuntimeServicesCode that are trivial assembly shims
>> doing hypercalls, and plumb these into the virtual EFI memory map and
>> tables?
>> 
>> That would keep things sane for any guest, allow for easy addition of
>> EFI features, and you could even enter the usual EFI entry point,
>> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
>> to make things sane for itself...
> 
> That's the way it was done on x86 and now we have common code both in
> Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
> scheme.  Switching to a different solution for ARM, would mean diverging
> with x86, which is not nice, or reimplementing the x86 solution too,
> which is expensive.
> 
> BTW I think that the idea you proposed was actually considered at the
> time and deemed hard to implement, if I recall correctly.

Considering that the EFI support is just for Dom0, and Dom0 (at
the time) had to be PV anyway, it was the more natural solution to
expose the interface via hypercalls, the more that this allows better
control over what is and primarily what is not being exposed to
Dom0. With the wrapper approach we'd be back to the same
problem (discussed elsewhere) of which EFI version to surface: The
host one would impose potentially missing extensions, while the
most recent hypervisor known one might imply hiding valuable
information from Dom0. Plus there are incompatible changes like
the altered meaning of EFI_MEMORY_WP in 2.5.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222247 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
> >>> On 10.09.15 at 13:37, <stefano.stabellini@eu.citrix.com> wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
> >> create pages of RuntimeServicesCode that are trivial assembly shims
> >> doing hypercalls, and plumb these into the virtual EFI memory map and
> >> tables?
> >> 
> >> That would keep things sane for any guest, allow for easy addition of
> >> EFI features, and you could even enter the usual EFI entry point,
> >> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
> >> to make things sane for itself...
> > 
> > That's the way it was done on x86 and now we have common code both in
> > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
> > scheme.  Switching to a different solution for ARM, would mean diverging
> > with x86, which is not nice, or reimplementing the x86 solution too,
> > which is expensive.
> > 
> > BTW I think that the idea you proposed was actually considered at the
> > time and deemed hard to implement, if I recall correctly.
> 
> Considering that the EFI support is just for Dom0, and Dom0 (at
> the time) had to be PV anyway, it was the more natural solution to
> expose the interface via hypercalls, the more that this allows better
> control over what is and primarily what is not being exposed to
> Dom0. With the wrapper approach we'd be back to the same
> problem (discussed elsewhere) of which EFI version to surface: The
> host one would impose potentially missing extensions, while the
> most recent hypervisor known one might imply hiding valuable
> information from Dom0. Plus there are incompatible changes like
> the altered meaning of EFI_MEMORY_WP in 2.5.

I'm not sure I follow how hypercalls solve any impedance mismatch here;
you're still expecting Dom0 to call up to Xen in order to perform calls,
and all I suggested was a different location for those hypercalls.

If Xen is happy to make such calls blindly, why does it matter if the
hypercall was in the kernel binary or an external shim?

Incompatible changes are a spec problem regardless of how this is
handled.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222252 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

>>> On 10.09.15 at 16:53, <mark.rutland@arm.com> wrote:
> On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
>> >>> On 10.09.15 at 13:37, <stefano.stabellini@eu.citrix.com> wrote:
>> > On Thu, 10 Sep 2015, Mark Rutland wrote:
>> >> Why can't Xen give a virtual EFI interface to Dom0 / guests? e.g.
>> >> create pages of RuntimeServicesCode that are trivial assembly shims
>> >> doing hypercalls, and plumb these into the virtual EFI memory map and
>> >> tables?
>> >> 
>> >> That would keep things sane for any guest, allow for easy addition of
>> >> EFI features, and you could even enter the usual EFI entry point,
>> >> simulate ExitBootServices(), SetVirtualAddressMap(), and allow the guest
>> >> to make things sane for itself...
>> > 
>> > That's the way it was done on x86 and now we have common code both in
>> > Linux (drivers/xen/efi.c) and Xen (xen/common/efi) which implement this
>> > scheme.  Switching to a different solution for ARM, would mean diverging
>> > with x86, which is not nice, or reimplementing the x86 solution too,
>> > which is expensive.
>> > 
>> > BTW I think that the idea you proposed was actually considered at the
>> > time and deemed hard to implement, if I recall correctly.
>> 
>> Considering that the EFI support is just for Dom0, and Dom0 (at
>> the time) had to be PV anyway, it was the more natural solution to
>> expose the interface via hypercalls, the more that this allows better
>> control over what is and primarily what is not being exposed to
>> Dom0. With the wrapper approach we'd be back to the same
>> problem (discussed elsewhere) of which EFI version to surface: The
>> host one would impose potentially missing extensions, while the
>> most recent hypervisor known one might imply hiding valuable
>> information from Dom0. Plus there are incompatible changes like
>> the altered meaning of EFI_MEMORY_WP in 2.5.
> 
> I'm not sure I follow how hypercalls solve any impedance mismatch here;
> you're still expecting Dom0 to call up to Xen in order to perform calls,
> and all I suggested was a different location for those hypercalls.
> 
> If Xen is happy to make such calls blindly, why does it matter if the
> hypercall was in the kernel binary or an external shim?

Because there could be new entries in SystemTable->RuntimeServices
(expected and blindly but validly called by the kernel). Even worse
(because likely harder to deal with) would be new fields in other
structures.

> Incompatible changes are a spec problem regardless of how this is
> handled.

Not necessarily - we don't expose the memory map (we'd have to
if we were to mimic EFI for Dom0), and hence the mentioned issue
doesn't exist in our model.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222960 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

> >> Considering that the EFI support is just for Dom0, and Dom0 (at
> >> the time) had to be PV anyway, it was the more natural solution to
> >> expose the interface via hypercalls, the more that this allows better
> >> control over what is and primarily what is not being exposed to
> >> Dom0. With the wrapper approach we'd be back to the same
> >> problem (discussed elsewhere) of which EFI version to surface: The
> >> host one would impose potentially missing extensions, while the
> >> most recent hypervisor known one might imply hiding valuable
> >> information from Dom0. Plus there are incompatible changes like
> >> the altered meaning of EFI_MEMORY_WP in 2.5.
> > 
> > I'm not sure I follow how hypercalls solve any impedance mismatch here;
> > you're still expecting Dom0 to call up to Xen in order to perform calls,
> > and all I suggested was a different location for those hypercalls.
> > 
> > If Xen is happy to make such calls blindly, why does it matter if the
> > hypercall was in the kernel binary or an external shim?
> 
> Because there could be new entries in SystemTable->RuntimeServices
> (expected and blindly but validly called by the kernel). Even worse
> (because likely harder to deal with) would be new fields in other
> structures.

Any of these could cause Xen to blow up, while Xen could always provide
a known-safe (but potentially sub-optimal) view to the kernel by
default.

> > Incompatible changes are a spec problem regardless of how this is
> > handled.
> 
> Not necessarily - we don't expose the memory map (we'd have to
> if we were to mimic EFI for Dom0), and hence the mentioned issue
> doesn't exist in our model.

We have to expose _some_ memory map, so I don't follow this point.

Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222134 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On Thu, 10 Sep 2015 16:41:56 +0800
Shannon Zhao <zhaoshenglong@huawei.com> wrote:

> From: Shannon Zhao <shannon.zhao@linaro.org>
> 
> These EFI stub parameters are used to internal communication between
> EFI stub and Linux kernel and EFI stub creates these parameters. But
> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
> providing these parameters for Dom0 and Dom0 is not only Linux
> kernel, but also other OS (such as FreeBSD) which will be used in the
> future. So here we plan to standardize the names by dropping the
> prefix "linux," and make them common to other OS. Also this will not
> break the compatibility since these parameters are used to internal
> communication between EFI stub and kernel.

It is unlikely FreeBSD will use this property when booting ad Xen dom0.
The kernel expects to be passed a data structure to find boot this
information.

My preference would be to have the FreeBSD loader load the xen binary,
the FreeBSD kernel, and set up these data structs before passing
control to Xen, with the information it needs to boot the kernel. My
understanding is this is how it is done on x86.

I can see a few issues with this where, for example, the device tree or
ACPI tables need to be modified, but these should be solvable.

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222138

On 10/09/15 12:32, Andrew Turner wrote:
> On Thu, 10 Sep 2015 16:41:56 +0800
> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
> 
>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>
>> These EFI stub parameters are used to internal communication between
>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>> providing these parameters for Dom0 and Dom0 is not only Linux
>> kernel, but also other OS (such as FreeBSD) which will be used in the
>> future. So here we plan to standardize the names by dropping the
>> prefix "linux," and make them common to other OS. Also this will not
>> break the compatibility since these parameters are used to internal
>> communication between EFI stub and kernel.
> 
> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
> The kernel expects to be passed a data structure to find boot this
> information.
> 
> My preference would be to have the FreeBSD loader load the xen binary,
> the FreeBSD kernel, and set up these data structs before passing
> control to Xen, with the information it needs to boot the kernel. My
> understanding is this is how it is done on x86.

Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
faking a multiboot module which contains all the informations.

I know that the bootloader is at least involved, I don't remember if
there is some code in FreeBSD to read this boot module. I've CCed Roger
to confirm.

> I can see a few issues with this where, for example, the device tree or
> ACPI tables need to be modified, but these should be solvable.

Xen has to modify the firmware table in order to remove everything that
it's used by itself (UART, virtual GIC...).

So we would need to modify the FreeBSD data structure to pass the new
DT/ACPI. Does the metadata are standardize? I.e is it stable from
accross FreeBSD version?

Anyway, I'd like to avoid any FreeBSD specific code in Xen, and even any
OS specific code in Xen. It's better if we keep a common interface for
everyone.

Regards,

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222153 — Re: [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

El 10/09/15 a les 13.48, Julien Grall ha escrit:
> On 10/09/15 12:32, Andrew Turner wrote:
>> On Thu, 10 Sep 2015 16:41:56 +0800
>> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>
>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>
>>> These EFI stub parameters are used to internal communication between
>>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>>> providing these parameters for Dom0 and Dom0 is not only Linux
>>> kernel, but also other OS (such as FreeBSD) which will be used in the
>>> future. So here we plan to standardize the names by dropping the
>>> prefix "linux," and make them common to other OS. Also this will not
>>> break the compatibility since these parameters are used to internal
>>> communication between EFI stub and kernel.
>>
>> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
>> The kernel expects to be passed a data structure to find boot this
>> information.
>>
>> My preference would be to have the FreeBSD loader load the xen binary,
>> the FreeBSD kernel, and set up these data structs before passing
>> control to Xen, with the information it needs to boot the kernel. My
>> understanding is this is how it is done on x86.
> 
> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
> faking a multiboot module which contains all the informations.
> 
> I know that the bootloader is at least involved, I don't remember if
> there is some code in FreeBSD to read this boot module. I've CCed Roger
> to confirm.

The metadata/modules needed by the FreeBSD Dom0 kernel is generated by
the native FreeBSD bootloader (as would be done when booting bare
metal). Then this blob is passed as a multiboot module in the same place
that Linux puts it's initramfs. Xen simply copies this blob straight
into guest memory and sets start_info.mod_start to point to the start
memory address of this blob.

I've done it this way because I don't see many other options. Xen is
tailored for Linux and only allows passing one module to the Dom0 kernel
(initramfs). For FreeBSD it would be good to be able to pass at least
two modules to the Dom0 kernel, one containing the metadata, and the
other one containing the modules themselves. The new PVH work (HVMlite
or whatever) will hopefully allow passing more than one module to the
Dom0 kernel, and should make the code in the FreeBSD loader simpler.

Roger.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222171 — Re: [Xen-devel] [PATCH] efi/libstub/fdt: Standardize the names of EFI stub parameters

On 10/09/15 13:05, Roger Pau Monné wrote:
> El 10/09/15 a les 13.48, Julien Grall ha escrit:
>> On 10/09/15 12:32, Andrew Turner wrote:
>>> On Thu, 10 Sep 2015 16:41:56 +0800
>>> Shannon Zhao <zhaoshenglong@huawei.com> wrote:
>>>
>>>> From: Shannon Zhao <shannon.zhao@linaro.org>
>>>>
>>>> These EFI stub parameters are used to internal communication between
>>>> EFI stub and Linux kernel and EFI stub creates these parameters. But
>>>> for Xen on ARM when booting with UEFI, Xen will create a minimal DT
>>>> providing these parameters for Dom0 and Dom0 is not only Linux
>>>> kernel, but also other OS (such as FreeBSD) which will be used in the
>>>> future. So here we plan to standardize the names by dropping the
>>>> prefix "linux," and make them common to other OS. Also this will not
>>>> break the compatibility since these parameters are used to internal
>>>> communication between EFI stub and kernel.
>>>
>>> It is unlikely FreeBSD will use this property when booting ad Xen dom0.
>>> The kernel expects to be passed a data structure to find boot this
>>> information.
>>>
>>> My preference would be to have the FreeBSD loader load the xen binary,
>>> the FreeBSD kernel, and set up these data structs before passing
>>> control to Xen, with the information it needs to boot the kernel. My
>>> understanding is this is how it is done on x86.
>>
>> Well, AFAICT, there is no FreeBSD specific code in Xen for x86. We are
>> faking a multiboot module which contains all the informations.
>>
>> I know that the bootloader is at least involved, I don't remember if
>> there is some code in FreeBSD to read this boot module. I've CCed Roger
>> to confirm.
> 
> The metadata/modules needed by the FreeBSD Dom0 kernel is generated by
> the native FreeBSD bootloader (as would be done when booting bare
> metal). Then this blob is passed as a multiboot module in the same place
> that Linux puts it's initramfs. Xen simply copies this blob straight
> into guest memory and sets start_info.mod_start to point to the start
> memory address of this blob.
> 
> I've done it this way because I don't see many other options. Xen is
> tailored for Linux and only allows passing one module to the Dom0 kernel
> (initramfs). For FreeBSD it would be good to be able to pass at least
> two modules to the Dom0 kernel, one containing the metadata, and the
> other one containing the modules themselves. The new PVH work (HVMlite
> or whatever) will hopefully allow passing more than one module to the
> Dom0 kernel, and should make the code in the FreeBSD loader simpler.

We have a multiboot based on device tree to boot Xen on ARM [1].

It may be possible to create another kind of module storing the FreeBSD
metadata and make a trampoline for Xen in FreeBSD to pass the
information correctly to the DOM0 kernel.

But the main problem is we have to modify those metadata because,
AFAICT, the device tree/ACPI blob is part of them. It also seems to be
the same for UEFI.

That means we need some knowledge in Xen to parse/modify those metadata.
Unless they are stable (i.e clearly defined, not changing, place in
memory known...), we can't use them in Xen as we would need to adapt for
every changes.

If it's stable, we have to know that we are using FreeBSD (could be done
with the multiboot string).

Although, I would be more in favor of the loader using the Xen boot
interface with a new multiboot module, Xen jumping on a trampoline in
the FreeBSD kernel still using the Guest Boot ABI (similar the the Linux
ABI). The trampoline would recreate the metadata with the new DT and
jump into the kernel.

I will give a look to this when I'm done with the FreeBSD ARM guest support.

Regards,

[1] http://xenbits.xen.org/docs/unstable/misc/arm/device-tree/booting.txt

-- 
Julien Grall
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web