[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 06/10] x86/mem-sharing: copy GADDR based shared guest areas
- To: Tamas K Lengyel <tamas@xxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 25 Oct 2022 08:18:26 +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=gFIPPrLjiVLFR4k5kNiKuRCDW0ZWacj8mAmtecTVxgo=; b=GtWuPJBqATYdRbYBqyijz/F5dyl0kK6BZ35lTLQ51ieGHfecgse08pq6+YdDlbBkFKpqheTBBbBdbM1l7t7qELws9o9e3g1YigwOaCkjnaFVhPiH9jyor0BwdOqJouy3aPHfu97ywJMIn9rNQqRLCkIkwr4tSTuZJZCRHf9DvFRGUwkJd1g8TkU1kvUOC4NO+Ne0bNsXFLVksjSqC+I9HwoS5cEIVhLOq7dBJJKQ/EIvdBiUpgaqPQiXjFfTflb6QtOCledAO/LuKExbfbSai7jUkcw2BSpLEVBcRFtID+TXz1VmyczX/fgWy64gUkYfBIcfnaszF5fzkJneDMPwxQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XtM3vD01AT7swj+zuesGnMxf+4HWB0s5DrJwAOnOGcU3/Jh/t6pmzAUqpMFDvx3pXmLYvsQNycFfJlIcPoz6QFDyIjuzuhtnvArOumq46qywDIn2AKmu6reftSH4GVXBW0eJMagG/4xvy4Cc4HrA2QoJk8UGPHTspp2vg4p7Z6tTICcMYjxczDey53BU/ww4BVCpbuB65PD74v12x0cT+PI5G7AuuV8vCtdXer3zYbt3oLsHwpfgFTyVz7LORrvSk8ZIDj8+N3kmpqYk6QZLegFbjwUxoWbPWwrY4p/mRbIY8D8BhyTmm17y8Wdrpp15PNZuVwXeSdSOnX5UMESjQw==
- 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>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
- Delivery-date: Tue, 25 Oct 2022 06:18:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 25.10.2022 01:04, Tamas K Lengyel wrote:
>> @@ -1987,7 +2056,10 @@ int mem_sharing_fork_reset(struct domain
>>
>> state:
>> if ( reset_state )
>> + {
>> rc = copy_settings(d, pd);
>> + /* TBD: What to do here with -ERESTART? */
>
> Generally speaking the fork reset operation does not support "restarting".
> While in the memory op path the error can be propagated back to the
> toolstack and have it re-issue it, on the monitor reply path that's not
> possible. But the important question is where does the -ERESTART come
> from?
>From map_guest_area() when d's hypercall deadlock mutex is busy. I
guess d is fully paused here, but checking for that to avoid the vCPU
pausing in map_guest_area() would end up fragile, I'm afraid.
Speaking of which - for the use of map_guest_area() here I guess it's
wrong for the function to have a local variable named "currd". I didn't
have this use here in mind when writing that function ...
> What I think would happen here though is that -ERESTART may happen
> during the initial fork op and that can fail, but if it succeeded, then
> during reset it can't happen since everything would be already allocated
> and mapped, the only thing during reset that would be done is the page
> copying.
As per above I don't think there's any dependency on initial fork vs reset
here.
Jan
|
