flight 185103 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185103/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185050
test-amd64-i386-xl-qemuu-win7-amd64 19
flight 185088 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185088/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt broken
build-amd64-xsm
flight 185100 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185100/
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
The Xen PVH entrypoint is 32bit non-PIC code running at a default load
address of 0x100 (16MB) (CONFIG_PHYSICAL_START). Xen loads the
kernel at that physical address inside the PVH container.
When running a PVH Dom0, the system reserved addresses are mapped 1-1
into the PVH container. There
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.
This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
Signed-off-by: Jason Andryuk
---
The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0
This is a limitation of only printing either string or numeric values.
Switch from the boolean to an enum which allows more flexibility in
printing the values. Introduce
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
On 25/01/2024 4:55 pm, Jan Beulich wrote:
> Since the performance counters used for the NMI watchdog count non-
> halted cycles, they may count at a rate higher than cpu_khz.
Is this in theory, or observed in practice?
It is my understanding that perf counters count in P0 reference cycles,
and
On 25/01/2024 2:12 pm, Jan Beulich wrote:
> "watchdog_timeout=0" is documented to disable the watchdog. Make sure
> this also is true when there's a subsequent "watchdog" command line
> option (and no further "watchdog_timeout=" one).
We also document that latest takes precedence, at which point
On 19/03/2024 7:58 pm, Andrew Cooper wrote:
> Require 's' to be superpage aligned if given over a superpage mapping. This
> is expected to be the case in practice, and prevents the v getting misaligned
> over superpages during the processing loop.
>
> Rmove the requirement for 'e' to be page
Require 's' to be superpage aligned if given over a superpage mapping. This
is expected to be the case in practice, and prevents the v getting misaligned
over superpages during the processing loop.
Rmove the requirement for 'e' to be page aligned. All this is doing is
forcing work for the
On 11/03/2024 11:29 am, Jan Beulich wrote:
> On 11.03.2024 11:54, Roger Pau Monne wrote:
>> The current logic to detect when to switch to the next L1 table is
>> incorrectly
>> using l2_table_offset() in order to notice when the last entry on the current
>> L1 table has been reached.
>>
>> It
On Tue, Jan 09, 2024 at 03:38:30PM +, Alejandro Vallejo wrote:
> Move struct xc_cpu_policy data structure out of xg_private.h and into
> the public xenguest.h so it can be used by libxl.
I will let Andrew comment on this one, IIRC the initial idea was to
not leak cpu_policy into libxl, and to
flight 185083 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185083/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt broken
build-i386-libvirt5
Hi Anthony,
On 19/03/2024 15:15, Anthony PERARD wrote:
Commit d638e304f13a introduced a bullet list, but parse-support-md
choke on it as it doesn't know what to do about it.
Introduce ri_BulletList() so that r_content() will find this new
function and call it instead of calling
On 18/03/2024 6:13 pm, Andrew Cooper wrote:
> All of these are informational and require no further logic changes in Xen to
> support.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>
On 19/03/2024 1:11 pm, Jan Beulich wrote:
> On 19.03.2024 08:33, Jan Beulich wrote:
>> On 18.03.2024 19:13, Andrew Cooper wrote:
>>> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>>> name of FAST_REP_SCASB.
>> With FSRS already used, I guess that's the closest we can
On 19/03/2024 4:51 pm, Jan Beulich wrote:
> On 19.03.2024 15:48, Andrew Cooper wrote:
>> The MSRs used by setup_k7_watchdog() are architectural in 64bit. The Unit
>> Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
>> years, making this a trend likely to continue.
>>
>>
On 19.03.2024 15:48, Andrew Cooper wrote:
> Andrew Cooper (2):
> x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
> x86/boot: Support the watchdog on newer AMD systems
>
> xen/arch/x86/nmi.c | 36
> 1 file changed, 16 insertions(+), 20
On 19.03.2024 15:48, Andrew Cooper wrote:
> The MSRs used by setup_k7_watchdog() are architectural in 64bit. The Unit
> Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
> years, making this a trend likely to continue.
>
> Drop the family check. If the Unit Select does
On 19.03.2024 15:48, Andrew Cooper wrote:
> Right now, if the user requests the watchdog on the command line,
> setup_apic_nmi_watchdog() will blindly assume that setting up the watchdog
> worked. Reuse nmi_perfctr_msr to identify when the watchdog has been set up.
>
> Rearrange
On 15.03.2024 11:58, Carlo Nonato wrote:
> Add a new memory page allocator that implements the cache coloring mechanism.
> The allocation algorithm enforces equal frequency distribution of cache
> partitions, following the coloring configuration of a domain. This allows
> for an even utilization
The pull request you sent on Tue, 19 Mar 2024 08:10:22 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.9-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0815d5cc7dfb4a2c6d02a6eb86974ab3992b803d
Thank you!
--
Deet-doot-dot, I
On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
> This allows the initial x2APIC ID to be sent on the migration stream. The
> hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> Given the vlapic data is zero-extended on restore, fix up migrations from
>
On 19.03.2024 16:58, Jan Beulich wrote:
> On 15.03.2024 11:59, Carlo Nonato wrote:
>> @@ -326,6 +328,27 @@ unsigned int get_max_nr_llc_colors(void)
>> return max_nr_colors;
>> }
>>
>> +paddr_t __init xen_colored_map_size(void)
>> +{
>> +return ROUNDUP((_end - _start) * max_nr_colors,
On 15.03.2024 11:59, Carlo Nonato wrote:
> @@ -62,7 +63,67 @@ unsigned int __init get_llc_way_size(void)
> return line_size * num_sets;
> }
>
> -void __init arch_llc_coloring_init(void) {}
Btw, doing things this way isn't very nice. I was about to ask ...
> +/**
> + * get_xen_paddr - get
On 15.03.2024 11:59, Carlo Nonato wrote:
> @@ -326,6 +328,27 @@ unsigned int get_max_nr_llc_colors(void)
> return max_nr_colors;
> }
>
> +paddr_t __init xen_colored_map_size(void)
> +{
> +return ROUNDUP((_end - _start) * max_nr_colors, XEN_PADDR_ALIGN);
> +}
XEN_PADDR_ALIGN is an
On 15.03.2024 11:59, Carlo Nonato wrote:
> From: Luca Miccio
>
> Add a new command line parameter to configure Xen cache colors.
> These colors can be dumped with the cache coloring info debug-key.
>
> By default, Xen uses the first color.
> Benchmarking the VM interrupt response time provides
flight 185098 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185098/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 35f6a2780e5198315a9f100c07b3bc86187d20a8
baseline version:
ovmf
On 15.03.2024 11:58, Carlo Nonato wrote:
> Add a new PGC_no_buddy_merge flag that prevents the buddy algorithm in
> free_heap_pages() from merging pages that have it set. As of now, only
> PGC_static has this feature, but future work can extend it easier than
> before.
>
Suggested-by: Jan
On 15.03.2024 11:58, Carlo Nonato wrote:
> PGC_static and PGC_extra needs to be preserved when assigning a page.
> Define a new macro that groups those flags and use it instead of or'ing
> every time.
>
> To make preserved flags even more meaningful, they are kept also when
> switching state in
On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -18,6 +18,63 @@ integer_param("llc-nr-ways", llc_nr_ways);
> /* Number of colors available in the LLC */
> static unsigned int __ro_after_init max_nr_colors;
>
> +static unsigned
On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/xen/common/llc-coloring.c
> +++ b/xen/common/llc-coloring.c
> @@ -253,6 +253,37 @@ 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
On 15.03.2024 11:58, Carlo Nonato wrote:
> @@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
> xfree(__va(__pa(d->llc_colors)));
> }
>
> +int domain_set_llc_colors(struct domain *d,
> + const struct xen_domctl_set_llc_colors *config)
> +{
> +
On 15.03.2024 11:58, Carlo Nonato wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>
> Specify a list of IO ports to be excluded from dom0 access.
>
> +### dom0-llc-colors
> +> `= List of [ |
Commit d638e304f13a introduced a bullet list, but parse-support-md
choke on it as it doesn't know what to do about it.
Introduce ri_BulletList() so that r_content() will find this new
function and call it instead of calling process_unknown().
Reported-by: Julien Grall
Fixes: d638e304f13a
On 15.03.2024 11:58, Carlo Nonato wrote:
> +Background
> +**
> +
> +Cache hierarchy of a modern multi-core CPU typically has first levels
> dedicated
> +to each core (hence using multiple cache units), while the last level is
> shared
> +among all of them. Such configuration implies that
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> The user of shm_mem member of the 'struct kernel_info' is only
> the code managing the static shared memory feature, which can be
> compiled out using CONFIG_STATIC_SHM, so in case the feature is
> not requested, that member won't be used
Right now, if the user requests the watchdog on the command line,
setup_apic_nmi_watchdog() will blindly assume that setting up the watchdog
worked. Reuse nmi_perfctr_msr to identify when the watchdog has been set up.
Rearrange setup_p6_watchdog() to not set nmi_perfctr_msr until the sanity
Andrew Cooper (2):
x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
x86/boot: Support the watchdog on newer AMD systems
xen/arch/x86/nmi.c | 36
1 file changed, 16 insertions(+), 20 deletions(-)
base-commit:
The MSRs used by setup_k7_watchdog() are architectural in 64bit. The Unit
Select (0x76, cycles not in halt state) isn't, but it hasn't changed in 23
years, making this a trend likely to continue.
Drop the family check. If the Unit Select does happen to change meaning in
the future,
On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote:
>
> On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> > Currently, multiboot2-compatible bootloaders can load ELF binaries and
> > a.out binaries. The presence of the address header tag determines
> > how the bootloader tries
On 2024-03-19 04:15, Jan Beulich wrote:
On 18.03.2024 22:21, Jason Andryuk wrote:
On 2024-03-15 05:48, Jan Beulich wrote:
On 14.03.2024 20:19, Jason Andryuk wrote:
On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++
flight 185094 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185094/
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 19 Mar 2024, at 13:10, Michal Orzel wrote:
>
> Hi Luca,
Hi Michal,
Thanks for having a look
>
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> Currently the 'stuct meminfo' is defining a static defined array of
>> 'struct membank' of NR_MEM_BANKS elements, some feature like
>>
With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
functions") having removed the sole place where d->g_iommu would be set
to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
latest from its 2nd if(). With it dropped, all other stuff in the file
is unused, too.
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 pointers to "unsigned long"
while at the same time making the necessary multiplication explicit.
Remaining arithmetic
When not holding the PoD lock across the entire region covering P2M
update and stats update, the entry count - if to be incorrect at all -
should indicate too large a value in preference to a too small one, to
avoid functions bailing early when they find the count is zero. However,
instead of
On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> Currently, multiboot2-compatible bootloaders can load ELF binaries and
> a.out binaries. The presence of the address header tag determines
> how the bootloader tries to interpret the binary (a.out if the address
> tag is present
On 19.03.2024 08:33, Jan Beulich wrote:
> On 18.03.2024 19:13, Andrew Cooper wrote:
>> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
>> name of FAST_REP_SCASB.
>
> With FSRS already used, I guess that's the closest we can get to keep
> names for similar features
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> Currently the 'stuct meminfo' is defining a static defined array of
> 'struct membank' of NR_MEM_BANKS elements, some feature like
> shared memory don't require such amount of memory allocation but
> might want to reuse existing code to
flight 185093 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185093/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-pvopsbroken
build-amd64-pvops 5 host-build-prep
On Thu, Mar 14, 2024 at 02:24:31PM +, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
> >
> > On 14.03.2024 10:30, Ross Lagerwall wrote:
> > > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
> > >>
> > >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > >>> In
flight 185080 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185080/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail REGR. vs. 184921
Tests which are
The single user wants this the sane way around. Write it as a normal static
inline just like rspin_lock().
Fixes: cc3e8df542ed ("xen/spinlock: add rspin_[un]lock_irq[save|restore]()")
Signed-off-by: Andrew Cooper
---
CC: Juergen Gross
CC: George Dunlap
CC: Jan Beulich
CC: Stefano Stabellini
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> Putting overlap and overflow checking in the loop is causing repetitive
> operation, so this commit extracts both checking outside the loop.
>
> Signed-off-by: Penny Zheng
> Signed-off-by: Luca Fancellu
> ---
>
On Wed, Mar 13, 2024 at 03:07:43PM +, Ross Lagerwall wrote:
> Binaries may be built with entry points above 4G. While bootloaders may
> relocate them below 4G, it should be possible for the binary to specify
> those entry points. Therefore, extend the multiboot2 protocol such that
> 64 bit
On 19.03.2024 09:50, Michal Orzel wrote:
> After introduction of lock_evaluate_nospec() using bool type, building
> Xen on Arm with UBSAN enabled fails:
>
> In file included from ./include/xen/spinlock.h:4,
> from common/ubsan/ubsan.c:13:
> ./include/xen/nospec.h:79:22: error:
After introduction of lock_evaluate_nospec() using bool type, building
Xen on Arm with UBSAN enabled fails:
In file included from ./include/xen/spinlock.h:4,
from common/ubsan/ubsan.c:13:
./include/xen/nospec.h:79:22: error: unknown type name ‘bool’
79 | static always_inline
On 18.03.2024 22:03, Stewart Hildebrand wrote:
> On 2/14/24 10:41, Jan Beulich wrote:
>> On 02.02.2024 22:33, Stewart Hildebrand wrote:
>>> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
>>> if ( pdev->ignore_bars )
>>> return 0;
>>>
>>> -/* Disable
On 18.03.2024 22:21, Jason Andryuk wrote:
> On 2024-03-15 05:48, Jan Beulich wrote:
>> On 14.03.2024 20:19, Jason Andryuk wrote:
>>> On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++
On 18.03.2024 22:19, Jason Andryuk wrote:
> On 2024-03-14 10:19, Jan Beulich wrote:
>> On 14.03.2024 15:13, Jason Andryuk wrote:
>>> On 2024-03-14 09:21, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/include/public/elfnote.h
> +++
On 19.03.2024 04:37, Stefano Stabellini wrote:
> On Mon, 18 Mar 2024, Jan Beulich wrote:
>> On 16.03.2024 01:07, Stefano Stabellini wrote:
>>> On Fri, 15 Mar 2024, Jan Beulich wrote:
On 14.03.2024 23:17, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on
On 19.03.2024 04:34, Stefano Stabellini wrote:
> On Mon, 18 Mar 2024, Jan Beulich wrote:
>> On 16.03.2024 01:43, Stefano Stabellini wrote:
>>> On Fri, 15 Mar 2024, Jan Beulich wrote:
On 14.03.2024 23:59, Stefano Stabellini wrote:
> On Mon, 11 Mar 2024, Simone Ballarin wrote:
>> On
On 18.03.2024 19:13, Andrew Cooper wrote:
> I'm not sure about FSRSC as a name, but it definitely beats AMD's longhand
> name of FAST_REP_SCASB.
With FSRS already used, I guess that's the closest we can get to keep
names for similar features similar.
> --- a/tools/misc/xen-cpuid.c
> +++
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.9-rc1-tag
xen: branch for v6.9-rc1
It contains the following patches:
- 2 patches for Xen event channel handling fixing a regression wit a
rare kernel config and adding some
67 matches
Mail list logo
