[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 11:55:19 +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=GZK5W22VBLkSZiXmKBK83nYJ6ueN5kvZsNOsOvMCTUM=; b=Dt/QMsw8v0OyY3y7iu3B5Q8HIxbylLhgIszm5KZGhg7IAhe/Ppb8WheW2nV1EVQ32ITdjWqCyStDGkwEPxh8gvmitRuxsWKAxP+TWsAcLxjTowXyksFtVohg85bhmPtEv4/HNFkZNrg2x/kuZVDgNrExgBswYkQD/GHwMIMGEcIttsc1RmHpLF/HcnxqOmvhZG8HhBkCMlA5YFPtuNN5q/jc5YJH7HcyGB2F61cplJCRk+aA69RkoUvPyvk802wE1DLq84j3f6i/0vbvKLohPOfhHsWW0AJXd/KYJFmIYJfxsNWBtdbrem8iyzkOfrssIsYQFD+NVxmRWmT2ntH2LA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HUrY8TbvxWNnxbThYNTwylmPDODOfvo6rA4LDqZe4iOsU7KRVV+RRYFvCjrhDq2AEokrqiX78qoHq/chmdMB9Ie5RqhNmQBjuNjm2edmCNLLWJwIOWIOcDsqkvCPV5xP3u3g2CihMds8iVHezuagG0o8CJKXcH2/UcpQprQBGBbRwo5LoIwvEXQGfyYAGEEmHtAkzhD1GaPSeEjlcoYNr2VAAzfWsw3XD+DeZ2eudbwr4af0uTkQ0k9LbQumhkBFQ4nc0ns7tF9rjxj6pjGw+jw+XzY/yU4PPwoWrr5k1KHyOIZSLQWH+B+6VLAoaqBPyGFcGW5n4KmmU+STt4EdNg==
  • 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 09:55:31 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 27.09.2023 10:51, Roger Pau Monné wrote:
> On Wed, May 03, 2023 at 05:54:47PM +0200, Jan Beulich wrote:
>> In preparation of the introduction of new vCPU operations allowing to
>> register the respective areas (one of the two is x86-specific) by
>> guest-physical address, add the necessary domain cleanup hooks.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> Reviewed-by: Julien Grall <jgrall@xxxxxxxxxx>
>> ---
>> RFC: Zapping the areas in pv_shim_shutdown() may not be strictly
>>      necessary: Aiui unmap_vcpu_info() is called only because the vCPU
>>      info area cannot be re-registered. Beyond that I guess the
>>      assumption is that the areas would only be re-registered as they
>>      were before. If that's not the case I wonder whether the guest
>>      handles for both areas shouldn't also be zapped.
> 
> IIRC the reason was to unset v->vcpu_info_mfn so that it could be set
> again on resume from suspension, or else the hypercall will return an
> error.

Right, that's the re-registration aspect mentioned.

> I guess we should also zap the runstate handlers, or else we might
> corrupt guest state.

So you think the guest might re-register a different area post resume?
I can certainly add another patch to zap the handles; I don't think it
should be done right here, not the least because if we see room for
such behavior, that change may even want backporting.

>> @@ -1568,6 +1572,19 @@ void unmap_vcpu_info(struct vcpu *v)
>>      put_page_and_type(mfn_to_page(mfn));
>>  }
>>  
>> +/*
>> + * This is only intended to be used for domain cleanup (or more generally 
>> only
>> + * with at least the respective vCPU, if it's not the current one, reliably
>> + * paused).
>> + */
>> +void unmap_guest_area(struct vcpu *v, struct guest_area *area)
> 
> vcpu param could be const given the current code, but I assume this
> will be changed by future patches.  Same could be said about
> guest_area but I'm confident that will change.

True for both.

>> +{
>> +    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.

Jan



 


Rackspace

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