This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [xen-devel][vNUMA v2][PATCH 2/8] public interface

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [xen-devel][vNUMA v2][PATCH 2/8] public interface
From: Dulloor <dulloor@xxxxxxxxx>
Date: Tue, 3 Aug 2010 08:43:21 -0700
Cc: Andre Przywara <andre.przywara@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 03 Aug 2010 08:44:02 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h2Wl9a+Rcd3VKHy7E+fDO3vNl5iPhDRoB36868eest4=; b=XlQeJrvj0gTFjklzhrsB9PPmOTQR1fDaKQLQWdb8NyW4BBvVU8WWO1VgmSN5vaD4M5 zcbQor/zlbCbANsMheHSd/KOXz0gXk5UCOEp9/jyiFEcQD1RQwnb8nijFwlPZTq+NPkO CeFsx6oljOiJCtoPoa62a02lzQy6reLuUAl1M=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ThhHu1zBqxZgTGnidryb2egcMYht6b4sXH3veX0g6OC1paIri49uP7E/29s+0ZFn1Z sMS+CB2m+q8PlwXrGrKazKuYYeRDtNSXKzIt8RWyMPNtMfzXtfWdry+1L/a/VOPW1WkM 9s7fu+DInJ6Hu9PQXsquxXBXbfdD0bIzME+3M=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C87DE1F9.1C932%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4C581BA6.3030502@xxxxxxx> <C87DE1F9.1C932%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, Aug 3, 2010 at 7:10 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx> wrote:
> On 03/08/2010 14:37, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:
>> +struct xen_vnode_info {
>> +    uint8_t mnode_id;  /* physical node vnode is allocated from */
>> +    uint32_t start;  /* start of the vnode range (in pages) */
>> +    uint32_t end;   /* end of the vnode range (in pages) */
>> +};
>> +
>>> +struct xen_domain_numa_info {
>>> +    uint8_t version;    /* Interface version */
>>> +    uint8_t type;       /* VM memory allocation scheme (see above) */
>>> +
>>> +    uint8_t nr_vcpus;
>> Isn't that redundant with info stored somewhere else (for instance
>> in the hvm_info table)?
>>> +    uint8_t nr_vnodes;
>>> +    /* data[] has the following entries :
>>> +     * //Only (nr_vnodes) entries are filled, each sizeof(struct
>>> xen_vnode_info)
>>> +     * struct xen_vnode_info vnode_info[nr_vnodes];
>> Why would the guest need that info (physical node, start and end) here?
>> Wouldn't be just the size of the node's memory sufficient?
> I would expect guest would see nodes 0 to nr_vnodes-1, and the mnode_id
> could go away.
mnode_id maps the vnode to a particular physical node. This will be
used by balloon driver in
the VMs when the structure is passed as NUMA enlightenment to PVs and
PV on HVMs.
I have a patch ready for that (once we are done with this series).

> Do you think the <start,end> ranges are also unnecessary, and
> could really be replaced by just a size? I asked for that to be changed the
> other way last time round.
Actually, we don't need <start, end> ranges, since the nodes are always
contiguous, which could be made implicit in domain builders (hvmloader
and PV enlightenment).
But, your previous suggestion to use <start, end> ranges could still
be seen as style/consistency thing,
which could be important in interfaces. Your pick :)

>  -- Keir

Xen-devel mailing list