flight 185929 xen-unstable real [real]
flight 185933 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185929/
http://logs.test-lab.xenproject.org/osstest/logs/185933/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Sun, Apr 07, 2024 at 09:11:42PM -0700, mhkelle...@gmail.com wrote:
> I've wondered if this code for zero'ing the pre- and post-padding
> should go in swiotlb_tbl_map_single(). The bounce buffer proper is
> already being initialized there. But swiotlb_tbl_map_single()
> would need to test for an
flight 185932 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185932/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c12bbc14900aa5c70eec8c0576757c2182db3d01
baseline version:
ovmf
flight 185931 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185931/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 17f333f2a450656101aa4cb46d24b7cf4ee80ebf
baseline version:
ovmf
On Mon, May 06, 2024, Mickaël Salaün wrote:
> On Fri, May 03, 2024 at 07:03:21AM GMT, Sean Christopherson wrote:
> > > ---
> > >
> > > Changes since v1:
> > > * New patch. Making user space aware of Heki properties was requested by
> > > Sean Christopherson.
> >
> > No, I suggested having
flight 185928 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185928/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-arndale 8 xen-boot fail in 185923 pass in 185928
test-armhf-armhf-libvirt-vhd 8
flight 185925 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185925/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185922
On Mon, 6 May 2024, Nicola Vetrini wrote:
> Repositories under people/* only execute the analyze step if manually
> triggered, but in order to avoid blocking the rest of the pipeline
> if such step is not run, allow it to fail.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Nicola Vetrini
On Fri, May 03, 2024 at 07:03:21AM GMT, Sean Christopherson wrote:
> On Fri, May 03, 2024, Mickaël Salaün wrote:
> > Add an interface for user space to be notified about guests' Heki policy
> > and related violations.
> >
> > Extend the KVM_ENABLE_CAP IOCTL with KVM_CAP_HEKI_CONFIGURE and
> >
flight 185926 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185926/
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
Hi Jan,
On Mon, May 6, 2024 at 2:22 PM Jan Beulich wrote:
>
> On 02.05.2024 18:55, Carlo Nonato wrote:
> > --- a/xen/common/page_alloc.c
> > +++ b/xen/common/page_alloc.c
> > @@ -159,6 +159,7 @@
> > #endif
> >
> > #define PGC_no_buddy_merge PGC_static
> > +#define PGC_preserved (PGC_extra |
Hi Jan,
On Mon, May 6, 2024 at 2:01 PM Jan Beulich wrote:
>
> On 02.05.2024 18:55, Carlo Nonato wrote:
> > Add a command line parameter to allow the user to set the coloring
> > configuration for Dom0.
> > A common configuration syntax for cache colors is introduced and
> > documented.
> > Take
Hi Jan,
On Mon, May 6, 2024 at 1:54 PM Jan Beulich wrote:
>
> On 02.05.2024 18:55, Carlo Nonato wrote:
> > --- a/xen/common/Kconfig
> > +++ b/xen/common/Kconfig
> > @@ -71,6 +71,9 @@ config HAS_IOPORTS
> > config HAS_KEXEC
> > bool
> >
> > +config HAS_LLC_COLORING
> > + bool
> > +
> >
V Sun, 7 Apr 2024 21:11:42 -0700
mhkelle...@gmail.com napsáno:
> From: Michael Kelley
>
> iommu_dma_map_page() allocates swiotlb memory as a bounce buffer when
> an untrusted device wants to map only part of the memory in an
> granule. The goal is to disallow the untrusted device having
> DMA
On Mon, 6 May 2024 15:14:05 +
Michael Kelley wrote:
> From: mhkelle...@gmail.com
> >
>
> Gentle ping ...
>
> Anyone interested in reviewing this series of two patches? It fixes
> an edge case bug in the size of the swiotlb request coming from
> dma-iommu, and plugs a hole that allows
On 06.05.2024 17:33, Roger Pau Monné wrote:
> On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote:
>> On 30.04.2024 18:58, Roger Pau Monne wrote:
>>> Keep track of the maximum gfn that has ever been populated into the p2m, and
>>> also account for the number of foreign mappings. Such
On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote:
> On 30.04.2024 18:58, Roger Pau Monne wrote:
> > Keep track of the maximum gfn that has ever been populated into the p2m, and
> > also account for the number of foreign mappings. Such information will be
> > needed in order to remove
From: mhkelle...@gmail.com
>
Gentle ping ...
Anyone interested in reviewing this series of two patches? It fixes
an edge case bug in the size of the swiotlb request coming from
dma-iommu, and plugs a hole that allows untrusted devices to see
kernel data unrelated to the intended DMA transfer.
On Mon, May 06, 2024 at 04:55:45PM +0200, Jan Beulich wrote:
> On 06.05.2024 16:32, Roger Pau Monné wrote:
> > On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote:
> >> On 30.04.2024 18:58, Roger Pau Monne wrote:
> > My initial intention was to do it
> > in p2m_entry_modify() so that
flight 185923 linux-linus real [real]
flight 185927 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185923/
http://logs.test-lab.xenproject.org/osstest/logs/185927/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Mon, May 06, 2024 at 12:41:49PM +0200, Jan Beulich wrote:
> On 30.04.2024 18:58, Roger Pau Monne wrote:
> > @@ -2695,6 +2691,70 @@ int p2m_set_altp2m_view_visibility(struct domain *d,
> > unsigned int altp2m_idx,
> > return rc;
> > }
> >
> > +/*
> > + * Remove foreign mappings from the
On 06.05.2024 16:32, Roger Pau Monné wrote:
> On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote:
>> On 30.04.2024 18:58, Roger Pau Monne wrote:
>>> Keep track of the maximum gfn that has ever been populated into the p2m, and
>>> also account for the number of foreign mappings. Such
On Mon, May 06, 2024 at 12:07:33PM +0200, Jan Beulich wrote:
> On 30.04.2024 18:58, Roger Pau Monne wrote:
> > Keep track of the maximum gfn that has ever been populated into the p2m, and
> > also account for the number of foreign mappings. Such information will be
> > needed in order to remove
On Thu, Feb 15, 2024 at 11:19:46AM +0100, Jan Beulich wrote:
> Use appropriate types for the control register value as well as the
> capability position. Constify a pointer. Use "else" in favor of encoding
> the opposite condition of the earlier if().
>
> Signed-off-by: Jan Beulich
Acked-by:
On Thu, Feb 15, 2024 at 11:18:52AM +0100, Jan Beulich wrote:
> All call sites pass it using the flag from the IOMMU which they also
> pass.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
On Mon, May 06, 2024 at 03:20:38PM +0200, Jan Beulich wrote:
> On 06.05.2024 14:42, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 11:15:39AM +0100, Jan Beulich wrote:
> >> Make the variable a tristate, with (as done elsewhere) a negative value
> >> meaning "default". Since all use sites need
Hi Luca,
On 23/04/2024 10:25, Luca Fancellu wrote:
>
>
> Wrap the code and logic that is calling assign_shared_memory
> and map_regions_p2mt into a new function 'handle_shared_mem_bank',
> it will become useful later when the code will allow the user to
> don't pass the host physical address.
>
On Thu, Feb 15, 2024 at 11:16:11AM +0100, Jan Beulich wrote:
> When the flag is set, permit Dom0 to control the device (no worse than
> what we had before and in line with other "best effort" behavior we use
> when it comes to Dom0),
I think we should somehow be able to signal dom0 that this
On Mon, May 6, 2024 at 11:59 AM Philippe Mathieu-Daudé
wrote:
>
> On 2/5/24 09:26, David Hildenbrand wrote:
> > On 30.04.24 18:49, Edgar E. Iglesias wrote:
> >> From: "Edgar E. Iglesias"
> >>
> >> Add xen_mr_is_memory() to abstract away tests for the
> >> xen_memory MR.
> >>
> >> Signed-off-by:
On 02.05.2024 18:55, Carlo Nonato wrote:
> From: Luca Miccio
>
> Add a new command line parameter to configure Xen cache colors.
> These colors are dumped together with other coloring info.
>
> Benchmarking the VM interrupt response time provides an estimation of
> LLC usage by Xen's most
Hi Luca,
On 23/04/2024 10:25, Luca Fancellu wrote:
>
>
> The current static shared memory code is using bootinfo banks when it
> needs to find the number of borrower, so every time assign_shared_memory
s/borrower/borrowers
> is called, the bank is searched in the bootinfo.shmem structure.
>
>
On 06.05.2024 14:42, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:15:39AM +0100, Jan Beulich wrote:
>> Make the variable a tristate, with (as done elsewhere) a negative value
>> meaning "default". Since all use sites need looking at, also rename it
>> to match our usual "opt_*" pattern.
On Sat, May 4, 2024 at 2:14 AM Stefano Stabellini
wrote:
>
> On Wed, 1 May 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Use the generic xen/linkage.h macros to annotate code symbols
> > and add missing annotations.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> >
On Sat, May 4, 2024 at 1:56 AM Stefano Stabellini
wrote:
>
> On Wed, 1 May 2024, Edgar E. Iglesias wrote:
> > From: "Edgar E. Iglesias"
> >
> > Use the generic xen/linkage.h macros to annotate code symbols
> > and add missing annotations.
> >
> > Signed-off-by: Edgar E. Iglesias
> > ---
> >
On 02.05.2024 18:55, Carlo Nonato wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -270,6 +270,20 @@ and not running softirqs. Reduce this if softirqs are
> not being run frequently
> enough. Setting this to a high value may cause boot failure,
On Thu, Feb 15, 2024 at 11:15:39AM +0100, Jan Beulich wrote:
> Make the variable a tristate, with (as done elsewhere) a negative value
> meaning "default". Since all use sites need looking at, also rename it
> to match our usual "opt_*" pattern. While touching it, also move it to
>
On 02.05.2024 18:55, Carlo Nonato wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -159,6 +159,7 @@
> #endif
>
> #define PGC_no_buddy_merge PGC_static
> +#define PGC_preserved (PGC_extra | PGC_static)
Seeing this again and its use ...
> @@ -1426,11 +1427,11 @@
On 02.05.2024 18:55, Carlo Nonato wrote:
> @@ -266,6 +267,47 @@ int domain_set_llc_colors(struct domain *d,
> return 0;
> }
>
> +int __init domain_set_llc_colors_from_str(struct domain *d, const char *str)
> +{
> +int err;
> +unsigned int *colors, num_colors;
> +
> +if ( !str )
On 02.05.2024 18:55, Carlo Nonato wrote:
> Add a new domctl hypercall to allow the user to set LLC coloring
> configurations. Colors can be set only once, just after domain creation,
> since recoloring isn't supported.
>
> Based on original work from: Luca Miccio
>
> Signed-off-by: Carlo Nonato
On 02.05.2024 18:55, Carlo Nonato wrote:
> Add a command line parameter to allow the user to set the coloring
> configuration for Dom0.
> A common configuration syntax for cache colors is introduced and
> documented.
> Take the opportunity to also add:
> - default configuration notion.
> -
On 02.05.2024 18:55, Carlo Nonato wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -71,6 +71,9 @@ config HAS_IOPORTS
> config HAS_KEXEC
> bool
>
> +config HAS_LLC_COLORING
> + bool
> +
> config HAS_PIRQ
> bool
>
> @@ -513,4 +516,23 @@ config TRACEBUFFER
>
On 02.05.2024 11:21, Sergiy Kibrik wrote:
> Separate Intel/AMD-specific MCE code using CONFIG_{INTEL,AMD} config options.
> Now we can avoid build of mcheck code if support for specific platform is
> intentionally disabled by configuration.
>
> Add default return value to
On Thu, Feb 15, 2024 at 11:15:12AM +0100, Jan Beulich wrote:
> The same set of conditions is used in three places, requiring to be kept
> in sync. Introduce a helper to centralize these checks.
>
> To allow all parameters of the new helper be pointer-to-const,
> iommu_has_cap() also needs its 1st
On 02.05.2024 11:18, Sergiy Kibrik wrote:
> Guard calls to CPU-specific mcheck init routines in common MCE code
> using new INTEL/AMD config options.
>
> The purpose is not to build platform-specific mcheck code and calls to it,
> if this platform is disabled in config.
>
> Signed-off-by: Sergiy
On 02.05.2024 11:16, Sergiy Kibrik wrote:
> Add build-time checks for newly introduced INTEL/AMD config options when
> calling vmce_{intel/amd}_{rdmsr/wrmsr}() routines.
> This way a platform-specific code can be omitted in vmce code, if this
> platform is disabled in config.
>
> Signed-off-by:
flight 185924 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185924/
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 02.05.2024 11:14, Sergiy Kibrik wrote:
> Moving this function out of mce_intel.c would make it possible to disable
> build of Intel MCE code later on, because the function gets called from
> common x86 code.
>
> Add internal check for CONFIG_INTEL option, as MCG_LMCE_P bit is currently
>
On 02.05.2024 11:12, Sergiy Kibrik wrote:
> Build AMD vPMU when CONFIG_AMD is on, and Intel vPMU when CONFIG_INTEL
> is on respectively, allowing for a plaftorm-specific build.
>
> No functional change intended.
>
> Signed-off-by: Sergiy Kibrik
> Reviewed-by: Stefano Stabellini
I can only
On Mon, May 06, 2024 at 01:01:48PM +0200, Jan Beulich wrote:
> On 06.05.2024 12:29, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 11:14:31AM +0100, Jan Beulich wrote:
> >> This is a prereq to us, in particular, respecting the "ATC required"
> >> flag.
> >>
> >> Note that
On 06.05.2024 12:29, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:14:31AM +0100, Jan Beulich wrote:
>> This is a prereq to us, in particular, respecting the "ATC required"
>> flag.
>>
>> Note that ACPI_SATC_ATC_REQUIRED has its #define put in dmar.h, as we
>> try to keep actbl*.h in sync
On 30.04.2024 18:58, Roger Pau Monne wrote:
> @@ -2695,6 +2691,70 @@ int p2m_set_altp2m_view_visibility(struct domain *d,
> unsigned int altp2m_idx,
> return rc;
> }
>
> +/*
> + * Remove foreign mappings from the p2m, as that drops the page reference
> taken
> + * when mapped.
> + */
>
On Mon, May 06, 2024 at 11:35:00AM +0200, Jan Beulich wrote:
> On 06.05.2024 11:26, Roger Pau Monné wrote:
> > And then some patches that I don't expect to make progress:
> >
> > x86/shutdown: change default reboot method preference
> >
On Thu, Feb 15, 2024 at 11:14:31AM +0100, Jan Beulich wrote:
> This is a prereq to us, in particular, respecting the "ATC required"
> flag.
>
> Note that ACPI_SATC_ATC_REQUIRED has its #define put in dmar.h, as we
> try to keep actbl*.h in sync what Linux (who in turn inherit from ACPI
> CA) has.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
Changes in V5-V9:
- Nothing changed. Only rebase.
---
Changes in V4:
- drop stubs for irq_actor_none() and irq_actor_none() as common/irq.c is
compiled now.
- drop defintion of max_page in stubs.c as common/page_alloc.c is compiled
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Break out xen_ram_addr_from_mapcache_single(), a multi-cache
aware version of xen_ram_addr_from_mapcache.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 17 +++--
1 file
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Break out xen_invalidate_map_cache_single().
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
On 2/5/24 08:32, Edgar E. Iglesias wrote:
On Wed, May 1, 2024 at 10:46 PM Stefano Stabellini
wrote:
On Tue, 30 Apr 2024, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add MapCache argument to xen_replace_cache_entry_unlocked in
preparation for supporting multiple map caches.
No
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V7-V9:
- Only rebase was done.
---
Changes in V6:
- update the commit in stubs.c around /* ... common/irq.c ... */
- add Acked-by: Jan Beulich
---
Changes in V5:
- drop unrelated changes
- assert_failed("unimplmented...")
The definition of __read_mostly should be removed in:
https://lore.kernel.org/xen-devel/f25eb5c9-7c14-6e23-8535-2c66772b3...@suse.com/
The patch introduces it in arch-specific header to not
block enabling of full Xen build for RISC-V.
Signed-off-by: Oleksii Kurochko
---
- [PATCH] move
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V8-V9:
- Nothing changed only rebase.
---
Changes in V7:
- update argument type of maddr_to_virt() function: unsigned long -> paddr_t
- rename argument of PFN_ORDER(): pfn -> pg.
- add Acked-by: Jan Beulich
---
Changes in
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:18:21: error: comparison of distinct pointer types lacks
a cast [-Werror]
18 | (void) (&_x == &_y);
Signed-off-by: Oleksii Kurochko
---
Changes in V5-V9:
- Only rebase was done.
---
Changes in V4:
- New patch.
---
xen/arch/riscv/Makefile | 1 +
xen/arch/riscv/vm_event.c | 19 +++
2 files changed, 20 insertions(+)
create mode 100644 xen/arch/riscv/vm_event.c
diff --git
Initially the patch was introduced by Bobby, who takes the header from
Linux kernel.
The following changes were done on top of Bobby's changes:
- atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
to use__*xchg_generic()
- drop casts in write_atomic() as they are unnecessary
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed by
the Xen RISC-V container and are anticipated to undergo continuous
testing. Older GCC and GNU Binutils would work,
but this is not a guarantee.
While it is feasible to
Disables unnecessary configs for two cases:
1. By utilizing EXTRA_FIXED_RANDCONFIG for randconfig builds (GitLab CI jobs).
2. By using tiny64_defconfig for non-randconfig builds.
Only configs which lead to compilation issues were disabled.
Remove lines related to disablement of configs which
Taken from Linux-6.4.0-rc1
Xen's bitops.h consists of several Linux's headers:
* linux/arch/include/asm/bitops.h:
* The following function were removed as they aren't used in Xen:
* test_and_set_bit_lock
* clear_bit_unlock
* __clear_bit_unlock
* The following functions
Signed-off-by: Oleksii Kurochko
---
Changes in V4-V9:
- Nothing changed. Only rebase.
---
Changes in V3:
- new patch.
---
xen/arch/riscv/include/asm/monitor.h | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 xen/arch/riscv/include/asm/monitor.h
diff --git
Add minimal requied things to be able to build full Xen.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5-V9:
- Nothing changed. Only rebase.
---
Changes in V4:
- BUG() was changed to BUG_ON("unimplemented");
- Change "xen/bug.h" to "xen/lib.h" as BUG_ON is defined in
The header was taken from Linux kernl 6.4.0-rc1.
Addionally, were updated:
* add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
access.
* replace tabs with spaces
* replace __* variale with *__
* introduce generic version of xchg_* and cmpxchg_*.
* drop
The mentioned macros exist only because of Linux compatible purpose.
The patch defines __ffs() in terms of Xen bitops and it is safe
to define in this way ( as __ffs() - 1 ) as considering that __ffs()
was defined as __builtin_ctzl(x), which has undefined behavior when x=0,
so it is assumed that
This patch series performs all of the additions necessary to drop the
build overrides for RISCV and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple.
The patch series is based on the
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 introduces the following generics which are
used by the functions mentioned above:
* BITOP_BITS_PER_WORD
* BITOP_MASK
* BITOP_WORD
*
On 30.04.2024 18:58, Roger Pau Monne wrote:
> Keep track of the maximum gfn that has ever been populated into the p2m, and
> also account for the number of foreign mappings. Such information will be
> needed in order to remove foreign mappings during teardown for HVM guests.
Is "needed" the
On 2/5/24 09:26, David Hildenbrand wrote:
On 30.04.24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add xen_mr_is_memory() to abstract away tests for the
xen_memory MR.
Signed-off-by: Edgar E. Iglesias
---
[...]
#endif
diff --git a/system/physmem.c b/system/physmem.c
index
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Propagate MR and is_write to xen_map_cache().
This is in preparation for adding support for grant mappings.
No functional change.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 10 ++
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add MapCache argument to xen_invalidate_map_cache_entry_unlocked.
This is in preparation for supporting multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 21
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Add MapCache argument to xen_remap_bucket in preparation
to support multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 9 +
1 file changed, 5 insertions(+),
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Make xen_map_cache take a MapCache as argument. This is in
prepaparation to support multiple map caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 35
On 30/4/24 18:49, Edgar E. Iglesias wrote:
From: "Edgar E. Iglesias"
Make the lock functions take MapCache * as argument. This is
in preparation for supporting multiple caches.
No functional changes.
Signed-off-by: Edgar E. Iglesias
---
hw/xen/xen-mapcache.c | 34
On 30.04.2024 14:47, Fouad Hilly wrote:
> @@ -21,10 +23,11 @@ static const char amd_id[] = "AuthenticAMD";
> static void usage(const char *name)
> {
> printf("%s: Xen microcode updating tool\n"
> - "Usage: %s [ | Options]\n"
> + "Usage: %s [microcode file] [options]\n"
On 06.05.2024 11:26, Roger Pau Monné wrote:
> And then some patches that I don't expect to make progress:
>
> x86/shutdown: change default reboot method preference
> https://lore.kernel.org/xen-devel/20230915074347.94712-1-roger@citrix.com/
>
> x86/time: prefer CMOS over EFI_GET_TIME
>
On Mon, May 06, 2024 at 11:21:06AM +0200, Jan Beulich wrote:
> On 06.05.2024 11:12, Roger Pau Monné wrote:
> > On Thu, Feb 15, 2024 at 11:14:02AM +0100, Jan Beulich wrote:
> >> It's acpi_parse_one_rmrr() where the allocation is coming from (by way
> >> of invoking acpi_parse_dev_scope()), or in
On 06.05.2024 11:22, Roger Pau Monné wrote:
> On Mon, May 06, 2024 at 11:06:07AM +0200, Jan Beulich wrote:
>> A stray 'p' was there, rendering the #undef ineffectual.
>>
>> Signed-off-by: Jan Beulich
>
> Acked-by: Roger Pau Monné
Thanks.
> No Fixes tag?
I didn't think it was worthwhile
On Fri, May 03, 2024 at 06:54:40PM +0200, Oleksii wrote:
> Hello everyone,
>
> I would like to share with you a list for status tracking based on Xen
> ML and community members comments:
>
> *** Arm ***:
> * Arm cache coloring [
>
On Mon, May 06, 2024 at 11:06:07AM +0200, Jan Beulich wrote:
> A stray 'p' was there, rendering the #undef ineffectual.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
No Fixes tag?
Thanks, Roger.
On 06.05.2024 11:12, Roger Pau Monné wrote:
> On Thu, Feb 15, 2024 at 11:14:02AM +0100, Jan Beulich wrote:
>> It's acpi_parse_one_rmrr() where the allocation is coming from (by way
>> of invoking acpi_parse_dev_scope()), or in add_one_user_rmrr()'s case
>> allocation is even open-coded there, so
flight 185922 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185922/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185919
On 30.04.2024 14:47, Fouad Hilly wrote:
> @@ -633,12 +637,12 @@ static long cf_check microcode_update_helper(void *data)
>microcode_cache);
>
> if ( result != NEW_UCODE &&
> - !(opt_ucode_allow_same && result == SAME_UCODE) )
> +
On Thu, Feb 15, 2024 at 11:14:02AM +0100, Jan Beulich wrote:
> It's acpi_parse_one_rmrr() where the allocation is coming from (by way
> of invoking acpi_parse_dev_scope()), or in add_one_user_rmrr()'s case
> allocation is even open-coded there, so freeing would better also happen
> there. Care
A stray 'p' was there, rendering the #undef ineffectual.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_64/platform_hypercall.c
+++ b/xen/arch/x86/x86_64/platform_hypercall.c
@@ -30,7 +30,7 @@ CHECK_pf_pcpu_version;
#define xen_pf_ucode_revision xenpf_ucode_revision
Repositories under people/* only execute the analyze step if manually
triggered, but in order to avoid blocking the rest of the pipeline
if such step is not run, allow it to fail.
Reported-by: Andrew Cooper
Signed-off-by: Nicola Vetrini
---
See
On 06.05.2024 10:45, Fonyuy-Asheri Caleb wrote:
>> From: "Roger Pau Monné"
>> Sent: Monday, May 6, 2024 10:34:20 AM
>
>> For basic leaves (0x00xx) we support up to leaf 0xd (XSTATE). It
>> doesn't mean there are no further leaves behind it, but we likely
>> still have no use for them, and
On 30.04.2024 14:47, Fouad Hilly wrote:
> Update microcode version check at Intel and AMD Level by:
> Preventing the low level code from sending errors if the microcode
> version is not a newer version. this is required to allow developers to do
> ucode loading testing, including the introduction
> From: "Roger Pau Monné"
> To: "Fonyuy-Asheri Caleb"
> Cc: "xen-devel"
> Sent: Monday, May 6, 2024 10:34:20 AM
> Subject: Re: file xen/include/xen/lib/x86/cpu-policy.h: Meaning of CPUID
> constants
> On Mon, May 06, 2024 at 09:46:58AM +0200, Fonyuy-Asheri Caleb wrote:
>> Hi,
>> I am
On Mon, May 06, 2024 at 09:46:58AM +0200, Fonyuy-Asheri Caleb wrote:
> Hi,
> I am currently doing a study on the way xen handles CPUID information.
>
> I came across these constants in the code
> (xen/include/xen/lib/x86/cpu-policy.h file) but no explanation of why they
> have been set that
Hi Julien,
On 5/1/2024 4:13 AM, Julien Grall wrote:
Hi Henry,
On 30/04/2024 04:50, Henry Wang wrote:
On 4/25/2024 10:28 PM, Julien Grall wrote:
Thanks for your feeedback. After checking the b8577547236f commit
message I think I now understand your point. Do you have any
suggestion about how
On Mon, 2024-05-06 at 09:11 +0200, Jan Beulich wrote:
> On 03.05.2024 18:54, Oleksii wrote:
> > *** x86 ***:
> > * [PATCH 0/4] iommu/x86: fixes/improvements for unity range
> > checks [
> > https://lore.kernel.org/xen-devel/20240201170159.66330-1-roger@citrix.com/
> > ]:
> > - almost
On 06.05.2024 10:16, Oleksii wrote:
> On Mon, 2024-05-06 at 08:33 +0200, Jan Beulich wrote:
>> On 03.05.2024 19:15, Oleksii wrote:
>>> On Thu, 2024-04-25 at 17:35 +0200, Jan Beulich wrote:
> #include
>
> +#ifndef arch_check_bitop_size
> +#define arch_check_bitop_size(addr)
On 30.04.2024 14:47, Fouad Hilly wrote:
> Use getopt_long() to handle command line arguments.
> Introduce ext_err for common exit with errors.
>
> Signed-off-by: Fouad Hilly
Nit: Neither subject nor description make clear ...
> tools/misc/xen-ucode.c | 45
On 30.04.2024 14:47, Fouad Hilly wrote:
> Refactor xen-ucode tool by adding usage() to handle usage\help messages.
> As we add more command options this will keep help\usage messages in a common
> block.
> Only generic error message is printed to stderr. usage and show_curr_cpu are
> printed to
1 - 100 of 111 matches
Mail list logo
