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

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

  • To: Penny Zheng <penny.zheng@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 9 Sep 2021 11:06:23 +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=luE6vr4B2Em6B7HB3xH6vsWXRYWQjWo9rnvd6ZwmLXM=; b=VPFp1S46PMqMCWiwjgs6WIEwi+bQxgHg3mJTosBu+4xdbc3uFHoxBkVqUm92NY1A4B1akXMxPLBhiqLOv03CBdUXJ6ZyWRJ5tMjbvFQR8Otj5ZP42WaFxCZZVBavDwY69diqjO5R//DlOODTGq1svx43WFSAk93DwbteOpJCAMn4ax7Ga5SyRk5R5SABlliFJ4wbsbxdyN/KLaS0/fPAqBH8oP/bwIfzfkD3PmYedkNgn7rf93g9Id+ZOnMsNBey2TyTE7J46NlLo0gpddOcuJvnn6McEdu8uQ3EoW4YWckKsyw9HoEXA7ze+bZJHIpjgqXiLuJqhu9VP/GeZWEgFw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T+/SGkWEdRYrSUOOilA2ADlXJ3RdabHx4b3S2gRAa9NnoQvkHZlHn8QynjsVE773UNW1HacaOFtlvJnwbJCsdTAz6rOg8a7nGAVQERsS+WxoHoA9QVnFSMkkBAGc2+zmwGwQQp4+edw7ujD9nLNeQVST0yxOybdMLZvzAiMH80/DvigDiviBME/Zf9s5kEzQscmaEB6K1jcvz5UGLaKpO6Ngy3ga76xycNZyDrWcKqUhGvzEWP31W1bR/qeWonaZUYGrjw2gVquEdCf3pgPF0AnIv/IjelJ20lPmZ8uGGfmYGClApgpnelt7x369fqkxjhbUuqtmfbRyhLqBNqDh5A==
  • Authentication-results: xen.org; dkim=none (message not signed) header.d=none;xen.org; dmarc=none action=none header.from=suse.com;
  • Cc: Bertrand.Marquis@xxxxxxx, Wei.Chen@xxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, sstabellini@xxxxxxxxxx, julien@xxxxxxx
  • Delivery-date: Thu, 09 Sep 2021 09:06:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 08.09.2021 11: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
> introduces a new helper assign_page for original page with a single order.
> Signed-off-by: Penny Zheng <penny.zheng@xxxxxxx>

I have to admit that I'm now very puzzled: Instead of restoring the
long agreed upon ordering of parameters (and then keeping my A-b),
you've dropped the ack.

> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -568,7 +568,7 @@ int __init dom0_construct_pv(struct domain *d,
>          else
>          {
>              while ( count-- )
> -                if ( assign_pages(d, mfn_to_page(_mfn(mfn++)), 0, 0) )
> +                if ( assign_pages(d, mfn_to_page(_mfn(mfn++)), 1, 0) )

This change alone demonstrates the problem when it comes to backporting
future changes: If the original patch contained a code addition similar
to what you change to, without the person doing the backporting paying
close attention, the result will be an order-1 request when an order-0
one is wanted. It was explained to you that in order to make people
doing backports aware of this semantic change, the order of parameters
of the function ought to be altered. That way the compiler will
complain, and the person will know to look closely what adjustments are

In this context I find it further puzzling ...

> --- a/xen/include/xen/mm.h
> +++ b/xen/include/xen/mm.h
> @@ -133,8 +133,14 @@ void heap_init_late(void);
>  int assign_pages(
>      struct domain *d,
> +    struct page_info *pg,
> +    unsigned long nr,
> +    unsigned int memflags);
> +
> +int assign_page(
>      struct page_info *pg,
>      unsigned int order,
> +    struct domain *d,
>      unsigned int memflags);

... that you also neglected the request to harmonize the argument order
of both functions. What we want (and what I thought has long been agreed
upon) is e.g.

int assign_pages(
    struct page_info *pg,
    unsigned long nr,
    struct domain *d,
    unsigned int memflags);

int assign_page(
    struct page_info *pg,
    unsigned int order,
    struct domain *d,
    unsigned int memflags);




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