flight 172675 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172675/
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
Hello,
Is it possible to install the Xen Hypervisor for just isolate my host OS and
disable its Virtualization features (Install guest OS)?
Thank you.
flight 172678 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172678/
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 172672 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172672/
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 172676 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172676/
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 172670 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172670/
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 172673 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172673/
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 172666 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172666/
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 Stefano,
On 19/08/2022 23:53, Stefano Stabellini wrote:
On Fri, 19 Aug 2022, Julien Grall wrote:
On 18/08/2022 23:03, Stefano Stabellini wrote:
Add SPDX license information to all the *.c files under arch/arm.
There are some of the files below that didn't have copyright. It would be
worth
flight 172671 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172671/
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
Hi Stefano,
On 19/08/2022 23:27, Stefano Stabellini wrote:
On Fri, 19 Aug 2022, Julien Grall wrote:
Hi Stefano,
On 18/08/2022 23:03, Stefano Stabellini wrote:
Add the individual licenses under a new top-level directory named
"LICENSES". Each license file includes its related SPDX tags.
We a
Hi Stefano,
On 19/08/2022 23:24, Stefano Stabellini wrote:
On Fri, 19 Aug 2022, Julien Grall wrote:
Hi Stefano,
On 18/08/2022 23:03, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
CODING_STYLE | 10 ++
1 file changed, 10 insertions(+)
diff --git a/CODING_STYLE
flight 172660 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172660/
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 172657 xen-unstable real [real]
flight 172669 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/172657/
http://logs.test-lab.xenproject.org/osstest/logs/172669/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Version: 6.0-rc1
Description:
In function 'privcmd_ioctl_dm_op' (drivers/xen/privcmd.c: 615)return
value of 'kcalloc' with GFP_KERNEL flag is assigned to "pages"
variable. GFP_KERNEL flag does not guarantee, that the return value
will not be NULL. In that case, there is a jump to the "out" label
flight 172668 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172668/
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 172658 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172658/
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 172664 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172664/
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 172661 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172661/
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
flight 172654 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172654/
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, 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.
> During update of the MTRRs the MTRR mechanism needs to be disabled by
> writing the related
flight 172662 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/172662/
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
Instead of having a stop_machine() handler for either a specific MTRR
register or all state at once, add a handler just for calling
cache_cpu_init() if appropriate.
Add functions for calling stop_machine() with this handler as well.
Add a generic replacements for mtrr_bp_restore() and a wrapper f
Prepare making PAT and MTRR support independent from each other by
moving some code needed by both out of the MTRR specific sources.
Signed-off-by: Juergen Gross
---
V2:
- move code from cpu/common.c to cpu/cacheinfo.c (Boris Petkov)
---
arch/x86/include/asm/cacheinfo.h | 3 ++
arch/x86/inclu
In order to prepare decoupling MTRR and PAT replace the MTRR specific
mtrr_aps_delayed_init flag with a more generic cache_aps_delayed_init
one.
Signed-off-by: Juergen Gross
---
V2:
- new patch
---
arch/x86/include/asm/cacheinfo.h | 2 ++
arch/x86/include/asm/mtrr.h | 2 --
arch/x86/kerne
Instead of using an indirect call to mtrr_if->set_all just call the
only possible target cache_cpu_init() directly. This enables to remove
the set_all callback from struct mtrr_ops.
Signed-off-by: Juergen Gross
---
arch/x86/kernel/cpu/mtrr/generic.c | 1 -
arch/x86/kernel/cpu/mtrr/mtrr.c| 1
Today PAT is usable only with MTRR being active, with some nasty tweaks
to make PAT usable when running as Xen PV guest, which doesn't support
MTRR.
The reason for this coupling is, that both, PAT MSR changes and MTRR
changes, require a similar sequence and so full PAT support was added
using the
The Cyrix cpu specific MTRR function cyrix_set_all() will never be
called, as the struct mtrr_ops set_all() callback will only be called
in the use_intel() case, which would require the use_intel_if member
of struct mtrr_ops to be set, which isn't the case for Cyrix.
Signed-off-by: Juergen Gross
In MTRR code use_intel() is only used in one source file, and the
relevant use_intel_if member of struct mtrr_ops is set only in
generic_mtrr_ops.
Replace use_intel() with a single flag in cacheinfo.c, which can be set
when assigning generic_mtrr_ops to mtrr_if. This allows to drop
use_intel_if fr
In case of the generic cache interface being used (Intel cpus or a
64-bit system), the initialization sequence of the boot cpu is more
complicated as necessary:
- check if MTRR enabled, if yes, call mtrr_bp_pat_init() which will
disable caching, set the PAT MSR, and reenable caching
- call mtrr
Split generic_set_all() into multiple parts, while moving the main
function body into cacheinfo.c.
This prepares the support of PAT without needing MTRR support by
moving the main function body of generic_set_all() into cacheinfo.c
while renaming it to cache_cpu_init(). The MTRR specific parts are
Today PAT can't be used without MTRR being available, unless MTRR is at
least configured via CONFIG_MTRR and the system is running as Xen PV
guest. In this case PAT is automatically available via the hypervisor,
but the PAT MSR can't be modified by the kernel and MTRR is disabled.
The same applies
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.
During update of the MTRRs the MTRR mechanism needs to be disabled by
writing the related MSR. The old contents of this MSR are saved in a
set of static variable
Hello,
I used to send out RFC v1 to introduce an extra io_tlb_mem (created with
SWIOTLB_ANY) in addition to the default io_tlb_mem (32-bit). The
dev->dma_io_tlb_mem is set to either default or the extra io_tlb_mem,
depending on dma mask. However, that is not good for setting
dev->dma_io_tlb_mem a
34 matches
Mail list logo
