xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: 'Andrii Anisov' <andrii.anisov@gmail.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
	"sstabellini@kernel.org" <sstabellini@kernel.org>,
	"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tim (Xen.org)" <tim@xen.org>,
	George Dunlap <George.Dunlap@citrix.com>,
	"jbeulich@suse.com" <jbeulich@suse.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [RFC 2/6] rangeset_destroy() refactoring
Date: Thu, 16 Feb 2017 14:29:02 +0000	[thread overview]
Message-ID: <cb7d000bdb114b73ac7eea05450417ac@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <CAC1WxdhW9ReXAZHGjGHcGz_xJdBmRW0GC4kKDh4rP2vk_+38fg@mail.gmail.com>

> -----Original Message-----
> From: Andrii Anisov [mailto:andrii.anisov@gmail.com]
> Sent: 16 February 2017 14:26
> To: Paul Durrant <Paul.Durrant@citrix.com>
> Cc: xen-devel@lists.xenproject.org; andrii_anisov@epam.com; Andrew
> Cooper <Andrew.Cooper3@citrix.com>; George Dunlap
> <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>;
> jbeulich@suse.com; konrad.wilk@oracle.com; sstabellini@kernel.org; Tim
> (Xen.org) <tim@xen.org>; Wei Liu <wei.liu2@citrix.com>
> Subject: Re: [RFC 2/6] rangeset_destroy() refactoring
> 
> Dear Paul,
> 
> >> It is still left a rangesets list functionality: rangeset_destroy()
> >> will remove itself from a list. If a spinlock is provided it will be
> >> held for list deletion operation. This would be reconsidered further.
> >>
> >
> > Maybe use the same scheme in patch #1 then and pass the lock, as well as
> the list_head, into rangeset_new().
> Initialized list head in patch#1 is provided by rangeset to user if
> user needs it to link to some list. So user should do the locking on
> tree insert if it needs. Here rangeset user can not acquire the tree
> head even if it has a rangeset itself, because `struct rangeset` is
> not exposed via header file. So rangeset_destroy() should take care of
> tree head remove and spinlock locking if needed.
> 
> I still have concerns why rangeset list keeping should be inside
> rangeset itself.

What use are rangesets if the implementation doesn't control the list/tree? How on earth would you implement an allocation function otherwise?

  Paul

> 
> Sincerely,
> Andrii Anisov.
> 
> 
> 2017-02-16 14:26 GMT+02:00 Paul Durrant <Paul.Durrant@citrix.com>:
> >> -----Original Message-----
> >> From: Andrii Anisov [mailto:andrii.anisov@gmail.com]
> >> Sent: 16 February 2017 12:03
> >> To: xen-devel@lists.xenproject.org
> >> Cc: andrii_anisov@epam.com; Andrew Cooper
> >> <Andrew.Cooper3@citrix.com>; George Dunlap
> >> <George.Dunlap@citrix.com>; Ian Jackson <Ian.Jackson@citrix.com>;
> >> jbeulich@suse.com; konrad.wilk@oracle.com; Paul Durrant
> >> <Paul.Durrant@citrix.com>; sstabellini@kernel.org; Tim (Xen.org)
> >> <tim@xen.org>; Wei Liu <wei.liu2@citrix.com>
> >> Subject: [RFC 2/6] rangeset_destroy() refactoring
> >>
> >> From: Andrii Anisov <andrii_anisov@epam.com>
> >>
> >> rangeset_destroy is made domain agnostic. The domain specific code
> >> is moved to common/domain.c:domain_rangeset_destroy().
> >>
> >> It is still left a rangesets list functionality: rangeset_destroy()
> >> will remove itself from a list. If a spinlock is provided it will be
> >> held for list deletion operation. This would be reconsidered further.
> >>
> >
> > Maybe use the same scheme in patch #1 then and pass the lock, as well as
> the list_head, into rangeset_new().
> >
> >   Paul
> >
> >> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
> >> ---
> >>  xen/arch/x86/hvm/ioreq.c   |  2 +-
> >>  xen/arch/x86/mm/p2m.c      |  2 +-
> >>  xen/common/domain.c        |  5 +++++
> >>  xen/common/rangeset.c      | 15 ++++++++-------
> >>  xen/include/xen/domain.h   |  3 +++
> >>  xen/include/xen/rangeset.h |  9 ++++++---
> >>  6 files changed, 24 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c
> >> index 6df191d..6ae5921 100644
> >> --- a/xen/arch/x86/hvm/ioreq.c
> >> +++ b/xen/arch/x86/hvm/ioreq.c
> >> @@ -496,7 +496,7 @@ static void
> hvm_ioreq_server_free_rangesets(struct
> >> hvm_ioreq_server *s,
> >>          return;
> >>
> >>      for ( i = 0; i < NR_IO_RANGE_TYPES; i++ )
> >> -        rangeset_destroy(s->range[i]);
> >> +        domain_rangeset_destroy(s->range[i], s->domain);
> >>  }
> >>
> >>  static int hvm_ioreq_server_alloc_rangesets(struct hvm_ioreq_server
> *s,
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 46301ad..d39c093 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -141,7 +141,7 @@ static void p2m_teardown_hostp2m(struct domain
> >> *d)
> >>
> >>      if ( p2m )
> >>      {
> >> -        rangeset_destroy(p2m->logdirty_ranges);
> >> +        domain_rangeset_destroy(p2m->logdirty_ranges, d);
> >>          p2m_free_one(p2m);
> >>          d->arch.p2m = NULL;
> >>      }
> >> diff --git a/xen/common/domain.c b/xen/common/domain.c
> >> index 1b9bc3c..f03a032 100644
> >> --- a/xen/common/domain.c
> >> +++ b/xen/common/domain.c
> >> @@ -1553,6 +1553,11 @@ struct rangeset *domain_rangeset_new(struct
> >> domain *d, char *name,
> >>      return r;
> >>  }
> >>
> >> +void domain_rangeset_destroy(struct domain *d,
> >> +    struct rangeset *r)
> >> +{
> >> +    rangeset_destroy(r, &d->rangesets_lock);
> >> +}
> >>
> >>
> >>  /*
> >> diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
> >> index 478d232..1172950 100644
> >> --- a/xen/common/rangeset.c
> >> +++ b/xen/common/rangeset.c
> >> @@ -354,19 +354,20 @@ struct rangeset *rangeset_new(char *name,
> >> unsigned int flags,
> >>  }
> >>
> >>  void rangeset_destroy(
> >> -    struct rangeset *r)
> >> +    struct rangeset *r, spinlock_t *lock)
> >>  {
> >>      struct range *x;
> >>
> >>      if ( r == NULL )
> >>          return;
> >>
> >> -    if ( r->domain != NULL )
> >> -    {
> >> -        spin_lock(&r->domain->rangesets_lock);
> >> -        list_del(&r->rangeset_list);
> >> -        spin_unlock(&r->domain->rangesets_lock);
> >> -    }
> >> +    if ( lock )
> >> +        spin_lock(lock);
> >> +
> >> +    list_del(&r->rangeset_list);
> >> +
> >> +    if ( lock )
> >> +        spin_unlock(lock);
> >>
> >>      while ( (x = first_range(r)) != NULL )
> >>          destroy_range(r, x);
> >> diff --git a/xen/include/xen/domain.h b/xen/include/xen/domain.h
> >> index cd62e6e..3d9c652 100644
> >> --- a/xen/include/xen/domain.h
> >> +++ b/xen/include/xen/domain.h
> >> @@ -111,4 +111,7 @@ void vnuma_destroy(struct vnuma_info *vnuma);
> >>  struct rangeset *domain_rangeset_new(struct domain *d, char *name,
> >>                                       unsigned int flags);
> >>
> >> +void domain_rangeset_destroy(struct domain *d,
> >> +    struct rangeset *r);
> >> +
> >>  #endif /* __XEN_DOMAIN_H__ */
> >> diff --git a/xen/include/xen/rangeset.h b/xen/include/xen/rangeset.h
> >> index 395ba62..deed54d 100644
> >> --- a/xen/include/xen/rangeset.h
> >> +++ b/xen/include/xen/rangeset.h
> >> @@ -14,6 +14,7 @@
> >>
> >>  struct domain;
> >>  struct list_head;
> >> +struct spinlock;
> >>  struct rangeset;
> >>
> >>  /*
> >> @@ -37,11 +38,13 @@ struct rangeset *rangeset_new(char *name,
> >> unsigned int flags,
> >>                                struct list_head **head);
> >>
> >>  /*
> >> - * Destroy a rangeset. It is invalid to perform any operation on a rangeset
> @r
> >> + * Destroy a rangeset. Rangeset will take an action to remove itself from
> a
> >> + * list. If a spinlock is provided it will be held during list deletion
> >> + * operation.
> >> + * It is invalid to perform any operation on a rangeset @r
> >>   * after calling rangeset_destroy(r).
> >>   */
> >> -void rangeset_destroy(
> >> -    struct rangeset *r);
> >> +void rangeset_destroy(struct rangeset *r, struct spinlock *lock);
> >>
> >>  /*
> >>   * Set a limit on the number of ranges that may exist in set @r.
> >> --
> >> 2.7.4
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-02-16 14:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 12:03 [RFC 0/6] Rangeset generalisation Andrii Anisov
2017-02-16 12:03 ` [RFC 1/6] rangeset_new() refactoring Andrii Anisov
2017-02-16 12:14   ` Paul Durrant
2017-02-16 13:15     ` Andrii Anisov
2017-02-16 12:03 ` [RFC 2/6] rangeset_destroy() refactoring Andrii Anisov
2017-02-16 12:26   ` Paul Durrant
2017-02-16 14:26     ` Andrii Anisov
2017-02-16 14:29       ` Paul Durrant [this message]
2017-02-16 16:22         ` Andrii Anisov
2017-02-16 16:37           ` Paul Durrant
2017-02-16 12:03 ` [RFC 3/6] Drop rangeset_domain_initialise() Andrii Anisov
2017-02-16 12:03 ` [RFC 4/6] rangeset_domain_destroy() refactoring Andrii Anisov
2017-02-16 12:03 ` [RFC 5/6] rangeset_domain_printk() refactoring Andrii Anisov
2017-02-16 12:03 ` [RFC 6/6] Drop domain remains from rangeset Andrii Anisov
2017-02-16 12:29 ` [RFC 0/6] Rangeset generalisation Paul Durrant
2017-02-16 12:45   ` Andrii Anisov
2017-02-16 12:50     ` Paul Durrant
2017-02-16 13:07       ` Andrii Anisov
2017-02-16 13:24       ` Andrii Anisov
2017-02-16 14:02         ` Paul Durrant
2017-02-16 14:28           ` Andrii Anisov
2017-02-16 13:25     ` Jan Beulich
2017-02-16 13:37       ` Andrii Anisov
2017-02-16 13:42       ` Andrii Anisov
2017-02-16 14:30         ` Jan Beulich
2017-02-16 17:39           ` George Dunlap

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=cb7d000bdb114b73ac7eea05450417ac@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Andrew.Cooper3@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=andrii.anisov@gmail.com \
    --cc=andrii_anisov@epam.com \
    --cc=jbeulich@suse.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --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).