[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 1/9] x86/shadow: replace sh_reset_l3_up_pointers()
- To: George Dunlap <george.dunlap@xxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 23 Jan 2023 17:14:12 +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=aLhiWSO1/sbXhCBK6AdHYeMWiQDCkuoYjDwExbfLF0A=; b=mM3kBQmxFbDHCWIRie1tN+H87xX8OydWFZVu7/LHyumLhDTMEqF6ELdCZG7WbqNWZ7UC7dXjVP67/7ayKGpPMwf2LDeHxTkjQ/3KXgQAKxgfoP1xoL7jokhK7dteTvHTm+ydi9iQKsxfkBGaMCW6s842E9oEr0vCSUFteqpAg4v987nM49FDYMtcHQyVt3KSP13VGKyRkE+Cl1ZaOC5YJQqK8Ez4mB45dP4oJpe+XvHerhpoy5s8txpAP2sLRjKm/dZpReokBEHg4Xx3OiQ8AZ/jz6eBxd5hB8qPzodZSadtiPuO5laxE2B32ybj0nNvPtHlpcCP5EytBLFaB+UyjA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VVGl0n4SGDbF+G3kvovPgaWobC6Wnf1zq4yRFn3JaNRocakIu4gSyxP2tq2br2ymM+lmZV7Oil4Pxh6VtDickLt5GUZNaerNfqqyY6Non6PJ/AiJIetA0nVunHC18V1WJvbULXlFwGCR1nl2bHmX5zDyMA1WpdeZyq95QObhFGc7OKqpFnp/8LHw5mSsgKxhlh0gS2usKzVBS/xaEW/8XfdMNbgpQHyvHqtDi9IwMFiBnaqqxmyvKsPAjgSfNkv9239WGRHSK23P7YFTVIUn7osucMBoZMiKsFN3BVAQVcbTcsVwY7Zob847ww9IxewhJOWaEILEU7w//hkRo+xZ/w==
- 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>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>
- Delivery-date: Mon, 23 Jan 2023 16:14:26 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 23.01.2023 16:20, George Dunlap wrote:
> Re the original question: I've stared at the code for a bit now, and I
> can't see anything obviously wrong or dangerous about it.
>
> But it does make me ask, why do we need the "unpinning_l3" pseudo-argument
> at all? Is there any reason not to unconditionally zero out sp->up when we
> find a head_type of SH_type_l3_64_shadow? As far as I can tell, sp->list
> doesn't require any special state. Why do we make the effort to leave it
> alone when we're not unpinning all l3s?
This was an attempt to retain original behavior as much as possible, but I'm
afraid that, ...
> In fact, is there a way to unpin an l3 shadow *other* than when we're
> unpinning all l3's?
... since the answer here is of course "yes", ...
> If so, then this patch, as written, is broken -- the
> original code clears the up-pointer for *all* L3_64 shadows, regardless of
> whether they're on the pinned list; the new patch will only clear the ones
> on the pinned list. But unconditionally clearing sp->up could actually fix
> that.
... you're right, and I failed (went too far) with that attempt. Plus it'll
naturally resolve the parameter-vs-state aspect.
Jan
|
