[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH v2 0/2] xen/x86: alternative fix for XSA-369


  • To: <linux-kernel@xxxxxxxxxxxxxxx>
  • From: Roger Pau Monne <roger.pau@xxxxxxxxxx>
  • Date: Wed, 24 Mar 2021 13:24:22 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=C3dYednsfe+JWK3g9vkdloy+BrfrO73P+Mzf/FA4yCA=; b=g5OgIQBC+8sJqBpfDpYcjs7iKkN6f9bgw8YnQH1jc7W0tFxJcufFcELaHnTAdLzn6dxWQ5khOuYgpE5toNYZoJQhPCv4i9Pu60wa/HkxtlMzCsZ2G4SOVineDlpWPW7SNHuH9z7v/ZOmERrsoZPgjBE05VfqTvYGxUJ0r7zmu0ThE7KWliofs6wfklU6L6NBmqlOmdO+cDvo9tZbbi1ESYMTnZMTpdf8dGDIyhKQeJm7ZzgnqJMeAq89A+zNDsBPUXhQVHmtscOR2cnvLLoRYyC8+niR6NNUNwbejOyZdtAXDALUOM6YFAGQFW5PTl/b5DidVy7A1MWdsd+dd8+sPQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g/aEh7ZQUFm3Sxn/iafliyzsSfelSJhIkGCnC0Ykq7rxvm9lBB6c2PhtYBv6cUPLMpMArmScNSnMGVka1CShoK8i1vBI9bdO5Zhf7OC7tl1uwq++N17PAjsrMY5QTk0cdJyIa6hrlQQIDwx7iV9knfTcvlG4ExNiQj844OlhgPahYAbGLLWuP+Dzpg3qh9CrCgWCs9DbVlbpEZdz+0CIVLjkZbm5i+2QoSEDAJAa26ucmL+r9dfUKIt+Z2olGKaxbZBDxyg2h/M3MeIsdmR9uSITF/zO1E6r+vQKNI3c5nF+Jrhih3Nw4y98s9BewyITVsMDG/oOHohHMeLNX0En4g==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Roger Pau Monne <roger.pau@xxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 24 Mar 2021 12:24:51 +0000
  • Ironport-hdrordr: A9a23:JBBtFaNY5Xw1p8BcTyXw55DYdL4zR+YMi2QD/3taDTRIb82VkN 2vlvwH1RnyzA0cQm0khMroAsa9aFvm39pQ7ZMKNbmvGDPntmyhMZ144eLZrwHIMxbVstRQ3a IIScVDIfXtEFl3itv76gGkE9AmhOKK6rysmP229RZQZCtBApsQiztRIACdD0FwWU16HpI/Dp WR/Y5qoDCndHQRYK2AdwM4dsLEoMDGk4+jXA4eC3ccmXKzpB6LyJq/KRiX2R8CTyhCqI1NzU HpmxH0j5/T1c2T5QTb0wbonvZrsf/A7vcGO8CWkMgSLVzX+3iVTaBsQaeLsjxwgMzH0idSrP D2rx0tP9t+5hrqFwnfy3uduHiR7B8U52L/0ljduHP/oKXCNU0HIvBcjoFUeAax0TtGgPhA1s twrgeknqsSJxbBkCPh3sPPRhFnm2GlyEBS7dI7vjhxV5ATZ6RWqpFa1ERJEI0YFCa/04w/Fv JyZfusrsp+QBe/VTT0r2NvyNujUjAaGQqHeFELvoiw3yJNlH504kMEzKUk7zo93aN4b6MBy/ XPM6xumr0LZNQRd7hBCOAIRtbyInDRQDrXWVjib2jPJeUiATbgupT36LI66KWBY5oT1qY/n5 zHTRdxqXMyQUTzEseDtac7vSzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+OuPMaLsrHW+ uiGZ5fDvP5RFGeWbph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6j6fZ/oVfnQOAdhflm6Lm oIXTD1KskFxFusQGXEjB/YXG6oXkT++Jl3AZXL5uR78vlOCqR89iwuzXip7MCCLjNP9oYsel FlHb/hmqSn4U674HjP9GcsHhZGFE5a7PHBXhpx1EM3GnKxVYxGl8SUeGhU0nfCDAR4VdnqHA lWoEky37m2IZyWzSULEMmmLWqesnsWqBuxPtYhs5zGwf2gVoIzD54gVqA0Px7MDQZJlQFjr3 oGVBUJXXbFFjTlibysibsdAO23Tag4vC6bZepv7V7Pv0SVos8iAl8WRSSnX8KsjQEyfDZMnV Fq/6gDgL2PpCa3JQIE8ZUFGWwJTF7SLKNNDQyDaokRoLztdQ1qZUqhhDCRiXgICyPX3nRXol akATyfePnNDFYYh2tR1bzy9khoMk+HeVhrV3x8uYphNGjPt3ppy9WXbq6r32b5UCpH/sgtdB X+JRcCKAJnwN66kCOPkDGZDHM829EAOPfeALlLScCm5lqdbKmz0YcIEP9f8Mw7aJTAsuoXXf mefAHQBjXiEO8t0xGUoHFgGCQckghXrdrYnDneqE6/1zoDJNCXBnJMbbQSOcud4GjpXOzg6u QOsfsF+c+LdlzsYduHw5zNZzFNKhnvsXe7JttY2qx8jOYXjv9PBJHVXjvD6WFf0Dg/JMnykl kCQK4T2sG1BqZfO+gbeydU5TMS5ayyBXpulgz9Gekle14xy1fdItOS+rLNwIBfSnGplU/VOV OF9Tda8OqAdyyf1aQCA6Z1BWhNckAz5DBD++yFHregQzmCRqVm/FCgNGW6f6IYYK+ZGa8Iph I/2uq2pYasBl3F8TGVmyB6LKJI+3umRs33IDvkI580z/WKfXKWgqWr58aviizQUjXTUTVeub F4
  • Ironport-sdr: MzSfs2m/4tf2O3g0SroNgQPrHzgt7tt4GMB8NmFqOWy1i6xUhTobNa7tFYT7wx4WJDNQYl9hUl bSJqXOIrnlsHAWUk9XReXOWgO/R47kMt7TH7V6E3Iz2fE4krYnsv8mZ/Rb0dguipURXYK62i/Y 7IF/Bpe9a/wsvYd3BWcmY5WPPadnzgY1VgQjIh2YKN/nHaAUfPzTi1UldFKemdJ7+hCTTLMaU1 0WaaK1mW3OvQqdX3YgTJnqHKniNmjhl+nXYfbth12JoPTQsdpwMz9ah6dV8vZPK3VgURmkJ6hG +RY=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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(-)

-- 
2.30.1




 


Rackspace

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