flight 92347 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92347/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm 15 guest-start/debian.repeat fail REGR. vs. 83040
Regression
flight 92401 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92401/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
This run is configured for baseline tests only.
flight 44356 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44356/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 capture
flight 92323 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92323/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 15 guest-localmigratefail REGR. vs. 60684
build-i386
flight 92389 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 92350
Tests which di
> As per my earlier reply to Konrad, there must be more to this. I.e.
> "normal" local symbols won't get dropped together with relocations
> referencing them getting resolved.
Correct. These .LCx symbols only cover .rodata.* sections. Any other
local symbols:
[konrad@x230 x86]$ readelf --symbols
flight 92375 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92375/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs. 92350
Tests which di
> On 22 Apr 2016, at 16:26, Ian Jackson wrote:
>
> This will result in the Xen build system building, and then
> preferring, oxenstored.
>
> Signed-off-by: Ian Jackson
> CC: David Scott
> CC: Wei Liu
This looks good to me too.
Reviewed-by: David Scott
> ---
> ts-xen-build-prep |1 +
This run is configured for baseline tests only.
flight 44355 xen-4.4-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44355/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop
flight 92310 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92310/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 92071
test-amd64-amd64-xl-qemuu-wi
flight 92320 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 14 guest-saverestore fail REGR. vs. 91479
test-amd64-amd64-libvirt-
>
>
> >> diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/vm_event.c
> >> index 5635603..22819c5 100644
> >> --- a/xen/arch/x86/vm_event.c
> >> +++ b/xen/arch/x86/vm_event.c
> >> @@ -20,6 +20,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> /* Implicitly seria
On 04/22/16 21:07, Andrew Cooper wrote:
> On 17/04/16 20:15, Razvan Cojocaru wrote:
>> diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
>> index 56c5514..9c17f37 100644
>> --- a/xen/arch/x86/hvm/event.c
>> +++ b/xen/arch/x86/hvm/event.c
>> @@ -57,9 +57,8 @@ bool_t hvm_event_cr(unsig
Hi George,
On 21/04/16 17:03, George Dunlap wrote:
Clarify the meaning of nested maintainership.
Signed-off-by: George Dunlap
---
We had a discussion about the meaning of nested maintainership at the
recent Xen Hackathon. The notes of that meeting can be found on this
list [1]. No decision i
Hi Wei,
On 21/04/16 09:24, Wei Chen wrote:
This patch adds v2m extension support in GIC-v2 driver. The GICv2 driver
detects the MSI frames from device tree and creates corresponding device
tree nodes in Domain0's DTB. It also provides one hw_ops callback to map
v2m MMIO regions to domain0 and ro
On Fri, Apr 22, 2016 at 06:20:36PM +, Shriram Rajagopalan wrote:
> I don't think so.
>
Thanks for confirming!
Wei.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
I don't think so.
On Fri, Apr 22, 2016 at 2:12 PM Wei Liu wrote:
> On Fri, Apr 22, 2016 at 06:07:46PM +, Shriram Rajagopalan wrote:
> > Blktap2 was the first disk backend implementation. I moved Remus to DRBD
> > because it had disk resynchronization support. For eg, when primary
> fails,
>
On Fri, Apr 22, 2016 at 11:03:53AM -0700, H. Peter Anvin wrote:
> Please don't use the cpu_has_* macros anymore, they are going away soon.
>
> In this case it should be static_cpu_has(X86_FEATURE_PSE).
Ingo fixed this up while merging:
b2eafe890d4a ("Merge branch 'x86/urgent' into x86/asm, to fi
On Wed, Apr 20, 2016 at 03:33:13PM +0100, Wei Liu wrote:
> Sorry I was at the Xen hackathon in the last two days.
>
> On Tue, Apr 12, 2016 at 11:35:20AM +0800, Zhenzhong Duan wrote:
> > 在 2016/4/11 19:27, Wei Liu 写道:
> > >On Mon, Apr 11, 2016 at 09:42:57AM +0800, Zhenzhong Duan wrote:
> > >>It's t
On Fri, Apr 22, 2016 at 06:07:46PM +, Shriram Rajagopalan wrote:
> Blktap2 was the first disk backend implementation. I moved Remus to DRBD
> because it had disk resynchronization support. For eg, when primary fails,
> backup takes over. When primary comes back online, DRBD would automatically
Blktap2 was the first disk backend implementation. I moved Remus to DRBD
because it had disk resynchronization support. For eg, when primary fails,
backup takes over. When primary comes back online, DRBD would automatically
resynchronize new changes from the backup disk to the primary disk and will
On Fri, Apr 22, 2016 at 02:01:24PM +0100, Wei Liu wrote:
> On Fri, Apr 22, 2016 at 05:39:41AM -0600, Jan Beulich wrote:
> > >>> On 22.04.16 at 12:33, wrote:
> > > Signed-off-by: Wei Liu
> >
> > FWIW:
> > Acked-by: Jan Beulich
> >
>
> Thank you both.
>
> I will push this later today.
>
Queu
On Tue, Apr 12, 2016 at 03:55:19PM +0200, Olaf Hering wrote:
> At least gcc-4.8 and older fails to recognize that err is always
> initialized, the build fails:
> xc_cpupool.c: In function 'xc_cpupool_removecpu':
> xc_cpupool.c:168:5: error: 'err' may be used uninitialized in this function
> [-
On 17/04/16 20:15, Razvan Cojocaru wrote:
> diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
> index 56c5514..9c17f37 100644
> --- a/xen/arch/x86/hvm/event.c
> +++ b/xen/arch/x86/hvm/event.c
> @@ -57,9 +57,8 @@ bool_t hvm_event_cr(unsigned int index, unsigned long
> value, unsigned
On Wed, Apr 20, 2016 at 02:18:48PM +0100, Ross Lagerwall wrote:
> On 04/13/2016 10:09 PM, Konrad Rzeszutek Wilk wrote:
> snip
> >+static int xsplice_action(xen_sysctl_xsplice_action_t *action)
> >+{
> >+struct payload *data;
> >+char n[XEN_XSPLICE_NAME_SIZE];
> >+int rc;
> >+
> >+rc
On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote:
> Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c
> Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c
> Author: Jan Beulich
> AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600
> Committer: Ingo Molnar
> Commit
On Fri, 22 Apr 2016, Jan Beulich wrote:
> >>> On 22.04.16 at 12:08, wrote:
> > On Fri, 22 Apr 2016, Jan Beulich wrote:
> >> >>> On 21.04.16 at 15:29, wrote:
> >> > --- a/xen/arch/x86/time.c
> >> > +++ b/xen/arch/x86/time.c
> >> > @@ -784,7 +784,7 @@ static void __update_vcpu_system_time(struct vc
On Fri, 22 Apr 2016, Wei Liu wrote:
> On Fri, Apr 22, 2016 at 05:40:02PM +0100, Julien Grall wrote:
> > (CC Wei for the release-ack)
> >
> > Hi Fu Wei,
> >
> > On 21/04/16 12:07, fu@linaro.org wrote:
> > >From: Fu Wei
> > >
> > >This patch updates the documentation for allowing detection of
On Fri, Apr 22, 2016 at 04:26:42PM +0100, Ian Jackson wrote:
> This will result in the Xen build system building, and then
> preferring, oxenstored.
>
> Signed-off-by: Ian Jackson
> CC: David Scott
> CC: Wei Liu
Reviewed-by: Wei Liu
> ---
> ts-xen-build-prep |1 +
> 1 file changed, 1 in
On Fri, Apr 22, 2016 at 06:29:34PM +0100, Ian Jackson wrote:
> Julien Grall writes ("Re: [PATCH v2] docs/arm64: update the documention for
> loading XSM support"):
> > The new version looks good to me:
> > Acked-by: Julien Grall
> >
> > Can a native speaker (Ian, Konrad, George) double-check the
Stefano Stabellini writes ("Re: [PATCH v2] docs/arm64: update the documention
for loading XSM support"):
> Improved the wording and committed
I see my mail proposing a new version crossed with yours.
Also, I seem to be racing in committing with you.
Can you come onto IRC so we can coordinate ?
Julien Grall writes ("Re: [PATCH v2] docs/arm64: update the documention for
loading XSM support"):
> The new version looks good to me:
> Acked-by: Julien Grall
>
> Can a native speaker (Ian, Konrad, George) double-check the wording)?
I found it rather difficult to read. See updated version, at
On Fri, 22 Apr 2016, Julien Grall wrote:
> Hi Jan,
>
> On 22/04/16 09:36, Jan Beulich wrote:
> > I've been getting increasingly annoyed by people not applying common
> > sense to these docs updates.
> >
> > Signed-off-by: Jan Beulich
>
> Acked-by: Julien Grall
>
committed
>
> >
> > --- a/
On Fri, 22 Apr 2016, Wei Liu wrote:
> On Fri, Apr 22, 2016 at 04:42:21PM +0100, Julien Grall wrote:
> > (CC Wei for release-ack)
> >
> > Hello Dirk,
> >
> > On 21/04/16 06:33, Dirk Behme wrote:
> > >Xen needs to blacklist any PSCI node as it will be recreated for DOM0.
> > >Up to now, this was do
Jan Beulich writes ("[PATCH] MAINTAINERS: ARM docs to be maintained by ARM
maintainers"):
> I've been getting increasingly annoyed by people not applying common
> sense to these docs updates.
>
> Signed-off-by: Jan Beulich
I have queued this for commit.
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> >+/* Defines an outstanding patching action. */
> >+struct xsplice_work
> >+{
> >+atomic_t semaphore; /* Used for rendezvous. */
> >+atomic_t irq_semaphore; /* Used to signal all IRQs disabled. */
>
> Why do you, btw, need two of them? I would seem to me that having just on
> Overall I think that all of the cited examples are such which already
> don't really lend themselves to live patching. Hence I think we're
> going to be fine without these extra two pieces for the initial round,
/me nods.
> taking into consideration just those cases where live patching is
> reas
Hi Lars,
On 22/04/16 15:19, Lars Kurth wrote:
On 22 Apr 2016, at 14:39, Wei Liu wrote:
On Fri, Apr 22, 2016 at 02:26:39PM +0100, Lars Kurth wrote:
Folks,
given that we have we are getting close to RC's, I would like to start to spec
out the headline Features for the press release. The big
On 21/04/16 16:45, Jan Beulich wrote:
> In commit aa7c1fdf9d ("x86/MSI: properly track guest masking requests")
> I neglected to consider devices allowing for both MSI and MSI-X to be
> used (not at the same time of course): The MSI-X part of the intercept
> logic needs to fall through to the MSI o
On 22/04/16 16:42, Julien Grall wrote:
(CC Wei for release-ack)
Hello Dirk,
On 21/04/16 06:33, Dirk Behme wrote:
Xen needs to blacklist any PSCI node as it will be recreated for DOM0.
Up to now, this was done only for arm,psci and arm,psci-0.2 compatible
nodes. Add PSCI 1.0 compatibility to
Jan Beulich writes ("Re: [for-4.7 v2 1/2] xen/bitops: Introduce GENMASK to
generate mask"):
> On 22.04.16 at 17:58, wrote:
> > The code has been imported from the header include/linux/bitops.h in
> > Linux v4.6-rc3.
> >
> > Signed-off-by: Julien Grall
> > Acked-by: Stefano Stabellini
>
> And
On 21/04/16 16:45, Jan Beulich wrote:
> In commit 9256f66c16 ("x86/PCI: intercept all PV Dom0 MMCFG writes")
> for an unclear to me reason I left pci_conf_write_intercept()'s return
> value unchecked. Correct this.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
Wei Liu writes ("Re: [PATCH for-4.7] libxl: pvusb: use %u to convert unsigned
number"):
> On Fri, Apr 22, 2016 at 03:44:09PM +0100, Ian Jackson wrote:
> > Juergen Gross writes ("Re: [PATCH for-4.7] libxl: pvusb: use %u to convert
> > unsigned number"):
> > > On 11/04/16 15:08, Wei Liu wrote:
> >
On Fri, Apr 22, 2016 at 03:54:43PM +0100, Ian Jackson wrote:
> It appears that no-one is looking at the output. These have not had a
> push to the tested output branch for at least 250 days (742 days in
> the case of linux-linus!) and the reports don't seem to be generating
> any bugfixing activit
On Fri, Apr 22, 2016 at 03:54:43PM +0100, Ian Jackson wrote:
> It appears that no-one is looking at the output. These have not had a
> push to the tested output branch for at least 250 days (742 days in
> the case of linux-linus!) and the reports don't seem to be generating
> any bugfixing activit
Hi Stefano,
On 22/04/16 10:42, Stefano Stabellini wrote:
On Tue, 12 Apr 2016, Julien Grall wrote:
The ARM implementation of share_xen_page_with_guest is nearly the same as the
x86 one. However, the type is never used so far for the P2M code.
So far, all ARM domains have been auto-translated. D
Hi Jan,
On 22/04/16 09:36, Jan Beulich wrote:
I've been getting increasingly annoyed by people not applying common
sense to these docs updates.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Regards,
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -129,6 +129,7 @@ M: Stefano Stabellini
S:
Hi Dirk,
On 22/04/16 07:15, Dirk Behme wrote:
Add a section about what the firmware should do in EL3 before starting Xen.
E.g. on ARM Linux the HVC instruction is used to trap into Xen. As this
I would rather say "E.g guest will use HVC instruction to issue hypercall".
can be set only at EL
Wei Liu writes ("Re: [PATCH] xenaccess: minor fixes and extra printouts"):
> On Thu, Apr 21, 2016 at 07:22:25AM +0300, Razvan Cojocaru wrote:
> > Acked-by: Razvan Cojocaru
> >
>
> Release-acked-by: Wei Liu
Queued for commit, thanks.
Ian.
___
Xen-de
On Fri, Apr 22, 2016 at 05:40:02PM +0100, Julien Grall wrote:
> (CC Wei for the release-ack)
>
> Hi Fu Wei,
>
> On 21/04/16 12:07, fu@linaro.org wrote:
> >From: Fu Wei
> >
> >This patch updates the documentation for allowing detection of an XSM
> >module that lacks a specific compatible stri
Sorry, I forgot to mention the typo in the title:
s/documention/documentation/
On 22/04/16 17:40, Julien Grall wrote:
(CC Wei for the release-ack)
Hi Fu Wei,
On 21/04/16 12:07, fu@linaro.org wrote:
From: Fu Wei
This patch updates the documentation for allowing detection of an XSM
modul
(CC Wei for the release-ack)
Hi Fu Wei,
On 21/04/16 12:07, fu@linaro.org wrote:
From: Fu Wei
This patch updates the documentation for allowing detection of an XSM
module that lacks a specific compatible string.
This mechanism has been added by the commit
ca32012341f3de7d3975407fb963e6028f
On 22/04/16 08:20, Jan Beulich wrote:
> When a guest unmasks MSI-X interrupts before enabling MSI-X on the
> device, so far nothing updates the {host,guest}_masked internal state;
> this to date only gets done when MSI-X is already enabled. This is why
> half way recent Linux works (as it enables M
On 21/04/16 17:03, George Dunlap wrote:
> Clarify the meaning of nested maintainership.
>
> Signed-off-by: George Dunlap
> ---
> We had a discussion about the meaning of nested maintainership at the
> recent Xen Hackathon. The notes of that meeting can be found on this
> list [1]. No decision is
Roger Pau Monne writes ("[PATCH for-4.7 3/5] build: pass HOST{CC/CXX} value
down to Kconfig"):
> Signed-off-by: Roger Pau Monné
Acked-by: Ian Jackson
(supposing the previous two patches are adjusted as suggested)
Ian.
___
Xen-devel mailing list
Xen
On 22/04/16 16:26, Ian Jackson wrote:
> This will result in the Xen build system building, and then
> preferring, oxenstored.
>
> Signed-off-by: Ian Jackson
> CC: David Scott
> CC: Wei Liu
Reviewed-by: Andrew Cooper
This matches my notes for developing the ocaml bits of xen.git outside
of the
Hello Peng,
I would specific the file modified in the title.
On 20/04/16 14:54, Peng Fan wrote:
The 'Base address for 4K mapping' is '(x19 >> THIRD_SHIFT) << THIRD_SHIFT'.
The computation is a sequence of 2 instructions. I gave a look to the
rest of the file and the comments are usually put
On Thu, Apr 21, 2016 at 12:59:00AM -0600, Jan Beulich wrote:
> >>> On 21.04.16 at 02:33, wrote:
> > On Wed, Apr 20, 2016 at 01:14:17AM -0600, Jan Beulich wrote:
> >> >>> Konrad Rzeszutek Wilk 04/14/16 12:03 AM >>>
> >> >--- a/Config.mk
> >> >+++ b/Config.mk
> >> >@@ -126,6 +126,17 @@ endef
> >>
On Fri, 22 Apr 2016, Jan Beulich wrote:
> >>> On 22.04.16 at 17:58, wrote:
> > The code has been imported from the header include/linux/bitops.h in
> > Linux v4.6-rc3.
> >
> > Signed-off-by: Julien Grall
> > Acked-by: Stefano Stabellini
>
> And just to double check - Stefano, this ack was mean
Hi Shriram and Hongyang
I have a question regarding REMUS block replication support. Does it
require blktap2 to function? The README.remus file only mention DRDB so
I'm not sure how blktap2 fit into the picture.
Thanks
Wei.
___
Xen-devel mailing list
X
On 22/04/16 15:17, Jan Beulich wrote:
> As both INVLPG and INVLPGA have basically the same exception rules
> (leaving aside that INVLPGA requires SVME enabled, which so far isn't
> being taken care of,
We also don't appear to handle the ASID in %ecx correctly either. Yet
another item on the TODO
Doug Goldstein writes ("[PATCH v2] tools: detect appropriate debug optimization
level"):
> When building debug use -Og as the optimization level if its available,
> otherwise retain the use of -O0. -Og has been added by GCC to enable all
> optimizations that to not affect debugging while retaining
On 21/04/16 02:06, Peng Fan wrote:
Hi Julien,
Hello Peng,
On Wed, Apr 20, 2016 at 03:44:09PM +0100, Julien Grall wrote:
Hello Peng,
On 20/04/16 14:54, Peng Fan wrote:
Use shift operator, but not muliplication.
No function change.
Why? The compiler will calculate the address at compilatio
> >+return -EINVAL;
> >+}
> >+
> >+start = sec->load_addr;
> >+end = sec->load_addr + sec->sec->sh_size;
> >+
> >+for ( a = start; a < end; a++ )
> >+{
> >+unsigned long instr = (unsigned long)(&a->instr_offset +
> >a->instr_offset);
>>> On 22.04.16 at 17:58, wrote:
> The code has been imported from the header include/linux/bitops.h in
> Linux v4.6-rc3.
>
> Signed-off-by: Julien Grall
> Acked-by: Stefano Stabellini
And just to double check - Stefano, this ack was meant also as a
REST maintainer, not just an ARM one (as the
Hello,
This small patch series is a bug fix for Xen 4.7 and should also be backported
to Xen 4.6.
Without it, the faulting IPA reported to memaccess may be wrong.
For all the changes see in each patch.
Regards,
Release-acked-by: Wei Liu
Julien Grall (2):
xen/bitops: Introduce GENMASK to ge
The register HPFAR_EL2 (resp. HPFAR on arm32) contains the bits [47:12]
(resp. [39:12]) of the faulting IPA. Unlike other registers that represent
an address, the upper bits of the IPA are stored in the register bits
[4:39] (resp. [4:21]).
However, Xen assumes that the register contains the faulti
The code has been imported from the header include/linux/bitops.h in
Linux v4.6-rc3.
Signed-off-by: Julien Grall
Acked-by: Stefano Stabellini
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim D
On Fri, Apr 22, 2016 at 04:42:21PM +0100, Julien Grall wrote:
> (CC Wei for release-ack)
>
> Hello Dirk,
>
> On 21/04/16 06:33, Dirk Behme wrote:
> >Xen needs to blacklist any PSCI node as it will be recreated for DOM0.
> >Up to now, this was done only for arm,psci and arm,psci-0.2 compatible
> >
On Fri, 22 Apr 2016, Julien Grall wrote:
> Hi Stefano,
>
> On 22/04/16 12:49, Stefano Stabellini wrote:
> > On Fri, 22 Apr 2016, Julien Grall wrote:
> > > Hi Jan,
> > >
> > > On 20/04/16 17:43, Jan Beulich wrote:
> > > > > > > Julien Grall 04/20/16 2:35 PM >>>
> > > > > It is a matter of taste.
(CC Wei for release-ack)
Hello Dirk,
On 21/04/16 06:33, Dirk Behme wrote:
Xen needs to blacklist any PSCI node as it will be recreated for DOM0.
Up to now, this was done only for arm,psci and arm,psci-0.2 compatible
nodes. Add PSCI 1.0 compatibility to make device tree nodes with
compatible =
Hi Stefano,
On 22/04/16 12:49, Stefano Stabellini wrote:
On Fri, 22 Apr 2016, Julien Grall wrote:
Hi Jan,
On 20/04/16 17:43, Jan Beulich wrote:
Julien Grall 04/20/16 2:35 PM >>>
It is a matter of taste.
Indeed.
Is there any reason to not allow different way to create a mask?
I dislike
This will result in the Xen build system building, and then
preferring, oxenstored.
Signed-off-by: Ian Jackson
CC: David Scott
CC: Wei Liu
---
ts-xen-build-prep |1 +
1 file changed, 1 insertion(+)
diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index b35e91b..c8cebf4 100755
--- a/ts-x
flight 92294 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92294/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-i386-xl-qemuu-ovm
On Tue, Apr 19, 2016 at 01:52:33PM -0600, Jan Beulich wrote:
> >>> Konrad Rzeszutek Wilk 04/14/16 12:02 AM >>>
> >NEW CODE:
> >
> >To make that work we add three tables:
>
> Why three? Two (or a single one with element pairs) ought to be sufficient:
> Afaict you could just have (symbol-address,sy
flight 92299 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92299/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken REGR. vs. 878
>>> On 22.04.16 at 16:40, wrote:
> On Fri, Apr 22, 2016 at 08:17:35AM -0600, Jan Beulich wrote:
>> As both INVLPG and INVLPGA have basically the same exception rules
>> (leaving aside that INVLPGA requires SVME enabled, which so far isn't
>> being taken care of, and that INVLPG requires ModRM.mod
flight 92263 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92263/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-qcow2 6 xen-bootfail REGR. vs. 92185
Regressions which ar
It appears that no-one is looking at the output. These have not had a
push to the tested output branch for at least 250 days (742 days in
the case of linux-linus!) and the reports don't seem to be generating
any bugfixing activity.
There is a plan to do some Xen testing in Zero-day but even if th
Hi,
Following the switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe, the pci root
bridge does not finish to initialize and breaks under Xen.
There are several issue probably due to the use of
PcdPciDisableBusEnumeration=TRUE.
First one:
ASSERT MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.
On Fri, Apr 22, 2016 at 03:44:09PM +0100, Ian Jackson wrote:
> Juergen Gross writes ("Re: [PATCH for-4.7] libxl: pvusb: use %u to convert
> unsigned number"):
> > On 11/04/16 15:08, Wei Liu wrote:
> > > Both be_domid and fe_domid are unsigned.
> > >
> > > Reported-by: Olaf Hering
> > > Signed-of
Juergen Gross writes ("Re: [PATCH for-4.7] libxl: pvusb: use %u to convert
unsigned number"):
> On 11/04/16 15:08, Wei Liu wrote:
> > Both be_domid and fe_domid are unsigned.
> >
> > Reported-by: Olaf Hering
> > Signed-off-by: Wei Liu
>
> Reviewed-by: Juergen Gross
This patch doesn't have a
> On 22 Apr 2016, at 15:29, Andrew Cooper wrote:
>
> On 22/04/16 14:26, Lars Kurth wrote:
>> Folks,
>>
>> given that we have we are getting close to RC's, I would like to start to
>> spec out the headline Features for the press release. The big items I am
>> aware of are COLO. I am a little c
On Fri, Apr 22, 2016 at 08:17:35AM -0600, Jan Beulich wrote:
> As both INVLPG and INVLPGA have basically the same exception rules
> (leaving aside that INVLPGA requires SVME enabled, which so far isn't
> being taken care of, and that INVLPG requires ModRM.mod != 3), fold
> the handling of the two a
Ping?
On 03/17/2016 09:33 AM, Boris Ostrovsky wrote:
Original version of that patch (commit a89941816726) had to be reverted
due to Xen allocating irqs in its cpu_up ops.
The first patch moves allocations into hotplug notifiers and the second
one restores the original patch (with minor adjustme
On 04/22/2016 08:05 AM, Ross Lagerwall wrote:
1fb3a8b2cfb2 ("xen/spinlock: Fix locking path engaging too soon under
PVHVM.") moved the initalization of the kicker interrupt until after
native_cpu_up() is called. However, when using qspinlocks, a CPU may try
to kick another CPU that is spinning
Fabio Fantoni writes ("Re: [PATCH] libxl: small indentation fix in
libxl_types.idl"):
> Il 24/02/2016 12:51, Wei Liu ha scritto:
> > On Fri, Feb 19, 2016 at 04:22:28PM +0100, Fabio Fantoni wrote:
> >> Signed-off-by: Fabio Fantoni
> > Acked-by: Wei Liu
>
> ping
We seem to have dropped this. I
On 22/04/16 14:26, Lars Kurth wrote:
> Folks,
>
> given that we have we are getting close to RC's, I would like to start to
> spec out the headline Features for the press release. The big items I am
> aware of are COLO. I am a little confused about xSplice.
>
> Maybe we can use this thread to sta
On Fri, Apr 22, 2016 at 03:22:51PM +0100, Lars Kurth wrote:
>
> > On 22 Apr 2016, at 15:08, George Dunlap wrote:
> >
> > On Fri, Apr 22, 2016 at 2:26 PM, Lars Kurth
> > wrote:
> >> Folks,
> >>
> >> given that we have we are getting close to RC's, I would like to start to
> >> spec out the he
On Fri, Apr 22, 2016 at 3:22 PM, Lars Kurth wrote:
>
>> On 22 Apr 2016, at 15:08, George Dunlap wrote:
>>
>> On Fri, Apr 22, 2016 at 2:26 PM, Lars Kurth wrote:
>>> Folks,
>>>
>>> given that we have we are getting close to RC's, I would like to start to
>>> spec out the headline Features for the
George Dunlap writes:
>
> soft reset for pv guests
>
For HVM guests I guess.
--
Vitaly
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Fri, Apr 22, 2016 at 3:19 PM, Lars Kurth wrote:
>
>> On 22 Apr 2016, at 14:39, Wei Liu wrote:
>>
>> On Fri, Apr 22, 2016 at 02:26:39PM +0100, Lars Kurth wrote:
>>> Folks,
>>>
>>> given that we have we are getting close to RC's, I would like to start to
>>> spec out the headline Features for t
> On 22 Apr 2016, at 15:08, George Dunlap wrote:
>
> On Fri, Apr 22, 2016 at 2:26 PM, Lars Kurth wrote:
>> Folks,
>>
>> given that we have we are getting close to RC's, I would like to start to
>> spec out the headline Features for the press release. The big items I am
>> aware of are COLO.
flight 92350 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/92350/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 13
> On 22 Apr 2016, at 14:39, Wei Liu wrote:
>
> On Fri, Apr 22, 2016 at 02:26:39PM +0100, Lars Kurth wrote:
>> Folks,
>>
>> given that we have we are getting close to RC's, I would like to start to
>> spec out the headline Features for the press release. The big items I am
>> aware of are COLO
On Fri, Apr 22, 2016 at 12:13:02PM +0100, Ross Lagerwall wrote:
> On 04/22/2016 11:08 AM, Jan Beulich wrote:
> On 22.04.16 at 10:45, wrote:
> >>On 04/22/2016 08:51 AM, Jan Beulich wrote:
> >>On 22.04.16 at 09:17, wrote:
> On 04/21/2016 01:26 AM, Konrad Rzeszutek Wilk wrote: snip
> >>>
As both INVLPG and INVLPGA have basically the same exception rules
(leaving aside that INVLPGA requires SVME enabled, which so far isn't
being taken care of, and that INVLPG requires ModRM.mod != 3), fold
the handling of the two as much as possible alongside achieving the
goal of the patch (at once
On Fri, Apr 22, 2016 at 9:26 AM, Lars Kurth wrote:
>
> Folks,
>
> given that we have we are getting close to RC's, I would like to start to
> spec out the headline Features for the press release. The big items I am
> aware of are COLO. I am a little confused about xSplice.
>
> Maybe we can use t
On Fri, Apr 22, 2016 at 2:26 PM, Lars Kurth wrote:
> Folks,
>
> given that we have we are getting close to RC's, I would like to start to
> spec out the headline Features for the press release. The big items I am
> aware of are COLO. I am a little confused about xSplice.
>
> Maybe we can use thi
>>> On 22.04.16 at 15:40, wrote:
> Hmm - Section 6.15 is rather more clear, and does state #GP(0) and
> #SS(0) for limit violations.
>
> In which case I am going to have to untangle hvmemul_virtual_to_linear()
> and hvm_virtual_to_linear_addr() to distinguish the two cases, and also
> to raise #
1 - 100 of 195 matches
Mail list logo
