Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Fri, 2015-10-23 at 02:01 -0600, Jan Beulich wrote:
> > > > On 22.10.15 at 19:08,  wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Thu, 22 Oct 2015, Ian Campbell wrote:
> > > > This was discussed prior to Wei submitting this patch, but I can't
> > > > remember
> > > > the reference. Hopefully either Wei or Stefano does.
> > > 
> > > 1444832748.23192.213.ca...@citrix.com 
> > 
> > Thanks for the reference.
> > 
> > I'm quite uncomfortable with this, really.
> > 
> > People who are using xen.git stable branches ought to get only changes
> > that we (or perhaps, someone else whose judgement we have some reason
> > to trust) have intentionally decided are suitable for deployment as a
> > bugfix or security update in an existing installation.
> > 
> > Ie, changes in stable branches are supposed to be low risk.  That's
> > not compatible with tracking an upstream development branch.
> 
> FWIW, I agree. Do we know of specific commits that we actually
> need?

Yes. Those (that?) and the reasons why we aren't just trivially taking them
are explained in the referenced thread.

Really this is about adding a new feature (arm64 support for ovmf) into
4.6.1 for Raisin's benefit.

My personal preference, given the arguments made in the thread, would be
for raisin to just point at mainline ovmf for the arm64 case. IOW
acknowledge that arm64 ovmf was not actually part of the 4.6 release and
that we should work towards making it not a special case in the 4.7 release
(by, you know, testing it prior to release and things like that).

IMHO the most natural way to express that would be to differentiate the
"OVMF blob built into hvmloader" from "OVMF consumed as an external
'kernel'" as different components in raisin and include them in the
appropriate per-parch component lists. While the former is something which
we test and include in our releases the latter is more akin to how grub2 is
(loosely) integrated.

Ian.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] Adding Xen development headers to XenServer

[D'Mita Levy]

Is it possible to add Xen development headers to XenServer? I would like to
do a little bit of VM introspection with LibVMI on XenServer. I have all
the other dependencies installed (glib, flex, etc.) just missing the ones
for Xen...Any help is greatly appreciated.

Thanks,
D'Mita

-- 
D'Mita Levy
Cyber Fellow, Applied Research Center
Florida International University
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Adding Xen development headers to XenServer

[Andrew Cooper]

On 23/10/15 19:07, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would
> like to do a little bit of VM introspection with LibVMI on XenServer.
> I have all the other dependencies installed (glib, flex, etc.) just
> missing the ones for Xen...Any help is greatly appreciated.

Wrong list.  Dropping xen-devel to BCC, adding xs-devel to CC.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Adding Xen development headers to XenServer

[Razvan Cojocaru]

On 10/23/2015 09:07 PM, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would like
> to do a little bit of VM introspection with LibVMI on XenServer. I have
> all the other dependencies installed (glib, flex, etc.) just missing the
> ones for Xen...Any help is greatly appreciated.

The XenServer source code is freely available, that includes the
hypervisor / tools:

https://www.citrix.com/go/products/xenserver/xenserver-source-free.html

http://xenserver.org/overview-xenserver-open-source-virtualization/source-code.html


Cheers,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 2/3] xl: convert vcpu related return codes to EXIT_[SUCCESS|FAILURE]

[Harmandeep Kaur]

turning vcpu manipulation functions xl exit codes toward using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index c215c14..2cb4fe8 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -946,11 +946,11 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 libxl_bitmap_init(_affinity_array[j]);
 if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[j], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", j);
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 if (cpurange_parse(buf, _affinity_array[j]))
-exit(1);
+exit(EXIT_FAILURE);
 
 j++;
 }
@@ -963,17 +963,17 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 libxl_bitmap_init(_affinity_array[0]);
 if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[0], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu 0\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 if (cpurange_parse(buf, _affinity_array[0]))
-exit(1);
+exit(EXIT_FAILURE);
 
 for (i = 1; i < b_info->max_vcpus; i++) {
 libxl_bitmap_init(_affinity_array[i]);
 if (libxl_cpu_bitmap_alloc(ctx, _affinity_array[i], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", i);
-exit(1);
+exit(EXIT_FAILURE);
 }
 libxl_bitmap_copy(ctx, _affinity_array[i],
   _affinity_array[0]);
@@ -1086,7 +1086,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 if (libxl_get_physinfo(ctx, ) != 0) {
 libxl_physinfo_dispose();
 fprintf(stderr, "libxl_get_physinfo failed\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 nr_nodes = physinfo.nr_nodes;
@@ -1105,7 +1105,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 libxl_bitmap_init(_parsed[i]);
 if (libxl_cpu_bitmap_alloc(ctx, _parsed[i], b_info->max_vcpus)) {
 fprintf(stderr, "libxl_node_bitmap_alloc failed.\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -1130,7 +1130,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 xlu_cfg_value_get_list(config, vnode_spec, _config_list, 0);
 if (!vnode_config_list) {
 fprintf(stderr, "xl: cannot get vnode config option list\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 for (conf_count = 0;
@@ -1152,7 +1152,7 @@ static void parse_vnuma_config(const XLU_Config *config,
_untrimmed)) {
 fprintf(stderr, "xl: failed to split \"%s\" into pair\n",
 buf);
-exit(1);
+exit(EXIT_FAILURE);
 }
 trim(isspace, option_untrimmed, );
 trim(isspace, value_untrimmed, );
@@ -1162,7 +1162,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 if (val >= nr_nodes) {
 fprintf(stderr,
 "xl: invalid pnode number: %lu\n", val);
-exit(1);
+exit(EXIT_FAILURE);
 }
 p->pnode = val;
 libxl_defbool_set(_info->numa_placement, false);
@@ -1218,20 +1218,20 @@ static void parse_vnuma_config(const XLU_Config *config,
 if (b_info->max_vcpus != 0) {
 if (b_info->max_vcpus != max_vcpus) {
 fprintf(stderr, "xl: vnuma vcpus and maxvcpus= mismatch\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 } else {
 int host_cpus = libxl_get_online_cpus(ctx);
 
 if (host_cpus < 0) {
 fprintf(stderr, "Failed to get online cpus\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 if (host_cpus < max_vcpus) {
 fprintf(stderr, "xl: vnuma specifies more vcpus than pcpus, "\
 "use maxvcpus= to override this check.\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 b_info->max_vcpus = max_vcpus;
@@ -1241,7 +1241,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 if (b_info->max_memkb != LIBXL_MEMKB_DEFAULT &&
 b_info->max_memkb != max_memkb) {
 fprintf(stderr, "xl: maxmem and vnuma memory size mismatch\n");
-exit(1);
+exit(EXIT_FAILURE);
 } else
 b_info->max_memkb = max_memkb;
 
@@ -5316,7 

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Wei Liu]

On Thu, Oct 22, 2015 at 07:14:20PM +0200, Dario Faggioli wrote:
> In fact, right now, failing at destroying a cpupool is just
> not reported to the user in any explicit way. Log an error,
> as it is customary for xl in these cases.
> 
> While there, take the chance to turn a couple of xl exit
> codes into EXIT_[SUCCESS|FAILURE], as discussed and agreed
> here:
> 
>  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01336.html
>  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01341.html
> 
> Signed-off-by: Dario Faggioli 

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 00/17] Add VT-d Posted-Interrupts support

[Dario Faggioli]

On Fri, 2015-10-23 at 08:35 +, Wu, Feng wrote:
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > > > On 23.10.15 at 04:12,  wrote:
> > > Kindly ping ...
> > 
> > I can understand that you want to get this to make progress, but as
> > said a number of times before (in variouw contexts) - as long as
> > Intel
> > contributors in general and Intel maintainers in particular won't
> > become more active in reviewing patches, I don't think you can
> > expect the few of us to carry the load of reviewing all these large
> > series that have been submitted by Intel during the last couple of
> > months.
> 
> Yes, this is a large series, but most of them have been reviewed,
> right?
> And thanks to your review efforts on them. Now I think the remaining
> review effort will need be put to patch
> "[PATCH v8 15/17] vmx: VT-d posted-interrupt core logic handling",
> which was understand discussion among you, George, Dario, and me
> during the last couple of weeks, since the memory is still fresh, why
> not continue to review it? 
>
I'll have a look ASAP, probably today.

However, "why not continue to review it", I think Jan put down quite
some sensible arguments for it. Also, as he said, there is no chance
that we _don't_ continue to review the series, it's just a matter of
priorities, which are influenced by a lot of factors.

> And I think maybe it is more efficient to do
> it now.
> 
Hey, everyone of us has his own workflow, and his own definitions of
what's "more efficient". :-)

Given the timing, I think it's after all fine that you "Kindly ping"
this series... Just don't get too far with that! :-D :-D

Anyway, and jokes apart, as said, I was already planning to have a look
at this soon.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 3/3] xl: convert cpupool related return codes to EXIT_[SUCCESS|FAILURE]

[Harmandeep Kaur]

turning  cpupools related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 2cb4fe8..c7009cf 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7497,7 +7497,7 @@ out:
 free(name);
 free(config_data);
 free(extra_config);
-return rc;
+return rc ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
 int main_cpupoollist(int argc, char **argv)
@@ -7524,14 +7524,14 @@ int main_cpupoollist(int argc, char **argv)
 pool = argv[optind];
 if (libxl_name_to_cpupoolid(ctx, pool, )) {
 fprintf(stderr, "Pool \'%s\' does not exist\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 }
 
 poolinfo = libxl_list_cpupool(ctx, _pools);
 if (!poolinfo) {
 fprintf(stderr, "error getting cpupool info\n");
-return 1;
+return EXIT_FAILURE;
 }
 
 printf("%-19s", "Name");
@@ -7562,7 +7562,7 @@ int main_cpupoollist(int argc, char **argv)
 
 libxl_cpupoolinfo_list_free(poolinfo, n_pools);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupooldestroy(int argc, char **argv)
@@ -7580,13 +7580,13 @@ int main_cpupooldestroy(int argc, char **argv)
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, , NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_destroy(ctx, poolid))
-return 1;
+return EXIT_FAILURE;
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupoolrename(int argc, char **argv)
@@ -7605,17 +7605,17 @@ int main_cpupoolrename(int argc, char **argv)
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, , NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 new_name = argv[optind];
 
 if (libxl_cpupool_rename(ctx, new_name, poolid)) {
 fprintf(stderr, "Can't rename cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupoolcpuadd(int argc, char **argv)
@@ -7633,7 +7633,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 libxl_bitmap_init();
 if (libxl_cpu_bitmap_alloc(ctx, , 0)) {
 fprintf(stderr, "Unable to allocate cpumap");
-return 1;
+return EXIT_FAILURE;
 }
 
 pool = argv[optind++];
@@ -7653,7 +7653,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 
 out:
 libxl_bitmap_dispose();
-return rc;
+return rc ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
 int main_cpupoolcpuremove(int argc, char **argv)
@@ -7667,7 +7667,7 @@ int main_cpupoolcpuremove(int argc, char **argv)
 libxl_bitmap_init();
 if (libxl_cpu_bitmap_alloc(ctx, , 0)) {
 fprintf(stderr, "Unable to allocate cpumap");
-return 1;
+return EXIT_FAILURE;
 }
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "cpupool-cpu-remove", 2) {
@@ -7691,7 +7691,7 @@ int main_cpupoolcpuremove(int argc, char **argv)
 
 out:
 libxl_bitmap_dispose();
-return rc;
+return rc ? EXIT_FAILURE : EXIT_SUCCESS;
 }
 
 int main_cpupoolmigrate(int argc, char **argv)
@@ -7712,19 +7712,19 @@ int main_cpupoolmigrate(int argc, char **argv)
 if (libxl_domain_qualifier_to_domid(ctx, dom, ) ||
 !libxl_domid_to_name(ctx, domid)) {
 fprintf(stderr, "unknown domain '%s'\n", dom);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, , NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_movedomain(ctx, poolid, domid))
-return 1;
+return EXIT_FAILURE;
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupoolnumasplit(int argc, char **argv)
@@ -7758,7 +7758,7 @@ int main_cpupoolnumasplit(int argc, char **argv)
 poolinfo = libxl_list_cpupool(ctx, _pools);
 if (!poolinfo) {
 fprintf(stderr, "error getting cpupool info\n");
-return 1;
+return EXIT_FAILURE;
 }
 poolid = poolinfo[0].poolid;
 sched = poolinfo[0].sched;
@@ -7766,13 +7766,13 @@ int main_cpupoolnumasplit(int argc, char **argv)
 
 if (n_pools > 1) {
 fprintf(stderr, "splitting not possible, already cpupools in use\n");
-return 1;
+return EXIT_FAILURE;
 }
 
 topology = libxl_get_cpu_topology(ctx, _cpus);
 if (topology == NULL) {
 fprintf(stderr, 

Re: [Xen-devel] [PATCH 0/2] limit xen vnic max queues number to online cpu number

[Paul Durrant]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Joe Jin
> Sent: 23 October 2015 08:54
> To: Wei Liu; Ian Campbell; Boris Ostrovsky; Konrad Rzeszutek Wilk; David S.
> Miller
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Subject: [PATCH 0/2] limit xen vnic max queues number to online cpu
> number
> 
> Currently xen vnic allowed to create lots of queues by set module param
> max_queues(both netback and netfront), when queues number larger than
> cpu number, it does not help for performance but need more cpu time.
> 

But it's an override, so why would you want to limit it? The parameter should 
not be set in the common case.

  Paul

> This patchset limit netback and netfront max queues number to online
> cpus number.
> 
> Joe Jin (2):
>   xen-netback: limit xen vif max queues number to online cpus
>   xen-front: limit vnic max_queues number to online cpus
> 
>  drivers/net/xen-netback/netback.c |   28 ++--
>  drivers/net/xen-netfront.c|   27 +--
>  2 files changed, 43 insertions(+), 12 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v5 7/9] x86/intel_pstate: add a booting param to select the driver to load

[Wang, Wei W]

On 23/10/2015 16:36,  Jan Beulich wrote:
> >>> On 23.10.15 at 10:18,  wrote:
> > On 07/10/2015 23:46,  Jan Beulich wrote:
> >> >>> On 14.09.15 at 04:32,  wrote:
> >> > --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> >> > @@ -647,9 +648,11 @@ static int __init cpufreq_driver_init(void)
> >> >  int ret = 0;
> >> >
> >> >  if ((cpufreq_controller == FREQCTL_xen) &&
> >> > -(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL))
> >> > -ret = cpufreq_register_driver(_cpufreq_driver);
> >> > -else if ((cpufreq_controller == FREQCTL_xen) &&
> >> > +(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) {
> >> > +ret = intel_pstate_init();
> >> > +if (ret)
> >> > +ret = cpufreq_register_driver(_cpufreq_driver);
> >> > +} else if ((cpufreq_controller == FREQCTL_xen) &&
> >> >  (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
> >> >  ret = powernow_register_driver();
> >>
> >> Since you're basically modifying the entire body of the function,
> >> please
> > gets its
> >> coding style corrected as you fiddle with it.
> >
> > Ok, I guess you was probably referring to the remaining lines in the
> > function - "(boot_cpu_data.x86_vendor == X86_VENDOR_AMD))".. Will
> > align them as well.
> 
> No, I'm not just talking about alignment. And the coding style of the file is 
> mixed
> already (see e.g. the following function, which admittedly has even more 
> blanks
> than needed), so getting this function into proper shape since you modify it 
> in its
> entirety is a step in the right direction.
> 

Ok. I will use Xen style brackets for this function.

Best,
Wei

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/3] xl: convert scheduling related return codes to EXIT_[SUCCESS|FAILURE]

[Harmandeep Kaur]

turning scheduling related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 67 
 1 file changed, 33 insertions(+), 34 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 365798b..c215c14 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5851,13 +5851,13 @@ static int sched_credit_domain_output(int domid)
 
 if (domid < 0) {
 printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
-return 0;
+return EXIT_SUCCESS;
 }
 
 libxl_domain_sched_params_init();
 rc = sched_domain_get(LIBXL_SCHEDULER_CREDIT, domid, );
 if (rc)
-return rc;
+return EXIT_FAILURE;
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %6d %4d\n",
 domname,
@@ -5866,7 +5866,7 @@ static int sched_credit_domain_output(int domid)
 scinfo.cap);
 free(domname);
 libxl_domain_sched_params_dispose();
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_credit_pool_output(uint32_t poolid)
@@ -5887,7 +5887,7 @@ static int sched_credit_pool_output(uint32_t poolid)
scparam.ratelimit_us);
 }
 free(poolname);
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_credit2_domain_output(
@@ -5899,13 +5899,13 @@ static int sched_credit2_domain_output(
 
 if (domid < 0) {
 printf("%-33s %4s %6s\n", "Name", "ID", "Weight");
-return 0;
+return EXIT_SUCCESS;
 }
 
 libxl_domain_sched_params_init();
 rc = sched_domain_get(LIBXL_SCHEDULER_CREDIT2, domid, );
 if (rc)
-return rc;
+return EXIT_FAILURE;
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %6d\n",
 domname,
@@ -5913,7 +5913,7 @@ static int sched_credit2_domain_output(
 scinfo.weight);
 free(domname);
 libxl_domain_sched_params_dispose();
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_rtds_domain_output(
@@ -5925,13 +5925,14 @@ static int sched_rtds_domain_output(
 
 if (domid < 0) {
 printf("%-33s %4s %9s %9s\n", "Name", "ID", "Period", "Budget");
-return 0;
+return EXIT_SUCCESS;
 }
 
 libxl_domain_sched_params_init();
 rc = sched_domain_get(LIBXL_SCHEDULER_RTDS, domid, );
 if (rc)
-goto out;
+libxl_domain_sched_params_dispose();
+return EXIT_FAILURE;
 
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %9d %9d\n",
@@ -5940,10 +5941,8 @@ static int sched_rtds_domain_output(
 scinfo.period,
 scinfo.budget);
 free(domname);
-
-out:
 libxl_domain_sched_params_dispose();
-return rc;
+return EXIT_SUCCESS;
 }
 
 static int sched_rtds_pool_output(uint32_t poolid)
@@ -5954,7 +5953,7 @@ static int sched_rtds_pool_output(uint32_t poolid)
 printf("Cpupool %s: sched=RTDS\n", poolname);
 
 free(poolname);
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_default_pool_output(uint32_t poolid)
@@ -5965,7 +5964,7 @@ static int sched_default_pool_output(uint32_t poolid)
 printf("Cpupool %s:\n",
poolname);
 free(poolname);
-return 0;
+return EXIT_SUCCESS;
 }
 
 static int sched_domain_output(libxl_scheduler sched, int (*output)(int),
@@ -5981,14 +5980,14 @@ static int sched_domain_output(libxl_scheduler sched, 
int (*output)(int),
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, cpupool, , NULL) 
||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool \'%s\'\n", cpupool);
-return -ERROR_FAIL;
+return EXIT_FAILURE;
 }
 }
 
 info = libxl_list_domain(ctx, _domain);
 if (!info) {
 fprintf(stderr, "libxl_list_domain failed.\n");
-return 1;
+return EXIT_FAILURE;
 }
 poolinfo = libxl_list_cpupool(ctx, _pools);
 if (!poolinfo) {
@@ -6016,7 +6015,7 @@ static int sched_domain_output(libxl_scheduler sched, int 
(*output)(int),
 
 libxl_cpupoolinfo_list_free(poolinfo, n_pools);
 libxl_dominfo_list_free(info, nb_domain);
-return 0;
+return EXIT_SUCCESS;
 }
 
 /* 
@@ -6080,16 +6079,16 @@ int main_sched_credit(int argc, char **argv)
 if ((cpupool || opt_s) && (dom || opt_w || opt_c)) {
 fprintf(stderr, "Specifying a cpupool or schedparam is not "
 "allowed with domain options.\n");
-return 1;
+return EXIT_FAILURE;
 }
 if (!dom && (opt_w || opt_c)) {
 fprintf(stderr, "Must specify a domain.\n");
-return 1;
+return EXIT_FAILURE;
 }
 if (!opt_s && (opt_t || opt_r)) {
 fprintf(stderr, "Must specify schedparam to set schedule "
 "parameter values.\n");
-return 1;
+   

[Xen-devel] [distros-debian-jessie test] 38201: tolerable all pass

[Platform Team regression test user]

flight 38201 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38201/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass

baseline version:
 flight   38174

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Push not applicable.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v8 00/17] Add VT-d Posted-Interrupts support

[Wu, Feng]

> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Friday, October 23, 2015 4:46 PM
> To: Wu, Feng ; Jan Beulich 
> Cc: Lars Kurth ; george.dun...@eu.citrix.com; Li, Susie
> ; xen-devel@lists.xen.org
> Subject: Re: [PATCH v8 00/17] Add VT-d Posted-Interrupts support
> 
> On Fri, 2015-10-23 at 08:35 +, Wu, Feng wrote:
> >
> > > -Original Message-
> > > From: Jan Beulich [mailto:jbeul...@suse.com]
> > > > > > On 23.10.15 at 04:12,  wrote:
> > > > Kindly ping ...
> > >
> Hey, everyone of us has his own workflow, and his own definitions of
> what's "more efficient". :-)
> 
> Given the timing, I think it's after all fine that you "Kindly ping"
> this series... Just don't get too far with that! :-D :-D
> 
> Anyway, and jokes apart, as said, I was already planning to have a look
> at this soon.
> 

Thanks a lot, great to hear that!:)

Thanks,
Feng
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] limit xen vnic max queues number to online cpu number

[Joe Jin]

On 10/23/2015 04:47 PM, Paul Durrant wrote:
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-
>> ow...@vger.kernel.org] On Behalf Of Joe Jin
>> Sent: 23 October 2015 08:54
>> To: Wei Liu; Ian Campbell; Boris Ostrovsky; Konrad Rzeszutek Wilk; David S.
>> Miller
>> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
>> Subject: [PATCH 0/2] limit xen vnic max queues number to online cpu
>> number
>>
>> Currently xen vnic allowed to create lots of queues by set module param
>> max_queues(both netback and netfront), when queues number larger than
>> cpu number, it does not help for performance but need more cpu time.
>>
> 
> But it's an override, so why would you want to limit it? The parameter should 
> not be set in the common case.

Always we can not stop people use it because we provided it :)

If queues number is larger than cpu number, with heavy network load,
cpus have to take more time for interrupt, this lead others less
chance to be scheduled.
Imaging dom0 have 64 cpus, and assigned 4 vcpus to the guest, if
set max_queues to 64 on guest, it will consumed more cpu times
and bandwidth on backend, I think this is not we expected?

Thanks,
Joe
> 
>   Paul
> 
>> This patchset limit netback and netfront max queues number to online
>> cpus number.
>>
>> Joe Jin (2):
>>   xen-netback: limit xen vif max queues number to online cpus
>>   xen-front: limit vnic max_queues number to online cpus
>>
>>  drivers/net/xen-netback/netback.c |   28 ++--
>>  drivers/net/xen-netfront.c|   27 +--
>>  2 files changed, 43 insertions(+), 12 deletions(-)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] limit xen vnic max queues number to online cpu number

[Jan Beulich]

>>> On 23.10.15 at 11:05,  wrote:
> On 10/23/2015 04:47 PM, Paul Durrant wrote:
>>> -Original Message-
>>> From: netdev-ow...@vger.kernel.org [mailto:netdev-
>>> ow...@vger.kernel.org] On Behalf Of Joe Jin
>>> Sent: 23 October 2015 08:54
>>> To: Wei Liu; Ian Campbell; Boris Ostrovsky; Konrad Rzeszutek Wilk; David S.
>>> Miller
>>> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org 
>>> Subject: [PATCH 0/2] limit xen vnic max queues number to online cpu
>>> number
>>>
>>> Currently xen vnic allowed to create lots of queues by set module param
>>> max_queues(both netback and netfront), when queues number larger than
>>> cpu number, it does not help for performance but need more cpu time.
>>>
>> 
>> But it's an override, so why would you want to limit it? The parameter 
> should not be set in the common case.
> 
> Always we can not stop people use it because we provided it :)

Well, it's always a question of whether preventing the admin to
shoot himself in the foot makes sense: When it leads to an unusable
system, it probably does. When it leads to a sub-optimal working
system, perhaps we should allow them their freedom?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH V3 1/2] xen-netback: limit xen vif max queues number to online cpus

[Andrew Cooper]

On 23/10/15 10:44, Joe Jin wrote:
> Should not allocate xen vif queues number more than online cpus.
>
> Signed-off-by: Joe Jin 
> Cc: Jan Beulich 
> Cc: Wei Liu 
> Cc: Ian Campbell 
> Cc: Boris Ostrovsky 
> Cc: Konrad Rzeszutek Wilk 
> ---
>  drivers/net/xen-netback/netback.c |   28 ++--
>  1 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index ec98d43..021dcb0 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -68,7 +68,9 @@ unsigned int rx_stall_timeout_msecs = 6;
>  module_param(rx_stall_timeout_msecs, uint, 0444);
>  
>  unsigned int xenvif_max_queues;
> -module_param_named(max_queues, xenvif_max_queues, uint, 0644);
> +static int xennet_set_max_queues(const char *val, struct kernel_param *kp);
> +module_param_call(max_queues, xennet_set_max_queues, param_get_uint,
> +   _max_queues, 0644);
>  MODULE_PARM_DESC(max_queues,
>"Maximum number of queues per virtual interface");
>  
> @@ -107,6 +109,20 @@ static struct xen_netif_rx_response 
> *make_rx_response(struct xenvif_queue *queue
>u16  size,
>u16  flags);
>  
> +static int xennet_set_max_queues(const char *val, struct kernel_param *kp)
> +{
> + unsigned int cpus = num_online_cpus();

This calculation is problematic in the scenario where a guest boots up,
then has more cpus hotplugged in, then wants to set up a sensible number
of queues.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}

[Julien Grall]

The last parameter of alloc_domheap_page{s,} contain the memory flags and
not the order of the allocation.

Use 0 for the call in p2m_pod_set_cache_target as it was before
1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for
page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the behavior
stays the same.

For the call in p2m_pod_offline_or_broken_replace we want to allocate
the new page on the same numa node as the previous page. So retrieve the
numa node and pass it in the memory flags.

Signed-off-by: Julien Grall 

---

Note that the patch has only been build tested.

Cc: George Dunlap 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Dario Faggioli 

Changes in v2:
- Change the behavior of p2m_pod_offline_or_broken_replace
to allocate the new page on the same numa node as the previous
page.
---
 xen/arch/x86/mm/p2m-pod.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c
index 901da37..acd85ea 100644
--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -222,7 +222,7 @@ p2m_pod_set_cache_target(struct p2m_domain *p2m, unsigned 
long pod_target, int p
 else
 order = PAGE_ORDER_4K;
 retry:
-page = alloc_domheap_pages(d, order, PAGE_ORDER_4K);
+page = alloc_domheap_pages(d, order, 0);
 if ( unlikely(page == NULL) )
 {
 if ( order == PAGE_ORDER_2M )
@@ -471,13 +471,14 @@ p2m_pod_offline_or_broken_replace(struct page_info *p)
 {
 struct domain *d;
 struct p2m_domain *p2m;
+nodeid_t node = phys_to_nid(page_to_maddr(p));
 
 if ( !(d = page_get_owner(p)) || !(p2m = p2m_get_hostp2m(d)) )
 return;
 
 free_domheap_page(p);
 
-p = alloc_domheap_page(d, PAGE_ORDER_4K);
+p = alloc_domheap_page(d, MEMF_node(node));
 if ( unlikely(!p) )
 return;
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCHv1 2/2] passthrough: improve locking when iterating over interrupts bound to VMs

[David Vrabel]

radix_tree_gang_lookup() only requires a RCU read lock, not the
per-domain event_lock.

Introduce a new RCU read lock and take the per-interrupt lock before
calling the callback instead.

This eliminates all contention on the event_lock when injecting
interrupts from passthrough devices.

Signed-off-by: David Vrabel 
---
 xen/drivers/passthrough/io.c | 10 +++---
 xen/include/xen/sched.h  |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index 7c86c20..9b51ef0 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -601,7 +601,7 @@ int pt_pirq_iterate(struct domain *d,
 unsigned int pirq = 0, n, i;
 struct pirq *pirqs[8];
 
-ASSERT(spin_is_locked(>event_lock));
+rcu_read_lock(>pirq_rcu_lock);
 
 do {
 n = radix_tree_gang_lookup(>pirq_tree, (void **)pirqs, pirq,
@@ -610,12 +610,18 @@ int pt_pirq_iterate(struct domain *d,
 {
 struct hvm_pirq_dpci *pirq_dpci = pirq_dpci(pirqs[i]);
 
+spin_lock(_dpci->lock);
+
 pirq = pirqs[i]->pirq;
 if ( (pirq_dpci->flags & HVM_IRQ_DPCI_MAPPED) )
 rc = cb(d, pirq_dpci, arg);
+
+spin_unlock(_dpci->lock);
 }
 } while ( !rc && ++pirq < d->nr_pirqs && n == ARRAY_SIZE(pirqs) );
 
+rcu_read_unlock(>pirq_rcu_lock);
+
 return rc;
 }
 
@@ -678,9 +684,7 @@ void hvm_dpci_msi_eoi(struct domain *d, int vector)
 if ( !iommu_enabled || !d->arch.hvm_domain.irq.dpci )
return;
 
-spin_lock(>event_lock);
 pt_pirq_iterate(d, _hvm_dpci_msi_eoi, (void *)(long)vector);
-spin_unlock(>event_lock);
 }
 
 static void hvm_dirq_assist(struct domain *d, struct hvm_pirq_dpci *pirq_dpci)
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 3729b0f..ae98c1e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -355,6 +355,7 @@ struct domain
  */
 struct radix_tree_root pirq_tree;
 unsigned int nr_pirqs;
+rcu_read_lock_t pirq_rcu_lock;
 
 enum guest_type guest_type;
 
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCHv1 1/2] passthrough: use per-interrupt lock when injecting an interrupt

[David Vrabel]

The use of the per-domain event_lock in hvm_dirq_assist() does not scale
with many VCPUs or interrupts.

Add a per-interrupt lock to reduce contention.  When a interrupt for a
passthrough device is being setup or teared down, we must take both
the event_lock and this new lock.

Signed-off-by: David Vrabel 
---
 xen/drivers/passthrough/io.c | 34 +++---
 xen/include/xen/hvm/irq.h|  1 +
 2 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/io.c b/xen/drivers/passthrough/io.c
index bda9374..7c86c20 100644
--- a/xen/drivers/passthrough/io.c
+++ b/xen/drivers/passthrough/io.c
@@ -106,7 +106,7 @@ static void pt_pirq_softirq_reset(struct hvm_pirq_dpci 
*pirq_dpci)
 {
 struct domain *d = pirq_dpci->dom;
 
-ASSERT(spin_is_locked(>event_lock));
+ASSERT(spin_is_locked(_dpci->lock));
 
 switch ( cmpxchg(_dpci->state, 1 << STATE_SCHED, 0) )
 {
@@ -209,7 +209,6 @@ int pt_irq_create_bind(
 if ( pirq < 0 || pirq >= d->nr_pirqs )
 return -EINVAL;
 
- restart:
 spin_lock(>event_lock);
 
 hvm_irq_dpci = domain_get_irq_dpci(d);
@@ -237,6 +236,8 @@ int pt_irq_create_bind(
 }
 pirq_dpci = pirq_dpci(info);
 
+spin_lock(_dpci->lock);
+
 /*
  * A crude 'while' loop with us dropping the spinlock and giving
  * the softirq_dpci a chance to run.
@@ -245,11 +246,11 @@ int pt_irq_create_bind(
  * would have spun forever and would do the same thing (wait to flush out
  * outstanding hvm_dirq_assist calls.
  */
-if ( pt_pirq_softirq_active(pirq_dpci) )
+while ( pt_pirq_softirq_active(pirq_dpci) )
 {
-spin_unlock(>event_lock);
+spin_unlock(_dpci->lock);
 cpu_relax();
-goto restart;
+spin_lock(_dpci->lock);
 }
 
 switch ( pt_irq_bind->irq_type )
@@ -301,6 +302,7 @@ int pt_irq_create_bind(
 pirq_dpci->dom = NULL;
 pirq_dpci->flags = 0;
 pirq_cleanup_check(info, d);
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 return rc;
 }
@@ -311,6 +313,7 @@ int pt_irq_create_bind(
 
 if ( (pirq_dpci->flags & mask) != mask )
 {
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 return -EBUSY;
 }
@@ -331,6 +334,7 @@ int pt_irq_create_bind(
 dest_mode = !!(pirq_dpci->gmsi.gflags & VMSI_DM_MASK);
 dest_vcpu_id = hvm_girq_dest_2_vcpu_id(d, dest, dest_mode);
 pirq_dpci->gmsi.dest_vcpu_id = dest_vcpu_id;
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 if ( dest_vcpu_id >= 0 )
 hvm_migrate_pirqs(d->vcpu[dest_vcpu_id]);
@@ -351,6 +355,7 @@ int pt_irq_create_bind(
 
 if ( !digl || !girq )
 {
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 xfree(girq);
 xfree(digl);
@@ -412,6 +417,7 @@ int pt_irq_create_bind(
 hvm_irq_dpci->link_cnt[link]--;
 pirq_dpci->flags = 0;
 pirq_cleanup_check(info, d);
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 xfree(girq);
 xfree(digl);
@@ -419,6 +425,7 @@ int pt_irq_create_bind(
 }
 }
 
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 
 if ( iommu_verbose )
@@ -430,6 +437,7 @@ int pt_irq_create_bind(
 }
 
 default:
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 return -EOPNOTSUPP;
 }
@@ -481,6 +489,8 @@ int pt_irq_destroy_bind(
 pirq = pirq_info(d, machine_gsi);
 pirq_dpci = pirq_dpci(pirq);
 
+spin_lock(_dpci->lock);
+
 if ( pt_irq_bind->irq_type != PT_IRQ_TYPE_MSI )
 {
 unsigned int bus = pt_irq_bind->u.pci.bus;
@@ -549,6 +559,7 @@ int pt_irq_destroy_bind(
 pirq_cleanup_check(pirq, d);
 }
 
+spin_unlock(_dpci->lock);
 spin_unlock(>event_lock);
 
 if ( what && iommu_verbose )
@@ -566,6 +577,7 @@ int pt_irq_destroy_bind(
 
 void pt_pirq_init(struct domain *d, struct hvm_pirq_dpci *dpci)
 {
+spin_lock_init(>lock);
 INIT_LIST_HEAD(>digl_list);
 dpci->gmsi.dest_vcpu_id = -1;
 }
@@ -621,7 +633,7 @@ int hvm_do_IRQ_dpci(struct domain *d, struct pirq *pirq)
 return 1;
 }
 
-/* called with d->event_lock held */
+/* called with pirq_dhci->lock held */
 static void __msi_pirq_eoi(struct hvm_pirq_dpci *pirq_dpci)
 {
 irq_desc_t *desc;
@@ -675,7 +687,7 @@ static void hvm_dirq_assist(struct domain *d, struct 
hvm_pirq_dpci *pirq_dpci)
 {
 ASSERT(d->arch.hvm_domain.irq.dpci);
 
-spin_lock(>event_lock);
+spin_lock(_dpci->lock);
 if ( test_and_clear_bool(pirq_dpci->masked) )
 {
 struct pirq *pirq = dpci_pirq(pirq_dpci);
@@ -687,7 +699,7 @@ static void hvm_dirq_assist(struct domain 

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > Yes. Those (that?) and the reasons why we aren't just trivially taking 
> > > them
> > > are explained in the referenced thread.
> 
> That explanation isn't very convincing to me.
> 
> > I cannot believe we are going to move forward without a way to introduce
> > any OVMF fixes into the  stable branches.
> 
> It is fine to introduce OVMF fixes into stable branches, of course.
> 
> But it is not fine to introduce other upstream changes to OVMF,
> willy-nilly.
> 
> Obviously these two requirements cannot be satisfied without there
> being some branch of OVMF which contains the intended fixes, without
> the unwanted upstream development.
> 
> If OVMF upstream do not have such a branch, we need to create one.

That's fine. We need the new branch in osstest and somebody maintaining
it.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V2 0/2] limit xen vnic max queues number to online cpus number

[Joe Jin]

Currently xen vnic allowed to create lots of queues by set module param
max_queues(both netback and netfront), when queues number larger than
cpus number, it does not help for performance but need more cpu time.

This patchset limit netback and netfront max queues number to online
cpus number.

Joe Jin (2):
  xen-netback: limit xen vif max queues number to online cpus
  xen-netfront: limit vnic max_queues number to online cpus

---
Changes in v2:
  - Replace param_get_int to param_get_uint.
  - Use '%u' for unsigned int when print.
  - Replace EINVAL to ERANGE when out of range [0-CPUs].
  - Reset the perm of max_queues on sysfs to 0644.

 drivers/net/xen-netback/netback.c |   28 ++--
 drivers/net/xen-netfront.c|   28 ++--
 2 files changed, 44 insertions(+), 12 deletions(-)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 04/13] x86/hvm: Setup TSC scaling ratio

[Jan Beulich]

>>> On 23.10.15 at 10:40,  wrote:
> On Fri, Oct 23, 2015 at 02:31:11AM -0600, Jan Beulich wrote:
>> >>> On 23.10.15 at 10:18,  wrote:
>> > On Fri, Oct 23, 2015 at 01:59:46AM -0600, Jan Beulich wrote:
>> >> >>> On 23.10.15 at 09:44,  wrote:
>> >> > On Thu, Oct 22, 2015 at 07:13:07AM -0600, Jan Beulich wrote:
>> >> >> >>> On 28.09.15 at 09:13,  wrote:
>> >> 
>> >> Please remember to trim your replies.
>> >> 
>> >> >> > @@ -2023,6 +2051,9 @@ static int hvm_load_cpu_ctxt(struct domain *d, 
>> > hvm_domain_context_t *h)
>> >> >> >  if ( hvm_funcs.load_cpu_ctxt(v, ) < 0 )
>> >> >> >  return -EINVAL;
>> >> >> >  
>> >> >> > +if ( !v->domain->arch.vtsc && hvm_funcs.tsc_scaling_supported )
>> >> >> > +hvm_setup_tsc_scaling(v);
>> >> >> 
>> >> >> What's the rationale for putting it in this function?
>> >> > 
>> >> > hvm_load_cpu_ctxt() is called in the migration to restore vcpu's state
>> >> > including TSC related things, so hvm_setup_tsc_scaling() is called
>> >> > here.
>> >> > 
>> >> > hvm_vcpu_reset_state() is not called in the migration, so we cannot
>> >> > rely on the call to hvm_setup_tsc_scaling() there.
>> >> 
>> >> All that is understood, but doesn't explain why the scaling setup gets
>> >> done here instead of somewhere after _all_ state got loaded.
>> > 
>> > Because vcpu is waken up at the end of hvm_vcpu_reset_state(), the
>> > setup of TSC scaling should be done before that.
>> 
>> But we're talking about hvm_load_cpu_ctxt() here.
> 
> Sorry for the typo. s/hvm_vcpu_reset_state/hvm_load_cpu_ctxt

Hmm, interesting. I don't really understand why we do so, and I
don't see how this can be correct unless we rely on either something
else to keep the vCPU from running or this always being the last
restored item. Plus the commit that introduced this (89fdf2860a) only
talks about waking APs, yet I don't see any distinction between BP
and APs here.

Andrew - you probably know the restore logic best: Any thoughts?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V2 1/2] xen-netback: limit xen vif max queues number to online cpus

[Joe Jin]

Should not allocate xen vif queues number more than online cpus.

Signed-off-by: Joe Jin 
Cc: Jan Beulich 
Cc: Wei Liu 
Cc: Ian Campbell 
Cc: Boris Ostrovsky 
Cc: Konrad Rzeszutek Wilk 
---
 drivers/net/xen-netback/netback.c |   28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index ec98d43..021dcb0 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -68,7 +68,9 @@ unsigned int rx_stall_timeout_msecs = 6;
 module_param(rx_stall_timeout_msecs, uint, 0444);
 
 unsigned int xenvif_max_queues;
-module_param_named(max_queues, xenvif_max_queues, uint, 0644);
+static int xennet_set_max_queues(const char *val, struct kernel_param *kp);
+module_param_call(max_queues, xennet_set_max_queues, param_get_uint,
+ _max_queues, 0644);
 MODULE_PARM_DESC(max_queues,
 "Maximum number of queues per virtual interface");
 
@@ -107,6 +109,20 @@ static struct xen_netif_rx_response 
*make_rx_response(struct xenvif_queue *queue
 u16  size,
 u16  flags);
 
+static int xennet_set_max_queues(const char *val, struct kernel_param *kp)
+{
+   unsigned int cpus = num_online_cpus();
+   unsigned int max_queues = simple_strtoul(val, NULL, 10);
+
+   if (max_queues == 0 || max_queues > cpus) {
+   pr_info("max_queues %u is out of range [0 - %u]!\n", 
+   max_queues, cpus);
+   return -ERANGE;
+   }
+
+   return param_set_uint(val, kp);
+}
+
 static inline unsigned long idx_to_pfn(struct xenvif_queue *queue,
   u16 idx)
 {
@@ -2110,15 +2126,15 @@ int xenvif_dealloc_kthread(void *data)
 static int __init netback_init(void)
 {
int rc = 0;
+   unsigned int cpus = num_online_cpus();
 
if (!xen_domain())
return -ENODEV;
 
-   /* Allow as many queues as there are CPUs if user has not
-* specified a value.
-*/
-   if (xenvif_max_queues == 0)
-   xenvif_max_queues = num_online_cpus();
+   /* Allow at most as many queues as CPUs. */
+   if (xenvif_max_queues == 0 || xenvif_max_queues > cpus)
+   xenvif_max_queues = cpus;
+   pr_info("vif max_queues: %u\n", xenvif_max_queues);
 
if (fatal_skb_slots < XEN_NETBK_LEGACY_SLOTS_MAX) {
pr_info("fatal_skb_slots too small (%d), bump it to 
XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n",
-- 
1.7.1



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/5] xen/arm: vgic-v2: Don't ignore a write in ITARGETSR if one field is 0

[Ian Campbell]

On Thu, 2015-10-22 at 17:51 +0100, Julien Grall wrote:
> On 22/10/15 17:07, Ian Campbell wrote:
> > > diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
> > > index 665afeb..6b7eab3 100644
> > > --- a/xen/arch/arm/vgic-v2.c
> > > +++ b/xen/arch/arm/vgic-v2.c
> > > @@ -50,6 +50,94 @@ void vgic_v2_setup_hw(paddr_t dbase, paddr_t
> > > cbase,
> > > paddr_t vbase)
> > >  vgic_v2_hw.vbase = vbase;
> > >  }
> > >  
> > > +#define NR_TARGET_PER_REG 4U
> > > +#define NR_BIT_PER_TARGET 8U
> > 
> > NR_TARGETS_ and NR_BITS_...
> > 
> > "REG" there is a bit generic, given this only works for registers with
> > 8
> > -bit fields, _ITARGETSR instead?
> 
> Well this is within the vgic-v2.c and only one register contains target.
> So I found pointless to add ITARGETSR to the name.

It's the use of the generic "REG" when there is only one relevant register
(which could be named) which I found confusing, since the current name
implies it has wider relevance than it actually does.

> > This is really a part of the for() iteration expression, but oddly
> > place
> > here.
> > If you turn the "((1 << NR_BIT_PER_TARGET) - 1)" thing into a #define
> > or
> > constant, then you may find that extracting the relevant byte from the
> > unshifted itargetsr using (itargetsr >> (i*NR_BITS_PER_TARGET) and then
> > applying the mask is clean enough to use here instead.
> 
> I placed this shift here because I didn't want to use ... >> (i *
> NR_BIT_..) which require a multiplication rather than a shift in the
> resulting code.

FWIW given a constant NR_BITS which is a power of two I think i*NR_BITS
would end up a shift with any reasonable compiler.

> > > + * guest).
> > > + */
> > > +if ( !new_target || (new_target > d->max_vcpus) )
> > > +{
> > > +printk(XENLOG_G_DEBUG
> > 
> > gdprintk?
> 
> I would prefer to keep this printk in non-debug to help us catching any
> OS potentially using this trick.
> 
> Based on that I would even use XENLOG_G_WARNING because this is not
> really compliant to the spec and we are meant to fix it.

Assuming I remember correctly that XENLOG_G_WARNING is ratelimited in
default configurations, then OK.

> 
> Regards,
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] limit xen vnic max queues number to online cpu number

[Paul Durrant]

> -Original Message-
> From: Joe Jin [mailto:joe@oracle.com]
> Sent: 23 October 2015 10:05
> To: Paul Durrant; Wei Liu; Ian Campbell; Boris Ostrovsky; Konrad Rzeszutek
> Wilk; David S. Miller
> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Subject: Re: [PATCH 0/2] limit xen vnic max queues number to online cpu
> number
> 
> On 10/23/2015 04:47 PM, Paul Durrant wrote:
> >> -Original Message-
> >> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> >> ow...@vger.kernel.org] On Behalf Of Joe Jin
> >> Sent: 23 October 2015 08:54
> >> To: Wei Liu; Ian Campbell; Boris Ostrovsky; Konrad Rzeszutek Wilk; David
> S.
> >> Miller
> >> Cc: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> >> Subject: [PATCH 0/2] limit xen vnic max queues number to online cpu
> >> number
> >>
> >> Currently xen vnic allowed to create lots of queues by set module param
> >> max_queues(both netback and netfront), when queues number larger
> than
> >> cpu number, it does not help for performance but need more cpu time.
> >>
> >
> > But it's an override, so why would you want to limit it? The parameter
> should not be set in the common case.
> 
> Always we can not stop people use it because we provided it :)
> 

Indeed, and I believe it was provided largely for test purposes... to force the 
limit to whatever the admin wants.

> If queues number is larger than cpu number, with heavy network load,
> cpus have to take more time for interrupt, this lead others less
> chance to be scheduled.
> Imaging dom0 have 64 cpus, and assigned 4 vcpus to the guest, if
> set max_queues to 64 on guest, it will consumed more cpu times
> and bandwidth on backend, I think this is not we expected?
> 

I think that would be entirely expected.

  Paul

> Thanks,
> Joe
> >
> >   Paul
> >
> >> This patchset limit netback and netfront max queues number to online
> >> cpus number.
> >>
> >> Joe Jin (2):
> >>   xen-netback: limit xen vif max queues number to online cpus
> >>   xen-front: limit vnic max_queues number to online cpus
> >>
> >>  drivers/net/xen-netback/netback.c |   28 ++---
> ---
> >>  drivers/net/xen-netfront.c|   27 +--
> >>  2 files changed, 43 insertions(+), 12 deletions(-)
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe netdev" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xl: convert scheduling related return codes to EXIT_[SUCCESS|FAILURE]

[Ian Campbell]

On Fri, 2015-10-23 at 10:30 +0200, Dario Faggioli wrote:
> On Fri, 2015-10-23 at 13:18 +0530, Harmandeep Kaur wrote:
> > turning scheduling related functions xl exit codes towards using the
> > EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> > numbers
> > or libxl return codes.
> > 
> So, it's probably worth mentioning that this is Harman's "bite size
> contribution" that is required for applying to the Outreachy program.
> 
> Harman, when you send a patch series, as you did here (thanks and good
> job doing it so quickly :-) ), you want to include a 'cover letter'. That
> is an introductory email, often labelled (usually automatically by git
> tools) as patch 0 of the series itself. In it, you give a brief
> explanation of what the series is meant at, and any kind of information
> you think the people reviewing the series should have, but that wouldn't
> fit in the various patches' changelogs, code comments, etc.

In particular in this case I would like to know whether all xl functions
now use EXIT_SUCCESS/FAILURE or if there is still inconsistencies/work to
be done.

I don't see any existing use of of EXIT_* in xl*.

> 
> For instance, in this case, you could have mentioned (among other things)
> that this is your small contribution for the sake of applying to
> Outreachy right in there. :-)
> 
> Thanks and Regards,
> Dario

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/5] xen/arm: vgic: Optimize the way to store the target vCPU in the rank

[Julien Grall]

On 23/10/15 11:14, Ian Campbell wrote:
> On Fri, 2015-10-23 at 11:01 +0100, Julien Grall wrote:
>> On 23/10/15 10:34, Ian Campbell wrote:
>>> On Thu, 2015-10-22 at 18:15 +0100, Julien Grall wrote:
 Hi Ian,

 On 22/10/15 17:17, Ian Campbell wrote:
> On Mon, 2015-10-12 at 15:22 +0100, Julien Grall wrote:
>> [...]
>>  /* Only migrate the vIRQ if the target vCPU has changed
>> */
>>  if ( new_target != old_target )
>>  {
>> +unsigned int virq = rank->index *
>> NR_INTERRUPT_PER_RANK
>> + offset;
>
> FWIW this was the value of offset before it was shifted + masked, I
> think.
> Could you not just save it up top and remember it?

 In fact, the virq is already correctly set before the loop (see patch
 #2):

 virq = rank->index * NR_INTERRUPT_PER_RANK + offset;

 The variable is incremented in the for loop. So I just forgot to drop
 this line when I did the split.

 Not that it's not possible to use directly offset because for byte
 access it will point to the byte modified and not the base address of
 the register.

 Though, I could use a mask, but I find this solution clearer.
>>>
>>> But per the above what is actually going to happen is you drop this
>>> change?
>>
>> As said, the introduction of virq within this patch is a mistake.
>> Patch #2 already set virq before the loop:
> 
> I thought that was what you said, but then your final line seemed to
> contradict that by implying that you wanted to keep virq here (the implicat
> ion of saying it is clearer to you).

Sorry, I was speaking about using the unmodified offset. I.e something like

virq = offset & 0x3;

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/3] xl: convert scheduling related return codes to EXIT_[SUCCESS|FAILURE]

[Ian Campbell]

On Fri, 2015-10-23 at 12:03 +0200, Dario Faggioli wrote:
> On Fri, 2015-10-23 at 10:56 +0100, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 10:30 +0200, Dario Faggioli wrote:
> 
> > > Harman, when you send a patch series, as you did here (thanks and
> > > good
> > > job doing it so quickly :-) ), you want to include a 'cover
> > > letter'. That
> > > is an introductory email, often labelled (usually automatically by
> > > git
> > > tools) as patch 0 of the series itself. In it, you give a brief
> > > explanation of what the series is meant at, and any kind of
> > > information
> > > you think the people reviewing the series should have, but that
> > > wouldn't
> > > fit in the various patches' changelogs, code comments, etc.
> > 
> > In particular in this case I would like to know whether all xl
> > functions
> > now use EXIT_SUCCESS/FAILURE or if there is still
> > inconsistencies/work to
> > be done.
> > 
> Exactly, Harman, these are the sort of things you'd include in a cover
> letter for a series like this.
> 
> > I don't see any existing use of of EXIT_* in xl*.
> > 
> I sent a patch turning one function into doing so just yesterday. :-)
> 
> We (me, you and Wei) talked about it a while back (see the changelog of
> that patch, it has the links):
> 
>  https://www.mail-archive.com/xen-devel@lists.xen.org/msg42850.html

Those links to previous discussions like are certainly the sort of
rationale which ought to appear in either a commit log (or a patch #0 if
one exists) as part of the rationale for a change.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Work on a project: Refactor Linux hotplug scripts

[Roger Pau Monné]

El 23/10/15 a les 7.53, Надежда Ампилогова ha escrit:
> Hi all,
> 
> I am interested in the project Refactor Linux hotplug scripts for 
> Outreachy(Round 11). I am more of an intermediate-beginner in c. Please can 
> anyone provide some pointers and helper about the things I need to do to join 
> this project.

Hello,

You have to start by setting up your development system, there's a lot
of information about how to do this on the Xen wiki:

http://wiki.xenproject.org/wiki/Getting_Started
http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
http://wiki.xenproject.org/wiki/Xen_Serial_Console

Since you have to submit a patch before formally applying for OPW, you
will have to get used to git (if you are not yet familiar with it), we
also have a couple of wiki pages about this:

http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches

I personally use stgit in order to manage my patches:

http://wiki.xenproject.org/wiki/Submitting_Xen_Patches_with_StGit

Maybe during this process you will find issues or things that you think
can be improved, if that's the case those patch(es) could be used in
order to fulfil your application. If not, reply back and we will try to
find a suitable small task.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Jan Beulich]

>>> On 23.10.15 at 15:58,  wrote:
> On 23/10/15 14:52, Jan Beulich wrote:
> On 23.10.15 at 15:30,  wrote:
>>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
 Hi,

 On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
>
> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> of function 'typeof' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]

 Ping? Aside the fact that other bits of the header may not be iso
 compliant, I still think this patch is valid.
>>>
>>> Yes, I agree.
>>> Acked-by: Ian Campbell 
>>>
>>> Jan, after your earlier comments are you happy to go ahead with this for
>>> now and sort the other possible issues separately?
>> 
>> Well - it's an improvement, sure, so I'm not intending to block it
>> going in if no better way can be determined in its place right away.
>> What makes me hesitant is that I'm not sure there indeed will be a
>> follow up to this any time soon.
> 
> TBH, having a script which check the validity of the headers is not in
> the top my todo list. Though it would be nice to have it.

No, the validating script is a nice-to-have, but nothing more. What
I was referring to was a patch to drop the use of this gcc extension.

> But I don't think we should delay this valid patch just because we don't
> have time to write a such script.

As said - I don't intend to block the patch going in; I'm just not
convinced that allowing it to go in won't result in not follow up at all.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Ian Campbell]

On Fri, 2015-10-23 at 15:31 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > > On 23.10.15 at 15:58,  wrote:
> > > On 23/10/15 14:52, Jan Beulich wrote:
> > > > > > > On 23.10.15 at 15:30,  wrote:
> > > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 04/10/15 20:24, Julien Grall wrote:
> > > > > > > The keyword typeof is not portable:
> > > > > > > 
> > > > > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > > > > declaration
> > > > > > > of function 'typeof' is invalid in C99
> > > > > > > [-Werror,-Wimplicit-function-declaration]
> > > > > > 
> > > > > > Ping? Aside the fact that other bits of the header may not be
> > > > > > iso
> > > > > > compliant, I still think this patch is valid.
> > > > > 
> > > > > Yes, I agree.
> > > > > Acked-by: Ian Campbell 
> > > > > 
> > > > > Jan, after your earlier comments are you happy to go ahead with
> > > > > this for
> > > > > now and sort the other possible issues separately?
> > > > 
> > > > Well - it's an improvement, sure, so I'm not intending to block it
> > > > going in if no better way can be determined in its place right
> > > > away.
> > > > What makes me hesitant is that I'm not sure there indeed will be a
> > > > follow up to this any time soon.
> > > 
> > > TBH, having a script which check the validity of the headers is not
> > > in
> > > the top my todo list. Though it would be nice to have it.
> > 
> > No, the validating script is a nice-to-have, but nothing more. What
> > I was referring to was a patch to drop the use of this gcc extension.
> 
> Then I'm confused. This patch turns a typeof into a __typeof__. In <
> 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof() is a
> gcc extension".
> 
> Are you now saying that __typeof__ also a gcc extension too?
> 
> I was under the impression that __typeof__ was standard (by some cxx at
> least) and your mail reinforced that (possibly wrong) impression.

Hrm, it seems I was indeed wrong here and __typeof__ is just an alternative
name for the gcc extension keyword which is not subject to -ansi.

Ian.

> 
> https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you are
> writing a header file that must work when included in ISO C programs,
> write
> __typeof__ instead of typeof", which also lead me to believe __typeof__
> was
> OK from this PoV.
> 
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Dario Faggioli]

On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:

> Looking at those links, I'm not sure that either you or myself was
> thinking
> of using EXIT_* as function return values, just that the eventual
> process
> exit would become one of those values instead of some negative
> number.
>
Exactly.

> Although the thread doesn't look like it is too clear if it is
> talking
> about return values from functions vs. process exit codes.
> 
Well, independently from the thread, I certainly meant that I think
EXIT_* should be used as process exit status, not as internal
functions' return value.

> I think what I would have been expecting is for the xl internal error
> code
> would become EXIT_* either in the call to exit() or the return from
> main
> instead of being the process exit code directly.
> 
But, in this specific case, and in cases of main_foo() functions in
xl_cmdimpl.c, it's exactly like that, isn't it?

...
if (cspec) {
if (dryrun_only && !cspec->can_dryrun) {
fprintf(stderr, "command does not implement -N (dryrun) option\n");
ret = 1;
goto xit;
}
ret = cspec->cmd_impl(argc, argv);
} else if (!strcmp(cmd, "help")) {
help(argv[1]);
ret = 0;
} else {
fprintf(stderr, "command not implemented\n");
ret = 1;
}

 xit:
return ret;
}

(from main() in xl.c)

> Seeing "return EXIT_FOO" outside of a main function seems rather
> strange to
> me.
> 
Well, same here. Except, given xl architecture, I was considering
main_foo() functions in xl_cmdimpl.c as some king of extensions of the
actual main function.

The alternative would be to always use, say, 0 and 1 in xl_cmdimpl.c,
and then convert them to EXIT_SUCCESS or EXIT_FAILURE in xl.c (for
return-s, of course, exit()-s need to use them no matter where they
are).

I'm fine with either, so, if you prefer the latter, I certainly can
arrange for doing things that way.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] arm64: iomem_resource doesn't contain all the region used

[Ian Campbell]

On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
> Is there any way we could register the IO region used on ARM without
> having to enforce it in all the drivers?

This seems like an uphill battle to me.

Why not do as I suggested IRL yesterday and expose the map of "potential
RAM" addresses to the guest as well as the "actual RAM" addresses in the
regular memory properties.

i.e. explicitly expose the holes where RAM can be hotplugged later.

This is even analogous to a native memory hotplug case, which AIUI
similarly involves the provisioning of specific address space where RAM
might plausibly appear in the future (I don't think physical memory hotplug
involves searching for free PA space and hoping for the best, although
strange things have happened I guess).

With any luck you would be able to steal or define the bindings in terms of
the native hotplug case rather than inventing some Xen specific thing.

In terms of dom0 the "potential" RAM is the host's actual RAM banks.

In terms of domU the "potential" RAM is defined by the domain builder
layout (currently the two banks mentioned in Xen's arch-arm.h).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] xl: Die on unknown options

[Ian Jackson]

def_getopt would print a message to stderr, but blunder on anyway.

Sadly this is probably not a backport candidate.

Signed-off-by: Ian Jackson 
---
 tools/libxl/xl_cmdimpl.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ea43761..de28593 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2759,6 +2759,7 @@ static int def_getopt(int argc, char * const argv[],
 exit(0);
 }
 fprintf(stderr, "option `%c' not supported.\n", optopt);
+exit(2);
 }
 if (opt == 'h') {
 help(helpstr);
-- 
1.7.10.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Ian Campbell]

On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> 
> > Looking at those links, I'm not sure that either you or myself was
> > thinking
> > of using EXIT_* as function return values, just that the eventual
> > process
> > exit would become one of those values instead of some negative
> > number.
> > 
> Exactly.
> 
> > Although the thread doesn't look like it is too clear if it is
> > talking
> > about return values from functions vs. process exit codes.
> > 
> Well, independently from the thread, I certainly meant that I think
> EXIT_* should be used as process exit status, not as internal
> functions' return value.
> 
> > I think what I would have been expecting is for the xl internal error
> > code
> > Well, same here. Except, given xl architecture, I was considering
> main_foo() functions in xl_cmdimpl.c as some king of extensions of the
> actual main function.

I had somehow convinced myself that these weren't being added in a
main_foo, I agree that main_foo should be treated somewhat like a regular
main().

Sorry for the noise.

> I'm fine with either, so, if you prefer the latter, I certainly can
> arrange for doing things that way.

It would be helpful to a) not combine this change with the logging change
and to b) include as part of the patch some sort of document comment in
some relevant xl-ish place explaining some of this stuff (i.e. that an xl
process should always return EXIT_FOO and that main_* can be treated like
main() as if they are returning a process exit status and not a function
return value).

I think it would also be useful to have xl's main() DTRT before starting to 
convert main_*. Currently it returns explicit 0 or 1 or the result of the 
main_*.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Dario Faggioli]

On Fri, 2015-10-23 at 16:40 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> > On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:

> > > I think what I would have been expecting is for the xl internal
> > > error
> > > code
> > Well, same here. Except, given xl architecture, I was considering
> > main_foo() functions in xl_cmdimpl.c as some king of extensions of
> > the
> > actual main function.
> 
> I had somehow convinced myself that these weren't being added in a
> main_foo, I agree that main_foo should be treated somewhat like a
> regular
> main().
> 
Ok, glad to see we're on the same page.

> Sorry for the noise.
> 
NP. :-)

> > I'm fine with either, so, if you prefer the latter, I certainly can
> > arrange for doing things that way.
> 
> It would be helpful to a) not combine this change with the logging 
> change
>
Sure, I'll resend the patch without changing that.

> b) include as part of the patch some sort of document comment in
> some relevant xl-ish place explaining some of this stuff (i.e. that
> an xl
> process should always return EXIT_FOO and that main_* can be treated
> like
> main() as if they are returning a process exit status and not a
> function
> return value).
> 
About this...

> I think it would also be useful to have xl's main() DTRT before
> starting to convert main_*. Currently it returns explicit 0 or 1 or
> the result of the main_*.
> 
... and this, I'll see if I can convince Harman to pick these up, as
part of her work on the subject. :-P :-P

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.5-testing test] 63214: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 63214 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63214/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep   fail REGR. vs. 63099
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
63099

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 63099
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 63099
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 63099
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 63099
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 63099

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass

version targeted for testing:
 xen  a5d0480d9c5b36b5f47459ce92ed3c67b7bed51d
baseline version:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17

Last test of basis63099  2015-10-20 17:40:41 Z2 days
Failing since 63155  2015-10-21 15:43:44 Z2 days2 attempts
Testing same since63214  2015-10-22 13:24:43 Z1 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Jan Beulich 
  Julien Grall 
  Wei Liu 
  Yang Zhang 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 

Re: [Xen-devel] [PATCH V2 2/2] xen-netfront: limit vnic max_queues number to online cpus

[Jan Beulich]

>>> On 23.10.15 at 11:19,  wrote:
>  
> @@ -164,6 +166,19 @@ struct netfront_rx_info {
>   struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX - 1];
>  };
>  
> +static int xennet_set_max_queues(const char *val, struct kernel_param *kp)
> +{
> + unsigned int cpus = num_online_cpus();
> + unsigned int max_queues = simple_strtoul(val, NULL, 10);
> +
> + if (max_queues == 0 || max_queues > cpus) {
> + pr_err("max_queues %u is out of range [0 - %u]!\n", 

I suppose you mean "...[1 - %u]!\n" here?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V3 0/2] limit xen vnic max queues number to online cpus number

[Joe Jin]

Currently xen vnic allowed to create lots of queues by set module param
max_queues(both netback and netfront), when queues number larger than
cpus number, it does not help for performance but need more cpu time.

This patchset limit netback and netfront max queues number to online
cpus number.

Joe Jin (2):
  xen-netback: limit xen vif max queues number to online cpus
  xen-netfront: limit vnic max_queues number to online cpus

---
Changes in v3:
  - Corrected the range info [1-CPUs].

Changes in v2:
  - Replace param_get_int to param_get_uint.
  - Use '%u' for unsigned int when print.
  - Replace EINVAL to ERANGE when out of range [0-CPUs].
  - Reset the perm of max_queues on sysfs to 0644.

 drivers/net/xen-netback/netback.c |   28 ++--
 drivers/net/xen-netfront.c|   28 ++--
 2 files changed, 44 insertions(+), 12 deletions(-)


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 02:01 -0600, Jan Beulich wrote:
> > > > > On 22.10.15 at 19:08,  wrote:
> > > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > > changeset"):
> > > > On Thu, 22 Oct 2015, Ian Campbell wrote:
> > > > > This was discussed prior to Wei submitting this patch, but I can't
> > > > > remember
> > > > > the reference. Hopefully either Wei or Stefano does.
> > > > 
> > > > 1444832748.23192.213.ca...@citrix.com 
> > > 
> > > Thanks for the reference.
> > > 
> > > I'm quite uncomfortable with this, really.
> > > 
> > > People who are using xen.git stable branches ought to get only changes
> > > that we (or perhaps, someone else whose judgement we have some reason
> > > to trust) have intentionally decided are suitable for deployment as a
> > > bugfix or security update in an existing installation.
> > > 
> > > Ie, changes in stable branches are supposed to be low risk.  That's
> > > not compatible with tracking an upstream development branch.
> > 
> > FWIW, I agree. Do we know of specific commits that we actually
> > need?
> 
> Yes. Those (that?) and the reasons why we aren't just trivially taking them
> are explained in the referenced thread.
> 
> Really this is about adding a new feature (arm64 support for ovmf) into
> 4.6.1 for Raisin's benefit.

This is not just about Raisin. What's going to happen when we fix a bug
in OVMF (http://marc.info/?l=xen-devel=144552787020580) which we think
needs to be backport to 4.6?

I cannot believe we are going to move forward without a way to introduce
any OVMF fixes into the  stable branches.


> My personal preference, given the arguments made in the thread, would be
> for raisin to just point at mainline ovmf for the arm64 case. IOW
> acknowledge that arm64 ovmf was not actually part of the 4.6 release and
> that we should work towards making it not a special case in the 4.7 release
> (by, you know, testing it prior to release and things like that).

Let's now lose the focus of the conversation by talking about this
specific backport request. We can always find ways around this in
Raisin.

The real problem is: what are we going to do about backport requests for
OVMF in general?

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU-XEN v4 9/9] xen: make it possible to build without the Xen PV domain builder

[Ian Campbell]

On Fri, 2015-10-23 at 12:35 +0100, Stefano Stabellini wrote:
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:12 +0100, Stefano Stabellini wrote:
> > > @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
> > > >fi
> > > >  fi
> > > >  
> > > > +if test "$xen_pv_domain_build" != "no"; then
> > > > +  if test "$xen_pv_domain_build" = "yes" &&
> > > > + test "$xen" != "yes"; then
> > > > +  error_exit "User requested Xen PV domain builder support" \
> > > > +"which requires Xen support."
> > > > +  fi
> > > > +  xen_pv_domain_build=no
> > > > +fi
> > > 
> > > Can we simplify this to:
> > > 
> > >   if test "$xen_pv_domain_build" = "yes" &&
> > >test "$xen" != "yes"; then
> > > error_exit "User requested Xen PV domain builder support" \
> > >"which requires Xen support."
> > > fi
> > >   fi
> > > 
> > > and move xen_pv_domain_build=no at the beginning of the file?
> > 
> > I think so, I hadn't noticed the precedent for doing so further up in
> > the
> > file.
> > 
> > Just to check, is this still your preference after my earlier reply-to
> > -self
> > explaining why the code above is utter rubbish and proposing a
> > different
> > simplified version?
> 
> The simplified check is OK, but I would still prefer if you moved
> xen_pv_domain_build=no at the beginning of the file.

Ack, I'll do that then.
> 
> 
> > @@ -46,13 +43,22 @@ static void xen_init_pv(MachineState *machine)
> > > >  case XEN_ATTACH:
> > > >  /* nothing to do, xend handles everything */
> > > >  break;
> > > > -case XEN_CREATE:
> > > > +case XEN_CREATE: {
> > > > +#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
> > > > +const char *kernel_filename = machine->kernel_filename;
> > > > +const char *kernel_cmdline = machine->kernel_cmdline;
> > > > +const char *initrd_filename = machine->initrd_filename;
> > > >  if (xen_domain_build_pv(kernel_filename, initrd_filename,
> > > >  kernel_cmdline) < 0) {
> > > >  fprintf(stderr, "xen pv domain creation failed\n");
> > > >  exit(1);
> > > >  }
> > > > +#else
> > > > +fprintf(stderr, "xen pv domain creation not supported\n");
> > > > +exit(1);
> > > > +#endif
> > > >  break;
> > > > +}
> > > >  case XEN_EMULATE:
> > > >  fprintf(stderr, "xen emulation not implemented (yet)\n");
> > > >  exit(1);
> > > 
> > > Please add a default case with an error and place the XEN_CREATE
> > > entirely within the ifdef CONFIG_XEN_PV_DOMAIN_BUILD.
> > 
> > Will do.
> > 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] passthrough: improve interrupt injection locking

[David Vrabel]

On 23/10/15 13:37, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
>> When injecting an interrupt for a passthrough device into a guest, the
>> per-domain event_lock is held, reducing performance when a guest has
>> many VCPUs and high interrupt rates.
> 
> Did you CC me due to a possible impact on ARM? If so then I think since ARM
> lacks this "dpci" stuff none of these changes should have any impact on
> that arch.
> 
> If you think I've missed something or you CCd me for some other reason
> please let me know.

This series seems to fall into "THE REST" category.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 03/13] python: remove flask related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any flask related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 238 --
 1 file changed, 238 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index d75f98c..c904627 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -20,8 +20,6 @@
 #include 
 #include 
 
-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
-
 /* Needed for Python versions earlier than 2.3. */
 #ifndef PyMODINIT_FUNC
 #define PyMODINIT_FUNC DL_EXPORT(void)
@@ -30,8 +28,6 @@
 #define PKG "xen.lowlevel.xc"
 #define CLS "xc"
 
-#define FLASK_CTX_LEN 1024
-
 static PyObject *xc_error_obj, *zero;
 
 typedef struct {
@@ -1855,187 +1851,6 @@ static PyObject *pyxc_cpupool_freeinfo(XcObject *self)
 return info;
 }
 
-static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
- PyObject 
*kwds)
-{
-xc_interface *xc_handle;
-char *ctx;
-uint32_t sid;
-int ret;
-
-static char *kwd_list[] = { "context", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s", kwd_list,
-  ) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), );
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return PyInt_FromLong(sid);
-}
-
-static PyObject *pyflask_sid_to_context(PyObject *self, PyObject *args,
- PyObject 
*kwds)
-{
-xc_interface *xc_handle;
-uint32_t sid;
-char ctx[FLASK_CTX_LEN];
-uint32_t ctx_len = FLASK_CTX_LEN;
-int ret;
-
-static char *kwd_list[] = { "sid", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  ) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("s", ctx, ctx_len);
-}
-
-static PyObject *pyflask_load(PyObject *self, PyObject *args, PyObject *kwds)
-{
-xc_interface *xc_handle;
-char *policy;
-uint32_t len;
-int ret;
-
-static char *kwd_list[] = { "policy", NULL };
-  
-if( !PyArg_ParseTupleAndKeywords(args, kwds, "s#", kwd_list, , 
) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_load(xc_handle, policy, len);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_getenforce(PyObject *self)
-{
-xc_interface *xc_handle;
-int ret;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_getenforce(xc_handle);
-
-xc_interface_close(xc_handle);
-
-if ( ret < 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_setenforce(PyObject *self, PyObject *args,
-PyObject *kwds)
-{
-xc_interface *xc_handle;
-int mode;
-int ret;
-
-static char *kwd_list[] = { "mode", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  ) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_setenforce(xc_handle, mode);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_access(PyObject *self, PyObject *args,
-   PyObject *kwds)
-{
-xc_interface *xc_handle;
-char *tcon, *scon;
-uint16_t tclass;
-uint32_t req, allowed, decided, auditallow, auditdeny, seqno;
-int ret;
-
-static char *kwd_list[] = { "src_context", "tar_context", 
-

[Xen-devel] [PATCH 09/13] python: remove domain handling related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of domain handling related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 358 --
 1 file changed, 358 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 02f1694..5146a2d 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -36,9 +36,6 @@ typedef struct {
 } XcObject;
 
 
-static PyObject *dom_op(XcObject *self, PyObject *args,
-int (*fn)(xc_interface *, uint32_t));
-
 static PyObject *pyxc_error_to_exception(xc_interface *xch)
 {
 PyObject *pyerr;
@@ -78,136 +75,6 @@ static PyObject *pyxc_error_to_exception(xc_interface *xch)
 return NULL;
 }
 
-static PyObject *pyxc_domain_dumpcore(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-char *corefile;
-
-if ( !PyArg_ParseTuple(args, "is", , ) )
-return NULL;
-
-if ( (corefile == NULL) || (corefile[0] == '\0') )
-return NULL;
-
-if ( xc_domain_dumpcore(self->xc_handle, dom, corefile) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_create(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom = 0, ssidref = 0, flags = 0, target = 0;
-int  ret, i;
-PyObject *pyhandle = NULL;
-xen_domain_handle_t handle = { 
-0xde, 0xad, 0xbe, 0xef, 0xde, 0xad, 0xbe, 0xef,
-0xde, 0xad, 0xbe, 0xef, 0xde, 0xad, 0xbe, 0xef };
-
-static char *kwd_list[] = { "domid", "ssidref", "handle", "flags", 
"target", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iiOii", kwd_list,
-  , , , , 
))
-return NULL;
-if ( pyhandle != NULL )
-{
-if ( !PyList_Check(pyhandle) || 
- (PyList_Size(pyhandle) != sizeof(xen_domain_handle_t)) )
-goto out_exception;
-
-for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
-{
-PyObject *p = PyList_GetItem(pyhandle, i);
-if ( !PyInt_Check(p) )
-goto out_exception;
-handle[i] = (uint8_t)PyInt_AsLong(p);
-}
-}
-
-if ( (ret = xc_domain_create(self->xc_handle, ssidref,
- handle, flags, )) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-if ( target )
-if ( (ret = xc_domain_set_target(self->xc_handle, dom, target)) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-
-return PyInt_FromLong(dom);
-
-out_exception:
-errno = EINVAL;
-PyErr_SetFromErrno(xc_error_obj);
-return NULL;
-}
-
-static PyObject *pyxc_domain_max_vcpus(XcObject *self, PyObject *args)
-{
-uint32_t dom, max;
-
-if (!PyArg_ParseTuple(args, "ii", , ))
-  return NULL;
-
-if (xc_domain_max_vcpus(self->xc_handle, dom, max) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_pause(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_pause);
-}
-
-static PyObject *pyxc_domain_unpause(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_unpause);
-}
-
-static PyObject *pyxc_domain_destroy_hook(XcObject *self, PyObject *args)
-{
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_destroy(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_destroy);
-}
-
-static PyObject *pyxc_domain_shutdown(XcObject *self, PyObject *args)
-{
-uint32_t dom, reason;
-
-if ( !PyArg_ParseTuple(args, "ii", , ) )
-  return NULL;
-
-if ( xc_domain_shutdown(self->xc_handle, dom, reason) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_resume(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-int fast;
-
-if ( !PyArg_ParseTuple(args, "ii", , ) )
-return NULL;
-
-if ( xc_domain_resume(self->xc_handle, dom, fast) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -259,42 +126,6 @@ static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
 return zero;
 }
 
-static PyObject *pyxc_domain_sethandle(XcObject *self, PyObject *args)
-{
-int i;
-uint32_t dom;
-PyObject *pyhandle;
-xen_domain_handle_t handle;
-
-if (!PyArg_ParseTuple(args, "iO", , ))
-return 

[Xen-devel] [PATCH 01/13] libxc: remove most of tools/libxc/xc_dom_compat_linux.c

[Juergen Gross]

In tools/libxc/xc_dom_compat_linux.c xc_linux_build() is the only
domain building function used by an in-tree component (qemu-xen) which
is really necessary.

Remove the other domain building functions and the unused python
wrapper xc.linux_build() referencing one of the to be removed
functions.

Suggested-by: Ian Campbell 
Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h  |   5 ++
 tools/libxc/include/xenguest.h|  48 -
 tools/libxc/xc_dom_compat_linux.c | 141 --
 tools/libxl/libxl_internal.h  |   1 +
 tools/python/xen/lowlevel/xc/xc.c |  98 --
 5 files changed, 36 insertions(+), 257 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ccc5926..6c15589 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -13,6 +13,9 @@
  * License along with this library; If not, see .
  */
 
+#ifndef _XC_DOM_H
+#define _XC_DOM_H
+
 #include 
 #include 
 
@@ -406,6 +409,8 @@ static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
+#endif /* _XC_DOM_H */
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index ec67fbd..a9fa32c 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -151,54 +151,6 @@ int xc_linux_build(xc_interface *xch,
unsigned int console_evtchn,
unsigned long *console_mfn);
 
-/** The same interface, but the dom structure is managed by the caller */
-struct xc_dom_image;
-int xc_dom_linux_build(xc_interface *xch,
-  struct xc_dom_image *dom,
-  uint32_t domid,
-  unsigned int mem_mb,
-  const char *image_name,
-  const char *ramdisk_name,
-  unsigned long flags,
-  unsigned int store_evtchn,
-  unsigned long *store_mfn,
-  unsigned int console_evtchn,
-  unsigned long *console_mfn);
-
-/**
- * This function will create a domain for a paravirtualized Linux
- * using buffers for kernel and initrd
- *
- * @parm xch a handle to an open hypervisor interface
- * @parm domid the id of the domain
- * @parm mem_mb memory size in megabytes
- * @parm image_buffer buffer containing kernel image
- * @parm image_size size of the kernel image buffer
- * @parm initrd_buffer name of the ramdisk image file
- * @parm initrd_size size of the ramdisk buffer
- * @parm cmdline command line string
- * @parm flags domain creation flags
- * @parm store_evtchn the store event channel for this domain to use
- * @parm store_mfn returned with the mfn of the store page
- * @parm console_evtchn the console event channel for this domain to use
- * @parm conole_mfn returned with the mfn of the console page
- * @return 0 on success, -1 on failure
- */
-int xc_linux_build_mem(xc_interface *xch,
-   uint32_t domid,
-   unsigned int mem_mb,
-   const char *image_buffer,
-   unsigned long image_size,
-   const char *initrd_buffer,
-   unsigned long initrd_size,
-   const char *cmdline,
-   const char *features,
-   unsigned long flags,
-   unsigned int store_evtchn,
-   unsigned long *store_mfn,
-   unsigned int console_evtchn,
-   unsigned long *console_mfn);
-
 struct xc_hvm_firmware_module {
 uint8_t  *data;
 uint32_t  length;
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index 5c1f043..20521cf 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -34,74 +34,26 @@
 
 /*  */
 
-static int xc_linux_build_internal(struct xc_dom_image *dom,
-   xc_interface *xch, uint32_t domid,
-   unsigned int mem_mb,
-   unsigned long flags,
-   unsigned int store_evtchn,
-   unsigned long *store_mfn,
-   unsigned int console_evtchn,
-   unsigned long *console_mfn)
-{
-int rc;
-
-dom->flags = flags;
-dom->console_evtchn = console_evtchn;
-dom->xenstore_evtchn = store_evtchn;
-
-if ( (rc = xc_dom_boot_xen_init(dom, xch, domid)) != 0 )
-goto out;
-if ( (rc = xc_dom_parse_image(dom)) != 0 )
-goto out;
-if ( (rc = xc_dom_mem_init(dom, mem_mb)) != 0 )
- 

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Fabio Fantoni]

Il 23/10/2015 14:56, Ian Campbell ha scritto:

On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:

We have no existing stable baseline for that arch, and no testing or
reason to believe that cb9a7eb (the Config.mk version currently
referenced by 4.6) as being any good at all on that platform,
whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.

20% of the patches since then are ARM related and I'm not sure that a quick
smoke test is a high enough bar to add something in a stable point release
(it might suffice for adding to the development branch and subsequently
releasing, after plenty of time and -rc's, test days etc)


I'm not convinced that taking some arbitrary old (although not as old
as I
thought) OVMF tree which we have tested to our satisfaction and
released on
x86, slapping a couple of arm64 backports on it and saying "this is now
a
good and stable thing to use on arm64" makes it good enough to release
as
ovmf arm64 in 4.6.1, encouraging our users to go about using etc.

Far better to be honest about it for now and point arm64 users at a
more
bleeding edge ovmf release outside of our own stable releases and
prepare
to do something better in 4.7.
  
Are you suggesting we don't create an OVMF branch for 4.6 until the

first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

I'm not against having an OVMF branch ready for any potential bug fixes
which might crop up in the feature set we released and in future we should
probably create one as a matter of course as part of branching.

What I don't like is adding OVMF/arm64 as a new feature in a point release
with very little of the usual confidence we would have in something we
would add in a 4.6.0, let alone a 4.6.1.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel


A recent ovmf patch (already tested) I think is good to backport is:
0f34a051104e2b1b9123d56d48673de4b21bc533 - OvmfPkg: XenPvBlkDxe: handle 
empty cdrom drives
Can be considered please? Without any domU using ovmf and having empty 
cdrom (required for cd hotplug) freeze on boot start.


There is also another important occasional bug (reported and linked also 
by Stefano Stabellini) but without solution for now where is good 
backport any fixes related when will be done.


Thanks for any reply and sorry for my bad english.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 3/3] xl: convert cpupool related return codes to EXIT_[SUCCESS|FAILURE]

[Harmandeep Kaur]

On Fri, Oct 23, 2015 at 5:40 PM, Dario Faggioli 
wrote:

> >  int main_cpupooldestroy(int argc, char **argv)
> > @@ -7580,13 +7580,13 @@ int main_cpupooldestroy(int argc, char
> > **argv)
> >  if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, ,
> > NULL) ||
> >  !libxl_cpupoolid_is_valid(ctx, poolid)) {
> >  fprintf(stderr, "unknown cpupool '%s'\n", pool);
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  if (libxl_cpupool_destroy(ctx, poolid))
> > -return 1;
> > +return EXIT_FAILURE;
> >
> > -return 0;
> > +return EXIT_SUCCESS;
> >  }
> >
> For this one: I've sent a patch for another reason yesterday, and while
> there I did the exit code adjustment myself. So, update your tree and,
> if my patch has been committed already, just skip this function.
>
>  https://www.mail-archive.com/xen-devel@lists.xen.org/msg42850.html
>
> Which brings up a question: what git tree are you using for
> development? You should stay either on master or staging branches (and
> I recommend staging) of the official repository:
>
>  http://wiki.xenproject.org/wiki/Xen_Project_Repositories


I was on master branch, now switching to staging.

Thank you so much for reviewing my patch and helping on this tight
timeline. And regarding your other questions (patch 1 and 2) I will be
answering as I digest all the information you just passed :)

Again, thank you Dario. I really appreciate your help.

Warmest Regards :)
Harman


> > @@ -7653,7 +7653,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
> >
> >  out:
> >  libxl_bitmap_dispose();
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >
> Same as already said for main_cpupoolcreate, just us rc.
>
> > @@ -7691,7 +7691,7 @@ int main_cpupoolcpuremove(int argc, char
> > **argv)
> >
> >  out:
> >  libxl_bitmap_dispose();
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >
> And here.
>
> >  int main_cpupoolnumasplit(int argc, char **argv)
> > @@ -7758,7 +7758,7 @@ int main_cpupoolnumasplit(int argc, char
> > **argv)
> >  poolinfo = libxl_list_cpupool(ctx, _pools);
> >  if (!poolinfo) {
> >  fprintf(stderr, "error getting cpupool info\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >  poolid = poolinfo[0].poolid;
> >  sched = poolinfo[0].sched;
> > @@ -7766,13 +7766,13 @@ int main_cpupoolnumasplit(int argc, char
> > **argv)
> >
> >  if (n_pools > 1) {
> >  fprintf(stderr, "splitting not possible, already cpupools in
> > use\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  topology = libxl_get_cpu_topology(ctx, _cpus);
> >  if (topology == NULL) {
> >  fprintf(stderr, "libxl_get_topologyinfo failed\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  if (libxl_cpu_bitmap_alloc(ctx, , 0)) {
> > @@ -7869,7 +7869,7 @@ out:
> >  libxl_dominfo_dispose();
> >  free(name);
> >
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >  }
> >
> And here too.
>
> Thanks and regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.3-testing test] 63212: tolerable FAIL - PUSHED

[osstest service owner]

flight 63212 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/63212/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail in 63151 pass 
in 63212
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
63151

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62742

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 63151 never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  85ca813ec23c5a60680e4a13777dad530065902b
baseline version:
 xen  998424e33db121270690586320e899a03c88b4aa

Last test of basis62742  2015-10-09 07:58:29 Z   14 days
Failing since 63098  2015-10-20 17:42:44 Z2 days3 attempts
Testing same since63151  2015-10-21 15:41:31 Z1 days2 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64  

Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

[Dario Faggioli]

On Fri, 2015-10-23 at 15:42 +0200, Juergen Gross wrote:
> On 10/21/2015 07:10 PM, Dario Faggioli wrote:

> > Also, all the operations done in schedule_cpu_switch() itself,
> > depend
> > either on per_cpu(scheduler) or on per_cpu(schedule_data) being
> > updated
> > properly, rather than on per_cpu(cpupool) (including the locking
> > that
> > you are mentioning above).
> > 
> > What am I missing?
> 
> Hmm, good question. I'm rather sure I had a problem related to
> exactly
> this topic in the early days of cpupools. Maybe the critical code has
> been modified since then. Or my memory is wrong. 
>
From a quick archeological investigation, some things certainly have
changed. Still, I can't spot anything directly related to this, but
it's quite possible that it's there and I'm missing it.

> Or we both don't see
> it now. ;-)
> 
Yep! :-)

> In case there is a problem it should show up doing a test which
> concurrently does all of the following:
> 
> - move a domain between two cpupools
> - move a cpu between the two cpupools
> - create and destroy a domain in one of the two cpupools
> 
Ok, I'll arrange for this and report.

> If the system is surviving this test for a couple of hours you are
> fine
> and then for the attached patch:
> 
> Acked-by: Juergen Gross 
> 
Thanks :-)
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

[Ian Campbell]

On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 23/10/15 14:28, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> > > The GICv2 DT node is usually used by the guest to know the
> > > address/size
> > > of the regions (GICD, GICC...) to map into their virtual memory.
> > > 
> > > While the GICv2 spec requires the size of the GICC to be 8KB, we
> > > correctly do an 8KB stage-2 mapping but errornously report 256 in the
> > > device tree (based on GUEST_GICC_SIZE).
> > 
> > "erroneously"
> > 
> > > 
> > > I bet we didn't see any issue so far because all the registers except
> > > GICC_DIR lives in the first 256 bytes of the GICC region and all the
> > > guest
> > 
> > "guests"
> > 
> > > I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
> > > 0.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Acked-by: Ian Campbell 
> > 
> > (typo's fixable on commit).
> 
> Thank you!
> 
> > > ---
> > > This patch is a good candidate to backport for Xen 4.6 - 4.4.
> > > Without it a guest relying on the DT can't use GICC_DIR.
> > 
> > Noted, but just to check: This patch (and none of the other fixes in
> > this
> > series) are all which are required for a guest to be able to use
> > GICC_DIR,
> > right?
> 
> Correct. BTW, I forgot to mention that this patch may not apply cleanly
> on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.

I'd be inclined not to bother with it for 4.4 at this juncture then.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Ian Campbell]

On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> Hi,
> 
> On 04/10/15 20:24, Julien Grall wrote:
> > The keyword typeof is not portable:
> > 
> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> > of function 'typeof' is invalid in C99
> > [-Werror,-Wimplicit-function-declaration]
> 
> Ping? Aside the fact that other bits of the header may not be iso
> compliant, I still think this patch is valid.

Yes, I agree.
Acked-by: Ian Campbell 

Jan, after your earlier comments are you happy to go ahead with this for
now and sort the other possible issues separately?

> 
> FWIW, it fixed build of the FreeBSD kernel for ARM64 with Xen enabled.
> 
> Regards,
> 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 3/4] xen/arm: gic-v2: Automatically detect aliased GIC400

[Ian Campbell]

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> We are currently using a per-platform quirk to know if the 2 4KB region
> of
> the GIC CPU interface are each aligned to 64KB. Although, it may be
> possible to have different layout on a same platform (depending on the
> firmware version).
> 
> Rather than having a quirk it's possible to detect by reading the GIC
> memory. This patch is based from the Linux commit "irqchip/GIC: Add
> workaround
> for aliased GIC400" [1].
> 
> Take the opportunity to clean up the GICv2 of code which was only
> required because of the quirk.
> 
> Note that none of the platform using the gic-hip04 were actually using
> the quirk, so the code has been dropped. I will let the maintainers
> decide whether it's relevant or not to add proper detection for aliased
> GIC for this hardware.
> 
> [1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
> Author: Marc Zyngier 
> Date:   Sun Sep 13 12:14:31 2015 +0100
> 
> irqchip/GIC: Add workaround for aliased GIC400
> 
> The GICv2 architecture mandates that the two 4kB GIC regions are
> contiguous, and on two separate physical pages (so that access to
> the second page can be trapped by a hypervisor). This doesn't work
> very well when PAGE_SIZE is 64kB.
> 
> A relatively common hack^Wway to work around this is to alias each
> 4kB region over its own 64kB page. Of course in this case, the base
> address you want to use is not really the begining of the region,
> but base + 60kB (so that you get a contiguous 8kB region over two
> distinct pages).
> 
> Normally, this would be described in DT with a new property, but
> some HW is already out there, and the firmware makes sure that
> it will override whatever you put in the GIC node. Duh. And of
> course,
> said firmware source code is not available, despite being based
> on u-boot.
> 
> The workaround is to detect the case where the CPU interface size
> is set to 128kB, and verify the aliasing by checking that the ID
> register for GIC400 (which is the only GIC wired this way so far)
> is the same at base and base + 0xF000. In this case, we update
> the GIC base address and let it roll.
> 
> And if you feel slightly sick by looking at this, rest assured that
> I do too...
> 
> Reported-by: Julien Grall 
> Signed-off-by: Marc Zyngier 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Stuart Yoder 
> Cc: Pavel Fedin 
> Cc: Jason Cooper 
> Link: http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc
> .zyng...@arm.com
> Signed-off-by: Thomas Gleixner 
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Campbell]

On Fri, 2015-10-23 at 15:16 +0200, Fabio Fantoni wrote:
> A recent ovmf patch (already tested) I think is good to backport is:

Pointing out backport candidates in the depths of a thread such as this is
a sure fire way to ensure they get missed I'm afraid.

Please make such requests explicitly in a new thread, or at least in a
reply to the patch in question.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] mm: hotplug: Don't release twice the resource on error

[David Vrabel]

On 23/10/15 13:57, Julien Grall wrote:
> The function add_memory_resource take in parameter a resource allocated
> by the caller. On error, both add_memory_resource and the caller will
> release the resource via release_memory_source.
[...]
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1298,7 +1298,6 @@ error:
>   /* rollback pgdat allocation and others */
>   if (new_pgdat)
>   rollback_node_hotadd(nid, pgdat);
> - release_memory_resource(res);
>   memblock_remove(start, size);

I've folded this in, thanks.

David

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

[Ian Campbell]

On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> On Thu, Oct 22, 2015 at 07:14:20PM +0200, Dario Faggioli wrote:
> > In fact, right now, failing at destroying a cpupool is just
> > not reported to the user in any explicit way. Log an error,
> > as it is customary for xl in these cases.
> > 
> > While there, take the chance to turn a couple of xl exit
> > codes into EXIT_[SUCCESS|FAILURE], as discussed and agreed
> > here:
> > 
> >  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01336.h
> > tml
> >  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01341.h
> > tml
> > 
> > Signed-off-by: Dario Faggioli 
> 
> Acked-by: Wei Liu 

Looking at those links, I'm not sure that either you or myself was thinking
of using EXIT_* as function return values, just that the eventual process
exit would become one of those values instead of some negative number.
Although the thread doesn't look like it is too clear if it is talking
about return values from functions vs. process exit codes.

I think what I would have been expecting is for the xl internal error code
would become EXIT_* either in the call to exit() or the return from main
instead of being the process exit code directly.

Seeing "return EXIT_FOO" outside of a main function seems rather strange to
me.

Wei, you acked so maybe you disagree?

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] mm: hotplug: Don't release twice the resource on error

[Julien Grall]

The function add_memory_resource take in parameter a resource allocated
by the caller. On error, both add_memory_resource and the caller will
release the resource via release_memory_source.

This will result to Linux crashing when the caller is trying to release
the resource:

CPU: 1 PID: 45 Comm: xenwatch Not tainted 4.3.0-rc6-00043-g5e1d6ca-dirty #170
Hardware name: XENVM-4.7 (DT)
task: ffc1fb2421c0 ti: ffc1fb27 task.ti:
ffc1fb27
PC is at __release_resource+0x28/0x8c
LR is at __release_resource+0x24/0x8c

[...]

Call trace:
[] __release_resource+0x28/0x8c
[] release_resource+0x24/0x44
[] reserve_additional_memory+0x114/0x128
[] alloc_xenballooned_pages+0x98/0x16c
[] blkfront_gather_backend_features+0x14c/0xd68
[] blkback_changed+0x678/0x150c
[] xenbus_otherend_changed+0x9c/0xa4
[] backend_changed+0xc/0x18
[] xenwatch_thread+0xa0/0x13c
[] kthread+0xdc/0xf4

As the caller is allocating the resource, let him handle the release.
This has been introduced by commit b75351f "mm: memory hotplug with
an existing resource".

Signed-off-by: Julien Grall 

---
Cc: David Vrabel 
Cc: linux...@kvack.org

The patch who introduced this issue is in xentip/for-linus-4.4. So
this patch is a good candidate for Linus 4.4.
---
 mm/memory_hotplug.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5f394e7..0780d11 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1298,7 +1298,6 @@ error:
/* rollback pgdat allocation and others */
if (new_pgdat)
rollback_node_hotadd(nid, pgdat);
-   release_memory_resource(res);
memblock_remove(start, size);
 
 out:
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 2/4] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT

[Ian Campbell]

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The size of the CPU interface will used in a follow-up patch to map the

^be

> region in Xen memory.
> 
> Based on GICv2 spec, the CPU interface should at least be 8KB, although
> most of the platform we are supporting use incorrectly the GICv1 size
> (i.e 4KB) in their DT. Only warn and update the size to avoid any
> breakage on these platforms.
> 
> Furthermore, Xen is relying on the fact that the Virtual CPU interface
> been at least 8KB. As in reality the Virtual CPU interface matches the


  s/been/is/

> +/* TODO: Add check on distributor */
> +
> +/*
> + * The GICv2 CPU interface should at least be 8KB. Although, most of the 
> DT
> + * doesn't correctly set it and use the GICv1 CPU interface size (i.e 
> 4KB).

   don't

> +, );
>  if ( res )
>  return;
>  
> +/*
> + * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
> + * So only support GICv2 on GICv3 when the virtuaL CPU interface is

s/L/l/

Apart from the typos:
Acked-by: Ian Campbell 



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

[Hu, Robert]

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, October 23, 2015 4:15 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> 
> > [Hu, Robert]
> > Seems the failure log shall be this, any idea? I've spent days on
> > debugging this:(
> > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > (XEN) PCI add device :00:00.0
> > (XEN) PCI add device :00:01.0
> > (XEN) PCI add device :00:01.1
> > (XEN) PCI add device :00:01.2
> > (XEN) PCI add device :00:01.3
> > (XEN) PCI add device :00:02.0
> > (XEN) PCI add device :00:03.0
> > (XEN) d0: Forcing read-only access to MFN fed00
> > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > Issued domain 3 reboot
> > qemu: terminating on signal 1 from pid 4322
> 
> Please can you report this as a regular bug in a fresh thread, that way
> the relevant Xen maintainers are likely to see and react to it, rather
> than just us osstest folks.
[Hu, Robert] 

It shall be in that way after I confirm it is a bug.
Currently I'm just still not certain it is a nested bug or because of the latest
osstest code change.
I was just asking for if you can recall some hint on what changes (of osstest)
might causing this.
I'm to restore to my v12 code, with current Xen and qemu selection to try
again. I think by this way, I can confirm it is an actual nested bug or not.
Then I would report this in a fresh thread.

> 
> Please include whatever information you can, e.g. the guest config file
> used, details about the type of guest, which level of nesting this is
> happening at, the contents of any logs under /var/log/xen in L0 and L1
> host etc.
[Hu, Robert] 

Yes, sure. I will include these in bug reporting.

> 
> If this crash is in an L1 host then you might also want to CC the
> nested hvm maintainers at Intel.
[Hu, Robert] 
Yes, thanks for remind.

> 
> See http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> for general advice on reporting a bug and other things to consider
> including.
> 
> Thanks,
> Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

[Julien Grall]

On 23/10/15 14:39, Ian Campbell wrote:
> On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 23/10/15 14:28, Ian Campbell wrote:
>>> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
 The GICv2 DT node is usually used by the guest to know the
 address/size
 of the regions (GICD, GICC...) to map into their virtual memory.

 While the GICv2 spec requires the size of the GICC to be 8KB, we
 correctly do an 8KB stage-2 mapping but errornously report 256 in the
 device tree (based on GUEST_GICC_SIZE).
>>>
>>> "erroneously"
>>>

 I bet we didn't see any issue so far because all the registers except
 GICC_DIR lives in the first 256 bytes of the GICC region and all the
 guest
>>>
>>> "guests"
>>>
 I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
 0.

 Signed-off-by: Julien Grall 
>>>
>>> Acked-by: Ian Campbell 
>>>
>>> (typo's fixable on commit).
>>
>> Thank you!
>>
 ---
 This patch is a good candidate to backport for Xen 4.6 - 4.4.
 Without it a guest relying on the DT can't use GICC_DIR.
>>>
>>> Noted, but just to check: This patch (and none of the other fixes in
>>> this
>>> series) are all which are required for a guest to be able to use
>>> GICC_DIR,
>>> right?
>>
>> Correct. BTW, I forgot to mention that this patch may not apply cleanly
>> on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.
> 
> I'd be inclined not to bother with it for 4.4 at this juncture then.

I'm fine with that.

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Work on a project: Refactor Linux hotplug scripts

[Roger Pau Monné]

El 23/10/15 a les 13.33, Roger Pau Monné ha escrit:
> El 23/10/15 a les 7.53, Надежда Ампилогова ha escrit:
>> Hi all,
>>
>> I am interested in the project Refactor Linux hotplug scripts for 
>> Outreachy(Round 11). I am more of an intermediate-beginner in c. Please can 
>> anyone provide some pointers and helper about the things I need to do to 
>> join this project.
> 
> Hello,
> 
> You have to start by setting up your development system, there's a lot
> of information about how to do this on the Xen wiki:
> 
> http://wiki.xenproject.org/wiki/Getting_Started
> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
> http://wiki.xenproject.org/wiki/Xen_Serial_Console
> 
> Since you have to submit a patch before formally applying for OPW, you
> will have to get used to git (if you are not yet familiar with it), we
> also have a couple of wiki pages about this:
> 
> http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> 
> I personally use stgit in order to manage my patches:
> 
> http://wiki.xenproject.org/wiki/Submitting_Xen_Patches_with_StGit
> 
> Maybe during this process you will find issues or things that you think
> can be improved, if that's the case those patch(es) could be used in
> order to fulfil your application. If not, reply back and we will try to
> find a suitable small task.

Here are some simple tasks that are suitable in order to complete your
application (if you pick one of them please say so in order to avoid
collisions with other applicants):

http://www.gossamer-threads.com/lists/xen/devel/34#34

Roger.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

[Ian Campbell]

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The GICv2 DT node is usually used by the guest to know the address/size
> of the regions (GICD, GICC...) to map into their virtual memory.
> 
> While the GICv2 spec requires the size of the GICC to be 8KB, we
> correctly do an 8KB stage-2 mapping but errornously report 256 in the
> device tree (based on GUEST_GICC_SIZE).

"erroneously"

> 
> I bet we didn't see any issue so far because all the registers except
> GICC_DIR lives in the first 256 bytes of the GICC region and all the guest

"guests"

> I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
> 0.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

(typo's fixable on commit).

> ---
> This patch is a good candidate to backport for Xen 4.6 - 4.4.
> Without it a guest relying on the DT can't use GICC_DIR.

Noted, but just to check: This patch (and none of the other fixes in this
series) are all which are required for a guest to be able to use GICC_DIR,
right?


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Stefano Stabellini]

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > > taking them
> > > > are explained in the referenced thread.
> > 
> > That explanation isn't very convincing to me.
> > 
> > > I cannot believe we are going to move forward without a way to
> > > introduce
> > > any OVMF fixes into the  stable branches.
> > 
> > It is fine to introduce OVMF fixes into stable branches, of course.
> > 
> > But it is not fine to introduce other upstream changes to OVMF,
> > willy-nilly.
> > 
> > Obviously these two requirements cannot be satisfied without there
> > being some branch of OVMF which contains the intended fixes, without
> > the unwanted upstream development.
> 
> For things which we released as part of a stable release I completely
> agree.
>
> But OVMF for aarch64 was not part of the 4.6 release.

What I asked is only one of the backports that might present themselves
in the future. Even if the backport request is rejected, I think we
should create an OVMF branch for 4.6 anyway.


> We have no existing stable baseline for that arch, and no testing or
> reason to believe that cb9a7eb (the Config.mk version currently
> referenced by 4.6) as being any good at all on that platform,
> whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.


> I'm not convinced that taking some arbitrary old (although not as old as I
> thought) OVMF tree which we have tested to our satisfaction and released on
> x86, slapping a couple of arm64 backports on it and saying "this is now a
> good and stable thing to use on arm64" makes it good enough to release as
> ovmf arm64 in 4.6.1, encouraging our users to go about using etc.
> 
> Far better to be honest about it for now and point arm64 users at a more
> bleeding edge ovmf release outside of our own stable releases and prepare
> to do something better in 4.7.
 
Are you suggesting we don't create an OVMF branch for 4.6 until the
first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] passthrough: improve interrupt injection locking

[Ian Campbell]

On Fri, 2015-10-23 at 13:38 +0100, David Vrabel wrote:
> On 23/10/15 13:37, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
> > > When injecting an interrupt for a passthrough device into a guest,
> > > the
> > > per-domain event_lock is held, reducing performance when a guest has
> > > many VCPUs and high interrupt rates.
> > 
> > Did you CC me due to a possible impact on ARM? If so then I think since
> > ARM
> > lacks this "dpci" stuff none of these changes should have any impact on
> > that arch.
> > 
> > If you think I've missed something or you CCd me for some other reason
> > please let me know.
> 
> This series seems to fall into "THE REST" category.

Ah, only Jan and I were CCd so I didn't think of that.

I think despite the paths this ends up being x86 specific, so I'll leave it
to Jan.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Julien Grall]

Hi,

On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
> 
> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> of function 'typeof' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]

Ping? Aside the fact that other bits of the header may not be iso
compliant, I still think this patch is valid.

FWIW, it fixed build of the FreeBSD kernel for ARM64 with Xen enabled.

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 4/4] xen/arm: platform: Drop the quirks callback

[Ian Campbell]

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> All the quirks has been replaced by proper detection. Lets drop the

 have

> callback and hope that no one will need new quirks.
> 
> At the same time, remove the definition platform_dom0_evtchn_ppi with is

 ^of   which

> not used any more.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Ian Campbell 
> 
> ---
> Changes in v2:
> - Add Ian's acked-by
> ---
>  xen/arch/arm/platform.c| 10 --
>  xen/include/asm-arm/platform.h |  8 
>  2 files changed, 18 deletions(-)
> 
> diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
> index 0af6d57..b0bfaa9 100644
> --- a/xen/arch/arm/platform.c
> +++ b/xen/arch/arm/platform.c
> @@ -127,16 +127,6 @@ void platform_poweroff(void)
>  platform->poweroff();
>  }
>  
> -bool_t platform_has_quirk(uint32_t quirk)
> -{
> -uint32_t quirks = 0;
> -
> -if ( platform && platform->quirks )
> -quirks = platform->quirks();
> -
> -return !!(quirks & quirk);
> -}
> -
>  bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
>  {
>  const struct dt_device_match *blacklist = NULL;
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm
> -arm/platform.h
> index 5e462ac..f97315d 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -27,12 +27,6 @@ struct platform_desc {
>  /* Platform power-off */
>  void (*poweroff)(void);
>  /*
> - * Platform quirks
> - * Defined has a function because a platform can support multiple
> - * board with different quirk on each
> - */
> -uint32_t (*quirks)(void);
> -/*
>   * Platform blacklist devices
>   * List of devices which must not pass-through to a guest
>   */
> @@ -48,9 +42,7 @@ int platform_cpu_up(int cpu);
>  #endif
>  void platform_reset(void);
>  void platform_poweroff(void);
> -bool_t platform_has_quirk(uint32_t quirk);
>  bool_t platform_device_is_blacklisted(const struct dt_device_node
> *node);
> -unsigned int platform_dom0_evtchn_ppi(void);
>  
>  #define PLATFORM_START(_name, _namestr) \
>  static const struct platform_desc  __plat_desc_##_name __used   \

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] libxl: Do not call assert() in signal handlers

[Ian Campbell]

On Thu, 2015-10-22 at 17:22 +0100, Ian Campbell wrote:
> On Thu, 2015-10-22 at 16:39 +0100, Ian Jackson wrote:
> > assert is not async-signal-safe.
> 
> I don't doubt you, but I'm curious regarding a reference.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html doe
> sn
> 't appear to be it, unless it is too subtle for me.
> 
> > In practice the effect of calling assert there is that if the
> > assertion fails we might get a secondary crash, or other undesirable
> > behaviour from stdio (which is how assert usually reports failures).
> 
> Or maybe it's just transitive through the (usual) use of stdio as part of
> assert()?
> 
> > Mention in a comment in libxl__self_pipe_wakeup that it has to be
> > async-signal-safe.
> > 
> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Ian Campbell 

Applied.



___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Julien Grall]

On 23/10/15 14:52, Jan Beulich wrote:
 On 23.10.15 at 15:30,  wrote:
>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>>> Hi,
>>>
>>> On 04/10/15 20:24, Julien Grall wrote:
 The keyword typeof is not portable:

 /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
 of function 'typeof' is invalid in C99
 [-Werror,-Wimplicit-function-declaration]
>>>
>>> Ping? Aside the fact that other bits of the header may not be iso
>>> compliant, I still think this patch is valid.
>>
>> Yes, I agree.
>> Acked-by: Ian Campbell 
>>
>> Jan, after your earlier comments are you happy to go ahead with this for
>> now and sort the other possible issues separately?
> 
> Well - it's an improvement, sure, so I'm not intending to block it
> going in if no better way can be determined in its place right away.
> What makes me hesitant is that I'm not sure there indeed will be a
> follow up to this any time soon.

TBH, having a script which check the validity of the headers is not in
the top my todo list. Though it would be nice to have it.

But I don't think we should delay this valid patch just because we don't
have time to write a such script.

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding

[Ian Campbell]

On Thu, 2015-10-08 at 12:10 -0400, Zhigang Wang wrote:
> On 10/08/2015 11:28 AM, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 10:58 -0400, Zhigang Wang wrote:
> > > On 10/08/2015 10:40 AM, Ian Campbell wrote:
> > > > On Tue, 2015-10-06 at 15:09 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue, Oct 06, 2015 at 06:13:04PM +0100, Andrew Cooper wrote:
> > > > > > On 06/10/15 17:57, Wei Liu wrote:
> > > > > > > Various people say this binding doesn't compile or doesn't
> > > > > > > work.
> > > > > > > Remove
> > > > > > > it for the benefit of xl feature development -- so that new
> > > > > > > features
> > > > > > > won't need to worry about making this broken binding happy.
> > > > > > > 
> > > > > > > This isn't going to expose any user visible changes because
> > > > > > > that
> > > > > > > module
> > > > > > > is not built by default.
> > > > > > > 
> > > > > > > Signed-off-by: Wei Liu 
> > > > > > 
> > > > > > Reviewed-by: Andrew Cooper 
> > > > > 
> > > > > And Zhigang mentioned to me offline that he is OK with these
> > > > > being
> > > > > gone too.
> > > > 
> > > > Could we get a formal ack from one of you then please?
> > > 
> > > I'm OK with removing libxl python bindings.
> > 
> > Thanks, are you okay with me translating this into
> > 
> > Acked-by: Zhigang Wang 
> > 
> > in the final commit?
> 
> Yes.
> 
> Acked-by: Zhigang Wang 

Thanks, acked it myself and applied.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Ian Campbell]

On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 15:30,  wrote:
> > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 04/10/15 20:24, Julien Grall wrote:
> > > > The keyword typeof is not portable:
> > > > 
> > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > declaration
> > > > of function 'typeof' is invalid in C99
> > > > [-Werror,-Wimplicit-function-declaration]
> > > 
> > > Ping? Aside the fact that other bits of the header may not be iso
> > > compliant, I still think this patch is valid.
> > 
> > Yes, I agree.
> > Acked-by: Ian Campbell 
> > 
> > Jan, after your earlier comments are you happy to go ahead with this
> > for
> > now and sort the other possible issues separately?
> 
> Well - it's an improvement, sure, so I'm not intending to block it
> going in if no better way can be determined in its place right away.
> What makes me hesitant is that I'm not sure there indeed will be a
> follow up to this any time soon.

Are you saying with "better way" that Julien's fix is incorrect and that
there is potentially a "proper" fix for this specific case? i.e. a followup
to fix the use of __typeof__ in set_xen_guest_handle_raw which this patch
introduces is expected?

I don't think you are, in which case are you suggesting that having fixed
this one issue that Julien should then be on the hook for fixing all
similar/related issues in these header?

I don't think it is right to mandate that Julien put this followup work
onto his TODO list as a condition of accepting this patch, if this is not a
case of Julien's change being incorrect and requiring a "proper" fix, but
that there are other similar things wrong elsewhere.

Of course if he or anyone else wants to do so voluntarily then that's
great.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}

[Dario Faggioli]

On Fri, 2015-10-23 at 11:33 +0100, Julien Grall wrote:
> The last parameter of alloc_domheap_page{s,} contain the memory flags
> and
> not the order of the allocation.
> 
> Use 0 for the call in p2m_pod_set_cache_target as it was before
> 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for
> page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the
> behavior
> stays the same.
> 
> For the call in p2m_pod_offline_or_broken_replace we want to allocate
> the new page on the same numa node as the previous page. So retrieve
> the
> numa node and pass it in the memory flags.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> Note that the patch has only been build tested.
> 
I've done some basic testing. That means I:
 - created an HVM guest with memory < maxmem
 - played with `xl mem-set' and `xl mem-max' on it
 - local migrated it
 - played with `xl mem-set' and `xl mem-max' on it again
 - shutdown it

All done on a NUMA host, with memory dancing (during the 'play' phases)
up and down the amount of RAM present in each NUMA node.

I'm not sure how I should trigger and test memory hotunplug, neither
whether or not my testbox supports it.

Since it seems that memory hotumplug is what was really necessary, I'm
not sure it's appropriate to add the following tag:

Tested-by: Dario Faggioli 

but I'll let you guys (Jan, mainly, I guess) decide. If the above is
deemed enough, feel free to stick it there, if not, fine anyway. :-)

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU-XEN v4 3/9] xen: Switch to libxengnttab interface for compat shims.

[Ian Campbell]

On Fri, 2015-10-23 at 12:06 +0100, Stefano Stabellini wrote:
> On Wed, 21 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> > 
> > One such library will be libxengnttab which provides access to grant
> > tables.
> > 
> > In preparation for this switch the compatibility layer in xen_common.h
> > (which support building with older versions of Xen) to use what will
> > be the new library API. This means that the gnttab shim will disappear
> > for versions of Xen which include libxengnttab.
> > 
> > To simplify things for the <= 4.0.0 support we wrap the int fd in a
> > malloc(sizeof int) such that the handle is always a pointer. This
> > leads to less typedef headaches and the need for
> > XC_HANDLER_INITIAL_VALUE etc for these interfaces.
> > 
> > Build tested with 4.0 and 4.5.
> > 
> > Note that this patch does not add any support for actually using
> > libxengnttab, it just adjusts the existing shims.
> > 
> > Signed-off-by: Ian Campbell 
> 
> The patch looks OK but doesn't apply cleanly to master, please rebase.
> After fixing it up, it fails my 4.0 build test (I probably made a
> mistake).

There was a new xc_gnttab_munmap which needed converting.

BTW, contrary to what every single commit message here says I'm actually
build testing on: xen with my other patches from this mega series, 4.6,
4.1, 4.0, 4.5, 4.4, 4.3, 4.2 and on my dev xen with pvbuilder forced to on.
I'm just going to drop all these "Build tested.." from the commit messages.

(the strange version ordering is so I test the different API classes first
and fail early on problems and then fill in the gaps).

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 12/13] python: remove permission related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of  permission related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 97 ---
 1 file changed, 97 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index c88386f..5039f94 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -608,74 +608,6 @@ static PyObject *pyxc_domain_set_target_mem(XcObject 
*self, PyObject *args)
 return zero;
 }
 
-static PyObject *pyxc_domain_ioport_permission(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-int first_port, nr_ports, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "first_port", "nr_ports", 
"allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "", kwd_list, 
-  , _port, _ports, 
_access) )
-return NULL;
-
-ret = xc_domain_ioport_permission(
-self->xc_handle, dom, first_port, nr_ports, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_irq_permission(PyObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-int pirq, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "pirq", "allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iii", kwd_list, 
-  , , _access) )
-return NULL;
-
-ret = xc_domain_irq_permission(
-xc->xc_handle, dom, pirq, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_iomem_permission(PyObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-unsigned long first_pfn, nr_pfns, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "first_pfn", "nr_pfns", 
"allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "illi", kwd_list, 
-  , _pfn, _pfns, 
_access) )
-return NULL;
-
-ret = xc_domain_iomem_permission(
-xc->xc_handle, dom, first_pfn, nr_pfns, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_domain_set_time_offset(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -925,35 +857,6 @@ static PyMethodDef pyxc_methods[] = {
   " mem_kb [int]: .\n"
   "Returns: [int] 0 on success; -1 on error.\n" },
 
-{ "domain_ioport_permission",
-  (PyCFunction)pyxc_domain_ioport_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a range of IO ports\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " first_port   [int]: First IO port\n"
-  " nr_ports [int]: Number of IO ports\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "domain_irq_permission",
-  (PyCFunction)pyxc_domain_irq_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a physical IRQ\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " pirq [int]: The Physical IRQ\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "domain_iomem_permission",
-  (PyCFunction)pyxc_domain_iomem_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a range of IO memory pages\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " first_pfn   [long]: First page of I/O Memory\n"
-  " nr_pfns [long]: Number of pages of I/O Memory (>0)\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
 { "pages_to_kib",
   (PyCFunction)pyxc_pages_to_kib,
   METH_VARARGS, "\n"
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 13/13] python: remove unused other libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there are
only some few python bindings in use, most of the in out of tree
tools. Remove all unused libxc python bindings.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 484 --
 1 file changed, 484 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5039f94..5d79b14 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -146,148 +146,11 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom, remote_dom;
-int port;
-
-static char *kwd_list[] = { "domid", "remote_dom", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  , _dom) )
-return NULL;
-
-if ( (port = xc_evtchn_alloc_unbound(self->xc_handle, dom, remote_dom)) < 
0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyInt_FromLong(port);
-}
-
-static PyObject *pyxc_evtchn_reset(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-
-static char *kwd_list[] = { "dom", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list, ) )
-return NULL;
-
-if ( xc_evtchn_reset(self->xc_handle, dom) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_physdev_map_pirq(PyObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-int index, pirq, ret;
-
-static char *kwd_list[] = {"domid", "index", "pirq", NULL};
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iii", kwd_list,
-  , , ) )
-return NULL;
-ret = xc_physdev_map_pirq(xc->xc_handle, dom, index, );
-if ( ret != 0 )
-  return pyxc_error_to_exception(xc->xc_handle);
-return PyLong_FromUnsignedLong(pirq);
-}
-
-static PyObject *pyxc_physdev_pci_access_modify(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int bus, dev, func, enable, ret;
-
-static char *kwd_list[] = { "domid", "bus", "dev", "func", "enable", NULL 
};
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list, 
-  , , , , ) )
-return NULL;
-
-ret = xc_physdev_pci_access_modify(
-self->xc_handle, dom, bus, dev, func, enable);
-if ( ret != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_readconsolering(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-unsigned int clear = 0, index = 0, incremental = 0;
-unsigned int count = 16384 + 1, size = count;
-char*str, *ptr;
-PyObject*obj;
-int  ret;
-
-static char *kwd_list[] = { "clear", "index", "incremental", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
-  , , ) ||
- !(str = malloc(size)) )
-return NULL;
-
-ret = xc_readconsolering(self->xc_handle, str, , clear,
- incremental, );
-if ( ret < 0 ) {
-free(str);
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-while ( !incremental && count == size && ret >= 0 )
-{
-size += count - 1;
-if ( size < count )
-break;
-
-ptr = realloc(str, size);
-if ( !ptr )
-break;
-
-str = ptr + count;
-count = size - count;
-ret = xc_readconsolering(self->xc_handle, str, , clear,
- 1, );
-count += str - ptr;
-str = ptr;
-}
-
-obj = PyString_FromStringAndSize(str, count);
-free(str);
-return obj;
-}
-
-
 static unsigned long pages_to_kib(unsigned long pages)
 {
 return pages * (XC_PAGE_SIZE / 1024);
 }
 
-
-static PyObject *pyxc_pages_to_kib(XcObject *self, PyObject *args)
-{
-unsigned long pages;
-
-if (!PyArg_ParseTuple(args, "l", ))
-return NULL;
-
-return PyLong_FromUnsignedLong(pages_to_kib(pages));
-}
-
 static PyObject *pyxc_physinfo(XcObject *self)
 {
 xc_physinfo_t pinfo;
@@ -360,168 +223,6 @@ static PyObject 

[Xen-devel] [PATCH 08/13] python: remove unused memory related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of most memory related python binding left. Remove them.
Especially xc.domain_set_target_mem() and xc.domain_setmaxmem() will
not be removed as there are some out of tree users.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 92 ---
 1 file changed, 92 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 6c4ad18..02f1694 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -953,59 +953,6 @@ static PyObject *pyxc_xeninfo(XcObject *self)
  "cc_compile_date", xen_cc.compile_date);
 }
 
-static PyObject *pyxc_shadow_control(PyObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-
-uint32_t dom;
-int op=0;
-
-static char *kwd_list[] = { "dom", "op", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list, 
-  , ) )
-return NULL;
-
-if ( xc_shadow_control(xc->xc_handle, dom, op, NULL, 0, NULL, 0, NULL) 
- < 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_shadow_mem_control(PyObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-int op;
-uint32_t dom;
-int mbarg = -1;
-unsigned long mb;
-
-static char *kwd_list[] = { "dom", "mb", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list, 
-  , ) )
-return NULL;
-
-if ( mbarg < 0 ) 
-op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
-else 
-{
-mb = mbarg;
-op = XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION;
-}
-if ( xc_shadow_control(xc->xc_handle, dom, op, NULL, 0, , 0, NULL) < 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-mbarg = mb;
-return Py_BuildValue("i", mbarg);
-}
-
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -1039,21 +986,6 @@ static PyObject *pyxc_domain_set_target_mem(XcObject 
*self, PyObject *args)
 return zero;
 }
 
-static PyObject *pyxc_domain_set_memmap_limit(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-unsigned int maplimit_kb;
-
-if ( !PyArg_ParseTuple(args, "ii", , _kb) )
-return NULL;
-
-if ( xc_domain_set_memmap_limit(self->xc_handle, dom, maplimit_kb) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_domain_ioport_permission(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -1530,22 +1462,6 @@ static PyMethodDef pyxc_methods[] = {
   "Returns [dict]: information about Xen"
   "[None]: on failure.\n" },
 
-{ "shadow_control", 
-  (PyCFunction)pyxc_shadow_control, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Set parameter for shadow pagetable interface\n"
-  " dom [int]:   Identifier of domain.\n"
-  " op [int, 0]: operation\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "shadow_mem_control", 
-  (PyCFunction)pyxc_shadow_mem_control, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Set or read shadow pagetable memory use\n"
-  " dom [int]:   Identifier of domain.\n"
-  " mb [int, -1]: MB of shadow memory this domain should have.\n\n"
-  "Returns: [int] MB of shadow memory in use by this domain.\n" },
-
 { "domain_setmaxmem", 
   (PyCFunction)pyxc_domain_setmaxmem, 
   METH_VARARGS, "\n"
@@ -1562,14 +1478,6 @@ static PyMethodDef pyxc_methods[] = {
   " mem_kb [int]: .\n"
   "Returns: [int] 0 on success; -1 on error.\n" },
 
-{ "domain_set_memmap_limit", 
-  (PyCFunction)pyxc_domain_set_memmap_limit, 
-  METH_VARARGS, "\n"
-  "Set a domain's physical memory mappping limit\n"
-  " dom [int]: Identifier of domain.\n"
-  " map_limitkb [int]: .\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
 { "domain_ioport_permission",
   (PyCFunction)pyxc_domain_ioport_permission,
   METH_VARARGS | METH_KEYWORDS, "\n"
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 11/13] python: remove hvm related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of hvm related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 92 ---
 1 file changed, 92 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5fcee3f..c88386f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -146,70 +146,6 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_hvm_param_get(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int param;
-uint64_t value;
-
-static char *kwd_list[] = { "domid", "param", NULL }; 
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  , ) )
-return NULL;
-
-if ( xc_hvm_param_get(self->xc_handle, dom, param, ) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyLong_FromUnsignedLongLong(value);
-
-}
-
-static PyObject *pyxc_hvm_param_set(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int param;
-uint64_t value;
-
-static char *kwd_list[] = { "domid", "param", "value", NULL }; 
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiL", kwd_list,
-  , , ) )
-return NULL;
-
-if ( xc_hvm_param_set(self->xc_handle, dom, param, value) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_gnttab_hvm_seed(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t dom, console_domid, xenstore_domid;
-unsigned long xenstore_gmfn = 0;
-unsigned long console_gmfn = 0;
-static char *kwd_list[] = { "domid",
-   "console_gmfn", "xenstore_gmfn",
-   "console_domid", "xenstore_domid", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  ,
- _gmfn, _gmfn,
- _domid, _domid) )
-return NULL;
-
-if ( xc_dom_gnttab_hvm_seed(self->xc_handle, dom,
-   console_gmfn, xenstore_gmfn,
-   console_domid, xenstore_domid) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_None;
-}
-
 static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -897,34 +833,6 @@ static PyMethodDef pyxc_methods[] = {
   "reason why it shut itself down.\n"
   " cpupool  [int]   Id of cpupool domain is bound to.\n" },
 
-{ "gnttab_hvm_seed",
-  (PyCFunction)pyxc_gnttab_hvm_seed,
-  METH_KEYWORDS, "\n"
-  "Initialise HVM guest grant table.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " console_gmfn [int]: \n"
-  " xenstore_gmfn [int]: \n"
-  " console_domid [int]: \n"
-  " xenstore_domid [int]: \n"
-  "Returns: None on sucess. Raises exception on error.\n" },
-
-{ "hvm_get_param", 
-  (PyCFunction)pyxc_hvm_param_get,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "get a parameter of HVM guest OS.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " param   [int]:  No. of HVM param.\n"
-  "Returns: [long] value of the param.\n" },
-
-{ "hvm_set_param", 
-  (PyCFunction)pyxc_hvm_param_set,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "set a parameter of HVM guest OS.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " param   [int]:  No. of HVM param.\n"
-  " value   [long]: Value of param.\n"
-  "Returns: [int] 0 on success.\n" },
-
 { "evtchn_alloc_unbound", 
   (PyCFunction)pyxc_evtchn_alloc_unbound,
   METH_VARARGS | METH_KEYWORDS, "\n"
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 07/13] python: remove scheduler related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any scheduler related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 133 --
 1 file changed, 133 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index e0f1d7f..6c4ad18 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1006,97 +1006,6 @@ static PyObject *pyxc_shadow_mem_control(PyObject *self,
 return Py_BuildValue("i", mbarg);
 }
 
-static PyObject *pyxc_sched_id_get(XcObject *self) {
-
-int sched_id;
-if (xc_sched_id(self->xc_handle, _id) != 0)
-return PyErr_SetFromErrno(xc_error_obj);
-
-return Py_BuildValue("i", sched_id);
-}
-
-static PyObject *pyxc_sched_credit_domain_set(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t domid;
-uint16_t weight;
-uint16_t cap;
-static char *kwd_list[] = { "domid", "weight", "cap", NULL };
-static char kwd_type[] = "I|HH";
-struct xen_domctl_sched_credit sdom;
-
-weight = 0;
-cap = (uint16_t)~0U;
-if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list, 
- , , ) )
-return NULL;
-
-sdom.weight = weight;
-sdom.cap = cap;
-
-if ( xc_sched_credit_domain_set(self->xc_handle, domid, ) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_sched_credit_domain_get(XcObject *self, PyObject *args)
-{
-uint32_t domid;
-struct xen_domctl_sched_credit sdom;
-
-if( !PyArg_ParseTuple(args, "I", ) )
-return NULL;
-
-if ( xc_sched_credit_domain_get(self->xc_handle, domid, ) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_BuildValue("{s:H,s:H}",
- "weight",  sdom.weight,
- "cap", sdom.cap);
-}
-
-static PyObject *pyxc_sched_credit2_domain_set(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t domid;
-uint16_t weight;
-static char *kwd_list[] = { "domid", "weight", NULL };
-static char kwd_type[] = "I|H";
-struct xen_domctl_sched_credit2 sdom;
-
-weight = 0;
-if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list,
- , ) )
-return NULL;
-
-sdom.weight = weight;
-
-if ( xc_sched_credit2_domain_set(self->xc_handle, domid, ) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject *args)
-{
-uint32_t domid;
-struct xen_domctl_sched_credit2 sdom;
-
-if( !PyArg_ParseTuple(args, "I", ) )
-return NULL;
-
-if ( xc_sched_credit2_domain_get(self->xc_handle, domid, ) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_BuildValue("{s:H}",
- "weight",  sdom.weight);
-}
-
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -1545,48 +1454,6 @@ static PyMethodDef pyxc_methods[] = {
   " value   [long]: Value of param.\n"
   "Returns: [int] 0 on success.\n" },
 
-{ "sched_id_get",
-  (PyCFunction)pyxc_sched_id_get,
-  METH_NOARGS, "\n"
-  "Get the current scheduler type in use.\n"
-  "Returns: [int] sched_id.\n" },
-
-{ "sched_credit_domain_set",
-  (PyCFunction)pyxc_sched_credit_domain_set,
-  METH_KEYWORDS, "\n"
-  "Set the scheduling parameters for a domain when running with the\n"
-  "SMP credit scheduler.\n"
-  " domid [int]:   domain id to set\n"
-  " weight[short]: domain's scheduling weight\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "sched_credit_domain_get",
-  (PyCFunction)pyxc_sched_credit_domain_get,
-  METH_VARARGS, "\n"
-  "Get the scheduling parameters for a domain when running with the\n"
-  "SMP credit scheduler.\n"
-  " domid [int]:   domain id to get\n"
-  "Returns:   [dict]\n"
-  " weight[short]: domain's scheduling weight\n"},
-
-{ "sched_credit2_domain_set",
-  (PyCFunction)pyxc_sched_credit2_domain_set,
-  METH_KEYWORDS, "\n"
-  "Set the scheduling parameters for a domain when running with the\n"
-  "SMP credit2 scheduler.\n"
-  " domid [int]:   domain id to set\n"
-  " weight[short]: domain's scheduling weight\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "sched_credit2_domain_get",
-  

[Xen-devel] [PATCH 02/13] libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c

[Juergen Gross]

xc_get_bit_size() is being used by the unused python wrapper
xc.getBitSize() only. Remove the wrapper and xc_get_bit_size().

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xenguest.h|  4 
 tools/libxc/xc_dom_compat_linux.c | 25 -
 tools/python/xen/lowlevel/xc/xc.c | 28 
 3 files changed, 57 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index a9fa32c..8f918b1 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -184,10 +184,6 @@ int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, 
int suspend_evtchn);
 int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce,
 int domid, int port, int *lockfd);
 
-int xc_get_bit_size(xc_interface *xch,
-const char *image_name, const char *cmdline,
-const char *features, int *type);
-
 int xc_mark_page_online(xc_interface *xch, unsigned long start,
 unsigned long end, uint32_t *status);
 
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index 20521cf..abbc09f 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -34,31 +34,6 @@
 
 /*  */
 
-int xc_get_bit_size(xc_interface *xch,
-const char *image_name, const char *cmdline,
-const char *features, int *bit_size)
-{
-struct xc_dom_image *dom;
-int rc;
-*bit_size = 0;
-dom = xc_dom_allocate(xch, cmdline, features);
-if (dom == NULL)
-return -1;
-if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 )
-goto out;
-if ( (rc = xc_dom_parse_image(dom)) != 0 )
-goto out;
-if( dom->guest_type != NULL){
-if(strstr(dom->guest_type, "x86_64") != NULL)
-*bit_size = X86_64_B_SIZE; //64bit Guest
-if(strstr(dom->guest_type, "x86_32") != NULL)
-*bit_size = X86_32_B_SIZE; //32bit Guest
-}
- out:
-xc_dom_release(dom);
-return rc;
-}
-
 int xc_linux_build(xc_interface *xch, uint32_t domid,
unsigned int mem_mb,
const char *image_name,
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 94f0a13..d75f98c 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -6,7 +6,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -431,26 +430,6 @@ static PyObject *pyxc_vcpu_getinfo(XcObject *self,
 return info_dict;
 }
 
-static PyObject *pyxc_getBitSize(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-PyObject *info_type;
-char *image = NULL, *cmdline = "", *features = NULL;
-int type = 0;
-static char *kwd_list[] = { "image", "cmdline", "features", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "sss", kwd_list,
-  , , ) )
-return NULL;
-
-xc_get_bit_size(self->xc_handle, image, cmdline, features, );
-if (type < 0)
-return pyxc_error_to_exception(self->xc_handle);
-info_type = Py_BuildValue("{s:i}",
-  "type", type);
-return info_type;
-}
-
 static PyObject *pyxc_hvm_param_get(XcObject *self,
 PyObject *args,
 PyObject *kwds)
@@ -2182,13 +2161,6 @@ static PyMethodDef pyxc_methods[] = {
   " cpumap   [int]:  Bitmap of CPUs this VCPU can run on\n"
   " cpu  [int]:  CPU that this VCPU is currently bound to\n" },
 
-{"getBitSize",
-  (PyCFunction)pyxc_getBitSize,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Get the bitsize of a guest OS.\n"
-  " image   [str]:  Name of kernel image file. May be gzipped.\n"
-  " cmdline [str, n/a]: Kernel parameters, if any.\n\n"},
-
 { "gnttab_hvm_seed",
   (PyCFunction)pyxc_gnttab_hvm_seed,
   METH_KEYWORDS, "\n"
-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 04/13] python: remove cpupool related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpupool related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 224 --
 1 file changed, 224 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index c904627..9d82579 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1682,175 +1682,6 @@ static PyObject *pyxc_dom_set_memshr(XcObject *self, 
PyObject *args)
 return zero;
 }
 
-static PyObject *cpumap_to_cpulist(XcObject *self, xc_cpumap_t cpumap)
-{
-PyObject *cpulist = NULL;
-int i;
-int nr_cpus;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpulist = PyList_New(0);
-for ( i = 0; i < nr_cpus; i++ )
-{
-if ( *cpumap & (1 << (i % 8)) )
-{
-PyObject* pyint = PyInt_FromLong(i);
-
-PyList_Append(cpulist, pyint);
-Py_DECREF(pyint);
-}
-if ( (i % 8) == 7 )
-cpumap++;
-}
-return cpulist;
-}
-
-static PyObject *pyxc_cpupool_create(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool = 0, sched = XEN_SCHEDULER_CREDIT;
-
-static char *kwd_list[] = { "pool", "sched", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|ii", kwd_list, ,
-  ))
-return NULL;
-
-if ( xc_cpupool_create(self->xc_handle, , sched) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyInt_FromLong(cpupool);
-}
-
-static PyObject *pyxc_cpupool_destroy(XcObject *self,
-  PyObject *args)
-{
-uint32_t cpupool;
-
-if (!PyArg_ParseTuple(args, "i", ))
-return NULL;
-
-if (xc_cpupool_destroy(self->xc_handle, cpupool) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_getinfo(XcObject *self)
-{
-PyObject *list, *info_dict;
-
-uint32_t pool;
-xc_cpupoolinfo_t *info;
-
-list = PyList_New(0);
-for (pool = 0;;)
-{
-info = xc_cpupool_getinfo(self->xc_handle, pool);
-if (info == NULL)
-break;
-info_dict = Py_BuildValue(
-"{s:i,s:i,s:i,s:N}",
-"cpupool", (int)info->cpupool_id,
-"sched",   info->sched_id,
-"n_dom",   info->n_dom,
-"cpulist", cpumap_to_cpulist(self, info->cpumap));
-pool = info->cpupool_id + 1;
-xc_cpupool_infofree(self->xc_handle, info);
-
-if ( info_dict == NULL )
-{
-Py_DECREF(list);
-return NULL;
-}
-
-PyList_Append(list, info_dict);
-Py_DECREF(info_dict);
-}
-
-return list;
-}
-
-static PyObject *pyxc_cpupool_addcpu(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool;
-int cpu = -1;
-
-static char *kwd_list[] = { "cpupool", "cpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  , ) )
-return NULL;
-
-if (xc_cpupool_addcpu(self->xc_handle, cpupool, cpu) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_removecpu(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t cpupool;
-int cpu = -1;
-
-static char *kwd_list[] = { "cpupool", "cpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  , ) )
-return NULL;
-
-if (xc_cpupool_removecpu(self->xc_handle, cpupool, cpu) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_movedomain(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool, domid;
-
-static char *kwd_list[] = { "cpupool", "domid", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  , ) )
-return NULL;
-
-if (xc_cpupool_movedomain(self->xc_handle, cpupool, domid) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_freeinfo(XcObject *self)
-{
-xc_cpumap_t cpumap;
-

[Xen-devel] [PATCH 05/13] python: remove cpuid related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpuid related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 128 --
 1 file changed, 128 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 9d82579..7809fc6 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -658,105 +658,6 @@ static PyObject *pyxc_get_device_group(XcObject *self,
 }
 
 #if defined(__i386__) || defined(__x86_64__)
-static void pyxc_dom_extract_cpuid(PyObject *config,
-  char **regs)
-{
-const char *regs_extract[4] = { "eax", "ebx", "ecx", "edx" };
-PyObject *obj;
-int i;
-
-memset(regs, 0, 4*sizeof(*regs));
-
-if ( !PyDict_Check(config) )
-return;
-
-for ( i = 0; i < 4; i++ )
-if ( (obj = PyDict_GetItemString(config, regs_extract[i])) != NULL )
-regs[i] = PyString_AS_STRING(obj);
-}
-
-static PyObject *pyxc_create_cpuid_dict(char **regs)
-{
-   const char *regs_extract[4] = { "eax", "ebx", "ecx", "edx" };
-   PyObject *dict;
-   int i;
-
-   dict = PyDict_New();
-   for ( i = 0; i < 4; i++ )
-   {
-   if ( regs[i] == NULL )
-   continue;
-   PyDict_SetItemString(dict, regs_extract[i],
-PyString_FromString(regs[i]));
-   free(regs[i]);
-   regs[i] = NULL;
-   }
-   return dict;
-}
-
-static PyObject *pyxc_dom_check_cpuid(XcObject *self,
-  PyObject *args)
-{
-PyObject *sub_input, *config;
-unsigned int input[2];
-char *regs[4], *regs_transform[4];
-
-if ( !PyArg_ParseTuple(args, "iOO", [0], _input, ) )
-return NULL;
-
-pyxc_dom_extract_cpuid(config, regs);
-
-input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( PyLong_Check(sub_input) )
-input[1] = PyLong_AsUnsignedLong(sub_input);
-
-if ( xc_cpuid_check(self->xc_handle, input,
-(const char **)regs, regs_transform) )
-return pyxc_error_to_exception(self->xc_handle);
-
-return pyxc_create_cpuid_dict(regs_transform);
-}
-
-static PyObject *pyxc_dom_set_policy_cpuid(XcObject *self,
-   PyObject *args)
-{
-int domid;
-
-if ( !PyArg_ParseTuple(args, "i", ) )
-return NULL;
-
-if ( xc_cpuid_apply_policy(self->xc_handle, domid) )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-
-static PyObject *pyxc_dom_set_cpuid(XcObject *self,
-PyObject *args)
-{
-PyObject *sub_input, *config;
-unsigned int domid, input[2];
-char *regs[4], *regs_transform[4];
-
-if ( !PyArg_ParseTuple(args, "IIOO", ,
-   [0], _input, ) )
-return NULL;
-
-pyxc_dom_extract_cpuid(config, regs);
-
-input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( PyLong_Check(sub_input) )
-input[1] = PyLong_AsUnsignedLong(sub_input);
-
-if ( xc_cpuid_set(self->xc_handle, domid, input, (const char **)regs,
-  regs_transform) )
-return pyxc_error_to_exception(self->xc_handle);
-
-return pyxc_create_cpuid_dict(regs_transform);
-}
-
 static PyObject *pyxc_dom_set_machine_address_size(XcObject *self,
   PyObject *args,
   PyObject *kwds)
@@ -2103,35 +2004,6 @@ static PyMethodDef pyxc_methods[] = {
   " keys[str]: String of keys to inject.\n" },
 
 #if defined(__i386__) || defined(__x86_64__)
-{ "domain_check_cpuid", 
-  (PyCFunction)pyxc_dom_check_cpuid, 
-  METH_VARARGS, "\n"
-  "Apply checks to host CPUID.\n"
-  " input [long]: Input for cpuid instruction (eax)\n"
-  " sub_input [long]: Second input (optional, may be None) for cpuid "
-  " instruction (ecx)\n"
-  " config [dict]: Dictionary of register\n"
-  " config [dict]: Dictionary of register, use for checking\n\n"
-  "Returns: [int] 0 on success; exception on error.\n" },
-
-{ "domain_set_cpuid", 
-  (PyCFunction)pyxc_dom_set_cpuid, 
-  METH_VARARGS, "\n"
-  "Set cpuid response for an input and a domain.\n"
-  " dom [int]: Identifier of domain.\n"
-  " input [long]: Input for cpuid instruction (eax)\n"
-  " sub_input [long]: Second input (optional, may be None) for cpuid "
-  " instruction (ecx)\n"
-  " config [dict]: Dictionary of register\n\n"
-  "Returns: [int] 0 on success; exception on error.\n" },
-
-{ "domain_set_policy_cpuid", 
-  (PyCFunction)pyxc_dom_set_policy_cpuid, 
-  METH_VARARGS, "\n"
-  "Set the default cpuid policy for a domain.\n"
-  " dom [int]: 

[Xen-devel] [PATCH 06/13] python: remove device related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any device related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 226 --
 1 file changed, 226 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 7809fc6..e0f1d7f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -466,197 +466,6 @@ static PyObject *pyxc_hvm_param_set(XcObject *self,
 return zero;
 }
 
-static int token_value(char *token)
-{
-token = strchr(token, 'x') + 1;
-return strtol(token, NULL, 16);
-}
-
-static int next_bdf(char **str, int *seg, int *bus, int *dev, int *func)
-{
-char *token;
-
-if ( !(*str) || !strchr(*str, ',') )
-return 0;
-
-token = *str;
-*seg  = token_value(token);
-token = strchr(token, ',') + 1;
-*bus  = token_value(token);
-token = strchr(token, ',') + 1;
-*dev  = token_value(token);
-token = strchr(token, ',') + 1;
-*func  = token_value(token);
-token = strchr(token, ',');
-*str = token ? token + 1 : NULL;
-
-return 1;
-}
-
-static PyObject *pyxc_test_assign_device(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  , _str) )
-return NULL;
-
-while ( next_bdf(_str, , , , ) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_test_assign_device(self->xc_handle, dom, sbdf) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_assign_device(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  , _str) )
-return NULL;
-
-while ( next_bdf(_str, , , , ) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_assign_device(self->xc_handle, dom, sbdf, 0) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_deassign_device(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  , _str) )
-return NULL;
-
-while ( next_bdf(_str, , , , ) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_deassign_device(self->xc_handle, dom, sbdf) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_get_device_group(XcObject *self,
- PyObject *args)
-{
-uint32_t sbdf;
-uint32_t max_sdevs, num_sdevs;
-int domid, seg, bus, dev, func, rc, i;
-PyObject *Pystr;
-char *group_str;
-char dev_str[9];
-uint32_t *sdev_array;
-
-if ( !PyArg_ParseTuple(args, "i", , , , , ) )
-return NULL;
-
-/* Maximum allowed siblings device number per group */
-max_sdevs = 1024;
-
-sdev_array = calloc(max_sdevs, sizeof(*sdev_array));
-if (sdev_array == NULL)
-return PyErr_NoMemory();
-
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-rc = xc_get_device_group(self->xc_handle,
-domid, sbdf, max_sdevs, _sdevs, sdev_array);
-
-if ( rc < 0 )
-{
-free(sdev_array); 
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-if ( !num_sdevs )
-{
-free(sdev_array);
-return Py_BuildValue("s", "");
-}
-
-group_str = 

[Xen-devel] [PATCH 10/13] python: remove vcpu related libxc python bindings

[Juergen Gross]

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of vcpu related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 134 --
 1 file changed, 134 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5146a2d..5fcee3f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -75,57 +75,6 @@ static PyObject *pyxc_error_to_exception(xc_interface *xch)
 return NULL;
 }
 
-static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-int vcpu = 0, i;
-xc_cpumap_t cpumap;
-PyObject *cpulist = NULL;
-int nr_cpus;
-
-static char *kwd_list[] = { "domid", "vcpu", "cpumap", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|iO", kwd_list, 
-  , , ) )
-return NULL;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpumap = xc_cpumap_alloc(self->xc_handle);
-if(cpumap == NULL)
-return pyxc_error_to_exception(self->xc_handle);
-
-if ( (cpulist != NULL) && PyList_Check(cpulist) )
-{
-for ( i = 0; i < PyList_Size(cpulist); i++ ) 
-{
-long cpu = PyInt_AsLong(PyList_GetItem(cpulist, i));
-if ( cpu < 0 || cpu >= nr_cpus )
-{
-free(cpumap);
-errno = EINVAL;
-PyErr_SetFromErrno(xc_error_obj);
-return NULL;
-}
-cpumap[cpu / 8] |= 1 << (cpu % 8);
-}
-}
-  
-if ( xc_vcpu_setaffinity(self->xc_handle, dom, vcpu, cpumap,
- NULL, XEN_VCPUAFFINITY_HARD) != 0 )
-{
-free(cpumap);
-return pyxc_error_to_exception(self->xc_handle);
-}
-Py_INCREF(zero);
-free(cpumap); 
-return zero;
-}
-
 static PyObject *pyxc_domain_getinfo(XcObject *self,
  PyObject *args,
  PyObject *kwds)
@@ -197,66 +146,6 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_vcpu_getinfo(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-PyObject *info_dict, *cpulist;
-
-uint32_t dom, vcpu = 0;
-xc_vcpuinfo_t info;
-int rc, i;
-xc_cpumap_t cpumap;
-int nr_cpus;
-
-static char *kwd_list[] = { "domid", "vcpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  , ) )
-return NULL;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-rc = xc_vcpu_getinfo(self->xc_handle, dom, vcpu, );
-if ( rc < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpumap = xc_cpumap_alloc(self->xc_handle);
-if(cpumap == NULL)
-return pyxc_error_to_exception(self->xc_handle);
-
-rc = xc_vcpu_getaffinity(self->xc_handle, dom, vcpu, cpumap,
- NULL, XEN_VCPUAFFINITY_HARD);
-if ( rc < 0 )
-{
-free(cpumap);
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-info_dict = Py_BuildValue("{s:i,s:i,s:i,s:L,s:i}",
-  "online",   info.online,
-  "blocked",  info.blocked,
-  "running",  info.running,
-  "cpu_time", info.cpu_time,
-  "cpu",  info.cpu);
-cpulist = PyList_New(0);
-for ( i = 0; i < nr_cpus; i++ )
-{
-if (*(cpumap + i / 8) & 1 ) {
-PyObject *pyint = PyInt_FromLong(i);
-PyList_Append(cpulist, pyint);
-Py_DECREF(pyint);
-}
-cpumap[i / 8] >>= 1;
-}
-PyDict_SetItemString(info_dict, "cpumap", cpulist);
-Py_DECREF(cpulist);
-free(cpumap);
-return info_dict;
-}
-
 static PyObject *pyxc_hvm_param_get(XcObject *self,
 PyObject *args,
 PyObject *kwds)
@@ -982,15 +871,6 @@ static PyObject *pyxc_dom_set_memshr(XcObject *self, 
PyObject *args)
 }
 
 static PyMethodDef pyxc_methods[] = {
-{ "vcpu_setaffinity", 
-  (PyCFunction)pyxc_vcpu_setaffinity, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Pin a VCPU to a specified set CPUs.\n"
-  " dom [int]: Identifier of domain to which VCPU belongs.\n"
-  " vcpu [int, 0]: VCPU being pinned.\n"
-  " cpumap [list, []]: list of usable CPUs.\n\n"
-  

[Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

[Juergen Gross]

This series is a combination of my previous patches:

"libxc: remove most of tools/libxc/xc_dom_compat_linux.c" 
"tools: remove unused wrappers for python"

I have split it up as requested by Ian Campbell, thus it consists of
13 patches instead just of 2, but the functionality is roughly the
same. I have just kept more python bindings compared to the first
version, as there have been reports of some out of tree uses. Asking
for more such use case on xen-devel and xen-user didn't result in
requests for more interfaces to be kept, so I delete them.

Juergen Gross (13):
  libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c
  python: remove flask related libxc python bindings
  python: remove cpupool related libxc python bindings
  python: remove cpuid related libxc python bindings
  python: remove device related libxc python bindings
  python: remove scheduler related libxc python bindings
  python: remove unused memory related libxc python bindings
  python: remove domain handling related libxc python bindings
  python: remove vcpu related libxc python bindings
  python: remove hvm related libxc python bindings
  python: remove  permission related libxc python bindings
  python: remove unused other libxc python bindings

 tools/libxc/include/xc_dom.h  |5 +
 tools/libxc/include/xenguest.h|   52 -
 tools/libxc/xc_dom_compat_linux.c |  142 +-
 tools/libxl/libxl_internal.h  |1 +
 tools/python/xen/lowlevel/xc/xc.c | 2624 +++--
 5 files changed, 170 insertions(+), 2654 deletions(-)

-- 
2.1.4


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

[Julien Grall]

Hi Ian,

On 23/10/15 14:28, Ian Campbell wrote:
> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
>> The GICv2 DT node is usually used by the guest to know the address/size
>> of the regions (GICD, GICC...) to map into their virtual memory.
>>
>> While the GICv2 spec requires the size of the GICC to be 8KB, we
>> correctly do an 8KB stage-2 mapping but errornously report 256 in the
>> device tree (based on GUEST_GICC_SIZE).
> 
> "erroneously"
> 
>>
>> I bet we didn't see any issue so far because all the registers except
>> GICC_DIR lives in the first 256 bytes of the GICC region and all the guest
> 
> "guests"
> 
>> I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
>> 0.
>>
>> Signed-off-by: Julien Grall 
> 
> Acked-by: Ian Campbell 
> 
> (typo's fixable on commit).

Thank you!

>> ---
>> This patch is a good candidate to backport for Xen 4.6 - 4.4.
>> Without it a guest relying on the DT can't use GICC_DIR.
> 
> Noted, but just to check: This patch (and none of the other fixes in this
> series) are all which are required for a guest to be able to use GICC_DIR,
> right?

Correct. BTW, I forgot to mention that this patch may not apply cleanly
on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.

Regards,

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: gic-v2: Detect automatically aliased GIC 400

[Ian Campbell]

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> Hi all,
> 
> Only patch #3 is related to the subject of the cover letter. The rest is
> clean
> up of code I looked while I was working on this series. Though, patch #1
> is a
> new bug fix I noticed between v3 and v4.

I fixed the typos I mentioned in my review and have now committed all four.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add support of PSCI v1.0 for the host

[Ian Campbell]

On Fri, 2015-10-23 at 11:39 +0100, Julien Grall wrote:
> On 23/10/15 11:39, Ian Campbell wrote:
> > On Thu, 2015-10-22 at 18:17 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 22/10/15 16:42, Ian Campbell wrote:
> > > > On Mon, 2015-10-12 at 16:39 +0100, Julien Grall wrote:
> > > > 
> > > > Subject: support PSCI v1.0 for the host.
> > > > 
> > > > > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar.
> > > > > All
> > > >Xen's
> > > > 
> > > > > the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF
> > > > > and
> > > > > SYSTEM_RESET) behaves exactly the same.
> > > > 
> > > > behave
> > > > 
> > > > > Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version
> > > > > must
> > > > > be
> > > > > compatible with 1.x when y > x for any functions existing in 1.x.
> > > > > 
> > > > > So check the presence of the new compatible string [1] and allow
> > > > > Xen
> > > > > to
> > > > > boot on any platform using PSCI 1.x.
> > > > > 
> > > > > [1] 
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-Octobe
> > > > > r/37
> > > > > 4547.html
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > 
> > > > Acked-by: Ian Campbell 
> > > 
> > > Shall I resend a new version with those typos fixed? Or do you plan
> > > to
> > > do it when you'll commit the patch?
> > 
> > Looks like those are the only changes required, so assuming you are are
> > happy with them I'll just do them on commit.
> 
> I'm fine with that.

Applied, thanks.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use __typeof__ rather than typeof

[Jan Beulich]

>>> On 23.10.15 at 15:30,  wrote:
> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> Hi,
>> 
>> On 04/10/15 20:24, Julien Grall wrote:
>> > The keyword typeof is not portable:
>> > 
>> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
>> > of function 'typeof' is invalid in C99
>> > [-Werror,-Wimplicit-function-declaration]
>> 
>> Ping? Aside the fact that other bits of the header may not be iso
>> compliant, I still think this patch is valid.
> 
> Yes, I agree.
> Acked-by: Ian Campbell 
> 
> Jan, after your earlier comments are you happy to go ahead with this for
> now and sort the other possible issues separately?

Well - it's an improvement, sure, so I'm not intending to block it
going in if no better way can be determined in its place right away.
What makes me hesitant is that I'm not sure there indeed will be a
follow up to this any time soon.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

[Juergen Gross]

On 10/21/2015 07:10 PM, Dario Faggioli wrote:

On Thu, 2015-10-15 at 10:25 +0200, Juergen Gross wrote:

Maybe it would be a good idea to move setting of per_cpu(cpupool,
cpu)
into schedule_cpu_switch(). Originally I didn't do that to avoid
spreading too much cpupool related actions outside of cpupool.c. But
with those ASSERT()s added hiding that action will cause more
confusion
than having the modification of per_cpu(cpupool, cpu) here.


Coming back to this.

When reworking the series, I tried to move 'per_cpu(cpupool, cpu)=c' in
schedule_cpu_switch() and, about this part:


When doing the code movement the current behaviour regarding sequence
of changes must be kept, of course. So when adding the cpu to a pool
the cpupool information must be set _before_ taking the scheduler
lock,
while when removing this must happen after release of the lock.


I don't think I see why I can't do as in the attached patch (i.e., just
update the cpupool per-cpu variable at the bottom of
schedule_cpu_switch() ).

I don't see anything in the various schedulers' code that relies on
that variable, except one thing in sched_credit.c, which looks safe to
me. And indeed I think that even any future potential code being added
there, should either not depend on it, or do it "safely".

Also, all the operations done in schedule_cpu_switch() itself, depend
either on per_cpu(scheduler) or on per_cpu(schedule_data) being updated
properly, rather than on per_cpu(cpupool) (including the locking that
you are mentioning above).

What am I missing?


Hmm, good question. I'm rather sure I had a problem related to exactly
this topic in the early days of cpupools. Maybe the critical code has
been modified since then. Or my memory is wrong. Or we both don't see
it now. ;-)

In case there is a problem it should show up doing a test which
concurrently does all of the following:

- move a domain between two cpupools
- move a cpu between the two cpupools
- create and destroy a domain in one of the two cpupools

If the system is surviving this test for a couple of hours you are fine
and then for the attached patch:

Acked-by: Juergen Gross 


Juergen



Regards,
Dario
---
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index e79850b..8e7b723 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -261,19 +261,13 @@ int cpupool_move_domain(struct domain *d, struct cpupool 
*c)
  static int cpupool_assign_cpu_locked(struct cpupool *c, unsigned int cpu)
  {
  int ret;
-struct cpupool *old;
  struct domain *d;

  if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
  return -EBUSY;
-old = per_cpu(cpupool, cpu);
-per_cpu(cpupool, cpu) = c;
  ret = schedule_cpu_switch(cpu, c);
  if ( ret )
-{
-per_cpu(cpupool, cpu) = old;
  return ret;
-}

  cpumask_clear_cpu(cpu, _free_cpus);
  if (cpupool_moving_cpu == cpu)
@@ -326,7 +320,6 @@ static long cpupool_unassign_cpu_helper(void *info)
  cpumask_clear_cpu(cpu, _free_cpus);
  goto out;
  }
-per_cpu(cpupool, cpu) = NULL;
  cpupool_moving_cpu = -1;
  cpupool_put(cpupool_cpu_moving);
  cpupool_cpu_moving = NULL;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d7e2d98..9072540 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,6 +1486,17 @@ void __init scheduler_init(void)
  BUG();
  }

+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ *  (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
  int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
  {
  unsigned long flags;
@@ -1494,9 +1505,24 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
  void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
  struct scheduler *old_ops = per_cpu(scheduler, cpu);
  struct scheduler *new_ops = (c == NULL) ?  : c->sched;
+struct cpupool *old_pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ */
+ASSERT(c != old_pool && (c != NULL || 

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

[Ian Campbell]

On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, October 23, 2015 4:15 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> > 
> > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> > 
> > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > 
> > > [Hu, Robert]
> > > Seems the failure log shall be this, any idea? I've spent days on
> > > debugging this:(
> > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > > (XEN) PCI add device :00:00.0
> > > (XEN) PCI add device :00:01.0
> > > (XEN) PCI add device :00:01.1
> > > (XEN) PCI add device :00:01.2
> > > (XEN) PCI add device :00:01.3
> > > (XEN) PCI add device :00:02.0
> > > (XEN) PCI add device :00:03.0
> > > (XEN) d0: Forcing read-only access to MFN fed00
> > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > Issued domain 3 reboot
> > > qemu: terminating on signal 1 from pid 4322
> > 
> > Please can you report this as a regular bug in a fresh thread, that way
> > the relevant Xen maintainers are likely to see and react to it, rather
> > than just us osstest folks.
> [Hu, Robert] 
> 
> It shall be in that way after I confirm it is a bug.
> Currently I'm just still not certain it is a nested bug or because of the
> latest
> osstest code change.
> I was just asking for if you can recall some hint on what changes (of
> osstest)
> might causing this.
> I'm to restore to my v12 code, with current Xen and qemu selection to try
> again. I think by this way, I can confirm it is an actual nested bug or
> not.
> Then I would report this in a fresh thread.

A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
whether it is exposed by a new osstest case or not. The people who are best
placed to figure out where the bug is are certainly not reading this
osstest thread.

So please just report it as a bug as it stands, with the relevant
information.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH V3 2/2] xen-netfront: limit vnic max_queues number to online cpus

[Joe Jin]

Should not allocate vnic queues number more than online cpus.

Signed-off-by: Joe Jin 
Cc: Jan Beulich 
Cc: Wei Liu 
Cc: Ian Campbell 
Cc: Boris Ostrovsky 
Cc: Konrad Rzeszutek Wilk 
---
 drivers/net/xen-netfront.c |   28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index f821a97..5cc2f4a 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -58,7 +58,9 @@
 
 /* Module parameters */
 static unsigned int xennet_max_queues;
-module_param_named(max_queues, xennet_max_queues, uint, 0644);
+static int xennet_set_max_queues(const char *val, struct kernel_param *kp);
+module_param_call(max_queues, xennet_set_max_queues, param_get_uint,
+ _max_queues, 0644);
 MODULE_PARM_DESC(max_queues,
 "Maximum number of queues per virtual interface");
 
@@ -164,6 +166,19 @@ struct netfront_rx_info {
struct xen_netif_extra_info extras[XEN_NETIF_EXTRA_TYPE_MAX - 1];
 };
 
+static int xennet_set_max_queues(const char *val, struct kernel_param *kp)
+{
+   unsigned int cpus = num_online_cpus();
+   unsigned int max_queues = simple_strtoul(val, NULL, 10);
+
+   if (max_queues == 0 || max_queues > cpus) {
+   pr_err("max_queues %u is out of range [1 - %u]!\n", 
+  max_queues, cpus);
+   return -ERANGE;
+   }
+   return param_set_uint(val, kp);
+}
+
 static void skb_entry_set_link(union skb_entry *list, unsigned short id)
 {
list->link = id;
@@ -2126,6 +2141,8 @@ static struct xenbus_driver netfront_driver = {
 
 static int __init netif_init(void)
 {
+   unsigned int cpus = num_online_cpus();
+
if (!xen_domain())
return -ENODEV;
 
@@ -2134,11 +2151,10 @@ static int __init netif_init(void)
 
pr_info("Initialising Xen virtual ethernet driver\n");
 
-   /* Allow as many queues as there are CPUs if user has not
-* specified a value.
-*/
-   if (xennet_max_queues == 0)
-   xennet_max_queues = num_online_cpus();
+   /* Allow at most as many queues as there are CPUs. */
+   if (xennet_max_queues == 0 || xennet_max_queues > cpus)
+   xennet_max_queues = cpus;
+   pr_info("max_queues: %d\n", xennet_max_queues);
 
return xenbus_register_frontend(_driver);
 }
-- 
1.7.1




___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 1/5] xen/arm: vgic-v2: Handle correctly byte write in ITARGETSR

[Julien Grall]

On 23/10/15 10:33, Ian Campbell wrote:
> On Thu, 2015-10-22 at 17:36 +0100, Julien Grall wrote:
>> On 22/10/15 16:53, Ian Campbell wrote:
>>> On Mon, 2015-10-12 at 15:22 +0100, Julien Grall wrote:

[...]


 Furthermore, the body of the loop is retrieving the old target list
 using the index of the byte.

 To avoid modifying too much the loop, shift the byte stored to the
 correct
 offset.
>>>
>>> That might have meant a smaller patch, but it's a lot harder to
>>> understand
>>> either the result or the diff.
>>
>> The size of the patch would have been the same. Although, it requires to
>> modify the call to vgic_byte_read in the loop to access the correct
>> interrupt.
>>
>> I didn't try to spend to much time to modify the loop because the
>> follow-up patch (#2) will rewrite the loop.
> 
> Since this patch is marked for backport then if we decided to take #2 then
> that's probably ok, otherwise the state of the tree after just this patch
> is more relevant.
> That's in itself probably a stronger argument for taking #2 than the actual
> functionality of #2 is.

This code is already complex and I don't think the loop modification would have
make the code easier to read.

Although, my plan was to ask to backport the whole series once we exercise
the code a bit in unstable. This is in order to fix 32-bit access on 64-bit
register.

>>
>> [...]
>>
  xen/arch/arm/vgic-v2.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

 diff --git a/xen/arch/arm/vgic-v2.c b/xen/arch/arm/vgic-v2.c
 index 2d63e12..665afeb 100644
 --- a/xen/arch/arm/vgic-v2.c
 +++ b/xen/arch/arm/vgic-v2.c
 @@ -346,11 +346,11 @@ static int vgic_v2_distr_mmio_write(struct vcpu
 *v, mmio_info_t *info,
  /* 8-bit vcpu mask for this domain */
  BUG_ON(v->domain->max_vcpus > 8);
  target = (1 << v->domain->max_vcpus) - 1;
 -if ( dabt.size == 2 )
 -target = target | (target << 8) | (target << 16) |
 (target << 24);
 +target = target | (target << 8) | (target << 16) | (target
 << 24);
 +if ( dabt.size == DABT_WORD )
 +target &= r;
  else
 -target = (target << (8 * (gicd_reg & 0x3)));
 -target &= r;
 +target &= (r << (8 * (gicd_reg & 0x3)));
>>>
>>> At this point do you not now have 3 bytes of
>>> (1 << v->domain->max_vcpus) - 1;
>>> and 1 byte of that masked with the write?
>>>
>>> IOW isn't this modifying the 3 bytes which aren't written?
>>
>> No, the current loop search for bit set to 1. As the target variable
>> will only contain one byte with some bit set to 1, only the IRQ
>> associated to this byte will be updated.
> 
> Um, OK, I'll take your word for that.

FWIW, I wrote a Linux patch to exercise the code changed and
I didn't see any possible issue:

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 982c09c..b6de74f 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -446,6 +446,7 @@ static void gic_cpu_if_up(struct gic_chip_data *gic)
writel_relaxed(bypass | mode | GICC_ENABLE, cpu_base + GIC_CPU_CTRL);
 }
 
+#include 
 
 static void __init gic_dist_init(struct gic_chip_data *gic)
 {
@@ -453,6 +454,7 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
u32 cpumask;
unsigned int gic_irqs = gic->gic_irqs;
void __iomem *base = gic_data_dist_base(gic);
+   void __iomem *target = base + GIC_DIST_TARGET;
 
writel_relaxed(GICD_DISABLE, base + GIC_DIST_CTRL);
 
@@ -465,6 +467,45 @@ static void __init gic_dist_init(struct gic_chip_data *gic)
for (i = 32; i < gic_irqs; i += 4)
writel_relaxed(cpumask, base + GIC_DIST_TARGET + i * 4 / 4);
 
+   for (i = 32; i < 34; i++) {
+   unsigned int n = i / 4;
+   unsigned int nb = i % 4;
+   int j;
+   void __iomem *regaddr = target + (i & ~0x3);
+   void __iomem *byte = target + i;
+
+   xen_raw_printk("Exerce ITARGETSR for irq %u\n", i);
+   xen_raw_printk("\t 32-bit ITARGETSR%u = 0x%x\n",
+  n, readl_relaxed(regaddr));
+   xen_raw_printk("\t 8-bit ITARGETSR%u[%u] = 0x%x\n",
+  n, nb, readb_relaxed(byte));
+   for (j = 0; j < 5; j++) {
+   xen_raw_printk("switch to CPU%u\n", j);
+   writeb(1 << j, byte);
+   xen_raw_printk("\t 32-bit ITARGETSR%u = 0x%x\n",
+  n, readl_relaxed(regaddr));
+   xen_raw_printk("\t 8-bit ITARGETSR%u[%u] = 0x%x\n",
+  n, nb, readb_relaxed(byte));
+   }
+   }
+
+   cpumask = 0x2;
+   cpumask |= cpumask << 8;
+   cpumask |= cpumask << 16;
+   xen_raw_printk("Excerce 

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add support of PSCI v1.0 for the host

[Julien Grall]

On 23/10/15 11:39, Ian Campbell wrote:
> On Thu, 2015-10-22 at 18:17 +0100, Julien Grall wrote:
>> Hi,
>>
>> On 22/10/15 16:42, Ian Campbell wrote:
>>> On Mon, 2015-10-12 at 16:39 +0100, Julien Grall wrote:
>>>
>>> Subject: support PSCI v1.0 for the host.
>>>
 From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
>>>Xen's
>>>
 the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
 SYSTEM_RESET) behaves exactly the same.
>>>
>>> behave
>>>
 Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version must
 be
 compatible with 1.x when y > x for any functions existing in 1.x.

 So check the presence of the new compatible string [1] and allow Xen
 to
 boot on any platform using PSCI 1.x.

 [1] 
 http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/37
 4547.html

 Signed-off-by: Julien Grall 
>>>
>>> Acked-by: Ian Campbell 
>>
>> Shall I resend a new version with those typos fixed? Or do you plan to
>> do it when you'll commit the patch?
> 
> Looks like those are the only changes required, so assuming you are are
> happy with them I'll just do them on commit.

I'm fine with that.

Thank you!

-- 
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 2/3] xl: convert vcpu related return codes to EXIT_[SUCCESS|FAILURE]

[Dario Faggioli]

On Fri, 2015-10-23 at 13:18 +0530, Harmandeep Kaur wrote:
> turning vcpu manipulation functions xl exit codes toward using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
> 
So, this patch is, technically, mostly fine. The observations on the
subject made when reviewing patch 1 applies here too, of course.

Something on the selection of functions the functions. The title says
the patch will address "vcpu related functions". However, there are a
bunch of parse_*() functions in the diff.

I appreciate that, for instance, parse_vcpu_affinity() can be
considered a vcpu related function, but that applies a lot less to
 parse_vnuma_config(), IMO. I'd therefore exclude the latter from this
patch.

Alternatively, get rid of both and do another patch specifically for
dealing with parse_*() items. There are not many of them that are
actual exit paths and/or contain calls to exit() (parse_config_data()
is big enough, and a bit more complex, that it may well deserve its own
patch, and you can leave it alone, just mention that in the changelog).

A few more comments below.

> @@ -5461,7 +5461,7 @@ static int vcpuset(uint32_t domid, const char*
> nr_vcpus, int check_host)
>  
>  rc = libxl_domain_info(ctx, , domid);
>  if (rc)
> -return 1;
> +return EXIT_FAILURE;
>  
 if (libxl_domain_info(ctx, , domid))
 return EXIT_FAILURE;

>  if (max_vcpus > dominfo.vcpu_online && max_vcpus > host_cpu)
> {
>  fprintf(stderr, "You are overcommmitting! You have %d
> physical" \
> @@ -5471,12 +5471,12 @@ static int vcpuset(uint32_t domid, const
> char* nr_vcpus, int check_host)
>  }
>  libxl_dominfo_dispose();
>  if (rc)
> -return 1;
> +return EXIT_FAILURE;
>  }
>  rc = libxl_cpu_bitmap_alloc(ctx, , max_vcpus);
>  if (rc) {
>  fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc: %d\n",
> rc);
> -return 1;
> +return EXIT_FAILURE;
>
 if (libxl_cpu_bitmap_alloc(ctx, , max_vcpus))
 return EXIT_FAILURE;

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU-XEN v4 3/9] xen: Switch to libxengnttab interface for compat shims.

[Stefano Stabellini]

On Wed, 21 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> One such library will be libxengnttab which provides access to grant
> tables.
> 
> In preparation for this switch the compatibility layer in xen_common.h
> (which support building with older versions of Xen) to use what will
> be the new library API. This means that the gnttab shim will disappear
> for versions of Xen which include libxengnttab.
> 
> To simplify things for the <= 4.0.0 support we wrap the int fd in a
> malloc(sizeof int) such that the handle is always a pointer. This
> leads to less typedef headaches and the need for
> XC_HANDLER_INITIAL_VALUE etc for these interfaces.
> 
> Build tested with 4.0 and 4.5.
> 
> Note that this patch does not add any support for actually using
> libxengnttab, it just adjusts the existing shims.
> 
> Signed-off-by: Ian Campbell 

The patch looks OK but doesn't apply cleanly to master, please rebase.
After fixing it up, it fails my 4.0 build test (I probably made a
mistake).


> v4: Ran checkpatch, fixed all errors
> Allocate correct size for handle (i.e. not size of the ptr)
> Rebase onto "xen_console: correctly cleanup primary console on
> teardown."
> ---
>  hw/block/xen_disk.c  | 38 --
>  hw/char/xen_console.c|  4 ++--
>  hw/net/xen_nic.c | 16 
>  hw/xen/xen_backend.c | 10 +-
>  include/hw/xen/xen_backend.h |  2 +-
>  include/hw/xen/xen_common.h  | 42 --
>  6 files changed, 68 insertions(+), 44 deletions(-)
> 
> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
> index 21842a0..15413f6 100644
> --- a/hw/block/xen_disk.c
> +++ b/hw/block/xen_disk.c
> @@ -172,11 +172,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
> gpointer user_data)
>  static void destroy_grant(gpointer pgnt)
>  {
>  PersistentGrant *grant = pgnt;
> -XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
>  
> -if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
> +if (xengnttab_munmap(gnt, grant->page, 1) != 0) {
>  xen_be_printf(>blkdev->xendev, 0,
> -  "xc_gnttab_munmap failed: %s\n",
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  grant->blkdev->persistent_gnt_count--;
> @@ -189,11 +189,11 @@ static void remove_persistent_region(gpointer data, 
> gpointer dev)
>  {
>  PersistentRegion *region = data;
>  struct XenBlkDev *blkdev = dev;
> -XenGnttab gnt = blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
>  
> -if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
> +if (xengnttab_munmap(gnt, region->addr, region->num) != 0) {
>  xen_be_printf(>xendev, 0,
> -  "xc_gnttab_munmap region %p failed: %s\n",
> +  "xengnttab_munmap region %p failed: %s\n",
>region->addr, strerror(errno));
>  }
>  xen_be_printf(>xendev, 3,
> @@ -328,7 +328,7 @@ err:
>  
>  static void ioreq_unmap(struct ioreq *ioreq)
>  {
> -XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
>  int i;
>  
>  if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
> @@ -338,8 +338,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  if (!ioreq->pages) {
>  return;
>  }
> -if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
> -xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
> failed: %s\n",
> +if (xengnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
> +xen_be_printf(>blkdev->xendev, 0,
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  ioreq->blkdev->cnt_map -= ioreq->num_unmap;
> @@ -349,8 +350,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  if (!ioreq->page[i]) {
>  continue;
>  }
> -if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
> -xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
> failed: %s\n",
> +if (xengnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
> +xen_be_printf(>blkdev->xendev, 0,
> +  "xengnttab_munmap failed: %s\n",
>strerror(errno));
>  }
>  ioreq->blkdev->cnt_map--;
> @@ -362,7 +364,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
>  
>  static int ioreq_map(struct ioreq *ioreq)
>  {
> -XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
> +xengnttab_handle *gnt = 

Re: [Xen-devel] [PATCH QEMU-XEN v4 6/9] xen: Switch uses of xc_map_foreign_bulk to use libxenforeignmemory API.

[Stefano Stabellini]

On Wed, 21 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> One such library will be libxenforeignmemory which provides access to
> privileged foreign mappings and which will provide an interface
> equivalent to xc_map_foreign_bulk.
> 
> In preparation for adding support for libxenforeignmemory add support
> to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
> switch to using the new API. These shims will disappear for versions
> of Xen which include libxenforeignmemory.
> 
> Since libxenforeignmemory will have its own handle type but for <= 4.6
> the functionality is provided by using a libxenctrl handle we
> introduce a new global xen_fmem alongside the existing xen_xc. In fact
> we make xen_fmem a pointer to the existing xen_xc, which then works
> correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
> is a pointer). In the latter case xen_fmem is actually a double
> indirect pointer, but it all falls out in the wash.
> 
> Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
> rather than just specifying that munmap should be used, so the unmap
> paths are updated to use xenforeignmemory_unmap, which is a shim for
> munmap on these versions of xen. The mappings in xen-hvm.c do not
> appear to be unmapped (which makes sense for a qemu-dm process)
> 
> In fb_disconnect this results in a change from simply mmap over the
> existing mapping (with an implciit munmap) to expliclty unmapping with
^ implicit

> xenforeignmemory_unmap and then mapping the required anonymous memory
> in the same hole. I don't think this is a problem since any other
> thread which was racily touching this region would already be running
> the risk of hitting the mapping halfway through the call. If this is
> thought to be a problem then we could consider adding an extra API to
> the libxenforeignmemory interface to replace a foreign mapping with
> anonymous shared memory, but I'd prefer not to.
> 
> Build tested with 4.0 and 4.5.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> I noticed in xen_console.c that the decision to use a foreign
> privileged memory mapping vs a grant dev is made using different
> variables in con_initialise vs con_disconnect. The former uses
> xendev->dev while the latter uses xendev->gnttabdev. Is this a latent
> bug?
> 
> v4: Rebase onto "xen_console: correctly cleanup primary console on
> teardown."
> 
> xenforeignmemory_unmap takes pages not bytes
> 
> Compat wrapper for xenforeignmemory_open instead of ifdef in code.
> 
> Run check patch and fix most issues. I did not fix:
> 
> ERROR: do not initialise globals to 0 or NULL
> +xenforeignmemory_handle *xen_fmem = NULL;
> 
> => This is consistent with all of the existing declarations.
> 
> ERROR: need consistent spacing around '*' (ctx:WxV)
> +typedef xc_interface *xenforeignmemory_handle;
> 
> => I think this is a false +ve since this is a pointer "*" not a multiple "*".
> ---
>  hw/char/xen_console.c|  8 
>  hw/display/xenfb.c   | 15 ---
>  hw/xen/xen_backend.c |  3 ++-
>  include/hw/xen/xen_backend.h |  1 +
>  include/hw/xen/xen_common.h  | 12 
>  xen-common.c |  6 ++
>  xen-hvm.c| 18 +-
>  xen-mapcache.c   |  6 +++---
>  8 files changed, 45 insertions(+), 24 deletions(-)
> 
> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
> index 11c6472..24f3a40 100644
> --- a/hw/char/xen_console.c
> +++ b/hw/char/xen_console.c
> @@ -230,9 +230,9 @@ static int con_initialise(struct XenDevice *xendev)
>  
>  if (!xendev->dev) {
>  xen_pfn_t mfn = con->ring_ref;
> -con->sring = xc_map_foreign_bulk(xen_xc, con->xendev.dom,
> - PROT_READ|PROT_WRITE,
> - , , 1);
> +con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
> +  PROT_READ|PROT_WRITE,
> +  , , 1);
>  } else {
>  con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
> con->xendev.dom,
>   con->ring_ref,
> @@ -274,7 +274,7 @@ static void con_disconnect(struct XenDevice *xendev)
>  
>  if (con->sring) {
>  if (!xendev->dev) {
> -munmap(con->sring, XC_PAGE_SIZE);
> +xenforeignmemory_unmap(xen_fmem, con->sring, 1);
>  } else {
>  xengnttab_munmap(xendev->gnttabdev, con->sring, 1);
>  }
> diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
> index b0ac1e6..a5ddb60 100644
> --- a/hw/display/xenfb.c
> +++ b/hw/display/xenfb.c
> @@ -103,8 +103,8 @@ static int 

Re: [Xen-devel] [PATCH QEMU-XEN v4 2/9] xen: Switch to libxenevtchn interface for compat shims.

[Stefano Stabellini]

On Wed, 21 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> One such library will be libxenevtchn which provides access to event
> channels.
> 
> In preparation for this switch the compatibility layer in xen_common.h
> (which support building with older versions of Xen) to use what will
> be the new library API. This means that the evtchn shim will disappear
> for versions of Xen which include libxenevtchn.
> 
> To simplify things for the <= 4.0.0 support we wrap the int fd in a
> malloc(sizeof int) such that the handle is always a pointer. This
> leads to less typedef headaches and the need for
> XC_HANDLER_INITIAL_VALUE etc for these interfaces.
> 
> Build tested with 4.0 and 4.5.
> 
> Note that this patch does not add any support for actually using
> libxenevtchn, it just adjusts the existing shims.
> 
> Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
> since that functionality is not exposed by /dev/xen/evtchn.
> 
> Signed-off-by: Ian Campbell 

Reviewed-by: Stefano Stabellini 


> v4: Ran checkpatch, fixed all errors
> Allocate correct size for handle (i.e. not size of the ptr)
> ---
>  hw/xen/xen_backend.c | 31 ---
>  include/hw/xen/xen_backend.h |  2 +-
>  include/hw/xen/xen_common.h  | 44 
> ++--
>  xen-hvm.c| 25 +
>  4 files changed, 64 insertions(+), 38 deletions(-)
> 
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index b2cb22b..342ec9b 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
> *type, int dom, int dev,
>  xendev->debug  = debug;
>  xendev->local_port = -1;
>  
> -xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
> -if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
> +xendev->evtchndev = xenevtchn_open(NULL, 0);
> +if (xendev->evtchndev == NULL) {
>  xen_be_printf(NULL, 0, "can't open evtchn device\n");
>  g_free(xendev);
>  return NULL;
>  }
> -fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
> +fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
>  
>  if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
>  xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
>  if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
>  xen_be_printf(NULL, 0, "can't open gnttab device\n");
> -xc_evtchn_close(xendev->evtchndev);
> +xenevtchn_close(xendev->evtchndev);
>  g_free(xendev);
>  return NULL;
>  }
> @@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int 
> dev)
>  g_free(xendev->fe);
>  }
>  
> -if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
> -xc_evtchn_close(xendev->evtchndev);
> +if (xendev->evtchndev != NULL) {
> +xenevtchn_close(xendev->evtchndev);
>  }
>  if (xendev->gnttabdev != XC_HANDLER_INITIAL_VALUE) {
>  xc_gnttab_close(xendev->gnttabdev);
> @@ -691,13 +691,14 @@ static void xen_be_evtchn_event(void *opaque)
>  struct XenDevice *xendev = opaque;
>  evtchn_port_t port;
>  
> -port = xc_evtchn_pending(xendev->evtchndev);
> +port = xenevtchn_pending(xendev->evtchndev);
>  if (port != xendev->local_port) {
> -xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
> %d)\n",
> +xen_be_printf(xendev, 0,
> +  "xenevtchn_pending returned %d (expected %d)\n",
>port, xendev->local_port);
>  return;
>  }
> -xc_evtchn_unmask(xendev->evtchndev, port);
> +xenevtchn_unmask(xendev->evtchndev, port);
>  
>  if (xendev->ops->event) {
>  xendev->ops->event(xendev);
> @@ -742,14 +743,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
>  if (xendev->local_port != -1) {
>  return 0;
>  }
> -xendev->local_port = xc_evtchn_bind_interdomain
> +xendev->local_port = xenevtchn_bind_interdomain
>  (xendev->evtchndev, xendev->dom, xendev->remote_port);
>  if (xendev->local_port == -1) {
> -xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
> +xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
>  return -1;
>  }
>  xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
> -qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
> +qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
>  xen_be_evtchn_event, NULL, xendev);
>  return 0;
>  }
> @@ -759,15 +760,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
>  if 

[Xen-devel] passthrough: improve interrupt injection locking

[David Vrabel]

When injecting an interrupt for a passthrough device into a guest, the
per-domain event_lock is held, reducing performance when a guest has
many VCPUs and high interrupt rates.

By using a per-interrupt lock in the hot paths, this contention is
eliminated and performance improves (a bit).

For testing, a 32 VCPU guest with an NVME device assigned to it was
used.  Continual reads with small (512 B) blocks were performed on all
32 hardware queues simultaneously.

* Lock profiling:

Before (elapsed: 60 s):

(XEN) [ 3321.143155] Domain 1 event_lock:
(XEN) [ 3321.143158]   lock:14411627(0005:90714AEF),
  block: 6658599(0003:709F82BD)

After (elapsed: 60 s):

(XEN) [ 1253.921427] Domain 2 event_lock:
(XEN) [ 1253.921429]   lock:8287(:01AE517C),
  block:  67(:000D4C3A)

* Aggregate performance:

MB/s
Before  60.8
After   68.4

David


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

[Ian Jackson]

Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF changeset"):
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > Yes. Those (that?) and the reasons why we aren't just trivially taking them
> > are explained in the referenced thread.

That explanation isn't very convincing to me.

> I cannot believe we are going to move forward without a way to introduce
> any OVMF fixes into the  stable branches.

It is fine to introduce OVMF fixes into stable branches, of course.

But it is not fine to introduce other upstream changes to OVMF,
willy-nilly.

Obviously these two requirements cannot be satisfied without there
being some branch of OVMF which contains the intended fixes, without
the unwanted upstream development.

If OVMF upstream do not have such a branch, we need to create one.

Ian.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU-XEN v4 7/9] xen: Use stable library interfaces when they are available.

[Stefano Stabellini]

On Wed, 21 Oct 2015, Ian Campbell wrote:
> In Xen 4.7 we are refactoring parts libxenctrl into a number of
> separate libraries which will provide backward and forward API and ABI
> compatiblity.
> 
> Specifically libxenevtchn, libxengnttab and libxenforeignmemory.
> 
> Previous patches have already laid the groundwork for using these by
> switching the existing compatibility shims to reflect the intefaces to
> these libraries.
> 
> So all which remains is to update configure to detect the libraries
> and enable their use. Although they are notionally independent we take
> an all or nothing approach to the three libraries since they were
> added at the same time.
> 
> The only non-obvious bit is that we now open a proper xenforeignmemory
> handle for xen_fmem instead of reusing the xen_xc handle.
> 
> Build tested with 4.0, 4.5 and the patches targetting 4.7 which adds
> these libraries.
> 
> Signed-off-by: Ian Campbell 
> ---
> v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.
> 
> Simplify configury by asserting that interface version 470 will
> always have the libraries (lack of them makes it 460).
> 
> Ran checkpatch and fixed everything except:
> 
> ERROR: need consistent spacing around '*' (ctx:WxV)
> +typedef xc_interface *XenXC;
> 
> Which I think is a false +ve.
> 
> simplify configury
> ---
>  configure   | 55 
> +
>  include/hw/xen/xen_common.h | 38 +--
>  2 files changed, 91 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index 779623a..fe0a39d 100755
> --- a/configure
> +++ b/configure
> @@ -1840,6 +1840,7 @@ fi
>  
>  if test "$xen" != "no" ; then
>xen_libs="-lxenstore -lxenctrl -lxenguest"
> +  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
>  
># First we test whether Xen headers and libraries are available.
># If no, we are done and there is no Xen support.
> @@ -1862,6 +1863,57 @@ EOF
># Xen unstable
>elif
>cat > $TMPC < +/*
> + * If we have stable libs the we don't want the libxc compat
> + * layers, regardless of what CFLAGS we may have been given.
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#if !defined(HVM_MAX_VCPUS)
> +# error HVM_MAX_VCPUS not defined
> +#endif
> +int main(void) {
> +  xc_interface *xc;
> +  xenforeignmemory_handle *xfmem;
> +  xenevtchn_handle *xe;
> +  xengnttab_handle *xg;
> +
> +  xs_daemon_open();
> +
> +  xc = xc_interface_open(0, 0, 0);
> +  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
> +  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
> +  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
> +  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
> +
> +  xe = xenevtchn_open(0, 0);
> +  xenevtchn_fd(xe);
> +
> +  xg = xengnttab_open(0, 0);
> +  xengnttab_map_grant_ref(xg, 0, 0, 0);
> +
> +  return 0;
> +}
> +EOF
> +  compile_prog "" "$xen_libs $xen_stable_libs"
> +  then
> +xen_ctrl_version=470
> +xen=yes

this is good


> +
> +  # Xen 4.6
> +  elif
> +  cat > $TMPC <  #include 
>  #include 
>  #include 
> @@ -2037,6 +2089,9 @@ EOF
>fi
>  
>if test "$xen" = yes; then
> +if test $xen_ctrl_version -ge 470  ; then
> + libs_softmmu="$xen_stable_libs $libs_softmmu"

tab


> +fi
>  libs_softmmu="$xen_libs $libs_softmmu"
>fi
>  fi
> diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> index 2a5f27a..38293b4 100644
> --- a/include/hw/xen/xen_common.h
> +++ b/include/hw/xen/xen_common.h
> @@ -6,6 +6,17 @@
>  #include 
>  #include 
>  
> +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470
> +/*
> + * If we have new enough libxenctrl then we do not want/need these compat
> + * interfaces, despite what the user supplied cflags might say. They
> + * must be undefined before including xenctrl.h
> + */
> +#undef XC_WANT_COMPAT_EVTCHN_API
> +#undef XC_WANT_COMPAT_GNTTAB_API
> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#endif

Can we always do the #under given that earlier libxenctrl versions will
simple ignore them?  I am asking because I would prefer to avoid
introducing another ifdef here outside the sequence if ifdefs already
present below.


>  #include 
>  #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
>  #  include 
> @@ -151,8 +162,8 @@ static inline void xs_close(struct xs_handle *xsh)
>  }
>  
>  
> -/* Xen 4.1 */
> -#else
> +/* Xen 4.1 thru 4.6 */
> +#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
>  
>  typedef xc_interface *XenXC;
>  typedef xc_interface *xenforeignmemory_handle;
> @@ -195,6 +206,29 @@ static inline int xc_fd(xc_interface *xen_xc)
>  {
>  return -1;
>  }
> +#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION 

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add support of PSCI v1.0 for the host

[Ian Campbell]

On Thu, 2015-10-22 at 18:17 +0100, Julien Grall wrote:
> Hi,
> 
> On 22/10/15 16:42, Ian Campbell wrote:
> > On Mon, 2015-10-12 at 16:39 +0100, Julien Grall wrote:
> > 
> > Subject: support PSCI v1.0 for the host.
> > 
> > > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar. All
> >Xen's
> > 
> > > the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF and
> > > SYSTEM_RESET) behaves exactly the same.
> > 
> > behave
> > 
> > > Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version must
> > > be
> > > compatible with 1.x when y > x for any functions existing in 1.x.
> > > 
> > > So check the presence of the new compatible string [1] and allow Xen
> > > to
> > > boot on any platform using PSCI 1.x.
> > > 
> > > [1] 
> > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/37
> > > 4547.html
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Acked-by: Ian Campbell 
> 
> Shall I resend a new version with those typos fixed? Or do you plan to
> do it when you'll commit the patch?

Looks like those are the only changes required, so assuming you are are
happy with them I'll just do them on commit.


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH QEMU-XEN v4 9/9] xen: make it possible to build without the Xen PV domain builder

[Stefano Stabellini]

On Wed, 21 Oct 2015, Ian Campbell wrote:
> Until the previous patch this relied on xc_fd(), which was only
> implemented for Xen 4.0 and earlier.
> 
> Given this wasn't working since Xen 4.0 I have marked this as disabled
> by default.
> 
> Removing this support drops the use of a bunch of symbols from
> libxenctrl, specifically:
> 
>   - xc_domain_create
>   - xc_domain_destroy
>   - xc_domain_getinfo
>   - xc_domain_max_vcpus
>   - xc_domain_setmaxmem
>   - xc_domain_unpause
>   - xc_evtchn_alloc_unbound
>   - xc_linux_build
> 
> This is another step towards only using Xen libraries which provide a
> stable inteface.
> 
> Signed-off-by: Ian Campbell 
> ---
> v4: Fixed all checkpatch errors.
> Disabled by default.
> ---
>  configure | 17 +
>  hw/xenpv/Makefile.objs|  4 +++-
>  hw/xenpv/xen_machine_pv.c | 14 ++
>  3 files changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/configure b/configure
> index fe0a39d..9eab587 100755
> --- a/configure
> +++ b/configure
> @@ -910,6 +910,10 @@ for opt do
>;;
>--enable-xen-pci-passthrough) xen_pci_passthrough="yes"
>;;
> +  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
> +  ;;
> +  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
> +  ;;
>--disable-brlapi) brlapi="no"
>;;
>--enable-brlapi) brlapi="yes"
> @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
>fi
>  fi
>  
> +if test "$xen_pv_domain_build" != "no"; then
> +  if test "$xen_pv_domain_build" = "yes" &&
> + test "$xen" != "yes"; then
> +  error_exit "User requested Xen PV domain builder support" \
> +  "which requires Xen support."
> +  fi
> +  xen_pv_domain_build=no
> +fi

Can we simplify this to:

  if test "$xen_pv_domain_build" = "yes" &&
   test "$xen" != "yes"; then
error_exit "User requested Xen PV domain builder support" \
 "which requires Xen support."
fi
  fi

and move xen_pv_domain_build=no at the beginning of the file?


>  ##
>  # libtool probe
>  
> @@ -4393,6 +4406,7 @@ fi
>  echo "xen support   $xen"
>  if test "$xen" = "yes" ; then
>echo "xen ctrl version  $xen_ctrl_version"
> +  echo "pv dom build $xen_pv_domain_build"
>  fi
>  echo "brlapi support$brlapi"
>  echo "bluez  support$bluez"
> @@ -4725,6 +4739,9 @@ fi
>  if test "$xen" = "yes" ; then
>echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
>echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
> $config_host_mak
> +  if test "$xen_pv_domain_build" = "yes" ; then
> +echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> +  fi
>  fi
>  if test "$linux_aio" = "yes" ; then
>echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
> diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
> index 49f6e9e..bbf5873 100644
> --- a/hw/xenpv/Makefile.objs
> +++ b/hw/xenpv/Makefile.objs
> @@ -1,2 +1,4 @@
>  # Xen PV machine support
> -obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
> +obj-$(CONFIG_XEN) += xen_machine_pv.o
> +# Xen PV machine builder support
> +obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 2e545d2..e5b3698 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -30,9 +30,6 @@
>  
>  static void xen_init_pv(MachineState *machine)
>  {
> -const char *kernel_filename = machine->kernel_filename;
> -const char *kernel_cmdline = machine->kernel_cmdline;
> -const char *initrd_filename = machine->initrd_filename;
>  DriveInfo *dinfo;
>  int i;
>  
> @@ -46,13 +43,22 @@ static void xen_init_pv(MachineState *machine)
>  case XEN_ATTACH:
>  /* nothing to do, xend handles everything */
>  break;
> -case XEN_CREATE:
> +case XEN_CREATE: {
> +#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
> +const char *kernel_filename = machine->kernel_filename;
> +const char *kernel_cmdline = machine->kernel_cmdline;
> +const char *initrd_filename = machine->initrd_filename;
>  if (xen_domain_build_pv(kernel_filename, initrd_filename,
>  kernel_cmdline) < 0) {
>  fprintf(stderr, "xen pv domain creation failed\n");
>  exit(1);
>  }
> +#else
> +fprintf(stderr, "xen pv domain creation not supported\n");
> +exit(1);
> +#endif
>  break;
> +}
>  case XEN_EMULATE:
>  fprintf(stderr, "xen emulation not implemented (yet)\n");
>  exit(1);

Please add a default case with an error and place the XEN_CREATE
entirely within the ifdef CONFIG_XEN_PV_DOMAIN_BUILD.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel