[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 |