>>> On 07.01.15 at 16:34, wrote:
> On 01/07/2015 10:07 AM, Jan Beulich wrote:
> On 07.01.15 at 15:47, wrote:
>>> On 07/01/15 14:42, Boris Ostrovsky wrote:
I kept this field as an int to be able to store NUMA_NO_NODE which I
thought to be (int)-1.
But now I see that NUMA_NO
>>> On 07.01.15 at 16:31, wrote:
> On 01/07/2015 10:06 AM, Jan Beulich wrote:
>>
Of course an additional question would be whether the node wouldn't
better go into struct arch_pci_dev - that depends on whether we
expect ARM to be using NUMA...
>>> Since we have CPU topology in commo
On 01/07/2015 10:06 AM, Jan Beulich wrote:
Of course an additional question would be whether the node wouldn't
better go into struct arch_pci_dev - that depends on whether we
expect ARM to be using NUMA...
Since we have CPU topology in common code I thought this would be
arch-independent as we
On 01/07/2015 10:07 AM, Jan Beulich wrote:
On 07.01.15 at 15:47, wrote:
On 07/01/15 14:42, Boris Ostrovsky wrote:
I kept this field as an int to be able to store NUMA_NO_NODE which I
thought to be (int)-1.
But now I see that NUMA_NO_NODE is, in fact, 0xff but is promoted to
(int)-1 by pxm_to_
>>> On 07.01.15 at 15:47, wrote:
> On 07/01/15 14:42, Boris Ostrovsky wrote:
>> I kept this field as an int to be able to store NUMA_NO_NODE which I
>> thought to be (int)-1.
>>
>> But now I see that NUMA_NO_NODE is, in fact, 0xff but is promoted to
>> (int)-1 by pxm_to_node(). Given that there is
>>> On 07.01.15 at 15:42, wrote:
> On 01/07/2015 04:06 AM, Jan Beulich wrote:
> On 06.01.15 at 03:18, wrote:
>>> --- a/xen/include/xen/pci.h
>>> +++ b/xen/include/xen/pci.h
>>> @@ -56,6 +56,8 @@ struct pci_dev {
>>>
>>> u8 phantom_stride;
>>>
>>> +int node; /* NUMA node */
>>
On 07/01/15 14:42, Boris Ostrovsky wrote:
> On 01/07/2015 04:06 AM, Jan Beulich wrote:
> On 06.01.15 at 03:18, wrote:
>>> @@ -618,7 +620,22 @@ ret_t do_physdev_op(int cmd,
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>> }
>>> else
>>> pdev_info.is_virtfn = 0;
>>> -
On 01/07/2015 04:06 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, wrote:
@@ -618,7 +620,22 @@ ret_t do_physdev_op(int cmd, XEN_GUEST_HANDLE_PARAM(void)
arg)
}
else
pdev_info.is_virtfn = 0;
-ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
>>> On 06.01.15 at 03:18, wrote:
> @@ -618,7 +620,22 @@ ret_t do_physdev_op(int cmd,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> }
> else
> pdev_info.is_virtfn = 0;
> -ret = pci_add_device(add.seg, add.bus, add.devfn, &pdev_info);
> +
> +if ( add.flags & X
>>> On 06.01.15 at 12:55, wrote:
> On 06/01/15 02:18, Boris Ostrovsky wrote:
>
>> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
>> index 5f295f3..a5eb81c 100644
>> --- a/xen/include/xen/pci.h
>> +++ b/xen/include/xen/pci.h
>> @@ -56,6 +56,8 @@ struct pci_dev {
>>
>> u8 phantom
On 06/01/15 02:18, Boris Ostrovsky wrote:
> diff --git a/xen/include/xen/pci.h b/xen/include/xen/pci.h
> index 5f295f3..a5eb81c 100644
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -56,6 +56,8 @@ struct pci_dev {
>
> u8 phantom_stride;
>
> +int node; /* NUMA node */
If ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.
We will store this information (in the form of nodeID) in pci_dev
structure so that we can provide it, for example, to the toolstack
12 matches
Mail list logo
