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

[Dulloor <dulloor@xxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel