[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/2] xen/x86: alternative fix for XSA-369
- To: Roger Pau Monne <roger.pau@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
- Date: Wed, 24 Mar 2021 19:09:51 -0400
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.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-SenderADCheck; bh=Io2lAihE3mQOuQ7rki9suM4viVm/JFb91YPnIilRCI8=; b=JRLDFR2UguDD5VfbX/PBw4YtNpt3x/EUyByI3GNGVJQGiwlOCVIUfBsvoAWntb1XvreE+1wlAaIwfAM/5gYEBod4COFJ45AiUbGTdCuggqZbS8OsrJ09AUy2KKAIk2DJ535FAvFBGoLKwTUnDzY+Zd7tfBjKgIO3DhDwNvqGhrEpHea6OMAZxJusxYOVfRoV8hR1mR+5b2I3N5v2fXuRwwxO3Q81Fwj77XVZWFcOkbB66ykzNg5NUNYmgZx+/ufixRDVgH9pxJzVv+W8+arD5nW61kG4HBs5uyWAKYAuCUyGsTFEf+SWdQbt/WJ+r6h/Qo8qOgAaKQW1se9/kBPlKg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BcTG725W8jhbRDeKi+s7n2vqKNSEmb1l3VYfTnaKMr9BksxkE9jxabsdo9tfLeFUYrsqGDIGE8YXnRT44jcL8/xJvF9RNWKGMbcEkQ7Vpe8oXGm33oz4xrVee3f/SLJZWPjPCs8UNCWNkF2h8KmMhFaGjh/lZvleI/91xgEBFspvL2JOYQa4e3gwNew60jIhrrjcWsLfmDwanOYdHH/y2iA4L8qt/8xdOhjz4g28AH+Hk7hI0RbMsnpUmMvuJPlJz80D2hLv2FYZZIrh60AZWNEBv1cuvlQsv0J9vrWR0+FW+YfoDQ0ZVC94lHX3TennUIaRMyt24KLvXkANjbIEog==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=oracle.com;
- Cc: Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Wed, 24 Mar 2021 23:10:10 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 3/24/21 8:24 AM, Roger Pau Monne wrote:
> Hello,
>
> This is a proposal for an alternative fix for XSA-369 that instead of
> special casing XEN_UNPOPULATED_ALLOC to size the p2m relies on making
> XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on the generic MEMORY_HOTPLUG
> option rather than XEN_BALLOON_MEMORY_HOTPLUG.
>
> I think this is safer, as we don't want to be special casing any option
> that pulls in generic MEMORY_HOTPLUG without XEN_BALLOON_MEMORY_HOTPLUG.
> Without this we would also need to at least special case ZONE_DEVICE
> which also relies on MEMORY_HOTPLUG, and is what pulls the generic
> MEMORY_HOTPLUG option even when XEN_BALLOON_MEMORY_HOTPLUG is disabled
> with XEN_UNPOPULATED_ALLOC.
>
> Thanks, Roger.
>
> Roger Pau Monne (2):
> xen/x86: make XEN_BALLOON_MEMORY_HOTPLUG_LIMIT depend on
> MEMORY_HOTPLUG
> Revert "xen: fix p2m size in dom0 for disabled memory hotplug case"
>
> arch/x86/include/asm/xen/page.h | 12 ------------
> arch/x86/xen/p2m.c | 7 ++-----
> arch/x86/xen/setup.c | 16 ++++++++++++++--
> drivers/xen/Kconfig | 4 ++--
> 4 files changed, 18 insertions(+), 21 deletions(-)
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
|
