flight 162169 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162169/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 159942
test-amd64-amd64-qemuu-nested-amd 20
On 26.05.2021 17:21, Jan Beulich wrote:
> On 03.05.2021 21:28, Jason Andryuk wrote:
>> --- a/tools/misc/xenpm.c
>> +++ b/tools/misc/xenpm.c
>> @@ -711,6 +711,7 @@ void start_gather_func(int argc, char *argv[])
>> /* print out parameters about cpu frequency */
>> static void
flight 162167 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162167/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
LPC and LF have issued an RFQ that includes upstream usability enhancements for
BBB and integration with Matrix chat.
Some feature gaps (page 7, HTML5 client) may be familiar to Xen Summit
participants. If Xen Summit has additional enhancement requests for 2022, these
could be coordinated
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-freebsd12-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 162164 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162164/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
162156 pass in 162164
> > You mean its availability should be checked both at build and runtime?
>
> Correct. You can have a libc suporting getrandom() but a kernel that doesn't
> provide the syscall.
>
Agree, I shall check this.
-Sergiy
> Ok. Can the reasoning be documented in the commit message (with a short
> summary in the code)? This would be helpful if in the future one decide to
> change the size of the seed.
>
Sure, I'll do that.
-Sergiy
On 5/26/21 10:10 AM, YueHaibing wrote:
> Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR(),
> which makes the code a bit shorter and easier to read.
>
> Signed-off-by: YueHaibing
Reviewed-by: Boris Ostrovsky
flight 162171 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162171/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 5/26/21 12:40 AM, Anchal Agarwal wrote:
> On Tue, May 25, 2021 at 06:23:35PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe.
>>
>>
On Wed, May 19, 2021 at 11:40 AM Jan Beulich wrote:
>
> Gcc 11 looks to make incorrect assumptions about valid ranges that
> pointers may be used for addressing when they are derived from e.g. a
> plain constant. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680.
>
> Utilize RELOC_HIDE() to
Hi,
Regarding our chat few minutes ago - this is part of the .gitlab-ci.yml,
that builds and pushed containers, that is later used for other tests:
variables:
CONTAINER_TEST_IMAGE: ...
build:
stage: build
image: docker/compose:latest
services:
-
On Wed, May 26, 2021 at 11:09 AM Jan Beulich wrote:
>
> On 26.05.2021 16:12, Jason Andryuk wrote:
> > On Wed, May 26, 2021 at 9:18 AM Jan Beulich wrote:
> >> Sorry, all quite nit-like remarks, but still ...
> >
> > It's fine. Would a design session be useful to discuss hwp?
>
> Is there
On 26/05/2021 10:28, Sergiy Kibrik wrote:
Hi Julien,
Hi Sergiy,
diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c index
34f8a29056..05c58a428c 100644
--- a/tools/libxl/libxl_arm.c
+++ b/tools/libxl/libxl_arm.c
@@ -342,6 +342,12 @@ static int make_chosen_node(libxl__gc *gc,
Hi,
On 26/05/2021 10:31, Sergiy Kibrik wrote:
Hi Julien,
From the man:
VERSIONS
getrandom() was introduced in version 3.17 of the Linux kernel.
Support was added to glibc in version 2.25.
If I am not mistaken glibc 2.25 was released in 2017. Also, the call was only
introduced
From: Julien Grall
Since commit 1aac966e24e9 "xen: support RAM at addresses 0 and 4096",
bits_to_zone() will never return 0 and it is expected that we have
minimum 2 zones.
Therefore the check in alloc_domheap_pages() is unnecessary and can
be removed. However, for sanity, it is replaced with
On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote:
> On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote:
> > @@ -138,4 +160,9 @@ one for multimedia processing (named
> > multimedia-memory@7700, 64MiB).
> > memory-region = <_reserved>;
> > /* ... */
flight 162160 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162160/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-install fail REGR. vs.
152332
On 03.05.2021 21:28, Jason Andryuk wrote:
> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -711,6 +711,7 @@ void start_gather_func(int argc, char *argv[])
> /* print out parameters about cpu frequency */
> static void print_cpufreq_para(int cpuid, struct xc_get_cpufreq_para
>
On 18/05/2021 15:01, Julien Grall wrote:
From: Julien Grall
Hi all,
By default, both Clang and GCC will happily compile C code where
non-const char * point to literal strings. This means the following
code will be accepted:
char *str = "test";
str[0] = 'a';
Literal strings
From: Julien Grall
Since XSA-288 (commit 02cbeeb62075 "gnttab: split maptrack lock to make
it fulfill its purpose again"), v->maptrack_head and v->maptrack_tail
are with the lock v->maptrack_freelist_lock held.
Therefore it is not necessary to update the fields using cmpxchg()
and also read
On 26.05.2021 16:44, Jason Andryuk wrote:
> On Wed, May 26, 2021 at 9:27 AM Jan Beulich wrote:
>> On 03.05.2021 21:28, Jason Andryuk wrote:
>>> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
>>> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
>>> @@ -340,7 +340,7 @@ static unsigned int
On 26.05.2021 16:12, Jason Andryuk wrote:
> On Wed, May 26, 2021 at 9:18 AM Jan Beulich wrote:
>> Sorry, all quite nit-like remarks, but still ...
>
> It's fine. Would a design session be useful to discuss hwp?
Is there anything beyond patch review that's necessary there? I'm
also not really
On 03.05.2021 21:28, Jason Andryuk wrote:
> If HWP Energy_Performance_Preference isn't supported, the code falls
> back to IA32_ENERGY_PERF_BIAS. Right now, we don't check
> CPUID.06H:ECX.SETBH[bit 3] before using that MSR.
May I ask what problem there is doing so?
> The SDM reads like
> it'll
On Wed, May 26, 2021 at 9:27 AM Jan Beulich wrote:
>
> On 03.05.2021 21:28, Jason Andryuk wrote:
> > Export feature_detect as intel_feature_detect so it can be re-used by
> > HWP.
> >
> > Signed-off-by: Jason Andryuk
>
> Acked-by: Jan Beulich
> albeit ...
>
> > ---
On Wed, May 26, 2021 at 9:24 AM Jan Beulich wrote:
>
> On 03.05.2021 21:27, Jason Andryuk wrote:
> > acpi-cpufreq scales the aperf/mperf measurements by max_freq, but HWP
> > needs to scale by base frequency. Settings max_freq to base_freq
> > "works" but the code is not obvious, and returning
On Wed, May 26, 2021 at 9:18 AM Jan Beulich wrote:
>
> On 03.05.2021 21:27, Jason Andryuk wrote:
> > For hwp, the standard governors are not usable, and only the internal
> > one is applicable.
>
> So you say "one" here but use plural in the subject. Which one is
> it (going to be)?
hwp only
Use DEVICE_ATTR_*() helper instead of plain DEVICE_ATTR(),
which makes the code a bit shorter and easier to read.
Signed-off-by: YueHaibing
---
drivers/xen/pcpu.c| 6 +++---
drivers/xen/xen-balloon.c | 28 +++-
drivers/xen/xenbus/xenbus_probe.c |
On 03.05.2021 21:28, Jason Andryuk wrote:
> Export feature_detect as intel_feature_detect so it can be re-used by
> HWP.
>
> Signed-off-by: Jason Andryuk
Acked-by: Jan Beulich
albeit ...
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -340,7 +340,7
On 03.05.2021 21:27, Jason Andryuk wrote:
> acpi-cpufreq scales the aperf/mperf measurements by max_freq, but HWP
> needs to scale by base frequency. Settings max_freq to base_freq
> "works" but the code is not obvious, and returning values to userspace
> is tricky. Add an additonal perf_freq
On 03.05.2021 21:27, Jason Andryuk wrote:
> For hwp, the standard governors are not usable, and only the internal
> one is applicable.
So you say "one" here but use plural in the subject. Which one is
it (going to be)?
> Add the cpufreq_governor_internal boolean to
> indicate when an internal
Sufficiently old Linux (3.12-ish) accesses these MSRs in an unguarded
manner. Furthermore these MSRs, at least on Fam11 and older CPUs, are
also consulted by modern Linux, and their (bogus) built-in zapping of
#GP faults from MSR accesses leads to it effectively reading zero
instead of the
flight 162158 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
Hi Claire,
On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote:
> Introduce the new compatible string, restricted-dma-pool, for restricted
> DMA. One can specify the address and length of the restricted DMA memory
> region by restricted-dma-pool in the reserved-memory node.
>
>
> On May 26, 2021, at 12:04 PM, Ian Jackson wrote:
>
> George Dunlap writes ("Re: IRC networks"):
>> Thanks, Ian. I tend to agree with the recommendation. I think unless
>> someone wants to argue that we go to libera (or stick with freenode), we
>> should go with that option.
>>
>>
flight 162161 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162161/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
George Dunlap writes ("Re: IRC networks"):
> Thanks, Ian. I tend to agree with the recommendation. I think unless
> someone wants to argue that we go to libera (or stick with freenode), we
> should go with that option.
>
> Normally for a decision like this we’d wait 2 weeks for
flight 162156 xen-unstable real [real]
flight 162162 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162156/
http://logs.test-lab.xenproject.org/osstest/logs/162162/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
Hi Julien,
>
> From the man:
>
> VERSIONS
> getrandom() was introduced in version 3.17 of the Linux kernel.
> Support was added to glibc in version 2.25.
>
> If I am not mistaken glibc 2.25 was released in 2017. Also, the call was only
> introduced in FreeBSD 12.
>
> So I think we
Hi Julien,
> > diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c index
> > 34f8a29056..05c58a428c 100644
> > --- a/tools/libxl/libxl_arm.c
> > +++ b/tools/libxl/libxl_arm.c
> > @@ -342,6 +342,12 @@ static int make_chosen_node(libxl__gc *gc, void
> *fdt, bool ramdisk,
> > if
The simple_strtoull() function is deprecated in some situation, since
it does not check for the range overflow, use kstrtoull() instead.
Signed-off-by: Chen Huang
---
drivers/xen/xen-balloon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xen-balloon.c
The simple_strtoull() function is deprecated in some situation since
it does not check for the range overflow, use kstrtoull() instead.
Signed-off-by: Chen Huang
---
fs/ocfs2/cluster/heartbeat.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
The simple_strtoull() function is deprecated in some situation, since
it does not check for the range overflow, use kstrtoull() instead.
Signed-off-by: Chen Huang
---
arch/powerpc/kernel/rtas-proc.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git
On 26.05.2021 10:27, Roger Pau Monné wrote:> It's also confusing that the
scheduler that gets set as the default> when shim exclusive is selected is not
available to enable/disable:> > [*] Credit scheduler support (NEW)> [*] Credit2
scheduler support (NEW)> Default Scheduler? (Null
On Wed, May 26, 2021 at 09:37:37AM +0200, Jan Beulich wrote:
> We shouldn't default to include any unsupported code in the shim. Mark
> the setting as off, replacing the ARGO specification. This points out
> anomalies with the scheduler configuration: Unsupported schedulers
> better don't default
IOMMU: make DMA containment of quarantined devices optional
Containing still in flight DMA was introduced to work around certain
devices / systems hanging hard upon hitting a "not-present" IOMMU fault.
Passing through (such) devices (on such systems) is inherently insecure
(as guests could easily
We shouldn't default to include any unsupported code in the shim. Mark
the setting as off, replacing the ARGO specification. This points out
anomalies with the scheduler configuration: Unsupported schedulers
better don't default to Y in release builds (like is already the case
for ARINC653).
flight 162159 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162159/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-armhf-libvirt
49 matches
Mail list logo
