On 19/04/2019 00:31, Joe Jin wrote:
> On 4/18/19 2:09 PM, Boris Ostrovsky wrote:
>> On 4/18/19 3:36 AM, Juergen Gross wrote:
>>> I'm currently investigating a problem related to swiotlb-xen. With a
>>> specific driver a customer is capable to trigger a situation where a
>>> MFN is mapped to
flight 134973 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134973/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
flight 134972 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134972/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3866 xen-buildfail REGR. vs. 134889
Tests which did not
flight 134859 qemu-upstream-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134859/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133734
flight 134969 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134969/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
flight 134970 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134889
version targeted for
flight 134855 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134855/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134611
build-arm64-pvops
flight 134965 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134965/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134889
build-i386-pvops
On 4/18/19 2:09 PM, Boris Ostrovsky wrote:
> On 4/18/19 3:36 AM, Juergen Gross wrote:
>> I'm currently investigating a problem related to swiotlb-xen. With a
>> specific driver a customer is capable to trigger a situation where a
>> MFN is mapped to multiple dom0 PFNs at the same time. There is no
flight 134966 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134966/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
On Thu, Apr 18, 2019 at 02:59:17PM +0100, Andrew Cooper wrote:
> On 18/04/2019 13:31, Wei Liu wrote:
> > Hi all
> >
> > We now have Gitlab CI as a complementary system to Osstest and have planned
> > to
> > add bots. It's high time we think about how we integrate them and how it may
> > improve
On 4/18/19 3:36 AM, Juergen Gross wrote:
> I'm currently investigating a problem related to swiotlb-xen. With a
> specific driver a customer is capable to trigger a situation where a
> MFN is mapped to multiple dom0 PFNs at the same time. There is no
> guest involved, so this is not related to
This run is configured for baseline tests only.
flight 84029 linux-arm-xen real [real]
http://osstest.xensource.com/osstest/logs/84029/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops
On Thu, 18 Apr 2019, Julien Grall wrote:
> On 18/04/2019 19:52, Stefano Stabellini wrote:
> > On Thu, 18 Apr 2019, Julien Grall wrote:
> > > On 18/04/2019 19:23, Stefano Stabellini wrote:
> > > > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > >
flight 134832 linux-arm-xen real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134832/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-examine 11 examine-serial/bootloader fail in 134708 pass in
134832
test-armhf-armhf-xl-rtds
On 18/04/2019 19:52, Stefano Stabellini wrote:
On Thu, 18 Apr 2019, Julien Grall wrote:
On 18/04/2019 19:23, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
On 4/17/19 9:28 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
If it is considered
On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 18/04/2019 19:40, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 27/03/2019
Hi,
On 18/04/2019 19:40, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
On 4/17/19 9:24 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Hi,
On 27/03/2019 19:03, Andrew Cooper wrote:
On 27/03/2019 18:45, Julien Grall wrote:
Clang is pickier than
On Thu, 18 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 18/04/2019 19:23, Stefano Stabellini wrote:
> > On Wed, 17 Apr 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > > > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > > > Clang is pickier than GCC
Hi,
On 18/04/2019 19:23, Stefano Stabellini wrote:
On Wed, 17 Apr 2019, Julien Grall wrote:
Hi,
On 4/17/19 9:28 PM, Stefano Stabellini wrote:
On Wed, 27 Mar 2019, Julien Grall wrote:
Clang is pickier than GCC for the register size in asm statement. It
expects the register size to match the
On Thu, Apr 18, 2019 at 11:02 AM George Dunlap wrote:
>
> On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
> > On Thu, Apr 18, 2019 at 3:53 AM George Dunlap
> > wrote:
> >>
> >> On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
> >>> On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
> >>> wrote:
>
On Wed, 17 Apr 2019, Julien Grall wrote:
> On 4/17/19 9:24 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Hi,
> > >
> > > On 27/03/2019 19:03, Andrew Cooper wrote:
> > > > On 27/03/2019 18:45, Julien Grall wrote:
> > > > > Clang is pickier than GCC for the
(+ Roger)
On 18/04/2019 12:15, Artem Mygaiev wrote:
Hi Julien
On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
On 18/04/2019 10:15, Artem Mygaiev wrote:
Hello Julien, Stefano
Hi Artem,
On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
Hi,
On 16/04/2019 23:43, Stefano
flight 134959 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134959/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 4/17/19 9:28 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang is pickier than GCC for the register size in asm statement. It
> > > expects the register size to match the value size.
> > >
> > > The asm
flight 134949 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134889
version targeted for
On Wed, 17 Apr 2019, Julien Grall wrote:
> Hi,
>
> On 4/17/19 9:45 PM, Stefano Stabellini wrote:
> > On Wed, 27 Mar 2019, Julien Grall wrote:
> > > Clang understands the GCCism in use here, but still complains that sp is
> > > unitialised. In such cases, resort to the older versions of this code,
On Thu, 18 Apr 2019, Wei Liu wrote:
> Hi all
>
> We now have Gitlab CI as a complementary system to Osstest and have planned to
> add bots. It's high time we think about how we integrate them and how it may
> improve our workflow.
>
> ## Requirements
>
> 1. We want to have light weight build
On 4/18/19 2:59 PM, Tamas K Lengyel wrote:
> On Thu, Apr 18, 2019 at 3:53 AM George Dunlap
> wrote:
>>
>> On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
>>> On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
>>> wrote:
On 16.04.2019 18:07, George Dunlap wrote:
> On
sg-run-job would unconditionally set the step state to the value it
calculated, which would usually be `pass' or `fail' or
`broken' (according to the recipe).
Relax this interface somewhat to allow a test script to set the step
status itself: specifically, do not overwrite an existing status of
No functional change except to a message.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 38c17d60..e218ff35 100644
--- a/Osstest/TestSupport.pm
+++
No functional change with existing callers.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index ec867e4f..38c17d60 100644
--- a/Osstest/TestSupport.pm
+++
Sometimes, due to a shortage of available resources, a flight might be
delayed because a handful of jobs are waiting much longer than the
rest. Add a heuristic which causes these jobs to be abandoned.
We consider ourselves starving if we are starving now, based on the
most optimistic start time
Little significant change with existing non-broken flights etc.
Signed-off-by: Ian Jackson
---
ts-logs-capture | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/ts-logs-capture b/ts-logs-capture
index a429bb76..83234f6f 100755
--- a/ts-logs-capture
+++ b/ts-logs-capture
Now that we have a more sophisticated estimate of our likely scheduled
time, use it here too.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
It needs to not mind if a job reports as `starved', even if sg-run-job
exited non-zero.
Signed-off-by: Ian Jackson
---
sg-execute-flight | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sg-execute-flight b/sg-execute-flight
index aed9823d..02f63316 100755
---
If a build job is starved, then the same status
(No jobs are marked `starved' yet.)
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 2e11c8f3..be5588fc 100644
---
This is much more convenient for ad-hoc use.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index dcfc70f2..3da138b1 100755
---
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index e218ff35..8e20244d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -235,6 +235,17 @@ sub broken ($;$) {
This just affects sorting etc. in the summary display.
Signed-off-by: Ian Jackson
---
ms-flights-summary | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/ms-flights-summary b/ms-flights-summary
index 9d15dd14..8293d4f6 100755
--- a/ms-flights-summary
+++
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index 3a680c9d..2e11c8f3 100644
--- a/Osstest/JobDB/Executive.pm
+++ b/Osstest/JobDB/Executive.pm
@@ -287,7 +287,7
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index b75927c1..64c4c9f9 100755
--- a/ts-hosts-allocate-Executive
+++
sg-report-flight is a bit awkward. It thinks mostly about step
status, not job status. So, when justifying, if we don't find a step,
and the job state is starved, we treat the step as starved.
If there are only starved steps, then we don't have evidence that this
is a regression, because the
Previously this was "broken".
We mustn't just call `broken' inside attempt_allocation because that
runs in a db transaction. Instead, we arrange that attempt_allocation
returns 2, which threads its way back out to the return value from
alloc_resources, and then call broken there.
Signed-off-by:
This gives a way for the caller's $resourcecall to signal something
interesting, back to its main loop. This is useful for calling
broken, for example: that can't be done within $resourcecall because
$resourcecall operates within the allocation db transaction (which
ought to be rolled back...)
We are going to use this for situations where the resources to run the
test weren't available. In general we are going to treat this as not
a regression.
Signed-off-by: Ian Jackson
---
sg-report-flight | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sg-report-flight
Provide hostalloc_starvation_* in Osstest::Executive, and a comment
saying what we are going to do. And provide a demo utility which
prints the effect of some particular runvar value on a range of
situations.
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 70
Prep work, no functional change.
Signed-off-by: Ian Jackson
---
ts-hosts-allocate-Executive | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
index 3da138b1..3425c8ce 100755
--- a/ts-hosts-allocate-Executive
+++
Sometimes we find ourselves seriously lacking the capacity to run
particular job(s). The result can be that the whole system stands
mostly idle while a small proportion of the resources runs flat out
with a giant queue.
In this series we arrange for osstest to be able to spot this
happening, and
ts-hosts-allocate is going to set the job status to `starved'
sometimes, and then die. `starved' needs to be added to the list of
job statuses that sg-run-job leaves alone.
Signed-off-by: Ian Jackson
---
tcl/JobDB-Executive.tcl | 1 +
1 file changed, 1 insertion(+)
diff --git
These functions are about to be sometimes called for non-substep
steps.
Signed-off-by: Ian Jackson
---
Osstest/JobDB/Executive.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Osstest/JobDB/Executive.pm b/Osstest/JobDB/Executive.pm
index ea349052..3a680c9d 100644
---
flight 134826 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134826/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134598
build-arm64
On 18/04/2019 16:02, Sam Caccavale wrote:
> As of now, the x86_instruction_emulator will execute opcodes
> belonging to CPU extensions that the host may not have.
> Specifying --ignore-sigill when running afl-harness will ignore
> all SIG_ILL including those generated by the above issue.
Which
flight 134815 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134815/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134594
Hi,
On 18/04/2019 12:46, Wei Liu wrote:
On Wed, Apr 17, 2019 at 06:42:47PM +0100, Julien Grall wrote:
Hi,
@Wei, @Ian: Do you have any input?
Sorry I haven't been following this closely, but shouldn't we fix the
interface to return gfn instead? And then the mapping of it should
interpret the
As of now, the x86_instruction_emulator will execute opcodes
belonging to CPU extensions that the host may not have.
Specifying --ignore-sigill when running afl-harness will ignore
all SIG_ILL including those generated by the above issue.
---
.../fuzz/x86_instruction_emulator/afl-harness.c | 17
flight 134952 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134952/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
On Thu, Apr 18, 2019 at 12:26:18PM +0100, Ian Jackson wrote:
> This branch is supposed to be suitable for all versions of Xen.
> Conversely, older versions of OVMF do not build on newer compilers (as
> provided, eg, in stretch).
>
> So, for "branches" other than xen-unstable and
Andrew Cooper writes ("Re: Xen project CI systems and committer workflow"):
> While everything presented here is fine to do as a matter of policy, the
> committers still need to retain the ability to actually push directly to
> the staging branches on xen.git
Why ?
In particular, this seems to
On Thu, Apr 18, 2019 at 3:53 AM George Dunlap wrote:
>
> On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
> > On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
> > wrote:
> >>
> >>
> >>
> >> On 16.04.2019 18:07, George Dunlap wrote:
> >>> On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
> On Tue,
On 18/04/2019 13:31, Wei Liu wrote:
> Hi all
>
> We now have Gitlab CI as a complementary system to Osstest and have planned to
> add bots. It's high time we think about how we integrate them and how it may
> improve our workflow.
>
> ## Requirements
>
> 1. We want to have light weight build tests
On Thu, Apr 18, 2019 at 02:21:44PM +0100, Ian Jackson wrote:
>
> > Gitlab CI doesn't have a self pushgate. If it is broken by accident Osstest
> > will be blocked.
>
> Could we plan some kind of procedural or robotic workaround ?
So my thoughts around this are on priority values. Admittedly it
On Thu, Apr 18, 2019 at 01:32:52PM +0100, Wei Liu wrote:
> Cc Anthony as well. Forgot to do that. Sorry.
>
> On Thu, Apr 18, 2019 at 01:31:59PM +0100, Wei Liu wrote:
> > Hi all
> >
> > We now have Gitlab CI as a complementary system to Osstest and have planned
> > to
> > add bots. It's high
This all sounds good.
Wei Liu writes ("Xen project CI systems and committer workflow"):
> ## Gaps
>
> The component / system which merges trees and drives CI systems is missing.
>
> Patchew and Patchwork don't do all the things we care about yet.
We need to decide how the plumbing should be
On 4/18/19 2:52 AM, Daniel P. Smith wrote:
> This deals with two casting issues for compiling under go 1.11:
> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
> - add cast to unsafe.Pointer for the C string cpath
>
> Signed-off-by: Daniel P. Smith
Reviewed-by: George Dunlap
On Wed, Apr 17, 2019 at 09:51:47PM -0700, PGNet Dev wrote:
> On 4/17/19 8:30 PM, PGNet Dev wrote:
> > Thx.
> >
> > not ignoring you -- opensuse kernel build system is having a hissy-fit
> > atm; builds are failing. :-/
> >
> > if I can't get it to behave a build a nice pkg for me, I'll work on
Cc Anthony as well. Forgot to do that. Sorry.
On Thu, Apr 18, 2019 at 01:31:59PM +0100, Wei Liu wrote:
> Hi all
>
> We now have Gitlab CI as a complementary system to Osstest and have planned to
> add bots. It's high time we think about how we integrate them and how it may
> improve our
Hi all
We now have Gitlab CI as a complementary system to Osstest and have planned to
add bots. It's high time we think about how we integrate them and how it may
improve our workflow.
## Requirements
1. We want to have light weight build tests before a patch series is reviewed
or committed.
On Mon, 2016-08-08 at 18:54 +, Trammell Hudson wrote:
> Keir Fraser replied to Ward's follow up question:
>
> > > Is there a significant difference between booting 3.1.4 and
> > > 3.2.1 with kexec in terms of BIOS requirements?
> >
> > If you specify no-real-mode in both cases then there
> >
I'm running an i7-8550U on a Huawei Matebook X Pro. Running Qubes OS I
used to idle ~60C, with these MSRs enabled, I've been able to get
stable ~45-55C.
I'm not too sure, but I think it was reverse engineered from Intel's
XTU Tool. Perhaps it's behind NDAs? I'm not too sure
MSR 150 is where
On Wed, Apr 17, 2019 at 06:42:47PM +0100, Julien Grall wrote:
> Hi,
>
> @Wei, @Ian: Do you have any input?
Sorry I haven't been following this closely, but shouldn't we fix the
interface to return gfn instead? And then the mapping of it should
interpret the value properly per guest type.
I
This branch is supposed to be suitable for all versions of Xen.
Conversely, older versions of OVMF do not build on newer compilers (as
provided, eg, in stretch).
So, for "branches" other than xen-unstable and xen-unstable-smoke, use
the usual "determine_version" machinery, which will select
Hi Julien
On Thu, 2019-04-18 at 11:43 +0100, Julien Grall wrote:
> On 18/04/2019 10:15, Artem Mygaiev wrote:
> > Hello Julien, Stefano
>
> Hi Artem,
>
> > On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 16/04/2019 23:43, Stefano Stabellini wrote:
> > > > On Fri,
Hi,
On 27/03/2019 18:45, Julien Grall wrote:
Hi,
I have applied the follow patches to my branch next-4.13. I will merge it to
unstable on the commit moratorium is lifted.
xen/arm: zynqmp: Fix header guard for xilinx-zynqmp-eemi.h
xen/arm64: sysreg: Implement the 32-bit helpers using
On 18/04/2019 10:19, Dylanger Daly wrote:
> No worries Andrew, it was my first patch, thank you for the response.
>
> It's based on Xen 4.8
>
> Dom0 should be controlling it, but I wasn't aware of the Security
> implications.
>
> The scope isn't well documented:
>
flight 134945 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
flight 84022 distros-debian-wheezy real [real]
http://osstest.xensource.com/osstest/logs/84022/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 18/04/2019 10:15, Artem Mygaiev wrote:
Hello Julien, Stefano
Hi Artem,
On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
Hi,
On 16/04/2019 23:43, Stefano Stabellini wrote:
On Fri, 29 Mar 2019, Julien Grall wrote:
On 28/03/2019 11:27, Artem Mygaiev wrote:
Hi Julien,
Hi Artem,
No worries Andrew, it was my first patch, thank you for the response.
It's based on Xen 4.8
Dom0 should be controlling it, but I wasn't aware of the Security
implications.
The scope isn't well documented:
https://ressman.org/posts/2018-06-26-voltage-temperature-tdp-thinkpad/
More experimental
Giving Laptop Users the ability to Undervolt and change Temp Throttle Limits.
Signed-off-by: Dylanger Daly
---
xen/arch/x86/traps.c| 8
xen/include/asm-x86/msr-index.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index
flight 134940 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134889
build-i386-pvops
On 4/17/19 7:22 PM, Tamas K Lengyel wrote:
> On Wed, Apr 17, 2019 at 1:15 AM Alexandru Stefan ISAILA
> wrote:
>>
>>
>>
>> On 16.04.2019 18:07, George Dunlap wrote:
>>> On 4/16/19 3:19 PM, Tamas K Lengyel wrote:
On Tue, Apr 16, 2019 at 8:02 AM George Dunlap
wrote:
>
> On
Hello Julien, Stefano
On Wed, 2019-04-17 at 10:42 +0100, Julien Grall wrote:
> Hi,
>
> On 16/04/2019 23:43, Stefano Stabellini wrote:
> > On Fri, 29 Mar 2019, Julien Grall wrote:
> > > On 28/03/2019 11:27, Artem Mygaiev wrote:
> > > > Hi Julien,
> > >
> > > Hi Artem,
> > >
> > > > On Wed,
On Thu, Apr 18, 2019 at 10:15:05AM +0800, Pu Wen wrote:
> On 2019/4/17 23:04, Wei Liu wrote:
> > On Sat, Apr 13, 2019 at 12:14:14AM +0800, Pu Wen wrote:
> > > On 2019/4/5 15:50, Jan Beulich wrote:
> > > > On 04.04.19 at 18:39, wrote:
> > > > > On 2019/4/4 22:07, Andrew Cooper wrote:
> > > > > >
On 18/04/2019 09:56, Dylanger Daly wrote:
> Giving Laptop Users the ability to Undervolt and change Temp Throttle Limits.
>
> Signed-off-by: Dylanger Daly
Thankyou for the patch. Which version of Xen is it against? It is
fairly old, given that the function you patch has now moved to
flight 134810 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134810/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow 12 guest-start fail REGR. vs. 134623
flight 134785 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134785/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134576
build-arm64-pvops
flight 134937 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
I'm currently investigating a problem related to swiotlb-xen. With a
specific driver a customer is capable to trigger a situation where a
MFN is mapped to multiple dom0 PFNs at the same time. There is no
guest involved, so this is not related to grants.
Wit a debug kernel I have managed to track
flight 134793 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846
build-arm64-libvirt
flight 134935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/134935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 21 leak-check/check fail REGR. vs. 134889
91 matches
Mail list logo
