Hi Jan,
On 2/23/23 12:47, Jan Beulich wrote:
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
--- /dev/null
+++ b/xen/arch/x86/hvm/vmx/vmx.h
@@ -0,0 +1,459 @@
+#include
+
+#include
+#include
+#include
+#include
As in the earlier patch, please use xen/types.h right away.
+extern int8_t opt_
On 23.02.2023 23:03, Andrew Cooper wrote:
> https://github.com/llvm/llvm-project/issues/60958
>
> While trying to work around a different Clang-IAS bug, I stubled onto
>
> In file included from arch/x86/asm-macros.c:3:
> ./arch/x86/include/asm/spec_ctrl_asm.h:144:19: error: \u used with
> n
On 23.02.2023 21:36, Andrew Cooper wrote:
> https://github.com/llvm/llvm-project/issues/60792
>
> It turns out that Clang-IAS does not expand \@ uniquely in a translaition
> unit, and the XSA-426 change tickles this bug:
>
> :4:1: error: invalid symbol redefinition
> .L1_fill_rsb_loop:
> ^
flight 178222 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178222/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-do
flight 178202 libvirt real [real]
flight 178283 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/178202/
http://logs.test-lab.xenproject.org/osstest/logs/178283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-
https://github.com/llvm/llvm-project/issues/60958
While trying to work around a different Clang-IAS bug, I stubled onto
In file included from arch/x86/asm-macros.c:3:
./arch/x86/include/asm/spec_ctrl_asm.h:144:19: error: \u used with
no following hex digits; treating as '\' followed by iden
flight 178254 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178254/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1eeca0750af5af2f0e78437bf791ac2de74bde74
baseline version:
ovmf 2c5961cccff1164ac7d0e
https://github.com/llvm/llvm-project/issues/60792
It turns out that Clang-IAS does not expand \@ uniquely in a translaition
unit, and the XSA-426 change tickles this bug:
:4:1: error: invalid symbol redefinition
.L1_fill_rsb_loop:
^
make[3]: *** [Rules.mk:247: arch/x86/acpi/cpu_idle.o] Er
Hi,
On 23/02/2023 16:01, Andrew Cooper wrote:
On 07/10/2022 1:39 pm, Matias Ezequiel Vara Larsen wrote:
A couple of observations, all unrelated to the stats themselves.
Although overall, I'm not entirely certain that a tool like this is
going to be very helpful after initial development. Some
A discussion about forward extensible APIs and ABIs here.
First, its important to say that this should be "domain stats" and not
just "vcpu stats". This is easy to account for now, but hard to
retrofit later.
For the shared memory, we have a minimum granularity of PAGE_SIZE (4k
for now, but this
flight 178195 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178195/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 177405
build-arm64-pv
flight 178185 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178185/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair broken
test-amd64-amd6
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 on AMD CPUs.
To achieve that, introduce is_cpu_primary() helper which will consider
every logical cp
Hi Marcelo,
On Thu, Feb 23, 2023 at 11:34:06AM -0300, Marcelo Tosatti wrote:
> On Mon, Feb 20, 2023 at 08:14:40PM -0800, Krister Johansen wrote:
> > On Mon, Feb 20, 2023 at 11:01:18PM +0100, Thomas Gleixner wrote:
> > > On Mon, Feb 20 2023 at 09:17, Krister Johansen wrote:
> > > > @@ -495,8 +496,7
On Wed, Feb 22, 2023 at 04:33:00PM +0100, Jens Wiklander wrote:
> diff --git a/tools/libs/light/libxl_types.idl
> b/tools/libs/light/libxl_types.idl
> index 0cfad8508dbd..64fb570bc19a 100644
> --- a/tools/libs/light/libxl_types.idl
> +++ b/tools/libs/light/libxl_types.idl
> @@ -494,7 +494,8 @@ lib
flight 178160 xen-unstable real [real]
flight 178251 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/178160/
http://logs.test-lab.xenproject.org/osstest/logs/178251/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Mon, Feb 20, 2023 at 08:14:40PM -0800, Krister Johansen wrote:
> On Mon, Feb 20, 2023 at 11:01:18PM +0100, Thomas Gleixner wrote:
> > On Mon, Feb 20 2023 at 09:17, Krister Johansen wrote:
> > > @@ -495,8 +496,7 @@ static int __init xen_tsc_safe_clocksource(void)
> > > /* Leaf 4, sub-leaf 0 (0x
On 07/10/2022 1:39 pm, Matias Ezequiel Vara Larsen wrote:
A couple of observations, all unrelated to the stats themselves.
Although overall, I'm not entirely certain that a tool like this is
going to be very helpful after initial development. Something to
consider would be to alter libxenstat to
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds the remaining SMC function IDs from FF-A 1.1 specification.
>
> Signed-off-by: Jens Wiklander
All number are coherent with the spec.
I guess you did not include the notification ones because you do not plan to
support them
On Thu, 2023-02-23 at 14:34 +0100, Jan Beulich wrote:
> On 20.02.2023 17:40, Oleksii Kurochko wrote:
> > --- a/xen/include/xen/lib.h
> > +++ b/xen/include/xen/lib.h
> > @@ -24,12 +24,12 @@
> >
> > #ifndef __ASSEMBLY__
> >
> > +#include
> > #include
> > #include
> > #include
> > #includ
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Describes a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
>
> [1] https://developer.arm.com/documentation/den0077/latest
> Signed-off-by: Jens Wiklander
It is a little bit hard to check wh
On Thu, 2023-02-23 at 14:32 +0100, Jan Beulich wrote:
> On 20.02.2023 17:40, Oleksii Kurochko wrote:
> > --- /dev/null
> > +++ b/xen/include/xen/bug.h
> > @@ -0,0 +1,161 @@
> > +#ifndef __XEN_BUG_H__
> > +#define __XEN_BUG_H__
> > +
> > +#define BUG_DISP_WIDTH 24
> > +#define BUG_LINE_LO_WIDTH (
flight 178201 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178201/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2c5961cccff1164ac7d0e34baa606d1ba1abcf43
baseline version:
ovmf 02fcfdce1e5ce86f19511
On 23/02/2023 14:46, Bertrand Marquis wrote:
diff --git a/xen/arch/arm/include/asm/tee/ffa.h
b/xen/arch/arm/include/asm/tee/ffa.h
new file mode 100644
index ..94960100718e
--- /dev/null
+++ b/xen/arch/arm/include/asm/tee/ffa.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: MIT */
On 07.02.23 22:09, Srivatsa S. Bhat wrote:
On 2/6/23 11:59 PM, Juergen Gross wrote:
The two paravirt callbacks .mmu.activate_mm and .mmu.dup_mmap are
sharing the same implementations in all cases: for Xen PV guests they
are pinning the PGD of the new mm_struct, and for all other cases
they are a
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds a new "ffa" value to the Enumeration "tee_type" to indicate if a
> guest is trusted to use FF-A.
>
> Signed-off-by: Jens Wiklander
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> tools/libs/light/libxl_arm.c | 3
Hi Jens,
> On 22 Feb 2023, at 16:32, Jens Wiklander wrote:
>
> Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
> Partition in secure world.
>
> This commit brings in only the parts needed to negotiate FF-A version
> number with guest and SPMC.
>
> [1] https://developer.arm.co
On Thu, Feb 23, 2023 at 01:03:03PM +, Bertrand Marquis wrote:
> Replace PKG_CONFIG variable name with PKG_CONFIG_FILE for the name of
> the pkg-config file.
> This is preventing a conflict in some build systems where PKG_CONFIG
> actually contains the path to the pkg-config executable to use, a
Hi,
I have only skimmed through the patch so far and I have one question below.
On 22/02/2023 15:32, Jens Wiklander wrote:
Adds a FF-A version 1.1 [1] mediator to communicate with a Secure
Partition in secure world.
This commit brings in only the parts needed to negotiate FF-A version
number w
On 2/23/23 13:16, Andrew Cooper wrote:
On 22/02/2023 12:00 pm, Xenia Ragiadakou wrote:
Create a new private header in arch/x86/hvm/svm called svm.h and move there
all definitions and declarations that are used solely by svm code.
The function svm_invlpga() stays in arch/x86/hvm/svm/svm.h beca
Hi Jens,
On 22/02/2023 15:32, Jens Wiklander wrote:
SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
registers and result registers for the SMC and HVC instructions.
Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
parameter and result registers.
Let us a
Hi Jens,
> On 22 Feb 2023, at 16:32, Jens Wiklander wrote:
>
> SMCCC v1.2 [1] AArch64 allows x0-x17 to be used as both parameter
> registers and result registers for the SMC and HVC instructions.
>
> Arm Firmware Framework for Armv8-A specification makes use of x0-x7 as
> parameter and result r
> On 23 Feb 2023, at 15:09, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 27 Jan 2023, at 20:55, Julien Grall wrote:
>>
>> From: Julien Grall
>>
>> Xen is currently not fully compliant with the Arm Arm because it will
>> switch the TTBR with the MMU on.
>>
>> In order to be compliant, w
> On 23 Feb 2023, at 15:06, Bertrand Marquis wrote:
>
> Hi Julien,
>
>> On 27 Jan 2023, at 20:55, Julien Grall wrote:
>>
>> From: Julien Grall
>>
>> Switching TTBR while the MMU is on is not safe. Now that the identity
>> mapping will not clash with the rest of the memory layout, we can av
Hi Julien,
> On 27 Jan 2023, at 20:55, Julien Grall wrote:
>
> From: Julien Grall
>
> Xen is currently not fully compliant with the Arm Arm because it will
> switch the TTBR with the MMU on.
>
> In order to be compliant, we need to disable the MMU before
> switching the TTBR. The implication
Hi Julien,
> On 27 Jan 2023, at 20:55, Julien Grall wrote:
>
> From: Julien Grall
>
> Switching TTBR while the MMU is on is not safe. Now that the identity
> mapping will not clash with the rest of the memory layout, we can avoid
> creating temporary page-tables every time a CPU is brought up.
Hi Jan,
> On 13 Feb 2023, at 09:36, Jan Beulich wrote:
>
> On 10.02.2023 16:54, Luca Fancellu wrote:
>>> On 2 Feb 2023, at 12:05, Jan Beulich wrote:
>>> On 02.02.2023 12:08, Luca Fancellu wrote:
(is hw_cap only for x86?)
>>>
>>> I suppose it is, but I also expect it would better go away t
On Thu, Feb 23, 2023 at 02:21:11PM +0100, Jan Beulich wrote:
> On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote:
> > On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote:
> >> On 22.02.2023 20:14, Demi Marie Obenour wrote:
> >>> To quote Andrew Cooper:
> >>>
> I know we've had this
flight 178238 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178238/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 20.02.2023 17:40, Oleksii Kurochko wrote:
> --- a/xen/include/xen/lib.h
> +++ b/xen/include/xen/lib.h
> @@ -24,12 +24,12 @@
>
> #ifndef __ASSEMBLY__
>
> +#include
> #include
> #include
> #include
> #include
> #include
> -#include
>
> #define BUG_ON(p) do { if (unlikely(p)) B
On 20.02.2023 17:40, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/xen/bug.h
> @@ -0,0 +1,161 @@
> +#ifndef __XEN_BUG_H__
> +#define __XEN_BUG_H__
> +
> +#define BUG_DISP_WIDTH24
> +#define BUG_LINE_LO_WIDTH (31 - BUG_DISP_WIDTH)
> +#define BUG_LINE_HI_WIDTH (31 - BUG_DISP_WIDTH)
On 23.02.2023 14:16, Oleksii wrote:
>>
>>> + void (*fn)(const struct cpu_user_regs *) = (void *)regs-
BUG_FN_REG;
>>
>> ... this, wouldn't it be better (and independent of the specific
>> arch) if
>> you checked for BUG_FN_REG being defined?
>>
>> Another (#ifdef-free) variant would be
On 23.02.2023 14:08, Marek Marczykowski-Górecki wrote:
> On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote:
>> On 22.02.2023 20:14, Demi Marie Obenour wrote:
>>> To quote Andrew Cooper:
>>>
I know we've had this argument before, but not calling
SetVirtualAddressMap() isn't a via
>
> > + void (*fn)(const struct cpu_user_regs *) = (void *)regs-
> > >BUG_FN_REG;
>
> ... this, wouldn't it be better (and independent of the specific
> arch) if
> you checked for BUG_FN_REG being defined?
>
> Another (#ifdef-free) variant would be to have bug_ptr() take a 2nd
> argument
On Thu, Feb 23, 2023 at 11:16:28AM +0100, Jan Beulich wrote:
> On 22.02.2023 20:14, Demi Marie Obenour wrote:
> > To quote Andrew Cooper:
> >
> >> I know we've had this argument before, but not calling
> >> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to
> >> function on lite
Replace PKG_CONFIG variable name with PKG_CONFIG_FILE for the name of
the pkg-config file.
This is preventing a conflict in some build systems where PKG_CONFIG
actually contains the path to the pkg-config executable to use, as the
default assignment in libs.mk is using a weak assignment (?=).
This
On 23.02.2023 13:16, Matias Ezequiel Vara Larsen wrote:
> On Fri, Feb 17, 2023 at 03:10:53PM +0100, Jan Beulich wrote:
>> On 17.02.2023 10:29, Matias Ezequiel Vara Larsen wrote:
>>> On Fri, Feb 17, 2023 at 09:57:43AM +0100, Jan Beulich wrote:
On 17.02.2023 09:50, Matias Ezequiel Vara Larsen wr
On 23.02.2023 13:22, Andrew Cooper wrote:
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -31,7 +31,7 @@
>
> #define __weak__attribute__((__weak__))
>
> -#if !defined(__clang__)
> +#if !CONFIG_CC_IS_CLANG || CONFIG_CLANG_VERSION >= 14
Hmm, for the sake o
On 23.02.2023 13:28, Jan Beulich wrote:
> On 23.02.2023 13:07, Andrew Cooper wrote:
>> Taking struct cpu_user_regs as a full object is bogus, and while what was
>> probably meant was to take a struct cpu_user_regs pointer, that's still
>> wrong.
>>
>> This isn't a function; its an address stored i
On 23.02.2023 13:07, Andrew Cooper wrote:
> Taking struct cpu_user_regs as a full object is bogus, and while what was
> probably meant was to take a struct cpu_user_regs pointer, that's still wrong.
>
> This isn't a function; its an address stored in the VMCS that the CPU resumes
> from on VMExit,
Adjust the ifdefary for `nocall`.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/include/xen/compiler.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
index a5631303348b..7d7
On Fri, Feb 17, 2023 at 03:10:53PM +0100, Jan Beulich wrote:
> On 17.02.2023 10:29, Matias Ezequiel Vara Larsen wrote:
> > On Fri, Feb 17, 2023 at 09:57:43AM +0100, Jan Beulich wrote:
> >> On 17.02.2023 09:50, Matias Ezequiel Vara Larsen wrote:
> >>> On Wed, Dec 14, 2022 at 08:56:57AM +0100, Jan Be
On Thu, 2023-02-23 at 11:11 +0100, Jan Beulich wrote:
> On 22.02.2023 17:16, Oleksii wrote:
> > On Wed, 2023-02-22 at 13:46 +0100, Jan Beulich wrote:
> > > On 20.02.2023 17:40, Oleksii Kurochko wrote:
> > > > --- /dev/null
> > > > +++ b/xen/common/bug.c
> > > > @@ -0,0 +1,113 @@
> > > > +#include
Taking struct cpu_user_regs as a full object is bogus, and while what was
probably meant was to take a struct cpu_user_regs pointer, that's still wrong.
This isn't a function; its an address stored in the VMCS that the CPU resumes
from on VMExit, meaning that it doesn't conform to a normal C API/A
On 23/02/2023 10:47 am, Jan Beulich wrote:
> On 22.02.2023 13:00, Xenia Ragiadakou wrote:
>> --- /dev/null
>> +++ b/xen/arch/x86/hvm/vmx/vmx.h
>> @@ -0,0 +1,459 @@
>> +#include
Like svm.h, SPDX tag and guards please.
>
>> +extern int8_t opt_ept_exec_sp;
>> +
>> +#define PI_xAPIC_NDST_MASK 0
On 23.02.2023 09:42, osstest service owner wrote:
> flight 178148 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/178148/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemuu-ws16-am
On Thu, Feb 09, 2023 at 11:00:16PM +, Julien Grall wrote:
> This is replacing the below pattern with the SPDX tag GPL-2.0 in
> xen/arch/x86/*.c:
>
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
On Thu, Feb 09, 2023 at 11:00:15PM +, Julien Grall wrote:
> This is replacing the below pattern with the SPDX tag GPL-2.0 in
The "GPL-2.0" identifier is actually deprecated:
https://spdx.org/licenses/GPL-2.0.html
We should use "GPL-2.0-only" instead.
https://spdx.org/licenses/GPL-2.0-o
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Move vmx_update_debug_state() in vmcs.c because it is used only in this
> file and limit its scope to this file by declaring it static and removing
> its declaration from private vmx.h
>
> Signed-off-by: Xenia Ragiadakou
Perhaps move this ahead in t
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Reduce the scope of nvmx_enqueue_n2_exceptions() to static because it is used
> only in this file.
>
> Take the opportunity to remove a trailing space.
>
> Signed-off-by: Xenia Ragiadakou
Reviewed-by: Jan Beulich
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Do not include the headers:
> asm/hvm/vpic.h
> asm/hvm/vpt.h
> asm/io.h
> asm/mce.h
> asm/mem_sharing.h
This one puzzled me, so I've looked up its origin. It's entirely unclear
to me why 29317cfbf36d ("HAP fault handling for shared pages") a
On 22/02/2023 12:00 pm, Xenia Ragiadakou wrote:
> Create a new private header in arch/x86/hvm/svm called svm.h and move there
> all definitions and declarations that are used solely by svm code.
>
> The function svm_invlpga() stays in arch/x86/hvm/svm/svm.h because it is used
> by arch/x86/hvm/svm/
On 2/23/23 12:50, Andrew Cooper wrote:
On 22/02/2023 12:59 pm, Jan Beulich wrote:
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
Remove forward declaration of struct vcpu, that is a leftover since
the removal of svm_update_guest_cr()'s declaration from svm.h.
Signed-off-by: Xenia Ragiadakou
On 22/02/2023 12:59 pm, Jan Beulich wrote:
> On 22.02.2023 13:00, Xenia Ragiadakou wrote:
>> Remove forward declaration of struct vcpu, that is a leftover since
>> the removal of svm_update_guest_cr()'s declaration from svm.h.
>>
>> Signed-off-by: Xenia Ragiadakou
> Acked-by: Jan Beulich
>
>> Fix
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/vmx/vmx.h
> @@ -0,0 +1,459 @@
> +#include
> +
> +#include
> +#include
> +#include
> +#include
As in the earlier patch, please use xen/types.h right away.
> +extern int8_t opt_ept_exec_sp;
> +
> +#define PI_
On 2/23/23 12:31, Jan Beulich wrote:
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
Since GAS_VMX_OP is used only by vm{read,write}_safe, move its definition
just above those functions and undefine it after use.
Signed-off-by: Xenia Ragiadakou
This can easily be done as part of the next patc
On 2/23/23 12:29, Jan Beulich wrote:
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
Do not include the headers:
asm/i387.h
asm/hvm/trace.h
asm/processor.h
asm/regs.h
because none of the declarations and macro definitions in them is used in
this file. Sort the rest of the headers alp
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Since GAS_VMX_OP is used only by vm{read,write}_safe, move its definition
> just above those functions and undefine it after use.
>
> Signed-off-by: Xenia Ragiadakou
This can easily be done as part of the next patch, with less code churn
overall.
J
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Do not include the headers:
> asm/i387.h
> asm/hvm/trace.h
> asm/processor.h
> asm/regs.h
> because none of the declarations and macro definitions in them is used in
> this file. Sort the rest of the headers alphabetically.
> Fix build by inclu
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Create a new private header in arch/x86/hvm/svm called svm.h and move there
> all definitions and declarations that are used solely by svm code.
>
> The function svm_invlpga() stays in arch/x86/hvm/svm/svm.h because it is used
> by arch/x86/hvm/svm/as
On 22.02.2023 13:00, Xenia Ragiadakou wrote:
> Delete the macros SVM_PAUSE{FILTER,THRESH}_INIT from svm.h and opencode
> their values, since they are used in a single place and using macros is
> just unnecessary obfuscation.
>
> Signed-off-by: Xenia Ragiadakou
Acked-by: Jan Beulich
> Changes i
On 22.02.2023 20:14, Demi Marie Obenour wrote:
> To quote Andrew Cooper:
>
>> I know we've had this argument before, but not calling
>> SetVirtualAddressMap() isn't a viable option. It's a prerequisite to
>> function on literally millions of devices
>
> Qubes OS has been shipping EFI_SET_VIRTUAL
On 22.02.2023 17:16, Oleksii wrote:
> On Wed, 2023-02-22 at 13:46 +0100, Jan Beulich wrote:
>> On 20.02.2023 17:40, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/common/bug.c
>>> @@ -0,0 +1,113 @@
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>
flight 178139 xen-4.17-testing real [real]
flight 178219 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/178139/
http://logs.test-lab.xenproject.org/osstest/logs/178219/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
When running as Xen PV initial domain (aka dom0), MTRRs are disabled
by the hypervisor, but the system should nevertheless use correct
cache memory types. This has always kind of worked, as disabled MTRRs
resulted in disabled PAT, too, so that the kernel avoided code paths
resulting in inconsistenc
This series tries to fix the rather special case of PAT being available
without having MTRRs (either due to CONFIG_MTRR being not set, or
because the feature has been disabled e.g. by a hypervisor).
The main use cases are Xen PV guests and SEV-SNP guests running under
Hyper-V.
Instead of trying t
flight 178148 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-do
77 matches
Mail list logo
