The data are properly aligned in trampoline.S.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/cmdline.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/boot/cmdline.c b/xen/arch/x86/boot/cmdline.c
index fc9241ede9..aae5a1f04f 100644
--- a/xen/arch/x86/boot/
On Mon, Sep 09, 2024 at 10:09:16PM -0400, Jason Andryuk wrote:
> From: Jason Andryuk
>
> Probing xen-fbfront faults in video_is_primary_device(). The passed-in
> struct device is NULL since xen-fbfront doesn't assign it and the
> memory is kzalloc()-ed. Assign fb_info->device to avoid this.
>
Am 10.09.24 um 04:09 schrieb Jason Andryuk:
From: Jason Andryuk
Probing xen-fbfront faults in video_is_primary_device(). The passed-in
struct device is NULL since xen-fbfront doesn't assign it and the
memory is kzalloc()-ed. Assign fb_info->device to avoid this.
This was exposed by the co
Hi
Am 10.09.24 um 09:22 schrieb Roger Pau Monné:
On Mon, Sep 09, 2024 at 10:09:16PM -0400, Jason Andryuk wrote:
From: Jason Andryuk
Probing xen-fbfront faults in video_is_primary_device(). The passed-in
struct device is NULL since xen-fbfront doesn't assign it and the
memory is kzalloc()-ed.
flight 187634 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187634/
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 20.08.24 11:38, Jan Beulich wrote:
On 20.08.2024 10:20, Juergen Gross wrote:
When running as a Xen PV dom0 it can happen that the kernel is being
loaded to a guest physical address conflicting with the host memory
map.
In order to be able to resolve this conflict, add the capability to
remap
On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 10.09.24 um 09:22 schrieb Roger Pau Monné:
> > On Mon, Sep 09, 2024 at 10:09:16PM -0400, Jason Andryuk wrote:
> > > From: Jason Andryuk
> > >
> > > Probing xen-fbfront faults in video_is_primary_device(). The passed-
On 20.08.24 11:56, Jan Beulich wrote:
On 20.08.2024 10:20, Juergen Gross wrote:
@@ -838,6 +839,31 @@ void __init xen_do_remap_nonram(void)
pr_info("Remapped %u non-RAM page(s)\n", remapped);
}
+/*
+ * Xen variant of acpi_os_ioremap() taking potentially remapped non-RAM
+ * regions
On 20.08.24 12:23, Jan Beulich wrote:
On 20.08.2024 10:20, Juergen Gross wrote:
In order to minimize required special handling for running as Xen PV
dom0, the memory layout is modified to match that of the host. This
requires to have only RAM at the locations where Xen allocated memory
is living
On 2024-09-10 08:26, Jan Beulich wrote:
On 10.09.2024 06:46, Stefano Stabellini wrote:
On Mon, 9 Sep 2024, Jan Beulich wrote:
On 07.09.2024 15:03, Nicola Vetrini wrote:
+ * - R18.2
+ - Subtraction between pointers encapsulated by macro
page_to_mfn
+ are safe.
+ - Tagged as `s
On 2024-09-10 06:39, Stefano Stabellini wrote:
Acked-by: Stefano Stabellini
On Mon, 9 Sep 2024, Jan Beulich wrote:
On 08.09.2024 15:27, Nicola Vetrini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -533,6 +533,14 @@ Deviations related to MISRA C:2012 Rules:
>
On 10.09.2024 10:18, Nicola Vetrini wrote:
> On 2024-09-10 08:26, Jan Beulich wrote:
>> On 10.09.2024 06:46, Stefano Stabellini wrote:
>>> On Mon, 9 Sep 2024, Jan Beulich wrote:
On 07.09.2024 15:03, Nicola Vetrini wrote:
> + * - R18.2
> + - Subtraction between pointers encapsulat
On Tue, Sep 10, 2024 at 10:13:01AM +0200, Roger Pau Monné wrote:
> On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 10.09.24 um 09:22 schrieb Roger Pau Monné:
> > > On Mon, Sep 09, 2024 at 10:09:16PM -0400, Jason Andryuk wrote:
> > > > From: Jason Andryuk
> > >
On 10.09.2024 09:18, Frediano Ziglio wrote:
> The data are properly aligned in trampoline.S.
I think the attribute was added as a precautionary measure. I don't
really mind seeing it dropped, but I wonder if it's getting in the
way somewhere, or whether this is solely tidying along the lines of
pe
Rule 7.3 states:
"The lowercase character l shall not be used in a literal suffix",
but the INTEL_MSR_RANGE macro uses the "ull" suffix.
The "u" is transformed in uppercase for consistency.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/acpi/cpufreq/acpi.c | 2 +-
1 file c
Hi Michal,
> On 3 Sep 2024, at 14:21, Michal Orzel wrote:
>
> According to GIC spec IHI 0069H.b (12.4.9), the ListRegs field of
> ICH_VTR_EL2 can have value between 0b0..0b0, as there can
> be maximum 16 LRs (field value + 1). Fix the mask used to extract this
> value which wrongly assum
On Tue, Aug 13, 2024 at 05:54:54PM +0200, Jan Beulich wrote:
> On 26.07.2024 17:21, Roger Pau Monne wrote:
> > The idle_pg_table L4 is cloned to create all the other L4 Xen uses, and
> > hence
> > it shouldn't be modified once further L4 are created.
>
> Yes, but the window between moving into SY
On 10.09.2024 10:15, Juergen Gross wrote:
> On 20.08.24 11:56, Jan Beulich wrote:
>> On 20.08.2024 10:20, Juergen Gross wrote:
>>> @@ -838,6 +839,31 @@ void __init xen_do_remap_nonram(void)
>>> pr_info("Remapped %u non-RAM page(s)\n", remapped);
>>> }
>>>
>>> +/*
>>> + * Xen variant of acp
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in the
for loop after 'out
On 10.09.2024 10:54, Roger Pau Monné wrote:
> On Tue, Aug 13, 2024 at 05:54:54PM +0200, Jan Beulich wrote:
>> On 26.07.2024 17:21, Roger Pau Monne wrote:
>>> The idle_pg_table L4 is cloned to create all the other L4 Xen uses, and
>>> hence
>>> it shouldn't be modified once further L4 are created.
On 10.09.2024 10:56, Nicola Vetrini wrote:
> On 2024-07-01 10:36, Jan Beulich wrote:
>> On 28.06.2024 08:30, Nicola Vetrini wrote:
>> This being about unreachable code, why are the domain_crash() not the
>> crucial points of "unreachability"? And even if they weren't there, why
>> wouldn't it be th
On Wed, Sep 04, 2024 at 01:25:46PM +, Anthony PERARD wrote:
> On Tue, Sep 03, 2024 at 04:19:23PM +0200, Roger Pau Monne wrote:
> > Current blkif implementations (both backends and frontends) have all slight
> > differences about how they handle the 'sector-size' xenstore node, and how
> > other
On 10.09.2024 10:48, Nicola Vetrini wrote:
> Rule 7.3 states:
> "The lowercase character l shall not be used in a literal suffix",
> but the INTEL_MSR_RANGE macro uses the "ull" suffix.
> The "u" is transformed in uppercase for consistency.
>
> No functional change.
>
> Signed-off-by: Nicola Vetr
From: Nicola Vetrini
The rule disallows the usage of an identifier reserved by the C standard.
All identfiers starting with '__' are reserved for any use, so the label
can be renamed in order to avoid the violation.
No functional change.
Signed-off-by: Nicola Vetrini
Signed-off-by: Alessandro
On 09.09.2024 16:54, Roger Pau Monne wrote:
> Adding such probing allows to clearly separate init vs runtime code, and to
> place the probing logic into the init section for the CMOS case. Note both
> the Xen shared_info page wallclock, and the EFI wallclock don't really have
> any
> probing-spec
On 09.09.2024 16:54, Roger Pau Monne wrote:
> Allow setting the used wallclock from the command line. When the option is
> set
> to a value different than `auto` the probing is bypassed and the selected
> implementation is used (as long as it's available).
>
> The `xen` and `efi` options require
On Tue, Sep 10, 2024 at 11:00:27AM +0200, Jan Beulich wrote:
> On 10.09.2024 10:54, Roger Pau Monné wrote:
> > On Tue, Aug 13, 2024 at 05:54:54PM +0200, Jan Beulich wrote:
> >> On 26.07.2024 17:21, Roger Pau Monne wrote:
> >>> The idle_pg_table L4 is cloned to create all the other L4 Xen uses, and
On 10.09.2024 11:13, Alessandro Zucchelli wrote:
> From: Nicola Vetrini
>
> The rule disallows the usage of an identifier reserved by the C standard.
> All identfiers starting with '__' are reserved for any use, so the label
> can be renamed in order to avoid the violation.
>
> No functional cha
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> Implement machine_restart() using printk() to prevent recursion that
> occurs when ASSERT(), BUG*(), or panic() are invoked.
> All these macros (except panic() which could be called directly)
> eventually call panic(), which then calls machine_restart(
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/atomic.h
> +++ b/xen/arch/riscv/include/asm/atomic.h
> @@ -54,16 +54,16 @@ static always_inline void read_atomic_size(const volatile
> void *p,
> })
>
> static always_inline void _write_atomic(volatile void *p,
> -
On 2024-09-10 11:08, Jan Beulich wrote:
On 10.09.2024 10:56, Nicola Vetrini wrote:
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
This being about unreachable code, why are the domain_crash() not the
crucial points of "unreachability"? And even if they weren'
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> Set up fixmap mappings and the L0 page table for fixmap support.
>
> Modify the Page Table Entries (PTEs) directly in arch_pmap_map()
> instead of using set_fixmap() ( which relies on map_pages_to_xen() ).
What do you derive this from? There's no set
On 10.09.2024 11:53, Nicola Vetrini wrote:
> On 2024-09-10 11:08, Jan Beulich wrote:
>> On 10.09.2024 10:56, Nicola Vetrini wrote:
>>> On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
This being about unreachable code, why are the domain_crash() not the
>
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/hypercall.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arc
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/mm/guest_walk.c | 1 +
xen/arch/x86/mm/hap/hap.c| 2 +-
xen/arch/x86/mm/hap/nested_hap.c |
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/x86_emulate/fpu.c | 4
xen/arch/x86/x86_emulate/x86_emulate.c | 1 +
2 files changed, 5 in
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/time.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
Add defensive code in unreachable program points.
This also meets the requirements to deviate a violation of MISRA C:2012
Rule 16.3: "An unconditional `break' statement shall terminate every
switch-clause".
Signed-off-by: Federico Serafini
---
xen/drivers/vpci/msix.c | 4
1 file changed, 4
Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/vm_event.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/vm_event.c b/xen/arch/x86/
This patch series addresses violations of Rule 16.3 on the x86 code.
If all the 12 patches will be committed, only 4 violations will be left:
these are under x86_emulate and involve some fallthrough cases.
I'll wait for instructions from x86 maintainers about the right "format" to make
the fallthr
Add defensive code after unreachable program points.
This also meets the requirements to deviate a violation of MISRA C:2012
Rule 16.3: "An unconditional `break' statement shall terminate every
switch-clause".
Signed-off-by: Federico Serafini
---
xen/arch/x86/x86_emulate/x86_emulate.c | 4
Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/x86_64/mmconfig-shared.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/x86_64/mmcon
Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/include/asm/monitor.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/include/asm/mon
Address a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/arch/x86/psr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/psr.c b/xen/arch/x86/psr.c
inde
Use agreed syntax for pseudo-keyword fallthrough to meet the
requirements to deviate a violation of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/common/efi/runtime.c | 2 +-
1 fil
Address violations of MISRA C:2012 Rule 16.3:
"An unconditional `break' statement shall terminate every
switch-clause".
No functional change.
Signed-off-by: Federico Serafini
---
xen/drivers/passthrough/pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/drivers/pas
On 2024-09-10 12:03, Jan Beulich wrote:
On 10.09.2024 11:53, Nicola Vetrini wrote:
On 2024-09-10 11:08, Jan Beulich wrote:
On 10.09.2024 10:56, Nicola Vetrini wrote:
On 2024-07-01 10:36, Jan Beulich wrote:
On 28.06.2024 08:30, Nicola Vetrini wrote:
This being about unreachable code, why are t
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/processor.h
> +++ b/xen/arch/riscv/include/asm/processor.h
> @@ -12,8 +12,31 @@
>
> #ifndef __ASSEMBLY__
>
> -/* TODO: need to be implemeted */
> -#define smp_processor_id() 0
> +#include
> +
> +register struct pc
On 10.09.2024 12:17, Nicola Vetrini wrote:
> On 2024-09-10 12:03, Jan Beulich wrote:
>> On 10.09.2024 11:53, Nicola Vetrini wrote:
>>> On 2024-09-10 11:08, Jan Beulich wrote:
On 10.09.2024 10:56, Nicola Vetrini wrote:
> On 2024-07-01 10:36, Jan Beulich wrote:
>> On 28.06.2024 08:30, Ni
There have been reports of failed boots with Xen due to an overlap of
the kernel's memory with ACPI NVS reported in the E820 map of the host.
This series fixes this issue by moving the NVS area in dom0 to some
higher address.
Changes in V2:
- split of v1 patch 5
- new patch 6
Changes in V3:
- ad
When booting as a Xen PV dom0 the memory layout of the dom0 is
modified to match that of the host, as this requires less changes in
the kernel for supporting Xen.
There are some cases, though, which are problematic, as it is the Xen
hypervisor selecting the kernel's load address plus some other da
Move the checks for e820 memory map conflicts using the
xen_chk_is_e820_usable() helper further up in order to prepare
resolving some of the possible conflicts by doing some e820 map
modifications, which must happen before evaluating the RAM layout.
Signed-off-by: Juergen Gross
Tested-by: Marek M
When running as a Xen PV dom0 it can happen that the kernel is being
loaded to a guest physical address conflicting with the host memory
map.
In order to be able to resolve this conflict, add the capability to
remap non-RAM areas to different guest PFNs. A function to use this
remapping informatio
In order to minimize required special handling for running as Xen PV
dom0, the memory layout is modified to match that of the host. This
requires to have only RAM at the locations where Xen allocated memory
is living. Unfortunately there seem to be some machines, where ACPI
NVS is located at 64 MB,
When running as a Xen PV dom0 the kernel is loaded by the hypervisor
using a different memory map than that of the host. In order to
minimize the required changes in the kernel, the kernel adapts its
memory map to that of the host. In order to do that it is checking
for conflicts of its load addres
Instead of having max_pfn as a local variable of xen_memory_setup(),
make it a static variable in setup.c instead. This avoids having to
pass it to subfunctions, which will be needed in more cases in future.
Rename it to ini_nr_pages, as the value denotes the currently usable
number of memory page
flight 187614 xen-unstable real [real]
flight 187639 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187614/
http://logs.test-lab.xenproject.org/osstest/logs/187639/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
When running as a Xen PV dom0 the system needs to map ACPI data of the
host using host physical addresses, while those addresses can conflict
with the guest physical addresses of the loaded linux kernel. The same
problem might apply in case a PV guest is configured to use the host
memory map.
This
Remove comment-based deviations since a project wide deviation that
cover such cases is present.
Signed-off-by: Federico Serafini
---
Changes from v1:
- split modifications in two patches.
---
xen/include/xen/bitmap.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/xen/include/xen/bitmap.h
Update ECLAIR configuration to deviate some safe violations of Rule 20.7.
Remove redundant comment-based deviations.
Federico Serafini (2):
automation/eclair: update configuration of Rule 20.7
xen/bitmap: remove redundant deviations
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
MISRA C:2012 Rule 20.7 states that "Expressions resulting from the
expansion of macro parameters shall be enclosed in parentheses".
The rational of the rule is that if a macro argument expands to an
expression, there may be problems related to operator precedence, e.g.,
define M(A, B) A * B
M(1+1
flight 187638 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187638/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b1ce2e1b67ff3b2478739976e952ac719010f019
baseline version:
ovmf 61f9695f20a575085d057
On 10/09/2024 10:12 am, Jan Beulich wrote:
> On 10.09.2024 10:48, Nicola Vetrini wrote:
>> Rule 7.3 states:
>> "The lowercase character l shall not be used in a literal suffix",
>> but the INTEL_MSR_RANGE macro uses the "ull" suffix.
>> The "u" is transformed in uppercase for consistency.
>>
>> No
On Mon, 09 Sep 2024 22:02:08 +0200,
Elliott Mitchell wrote:
>
> On Sat, Sep 07, 2024 at 11:38:50AM +0100, Andrew Cooper wrote:
> > On 07/09/2024 8:46 am, Takashi Iwai wrote:
> > > On Fri, 06 Sep 2024 20:42:09 +0200,
> > > Ariadne Conill wrote:
> > >> This patch attempted to work around a DMA issue
Since recently in the commit e469e2045f1b ("ALSA: memalloc: Let IOMMU
handle S/G primarily"), the SG buffer allocation code was modified to
use the standard DMA code primarily and the fallback is applied only
limitedly. This made the Xen PV specific workarounds we took in the
commit 53466ebdec61 (
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> 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 availabi
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.
To give some context, this is an excerpt of how differ
Hi Julien,
On 09/09/2024 21:59, Julien Grall wrote:
Hi Stefano,
On 09/09/2024 20:53, Stefano Stabellini wrote:
On Mon, 9 Sep 2024, Julien Grall wrote:
On 09/09/2024 10:50, Ayan Kumar Halder wrote:
On 09/09/2024 10:11, Julien Grall wrote:
On 09/09/2024 09:56, Michal Orzel wrote:
Hi Julien
On 02.09.2024 19:01, Oleksii Kurochko wrote:
> 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
On Tue, 10 Sept 2024 at 10:33, Greg KH wrote:
>
> On Tue, Sep 10, 2024 at 10:13:01AM +0200, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 10.09.24 um 09:22 schrieb Roger Pau Monné:
> > > > On Mon, Sep 09, 2024 at 10:09:16PM -0
On Tue, Sep 10, 2024 at 02:18:35PM +0200, Arthur Borsboom wrote:
> On Tue, 10 Sept 2024 at 10:33, Greg KH wrote:
> >
> > On Tue, Sep 10, 2024 at 10:13:01AM +0200, Roger Pau Monné wrote:
> > > On Tue, Sep 10, 2024 at 09:29:30AM +0200, Thomas Zimmermann wrote:
> > > > Hi
> > > >
> > > > Am 10.09.24
On 10.09.2024 12:39, Juergen Gross wrote:
> When running as a Xen PV dom0 it can happen that the kernel is being
> loaded to a guest physical address conflicting with the host memory
> map.
>
> In order to be able to resolve this conflict, add the capability to
> remap non-RAM areas to different g
On 10.09.2024 12:39, Juergen Gross wrote:
> When running as a Xen PV dom0 the system needs to map ACPI data of the
> host using host physical addresses, while those addresses can conflict
> with the guest physical addresses of the loaded linux kernel. The same
> problem might apply in case a PV gue
On 10.09.2024 12:39, Juergen Gross wrote:
> In order to minimize required special handling for running as Xen PV
> dom0, the memory layout is modified to match that of the host. This
> requires to have only RAM at the locations where Xen allocated memory
> is living. Unfortunately there seem to be
On 10/09/2024 14:16, Ayan Kumar Halder wrote:
> Hi Julien,
>
> On 09/09/2024 21:59, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 09/09/2024 20:53, Stefano Stabellini wrote:
>>> On Mon, 9 Sep 2024, Julien Grall wrote:
On 09/09/2024 10:50, Ayan Kumar Halder wrote:
> On 09/09/2024 10:11, J
MISRA Rule 20.7 states:
"Expressions resulting from the expansion of macro parameters
shall be enclosed in parentheses".
The files imported from the gnu-efi package are already deviated, yet
the macro NextMemoryDescriptor is used in non-excluded code, so a further
deviation is needed to exclude al
On 10.09.24 14:26, Jan Beulich wrote:
On 10.09.2024 12:39, Juergen Gross wrote:
When running as a Xen PV dom0 it can happen that the kernel is being
loaded to a guest physical address conflicting with the host memory
map.
In order to be able to resolve this conflict, add the capability to
remap
On 10.09.24 14:34, Jan Beulich wrote:
On 10.09.2024 12:39, Juergen Gross wrote:
When running as a Xen PV dom0 the system needs to map ACPI data of the
host using host physical addresses, while those addresses can conflict
with the guest physical addresses of the loaded linux kernel. The same
pro
On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
> On 09.09.2024 16:54, Roger Pau Monne wrote:
> > Allow setting the used wallclock from the command line. When the option is
> > set
> > to a value different than `auto` the probing is bypassed and the selected
> > implementation is use
Ping?
I think this is a useful change, could we please have a new version
with the proposed adjustments?
Thanks, Roger.
On Wed, Apr 24, 2024 at 03:18:26PM -0400, Daniel P. Smith wrote:
> From: Stefano Stabellini
>
> Xen always generates as XSDT table even if the firmware provided an RSDT
> ta
On 09/09/2024 15:45, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 09/09/2024 11:29, Ayan Kumar Halder wrote:
On 08/09/2024 22:13, Julien Grall wrote:
Hi,
Hi Julien,
On 02/09/2024 15:48, Ayan Kumar Halder wrote:
I will rephrase this as ...
"Used to set customized address at which whic
flight 187623 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187623/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187595
test-amd64-amd64-xl-qemut-win7-amd64
On 10.09.24 13:46, Roger Pau Monne wrote:
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
other fields are derived from this value or hardcoded to be expressed in units
of 512 bytes.
To give so
On 29.08.24 10:47, Shen Lichuan wrote:
Use ERR_CAST() as it is designed for casting an error pointer to
another type.
This macro utilizes the __force and __must_check modifiers, which instruct
the compiler to verify for errors at the locations where it is employed.
Signed-off-by: Shen Lichuan
On 10.09.2024 15:10, Roger Pau Monné wrote:
> On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
>> On 09.09.2024 16:54, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -1550,6 +1550,36 @@ static const char *__init
>>> wallclock_type_to_string(vo
On Tue, 2024-09-10 at 11:42 +0200, Jan Beulich wrote:
> On 02.09.2024 19:01, Oleksii Kurochko wrote:
> > Implement machine_restart() using printk() to prevent recursion
> > that
> > occurs when ASSERT(), BUG*(), or panic() are invoked.
> > All these macros (except panic() which could be called dire
On Tue, Sep 10, 2024 at 03:46:00PM +0200, Jürgen Groß wrote:
> On 10.09.24 13:46, Roger Pau Monne wrote:
> > Current blkif implementations (both backends and frontends) have all slight
> > differences about how they handle the 'sector-size' xenstore node, and how
> > other fields are derived from t
On 10.09.24 15:59, Roger Pau Monné wrote:
On Tue, Sep 10, 2024 at 03:46:00PM +0200, Jürgen Groß wrote:
On 10.09.24 13:46, Roger Pau Monne wrote:
Current blkif implementations (both backends and frontends) have all slight
differences about how they handle the 'sector-size' xenstore node, and how
Add deviation to address violations of MISRA C:2012 Directive 4.10
("Precautions shall be taken in order to prevent the contents of a
header file being included more than once").
This deviation suppresses the violation arising from autogenerated file
xen/include/generated/autoconf.h
No functional
On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
> On 10.09.2024 15:10, Roger Pau Monné wrote:
> > On Tue, Sep 10, 2024 at 11:32:05AM +0200, Jan Beulich wrote:
> >> On 09.09.2024 16:54, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/time.c
> >>> +++ b/xen/arch/x86/time.c
> >>> @@ -1550
On 10.09.2024 16:24, Roger Pau Monné wrote:
> On Tue, Sep 10, 2024 at 03:49:52PM +0200, Jan Beulich wrote:
>> On 10.09.2024 15:10, Roger Pau Monné wrote:
>>> Would you be fine with
>>> adding the following in init_xen_time():
>>>
>>> /*
>>> * EFI run time services can be disabled form the
From: Andrei Cherechesu
Enabled the support for debug through early printk on S32CC
platforms via the NXP LINFlexD UART driver.
Signed-off-by: Andrei Cherechesu
---
xen/arch/arm/Kconfig.debug | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/Kconfig.debug b/xen/arch/arm/Kcon
From: Andrei Cherechesu
All versions of Cortex-A53 cores are affected by the speculative
AT instruction erratum, as mentioned in the Cortex-A53 Revision r0
SDEN v21 documentation.
Enabled ARM64_WORKAROUND_AT_SPECULATE for all versions of Cortex-A53
cores, to avoid corrupting the TLB if performin
From: Andrei Cherechesu
This patch series adds support for NXP Automotive S32CC platform
family, which includes S32G [0] and S32R [1].
First patch adds the driver for the NXP LINFlexD UART, available
on S32V, S32G and S32R automotive processors. The compatibles in
the driver match the ones in up
From: Andrei Cherechesu
This adds support for early printk debug via the NXP LINFlexD
UART controller.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van der Perk
---
xen/arch/arm/Kconfig.debug | 14 +++
xen/arch/arm/arm64/debug-linflex.inc | 58 ++
From: Andrei Cherechesu
The LINFlexD UART is an UART controller available on NXP S32
processors family targeting automotive (for example: S32G2, S32G3,
S32R).
S32G3 Reference Manual:
https://www.nxp.com/webapp/Download?colCode=RMS32G3.
Signed-off-by: Andrei Cherechesu
Signed-off-by: Peter van
From: Andrei Cherechesu
Added support for NXP S32CC platforms (S32G2, S32G3, S32R45),
which need SCMI over SMC calls forwarded to the firmware
running at EL3 (TF-A). Linux relies on the SCMI Platform
for system services such as clocking, reset, etc.
S32CC platforms use the NXP LINFlexD UART driv
It's been unused for nearly 9 years. By the end of the series stdvga.c's
sole purpose will be to make sure VRAM writes use the bufio ioreq path.
1: drop stdvga's "cache" struct member
2: drop stdvga's "stdvga" struct member
3: remove unused MMIO handling code
4: drop stdvga's "gr[]" struct member
As of 68e1183411be ("libxc: introduce a xc_dom_arch for hvm-3.0-x86_32
guests") caching mode is disabled for HVM domains from start-of-day, due
the disabling being unconditional in hvm/save.c:arch_hvm_load(). With
that the field is useless, and can be dropped. Drop the helper functions
manipulating
No consumers are left, hence the producer and the array itself can also
go away. The static gr_mask[] is then orphaned and hence needs dropping,
too.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -49,18 +49,6 @@ static const uint8_t sr_mask[8] = {
1 - 100 of 154 matches
Mail list logo
