Re: Issues regarding "mem_access: Add helper API to setup ring and enable mem_access"

From: "Jan Beulich" <JBeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Campbell <Ian.Campbell@citrix.com>
Cc: Tamas Lengyel <tamas.lengyel@zentific.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Aravindh Puthiyaparambil <aravindp@cisco.com>
Subject: Re: Issues regarding "mem_access: Add helper API to setup ring and enable mem_access"
Date: Mon, 30 Jun 2014 15:12:15 +0100	[thread overview]
Message-ID: <53B18C5F020000780001E96B@mail.emea.novell.com> (raw)
In-Reply-To: <53B161DD.1010809@citrix.com>

>>> On 30.06.14 at 15:10, <andrew.cooper3@citrix.com> wrote:
> On 30/06/14 14:09, Ian Campbell wrote:
>> On Mon, 2014-06-30 at 14:07 +0100, Andrew Cooper wrote:
>>> On 30/06/14 13:44, Ian Campbell wrote:
>>>> On Mon, 2014-06-30 at 13:42 +0100, Ian Jackson wrote:
>>>>> Tamas Lengyel writes ("Re: [Xen-devel] Issues regarding "mem_access: Add 
> helper API to setup ring and enable mem_access""):
>>>>>>     > Now with this function being reintroduced, it becomes more complicated
>>>>>>     > to determine which version of the mem_access API does Xen actually
>>>>>>     > provide. A #define indicating mem_access API version would nicely
>>>>>>     > overcome this issue, or  naming xc_mem_event_enable something else.
>>>>>>
>>>>>>     Doesn't configure support checking for functions with a given prototype?
>>>>>>
>>>>>> It does but in a very hacky way, essentially trying to compile code where 
> the
>>>>>> function is being called with different prototypes. We can work around it 
> but a
>>>>>> clean solution would be preferred at some point.
>>>>> I agree with your criticism, TBH.  Aravindh/Ian, can we rename this
>>>>> function ?
>>>> I have no objection to some other name.
>>>>
>>>>>> This is now a rather opaque behavior of libxc. As it is not merged
>>>>>> into master I guess I will just submit a patch for it..
>>>>> Yes.  I think this would be the right approach to addressing both of
>>>>> these problems.  (Please send two patches, one for each.)
>>>>>
>>>>> Thanks,
>>>>> Ian.
>>> There is a bug in Xen.  domctl pause and unpause hypercalls are not
>>> properly refcounted.  Patch on its way.
>> I had convinced myself by reading that they were, but Tamas'
>> experimental evidence obviously counters that ;-)
> 
> The "d->is_paused_by_controller" is a boolean, not an atomic count.
> 
> The second pause doesn't add an extra pause ref to the domain, and the
> first unpause resumes the domain.

Which, as you see, is (in the hypervisor) intended behavior. If the
tool stack wants this to be ref-counted, it needs to do so by itself.

Jan