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 patch series have been merged already except the patch:
> [PATCH 4
On Sat, May 04, 2024 at 02:48:12AM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, May 03, 2024 at 10:33:38AM +0200, Roger Pau Monné wrote:
> > On Fri, Apr 26, 2024 at 07:54:00PM +0200, Marek Marczykowski-Górecki wrote:
> > > Some devices (notably Intel Wifi 6 AX210 card) keep auxiliary register
On 05.05.2024 11:54, scan-ad...@coverity.com wrote:
> Hi,
>
> Please find the latest report on new defect(s) introduced to XenProject found
> with Coverity Scan.
>
> 2 new defect(s) introduced to XenProject found with Coverity Scan.
> 1 defect(s), reported by Coverity Scan earlier, were marked f
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 way.
#define CPUID_GUEST_NR_BASIC (0xdu + 1)
#define CPUID_GUEST_NR_CACHE (5u + 1
While decompression errors are likely going to be fatal to Xen's boot
process anyway, the latest with the goal of doing multiple decompressor
runs it is likely better to avoid leaks even on error paths. All the
more when this way code size actually shrinks a tiny bit.
Signed-off-by: Jan Beulich
-
On 06.05.2024 09:46, Fonyuy-Asheri Caleb wrote:
> 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 way.
>
> #define CPUID_GUEST_NR_BASIC (0xdu + 1)
> #define CPUID_GUEST_NR_CACHE (5u + 1)
> #define CPUI
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)
> > >
> > > Can this really do no
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 s
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 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 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 patc
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, 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 wa
> 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 currently
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 o
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 he
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 https://gitlab.com/xen-project/people/bugseng/xen/-
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
CHECK_pf_ucode_revisio
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 need
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) )
> +
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
test-amd64-amd64-xl-qemuu-ws16-amd64
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 fr
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 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 [
> https://lore.kernel.org/xen-devel/20240502165533.319988-1-carlo.
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 diggin
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 add
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
> https:
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 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/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"
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(+), 4
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"
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 ++
includ
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.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 right
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
*
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 foll
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 s
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 x
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 {cmp}xchg{release,relaxed,a
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 a
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
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 aren
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 ut
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
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 a/
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
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 V
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 __read_mos
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...")
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 functi
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(-)
Reviewed-
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 c
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 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.
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
> > https://lore.kernel.org/xen-devel/20230915074347.94712-1-roge
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.
> + */
> +i
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 wha
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 ACPI_SATC_ATC_REQUIRED
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 gues
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
> specif
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 1
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: Se
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 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: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 init_nonfatal_mce_checker
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 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.
> - functi
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:
> @@ -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:
> --- 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 @@ stati
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
> .data.ro_after_i
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, parti
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
> > ---
> > xen
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
> > ---
> > xen
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. Whil
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 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 latenc
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: E
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 devic
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 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 l
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 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: Rog
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 fo
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 infor
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
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 run
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 nr_fo
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 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 fo
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 infor
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 u
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 a
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
> > +
> >
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 t
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 | PGC
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 1
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
> > KVM_
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
Revi
1 - 100 of 107 matches
Mail list logo
