[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 07/10] domain: map/unmap GADDR based shared guest areas
- To: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 23 Jan 2023 09:29:46 +0100
- 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=DuRlfe95W/9eOqK3eeexAn5DajWVjHXYSptDvHAEZTY=; b=Aow2jM33m4QwRtF1ylk9skltAtRrqsP7+D9QHk5x0PFKw759easxb1Fzu6bVx/0elWowyOI1JXTcTZ+fLTGEwCqG05p3wtslS+89pqWigf3M9NjV4TlF/P6sGCetfKyvFzg3ryv/lBlj4YALFePxtvvc6hBHOSVh7LUelb4jUHu5/GUUMRFBFY5YaYo+VtomrjHm/MAuZaan3GT3ApM3IyfPAmdpdOO+uAy6ZC9FOhbZfvsylBFId/ZzltQDakKt69suWIBQwEiXpk6AtPtuJbIF9pgIeNI3kY4dn1wczmkCFPTwdJP5svrQaw+kd75Q5XtyVEohyUZfdVFVL8X1QQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SK4IzHarI7KXM+0jG7eMfW/0GurjZJBfAP2oSlJEZyN+RCaOzrIpEjZzLUp6bqRiMXOFvxce0I8Osuq0KW7Z1p1YPAit6az3iIF7PWTSAF5SiWHUbT6N1xS8yBUbYRzY7/ljGuHdu1tw6LZYtTMl5EYH+FsX9RXoF9Kj34HWRkVh/6iddJd2eKgyO8d5VRTYtor0sYUURt7DHGAzzw1f4IdRHWciKhfC4Cfx7iuEUhQowUtK8GUc91jV1X7Et+4BsIOfjYgESh8QG0GwiKlHUnY2cfKMn2J1S0vQUAOVj7ZbtI0llWns3YH29NU+M9W/HVq10Pcey974Jf20WW0hdQ==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monne <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 23 Jan 2023 08:30:04 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 20.01.2023 19:15, Andrew Cooper wrote:
> On 18/01/2023 9:55 am, Jan Beulich wrote:
>> On 17.01.2023 23:04, Andrew Cooper wrote:
>>> On 19/10/2022 8:43 am, 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, flesh out the map/unmap functions.
>>>>
>>>> Noteworthy differences from map_vcpu_info():
>>>> - areas can be registered more than once (and de-registered),
>>> When register by GFN is available, there is never a good reason to the
>>> same area twice.
>> Why not? Why shouldn't different entities be permitted to register their
>> areas, one after the other? This at the very least requires a way to
>> de-register.
>
> Because it's useless and extra complexity.
As to this: Looking at the code I think that I would actually add
complexity (just a little - an extra check) to prevent re-registration.
Things come out more naturally, from what I can tell, by allowing it.
This can also be seen in "common: convert vCPU info area registration"
where I'm actually adding such a (conditional) check to maintain the
"no re-registration" property of the sub-op there. Granted there can be
an argument towards making that check unconditional then ...
Jan
|
