From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>, Wei Liu <wei.liu2@citrix.com>
Cc: Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c
Date: Thu, 8 Jun 2017 12:30:02 +0100 [thread overview]
Message-ID: <d12a645a-a78d-5b6d-bc95-cf64123a8863@citrix.com> (raw)
In-Reply-To: <5936779C020000780015F9C2@prv-mh.provo.novell.com>
On 06/06/17 08:36, Jan Beulich wrote:
>>>> On 02.06.17 at 13:01, <wei.liu2@citrix.com> wrote:
>> On Wed, May 31, 2017 at 05:45:14AM -0600, Jan Beulich wrote:
>>>>>> On 31.05.17 at 13:14, <wei.liu2@citrix.com> wrote:
>>>> On Tue, May 30, 2017 at 11:59:31PM -0600, Jan Beulich wrote:
>>>>>>>> On 30.05.17 at 19:40, <andrew.cooper3@citrix.com> wrote:
>>>>>> On 29/05/17 16:40, Jan Beulich wrote:
>>>>>>>>>> On 18.05.17 at 19:09, <wei.liu2@citrix.com> wrote:
>>>>>>>> The following handlers are moved:
>>>>>>>> 1. do_set_trap_table
>>>>>>> This one makes sense to move to pv/traps.c, but ...
>>>>>>>
>>>>>>>> 2. do_set_debugreg
>>>>>>>> 3. do_get_debugreg
>>>>>>>> 4. do_fpu_taskswitch
>>>>>>> ... none of these do. I could see them go into pv/hypercall.c,
>>>>>>> but I could also see that file dealing intentionally only with
>>>>>>> everything hypercall related except individual handlers. Andrew,
>>>>>>> do you have any opinion or thoughts here?
>>>>>> Despite its name, traps.c deals with mostly low level exception
>>>>>> handling, so I am not completely convinced that do_set_trap_table()
>>>>>> would logically live in traps.c
>>>>> I can see this being the case for traps.c, but pv/traps.c? There's
>>>>> not much _low level_ exception handling that's PV-specific. But I
>>>>> certainly don't mind such relatively small hypercall handlers to be
>>>>> lumped together into some other file, ...
>>>>>
>>>>>> I'd also prefer not to mix these into hypercall.c. The best I can
>>>>>> suggest is pv/domain.c, but even that isn't great.
>>>>>>
>>>>>> Sorry for being unhelpful. I'm not sure pv/misc-hypercalls.c is a
>>>>>> suitable name either.
>>>>> ... be it this name or some other one (if we can think of a better
>>>>> alternative). Thinking of it: The currently present file is named
>>>>> "hypercall.c" - how about "hypercalls.c"?
>>>>>
>>>> Well I don't think moving them into hypercall(s).c is nice either.
>>>>
>>>> Since you expressed the idea of using iret.c for do_iret, maybe we can
>>>> use debugreg.c and fpu_taskswitch.c ?
>>> I did consider this too, but some of these are really small, and
>>> while is dislike overly large files, I also don't think files with just
>>> one or two dozens of actual code lines are very useful to have.
>>>
>> TBH I don't really see a problem with that approach -- we have clear_page.S,
>> copy_page.S and gpr_switch.S which don't get lumped together into one
>> file.
> I view C files slightly differently from assembly ones in this regard.
Looking at those files, they really should be replaced with something
better. Steel^W Borrowing the Linux alternatives-based clear/copy
routines would probably be a very good move.
>
>> But if you don't like that, I will just put those small handlers
>> into hypercall.c and change the comment of that file to:
>>
>> diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
>> index 7c5e5a629d..b0c9e01268 100644
>> --- a/xen/arch/x86/pv/hypercall.c
>> +++ b/xen/arch/x86/pv/hypercall.c
>> @@ -1,7 +1,7 @@
>>
>> /****************************************************************************
>> **
>> * arch/x86/pv/hypercall.c
>> *
>> - * PV hypercall dispatching routines
>> + * PV hypercall dispatching routines and misc hypercalls
> As indicated before, I don't really like the idea of specific
> hypercall handler being put here. I did suggest hypercalls.c
> as a possible place for one which don't fit elsewhere.
>
> Andrew, do you have any specific opinion both on the specific
> situation here as well as the broader question of file granularity?
I'd prefer not to have individual files for individual functions; that
is going too far IMO. I'd also prefer not to mix misc hypercalls into
this file.
pv/misc-hypercalls.c ?
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2017-06-08 11:30 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-18 17:09 [PATCH for-next v3 00/22] x86: refactor trap handling code Wei Liu
2017-05-18 17:09 ` [PATCH for-next v3 01/22] x86/traps: move privilege instruction emulation code Wei Liu
2017-05-18 17:28 ` Wei Liu
2017-05-29 15:14 ` Jan Beulich
2017-05-30 17:27 ` Wei Liu
2017-05-30 17:30 ` Andrew Cooper
2017-05-31 5:55 ` Jan Beulich
2017-05-31 11:01 ` Wei Liu
2017-05-31 11:05 ` Andrew Cooper
2017-05-31 11:36 ` Wei Liu
2017-05-31 11:43 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 02/22] x86/traps: move gate op " Wei Liu
2017-05-29 15:15 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 03/22] x86/traps: move emulate_invalid_rdtscp Wei Liu
2017-05-29 15:18 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 04/22] x86/traps: move emulate_forced_invalid_op Wei Liu
2017-05-29 15:19 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 05/22] x86/pv: clean up emulate.c Wei Liu
2017-05-29 15:37 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 06/22] x86/traps: move PV hypercall handlers to pv/traps.c Wei Liu
2017-05-29 15:40 ` Jan Beulich
2017-05-30 17:40 ` Andrew Cooper
2017-05-31 5:59 ` Jan Beulich
2017-05-31 11:14 ` Wei Liu
2017-05-31 11:45 ` Jan Beulich
2017-06-02 11:01 ` Wei Liu
2017-06-06 7:36 ` Jan Beulich
2017-06-08 11:30 ` Andrew Cooper [this message]
2017-06-08 14:28 ` Wei Liu
2017-05-18 17:09 ` [PATCH for-next v3 07/22] x86/traps: move pv_inject_event " Wei Liu
2017-05-29 15:42 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 08/22] x86/traps: move set_guest_{machinecheck, nmi}_trapbounce Wei Liu
2017-05-29 15:43 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 09/22] x86/traps: move {un, }register_guest_nmi_callback Wei Liu
2017-05-18 17:09 ` [PATCH for-next v3 10/22] x86/traps: delcare percpu softirq_trap Wei Liu
2017-05-29 15:49 ` Jan Beulich
2017-05-31 11:35 ` Wei Liu
2017-05-31 11:46 ` Jan Beulich
2017-05-31 11:54 ` Wei Liu
2017-05-18 17:09 ` [PATCH for-next v3 11/22] x86/traps: move guest_has_trap_callback to pv/traps.c Wei Liu
2017-05-29 15:54 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 12/22] x86/traps: move send_guest_trap " Wei Liu
2017-05-29 15:55 ` Jan Beulich
2017-06-05 17:08 ` Wei Liu
2017-06-06 7:37 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 13/22] x86/traps: move toggle_guest_mode Wei Liu
2017-05-29 16:05 ` Jan Beulich
2017-05-30 17:47 ` Andrew Cooper
2017-05-31 6:00 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 14/22] x86/traps: move do_iret to pv/traps.c Wei Liu
2017-05-29 16:07 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 15/22] x86/traps: move init_int80_direct_trap Wei Liu
2017-05-29 16:07 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 16/22] x86/traps: move callback_op code Wei Liu
2017-05-29 16:09 ` Jan Beulich
2017-05-18 17:09 ` [PATCH for-next v3 17/22] x86/traps: move hypercall_page_initialise_ring3_kernel Wei Liu
2017-05-29 16:10 ` Jan Beulich
2017-05-18 17:10 ` [PATCH for-next v3 18/22] x86/traps: merge x86_64/compat/traps.c into pv/traps.c Wei Liu
2017-05-29 16:12 ` Jan Beulich
2017-05-18 17:10 ` [PATCH for-next v3 19/22] x86: clean up pv/traps.c Wei Liu
2017-05-29 16:18 ` Jan Beulich
2017-05-18 17:10 ` [PATCH for-next v3 20/22] x86: guest_has_trap_callback should return bool Wei Liu
2017-05-18 17:10 ` [PATCH for-next v3 21/22] x86: fix coding style issues in asm-x86/traps.h Wei Liu
2017-05-18 17:10 ` [PATCH for-next v3 22/22] x86: clean up traps.c Wei Liu
2017-05-29 16:21 ` Jan Beulich
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=d12a645a-a78d-5b6d-bc95-cf64123a8863@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=wei.liu2@citrix.com \
--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).