These two files contain several deliberate violations of MISRA C rules and
they are not linked in the final Xen binary, therefore they can be exempted
from MISRA compliance.
No functional change.
Signed-off-by: Nicola Vetrini
---
Since the exclude list only contains arm64 and x86 files I reasone
On 08.02.2024 03:25, Jason Andryuk wrote:
> On Wed, Feb 7, 2024 at 7:50 AM Jan Beulich wrote:
>>
>> On 06.02.2024 12:45, Anthony PERARD wrote:
>>> On Thu, Feb 01, 2024 at 01:30:21PM -0500, Jason Andryuk wrote:
same_vm is broken when the two main domains do not have targets. otvm
and tar
On 08.02.2024 05:32, George Dunlap wrote:
> Er, ok, just one more comment: this could allow an altp2m to have more
> permissions than the host; for example, the host p2m entry could be
> p2m_access_r, but if the altp2m's default_access were p2m_access_rw,
> it would override that. Is that the beha
On 14.11.2023 18:50, Krystian Hebel wrote:
> Both fields held the same data.
Supposedly the same data only. They come from different origins, and you're
hiding this quite well by leaving all sites in place where the field is
written. Both items are also used for entirely separate purposes. So you
flight 184623 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184623/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8f316e99ec8de9dea294f6751dd7457f9f1a828c
baseline version:
ovmf 4d1f0babe20cf757897fa
On Thu, Jun 23, 2022 at 7:54 PM Jan Beulich wrote:
> Grant P2M entries, which are covered by p2m_is_any_ram(), wouldn't pass
> the get_page() unless the grant was a local one. These need to take the
> same path as foreign entries. Just the assertion there is not valid for
> local grants, and henc
flight 184620 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184620/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu broken
test-armhf-armhf-xl-multivcpu 5 host-ins
On Thu, Feb 8, 2024 at 9:21 AM Tamas K Lengyel wrote:
>
> On Wed, Feb 7, 2024 at 5:21 PM Andrew Cooper
> wrote:
> >
> > On 07/02/2024 1:18 am, George Dunlap wrote:
> > > On Tue, Feb 6, 2024 at 6:08 PM Petr Beneš wrote:
> > >> From: Petr Beneš
> > >>
> > >> This patch addresses a behavior discr
On Wed, Feb 7, 2024 at 7:50 AM Jan Beulich wrote:
>
> On 06.02.2024 12:45, Anthony PERARD wrote:
> > On Thu, Feb 01, 2024 at 01:30:21PM -0500, Jason Andryuk wrote:
> >> same_vm is broken when the two main domains do not have targets. otvm
> >> and targetvm are both missing, which means they get s
On Mon, Feb 5, 2024 at 5:51 AM Juergen Gross wrote:
>
> Add the read request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jason Andryuk
> Acked-by: Anthony PERARD
> ---
> V2:
> - make error check more readable (Jason Andryuk)
> V4:
> - add directory read support
> ---
>
On Wed, Feb 7, 2024 at 5:21 PM Andrew Cooper wrote:
>
> On 07/02/2024 1:18 am, George Dunlap wrote:
> > On Tue, Feb 6, 2024 at 6:08 PM Petr Beneš wrote:
> >> From: Petr Beneš
> >>
> >> This patch addresses a behavior discrepancy in the handling of altp2m
> >> views,
> >> where upon the creation
flight 184617 xen-unstable real [real]
flight 184621 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184617/
http://logs.test-lab.xenproject.org/osstest/logs/184621/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On Mon, Feb 5, 2024 at 5:57 AM Juergen Gross wrote:
>
> Add the stat request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
On Mon, Feb 5, 2024 at 6:21 AM Juergen Gross wrote:
>
> Add the create request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
On Mon, Feb 5, 2024 at 5:58 AM Juergen Gross wrote:
>
> Add the clunk request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
On 05/02/2024 10:49 am, Juergen Gross wrote:
> Add "xen-9pfsd", a new logging daemon meant to support infrastructure
> domains (e.g. xenstore-stubdom) to access files in dom0.
I was still expecting for "logging" to disappear from this.
In both cases it could just be deleted the sentences still wo
On Mon, Feb 5, 2024 at 6:13 AM Juergen Gross wrote:
>
> Add the open request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
On Mon, Feb 5, 2024 at 5:59 AM Juergen Gross wrote:
>
> Add the walk request of the 9pfs protocol.
>
> Signed-off-by: Juergen Gross
> Acked-by: Anthony PERARD
Reviewed-by: Jason Andryuk
On Mon, Feb 5, 2024 at 5:57 AM Juergen Gross wrote:
>
> Add the attach request of the 9pfs protocol. This introduces the "fid"
> scheme of the 9pfs protocol.
>
> As this will be needed later, use a dedicated memory allocation
> function in alloc_fid() and prepare a fid reference count.
>
> For fil
On Mon, Feb 5, 2024 at 5:50 AM Juergen Gross wrote:
>
> Add support for generation a 9pfs protocol response via a format based
> approach.
>
> Strings are stored in a per device string buffer and they are
> referenced via their offset in this buffer. This allows to avoid
> having to dynamically al
On 07/02/2024 1:18 am, George Dunlap wrote:
> On Tue, Feb 6, 2024 at 6:08 PM Petr Beneš wrote:
>> From: Petr Beneš
>>
>> This patch addresses a behavior discrepancy in the handling of altp2m views,
>> where upon the creation and subsequent EPT violation, the page access
>> permissions were incorr
From: Petr Beneš
Add the missing `vmtrace_buf_kb` field to the OCaml bindings to match the
vm.cfg configuration, correcting an oversight from its initial introduction.
Signed-off-by: Petr Beneš
---
tools/ocaml/libs/xc/xenctrl.ml | 1 +
tools/ocaml/libs/xc/xenctrl.mli | 1 +
tools/oc
flight 184619 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184619/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4d1f0babe20cf757897fa43c399fd79bb6aa8a30
baseline version:
ovmf 1d0b95f6457d225c51083
flight 184614 linux-linus real [real]
flight 184618 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184614/
http://logs.test-lab.xenproject.org/osstest/logs/184618/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
From: Cyril Rébert
Add a command line option to xentop to be able to display dom0 first, on top of
the list.
This is unconditional, so sorting domains with the S option will also ignore
dom0.
Signed-off-by: Cyril Rébert (zithro)
---
Changes in v3:
(none, just reformatting patch correctly ...
The idea is to use xc_cpu_policy_t as a single object containing both the
serialised and deserialised forms of the policy. Note that we need lengths
for the arrays, as the serialised policies may be shorter than the array
capacities.
* Add the serialised lengths to the struct so we can distinguish
In the context of creating a domain, we currently issue a lot of hypercalls
redundantly while populating its CPU policy; likely a side effect of
organic growth more than anything else.
However, the worst part is not the overhead (this is a glacially cold
path), but the insane amounts of boilerplat
Factor out policy getters/setters from both (CPUID and MSR) policy override
functions. Additionally, use host policy rather than featureset when
preparing the cur policy, saving one hypercall and several lines of
boilerplate.
No functional change intended.
Signed-off-by: Alejandro Vallejo
---
t
This enables a set of follow-up simplifications in the toolstack.
No functional change.
Signed-off-by: Alejandro Vallejo
---
tools/include/xenguest.h | 8 +++-
tools/libs/guest/xg_private.h| 10 --
xen/include/xen/lib/x86/cpu-policy.h | 6 --
3 files change
On 14.11.2023 18:50, Krystian Hebel wrote:
> It used to be called from smp_callin(), however BUG_ON() was invoked on
> multiple occasions before that. It may end up calling machine_restart()
> which tries to get APIC ID for CPU running this code. If BSP detected
> that x2APIC is enabled, get_apic_i
flight 184616 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184616/
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 14.11.2023 18:50, Krystian Hebel wrote:
> --- a/xen/arch/x86/boot/x86_64.S
> +++ b/xen/arch/x86/boot/x86_64.S
> @@ -33,9 +33,8 @@ ENTRY(__high_start)
> cmp %esp, CPUINFO_X86_apicid(%rcx)
> jne 1b
>
> -/* %eax is now Xen CPU index. */
> -lea stack_b
On 02.02.2024 19:11, Julien Grall wrote:
> Hi,
>
> On 14/11/2023 17:50, Krystian Hebel wrote:
>> Both fields held the same data.
>>
>> Signed-off-by: Krystian Hebel
>> ---
>> xen/arch/x86/boot/x86_64.S | 8 +---
>> xen/arch/x86/include/asm/asm_defns.h | 2 +-
>> xen/arch/x86/i
On 14.11.2023 18:49, Krystian Hebel wrote:
> --- a/xen/arch/x86/apic.c
> +++ b/xen/arch/x86/apic.c
> @@ -950,7 +950,7 @@ __next:
> */
> if (boot_cpu_physical_apicid == -1U)
> boot_cpu_physical_apicid = get_apic_id();
> -x86_cpu_to_apicid[0] = get_apic_id();
> +cpu_physic
On 07.02.2024 16:58, Federico Serafini wrote:
> On 07/02/24 16:24, Jan Beulich wrote:
>> On 07.02.2024 16:08, Federico Serafini wrote:
>>> On 07/02/24 15:16, Jan Beulich wrote:
On 07.02.2024 14:51, Federico Serafini wrote:
> On 07/02/24 08:38, Jan Beulich wrote:
>> On 07.02.2024 02:08,
On 14.11.2023 18:49, Krystian Hebel wrote:
> --- a/xen/arch/x86/boot/trampoline.S
> +++ b/xen/arch/x86/boot/trampoline.S
> @@ -72,6 +72,26 @@ trampoline_protmode_entry:
> mov $X86_CR4_PAE,%ecx
> mov %ecx,%cr4
>
> +/*
> + * Get APIC ID while we're in non-p
On Tue, Feb 06, 2024 at 04:15:45PM +0100, zithro / Cyril Rébert wrote:
> Add a command line option to xentop to be able to display dom0 first, on top
> of the list.
> This is unconditional, so sorting domains with the S option will also ignore
> dom0.
>
> Signed-off-by: Cyril Rébert (zithro)
>
On 07/02/24 16:24, Jan Beulich wrote:
On 07.02.2024 16:08, Federico Serafini wrote:
On 07/02/24 15:16, Jan Beulich wrote:
On 07.02.2024 14:51, Federico Serafini wrote:
On 07/02/24 08:38, Jan Beulich wrote:
On 07.02.2024 02:08, Stefano Stabellini wrote:
On Tue, 6 Feb 2024, Jan Beulich wrote:
On Tue, Feb 06, 2024 at 03:38:05PM +0100, zithro wrote:
> On 05 Feb 2024 18:27, Anthony PERARD wrote:
> > On Wed, Jan 31, 2024 at 06:51:34PM +0100, Cyril Rébert wrote:
> > > Add a command line option to xentop to be able to display dom0 first, on
> > > top of the list.
> > > This is unconditional,
IVMD and RMRR ranges are functionally equivalent, and as so could use the same
validity checker.
Move the IVMD to x86 common IOMMU code and adjust the function to take a pair
of [start, end] mfn parameters.
So far only the AMD-Vi side is adjusted to use the newly introduced helper, the
VT-d side
Use the newly introduced generic unity map checker.
Also drop the message recommending the usage of iommu_inclusive_mapping: the
ranges would end up being mapped anyway even if some of the checks above
failed, regardless of whether iommu_inclusive_mapping is set. Plus such option
is not supported
Hello,
The following patches unify the check for the RMRR/IVMD ranges in a
common function, using the IVMD as the basis.
Thanks, Roger.
Roger Pau Monne (2):
iommu/x86: introduce a generic IVMD/RMRR range validity helper
iommu/vt-d: switch to common RMRR checker
xen/arch/x86/include/asm/iom
On 07.02.2024 16:08, Federico Serafini wrote:
> On 07/02/24 15:16, Jan Beulich wrote:
>> On 07.02.2024 14:51, Federico Serafini wrote:
>>> On 07/02/24 08:38, Jan Beulich wrote:
On 07.02.2024 02:08, Stefano Stabellini wrote:
> On Tue, 6 Feb 2024, Jan Beulich wrote:
>> On 26.01.2024 11:0
On 07/02/2024 3:10 pm, Anthony PERARD wrote:
> On Wed, Feb 7, 2024 at 2:55 PM Andrew Cooper
> wrote:
>> On 07/02/2024 2:34 pm, Anthony PERARD wrote:
>>> On Wed, Feb 7, 2024 at 2:24 PM Andrew Cooper
>>> wrote:
>> Stage: test
>> Name: qemu-smoke-riscv64-gcc
> I have to admit that I ca
On Wed, Feb 7, 2024 at 2:55 PM Andrew Cooper wrote:
>
> On 07/02/2024 2:34 pm, Anthony PERARD wrote:
> > On Wed, Feb 7, 2024 at 2:24 PM Andrew Cooper
> > wrote:
> Stage: test
> Name: qemu-smoke-riscv64-gcc
> >>> I have to admit that I can't connect what was pushed recently to this job
On 04.01.2024 14:16, Jan Beulich wrote:
> On 22.12.2023 16:49, Neowutran wrote:
>> Full logs without my patch to set allow-memory-relocate
>> (https://github.com/neowutran/qubes-vmm-xen/blob/allowmemoryrelocate/ALLOWMEMORYRELOCATE.patch)
>> https://pastebin.com/g
>> QGg55WZ
>> (GPU passthrough do
On 07/02/24 15:16, Jan Beulich wrote:
On 07.02.2024 14:51, Federico Serafini wrote:
On 07/02/24 08:38, Jan Beulich wrote:
On 07.02.2024 02:08, Stefano Stabellini wrote:
On Tue, 6 Feb 2024, Jan Beulich wrote:
On 26.01.2024 11:05, Federico Serafini wrote:
@@ -208,7 +205,7 @@ do {
Introduce a new Kconfig check for whether the compiler supports
-falign-functions and if supported use it to align functions to the per-arch
selected value, just like it's done for assembly ENTRY() and FUNC() symbols.
Note that it's possible for the compiler to end up using a higher function
align
Hello,
The following series adds an additional Kconfig option for the per-arch
code alignment. Such alignment is to be used in all assembly code
symbols and C functions unless specified otherwise.
Last patch also uses such alignment in order to guarantee enough
distance between function entry po
The minimal function size requirements for an x86 livepatch are either 5 bytes
(for jmp) or 9 bytes (for endbr + jmp), and always 4 bytes on Arm. Ensure that
distance between functions entry points is always at least of the minimal
required size for livepatch instruction replacement to be successf
And use it to replace CODE_ALIGN in assembly. This allows to generalize the
way the code alignment gets set across all architectures.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v5:
- New in this version.
---
xen/Kconfig | 17 +++
On 07/02/2024 2:34 pm, Anthony PERARD wrote:
> On Wed, Feb 7, 2024 at 2:24 PM Andrew Cooper
> wrote:
Stage: test
Name: qemu-smoke-riscv64-gcc
>>> I have to admit that I can't connect what was pushed recently to this job
>>> failing.
>> The qemu smoke tests for riscv and ppc intermittent
On 07.02.2024 15:31, Andrew Cooper wrote:
> On 07/02/2024 2:03 pm, Jan Beulich wrote:
>> This aspect is simply meaningless for this component.
>>
>> Signed-off-by: Jan Beulich
>
> In principle Acked-by: Andrew Cooper , but
>
>>
>> --- a/tools/firmware/hvmloader/Makefile
>> +++ b/tools/firmware/h
On Wed, Feb 7, 2024 at 2:24 PM Andrew Cooper wrote:
> >> Stage: test
> >> Name: qemu-smoke-riscv64-gcc
> > I have to admit that I can't connect what was pushed recently to this job
> > failing.
>
> The qemu smoke tests for riscv and ppc intermittently fail on the
> OSSTest-lab infrastructure in Gi
On 07/02/2024 2:03 pm, Jan Beulich wrote:
> This aspect is simply meaningless for this component.
>
> Signed-off-by: Jan Beulich
In principle Acked-by: Andrew Cooper , but
>
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -20,6 +20,8 @@
> XEN_ROOT = $(CU
On 07/02/2024 1:39 pm, Jan Beulich wrote:
> ... to boot code, limiting their scope and thus allowing to drop
> respective #undef-s from the linker script.
>
> Signed-off-by: Jan Beulich
> ---
> An obvious alternative would be to convert boot code right away too, but
> I think this has lower priori
On 07.02.2024 14:55, Andrew Cooper wrote:
> On 07/02/2024 1:37 pm, Jan Beulich wrote:
>> Use the generic framework from xen/linkage.h.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> v6: New.
>>
>> --- a/xen/arch/x86/hvm/vmx/entry.S
>> +++ b/xen/arch/x86/hvm/vmx/entry.S
>> @@ -24,7 +24,7 @@
>> #define
On 07/02/2024 2:20 pm, Jan Beulich wrote:
> On 07.02.2024 15:02, GitLab wrote:
>>
>> Pipeline #1167820960 has failed!
>>
>> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
>> Branch: staging (
>> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>>
>> Commit: f4519ee8 (
On 07.02.2024 15:02, GitLab wrote:
>
>
> Pipeline #1167820960 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/hardware/xen )
> Branch: staging (
> https://gitlab.com/xen-project/hardware/xen/-/commits/staging )
>
> Commit: f4519ee8 (
> https://gitlab.com/xen-project/hardware/xen
On 07.02.2024 14:51, Federico Serafini wrote:
> On 07/02/24 08:38, Jan Beulich wrote:
>> On 07.02.2024 02:08, Stefano Stabellini wrote:
>>> On Tue, 6 Feb 2024, Jan Beulich wrote:
On 26.01.2024 11:05, Federico Serafini wrote:
> @@ -208,7 +205,7 @@ do {
On 07/02/2024 1:38 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/x86_64/entry.S
> +++ b/xen/arch/x86/x86_64/entry.S
> @@ -599,7 +599,7 @@ domain_crash_page_fault_0x8:
> ALTERNATIVE "", clac, X86_FEATURE_XEN_SMAP
> movq %rsi,%rdi
> call show_page_walk
> -ENTRY(dom_crash_s
On 07/02/2024 1:38 pm, Jan Beulich wrote:
> Use the generic framework from xen/linkage.h.
>
> Signed-off-by: Jan Beulich
> ---
> Using the linker script like this feels fragile. Maybe it's better to
> suppress (#undef) CONFIG_CC_SPLIT_SECTIONS for this one file?
This is specific glue code, needin
This aspect is simply meaningless for this component.
Signed-off-by: Jan Beulich
--- a/tools/firmware/hvmloader/Makefile
+++ b/tools/firmware/hvmloader/Makefile
@@ -20,6 +20,8 @@
XEN_ROOT = $(CURDIR)/../../..
include $(XEN_ROOT)/tools/firmware/Rules.mk
+ld-option = $(shell if $(LD) -v $(1) >
On 07/02/2024 1:37 pm, Jan Beulich wrote:
> Use the generic framework from xen/linkage.h.
>
> Signed-off-by: Jan Beulich
> ---
> The .Lsuspend_err label is used in a cross-function manner here, but
> it's not clear to me what - if anything - to do about this.
Well - again like VMX, this is specia
On 07/02/2024 1:37 pm, Jan Beulich wrote:
> Use the generic framework from xen/linkage.h.
>
> Signed-off-by: Jan Beulich
> ---
> v6: New.
>
> --- a/xen/arch/x86/hvm/vmx/entry.S
> +++ b/xen/arch/x86/hvm/vmx/entry.S
> @@ -24,7 +24,7 @@
> #define VMRESUME .byte 0x0f,0x01,0xc3
> #define VMLAUNCH
Juergen Gross, le mer. 07 févr. 2024 14:49:20 +0100, a ecrit:
> There was a typo in the recent 9pfront fix.
>
> Fixes: b119f0178fd8 ("Mini-OS: fix 9pfs frontend error path")
> Reported-by: Julien Grall
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
> ---
> 9pfront.c | 2 +-
> 1
On 07/02/24 08:38, Jan Beulich wrote:
On 07.02.2024 02:08, Stefano Stabellini wrote:
On Tue, 6 Feb 2024, Jan Beulich wrote:
On 26.01.2024 11:05, Federico Serafini wrote:
@@ -208,7 +205,7 @@ do {
\
case 8:
There was a typo in the recent 9pfront fix.
Fixes: b119f0178fd8 ("Mini-OS: fix 9pfs frontend error path")
Reported-by: Julien Grall
Signed-off-by: Juergen Gross
---
9pfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/9pfront.c b/9pfront.c
index 042879a7..1741d600 10064
On 07/02/2024 1:37 pm, Jan Beulich wrote:
> Use the generic framework from xen/linkage.h.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 07.02.24 14:41, Julien Grall wrote:
Hi Juergen,
On 07/02/2024 13:31, Juergen Gross wrote:
Update the Mini-OS upstream revision.
Signed-off-by: Juergen Gross
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index f7d6d84847..077d841b
On 07.02.2024 14:31, Juergen Gross wrote:
> Update the Mini-OS upstream revision.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Hi Juergen,
On 07/02/2024 13:31, Juergen Gross wrote:
Update the Mini-OS upstream revision.
Signed-off-by: Juergen Gross
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index f7d6d84847..077d841bb7 100644
--- a/Config.mk
+++ b/Config.m
... to boot code, limiting their scope and thus allowing to drop
respective #undef-s from the linker script.
Signed-off-by: Jan Beulich
---
An obvious alternative would be to convert boot code right away too, but
I think this has lower priority for now.
---
v6: New.
--- a/xen/arch/x86/boot/head.
Use the generic framework from xen/linkage.h.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/xen/arch/x86/clear_page.S
+++ b/xen/arch/x86/clear_page.S
@@ -1,8 +1,9 @@
.file __FILE__
+#include
#include
-ENTRY(clear_page_sse2)
+FUNC(clear_page_sse2)
mov $PAGE_SIZE/32, %
Use the generic framework from xen/linkage.h.
Signed-off-by: Jan Beulich
---
Using the linker script like this feels fragile. Maybe it's better to
suppress (#undef) CONFIG_CC_SPLIT_SECTIONS for this one file?
---
v6: New.
--- a/xen/arch/x86/x86_64/kexec_reloc.S
+++ b/xen/arch/x86/x86_64/kexec_re
Use the generic framework from xen/linkage.h.
Signed-off-by: Jan Beulich
---
The .Lsuspend_err label is used in a cross-function manner here, but
it's not clear to me what - if anything - to do about this.
---
v6: New.
--- a/xen/arch/x86/acpi/wakeup_prot.S
+++ b/xen/arch/x86/acpi/wakeup_prot.S
@
Use the generic framework from xen/linkage.h.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -24,7 +24,7 @@
#define VMRESUME .byte 0x0f,0x01,0xc3
#define VMLAUNCH .byte 0x0f,0x01,0xc2
-ENTRY(vmx_asm_vmexit_handler)
+FU
Use the generic framework from xen/linkage.h.
Signed-off-by: Jan Beulich
---
v6: New.
--- a/xen/arch/x86/hvm/svm/entry.S
+++ b/xen/arch/x86/hvm/svm/entry.S
@@ -24,7 +24,7 @@
#include
#include
-ENTRY(svm_asm_do_resume)
+FUNC(svm_asm_do_resume)
GET_CURRENT(bx)
.Lsvm_do_resume:
Leverage the new infrastructure in xen/linkage.h to also switch to per-
function sections (when configured), deriving the specific name from the
"base" section in use at the time FUNC() is invoked.
Signed-off-by: Jan Beulich
---
TBD: Since we use .subsection in UNLIKELY_START(), a perhaps not rea
On 07.02.2024 14:34, Jan Beulich wrote:
> 1: common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions
> 2: SVM: convert entry point annotations
> 3: VMX: convert entry point annotations
> 4: x86/ACPI: annotate assembly functions with type and size
> 5: x86/kexec: convert entry point annot
1: common: honor CONFIG_CC_SPLIT_SECTIONS also for assembly functions
2: SVM: convert entry point annotations
3: VMX: convert entry point annotations
4: x86/ACPI: annotate assembly functions with type and size
5: x86/kexec: convert entry point annotations
6: x86: convert misc assembly function anno
Update the Mini-OS upstream revision.
Signed-off-by: Juergen Gross
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index f7d6d84847..077d841bb7 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,7 +224,7 @@ QEMU_UPSTREAM_URL ?=
https://xenbits
flight 184612 xen-unstable real [real]
flight 184615 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184612/
http://logs.test-lab.xenproject.org/osstest/logs/184615/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 06.02.2024 12:45, Anthony PERARD wrote:
> On Thu, Feb 01, 2024 at 01:30:21PM -0500, Jason Andryuk wrote:
>> same_vm is broken when the two main domains do not have targets. otvm
>> and targetvm are both missing, which means they get set to -1 and then
>> converted to empty strings:
>>
>> ++1069
On 07.02.2024 13:21, Simone Ballarin wrote:
> On 07/02/24 11:24, Jan Beulich wrote:
>> On 07.02.2024 11:03, Simone Ballarin wrote:
>>> On 06/02/24 13:04, Jan Beulich wrote:
On 02.02.2024 16:16, Simone Ballarin wrote:
> Rule 13.1: Initializer lists shall not contain persistent side effects
On 06/02/24 14:13, Jan Beulich wrote:
On 02.02.2024 16:16, Simone Ballarin wrote:
Rule 13.1: Initializer lists shall not contain persistent side effects
This patch moves expressions with side-effects into new variables before
the initializer lists.
No functional changes.
Signed-off-by: Simone
On 07/02/24 11:24, Jan Beulich wrote:
On 07.02.2024 11:03, Simone Ballarin wrote:
On 06/02/24 13:04, Jan Beulich wrote:
On 02.02.2024 16:16, Simone Ballarin wrote:
Rule 13.1: Initializer lists shall not contain persistent side effects
Effects caused by debug/logging macros and functions (like
On 07.02.24 13:02, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 12:43:03 +0100, a ecrit:
On 07.02.24 12:34, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 12:16:44 +0100, a ecrit:
On 07.02.24 12:00, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +01
Hi Michal,
On 07/02/2024 11:52, Michal Orzel wrote:
On 07/02/2024 11:06, Julien Grall wrote:
Hi Michal,
On 07/02/2024 07:45, Michal Orzel wrote:
On 06/02/2024 19:49, Julien Grall wrote:
On 31/01/2024 12:10, Ayan Kumar Halder wrote:
There can be situations when the registers cannot be em
Jürgen Groß, le mer. 07 févr. 2024 12:43:03 +0100, a ecrit:
> On 07.02.24 12:34, Samuel Thibault wrote:
> > Jürgen Groß, le mer. 07 févr. 2024 12:16:44 +0100, a ecrit:
> > > On 07.02.24 12:00, Samuel Thibault wrote:
> > > > Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +0100, a ecrit:
> > > > > while
On 07/02/2024 11:06, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 07/02/2024 07:45, Michal Orzel wrote:
>> On 06/02/2024 19:49, Julien Grall wrote:
>>> On 31/01/2024 12:10, Ayan Kumar Halder wrote:
There can be situations when the registers cannot be emulated to their full
functional
On 07.02.24 12:34, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 12:16:44 +0100, a ecrit:
On 07.02.24 12:00, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +0100, a ecrit:
while implementing kexec in Mini-OS.
Oh, nice :D
For that I need it for sure.
It nee
Jürgen Groß, le mer. 07 févr. 2024 12:16:44 +0100, a ecrit:
> On 07.02.24 12:00, Samuel Thibault wrote:
> > Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +0100, a ecrit:
> > > while implementing kexec in Mini-OS.
> >
> > Oh, nice :D
> >
> > > For that I need it for sure.
> >
> > It needs to be don
On 07.02.24 12:00, Samuel Thibault wrote:
Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +0100, a ecrit:
while implementing kexec in Mini-OS.
Oh, nice :D
For that I need it for sure.
It needs to be done by kexec itself then.
That's another option, yes.
The question is whether we want to su
Jürgen Groß, le mer. 07 févr. 2024 11:42:20 +0100, a ecrit:
> while implementing kexec in Mini-OS.
Oh, nice :D
> For that I need it for sure.
It needs to be done by kexec itself then.
Samuel
On 07.02.2024 11:46, Juergen Gross wrote:
> On 07.02.24 11:39, Jan Beulich wrote:
>> On 07.02.2024 11:31, Juergen Gross wrote:
>>> --- a/arch/x86/setup.c
>>> +++ b/arch/x86/setup.c
>>> @@ -184,6 +184,8 @@ arch_init(void *par)
>>> {
>>> static char hello[] = "Bootstrapping...\n";
>>>
>>> +
On 07/02/2024 10:42 am, Jürgen Groß wrote:
> On 07.02.24 11:38, Samuel Thibault wrote:
>> Juergen Gross, le mer. 07 févr. 2024 11:31:38 +0100, a ecrit:
>>> The .bss segment should be zeroed at very early boot.
>>
>> Is that not done by the elf loader of Xen?
>
> It might be done by Xen tools today,
On 07.02.2024 11:42, Jürgen Groß wrote:
> On 07.02.24 11:38, Samuel Thibault wrote:
>> Juergen Gross, le mer. 07 févr. 2024 11:31:38 +0100, a ecrit:
>>> The .bss segment should be zeroed at very early boot.
>>
>> Is that not done by the elf loader of Xen?
>
> It might be done by Xen tools today, b
On 07.02.24 11:39, Jan Beulich wrote:
On 07.02.2024 11:31, Juergen Gross wrote:
--- a/arch/x86/setup.c
+++ b/arch/x86/setup.c
@@ -184,6 +184,8 @@ arch_init(void *par)
{
static char hello[] = "Bootstrapping...\n";
+ memset(&__bss_start, 0, &_end - &__bss_start);
Doesn't / shouldn't
On 07.02.2024 10:14, Roger Pau Monné wrote:
> On Tue, Feb 06, 2024 at 12:49:08PM +0100, Jan Beulich wrote:
>> On 01.02.2024 18:01, Roger Pau Monne wrote:
>>> Currently when a unity range overlaps with memory being used as RAM by the
>>> hypervisor the result would be that the IOMMU gets disabled.
1 - 100 of 113 matches
Mail list logo
