All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@amd64.org>
To: Tony Luck <tony.luck@intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Borislav Petkov <borislav.petkov@amd.com>
Subject: [RFC PATCH 0/3] mca_config stuff
Date: Wed, 10 Oct 2012 16:19:58 +0200	[thread overview]
Message-ID: <1349878801-15956-1-git-send-email-bp@amd64.org> (raw)

From: Borislav Petkov <borislav.petkov@amd.com>

Right,

so I did give that a try and it turned out to be a bit more involved
than I thought. Basically, I'm relying on the assumption that if I use a
u64 bitfield and pass a pointer to it, accessing it through that pointer
as a u64 value works. Actually, I have the u64 bitfield as the first
member of a struct and if I cast a pointer to that struct to u64 *, I'm
expecting to have the 64 bits of the same bitfield.

Therefore, I can toggle the bits in the mce code with mca_cfg.<bitname>.
When defining accessing them through the device attributes in sysfs, I
use a new macro DEVICE_BIT_ATTR which gets the corresponding bit number
of that same bit in the bitfield. This gives only one function which
operates on a bitfield instead of a single function per bit in the
bitfield.

For example,

mca_cfg {
	u64 dont_log_ce : 1,

is the first bit in the bitfield and I also have a MCA_CFG_DONT_LOG_CE
define which is 0, i.e. the first bit, which I use to toggle the
corresponding bit in the u64 in device_{show,store}_bit.

So I converted mce_dont_log_ce and mce_disabled (renaming it into the
more correct mca_disabled) and it seems to work.

The asm looks sane too. One other advantage is that it makes the code
much more cleaner and compact by collecting all those bool config values
in a single struct, which was my original incentive to do that.

So please take a look and let me know whether this is sane, especially
the above assumption that I can access a u64 bitfield through a u64 *
and the bits are where they're expected to be. gcc seems to do that...
and I don't see anything in the C99 standard that would object to it but
I could be overlooking something.

Thanks.

Borislav Petkov (3):
  Add DEVICE_BIT_ATTR
  Change mce_dont_log_ce
  Convert mce_disabled

 arch/x86/include/asm/mce.h       |  9 ++++++++-
 arch/x86/kernel/cpu/mcheck/mce.c | 21 ++++++++++-----------
 arch/x86/lguest/boot.c           |  2 +-
 drivers/base/core.c              | 36 ++++++++++++++++++++++++++++++++++++
 include/linux/device.h           |  9 +++++++++
 5 files changed, 64 insertions(+), 13 deletions(-)

-- 
1.8.0.rc0.18.gf84667d


             reply	other threads:[~2012-10-10 14:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-10 14:19 Borislav Petkov [this message]
2012-10-10 14:19 ` [RFC PATCH 1/3] Add DEVICE_BIT_ATTR Borislav Petkov
2012-10-10 14:20 ` [RFC PATCH 2/3] Change mce_dont_log_ce Borislav Petkov
2012-10-10 14:20 ` [RFC PATCH 3/3] Convert mce_disabled Borislav Petkov
2012-10-10 15:46   ` Luck, Tony
2012-10-10 15:53     ` Borislav Petkov
2012-10-12 10:50   ` Naveen N. Rao
2012-10-12 11:56     ` Borislav Petkov
2012-10-12 17:46       ` Luck, Tony
2012-10-12 21:58         ` Borislav Petkov
2012-10-15  5:53       ` Naveen N. Rao
2012-10-10 15:35 ` [RFC PATCH 0/3] mca_config stuff Luck, Tony
2012-10-10 19:53   ` Borislav Petkov

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=1349878801-15956-1-git-send-email-bp@amd64.org \
    --to=bp@amd64.org \
    --cc=borislav.petkov@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    /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.