>>> On 08.01.15 at 16:49, wrote:
> On 01/08/2015 04:50 AM, Jan Beulich wrote:
> On 07.01.15 at 18:55, 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'
On 01/08/2015 04:50 AM, Jan Beulich wrote:
On 07.01.15 at 18:55, 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
>>> On 07.01.15 at 18:55, 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
On Wed, 2015-01-07 at 10:54 -0500, Boris Ostrovsky wrote:
> On 01/07/2015 10:17 AM, Jan Beulich wrote:
> >> This is the same information (pxm -> node mapping ) that we provide in
> >> XEN_SYSCTL_topologyinfo (renamed in this series to
> >> XEN_SYSCTL_cputopoinfo). Given that I expect the two topolo
>>> On 07.01.15 at 16:54, wrote:
> On 01/07/2015 10:17 AM, Jan Beulich wrote:
>> I personally think that exposing e.g. the firmware
>> determined (and hence hopefully stable across reboots) PXM would
>> be more reasonable.
>
> Again, the main argument that I see against using PXM values directly
On 01/07/2015 10:17 AM, Jan Beulich wrote:
On 07.01.15 at 15:55, wrote:
On 01/07/2015 04:21 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, wrote:
+for ( ; ti->first_dev < ti->num_devs; ti->first_dev++ )
+{
+xen_sysctl_pcitopo_t pcitopo;
+struct pci_dev *
>>> On 07.01.15 at 15:55, wrote:
> On 01/07/2015 04:21 AM, Jan Beulich wrote:
> On 06.01.15 at 03:18, wrote:
>>> +for ( ; ti->first_dev < ti->num_devs; ti->first_dev++ )
>>> +{
>>> +xen_sysctl_pcitopo_t pcitopo;
>>> +struct pci_dev *pdev;
>>> +
>>> +
On 01/07/2015 04:21 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, wrote:
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -365,6 +365,66 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
u_sysctl)
}
break;
#ifdef HAS_PCI
+case XEN_SYSCTL_pcitopoinfo:
+{
+
>>> On 06.01.15 at 03:18, wrote:
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -365,6 +365,66 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t)
> u_sysctl)
> }
> break;
>
#ifdef HAS_PCI
> +case XEN_SYSCTL_pcitopoinfo:
> +{
> +xen_sysctl_pcitopoinf
On 01/06/2015 11:55 AM, Wei Liu wrote:
On Mon, Jan 05, 2015 at 09:18:56PM -0500, Boris Ostrovsky wrote:
[...]
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
/* XEN_SYSCTL_cputopoinfo */
A bikeshed issue: is it better to just modified the above comment
instead of adding new trailing c
On Mon, Jan 05, 2015 at 09:18:56PM -0500, Boris Ostrovsky wrote:
[...]
> DEFINE_XEN_GUEST_HANDLE(xen_sysctl_lockprof_op_t);
>
> /* XEN_SYSCTL_cputopoinfo */
A bikeshed issue: is it better to just modified the above comment
instead of adding new trailing comment?
Wei.
> -#define INVALID_TOPOL
Signed-off-by: Boris Ostrovsky
---
xen/common/sysctl.c | 60 +++
xen/include/public/sysctl.h | 35 -
2 files changed, 94 insertions(+), 1 deletions(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 1254a24.
12 matches
Mail list logo
