On 24.02.2023 23:55, Demi Marie Obenour wrote:
> On Tue, Feb 21, 2023 at 11:07:58AM +0100, Jan Beulich wrote:
>> On 19.02.2023 03:46, Demi Marie Obenour wrote:
>>> --- a/stubdom/configure
>>> +++ b/stubdom/configure
>>> @@ -3535,7 +3535,7 @@ if test "x$ZLIB_URL" = "x"; then :
>>> if test "x$ext
On 26.02.23 17:34, Tom Rix wrote:
building with gcc and W=1 reports
drivers/net/xen-netback/netback.c:886:21: error: variable
‘pending_idx’ set but not used [-Werror=unused-but-set-variable]
886 | u16 pending_idx;
| ^~~
pending_idx is not
On 25.02.2023 21:37, Demi Marie Obenour wrote:
> --- a/Config.mk
> +++ b/Config.mk
> @@ -191,7 +191,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES), -I$(i))
> EMBEDDED_EXTRA_CFLAGS := -fno-pie -fno-stack-protector
> -fno-stack-protector-all
> EMBEDDED_EXTRA_CFLAGS += -fno-exceptions -fno-a
On 25.02.2023 21:37, Demi Marie Obenour wrote:
> --- a/stubdom/configure
> +++ b/stubdom/configure
> @@ -3545,7 +3545,7 @@ if test "x$LIBPCI_URL" = "x"; then :
> if test "x$extfiles" = "xy"; then :
>LIBPCI_URL=\$\(XEN_EXTFILES_URL\)
> else
> - LIBPCI_URL="http://www.kernel.org/pub/softw
On 2/24/23 23:06, Andrew Cooper wrote:
struct nestedvm uses mostly plain integer types, except for virt_ext_t which
is a union wrapping two bitfield names. But the nested virt logic only ever
deals with it as full opaque register.
Switch it to being a plain uint64_t, allowing us to hide even
On 24.02.2023 17:36, Oleksii wrote:
> On Fri, 2023-02-24 at 16:04 +0100, Jan Beulich wrote:
>> On 24.02.2023 15:48, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> xen/arch/riscv/setup.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/xen/arch/
There are no references anymore as of c9a4a1c419ce ("x86/layout: Correct
Xen's idea of its own memory layout"). For what's left, switch to
"unsigned char" as here we're not dealing with strings of any kind.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -305,
flight 178616 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178616/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
in 178515 pass in 178616
test-a
On 25.02.2023 17:42, Julien Grall wrote:
> On 24/02/2023 11:31, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/common/bug.c
>> @@ -0,0 +1,109 @@
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include > +#include
>> +#include
>> +#include
>> +
>> +#include
>> +
>> +/* Set d
This is done so that the crypto/ source files are listed in all_sources
and thus taken into account for cscope,tags,... targets.
Signed-off-by: Michal Orzel
---
xen/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/Makefile b/xen/Makefile
index 2d55bb9401f4..27a203
On Fri, 2023-02-24 at 16:55 +, Andrew Cooper wrote:
> On 24/02/2023 2:48 pm, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > xen/arch/riscv/setup.c | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/s
On 27.02.2023 10:53, Michal Orzel wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -589,7 +589,7 @@ $(TARGET): outputmakefile FORCE
> $(Q)$(MAKE) $(build)=. arch/$(TARGET_ARCH)/include/asm/asm-offsets.h
> $(Q)$(MAKE) $(build)=. MKRELOC=$(MKRELOC) 'ALL_OBJS=$(ALL_OBJS-y)'
> 'ALL_LI
On 26.02.2023 00:56, Marek Marczykowski-Górecki wrote:
> The ELF is repacked from from 64bit to 32bit. With CET-related notes,
> which use 64bit fields, this results in 32bit binary with corrupted
> notes. Drop them all (except build-id and PVH note retained
> explicitly).
>
> Suggested-by: Jan Be
> On 24 Feb 2023, at 14:56, Andrew Cooper wrote:
>
> On 24/02/2023 1:36 pm, Edwin Török wrote:
>> From: Edwin Török
>>
>> Prior to bd7a29c3d0 'out' would've always been executed and memory
>> freed, but that commit changed it such that it returns early and leaks.
>>
>> Found using gcc 12.2.
On 24.02.2023 22:33, Andrew Cooper wrote:
> But I think we want to change tact slightly at this point, so I'm not
> going to do any further tweaking on commit.
>
> Next, I think we want to rename asm/hvm/svm/svm.h to asm/hvm/svm.h,
> updating the non-SVM include paths as we go. Probably best to
>
On 27/02/2023 8:52 am, Xenia Ragiadakou wrote:
>
> On 2/24/23 23:06, Andrew Cooper wrote:
>> struct nestedvm uses mostly plain integer types, except for
>> virt_ext_t which
>> is a union wrapping two bitfield names. But the nested virt logic
>> only ever
>> deals with it as full opaque register.
>
Hardly anybody still uses 32-bit x86 hosts today, so we should
start deprecating them to finally have less test efforts.
With regards to 32-bit KVM support in the x86 Linux kernel,
the developers confirmed that they do not need a recent
qemu-system-i386 binary here:
https://lore.kernel.org/kvm/y%
qemu-system-aarch64 is a proper superset of qemu-system-arm,
and the latter was mainly still required for 32-bit KVM support.
But this 32-bit KVM arm support has been dropped in the Linux
kernel a couple of years ago already,so we don't really need
qemu-system-arm anymore, thus deprecated it now.
We're struggling quite badly with our CI minutes on the shared
gitlab runners, so we urgently need to think of ways to cut down
our supported build and target environments. qemu-system-i386 and
qemu-system-arm are not really required anymore, since nobody uses
KVM on the corresponding systems for p
On 27/02/2023 10:46 am, Jan Beulich wrote:
> On 24.02.2023 22:33, Andrew Cooper wrote:
>> But I think we want to change tact slightly at this point, so I'm not
>> going to do any further tweaking on commit.
>>
>> Next, I think we want to rename asm/hvm/svm/svm.h to asm/hvm/svm.h,
>> updating the no
On Mon, 2023-02-27 at 10:17 +0100, Jan Beulich wrote:
> On 24.02.2023 17:36, Oleksii wrote:
> > On Fri, 2023-02-24 at 16:04 +0100, Jan Beulich wrote:
> > > On 24.02.2023 15:48, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > > > ---
> > > > xen/arch/riscv/setup.c | 12
On 27/02/2023 9:32 am, Jan Beulich wrote:
> There are no references anymore as of c9a4a1c419ce ("x86/layout: Correct
> Xen's idea of its own memory layout"). For what's left, switch to
> "unsigned char" as here we're not dealing with strings of any kind.
>
> Signed-off-by: Jan Beulich
Acked-by: A
On 27.02.2023 12:15, Andrew Cooper wrote:
> On 27/02/2023 10:46 am, Jan Beulich wrote:
>> On 24.02.2023 22:33, Andrew Cooper wrote:
>>> But I think we want to change tact slightly at this point, so I'm not
>>> going to do any further tweaking on commit.
>>>
>>> Next, I think we want to rename asm/h
struct nestedvm uses mostly plain integer types, except for virt_ext_t which
is a union wrapping two bitfield names.
However, it turns out that this is a write-only variable. Delete it, allowing
us to drop the include of vmcb.h
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Xenia Ragiada
On 27.02.2023 12:19, Oleksii wrote:
> On Mon, 2023-02-27 at 10:17 +0100, Jan Beulich wrote:
>> On 24.02.2023 17:36, Oleksii wrote:
>>> On Fri, 2023-02-24 at 16:04 +0100, Jan Beulich wrote:
On 24.02.2023 15:48, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> xen/
On 27.02.2023 12:35, Andrew Cooper wrote:
> struct nestedvm uses mostly plain integer types, except for virt_ext_t which
> is a union wrapping two bitfield names.
>
> However, it turns out that this is a write-only variable. Delete it, allowing
> us to drop the include of vmcb.h
>
> Signed-off-b
On 27/02/2023 11:41 am, Jan Beulich wrote:
> On 27.02.2023 12:35, Andrew Cooper wrote:
>> struct nestedvm uses mostly plain integer types, except for virt_ext_t which
>> is a union wrapping two bitfield names.
>>
>> However, it turns out that this is a write-only variable. Delete it,
>> allowing
Hi,
I have been looking into using S0ix with Xen. On systems with with 11th
gen (Tiger Lake) Intel mobile CPUs or newer this is often the only
supported suspend method, thus we want to support it in Qubes OS.
Below a summary of my current understanding of what's needed (and known
unknowns). I wou
On Mon, Feb 27, 2023 at 12:10:49PM +0100, Thomas Huth wrote:
> Hardly anybody still uses 32-bit x86 hosts today, so we should
> start deprecating them to finally have less test efforts.
> With regards to 32-bit KVM support in the x86 Linux kernel,
> the developers confirmed that they do not need a
On 27/02/2023 11:33 am, Jan Beulich wrote:
> On 27.02.2023 12:15, Andrew Cooper wrote:
>> On 27/02/2023 10:46 am, Jan Beulich wrote:
>>> On 24.02.2023 22:33, Andrew Cooper wrote:
But I think we want to change tact slightly at this point, so I'm not
going to do any further tweaking on comm
There are some macros defined multiple times in tools. Use only
xen-tools/libs.h for defining those macros and drop the copies.
Juergen Gross (3):
tools: add container_of() macro to xen-tools/libs.h
tools: get rid of additional min() and max() definitions
tools: add offsetof() to xen-tools/l
Instead of having 4 identical copies of the definition of a
container_of() macro in different tools header files, add that macro
to xen-tools/libs.h and use that instead.
Delete the other copies of that macro.
Signed-off-by: Juergen Gross
---
There is a similar macro CONTAINER_OF() defined in
to
Defining min(), min_t(), max() and max_t() at other places than
xen-tools/libs.h isn't needed, as the definitions in said header can
be used instead.
Same applies to BUILD_BUG_ON() in hvmloader.
Signed-off-by: Juergen Gross
---
tools/firmware/hvmloader/util.h | 8 ++--
tools/libs/vchan/ini
Instead of having multiple files defining offsetof(), add the
definition to tools/include/xen-tools/libs.h.
Signed-off-by: Juergen Gross
---
tools/firmware/hvmloader/util.h | 3 ---
tools/firmware/include/stddef.h | 4 ++--
tools/include/xen-tools/libs.h | 4
tools/libfsimage/Rules.mk
On 27.02.2023 12:48, Simon Gaiser wrote:
> PIT timer: During some previous private discussion it was mentioned that
> the PIT timer that Xen initializes for IO-APIC testing prevents S0ix
> residency and therefore that part needs to be reworked. But if I'm
> reading the current code correctly Xen ca
On Mon, 2023-02-27 at 12:37 +0100, Jan Beulich wrote:
> On 27.02.2023 12:19, Oleksii wrote:
> > On Mon, 2023-02-27 at 10:17 +0100, Jan Beulich wrote:
> > > On 24.02.2023 17:36, Oleksii wrote:
> > > > On Fri, 2023-02-24 at 16:04 +0100, Jan Beulich wrote:
> > > > > On 24.02.2023 15:48, Oleksii Kuroch
On 27.02.2023 13:06, Andrew Cooper wrote:
> On 27/02/2023 11:33 am, Jan Beulich wrote:
>> On 27.02.2023 12:15, Andrew Cooper wrote:
>>> On 27/02/2023 10:46 am, Jan Beulich wrote:
On 24.02.2023 22:33, Andrew Cooper wrote:
> But I think we want to change tact slightly at this point, so I'm n
On 27.02.2023 13:09, Juergen Gross wrote:
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmloader/util.h
> @@ -30,9 +30,6 @@ enum {
> #define SEL_DATA32 0x0020
> #define SEL_CODE64 0x0028
>
> -#undef offsetof
> -#define offsetof(t, m) ((unsigned long)&((t *)0)
On 27.02.23 13:31, Jan Beulich wrote:
On 27.02.2023 13:09, Juergen Gross wrote:
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -30,9 +30,6 @@ enum {
#define SEL_DATA32 0x0020
#define SEL_CODE64 0x0028
-#undef offsetof
-#define offsetof(t,
On 27.02.2023 13:34, Juergen Gross wrote:
> On 27.02.23 13:31, Jan Beulich wrote:
>> On 27.02.2023 13:09, Juergen Gross wrote:
>>> --- a/tools/firmware/hvmloader/util.h
>>> +++ b/tools/firmware/hvmloader/util.h
>>> @@ -30,9 +30,6 @@ enum {
>>> #define SEL_DATA32 0x0020
>>> #define SEL_
On 24.02.2023 12:35, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/traps.c
> +++ b/xen/arch/riscv/traps.c
> @@ -4,10 +4,95 @@
> *
> * RISC-V Trap handlers
> */
> +
> +#include
I couldn't spot anything in the file which would require this inclusion.
> +#include
> +
> +#include
> +#includ
On 24.02.2023 12:35, Oleksii Kurochko wrote:
> @@ -11,6 +13,8 @@ void __init noreturn start_xen(void)
> {
> early_printk("Hello from C env\n");
>
> +trap_init();
> +
> for ( ;; )
> asm volatile ("wfi");
Along the lines of what Andrew has said there - it's hard to see
how
On 24.02.2023 12:35, Oleksii Kurochko wrote:
> The patch introduces macros: BUG(), WARN(), run_in_exception(),
> assert_failed.
>
> The implementation uses "ebreak" instruction in combination with
> diffrent bug frame tables (for each type) which contains useful
> information.
>
> Signed-off-by:
flight 178623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178623/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-fr
Hi Jan,
On 27/02/2023 11:10, Jan Beulich wrote:
>
>
> On 27.02.2023 10:53, Michal Orzel wrote:
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -589,7 +589,7 @@ $(TARGET): outputmakefile FORCE
>> $(Q)$(MAKE) $(build)=. arch/$(TARGET_ARCH)/include/asm/asm-offsets.h
>> $(Q)$(MAKE) $(b
On 2/27/23 2:12 AM, Juergen Gross wrote:
On 24.02.23 22:00, Boris Ostrovsky wrote:
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platform_op(&op))
+ break;
If we f
On 27.02.2023 14:41, Michal Orzel wrote:
> Hi Jan,
>
> On 27/02/2023 11:10, Jan Beulich wrote:
>>
>>
>> On 27.02.2023 10:53, Michal Orzel wrote:
>>> --- a/xen/Makefile
>>> +++ b/xen/Makefile
>>> @@ -589,7 +589,7 @@ $(TARGET): outputmakefile FORCE
>>> $(Q)$(MAKE) $(build)=. arch/$(TARGET_ARCH
On 27.02.23 14:52, Boris Ostrovsky wrote:
On 2/27/23 2:12 AM, Juergen Gross wrote:
On 24.02.23 22:00, Boris Ostrovsky wrote:
On 2/23/23 4:32 AM, Juergen Gross wrote:
+
+ for (reg = 0; reg < MTRR_MAX_VAR_RANGES; reg++) {
+ op.u.read_memtype.reg = reg;
+ if (HYPERVISOR_platfo
On 27/02/2023 12:43 pm, Jan Beulich wrote:
> On 27.02.2023 13:34, Juergen Gross wrote:
>> On 27.02.23 13:31, Jan Beulich wrote:
>>> On 27.02.2023 13:09, Juergen Gross wrote:
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -30,9 +30,6 @@ enum {
#d
On 27.02.23 15:06, Andrew Cooper wrote:
On 27/02/2023 12:43 pm, Jan Beulich wrote:
On 27.02.2023 13:34, Juergen Gross wrote:
On 27.02.23 13:31, Jan Beulich wrote:
On 27.02.2023 13:09, Juergen Gross wrote:
--- a/tools/firmware/hvmloader/util.h
+++ b/tools/firmware/hvmloader/util.h
@@ -30,9 +30
On 27.02.2023 15:06, Andrew Cooper wrote:
> On 27/02/2023 12:43 pm, Jan Beulich wrote:
>> On 27.02.2023 13:34, Juergen Gross wrote:
>>> On 27.02.23 13:31, Jan Beulich wrote:
On 27.02.2023 13:09, Juergen Gross wrote:
> --- a/tools/firmware/hvmloader/util.h
> +++ b/tools/firmware/hvmload
On 27/02/2023 2:12 pm, Jan Beulich wrote:
> On 27.02.2023 15:06, Andrew Cooper wrote:
>> On 27/02/2023 12:43 pm, Jan Beulich wrote:
>>> On 27.02.2023 13:34, Juergen Gross wrote:
On 27.02.23 13:31, Jan Beulich wrote:
> On 27.02.2023 13:09, Juergen Gross wrote:
>> --- a/tools/firmware/hv
On 24.02.2023 12:31, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/common/bug.c
> @@ -0,0 +1,109 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/* Set default value for TRAP_invalid_op as it is defined only fo
On Sat, Feb 25, 2023 at 11:34:32PM +0100, Marek Marczykowski-Górecki wrote:
> On Sat, Feb 25, 2023 at 03:37:11PM -0500, Demi Marie Obenour wrote:
> > Obtaining code over an insecure transport is a terrible idea for
> > blatently obvious reasons. Even for non-executable data, insecure
> > transport
On 24.02.2023 12:31, Oleksii Kurochko wrote:
> Since the generic version of bug.h stuff was introduced use
> instead of unnecessary
You keep saying "unnecessary" here, but that's not really correct.
Including asm/bug.h alone simply becomes meaningless. So how about
"... instead of now useless (i
On 24.02.23 15:56, Andrew Cooper wrote:
On 24/02/2023 1:36 pm, Edwin Török wrote:
From: Edwin Török
Prior to bd7a29c3d0 'out' would've always been executed and memory
freed, but that commit changed it such that it returns early and leaks.
Found using gcc 12.2.1 `-fanalyzer`:
```
xg_core_x86.c
flight 178663 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178663/
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 24.02.2023 12:31, Oleksii Kurochko wrote:
> The following changes were made:
> * Make GENERIC_BUG_FRAME mandatory for X86
> * Update asm/bug.h using generic implementation in
> * Change prototype of debugger_trap_fatal() in asm/debugger.h
> to align it with generic prototype in .
> * Update d
On 27/02/2023 14:54, Jan Beulich wrote:
>
>
> On 27.02.2023 14:41, Michal Orzel wrote:
>> Hi Jan,
>>
>> On 27/02/2023 11:10, Jan Beulich wrote:
>>>
>>>
>>> On 27.02.2023 10:53, Michal Orzel wrote:
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -589,7 +589,7 @@ $(TARGET): outputmakefil
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds support for the FF-A function FFA_ID_GET to return the ID of the
> calling client.
>
> Signed-off-by: Jens Wiklander
> ---
> xen/arch/arm/tee/ffa.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
On 27/02/2023 2:42 pm, Juergen Gross wrote:
> On 24.02.23 15:56, Andrew Cooper wrote:
>> On 24/02/2023 1:36 pm, Edwin Török wrote:
>>> From: Edwin Török
>>>
>>> Prior to bd7a29c3d0 'out' would've always been executed and memory
>>> freed, but that commit changed it such that it returns early and l
Hi,
On 27/02/2023 14:48, Bertrand Marquis wrote:
On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
Adds support for the FF-A function FFA_ID_GET to return the ID of the
calling client.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 21 -
1 file changed, 20 insert
On 27.02.2023 15:46, Michal Orzel wrote:
> On 27/02/2023 14:54, Jan Beulich wrote:
>> On 27.02.2023 14:41, Michal Orzel wrote:
>>> On 27/02/2023 11:10, Jan Beulich wrote:
On 27.02.2023 10:53, Michal Orzel wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -589,7 +589,7 @@ $(TARG
Edwin, with the help of GCC's -fanalyzer, identified that p2m_frame_list_list
gets leaked. What fanalyzer can't see is that the live_p2m_frame_list_list
and live_p2m_frame_list foreign mappings are leaked too.
Rework the logic so the out path is executed unconditionally, which cleans up
all the i
On 24.02.2023 16:06, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/page.h
> @@ -0,0 +1,90 @@
> +#ifndef _ASM_RISCV_PAGE_H
> +#define _ASM_RISCV_PAGE_H
> +
> +#include
> +#include
> +
> +#define PAGE_ENTRIES512
> +#define VPN_BITS(9)
> +#def
On 25.02.2023 19:05, Julien Grall wrote:
> On 24/02/2023 15:06, Oleksii Kurochko wrote:
>> @@ -43,6 +45,11 @@ static void __init disable_fpu(void)
>>
>> void __init noreturn start_xen(void)
>> {
>> +unsigned long load_start= (unsigned long)start;
>> +unsigned long load_end =
On 27.02.2023 16:12, Jan Beulich wrote:
> On 24.02.2023 16:06, Oleksii Kurochko wrote:
>> +static void __attribute__((section(".entry")))
>> +_setup_initial_pagetables(pte_t *second, pte_t *first, pte_t *zeroeth,
>
> Why the special section (also again further down)?
Looking at patch 2 it occurre
On 11/02/2023 10:01, Julien Grall wrote:
Hi Ayan,
Hi Julien,
I need some clarification.
On 08/02/2023 12:05, Ayan Kumar Halder wrote:
Some Arm based hardware platforms which does not support LPAE
(eg Cortex-R52), uses 32 bit physical addresses.
Also, users may choose to use 32 bits to re
On 24.02.2023 19:50, Xenia Ragiadakou wrote:
> --- /dev/null
> +++ b/xen/arch/x86/hvm/vmx/pi.h
> @@ -0,0 +1,78 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * pi.h: VMX Posted Interrupts
> + *
> + * Copyright (c) 2004, Intel Corporation.
> + */
> +
> +#ifndef __X86_HVM_VMX_PI_PRIV_H__
> +#
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds support for sending a FF-A direct request. Checks that the SP also
> supports handling a 32-bit direct request. 64-bit direct requests are
> not used by the mediator itself so there is not need to check for that.
>
> Signed-off
On 27/02/2023 15:17, Jan Beulich wrote:
On 25.02.2023 19:05, Julien Grall wrote:
On 24/02/2023 15:06, Oleksii Kurochko wrote:
@@ -43,6 +45,11 @@ static void __init disable_fpu(void)
void __init noreturn start_xen(void)
{
+unsigned long load_start= (unsigned long)start;
+
There are some macros defined multiple times in tools. Use only
a single header file for defining those macros and drop the copies.
V2:
- add patch 1 (Andrew Cooper)
Juergen Gross (4):
tools: rename xen-tools/libs.h file to common-macros.h
tools: add container_of() macro to xen-tools/common-m
In order to better reflect the contents of the header and to make it
more appropriate to use it for different runtime environments like
programs, libraries, and firmware, rename the libs.h include file to
common-macros.h. Additionally ad a comment pointing out the need to be
self-contained.
Sugges
Instead of having 4 identical copies of the definition of a
container_of() macro in different tools header files, add that macro
to xen-tools/common-macros.h and use that instead.
Delete the other copies of that macro.
Signed-off-by: Juergen Gross
---
There is a similar macro CONTAINER_OF() defi
Instead of having multiple files defining offsetof(), add the
definition to tools/include/xen-tools/common-macros.h.
Signed-off-by: Juergen Gross
---
tools/firmware/hvmloader/util.h | 3 ---
tools/firmware/include/stddef.h | 4 ++--
tools/include/xen-tools/common-macros.h | 4 +++
Defining min(), min_t(), max() and max_t() at other places than
xen-tools/common-macros.h isn't needed, as the definitions in said
header can be used instead.
Same applies to BUILD_BUG_ON() in hvmloader.
Signed-off-by: Juergen Gross
---
tools/firmware/hvmloader/util.h | 8 ++--
tools/libs/
On 27/02/2023 16:00, Jan Beulich wrote:
>
>
> On 27.02.2023 15:46, Michal Orzel wrote:
>> On 27/02/2023 14:54, Jan Beulich wrote:
>>> On 27.02.2023 14:41, Michal Orzel wrote:
On 27/02/2023 11:10, Jan Beulich wrote:
> On 27.02.2023 10:53, Michal Orzel wrote:
>> --- a/xen/Makefile
>
On 27.02.2023 16:41, Juergen Gross wrote:
> --- a/tools/include/xen-tools/libs.h
> +++ b/tools/include/xen-tools/common-macros.h
> @@ -1,5 +1,13 @@
> -#ifndef __XEN_TOOLS_LIBS__
> -#define __XEN_TOOLS_LIBS__
> +#ifndef __XEN_TOOLS_COMMON_MACROS__
> +#define __XEN_TOOLS_COMMON_MACROS__
> +
> +/*
> +
On 27.02.2023 16:41, Juergen Gross wrote:
> --- a/tools/firmware/include/stddef.h
> +++ b/tools/firmware/include/stddef.h
> @@ -1,10 +1,10 @@
> #ifndef _STDDEF_H_
> #define _STDDEF_H_
>
> +#include
> +
> typedef __SIZE_TYPE__ size_t;
>
> #define NULL ((void*)0)
>
> -#define offsetof(t, m
On 27.02.2023 16:46, Michal Orzel wrote:
> On 27/02/2023 16:00, Jan Beulich wrote:
>> On 27.02.2023 15:46, Michal Orzel wrote:
>>> On 27/02/2023 14:54, Jan Beulich wrote:
On 27.02.2023 14:41, Michal Orzel wrote:
> On 27/02/2023 11:10, Jan Beulich wrote:
>> On 27.02.2023 10:53, Michal O
On 24/02/2023 6:50 pm, 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 vmx.h.
>
> No functional change intended.
>
> Signed-off-by: Xenia Ragiadakou
On 27.02.2023 16:57, Jan Beulich wrote:
> Well, I'm not outright opposed. But I definitely want to hear another
> maintainer's view before deciding.
Oh, and I should have added: If to be taken, the description would need
extending to explain why the simple route is taken here, and why it is
deemed
On 23.02.2023 18:39, Sergey Dyasli wrote:
> 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_p
On Mon, Feb 27, 2023 at 04:41:50PM +0100, Juergen Gross wrote:
> In order to better reflect the contents of the header and to make it
> more appropriate to use it for different runtime environments like
> programs, libraries, and firmware, rename the libs.h include file to
> common-macros.h. Additi
On 24/02/2023 6:50 pm, Xenia Ragiadakou wrote:
> Create two new private headers in arch/x86/hvm/vmx called vmx.h and pi.h.
> Move all the definitions and declarations that are used solely by vmx code
> into the private vmx.h, apart from the ones related to posted interrupts that
> are moved into pi
On 27/02/2023 4:26 pm, Andrew Cooper wrote:
> On 24/02/2023 6:50 pm, Xenia Ragiadakou wrote:
>> Create two new private headers in arch/x86/hvm/vmx called vmx.h and pi.h.
>> Move all the definitions and declarations that are used solely by vmx code
>> into the private vmx.h, apart from the ones rela
On Sat, 2023-02-25 at 17:53 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/02/2023 15:06, Oleksii Kurochko wrote:
> > Mostly the code for setup_initial_pages was taken from Bobby's
> > repo except for the following changes:
> > * Use only a minimal part of the code enough to enable MMU
> > * r
On 26.02.2023 01:08, Marek Marczykowski-Górecki wrote:
> If the scope for IGD's IOMMU contains additional device that doesn't
> actually exist, iommu=no-igfx would not disable that IOMMU. In this
> particular case (Thinkpad x230) it included
> 00:02.1, but there is no such device on this platform.
On Sat, 2023-02-25 at 18:05 +, Julien Grall wrote:
> Hi,
>
> On 24/02/2023 15:06, Oleksii Kurochko wrote:
> > Calculate load and linker linker image addresses and
> > setup initial pagetables.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > xen/arch/riscv/setup.c | 11 +++
> >
Hi Oleksii,
On 27/02/2023 16:52, Oleksii wrote:
On Sat, 2023-02-25 at 17:53 +, Julien Grall wrote:
+/*
+ * WARNING: load_addr() and linker_addr() are to be called only
when the MMU is
+ * disabled and only when executed by the primary CPU. They
cannot refer to
+ * any global variable or fu
Hi,
On 27/02/2023 17:17, Oleksii wrote:
On Sat, 2023-02-25 at 18:05 +, Julien Grall wrote:
Hi,
On 24/02/2023 15:06, Oleksii Kurochko wrote:
Calculate load and linker linker image addresses and
setup initial pagetables.
Signed-off-by: Oleksii Kurochko
---
xen/arch/riscv/setup.c | 11 +
On Mon, Feb 27, 2023 at 12:10:48PM +0100, Thomas Huth wrote:
> We're struggling quite badly with our CI minutes on the shared
> gitlab runners, so we urgently need to think of ways to cut down
> our supported build and target environments. qemu-system-i386 and
> qemu-system-arm are not really requi
On Mon, Feb 27, 2023 at 09:35:51AM +0100, Jan Beulich wrote:
> On 25.02.2023 21:37, Demi Marie Obenour wrote:
> > --- a/Config.mk
> > +++ b/Config.mk
> > @@ -191,7 +191,7 @@ APPEND_CFLAGS += $(foreach i, $(APPEND_INCLUDES),
> > -I$(i))
> > EMBEDDED_EXTRA_CFLAGS := -fno-pie -fno-stack-protector
>
On 09/09/2022 3:30 pm, Jan Beulich wrote:
> Gcc12 takes issue with core_parking_remove()'s
>
> for ( ; i < cur_idle_nums; ++i )
> core_parking_cpunum[i] = core_parking_cpunum[i + 1];
>
> complaining that the right hand side array access is past the bounds of
> 1. Clearly the compiler can'
On 27/02/2023 7:43 pm, Andrew Cooper wrote:
> On 09/09/2022 3:30 pm, Jan Beulich wrote:
>> select HAS_ALTERNATIVE
>> select HAS_COMPAT
>> select HAS_CPUFREQ
>> --- a/xen/arch/x86/platform_hypercall.c
>> +++ b/xen/arch/x86/platform_hypercall.c
>> @@ -727,12 +727,17 @@ ret_t do_platform_o
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
> I feel like we should have separate deprecation entries for the
> i686 host support, and for qemu-system-i386 emulator binary, as
> although they're related they are independant features with
> differing impact. eg removing qemu-
On Mon, Feb 27, 2023 at 09:25:32AM +0100, Jan Beulich wrote:
> On 24.02.2023 23:55, Demi Marie Obenour wrote:
> > On Tue, Feb 21, 2023 at 11:07:58AM +0100, Jan Beulich wrote:
> >> On 19.02.2023 03:46, Demi Marie Obenour wrote:
> >>> --- a/stubdom/configure
> >>> +++ b/stubdom/configure
> >>> @@ -35
On 2/27/23 10:12, Michael S. Tsirkin wrote:
On Mon, Feb 27, 2023 at 11:50:07AM +, Daniel P. Berrangé wrote:
I feel like we should have separate deprecation entries for the
i686 host support, and for qemu-system-i386 emulator binary, as
although they're related they are independant features w
On 2/27/23 01:50, Daniel P. Berrangé wrote:
On Mon, Feb 27, 2023 at 12:10:49PM +0100, Thomas Huth wrote:
Hardly anybody still uses 32-bit x86 hosts today, so we should
start deprecating them to finally have less test efforts.
With regards to 32-bit KVM support in the x86 Linux kernel,
the develo
On Mon, Feb 27, 2023 at 09:42:24AM +0100, Jan Beulich wrote:
> On 25.02.2023 21:37, Demi Marie Obenour wrote:
> > --- a/stubdom/configure
> > +++ b/stubdom/configure
> > @@ -3545,7 +3545,7 @@ if test "x$LIBPCI_URL" = "x"; then :
> > if test "x$extfiles" = "xy"; then :
> >LIBPCI_URL=\$\(XEN_
1 - 100 of 124 matches
Mail list logo
