On 07.01.15 at 18:55, dario.faggi...@citrix.com 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
On 01/08/2015 04:50 AM, Jan Beulich wrote:
On 07.01.15 at 18:55, dario.faggi...@citrix.com 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
On 08.01.15 at 16:49, boris.ostrov...@oracle.com wrote:
On 01/08/2015 04:50 AM, Jan Beulich wrote:
On 07.01.15 at 18:55, dario.faggi...@citrix.com 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
On 06.01.15 at 03:18, boris.ostrov...@oracle.com 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 01/07/2015 04:21 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, boris.ostrov...@oracle.com 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
On 01/07/2015 10:17 AM, Jan Beulich wrote:
On 07.01.15 at 15:55, boris.ostrov...@oracle.com wrote:
On 01/07/2015 04:21 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, boris.ostrov...@oracle.com wrote:
+for ( ; ti-first_dev ti-num_devs; ti-first_dev++ )
+{
+
On 07.01.15 at 15:55, boris.ostrov...@oracle.com wrote:
On 01/07/2015 04:21 AM, Jan Beulich wrote:
On 06.01.15 at 03:18, boris.ostrov...@oracle.com wrote:
+for ( ; ti-first_dev ti-num_devs; ti-first_dev++ )
+{
+xen_sysctl_pcitopo_t pcitopo;
+struct
On 07.01.15 at 16:54, boris.ostrov...@oracle.com 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
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 topologies to be
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
Signed-off-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
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
11 matches
Mail list logo
