All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>,
	Wei Liu <wei.liu2@citrix.com>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Subject: Re: [PATCH RFC 04/13] x86/mm: carve out create_grant_pv_mapping
Date: Wed, 29 Mar 2017 12:02:58 +0100	[thread overview]
Message-ID: <20170329110258.4ke3jim3xef5va6t@citrix.com> (raw)
In-Reply-To: <3bf05a2c-569f-da2f-b4d2-929703d0cd4d@citrix.com>

On Wed, Mar 29, 2017 at 11:49:54AM +0100, Andrew Cooper wrote:
> On 29/03/17 11:45, Jan Beulich wrote:
> >>>> On 29.03.17 at 12:27, <andrew.cooper3@citrix.com> wrote:
> >> One idea I had while starting the hypercall work was to introduce a
> >> "struct guest_type_ops" to contain some function pointers for options we
> >> perform on all guests, irrespective of type.  My first candidate for
> >> splitting this way was the hypercall page writing.
> >>
> >> This splitting here is subtly different.  Its more "struct
> >> paging_type_op", but still common operations we would need to perform
> >> for guests.
> >>
> >> I was thinking that ops structures like this would be cleaner to isolate
> >> than needing an explicit dispatch functions such as
> >> create_grant_host_mapping() below.
> >>
> >> Thoughts, (seeing as this is the first time I have floated this idea on
> >> xen-devel) ?
> > I think that's reasonable as long as we don't go too far with this
> > (indirect calls after all generally having a higher overhead than
> > mis-predicted branches).
> 
> Without any #ifdefary in a source tree, that is fine.  It is harder
> however if you want to conditionally compile things out.
> 
> A alternative option would be to have a static inline in a header file
> which contains the appropriate #ifdefary internally.
> 

Both sound reasonable to me. I slightly prefer guest_op_ops because it
seems cleaner.

The overhead concern applies to hot path code -- I don't think most
guest type specific hypercalls qualify.

Wei.

> ~Andrew

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

  reply	other threads:[~2017-03-29 11:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27  9:10 [PATCH RFC 00/13] Refactor x86/mm.c Wei Liu
2017-03-27  9:10 ` [PATCH RFC 01/13] x86/mm: export {get,put}_pg_owner Wei Liu
2017-03-28 21:11   ` [PATCH RFC 01/13] x86/mm: export {get, put}_pg_owner Andrew Cooper
2017-03-29  9:03     ` Jan Beulich
2017-03-29  9:10       ` Andrew Cooper
2017-03-30 10:07         ` Wei Liu
2017-03-30 12:25           ` Jan Beulich
2017-03-30 12:48             ` Wei Liu
2017-03-27  9:10 ` [PATCH RFC 02/13] x86/mm: move MEM_LOG to asm-x86/mm.h Wei Liu
2017-03-28 21:14   ` Andrew Cooper
2017-03-29 10:50     ` Wei Liu
2017-03-27  9:10 ` [PATCH RFC 03/13] x86/mm: export vcpumask_to_pcpumask Wei Liu
2017-03-29 10:15   ` Andrew Cooper
2017-03-29 10:49     ` Wei Liu
2017-03-27  9:10 ` [PATCH RFC 04/13] x86/mm: carve out create_grant_pv_mapping Wei Liu
2017-03-29 10:27   ` Andrew Cooper
2017-03-29 10:45     ` Jan Beulich
2017-03-29 10:49       ` Andrew Cooper
2017-03-29 11:02         ` Wei Liu [this message]
2017-04-03  8:40     ` Wei Liu
2017-04-03 14:05       ` Andrew Cooper
2017-03-27  9:10 ` [PATCH RFC 05/13] x86/mm: carve out replace_grant_pv_mapping Wei Liu
2017-03-27  9:10 ` [PATCH RFC 06/13] x86/mm: extract page table masks to mm.h Wei Liu
2017-03-27  9:10 ` [PATCH RFC 07/13] x86/mm: extract PAGE_CACHE_ATTRS " Wei Liu
2017-03-27  9:10 ` [PATCH RFC 08/13] x86/mm: extract adjust_guest_l*e macros " Wei Liu
2017-03-27  9:10 ` [PATCH RFC 09/13] x86/mm: export a bunch of {get, put}_page functions Wei Liu
2017-03-27  9:10 ` [PATCH RFC 10/13] x86/mm: export invalidate_shadow_ldt Wei Liu
2017-03-27  9:10 ` [PATCH RFC 11/13] x86/mm: export create_pae_xen_mappings Wei Liu
2017-03-27  9:10 ` [PATCH RFC 12/13] x86/mm: split PV MMU code to pv/mm.c Wei Liu
2017-03-27  9:10 ` [PATCH RFC 13/13] x86/mm: split HVM grant table code to hvm/mm.c Wei Liu

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=20170329110258.4ke3jim3xef5va6t@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@eu.citrix.com \
    --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 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.