On 15.02.2023 19:54, Andrew Cooper wrote:
> On 09/02/2023 10:38 am, Jan Beulich wrote:
>> Have these in one place, for all architectures to use. Also use the C99
>> types as the "original" ones, and derive the Linux compatible ones
>> (which we're trying to phase out). For __s, seeing that no uses
On 15.02.2023 19:41, Andrew Cooper wrote:
> On 15/02/2023 3:10 pm, Jan Beulich wrote:
>> Besides a printk() the main effect is slight corruption of the start
>> info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
>> up as xen-3.0-x86_64p.
>>
>> Fixes: 460060f83d41 ("libelf: use
On 16.02.2023 00:22, Boris Ostrovsky wrote:
>
> On 2/15/23 3:31 AM, Jan Beulich wrote:
>> On 15.02.2023 01:07, Boris Ostrovsky wrote:
>>> On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
> --- a/arch/x86/kernel/cpu/bugs.c
> +++
On 15.02.2023 18:59, Oleksii wrote:
> Hello Jan and community,
>
> I experimented and switched RISC-V to x86 implementation. All that I
> changed in x86 implementation for RISC-V was _ASM_BUGFRAME_TEXT. Other
> things are the same as for x86.
>
> For RISC-V it is fine to skip '%c' modifier so
On 15.02.23 12:27, Jan Beulich wrote:
Both the 4Gb-segments and the PAE-extended-CR3 one are applicable to
32-bit guests only. The PAE-extended-CR3 use, furthermore, was redundant
with the PAE_MODE ELF note anyway.
Signed-off-by: Jan Beulich
Reviewed-by: Juergen Gross
Juergen
On 16.02.23 00:22, Linus Torvalds wrote:
On Wed, Feb 15, 2023 at 12:25 AM Juergen Gross wrote:
The problem arises in case a large mapping is spanning multiple MTRRs,
even if they define the same caching type (uniform is set to 0 in this
case).
Oh, I think then you should fix uniform to be
> From: Xenia Ragiadakou
> Sent: Monday, February 13, 2023 7:50 PM
>
> APIC virtualization support is currently implemented only for Intel VT-x.
> To aid future work on separating AMD-V from Intel VT-x code, instead of
> calling directly vmx_vlapic_msr_changed() from common hvm code, add a
>
flight 177405 xen-4.16-testing real [real]
flight 177446 xen-4.16-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/177405/
http://logs.test-lab.xenproject.org/osstest/logs/177446/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 177400 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177400/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 177298
test-amd64-amd64-xl-qemuu-win7-amd64
On 14/02/2023 3:38 pm, Michal Orzel wrote:
> diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
> index f8e156e0a994..079e9b73f659 100644
> --- a/automation/gitlab-ci/build.yaml
> +++ b/automation/gitlab-ci/build.yaml
> @@ -565,6 +565,26 @@
Since commit ee6d3dd4ed48 ("driver core: make kobj_type constant.")
the driver core allows the usage of const struct kobj_type.
Take advantage of this to constify the structure definition to prevent
modification at runtime.
Signed-off-by: Thomas Weißschuh
---
drivers/xen/sys-hypervisor.c | 2
flight 177433 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177433/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, 15 Feb 2023, Andrew Cooper wrote:
> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> > While the Let's Encrypt root certificate ISRG_Root_X1.crt is already
> > present, openssl seems to still check for the root certificate
> > DST_Root_CA_X3.crt which has expired. This prevent https
On Wed, 15 Feb 2023, Andrew Cooper wrote:
> On 15/02/2023 4:31 pm, Andrew Cooper wrote:
> > On 15/02/2023 4:28 pm, Anthony PERARD wrote:
> >> On Wed, Feb 15, 2023 at 12:26:40PM +, Andrew Cooper wrote:
> >>> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> First, apt complain that it isn't
Hi Julien and all,
Summarizing here on the list what I had with Julien and Bertrand this
morning.
On Wed, 15 Feb 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 14/02/2023 22:25, Stefano Stabellini wrote:
> > > Patch 1's example has a "comment" field, which no entry makes use of.
> > > Without
On Wed, Feb 15, 2023 at 12:25 AM Juergen Gross wrote:
>
> The problem arises in case a large mapping is spanning multiple MTRRs,
> even if they define the same caching type (uniform is set to 0 in this
> case).
Oh, I think then you should fix uniform to be 1.
IOW, we should not think "multiple
On 2/15/23 3:31 AM, Jan Beulich wrote:
On 15.02.2023 01:07, Boris Ostrovsky wrote:
On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
On 2/14/23 11:13 AM, Jan Beulich wrote:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -18,6 +18,8 @@
#include
#include
+#include
From: Stefano Stabellini
Copy the build output of Yocto builds to binaries/ for the arm32 target,
and export binaries/ among the jobs artifacts so that they can be reused
by other jobs.
Signed-off-by: Stefano Stabellini
---
Changes in v2:
- only copy binaries for the arm32 target
---
From: Stefano Stabellini
As part of the arm32 dom0 test, also create a simple domU using xl. To
do that, we need the toolstack installed in the dom0 rootfs. We switch
to using the kernel and rootfs built by the Yocto arm32 job.
Remove the PCI node from the host device tree: it is unused but
From: Stefano Stabellini
We are going to use artifacts produced by the Yocto builds in test jobs.
Signed-off-by: Stefano Stabellini
---
automation/gitlab-ci/build.yaml | 51 +
automation/gitlab-ci/test.yaml | 45 -
2 files changed,
Hi all,
This patch series add a domU creation test based on xl for arm32. To do
that, it reuses the existing arm32 dom0 test, and also reuses the Yocto
qemuarm build output.
Pipeline (with reduced amount of jobs):
https://gitlab.com/xen-project/people/sstabellini/xen/-/pipelines/779022452
flight 177376 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177376/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-raw 7 xen-install fail in 177312 pass in 177376
On Wed, Feb 15, 2023 at 10:09 AM Jan Beulich wrote:
>
> Both values are unconditionally overridden (to 0) in the "hvm" (i.e.
> PVH) case. There's therefore no reason to punish a PVH kernel for
> setting the former but not the latter.
>
> Fixes: 632cbaf1243e ("libelf: improve PVH elfnote parsing")
On 09/02/2023 10:39 am, Jan Beulich wrote:
> Consolidate cper.h to use exclusively standard types.
>
> No functional change intended.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 09/02/2023 10:38 am, Jan Beulich wrote:
> Have these in one place, for all architectures to use. Also use the C99
> types as the "original" ones, and derive the Linux compatible ones
> (which we're trying to phase out). For __s, seeing that no uses exist
> anymore, move them to a new Linux
On 15/02/2023 3:10 pm, Jan Beulich wrote:
> Besides a printk() the main effect is slight corruption of the start
> info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
> up as xen-3.0-x86_64p.
>
> Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder")
> Signed-off-by: Jan
On 15/02/2023 4:31 pm, Andrew Cooper wrote:
> On 15/02/2023 4:28 pm, Anthony PERARD wrote:
>> On Wed, Feb 15, 2023 at 12:26:40PM +, Andrew Cooper wrote:
>>> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
First, apt complain that it isn't the right way to add keys anymore,
but
On Wed, Feb 15, 2023 at 4:50 AM Jan Beulich wrote:
>
> On 14.02.2023 20:04, Jason Andryuk wrote:
> > Qubes recently incorporated my HWP patches, but there was a report of
> > a laptop, Thinkpad X1 Carbon Gen 4 with a Skylake processor, locking
> > up during boot when HWP is enabled. A user found
Hello Jan and community,
I experimented and switched RISC-V to x86 implementation. All that I
changed in x86 implementation for RISC-V was _ASM_BUGFRAME_TEXT. Other
things are the same as for x86.
For RISC-V it is fine to skip '%c' modifier so _ASM_BUGFRAME_TEXT will
look like:
#define
On Wed, Feb 15, 2023 at 04:30:43PM +0100, Jan Beulich wrote:
> On 15.02.2023 16:21, Anthony PERARD wrote:
> > @@ -13,6 +14,10 @@ MAJOR := $(shell $(XEN_ROOT)/version.sh
> > $(XEN_ROOT)/xen/Makefile)
> > endif
> > MINOR ?= 0
> >
> > +ifeq ($(origin version-script), undefined)
> >
flight 177402 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177402/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Philippe Mathieu-Daudé writes:
> Unused since introduction in commit 04b0de0ee8
> ("xen: factor out common functions").
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Alex Bennée
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
An assert failure has been observed in p2m_teardown when performing vm
forking and then destroying the forked VM (p2m-basic.c:173). The assert
checks whether the domain's shared pages counter is 0. According to the
patch that originally added the assert (7bedbbb5c31) the p2m_teardown
should only
On Wed, Feb 15, 2023 at 6:03 AM Jan Beulich wrote:
>
> On 14.02.2023 06:07, Tamas K Lengyel wrote:
> > When VM forking is initiated a VM is not supposed to try to perform
mem_sharing
> > yet as the fork process hasn't completed all required steps. However,
the vCPU
> > bring-up paths trigger
flight 177347 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177347/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-amd64-i386-libvirt-xsm 15
On 15/02/2023 4:28 pm, Anthony PERARD wrote:
> On Wed, Feb 15, 2023 at 12:26:40PM +, Andrew Cooper wrote:
>> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
>>> First, apt complain that it isn't the right way to add keys anymore,
>>> but hopefully that's just a warning.
>>>
>>> Second, we can't
On Wed, Feb 15, 2023 at 5:27 AM Jan Beulich wrote:
>
> On 14.02.2023 06:07, Tamas K Lengyel wrote:
> > An assert failure has been observed at p2m-basic.c:173 when performing
vm
>
> Please can you at least also name the function here? The line number is
> going to change, and when coming back to
On Wed, Feb 15, 2023 at 12:26:40PM +, Andrew Cooper wrote:
> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> > First, apt complain that it isn't the right way to add keys anymore,
> > but hopefully that's just a warning.
> >
> > Second, we can't install clang-8:
> > The following packages have
On Wed, Feb 15, 2023 at 12:36:30PM +, Andrew Cooper wrote:
> On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> > We can't easily install package on Debian Jessie anymore, the release
> > keys seems to have expired without a way to get new ones. We have
> > these warning:
> > W: GPG error:
flight 177333 linux-linus real [real]
flight 177395 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/177333/
http://logs.test-lab.xenproject.org/osstest/logs/177395/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 15/02/2023 3:21 pm, Anthony PERARD wrote:
> Unfortunatly, --default-symver doesn't work on FreeBSD 12, with LLVM's
> LD. Instead, we will generate a temporary version-script.
It was all builds, not just FreeBSD 12, and not really FreeBSD either.
LLD simply doesn't understand the
Currently late ucode loading is performed only on the first core of CPU
siblings. But according to the latest recommendation from AMD, late
ucode loading should happen on every logical thread/core.
To achieve that, consider every logical cpu as "primary" when running on
AMD cpus, i.e. skip
I've added a second patch to cover late loading as that should also
happen on every cpu, according to AMD.
Sergey Dyasli (2):
x86/ucode/AMD: apply the patch early on every logical thread
x86/ucode/AMD: late load the patch on every logical thread
xen/arch/x86/cpu/microcode/amd.c | 11
The original issue has been reported on AMD Bulldozer-based CPUs where
ucode loading loses the LWP feature bit in order to gain the IBPB bit.
LWP disabling is per-SMT/CMT core modification and needs to happen on
each sibling thread despite the shared microcode engine. Otherwise,
logical CPUs will
Unused since introduction in commit 04b0de0ee8
("xen: factor out common functions").
Signed-off-by: Philippe Mathieu-Daudé
---
accel/xen/xen-all.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/accel/xen/xen-all.c b/accel/xen/xen-all.c
index 69aa7d018b..c1b697a8bd 100644
---
On 15.02.2023 16:21, Anthony PERARD wrote:
> @@ -13,6 +14,10 @@ MAJOR := $(shell $(XEN_ROOT)/version.sh
> $(XEN_ROOT)/xen/Makefile)
> endif
> MINOR ?= 0
>
> +ifeq ($(origin version-script), undefined)
> +version-script := libxen$(LIBNAME).map.tmp
> +endif
Such a use of $(origin ...) is
Unfortunatly, --default-symver doesn't work on FreeBSD 12, with LLVM's
LD. Instead, we will generate a temporary version-script.
In order to allow regenerating the script, we'll have a different
filename. In order to check if the content is up-to-date, we'll always
generated it and compare.
On 03.10.2022 18:21, Marek Marczykowski-Górecki wrote:
> Documentation for credit2_runqueue=all says it should create one queue
> for all pCPUs on the host. But since introduction
> sched_credit2_max_cpus_runqueue, it actually created separate runqueue
> per socket, even if the CPUs count is below
Besides a printk() the main effect is slight corruption of the start
info magic: While that's meant to be xen-3.0-x86_64, it wrongly ended
up as xen-3.0-x86_64p.
Fixes: 460060f83d41 ("libelf: use for x86 dom0 builder")
Signed-off-by: Jan Beulich
---
RFC: While Linux works fine with the
Both values are unconditionally overridden (to 0) in the "hvm" (i.e.
PVH) case. There's therefore no reason to punish a PVH kernel for
setting the former but not the latter.
Fixes: 632cbaf1243e ("libelf: improve PVH elfnote parsing")
Signed-off-by: Jan Beulich
---
On Tue, 2023-02-14 at 17:55 +0100, Jan Beulich wrote:
> On 14.02.2023 17:22, Oleksii wrote:
> > On Mon, 2023-02-13 at 13:24 +0100, Jan Beulich wrote:
> > > On 03.02.2023 18:05, Oleksii Kurochko wrote:
> > > > --- a/xen/common/Kconfig
> > > > +++ b/xen/common/Kconfig
> > > > @@ -92,6 +92,12 @@
flight 177386 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177386/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 38da9606f77842cdcdc231210c0369a6180c51a0
baseline version:
ovmf
While the PAE-extended-CR3 VM assist is a 32-bit only concept, it still
applies to guests also when run on a 64-bit hypervisor: The "extended
CR3" format has to be used there as well, to fit the address in the only
32-bit wide register there. As a result it was a mistake that the check
was never
On 09/02/2023 10:38 am, Jan Beulich wrote:
> This is the only file left with a use of an __s type coming from
> Linux. Since the file has been using an apparently random mix of all
> three classes of fixed-width types (__{s,u}, {s,u}, and
> {,u}int_t), consolidate this to use exclusively standard
On 08/02/2023 6:04 pm, Ross Lagerwall wrote:
> Certain debug sections like ".debug_aranges" when built with GCC 11.2.1
> are missing section symbols (presumably because they're not needed).
> Instead, of segfaulting, simply don't include them if they're missing.
>
> Signed-off-by: Ross Lagerwall
On 15/02/2023 1:36 pm, Jan Beulich wrote:
> On 15.02.2023 14:25, Andrew Cooper wrote:
>> MOD_START_PFN is PV only. It's not applicable for HVM/PVH.
> It isn't right now, yes. I continue to be uncertain and would
> prefer to leave it as is.
Its the wrong address space to be applicable to HVM/PVH.
On 15.02.2023 14:25, Andrew Cooper wrote:
> On 15/02/2023 1:12 pm, Juergen Gross wrote:
>> On 15.02.23 13:42, Jan Beulich wrote:
>>> On 15.02.2023 13:05, Juergen Gross wrote:
On 15.02.23 12:33, Jan Beulich wrote:
> -#endif
> #ifdef CONFIG_XEN_PV
> ELFNOTE(Xen,
On 15/02/2023 1:12 pm, Juergen Gross wrote:
> On 15.02.23 13:42, Jan Beulich wrote:
>> On 15.02.2023 13:05, Juergen Gross wrote:
>>> On 15.02.23 12:33, Jan Beulich wrote:
First of all drop 32-bit leftovers, including the inclusion of the
file
from head_32.S.
>>>
>>> I don't see why
On 15.02.23 13:42, Jan Beulich wrote:
On 15.02.2023 13:05, Juergen Gross wrote:
On 15.02.23 12:33, Jan Beulich wrote:
First of all drop 32-bit leftovers, including the inclusion of the file
from head_32.S.
I don't see why we would want to drop 32-bit HVM and PVH support.
HVM doesn't use
On 15.02.2023 13:05, Juergen Gross wrote:
> On 15.02.23 12:33, Jan Beulich wrote:
>> First of all drop 32-bit leftovers, including the inclusion of the file
>> from head_32.S.
>
> I don't see why we would want to drop 32-bit HVM and PVH support.
HVM doesn't use this, does it? But yes, the PVH
On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> While the Let's Encrypt root certificate ISRG_Root_X1.crt is already
> present, openssl seems to still check for the root certificate
> DST_Root_CA_X3.crt which has expired. This prevent https connections.
>
> Removing DST_Root_CA_X3 fix the issue.
>
On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> We can't easily install package on Debian Jessie anymore, the release
> keys seems to have expired without a way to get new ones. We have
> these warning:
> W: GPG error: http://deb.debian.org jessie-updates InRelease: The
> following signatures
On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> Signed-off-by: Anthony PERARD
Acked-by: Andrew Cooper
On 15/02/2023 12:02 pm, Anthony PERARD wrote:
> First, apt complain that it isn't the right way to add keys anymore,
> but hopefully that's just a warning.
>
> Second, we can't install clang-8:
> The following packages have unmet dependencies:
> clang-8 : Depends: libstdc++-8-dev but it is not
While the Let's Encrypt root certificate ISRG_Root_X1.crt is already
present, openssl seems to still check for the root certificate
DST_Root_CA_X3.crt which has expired. This prevent https connections.
Removing DST_Root_CA_X3 fix the issue.
centos: found the filter by looking for "DST Root" in
Signed-off-by: Anthony PERARD
---
automation/scripts/containerize | 3 +++
1 file changed, 3 insertions(+)
diff --git a/automation/scripts/containerize b/automation/scripts/containerize
index 9e508918bf..9b1a302d05 100755
--- a/automation/scripts/containerize
+++
We can't easily install package on Debian Jessie anymore, the release
keys seems to have expired without a way to get new ones. We have
these warning:
W: GPG error: http://deb.debian.org jessie-updates InRelease: The following
signatures were invalid: KEYEXPIRED 1668891673
W: GPG error:
On 15.02.23 12:33, Jan Beulich wrote:
First of all drop 32-bit leftovers, including the inclusion of the file
from head_32.S.
I don't see why we would want to drop 32-bit HVM and PVH support.
Then further move PV-only ELF notes inside the XEN_PV
conditional. Finally have the "supported
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.gitlab-containers-update-v1
There is work in progress [1] to update urls in our repo to use https, but
those https urls to xenbits don't work in our containers, due to an expired
root
First, apt complain that it isn't the right way to add keys anymore,
but hopefully that's just a warning.
Second, we can't install clang-8:
The following packages have unmet dependencies:
clang-8 : Depends: libstdc++-8-dev but it is not installable
Depends: libgcc-8-dev but it is not
First of all drop 32-bit leftovers, including the inclusion of the file
from head_32.S. Then further move PV-only ELF notes inside the XEN_PV
conditional. Finally have the "supported features" note actually report
reality: All three of the features are supported and/or applicable only
in certain
Both the 4Gb-segments and the PAE-extended-CR3 one are applicable to
32-bit guests only. The PAE-extended-CR3 use, furthermore, was redundant
with the PAE_MODE ELF note anyway.
Signed-off-by: Jan Beulich
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -934,12 +934,8 @@ void
On 31.08.2022 16:10, Volodymyr Babchuk wrote:
> --- /dev/null
> +++ b/xen/include/xen/refcnt.h
> @@ -0,0 +1,28 @@
> +#ifndef __XEN_REFCNT_H__
> +#define __XEN_REFCNT_H__
> +
> +#include
> +
> +typedef atomic_t refcnt_t;
Like Linux has it, I think this would better be a separate struct. At
least
On 14.02.2023 06:07, Tamas K Lengyel wrote:
> When VM forking is initiated a VM is not supposed to try to perform
> mem_sharing
> yet as the fork process hasn't completed all required steps. However, the vCPU
> bring-up paths trigger guest memory accesses that can lead to such premature
> sharing
flight 177312 xen-unstable real [real]
flight 177369 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/177312/
http://logs.test-lab.xenproject.org/osstest/logs/177369/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 14.02.2023 06:07, Tamas K Lengyel wrote:
> An assert failure has been observed at p2m-basic.c:173 when performing vm
Please can you at least also name the function here? The line number is
going to change, and when coming back to this change later, it'll be
more troublesome to figure out which
> From: Jan Beulich
> Sent: Wednesday, February 15, 2023 9:55 AM
> To: Ross Lagerwall
> Cc: Andrew Cooper ; George Dunlap
> ; Julien Grall ; Stefano Stabellini
> ; Wei Liu ; Anthony Perard
> ; xen-devel@lists.xenproject.org
>
> Subject: Re: [PATCH v2] build: Make FILE symbol paths
On 13.02.2023 17:55, Ross Lagerwall wrote:
> The FILE symbols in out-of-tree builds may be either a relative path to
> the object dir or an absolute path depending on how the build is
> invoked. Fix the paths for C files so that they are consistent with
> in-tree builds - the path is relative to
On 14.02.2023 20:04, Jason Andryuk wrote:
> Qubes recently incorporated my HWP patches, but there was a report of
> a laptop, Thinkpad X1 Carbon Gen 4 with a Skylake processor, locking
> up during boot when HWP is enabled. A user found a kernel bug that
> seems to be the same issue:
>
flight 177365 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177365/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 77d6772708541a2ddf093af79816dd1831581388
baseline version:
ovmf
On 15.02.2023 00:38, Volodymyr Babchuk wrote:
> Stefano Stabellini writes:
>> On Wed, 31 Aug 2022, Volodymyr Babchuk wrote:
>> 1) iommu.c:reassign_device_ownership and pci_amd_iommu.c:reassign_device
>> Both functions without any pdevs_lock locking do:
>> list_move(>domain_list, >pdev_list);
>>
Hi Stefano,
On 14/02/2023 22:25, Stefano Stabellini wrote:
Patch 1's example has a "comment" field, which no entry makes use of.
Without that, how does it become clear _why_ a particular file is to
be excluded? The patch description here also doesn't provide any
justification ...
It would be
On 15.02.2023 01:07, Boris Ostrovsky wrote:
>
> On 2/14/23 6:53 PM, Boris Ostrovsky wrote:
>>
>> On 2/14/23 11:13 AM, Jan Beulich wrote:
>>
>>> --- a/arch/x86/kernel/cpu/bugs.c
>>> +++ b/arch/x86/kernel/cpu/bugs.c
>>> @@ -18,6 +18,8 @@
>>> #include
>>> #include
>>> +#include
>>> +
>>>
On 13.02.23 19:21, Edgecombe, Rick P wrote:
On Mon, 2023-02-13 at 07:12 +0100, Juergen Gross wrote:
Thanks for the report.
I'll have a look. Probably I'll need to re-add the check for WB in
patch 7.
Sure, let me know if you need any more details about by setup.
I have reproduced the
flight 177356 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/177356/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 68c1bedbf297b57a336a2edc046f1f9874ba69fa
baseline version:
ovmf
85 matches
Mail list logo
