On Wed, 2015-02-25 at 12:23 +, Andrew Cooper wrote:
On 25/02/15 12:16, Ian Campbell wrote:
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
[...]
[]
Translated addresses (in d-arch.vgic.{c,d}base) are now bus addresses
which could not always be applied to the DT.
Copy the original addresses from DT directly to get the original
untranslated reg property which will give same d-arch.vgic.{c,d}base
values once translated again.
Signed-off-by:
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
When doing an OSSTEST_USE_HEAD test in infrastructure mode we would
like to use the real osstest mainline baseline as a reference for the
flight reports. (Rather than simply using the very version under test
as the baseline.)
So revert
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
We don't want sg-report-flight digging through the `test history
database' (which doesn't really exist in standalone mode) looking for
a baseline.
Passing OLD_REVISION=NONE also avoids calling ./ap-fetch-version-old
for the current
On Fri, 2015-02-13 at 02:07 +, Xu, Quan wrote:
I try to redefine tpm2_types.h, deleting 'UINT16, UINT32 ..' and changing
'TPM_HANDLE ...' to ' TPM2_HANDLE ..',
Or, could you give some advice? Thanks.
Perhaps make stubdom/vtpmmgr/types.h with these and use it for both?
Or switch to the
On 25/02/15 12:16, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took
On 25/02/15 12:16, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took
On Thu, 2015-02-19 at 15:13 +, Ian Campbell wrote:
On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
Although, I think the debug message in bad_trap is useful to keep. It
may be handy to have the HSR and the guest stack trace printed if Xen
hit the condition.
Doesn't
On Thu, 2015-02-19 at 16:20 +, Julien Grall wrote:
Regardless the question,this patch look good to me. With the 2 nits I
spotted on my previous email:
Reviewed-by: Julien Grall julien.gr...@linaro.org
Thanks, applied both patches (with nits fixed)
Regards,
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took the opportunity to also confirm that x86_32,
On Wed, Feb 25, 2015 at 12:16:50PM +, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as
Hi Dario,
In summary, I agree with you and will apply these comments discussed
in this thread to work out a RFC patch for it. Below is just some
reply to your question. :-)
2015-02-25 3:44 GMT-05:00 Dario Faggioli dario.faggi...@citrix.com:
On Tue, 2015-02-24 at 21:42 -0500, Meng Xu wrote:
Hi
On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Ian Campbell wrote:
On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
Now that we autodetect the use of dom0_mem and set autoballooning
On 25/02/15 14:17, Stefano Stabellini wrote:
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This unwraps XEN_BACKEND from depending on XEN_DOM0, it
instead makes it depend on the possible x86 backends and
under what scenerios its allowed under ARM. This
On 02/25/15 03:30, Jan Beulich wrote:
On 24.02.15 at 19:29, dsl...@verizon.com wrote:
+/*
+ * Test out special #GP handling for the VMware port 0x5658.
+ * This is done in two modes, j=0 and j=1. Testing 4
+ * instructions (all the basic PIO) in both modes.
+ *
+ *
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took the opportunity to also confirm that x86_32,
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsigned i;
+
+for (i = 0; i XEN_N_RESERVED_AREAS; i++) {
+
+if
Do not override this if the environment already has one.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
branch-settings.osstest |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/branch-settings.osstest b/branch-settings.osstest
index 060ff4b..fe9561f 100644
---
While testing Wei Liu's XSM series, I found that the adhoc testing
arrangements less than ideal.
After these patches, I can create `daily-cron-email-liuw' containing
To: ian.jack...@eu.citrix.com, Wei Liu wei.l...@citrix.com
and (in my own account on the test controller) do this:
We don't want sg-report-flight digging through the `test history
database' (which doesn't really exist in standalone mode) looking for
a baseline.
Passing OLD_REVISION=NONE also avoids calling ./ap-fetch-version-old
for the current branch. This is useful particularly when the current
branch is
When ap-fetch-version and ap-fetch-version-old are run on the osstest
controller but as a different user they should look in ~osstest, not
$HOME, for the master testing.git tree.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
ap-fetch-version |2 +-
ap-fetch-version-old |2
Defer computing this variable until it is going to be used.
The effect is that the fallback default value is assigned much later -
in start_email (cr-daily-branch) or send_bisection_email (cri-bisect).
Previously it was assigned as soon as cri-args-hostlists was read,
which is quite early.
In
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
Do not override this if the environment already has one.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
___
Xen-devel mailing list
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
This is prefixed before the other computed prefixes. It makes it
easier to distinguish an adhoc cr-daily-branch test runs for a real
branch.
Do they not already get adhoc in the $subject? i.e. my commissioning
runs for the new arm create
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
Defer computing this variable until it is going to be used.
The effect is that the fallback default value is assigned much later -
in start_email (cr-daily-branch) or send_bisection_email (cri-bisect).
Previously it was assigned as soon
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
OSSTEST_NO_BASELINE disables the thing where cr-daily-branch decides
(based on information from sg-check-tested) that the baseline is
untested and therefore that it ought to do a baseline test instead of
testing the tip.
This whole
On 25/02/15 13:39, Ian Campbell wrote:
+ * Guest transmit
+ * ==
+ *
+ * Ring slot size is 12 octets, however not all request/response
+ * structs use the full size.
+ *
+ * tx request data (netif_tx_request_t)
+ *
+ *
+ *0 1
On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Fri, Dec 12, 2014 at 9:29
On Tue, Feb 24, 2015 at 03:00:16PM +, Anthony PERARD wrote:
On Tue, Feb 24, 2015 at 01:22:19PM +, Daniel P. Berrange wrote:
On Tue, Feb 24, 2015 at 01:15:57PM +, Anthony PERARD wrote:
On Tue, Feb 24, 2015 at 12:46:44PM +, Daniel P. Berrange wrote:
On Tue, Feb 24, 2015 at
On Wed, 2015-02-25 at 13:48 +0100, Jürgen Groß wrote:
On 02/25/2015 01:16 PM, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a
On Wed, 2015-02-25 at 12:59 +, Andrew Cooper wrote:
On 25/02/15 12:16, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux
On 02/25/2015 05:35 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, boris.ostrov...@oracle.com wrote:
@@ -121,10 +123,12 @@ struct npfec {
#define _MEMF_exact_node 4
#define MEMF_exact_node (1U_MEMF_exact_node)
#define _MEMF_node8
-#define MEMF_node(n)
On Wed, 25 Feb 2015, Ian Campbell wrote:
On Wed, 2015-02-25 at 12:00 +, Ian Campbell wrote:
On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Ian Campbell wrote:
On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
Now that we autodetect
On 25/02/15 14:32, Ian Campbell wrote:
On Thu, 2015-02-19 at 15:13 +, Ian Campbell wrote:
On Thu, 2015-02-19 at 14:42 +, Julien Grall wrote:
Although, I think the debug message in bad_trap is useful to keep. It
may be handy to have the HSR and the guest stack trace printed if Xen
On Wed, 25 Feb 2015, David Vrabel wrote:
On 25/02/15 14:17, Stefano Stabellini wrote:
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This unwraps XEN_BACKEND from depending on XEN_DOM0, it
instead makes it depend on the possible x86 backends and
On Wed, 2015-02-25 at 11:39 +, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Ian Campbell wrote:
On Tue, 2015-02-24 at 16:06 +, Stefano Stabellini wrote:
Now that we autodetect the use of dom0_mem and set autoballooning
correctly perhaps we should just revert a39b5bc64?
On 02/25/2015 01:16 PM, Ian Campbell wrote:
In RFC style, rather than relying on the implicit assumptions of a
particular C ABI.
I have also confirmed, using the Python gdb extension technique in
[0], that the struct offsets (in a Linux binary at least) are the same
as described here.
I took
OSSTEST_NO_BASELINE disables the thing where cr-daily-branch decides
(based on information from sg-check-tested) that the baseline is
untested and therefore that it ought to do a baseline test instead of
testing the tip.
This whole feature is never correct in standalone mode, where there is
no
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cri-args-hostlists |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index ef4cebd..1acecb6 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -50,7 +50,9 @@ elif [
This is prefixed before the other computed prefixes. It makes it
easier to distinguish an adhoc cr-daily-branch test runs for a real
branch.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
---
cri-args-hostlists |2 +-
cri-bisect |2 +-
2 files changed, 2 insertions(+), 2
When doing an OSSTEST_USE_HEAD test in infrastructure mode we would
like to use the real osstest mainline baseline as a reference for the
flight reports. (Rather than simply using the very version under test
as the baseline.)
So revert cf805fa8 Allow forcing the use of current osstest HEAD for
On 02/25/2015 04:34 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, boris.ostrov...@oracle.com wrote:
--- a/xen/arch/x86/srat.c
+++ b/xen/arch/x86/srat.c
@@ -27,35 +27,79 @@ static nodemask_t memory_nodes_parsed __initdata;
static nodemask_t processor_nodes_parsed __initdata;
static nodemask_t
On Wed, 2015-02-25 at 13:01 +, Ian Jackson wrote:
When ap-fetch-version and ap-fetch-version-old are run on the osstest
controller but as a different user they should look in ~osstest, not
$HOME, for the master testing.git tree.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
But
On 25.02.15 at 14:30, boris.ostrov...@oracle.com wrote:
On 02/25/2015 05:35 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, boris.ostrov...@oracle.com wrote:
@@ -121,10 +123,12 @@ struct npfec {
#define _MEMF_exact_node 4
#define MEMF_exact_node (1U_MEMF_exact_node)
#define _MEMF_node
On Wed, 25 Feb 2015, Stefano Stabellini wrote:
On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez
On 25/02/15 11:14, Frediano Ziglio wrote:
Translated address (in d-arch.vgic.{c,d}base) are now bus addresses
addresses
which could not always be applied to the DT.
Copy the original address from DT directly to get the original
addresses
untraslated reg property which will give same
On 25.02.15 at 14:11, boris.ostrov...@oracle.com wrote:
On 02/25/2015 04:34 AM, Jan Beulich wrote:
On 24.02.15 at 20:11, boris.ostrov...@oracle.com wrote:
+{ [0 ... MAX_NUMNODES - 1] = {.node = NUMA_NO_NODE} };
+
+static int node_to_pxm(int n);
I don't see why you need to reinstate this
flight 35312 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rhel6hvm-amd 6 leak-check/basis(6) running in 34247
[st=running!]
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This unwraps XEN_BACKEND from depending on XEN_DOM0, it
instead makes it depend on the possible x86 backends and
under what scenerios its allowed under ARM. This is as per
the agreed upon Xen Kconfig
offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Signed-off-by: pedro pma...@cemitec.com
---
drivers/net/xen-netback/netback.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Wed, Feb 25, 2015 at 03:27:13PM +0100, pedro wrote:
offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Signed-off-by: pedro pma...@cemitec.com
Acked-by: Wei Liu wei.l...@citrix.com
Thanks for the patch.
One question
Non-anonymous allocations with this flag set should - for the purpose
of the availability check - be treated just like anonymous ones, as
they wouldn't lead to a reduction of -outstanding_pages.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/common/page_alloc.c
+++
On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
FWIW, this code in openstack was only added for benefit of s390
architecture where apparently it is common to have hosts with
CPUs offlined. Presumably you have to pay IBM for each extra
CPU you turn online :)
Presumably :-)
OOI,
flight 35317 ovmf real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35317/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 5 xen-boot fail REGR. vs. 33686
test-amd64-i386-pair 17
Hello,
I have made a naive attempt at compiling a modified version of Xentrace
using RELEASE-4.5.0. After executing #make tools successfully, I retrieved
the binary found in the /xen/dist/install/usr/local/bin/xentrace and
attempted to run that on Xenserver. I get the error:
libxenctrl.so.4.5
Hi Frediano,
On 25/02/15 15:28, Frediano Ziglio wrote:
HiSilison Hip04 platform use a slightly different version
I honestly don't like the idea to copy the whole GIC-v2 drivers. It
will require more maintenance for us.
Is there any way to introduce callbacks in the GICv2 code where
Original the structure was memset to a poison value. That prevented
_dispose to be made idempotent. We should stop doing so.
Memseting the structure to 0 makes all pointers in structure become
NULL, which can be handled by free().
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell
These functions are not generated, so we need to do it by hand.
Functions list:
libxl_bitmap_dispose
libxl_string_list_dispose
libxl_key_value_list_dipose
libxl_cpuid_dispose
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson
On Thu, 2015-02-19 at 18:12 +, Julien Grall wrote:
While it's easy to know which hardware IRQ is assigned to a domain, there
is no way to know which vIRQ is allocated by Xen for a specific domain.
Introduce a bitmap to keep track of every vIRQ used by a domain. This
will be used later to
On Wed, Feb 25, 2015 at 10:24:37AM +0100, Dario Faggioli wrote:
On Tue, 2015-02-24 at 13:10 +, Ian Campbell wrote:
On Tue, 2015-02-24 at 12:41 +, Anthony PERARD wrote:
What libxl API those provide this information, if it exist?
I found libxl_get_online_cpus() but that not
In fact: vnode_to_pnode is an array, not a mask; there was a
typo in the one about vmemrange; there was no indication
of the data directions.
Signed-off-by: Dario Faggioli dario.faggi...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Andrew Cooper
On Wed, 2015-02-25 at 10:35 -0500, D'Mita Levy wrote:
Hello,
I have made a naive attempt at compiling a modified version of
Xentrace using RELEASE-4.5.0. After executing #make tools
successfully, I retrieved the binary found in
the /xen/dist/install/usr/local/bin/xentrace and attempted to
On Wed, 2015-02-25 at 15:34 +, Julien Grall wrote:
Hi Frediano,
On 25/02/15 15:28, Frediano Ziglio wrote:
HiSilison Hip04 platform use a slightly different version
I honestly don't like the idea to copy the whole GIC-v2 drivers. It will
require more maintenance for us.
Will it? This
On 02/25/2015 03:24 PM, David Vrabel wrote:
On 24/02/15 06:27, Juergen Gross wrote:
On 02/19/2015 07:07 PM, David Vrabel wrote:
On 18/02/2015 06:51, Juergen Gross wrote:
+{
+unsigned long pfn;
+unsigned long area_start, area_end;
+unsigned i;
+
+for (i = 0; i
BTW, you should send this patch to net...@vger.kernel.org.
Have a look at Documentation/networking/netdev-FAQ.txt for more
information. Feel free to ask me any question if you have doubt.
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
On Mon, 2 Feb 2015, Ian Campbell wrote:
On Thu, 2015-01-29 at 15:08 +, Stefano Stabellini wrote:
@@ -4775,6 +4781,14 @@ retry_transaction:
new_target_memkb = current_target_memkb + target_memkb;
} else
new_target_memkb = target_memkb - videoram;
+
+
Hi Frediano,
On 25/02/15 15:28, Frediano Ziglio wrote:
HiSilison Hip04 platform use a slightly different version
I honestly don't like the idea to copy the whole GIC-v2 drivers. It
will require more maintenance for us.
Is there any way to introduce callbacks in the GICv2 code where
We need a sentinel slot in the generated libxl_key_value_list.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
This should be backported to 4.5.
---
tools/libxl/libxl_json.c | 2 +-
1 file changed, 1 insertion(+),
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/libxl.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c219f59..b394ee8 100644
---
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/gentypes.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/libxl/gentypes.py b/tools/libxl/gentypes.py
index afd4eea..00816c0 100644
---
The first two patches are bug fixes.
Other patches are used to make _dispose idempotent and NULL-tolerant.
Wei.
Wei Liu (7):
libxl: fix off-by-one error in JSON parser
gentest: make testidl valgrind clean
libxl: make some _dipose functions idempotent and tolerate NULL
gentypes: zero out
LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
domain by a constant amount. As it is not clear the reason why we should
be doing this, remove the constant.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
CC: mlati...@suse.com
CC: ian.campb...@citrix.com
---
freemem_slack accounts for the amount of memory to be left free in the
system because empirical experiments seem to demonstrate that is needed
for stability reasons.
As we don't have any actual data on these stability issues, remove it.
Signed-off-by: Stefano Stabellini
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Dienstag, 24. Februar 2015 18:13
An: Mayer, Kevin; xen-devel@lists.xen.org
Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
initialization
On 02/24/2015 10:27 AM,
On Wed, Feb 25, 2015 at 03:13:36PM +, Ian Campbell wrote:
On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
FWIW, this code in openstack was only added for benefit of s390
architecture where apparently it is common to have hosts with
CPUs offlined. Presumably you have to pay
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due
HiSilison Hip04 platform use a slightly different version
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/Makefile| 2 +-
xen/arch/arm/gic-hip04.c | 788 +++
2 files changed, 789 insertions(+), 1 deletion(-)
create
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This will later more easily let us unfold PARAVIRT and PARAVIRT_CLOCK
from under CONFIG_XEN. All the XEN_PV* stuff is under the x86 universe.
This is as per the agreed upon Xen Kconfig changes [0].
[0]
Remove a redundant statement from parse_dom0_mem() and refuse bogus
ranges (with a separator other than a dash) passed to
parse_dom0_max_vcpus(). Fix coding style issues in the latter function
at the same time.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain_build.c
+++
Free the JSON string after use to avoid memory leak. With this change
testidl is valgrind clean.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/gentest.py | 10 +++---
1 file changed, 7
Call _init and _dispose between 1 to 10 times on a type to test if _init
and _dispose are idempotent.
Signed-off-by: Wei Liu wei.l...@citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
---
tools/libxl/gentest.py | 12 +---
1 file changed, 9
... when calculating how many pages to allocate fopr Dom0. This is
basically equivalent to the already present IOMMU related adjustment.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -132,6 +132,8 @@ struct vcpu *__init
On Wed, 11 Feb 2015, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
This lets us expose XEN_PVH and set what is required for it.
This only exists on the x86 universe. This is as per the agreed
upon Xen Kconfig changes [0].
[0]
On 2015-02-10 23:32, Paul Bolle wrote:
On Tue, 2015-02-10 at 14:21 -0800, David Rientjes wrote:
We need an update to the MAINTAINERS file if Yann E. MORIN
yann.morin.1...@free.fr isn't the active Kconfig maintainer anymore.
Yes, we do. Michal, what update would you suggest?
I'll revert the
In libxl_set_memory_target when setting the new maxmem, retain the same
offset on top of the current target. In the future the offset will
include memory allocated by QEMU for rom files.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
Changes in v4:
- remove
This set of patches add Xen support for hip04-d01 platform (see
https://wiki.linaro.org/Boards/D01 for details).
Changes from v5:
- do not change gic-v2.c code but use a copy.
To be considered RFC, to see if better to use copy or other techniques.
Changes from v4:
- rebased to new version;
-
Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
---
xen/arch/arm/gic-hip04.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/xen/arch/arm/gic-hip04.c
On Wed, 2015-02-25 at 15:20 +, Daniel P. Berrange wrote:
On Wed, Feb 25, 2015 at 03:13:36PM +, Ian Campbell wrote:
On Wed, 2015-02-25 at 15:03 +, Daniel P. Berrange wrote:
FWIW, this code in openstack was only added for benefit of s390
architecture where apparently it is
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.
Use nr_lines to check for maximum
On 25/02/15 14:45, Jan Beulich wrote:
... when calculating how many pages to allocate fopr Dom0. This is
fopr = for ?
basically equivalent to the already present IOMMU related adjustment.
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/domain_build.c
+++
On Wed, Feb 25, 2015 at 04:40:40PM +, Ian Campbell wrote:
On Wed, 2015-02-25 at 16:34 +, Will Deacon wrote:
On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
I couldn't care less
On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
-Ursprüngliche Nachricht-
Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
Gesendet: Dienstag, 24. Februar 2015 18:13
An: Mayer, Kevin; xen-devel@lists.xen.org
Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
On 25/02/15 14:47, Jan Beulich wrote:
Remove a redundant statement from parse_dom0_mem() and refuse bogus
ranges (with a separator other than a dash) passed to
parse_dom0_max_vcpus(). Fix coding style issues in the latter function
at the same time.
Signed-off-by: Jan Beulich
On 25/02/15 16:34, Will Deacon wrote:
On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
I couldn't care less :)
The arm64 part is boring in the good sense of the word.
I will still need a ack
On Fri, 2015-02-20 at 09:56 +, Frediano Ziglio wrote:
This set of patches add Xen support for hip04-d01 platform (see
https://wiki.linaro.org/Boards/D01 for details).
When (or where) would the general public be able to purchase one of
these systems?
Ian.
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
Regards,
On 18/02/15 13:51, Julien Grall wrote:
Hello,
This small patch series moves the detection of running on Xen earlier. This is
required in order to support earlyprintk via Xen and selecting preferred
On Wed, 25 Feb 2015, Frediano Ziglio wrote:
HiSilison Hip04 platform use a slightly different version
Signed-off-by: Frediano Ziglio frediano.zig...@huawei.com
I think that this is preferable to the previous approach of modifying
the existing gic-v2 driver, after all the hip04 interrupt
On Wed, 2015-02-25 at 16:34 +, Will Deacon wrote:
On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
I couldn't care less :)
The arm64 part is boring in the good sense of the word.
May
On Wed, Feb 25, 2015 at 04:22:33PM +, Julien Grall wrote:
Hello,
Ping? Any comments from ARM's maintainers on theses patches (at least #2)?
I couldn't care less :)
The arm64 part is boring in the good sense of the word.
Will
___
Xen-devel
1 - 100 of 167 matches
Mail list logo
