> On 5 Aug 2022, at 18:35, Julien Grall wrote:
>
> Hi Luca,
>
> On 05/08/2022 14:08, Luca Fancellu wrote:
>> The function arch_set_info_guest is not reached anymore through
>> VCPUOP_initialise on arm, update the comment.
>> Signed-off-by: Luca Fancellu
>> ---
>> Changes in v2:
>> - rephras
On 21.08.22 23:41, Borislav Petkov wrote:
On Sun, Aug 21, 2022 at 02:25:59PM +0200, Borislav Petkov wrote:
Fix that by using percpu variables for saving the MSR contents.
Cc: sta...@vger.kernel.org
Signed-off-by: Juergen Gross
---
I thought adding a "Fixes:" tag for the kernel's initial git co
flight 172693 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172693/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172697 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172697/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
Current NUMA nodes number is a hardcode configuration. This
configuration is difficult for an administrator to change
unless changing the code.
So in this patch, we introduce this new Kconfig option for
administrators to change NUMA nodes number conveniently.
Also considering that not all architec
x86 has implemented a set of codes to scan NUMA nodes. These
codes will parse NUMA memory and processor information from
ACPI SRAT table. But except some ACPI specific codes, most
of the scan codes like memory blocks validation, node memory
range updates and some sanity check can be reused by other
There are some codes in x86/numa.c can be shared by common
architectures to implememnt NUMA support. Just like some
variables and functions to check and store NUMA memory map.
And some variables and functions to do NUMA initialization.
In this patch, we move them to common/numa.c and xen/numa.h
an
The sanity check of nodes_cover_memory is also a requirement of
other architectures that support NUMA. But now, the code of
nodes_cover_memory is tied to the x86 E820. In this case, we
introduce arch_get_ram_range to decouple architecture specific
memory map from this function. This means, other ar
(The Arm device tree based NUMA support patch set contains 35
patches. In order to make stuff easier for reviewers, I split
them into 3 parts:
1. Preparation. I have re-sorted the patch series. And moved
independent patches to the head of the series - merged in [1]
2. Move generically usable cod
acpi_numa is a specific NUMA switch for ACPI NUMA implementation.
Other NUMA implementation may not need this switch. But this switch is
not only used by ACPI code, it is also used directly in some general
NUMA logic code. So far this hasn't caused any problem because Xen only
has x86 implementing
VIRTUAL_BUG_ON is an empty macro used in phys_to_nid. This
results in two lines of error-checking code in phys_to_nid
that is not actually working and causing two compilation
errors:
1. error: "MAX_NUMNODES" undeclared (first use in this function).
This is because in the common header file, "MAX
flight 172691 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172691/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
Hi,
This email is sent to discuss the possible Release Candidates (RCs) for
Xen 4.17 release. We are still 1+ month away from where they start but
we can start early to gather opinions from all stakeholders.
I checked the RC schedule when Xen 4.16 was released. The RCs were prepared
after the Cod
flight 172694 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172694/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172688 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172688/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172692 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Sun, Aug 21, 2022 at 02:25:59PM +0200, Borislav Petkov wrote:
> > Fix that by using percpu variables for saving the MSR contents.
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Juergen Gross
> > ---
> > I thought adding a "Fixes:" tag for the kernel's initial git commit
> > would maybe
flight 172686 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172686/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172690 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172690/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172684 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172684/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172133
build-amd64-libvirt
On Sat, Oct 09, 2021 at 06:28:17PM +0200, Marek Marczykowski-Górecki wrote:
> On Sun, Jan 31, 2021 at 03:15:30AM +0100, Marek Marczykowski-Górecki wrote:
> > On Tue, Sep 29, 2020 at 05:27:48PM +0200, Jürgen Groß wrote:
> > > On 29.09.20 17:16, Marek Marczykowski-Górecki wrote:
> > > > On Tue, Sep 2
flight 172687 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172687/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172680 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172128
build-amd64-libvirt
flight 172685 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172685/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
On Sat, Aug 20, 2022 at 11:25:24AM +0200, Juergen Gross wrote:
> When booting or resuming the system MTRR state is saved on the boot
> processor and then this state is loaded into MTRRs of all other cpus.
s/cpu/CPU/g
Pls check all commit messages.
> During update of the MTRRs the MTRR mechanism
flight 172679 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172679/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-raw 1 buil
flight 172677 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172677/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 172123
build-i386-libvir
flight 172682 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172682/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 172136
build-amd64-libvirt
flight 172683 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172683/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
29 matches
Mail list logo
