All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Xen-devel <xen-devel@lists.xen.org>
Cc: Wei Liu <wei.liu2@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: [PATCH RFC 15/31] x86: Generate deep dependencies of x86 features
Date: Tue, 5 Jan 2016 16:54:41 +0000	[thread overview]
Message-ID: <1452012881.13361.385.camel@citrix.com> (raw)
In-Reply-To: <568BF289.8020204@citrix.com>

On Tue, 2016-01-05 at 16:42 +0000, Andrew Cooper wrote:
> 
> > IIRC void * arithmetic is a gcc (and presumably clang) extension, which
> > we
> > can specify for Xen itself, but I'm not sure about libxc (cf: recent
> > discussions about building stuff for Windows).
> 
> It isn't void* arithmetic.  Simply taking a void * to facilitate
> different underlying types for a bitmap.
> 
> > 
> > What actually breaks with the existing definitions?
> 
> Xen uses unsigned int[] for bitmaps, while libxc uses unsigned long[]. 
> The compiler objects to the mix of pointers to different sized.

Did you also change Xen to void somewhere in this series, or if not why not
change libxc to use an unsigned int[] if we want them to be consistent?


> > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> > > ---
> > > CC: Jan Beulich <JBeulich@suse.com>
> > > CC: Ian Campbell <Ian.Campbell@citrix.com>
> > > CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> > > CC: Wei Liu <wei.liu2@citrix.com>
> > > 
> > > TODO: The generation of autogen.c now means that libxc needs to be
> > > compiled
> > > after the hypervisor, as the vpath doesn't convey the generation
> > > information.
> > > I need to find a way to fix this.
> > I'd be inclined to do the autogeneration twice with the output being
> > outside the shared directory or gaining a (tools|xen)_ prefix.
> > 
> > It's a bit wasteful to do it twice but anything else would add an
> > undesirable linkage between tools and hypervisor build I think. I'm
> > certain
> > we don't want to commit the generated files.
> 
> I will see how much of this I can get into the automatically generated
> part.  The problem is that there is a header file and secondary .c file
> which are not automatically generated, but needed in both places.  I
> definitely do not want to duplicate those.

The secondary.c seems ok, it'll get vpathd.

The header, I suppose it depends which way the #include goes from the
generated things, at worst it'd be an #ifdef or a flag to the generator I
guess?

> > > +/* Sparse feature matrix identifying all features which depend on a
> > > feature. */
> > > +extern const struct tagged_featureset deep_deps[];
> > This'll be XEN_NR_FEATURESET_ENTRIES^2 entries? How big is that getting
> > OOI?
> 
> It is a sparse matrix, not an n^2 matrix.  It only has entries for
> features which sit in a dependency tree, which is vastly fewer than all
> known features.  Currently, it is an array of 9 entries.

I'd probably just call this a (sorted) list of dependencies, but ok then ;-
)

> > > +
> > > +        # Expected duplicate symbols.  Discard
> > > +        if name in ('3DNOW_ALT', ):
> > > +            continue
> > OOI how does this arise?
> 
> Bug in older AMD processors.  See the first and final hunks of c/s
> d8ba3a9

Lovely!

I think I'd say "Expected duplicate values" since I thought the name
3DNOW_ALT was what was duplicated, which made me wonder how it compiled...

If you dropped the appearance of being generic the comment could usefully
give a hint about BPE, afterall this should be a pretty exceptional
occurrence and another if with another comment for the next one doesn't
seem too hateful.

> 
> ~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-01-05 16:54 UTC|newest]

Thread overview: 123+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 21:24 [PATCH RFC 00/31] x86: Improvements to cpuid handling for guests Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 01/31] xen/public: Export featureset information in the public API Andrew Cooper
2015-12-22 16:28   ` Jan Beulich
2015-12-22 16:42     ` Andrew Cooper
2015-12-22 16:59       ` Jan Beulich
2015-12-23 10:05         ` Andrew Cooper
2015-12-23 10:24           ` Jan Beulich
2015-12-23 11:26             ` Andrew Cooper
2016-01-06  7:43               ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 02/31] tools/libxc: Use public/featureset.h for cpuid policy generation Andrew Cooper
2015-12-22 16:29   ` Jan Beulich
2016-01-05 14:13     ` Ian Campbell
2016-01-05 14:17       ` Andrew Cooper
2016-01-05 14:18         ` Ian Campbell
2016-01-05 14:23           ` Andrew Cooper
2016-01-05 15:02             ` Ian Campbell
2016-01-05 15:42               ` Andrew Cooper
2016-01-05 16:09                 ` Ian Campbell
2015-12-16 21:24 ` [PATCH RFC 03/31] xen/x86: Store antifeatures inverted in a featureset Andrew Cooper
2015-12-22 16:32   ` Jan Beulich
2015-12-22 17:03     ` Andrew Cooper
2016-01-05 14:19       ` Ian Campbell
2016-01-05 14:24         ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 04/31] xen/x86: Mask out unknown features from Xen's capabilities Andrew Cooper
2015-12-22 16:42   ` Jan Beulich
2015-12-22 17:01     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 05/31] xen/x86: Collect more CPUID feature words Andrew Cooper
2015-12-22 16:46   ` Jan Beulich
2015-12-22 17:17     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 06/31] xen/x86: Infrastructure to calculate guest featuresets Andrew Cooper
2015-12-22 16:50   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 07/31] xen/x86: Export host featureset via SYSCTL Andrew Cooper
2015-12-22 16:57   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 08/31] tools/stubs: Expose host featureset to userspace Andrew Cooper
2016-01-05 15:36   ` Ian Campbell
2016-01-05 15:59     ` Andrew Cooper
2016-01-05 16:09       ` Ian Campbell
2016-01-05 16:19         ` Andrew Cooper
2016-01-05 16:38           ` Ian Campbell
2015-12-16 21:24 ` [PATCH RFC 09/31] xen/x86: Calculate PV featureset Andrew Cooper
2015-12-22 17:07   ` Jan Beulich
2015-12-22 17:13     ` Andrew Cooper
2015-12-22 17:18       ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 10/31] xen/x86: Calculate HVM featureset Andrew Cooper
2015-12-22 17:11   ` Jan Beulich
2015-12-22 17:21     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 11/31] xen/x86: Calculate Raw featureset Andrew Cooper
2015-12-22 17:14   ` Jan Beulich
2015-12-22 17:27     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 12/31] tools: Utility for dealing with featuresets Andrew Cooper
2016-01-05 15:17   ` Ian Campbell
2016-01-05 16:14     ` Andrew Cooper
2016-01-05 16:34       ` Ian Campbell
2016-01-05 17:13         ` Andrew Cooper
2016-01-05 17:37           ` Ian Campbell
2016-01-05 18:04             ` Andrew Cooper
2016-01-06 10:38               ` Ian Campbell
2016-01-06 10:40   ` Ian Campbell
2016-01-06 10:42     ` Ian Campbell
2015-12-16 21:24 ` [PATCH RFC 13/31] tools/libxc: Wire a featureset through to cpuid policy logic Andrew Cooper
2016-01-05 15:42   ` Ian Campbell
2016-01-05 16:20     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 14/31] tools/libxc: Use featureset rather than guesswork Andrew Cooper
2016-01-05 15:54   ` Ian Campbell
2016-01-05 16:22     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 15/31] x86: Generate deep dependencies of x86 features Andrew Cooper
2016-01-05 16:03   ` Ian Campbell
2016-01-05 16:42     ` Andrew Cooper
2016-01-05 16:54       ` Ian Campbell [this message]
2016-01-05 17:09         ` Andrew Cooper
2016-01-05 17:19           ` Ian Campbell
2015-12-16 21:24 ` [PATCH RFC 16/31] x86: Automatically generate known_features Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 17/31] xen/x86: Clear dependent features when clearing a cpu cap Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 18/31] xen/x86: Improve disabling of features which have dependencies Andrew Cooper
2016-01-21 16:48   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 19/31] tools/libxc: Sanitise guest featuresets Andrew Cooper
2016-01-05 16:05   ` Ian Campbell
2015-12-16 21:24 ` [PATCH RFC 20/31] x86: Improvements to in-hypervisor cpuid sanity checks Andrew Cooper
2016-01-21 17:02   ` Jan Beulich
2016-01-21 17:21     ` Andrew Cooper
2016-01-21 18:15       ` Andrew Cooper
2016-01-22  7:47         ` Jan Beulich
2016-01-22  7:45       ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 21/31] x86/domctl: Break out logic to update domain state from cpuid information Andrew Cooper
2016-01-21 17:05   ` Jan Beulich
2016-01-21 17:08     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 22/31] x86/cpu: Move set_cpumask() calls into c_early_init() Andrew Cooper
2016-01-21 17:08   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 23/31] xen/x86: Export cpuid levelling capabilities via SYSCTL Andrew Cooper
2016-01-21 17:23   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 24/31] tools/stubs: Expose host levelling capabilities to userspace Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 25/31] xen/x86: Common infrastructure for levelling context switching Andrew Cooper
2016-01-22  8:56   ` Jan Beulich
2016-01-22 10:05     ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 26/31] xen/x86: Rework AMD masking MSR setup Andrew Cooper
2016-01-22  9:27   ` Jan Beulich
2016-01-22 11:01     ` Andrew Cooper
2016-01-22 11:13       ` Jan Beulich
2016-01-22 13:59         ` Andrew Cooper
2016-01-22 14:12           ` Jan Beulich
2016-01-22 17:03             ` Andrew Cooper
2016-01-25 11:25               ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 27/31] xen/x86: Rework Intel masking/faulting setup Andrew Cooper
2016-01-22  9:40   ` Jan Beulich
2016-01-22 14:09     ` Andrew Cooper
2016-01-22 14:29       ` Jan Beulich
2016-01-22 14:46         ` Andrew Cooper
2016-01-22 14:53           ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 28/31] xen/x86: Context switch all levelling state in context_switch() Andrew Cooper
2016-01-22  9:52   ` Jan Beulich
2016-01-22 14:19     ` Andrew Cooper
2016-01-22 14:31       ` Jan Beulich
2016-01-22 14:39         ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 29/31] x86/pv: Provide custom cpumasks for PV domains Andrew Cooper
2016-01-22  9:56   ` Jan Beulich
2016-01-22 14:24     ` Andrew Cooper
2016-01-22 14:33       ` Jan Beulich
2016-01-22 14:42         ` Andrew Cooper
2016-01-22 14:48           ` Jan Beulich
2016-01-22 14:56             ` Andrew Cooper
2015-12-16 21:24 ` [PATCH RFC 30/31] x86/domctl: Update PV domain cpumasks when setting cpuid policy Andrew Cooper
2016-01-22 10:02   ` Jan Beulich
2015-12-16 21:24 ` [PATCH RFC 31/31] tools/libxc: Calculate xstate cpuid leaf from guest information 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=1452012881.13361.385.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xen.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.