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 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 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->
43 matches
Mail list logo
