On Thu, Jun 19, 2014 at 03:41:12PM +0100, Matt Fleming wrote:
> On Wed, 18 Jun, at 06:48:35PM, Daniel Kiper wrote:
> > >
> > > Why don't you want to export efi.fw_vendor, etc? Rationale please.
> >
> > I am exporting real addresses (machine addresses) of things which
> > I am able to get. Stuff
On Thu, Jun 19, 2014 at 03:41:12PM +0100, Matt Fleming wrote:
On Wed, 18 Jun, at 06:48:35PM, Daniel Kiper wrote:
Why don't you want to export efi.fw_vendor, etc? Rationale please.
I am exporting real addresses (machine addresses) of things which
I am able to get. Stuff which was
On Wed, 18 Jun, at 06:48:35PM, Daniel Kiper wrote:
> >
> > Why don't you want to export efi.fw_vendor, etc? Rationale please.
>
> I am exporting real addresses (machine addresses) of things which
> I am able to get. Stuff which was created artificially and lives
> in dom0 address space or does
On Wed, 18 Jun, at 06:48:35PM, Daniel Kiper wrote:
Why don't you want to export efi.fw_vendor, etc? Rationale please.
I am exporting real addresses (machine addresses) of things which
I am able to get. Stuff which was created artificially and lives
in dom0 address space or does not exist
On Wed, Jun 18, 2014 at 02:52:29PM +0100, Matt Fleming wrote:
> On Fri, 13 Jun, at 07:00:18PM, Daniel Kiper wrote:
> > Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
> > on EFI platform but it has not direct control on EFI stuff
> > like EFI runtime, tables, structures, etc. If not
On Wed, 18 Jun, at 03:30:25PM, Stefano Stabellini wrote:
>
> I was thinking the same thing.
>
> However this patch series doesn't add much code outside
> drivers/xen/efi.c and include/xen/interface/platform.h.
> I think it wouldn't be fair to ask Daniel to refactor the efi code
> currently under
On Wed, Jun 18, 2014 at 03:30:25PM +0100, Stefano Stabellini wrote:
> On Wed, 18 Jun 2014, Jan Beulich wrote:
> > >>> On 18.06.14 at 15:52, wrote:
> > > EFI_PARAVIRT will be usable by architectures other than x86, correct? If
> > > your intention is for it only ever to be used by x86, then it
On Wed, 18 Jun 2014, Jan Beulich wrote:
> >>> On 18.06.14 at 15:52, wrote:
> > EFI_PARAVIRT will be usable by architectures other than x86, correct? If
> > your intention is for it only ever to be used by x86, then it should
> > probably be EFI_ARCH_2.
>
> I would expect ARM, once it gets UEFI
>>> On 18.06.14 at 15:52, wrote:
> EFI_PARAVIRT will be usable by architectures other than x86, correct? If
> your intention is for it only ever to be used by x86, then it should
> probably be EFI_ARCH_2.
I would expect ARM, once it gets UEFI support on the Xen side, to
be able to handle most of
On Fri, 13 Jun, at 07:00:18PM, Daniel Kiper wrote:
> Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
> on EFI platform but it has not direct control on EFI stuff
> like EFI runtime, tables, structures, etc. If not this means
> that Linux Kernel has direct access to EFI infrastructure
>
On Fri, 13 Jun, at 07:00:18PM, Daniel Kiper wrote:
Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
on EFI platform but it has not direct control on EFI stuff
like EFI runtime, tables, structures, etc. If not this means
that Linux Kernel has direct access to EFI infrastructure
and
On 18.06.14 at 15:52, m...@console-pimps.org wrote:
EFI_PARAVIRT will be usable by architectures other than x86, correct? If
your intention is for it only ever to be used by x86, then it should
probably be EFI_ARCH_2.
I would expect ARM, once it gets UEFI support on the Xen side, to
be able
On Wed, 18 Jun 2014, Jan Beulich wrote:
On 18.06.14 at 15:52, m...@console-pimps.org wrote:
EFI_PARAVIRT will be usable by architectures other than x86, correct? If
your intention is for it only ever to be used by x86, then it should
probably be EFI_ARCH_2.
I would expect ARM, once it
On Wed, Jun 18, 2014 at 03:30:25PM +0100, Stefano Stabellini wrote:
On Wed, 18 Jun 2014, Jan Beulich wrote:
On 18.06.14 at 15:52, m...@console-pimps.org wrote:
EFI_PARAVIRT will be usable by architectures other than x86, correct? If
your intention is for it only ever to be used by x86,
On Wed, 18 Jun, at 03:30:25PM, Stefano Stabellini wrote:
I was thinking the same thing.
However this patch series doesn't add much code outside
drivers/xen/efi.c and include/xen/interface/platform.h.
I think it wouldn't be fair to ask Daniel to refactor the efi code
currently under
On Wed, Jun 18, 2014 at 02:52:29PM +0100, Matt Fleming wrote:
On Fri, 13 Jun, at 07:00:18PM, Daniel Kiper wrote:
Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
on EFI platform but it has not direct control on EFI stuff
like EFI runtime, tables, structures, etc. If not this
On 13/06/14 18:00, Daniel Kiper wrote:
> Introduce EFI_NO_DIRECT flag.
EFI_PARAVIRT would be a clearer name I think.
> +#define EFI_NO_DIRECT6 /* Can we access EFI directly?
> */
#define EFI_PARAVIRT 6 /* Access is via a paravirt interface */
David
--
To unsubscribe from
On 13/06/14 18:00, Daniel Kiper wrote:
Introduce EFI_NO_DIRECT flag.
EFI_PARAVIRT would be a clearer name I think.
+#define EFI_NO_DIRECT6 /* Can we access EFI directly?
*/
#define EFI_PARAVIRT 6 /* Access is via a paravirt interface */
David
--
To unsubscribe from
Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
on EFI platform but it has not direct control on EFI stuff
like EFI runtime, tables, structures, etc. If not this means
that Linux Kernel has direct access to EFI infrastructure
and everything runs as usual.
This functionality is used in
Introduce EFI_NO_DIRECT flag. If it is set then kernel runs
on EFI platform but it has not direct control on EFI stuff
like EFI runtime, tables, structures, etc. If not this means
that Linux Kernel has direct access to EFI infrastructure
and everything runs as usual.
This functionality is used in
20 matches
Mail list logo
