Hi Ayan,
On 17/01/2023 18:43, Ayan Kumar Halder wrote:
>
>
> Hi All,
>
> Please have a look at
> https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
> for the context.
>
> The benefits of using 32 bit physical addresses are as follows :-
>
> 1. It helps to use Xen on
in
setup_frametable_mappings to be notified whenever the size of the
structure changes. Also call a panic if the calculated frametable_size
exceeds the limit defined by FRAMETABLE_SIZE macro.
Update the comments regarding the frametable in asm/config.h.
Signed-off-by: Michal Orzel
---
Changes in v2:
- refactor
of physical memory so this is
a latent issue.
Fixes: 5263507b1b4a ("xen: arm: Use a direct mapping of RAM on arm64")
Signed-off-by: Michal Orzel
---
Changes in v2:
- update commit msg making it clear that this is a latent issue
---
xen/arch/arm/include/asm/config.h | 2 +-
1 file
of
the frametable exceeds the limit.
Sent together for ease of merging.
Michal Orzel (3):
xen/arm64: Fix incorrect DIRECTMAP_SIZE calculation
xen/arm32: Remove unused macro FRAMETABLE_VIRT_END
xen/arm: Harden setup_frametable_mappings
xen/arch/arm/include/asm/config.h | 7 +++
xen/arch/arm
This macro is unused and the corresponding one for arm64 has already
been removed as part of the commit 6dc9a1fe982f ("xen/arm: Remove most
of the *_VIRT_END defines").
Signed-off-by: Michal Orzel
---
Changes in v2:
- move a change to a separate patch
---
xen/arch/arm/include/asm/co
If they are truly separate, then please don't thread them.
They were meant to be separated. I will form a series for v2 to make the
commiting easier.
>
> On 16/01/2023 14:41, Michal Orzel wrote:
>> The direct mapped area occupies L0 slots from 256 to 265 (i.e. 10 slots),
>
> I would wri
Hi Julien,
On 17/01/2023 10:29, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 16/01/2023 14:41, Michal Orzel wrote:
>> The amount of supported physical memory depends on the frametable size
>> and the number of struct page_info entries that can fit into it. Defin
; resulting in 5TB (512GB * 10) of virtual address space. However, due to
>> incorrect slot subtraction (we take 9 slots into account) we set
>> DIRECTMAP_SIZE to 4.5TB instead. Fix it.
>>
>> Fixes: 5263507b1b4a ("xen: arm: Use a direct mapping of RAM on arm64")
>
irect mapping of RAM on arm64")
Signed-off-by: Michal Orzel
---
xen/arch/arm/include/asm/config.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm/include/asm/config.h
b/xen/arch/arm/include/asm/config.h
index 0fefed1b8aa9..16213c8b677f 100644
--- a/xen/arch/a
FRAMETABLE_VIRT_END on arm32.
Signed-off-by: Michal Orzel
---
xen/arch/arm/include/asm/config.h | 5 ++---
xen/arch/arm/include/asm/mm.h | 11 +++
xen/arch/arm/mm.c | 5 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/include/asm/config.h
b/xen/arch
Hi Julien,
On 16/01/2023 10:29, Julien Grall wrote:
>
>
> On 16/01/2023 08:46, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 13/01/2023 11:11, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
On 16/01/2023 09:55, Julien Grall wrote:
>
>
> On 16/01/2023 08:14, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Luca,
>
>> On 13/01/2023 11:11, Julien Grall wrote:
>>> +/*
>>> + * Remove the temporary mapping of Xen starting at
>>> T
Hi Julien,
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> At the moment, switch_ttbr() is switching the TTBR whilst the MMU is
> still on.
>
> Switching TTBR is like replacing existing mappings with new ones. So
> we need to follow the break-before-make sequence.
>
>
Hi Julien,
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> In follow-up patches we will need to have part of Xen identity mapped in
> order to safely switch the TTBR.
>
> On some platform, the identity mapping may have to start at 0. If we always
> keep the identity
Hi Julien,
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> Xen is currently not fully compliant with the Arm Arm because it will
> switch the TTBR with the MMU on.
>
> In order to be compliant, we need to disable the MMU before
> switching the TTBR. The implication is
Hi Julien,
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> At the moment, the temporary mapping is only used when the virtual
> runtime region of Xen is clashing with the physical region.
>
> In follow-up patches, we will rework how secondary CPU bring-up works
> and it
Hi Julien,
On 13/01/2023 11:11, Julien Grall wrote:
>
>
> From: Julien Grall
>
> At the moment, bootloaders can load Xen anywhere in memory but the
> region 2MB - 4MB. While I am not aware of any issue, we have no way
> to tell the bootloader to avoid that region.
>
> In addition to that, in
:
> - Expand the commit message to explain why switch_ttbr() is
> not updated.
> - Remove extra spaces in the comment
> - Fix typo in the commit message
Thanks,
Reviewed-by: Michal Orzel
~Michal
tended.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Stefano Stabellini
>
>
> Changes in v4:
> * Add Stefano's reviewed-by tag
> * Add missing space
> * Add Michal's reviewed-by tag
It looks like you forgot to add it, so to make b4 happy:
Reviewed-by: Michal Orzel
~Michal
On 11/01/2023 11:44, Andrew Cooper wrote:
>
>
> On 10/01/2023 4:25 pm, Oleksii Kurochko wrote:
>> All RISCV_64-related stuff was renamed to be consistent with
>> ARM (arm32 is cross build as RISCV_64).
>>
>> The patch is based on the following patch series:
>> [PATCH *] Basic early_printk and
Hi Luca,
On 06/01/2023 11:41, Luca Fancellu wrote:
>
>
> Sort alphabetically cppcheck report entries when producing the text
> report, this will help comparing different reports and will group
> together findings from the same file.
>
> Signed-off-by: Luca Fancellu
> ---
>
Hi Oleksii,
On 06/01/2023 14:14, Oleksii Kurochko wrote:
>
>
> The patch introduce sbi_putchar() SBI call which is necessary
> to implement initial early_printk
>
> Signed-off-by: Oleksii Kurochko
> ---
> xen/arch/riscv/Makefile | 1 +
> xen/arch/riscv/include/asm/sbi.h | 34
6, Julien Grall wrote:
>>>> CAUTION: This message has originated from an External Source. Please
>>>> use proper judgment and caution when opening attachments, clicking
>>>> links, or responding to this email.
>>>>
>>>>
>>>> H
On 04/01/2023 13:12, Andrew Cooper wrote:
>
>
> On 02/01/2023 2:00 pm, Michal Orzel wrote:
>> Hi Andrew,
>>
>> On 30/12/2022 01:38, Andrew Cooper wrote:
>>> Caution: This message originated from an External Source. Use proper
>>> caution when openi
Printing memory size in hex without 0x prefix can be misleading, so
add it. Also, take the opportunity to adhere to 80 chars line length
limit by moving the printk arguments to the next line.
Signed-off-by: Michal Orzel
---
Changes in v2:
- was: "Print memory size in decimal in construct
Hi Julien,
On 03/01/2023 10:56, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 03/01/2023 09:39, Michal Orzel wrote:
>> On 03/01/2023 10:21, Ayan Kumar Halder wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 02/01/2023 14:49, Michal O
Hi Ayan,
On 03/01/2023 10:21, Ayan Kumar Halder wrote:
>
>
> Hi Michal,
>
> On 02/01/2023 14:49, Michal Orzel wrote:
>> Printing domain's memory size in hex without even prepending it
>> with 0x is not very useful and can be misleading. Switch to decimal
&g
Printing domain's memory size in hex without even prepending it
with 0x is not very useful and can be misleading. Switch to decimal
notation.
Signed-off-by: Michal Orzel
---
xen/arch/arm/domain_build.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/arm
rm32-*
> testcases at the point that arm32 get matched with a container that can only
> build Xen.
>
> For simplicity, retain the RANDCONFIG -> HYPERVISOR_ONLY implication.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Michal Orzel
With regards to Oleksii comment, I do
Hi Andrew,
On 30/12/2022 01:38, Andrew Cooper wrote:
>
>
> This is purely code motion of the cfgargs construction, into the case where it
> is used.
>
> No practical change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Michal Orzel
~Michal
nt artefacts. No change in other
> configurations.
>
> Signed-off-by: Andrew Cooper
I'd prefer to keep using "artifacts" and not "artefacts" as the former is what
GitLab uses
and what we use in build/test.yaml.
Apart from that:
Reviewed-by: Michal Orzel
~Michal
HVM-only and neither will come up frequently in randconfig, so
> drop all the logic here to simplify things.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Michal Orzel
~Michal
Hi Ayan,
On 17/12/2022 20:38, Ayan Kumar Halder wrote:
> Currently, kernel_uimage_probe() does not set info->zimage.start. As a
> result, it contains the default value (ie 0). This causes,
> kernel_zimage_place() to treat the binary (contained within uImage) as
> position independent executable.
the d_cfg.max_{grant_frames,maptrack_frames} are of type int32_t.
Call panic in case of overflow. Other sanity checks are already there in
grant_table_init() resulting in panic in case of errors, therefore no
need to repeat them in create_domUs().
Signed-off-by: Michal Orzel
---
Changes in v2:
- call panic
-project/fusa/xtf.git (branch xtf-arm)
Signed-off-by: Michal Orzel
---
Changes in v2:
- run XTF in pure dom0less configuration
---
automation/scripts/qemu-xtf-dom0less-arm64.sh | 68 +++
1 file changed, 68 insertions(+)
create mode 100755 automation/scripts/qemu-xtf-dom0less-arm64.sh
of the xen_version hypercall operations.
Changes in v2:
Let's take the opportunity to run XTF as a domU in pure dom0less configuration,
as this is something our testing do not cover at the moment.
Michal Orzel (2):
automation: Add support for using XTF for arm64 testing
automation: Add test
Add test jobs in both debug and non-debug versions to run hyp-xen-version
XTF test as a dom0less domU on arm64. The purpose of this test is to
validate the functional behavior of xen_version hypercall.
Signed-off-by: Michal Orzel
---
Changes in v2:
- as we are going to run XTF in pure dom0less
On 16/12/2022 10:33, Michal Orzel wrote:
>
>
> Hi Stefano,
>
> On 15/12/2022 22:08, Stefano Stabellini wrote:
>>
>>
>> On Thu, 15 Dec 2022, Michal Orzel wrote:
>>> Add test jobs in both debug and non-debug versions to run hyp-xen-version
>>>
On 16/12/2022 11:21, Jan Beulich wrote:
>
>
> On 16.12.2022 10:30, Michal Orzel wrote:
>> On 15/12/2022 16:48, Jan Beulich wrote:
>>> On 15.12.2022 16:25, Michal Orzel wrote:
>>>> --- /dev/null
>>>> +++ b/tests/hyp-xen-version/main.c
>>&
Hi Stefano,
On 15/12/2022 22:08, Stefano Stabellini wrote:
>
>
> On Thu, 15 Dec 2022, Michal Orzel wrote:
>> Add test jobs in both debug and non-debug versions to run hyp-xen-version
>> XTF test as a dom0less domU on arm64. The purpose of this test is to
>> valid
Hi Stefano,
On 15/12/2022 22:05, Stefano Stabellini wrote:
>
>
> On Thu, 15 Dec 2022, Michal Orzel wrote:
>> Introduce support for using XTF on Arm to perform low-level testing.
>> For the purpose of the CI testing, let's use the fork [1] from upstream
>> XTF with im
Hi Jan,
Thanks for the feedback.
On 15/12/2022 16:48, Jan Beulich wrote:
>
>
> On 15.12.2022 16:25, Michal Orzel wrote:
>> Add a new test hyp-xen-version to perform functional testing of
>> xen_version hypercall. Check the following commands (more
Hi Stefano,
On 15/12/2022 22:38, Stefano Stabellini wrote:
>
>
> On Wed, 14 Dec 2022, Michal Orzel wrote:
>> At the moment, for dom0less domUs, we do not have a way to specify
>> per domain grant table related limits (unlike when using xl), namely
>> max version, max
Add test jobs in both debug and non-debug versions to run hyp-xen-version
XTF test as a dom0less domU on arm64. The purpose of this test is to
validate the functional behavior of xen_version hypercall.
Signed-off-by: Michal Orzel
---
automation/gitlab-ci/test.yaml | 16
1 file
of the xen_version hypercall operations.
Michal Orzel (2):
automation: Add support for using XTF for arm64 testing
automation: Add test jobs to run XTF hypercall xen_version test
automation/gitlab-ci/test.yaml| 16 +++
automation/scripts/qemu-xtf-dom0less-arm64.sh | 97
] https://gitlab.com/xen-project/fusa/xtf.git (branch xtf-arm)
Signed-off-by: Michal Orzel
---
automation/scripts/qemu-xtf-dom0less-arm64.sh | 97 +++
1 file changed, 97 insertions(+)
create mode 100755 automation/scripts/qemu-xtf-dom0less-arm64.sh
diff --git a/automation/scripts/qemu
, enable this test only for arm64.
Signed-off-by: Michal Orzel
---
This is a patch for XTF fork https://gitlab.com/xen-project/fusa/xtf
(branch xtf-arm) under which XTF on Arm port is maintained.
Pushed to xen-devel together with patches to Xen CI automation, so that it is
clear what the test is doing
On 15/12/2022 09:34, Julien Grall wrote:
>
>
> Hi,
>
> On 15/12/2022 01:41, osstest service owner wrote:
>> flight 175226 xen-unstable-smoke real [real]
>>
instruction
> cache flush is only necessary when executable code is modified.
> None of the boot code is doing that.
> * The instruction cache is not invalidated and misprediction is not
> a problem at boot.
>
> Signed-off-by: Julien Grall
Apart fr
there in grant_table_init() resulting in panic in case of errors,
therefore no need to repeat them in create_domUs().
Signed-off-by: Michal Orzel
---
docs/misc/arm/device-tree/booting.txt | 21 +
xen/arch/arm/domain_build.c | 11 ++-
2 files changed, 31 insertions(+), 1
ufficient.
> For the SMP version, a inner-shareable barrier is sufficient.
s/a/an/
>
> Furthermore, the initial barrier only need to a store barrier.
s/need/needs/
>
> For the full explanation of the sequence see asm/arm{32,64}/flushtlb.h.
>
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
~Michal
mmediate of two instructions.
>
> So replace all "ldr rX, =" with "mov_w rX, ".
>
> No functional changes intended.
>
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
with one small change.
>
> ---
>
On 13/12/2022 11:57, Michal Orzel wrote:
>
>
> Hi Julien,
>
> On 12/12/2022 10:55, Julien Grall wrote:
>>
>>
>> From: Julien Grall
>>
>> In a follow-up patch, the base address for the common mappings will
>> vary between arm32 and arm64
evious one.
>
> Take the opportunity to:
> * add missing *_SIZE for FIXMAP_VIRT_* and XEN_VIRT_*
> * switch to MB()/GB() to be avoid hexadecimal (easier to read)
>
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
~Michal
that confirm the same implementation.
>
> Furthermore, Linux has been using 'nsh' since 2013 (62cbbc42e001
> "ARM: tlb: reduce scope of barrier domains for TLB invalidation").
>
> This means barrier after local TLB flushes could be reduced to
> non-shareable.
>
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
~Michal
Hi Julien,
On 13/12/2022 10:45, Julien Grall wrote:
>
>
> On 13/12/2022 09:11, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>> On 12/12/2022 10:55, Julien Grall wrote:
>>>
>>>
>>> From: Julien Grall
>>>
>>
hould also be applied for the TLB flush
> by VA helpers.
>
> Fixes: 22e323d115d8 ("xen/arm: Add workaround for Cortex-A76/Neoverse-N1
> erratum #1286807")
> Signed-off-by: Julien Grall
Reviewed-by: Michal Orzel
~Michal
est_tlb, vmalls12e1is, ish);
>
> /* Flush local TLBs, all VMIDs, non-hypervisor mode */
> -TLB_HELPER(flush_all_guests_tlb_local, alle1);
> +TLB_HELPER(flush_all_guests_tlb_local, alle1, nsh);
>
> /* Flush innershareable TLBs, all VMIDs, non-hypervisor mode */
> -TLB_HELPER(flush_all_guests_tlb, alle1is);
> +TLB_HELPER(flush_all_guests_tlb, alle1is, ish);
>
> /* Flush all hypervisor mappings from the TLB of the local processor. */
> -TLB_HELPER(flush_xen_tlb_local, alle2);
> +TLB_HELPER(flush_xen_tlb_local, alle2, nsh);
>
> /* Flush TLB of local processor for address va. */
> static inline void __flush_xen_tlb_one_local(vaddr_t va)
> --
> 2.38.1
>
With the remarks fixed:
Reviewed-by: Michal Orzel
~Michal
On 08/12/2022 19:42, Ayan Kumar Halder wrote:
>
> On 08/12/2022 16:53, Julien Grall wrote:
>> Hi,
> Hi,
>>
>> On 08/12/2022 15:24, Michal Orzel wrote:
>>> On 08/12/2022 14:51, Julien Grall wrote:
>>>> Caution: This message originated from a
Hi,
On 08/12/2022 14:51, Julien Grall wrote:
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Hi,
>
> Title extra NIT: I have seen it multiple time and so far refrain to say
> it. Please use 'arm'
On 08/12/2022 09:14, Jan Beulich wrote:
>
>
> On 07.12.2022 13:33, Michal Orzel wrote:
>> Hi Stefano,
>>
>> On 07/12/2022 03:12, Stefano Stabellini wrote:
>>>
>>>
>>> Fix two MISRA Issues Rule 8.4 ("A compatible declaration shall be
&
On 17/11/2022 22:15, Stefano Stabellini wrote:
>
>
> On Thu, 17 Nov 2022, Jan Beulich wrote:
>> On 17.11.2022 11:39, Michal Orzel wrote:
>>> On 17/11/2022 11:03, Jan Beulich wrote:
>>>> On 16.11.2022 10:20, Michal Orzel wrote:
>>>>> ---
Hi Stefano,
On 07/12/2022 03:12, Stefano Stabellini wrote:
>
>
> Fix two MISRA Issues Rule 8.4 ("A compatible declaration shall be
> visible when an object or function with external linkage is defined")
> found by cppcheck affecting xen/xsm/flask/ss/services.c.
>
> Fix the first issue by
Hi Jan,
On 07/12/2022 11:34, Jan Beulich wrote:
>
>
> On 07.12.2022 11:29, Michal Orzel wrote:
>> A build failure [1] is observed if CONFIG_VGA (and thus CONFIG_VIDEO) is
>> not set. This is because XENPF_get_dom0_console cmd of platform hypercall
>> makes a call
XENPF_get_dom0_console with CONFIG_VIDEO
ifdefery.
[1]:
ld: prelink.o: in function `do_platform_op':
(.text.do_platform_op+0x1a7): undefined reference to `fill_console_start_info'
Fixes: 4dd160583c79 ("x86/platform: introduce hypercall to get initial video
console settings")
Signed-off-by: Mi
y used. Fix it.
With regards to the comments and respective macros in pci_regs.h, these
were inherited from Linux. Let's knowingly accept the divergence.
Signed-off-by: Michal Orzel
Reviewed-by: Jan Beulich
---
Changes in v2:
- use (?!?) for arch-x86_64.h
- add a note in commit msg that pci_
On 06/12/2022 14:46, Jan Beulich wrote:
>
>
> On 06.12.2022 14:05, Michal Orzel wrote:
>> On 06/12/2022 13:42, Jan Beulich wrote:
>>> On 06.12.2022 11:59, Michal Orzel wrote:
>>>> --- a/xen/include/xen/pci_regs.h
>>>> +++ b/xen/include/xen/pci
Hi Jan,
On 06/12/2022 13:42, Jan Beulich wrote:
>
>
> On 06.12.2022 11:59, Michal Orzel wrote:
>> --- a/xen/include/public/arch-x86_64.h
>> +++ b/xen/include/public/arch-x86_64.h
>> @@ -22,5 +22,5 @@
>> * A similar callback occurs if the segment selectors are
y used. Fix it.
Signed-off-by: Michal Orzel
---
xen/arch/x86/x86_emulate/x86_emulate.h | 2 +-
xen/include/public/arch-x86_64.h | 2 +-
xen/include/xen/pci_regs.h | 12 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/x86_emulate/x86_emulat
Hi Rahul,
On 02/12/2022 11:59, Michal Orzel wrote:
> Hi Rahul,
>
> On 01/12/2022 17:02, Rahul Singh wrote:
>>
>>
>> The SMMUv3 supports two stages of translation. Each stage of translation can
>> be
>> independently enabled. An incoming address is logicall
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> CMD_CFGI_STE is used to invalidate/validate the STE. Emulated vSMMUv3
> driver in XEN will read the STE from the guest memory space and capture
> the Stage-1 configuration required to support nested translation.
>
> Signed-off-by: Rahul
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> Add new viommu_type field and field values XEN_DOMCTL_CONFIG_VIOMMU_NONE
> XEN_DOMCTL_CONFIG_VIOMMU_SMMUV3 in xen_arch_domainconfig to
> enable/disable vIOMMU support for domains.
>
> Also add viommu="N" parameter to xl domain
Hi Rahul,
On 05/12/2022 14:53, Rahul Singh wrote:
>
>
> Hi Michal,
>
>> On 5 Dec 2022, at 8:26 am, Michal Orzel wrote:
>>
>> Hi Rahul,
>>
>> On 01/12/2022 17:02, Rahul Singh wrote:
>>>
>>>
>>> This patch adds basic framework
rovement.
>
> [1] https://developer.arm.com/documentation/den0094/c/?lang=en
> [2]
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/
>
> Signed-off-by: Jiamei Xie
As I wrote in v4:
Reviewed-by: Michal Orzel
~Michal
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> domain_viommu_init() will be called during domain creation and will add
> the dummy trap handler for virtual IOMMUs for guests.
>
> A host IOMMU list will be created when host IOMMU devices are probed
> and this list will be used to
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> This patch adds basic framework for vIOMMU.
>
> Signed-off-by: Rahul Singh
> ---
> xen/arch/arm/domain.c| 17 +++
> xen/arch/arm/domain_build.c | 3 ++
> xen/arch/arm/include/asm/viommu.h| 70
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> To configure IOMMU in guest for passthrough devices, user will need to
> copy the unmodified "iommus" property from host device tree to partial
> device tree. To enable the dom0 linux kernel to confiure the IOMMU
> correctly replace the
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> XEN will create an Emulated SMMUv3 device tree node in the device tree
> to enable the dom0less domains to discover the virtual SMMUv3 during
> boot. Emulated SMMUv3 device tree node will only be created when cmdline
> option vsmmuv3 is
se files are
> generated.
>
> Signed-off-by: Bertrand Marquis
Reviewed-by: Michal Orzel
I know that Stefano tested the build/run on arm64. I did the same locally
on x86 successfully.
~Michal
image
>
> Signed-off-by: Bertrand Marquis
Reviewed-by: Michal Orzel
~Michal
Hi Rahul,
On 01/12/2022 17:02, Rahul Singh wrote:
>
>
> The SMMUv3 supports two stages of translation. Each stage of translation can
> be
> independently enabled. An incoming address is logically translated from VA to
> IPA in stage 1, then the IPA is input to stage 2 which translates the IPA
Hi Julien,
On 01/12/2022 09:52, Julien Grall wrote:
>
>
> Hi,
>
> On 01/12/2022 09:42, Michal Orzel wrote:
>> On 01/12/2022 09:03, Jiamei Xie wrote:
>>>
>>>
>>> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
&g
On 01/12/2022 09:42, Michal Orzel wrote:
>
>
> Hi Jiamei,
>
> On 01/12/2022 09:03, Jiamei Xie wrote:
>>
>>
>> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
>> Linux SBSA PL011 driver will access PL011 DMACR register
rovement.
>
> [1] https://developer.arm.com/documentation/den0094/c/?lang=en
> [2]
> https://lore.kernel.org/xen-devel/alpine.DEB.2.22.394.2211161552420.4020@ubuntu-linux-20-04-desktop/
>
> Signed-off-by: Jiamei Xie
The patch looks good, so:
Reviewed-by: Michal Orzel
Hi Bertrand,
On 30/11/2022 16:07, Bertrand Marquis wrote:
>
>
> Hi Michal,
>
>> On 30 Nov 2022, at 13:02, Michal Orzel wrote:
>>
>> Hi Bertrand,
>>
>> On 30/11/2022 13:15, Bertrand Marquis wrote:
>>>
>>>
>>> From:
Hi Bertrand,
I will try to build and run the yocto containers for a test.
In the meantime I just spotted one thing.
On 30/11/2022 13:15, Bertrand Marquis wrote:
>
>
> Add containers suitable to run yocto kirkstone build based on ubuntu
> 22.04. It contains all packages required by Yocto and a
image
>
> Signed-off-by: Bertrand Marquis
Reviewed-by: Michal Orzel
~Michal
Hi Bertrand,
On 30/11/2022 13:15, Bertrand Marquis wrote:
>
>
> From: Michal Orzel
>
> Populate test jobs for Yocto based tests using the provided containers.
> Due to the size restrictions, it is currently not possible to split the
> build and run tasks, therefo
t Controller (GIC) implemented with an Armv8-R PE must not
> implement LPI support."
>
> By default GICv3 is disabled on AArch32 and enabled on AArch64.
>
> Updated SUPPORT.md to state that GICv3 on Arm32 is not security supported.
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
~Michal
egister
> 11. Interrupt Controller Empty List Register Status Register
> 12. Interrupt Controller Virtual Machine Control Register
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
with one remark...
> ---
>
> Changes from :-
> v1 - 1. Moved coproc regs defin
iorities Group1 Registers 0-3
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel
~Michal
;_EL2) << 32) | ICH_LR<0...15>_EL2
>
> Also, ICR_LR macros need to be modified as ULL is 64 bits for AArch32 and
> AArch64.
>
> Signed-off-by: Ayan Kumar Halder
Reviewed-by: Michal Orzel ,
with two remarks (this is up to maintainers as these are rather cosmetic
changes).
, because less than zero comparison of an unsigned value
can never be true. Fix it by defining vpl011_virq as int.
Fixes: 3580c8b2dfc3 ("xen/arm: if direct-map domain use native UART address and
IRQ number for vPL011")
Signed-off-by: Michal Orzel
---
To be considered to be taken for 4.17
Hi Henry,
On 23/11/2022 11:46, Henry Wang wrote:
>
>
> Hi Michal,
>
>> -Original Message-
>> Subject: Re: [PATCH v4 1/3] CHANGELOG: Add missing entries for work during
>> the 4.17 release
>> Hi Henry,
>> Looking at the "Added" section for the previous releases, we seem to
>> mention
Hi Henry,
On 23/11/2022 05:03, Henry Wang wrote:
>
>
> Signed-off-by: Henry Wang
> ---
> v3 -> v4:
> - Use the corrected sentence for VIRT_SSBD and MSR_SPEC_CTRL
> - Clarify that the virtio-mmio toolstack for ARM is only creating the
> device-tree binding.
> - Remove the "initial" in i.MX
t Controller (GIC) implemented with an Armv8-R PE must not
> implement LPI support."
>
> By default GICv3 is disabled on AArch32 and enabled on AArch64.
>
> Updated SUPPORT.md to state that GICv3 on Arm32 is not security supported.
>
> Signed-off-by: Ayan Kumar Halder
Hi Julien,
On 22/11/2022 21:31, Julien Grall wrote:
>
>
> On 17/11/2022 13:39, Michal Orzel wrote:
>> Hi Ayan,
>>
>> On 11/11/2022 15:17, Ayan Kumar Halder wrote:
>>> Refer ARM DDI 0487I.a ID081822, G8-9817, G8.2.169
>>> Affinity level 3 is no
Hi,
On 22/11/2022 13:25, Julien Grall wrote:
>
>
> Hi,
>
> On 22/11/2022 05:46, Jiamei Xie wrote:
>> When the guest kernel enables DMA engine with "CONFIG_DMA_ENGINE=y",
>> Linux SBSA PL011 driver will access PL011 DMACR register in some
>> functions. As chapter "B Generic UART" in "ARM Server
Hi Ayan,
On 11/11/2022 15:17, Ayan Kumar Halder wrote:
> "unsigned long long" is defined as 64 bits on AArch64 and AArch32
> Thus, one should this instead of "unsigned long" which is 32 bits
> on AArch32.
>
> Also use 'PRIx64' instead of 'lx' or 'llx' to print uint64_t.
>
> Signed-off-by: Ayan
Hi Ayan,
On 11/11/2022 15:17, Ayan Kumar Halder wrote:
> Define missing assembly aliases for GIC registers on arm32, taking the ones
> defined already for arm64 as a base. Aliases are defined according to the
> GIC Architecture Specification ARM IHI 0069H.
>
> Defined the following registers:-
>
601 - 700 of 1233 matches
Mail list logo
