From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C5701C31E5B for ; Tue, 18 Jun 2019 22:21:40 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8D4C02082C for ; Tue, 18 Jun 2019 22:21:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FkffmOtD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D4C02082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hdMTY-0008SB-ED; Tue, 18 Jun 2019 22:21:12 +0000 Received: from us1-rack-dfw2.inumbo.com ([104.130.134.6]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hdMTX-0008S6-78 for xen-devel@lists.xenproject.org; Tue, 18 Jun 2019 22:21:11 +0000 X-Inumbo-ID: 5f840bea-9217-11e9-8980-bc764e045a96 Received: from mail-ua1-x943.google.com (unknown [2607:f8b0:4864:20::943]) by us1-rack-dfw2.inumbo.com (Halon) with ESMTPS id 5f840bea-9217-11e9-8980-bc764e045a96; Tue, 18 Jun 2019 22:21:09 +0000 (UTC) Received: by mail-ua1-x943.google.com with SMTP id f20so7724260ual.0 for ; Tue, 18 Jun 2019 15:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Y+G/dg/rxNAs3OZvpOBmjhH1X4jyL0Q5yVyoy+9BFo=; b=FkffmOtDAKyBZgD3qhj5lh463P1Q1u8vP1FjR/xD4iOb925dSoS8uAiL7nW83zgRNc haiS+tq1ud3K/mpdJV0w5mG8EdWD2wybSLQSD4wzmiy4UV/qxL1zqS1PBRygqTJGR3mD y8ldOYTAyqGTmpeXd75QQSbBGGpf5DiZU/2Id6O/DjRO1wo31ZDBdz/Uz0BPoUv93YSy Em1slB8FDnr4frPWBDBg96MvvhUjcAx4aGCfusSGfDHGSuPSXkTSaER2ilJOOs54XNTI kLHnuSCQcw0FuPg6R2+h+58cDppiIK0ygIAI++QOnHwwmv116r78qBrof5d+8oQvTq/s 3uPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Y+G/dg/rxNAs3OZvpOBmjhH1X4jyL0Q5yVyoy+9BFo=; b=Fpq8PN9fbI05VicDSc7ERI5r6lI08DVJ0jZvCdn/bIcSqLjI7JJ1jqHhes95FJvjRO w2/4uZGGADR0RdYdFylpZ7qetkXXOZmJWj8u8h8B0YOUnXCfpJGTPje2UWV0hehjCsD0 2/eYMvntMGc83kh+57SsLBv4dwTP4FjAhtcdwg9zHlurs+sRTDU1CRWyRMaigmov9yQ1 ElOK/wjiwRxL2kr/iyF+j32jAUA0zwyghcYJiPq9mRUxFX1ugzg2+zyYFBVSHYjJ0C3w S4khXPJKSQ+zgpr0eVrbo+CA/WtNBAtk55nlwBv51mupLJcPFJiQ4+4I8Fum/MZfFuf5 904w== X-Gm-Message-State: APjAAAWZnSKDvutk6VdI/tchYN6kO0WWaa+3npr9Epvhg5wOveSowGXa Mf3JmDq6XXe6r/7k6Gj6cuZP65ZI9GBL+DzVrXY= X-Google-Smtp-Source: APXvYqxJg0nr40R9AN8RUqm0wgOr2cVoWdwQytrBAkBaKyscWae7ntzh/riZ+yujl7gxypfcZSS3pOX3/r6buibBLrE= X-Received: by 2002:a67:1e01:: with SMTP id e1mr55875817vse.13.1560896469112; Tue, 18 Jun 2019 15:21:09 -0700 (PDT) MIME-Version: 1.0 References: <1556658172-8824-5-git-send-email-sstabellini@kernel.org> In-Reply-To: From: Julien Grall Date: Tue, 18 Jun 2019 23:20:56 +0100 Message-ID: To: Stefano Stabellini Subject: Re: [Xen-devel] [PATCH v2 05/10] libxl/xl: add memory policy option to iomem X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: xen-devel , Julien Grall , ian.jackson@eu.citrix.com, wei.liu2@citrix.com, Stefano Stabellini Content-Type: multipart/mixed; boundary="===============1880288912437783584==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============1880288912437783584== Content-Type: multipart/alternative; boundary="000000000000929bc8058ba087cb" --000000000000929bc8058ba087cb Content-Type: text/plain; charset="UTF-8" Sorry for the formatting. On Tue, 18 Jun 2019, 23:09 Stefano Stabellini, wrote: > On Tue, 18 Jun 2019, Julien Grall wrote: > > On 30/04/2019 22:02, Stefano Stabellini wrote: > > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > > > index 89fe80f..a6c5e30 100644 > > > --- a/tools/libxl/libxl_create.c > > > +++ b/tools/libxl/libxl_create.c > > > @@ -415,6 +415,21 @@ static void init_console_info(libxl__gc *gc, > > > Only 'channels' when mapped to consoles have a string name. */ > > > } > > > +static uint32_t libxl__memory_policy_to_xc(libxl_memory_policy c) > > > +{ > > > + switch (c) { > > > + case LIBXL_MEMORY_POLICY_ARM_MEM_WB: > > > + return MEMORY_POLICY_ARM_MEM_WB; > > > + case LIBXL_MEMORY_POLICY_ARM_DEV_NGRE: > > > + return MEMORY_POLICY_ARM_DEV_nGRE; > > > + case LIBXL_MEMORY_POLICY_X86_UC: > > > + return MEMORY_POLICY_X86_UC; > > > + case LIBXL_MEMORY_POLICY_DEFAULT: > > > + default: > > > > Looking at this again, don't we want to bail out if the policy is > unknown? My > > concern here is the user may configure with something it didn't expect. > The > > risk is the problem will be hard to debug. > > > > I also believe this could be part of libxl_{arm,x86}.c allowing us to > filter > > misuse early. > > This sounds like a good idea, I can do that. Then, I can also #ifdef the > hypercalls defines, although for some reason today libxl doesn't have > CONFIG_X86 or CONFIG_ARM set so I would also have to do the following in > the libxl Makefile: > > ifeq ($(CONFIG_X86),y) > CFLAGS_LIBXL += -DCONFIG_X86 > else > CFLAGS_LIBXL += -DCONFIG_ARM > endif > Or just follow what we do today in other public headers: #if defined(__arm__) || defined(__aarch64__) You need to double check the exact syntax as I wrote it by memory. Cheers, > > > Ian, Wei, any opinion? > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xenproject.org > https://lists.xenproject.org/mailman/listinfo/xen-devel --000000000000929bc8058ba087cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry for the formatting.

On Tue, 18 Jun 2019, 23:09 St= efano Stabellini, <sstabellini= @kernel.org> wrote:
On Tue, = 18 Jun 2019, Julien Grall wrote:
> On 30/04/2019 22:02, Stefano Stabellini wrote:
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_creat= e.c
> > index 89fe80f..a6c5e30 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -415,6 +415,21 @@ static void init_console_info(libxl__gc *gc,=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Only 'channels' when ma= pped to consoles have a string name. */
> >=C2=A0 =C2=A0}
> >=C2=A0 =C2=A0+static uint32_t libxl__memory_policy_to_xc(libxl_mem= ory_policy c)
> > +{
> > +=C2=A0 =C2=A0 switch (c) {
> > +=C2=A0 =C2=A0 case LIBXL_MEMORY_POLICY_ARM_MEM_WB:
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return MEMORY_POLICY_ARM_MEM_WB;
> > +=C2=A0 =C2=A0 case LIBXL_MEMORY_POLICY_ARM_DEV_NGRE:
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return MEMORY_POLICY_ARM_DEV_nGRE; > > +=C2=A0 =C2=A0 case LIBXL_MEMORY_POLICY_X86_UC:
> > +=C2=A0 =C2=A0 =C2=A0 =C2=A0 return MEMORY_POLICY_X86_UC;
> > +=C2=A0 =C2=A0 case LIBXL_MEMORY_POLICY_DEFAULT:
> > +=C2=A0 =C2=A0 default:
>
> Looking at this again, don't we want to bail out if the policy is = unknown? My
> concern here is the user may configure with something it didn't ex= pect. The
> risk is the problem will be hard to debug.
>
> I also believe this could be part of libxl_{arm,x86}.c allowing us to = filter
> misuse early.

This sounds like a good idea, I can do that. Then, I can also #ifdef the hypercalls defines, although for some reason today libxl doesn't have CONFIG_X86 or CONFIG_ARM set so I would also have to do the following in the libxl Makefile:

ifeq ($(CONFIG_X86),y)
CFLAGS_LIBXL +=3D -DCONFIG_X86
else
CFLAGS_LIBXL +=3D -DCONFIG_ARM
endif

Or just follow what we do today in other public headers:

#if defined(__arm__) || defined(__aar= ch64__)

You need to doub= le check the exact syntax as I wrote it by memory.
<= br>
Cheers,



> Ian, Wei, any opinion?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailm= an/listinfo/xen-devel
--000000000000929bc8058ba087cb-- --===============1880288912437783584== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============1880288912437783584==--