On 2014/11/18 16:01, Jan Beulich wrote:
On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:
Here I tried to implement what you want. Note just pick two key
fragments since others have no big deal.
#1:
@@ -898,14 +898,25 @@ int
intel_iommu_get_reserved_device_memory(iommu_grdm_t *func, void
On 17.11.14 at 23:40, li...@eikelenboom.it wrote:
OK, i still don't get why the output of debug-key 'i' reports +47 as pirq
here instead of the guest value
(g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a
MSI with the PIRQ ?
No - as you said yourself, it's a
flight 31610 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31610/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
On Mon, Nov 17, 2014 at 09:41:17AM +, Wei Liu wrote:
On Mon, Nov 17, 2014 at 05:28:58PM +0800, Chao Peng wrote:
Avoid sending duplicated qmp commands and eliminate the confusing error
messages like Unable to add CPU: 0, it already exists.
Signed-off-by: Chao Peng
On Mon, 2014-11-17 at 15:03 -0500, Zhigang Wang wrote:
On 11/12/2014 07:03 AM, Ian Campbell wrote:
On Mon, 2014-11-10 at 10:38 -0500, Zhigang Wang wrote:
OK. Let me try my best:
I'm confused by the description of what's going on, in particular the
mixing of mem-max commands and target
On 17.11.14 at 19:01, li...@eikelenboom.it wrote:
(XEN) [2014-11-17 17:54:18.695] CPU00:
(XEN) [2014-11-17 17:54:18.705] CPU01:
(XEN) [2014-11-17 17:54:18.716] d16 OK-softirq 62msec ago, state:1, 2628
count,
[prev:83054ef57e70, next:83054ef57e70] 83051b904428NULL
MAPPED_SHIFT
On 18.11.14 at 09:16, tiejun.c...@intel.com wrote:
On 2014/11/18 16:01, Jan Beulich wrote:
On 18.11.14 at 04:08, tiejun.c...@intel.com wrote:
Here I tried to implement what you want. Note just pick two key
fragments since others have no big deal.
#1:
@@ -898,14 +898,25 @@ int
On Mon, 2014-11-17 at 12:10 +, Wei Liu wrote:
The existence check is to make sure a device is not added to a guest
multiple times.
PCI device backend path has different rules from vif, disk etc. For
example:
/local/domain/0/backend/pci/9/0/dev-1/:03:10.1
At 17:25 + on 17 Nov (1416241517), Andrew Cooper wrote:
On 17/11/14 17:00, Tim Deegan wrote:
At 16:40 + on 17 Nov (1416238835), Andrew Cooper wrote:
On 17/11/14 16:30, Tim Deegan wrote:
At 16:24 + on 17 Nov (1416237888), Jan Beulich wrote:
On 17.11.14 at 16:39,
Hi Stefano,
On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
On Mon, 17 Nov 2014, Andrii Tseglytskyi wrote:
Hi Stefano,
Thank you for your answer.
On Mon, Nov 17, 2014 at 6:39 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
flight 31651 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 30603
Tests which did
On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich jbeul...@suse.com wrote:
On 17.11.14 at 18:06, tamas.leng...@zentific.com wrote:
On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich jbeul...@suse.com wrote:
On 12.11.14 at 16:48, andrew.coop...@citrix.com wrote:
On 12/11/14 15:31, Tamas K Lengyel
OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.
Stefano, could you please take a look to these changes?
commit 3628a0aa35706a8f532af865ed784536ce514eca
Author: Andrii Tseglytskyi
Konrad,
I think we should have this fix in Xen 4.5. Should I go ahead and
backport it?
On Mon, 17 Nov 2014, Don Slutz wrote:
The other callers to blk_set_enable_write_cache() in this file
already check for s-blk == NULL.
Signed-off-by: Don Slutz dsl...@verizon.com
---
I think this is a
xen.org writes ([qemu-mainline test] 31651: regressions - FAIL):
flight 31651 qemu-mainline real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-pair 17
On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
Hmm - this is a pitfall waiting to happen.
In the case that there is a heterogeneous setup with one 1G capable
and one 1G incapable server, Xen cannot forcibly prevent the use of 1G
pages on the capable hardware. Any VM which
flight 31652 qemu-upstream-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31652/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ovmf-amd64 7 debian-hvm-install fail never pass
Konrad Rzeszutek Wilk writes (Re: [PATCH for-4.5 v2 0/4] libxl: CODING_STYLE):
On Fri, Nov 14, 2014 at 06:52:37PM +, Ian Jackson wrote:
The structural considerations, error handling patterns, and so on, in
libxl have remained undocumented. This has been a problem during
recent code
Chunyan Liu writes ([PATCH v2] fix rename: xenstore not fully updated):
Currently libxl__domain_rename only update /local/domain/domid/name,
still some places in xenstore are not updated, including:
/vm/uuid/name and /local/domain/0/backend/device/domid/.../domain.
Thanks. The principle is
On Tue, 2014-11-18 at 14:49 +, Ian Jackson wrote:
Chunyan Liu writes ([PATCH v2] fix rename: xenstore not fully updated):
Currently libxl__domain_rename only update /local/domain/domid/name,
still some places in xenstore are not updated, including:
/vm/uuid/name and
Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3
for domU):
I need to create an empty structure. Is the dummy field really needed?
Empty structs are a gcc extension (`(gcc-4.4) Empty Structures'). I
would be very surprised if clang didn't support them too.
AIUI our
At 14:26 + on 18 Nov (1416317209), Ian Campbell wrote:
On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
Hmm - this is a pitfall waiting to happen.
In the case that there is a heterogeneous setup with one 1G capable
and one 1G incapable server, Xen cannot forcibly prevent
On 11/18/2014 03:10 PM, Ian Jackson wrote:
Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3
for domU):
I need to create an empty structure. Is the dummy field really needed?
Empty structs are a gcc extension (`(gcc-4.4) Empty Structures'). I
would be very
If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch). Since the vcpu's xsave
area is never zeroed after the initial
Hi,
If I call libxl_device_nic_add and pass in a mostly-default
libxl_device_nic structure, the function fills in the unspecified default
config fields with data for the NIC which it has just created:
libxl_device_nic nic;
libxl_device_nic_init(nic);
/*
Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for GICv3
for domU):
On 11/18/2014 03:10 PM, Ian Jackson wrote:
Empty structs are a gcc extension (`(gcc-4.4) Empty Structures'). I
would be very surprised if clang didn't support them too.
AFAIK, clang doesn't complain
On Tue, 2014-11-18 at 15:28 +, Euan Harris wrote:
Hi,
If I call libxl_device_nic_add and pass in a mostly-default
libxl_device_nic structure, the function fills in the unspecified default
config fields with data for the NIC which it has just created:
libxl_device_nic nic;
On Tue, 18 Nov 2014, Andrii Tseglytskyi wrote:
OK, I see that GICH_V2_LR_MAINTENANCE_IRQ must always be set and
everything works fine
The following 2 patches fixes xen/master for my platform.
Stefano, could you please take a look to these changes?
commit
What if I try on top of current master branch the following code:
diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
index 31fb81a..6764ab7 100644
--- a/xen/arch/arm/gic-v2.c
+++ b/xen/arch/arm/gic-v2.c
@@ -36,6 +36,8 @@
#include asm/io.h
#include asm/gic.h
+#define GIC_DEBUG 1
+
/*
On 18.11.14 at 16:00, julien.gr...@linaro.org wrote:
On 10/31/2014 09:02 AM, Jan Beulich wrote:
On 30.10.14 at 19:51, julien.gr...@linaro.org wrote:
The naming suggests that the #if really should be around just the
gic_version field (with a dummy field in the #else case to be C89
compatible,
Without #define DIFF_LIST 1:
1) The guest still crashes (xl-dmesg-not-defined.txt)
AHA!
--MARK--
0: 8305085ffd28 [p:83054ef27e88, n:83054ef27e88]
1: 8305085ffd28 [p:0200200200200200, n:0100100100100100]
The same pirq_dpci structure is put twice on the list. That
will
On 11/18/2014 04:15 PM, Jan Beulich wrote:
On 18.11.14 at 16:00, julien.gr...@linaro.org wrote:
On 10/31/2014 09:02 AM, Jan Beulich wrote:
On 30.10.14 at 19:51, julien.gr...@linaro.org wrote:
The naming suggests that the #if really should be around just the
gic_version field (with a dummy
Hello Jan,
Friday, November 14, 2014, 5:27:36 AM, you wrote:
I implied your earlier statement to mean that. But - did you also
verify that the three flags actually end up set (ideally from both
DomU and Dom0 perspective)? The PCI backend may be screwing
up things...
Yes I do verify the
Hello Konrad,
Thursday, November 13, 2014, 4:29:15 PM, you wrote:
On Thu, Nov 13, 2014 at 04:21:48PM -0300, Simon Martin wrote:
Thanks Konrad,
Thursday, November 13, 2014, 4:03:38 PM, you wrote:
Yes I do verify the write. How do I check this from Dom0?
You can crank up the debug
OK got it. Give me a few mins
On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
stefano.stabell...@eu.citrix.com wrote:
It is not the same: I would like to set GICH_V2_LR_MAINTENANCE_IRQ only
for non-hardware irqs (desc == NULL) and keep avoiding
GICH_V2_LR_MAINTENANCE_IRQ and setting
It is expected that repeated builds of identical sources results in
identical binaries on different hosts at different build times. This
fails for xen.gz and xen.efi because unstable strings are included in
the binaries.
In addition to existing variables use XEN_BUILD_DATE, XEN_BUILD_TIME and
On 11/18/2014 04:21 PM, Ian Campbell wrote:
On Tue, 2014-11-18 at 15:49 +, Julien Grall wrote:
(Rename the mail and strip the cc list)
On 11/18/2014 03:35 PM, Ian Jackson wrote:
Julien Grall writes (Re: [PATCH for Xen 4.5] xen/arm: Add support for
GICv3 for domU):
On 11/18/2014 03:10
On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that used
that area (e.g. during a context switch).
On 18/11/14 16:32, Konrad Rzeszutek Wilk wrote:
On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch wrote:
If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has ever been done that
Olaf Hering writes ([PATCH] xen: use more fixed strings to build the
hypervisor):
It is expected that repeated builds of identical sources results in
identical binaries on different hosts at different build times. This
fails for xen.gz and xen.efi because unstable strings are included in
the
On Tue, 2014-11-18 at 16:29 +, Julien Grall wrote:
On 11/18/2014 04:21 PM, Ian Campbell wrote:
On Tue, 2014-11-18 at 15:49 +, Julien Grall wrote:
(Rename the mail and strip the cc list)
On 11/18/2014 03:35 PM, Ian Jackson wrote:
Julien Grall writes (Re: [PATCH for Xen 4.5]
These patches:
* fix up an off by one bug in the xgene mapping of additional PCI
bus resources, which would cause an additional extra page to be
mapped
* correct the size of the mapped regions to match the docs
* adds support for the other 4 PCI buses on the
The callers pass the end as the pfn immediately *after* the last page to be
mapped, therefore adding one is incorrect and causes an additional page to be
mapped.
At the same time correct the printing of the mfn values, zero-padding them to
16 digits as for a paddr when they are frame numbers is
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/Rules.mk |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..ef887a5 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -95,6 +95,12 @@
The region assigned to PCIE0, according to the docs, is 0x0e0 to
0x100. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.
This results in no change for Mustang.
Signed-off-by: Ian Campbell
Hi Stefano,
No hangs with this change.
Complete log is the following:
U-Boot SPL 2013.10-00499-g062782f (Oct 14 2014 - 11:36:26)
DRA752 ES1.0
ethaddr not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control
On Tue, 18 Nov 2014 16:35:42 +
Jan Beulich jbeul...@suse.com wrote:
On 18.11.14 at 16:26, dk...@verizon.com wrote:
If we restore an xsave area from an older xen that has a larger
size than the xcr0 bit call for, it is possible to have non-zero
data in the unused area if an xsave has
On 18.11.14 at 17:24, furryfutt...@gmail.com wrote:
Hello Jan,
Friday, November 14, 2014, 5:27:36 AM, you wrote:
I implied your earlier statement to mean that. But - did you also
verify that the three flags actually end up set (ideally from both
DomU and Dom0 perspective)? The PCI
On Tue, 2014-11-18 at 16:44 +, Ian Campbell wrote:
These patches:
... which are also at
git://xenbits.xen.org/people/ianc/xen.git mcdivitt-v1
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/Rules.mk |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index 572d854..ef887a5 100644
---
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
The region assigned to PCIE0, according to the docs, is 0x0e0 to
0x100. They make no distinction between PCI CFG and PCI IO mem within
this range (in fact, I'm not sure that isn't up to the driver).
Signed-off-by: Ian
The device parameter of libxl_device_type_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for the created
device when the function returns. Document this behaviour.
Signed-off-by: Euan Harris euan.har...@citrix.com
---
tools/libxl/libxl.h | 4
1 file
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
Currently we only establish specific mappings for pcie0, which is
used on the Mustang platform. However at least McDivitt uses pcie3.
So wire up all the others, based on whether the corresponding DT node
is marked as available.
This
Euan Harris writes ([PATCH] libxl: Document device parameter of
libxl_device_type_add functions):
The device parameter of libxl_device_type_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for the created
device when the function returns. Document this
Hello Andrii,
we are getting closer :-)
It would help if you post the output with GIC_DEBUG defined but without
the other change that fixes the issue.
I think the problem is probably due to software irqs.
You are getting too many
gic.c:617:d0v1 trying to inject irq=2 into d0v0, when it is still
On Thu, Nov 13, 2014 at 09:05:47AM +, Jan Beulich wrote:
All,
while the 3 month period since the previous stable releases would
expire at the beginning of December, looking at the number of
changes in the stable trees I don't think starting preparations right
now would make much sense.
On Tue, Nov 18, 2014 at 05:44:20PM +, Ian Jackson wrote:
Euan Harris writes ([PATCH] libxl: Document device parameter of
libxl_device_type_add functions):
The device parameter of libxl_device_type_add is an in/out parameter.
Unspecified fields are filled in with appropriate values for
Daniel Kiper writes (Re: [Xen-devel] delaying 4.4.2 and 4.3.4):
By the way, what I should do to have commit
f3f5f1927f0d3aef9e3d2ce554dbfa0de73487d5
(tools/hotplug: set mtu from bridge for tap interface) in at least Xen 4.3?
I am asking about that more than five months. This patch fixes real
flight 31630 xen-4.2-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31630/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvops 5 kernel-build fail REGR. vs. 30594
On ARM the virtual GIC may differ between each guest (emulated GIC version,
number of SPIs...). Those informations are already known at the domain creation
and can never change.
For now only the gic_version is set. In long run, there will be more parameters
such as the number of SPIs. All will be
On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell ian.campb...@citrix.com
wrote:
On Sun, 2014-11-16 at 23:39 -0500, Tim Wood wrote:
Hi,
I am curious if Xen currently supports sharing hugepages between
domains (specifically ones originally allocated in Dom-0 and shared
with a guest r/w).
By default, the script get_maintainer.pl will remove duplicates email as soon
as it appends the list of maintainers of a new file, and therefore override
the role of the developper.
On complex patch (see [1]), this will result to ommitting randomly some
maintainers.
This could be fixed by not
On Tue, Nov 18, 2014 at 05:20:44PM +, Jan Beulich wrote:
On 18.11.14 at 18:03, li...@eikelenboom.it wrote:
Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
1) test_and_[set|clear]_bit sometimes return unexpected values.
[But this might be invalid as the addition of the
Uhmm i thought i had these switched off (due to problems earlier and then
forgot
about them .. however looking at the earlier reports these lines were also in
those reports).
The xen-syms and these last runs are all with a prestine xen tree cloned
today (staging
branch), so the
Before this patch, pv guest video_memkb is -1, which is an invalid value.
And it will cause the xenstore 'memory/targe' calculation wrong:
memory/target = info-target_memkb - info-video_memkb
Signed-off-by: Zhigang Wang zhigang.x.w...@oracle.com
---
tools/libxl/libxl_create.c | 2 ++
1 file
flight 31657 linux-3.10 real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31657/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-winxpsp3 7 windows-install fail REGR. vs. 26303
Regressions which are
flight 31643 linux-next real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31643/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-rumpuserxen-amd64 8 guest-start fail baseline untested
test-amd64-amd64-xl-sedf
flight 31661 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31661/
Perfect :-)
All tests in this flight passed
version targeted for testing:
rumpuserxen 9716ed62cb1d73254b552e2077497d684c81639d
baseline version:
rumpuserxen
flight 31660 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31660/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9
So without lookuping devices[i], how can we call func() for each sbdf as
you mentioned?
You've got both rmrr and bdf in the body of for_each_rmrr_device().
After all - as I said - you just open-coded it.
Yeah, so change this again,
int intel_iommu_get_reserved_device_memory(iommu_grdm_t
Tim Deegan wrote on 2014-11-18:
At 14:26 + on 18 Nov (1416317209), Ian Campbell wrote:
On Tue, 2014-11-18 at 11:41 +, Zhang, Yang Z wrote:
Hmm - this is a pitfall waiting to happen.
In the case that there is a heterogeneous setup with one 1G
capable and one 1G incapable server, Xen
On Tue, Nov 18, 2014 at 11:12:54PM +0100, Sander Eikelenboom wrote:
Tuesday, November 18, 2014, 9:56:33 PM, you wrote:
Uhmm i thought i had these switched off (due to problems earlier and then
forgot
about them .. however looking at the earlier reports these lines were also
in
flight 31663 qemu-upstream-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31663/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rhel6hvm-intel 5 xen-boot fail blocked in 25336
Tests which did
flight 31659 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31659/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-pair17 guest-migrate/src_host/dst_host fail like 31489
Tests which did not succeed,
libxl__domain_rename only updates /local/domain/domid/name,
/vm/uuid/name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm/uuid/name too.
Signed-off-by: Chunyan Liu cy...@suse.com
---
tools/libxl/libxl.c | 13 +
1 file changed, 13 insertions(+)
diff --git
On Tue, Nov 18, Ian Jackson wrote:
How about
It should be possible to repeatedly build identical sources
and get identical binaries, even on different hosts at different
build times. This fails [etc. etc. ...]
Provide variables XEN_BUILD_DATE, XEN_BUILD_TIME and
flight 31665 linux-linus real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/31665/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 8 guest-start fail REGR. vs. 31241
78 matches
Mail list logo
