From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andrew Cooper <andrew.cooper3@citrix.com>
Subject: Re: [PATCH v3] xen/common: Properly reference count
 DOMCTL_{, un}pausedomain hypercalls
Date: Wed, 2 Jul 2014 17:10:11 +0100
Message-ID: <53B42EE3.2010308@citrix.com>
References: <1404313416-25825-1-git-send-email-andrew.cooper3@citrix.com>
	<53B44167020000780001FAC7@mail.emea.novell.com>
	<53B4282F.9050105@citrix.com>
	<53B44A21020000780001FB88@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <53B44A21020000780001FB88@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>, Tim Deegan <tim@xen.org>, Ian Jackson <Ian.Jackson@eu.citrix.com>, Ian Campbell <Ian.Campbell@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

On 02/07/14 17:06, Jan Beulich wrote:
>>>> On 02.07.14 at 17:41, <andrew.cooper3@citrix.com> wrote:
>> On 02/07/14 16:29, Jan Beulich wrote:
>>>>>> On 02.07.14 at 17:03, <andrew.cooper3@citrix.com> wrote:
>>>> --- a/xen/include/xen/sched.h
>>>> +++ b/xen/include/xen/sched.h
>>>> @@ -366,7 +366,7 @@ struct domain
>>>>      /* Is this guest dying (i.e., a zombie)? */
>>>>      enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
>>>>      /* Domain is paused by controller software? */
>>>> -    bool_t           is_paused_by_controller;
>>>> +    atomic_t         controller_pause_count;
>>>>      /* Domain's VCPUs are pinned 1:1 to physical CPUs? */
>>>>      bool_t           is_pinned;
>>>>  
>>> Now why did you leave this be an atomic_t, sitting between two
>>> bool_t-s?
>> It is not sitting between two bool_t's.  It is sitting next to an enum
>> which has the same natural width and alignment.
> Oh, right, the first one is being replaced.
>
> But you didn't say why it need to be an atomic_t, while in v1 it was a
> plain scalar.
>
> Jan
>

v1 was a plain scalar because of the spinlock.  v2 was an atomic_t
because of atomic_{inc,dec}_bounded()

But given the hand rolled loops with cmpxchg(), this can indeed be a
plan scalar.

v4 on its way.

~Andrew