Hi all,
I would like to remind that the feature freeze date for Xen 4.19 is May
17, 2024. If you want your features to be included for the release,
please make sure they are committed by May 17, 2024.
Have a nice day!
Best regards,
Oleksii
On Thu, 2024-05-09 at 16:53 +0100, Andrew Cooper wrote:
> On 08/05/2024 10:38 pm, Leigh Brown wrote:
> > Hello all,
> >
> > I realised over the weekend that there is a valid use case for
> > providing
> > a VIF to a domain that has access to multiple VLANs, e.g. a router.
> > Yes,
> > you can crea
On Fri, 2024-05-10 at 16:20 +0100, Andrew Cooper wrote:
> On 10/05/2024 1:49 pm, Roger Pau Monne wrote:
> > libxl passes some information to libacpi to create the ACPI table
> > for a PVH
> > guest, and among that information it's a bitmap of which vCPUs are
> > online
> > which can be less than th
On Mon, 2024-05-13 at 10:59 +0200, Roger Pau Monne wrote:
> There's no point in forcing a system wide update of the MTRRs on all
> processors
> when there are no changes to be propagated. On AP startup it's only
> the AP
> that needs to write the system wide MTRR values in order to match the
> res
On Thu, 2024-05-09 at 14:13 +0200, Roger Pau Monné wrote:
> On Thu, May 02, 2024 at 03:16:54PM +0200, Jan Beulich wrote:
> > On 02.05.2024 13:49, Roger Pau Monne wrote:
> > > Like it was done recently for libxl, switch to using the auto-
> > > generated feature
> > > names by the processing of cpuf
Hello everyone,
We're observing fewer merged patches/series across several
architectures for the current 4.19 release in comparison to previous
release.
For example:
1. For Arm, significant features like Cache Coloring and PCI
Passthrough won't be fully merged. Thus, it would be beneficial to
com
te email tomorrow if no one objects.
~ Oleksii
>
> Many thanks,
> Kelly Choi
>
> Community Manager
> Xen Project
>
>
> On Wed, May 15, 2024 at 4:13 AM Henry Wang wrote:
> > Hi Oleksii,
> >
> > On 5/14/2024 11:43 PM, Andrew Cooper wrote:
>
On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > Changes in V9:
> > - update return type of fls and flsl() to unsigned int to be
> > aligned with other
> > bit ops.
>
> But this then needs carrying through to ...
>
> > --- a/xen/arch/arm
On Wed, 2024-05-15 at 11:49 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > Changes in V9:
> > - update the defintion of write_atomic macros:
> > drop the return value as this macros isn't expeceted to return
> > something
> > drop unnessary parentheses around p.
On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
> On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > The following generic functions were introduced:
> > * test_bit
> > * generic__test_and_set_bit
> > * generic__test_and_clear_bit
> > * generic__test_and_change_bit
> >
> > Also, the patch intr
On Wed, 2024-05-15 at 16:07 +0200, Jan Beulich wrote:
> On 15.05.2024 15:55, Oleksii K. wrote:
> > On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> > > On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > > > Changes in V9:
> > > > - update return ty
On Wed, 2024-05-15 at 17:41 +0200, Jan Beulich wrote:
> On 15.05.2024 17:29, Oleksii K. wrote:
> > On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
> > > On 06.05.2024 12:15, Oleksii Kurochko wrote:
> > > > The following generic functions were
On Thu, 2024-05-16 at 09:04 +0200, Jan Beulich wrote:
> On 15.05.2024 19:03, Oleksii K. wrote:
> > On Wed, 2024-05-15 at 17:41 +0200, Jan Beulich wrote:
> > > On 15.05.2024 17:29, Oleksii K. wrote:
> > > > On Wed, 2024-05-15 at 10:52 +0200, Jan Beulich wrote:
> >
Hello everyone,
Since there were no objections to extending the Feature Freeze Deadline
Proposal, I would like to inform you that the deadline has been
extended to May 24.
At the moment, I don't see any reason to extend other deadlines, so
they will remain the same.
Have a nice day!
Best regard
On Wed, 2024-05-15 at 09:48 +0200, Jan Beulich wrote:
> Oleksii,
>
> On 15.05.2024 09:34, Nicola Vetrini wrote:
> > Hi all,
> >
> > this series aims to refactor some macros that cause violations of
> > MISRA C Rule
> > 20.7 ("Expressions resulting from the expansion of macro parameters
> > shall
On Wed, 2024-05-15 at 16:30 +0100, Andrew Cooper wrote:
> On 15/05/2024 4:29 pm, Roger Pau Monne wrote:
> > Print the CPU affinity masks as numeric ranges instead of plain
> > hexadecimal
> > bitfields.
> >
> > Signed-off-by: Roger Pau Monné
>
> Ha - I was going to write exactly the same patch,
On Wed, 2024-05-15 at 10:27 -0400, Stewart Hildebrand wrote:
> On 4/18/24 23:53, Jiqian Chen wrote:
> > When a device has been reset on dom0 side, the vpci on Xen
> > side won't get notification, so the cached state in vpci is
> > all out of date compare with the real device state.
> > To solve tha
On Tue, 2024-05-14 at 14:52 +0100, Andrew Cooper wrote:
> On 14/05/2024 1:36 pm, Leigh Brown wrote:
> > Hello,
> >
> > On 2024-05-14 13:07, Andrew Cooper wrote:
> > > On 14/05/2024 9:13 am, Leigh Brown wrote:
> > > > Although using integer comparison to compare doubles kind of
> > > > works, it's
On Tue, 2024-05-14 at 12:13 +0100, Julien Grall wrote:
> Hi,
>
> (+ Oleksii as the release manager)
>
> Chiming into the discussion as there seems there is disagreement.
>
> On 14/05/2024 11:03, Jan Beulich wrote:
> > On 14.05.2024 11:51, Andrew Cooper wrote:
> > > On 14/05/2024 10:25 am, Jan Be
On Thu, 2024-05-16 at 18:08 +0200, Jan Beulich wrote:
> > > for 4.18 we took a relaxed approach towards (simple) changes for
> > > Misra purposes.
> > > I wonder whether you mean to permit the same for 4.19, or whether
> > > series like
> > > this one rather want/need delaying until after branching
On Thu, 2024-05-16 at 12:49 +0200, Jan Beulich wrote:
> > Anyway, I am not sure I understand which approach I should use in
> > this
> > patch. You mentioned that possibly test_and_() can't have a generic
> > form, meaning it won't be a set of arch_test_and_() functions.
> >
> > So, can I rename a
On Wed, 2024-05-15 at 11:09 +0200, Jan Beulich wrote:
> But this then needs carrying through to ...
>
> > --- a/xen/arch/arm/include/asm/arm64/bitops.h
> > +++ b/xen/arch/arm/include/asm/arm64/bitops.h
> > @@ -22,17 +22,15 @@ static /*__*/always_inline unsigned long
> > __ffs(unsigned long word)
>
On Fri, 2024-05-17 at 15:56 +0200, Roger Pau Monne wrote:
> Use the same check that's used in dump_irqs().
>
> Signed-off-by: Roger Pau Monné
> ---
> xen/arch/x86/msi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
> index 19830528b65a..0c9
Hi Andrew,
We can consider this patch series to be in Xen 4.19:
Release-acked-by: Oleksii Kurochko
~ Oleksii
On Tue, 2024-05-21 at 18:15 +0100, Andrew Cooper wrote:
> Misc fixes collected during today's call.
>
> Andrew Cooper (3):
> xen/lzo: Implement COPY{4,8} using memcpy()
> xen/x86: D
On Tue, 2024-05-21 at 13:18 +0200, Jan Beulich wrote:
> On 17.05.2024 15:54, Oleksii Kurochko wrote:
> > To avoid the compilation error below, it is needed to update to
> > places
> > in common/page_alloc.c where flsl() is used as now flsl() returns
> > unsigned int:
> >
> > ./include/xen/kernel.h
Hi Julien,
On Wed, 2024-05-22 at 21:50 +0100, Julien Grall wrote:
> Hi,
>
> Adding Oleksii as the release manager.
>
> On 22/05/2024 19:27, Tamas K Lengyel wrote:
> > On Fri, May 10, 2024 at 8:32 AM Alessandro Zucchelli
> > wrote:
> > >
> > > In order to comply to MISRA C:2012 Rule 8.4 for ARM
On Wed, 2024-05-22 at 12:17 +0200, Jan Beulich wrote:
> The emulation_count field is set only conditionally right now.
> Convert
> all field setting to an initializer, thus guaranteeing that field to
> be
> set to 0 (default initialized) when GUEST_PAGING_LEVELS != 3.
>
> While there also drop the
On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
> Hi Oleksii,
Hi Julien,
>
> On 17/05/2024 14:54, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/arm/arm64/livepatch.c
> > b/xen/arch/arm/arm64/livepatch.c
> > index df2cebedde..4bc8ed9be5 100644
> > --- a/xen/arch/arm/arm64/livepatch.c
>
On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
>
>
> On 23/05/2024 15:11, Oleksii K. wrote:
> > On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
> > > Hi Oleksii,
> > Hi Julien,
> >
> > >
> > > On 17/05/2024 14:54, Oleksii K
On Fri, 2024-05-24 at 08:48 +0200, Jan Beulich wrote:
> On 23.05.2024 18:40, Oleksii K. wrote:
> > On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
> > > On 23/05/2024 15:11, Oleksii K. wrote:
> > > > On Thu, 2024-05-23 at 14:00 +0100, Julien Grall wrote:
On Fri, 2024-05-24 at 09:35 +0200, Jan Beulich wrote:
> On 24.05.2024 09:25, Oleksii K. wrote:
> > On Fri, 2024-05-24 at 08:48 +0200, Jan Beulich wrote:
> > > On 23.05.2024 18:40, Oleksii K. wrote:
> > > > On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
On Thu, 2024-05-23 at 15:33 +0100, Julien Grall wrote:
> > > > #include
> > > >
> > > > +/**
> > > > + * generic__test_and_set_bit - Set a bit and return its old
> > > > value
> > > > + * @nr: Bit to set
> > > > + * @addr: Address to count from
> > > > + *
> > > > + * This operation is no
I think we can consider to have this patch series in Xen 4.19 release:
Release-acked-by: Oleksii Kurochko
~ Oleksii
On Fri, 2024-05-24 at 21:03 +0100, Andrew Cooper wrote:
> bitops.h is a mess. It has grown organtically over many years, and
> forces
> unreasonable repsonsibilities out into the
Hi all,
I would like to remind you that the code freeze date for Xen 4.19 is
May 31, 2024.
I'm okay with bug fixes being committed without my release ack (just CC
me), except in cases where a one of maintainers gives a strong NACK.
Have a nice week!
Best regards,
Oleksii
On Sat, 2024-05-25 at 00:06 +0100, Julien Grall wrote:
> Hi Stefano,
>
> You have sent a new version. But you didn't reply to Juergen's
> comment.
>
> While he is not the maintainer of the Arm code, he is the Xenstore
> maintainer. Even if I agree with this approach I don't feel this is
> right
On Mon, 2024-05-27 at 17:12 +0200, Jan Beulich wrote:
> On 27.05.2024 15:58, Oleksii K. wrote:
> > I would like to remind you that the code freeze date for Xen 4.19
> > is
> > May 31, 2024.
>
> I may be confused: With feature freeze having been last Friday aiui,
> i
On Sun, 2024-04-07 at 16:49 -0400, Jason Andryuk wrote:
> From: Jason Andryuk
>
> Add entry for backendtype=tap support in libxl. blktap needs some
> changes to work with libxl, which haven't been merged. They are
> available from this PR:
> https://github.com/xapi-project/blktap/pull/394
>
>
On Mon, 2024-05-27 at 17:55 +0200, Jan Beulich wrote:
> On 27.05.2024 17:52, Oleksii K. wrote:
> > On Mon, 2024-05-27 at 17:12 +0200, Jan Beulich wrote:
> > > On 27.05.2024 15:58, Oleksii K. wrote:
> > > > I would like to remind you that the code freeze date f
On Tue, 2024-05-28 at 08:20 +0200, Jan Beulich wrote:
> On 24.05.2024 13:08, Oleksii Kurochko wrote:
> > The following generic functions were introduced:
> > * test_bit
> > * generic__test_and_set_bit
> > * generic__test_and_clear_bit
> > * generic__test_and_change_bit
> >
> > These functions and
On Tue, 2024-05-28 at 17:37 +0200, Jan Beulich wrote:
> On 28.05.2024 17:32, Andrew Cooper wrote:
> > This avoids having a function call in a typeof() expression.
> >
> > No functional change.
> >
> > Signed-off-by: Andrew Cooper
>
> Acked-by: Jan Beulich
>
Release-Acked-by: Oleksii Kurochko
On Mon, 2024-05-27 at 17:47 +0200, Jan Beulich wrote:
> Oleksii,
>
> On 22.05.2024 10:37, Sergiy Kibrik wrote:
> > Three remaining patches to separate support of Intel & AMD CPUs in
> > Xen build.
> > Most of related patches from previous series had already been
> > merged.
> > Specific changes si
On Tue, 2024-05-21 at 18:15 +0100, Andrew Cooper wrote:
> Misc fixes collected during today's call.
Release-Acked-by: Oleksii Kurochko
>
> Andrew Cooper (3):
> xen/lzo: Implement COPY{4,8} using memcpy()
> xen/x86: Drop useless non-Kconfig CONFIG_* variables
> xen/x86: Address two misc MIS
On Tue, 2024-05-28 at 15:22 +0100, Andrew Cooper wrote:
> ... and move x86's stub_selftest() under this new option.
>
> There is value in having these tests included in release builds too.
>
> It will shortly be used to gate the bitops unit tests on all
> architectures.
>
> Signed-off-by: Andrew
On Wed, 2024-05-29 at 09:24 +0200, Jan Beulich wrote:
> On 17.05.2024 15:33, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series attempts to solve a shortcoming of HVM/PVH
> > guests
> > with the lack of support for foreign mappings. Such lack of
> > support
> > prevents using PVH base
On Tue, 2024-05-28 at 09:53 +0100, Julien Grall wrote:
> > > > +/**
> > > > + * generic_test_bit - Determine whether a bit is set
> > > > + * @nr: bit number to test
> > > > + * @addr: Address to start counting from
> > > > + *
> > > > + * This operation is non-atomic and can be reordered.
> > > >
Hello everyone,
I would like to announce that I have decided to update the Xen 4.19
schedule due to the extended feature freeze period and the upcoming Xen
Summit next week.
I propose the following updates:
Code Freeze: from May 31 to June 7
Hard Code Freeze: from June 21 to June 28
Fina
On Wed, 2024-05-29 at 11:01 +0200, Roger Pau Monne wrote:
> Hello,
>
> The following series aim to fix interrupt handling when doing CPU
> plug/unplug operations. Without this series running:
>
> cpus=`xl info max_cpu_id`
> while [ 1 ]; do
> for i in `seq 1 $cpus`; do
> xen-hptool cp
On Wed, 2024-05-29 at 10:19 +0200, Jan Beulich wrote:
> On 29.05.2024 10:03, Oleksii K. wrote:
> > Hello everyone,
> >
> > I would like to announce that I have decided to update the Xen 4.19
> > schedule due to the extended feature freeze period and the upcoming
&
On Wed, 2024-05-29 at 11:37 +0100, Andrew Cooper wrote:
> {cmci,lmce}_support are written during S3 resume, so cannot live in
> __ro_after_init. Move them back to being __read_mostly, as they were
> originally.
>
> Link: https://gitlab.com/xen-project/xen/-/jobs/6966698361
> Fixes: 19b6e9f9149f (
static always_inline bool test_bit(int nr, const volatile void *addr)On
Wed, 2024-05-29 at 12:06 +0200, Jan Beulich wrote:
> On 29.05.2024 11:59, Julien Grall wrote:
> > Hi,
> >
> > On 29/05/2024 09:36, Jan Beulich wrote:
> > > On 29.05.2024 09:50, Oleksii K. wrote:
On Wed, 2024-05-29 at 17:22 +0200, Jan Beulich wrote:
> On 29.05.2024 16:58, Oleksii K. wrote:
> > static always_inline bool test_bit(int nr, const volatile void
> > *addr)On
> > Wed, 2024-05-29 at 12:06 +0200, Jan Beulich wrote:
> > > On 29.05.2024 11:59, Julien
On Wed, 2024-05-29 at 18:29 +0200, Oleksii K. wrote:
> On Wed, 2024-05-29 at 17:22 +0200, Jan Beulich wrote:
> > On 29.05.2024 16:58, Oleksii K. wrote:
> > > static always_inline bool test_bit(int nr, const volatile void
> > > *addr)On
> > > Wed, 2024-05-
On Thu, 2024-05-30 at 11:14 +0100, Andrew Cooper wrote:
> When reinstating some of systemd.m4 between v1 and v2, I reintroduced
> a little
> too much. While {c,o}xenstored are indeed no longer linked against
> libsystemd, ./configure still looks for it.
>
> Drop this too.
>
> Fixes: ae26101f6bfc
On Thu, 2024-05-30 at 10:44 +0100, Andrew Cooper wrote:
> On 29/05/2024 3:30 pm, Alejandro Vallejo wrote:
> > Alejandro Vallejo (2):
> > tools/xg: Streamline cpu policy serialise/deserialise calls
> > tools/xg: Clean up xend-style overrides for CPU policies
>
> Oleksii: Please consider for 4.1
On Thu, 2024-05-30 at 17:44 +0100, Andrew Cooper wrote:
>
> The subject should say "update Kconfig", because you're not (only)
> disabling.
>
> I'd suggest "xen/riscv: Update Kconfig in preparation for a full Xen
> build".
>
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > Disables unnecessa
On Thu, 2024-05-30 at 10:14 +0200, Roger Pau Monné wrote:
> On Thu, May 30, 2024 at 09:04:08AM +0100, Andrew Cooper wrote:
> > On 30/05/2024 8:53 am, Roger Pau Monne wrote:
> > > For HVM based control domains XENMEM_machine_memory_map must be
> > > available so
> > > that the `e820_host` xl.cfg opt
On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c
> > index 8285bcffef..bda35fc347 100644
> > --- a/xen/arch/riscv/stubs.c
> > +++ b/xen/arch/riscv/stubs.c
> > @@ -24,12 +24,6 @@
On Thu, 2024-05-30 at 17:47 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > diff --git a/README b/README
> > index c8a108449e..30da5ff9c0 100644
> > --- a/README
> > +++ b/README
> > @@ -48,6 +48,10 @@ provided by your OS distributor:
> > - For ARM 64-bit:
>
On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
>
> This patch looks like it can go in independently? Or does it depend
> on
> having bitops.h working in practice?
>
> However
On Thu, 2024-05-30 at 18:45 +0100, Andrew Cooper wrote:
> On 30/05/2024 6:12 pm, Oleksii K. wrote:
> > On Thu, 2024-05-30 at 17:48 +0100, Andrew Cooper wrote:
> > > On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > > > diff --git a/xen/arch/riscv/stubs.c b/xen/ar
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Found when reviewing Oleksii's series to enable the RISC-V build.
>
> The way no_irq_type works is horrifying. Make it less-so.
>
> Andrew Cooper (2):
> arch/irq: Make irq_ack_none() mandatory
> arch/irq: Centralise no_irq_type
>
>
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Any non-stub implementation of these is going to have to do something
> here.
>
> irq_end_none() is more complicated and has arch-specific interactions
> with
> irq_ack_none(), so make it optional.
>
> For PPC, introduce a stub irq_ack_non
On Thu, 2024-05-30 at 19:40 +0100, Andrew Cooper wrote:
> Having no_irq_type defined per arch, but using common callbacks is a
> mess, and
> particualrly hard to bootstrap a new architecture with.
>
> Now that the ack()/end() hooks have been exported suitably, move the
> definition of no_irq_type
On Wed, 2024-05-29 at 15:19 +0100, Andrew Cooper wrote:
> All found while making extensive use of Gitlab CI for the bitops boot
> testing.
>
> For 4.19. It's all very low risk, and improves the
> utility/useability of our
> testing.
Release-Acked-by: Oleksii Kurochko
~ Oleksii
>
> Andrew Coope
On Sat, 2024-06-01 at 21:13 +0200, Nicola Vetrini wrote:
> Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are
> added
> to the list of clean guidelines.
>
> Some guidelines listed in the additional clean section for ARM are
> also
> clean on x86, so they can be removed from there
On Tue, 2024-06-04 at 14:01 +0200, Nicola Vetrini wrote:
> On 2024-06-04 13:39, Oleksii K. wrote:
> > On Sat, 2024-06-01 at 21:13 +0200, Nicola Vetrini wrote:
> > > Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they
> > > are
> > > added
&
On Thu, 2024-06-06 at 18:00 +0200, Jan Beulich wrote:
> Oleksii,
>
> a decision of the session just finished was to deprecate support
> for XeonPhi in 4.19, with the firm plan to remove support in 4.20.
> This will want putting in the release notes.
Thanks for notifing me.
~ Oleksii
On Mon, 2024-06-10 at 08:38 +0200, Jan Beulich wrote:
> To get past the recurring friction on the approach to take wrt
> workarounds needed for various firmware flaws, I'm stepping down as
> the
> maintainer of our code interfacing with EFI firmware. Two new
> maintainers are being introduced in my
On Fri, 2024-06-07 at 12:03 +0200, Roger Pau Monne wrote:
> PVH dom0 is functionally very similar to PVH domU except for the
> domain
> builder and the added set of hypercalls available to it.
>
> The main concern with declaring it "Supported" is the lack of some
> features
> when compared to clas
On Thu, 2024-05-30 at 20:52 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > diff --git a/README b/README
> > index c8a108449e..30da5ff9c0 100644
> > --- a/README
> > +++ b/README
> > @@ -48,6 +48,10 @@ provided by your OS distributor:
> > - For ARM 64-bit:
>
Hi Bertrand and Julien,
On Tue, 2024-06-11 at 07:09 +, Bertrand Marquis wrote:
> Hi Julien and Oleksii,
>
> @Oleksii: Could we consider having this serie merged for next release
> ?
We can consider including it in Xen 4.19 as it has a low impact on
existing systems and needs to be explicitly
On Mon, 2024-06-10 at 16:25 +0100, Andrew Cooper wrote:
> On 10/06/2024 2:32 pm, Marek Marczykowski-Górecki wrote:
> > This tests if QEMU works in PVH dom0. QEMU in dom0 requires
> > enabling TUN
> > in the kernel, so do that too.
> >
> > Add it to both x86 runners, similar to the PVH domU test.
>
On Mon, 2024-06-10 at 17:00 +0200, Jan Beulich wrote:
> On 10.06.2024 16:58, Jan Beulich wrote:
> > mfn_valid() is RAM-focused; it will often return false for MMIO.
> > Yet
> > access to actual MMIO space should not generally be restricted to
> > UC
> > only; especially video frame buffer accesses
On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote:
> On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > Acked-by: Jan Beulich
>
> This patch looks like it can go in independently? Or does it depend
> on
> having bitops.h working in practice?
>
> However
On Tue, 2024-06-11 at 12:35 +, Luca Fancellu wrote:
> + Oleksii
>
> > On 24 May 2024, at 13:40, Luca Fancellu
> > wrote:
> >
> > This serie is a partial rework of this other serie:
> > https://patchwork.kernel.org/project/xen-devel/cover/20231206090623.1932275-1-penny.zh...@arm.com/
> >
> >
On Tue, 2024-06-11 at 13:47 +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
Release-Acked-by: Oleksii Kurochko
~ Oleksii
> ---
> CC: Stefano Stabellini
> CC: Michal Orzel
> CC: Roger Pau Monné
> CC: Oleksii Kurochko
> CC: Jan Beulich
>
> Updated run:
> https://cirrus-ci.com/
On Tue, 2024-06-11 at 16:53 +0100, Andrew Cooper wrote:
> On 30/05/2024 7:22 pm, Oleksii K. wrote:
> > On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote:
> > > On 29/05/2024 8:55 pm, Oleksii Kurochko wrote:
> > > > Signed-off-by: Oleksii Kurochko
> > &
On Wed, 2024-06-12 at 10:44 +0200, Jan Beulich wrote:
> It's hardly ever correct to check for just DOMID_SELF, as guests have
> ways to figure out their domain IDs and hence could instead use those
> as
> inputs to respective hypercalls. Note, however, that for ordinary
> DomU-s
> the adjustment is
On Wed, 2024-06-12 at 10:56 +0200, Jan Beulich wrote:
> On 12.06.2024 10:09, Roger Pau Monné wrote:
> > On Tue, Jun 11, 2024 at 09:42:39AM +0200, Jan Beulich wrote:
> > > On 10.06.2024 16:20, Roger Pau Monne wrote:
> > > > Due to the current rwlock logic, if the CPU calling
> > > > get_cpu_maps() d
On Tue, 2024-06-11 at 09:44 +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > The logic to move interrupts across CPUs is complex, attempt to
> > provide a
> > comment that describes the expected behavior so users of the
> > interrupt system
> > have more context about the
On Tue, 2024-06-11 at 11:59 +0200, Jan Beulich wrote:
> On 10.06.2024 16:20, Roger Pau Monne wrote:
> > The current check used in fixup_irqs() to decide whether to move
> > around
> > interrupts is based on the affinity mask, but such mask can have
> > all bits set,
> > and hence is unlikely to be
On Thu, 2024-06-13 at 10:19 +0200, Jan Beulich wrote:
> Intel CPUs have a MSR bit to limit CPUID enumeration to leaf two. If
> this bit is set by the BIOS then CPUID evaluation does not work when
> data from any leaf greater than two is needed; early_cpu_init() in
> particular wants to collect leaf
On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> mfn_valid() granularity is (currently) 256Mb. Therefore the start of
> a
> 1Gb page passing the test doesn't necessarily mean all parts of such
> a
> range would also pass. Yet using the result of mfn_to_page() on an
> MFN
> which doesn't pass
On Wed, 2024-06-12 at 15:16 +0200, Jan Beulich wrote:
> For non-present entries EMT, like most other fields, is meaningless
> to
> hardware. Make the logic in ept_set_entry() setting the field (and
> iPAT)
> conditional upon dealing with a present entry, leaving the value at 0
> otherwise. This has
On Fri, 2024-06-14 at 09:28 +0200, Roger Pau Monné wrote:
> Sorry, forgot to add the for-4.19 tag and Cc Oleksii.
>
> Since we have taken the start of the series, we might as well take
> the
> remaining patches (if other x86 maintainers agree) and attempt to
> hopefully fix all the interrupt issue
On Fri, 2024-06-14 at 13:49 +0100, Andrew Cooper wrote:
> These being in cache.h is inherited from Linux, but is an
> inappropriate
> location to live.
>
> __read_mostly is an optimisation related to data placement in order
> to avoid
> having shared data in cachelines that are likely to be writte
On Mon, 2024-06-17 at 18:55 +0100, Andrew Cooper wrote:
> struct type_descriptor is arranged with a NUL terminated string
Should it be NULL instead of NUL?
> following the
> kind/info fields.
>
> The only reason this doesn't trip UBSAN detection itself (on more
> modern
> compilers at least) is b
On Mon, 2024-06-17 at 15:18 +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Given the current logic it's possible for ->arch.old_cpu_mask to
> > get out of
> > sync: if a CPU set in old_cpu_mask is offlined and then onlined
> > again without old_cpu_mask having been upda
On Mon, 2024-06-17 at 15:31 +0200, Jan Beulich wrote:
> On 13.06.2024 18:56, Roger Pau Monne wrote:
> > Currently there's logic in fixup_irqs() that attempts to prevent
> > _assign_irq_vector() from failing, as fixup_irqs() is required to
> > evacuate all
> > interrupts from the CPUs not present in
On Fri, 2024-06-14 at 10:47 +0100, Andrew Cooper wrote:
> On 11/06/2024 7:23 pm, Oleksii K. wrote:
> > On Tue, 2024-06-11 at 16:53 +0100, Andrew Cooper wrote:
> > > On 30/05/2024 7:22 pm, Oleksii K. wrote:
> > > > On Thu, 2024-05-30 at 18:23 +0100, Andrew Cooper wrote
On Tue, 2024-06-18 at 14:24 +0100, Andrew Cooper wrote:
> On 19/03/2024 1:26 pm, Jan Beulich wrote:
> > At least XENMEM_memory_exchange can have huge values passed in the
> > nr_extents and nr_exchanged fields. Adding such values to pointers
> > can
> > overflow, resulting in UB. Cast respective po
On Tue, 2024-06-18 at 14:00 +0100, Andrew Cooper wrote:
> When centralising irq_ack_none(), different architectures had
> different names
> for the parameter of irq_ack_none(). As it's type is struct irq_desc
> *, it
> should be named desc. Make this consistent.
>
> No functional change.
>
> Fi
Hi,
On Wed, 2024-06-19 at 09:02 +, Bertrand Marquis wrote:
> Hi,
>
> Adding Oleksii for Release ack.
>
> Cheers
> Bertrand
>
> > On 19 Jun 2024, at 08:46, Michal Orzel
> > wrote:
> >
> > Building Xen with CONFIG_STATIC_SHM=y results in a build failure:
> >
> > arch/arm/static-shmem.c: In
On Mon, 2024-06-17 at 18:39 +0100, Andrew Cooper wrote:
> Only minor changes in v4 vs v3. See patches for details.
>
> The end result has been tested across the entire XenServer hardware
> lab. This
> found several false assupmtion about how the dynamic sizes behave.
Release-Acked-by: Oleksii Ku
On Wed, 2024-06-19 at 13:53 +0200, Jan Beulich wrote:
> On 19.06.2024 11:58, Roger Pau Monne wrote:
> > fixup_irqs() is used to evacuate interrupts from to be offlined
> > CPUs. Given
> > the CPU is to become offline, the normal migration logic used by
> > Xen where the
> > vector in the previous
On Thu, 2024-06-20 at 09:04 +0100, Ross Lagerwall wrote:
> On Thu, Jun 20, 2024 at 8:16 AM Jan Beulich
> wrote:
> >
> > As was made noticeable by the last of the commits referenced below,
> > using a fixed-size type for such purposes is not only against
> > ./CODING_STYLE, but can lead to actual
On Wed, 2024-06-19 at 14:33 +, Anthony PERARD wrote:
> On Wed, Jun 19, 2024 at 02:07:04PM +0200, Jan Beulich wrote:
> > On 16.05.2024 15:52, Jason Andryuk wrote:
> > > On 2024-05-16 03:41, Jan Beulich wrote:
> > > > On 16.05.2024 04:22, Jason Andryuk wrote:
> > > > > From: Jason Andryuk
> > >
On Wed, 2024-06-19 at 13:57 +0200, Jan Beulich wrote:
> On 20.05.2024 19:08, Jason Andryuk wrote:
> > On 2024-05-20 12:44, Leigh Brown wrote:
> > > After the following commit:
> > > 3bc14e4fa4b9 ("tools/libs/light: Add vlan field to
> > > libxl_device_nic")
> > > xl list -l aborts with a double fre
On Thu, 2024-06-20 at 16:16 +0100, Andrew Cooper wrote:
> On 20/06/2024 3:31 pm, Matthew Barnes wrote:
> > There exists a bitshift in the IOAPIC code where a signed integer
> > is
> > shifted to the left by at most 31 bits. This is undefined
> > behaviour,
> > and can cause faults in xtf tests such
On Thu, 2024-06-20 at 17:07 +0100, Andrew Cooper wrote:
> On 20/06/2024 4:34 pm, Jan Beulich wrote:
> > When the left shift amount is up to 31, the shifted quantity wants
> > to be
> > of unsigned int (or wider) type.
> >
> > While there also adjust types: get doesn't alter the array and
> > retur
1 - 100 of 101 matches
Mail list logo
