[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v9 1/9] xen: vnuma topology and subop hypercalls

On Wed, Sep 3, 2014 at 4:28 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>> On 03.09.14 at 02:46, <ufimtseva@xxxxxxxxx> wrote:
>> On Fri, Aug 29, 2014 at 6:37 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>>> On 29.08.14 at 05:04, <ufimtseva@xxxxxxxxx> wrote:
>>>> +static struct vnuma_info *vnuma_init(const struct xen_domctl_vnuma *uinfo,
>>>> +                                     const struct domain *d)
>>>> +{
>>>> +    unsigned int nr_vnodes;
>>>> +    int i, ret = -EINVAL;
>>>> +    struct vnuma_info *info;
>>>> +
>>>> +    nr_vnodes = uinfo->nr_vnodes;
>>>> +
>>>> +    if ( nr_vnodes == 0 || nr_vnodes > uinfo->nr_vmemranges ||
>>> Is that really a necessary check? I.e. does code elsewhere rely on
>>> that? I ask because memory-less nodes are possible on real
>>> hardware.
>> That is true. But taking into account that there are no buses support
>> yet added, absence of memory and buses for a vNUMA node
>> seem to be useless. And vNUMA can mimic hardware NUMA as close as
>> possible, but I think the degree of this is pretty much our choice.
>> With further extension of vNUMA to include buses I think this check
>> will naturally disappear.
> I have to admit that I struggle with the references to "buses" in your
> reply. Could you perhaps give some context (not the least because
> already known future extensions may call for making provisions for
> them in the public interface)?
> Jan

Sorry Jan, looks like I have missed that one.

I meant NUMA I/O when was referring to buses.
For example from here/

Or here NUMA I/O = PCIe :

In earlier discussions of vNUMA, numa I/O was mentioned but never
really looked at yet from implementation point of view.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.