The document looks good to me. I would appreciate if the linux guys
could give a look at the last three paragraphs under section 5.
On Thu, 5 Nov 2015, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Any comments are welcome.
>
> Chang
This document is going to explain the design details of Xen booting with
ACPI on ARM. Any comments are welcome.
Changes v5->v6:
* add a new node "uefi" under /hypervisor to pass UEFI informations to
Dom0 instead of the nodes under /chosen.
* change creation of MADT table, get the information fro
On Mon, 7 Sep 2015, Shannon Zhao wrote:
> On 2015/9/2 20:18, Ian Campbell wrote:
> > On Fri, 2015-08-28 at 17:45 +0800, Shannon Zhao wrote:
> >>
> >> 1. Create minimal DT to pass required information to Dom0
> >> --
> >> The UEFI stub is a fea
On 2015/9/2 20:18, Ian Campbell wrote:
> On Fri, 2015-08-28 at 17:45 +0800, Shannon Zhao wrote:
>>
>> 1. Create minimal DT to pass required information to Dom0
>> --
>> The UEFI stub is a feature that extends the Image/zImage into a valid
>>
On 2 September 2015 at 17:27, Leif Lindholm wrote:
> On Wed, Sep 02, 2015 at 03:57:51PM +0200, Christoffer Dall wrote:
>> On Wed, Sep 2, 2015 at 3:54 PM, Ian Campbell wrote:
>> > On Wed, 2015-09-02 at 14:48 +0100, Julien Grall wrote:
>> >> On 02/09/15 14:26, Ian Campbell wrote:
>> >> > > > > I th
On Wed, Sep 02, 2015 at 03:57:51PM +0200, Christoffer Dall wrote:
> On Wed, Sep 2, 2015 at 3:54 PM, Ian Campbell wrote:
> > On Wed, 2015-09-02 at 14:48 +0100, Julien Grall wrote:
> >> On 02/09/15 14:26, Ian Campbell wrote:
> >> > > > > I think the problem is how you reserved this region in the EFI
On Wed, 2015-09-02 at 21:59 +0800, Shannon Zhao wrote:
> Hi Ian,
>
> On 2015/9/2 20:54, Ian Campbell wrote:
> > On Mon, 2015-08-31 at 03:40 -0600, Jan Beulich wrote:
> > > > d) Copy MADT table
> > > > > > > > It needs to change MADT table to restrict the number of
> > > > > > > > vCPUs.
> > > > >
>>> On 02.09.15 at 15:48, wrote:
> On 02/09/15 14:26, Ian Campbell wrote:
> I think the problem is how you reserved this region in the EFI memory
> table. From what I saw, you marked this new memory with EFI_MEMORY_WB
> (which means that the region can be usable by Linux).
>
Y
Hi Ian,
On 2015/9/2 20:54, Ian Campbell wrote:
On Mon, 2015-08-31 at 03:40 -0600, Jan Beulich wrote:
d) Copy MADT table
It needs to change MADT table to restrict the number of vCPUs.
We choose
to copy the first dom0_max_vcpus GICC entries of MADT to new
created
MADT table when numa is not supp
On Wed, Sep 2, 2015 at 3:54 PM, Ian Campbell wrote:
> On Wed, 2015-09-02 at 14:48 +0100, Julien Grall wrote:
>> On 02/09/15 14:26, Ian Campbell wrote:
>> > > > > I think the problem is how you reserved this region in the EFI
>> > > > > memory
>> > > > > table. From what I saw, you marked this new
On 02/09/15 14:26, Ian Campbell wrote:
I think the problem is how you reserved this region in the EFI memory
table. From what I saw, you marked this new memory with EFI_MEMORY_WB
(which means that the region can be usable by Linux).
>>> Yes, I mark it with EFI_MEMORY_WB. Is this
On Wed, 2015-09-02 at 14:48 +0100, Julien Grall wrote:
> On 02/09/15 14:26, Ian Campbell wrote:
> > > > > I think the problem is how you reserved this region in the EFI
> > > > > memory
> > > > > table. From what I saw, you marked this new memory with
> > > > > EFI_MEMORY_WB
> > > > > (which mean
On Wed, 2015-09-02 at 13:52 +0100, Julien Grall wrote:
> On 02/09/15 13:02, Shannon Zhao wrote:
> > > Hold on, this is about Linux able to use the memory for his own
> > > usage.
> > > ACPI table are not part of this memory because they are marked
> > > reserved
> > > by the firmware.
> > >
> >
On Mon, 2015-08-31 at 13:34 +0100, Julien Grall wrote:
>
> No, see my answer above. I'm suggesting to re-use the same trick as we
> do for the grant table region. We know that this region will never be
> allocated in the DOM0 address space either because of the direct mapping
> or because it's
On Mon, 2015-08-31 at 03:40 -0600, Jan Beulich wrote:
> > d) Copy MADT table
> > > > > > It needs to change MADT table to restrict the number of vCPUs.
> > > > > > We choose
> > > > > > to copy the first dom0_max_vcpus GICC entries of MADT to new
> > > > > > created
> > > > > > MADT table when nu
On 02/09/15 13:02, Shannon Zhao wrote:
>> Hold on, this is about Linux able to use the memory for his own usage.
>> ACPI table are not part of this memory because they are marked reserved
>> by the firmware.
>>
>> If we follow your logic, all ACPI tables always should be above the
>> kernel. I don'
>>> On 02.09.15 at 11:25, wrote:
>
> On 2015/9/2 16:41, Jan Beulich wrote:
> Shannon Zhao 09/02/15 8:03 AM >>>
>>> >There are some descriptions in Documentation/arm64/booting.txt of Linux:
>>> >
>>> >"The Image must be placed text_offset bytes from a 2MB aligned base
>>> >address near the s
On Fri, 2015-08-28 at 17:45 +0800, Shannon Zhao wrote:
>
> 1. Create minimal DT to pass required information to Dom0
> --
> The UEFI stub is a feature that extends the Image/zImage into a valid
> UEFI PE/COFF executable, including a loader ap
On Wed, 2015-09-02 at 12:39 +0100, Julien Grall wrote:
> Hi Ian,
>
> On 02/09/15 12:30, Ian Campbell wrote:
> > > Although, when running on Xen, FreeBSD is creating a Xen console by
> > > default with the higher priority. It will be grabbed by FreeBSD as
> > > the
> > > default one.
> >
> > ...
On 2015/9/2 19:09, Julien Grall wrote:
On 02/09/15 07:02, Shannon Zhao wrote:
On 2015/9/1 21:40, Julien Grall wrote:
On 01/09/15 13:35, Shannon Zhao wrote:
On 2015/9/1 19:28, Julien Grall wrote:
Hi Shannon,
On 01/09/15 05:12, Shannon Zhao wrote:
I tried this. Directly use the "kinfo->g
Hi Ian,
On 02/09/15 12:30, Ian Campbell wrote:
>> Although, when running on Xen, FreeBSD is creating a Xen console by
>> default with the higher priority. It will be grabbed by FreeBSD as the
>> default one.
>
> ... Linux should be doing the same. The problem is that the existing code
> to call a
On Tue, 2015-08-18 at 12:00 -0700, Julien Grall wrote:
> Hi,
>
> On 18/08/2015 02:34, Shannon Zhao wrote:
> > IIUC, this is a requirement for Linux. Because when Linux parses the
> > minimal DT, it uses below dt_params to match the DT properties. If it
> > doesn't match any of them, it will fial.
On Wed, 2015-08-12 at 13:20 +0100, Julien Grall wrote:
> On 12/08/15 11:36, Andrew Turner wrote:
> > Would it be possible to add a stdout property and node for the hvc0
> > device? It would help FreeBSD as we use this to find the kernel
> > console. We check for the stdout-path, linux,stdout-path,
On Wed, 2015-08-12 at 13:11 +0100, Julien Grall wrote:
> On 12/08/15 12:23, Ian Campbell wrote:
> > Strictly it is considered a separate thing, much like loader.efi, despite
> > where it lives e.g. it is self contained and not allowed to call into the
> > kernel proper except via the formal interfa
Hi Shannon,
On 02/09/15 10:18, Christoffer Dall wrote:
> On Wed, Sep 02, 2015 at 02:41:36AM -0600, Jan Beulich wrote:
> Shannon Zhao 09/02/15 8:03 AM >>>
>>> There are some descriptions in Documentation/arm64/booting.txt of Linux:
>>>
>>> "The Image must be placed text_offset bytes from a 2MB
On 02/09/15 07:02, Shannon Zhao wrote:
>
>
> On 2015/9/1 21:40, Julien Grall wrote:
>> On 01/09/15 13:35, Shannon Zhao wrote:
>>>
>>>
>>> On 2015/9/1 19:28, Julien Grall wrote:
Hi Shannon,
On 01/09/15 05:12, Shannon Zhao wrote:
> I tried this. Directly use the "kinfo->gnttab_start =
On 2015/9/2 16:41, Jan Beulich wrote:
Shannon Zhao 09/02/15 8:03 AM >>>
>> >There are some descriptions in Documentation/arm64/booting.txt of Linux:
>> >
>> >"The Image must be placed text_offset bytes from a 2MB aligned base
>> >address near the start of usable system RAM and called there.
Hi Jan,
On Wed, Sep 02, 2015 at 02:41:36AM -0600, Jan Beulich wrote:
> >>> Shannon Zhao 09/02/15 8:03 AM >>>
> >There are some descriptions in Documentation/arm64/booting.txt of Linux:
> >
> >"The Image must be placed text_offset bytes from a 2MB aligned base
> >address near the start of usable s
>>> Shannon Zhao 09/02/15 8:03 AM >>>
>There are some descriptions in Documentation/arm64/booting.txt of Linux:
>
>"The Image must be placed text_offset bytes from a 2MB aligned base
>address near the start of usable system RAM and called there. Memory
>below that base address is currently unusabl
On 2015/9/1 21:40, Julien Grall wrote:
> On 01/09/15 13:35, Shannon Zhao wrote:
>>
>>
>> On 2015/9/1 19:28, Julien Grall wrote:
>>> Hi Shannon,
>>> On 01/09/15 05:12, Shannon Zhao wrote:
I tried this. Directly use the "kinfo->gnttab_start = __pa(_stext)" as
the address where these table
On 01/09/15 15:03, Jan Beulich wrote:
On 01.09.15 at 15:40, wrote:
>> On 01/09/15 13:35, Shannon Zhao wrote:
>
> Shannon, Julien,
>
> since the pattern continues and continues without anyone noticing:
> Would you please stop sending at least detail discussions like what
> has been going on
>>> On 01.09.15 at 15:40, wrote:
> On 01/09/15 13:35, Shannon Zhao wrote:
Shannon, Julien,
since the pattern continues and continues without anyone noticing:
Would you please stop sending at least detail discussions like what
has been going on for the last several rounds To everyone, instead
of
On 01/09/15 13:35, Shannon Zhao wrote:
>
>
> On 2015/9/1 19:28, Julien Grall wrote:
>> Hi Shannon,
>> On 01/09/15 05:12, Shannon Zhao wrote:
>>> I tried this. Directly use the "kinfo->gnttab_start = __pa(_stext)" as
>>> the address where these tables are mapped to Dom0. But the value of
>>> gntta
On 2015/9/1 19:28, Julien Grall wrote:
> Hi Shannon,
> On 01/09/15 05:12, Shannon Zhao wrote:
>> I tried this. Directly use the "kinfo->gnttab_start = __pa(_stext)" as
>> the address where these tables are mapped to Dom0. But the value of
>> gnttab_start is lower than the start of RAM, so Dom0 in
Hi Shannon,
On 01/09/15 05:12, Shannon Zhao wrote:
> I tried this. Directly use the "kinfo->gnttab_start = __pa(_stext)" as
> the address where these tables are mapped to Dom0. But the value of
> gnttab_start is lower than the start of RAM, so Dom0 ingore these
> regions and boot failed. see early_
On 2015/8/31 20:34, Julien Grall wrote:
>
>
> On 31/08/2015 13:03, Shannon Zhao wrote:
Currently I use the last RAM bank(kinfo->mem.bank[nr_banks - 1]) to
calculate the start address of non-RAM place. I'm not sure there
will be
no MMIO at that place. Do you have any good ide
On 31/08/2015 13:03, Shannon Zhao wrote:
Currently I use the last RAM bank(kinfo->mem.bank[nr_banks - 1]) to
calculate the start address of non-RAM place. I'm not sure there will be
no MMIO at that place. Do you have any good idea to find such sure and
safe non-ram place?
It's not a safe plac
On 2015/8/31 19:44, Julien Grall wrote:
>
>
> On 29/08/2015 02:00, Shannon Zhao wrote:
>> Hi Julien,
>>
>> On 2015/8/28 20:55, Julien Grall wrote:
>>> Hi Shannon,
>>>
>>> On 28/08/15 10:45, Shannon Zhao wrote:
2. Copy and change some EFI and ACPI tables
---
>>> On 31.08.15 at 13:31, wrote:
> On 2015/8/31 17:40, Jan Beulich wrote:
> On 31.08.15 at 10:51, wrote:
>>> (I wonder why you didn't get this if you have a glance at the booting
>>> process. uefi_init(arch/arm64/kernel/efi.c of Linux) -->
>>> efi_config_parse_tables --> match_config_table. I
On 29/08/2015 02:00, Shannon Zhao wrote:
Hi Julien,
On 2015/8/28 20:55, Julien Grall wrote:
Hi Shannon,
On 28/08/15 10:45, Shannon Zhao wrote:
2. Copy and change some EFI and ACPI tables
---
[..]
All above tables will be mapped to Dom0 non-RAM spa
On 2015/8/31 17:40, Jan Beulich wrote:
On 31.08.15 at 10:51, wrote:
>> On 2015/8/31 15:39, Jan Beulich wrote:
>> On 29.08.15 at 03:29, wrote:
On 2015/8/28 23:06, Jan Beulich wrote:
On 28.08.15 at 11:45, wrote:
>> Create only one ConfigurationTable to store VendorGuid
>>> On 31.08.15 at 10:51, wrote:
> On 2015/8/31 15:39, Jan Beulich wrote:
> On 29.08.15 at 03:29, wrote:
>>> On 2015/8/28 23:06, Jan Beulich wrote:
>>> On 28.08.15 at 11:45, wrote:
> Create only one ConfigurationTable to store VendorGuid and VendorTable.
What do you mean wi
Hi Jan,
On 2015/8/31 15:39, Jan Beulich wrote:
On 29.08.15 at 03:29, wrote:
>> On 2015/8/28 23:06, Jan Beulich wrote:
>> On 28.08.15 at 11:45, wrote:
Create only one ConfigurationTable to store VendorGuid and VendorTable.
>>>
>>> What do you mean with "Create only one ..." - there
>>> On 29.08.15 at 03:29, wrote:
> On 2015/8/28 23:06, Jan Beulich wrote:
> On 28.08.15 at 11:45, wrote:
>>> Create only one ConfigurationTable to store VendorGuid and VendorTable.
>>
>> What do you mean with "Create only one ..." - there is only one.
>> DYM "Create one additional Configurat
>>> On 29.08.15 at 03:00, wrote:
> On 2015/8/28 20:55, Julien Grall wrote:
>> On 28/08/15 10:45, Shannon Zhao wrote:
>>> All above tables will be mapped to Dom0 non-RAM space(e.g. the space
>>> after Dom0 RAM).
>>
>> If I understand correctly what you are saying, you plan to put the
>> tables jus
On 2015/8/28 23:06, Jan Beulich wrote:
On 28.08.15 at 11:45, wrote:
>> 2. Copy and change some EFI and ACPI tables
>> ---
>> a) Create EFI_SYSTEM_TABLE table
>> Copy the header from the origin and change the value of FirmwareVendor.
>
> Careful: The
Hi Julien,
On 2015/8/28 20:55, Julien Grall wrote:
> Hi Shannon,
>
> On 28/08/15 10:45, Shannon Zhao wrote:
>> 2. Copy and change some EFI and ACPI tables
>> ---
>
> [..]
>
>> All above tables will be mapped to Dom0 non-RAM space(e.g. the space
>> after D
>>> On 28.08.15 at 11:45, wrote:
> 2. Copy and change some EFI and ACPI tables
> ---
> a) Create EFI_SYSTEM_TABLE table
> Copy the header from the origin and change the value of FirmwareVendor.
Careful: The version in the header may imply that fields are th
Hi Shannon,
On 28/08/15 10:45, Shannon Zhao wrote:
> 2. Copy and change some EFI and ACPI tables
> ---
[..]
> All above tables will be mapped to Dom0 non-RAM space(e.g. the space
> after Dom0 RAM).
If I understand correctly what you are saying, you plan t
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v4->v5:
* change the description of section 4 to make it more generic
* place EFI and ACPI tables at non-RAM space of Dom0
Changes v3->
On 2015/8/27 22:13, Jan Beulich wrote:
On 27.08.15 at 15:50, wrote:
On 2015/8/27 15:52, Jan Beulich wrote:
One other aspect completely left off so far is that of proper isolation:
What x86 exposes to Dom0 is specifically limited to what Dom0 is
supposed to know. I'm getting the impression th
>>> On 27.08.15 at 15:50, wrote:
> On 2015/8/27 15:52, Jan Beulich wrote:
>> One other aspect completely left off so far is that of proper isolation:
>> What x86 exposes to Dom0 is specifically limited to what Dom0 is
>> supposed to know. I'm getting the impression that by exposing more
>> EFI tab
On 2015/8/27 15:52, Jan Beulich wrote:
On 27.08.15 at 02:37, wrote:
On 20/08/2015 19:25, Shannon Zhao wrote:
On 2015/8/20 22:06, Jan Beulich wrote:
So can the two of you please sort out whether these are Linux
internal tags (which Xen has no business generating, or even
knowing of) or some
>>> On 27.08.15 at 02:37, wrote:
> On 20/08/2015 19:25, Shannon Zhao wrote:
>> On 2015/8/20 22:06, Jan Beulich wrote:
>>> So can the two of you please sort out whether these are Linux
>>> internal tags (which Xen has no business generating, or even
>>> knowing of) or some form of publicly document
Hi,
Sorry for the late answer.
On 20/08/2015 19:25, Shannon Zhao wrote:
On 2015/8/20 22:06, Jan Beulich wrote:
On 20.08.15 at 14:56, wrote:
On 2015/8/20 17:30, Jan Beulich wrote:
On 20.08.15 at 05:41, wrote:
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
1. Crea
>>> On 21.08.15 at 04:25, wrote:
> I'm ok with placing them in the memory not owned by Dom0. Is there some
> ways to find that kind of memory space in Xen?
Who do you need to be able to find such memory? Or maybe I'm not
getting what or why you're asking...
Jan
On 2015/8/20 21:46, Roger Pau Monné wrote:
> El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>>
>>
>> On 2015/8/20 19:28, Roger Pau Monné wrote:
>>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
> El 20/08/15 a les 5.07,
On 2015/8/20 22:06, Jan Beulich wrote:
On 20.08.15 at 14:56, wrote:
>
>>
>> On 2015/8/20 17:30, Jan Beulich wrote:
>> On 20.08.15 at 05:41, wrote:
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
>> 1. Create minimal DT to pass required informatio
>>> On 20.08.15 at 15:46, wrote:
> El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>>
>>
>> On 2015/8/20 19:28, Roger Pau Monné wrote:
>>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
> El 20/08/15 a les 5.07, Shannon Z
>>> On 20.08.15 at 14:56, wrote:
>
> On 2015/8/20 17:30, Jan Beulich wrote:
> On 20.08.15 at 05:41, wrote:
>>> On 2015/8/19 22:05, Jan Beulich wrote:
>>> On 19.08.15 at 14:13, wrote:
> 1. Create minimal DT to pass required information to Dom0
> -
El 20/08/15 a les 14.29, Shannon Zhao ha escrit:
>
>
> On 2015/8/20 19:28, Roger Pau Monné wrote:
>> El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
>>> Hi Roger,
>>>
>>> On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
> On 2015/8/19 23:02, Rog
On 2015/8/20 17:30, Jan Beulich wrote:
On 20.08.15 at 05:41, wrote:
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
1. Create minimal DT to pass required information to Dom0
--
Since there are no legacy interfaces
On 2015/8/20 19:28, Roger Pau Monné wrote:
El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
XENM
>>> On 20.08.15 at 13:28, wrote:
> If you want you can check in the hypercall handler that idxs[i] ==
> gpfns[i], and return -EOPNOTSUPP if they don't match, but I still don't
> see why this should be restricted to 1:1 mappings.
+1
Jan
___
Xen-devel
El 20/08/15 a les 13.22, Shannon Zhao ha escrit:
> Hi Roger,
>
> On 2015/8/20 16:20, Roger Pau Monné wrote:
>> El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
>>> On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
> XENMAPSPACE "XENMAPSPACE_dev_mmi
Hi Roger,
On 2015/8/20 16:20, Roger Pau Monné wrote:
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
On 2015/8/19 23:02, Roger Pau Monné wrote:
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
XENMAPSPACE "XENMAPSPACE_dev_mmio". The usage of this hypercall
parameters:
- domid: DOMID_SELF.
- s
>>> On 20.08.15 at 05:41, wrote:
> On 2015/8/19 22:05, Jan Beulich wrote:
> On 19.08.15 at 14:13, wrote:
>>> 1. Create minimal DT to pass required information to Dom0
>>> --
>>> Since there are no legacy interfaces like x86 for Dom0 to g
>>> On 19.08.15 at 20:37, wrote:
> On 19/08/2015 07:05, Jan Beulich wrote:
>> ... wouldn't it make more sense to leave the generation of these
>> Linux-specific tags to Linux (and allow them to continue to be Linux
>> specific), by the same or a second, parallel (Xen) stub? This would
>> then also
El 20/08/15 a les 5.07, Shannon Zhao ha escrit:
> On 2015/8/19 23:02, Roger Pau Monné wrote:
>> El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
>>> XENMAPSPACE "XENMAPSPACE_dev_mmio". The usage of this hypercall
>>> parameters:
>>> - domid: DOMID_SELF.
>>> - space: XENMAPSPACE_dev_mmio.
>>> - gpfn
On 19/08/2015 20:07, Shannon Zhao wrote:
and I
don't think the domid field needs an explanation TBH.
Within the register, check if the device is newly added, then call
hypercall XENMEM_add_to_physmap to map the mmio regions.
For PCI bus device, it could reuse the existing PCI bus_notifier l
Hi Jan,
On 2015/8/19 22:05, Jan Beulich wrote:
On 19.08.15 at 14:13, wrote:
>> 1. Create minimal DT to pass required information to Dom0
>> --
>> Since there are no legacy interfaces like x86 for Dom0 to get the
>> booting required info
Hi Roger,
On 2015/8/19 23:02, Roger Pau Monné wrote:
> El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
>> 4. Map MMIO regions
>> ---
>> Register a bus_notifier for platform and amba bus in Linux. Add a new
>
> Can we make this OS agnostic? Could you explain what you mean with the
Hi Jan,
On 19/08/2015 07:05, Jan Beulich wrote:
... wouldn't it make more sense to leave the generation of these
Linux-specific tags to Linux (and allow them to continue to be Linux
specific), by the same or a second, parallel (Xen) stub? This would
then also move at least some of the awkward ta
El 19/08/15 a les 14.13, Shannon Zhao ha escrit:
> 4. Map MMIO regions
> ---
> Register a bus_notifier for platform and amba bus in Linux. Add a new
Can we make this OS agnostic? Could you explain what you mean with the
above sentence without using Linux kernel internals?
> XENMAP
>>> On 19.08.15 at 14:13, wrote:
> 1. Create minimal DT to pass required information to Dom0
> --
> Since there are no legacy interfaces like x86 for Dom0 to get the
> booting required information on ARM, here we use the minimal DT which is
>
This document is going to explain the design details of Xen booting with
ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
welcome.
Changes v3->v4:
* add explanation for minimal DT and the properties
* drop "linux," prefix of the properties
* add explanation for the event cha
On 18/08/2015 00:01, Jan Beulich wrote:
On 18.08.15 at 08:43, wrote:
Hi Jan,
On 17/08/2015 22:10, Jan Beulich wrote:
Julien Grall 08/17/15 6:27 PM >>>
On 17/08/2015 08:33, Jan Beulich wrote:
On 14.08.15 at 16:59, wrote:
b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start
Hi,
On 18/08/2015 02:34, Shannon Zhao wrote:
IIUC, this is a requirement for Linux. Because when Linux parses the
minimal DT, it uses below dt_params to match the DT properties. If it
doesn't match any of them, it will fial.
See efi_get_fdt_params in drivers/firmware/efi/efi.c.
This is *not* a
On 18/08/2015 00:23, Shannon Zhao wrote:
On 2015/8/18 14:36, Julien Grall wrote:
On 17/08/2015 20:19, Shannon Zhao wrote:
Yes, I think it's good to drop the "linux," too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen
On 2015/8/18 17:11, Jan Beulich wrote:
On 18.08.15 at 10:21, wrote:
>
>>
>> On 2015/8/18 16:15, Jan Beulich wrote:
>> On 18.08.15 at 09:35, wrote:
Hi Jan,
On 2015/8/18 13:14, Jan Beulich wrote:
Shannon Zhao 08/18/15 5:46 AM >>>
>> On 2015/8/17 23:33, Jan B
>>> On 18.08.15 at 10:21, wrote:
>
> On 2015/8/18 16:15, Jan Beulich wrote:
> On 18.08.15 at 09:35, wrote:
>>> Hi Jan,
>>>
>>> On 2015/8/18 13:14, Jan Beulich wrote:
>>> Shannon Zhao 08/18/15 5:46 AM >>>
> On 2015/8/17 23:33, Jan Beulich wrote:
> On 14.08.15 at 16:59, wrot
On 2015/8/18 16:15, Jan Beulich wrote:
On 18.08.15 at 09:35, wrote:
>> Hi Jan,
>>
>> On 2015/8/18 13:14, Jan Beulich wrote:
>> Shannon Zhao 08/18/15 5:46 AM >>>
On 2015/8/17 23:33, Jan Beulich wrote:
On 14.08.15 at 16:59, wrote:
>> 1. Copy and change some EFI and ACP
On 2015/8/18 15:01, Jan Beulich wrote:
On 18.08.15 at 08:43, wrote:
>> > Hi Jan,
>> >
>> > On 17/08/2015 22:10, Jan Beulich wrote:
>> > Julien Grall 08/17/15 6:27 PM >>>
>>> On 17/08/2015 08:33, Jan Beulich wrote:
>>> On 14.08.15 at 16:59, wrote:
>> > b)
>>> On 18.08.15 at 09:35, wrote:
> Hi Jan,
>
> On 2015/8/18 13:14, Jan Beulich wrote:
> Shannon Zhao 08/18/15 5:46 AM >>>
>>> On 2015/8/17 23:33, Jan Beulich wrote:
>>> On 14.08.15 at 16:59, wrote:
> 1. Copy and change some EFI and ACPI tables
> -
Hi Jan,
On 2015/8/18 13:14, Jan Beulich wrote:
Shannon Zhao 08/18/15 5:46 AM >>>
>> On 2015/8/17 23:33, Jan Beulich wrote:
>> On 14.08.15 at 16:59, wrote:
1. Copy and change some EFI and ACPI tables
---
>>>
>>> While some explanation on
On 2015/8/18 14:36, Julien Grall wrote:
>
>
> On 17/08/2015 20:19, Shannon Zhao wrote:
Yes, I think it's good to drop the "linux," too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen still uses "linux,"?
>>>
>
>>> On 18.08.15 at 08:43, wrote:
> Hi Jan,
>
> On 17/08/2015 22:10, Jan Beulich wrote:
> Julien Grall 08/17/15 6:27 PM >>>
>>> On 17/08/2015 08:33, Jan Beulich wrote:
>>> On 14.08.15 at 16:59, wrote:
> b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
> size
Hi Jan,
On 17/08/2015 22:10, Jan Beulich wrote:
Julien Grall 08/17/15 6:27 PM >>>
On 17/08/2015 08:33, Jan Beulich wrote:
On 14.08.15 at 16:59, wrote:
b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
size information of Dom0. And Dom0 will get the memory information
thr
On 17/08/2015 20:19, Shannon Zhao wrote:
Yes, I think it's good to drop the "linux," too. But if we drop the
linux, would it impact the linux kernel booting with UEFI? And why we
don't do it to Xen since Xen still uses "linux,"?
I don't understand your second question.
I mean that Xen is us
>>> Shannon Zhao 08/18/15 5:46 AM >>>
>On 2015/8/17 23:33, Jan Beulich wrote:
> On 14.08.15 at 16:59, wrote:
>>> 1. Copy and change some EFI and ACPI tables
>>> ---
>>
>> While some explanation on the reasons for this was given in the past
>> discussio
>>> Julien Grall 08/17/15 6:27 PM >>>
>On 17/08/2015 08:33, Jan Beulich wrote:
> On 14.08.15 at 16:59, wrote:
>>> b) Create EFI_MEMORY_DESCRIPTOR table. This will add memory start and
>>> size information of Dom0. And Dom0 will get the memory information
>>> through this EFI table.
>>
>> To s
Hi Jan,
On 2015/8/17 23:33, Jan Beulich wrote:
On 14.08.15 at 16:59, wrote:
>> 1. Copy and change some EFI and ACPI tables
>> ---
>
> While some explanation on the reasons for this was given in the past
> discussion, I'm still missing a word on the "w
Hi Julien,
On 2015/8/18 0:10, Julien Grall wrote:
> Hi,
>
> On 17/08/2015 06:01, Shannon Zhao wrote:
>>
>>
>> On 2015/8/14 23:17, Julien Grall wrote:
>>> On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
On 2015/8/17 18:36, Roger Pau Monné wrote:
> El 11/08/15 a les 16.19, Ian Campbell ha escrit:
>> On Fri, 2015-08-07 at 10:11 +0800, Shannon Zhao wrote:
>>> This document is going to explain the design details of Xen booting with
>>> ACPI on ARM. Maybe parts of it may not be appropriate. Any comme
On 17/08/2015 08:33, Jan Beulich wrote:
On 14.08.15 at 16:59, wrote:
1. Copy and change some EFI and ACPI tables
---
While some explanation on the reasons for this was given in the past
discussion, I'm still missing a word on the "why" for each of the
Hi,
On 17/08/2015 06:01, Shannon Zhao wrote:
On 2015/8/14 23:17, Julien Grall wrote:
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address
>>> On 14.08.15 at 16:59, wrote:
> 1. Copy and change some EFI and ACPI tables
> ---
While some explanation on the reasons for this was given in the past
discussion, I'm still missing a word on the "why" for each of these here.
> a) Copy EFI_SYSTEM_TABLE a
On 2015/8/14 23:17, Julien Grall wrote:
On 14/08/15 15:59, Shannon Zhao wrote:
2. Create minimal DT to pass required information to Dom0
--
The minimal DT mainly passes Dom0 bootargs, address and size of initrd
(if available), address and
El 11/08/15 a les 16.19, Ian Campbell ha escrit:
> On Fri, 2015-08-07 at 10:11 +0800, Shannon Zhao wrote:
>> This document is going to explain the design details of Xen booting with
>> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
>> welcome.
>
> Some small subsets of thi
On Fri, Aug 14, 2015 at 10:59:19PM +0800, Shannon Zhao wrote:
> This document is going to explain the design details of Xen booting with
> ACPI on ARM. Maybe parts of it may not be appropriate. Any comments are
> welcome.
>
> Changes v2->v3:
> * remove the two HVM_PARAMs for grant table and let li
1 - 100 of 192 matches
Mail list logo
