Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751657AbdLKV7x (ORCPT ); Mon, 11 Dec 2017 16:59:53 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45982 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751234AbdLKV7w (ORCPT ); Mon, 11 Dec 2017 16:59:52 -0500 Subject: Re: [RFC PATCH v2 1/2] xen/pvh: Add memory map pointer to hvm_start_info struct To: Jan Beulich , Maran Wilson Cc: andrew.cooper3@citrix.com, roger.pau@citrix.com, hch@infradead.org, x86@kernel.org, tglx@linutronix.de, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com, mingo@redhat.com, rkrcmar@redhat.com, Juergen Gross , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com References: <1512686715-11488-1-git-send-email-maran.wilson@oracle.com> <1512686715-11488-2-git-send-email-maran.wilson@oracle.com> <5A2A60130200007800195D10@prv-mh.provo.novell.com> From: Paolo Bonzini Message-ID: <94195d5b-fb04-0e27-4fd5-ab3c13b58d07@redhat.com> Date: Mon, 11 Dec 2017 22:59:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5A2A60130200007800195D10@prv-mh.provo.novell.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 11 Dec 2017 21:59:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1079 Lines: 25 On 08/12/2017 09:49, Jan Beulich wrote: >> + * The layout of each entry in the memory map table is as follows and no >> + * padding is used between entries in the array: >> + * >> + * 0 +----------------+ >> + * | addr | Base address >> + * 8 +----------------+ >> + * | size | Size of mapping >> + * 16 +----------------+ >> + * | type | E820_TYPE_xxx >> + * 20 +----------------| > I'm not convinced of re-using E820 types here. I can see that this > might ease the consumption in Linux, but I don't think there should > be any connection to x86 aspects here - the data being supplied is > x86-agnostic, and Linux'es placement of the header is also making > no connection to x86 (oddly enough, the current placement in the > Xen tree does, for a reason which escapes me). FWIW, e820 types are now part of the ACPI standard. So using them is not necessarily related to x86, and reasonably x86-agnostic. Paolo > I could also imagine reasons to add new types without them being > sanctioned by whoever maintains E820 type assignments.