From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>,
"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 5/6] x86/ucode: Alter ops->free_patch() to free the entire patch
Date: Fri, 20 Mar 2020 14:51:19 +0100 [thread overview]
Message-ID: <2acabccd-da3b-9e22-8f27-41ab1b3cde8a@suse.com> (raw)
In-Reply-To: <20200319152622.31758-6-andrew.cooper3@citrix.com>
On 19.03.2020 16:26, Andrew Cooper wrote:
> The data layout for struct microcode_patch is extremely poor, and
> unnecessarily complicated. Almost all of it is opaque to core.c, with the
> exception of free_patch().
>
> Move the responsibility for freeing the patch into the free_patch() hook,
> which will allow each driver to do a better job.
But that wrapper structure is something common, i.e. to be
allocated as well as to be freed (preferably) by common code.
We did specifically move there during review of the most
recent re-work.
However, having taken a look also at the next patch I wonder
why you even retain that wrapper structure containing just
a single pointer? Why can't what is now
struct microcode_{amd,intel} become struct microcode_patch,
with - as you say there - different per-vendor layout which
is opaque to common code?
> Take the opportunity to make the hooks idempotent.
I'm having difficulty seeing what part of the patch this is
about.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-03-20 13:51 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-19 15:26 [Xen-devel] [PATCH 0/6] x86/ucode: Cleanup - Part 1/n Andrew Cooper
2020-03-19 15:26 ` [Xen-devel] [PATCH 1/6] x86/ucode: Remove declarations for non-external functions Andrew Cooper
2020-03-19 15:26 ` [Xen-devel] [PATCH 2/6] x86/ucode: Move microcode into its own directory Andrew Cooper
2020-03-19 15:26 ` [Xen-devel] [PATCH 3/6] x86/ucode: Move interface from processor.h to microcode.h Andrew Cooper
2020-03-19 15:26 ` [Xen-devel] [PATCH 4/6] x86/ucode: Rationalise startup and family/model checks Andrew Cooper
2020-03-20 13:37 ` Jan Beulich
2020-03-20 13:40 ` Andrew Cooper
2020-03-20 13:56 ` Jan Beulich
2020-03-20 14:27 ` Andrew Cooper
2020-03-20 14:48 ` Jan Beulich
2020-03-19 15:26 ` [Xen-devel] [PATCH 5/6] x86/ucode: Alter ops->free_patch() to free the entire patch Andrew Cooper
2020-03-20 13:51 ` Jan Beulich [this message]
2020-03-20 14:50 ` Andrew Cooper
2020-03-20 15:15 ` Jan Beulich
2020-03-20 16:10 ` Andrew Cooper
2020-03-20 16:16 ` Jan Beulich
2020-03-20 16:48 ` Andrew Cooper
2020-03-23 7:52 ` Jan Beulich
2020-03-19 15:26 ` [Xen-devel] [PATCH 6/6] x86/ucode: Make struct microcode_patch opaque Andrew Cooper
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=2acabccd-da3b-9e22-8f27-41ab1b3cde8a@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).