From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: open-coded page list manipulation in shadow code Date: Mon, 26 Jan 2015 16:35:04 +0000 Message-ID: <54C67AC802000078000598CE@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YFmd2-0003j6-Jy for xen-devel@lists.xenproject.org; Mon, 26 Jan 2015 16:35:08 +0000 Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: xen-devel List-Id: xen-devel@lists.xenproject.org Tim, in the course of adding >16Tb support to the hypervisor, I ran into issues with you having added several open-coded page list accesses while breaking up non-order-0 allocations there. I looked at that code for quite a while, but wasn't really able to figure how to properly convert these. In particular I'm struggling with the list terminations (would using NULL for PAGE_LIST_NULL be correct when using ordinary struct list_head-s for struct page_info's list member?) and the implications of this comment /* Page lists don't have pointers back to the head structure, so * it's safe to use a head structure on the stack to link the pages * together. */ in shadow_alloc(), but then again I also didn't look very closely at the other places that also fail to compile. To help myself test the new code, I invented a shadow stub which provides just enough functionality to build and not crash with all the other shadow code compiled out. I wonder whether such a build mode might actually be useful for other purposes, and hence whether it might be worthwhile extracting that from the patch into a standalone one. Thanks, Jan