On 01-03-23, 12:29, Stefan Hajnoczi wrote:
> What is the advantage over defining separate messages? Separate messages
> are cleaner and more typesafe.
I thought we wanted to keep single message for one kind of functionality, which
is mmap related quirks here. And so it would be better if we can re
Hello,
in (I think) Intel SDM version 076 a new guarantee of atomicity of certain
aligned 16-byte accesses appeared. While initially I thought this would be
another special case we need to invent a solution for (it still is, in
certain cases, as per further down), I had to realize that we don't ev
> On 2 Mar 2023, at 00:21, Stefano Stabellini wrote:
>
> On Wed, 1 Mar 2023, Luca Fancellu wrote:
>> Add entries to the exclude-list.json for those files that need to be
>> excluded from the analysis scan.
>>
>> Signed-off-by: Luca Fancellu
>> Signed-off-by: Michal Orzel
>
>
> I checked t
The patch series is based on the patch [1].
A large part of the content of the bug.h is repeated among all
architectures (especially x86 and RISCV have the same implementation), so it
was created a new config CONFIG_GENERIC_BUG_FRAME which is used to
introduce generic implementation of do_bug_fram
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 do_invalid_op using generic do_bug_frame()
Signed-off-by:
The idea of the patch is to change all to and
keep Xen compilable with adding only minimal amount of changes:
1. It was added "#include " to ARM's "" as it
uses uint_{16,32}t in 'struct bug_frame'.
2. It was added '#define BUG_FRAME_STRUCT' which means that ARM hasn't
been switched to generic
The following changes were made:
* make GENERIC_BUG_FRAME mandatory for ARM
* As do_bug_frame() returns -EINVAL in case something goes wrong
otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
updated to check if the returned value is less than 0
* Switch ARM's implementation
A large part of the content of the bug.h is repeated among all
architectures, so it was decided to create a new config
CONFIG_GENERIC_BUG_FRAME.
The version of from x86 was taken as the base version.
The patch introduces the following stuff:
* common bug.h header
* generic implementation of
On 02/03/2023 08:35, Jan Beulich wrote:
Hello,
in (I think) Intel SDM version 076 a new guarantee of atomicity of certain
aligned 16-byte accesses appeared. While initially I thought this would be
another special case we need to invent a solution for (it still is, in
certain cases, as per furthe
On 01/03/2023 20:54, Michael S. Tsirkin wrote:
On Sat, Feb 04, 2023 at 11:07:37PM -0500, Alexander Bulekov wrote:
This protects devices from bh->mmio reentrancy issues.
Reviewed-by: Darren Kenny
Reviewed-by: Stefan Hajnoczi
Signed-off-by: Alexander Bulekov
Reviewed-by: Michael S. Tsirkin
flight 178922 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178922/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 178771
test-amd64-i386-xl-qemuu-win7-amd64
On 01.03.2023 19:01, Sergey Dyasli wrote:
> On Wed, Mar 1, 2023 at 11:31 AM Jan Beulich wrote:
>> On 28.02.2023 18:39, Sergey Dyasli wrote:
>>> Add an option to xen-ucode tool to print the currently loaded ucode
>>> version and also print it during usage info. Print CPU signature and
>>> processo
On 01.03.2023 21:55, Andrew Cooper wrote:
> On 15/12/2022 8:20 am, Jan Beulich wrote:
>> core_set_legacy_ssbd() counts the number of times SSBD is being enabled
>> via LS_CFG on a core. This assumes that calls there only occur if the
>> state actually changes. While svm_ctxt_switch_{to,from}() conf
On 01.03.2023 21:38, Julien Grall wrote:
> On 01/03/2023 17:50, Julien Grall wrote:
>> I got the answer. The problem now is gitlab only keep the artifact for
>> the latest build and it only provide a zImage (having the ELF would be
>> easier).
>>
>> I will try to reproduce the error on my end.
>
On 02.03.2023 10:20, Oleksii Kurochko wrote:
> The following changes were made:
> * make GENERIC_BUG_FRAME mandatory for ARM
> * As do_bug_frame() returns -EINVAL in case something goes wrong
> otherwise id of bug frame. Thereby 'if' cases where do_bug_frame() was
> updated to check if the retu
On 02.03.2023 10:23, Paul Durrant wrote:
> On 02/03/2023 08:35, Jan Beulich wrote:
>> Hello,
>>
>> in (I think) Intel SDM version 076 a new guarantee of atomicity of certain
>> aligned 16-byte accesses appeared. While initially I thought this would be
>> another special case we need to invent a sol
On Thu, 2023-03-02 at 10:55 +0100, Jan Beulich wrote:
> On 02.03.2023 10:20, Oleksii Kurochko wrote:
> > The following changes were made:
> > * make GENERIC_BUG_FRAME mandatory for ARM
> > * As do_bug_frame() returns -EINVAL in case something goes wrong
> > otherwise id of bug frame. Thereby 'if'
flight 178942 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 178838
test-amd64-amd64-libvir
>> +Exclude file list for xen-analysis script
>> +=
>> +
>> +The code analysis is performed on the Xen codebase for both MISRA checkers
>> and
>> +static analysis checkers, there are some files however that needs to be
>> removed
>> +from the findings repo
Hi,
On 02/03/2023 09:45, Jan Beulich wrote:
On 01.03.2023 21:38, Julien Grall wrote:
On 01/03/2023 17:50, Julien Grall wrote:
I got the answer. The problem now is gitlab only keep the artifact for
the latest build and it only provide a zImage (having the ELF would be
easier).
I will try to re
On 02.03.2023 12:01, Julien Grall wrote:
> On 02/03/2023 09:45, Jan Beulich wrote:
>> On 01.03.2023 21:38, Julien Grall wrote:
>>> I managed to reproduce it. It looks like that after your bug patch,
>>> *(.rodata.*) will not be end on a 4-byte boundary. Before your patch,
>>> all the messages will
Quoting b5d8b03db136 ("x86/shadow: Drop dubious lastpage diagnostic"):
"This is a global variable (actually 3, one per GUEST_PAGING_LEVEL), operated
on using atomics only (with no regard to what else shares the same cacheline),
which emits a diagnostic (in debug builds only) without changing any
On Thu, Mar 02, 2023 at 01:49:07PM +0530, Viresh Kumar wrote:
> On 01-03-23, 12:29, Stefan Hajnoczi wrote:
> > What is the advantage over defining separate messages? Separate messages
> > are cleaner and more typesafe.
>
> I thought we wanted to keep single message for one kind of functionality,
On 02/03/2023 12:06 pm, Jan Beulich wrote:
> Quoting b5d8b03db136 ("x86/shadow: Drop dubious lastpage diagnostic"):
>
> "This is a global variable (actually 3, one per GUEST_PAGING_LEVEL), operated
> on using atomics only (with no regard to what else shares the same
> cacheline),
> which emits a
Hi Jiamei,
Patch looks good apart from minor comments down below.
On 02/03/2023 05:46, jiamei.xie wrote:
>
>
> From: jiamei Xie
>
> Add a new config parameter to configure static heap.
> STATIC_HEAP="baseaddr1 size1 ... baseaddrN sizeN"
> if specified, indicates the host physical address regi
Provide support for this insn, which is a prereq to FRED. CPUID-wise
introduce both its and FRED's bit at this occasion, thus allowing to
also express the dependency right away.
While adding a testcase, also add a SWAPGS one. In order to not affect
the behavior of pre-existing tests, install write
On Mon, Feb 27, 2023 at 02:29:29PM -0800, Rick Edgecombe wrote:
> [0]
> https://lore.kernel.org/lkml/0e29a2d0-08d8-bcd6-ff26-4bea0e403...@redhat.com/#t
I guess that sub-thread about how you arrived at this "pass a VMA"
decision should be in the Link tag. But that's for the committer, I'd
say.
Th
Hi Jan,
On 02/03/2023 11:21, Jan Beulich wrote:
On 02.03.2023 12:01, Julien Grall wrote:
On 02/03/2023 09:45, Jan Beulich wrote:
On 01.03.2023 21:38, Julien Grall wrote:
I managed to reproduce it. It looks like that after your bug patch,
*(.rodata.*) will not be end on a 4-byte boundary. Befo
Signed-off-by: Oleksii Kurochko
---
Changes since v1:
* initialization of .bss was moved to head.S
---
xen/arch/riscv/include/asm/asm.h | 4
xen/arch/riscv/riscv64/head.S| 9 +
2 files changed, 13 insertions(+)
diff --git a/xen/arch/riscv/include/asm/asm.h b/xen/arch/riscv/incl
Disable FPU to detect illegal usage of floating point in kernel
space.
Signed-off-by: Oleksii Kurochko
---
Changes since v1:
* Rebase on top of two previous patches.
---
xen/arch/riscv/setup.c | 8
1 file changed, 8 insertions(+)
diff --git a/xen/arch/riscv/setup.c b/xen/arch/riscv/se
Signed-off-by: Oleksii Kurochko
---
Changes since v1:
* read/save/pass of hart_id and dtb_base passed by a bootloader
were moved to head.S.
* Update start_xen() to recieve hard_id & dtb_base
---
xen/arch/riscv/riscv64/head.S | 24
xen/arch/riscv/setup.c| 3
The patch series groups and updates the following patches:
1. xen/riscv: disable fpu
2. xen/riscv: initialize .bss section
3. xen/riscv: read/save hart_id and dtb_base passed by bootloader
---
Changes since v1:
* initialization of .bss was moved to head.S
* read/save/pass of hart_id and dtb_bas
On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/riscv64/head.S b/xen/arch/riscv/riscv64/head.S
> index ffd95f9f89..851b4691a5 100644
> --- a/xen/arch/riscv/riscv64/head.S
> +++ b/xen/arch/riscv/riscv64/head.S
> @@ -6,8 +7,31 @@ ENTRY(start)
> /* Mask all interr
On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes since v1:
> * initialization of .bss was moved to head.S
> ---
> xen/arch/riscv/include/asm/asm.h | 4
> xen/arch/riscv/riscv64/head.S| 9 +
> 2 files changed, 13 insertions(+)
>
> d
On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> Disable FPU to detect illegal usage of floating point in kernel
> space.
>
> Signed-off-by: Oleksii Kurochko
> ---
> Changes since v1:
> * Rebase on top of two previous patches.
> ---
Apologies - I meant to ask these on the previous series, but di
On 02.03.2023 14:23, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/riscv64/head.S
> +++ b/xen/arch/riscv/riscv64/head.S
> @@ -13,6 +13,15 @@ ENTRY(start)
> lla a6, _dtb_base
> REG_S a1, (a6)
>
> +la a3, __bss_start
> +la a4, __bss_end
> +
Checking for what $(SIMD) contains was initially right, but already the
addition of $(FMA) wasn't. Later categories (correctly) weren't added.
Instead what is of interest is anything the main harness source file
uses outside of suitable #if and without resorting to .byte, as that's
the one file (co
Hi Oleksii,
On 02/03/2023 07:34, Oleksii wrote:
Hi Julien,
On Wed, 2023-03-01 at 16:21 +, Julien Grall wrote:
Hi Oleksii,
On 01/03/2023 16:14, Oleksii Kurochko wrote:
During testing of bug.h's macros generic implementation
yocto-
qemuarm
job crashed with data abort:
The commit message
On Thu, 2023-03-02 at 14:02 +, Andrew Cooper wrote:
> On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/riscv64/head.S
> > b/xen/arch/riscv/riscv64/head.S
> > index ffd95f9f89..851b4691a5 100644
> > --- a/xen/arch/riscv/riscv64/head.S
> > +++ b/xen/arch/riscv/riscv6
On Thu, 2023-03-02 at 14:12 +, Andrew Cooper wrote:
> On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes since v1:
> > * initialization of .bss was moved to head.S
> > ---
> > xen/arch/riscv/include/asm/asm.h | 4
> > xen/arch/riscv/ri
From: Julien Grall
Hi all,
Currently, Xen on Arm will switch TTBR whilst the MMU is on. This is
similar to replacing existing mappings with new ones. So we need to
follow a break-before-make sequence.
When switching the TTBR, we need to temporarily disable the MMU
before updating the TTBR. This
From: Julien Grall
At the moment, the temporary mapping is only used when the virtual
runtime region of Xen is clashing with the physical region.
In follow-up patches, we will rework how secondary CPU bring-up works
and it will be convenient to use the fixmap area for accessing
the root page-tab
From: Julien Grall
In follow-up patches we will need to have part of Xen identity mapped in
order to safely switch the TTBR.
On some platform, the identity mapping may have to start at 0. If we always
keep the identity region mapped, NULL pointer dereference would lead to
access to valid mapping
From: Julien Grall
At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
still on.
Switching TTBR is like replacing existing mappings with new ones. So
we need to follow the break-before-make sequence.
In this case, it means the MMU needs to be switched off while the
TTBR is upda
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 is the page-tables should
contain an identity mapping of the code switching th
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.
The arm32 code will use a different approach. So this issue is for now
o
Hi Jens,
> On 22 Feb 2023, at 16:33, Jens Wiklander wrote:
>
> Adds support in the mediator to map and unmap the RX and TX buffers
> provided by the guest using the two FF-A functions FFA_RXTX_MAP and
> FFA_RXTX_UNMAP.
>
> These buffer are later used to to transmit data that cannot be passed in
Hi Julien,
> -Original Message-
> Subject: [PATCH v6 3/5] xen/arm64: mm: Introduce helpers to
> prepare/enable/disable the identity mapping
>
> From: Julien Grall
>
> In follow-up patches we will need to have part of Xen identity mapped in
> order to safely switch the TTBR.
>
> On some
From: David Woodhouse
Whem emulating Xen, multi-page grants are distinctly non-trivial and we
have elected not to support them for the time being. Don't advertise
them to the guest.
Signed-off-by: David Woodhouse
---
hw/block/xen-block.c | 11 ---
1 file changed, 8 insertions(+), 3 del
From: Paul Durrant
The xen-block code ends up calling aio_poll() through blkconf_geometry(),
which means we see watch events during the indirect call to
xendev_class->realize() in xen_device_realize(). Unfortunately this call
is made before populating the initial frontend and backend device nodes
From: David Woodhouse
We provided the backend-facing evtchn functions very early on as part of
the core Xen platform support, since things like timers and xenstore need
to use them.
By what may or may not be an astonishing coincidence, those functions
just *happen* all to have exactly the right
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 70 ++
1 file changed, 70 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index 1b1358ad4c..5a8e38aae7 100644
-
From: David Woodhouse
XC_PAGE_SIZE comes from the actual Xen libraries, while XEN_PAGE_SIZE is
provided by QEMU itself in xen_backend_ops.h. For backends which may be
built for emulation mode, use the latter.
Signed-off-by: David Woodhouse
---
hw/block/dataplane/xen-block.c | 8
hw/d
From: Paul Durrant
Store perms as a GList of strings, check permissions.
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 2 +-
hw/i386/kvm/xenstore_impl.c | 259 +---
hw/i386/kvm/xenstore_impl.h | 8 +-
tests/uni
From: David Woodhouse
This header is now only for native Xen code, not PV backends that may be
used in Xen emulation. Since the toolstack libraries may depend on the
specific version of Xen headers that they pull in (and will set the
__XEN_TOOLS__ macro to enable internal definitions that they de
From: David Woodhouse
Now that we have the redirectable Xen backend operations we can build the
PV backends even without the Xen libraries.
Signed-off-by: David Woodhouse
---
hw/9pfs/meson.build| 2 +-
hw/block/dataplane/meson.build | 2 +-
hw/block/meson.build | 2 +-
hw
From: David Woodhouse
There's no need for this to be in the Xen accel code, and as we want to
use the Xen console support with KVM-emulated Xen we'll want to have a
platform-agnostic version of it. Make it use GString to build up the
path while we're at it.
Signed-off-by: David Woodhouse
---
a
From: David Woodhouse
This is a fairly simple implementation of a copy-on-write tree.
The node walk function starts off at the root, with 'inplace == true'.
If it ever encounters a node with a refcount greater than one (including
the root node), then that node is shared with other trees, and can
From: David Woodhouse
Signed-off-by: David Woodhouse
Signed-off-by: Paul Durrant
---
hw/char/xen_console.c| 8 +++---
hw/display/xenfb.c | 20 +++---
hw/xen/xen-operations.c | 45
include/hw/xen/xen_backend_ops.h | 26
From: David Woodhouse
Starts out fairly simple: a hash table of watches based on the path.
Except there can be multiple watches on the same path, so the watch ends
up being a simple linked list, and the head of that list is in the hash
table. Which makes removal a bit of a PITA but it's not so b
From: David Woodhouse
The previous commit introduced redirectable gnttab operations fairly
much like-for-like, with the exception of the extra arguments to the
->open() call which were always NULL/0 anyway.
This *changes* the arguments to the ->unmap() operation to include the
original ref# that
From: David Woodhouse
Now that all the work is done to enable the PV backends to work without
actual Xen, instantiate the bus from pc_basic_device_init() for emulated
mode.
This allows us finally to launch an emulated Xen guest with PV disk.
qemu-system-x86_64 -serial mon:stdio -M q35 -cpu h
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/i386/kvm/xen_xenstore.c b/hw/i386/kvm/xen_xenstore.c
index 028f80499e..f9b7387024 100644
--- a/hw/i386/kvm/xen_xenstore.c
+++ b/hw/i386/kv
Now that the basic platform support is hopefully on the cusp of being
merged, here's phase 2 which wires up the XenBus and PV back ends.
It starts with a basic single-tenant internal implementation of a
XenStore, with a copy-on-write tree, watches, transactions, quotas.
Then we introduce operat
From: David Woodhouse
Move the existing code using libxengnttab to xen-operations.c and allow
the operations to be redirected so that we can add emulation of grant
table mapping for backend drivers.
In emulation, mapping more than one grant ref to be virtually contiguous
would be fairly difficul
From: David Woodhouse
Given that the whole thing supported copy on write from the beginning,
transactions end up being fairly simple. On starting a transaction, just
take a ref of the existing root; swap it back in on a successful commit.
The main tree has a transaction ID too, and we keep a rec
From: David Woodhouse
The existing implementation calling into the real libxenevtchn moves to
a new file hw/xen/xen-operations.c, and is called via a function table
which in a subsequent commit will also be able to invoke the emulated
event channel support.
Signed-off-by: David Woodhouse
Signed
From: David Woodhouse
In fact I think we want to only serialize the contents of the domain's
path in /local/domain/${domid} and leave the rest to be recreated? Will
defer to Paul for that.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/xen_xenstore.c | 25 +-
hw/i386/kvm/xenstore_impl.c | 57
From: David Woodhouse
This implements the basic wire protocol for the XenStore commands, punting
all the actual implementation to xs_impl_* functions which all just return
errors for now.
Signed-off-by: David Woodhouse
---
hw/i386/kvm/meson.build | 1 +
hw/i386/kvm/trace-events| 15
From: David Woodhouse
This is limited to mapping a single grant at a time, because under Xen the
pages are mapped *contiguously* into qemu's address space, and that's very
hard to do when those pages actually come from anonymous mappings in qemu
in the first place.
Eventually perhaps we can look
From: David Woodhouse
This is only part of it; we will also need to get the PV back end drivers
to tear down their own mappings (or do it for them, but they kind of need
to stop using the pointers too).
Some more work on the actual PV back ends and xen-bus code is going to be
needed to really ma
From: David Woodhouse
Firing watches on the nodes that still exist is relatively easy; just
walk the tree and look at the nodes with refcount of one.
Firing watches on *deleted* nodes is more fun. We add 'modified_in_tx'
and 'deleted_in_tx' flags to each node. Nodes with those flags cannot
be sh
From: David Woodhouse
Now that we have an internal implementation of XenStore, we can populate
the xenstore_backend_ops to allow PV backends to talk to it.
Watches can't be processed with immediate callbacks because that would
call back into XenBus code recursively. Defer them to a QEMUBH to be
From: Paul Durrant
Signed-off-by: Paul Durrant
Signed-off-by: David Woodhouse
---
accel/xen/xen-all.c | 11 +-
hw/char/xen_console.c | 2 +-
hw/i386/kvm/xen_xenstore.c | 3 -
hw/i386/kvm/xenstore_impl.h | 8 +-
hw/xen/xen-bus-helper.c
Hi Julien,
> On 2 Mar 2023, at 15:59, Julien Grall wrote:
>
> From: Julien Grall
>
> At the moment, the temporary mapping is only used when the virtual
> runtime region of Xen is clashing with the physical region.
>
> In follow-up patches, we will rework how secondary CPU bring-up works
> and
On Thu, 2023-03-02 at 15:22 +0100, Jan Beulich wrote:
> On 02.03.2023 14:23, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/riscv64/head.S
> > +++ b/xen/arch/riscv/riscv64/head.S
> > @@ -13,6 +13,15 @@ ENTRY(start)
> > lla a6, _dtb_base
> > REG_S a1, (a6)
> >
> > +
On 02.03.2023 16:55, Oleksii wrote:
> On Thu, 2023-03-02 at 15:22 +0100, Jan Beulich wrote:
>> On 02.03.2023 14:23, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/riscv64/head.S
>>> +++ b/xen/arch/riscv/riscv64/head.S
>>> @@ -13,6 +13,15 @@ ENTRY(start)
>>> lla a6, _dtb_base
>>>
flight 178951 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178951/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-freebsd12-amd64 8 xen-boot fail REGR. vs. 178042
test-amd64-amd64-qe
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
Hardly anybody still uses 32-bit x86 hosts today, so we should start
deprecating them to stop wasting our time and CI minutes here.
For example, there are also still some unresolved problems with these:
When emulating 64-bit binaries in user mode, TCG does not honor atomicity
for 64-bit accesses, w
Hardly anybody really requires the i386 binary anymore, since the
qemu-system-x86_64 binary is a proper superset. So let's deprecate
the 32-bit variant now, so that we can finally stop wasting our time
and CI minutes with this.
With regards to 32-bit KVM support in the x86 Linux kernel,
the develo
Hardly anybody still uses 32-bit x86 environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 16
1 file changed, 16 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab
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.
For running QEMU in system emulation mode, the user needs a rather
strong host system, i.e. not only an embedded low-frequency controller.
All recent beefy arm host machines should support 64-bit now, it's
unlikely that anybody is still seriously using QEMU on a 32-bit arm
CPU, so we deprecate the
Hardly anybody still uses 32-bit arm environments for running QEMU,
so let's stop wasting our scarce CI minutes with these jobs.
Signed-off-by: Thomas Huth
---
.gitlab-ci.d/crossbuilds.yml | 14 --
1 file changed, 14 deletions(-)
diff --git a/.gitlab-ci.d/crossbuilds.yml b/.gitlab-c
flight 178990 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/178990/
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 Thu, 2023-03-02 at 14:20 +, Andrew Cooper wrote:
> On 02/03/2023 1:23 pm, Oleksii Kurochko wrote:
> > Disable FPU to detect illegal usage of floating point in kernel
> > space.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes since v1:
> > * Rebase on top of two previous patche
On Thu, 2023-03-02 at 14:50 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 02/03/2023 07:34, Oleksii wrote:
> > Hi Julien,
> > > > > On Wed, 2023-03-01 at 16:21 +, Julien Grall wrote:
> > > > > > Hi Oleksii,
> > > > > >
> > > > > > On 01/03/2023 16:14, Oleksii Kurochko wrote:
> > > > > > > D
Only run this on the staging branch, whenever the dockerfile changes.
Allow to set a suffix when building containers, to be able to test it
before changing the one in production.
Using "rules" instead of "only" as this allow to use variables in the
"changes" rules. Also, "rules" is the preferred
Jobs in the "test-containers" stage will be used to check that the
newly built container is working fine, and that it could be used in
production.
Need to rename jobs name compared to "build.yaml", adding "test-"
prefix to all build jobs.
Need also to rename templates as many of them are used wit
For the test-containers jobs, mostly copy from "build.yaml", rename
'.container-*-tmpl' templates to '.container-*-testtmpl', prefix build
jobs with "test-", add BUILD_CONTAINER and "needs" to container
template.
Signed-off-by: Anthony PERARD
---
Notes:
WARNING: This is an incomplete list of
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.gitlab-containers-auto-rebuild-v1
Hi,
I have done some research to be able to build containers in the CI. This works
only for x86 containers as I've setup only a single x86 gitlab-runne
This allow to start a pipeline manually and set a variable to test the
build of a single container, e.g.
DO_REBUILD_CONTAINER = ubuntu/xenial
Signed-off-by: Anthony PERARD
---
automation/gitlab-ci/containers.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/automation/gitlab-ci/contai
Have one template per container, which each build job will extend.
This will allow to add more variable which are linked to a used
container.
Signed-off-by: Anthony PERARD
---
automation/gitlab-ci/build.yaml | 327
1 file changed, 202 insertions(+), 125 deletions
Now, we can run a pipeline and set two variables to have a container
been rebuilt, tested, and pushed.
Variables:
DO_REBUILD_CONTAINER = "ubuntu/xenial"
PUSH_CONTAINER = 1
Or if PUSH_CONTAINER is set on a gitlab project "xen-project/xen", a
change on the dockerfile can result in a contain
Signed-off-by: Anthony PERARD
---
Notes:
WARNING: This is an incomplete list of jobs needed to push.
automation/gitlab-ci/push-containers.yaml | 49 +++
1 file changed, 49 insertions(+)
diff --git a/automation/gitlab-ci/push-containers.yaml
b/automation/gitlab-ci/push-
On Thu, Mar 02, 2023 at 05:31:01PM +0100, Thomas Huth wrote:
> Hardly anybody really requires the i386 binary anymore, since the
> qemu-system-x86_64 binary is a proper superset. So let's deprecate
> the 32-bit variant now, so that we can finally stop wasting our time
> and CI minutes with this.
T
On Thu, Mar 02, 2023 at 05:31:02PM +0100, Thomas Huth wrote:
> Hardly anybody still uses 32-bit x86 hosts today, so we should start
> deprecating them to stop wasting our time and CI minutes here.
> For example, there are also still some unresolved problems with these:
> When emulating 64-bit binar
On Thu, Mar 02, 2023 at 05:31:03PM +0100, Thomas Huth wrote:
> Hardly anybody still uses 32-bit x86 environments for running QEMU,
> so let's stop wasting our scarce CI minutes with these jobs.
>
> Signed-off-by: Thomas Huth
> ---
> .gitlab-ci.d/crossbuilds.yml | 16
> 1 file ch
On Thu, Mar 02, 2023 at 05:31:04PM +0100, Thomas Huth wrote:
> 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 w
1 - 100 of 135 matches
Mail list logo
