[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC 7/9] xen: arm: handle variable p2m levels in apply_p2m_changes



On Mon, Aug 11, 2014 at 12:30 PM, Vijay Kilari <vijay.kilari@xxxxxxxxx> wrote:
> On Wed, Jul 30, 2014 at 7:17 PM, Ian Campbell <ian.campbell@xxxxxxxxxx> wrote:
>> As with prervious changes this involves conversion from a linear series of
>> lookups into a loop over the levels.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
>> ---
>>  xen/arch/arm/p2m.c |  178 
>> +++++++++++++++++++++++++---------------------------
>>  1 file changed, 84 insertions(+), 94 deletions(-)
>>
>> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
>> index 557663f..e9938ae 100644
>> --- a/xen/arch/arm/p2m.c
>> +++ b/xen/arch/arm/p2m.c
>> @@ -15,7 +15,6 @@
>>
>>  /* First level P2M is 2 consecutive pages */
>>  #define P2M_ROOT_ORDER 1
>> -#define P2M_ROOT_ENTRIES (LPAE_ENTRIES<<P2M_ROOT_ORDER)
>>  #define P2M_ROOT_PAGES    (1<<P2M_ROOT_ORDER)
>>
>>  static bool_t p2m_valid(lpae_t pte)
>> @@ -115,31 +114,6 @@ void flush_tlb_domain(struct domain *d)
>>          p2m_load_VTTBR(current->domain);
>>  }
>>
>> -static int p2m_first_level_index(paddr_t addr)
>> -{
>> -    /*
>> -     * 1st pages are concatenated so zeroeth offset gives us the
>> -     * index of the 1st page
>> -     */
>> -    return zeroeth_table_offset(addr);
>> -}
>> -
>> -/*
>> - * Map whichever of the first pages contain addr. The caller should
>> - * then use first_table_offset as an index.
>> - */
>> -static lpae_t *p2m_map_first(struct p2m_domain *p2m, paddr_t addr)
>> -{
>> -    struct page_info *page;
>> -
>> -    if ( first_linear_offset(addr) >= P2M_ROOT_ENTRIES )
>> -        return NULL;
>> -
>> -    page = p2m->root + p2m_first_level_index(addr);
>> -
>> -    return __map_domain_page(page);
>> -}
>> -
>>  /*
>>   * Lookup the MFN corresponding to a domain's PFN.
>>   *
>> @@ -707,14 +681,13 @@ static int apply_p2m_changes(struct domain *d,
>>                       int mattr,
>>                       p2m_type_t t)
>>  {
>> -    int rc, ret;
>> +    int level, rc, ret;
>>      struct p2m_domain *p2m = &d->arch.p2m;
>> -    lpae_t *first = NULL, *second = NULL, *third = NULL;
>> +    lpae_t *mappings[4] = { NULL, };
>>      paddr_t addr;
>> -    unsigned long cur_first_page = ~0,
>> -                  cur_first_offset = ~0,
>> -                  cur_second_offset = ~0;
>> -    unsigned long count = 0;
>> +    unsigned int cur_root_table = ~0;
>> +    unsigned int cur_offset[4] = { ~0, };
>> +    unsigned int count = 0;
>>      bool_t flush = false;
>>      bool_t flush_pt;
>>
>> @@ -726,9 +699,27 @@ static int apply_p2m_changes(struct domain *d,
>>
>>      spin_lock(&p2m->lock);
>>
>> +    if ( P2M_ROOT_PAGES == 1 )
>> +    {
>> +        /* Static mapping. P2M_ROOT_PAGES > 1 are handled below */
>> +        mappings[P2M_ROOT_LEVEL] = __map_domain_page(p2m->root);
>> +        {
>> +            rc = -EINVAL;

Commenting below lines of code, where forcibly jumping to out if
P2M_ROOT_PAGES==1
I could boot my system with 48-bit PA

        mappings[P2M_ROOT_LEVEL] = __map_domain_page(p2m->root);
        /*{
            printk("In %s line %d\n",__func__, __LINE__);
            rc = -EINVAL;
            goto out;
        }*/

>
>          In case of 48-bit platform in  pa_range_info[] structure in
> setup_virt_paging()
> function, the root-order is set to 0. So for 48-bit platform P2M_ROOT_PAGES = 
> 1
> and hence Dom0 mapping always fails with below log
>
> (XEN) P2M: 48-bit IPA with 48-bit PA
> (XEN) P2M: 4 levels with order-0 root, VTCR 0x80053590
> (XEN) *** LOADING DOMAIN 0 ***
> (XEN) Loading kernel from boot module @ 0000000080080000
> (XEN) Allocating 1:1 mappings totalling 128MB for dom0:
> (XEN) Allocated 0x000000f0000000-0x000000f8000000 (128MB/128MB, order 15)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Failed map pages to DOM0: -22
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> Regards
> Vijay

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.