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

Re: [PATCH v7 5/7] xen: re-define assign_pages and introduce a new function assign_page

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 15 Sep 2021 10:04:45 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r132eiCb14LF3oKvpumOcwCR1jNghL/zwsEyh0UIrSY=; b=Vx5EZs817tlPtQPk6h1iejvDcSvCzI0UPrdKoOUXXPwrhrbVbs+lJcqcYSNJy5sa/rAH3LjHRo/VOCgONvoVub8Yf3ClWRnZVnC0PaHJUhjSteZVemvMIZ5T4UXDO+fQrfoA/rIDZi1P8kPkclxPRqARhycE6BGXLn3uJhUQ7YXneyRnGcj+nr9xuu6lLqsV9bnGRpgJ4ZF+A8yk2Z/AFvu3iYSMB7HPgCTcGf5lLoWBHlvOhUBbP0raMoeTBg/mt7Y2r2mlijOldKzu5pzYRPptNlv5q0xGSPZQAHzLFrSNItfy9o/uiHo2HmkJ2rUf2en9GBGIrstWxn8l2S8mZw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YMjeqgtxZOzecfOl9XVohA844BHun1geGRBwe4PoCp11H1PpoYWP0swF8TS52ACHsyTEJDoS2VLIZUrEmUfDtwZ45RCWJU/ERwW9uVmvbCqqw3iQj3jKYJifJM3zfzhJ42Lsg1wVjQOmHQZDLx3CQjpH58pxM+/XoGynIWwKhnOwBJbo+D280E2mzR82FGnBnlVeyW9wHM79d2VazMHvI/TAcuA3V7Z9wjGY0aOG31rBam4WXHvKcEwtup2jwMz1MFzS+HUxnl3u6LYaFPyDMVE6agmLC4nCZe2FIHYyUAH+M+VovnBTnk8rMG4VnmSry/yTunuxYWZ5i2CIFfo7Fw==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: Penny Zheng <penny.zheng@xxxxxxx>, Bertrand.Marquis@xxxxxxx, Wei.Chen@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, julien@xxxxxxx
  • Delivery-date: Wed, 15 Sep 2021 08:04:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.09.2021 18:23, Stefano Stabellini wrote:
> On Fri, 10 Sep 2021, Jan Beulich wrote:
>> On 10.09.2021 04:52, Penny Zheng wrote:
>>> In order to deal with the trouble of count-to-order conversion when page 
>>> number
>>> is not in a power-of-two, this commit re-define assign_pages for nr pages 
>>> and
>>> assign_page for original page with a single order.
>>> Backporting confusion could be helped by altering the order of assign_pages
>>> parameters, such that the compiler would point out that adjustments at call
>>> sites are needed.
>> Thanks, this now takes care of my primary concern. However, I (now?) have
>> another (I thought I would have mentioned this before):
>>> --- a/xen/common/page_alloc.c
>>> +++ b/xen/common/page_alloc.c
>>> @@ -2259,9 +2259,9 @@ void init_domheap_pages(paddr_t ps, paddr_t pe)
>>>  int assign_pages(
>>> -    struct domain *d,
>>>      struct page_info *pg,
>>> -    unsigned int order,
>>> +    unsigned long nr,
>> If this really is to be "unsigned long" (and not "unsigned int"), then...
> Thanks for spotting this. I think it makes sense to use "unsigned int
> nr" here.

I see you've made the change while committing, but the subsequent patch
then would have needed adjustment as well: It's now silently truncating
an "unsigned long" value to "unsigned int". It was the splitting that's
now needed there _anyway_ that made me wonder whether the patch here
really is worthwhile to have. But of course acquire_domstatic_pages()
could for now also simply reject too large values ...




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