From: Vivek Goyal <vgoyal@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Benjamin Romer <benjamin.romer@unisys.com>, linux-kernel@vger.kernel.org
Subject: Re: PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64)
Date: Thu, 18 Jan 2007 13:30:03 +0530 [thread overview]
Message-ID: <20070118080003.GC31860@in.ibm.com> (raw)
In-Reply-To: <m1tzyo7qtc.fsf@ebiederm.dsl.xmission.com>
On Thu, Jan 18, 2007 at 12:10:55AM -0700, Eric W. Biederman wrote:
> Vivek Goyal <vgoyal@in.ibm.com> writes:
> >
> > Or how about making physical_dest field also 8bit like logical_dest field.
> > This will work both for 4bit and 8bit physical apic ids at the same time
> > code becomes more intutive and it is easier to know whether IOAPIC is being
> > put in physical or destination logical mode.
>
> Exactly what I was trying to suggest.
>
> Looking closer at the code I think it makes sense to just kill the union and
> stop the discrimination between physical and logical modes and just have a
> dest field in the structure. Roughly as you were suggesting at first.
>
> The reason we aren't bitten by this on a regular basis is the normal code
> path uses logical.logical_dest in both logical and physical modes.
> Which is a little confusing.
>
> Since there really isn't a distinction to be made we should just stop
> trying, which will make maintenance easier :)
>
> Currently there are several non-common case users of physical_dest
> that are probably bitten by this problem under the right
> circumstances.
>
> So I think we should just make the structure:
>
> struct IO_APIC_route_entry {
> __u32 vector : 8,
> delivery_mode : 3, /* 000: FIXED
> * 001: lowest prio
> * 111: ExtINT
> */
> dest_mode : 1, /* 0: physical, 1: logical */
> delivery_status : 1,
> polarity : 1,
> irr : 1,
> trigger : 1, /* 0: edge, 1: level */
> mask : 1, /* 0: enabled, 1: disabled */
> __reserved_2 : 15;
>
> __u32 __reserved_3 : 24,
> __dest : 8;
> } __attribute__ ((packed));
>
> And fixup the users. This should keep us from getting bit by this bug
> in the future. Like when people start introducing support for more
> than 256 cores and the low 24bits start getting used.
>
> Or when someone new starts working on the code and thinks the fact
> the field name says logical we are actually using the apic in logical
> mode.
This makes perfect sense to me. Ben, interested in providing a patch
for this?
Thanks
Vivek
next prev parent reply other threads:[~2007-01-18 8:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-17 16:46 PATCH: Update disable_IO_APIC to use 8-bit destination field (X86_64) Benjamin Romer
2007-01-17 19:08 ` Eric W. Biederman
2007-01-18 3:41 ` Vivek Goyal
2007-01-18 4:36 ` Vivek Goyal
2007-01-18 7:10 ` Eric W. Biederman
[not found] ` <2 0070118080003.GC31860@in.ibm.com>
2007-01-18 8:00 ` Vivek Goyal [this message]
2007-01-18 14:58 ` Benjamin Romer
2007-01-18 17:23 ` Benjamin Romer
2007-01-18 18:14 ` Eric W. Biederman
[not found] ` <1169147619.6665. 11.camel@ustr-romerbm-2.na.uis.unisys.com>
2007-01-18 19:13 ` Benjamin Romer
2007-01-19 3:49 ` Vivek Goyal
2007-01-19 15:11 ` Benjamin Romer
2007-01-19 15:43 ` Randy Dunlap
2007-01-19 17:14 ` Benjamin Romer
2007-01-19 15:55 ` Eric W. Biederman
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=20070118080003.GC31860@in.ibm.com \
--to=vgoyal@in.ibm.com \
--cc=benjamin.romer@unisys.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.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.