flight 187880 qemu-mainline real [real]
flight 187885 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187880/
http://logs.test-lab.xenproject.org/osstest/logs/187885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 187883 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187883/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 10783187ddb71808a4ea361e887800d3b899b85f
baseline version:
ovmf 48b5815d7771b92f343bf
flight 187878 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187878/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187867
test-amd64-amd64-xl-qemuu-win7-amd64
Introduce functions to work with the SBI RFENCE extension for issuing
various fence operations to remote CPUs.
Add the sbi_init() function along with auxiliary functions and macro
definitions for proper initialization and checking the availability of
SBI extensions. Currently, this is implemented
On Fri Sep 27, 2024 at 3:39 PM BST, Alejandro Vallejo wrote:
> Would whoever planned to commit this mind replacing the commit msg on commit?
> Otherwise I'll just resend.
Actually, I've just re-sent it to avoid confusions. Apologies.
Cheers,
Alejandro
On 2024-09-26 06:41, Ard Biesheuvel wrote:
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assume
flight 187881 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187881/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 48b5815d7771b92f343bfa2b32b70be36c98e6f3
baseline version:
ovmf 8b295e0aad55cdf0c20eb
flight 187879 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187879/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8b295e0aad55cdf0c20eba6398862832ce188a0c
baseline version:
ovmf ded3ae2cf4ba974313f8a
Set up fixmap mappings and the L0 page table for fixmap support.
Modify the PTEs (xen_fixmap[]) directly in arch_pmap_map() instead
of using set_fixmap() which is expected to be implemented using
map_pages_to_xen(), which, in turn, is expected to use
arch_pmap_map() during early boot, resulting in
flight 187872 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187872/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs.
187720
Tests whi
Current patch series introduces device tree mapping for RISC-V
and necessary things for that such as:
- Fixmap mapping
- pmap
- Xen page table processing
---
Changes in v8:
- The following patch was merged to staging:
[PATCH v5 1/7] xen/riscv: use {read,write}{b,w,l,q}_cpu() to define
{read
The pull request you sent on Fri, 27 Sep 2024 11:43:37 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.12-rc1a-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/653608c67ae3dce1c5dee8c620ce6016e174bbd1
Thank you!
--
Deet-doot-dot,
Refactor arm/xen.lds.S by replacing the inline definitions for
device info sections with the newly introduced {DT,ACPI}_DEV_INFO
macros from xen/xen.lds.h.
Change alignment of DT_DEV_INFO and ACPI_DEV_INFO sections from
8 to POINTER_ALIGN as struct acpi_device_desc and struct device_desc
don't hav
The {acpi_}device_init() and device_get_class() functions are identical across
Arm and RISC-V, and they are likely to remain the same for other architectures
like PPC.
Since there is no architecture-specific logic within these functions, they are
good candidates to be moved to the common codebase.
Update the defintion of write_atomic() to support non-scalar types,
bringing it closer to the behavior of read_atomic().
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
xen/arch/riscv/include/asm/atomic.h | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/
Introduce arch_pmap_{un}map functions and select HAS_PMAP for CONFIG_RISCV.
Add pte_from_mfn() for use in arch_pmap_map().
Introduce flush_xen_tlb_one_local() and use it in arch_pmap_{un}map().
Signed-off-by: Oleksii Kurochko
Reviewed-by: Jan Beulich
---
xen/arch/riscv/Kconfig
Introduce function which allows to map FDT to Xen.
Also, initialization of device_tree_flattened happens using
early_fdt_map().
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
xen/arch/riscv/include/asm/mm.h | 2 ++
xen/arch/riscv/mm.c | 55 ++
Implement map_pages_to_xen() which requires several
functions to manage page tables and entries:
- pt_update()
- pt_mapping_level()
- pt_update_entry()
- pt_next_level()
- pt_check_entry()
To support these operations, add functions for creating,
mapping, and unmapping Xen tables:
- create_table()
Introduce struct pcpu_info to store pCPU-related information.
Initially, it includes only processor_id and hart id, but it
will be extended to include guest CPU information and
temporary variables for saving/restoring vCPU registers.
Add set_processor_id() function to set processor_id stored in
pc
Introduce DECL_SECTION_WITH_LADDR in order to signal whether
DECL_SECTION() should specify a load address or not.
Update {ppc,x86}/xen.lds.S to use DECL_SECTION_WITH_LADDR.
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V5:
- s/SIMPLE_DECL_SECTION/DECL_SECTION_WITH_LADDR.
Remove the device initialization code from `xen/arch/arm/device.c`
and move it to the common code to avoid duplication and make it accessible
for both ARM and other architectures.
device_get_class(), device_init(), _sdevice[] and _edevice[] are wrapped by
"#ifdef CONFIG_HAS_DEVICE_TREE" for the cas
Introduce a new `.dev.info` section in the PPC linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end of
Introduce macros to define device information sections based on
the configuration of ACPI or device tree support. These sections
are required for common code of device initialization and getting
an information about a device.
These macros are expected to be used across different
architectures (Arm
Introduce a new `.dev.info` section in the RISC-V linker script to
handle device-specific information. This section is required by
common code (common/device.c: device_init(), device_get_class() ).
This section is aligned to `POINTER_ALIGN`, with `_sdevice` and `_edevice`
marking the start and end
On Wed, Sep 25, 2024 at 05:01:02PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> Bump the minimum GCC version to 8.1 to gain unconditional support for
> referring to the per-task stack cookie using a symbol rather than
> relying on the fixed offset of 40 bytes from %GS, which requires
>
flight 187869 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187869/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187861
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 187877 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187877/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ded3ae2cf4ba974313f8ab043f610b1e6d3ddcdc
baseline version:
ovmf fe93b3745f13d7eb891d9
Hitting a page fault clobbers %cr2, so if a page fault is handled while
handling a previous page fault then %cr2 will hold the address of the
latter fault rather than the former. In particular, if a debug key
handler happens to trigger during #PF and before %cr2 is read, and that
handler itself enc
On Fri Sep 27, 2024 at 3:23 PM BST, Alejandro Vallejo wrote:
> Hitting a page fault clobbers %cr2, so if a page fault is handled while
> handling a previous page fault then %cr2 will hold the address of the
> latter fault rather than the former. This patch makes the page fault
> path delay re-enabl
Hitting a page fault clobbers %cr2, so if a page fault is handled while
handling a previous page fault then %cr2 will hold the address of the
latter fault rather than the former. This patch makes the page fault
path delay re-enabling IRQs until %cr2 has been read in order to ensure
it stays consist
On Wed Sep 25, 2024 at 7:35 AM BST, Jan Beulich wrote:
> On 24.09.2024 20:36, Andrew Cooper wrote:
> > On 23/09/2024 2:03 pm, Jan Beulich wrote:
> >> On 23.09.2024 12:14, Alejandro Vallejo wrote:
> >>> On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote:
> On Wed, Sep 18, 2024 at 02:05:5
Hi,
On Tue Sep 24, 2024 at 7:36 PM BST, Andrew Cooper wrote:
> On 23/09/2024 2:03 pm, Jan Beulich wrote:
> > On 23.09.2024 12:14, Alejandro Vallejo wrote:
> >> On Fri Sep 20, 2024 at 3:12 PM BST, Roger Pau Monné wrote:
> >>> On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote:
>
flight 187867 linux-linus real [real]
flight 187876 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187867/
http://logs.test-lab.xenproject.org/osstest/logs/187876/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 27/09/2024 7:25 am, Jan Beulich wrote:
> On 26.09.2024 18:03, Frediano Ziglio wrote:
>> On Thu, Sep 26, 2024 at 3:46 PM Jan Beulich wrote:
>>> On 26.09.2024 15:48, Frediano Ziglio wrote:
--- a/xen/drivers/video/font_8x14.c
+++ b/xen/drivers/video/font_8x14.c
@@ -2059,7 +2059,7 @@
On 27.09.2024 13:32, oleksii.kuroc...@gmail.com wrote:
> Just to be sure. Do you mean the following:
>
> diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c
> index d7eb207ddc..6cd2e595b6 100644
> --- a/xen/arch/riscv/pt.c
> +++ b/xen/arch/riscv/pt.c
> @@ -209,24 +209,15 @@ static int pt_update
On 27.09.2024 12:42, oleksii.kuroc...@gmail.com wrote:
> On Fri, 2024-09-27 at 11:41 +0200, Roger Pau Monné wrote:
>> On Fri, Sep 27, 2024 at 11:07:58AM +0200,
>> oleksii.kuroc...@gmail.com wrote:
>>> On Fri, 2024-09-27 at 09:58 +0200, Roger Pau Monné wrote:
On Thu, Sep 26, 2024 at 06:54:20PM
On Fri, 2024-09-27 at 11:15 +0200, Jan Beulich wrote:
> On 27.09.2024 10:49, oleksii.kuroc...@gmail.com wrote:
> > On Wed, 2024-09-25 at 16:58 +0200, Jan Beulich wrote:
> > > On 25.09.2024 16:50, oleksii.kuroc...@gmail.com wrote:
> > > > On Wed, 2024-09-25 at 16:22 +0200, Jan Beulich wrote:
> > > >
On Fri, 2024-09-27 at 11:41 +0200, Roger Pau Monné wrote:
> On Fri, Sep 27, 2024 at 11:07:58AM +0200,
> oleksii.kuroc...@gmail.com wrote:
> > On Fri, 2024-09-27 at 09:58 +0200, Roger Pau Monné wrote:
> > > On Thu, Sep 26, 2024 at 06:54:20PM +0200, Oleksii Kurochko wrote:
> > > > Introduce SIMPLE_DE
On Tue, Aug 13, 2024 at 03:16:42PM +0200, Jan Beulich wrote:
> On 26.07.2024 17:22, Roger Pau Monne wrote:
> > With the stack mapped on a per-CPU basis there's no risk of other CPUs being
> > able to read the stack contents, but vCPUs running on the current pCPU could
> > read stack rubble from ope
flight 187874 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187874/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fe93b3745f13d7eb891d9666debf2689a8975e5b
baseline version:
ovmf 3ed4f43f83c1f9ef6033a
On Fri, Aug 16, 2024 at 07:40:40PM +0100, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 4:22 PM BST, Roger Pau Monne wrote:
> > So far L4 slot 260 has always been per-domain, in other words: all vCPUs of
> > a
> > domain share the same L3 entry. Currently only 3 slots are used in that L3
> >
On 27.09.2024 11:42, Sergiy Kibrik wrote:
> 23.09.24 13:01, Jan Beulich:
>>> --- a/xen/arch/x86/domain.c
>>> +++ b/xen/arch/x86/domain.c
>>> @@ -758,6 +758,9 @@ static bool emulation_flags_ok(const struct domain
>>> *d, uint32_t emflags)
>>> (X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_U
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-6.12-rc1a-tag
xen: branch for v6.12-rc1a
It contains a second round of Xen related changes and features for the
6.12 merge window:
- A small fix of the xen-pciback driver for a warni
23.09.24 13:01, Jan Beulich:
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -758,6 +758,9 @@ static bool emulation_flags_ok(const struct domain
*d, uint32_t emflags)
(X86_EMU_ALL & ~(X86_EMU_VPCI | X86_EMU_USE_PIRQ)) &&
emflags != X86_EMU_LAPIC )
On Fri, Sep 27, 2024 at 11:07:58AM +0200, oleksii.kuroc...@gmail.com wrote:
> On Fri, 2024-09-27 at 09:58 +0200, Roger Pau Monné wrote:
> > On Thu, Sep 26, 2024 at 06:54:20PM +0200, Oleksii Kurochko wrote:
> > > Introduce SIMPLE_DECL_SECTION to cover the case when
> > > an architecture wants to dec
Hi Michal,
On Fri, 2024-09-27 at 09:16 +0200, Michal Orzel wrote:
> Hi Oleksii,
>
> On 26/09/2024 18:54, Oleksii Kurochko wrote:
> >
> >
> > Refactor arm/xen.lds.S by replacing the inline definitions for
> > device info sections with the newly introduced {DT,ACPI}_DEV_INFO
> > macros from xen/x
On Wed, Aug 21, 2024 at 05:42:26PM +0100, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> > index 9cfcf0dc63f3..b62c4311da6c 100644
> > --- a/xen/arch/x86/domain.c
> > +++ b/xen/arch/x86/domain.c
On Fri, 2024-09-27 at 09:28 +0200, Jan Beulich wrote:
> On 26.09.2024 18:54, Oleksii Kurochko wrote:
> > --- a/xen/include/xen/xen.lds.h
> > +++ b/xen/include/xen/xen.lds.h
> > @@ -120,6 +120,14 @@
> >
> > /* List of constructs other than *_SECTIONS in alphabetical order.
> > */
> >
> > +#defi
On 27.09.2024 10:49, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-09-25 at 16:58 +0200, Jan Beulich wrote:
>> On 25.09.2024 16:50, oleksii.kuroc...@gmail.com wrote:
>>> On Wed, 2024-09-25 at 16:22 +0200, Jan Beulich wrote:
On 25.09.2024 12:07, oleksii.kuroc...@gmail.com wrote:
> On Tue
On Fri, 2024-09-27 at 09:58 +0200, Roger Pau Monné wrote:
> On Thu, Sep 26, 2024 at 06:54:20PM +0200, Oleksii Kurochko wrote:
> > Introduce SIMPLE_DECL_SECTION to cover the case when
> > an architecture wants to declare a section without specifying
> > of load address for the section.
> >
> > Upda
On Wed, 2024-09-25 at 16:58 +0200, Jan Beulich wrote:
> On 25.09.2024 16:50, oleksii.kuroc...@gmail.com wrote:
> > On Wed, 2024-09-25 at 16:22 +0200, Jan Beulich wrote:
> > > On 25.09.2024 12:07, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-09-24 at 15:31 +0200, Jan Beulich wrote:
> > > >
On Thu, Sep 26, 2024 at 06:54:20PM +0200, Oleksii Kurochko wrote:
> Introduce SIMPLE_DECL_SECTION to cover the case when
> an architecture wants to declare a section without specifying
> of load address for the section.
>
> Update x86/xen.lds.S to use SIMPLE_DECL_SECTION.
No strong opinion, but I
On 26/09/2024 18:54, Oleksii Kurochko wrote:
>
>
> Remove the device initialization code from `xen/arch/arm/device.c`
> and move it to the common code to avoid duplication and make it accessible
> for both ARM and other architectures.
> device_get_class(), device_init(), _sdevice[] and _edevic
On 26.09.2024 18:54, Oleksii Kurochko wrote:
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -120,6 +120,14 @@
>
> /* List of constructs other than *_SECTIONS in alphabetical order. */
>
> +#define ACPI_DEV_INFO(secname) \
> + . = ALIGN(POINTER_ALIGN); \
> + DEC
On Fri, 27 Sept 2024 at 07:49, Ard Biesheuvel wrote:
>
> On Fri, 27 Sept 2024 at 03:47, Jason Andryuk wrote:
> >
> > On 2024-09-26 06:41, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel
> > >
> > > Xen puts virtual and physical addresses into ELF notes that are treated
> > > by the linker as re
Hi Oleksii,
On 26/09/2024 18:54, Oleksii Kurochko wrote:
>
>
> Refactor arm/xen.lds.S by replacing the inline definitions for
> device info sections with the newly introduced {DT,ACPI}_DEV_INFO
> macros from xen/xen.lds.h.
I would expect so see a note about s/8/POINTER_ALIGN/ that it's safe to
56 matches
Mail list logo
