Hi,
>From the comments on this patch, IIUC, we don't object to the change
brought by this patch. What we didn't reach an agreement is how to
support runtime service for Dom0. Right? If so, I think this patch
doesn't conflict with adding support for runtime service in the future.
So could we move t
On Mon, Sep 14, 2015 at 03:09:34PM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 14:28, Daniel Kiper wrote:
> > On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> >> On 14 September 2015 at 11:25, Mark Rutland wrote:
> >> > On Sat, Sep 12, 2015 at 12:36:55PM +0100, Daniel
On 14 September 2015 at 14:28, Daniel Kiper wrote:
> On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
>> On 14 September 2015 at 11:25, 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 Rutlan
On Mon, Sep 14, 2015 at 11:43:27AM +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 11:25, 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,
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:0
>>> On 14.09.15 at 13:16, 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
_
On 14 September 2015 at 12:39, Jan Beulich wrote:
On 14.09.15 at 11:36, wrote:
>> On 14 September 2015 at 11:31, Shannon Zhao 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
>>> On 14.09.15 at 11:36, wrote:
> On 14 September 2015 at 11:31, Shannon Zhao 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
On Mon, 2015-09-14 at 12:02 +0200, Ard Biesheuvel wrote:
> On 14 September 2015 at 11:57, Ian Campbell wrote:
> > > or SetVirtualAddressMap/ConvertPointer, and
> >
> > These two are RTS, so in principal it could.
> >
> > (I'm not sure about ConvertPointer, is it useful for OS kernels, or
> > ju
On 14 September 2015 at 11:57, Ian Campbell wrote:
> On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote:
>
>> Xen will not boot the kernel via the stub, but directly. It needs to
>> supply a EFI like environment so that the kernel can boot via ACPI.
>> There is no reason whatsoever to mock up
On Mon, 2015-09-14 at 11:43 +0200, Ard Biesheuvel wrote:
> Xen will not boot the kernel via the stub, but directly. It needs to
> supply a EFI like environment so that the kernel can boot via ACPI.
> There is no reason whatsoever to mock up boot services or other pieces
> of UEFI functionality tha
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 Rutla
On 14 September 2015 at 11:25, 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, Ma
(snip some cc's)
On 14 September 2015 at 11:31, Shannon Zhao wrote:
>
>
> On 2015/9/14 17:09, Ard Biesheuvel wrote:
>> On 14 September 2015 at 10:42, Shannon Zhao wrote:
>> [..]
>>
>>>
>>> It only needs to apply following patch to fix a bug in Linux kernel when
>>> mapping EFI_MEMORY_RUNTIME mem
On 2015/9/14 17:09, Ard Biesheuvel wrote:
> On 14 September 2015 at 10:42, Shannon Zhao 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
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 troublesom
On 14 September 2015 at 10:42, Shannon Zhao 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?
The absence of s
On 2015/9/11 23:45, Daniel Kiper wrote:
> On Fri, Sep 11, 2015 at 03:30:15PM +0200, Ard Biesheuvel wrote:
>> On 11 September 2015 at 15:14, Stefano Stabellini
>> wrote:
>>> On Fri, 11 Sep 2015, Daniel Kiper wrote:
On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
>>> C) When
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 d
> >> 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. Wit
> 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
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
On Fri, Sep 11, 2015 at 03:30:15PM +0200, Ard Biesheuvel wrote:
> On 11 September 2015 at 15:14, Stefano Stabellini
> wrote:
> > On Fri, 11 Sep 2015, Daniel Kiper wrote:
> >> On Thu, Sep 10, 2015 at 05:23:02PM +0100, Mark Rutland wrote:
> >> > > > C) When you could go:
> >> > > >
> >> > > >DT
On 11 September 2015 at 15:14, Stefano Stabellini
wrote:
> On Fri, 11 Sep 2015, 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
>> > > > disco
On Fri, 11 Sep 2015, 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 X
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)
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,
On Thu, 10 Sep 2015 16:41:56 +0800
Shannon Zhao wrote:
> From: Shannon Zhao
>
> 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
> pro
> > 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
On Thu, 10 Sep 2015, Mark Rutland wrote:
> On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> > > > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > > > > Does X
>>> On 10.09.15 at 16:53, wrote:
> On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
>> >>> On 10.09.15 at 13:37, 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
On Thu, Sep 10, 2015 at 01:55:25PM +0100, Jan Beulich wrote:
> >>> On 10.09.15 at 13:37, 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 hy
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> > > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > > > Does Xen not talk to EFI itself and/or give the kernel a
On Thu, Sep 10, 2015 at 02:52:25PM +0100, Stefano Stabellini wrote:
> > > In any case this should be separate from the shim ABI discussion.
> >
> > I disagree; I think this is very much relevant to the ABI discussion.
> > That's not to say that I insist on a particular approach, but I think
> > th
On Thu, 10 Sep 2015, Mark Rutland wrote:
> On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> > On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > > > > interface?
> > > >
> > > > Xen talks to EFI itself bu
On Thu, 2015-09-10 at 07:08 -0600, Jan Beulich wrote:
> > > > On 10.09.15 at 14:58, wrote:
> > On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
> >
> > > > In any case this should be separate from the shim ABI discussion.
> > >
> > > I disagree; I think this is very much relevant to the AB
>>> On 10.09.15 at 14:58, wrote:
> On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
>
>> > In any case this should be separate from the shim ABI discussion.
>>
>> I disagree; I think this is very much relevant to the ABI discussion.
>> That's not to say that I insist on a particular approa
On Thu, 2015-09-10 at 13:15 +0100, Mark Rutland wrote:
> > In any case this should be separate from the shim ABI discussion.
>
> I disagree; I think this is very much relevant to the ABI discussion.
> That's not to say that I insist on a particular approach, but I think
> that they need to be con
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 wrote:
>>>
From: Shannon Zhao
These EFI stub parameters are used to internal communication
>>> On 10.09.15 at 13:37, 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
On Thu, Sep 10, 2015 at 12:37:57PM +0100, Stefano Stabellini wrote:
> On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > > > interface?
> > >
> > > Xen talks to EFI itself but the interface provided to dom0 is somewhat
> > > di
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 wrote:
>>
>>> From: Shannon Zhao
>>>
>>> These EFI stub parameters are used to internal communication between
>>> EFI stub and Linux kernel and EFI stub
On 10/09/15 12:32, Andrew Turner wrote:
> On Thu, 10 Sep 2015 16:41:56 +0800
> Shannon Zhao wrote:
>
>> From: Shannon Zhao
>>
>> 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 boo
On Thu, 10 Sep 2015, Mark Rutland wrote:
> > > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > > interface?
> >
> > Xen talks to EFI itself but the interface provided to dom0 is somewhat
> > different: there are no BootServices (Xen calls ExitBootServices before
> > runnin
> > Does Xen not talk to EFI itself and/or give the kernel a virtual EFI
> > interface?
>
> Xen talks to EFI itself but the interface provided to dom0 is somewhat
> different: there are no BootServices (Xen calls ExitBootServices before
> running the kernel), and the RuntimeServices go via hyperca
On Thu, 10 Sep 2015, Mark Rutland wrote:
> Hi,
>
> I'm not necessarily opposed to the renaming, but I think that this is
> the least important thing to standardize for this to work.
>
> On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote:
> > From: Shannon Zhao
> >
> > These EFI stub p
Hi,
I'm not necessarily opposed to the renaming, but I think that this is
the least important thing to standardize for this to work.
On Thu, Sep 10, 2015 at 09:41:56AM +0100, Shannon Zhao wrote:
> From: Shannon Zhao
>
> These EFI stub parameters are used to internal communication between EFI
>
From: Shannon Zhao
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, b
48 matches
Mail list logo
