On 27/02/2023 21.25, Richard Henderson wrote:
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
On 27/02/2023 21.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
On 27.02.2023 17:26, 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
On 27/02/2023 23.32, Philippe Mathieu-Daudé wrote:
On 27/2/23 21: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
On 27/02/2023 19.38, Daniel P. Berrangé wrote:
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.
On 2/27/23 17:25, Jan Beulich wrote:
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
On 27.02.2023 22:41, George Dunlap wrote:
> Note the following administrative conventions for the call:
> * Unless, agreed in the previous meeting otherwise, the call is on the 1st
> Thursday of each month at 1600 British Time (either GMT or BST)
Since nothing else was said, I suppose the title
On 28.02.2023 08:09, Xenia Ragiadakou wrote:
>
> On 2/27/23 14:17, Jan Beulich wrote:
>> 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
On 2/27/23 14:17, Jan Beulich wrote:
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
Hi,
We encountered a vcpu-set issue on old xen, when I tried to confirm
if xen upstream xen has the same issue I find neither my upstream build
nor ubuntu 22.04 xen-hypervisor-4.16 work.
I can add vcpus(8->16) to my guest but I can not reduce vcpu number:
root@ubuntu2204:~/vm# xl list
Name
flight 178673 xen-unstable real [real]
flight 178720 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/178673/
http://logs.test-lab.xenproject.org/osstest/logs/178720/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 178708 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178708/
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
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Sun, 26 Feb 2023 11:34:29 -0500 you 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]
>
On Mon, 27 Feb 2023 09:29:30 +0100 Juergen Gross wrote:
> 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
On Fri, 24 Feb 2023, Michal Orzel wrote:
> Add a debian container with cppcheck installation routine inside,
> capable of performing cppcheck analysis on Xen-only build including
> cross-builds for arm32 and x86_64.
>
> Populate build jobs making use of that container to run cppcheck
> analysis
On 27/2/23 21: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
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to function
properly.
One of these unusual properties is that shadow stack memory is writable,
but
The x86 Control-flow Enforcement Technology (CET) feature includes a new
type of memory called shadow stack. This shadow stack memory has some
unusual properties, which requires some core mm changes to function
properly.
One of these changes is to allow for pte_mkwrite() to create different
types
flight 178669 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178669/
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
On Fri, 24 Feb 2023, Luca Fancellu wrote:
> Hi Stefano,
>
> >> Hi Jan,
> >>
> >> my personal opinion is that we can’t handle them for files that needs to
> >> be kept
> >> in sync from an external source, because we can’t justify findings or tag
> >> false
> >> positives, if we are lucky we
On Tue, 21 Feb 2023, Pavel Zhukov wrote:
> uboot supports virtio-blk drives and can load kernel image from it.
> Adding option to use '-t virtio' for loading image from virtio device
>
> Signed-off-by: Pavel Zhukov
Reviewed-by: Stefano Stabellini
> ---
> README.md| 14
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/6pAe-+J05tY4OGg2sOobRrhO/ and you can
edit to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
On Fri, 24 Feb 2023, Andrew Cooper wrote:
> Use a single fairly generic string as the "all done" message to look for,
> which avoids the need to patch qemu-smoke-riscv64.sh each time a new feature
> is added.
>
> Signed-off-by: Andrew Cooper
Acked-by: Stefano Stabellini
> ---
> CC: Oleksii
flight 178690 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178690/
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
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 :
> >
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
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
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
> >>> @@
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
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
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
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 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
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
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
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 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 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
> > *
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
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
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.
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
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
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: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
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,
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: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
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 ++--
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
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()
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.
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
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;
+
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.
>
>
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__
>
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
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
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 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)
>
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
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 @@
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
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
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 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):
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
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
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`:
```
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
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
> >
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
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:
>> ---
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
> +++
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
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 {
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
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)=.
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())
+ break;
If we
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)
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
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:
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:
> --- 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
>
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
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
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
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
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
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
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
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 ++--
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
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
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
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
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
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
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
>
>
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
> ---
>
1 - 100 of 124 matches
Mail list logo
