Hi Julien,
On 16/01/2024 15:37, Julien Grall wrote:
>
>
> From: Julien Grall
>
> With the upcoming work to color Xen, the binary will not be anymore
> physically contiguous. This will be a problem during boot as the
> assembly code will need to work out where each piece of Xen reside.
>
> An
Hi Julien,
On 16/01/2024 15:37, Julien Grall wrote:
>
>
> From: Julien Grall
>
> With the upcoming work to color Xen, the binary will not be anymore
> physically contiguous. This will be a problem during boot as the
> assembly code will need to work out where each piece of Xen reside.
>
> An
On 17.01.2024 07:12, Patrick Plenefisch wrote:
> On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich wrote:
>
>> On 16.01.2024 01:22, Patrick Plenefisch wrote:
>>> I managed to set up serial access and saved the output with the requested
>>> flags as the attached logs
>>
>> Thanks. While you didn't ...
>
On Wed, Jan 17, 2024 at 01:12:30AM -0500, Patrick Plenefisch wrote:
> On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich wrote:
>
> > On 16.01.2024 01:22, Patrick Plenefisch wrote:
> > It remains to be seen in how far it is reasonably possible to work
> > around this in the kernel. While (sadly) still u
On 16/01/2024 15:37, Julien Grall wrote:
>
>
> From: Julien Grall
>
> With the upcoming work to color Xen, the binary will not be anymore
> physically contiguous. This will be a problem during boot as the
> assembly code will need to work out where each piece of Xen reside.
>
> An easy way
elf_load_binary() isn't the primary source of brokenness being
indicated. Therefore make the respective log message there conditional
(much like PV has it), and add another instance when elf_xen_parse()
failed (again matching behavior in the PV case).
Signed-off-by: Jan Beulich
--- a/xen/arch/x8
On 16.01.2024 18:31, Andrew Cooper wrote:
> On 16/01/2024 4:58 pm, Jan Beulich wrote:
>> This way we can arrange for ioemul_handle_proliant_quirk()'s ENDBR to
>> also be zapped. Utilize existing data rather than introducing another
>> otherwise unused static variable (array); eventually (if any new
This way we can arrange for core_parking_{performance,power}()'s ENDBR
to also be zapped.
For the decision to be taken before the 2nd alternative patching pass,
the initcall needs to become a pre-SMP one, though.
Signed-off-by: Jan Beulich
--- a/xen/common/core_parking.c
+++ b/xen/common/core_p
While .setup() and .e820_fixup() don't need fiddling with for being run
only very early, both .ap_setup() and .resume() want converting too:
This way both pre-filled struct hypervisor_ops instances can become
__initconst_cf_clobber, thus allowing to eliminate up to 5 more ENDBR
(configuration depen
Hi Julien,
On Tue, 2024-01-16 at 17:12 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 16/01/2024 09:44, Oleksii wrote:
> > On Mon, 2024-01-15 at 12:01 +0100, Jan Beulich wrote:
> > > On 15.01.2024 11:35, Oleksii wrote:
> > > > Hi Julien,
> > > >
> > > > On Fri, 2024-01-12 at 10:39 +, Julien
The use of (supposedly) vendor-specific hooks is a relic from the days
when Xen was still possible to build as 32-bit binary. There's no
expectation that a new need for such an abstraction would arise. Convert
mttr_if to a mere boolean and all prior calls through it to direct ones,
thus allowing to
This way ioemul_handle_proliant_quirk() won't need ENDBR anymore.
While touching this code, also
- arrange for it to not be built at all when !PV,
- add "const" to the last function parameter and bring the definition
in sync with the declaration (for Misra).
Signed-off-by: Jan Beulich
---
Obvi
On 15.01.2024 17:10, Jan Beulich wrote:
> Even functions used on infrequently executed paths want converting: This
> way all pre-filled struct cpufreq_driver instances can become
> __initconst_cf_clobber, thus allowing to eliminate another 15 ENDBR
> during the 2nd phase of alternatives patching.
>
flight 184374 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184374/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 12 windows-install fail in 184365 pass in
184374
test-armhf-armhf-libvirt
1: separate BSP-only initialization
2: switch some callback invocations to altcall
Jan
Several function pointers are registered over and over again, when
setting them once on the BSP suffices. Arrange for this in the vendor
init functions and mark involved registration functions __init.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mche
While not performance critical, these hook invocations still would
better be converted: This way all pre-filled (and newly introduced)
struct mce_callback instances can become __initconst_cf_clobber, thus
allowing to eliminate another 9 ENDBR during the 2nd phase of
alternatives patching.
While th
Hi Bertrand,
On Mon, Jan 15, 2024 at 12:15 PM Bertrand Marquis
wrote:
>
> Hi Jens,
>
> Very sorry for the long delay.
>
> > On 13 Dec 2023, at 12:25, Jens Wiklander wrote:
> >
> > When an FF-A enabled guest is destroyed it may leave behind memory
> > shared with SPs. This memory must be reclaime
On Wed, Jan 17, 2024 at 09:46:27AM +0100, Jan Beulich wrote:
> On 17.01.2024 07:12, Patrick Plenefisch wrote:
> > On Tue, Jan 16, 2024 at 4:33 AM Jan Beulich wrote:
> >> On 16.01.2024 01:22, Patrick Plenefisch wrote:
> >> It remains to be seen in how far it is reasonably possible to work
> >> arou
On Wed, Jan 17, 2024 at 09:53:26AM +0100, Jan Beulich wrote:
> elf_load_binary() isn't the primary source of brokenness being
> indicated. Therefore make the respective log message there conditional
> (much like PV has it), and add another instance when elf_xen_parse()
> failed (again matching beha
> kasprintf() returns a pointer to dynamically allocated memory
> which can be NULL upon failure. Ensure the allocation was successful
> by checking the pointer validity.
…
> +++ b/arch/x86/xen/smp.c
> @@ -61,10 +61,14 @@ void xen_smp_intr_free(unsigned int cpu)
>
> int xen_smp_intr_init(unsigned
On 17.01.2024 11:13, Roger Pau Monné wrote:
> On Wed, Jan 17, 2024 at 09:46:27AM +0100, Jan Beulich wrote:
>> Whereas I assume the native kernel can deal with that as long as
>> it's built with CONFIG_RELOCATABLE=y. I don't think we want to
>> get into the business of interpreting the kernel's inte
On 17.01.2024 11:25, Roger Pau Monné wrote:
> On Wed, Jan 17, 2024 at 09:53:26AM +0100, Jan Beulich wrote:
>> elf_load_binary() isn't the primary source of brokenness being
>> indicated. Therefore make the respective log message there conditional
>> (much like PV has it), and add another instance w
On 17/01/2024 10:42 am, Jan Beulich wrote:
> On 17.01.2024 11:25, Roger Pau Monné wrote:
>> On Wed, Jan 17, 2024 at 09:53:26AM +0100, Jan Beulich wrote:
>>> elf_load_binary() isn't the primary source of brokenness being
>>> indicated. Therefore make the respective log message there conditional
>>>
On 17/01/2024 9:37 am, Jan Beulich wrote:
> This way ioemul_handle_proliant_quirk() won't need ENDBR anymore.
>
> While touching this code, also
> - arrange for it to not be built at all when !PV,
> - add "const" to the last function parameter and bring the definition
> in sync with the declarati
When an FF-A enabled guest is destroyed it may leave behind memory
shared with SPs. This memory must be reclaimed before it's reused or an
SP may make changes to memory used by a new unrelated guest. So when the
domain is teared down add FF-A requests to reclaim all remaining shared
memory.
SPs in
On Tue, 2024-01-16 at 14:24 +0100, Jan Beulich wrote:
> On 16.01.2024 14:06, Oleksii wrote:
> > On Mon, 2024-01-15 at 17:44 +0100, Jan Beulich wrote:
> > > On 22.12.2023 16:12, Oleksii Kurochko wrote:
> > > > +#define test_and_set_bit __test_and_set_bit
> > > > +#define test_and_clear_bit __test_
On Wed, Jan 17, 2024 at 11:42:53AM +0100, Jan Beulich wrote:
> On 17.01.2024 11:25, Roger Pau Monné wrote:
> > On Wed, Jan 17, 2024 at 09:53:26AM +0100, Jan Beulich wrote:
> >> elf_load_binary() isn't the primary source of brokenness being
> >> indicated. Therefore make the respective log message t
On 17.01.2024 12:13, Oleksii wrote:
> On Tue, 2024-01-16 at 14:24 +0100, Jan Beulich wrote:
>> On 16.01.2024 14:06, Oleksii wrote:
>>> On Mon, 2024-01-15 at 17:44 +0100, Jan Beulich wrote:
On 22.12.2023 16:12, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/bito
On 1/16/2024 10:18, Jan Beulich wrote:
On 16.01.2024 16:52, Sébastien Chaumat wrote:
Le mar. 2 janv. 2024 à 21:23, Sébastien Chaumat a
écrit :
output of gpioinfo
kernel alone :
line 5: unnamed input active-low consumer=interrupt
line 84: unnamed inpu
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202401161119.iof6bqsf-...@i
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
---
arch/x86/xen/smp.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/xen/smp.c b/a
Hello Doug abd Stefano,
Could you please take a look at this patch and the next one [1] of this
patch series?
Thanks in advance.
[1]https://lore.kernel.org/xen-devel/db2c3d36b25b686bf07ac23f8ee8c879e0e9e81d.1703072575.git.oleksii.kuroc...@gmail.com/
Best regards,
Oleksii
On Wed, 2023-12-20
> > >
> > > > > Also you want to make sure asm-generic/bitops/bitops-bits.h
> > > > > is
> > > > > really in use here, or else an arch overriding / not using
> > > > > that
> > > > > header may end up screwed.
> > > > I am not really understand what do you mean. Could you please
> > > > explain a
On Tue, Jan 16, 2024 at 10:33:26AM +0100, Jan Beulich wrote:
> ... as per
>
> (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x4a0
>
> there's an overlap with not exactly a hole, but with an
> EfiACPIMemoryNVS region:
>
> (XEN) 00010-003159fff type=2 attr=0
On 17/01/2024 08:30, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 16/01/2024 15:37, Julien Grall wrote:
From: Julien Grall
With the upcoming work to color Xen, the binary will not be anymore
physically contiguous. This will be a problem during boot as the
assembly code will need to wo
On Wed, Jan 17, 2024 at 11:40:20AM +0100, Jan Beulich wrote:
> On 17.01.2024 11:13, Roger Pau Monné wrote:
> > On Wed, Jan 17, 2024 at 09:46:27AM +0100, Jan Beulich wrote:
> >> Whereas I assume the native kernel can deal with that as long as
> >> it's built with CONFIG_RELOCATABLE=y. I don't think
On Wed, Jan 17, 2024 at 01:06:53PM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 16, 2024 at 10:33:26AM +0100, Jan Beulich wrote:
> > ... as per
> >
> > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x4a0
> >
> > there's an overlap with not exactly a hole, but with an
> >
On 17/01/2024 13:10, Julien Grall wrote:
>
>
> On 17/01/2024 08:30, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 16/01/2024 15:37, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
>>> With the upcoming work to color Xen, the binary will not be anymore
>>> physically contig
flight 184385 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184385/
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 17.01.2024 13:59, Roger Pau Monné wrote:
> On Wed, Jan 17, 2024 at 01:06:53PM +0100, Marek Marczykowski-Górecki wrote:
>> On Tue, Jan 16, 2024 at 10:33:26AM +0100, Jan Beulich wrote:
>>> ... as per
>>>
>>> (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x100 -> 0x4a0
>>>
>>> there's an over
On 17.01.2024 12:37, Oleksii wrote:
>> Also you want to make sure asm-generic/bitops/bitops-bits.h
>> is
>> really in use here, or else an arch overriding / not using
>> that
>> header may end up screwed.
> I am not really understand what do you mean. Could you please
>
On 17/01/2024 9:32 am, Jan Beulich wrote:
> The use of (supposedly) vendor-specific hooks is a relic from the days
> when Xen was still possible to build as 32-bit binary. There's no
> expectation that a new need for such an abstraction would arise. Convert
> mttr_if to a mere boolean and all prior
flight 184378 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 debian-install fail REGR. vs. 184270
test-arm64-arm64-xl
Without this, building "ioemu-stubdom" fails on Debian Buster or
Bookworm, with:
/home/osstest/build.184372.build-amd64/xen/stubdom/mini-os-x86_64-ioemu/mini-os.o:
in function `xenfb_pv_display_init':
ungetc.c:(.text+0x43533): undefined reference to `pt_base'
Signed-off-by: Anthony PERARD
---
Anthony PERARD, le mer. 17 janv. 2024 15:37:45 +, a ecrit:
> Without this, building "ioemu-stubdom" fails on Debian Buster or
> Bookworm, with:
>
> /home/osstest/build.184372.build-amd64/xen/stubdom/mini-os-x86_64-ioemu/mini-os.o:
> in function `xenfb_pv_display_init':
> ungetc.c:(.text+0x435
On Mon, Jan 15, 2024 at 03:34:05PM +0100, Jan Beulich wrote:
> Recent gas versions generate minimalistic Dwarf debug info for items
> annotated as functions and having their sizes specified [1]. Furthermore
> generating live patches wants items properly annotated. "Borrow" Arm's
> END() and (remote
Hi everyone,
I've spent a bit of time talking to various individuals and the advisory
board about setting up a new Community Process Group.
A survey was recently conducted to identify how the community as a whole
feels about a certain situation. It was not intended to ban specific
wording or crea
Hi Julien
On Tue, Jan 16, 2024 at 3:37 PM Julien Grall wrote:
>
> From: Julien Grall
>
> In order to confirm the early boot code is self-contained, allocate a
> separate trampoline region for secondary to boot from it.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/arm64/mmu/mm.c | 7 ++
Hi Julien,
On Tue, Jan 16, 2024 at 12:59 PM Julien Grall wrote:
>
> Hi,
>
> On 15/01/2024 16:16, Julien Grall wrote:
> > On 15/01/2024 15:43, Carlo Nonato wrote:
> >> Hi Julien,
> >
> > Hi Carlo,
> >
> >> On Mon, Jan 15, 2024 at 12:18 PM Julien Grall wrote:
> >>> On 15/01/2024 10:11, Carlo Nonat
flight 184381 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184381/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-raw 17 guest-start/debian.repeatfail like 184327
test-armhf-armhf-xl-vhd 13 guest-s
The pull request you sent on Thu, 11 Jan 2024 13:19:43 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.8-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/82fd5ee9d8a516d47a17e8c99c2712a3fd937014
Thank you!
--
Deet-doot-dot, I
On 17/01/2024 9:31 am, Jan Beulich wrote:
> While .setup() and .e820_fixup() don't need fiddling with for being run
> only very early, both .ap_setup() and .resume() want converting too:
> This way both pre-filled struct hypervisor_ops instances can become
> __initconst_cf_clobber, thus allowing to
On 17/01/2024 9:29 am, Jan Beulich wrote:
> This way we can arrange for core_parking_{performance,power}()'s ENDBR
> to also be zapped.
>
> For the decision to be taken before the 2nd alternative patching pass,
> the initcall needs to become a pre-SMP one, though.
>
> Signed-off-by: Jan Beulich
R
On 17/01/2024 9:58 am, Jan Beulich wrote:
> 1: separate BSP-only initialization
> 2: switch some callback invocations to altcall
Reviewed-by: Andrew Cooper
On Fri, 12 Jan 2024, Michal Orzel wrote:
> Hi Carlo,
>
> On 23/01/2023 16:47, Carlo Nonato wrote:
> >
> >
> > From: Luca Miccio
> >
> > This commit allows the user to set the cache coloring configuration for
> > Dom0 via a command line parameter.
> > Since cache coloring and static memory are
Hi Julien,
On 12/20/23 7:49 AM, Julien Grall wrote:
> Hi,
>
> On 15/12/2023 02:44, Shawn Anastasio wrote:
>> diff --git a/xen/common/device-tree/bootfdt.c
>> b/xen/common/device-tree/bootfdt.c
>> index 796ac01c18..7ddfcc7e2a 100644
>> --- a/xen/common/device-tree/bootfdt.c
>> +++ b/xen/common/dev
Hi Jan,
On 12/20/23 5:48 AM, Jan Beulich wrote:
> On 15.12.2023 03:44, Shawn Anastasio wrote:
>> Now that we have common code building, there's no need to keep the old
>> itoa64+debug print function in mm-radix.c
>>
>> Signed-off-by: Shawn Anastasio
>
> Looks okay, just one question:
>
>> --- a
flight 184384 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184384/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-qcow2 13 guest-startfail in 184374 pass in 184384
test-amd64-amd64-xl-xsm 20
flight 184386 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184386/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 12 debian-install fail REGR. vs. 184270
test-arm64-arm64-xl
On 18/01/2024 01:23, Stefano Stabellini wrote:
>
>
> On Fri, 12 Jan 2024, Michal Orzel wrote:
>> Hi Carlo,
>>
>> On 23/01/2023 16:47, Carlo Nonato wrote:
>>>
>>>
>>> From: Luca Miccio
>>>
>>> This commit allows the user to set the cache coloring configuration for
>>> Dom0 via a command line p
61 matches
Mail list logo
