On 06.05.2024 17:53, Carlo Nonato wrote:
> 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 co
On 13.05.2024 11:11, Sergiy Kibrik wrote:
> 06.05.24 14:32, Jan Beulich:
>> On 02.05.2024 11:21, Sergiy Kibrik wrote:
>>> Also global Intel-specific variables lmce_support & cmci_support have to be
>>> redefined if !INTEL, as they get checked in common code.
>>
>> Them being checked in common code
On Sat, May 11, 2024 at 04:16:42PM +0100, Andrew Cooper wrote:
> I was playing with GCC-14, and gave the new static analyser (-fanalyze) a
> try. One of the more serious things it came back with was this:
>
> In file included from ./arch/x86/include/asm/mm.h:10,
>from ./incl
On 08.05.2024 09:10, Jens Wiklander wrote:
> On Fri, May 3, 2024 at 12:32 PM Jan Beulich wrote:
>> Furthermore, is it guaranteed that the IRQ handler won't interrupt code
>> fiddling with the domain list? I don't think it is, since
>> domlist_update_lock isn't acquired in an IRQ-safe manner. Looks
On Fri, May 10, 2024 at 11:39:59PM +0100, Andrew Cooper wrote:
> Rename INIT_FEATURE_NAMES to INIT_FEATURE_NAME_TO_VAL as we're about to gain a
> inverse mapping of the same thing.
>
> Use dict.items() unconditionally. iteritems() is a marginal perf optimsiation
> for Python2 only, and simply not
On Fri, May 10, 2024 at 11:40:00PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Split out of subsequent patch to aid legibility.
Maybe add: "No functional change intended".
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Reviewed-by: Roger Pau Monné
Thanks, Ro
On 07.05.2024 19:37, Julien Grall wrote:
>
>
> On 07/05/2024 17:55, Edgar E. Iglesias wrote:
>> On Tue, May 7, 2024 at 11:57 AM Julien Grall wrote:
>> Hi Julien,
>
> Hi Edgar,
>
>>
>> The reason I choose FUNC for the start of the symbol is because these
>> symbols contain
>> executable code (n
On 14.05.2024 09:05, Roger Pau Monné wrote:
> On Sat, May 11, 2024 at 04:16:42PM +0100, Andrew Cooper wrote:
>> Architecturally, there's no 64-bit variant of OUTS in x86.
This is the reason why personally ...
>> Leaving an
>> assertion to this effect is enough to satisfy the analyser.
... I vie
On 10.05.2024 19:40, Jason Andryuk wrote:
> On 2023-12-18 09:48, Jan Beulich wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -425,6 +425,72 @@ static struct platform_timesource __init
>> .resume = resume_pit,
>> };
>>
>> +unsigned int __initdata pit_alias_mask;
>>
On Fri, May 10, 2024 at 11:40:01PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Have gen-cpuid.py write out INIT_FEATURE_VAL_TO_NAME, derived from the same
> data source as INIT_FEATURE_NAME_TO_VAL, although both aliases of common_1d
> are needed.
>
> In xen-cpuid.c, have the compiler
On Fri, May 10, 2024 at 11:40:02PM +0100, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Not used any more. Split out of previous patch to aid legibility.
>
> Signed-off-by: Roger Pau Monné
> Signed-off-by: Andrew Cooper
Acked-by: Roger Pau Monné
Thanks, Roger.
Hi Julien,
Thanks for having a look on the patch,
> On 13 May 2024, at 22:54, Julien Grall wrote:
>
> Hi Luca,
>
> On 25/04/2024 14:11, Luca Fancellu wrote:
>> Currently the code is listing device tree reserve map regions
>> as reserved memory for Xen, but they are not added into
>> bootinfo.r
Hi Julien,
>
>> Note also that a foreign unmap resulting in a page free is also not
>> the common case, as that should only happen when the foreign domain
>> has been destroyed, or the page ballooned out, so to benchmark the
>> worst case some effort will be needed in order to model this
>> scena
On 13.05.2024 17:27, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 11:10:59AM +, Elias El Yandouzi wrote:
>> @@ -317,6 +317,14 @@ extern unsigned long xen_phys_start;
>> #define ARG_XLAT_START(v)\
>> (ARG_XLAT_VIRT_START + ((v)->vcpu_id << ARG_XLAT_VA_SHIFT))
>>
>> +/* pv_roo
On 10.05.2024 14:32, Alessandro Zucchelli wrote:
> --- a/xen/arch/arm/include/asm/mem_access.h
> +++ b/xen/arch/arm/include/asm/mem_access.h
> @@ -17,6 +17,8 @@
> #ifndef _ASM_ARM_MEM_ACCESS_H
> #define _ASM_ARM_MEM_ACCESS_H
>
> +#include
> +
> static inline
> bool p2m_mem_access_emulate_che
Although using integer comparison to compare doubles kind of
works, it's annoying to see domains slightly out of order when
sorting by cpu%.
Add a compare_dbl() function and update compare_cpu_pct() to
call it.
Signed-off-by: Leigh Brown
---
tools/xentop/xentop.c | 13 -
1 file chan
This series aims to separate support of Intel & AMD CPUs in Xen build.
The code to drive both platforms used to be built unconditionally, until recent
introduction of CONFIG_{AMD,INTEL} Kconfig options.
This series extends coverage of these options on vpmu and mcheck subsystems,
which allows not t
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
Acked-by: Jan Beulich
CC: Andrew Cooper
---
changes in v3:
- neither
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.
Also replace boilerplate code that checks for MCG_LMCE_P flag with
vmce_has_lmce(), which might contribute to readability a bit.
Signe
On 13.05.2024 10:44, Roger Pau Monné wrote:
> On Fri, May 10, 2024 at 09:09:54PM -0700, Elliott Mitchell wrote:
>> On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
>>>
>>> I suspect this is a case of there is some step which is missing from
>>> Xen's IOMMU handling. Perhaps someth
On Mon, May 13, 2024 at 01:40:31PM +, Elias El Yandouzi wrote:
> From: Wei Liu
>
> It is going to be needed by HVM and idle domain as well, because without
> the direct map, both need a mapcache to map pages.
The idle domain is a PV domain, and so gets the mapcache already
initialized with t
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: Sergiy Kibrik
Reviewed-by: Stefano Stabellini
Acked-by
On 13.05.2024 22:11, Elliott Mitchell wrote:
> On Mon, May 13, 2024 at 10:44:59AM +0200, Roger Pau Monné wrote:
>> Why do you mask the device SBDF in the above snippet? I would really
>> like to understand what's so privacy relevant in a PCI SBDF number.
>
> I doubt it reveals much. Simply seems
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 Kibrik
Reviewed-by: Stefano Stabellini
Acked-by: Jan B
The default switch case block is likely wanted here, to handle situation
e.g. of unexpected c->x86_vendor value -- then no mcheck init is done, but
misleading message still gets logged anyway.
Signed-off-by: Sergiy Kibrik
CC: Jan Beulich
---
xen/arch/x86/cpu/mcheck/non-fatal.c | 4
1 file
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.
Also global variables lmce_support & cmci_support from Intel-specific
mce_intel.c have to moved to common
On 14.05.2024 02:09, Stefano Stabellini wrote:
> On Mon, 13 May 2024, Julien Grall wrote:
>> Hi Stefano,
>>
>> title: Is this the only violation we have in Xen? If so, then please add the
>> subsystem in the title.
>
> The only remaining violations are about the use of the "toupper" macro.
> Bugse
On Mon, May 13, 2024 at 01:40:32PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> In order to use the mapcache in the idle domain, we also have to
> populate its page tables in the PERDOMAIN region, and we need to move
> mapcache_domain_init() earlier in arch_domain_create().
Oh, so thi
On 14.05.2024 02:32, Stefano Stabellini wrote:
> Fix last violation of R10.2 by casting the result of toupper to plain
> char. Note that we don't want to change toupper itself as it is a legacy
> interface and it would cause more issues.
Can you point me at a single example where a new issue would
On 14.05.2024 02:24, Stefano Stabellini wrote:
> On Sat, 11 May 2024, Andrew Cooper wrote:
>> --- a/xen/drivers/cpufreq/cpufreq.c
>> +++ b/xen/drivers/cpufreq/cpufreq.c
>> @@ -459,21 +459,21 @@ static void print_PPC(unsigned int platform_limit)
>>
>> int set_px_pminfo(uint32_t acpi_id, struct xe
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 30.04.2024 16:28, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
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
flight 185992 linux-linus real [real]
flight 185995 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185992/
http://logs.test-lab.xenproject.org/osstest/logs/185995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
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
On Mon, May 13, 2024 at 01:40:33PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Also add a helper function to retrieve it. Change arch_mfns_in_direct_map
> to check this option before returning.
>
> This is added as a Kconfig option as well as a boot command line option.
> While being
On 03.04.2024 08:16, Jan Beulich wrote:
> On 02.04.2024 19:06, Andrew Cooper wrote:
>> The commit makes a claim without any kind of justification.
>
> Well, what does "have no business" leave open?
>
>> The claim is false, and the commit broke lsevtchn in dom0.
>
> Or alternatively lsevtchn was
On Mon, May 13, 2024 at 01:40:34PM +, Elias El Yandouzi wrote:
> From: Julien Grall
>
> PMAP will be used in a follow-up patch to bootstrap map domain
> page infrastructure -- we need some way to map pages to setup the
> mapcache without a direct map.
>
> The functions pmap_{map, unmap} open
On 07.05.2024 15:45, Andrew Cooper wrote:
> Ever since Xen 4.14, there has been a latent bug with migration.
>
> While some toolstacks can level the features properly, they don't shink
> feat.max_subleaf when all features have been dropped. This is because
> we *still* have not completed the tool
On Mon, May 13, 2024 at 01:40:35PM +, Elias El Yandouzi wrote:
> The early fixed addresses must all fit into the static L1 table.
> Introduce a build assertion to this end.
>
> Signed-off-by: Elias El Yandouzi
>
>
>
> Changes in v2:
> * New patch
>
> diff --git a/xen/arc
On 14.05.2024 11:40, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:34PM +, Elias El Yandouzi wrote:
>> @@ -53,6 +55,8 @@ enum fixed_addresses {
>> FIX_PV_CONSOLE,
>> FIX_XEN_SHARED_INFO,
>> #endif /* CONFIG_XEN_GUEST */
>> +FIX_PMAP_BEGIN,
>> +FIX_PMAP_END = FIX_PMAP
On 14.05.2024 11:42, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:35PM +, Elias El Yandouzi wrote:
>> The early fixed addresses must all fit into the static L1 table.
>> Introduce a build assertion to this end.
>>
>> Signed-off-by: Elias El Yandouzi
>>
>>
>>
>> Changes in v
On 14/05/2024 10:25 am, Jan Beulich wrote:
> On 03.04.2024 08:16, Jan Beulich wrote:
>> On 02.04.2024 19:06, Andrew Cooper wrote:
>>> The commit makes a claim without any kind of justification.
>> Well, what does "have no business" leave open?
>>
>>> The claim is false, and the commit broke lsevtch
On 07.05.2024 17:21, Elias El Yandouzi wrote:
> > On 20/02/2024 10:28, Jan Beulich wrote:
>>> On 16.01.2024 20:25, Elias El Yandouzi wrote:
>>> --- a/xen/arch/x86/pv/dom0_build.c
>>> +++ b/xen/arch/x86/pv/dom0_build.c
>>> @@ -382,6 +382,10 @@ int __init dom0_construct_pv(struct domain *d,
>>>
On 07.05.2024 17:22, Elias El Yandouzi wrote:
>>> This only lifts the mapcache variable up. Whether we populate the
>>> mapcache for a domain is unchanged in this patch.
>>
>> Is it? I wonder because of ...
>>
>
> I agree, the commit message doesn't completely reflect the changes below.
>
>>> ---
On 14.05.2024 11:51, Andrew Cooper wrote:
> On 14/05/2024 10:25 am, Jan Beulich wrote:
>> On 03.04.2024 08:16, Jan Beulich wrote:
>>> On 02.04.2024 19:06, Andrew Cooper wrote:
The commit makes a claim without any kind of justification.
>>> Well, what does "have no business" leave open?
>>>
>>>
On 13.05.2024 11:35, Elias El Yandouzi wrote:
> On 20/02/2024 10:51, Jan Beulich wrote:
>> On 16.01.2024 20:25, Elias El Yandouzi wrote:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -750,9 +750,16 @@ int arch_domain_create(struct domain *d,
>>>
>>> spin_lock_init(
On 13.05.2024 12:50, Elias El Yandouzi wrote:
> On 20/02/2024 11:14, Jan Beulich wrote:
>> On 16.01.2024 20:25, Elias El Yandouzi wrote:
>>> --- a/xen/arch/x86/Kconfig
>>> +++ b/xen/arch/x86/Kconfig
>>> @@ -29,6 +29,7 @@ config X86
>>> select HAS_UBSAN
>>> select HAS_VPCI if HVM
>>> sel
On Tue, May 14, 2024 at 11:20:21AM +0200, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:33PM +, Elias El Yandouzi wrote:
> > From: Hongyan Xia
> > diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
> > index 7561297a75..9d4f1f2d0d 100644
> > --- a/xen/include/xen/mm.h
> > +++ b/
On Tue, May 14, 2024 at 11:43:14AM +0200, Jan Beulich wrote:
> On 14.05.2024 11:40, Roger Pau Monné wrote:
> > On Mon, May 13, 2024 at 01:40:34PM +, Elias El Yandouzi wrote:
> >> @@ -53,6 +55,8 @@ enum fixed_addresses {
> >> FIX_PV_CONSOLE,
> >> FIX_XEN_SHARED_INFO,
> >> #endif /* CO
On 14.05.2024 12:22, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 11:43:14AM +0200, Jan Beulich wrote:
>> On 14.05.2024 11:40, Roger Pau Monné wrote:
>>> On Mon, May 13, 2024 at 01:40:34PM +, Elias El Yandouzi wrote:
@@ -53,6 +55,8 @@ enum fixed_addresses {
FIX_PV_CONSOLE,
>>
On 13/05/2024 9:59 am, 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 rest of
> the alre
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 Beulich wrote:
On 03.04.2024 08:16, Jan Beulich wrote:
On 02.04.2024 19:06,
Hi Stefano,
On 14/05/2024 01:09, Stefano Stabellini wrote:
On Mon, 13 May 2024, Julien Grall wrote:
Hi Stefano,
title: Is this the only violation we have in Xen? If so, then please add the
subsystem in the title.
The only remaining violations are about the use of the "toupper" macro.
Bugseng
On Mon, May 13, 2024 at 01:40:36PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When mfn is not in direct map, never use mfn_to_virt for any mappings.
>
> We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
> arch_mfns_in_direct_map(mfn, 1) because these two are equi
On 14/05/2024 12:09 pm, Andrew Cooper wrote:
> On 13/05/2024 9:59 am, 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 M
On Tue, May 14, 2024 at 12:26:29PM +0200, Jan Beulich wrote:
> On 14.05.2024 12:22, Roger Pau Monné wrote:
> > On Tue, May 14, 2024 at 11:43:14AM +0200, Jan Beulich wrote:
> >> On 14.05.2024 11:40, Roger Pau Monné wrote:
> >>> On Mon, May 13, 2024 at 01:40:34PM +, Elias El Yandouzi wrote:
> >>>
On 13.05.2024 10:59, Roger Pau Monne wrote:
> --- a/xen/arch/x86/cpu/mtrr/main.c
> +++ b/xen/arch/x86/cpu/mtrr/main.c
> @@ -573,14 +573,15 @@ void mtrr_ap_init(void)
> if (!mtrr_if || hold_mtrr_updates_on_aps)
> return;
> /*
> - * Ideally we should hold mtrr_mutex her
On 14/05/2024 9:13 am, Leigh Brown wrote:
> Although using integer comparison to compare doubles kind of
> works, it's annoying to see domains slightly out of order when
> sorting by cpu%.
>
> Add a compare_dbl() function and update compare_cpu_pct() to
> call it.
>
> Signed-off-by: Leigh Brown
>
On Tue, May 07, 2024 at 09:16:06AM -0700, Sean Christopherson wrote:
> On Tue, May 07, 2024, Mickaël Salaün wrote:
> > > Actually, potential bad/crazy idea. Why does the _host_ need to define
> > > policy?
> > > Linux already knows what assets it wants to (un)protect and when. What's
> > > miss
flight 185993 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185993/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 18 guest-localmigrate/x10 fail
pass in 185987
Tests which did not
On Fri, May 10, 2024 at 10:07:00AM +, Nicolas Saenz Julienne wrote:
> On Tue May 7, 2024 at 4:16 PM UTC, Sean Christopherson wrote:
> > > If yes, that would indeed require a *lot* of work for something we're not
> > > sure will be accepted later on.
> >
> > Yes and no. The AWS folks are pursui
On 14.05.2024 13:51, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 12:26:29PM +0200, Jan Beulich wrote:
>> On 14.05.2024 12:22, Roger Pau Monné wrote:
>>> On Tue, May 14, 2024 at 11:43:14AM +0200, Jan Beulich wrote:
On 14.05.2024 11:40, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 0
On 14.05.2024 14: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 annoying to see domains slightly out of order when
>> sorting by cpu%.
>>
>> Add a compare_dbl() function and update compare_cpu_pct()
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 annoying to see domains slightly out of order when
sorting by cpu%.
Add a compare_dbl() function and update compare_cpu_pct() to
c
On 14/05/2024 8:53 am, Roger Pau Monné wrote:
> On Fri, May 10, 2024 at 11:40:01PM +0100, Andrew Cooper wrote:
>> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
>> index 6ee835b22949..2f34694e9c57 100644
>> --- a/tools/misc/xen-cpuid.c
>> +++ b/tools/misc/xen-cpuid.c
>> @@ -11,6 +11,7
On 14.05.2024 09:53, Roger Pau Monné wrote:
> On Fri, May 10, 2024 at 11:40:01PM +0100, Andrew Cooper wrote:
>> Differences in names are:
>>
>> sysenter-> sep
>> tm -> tm1
>> ds-cpl -> dscpl
>> est -> eist
>> sse41 -> sse4-1
>> sse42 -> sse4-2
>> movebe
On Mon, May 13, 2024 at 01:40:37PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When there is not an always-mapped direct map, xenheap allocations need
> to be mapped and unmapped on-demand.
>
> Signed-off-by: Hongyan Xia
> Signed-off-by: Julien Grall
> Signed-off-by: Elias El Yando
On Tue, May 14, 2024 at 01:57:13PM +0200, Jan Beulich wrote:
> On 13.05.2024 10:59, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/cpu/mtrr/main.c
> > +++ b/xen/arch/x86/cpu/mtrr/main.c
> > @@ -573,14 +573,15 @@ void mtrr_ap_init(void)
> > if (!mtrr_if || hold_mtrr_updates_on_aps)
> >
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 annoying to see domains slightly out of order when
sorting by cpu%.
Add a compare_dbl() function and update compare_cpu_pct() to
call it.
On 14.05.2024 15:10, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 01:57:13PM +0200, Jan Beulich wrote:
>> On 13.05.2024 10:59, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/cpu/mtrr/main.c
>>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>>> @@ -573,14 +573,15 @@ void mtrr_ap_init(void)
>>> if (!mtrr
flight 185994 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185994/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185988
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 11.05.2024 01:32, Stefano Stabellini wrote:
> After looking closely at the R13.1 violations and potential fixes or
> deviations, upon further reflection and discussions, we realized that it
> is R13.2, limited to initializers list, that we want to comply with.
>
> Link: https://marc.info/?l=xen
On 14/05/2024 12:09 pm, Andrew Cooper wrote:
> On 13/05/2024 9:59 am, 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 M
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 annoying to see domains slightly out of order when
>>> sorting by cpu%.
>>>
On 14.05.2024 15:47, Jan Beulich wrote:
> On 11.05.2024 01:32, Stefano Stabellini wrote:
>> After looking closely at the R13.1 violations and potential fixes or
>> deviations, upon further reflection and discussions, we realized that it
>> is R13.2, limited to initializers list, that we want to com
On Mon, May 13, 2024 at 01:40:38PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When we do not have a direct map, memory for metadata of heap nodes in
> init_node_heap() is allocated from xenheap, which needs to be mapped and
> unmapped on demand. However, we cannot just take memory fr
On 08.05.2024 13:04, Matthew Barnes wrote:
> @@ -24,7 +25,18 @@ int main(int argc, char **argv)
> status.port = port;
> rc = xc_evtchn_status(xch, &status);
> if ( rc < 0 )
> -break;
> +{
> +if ( errno == ESRCH )
> +{
> +
On 09.05.2024 10:23, Roger Pau Monné wrote:
> On Wed, May 08, 2024 at 08:38:07PM +0100, Andrew Cooper wrote:
>> On 08/05/2024 12:23 pm, Roger Pau Monne wrote:
>>> Enabling it using an HVM param is fragile, and complicates the logic when
>>> deciding whether options that interact with altp2m can als
On Tue, May 14, 2024 at 02:05:10PM +0100, Andrew Cooper wrote:
> On 14/05/2024 8:53 am, Roger Pau Monné wrote:
> > On Fri, May 10, 2024 at 11:40:01PM +0100, Andrew Cooper wrote:
> >> diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
> >> index 6ee835b22949..2f34694e9c57 100644
> >> --- a
On 14/05/2024 9:52 am, Jan Beulich wrote:
> On 14.05.2024 02:24, Stefano Stabellini wrote:
>> On Sat, 11 May 2024, Andrew Cooper wrote:
>>> --- a/xen/drivers/cpufreq/cpufreq.c
>>> +++ b/xen/drivers/cpufreq/cpufreq.c
>>> @@ -459,21 +459,21 @@ static void print_PPC(unsigned int platform_limit)
>>>
On 14/05/2024 3:27 pm, Roger Pau Monné wrote:
> On Tue, May 14, 2024 at 02:05:10PM +0100, Andrew Cooper wrote:
>> On 14/05/2024 8:53 am, Roger Pau Monné wrote:
>>> On Fri, May 10, 2024 at 11:40:01PM +0100, Andrew Cooper wrote:
diff --git a/tools/misc/xen-cpuid.c b/tools/misc/xen-cpuid.c
i
This is next version of vPCI rework. Aim of this series is to prepare
ground for introducing PCI support on ARM platform.
in v14:
- drop first 9 patches as they were committed
- updated ("vpci/header: emulate PCI_COMMAND register for guests")
in v13:
- drop ("xen/arm: vpci: permit access to gu
From: Oleksandr Andrushchenko
Assign SBDF to the PCI devices being passed through with bus 0.
The resulting topology is where PCIe devices reside on the bus 0 of the
root complex itself (embedded endpoints).
This implementation is limited to 32 devices which are allowed on
a single PCI bus.
Plea
From: Oleksandr Andrushchenko
Xen and/or Dom0 may have put values in PCI_COMMAND which they expect
to remain unaltered. PCI_COMMAND_SERR bit is a good example: while the
guest's (domU) view of this will want to be zero (for now), the host
having set it to 1 should be preserved, or else we'd effec
From: Oleksandr Andrushchenko
There are three originators for the PCI configuration space access:
1. The domain that owns physical host bridge: MMIO handlers are
there so we can update vPCI register handlers with the values
written by the hardware domain, e.g. physical view of the registers
vs g
From: Oleksandr Andrushchenko
At the moment, we always allocate an extra 16 slots for IO handlers
(see MAX_IO_HANDLER). So while adding IO trap handlers for the emulated
MSI-X registers we need to explicitly tell that we have additional IO
handlers, so those are accounted.
Signed-off-by: Oleksan
From: Volodymyr Babchuk
Guest can try to read config space using different access sizes: 8,
16, 32, 64 bits. We need to take this into account when we are
returning an error back to MMIO handler, otherwise it is possible to
provide more data than requested: i.e. guest issues LDRB instruction
to r
On 08.05.2024 13:23, Roger Pau Monne wrote:
> @@ -1043,7 +1045,7 @@ static inline int p2m_entry_modify(struct p2m_domain
> *p2m, p2m_type_t nt,
> break;
>
> case p2m_map_foreign:
> -if ( !mfn_valid(nfn) )
> +if ( !mfn_valid(nfn) || p2m != p2m_get_hostp2m(p2m->domain
On 08.05.2024 13:23, Roger Pau Monne wrote:
> Such information will be needed in order to remove foreign mappings during
> teardown for HVM guests.
>
> Right now the introduced counter is not consumed.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
Yet I think it shouldn't be comm
On Tue, May 14, 2024 at 02:50:18PM +0100, Andrew Cooper wrote:
> On 14/05/2024 12:09 pm, Andrew Cooper wrote:
> > On 13/05/2024 9:59 am, 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 13.05.2024 15:40, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Create a per-domain mapping of PV guest_root_pt as direct map is being
> removed.
>
> Note that we do not map and unmap root_pgt for now since it is still a
> xenheap page.
>
> Signed-off-by: Hongyan Xia
> Signed-off-by: Jul
On 13.05.2024 18:49, Roger Pau Monné wrote:
> On Mon, May 13, 2024 at 01:40:30PM +, Elias El Yandouzi wrote:
>> @@ -710,22 +714,32 @@ int __init dom0_construct_pv(struct domain *d,
>> v->arch.pv.event_callback_cs= FLAT_COMPAT_KERNEL_CS;
>> }
>>
>> +#define UNMAP_MAP_AND_ADVA
On Mon, May 13, 2024 at 01:40:39PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> When we do not have a direct map, archs_mfn_in_direct_map() will always
> return false, thus init_node_heap() will allocate xenheap pages from an
> existing node for the metadata of a new node. This means t
On 13.05.2024 15:40, Elias El Yandouzi wrote:
> --- a/xen/arch/x86/pv/dom0_build.c
> +++ b/xen/arch/x86/pv/dom0_build.c
> @@ -382,6 +382,10 @@ int __init dom0_construct_pv(struct domain *d,
> l3_pgentry_t *l3tab = NULL, *l3start = NULL;
> l2_pgentry_t *l2tab = NULL, *l2start = NULL;
>
On Mon, May 13, 2024 at 01:40:40PM +, Elias El Yandouzi wrote:
> From: Hongyan Xia
>
> Create empty mappings in the second e820 pass. Also, destroy existing
> direct map mappings created in the first pass.
>
> To make xenheap pages visible in guests, it is necessary to create empty
> L3 tabl
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
On 14/05/2024 4:40 pm, Oleksii K. wrote:
> 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 w
On Mon, May 13, 2024 at 01:40:41PM +, Elias El Yandouzi wrote:
> Until directmap gets completely removed, we'd still need to
> keep some calls to mfn_to_virt() for xenheap pages or when the
> directmap is enabled.
>
> Rename the macro to mfn_to_directmap_virt() to flag them and
> prevent furth
1 - 100 of 138 matches
Mail list logo
