From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>
Subject: Re: [PATCH v2 1/5] x86/hpet: Pre cleanup
Date: Fri, 8 Nov 2013 10:37:13 +0000 [thread overview]
Message-ID: <527CBED9.7060706@citrix.com> (raw)
In-Reply-To: <527CC1A602000078001011B7@nat28.tlf.novell.com>
On 08/11/13 09:49, Jan Beulich wrote:
>>>> On 07.11.13 at 16:28, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> This is a set of changes which might not make sense alone, but are
>> used/required for the main purpose of the series, and simply the mammoth
>> patch
>> making it easier to review.
>>
>> * Make hpet_msi_write conditionally disable MSIs while updating the route
>> register. This removes the requirement that it must be masked while
>> writing.
>>
>> * Defer read of cfg register in hpet_setup_msi_irq. As a result, an
>> intremap
>> failure prevents us suffering a pointless MMIO read.
> Rather benign I would say - this isn't a hot code path.
>
>> * Change some instances of per_cpu($foo, cpu) to this_cpu($foo). It is
>> cleaner to read, and makes it more obvious when the code is poking around
>> in
>> another cpus data.
> Documentation wise this is certainly desirable, but since our this_cpu(),
> other than e.g. Linux'es equivalents, internally does another
> smp_processor_id(), generate code becomes worse.
with an "unsigned int cpu = smp_processor_id()" in context, the
generated code appears to be identical.
>
>> * Convert hpet_next_event() to taking a struct hpet_event_channel *, and
>> rename to __hpet_set_counter() for a more accurate description of its
>> actions.
> I very much think we should get away from the habit of prefixing
> symbols with two underscores: Such names are reserved to the
> compiler/platform, and the standard specifically reserves names
> starting with one underscore (and not followed by an upper case
> letter) for use a file scope symbols. This is what I'd like to request
> be done here.
So what would you suggest? Here, all the __$foo() are designed to end
up similar to large swathes of other Xen code, implying that the
appropriate spinlock should be held by the caller.
I am not too fussed which convention we use, so long as it is used
consistently.
>
>> @@ -697,14 +707,16 @@ void hpet_broadcast_enter(void)
>> {
>> unsigned int cpu = smp_processor_id();
>> struct hpet_event_channel *ch = per_cpu(cpu_bc_channel, cpu);
> And you're not even consistent with your conversion - you don't
> convert the above, ...
Because cpu_bc_channel disappears in the next patch. As stated in the
description, the primary purpose of this patch is to make the following
patch easier to read, rather than to strictly make sense itself.
>
>> + s_time_t deadline = this_cpu(timer_deadline);
>> +
>> + ASSERT(!local_irq_is_enabled());
>>
>> - if ( per_cpu(timer_deadline, cpu) == 0 )
> ... but you do convert this one.
Because the following patch needs 'deadline' in the new code added here.
~Andrew
>
>> @@ -725,7 +737,9 @@ void hpet_broadcast_exit(void)
>> unsigned int cpu = smp_processor_id();
>> struct hpet_event_channel *ch = per_cpu(cpu_bc_channel, cpu);
>>
>> - if ( per_cpu(timer_deadline, cpu) == 0 )
>> + ASSERT(local_irq_is_enabled());
>> +
>> + if ( this_cpu(timer_deadline) == 0 )
> Same here. Anyway - I'd prefer these to be left alone.
>
> Jan
>
next prev parent reply other threads:[~2013-11-08 10:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 15:28 [RFC v2 0/5] HPET fix interrupt logic Andrew Cooper
2013-11-07 15:28 ` [PATCH v2 1/5] x86/hpet: Pre cleanup Andrew Cooper
2013-11-08 9:49 ` Jan Beulich
2013-11-08 10:37 ` Andrew Cooper [this message]
2013-11-08 11:40 ` Jan Beulich
2013-11-08 16:39 ` Tim Deegan
2013-11-11 9:05 ` Jan Beulich
2013-11-11 10:49 ` David Vrabel
2013-11-07 15:28 ` [PATCH v2 2/5] x86/hpet: Use singe apic vector rather than irq_descs for HPET interrupts Andrew Cooper
2013-11-08 1:08 ` Tim Deegan
2013-11-08 11:05 ` Andrew Cooper
2013-11-07 15:28 ` [PATCH v2 3/5] x86/hpet: Post cleanup Andrew Cooper
2013-11-07 15:28 ` [PATCH v2 4/5] x86/hpet: Debug and verbose hpet logging Andrew Cooper
2013-11-07 15:28 ` [PATCH v2 5/5] x86/hpet: debug keyhandlers 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=527CBED9.7060706@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=keir@xen.org \
--cc=tim@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).