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=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=no 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 8A5DFC433DF for ; Fri, 10 Jul 2020 05:44:47 +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 59BB32076A for ; Fri, 10 Jul 2020 05:44:47 +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="UjYgshhZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 59BB32076A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass 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.92) (envelope-from ) id 1jtlpp-0002wO-0W; Fri, 10 Jul 2020 05:44:33 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jtlpn-0002wJ-SV for xen-devel@lists.xenproject.org; Fri, 10 Jul 2020 05:44:31 +0000 X-Inumbo-ID: 6cb03c96-c270-11ea-bb8b-bc764e2007e4 Received: from mail-wm1-x344.google.com (unknown [2a00:1450:4864:20::344]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id 6cb03c96-c270-11ea-bb8b-bc764e2007e4; Fri, 10 Jul 2020 05:44:30 +0000 (UTC) Received: by mail-wm1-x344.google.com with SMTP id g75so4579836wme.5 for ; Thu, 09 Jul 2020 22:44:30 -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=4edQ0YselGGDwyfZkAcxeIabieLMJek3/TpD0WH/gAs=; b=UjYgshhZvEWQNEWUObMADwMsQSzjL+gWFhsuTHMIBcP61wwzte+xmJRtWR8zWDGM1P yKfTP3P5NlujAe6T7iRtODNObxBsAYGGvgIABKxUJZfLbKqzYgmWl5bMIYF1Ql+FrG4S DdD/RlugPLcc3Kq2x8OSi5flUDSIj8P4CP4QBOKjgrF44UTz1XCg4IdIH/aOPkYWd7Ve k4neig2NOv48t7nWgBuw2bNWouTRZEPOMF8P4Npcs9eVtIsITh1Yyow3ZFORSjnmEj85 e0XNmYVkwFG4UJXCrZgEN3/22C+QJPciILXLA++u2I3UPPpdPAL0j6KIlzjcf5bCIfx/ c3rw== 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=4edQ0YselGGDwyfZkAcxeIabieLMJek3/TpD0WH/gAs=; b=AQkapJjTkgg8UU7ZletJuZD2U4KCEYt9/OtEipRTl87/5EP++8FzUaE6klYOqhZMDW JnzcQw3/g1F/oDK1Fxh6phoEBJk4UglX+aXov3EP9kMzqtMWgKWsnzB+LFreOkXPNlEt uT6JnxHo4dRH5vVtklNafuyXR7vd7Go9p3aYOKNAO/yx0wzZ2wsW28LAlGLvLQNmnMKn IL9gqju/YAQIvEo5319n/7jaJ6BCjNgGnRgtDza9Wop1/zgQ997kvRqZP9XPVGRAsRgp bz/YEOYnfXybfKPvdo6xhK7D51/FTk0Zwi+TwigSJ1WcLs74p8XB5jJ6rkyWgp/PINPm MaPQ== X-Gm-Message-State: AOAM5311ka/6Vb2MMuCdV7+xHXuUO7cXLRP71UtDl/tKLD6tYlJ9Nyu+ IWzqeu91zYolkAcviHTgsOEyYtylx3F9K3OdbnQ= X-Google-Smtp-Source: ABdhPJxysuxRtR4lmGruhCGGljqm79dbNa6fBn3RLiqmrOitAMZFSVIoeNqahz4At2LsIVYfu/QWmGcO3Dq95awlOKM= X-Received: by 2002:a05:600c:2058:: with SMTP id p24mr3399981wmg.74.1594359870011; Thu, 09 Jul 2020 22:44:30 -0700 (PDT) MIME-Version: 1.0 References: <20200627095533.14145-1-julien@xen.org> <20200627095533.14145-3-julien@xen.org> <2e0a451e-58be-eff1-0030-be489e5098f3@xen.org> In-Reply-To: From: Julien Grall Date: Fri, 10 Jul 2020 06:44:16 +0100 Message-ID: Subject: Re: [PATCH v4 for-4.14 2/2] pvcalls: Document correctly and explicitely the padding for all arches To: Stefano Stabellini Content-Type: multipart/alternative; boundary="000000000000b23c4d05aa0fd5ea" X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Juergen Gross , Wei Liu , Paul Durrant , Andrew Cooper , Julien Grall , Ian Jackson , George Dunlap , Jan Beulich , xen-devel Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --000000000000b23c4d05aa0fd5ea Content-Type: text/plain; charset="UTF-8" On Thu, 9 Jul 2020, 22:43 Stefano Stabellini, wrote: > On Thu, 9 Jul 2020, Julien Grall wrote: > > Hi, > > > > Gentle ping. > > > > Is the new commit message fine? > > > > Cheers, > > > > On 04/07/2020 16:29, Julien Grall wrote: > > > Hi, > > > > > > On 27/06/2020 10:55, Julien Grall wrote: > > > > From: Julien Grall > > > > > > > > The specification of pvcalls suggests there is padding for 32-bit x86 > > > > at the end of most the structure. However, they are not described in > > > > in the public header. > > > > > > > > Because of that all the structures would be 32-bit aligned and not > > > > 64-bit aligned for 32-bit x86. > > > > > > > > For all the other architectures supported (Arm and 64-bit x86), the > > > > structure are aligned to 64-bit because they contain uint64_t field. > > > > Therefore all the structures contain implicit padding. > > > > > > > > Given the specification is authoriitative, the padding will the same > for > > > > the all architectures. The potential breakage of compatibility is > ought > > > > to be fine as pvcalls is still a tech preview. > > > > > > > > As an aside, the padding sadly cannot be mandated to be 0 as they are > > > > already present. So it is not going to be possible to use the padding > > > > for extending a command in the future. > > > > > > > > Signed-off-by: Julien Grall > > > > > > It looks like most of the comments are on the commit message. So > rather than > > > sending the series again, below a new version of the commit message: > > > > > > " > > > The specification of pvcalls suggests there is padding for 32-bit x86 > > > at the end of most the structure. However, they are not described in > > > in the public header. > > > > > > Because of that all the structures would have a different size between > > > 32-bit x86 and 64-bit x86. > > > > > > For all the other architectures supported (Arm and 64-bit x86), the > > > structure have the sames sizes because they contain implicit padding > thanks > > > to the 64-bit alinment of the field uint64_t field. > > > > > > Given the specification is authoritative, the padding will now be the > same > > > for all architectures. The potential breakage of compatibility is > ought to > > > be fine as pvcalls is still a tech preview. > > > " > > Looks good to me > > Acked-by: Stefano Stabellini > Thanks! I don't have access to my work laptop today. Can any of the committers merge it so it doesn't miss 4.14? Cheers, > --000000000000b23c4d05aa0fd5ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, 9 Jul 2020, 22:43 Stefano Stabellini, <sstabellini@kernel.org> wrote:=
On Thu, 9 Jul 2020, Julien Grall w= rote:
> Hi,
>
> Gentle ping.
>
> Is the new commit message fine?
>
> Cheers,
>
> On 04/07/2020 16:29, Julien Grall wrote:
> > Hi,
> >
> > On 27/06/2020 10:55, Julien Grall wrote:
> > > From: Julien Grall <jgrall@amazon.com>
> > >
> > > The specification of pvcalls suggests there is padding for 3= 2-bit x86
> > > at the end of most the structure. However, they are not desc= ribed in
> > > in the public header.
> > >
> > > Because of that all the structures would be 32-bit aligned a= nd not
> > > 64-bit aligned for 32-bit x86.
> > >
> > > For all the other architectures supported (Arm and 64-bit x8= 6), the
> > > structure are aligned to 64-bit because they contain uint64_= t field.
> > > Therefore all the structures contain implicit padding.
> > >
> > > Given the specification is authoriitative, the padding will = the same for
> > > the all architectures. The potential breakage of compatibili= ty is ought
> > > to be fine as pvcalls is still a tech preview.
> > >
> > > As an aside, the padding sadly cannot be mandated to be 0 as= they are
> > > already present. So it is not going to be possible to use th= e padding
> > > for extending a command in the future.
> > >
> > > Signed-off-by: Julien Grall <jgrall@amazon.com>
> >
> > It looks like most of the comments are on the commit message. So = rather than
> > sending the series again, below a new version of the commit messa= ge:
> >
> > "
> > The specification of pvcalls suggests there is padding for 32-bit= x86
> > at the end of most the structure. However, they are not described= in
> > in the public header.
> >
> > Because of that all the structures would have a different size be= tween
> > 32-bit x86 and 64-bit x86.
> >
> > For all the other architectures supported (Arm and 64-bit x86), t= he
> > structure have the sames sizes because they contain implicit padd= ing thanks
> > to the 64-bit alinment of the field uint64_t field.
> >
> > Given the specification is authoritative, the padding will now be= the same
> > for all architectures. The potential breakage of compatibility is= ought to
> > be fine as pvcalls is still a tech preview.
> > "

Looks good to me

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


Thanks! I don't have access to my work laptop today= . Can any of the committers merge it so it doesn't miss 4.14?

Cheers,
--000000000000b23c4d05aa0fd5ea--