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
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
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
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:
>
>> ---
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
>> +++
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
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 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
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
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
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
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
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 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
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
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':
>
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
---
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
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
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 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
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
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
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 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 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
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
> > >
> > > > > 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
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,
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
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:
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
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
> +++
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
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
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
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
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 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
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
> 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 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
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
> >>
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
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
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
+++
1: separate BSP-only initialization
2: switch some callback invocations to altcall
Jan
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
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.
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
---
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
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 +,
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
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
+++
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
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
---
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
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
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 ...
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
61 matches
Mail list logo
