[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 1/8] domain: GADDR based shared guest area registration alternative - teardown


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 27 Sep 2023 13:44:02 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=YRJGX9XiEtrrk9vEYMkVT1aeuKnmYmmlMELE39CGDEU=; b=n1M2CE19x0ZRWv0KpPypUkt+1vN642jR63LEUBuWFCwptFsaL1V0jsWwaFjTPkPWjpEFNyCA13sC4lZUeH+5XsINoignHRhMvsGVqa0sicYuvDKmvAcv7ndYNZi8bFhojhuA98pABz6hJVVpr6ggXRT2FB9XlaqEdBewEqPDFG89jsJyObOkgVUjhvQIwGTUaCRchtyNASWTJKahxDkChw8QB+rIihRnW2Mn2dh0DNmfy3v4WEmLX9jPGbNicZj5/GTEblzxuIm+gwb9k7LOA9MsbPPtrbQYUYxMegXcIQmPASisaf3tdx78DTorz7YQSdiVXhlR+169U354qEDRvA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z3cVZdR+ruLXlyEdknlEUXuI8AbuuY8Zn+aROrsayjWPrbxAPSuHDrCxThQyXPJllUm/33nHmQ6IdCsQnyV8FuazQHihP6FNEyrnuMs7Z5yX49KfRdPxikGiroohuu4m4yhRYelBp3QwiE8Y56ywibm7jInn48akNbwBwnempskx1GH3sK2SH2Kr63g0gwnAim5otswUaEfvLIG6diULwjWCReL7OzuZzIcmN5tqkegK4Rk9InkKB/n5eI+sNX6ktizO9Iw6s3QIbbqw6QZJIrpfSZZ9GP+gQT93dvkyr4hzhZK87tUyuMpx4HJI8jHPAbF1Iogp+1AjMgaazhjcbw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 27 Sep 2023 11:44:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.09.2023 12:50, Roger Pau Monné wrote:
> On Wed, Sep 27, 2023 at 12:46:07PM +0200, Jan Beulich wrote:
>> On 27.09.2023 12:42, Roger Pau Monné wrote:
>>> On Wed, Sep 27, 2023 at 11:55:19AM +0200, Jan Beulich wrote:
>>>> On 27.09.2023 10:51, Roger Pau Monné wrote:
>>>>> On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
>>>>>> +{
>>>>>> +    struct domain *d = v->domain;
>>>>>> +
>>>>>> +    if ( v != current )
>>>>>> +        ASSERT(atomic_read(&v->pause_count) | 
>>>>>> atomic_read(&d->pause_count));
>>>>>
>>>>> Isn't this racy?
>>>>
>>>> It is, yes.
>>>>
>>>>>  What guarantees that the vcpu won't be kicked just
>>>>> after the check has been performed?
>>>>
>>>> Nothing. This check isn't any better than assertions towards an ordinary
>>>> spinlock being held. I assume you realize that we've got a number of such
>>>> assertions elsewhere already.
>>>
>>> Right, but different from spinlock assertions, the code here could be
>>> made safe just by pausing the vCPU?
>>
>> That's what the assertion is checking (see also the comment ahead of the
>> function). It's just that the assertions cannot be made more strict, at
>> least from all I can tell.
> 
> But the assertion might no longer be true by the time the code
> afterwards is executed.  Why not wrap the code in a pair of
> vcpu_{,un}pause() calls?

Because it's not quite as simple (if I was to do so, I'd want to do it
correctly, and not just give the impression of universal usability). See
how map_guest_area() involves hypercall_deadlock_mutex. Hence I continue
to think it is okay the way I have it, with all callers satisfying the
requirement (afaict).

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.