On 14.02.2025 00:28, Andrew Cooper wrote:
> On 13/02/2025 10:35 pm, dm...@proton.me wrote:
>> Every guest_printk() call computes "(d%d) " prefix on every call.
>> Move prefix generation to the domain creation time.
>>
>> Signed-off-by: Denis Mukhin
>
> I'm on the fence here.
>
> Part of that is
On 14.02.2025 08:46, Nicola Vetrini wrote:
> On 2025-02-14 04:00, Stefano Stabellini wrote:
>> On Thu, 13 Feb 2025, Stefano Stabellini wrote:
> diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h
> b/xen/arch/x86/cpu/mcheck/mctelem.h
> index f4c5ff848d..2ccd490e5d 100644
> --- a/xen/arc
On 13.02.2025 22:41, dm...@proton.me wrote:
> Add Xen version printout to 'h' keyhandler output.
>
> That is useful for debugging systems that have been left intact for a long
> time.
>
> Signed-off-by: Denis Mukhin
> ---
> Changes since v2:
> - moved new function declarations to xen/lib.h
> - d
On 13/02/2025 21:18, Stefano Stabellini wrote:
>
>
> On Thu, 13 Feb 2025, Jan Beulich wrote:
>> On 13.02.2025 15:18, GitLab wrote:
>>>
>>>
>>> Pipeline #1669696445 has failed!
>>>
>>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>>> Branch: staging (
>>> https://gitlab.com/xen
On 2025-02-14 04:00, Stefano Stabellini wrote:
On Thu, 13 Feb 2025, Stefano Stabellini wrote:
> > diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h
b/xen/arch/x86/cpu/mcheck/mctelem.h
> > index f4c5ff848d..2ccd490e5d 100644
> > --- a/xen/arch/x86/cpu/mcheck/mctelem.h
> > +++ b/xen/arch/x86/cpu/mch
On 13.02.2025 22:46, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Andrew Cooper wrote:
>> On 13/02/2025 7:26 pm, Stefano Stabellini wrote:
>>> On Thu, 13 Feb 2025, Luca Fancellu wrote:
> On 13 Feb 2025, at 15:42, Nicola Vetrini
> wrote:
> On 2025-02-13 16:32, Nicola Vetrini wrote:
On Thursday, February 13th, 2025 at 3:28 PM, Andrew Cooper
wrote:
>
>
> On 13/02/2025 10:35 pm, dm...@proton.me wrote:
>
> > Every guest_printk() call computes "(d%d) " prefix on every call.
> > Move prefix generation to the domain creation time.
> >
> > Signed-off-by: Denis Mukhin dmuk...@ford.
On 13.02.2025 20:26, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Luca Fancellu wrote:
>>> On 13 Feb 2025, at 15:42, Nicola Vetrini wrote:
>>> On 2025-02-13 16:32, Nicola Vetrini wrote:
On 2025-02-13 16:01, Jan Beulich wrote:
> On 13.02.2025 15:52, Nicola Vetrini wrote:
>> On 2025
On 14.02.2025 04:00, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Stefano Stabellini wrote:
diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h
b/xen/arch/x86/cpu/mcheck/mctelem.h
index f4c5ff848d..2ccd490e5d 100644
--- a/xen/arch/x86/cpu/mcheck/mctelem.h
+++ b/xen/arch/x86
On 14.02.2025 04:32, Chen, Jiqian wrote:
> On 2025/2/11 17:21, Roger Pau Monné wrote:
>> On Tue, Feb 11, 2025 at 10:22:57AM +0800, Jiqian Chen wrote:
>>> Some devices, like AMDGPU, support resizable bar capability,
>>> but vpci of Xen doesn't support this feature, so they fail
>>> to resize bars an
On 14.02.2025 00:05, Shawn Anastasio wrote:
> On 2/6/25 6:29 AM, Jan Beulich wrote:
>> On 05.02.2025 22:02, Shawn Anastasio wrote:
>>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>>> represent architecture-d
On 13.02.2025 19:32, Andrew Cooper wrote:
> On 13/02/2025 10:06 am, Jan Beulich wrote:
>> On 12.02.2025 18:20, Andrew Cooper wrote:
>>> Elsewhere in the tree we fix this with -ffreestanding -nostdinc
>>> -I$(XEN_ROOT)/tools/firmware/include but that isn't an option for
>>> test_x86_emulator in gene
On 13.02.2025 22:47, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Jan Beulich wrote:
>> On 13.02.2025 03:00, Stefano Stabellini wrote:
>>> On Wed, 12 Feb 2025, Stefano Stabellini wrote:
On Thu, 13 Feb 2025, Andrew Cooper wrote:
> On 13/02/2025 1:25 am, Stefano Stabellini wrote:
>>
On 13.02.2025 20:09, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Jan Beulich wrote:
>> On 13.02.2025 01:51, Andrew Cooper wrote:
>>> On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
> Hello everyone,
>
> During the installation of X
On 2025/2/11 17:21, Roger Pau Monné wrote:
> On Tue, Feb 11, 2025 at 10:22:57AM +0800, Jiqian Chen wrote:
>> Some devices, like AMDGPU, support resizable bar capability,
>> but vpci of Xen doesn't support this feature, so they fail
>> to resize bars and then cause probing failure.
>>
>> According t
On Thu, 13 Feb 2025, Stefano Stabellini wrote:
> > > diff --git a/xen/arch/x86/cpu/mcheck/mctelem.h
> > > b/xen/arch/x86/cpu/mcheck/mctelem.h
> > > index f4c5ff848d..2ccd490e5d 100644
> > > --- a/xen/arch/x86/cpu/mcheck/mctelem.h
> > > +++ b/xen/arch/x86/cpu/mcheck/mctelem.h
> > > @@ -52,7 +52,7 @
On Thu, Feb 13, 2025 at 05:36:47PM -0800, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Marek Marczykowski-Górecki wrote:
> > Debugging sometimes involves running specific jobs on different
> > versions. It's useful to easily avoid running all of the not interesting
> > ones (for given case) to
On Thu, 13 Feb 2025, Marek Marczykowski-Górecki wrote:
> Debugging sometimes involves running specific jobs on different
> versions. It's useful to easily avoid running all of the not interesting
> ones (for given case) to save both time and CI resources. Doing so used
> to require changing the yam
- Add some more test jobs
- Allow selecting individual jobs, without editing yaml files
I don't think it needs to be included in 4.20, but may be considered later for
backporting.
Marek Marczykowski-Górecki (4):
automation: skip building domU if there is no test defined for it
automation: add
Signed-off-by: Marek Marczykowski-Górecki
---
new in v2
If those tests are sensitive to underlying hardware, I guess it makes
sense to run them on other runners too. Are they?
Similarly - does it matter if dom0 is PV or PVH for those tests? If not,
probably better to put just one of those jobs (PV
There are a bunch of tests in tools/tests/, let them run in CI.
For each subdirectory expect "make run" will run the test, and observe
its exit code. This way, adding new tests is easy, and they will be
automatically picked up.
For better visibility, log test output to junit xml format, and let
gi
This will be useful for later tests not using generic domU (unit tests,
xtf etc).
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Stefano Stabellini
---
automation/scripts/qubes-x86-64.sh | 50 +++
1 file changed, 31 insertions(+), 19 deletions(-)
diff --git
Debugging sometimes involves running specific jobs on different
versions. It's useful to easily avoid running all of the not interesting
ones (for given case) to save both time and CI resources. Doing so used
to require changing the yaml files, usually in several places.
Ease this step by adding SE
On 13/02/2025 6:50 pm, Stewart Hildebrand wrote:
> When building with CONFIG_HVM=n and -Og, we encounter:
>
> prelink.o: in function `pit_set_gate':
> xen/xen/arch/x86/emul-i8254.c:195: undefined reference to
> `destroy_periodic_time'
>
> Add an IS_ENABLED(CONFIG_HVM) check to assist with dead cod
On 14/02/2025 12:34 am, Volodymyr Babchuk wrote:
> Hi Andrew,
>
> Andrew Cooper writes:
>
>> On 13/02/2025 10:00 pm, Volodymyr Babchuk wrote:
>>> Volodymyr Babchuk (4):
>>> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
>>> xen: common: add ability to enable stack protector
>>>
Hi Andrew,
Andrew Cooper writes:
> On 13/02/2025 10:00 pm, Volodymyr Babchuk wrote:
>> Volodymyr Babchuk (4):
>> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
>> xen: common: add ability to enable stack protector
>> xen: arm: enable stack protector feature
>> CHANGELOG
On 13/02/2025 10:35 pm, dm...@proton.me wrote:
> Every guest_printk() call computes "(d%d) " prefix on every call.
> Move prefix generation to the domain creation time.
>
> Signed-off-by: Denis Mukhin
I'm on the fence here.
Part of that is speaking as someone who has had to shrink struct domain
On 13/02/2025 10:00 pm, Volodymyr Babchuk wrote:
> Volodymyr Babchuk (4):
> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
> xen: common: add ability to enable stack protector
> xen: arm: enable stack protector feature
> CHANGELOG.md: Mention stack-protector feature
Given t
Hi Jan,
On 2/6/25 6:29 AM, Jan Beulich wrote:
> On 05.02.2025 22:02, Shawn Anastasio wrote:
>> Xen's memory management APIs map_pages_to_xen, modify_xen_mappings,
>> set_fixmap, ioremap_attr, and __vmap all use an unsigned int to
>> represent architecture-dependent page table entry flags. This ass
On Wed, 12 Feb 2025, dm...@proton.me wrote:
> Add new CONRING_SIZE Kconfig parameter to specify the boot console buffer size
> in bytes. The value is rounded to the nearest power of 2 to match existing
> conring_size= behavior.
>
> The supported range is [16KiB..128MiB].
>
> Bump default size to
Every guest_printk() call computes "(d%d) " prefix on every call.
Move prefix generation to the domain creation time.
Signed-off-by: Denis Mukhin
---
xen/arch/x86/pv/shim.c | 2 ++
xen/common/domain.c| 2 ++
xen/drivers/char/console.c | 6 +-
xen/include/xen/sched.h| 1 +
4 f
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This series
makes possible to use this feature in Xen. I tested this on ARM64 and
it is working as intended. Tested both with GCC and Clang.
It is hard to enable this fea
This patch is preparation for making stack protector
configurable. First step is to remove -fno-stack-protector flag from
EMBEDDED_EXTRA_CFLAGS so separate components (Hypervisor in this case)
can enable/disable this feature by themselves.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Jan Beulich
Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. Initialize stack protector very early, at the very beginning
of start_xen() function.
Signed-off-by: Volodymyr Babchuk
---
Changes in v5:
- Call boot_stack_chk_guard_setup() from start_xen()
instead of early ASM
---
Stack protector is meant to be enabled on all architectures, but
currently it is tested (and enabled) only on ARM, so mention it in ARM
section.
Signed-off-by: Volodymyr Babchuk
Reviewed-by: Andrew Cooper
---
CHANGELOG.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/CHANGELOG.md b/CHANGE
Both GCC and Clang support -fstack-protector feature, which add stack
canaries to functions where stack corruption is possible. This patch
makes general preparations to enable this feature on different
supported architectures:
- Added CONFIG_HAS_STACK_PROTECTOR option so each architecture
can
On Thu, 13 Feb 2025, Grygorii Strashko wrote:
> Hi Stefano,
>
> On 13.02.25 00:11, Stefano Stabellini wrote:
> > On Wed, 12 Feb 2025, Grygorii Strashko wrote:
> > > The Arm Xen allocates memory to place Dom0 following the logic described
> > > in
> > > allocate_memory_11() function which is a bit
On Thu, Feb 13, 2025 at 11:14:43AM -0800, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Marek Marczykowski-Górecki wrote:
> > > > diff --git a/automation/scripts/run-tools-tests
> > > > b/automation/scripts/run-tools-tests
> > > > new file mode 100755
> > > > index ..242a9edad941
>
On Thu, 13 Feb 2025, Andrew Cooper wrote:
> On 13/02/2025 7:26 pm, Stefano Stabellini wrote:
> > On Thu, 13 Feb 2025, Luca Fancellu wrote:
> >>> On 13 Feb 2025, at 15:42, Nicola Vetrini
> >>> wrote:
> >>> On 2025-02-13 16:32, Nicola Vetrini wrote:
> On 2025-02-13 16:01, Jan Beulich wrote:
>
On Thu, 13 Feb 2025, Jan Beulich wrote:
> On 13.02.2025 03:00, Stefano Stabellini wrote:
> > On Wed, 12 Feb 2025, Stefano Stabellini wrote:
> >> On Thu, 13 Feb 2025, Andrew Cooper wrote:
> >>> On 13/02/2025 1:25 am, Stefano Stabellini wrote:
> Hi all,
>
> I am looking through the few
On Thursday, February 13th, 2025 at 1:10 AM, Jan Beulich
wrote:
>
>
> On 13.02.2025 09:28, dm...@proton.me wrote:
>
> > --- a/xen/include/xen/version.h
> > +++ b/xen/include/xen/version.h
> > @@ -29,4 +29,7 @@ int xen_build_id_check(const Elf_Note *n, unsigned int
> > n_sz,
> > static inli
Add Xen version printout to 'h' keyhandler output.
That is useful for debugging systems that have been left intact for a long
time.
Signed-off-by: Denis Mukhin
---
Changes since v2:
- moved new function declarations to xen/lib.h
- dropped xen_ prefix in new functions
---
xen/common/keyhandler.c
Hi Shenghui,
Thank you for your interest in Xen! Let me add Stewart, who can provide
you with an overview of the latest status of PCI Passthrough on ARM.
Among the various items in progress, I would like to highlight this
series from Mykyta, which is currently under review:
https://marc.info/?l
On Thu, 13 Feb 2025, Jan Beulich wrote:
> On 13.02.2025 15:18, GitLab wrote:
> >
> >
> > Pipeline #1669696445 has failed!
> >
> > Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> > Branch: staging (
> > https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
> >
> > Commi
On 2/13/25 7:50 PM, Stewart Hildebrand wrote:
When building with CONFIG_HVM=n and -Og, we encounter:
prelink.o: in function `pit_set_gate':
xen/xen/arch/x86/emul-i8254.c:195: undefined reference to
`destroy_periodic_time'
Add an IS_ENABLED(CONFIG_HVM) check to assist with dead code
eliminatio
On 13/02/2025 7:26 pm, Stefano Stabellini wrote:
> On Thu, 13 Feb 2025, Luca Fancellu wrote:
>>> On 13 Feb 2025, at 15:42, Nicola Vetrini wrote:
>>> On 2025-02-13 16:32, Nicola Vetrini wrote:
On 2025-02-13 16:01, Jan Beulich wrote:
> On 13.02.2025 15:52, Nicola Vetrini wrote:
>> On 20
On Thu, 13 Feb 2025, Jan Beulich wrote:
> On 13.02.2025 01:51, Andrew Cooper wrote:
> > On 12/02/2025 9:52 pm, Stefano Stabellini wrote:
> >> On Wed, 12 Feb 2025, Oleksii Kurochko wrote:
> >>> Hello everyone,
> >>>
> >>> During the installation of Xen on an ARM server machine from the source
> >>>
On Thu, 13 Feb 2025, Luca Fancellu wrote:
> > On 13 Feb 2025, at 15:42, Nicola Vetrini wrote:
> > On 2025-02-13 16:32, Nicola Vetrini wrote:
> >> On 2025-02-13 16:01, Jan Beulich wrote:
> >>> On 13.02.2025 15:52, Nicola Vetrini wrote:
> On 2025-02-13 15:22, Jan Beulich wrote:
> > Any (sig
On Thu, 13 Feb 2025, Marek Marczykowski-Górecki wrote:
> > > diff --git a/automation/scripts/run-tools-tests
> > > b/automation/scripts/run-tools-tests
> > > new file mode 100755
> > > index ..242a9edad941
> > > --- /dev/null
> > > +++ b/automation/scripts/run-tools-tests
> > > @@ -0,0
When building with CONFIG_HVM=n and -Og, we encounter:
prelink.o: in function `pit_set_gate':
xen/xen/arch/x86/emul-i8254.c:195: undefined reference to
`destroy_periodic_time'
Add an IS_ENABLED(CONFIG_HVM) check to assist with dead code
elimination.
Fixes: 14f42af3f52d ("x86/vPIT: account for "
On Thu, 13 Feb 2025, Volodymyr Babchuk wrote:
> ARM Architecture Reference Manual states that IL field of ESR_EL1
> register should be 1 when EC is 0b00 aka HSR_EC_UNKNOWN.
>
> Section D24.2.40, page D24-7337 of ARM DDI 0487L:
>
> IL, bit [25]
> Instruction Length for synchronous exceptio
On 13/02/2025 10:06 am, Jan Beulich wrote:
> On 12.02.2025 18:20, Andrew Cooper wrote:
>> I've noticed the following failure in XenServer's build environment
>>
>>> make[6]: Leaving directory
>>> '/builddir/build/BUILD/xen-4.19.1/tools/tests/x86_emulator'
>>> In file included from /usr/include/feat
On Thu, Feb 13, 2025 at 10:06:26AM +0100, Jan Beulich wrote:
> On 12.02.2025 16:38, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/dom0_build.c
> > +++ b/xen/arch/x86/dom0_build.c
> > @@ -555,10 +555,6 @@ int __init dom0_setup_permissions(struct domain *d)
> > if ( !rangeset_contains_single
On 13.02.2025 17:46, Andrew Cooper wrote:
> When a watchdog fires, the domain is crashed and can't dump any state.
>
> Xen allows a domain to have two separate watchdogs. Therefore, for a
> domain running multiple watchdogs (e.g. one based around network, one
> for disk), it is important for diag
When a watchdog fires, the domain is crashed and can't dump any state.
Xen allows a domain to have two separate watchdogs. Therefore, for a
domain running multiple watchdogs (e.g. one based around network, one
for disk), it is important for diagnostics to know which watchdog
fired.
As the printk
Hi Nicola,
> On 13 Feb 2025, at 15:42, Nicola Vetrini wrote:
>
> On 2025-02-13 16:32, Nicola Vetrini wrote:
>> On 2025-02-13 16:01, Jan Beulich wrote:
>>> On 13.02.2025 15:52, Nicola Vetrini wrote:
On 2025-02-13 15:22, Jan Beulich wrote:
> Any (signed) integer is okay to pass into radix
ARM Architecture Reference Manual states that IL field of ESR_EL1
register should be 1 in some cases, and all these cases are covered by
inject_abt64_exception()
Section D24.2.40, page D24-7337 of ARM DDI 0487L:
IL, bit [25]
Instruction Length for synchronous exceptions. Possible values of th
On 2025-02-13 16:32, Nicola Vetrini wrote:
On 2025-02-13 16:01, Jan Beulich wrote:
On 13.02.2025 15:52, Nicola Vetrini wrote:
On 2025-02-13 15:22, Jan Beulich wrote:
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(),
yet
left shifting negative values is UB. Use an unsigned inte
Internal discussion on "Is ESR=0x0 a valid exception syndrome?" led
to realization that:
1. It is not valid exception syndrome
2. Xen theoretically may inject an exception with ESR=0x0
Further discussion in the ML showed that Xen also may inject
non-standard Data or Instuction Abort exception.
ARM Architecture Reference Manual states that IL field of ESR_EL1
register should be 1 when EC is 0b00 aka HSR_EC_UNKNOWN.
Section D24.2.40, page D24-7337 of ARM DDI 0487L:
IL, bit [25]
Instruction Length for synchronous exceptions. Possible values of this bit
are:
[...]
0b1 - 32-b
On 2025-02-13 16:01, Jan Beulich wrote:
On 13.02.2025 15:52, Nicola Vetrini wrote:
On 2025-02-13 15:22, Jan Beulich wrote:
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(),
yet
left shifting negative values is UB. Use an unsigned intermediate
type,
reducing the impact to impl
On 13.02.2025 15:52, Nicola Vetrini wrote:
> On 2025-02-13 15:22, Jan Beulich wrote:
>> Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
>> left shifting negative values is UB. Use an unsigned intermediate type,
>> reducing the impact to implementation defined behavior (for th
On 13/02/2025 2:30 pm, Jan Beulich wrote:
> On 13.02.2025 15:26, Oleksii Kurochko wrote:
>> On 2/13/25 3:21 PM, Oleksii Kurochko wrote:
>>>
>>> On 2/13/25 3:07 PM, Andrew Cooper wrote:
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
> Hi Andrew,
>
> Andrew Cooper writes:
>
On 13/02/2025 2:52 pm, Nicola Vetrini wrote:
> On 2025-02-13 15:22, Jan Beulich wrote:
>> Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
>> left shifting negative values is UB. Use an unsigned intermediate type,
>> reducing the impact to implementation defined behavior (for
On 13/02/2025 2:22 pm, Jan Beulich wrote:
> Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
> left shifting negative values is UB. Use an unsigned intermediate type,
> reducing the impact to implementation defined behavior (for the
> unsigned->signed conversion).
>
> Also ple
On 2025-02-13 15:22, Jan Beulich wrote:
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
left shifting negative values is UB. Use an unsigned intermediate type,
reducing the impact to implementation defined behavior (for the
unsigned->signed conversion).
Also please Misra C
On Wed, Feb 12, 2025 at 01:35:16PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The Mediatek MT7922 WiFi device advertises FLR support, but it apparently
> does not work, and all subsequent config reads return ~0:
>
> pci :01:00.0: [14c3:0616] type 00 class 0x028000 PCIe Endpoint
On 13/02/2025 14:20, Julien Grall wrote:
Hi,
On 14/01/2025 04:25, Volodymyr Babchuk wrote:
Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. We initialize stack protector very early, in head.S using
boot_stack_chk_guard_setup. This ensures that all C code from the very
On 13/02/2025 2:26 pm, Oleksii Kurochko wrote:
>
>
> On 2/13/25 3:21 PM, Oleksii Kurochko wrote:
>>
>>
>> On 2/13/25 3:07 PM, Andrew Cooper wrote:
>>> On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
> On 14/01/2025 4:25 am, Volodymyr Babchuk
On 13.02.2025 15:26, Oleksii Kurochko wrote:
>
> On 2/13/25 3:21 PM, Oleksii Kurochko wrote:
>>
>>
>> On 2/13/25 3:07 PM, Andrew Cooper wrote:
>>> On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
> On 14/01/2025 4:25 am, Volodymyr Babchuk wro
On 13.02.2025 15:18, GitLab wrote:
>
>
> Pipeline #1669696445 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: b5b2f987 (
> https://gitlab.com/xen-project/hardware/xen
On 2/13/25 3:24 PM, Julien Grall wrote:
Hi,
On 13/02/2025 14:21, Oleksii Kurochko wrote:
On 2/13/25 3:07 PM, Andrew Cooper wrote:
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
Volodymyr Babchuk (4):
co
On 2/13/25 3:21 PM, Oleksii Kurochko wrote:
On 2/13/25 3:07 PM, Andrew Cooper wrote:
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
Volodymyr Babchuk (4):
common: remove -fno-stack-protector from EMBEDDE
Hi,
On 13/02/2025 14:21, Oleksii Kurochko wrote:
On 2/13/25 3:07 PM, Andrew Cooper wrote:
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
Volodymyr Babchuk (4):
common: remove -fno-stack-protector from EMB
Any (signed) integer is okay to pass into radix_tree_int_to_ptr(), yet
left shifting negative values is UB. Use an unsigned intermediate type,
reducing the impact to implementation defined behavior (for the
unsigned->signed conversion).
Also please Misra C:2012 rule 7.3 by dropping the lower case
On 2/13/25 3:07 PM, Andrew Cooper wrote:
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
Hi Andrew,
Andrew Cooper writes:
On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
Volodymyr Babchuk (4):
common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
xen: common: add ability to e
Hi,
On 14/01/2025 04:25, Volodymyr Babchuk wrote:
Enable previously added CONFIG_STACK_PROTECTOR feature for ARM
platform. We initialize stack protector very early, in head.S using
boot_stack_chk_guard_setup. This ensures that all C code from the very
beginning can use stack protector.
Signed-o
On 1/14/25 5:25 AM, Volodymyr Babchuk wrote:
Stack protector is meant to be enabled on all architectures, but
currently it is tested (and enabled) only on ARM, so mention it in ARM
section.
Signed-off-by: Volodymyr Babchuk
Reviewed-By: Oleksii Kurochko
Thanks.
~ Oleksii
---
CHANGELOG.md
Hi Andrew,
Andrew Cooper writes:
> On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
>> Volodymyr Babchuk (4):
>> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
>> xen: common: add ability to enable stack protector
>> xen: arm: enable stack protector feature
>> CHANGELOG.
On 13/02/2025 1:54 pm, Volodymyr Babchuk wrote:
> Hi Andrew,
>
> Andrew Cooper writes:
>
>> On 14/01/2025 4:25 am, Volodymyr Babchuk wrote:
>>> Volodymyr Babchuk (4):
>>> common: remove -fno-stack-protector from EMBEDDED_EXTRA_CFLAGS
>>> xen: common: add ability to enable stack protector
>>>
On 13/02/2025 1:03 pm, Andrii Sultanov wrote:
> diff --git a/tools/ocaml/xenstored/process.ml
> b/tools/ocaml/xenstored/process.ml
> index 432d66321c..cb4efc0fb5 100644
> --- a/tools/ocaml/xenstored/process.ml
> +++ b/tools/ocaml/xenstored/process.ml
> @@ -437,7 +437,7 @@ let input_handle_error ~c
When mcheck_init() doesn't recognize the CPU vendor, it will undo the
all-banks allocation, and it will in particular not install the CPU
notifier. This way APs will pointlessly try to re-establish an
all-banks allocation, while then falling over NULL pointers due to the
notifier hot having run and
Acked-by: Christian Lindig
> On 13 Feb 2025, at 13:03, Andrii Sultanov wrote:
>
> OCaml, in preparation for a renaming of the error string associated with
> conversion failure in 'int_of_string' functions, started to issue this
> warning:
> ```
> File "process.ml", line 440, characters 13-28:
>
Andrii Sultanov (1):
tools/ocaml: Fix oxenstored build warning
tools/ocaml/xenstored/Makefile | 1 +
tools/ocaml/xenstored/perms.ml | 2 +-
tools/ocaml/xenstored/poll.ml | 2 +-
tools/ocaml/xenstored/process.ml | 18 +-
tools/ocaml/xenstored/utils.ml | 10 +
OCaml, in preparation for a renaming of the error string associated with
conversion failure in 'int_of_string' functions, started to issue this
warning:
```
File "process.ml", line 440, characters 13-28:
440 | | (Failure "int_of_string")-> reply_error "EINVAL"
^
The generic entry code expects architecture code to provide
regs_irqs_disabled(regs) function, but arm64 does not have this and
provides inerrupts_enabled(regs), which has the opposite polarity.
In preparation for moving arm64 over to the generic entry code,
relace arm64's interrupts_enabled() wit
The arm64 entry code only preempts a kernel context upon a return from
a regular IRQ exception. The generic entry code may preempt a kernel
context for any exception return where irqentry_exit() is used, and so
may preempt other exceptions such as faults.
In preparation for moving arm64 over to th
The generic entry code has the form:
| raw_irqentry_exit_cond_resched()
| {
| if (!preempt_count()) {
| ...
| if (need_resched())
| preempt_schedule_irq();
| }
| }
In preparation for moving arm64 over to the generic entry code, align
t
ARM64 requires an additional check whether to reschedule on return
from interrupt. So add arch_irqentry_exit_need_resched() as the default
NOP implementation and hook it up into the need_resched() condition in
raw_irqentry_exit_cond_resched(). This allows ARM64 to implement
the architecture specifi
Currently CONFIG_GENERIC_ENTRY enables both the generic exception
entry logic and the generic syscall entry logic, which are otherwise
loosely coupled.
Introduce separate config options for these so that archtiectures can
select the two independently. This will make it easier for
architectures to
Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
to use the generic entry infrastructure from kernel/entry/*.
The generic entry makes maintainers' work easier and codes
more elegant.
Switch arm64 to generic IRQ entry first, which removed duplicate 100+
LOC and make Lazy preemp
The generic entry code uses irqentry_state_t to track lockdep and RCU
state across exception entry and return. For historical reasons, arm64
embeds similar fields within its pt_regs structure.
In preparation for moving arm64 over to the generic entry code, pull
these fields out of arm64's pt_regs,
Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
to use the generic entry infrastructure from kernel/entry/*. The generic
entry makes maintainers' work easier and codes more elegant, which will
make PREEMPT_DYNAMIC and PREEMPT_LAZY available and remove a lot of
duplicate code.
The generic entry code uses preempt_count() and need_resched() helpers to
check if it should do preempt_schedule_irq(). Currently, arm64 use its own
check logic, that is "READ_ONCE(current_thread_info()->preempt_count == 0",
which is equivalent to "preempt_count() == 0 && need_resched()".
In prepa
Hi Stefano,
On 13.02.25 00:11, Stefano Stabellini wrote:
On Wed, 12 Feb 2025, Grygorii Strashko wrote:
The Arm Xen allocates memory to place Dom0 following the logic described in
allocate_memory_11() function which is a bit complicated with major
requirement to place Dom0 within the first 128MB
On 2/13/25 12:10 PM, Jan Beulich wrote:
My adjustments to move from xmalloc() et al to respective xvmalloc()
flavors was flawed - a freeing instance wasn't converted.
Fixes: 23d60dbb0493 ("x86/HVM: allocate emulation cache entries dynamically")
Signed-off-by: Jan Beulich
---
Noticed while backp
Hi everyone,
As we start the New Year, I'd like to ask you to reflect on how the project
went in 2024. This will help us track the health of the community and also
give you a chance to express your ideas and feedback.
The survey can be answered anonymously and should take less than 10 minutes.
*
On 13/02/2025 11:10 am, Jan Beulich wrote:
> My adjustments to move from xmalloc() et al to respective xvmalloc()
> flavors was flawed - a freeing instance wasn't converted.
>
> Fixes: 23d60dbb0493 ("x86/HVM: allocate emulation cache entries dynamically")
> Signed-off-by: Jan Beulich
Acked-by: An
You seem to have accidentally dropped xen-devel. Re-adding.
On 13/02/2025 12:04, Volodymyr Babchuk wrote:
>
>
> Hi Michal,
>
> "Orzel, Michal" writes:
>
>> Hi Volodymyr,
>>
>> NIT: s/EL/IL/ in commit title
>
> Sure, thanks.
>
>> One remark below.
>>
>> On 12/02/2025 23:03, Stefano Stabellin
My adjustments to move from xmalloc() et al to respective xvmalloc()
flavors was flawed - a freeing instance wasn't converted.
Fixes: 23d60dbb0493 ("x86/HVM: allocate emulation cache entries dynamically")
Signed-off-by: Jan Beulich
---
Noticed while backporting, where the conversion needs undoing
1 - 100 of 113 matches
Mail list logo
