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
test-amd64-amd64-rump
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 XEN_BU
While running libvirt-tck domain/102-broken-save-restore.t
test (save domain, corrupt saved file by truncate the last 512k,
then restore), found that restore domain failed, but domain
related xenstore entries still exist in xenstore.
Add a patch to clear xenstore entries in this case.
Signed-off-
Currently libxl__domain_rename only update /local/domain//name,
still some places in xenstore are not updated, including:
/vm//name and /local/domain/0/backend///.../domain.
This patch series updates /vm//name in xenstore, and removes the unusual
'domain' field under backend directory.
---
Change
libxl__domain_rename only updates /local/domain//name,
/vm//name in xenstore are not updated. Add code in
libxl__domain_rename to update /vm//name too.
Signed-off-by: Chunyan Liu
---
tools/libxl/libxl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/libxl/libxl.c b/tool
Remove the unusual 'domain' field under backend directory. The
affected are backend/console, backend/vfb, backend/vkbd.
Signed-off-by: Chunyan Liu
---
tools/libxl/libxl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index f7961f6..dbefaf3 1006
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,
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
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 wer
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, November 14, 2014 7:28 PM
> To: Hu, Robert
> Cc: Fabio Fantoni; Wei Liu; jbeul...@suse.com; xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] [TestDay] VMX test report for Xen 4.5.0-rc1
>
> On Fri,
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 inca
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 *fun
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 guest-start
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 1eb3666b469e307b20262e856229
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 9
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
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
---
tools/libxl/libxl_create.c | 2 ++
1 file changed, 2 insertions(+
>
> 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
On Tue, Nov 18, 2014 at 05:20:44PM +, Jan Beulich wrote:
> >>> On 18.11.14 at 18:03, 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 8303faaf25a8
>
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 rem
On Mon, Nov 17, 2014 at 5:34 AM, Ian Campbell
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). I've seen some
>>> On 11/18/2014 at 11:24 AM, Ian Jackson wrote:
> 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 a
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
test-amd64-i386-p
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
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
On Tue, Nov 18, 2014 at 05:44:20PM +, Ian Jackson wrote:
> Euan Harris writes ("[PATCH] libxl: Document device parameter of
> libxl_device__add functions"):
> > The device parameter of libxl_device__add is an in/out parameter.
> > Unspecified fields are filled in with appropriate values for th
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 sen
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 stil
Euan Harris writes ("[PATCH] libxl: Document device parameter of
libxl_device__add functions"):
> The device parameter of libxl_device__add is an in/out parameter.
> Unspecified fields are filled in with appropriate values for the created
> device when the function returns. Document this behaviou
>>> On 18.11.14 at 18:03, 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 8303faaf25a8
>> might be correct - as the second dpci the softirq is processin
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
> > I believe so, yes. The comment under "Devices" in libxl.h probably ought
> > to be adjusted to say so explicitly.
> >
> > Ian (J) -- do you agree?
>
> I do. I think this applies to other kinds of device too, which might
> have unspecified parameters which get filled in.
>
> Euan, would you
The device parameter of libxl_device__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
---
tools/libxl/libxl.h | 4
1 file changed, 4 insertions(+)
dif
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 C
Tuesday, November 18, 2014, 5:16:50 PM, you wrote:
>> 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
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
> 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 the
Hi Ian,
On 11/18/2014 04:44 PM, Ian Campbell wrote:
> Signed-off-by: Ian Campbell
> ---
> 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/x
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
ping?
On Fri, 14 Nov 2014, Stefano Stabellini wrote:
> Russell,
> this patch needs your feedback.
>
> - Stefano
>
> On Wed, 12 Nov 2014, Stefano Stabellini wrote:
> > Introduce a boolean flag and an accessor function to check whether a
> > device is dma_coherent. Set the flag from set_arch_dma_c
>>> On 18.11.14 at 17:24, 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 backend ma
On Tue, 18 Nov 2014 16:35:42 +
Jan Beulich wrote:
> >>> On 18.11.14 at 16:26, 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
>
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
not set. Validating first E-fuse MAC
cpsw
- UART enabled -
- CPU booting -
- Xen starting in Hyp mode -
- Zero BSS -
- Setting up control registe
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
-
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
---
xen/arch/arm/platforms/xgene-storm.c | 18 ++---
Signed-off-by: Ian Campbell
---
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 @@ EARLY_PRINTK_BAUD := 115200
EA
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 ju
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 chip,
>>> On 18.11.14 at 17:19, wrote:
> On 11/18/2014 04:15 PM, Jan Beulich wrote:
> On 18.11.14 at 16:00, wrote:
>>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>>> On 30.10.14 at 19:51, wrote:
The naming suggests that the #if really should be around just the
gic_version field (with
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 fo
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 don
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
>
>>> On 18.11.14 at 16:26, 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). Since the vcpu's xsav
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 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
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
XEN_
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
OK got it. Give me a few mins
On Tue, Nov 18, 2014 at 6:14 PM, Stefano Stabellini
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 GICH_LR_HW for hardware irqs.
>
> Al
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 d
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 PM, Ian Jackson wrote:
> >>> Em
On 11/18/2014 04:15 PM, Jan Beulich wrote:
On 18.11.14 at 16:00, wrote:
>> On 10/31/2014 09:02 AM, Jan Beulich wrote:
>> On 30.10.14 at 19:51, 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 C8
> 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 sur
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 GICH_LR_HW for hardware irqs.
Also testing on 394b7e587b05d0f4a5fd6f067b38339ab5a77121 would avoid
other potential bugs introduced l
>>> On 18.11.14 at 16:00, wrote:
> On 10/31/2014 09:02 AM, Jan Beulich wrote:
> On 30.10.14 at 19:51, 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, e.g. a zero width unnamed bitfi
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
#include
+#define GIC_DEBUG 1
+
/*
* LR register def
Tuesday, November 18, 2014, 4:09:25 PM, you wrote:
> Tuesday, November 18, 2014, 12:07:41 PM, you wrote:
>> Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
>>> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
Monday, November 17, 2014, 9:43:47 PM, you wrote:
On Tue, 2014-11-18 at 15:41 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to
> libxl_network_device_add an (in)_out parameter?"):
> > On Tue, 2014-11-18 at 15:28 +, Euan Harris wrote:
> > > If I call libxl_device_nic_add and pass in a mostly-default
(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 PM, Ian Jackson wrote:
>>> Empty structs are a gcc extension (`(gcc-4.4) Empty Structures'). I
>>
Ian Campbell writes ("Re: [Xen-devel] libxl: Is the nic param to
libxl_network_device_add an (in)_out parameter?"):
> On Tue, 2014-11-18 at 15:28 +, Euan Harris wrote:
> > If I call libxl_device_nic_add and pass in a mostly-default
> > libxl_device_nic structure, the function fills in the unsp
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 3628a0aa35706a8f532af865ed78
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 com
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;
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);
/*
nic.de
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 a
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 ver
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 forcib
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 ou
Hi Jan,
On 10/31/2014 09:02 AM, Jan Beulich wrote:
On 30.10.14 at 19:51, 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, e.g. a zero width unnamed bitfield) and the
> corresponding #d
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//name,
> > still some places in xenstore are not updated, including:
> > /vm//name and /local/domain/0/backe
Chunyan Liu writes ("[PATCH v2] fix rename: xenstore not fully updated"):
> Currently libxl__domain_rename only update /local/domain//name,
> still some places in xenstore are not updated, including:
> /vm//name and /local/domain/0/backend///.../domain.
Thanks. The principle is correct now and so
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
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
test-amd64-i386-xl-qemuu-
I see that when the vTPM domain is destroyed using xl destroy the
advertised info is not removed from xenstore. I don't see a reason for
which it should remain there.
If something crashes the vTPM it must be destroyed, started again and
attached to domU using xl vtpm-attach. The problem is that be
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 w
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-
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
> ---
>
> I think this is a bugfix that
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
Date: Tue Nov 18 1
On Tue, Nov 18, 2014 at 8:32 AM, Jan Beulich wrote:
> >>> On 17.11.14 at 18:06, wrote:
> > On Mon, Nov 17, 2014 at 5:37 PM, Jan Beulich wrote:
> >
> >> >>> On 12.11.14 at 16:48, wrote:
> >> > On 12/11/14 15:31, Tamas K Lengyel wrote:
> >> >> xen/include/public/domctl.h | 44 +--
> >>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-8595 / XSA-110
version 3
Missing privilege level checks in x86 emulation of far branches
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2014-8594 / XSA-109
version 3
Insufficient restrictions on certain MMU update hypercalls
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
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 not
Andrew Cooper wrote on 2014-11-18:
> On 18/11/14 10:14, Tim Deegan wrote:
>> 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:
Strange - looks like baseline code already does the same, that you
sent me yesterday. The only what is needed - is to set
PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI.
But baseline contains an issue. And in the same time changes on top of
5495a512b63bad868c147198f7f049c2617d468c work fine.
Regards,
Andrii
Tuesday, November 18, 2014, 3:49:27 AM, you wrote:
> On Mon, Nov 17, 2014 at 11:40:11PM +0100, Sander Eikelenboom wrote:
>>
>> Monday, November 17, 2014, 9:43:47 PM, you wrote:
>>
>> > . snip..
>> >> > # cat /proc/interrupts |grep eth
>> >> > 36: 384183 0 xen-pirq-ioapic-level e
On 18/11/14 10:51, Andrew Cooper wrote:
>>
> It is not just ballooning. It is any change to the p2m whatsoever.
> This includes mapping/unmapping grants, XENMEM_exchange, and the guest
> simply changing the p2m layout.
Grants don't matter because they're never saved.
David
On 18/11/14 05:33, Juergen Gross wrote:
> On 11/14/2014 05:08 PM, Andrew Cooper wrote:
>> On 14/11/14 15:32, Juergen Gross wrote:
>>> On 11/14/2014 03:59 PM, Andrew Cooper wrote:
On 14/11/14 14:14, Jürgen Groß wrote:
> On 11/14/2014 02:56 PM, Andrew Cooper wrote:
>> On 14/11/14 12:53,
On 18/11/14 10:14, Tim Deegan wrote:
> 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 Beuli
Hi Stefano,
On Mon, Nov 17, 2014 at 8:02 PM, Stefano Stabellini
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
>> wrote:
>> > Although it is possible that that patch is the cause of
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
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
> /local/domain/0/backe
>>> On 18.11.14 at 09:16, wrote:
> On 2014/11/18 16:01, Jan Beulich wrote:
> On 18.11.14 at 04:08, 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
1 - 100 of 107 matches
Mail list logo
