From mboxrd@z Thu Jan  1 00:00:00 1970
From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Subject: Re: [PATCH v2 3/4] sysctl: Add sysctl interface for
 querying PCI topology
Date: Thu, 08 Jan 2015 10:49:50 -0500
Message-ID: <54AEA71E.6090905@oracle.com>
References: <1420510737-22813-1-git-send-email-boris.ostrovsky@oracle.com>
	<1420510737-22813-4-git-send-email-boris.ostrovsky@oracle.com>
	<54AD08AE02000078000522B7@mail.emea.novell.com>
	<54AD48D1.5000904@oracle.com>
	<54AD5C2D02000078000525F0@mail.emea.novell.com>
	<54AD569B.7070307@oracle.com>
	<1420653340.17031.93.camel@Abyss.station>
	<54AE60DD02000078000528CD@mail.emea.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <54AE60DD02000078000528CD@mail.emea.novell.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Jan Beulich <JBeulich@suse.com>, Dario Faggioli <dario.faggioli@citrix.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com, andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org, ufimtseva@gmail.com, keir@xen.org
List-Id: xen-devel@lists.xenproject.org

On 01/08/2015 04:50 AM, Jan Beulich wrote:
>>>> On 07.01.15 at 18:55, <dario.faggioli@citrix.com> wrote:
>> There probably would not be too serious issues in converting everything
>> to PXM, or adding duplicates, but I don't see the reason why we should
>> do such a thing... Perhaps I'm missing what using PXM would actually buy
>> us?
> As long as those node IDs don't get stored persistently for future
> use, using them (despite being a Xen internal representation)
> ought to be fine. My concern really is that such Xen internals may
> easily get mis-used in the tool stack, e.g. assuming that they won't
> change across reboots (perhaps after a hypervisor update).

Are PXMs guaranteed to be persistent across firmware upgrades? I don't 
see anything about this in the APCI spec. The only semi-relevant 
statement that I found was that PXM values are meaningless (i.e. they 
are much like cookies).

(FWIW, Linux exposes nodeIDs in the same manner as Xen. In fact, Xen's 
srat.c appears to be derived from Linux code.)

-boris