|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 07/10] xen/arm: intruduce alloc_domstatic_pages
On 21.05.2021 08:41, Penny Zheng wrote:
> Hi Jan
>
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: Tuesday, May 18, 2021 7:23 PM
>> To: Penny Zheng <Penny.Zheng@xxxxxxx>
>> Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>; Wei Chen
>> <Wei.Chen@xxxxxxx>; nd <nd@xxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx;
>> sstabellini@xxxxxxxxxx; julien@xxxxxxx
>> Subject: Re: [PATCH 07/10] xen/arm: intruduce alloc_domstatic_pages
>>
>> On 18.05.2021 10:57, Penny Zheng wrote:
>>>> From: Jan Beulich <jbeulich@xxxxxxxx>
>>>> Sent: Tuesday, May 18, 2021 3:35 PM
>>>>
>>>> On 18.05.2021 07:21, Penny Zheng wrote:
>>>>> --- a/xen/common/page_alloc.c
>>>>> +++ b/xen/common/page_alloc.c
>>>>> @@ -2447,6 +2447,9 @@ int assign_pages(
>>>>> {
>>>>> ASSERT(page_get_owner(&pg[i]) == NULL);
>>>>> page_set_owner(&pg[i], d);
>>>>> + /* use page_set_reserved_owner to set its reserved domain owner.
>>>> */
>>>>> + if ( (pg[i].count_info & PGC_reserved) )
>>>>> + page_set_reserved_owner(&pg[i], d);
>>>>
>>>> Now this is puzzling: What's the point of setting two owner fields to
>>>> the same value? I also don't recall you having introduced
>>>> page_set_reserved_owner() for x86, so how is this going to build there?
>>>>
>>>
>>> Thanks for pointing out that it will fail on x86.
>>> As for the same value, sure, I shall change it to domid_t domid to record
>>> its
>> reserved owner.
>>> Only domid is enough for differentiate.
>>> And even when domain get rebooted, struct domain may be destroyed, but
>>> domid will stays The same.
>>
>> Will it? Are you intending to put in place restrictions that make it
>> impossible
>> for the ID to get re-used by another domain?
>>
>>> Major user cases for domain on static allocation are referring to the
>>> whole system are static, No runtime creation.
>>
>> Right, but that's not currently enforced afaics. If you would enforce it, it
>> may
>> simplify a number of things.
>>
>>>>> @@ -2509,6 +2512,56 @@ struct page_info *alloc_domheap_pages(
>>>>> return pg;
>>>>> }
>>>>>
>>>>> +/*
>>>>> + * Allocate nr_pfns contiguous pages, starting at #start, of static
>>>>> +memory,
>>>>> + * then assign them to one specific domain #d.
>>>>> + * It is the equivalent of alloc_domheap_pages for static memory.
>>>>> + */
>>>>> +struct page_info *alloc_domstatic_pages(
>>>>> + struct domain *d, unsigned long nr_pfns, paddr_t start,
>>>>> + unsigned int memflags)
>>>>> +{
>>>>> + struct page_info *pg = NULL;
>>>>> + unsigned long dma_size;
>>>>> +
>>>>> + ASSERT(!in_irq());
>>>>> +
>>>>> + if ( memflags & MEMF_no_owner )
>>>>> + memflags |= MEMF_no_refcount;
>>>>> +
>>>>> + if ( !dma_bitsize )
>>>>> + memflags &= ~MEMF_no_dma;
>>>>> + else
>>>>> + {
>>>>> + dma_size = 1ul << bits_to_zone(dma_bitsize);
>>>>> + /* Starting address shall meet the DMA limitation. */
>>>>> + if ( dma_size && start < dma_size )
>>>>> + return NULL;
>>>>
>>>> It is the entire range (i.e. in particular the last byte) which needs
>>>> to meet such a restriction. I'm not convinced though that DMA width
>>>> restrictions and static allocation are sensible to coexist.
>>>>
>>>
>>> FWIT, if starting address meets the limitation, the last byte, greater
>>> than starting address shall meet it too.
>>
>> I'm afraid I don't know what you're meaning to tell me here.
>>
>
> Referring to alloc_domheap_pages, if `dma_bitsize` is none-zero value,
> it will use alloc_heap_pages to allocate pages from [dma_zone + 1,
> zone_hi], `dma_zone + 1` pointing to address larger than 2^(dma_zone + 1).
> So I was setting address limitation for the starting address.
But does this zone concept apply to static pages at all?
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |