flight 85255 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85255/
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
Hi all,
I'm sara, a researcher, who trying to modify xen HV. This is my first question
and i'm fresh in mailing lists, so hope i choose the correct list.
I need to create two or more identical vcpus and then run them on separate
cores. I exactly mean that i want having two or more from one vcpu
Hi all,
I'm sara, a researcher, who trying to modify xen HV. This is my first question
and i'm fresh in mailing lists, so hope i choose the correct list.
I need to create two or more identical vcpus and then run them on separate
cores. I exactly mean that i want having two or more from one vcpu
flight 85254 linux-3.10 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85254/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail REGR. vs. 84139
build-i386-rumpuserxen6
flight 85296 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85296/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saver
Hi Congyang,
Thanks for your reply,
even with your script, and I modify the "path_to_xen_source" to point where
my xen directory is. I still got this error.
ERROR: User requested feature xen
configure was not able to find it.
Install xen devel
What do you think what I am missing?
Budget replenishment and enforcement are separated by adding
a replenishment timer, which fires at the next most imminent
release time of all runnable vcpus.
A replenishment queue has been added to keep track of all replenishment
events.
The following functions have major changes to manage the re
flight 85252 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85252/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 84935
Regressions which a
flight 85235 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85235/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 85064
Regressions which ar
> +/* Handle VT-d posted-interrupt when VCPU is blocked. */
> +static void pi_wakeup_interrupt(struct cpu_user_regs *regs)
> +{
> +struct arch_vmx_struct *vmx, *tmp;
> +spinlock_t *lock = &per_cpu(vmx_pi_blocking, smp_processor_id()).lock;
> +struct list_head *blocked_vcpus =
> +
On Sat, Nov 28, 2015 at 04:44:57PM -0500, Don Slutz wrote:
> Changes v12 to v13:
> Rebased on staging (not a simple rebase, needed rework to function
> with changes).
Hey Don,
I was wondering what your plans are for this. The feature freeze window
is coming mighty close and this a pretty neat
On Fri, Mar 04, 2016 at 02:15:49PM +0800, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Add a new delivery type:
> val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI.
> To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
> bit 9 stands the interrupt polarity is active low(1)
Hello,
My name is Ben Sanda, I'm a kernel/firmware developer with DornerWorks
engineering. Our team is working on support for Xen on the new Xilinx
Ultrascale+ MPSoC platforms (ARM A53 core) and I've specifically been tasked
with characterizing performance, particularly that of the schedulers. I w
> +static void do_inc_thresh(unsigned char key, struct cpu_user_regs *regs)
> +{
> +++*lower_thresh_adj;
> +do_adj_thresh(key);
> +}
> +
> +static void do_dec_thresh(unsigned char key, struct cpu_user_regs *regs)
> +{
> +if ( *lower_thresh_adj )
> +--*lower_thresh_adj;
> +do
On Fri, Mar 04, 2016 at 06:17:13PM +, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 00/27] COarse-grain LOck-stepping Virtual
> Machines for Non-stop Service"):
> > This patchset implemented the COLO feature for Xen.
> > For detail/install/use of COLO feature, refer to:
> > http://w
On Fri, Mar 04, 2016 at 05:52:09PM +, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
> > +Enable COLO HA for disk. For better understanding block replication on
> > +QEMU, please refer to:
> > +http://wiki.qemu.org/Features/BlockReplication
>
>
On Fri, Mar 04, 2016 at 05:03:16PM +, Ian Jackson wrote:
> Changlong Xie writes ("[PATCH v11 12/27] tools/libx{l,c}: introduce
> wait_checkpoint callback"):
> > From: Wen Congyang
> >
> > Under COLO, we are doing checkpoint on demand, if this
> > callback returns 1, we will take another chec
Non-debug builds need to explicitly disable debug due to debug being
defaulted to y in Config.mk
Signed-off-by: Doug Goldstein
---
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
CC: Andrew Cooper
change since v1:
- none
tested at: https://travis-ci.org/cardoe/xen/builds/113
When we use GCC 5.x, we need to install the C++ compiler and the C
compiler together because QEMU tests for feature flags against the C
compiler and assumes the C++ compiler has them. We also have to
ensure that it is used. Have to do the modification of the CXX variable
in two steps to ensure we s
Skip building of the coverity, smoke, stable, and master branches since
they just fast forward from staging.
Suggested-by: Andrew Cooper
Signed-off-by: Doug Goldstein
---
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
CC: Andrew Cooper
change since v1:
- ignore all coverity
On Fri, Mar 04, 2016 at 07:25:30PM +0100, Dario Faggioli wrote:
> Hello committers, George,
>
> This is basically a ping for this series, as I think most of it can
> actually go in, unless I've missed something.
>
> So, let me try to recap:
>
> On Tue, 2016-02-16 at 19:11 +0100, Dario Faggioli w
flight 85210 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85210/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs.
83135
Tests which
On Fri, 2016-03-04 at 09:48 -0700, Jan Beulich wrote:
> This is pretty simplistic for now, but I'd rather have someone better
> friends with the tools improve it (if desired).
>
> Signed-off-by: Jan Beulich
>
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5958,6 +5958,26 @@ int li
flight 85354 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85354/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
On 3/4/16 9:56 AM, Doug Goldstein wrote:
> On 3/4/16 8:46 AM, Doug Goldstein wrote:
>> Non-debug builds need to explicitly disable debug due to debug being
>> defaulted to y in Config.mk
>>
>> Signed-off-by: Doug Goldstein
>> ---
>> CC: Ian Jackson
>> CC: Jan Beulich
>> CC: Keir Fraser
>> CC: T
Hello committers, George,
This is basically a ping for this series, as I think most of it can
actually go in, unless I've missed something.
So, let me try to recap:
On Tue, 2016-02-16 at 19:11 +0100, Dario Faggioli wrote:
>
> Dario Faggioli (16):
> xen: sched: __runq_tickle takes a useles
Changlong Xie writes ("[PATCH v11 00/27] COarse-grain LOck-stepping Virtual
Machines for Non-stop Service"):
> This patchset implemented the COLO feature for Xen.
> For detail/install/use of COLO feature, refer to:
> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping
Thanks for this ser
Changlong Xie writes ("[PATCH v11 27/27] cmdline switches and config vars to
control colo-proxy"):
> From: Wen Congyang
>
> Add cmdline switches to 'xl migrate-receive' command to specify
> a domain-specific hotplug script to setup COLO proxy.
>
> Add a new config var 'colo.default.agentscript'
Changlong Xie writes ("[PATCH v11 26/27] setup and control colo proxy on
secondary side"):
> From: Wen Congyang
I don't see anything here I have questions about. I don't intend to
review it in detail...
Thanks,
Ian.
___
Xen-devel mailing list
Xen-de
> +static void colo_proxy_async_call(libxl__egc *egc,
> + libxl__colo_save_state *css,
> + void func(libxl__colo_save_state *),
> + libxl__ev_child_callback callback)
> +{
This is a straight clone-an
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index a2078d1..6b57aba 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -599,6 +599,7 @@ libxl_device_nic = Struct("device_nic", [
> ("rate_bytes_per_interval", uint64),
> ("rate_
Changlong Xie writes ("[PATCH v11 23/27] COLO proxy: preresume, postresume and
checkpoint"):
> From: Wen Congyang
>
> preresume, postresume and checkpoint
I think maybe this needs to be combined with the previous patch ?
I don't think I quite understand the structure of the patch series at
thi
Changlong Xie writes ("[PATCH v11 22/27] COLO proxy: implement setup/teardown
of COLO proxy module"):
> From: Wen Congyang
>
> setup/teardown of COLO proxy module.
> we use netlink to communicate with proxy module.
> About colo-proxy module:
> https://lkml.org/lkml/2015/6/18/32
> How to use:
> h
Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
> +Enable COLO HA for disk. For better understanding block replication on
> +QEMU, please refer to:
> +http://wiki.qemu.org/Features/BlockReplication
Sorry, I missed this link on my first pass. I still think that at the
v
On 3/3/2016 4:10 PM, Corneliu ZUZU wrote:
Then,
QUESTIONS (FOR VM-EVENTS & ARM MAINTAINERS ESPECIALLY):
Q1) [...]
Q2) [...]
Q3) [...]
Q4) [...]
JSYK, I've realized I can find the answer for these easily (besides Q2,
for which
Razvan already gave feedback) with some tests (as soon as I ge
Changlong Xie writes ("[PATCH v11 20/27] Support colo mode for qemu disk"):
> From: Wen Congyang
>
> Usage: disk =
> ['...,colo,colo-host=xxx,colo-port=xxx,colo-export=xxx,active-disk=xxx,hidden-disk=xxx...']
> For QEMU block replication details:
> http://wiki.qemu.org/Features/BlockReplication
Changlong Xie writes ("[PATCH v11 19/27] COLO: introduce new API to
prepare/start/do/get_error/stop replication"):
> From: Wen Congyang
>
> We will use qemu block replication, and qemu provides some qmp commands
> to prepare replication, start replication, get replication error, and
> stop repli
Changlong Xie writes ("[PATCH v11 19/27] COLO: introduce new API to
prepare/start/do/get_error/stop replication"):
> From: Wen Congyang
>
> We will use qemu block replication, and qemu provides some qmp commands
> to prepare replication, start replication, get replication error, and
> stop repli
> --- a/docs/man/xl.pod.1
> +++ b/docs/man/xl.pod.1
...
> + COLO support in xl is still in experimental (proof-of-concept) phase.
> + There is no support for network or disk at the moment.
I think you need to spell out the lack of storage and network handling
means that the guest will corr
flight 44218 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44218/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail
never pass
test-armhf-ar
Changlong Xie writes ("[PATCH v11 17/27] libxc/save: support COLO save"):
> From: Wen Congyang
>
> After suspend primary vm, get dirty bitmap on secondary vm,
> and send pages both dirty on primary/secondary to secondary.
This patch again seems like a plausible kind of thing. Again, I'd
like to
Changlong Xie writes ("[PATCH v11 16/27] libxc/restore: support COLO restore"):
> From: Wen Congyang
>
> a. call callbacks resume/checkpoint/suspend while secondary vm
>status is consistent with primary
> b. send dirty pfn list to primary when checkpoint under colo
> c. send store gfn and con
Changlong Xie writes ("[PATCH v11 15/27] primary vm suspend/resume/checkpoint
code"):
> From: Wen Congyang
I would look at this on the same basis as the previous patch.
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 48b4858..5160939 100644
> --- a/tools/libxl
Changlong Xie writes ("[PATCH v11 14/27] secondary vm suspend/resume/checkpoint
code"):
> From: Wen Congyang
>
> Secondary vm is running in colo mode. So we will do
> the following things again and again:
I don't propose to review this in detail. Skimreading it, it looks
plausible. I don't th
Changlong Xie writes ("[PATCH v11 13/27] tools/libx{l,c}: add postcopy/suspend
callback to restore side"):
> From: Wen Congyang
>
> Secondary(restore side) is running under COLO, we also need
> postcopy/suspend callbacks.
This patch does not provide an implementation of any of these
callbacks,
Changlong Xie writes ("[PATCH v11 12/27] tools/libx{l,c}: introduce
wait_checkpoint callback"):
> From: Wen Congyang
>
> Under COLO, we are doing checkpoint on demand, if this
> callback returns 1, we will take another checkpoint.
> 0 indicates unexpected error.
This doesn't seem to have a corr
Changlong Xie writes ("[PATCH v11 11/27] tools/libxl: add back channel support
to read stream"):
> From: Wen Congyang
>
> This is used by primay to read records sent by secondary.
I haven't reviewed the flow here in detail but the general idea seems
sound.
Ian.
___
Changlong Xie writes ("[PATCH v11 10/27] tools/libxl: add back channel support
to write stream"):
> From: Wen Congyang
>
> Add back channel support to write stream. If the write stream is
> a back channel stream, this means the write stream is used by
> Secondary to send some records back.
The
Changlong Xie writes ("[PATCH v11 09/27] libxc/migration: export read_record
for common use"):
> From: Wen Congyang
...
> +int read_record(struct xc_sr_context *ctx, int fd, struct xc_sr_record *rec)
> +{
I haven't checked that this is (apart from the specified change) pure
code motion, but on t
Changlong Xie writes ("[PATCH v11 08/27] libxc/migration: Specification update
for DIRTY_PFN_LIST records"):
> From: Wen Congyang
>
> Used by secondary to send it's dirty bitmap to primary under COLO.
Again, I think this will want a review from Andrew Coooper.
Also, again, I think it would ben
Changlong Xie writes ("[PATCH v11 07/27] docs/libxl: Introduce
CHECKPOINT_CONTEXT to support migration v2 colo streams"):
> From: Wen Congyang
I think we will want to see an ack from Andy Cooper on this, in due
course.
> It is the negotiation record for COLO.
> Primary->Secondary:
> control_id
This is pretty simplistic for now, but I'd rather have someone better
friends with the tools improve it (if desired).
Signed-off-by: Jan Beulich
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5958,6 +5958,26 @@ int libxl_send_debug_keys(libxl_ctx *ctx
return 0;
}
+int libxl_log_
Signed-off-by: Jan Beulich
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1120,6 +1120,11 @@ int xc_readconsolering(xc_interface *xch
int xc_send_debug_keys(xc_interface *xch, char *keys);
+int xc_get_log_level(xc_interface *xch, bool guest,
+
flight 85333 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85333/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080
Tests which di
flight 85168 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85168/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 59254
build-amd64-rumpuserx
... from serial console and via sysctl so that one doesn't always need
to reboot to see more / less messages.
Note that upper thresholds driven from the serial console are sticky,
i.e. while they get adjusted upwards when the lower threshold would
otherwise end up above the upper one, they don't g
Changlong Xie writes ("[PATCH v11 05/27] tools/libx{l,c}: add back channel to
libxc"):
> [stuff]
A good explanation, thanks.
> Note: it is different from the paper. We change the original design to
> the current one, according to our following concerns:
> 1. The original design needs extra memor
Changlong Xie writes ("[PATCH v11 04/27] tools/libxl: Introduce new helper
function dup_fd_helper()"):
> From: Wen Congyang
>
> It is pure refactoring and no functional changes.
...
> /*- helper execution -*/
> +static int dup_fd_helper(libxl__gc *gc, int fd, const char *what)
> +{
Thi
Changlong Xie writes ("[PATCH v11 03/27] tools/libxl: Add back channel to allow
migration target send data back"):
> From: Wen Congyang
>
> In COLO mode, secondary needs to send the following data to primary:
> 1. In libxl
>Secondary sends the following CHECKPOINT_CONTEXT to primary:
>CH
Only patch 1 has been sent before.
1: console: allow log level threshold adjustments
2: libxc: wrapper for log level sysctl
3: xl: new "loglvl" command
Signed-off-by: Jan Beulich
---
v2: Add sysctl, libxc wrapper, and xl command.
___
Xen-devel mailin
On Fri, 2016-02-26 at 13:33 -0500, Chen, Tianyang wrote:
> Attached.
>
Hey,
here I am... sorry it took a bit.
I've had a look, and I've been able to come up with some code that I at
least do not dislike too much! ;-P
Have a look at the attached patch (you should apply it on top of the
sched_rt.
Changlong Xie writes ("[PATCH v11 01/27] tools/libxl: introduction of
libxl__qmp_restore to load qemu state"):
> From: Wen Congyang
>
> In normal migration, the qemu state is passed to qemu as a parameter.
> With COLO, secondary vm is running. So we will do the following steps
> at every checkpo
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/4 20:24, Stefano Stabellini wrote:
> > On Fri, 4 Mar 2016, Shannon Zhao wrote:
> > > >From: Shannon Zhao
> > > >
> > > >ACPI 6.0 introduces a new table STAO to list the devices which are used
> > > >by Xen and can't be used by Dom0. On Xen virtual
Jan Beulich writes ("Re: [Xen-devel] [PATCH v3] xen/errno: Reduce complexity of
inclusion"):
> On 04.03.16 at 13:50, wrote:
> > IMO, it is wrong to undef XEN_ERRNO if it was provided from external scope.
>
> Well, even if not written down, that's the intended behavior: The
> use case for the inc
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016/3/4 23:23, Stefano Stabellini wrote:
> > On Fri, 4 Mar 2016, Shannon Zhao wrote:
> > > >On 2016年03月04日 18:55, Stefano Stabellini wrote:
> > > > > >On Fri, 4 Mar 2016, Jan Beulich wrote:
> > > > > > > > > > > > > > > >>>On 04.03.16 at
> > > > > >
On 3/4/16 8:46 AM, Doug Goldstein wrote:
> Non-debug builds need to explicitly disable debug due to debug being
> defaulted to y in Config.mk
>
> Signed-off-by: Doug Goldstein
> ---
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Keir Fraser
> CC: Tim Deegan
> CC: Andrew Cooper
Here's a run with
On 2016/3/4 20:24, Stefano Stabellini wrote:
On Fri, 4 Mar 2016, Shannon Zhao wrote:
>From: Shannon Zhao
>
>ACPI 6.0 introduces a new table STAO to list the devices which are used
>by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>UART is used by Xen. So here it hides U
On 3/4/16 9:30 AM, Andrew Cooper wrote:
> On 04/03/16 14:46, Doug Goldstein wrote:
>> Skip building of the coverity, smoke and master branches since they just
>> fast forward from staging.
>>
>> Suggested-by: Andrew Cooper
>> Signed-off-by: Doug Goldstein
>> ---
>> CC: Ian Jackson
>> CC: Jan Beu
On 2016/3/4 23:31, Stefano Stabellini wrote:
On Fri, 4 Mar 2016, Shannon Zhao wrote:
>On 2016年03月04日 18:59, Stefano Stabellini wrote:
> >>diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> >> >index 7f59761..6db3711 100644
> >> >--- a/xen/include/asm-arm/acpi.h
> >> >+++
On 3/4/16 9:48 AM, Jan Beulich wrote:
On 04.03.16 at 15:46, wrote:
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -1,6 +1,12 @@
>> language: c
>> dist: trusty
>> sudo: required
>> +# don't test master, smoke and coverity branches
>> +branches:
>> +except:
>> +- master
>> +
On 2016/3/4 23:23, Stefano Stabellini wrote:
On Fri, 4 Mar 2016, Shannon Zhao wrote:
>On 2016年03月04日 18:55, Stefano Stabellini wrote:
> >On Fri, 4 Mar 2016, Jan Beulich wrote:
> > > >>>On 04.03.16 at 07:15, wrote:
> >>> > >From: Shannon Zhao
> >>> > >
> >>> > >Estimate the memory requi
>>> On 04.03.16 at 15:46, wrote:
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,6 +1,12 @@
> language: c
> dist: trusty
> sudo: required
> +# don't test master, smoke and coverity branches
> +branches:
> +except:
> +- master
> +- smoke
> +- coverity-tested/master
W
>>> On 04.03.16 at 16:03, wrote:
> On 2016年03月04日 18:55, Stefano Stabellini wrote:
>> On Fri, 4 Mar 2016, Jan Beulich wrote:
>> > >>> On 04.03.16 at 07:15, wrote:
> > From: Shannon Zhao
> >
> > Estimate the memory required for loading acpi/efi tables in Dom0. Make
> > th
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016年03月04日 18:59, Stefano Stabellini wrote:
> >> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
> >> > index 7f59761..6db3711 100644
> >> > --- a/xen/include/asm-arm/acpi.h
> >> > +++ b/xen/include/asm-arm/acpi.h
> >> > @@ -25,6 +2
On 04/03/16 14:46, Doug Goldstein wrote:
> Skip building of the coverity, smoke and master branches since they just
> fast forward from staging.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Doug Goldstein
> ---
> CC: Ian Jackson
> CC: Jan Beulich
> CC: Keir Fraser
> CC: Tim Deegan
> CC: A
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> On 2016年03月04日 18:55, Stefano Stabellini wrote:
> > On Fri, 4 Mar 2016, Jan Beulich wrote:
> > > >>> On 04.03.16 at 07:15, wrote:
> >>> > > From: Shannon Zhao
> >>> > >
> >>> > > Estimate the memory required for loading acpi/efi tables in Dom0. Make
On 2016年03月04日 18:59, Stefano Stabellini wrote:
>> diff --git a/xen/include/asm-arm/acpi.h b/xen/include/asm-arm/acpi.h
>> > index 7f59761..6db3711 100644
>> > --- a/xen/include/asm-arm/acpi.h
>> > +++ b/xen/include/asm-arm/acpi.h
>> > @@ -25,6 +25,7 @@
>> >
>> > #include
>> > #include
>> > +
On 2016年03月04日 19:26, Stefano Stabellini wrote:
> On Fri, 4 Mar 2016, Shannon Zhao wrote:
>> > From: Shannon Zhao
>> >
>> > Interrupt information is described in DSDT and is not available at the
>> > time of booting. Check if the interrupt is permitted to access and set
>> > the interrupt type, r
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
> refactors the functions preinit_xen_time and init_xen_time. But it
> wrongly moves the platform_get_irq from init_xen_time to
> preinit_dt_xen_time and this will cause booting failure
On 2016年03月04日 18:55, Stefano Stabellini wrote:
> On Fri, 4 Mar 2016, Jan Beulich wrote:
> > >>> On 04.03.16 at 07:15, wrote:
>>> > > From: Shannon Zhao
>>> > >
>>> > > Estimate the memory required for loading acpi/efi tables in Dom0. Make
>>> > > the length of each table aligned with 64bit.
flight 85150 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 60684
build-amd6
Non-debug builds need to explicitly disable debug due to debug being
defaulted to y in Config.mk
Signed-off-by: Doug Goldstein
---
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
CC: Andrew Cooper
---
.travis.yml | 18 +-
1 file changed, 9 insertions(+), 9 del
Skip building of the coverity, smoke and master branches since they just
fast forward from staging.
Suggested-by: Andrew Cooper
Signed-off-by: Doug Goldstein
---
CC: Ian Jackson
CC: Jan Beulich
CC: Keir Fraser
CC: Tim Deegan
CC: Andrew Cooper
---
.travis.yml | 6 ++
1 file changed, 6 i
When we use GCC 5.x, we need to install the C++ compiler and the C
compiler together because QEMU tests for feature flags against the C
compiler and assumes the C++ compiler has them. We also have to
ensure that it is used. Have to do the modification of the CXX variable
in two steps to ensure we s
flight 85121 xen-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 83004
build-armhf
While to support ACPI, patch "arm/acpi: Parse GTDT to initialize timer"
refactors the functions preinit_xen_time and init_xen_time. But it
wrongly moves the platform_get_irq from init_xen_time to
preinit_dt_xen_time and this will cause booting failure.
So move platform_get_irq back to init_xen_tim
>>> On 04.03.16 at 15:09, wrote:
> On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote:
>> In the course of backporting other XSA fixes to very old trees I had
>> noticed that the XSA-155 had shrunk to just the change to
>> xen/include/public/io/ring.h at some point, which didn't seem righ
This run is configured for baseline tests only.
flight 44216 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44216/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm3 host-install(3)
>>> On 04.03.16 at 14:59, wrote:
> On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote:
>> On March 04, 2016 5:29pm, wrote:
>> > To be honest, changes like this would better not be buried in a big
>> > rework like
>> > the one here. Make it a prereq patch, where you then will kind of
>> > automatic
On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote:
> In the course of backporting other XSA fixes to very old trees I had
> noticed that the XSA-155 had shrunk to just the change to
> xen/include/public/io/ring.h at some point, which didn't seem right.
> Clearly up to 4.5 the situation of
>>> On 04.03.16 at 12:22, wrote:
> The offset at which components xsaved by xsave[sc] are not fixed.
> So when when a save with v->fpu_dirtied set is followed by one
> with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
> written by the lazy one.
>
> The solution is when xsave[sc]
On Fri, 2016-03-04 at 11:54 +, Xu, Quan wrote:
> On March 04, 2016 5:29pm, wrote:
> > On March 04, 2016 7:59am, wrote:
> >
> > > Also I'd highlight the below modification:
> > > -if ( !spin_trylock(&pcidevs_lock) )
> > > -return -ERESTART;
> > > -
> > > +pcidevs_lock();
> > >
>>> On 04.03.16 at 12:00, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -934,8 +934,14 @@ long arch_do_domctl(
> goto vcpuextstate_out;
> }
>
> -expand_xsave_states(v, xsave_area,
> -
flight 85320 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85320/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 85080
Tests which di
flight 85117 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/85117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumpuserxen 6 xen-build fail REGR. vs. 66399
build-i386-rumpuserxen
>>> On 23.02.16 at 12:22, wrote:
> Patches 1 and 2 are meant to go in. Patch 3 is a prerequisite to patch
> 4 and may go in as well, but patch 4 is RFC because with the Pericom
> board I have MSI doesn't appear to function. Since it also does not
> work in baremetal Linux when doing the trivial ad
>>> On 04.03.16 at 13:50, wrote:
> On 04/03/16 12:28, Jan Beulich wrote:
> On 04.03.16 at 13:24, wrote:
>> On 03.03.16 at 15:14, wrote:
@@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN,106)/* Transport endpoint
is already
>>> connected */
XEN_ERRNO(ENOTCONN, 107)
On 04/03/16 12:28, Jan Beulich wrote:
On 04.03.16 at 13:24, wrote:
> On 03.03.16 at 15:14, wrote:
>>> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint
>>> is already
>> connected */
>>> XEN_ERRNO(ENOTCONN,107)/* Transport endpoint is not connected
>>> On 04.03.16 at 13:24, wrote:
On 03.03.16 at 15:14, wrote:
>> @@ -82,16 +109,19 @@ XEN_ERRNO(EISCONN, 106)/* Transport endpoint
>> is already
> connected */
>> XEN_ERRNO(ENOTCONN, 107)/* Transport endpoint is not connected */
>> XEN_ERRNO(ETIMEDOUT,110)/* Conn
On Fri, 4 Mar 2016, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Sometimes it needs to check if there is a subnode of given node in FDT
> by given name. Introduce this helper to get the subnode if it exists.
>
> CC: Rob Herring
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
>
1 - 100 of 184 matches
Mail list logo
