From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Julien Grall <julien@xen.org>, Wei Liu <wl@xen.org>,
Paul Durrant <paul@xen.org>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@citrix.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 2/7] x86/mce: add compat struct checking for XEN_MC_inject_v2
Date: Tue, 14 Jul 2020 12:24:48 +0200 [thread overview]
Message-ID: <20200714102448.GH7191@Air-de-Roger> (raw)
In-Reply-To: <007679c8-84d5-2e91-e48e-68746741fb45@suse.com>
On Wed, Jul 01, 2020 at 12:25:48PM +0200, Jan Beulich wrote:
> 84e364f2eda2 ("x86: add CMCI software injection interface") merely made
> sure things would build, without any concern about things actually
> working:
> - despite the addition of xenctl_bitmap to xlat.lst, the resulting macro
> wasn't invoked anywhere (which would have lead to recognizing that the
> structure appeared to have no fully compatible layout, despite the use
> of a 64-bit handle),
> - the interface struct itself was neither added to xlat.lst (and the
> resulting macro then invoked) nor was any manual checking of
> individual fields added.
>
> Adjust compat header generation logic to retain XEN_GUEST_HANDLE_64(),
> which is intentionally layed out to be compatible between different size
> guests. Invoke the missing checking (implicitly through CHECK_mc).
>
> No change in the resulting generated code.
>
> Fixes: 84e364f2eda2 ("x86: add CMCI software injection interface")
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
LGTM, just one question below.
> --- a/xen/tools/compat-build-header.py
> +++ b/xen/tools/compat-build-header.py
> @@ -19,6 +19,7 @@ pats = [
> [ r"(^|[^\w])xen_?(\w*)_compat_t([^\w]|$$)", r"\1compat_\2_t\3" ],
> [ r"(^|[^\w])XEN_?", r"\1COMPAT_" ],
> [ r"(^|[^\w])Xen_?", r"\1Compat_" ],
> + [ r"(^|[^\w])COMPAT_HANDLE_64\(", r"\1XEN_GUEST_HANDLE_64(" ],
Why do you need to match with the opening parenthesis?
Is this for the #ifndef XEN_GUEST_HANDLE_64 instances? Don't they need
to also be replaced with the compat types?
Thanks, Roger.
next prev parent reply other threads:[~2020-07-14 10:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 10:22 [PATCH v2 0/7] x86: compat header generation and checking adjustments Jan Beulich
2020-07-01 10:25 ` [PATCH v2 1/7] x86: fix compat header generation Jan Beulich
2020-07-01 16:10 ` Roger Pau Monné
2020-07-01 16:17 ` Jan Beulich
2020-07-15 8:43 ` Roger Pau Monné
2020-07-15 8:56 ` Jan Beulich
2020-07-01 10:25 ` [PATCH v2 2/7] x86/mce: add compat struct checking for XEN_MC_inject_v2 Jan Beulich
2020-07-14 10:24 ` Roger Pau Monné [this message]
2020-07-14 11:44 ` Jan Beulich
2020-07-14 14:30 ` Roger Pau Monné
2020-07-01 10:26 ` [PATCH v2 3/7] x86/mce: bring hypercall subop compat checking in sync again Jan Beulich
2020-07-14 11:19 ` Roger Pau Monné
2020-07-14 11:47 ` Jan Beulich
2020-07-14 14:31 ` Roger Pau Monné
2020-07-15 6:27 ` Jan Beulich
2020-07-14 14:32 ` Roger Pau Monné
2020-07-01 10:27 ` [PATCH v2 4/7] x86/dmop: add compat struct checking for XEN_DMOP_map_mem_type_to_ioreq_server Jan Beulich
2020-07-14 11:19 ` Roger Pau Monné
2020-07-01 10:27 ` [PATCH v2 5/7] x86: generalize padding field handling Jan Beulich
2020-07-14 14:29 ` Roger Pau Monné
2020-07-15 6:36 ` Jan Beulich
2020-07-15 8:34 ` Roger Pau Monné
2020-07-15 8:47 ` Jan Beulich
2020-07-01 10:28 ` [PATCH v2 6/7] flask: drop dead compat translation code Jan Beulich
2020-07-14 14:58 ` Roger Pau Monné
2020-07-15 6:42 ` Jan Beulich
2020-07-15 8:41 ` Roger Pau Monné
2020-07-15 8:52 ` Jan Beulich
2020-07-15 10:08 ` Roger Pau Monné
2020-07-01 10:28 ` [PATCH v2 7/7] x86: only generate compat headers actually needed Jan Beulich
2020-07-14 15:03 ` Roger Pau Monné
2020-07-15 6:47 ` Jan Beulich
2020-07-02 7:34 ` [PATCH v2 0/7] x86: compat header generation and checking adjustments Paul Durrant
2020-07-02 7:42 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200714102448.GH7191@Air-de-Roger \
--to=roger.pau@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@citrix.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=paul@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.