Some parts of the build, like "make -C xen defconfig" use the "hostname"
binary, which may not be installed by default. At least the openSUSE
containers lack it. The configure scripts already have code like
"hostname | uname -n" to handle this. I think 'uname -n' gives the same
result as 'hostname'
The current usage of memblock_reserve() in init_pvh_bootparams() is done before
the .bss is zeroed, and that used to be fine when
memblock_reserved_init_regions implicitly ended up in the .meminit.data
section. However after commit 73db3abdca58c memblock_reserved_init_regions
ends up in the .bss s
Hello,
First patch is just code movement, the second patch is the actual
bugfix.
Thanks, Roger.
Roger Pau Monne (2):
x86/xen: move xen_reserve_extra_memory()
x86/xen: fix memblock_reserve() usage on PVH
arch/x86/include/asm/xen/hypervisor.h | 5 --
arch/x86/platform/pvh/enlighten.c |
In preparation for making the function static.
No functional change.
Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
Signed-off-by: Roger Pau Monné
---
Since this is a pre-requisite for a bugfix, I've tagged it with "Fixes:", not
sure if that's appropriate or there'
flight 186985 xen-unstable real [real]
flight 186999 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186985/
http://logs.test-lab.xenproject.org/osstest/logs/186999/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 25.07.24 09:31, Roger Pau Monne wrote:
The current usage of memblock_reserve() in init_pvh_bootparams() is done before
the .bss is zeroed, and that used to be fine when
memblock_reserved_init_regions implicitly ended up in the .meminit.data
section. However after commit 73db3abdca58c memblock
On 25.07.24 09:31, Roger Pau Monne wrote:
In preparation for making the function static.
No functional change.
Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
Signed-off-by: Roger Pau Monné
Without the Fixes: tag (can be dropped while committing):
Reviewed-by:
On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
> On 25.07.24 09:31, Roger Pau Monne wrote:
> > The current usage of memblock_reserve() in init_pvh_bootparams() is done
> > before
> > the .bss is zeroed, and that used to be fine when
> > memblock_reserved_init_regions implicitly ended
flight 187000 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187000/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 556640bceac32c86a843d09a1dd0688e44883781
baseline version:
ovmf 6271b617b4e6530292461
Introduce --force option to xen-ucode to force skipping microcode version
check, which
allows the user to update x86 microcode even if both versions are the same or
downgrade.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2.
Signed-off-by: Fouad Hilly
Revie
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
This change is required to enable developers to load ucode that is t
Pass xen-ucode flags to do low level checks on micorocde version and
utilize it to allow for microcode downgrade or reapply the same version of the
microcode.
ucode_force is required to be passed to a low level Intel and AMD for version
checks to be done.
While adding ucode_force, opt_ucode_allow_s
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
Introducing usage() to handle usage\help messages in a common block.
show_curr_cpu is printed to stdout only.
Signed-off-by: Fouad Hilly
---
[v6]
1- Update usage() printed message format: [microcode
Refactor microcode_update() by adding flags field.
struct xenpf_microcode_update2 added with uint32_t flags field.
Introduce XENPF_microcode_update2 hypercall with flags field.
Signed-off-by: Fouad Hilly
Reviewed-by: Andrew Cooper
---
[v6]
No change
[v5]
1- Update commit message to include the f
On 25.07.2024 10:27, Fouad Hilly wrote:
> @@ -71,12 +72,29 @@ static void show_curr_cpu(FILE *f)
> }
> }
>
> +static void usage(FILE *stream, const char *name)
> +{
> +fprintf(stream,
> +"%s: Xen microcode updating tool\n"
> +"options:\n"
> +" -h, --
On 25.07.2024 10:27, Fouad Hilly wrote:
> @@ -71,12 +72,29 @@ static void show_curr_cpu(FILE *f)
> }
> }
>
> +static void usage(FILE *stream, const char *name)
> +{
> +fprintf(stream,
> +"%s: Xen microcode updating tool\n"
> +"options:\n"
> +" -h, --
On 25.07.2024 10:27, Fouad Hilly wrote:
> Introduce --force option to xen-ucode to force skipping microcode version
> check, which
> allows the user to update x86 microcode even if both versions are the same or
> downgrade.
> xc_microcode_update() refactored to accept flags and utilize
> xenpf_m
On 25.07.24 10:10, Roger Pau Monné wrote:
On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
On 25.07.24 09:31, Roger Pau Monne wrote:
The current usage of memblock_reserve() in init_pvh_bootparams() is done before
the .bss is zeroed, and that used to be fine when
memblock_reserved_in
On 23.07.2024 05:24, Marek Marczykowski-Górecki wrote:
> +static int __init subpage_mmio_ro_add_page(
> +mfn_t mfn,
> +unsigned int offset_s,
> +unsigned int offset_e)
> +{
> +struct subpage_ro_range *entry = NULL;
> +bool new_entry = false;
> +unsigned int i;
> +
> +ent
While the CHECK_* macro invocations exist for these, the just-in-case
CASE() invocations were missing for them.
Fixes: a98dc13703e0 ("Introduce a grant_entry_v2 structure")
Signed-off-by: Jan Beulich
---
Alternatively, as I'm under the impression Andrew would prefer it, we
could decide to drop al
flight 186989 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186989/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827
test-amd64-amd64-do
The current code in ALT_CALL_ARG() won't successfully workaround the clang
code-generation issue if the arg parameter has a size that's not a power of 2.
While there are no such sized parameters at the moment, improve the workaround
to also be effective when such sizes are used.
Instead of using a
On Mon, Jun 17, 2024 at 08:04:41AM +0200, Christoph Hellwig wrote:
> Use the chance to switch to defaulting to non-rotational and require
> the driver to opt into rotational, which matches the polarity of the
> sysfs interface.
[...]
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index
On Thu, Jul 25, 2024 at 01:35:46PM +0200, Wouter Verhelst wrote:
> NBD actually exports a flag for rotational devices; it's defined in
> nbd.h in the NBD userland source as
>
> #define NBD_FLAG_ROTATIONAL (1 << 4)/* Use elevator algorithm -
> rotational media */
>
> which is passed i
flight 186998 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186998/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186977
test-amd64-amd64-libvirt-xsm 15 migrate-s
flight 187003 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187003/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8665187b017b0e4e4febf2241b433e6371f6e7e1
baseline version:
ovmf 556640bceac32c86a843d
On 25.07.2024 12:56, Roger Pau Monne wrote:
> --- a/xen/arch/x86/include/asm/alternative.h
> +++ b/xen/arch/x86/include/asm/alternative.h
> @@ -184,11 +184,11 @@ extern void alternative_branches(void);
> * https://github.com/llvm/llvm-project/issues/82598
> */
> #define ALT_CALL_ARG(arg, n)
Signed-off-by: Oleksii Kurochko
---
CHANGELOG.md | 24
1 file changed, 24 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f8fbe82df6..39e8737e61 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -15,6 +15,17 @@ The format is based on [Keep a
Changelog](https:
On Thu, May 16, 2024 at 03:58:28PM +0200, Marek Marczykowski-Górecki wrote:
> Especially allow it to control MSI/MSI-X enabling bits. This part only
> writes a flag to a sysfs, the actual implementation is on the kernel
> side.
>
> This requires Linux >= 5.10 in dom0 (or relevant patch backported).
On Thu, Jul 25, 2024 at 02:06:04PM +, Anthony PERARD wrote:
> On Thu, May 16, 2024 at 03:58:28PM +0200, Marek Marczykowski-Górecki wrote:
> > Especially allow it to control MSI/MSI-X enabling bits. This part only
> > writes a flag to a sysfs, the actual implementation is on the kernel
> > side.
All,
the releases are due in about two weeks. Please point out backports you find
missing from the respective staging branches, but which you consider relevant.
Note that 4.17.5 is going to be the last Xen Project coordinated ordinary stable
release from the 4.17 branch; the branch will move into
On Thu, Jul 25, 2024 at 03:18:29PM +0200, Jan Beulich wrote:
> On 25.07.2024 12:56, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/include/asm/alternative.h
> > +++ b/xen/arch/x86/include/asm/alternative.h
> > @@ -184,11 +184,11 @@ extern void alternative_branches(void);
> > * https://github.com/l
On Thu, Jul 25, 2024 at 03:20:29PM +0200, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> CHANGELOG.md | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/CHANGELOG.md b/CHANGELOG.md
> index f8fbe82df6..39e8737e61 100644
> --- a/CHANGELOG.md
> +++
On 25.07.2024 16:54, Roger Pau Monné wrote:
> On Thu, Jul 25, 2024 at 03:18:29PM +0200, Jan Beulich wrote:
>> On 25.07.2024 12:56, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/include/asm/alternative.h
>>> +++ b/xen/arch/x86/include/asm/alternative.h
>>> @@ -184,11 +184,11 @@ extern void alternati
On Wed, May 15, 2024 at 10:10:10PM -0400, Jason Andryuk wrote:
> +static void cdrom_insert_stubdom_parse_fdset_rm(libxl__egc *egc,
> +libxl__ev_qmp *qmp,
> +const libxl__json_object
> *resp,
> +
flight 187001 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187001/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186985
test-amd64-amd64-xl-qemut-win7-amd64
A bit about Apple Silicon M1(2,3,4) architecture, SoC and motherboard.
(AFAIK)
There are no EFI assumptions nor contracts, and no EFI firmware.
Between those 4 generations of silicon, there are about 80 different
roles "SoC cores/components" can play, each with its own signed Apple
Firmware.
Mos
From: Victor Lira
Requested-by: Jan Beulich
Signed-off-by: Victor Lira
---
Notes:
This is a utilty script for help with the MISRA process.
This script matches all linker symbol names in linker script files for
arm or x86.
Not included are symbol names starting with "." or symbol names enclosed
Thanks all for suggestions in v2.
Do we need to worry about duplicates or alphabetically sorting/filtering
the output here? As it stands there are no duplicates but I think it can
happen with linker syntax.
Victor
On 2024-07-25 21:06, Lira, Victor M wrote:
Thanks all for suggestions in v2.
Do we need to worry about duplicates or alphabetically
sorting/filtering the output here? As it stands there are no duplicates
but I think it can happen with linker syntax.
Victor
Hi,
for the specific task it wil
On 2024-07-25 21:01, victorm.l...@amd.com wrote:
From: Victor Lira
Requested-by: Jan Beulich
Signed-off-by: Victor Lira
---
Notes:
This is a utilty script for help with the MISRA process.
This script matches all linker symbol names in linker script files for
arm or x86.
Not included are symbo
flight 187008 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187008/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1bce5e5649840159d54eb8bffa4fa3d4fae8ee6
baseline version:
ovmf 8665187b017b0e4e4febf
On Thu, 25 Jul 2024, Techguru wrote:
> A bit about Apple Silicon M1(2,3,4) architecture, SoC and motherboard. (AFAIK)
>
> There are no EFI assumptions nor contracts, and no EFI firmware.
> Between those 4 generations of silicon, there are about 80 different roles
> "SoC cores/components" can play
On Thu, 25 Jul 2024, Nicola Vetrini wrote:
> On 2024-07-25 21:01, victorm.l...@amd.com wrote:
> > From: Victor Lira
> >
> > Requested-by: Jan Beulich
> > Signed-off-by: Victor Lira
> > ---
> > Notes:
> > This is a utilty script for help with the MISRA process.
> > This script matches all linker
flight 187002 linux-6.1 real [real]
flight 187009 linux-6.1 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187002/
http://logs.test-lab.xenproject.org/osstest/logs/187009/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd6
On Sat, 20 Jul 2024, Marek Marczykowski-Górecki wrote:
> `cp --preserve=xattr` doesn't work in docker when SELinux is enabled. It
> tries to set the "security.selinux" xattr, but SELinux (or overlay fs?)
> denies it.
> Workaround it by skipping selinux.selinux xattr copying.
>
> Signed-off-by: Mar
Upgrade Yocto to a newer version. Use ext4 as image format for testing
with QEMU on ARM and ARM64 as the default is WIC and it is not available
for our xen-image-minimal target.
Signed-off-by: Stefano Stabellini
---
I am running one last test (that takes hours) I'll make sure it passes
before I c
On Thu, Jul 25, 2024 at 11:26:31AM +0200, Jan Beulich wrote:
> On 23.07.2024 05:24, Marek Marczykowski-Górecki wrote:
> > + * so tolerate it.
> > + * But unaligned size would result in smaller area, so deny it.
> > + */
> > +ASSERT(IS_ALIGNED(start, MMIO_RO_SUBPAGE_GRAN));
> > +
Not the whole page, which may contain other registers too. The XHCI
specification describes DbC as designed to be controlled by a different
driver, but does not mandate placing registers on a separate page. In fact
on Tiger Lake and newer (at least), this page do contain other registers
that Linux
On older systems, XHCI xcap had a layout that no other (interesting) registers
were placed on the same page as the debug capability, so Linux was fine with
making the whole page R/O. But at least on Tiger Lake and Alder Lake, Linux
needs to write to some other registers on the same page too.
Add a
In some cases, only few registers on a page needs to be write-protected.
Examples include USB3 console (64 bytes worth of registers) or MSI-X's
PBA table (which doesn't need to span the whole table either), although
in the latter case the spec forbids placing other registers on the same
page. Curre
flight 187004 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187004/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827
test-amd64-amd64-do
On 2024-07-26 00:43, Stefano Stabellini wrote:
On Thu, 25 Jul 2024, Nicola Vetrini wrote:
On 2024-07-25 21:01, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Requested-by: Jan Beulich
> Signed-off-by: Victor Lira
> ---
> Notes:
> This is a utilty script for help with the MISRA process.
>
flight 187012 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187012/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ffc09b51cb7cc47bc80730d6c9e14563140dd052
baseline version:
ovmf b1bce5e5649840159d54e
On 2024/7/23 06:10, Stefano Stabellini wrote:
> On Mon, 8 Jul 2024, Jiqian Chen wrote:
>> Some type of domains don't have PIRQs, like PVH, it doesn't do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest base on PVH dom0, callstack
>> pci_add_dm_done->XEN_DOMCTL_irq_permissio
Hi Daniel,
On 2024/7/9 21:08, Jan Beulich wrote:
> On 08.07.2024 13:41, Jiqian Chen wrote:
>> Some type of domains don't have PIRQs, like PVH, it doesn't do
>> PHYSDEVOP_map_pirq for each gsi. When passthrough a device
>> to guest base on PVH dom0, callstack
>> pci_add_dm_done->XEN_DOMCTL_irq_perm
56 matches
Mail list logo
