Re: [PATCH] xen/iommu: dt: Check the return value of xsm_deassign_dtdevice()
Hi Julien,
On 22.05.2022 18:59, Julien Grall wrote:
> From: Julien Grall
>
> xsm_deasign_dtdevice() will indicate whether the caller is allowed
s/deasign/deassign/
> to issue the operation. So the return value has to be checked.
>
> Spotted by clang static analyzer.
>
> Fixes: fe36483c ("xen/passthrough: Extend XEN_DOMCTL_*assign_device to
> support DT device")
> Signed-off-by: Julien Grall
Apart from that:
Reviewed-by: Michal Orzel
Re: [PATCH v2] tools/libs/ctrl: rename and export do_memory_op as xc_memory_op
On 19.05.22 19:16, Tamas K Lengyel wrote: Make the do_memory_op function accessible to tools linking with libxc. Similar functions are already available for both domctl and sysctl. As part of this patch we also change the input 'cmd' to be unsigned int to accurately reflect what the hypervisor expects. Signed-off-by: Tamas K Lengyel Reviewed-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v4 1/8] xen: reuse x86 EFI stub functions for Arm
On 23.05.2022 08:25, Wei Chen wrote: > x86 is using compiler feature testing to decide EFI build > enable or not. When EFI build is disabled, x86 will use an > efi/stub.c file to replace efi/runtime.c for build objects. > Following this idea, we introduce a stub file for Arm, but > use CONFIG_ARM_EFI to decide EFI build enable or not. > > And the most functions in x86 EFI stub.c can be reused for > other architectures, like Arm. So we move them to common > and keep the x86 specific function in x86/efi/stub.c. > > To avoid the symbol link conflict error when linking common > stub files to x86/efi. We add a regular file check in efi > stub files' link script. Depends on this check we can bypass > the link behaviors for existed stub files in x86/efi. > > As there is no Arm specific EFI stub function for Arm in > current stage, Arm still can use the existed symbol link > method for EFI stub files. > > Change-Id: Idf19db1ada609d05fc0c0c3b0e1e8687c9d6ac71 > Issue-Id: SCM-2240 I don't think these two lines belong in an upstream submission (I checked patch 2 and at least there they are two similar lines). > Signed-off-by: Wei Chen > Tested-by: Jiamei Xie While I'm not really happy with the Arm side, it's only the other parts which this is applicable to anyway (with the stray tags dropped): Acked-by: Jan Beulich Jan
[ovmf test] 170693: regressions - FAIL
flight 170693 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170693/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 83 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1181 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 69 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
RE: [PATCH v4 1/8] xen: reuse x86 EFI stub functions for Arm
Hi Jan, > -Original Message- > From: Jan Beulich > Sent: 2022年5月23日 15:11 > To: Wei Chen > Cc: nd ; Stefano Stabellini ; Julien > Grall ; Bertrand Marquis ; > Volodymyr Babchuk ; Andrew Cooper > ; Roger Pau Monné ; Wei > Liu ; Jiamei Xie ; xen- > de...@lists.xenproject.org > Subject: Re: [PATCH v4 1/8] xen: reuse x86 EFI stub functions for Arm > > On 23.05.2022 08:25, Wei Chen wrote: > > x86 is using compiler feature testing to decide EFI build > > enable or not. When EFI build is disabled, x86 will use an > > efi/stub.c file to replace efi/runtime.c for build objects. > > Following this idea, we introduce a stub file for Arm, but > > use CONFIG_ARM_EFI to decide EFI build enable or not. > > > > And the most functions in x86 EFI stub.c can be reused for > > other architectures, like Arm. So we move them to common > > and keep the x86 specific function in x86/efi/stub.c. > > > > To avoid the symbol link conflict error when linking common > > stub files to x86/efi. We add a regular file check in efi > > stub files' link script. Depends on this check we can bypass > > the link behaviors for existed stub files in x86/efi. > > > > As there is no Arm specific EFI stub function for Arm in > > current stage, Arm still can use the existed symbol link > > method for EFI stub files. > > > > Change-Id: Idf19db1ada609d05fc0c0c3b0e1e8687c9d6ac71 > > Issue-Id: SCM-2240 > > I don't think these two lines belong in an upstream submission (I > checked patch 2 and at least there they are two similar lines). > Ah, sorry, I had selected the wrong directory after I ran the scripts. But the patch content is the same. > > Signed-off-by: Wei Chen > > Tested-by: Jiamei Xie > > While I'm not really happy with the Arm side, it's only the other > parts which this is applicable to anyway (with the stray tags > dropped): > Acked-by: Jan Beulich > Thanks! > Jan
Re: [PATCH 13/16] xen/arm32: setup: Move out the code to populate the boot allocator
Hi Julien,
On 20.05.2022 14:09, Julien Grall wrote:
> From: Julien Grall
>
> In a follow-up patch, we will want to populate the boot allocator
> separately for arm64. The code will end up to be very similar to the one
> on arm32. So move out the code in a new helper populate_boot_allocator().
>
> For now the code is still protected by CONFIG_ARM_32 to avoid any build
> failure on arm64.
>
> Take the opportunity to replace mfn_add(xen_mfn_start, xenheap_pages) with
> xenheap_mfn_end as they are equivalent.
>
> Signed-off-by: Julien Grall
>
> ---
>
> Changes in v4:
> - Patch added
> ---
> xen/arch/arm/setup.c | 90 +---
> 1 file changed, 51 insertions(+), 39 deletions(-)
>
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index d5d0792ed48a..3d5a2283d4ef 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -637,10 +637,58 @@ static void __init init_staticmem_pages(void)
> }
>
> #ifdef CONFIG_ARM_32
> +/*
> + * Populate the boot allocator. All the RAM but the following regions
> + * will be added:
> + * - Modules (e.g., Xen, Kernel)
> + * - Reserved regions
> + * - Xenheap
> + */
> +static void __init populate_boot_allocator(void)
> +{
> +unsigned int i;
Shouldn't this be an int (as it was previously) because ...
> +const struct meminfo *banks = &bootinfo.mem;
> +
> +for ( i = 0; i < banks->nr_banks; i++ )
... nr_banks is int ?
Apart from that:
Reviewed-by: Michal Orzel
Cheers,
Michal
[ovmf test] 170694: regressions - FAIL
flight 170694 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170694/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 83 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1182 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 70 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH 3/5] x86/perf: expose LBR format in PERF_CAPABILITIES
On Fri, May 20, 2022 at 02:58:01PM +, Andrew Cooper wrote:
> On 20/05/2022 15:19, Jan Beulich wrote:
> > On 20.05.2022 16:10, Andrew Cooper wrote:
> >> On 20/05/2022 14:37, Roger Pau Monne wrote:
> >>> --- a/xen/include/public/arch-x86/cpufeatureset.h
> >>> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> >>> @@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+ 9) /*A
> >>> Supplemental Streaming SIMD Extensio
> >>> XEN_CPUFEATURE(FMA, 1*32+12) /*A Fused Multiply Add */
> >>> XEN_CPUFEATURE(CX16, 1*32+13) /*A CMPXCHG16B */
> >>> XEN_CPUFEATURE(XTPR, 1*32+14) /* Send Task Priority Messages
> >>> */
> >>> -XEN_CPUFEATURE(PDCM, 1*32+15) /* Perf/Debug Capability MSR */
> >>> +XEN_CPUFEATURE(PDCM, 1*32+15) /*S Perf/Debug Capability MSR */
> >> This is the bit which requires more toolstack logic to safely enable.
> >> Using 's' for off-by-default is fine if we want to get the series in now.
> >>
> >> But before we expose the MSR generally, we need to:
> >>
> >> 1) Put the configuration in msr_policy so the toolstack can reason about it
> >> 2) Reject migration attempts to destinations where the LBR format changes
> > Since this could be quite restrictive, and since people needing to know
> > they need to hide this feature for migration to work, I guess this would
> > further want qualifying by "did the guest actually use LBRs so far"?
>
> In practice, it's every major generation ("tock" on Intel's old model),
> so isn't actually limiting the kinds of heterogeneous setups used in
> production. (Migration gets steadily less stable the further apart the
> two CPUs are.)
>
> As to dynamic, no - that would be a security bug in a cloud scenario,
> because there must not be anything the guest can do to interfere with
> the manageability.
>
> Use of LBR is rare, as demonstrated by the fact that noone has
> complained about the fact that migrating such a VM will malfunction.
>
> As we now have a way of reporting "no model-specific LBR", I'm tempted
> to suggest that VMs get no LBR by default, and someone wanting LBR has
> to opt in, which is also an explicit agreement to the migration limitation.
I did also consider exposing "no model-specific LBR" in
PERF_CAPABILITIES unconditionally, but I was worried whether that
would break existing setups.
If we think that providing an option to expose the native LBR format
in PERF_CAPABILITIES is fine that could be a sensible solution IMO.
Thanks, Roger.
Re: [PATCH 3/5] x86/perf: expose LBR format in PERF_CAPABILITIES
On 20.05.2022 16:58, Andrew Cooper wrote:
> On 20/05/2022 15:19, Jan Beulich wrote:
>> On 20.05.2022 16:10, Andrew Cooper wrote:
>>> On 20/05/2022 14:37, Roger Pau Monne wrote:
--- a/xen/include/public/arch-x86/cpufeatureset.h
+++ b/xen/include/public/arch-x86/cpufeatureset.h
@@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+ 9) /*A
Supplemental Streaming SIMD Extensio
XEN_CPUFEATURE(FMA, 1*32+12) /*A Fused Multiply Add */
XEN_CPUFEATURE(CX16, 1*32+13) /*A CMPXCHG16B */
XEN_CPUFEATURE(XTPR, 1*32+14) /* Send Task Priority Messages */
-XEN_CPUFEATURE(PDCM, 1*32+15) /* Perf/Debug Capability MSR */
+XEN_CPUFEATURE(PDCM, 1*32+15) /*S Perf/Debug Capability MSR */
>>> This is the bit which requires more toolstack logic to safely enable.
>>> Using 's' for off-by-default is fine if we want to get the series in now.
>>>
>>> But before we expose the MSR generally, we need to:
>>>
>>> 1) Put the configuration in msr_policy so the toolstack can reason about it
>>> 2) Reject migration attempts to destinations where the LBR format changes
>> Since this could be quite restrictive, and since people needing to know
>> they need to hide this feature for migration to work, I guess this would
>> further want qualifying by "did the guest actually use LBRs so far"?
>
> In practice, it's every major generation ("tock" on Intel's old model),
> so isn't actually limiting the kinds of heterogeneous setups used in
> production. (Migration gets steadily less stable the further apart the
> two CPUs are.)
>
> As to dynamic, no - that would be a security bug in a cloud scenario,
> because there must not be anything the guest can do to interfere with
> the manageability.
>
> Use of LBR is rare, as demonstrated by the fact that noone has
> complained about the fact that migrating such a VM will malfunction.
>
> As we now have a way of reporting "no model-specific LBR",
Which only rather new guest kernels will know to look for. Hence ...
> I'm tempted
> to suggest that VMs get no LBR by default, and someone wanting LBR has
> to opt in, which is also an explicit agreement to the migration limitation.
... while in principle I agree with this, I see a practical issue.
Jan
[ovmf test] 170695: regressions - FAIL
flight 170695 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170695/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 83 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1183 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 71 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH v4 13/21] IOMMU/x86: prefill newly allocate page tables
On Mon, May 23, 2022 at 08:49:27AM +0200, Jan Beulich wrote:
> On 20.05.2022 16:38, Roger Pau Monné wrote:
> > On Fri, May 20, 2022 at 04:28:14PM +0200, Roger Pau Monné wrote:
> >> On Fri, May 20, 2022 at 02:36:02PM +0200, Jan Beulich wrote:
> >>> On 20.05.2022 14:22, Roger Pau Monné wrote:
> On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
> > On 20.05.2022 13:11, Jan Beulich wrote:
> >> On 20.05.2022 12:47, Roger Pau Monné wrote:
> >>> On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
> On 06.05.2022 13:16, Roger Pau Monné wrote:
> > On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
> >> --- a/xen/drivers/passthrough/amd/iommu_map.c
> >> +++ b/xen/drivers/passthrough/amd/iommu_map.c
> >> @@ -115,7 +115,19 @@ static void set_iommu_ptes_present(unsig
> >>
> >> while ( nr_ptes-- )
> >> {
> >> -set_iommu_pde_present(pde, next_mfn, 0, iw, ir);
> >> +ASSERT(!pde->next_level);
> >> +ASSERT(!pde->u);
> >> +
> >> +if ( pde > table )
> >> +ASSERT(pde->ign0 == find_first_set_bit(pde - table));
> >> +else
> >> +ASSERT(pde->ign0 == PAGE_SHIFT - 3);
> >
> > I think PAGETABLE_ORDER would be clearer here.
>
> I disagree - PAGETABLE_ORDER is a CPU-side concept. It's not used
> anywhere
> in IOMMU code afaics.
> >>>
> >>> Isn't PAGE_SHIFT also a CPU-side concept in the same way? I'm not
> >>> sure what's the rule for declaring that PAGE_SHIFT is fine to use in
> >>> IOMMU code but not PAGETABLE_ORDER.
> >>
> >> Hmm, yes and no. But for consistency with other IOMMU code I may want
> >> to switch to PAGE_SHIFT_4K.
> >
> > Except that, with the plan to re-use pt_update_contig_markers() for CPU-
> > side re-coalescing, there I'd prefer to stick to PAGE_SHIFT.
>
> Then can PAGETABLE_ORDER be used instead of PAGE_SHIFT - 3?
> >>>
> >>> pt_update_contig_markers() isn't IOMMU code; since I've said I'd switch
> >>> to PAGE_SHIFT_4K in IOMMU code I'm having a hard time seeing how I could
> >>> at the same time start using PAGETABLE_ORDER there.
> >>
> >> I've got confused by the double reply and read it as if you where
> >> going to stick to using PAGE_SHIFT everywhere as proposed originally.
> >>
> >>> What I maybe could do is use PTE_PER_TABLE_SHIFT in AMD code and
> >>> LEVEL_STRIDE in VT-d one. Yet I'm not sure that would be fully correct/
> >>> consistent, ...
> >>>
> IMO it makes the code quite easier to understand.
> >>>
> >>> ... or in fact helping readability.
> >>
> >> Looking at pt_update_contig_markers() we hardcode CONTIG_LEVEL_SHIFT
> >> to 9 there, which means all users must have a page table order of 9.
> >>
> >> It seems to me we are just making things more complicated than
> >> necessary by trying to avoid dependencies between CPU and IOMMU
> >> page-table sizes and definitions, when the underlying mechanism to set
> >> ->ign0 has those assumptions baked in.
> >>
> >> Would it help if you introduced a PAGE_TABLE_ORDER in page-defs.h?
> >
> > Sorry, should be PAGE_TABLE_ORDER_4K.
>
> Oh, good that I looked here before replying to the earlier mail: I'm
> afraid I view PAGE_TABLE_ORDER_4K as not very useful. From an
> abstract POV, what is the base unit meant to be that the order is
> is based upon? PAGE_SHIFT? Or PAGE_SHIFT_4K? I think such an
> ambiguity is going to remain even if we very clearly spelled out what
> we mean things to be, as one would always need to go back to that
> comment to check which of the two possible ways it is.
>
> Furthermore I'm not convinced PAGETABLE_ORDER is really meant to be
> associated with a particular page size anyway: PAGE_TABLE_ORDER_2M
> imo makes no sense at all. And page-defs.h is not supposed to
> express any platform properties anyway, it's merely an accumulation
> of (believed) useful constants.
>
> Hence the only thing which I might see as a (remote) option is
> IOMMU_PAGE_TABLE_ORDER (for platforms where all IOMMU variants have
> all page table levels using identical sizes, which isn't a given, but
> which would hold for x86 and hence for the purpose here).
Since you already define a page table order in pt-contig-markers.h
(CONTIG_NR) it might be possible to export and use that? In fact the
check done here would be even more accurate if it was done using the
same constant that's used in pt_update_contig_markers(), because the
purpose here is to check that the vendor specific code to init the
page tables has used the correct value.
Thanks, Roger.
[PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime
Introduce a command line parameter "maxcpus" on Arm to allow adjusting
the number of CPUs to activate. Currently the limit is defined by the
config option CONFIG_NR_CPUS. Such parameter already exists on x86.
Define a parameter "maxcpus" and a corresponding static variable
max_cpus in Arm smpboot.c. Modify function smp_get_max_cpus to take
max_cpus as a limit and to return proper unsigned int instead of int.
Take the opportunity to remove redundant variable cpus from start_xen
function and to directly assign the return value from smp_get_max_cpus
to nr_cpu_ids (global variable in Xen used to store the number of CPUs
actually activated).
Signed-off-by: Michal Orzel
---
max_cpus is also defined in x86 setup.c. It would be possible to join
these definitions in xen/common/cpu.c. However in that case, max_cpus
would become global which is not really what we want. There is already
global nr_cpu_ids used everywhere and max_cpus being used only in x86
start_xen and Arm smp_get_max_cpus should be kept local. Also there are
already lots of places in Xen using max_cpus (local versions) and that
would start to be hard to read (variable shadowing).
---
docs/misc/xen-command-line.pandoc | 2 +-
xen/arch/arm/include/asm/smp.h| 2 +-
xen/arch/arm/setup.c | 10 --
xen/arch/arm/smpboot.c| 18 --
4 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/docs/misc/xen-command-line.pandoc
b/docs/misc/xen-command-line.pandoc
index 1dc7e1ca07..a40d0ae2e8 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -1651,7 +1651,7 @@ with **crashinfo_maxaddr**.
Specify the threshold below which Xen will inform dom0 that the quantity of
free memory is getting low. Specifying `0` will disable this notification.
-### maxcpus (x86)
+### maxcpus
> `= `
Specify the maximum number of CPUs that should be brought up.
diff --git a/xen/arch/arm/include/asm/smp.h b/xen/arch/arm/include/asm/smp.h
index 83c0cd6976..8133d5c295 100644
--- a/xen/arch/arm/include/asm/smp.h
+++ b/xen/arch/arm/include/asm/smp.h
@@ -33,7 +33,7 @@ extern void init_secondary(void);
extern void smp_init_cpus(void);
extern void smp_clear_cpu_maps (void);
-extern int smp_get_max_cpus (void);
+extern unsigned int smp_get_max_cpus(void);
#define cpu_physical_id(cpu) cpu_logical_map(cpu)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed4..b8d97950b7 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -862,11 +862,10 @@ void __init start_xen(unsigned long boot_phys_offset,
unsigned long fdt_paddr)
{
size_t fdt_size;
-int cpus, i;
const char *cmdline;
struct bootmodule *xen_bootmodule;
struct domain *d;
-int rc;
+int rc, i;
dcache_line_bytes = read_dcache_line_bytes();
@@ -942,9 +941,8 @@ void __init start_xen(unsigned long boot_phys_offset,
processor_id();
smp_init_cpus();
-cpus = smp_get_max_cpus();
-printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", cpus);
-nr_cpu_ids = cpus;
+nr_cpu_ids = smp_get_max_cpus();
+printk(XENLOG_INFO "SMP: Allowing %u CPUs\n", nr_cpu_ids);
/*
* Some errata relies on SMCCC version which is detected by psci_init()
@@ -988,7 +986,7 @@ void __init start_xen(unsigned long boot_phys_offset,
for_each_present_cpu ( i )
{
-if ( (num_online_cpus() < cpus) && !cpu_online(i) )
+if ( (num_online_cpus() < nr_cpu_ids) && !cpu_online(i) )
{
int ret = cpu_up(i);
if ( ret != 0 )
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 9bb32a301a..22fede6600 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -43,6 +43,10 @@ cpumask_t cpu_possible_map;
struct cpuinfo_arm cpu_data[NR_CPUS];
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus;
+integer_param("maxcpus", max_cpus);
+
/* CPU logical map: map xen cpuid to an MPIDR */
register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
@@ -277,16 +281,18 @@ void __init smp_init_cpus(void)
"unless the cpu affinity of all domains is specified.\n");
}
-int __init
-smp_get_max_cpus (void)
+unsigned int __init smp_get_max_cpus(void)
{
-int i, max_cpus = 0;
+unsigned int i, cpus = 0;
+
+if ( ( !max_cpus ) || ( max_cpus > nr_cpu_ids ) )
+max_cpus = nr_cpu_ids;
-for ( i = 0; i < nr_cpu_ids; i++ )
+for ( i = 0; i < max_cpus; i++ )
if ( cpu_possible(i) )
-max_cpus++;
+cpus++;
-return max_cpus;
+return cpus;
}
void __init
--
2.25.1
[libvirt test] 170690: regressions - FAIL
flight 170690 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/170690/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-raw 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a version targeted for testing: libvirt 42cb54804588aa82e32219fc56c15817f8b1edb0 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 682 days Failing since151818 2020-07-11 04:18:52 Z 681 days 663 attempts Testing same since 170624 2022-05-21 04:18:50 Z2 days3 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Amneesh Singh Andika Triwidada Andrea Bolognani Andrew Melnychenko Ani Sinha Balázs Meskó Barrett Schonefeld Bastian Germann Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Bjoern Walk Boris Fiuczynski Brad Laue Brian Turek Bruno Haible Chris Mayo Christian Borntraeger Christian Ehrhardt Christian Kirbach Christian Schoenebeck Christophe Fergeau Claudio Fontana Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Didik Supriadi dinglimin Divya Garg Dmitrii Shcherbakov Dmytro Linkin Eiichi Tsukata Emilio Herrera Eric Farman Erik Skultety Fabian Affolter Fabian Freyer Fabiano Fidêncio Fangge Jin Farhan Ali Fedora Weblate Translation Franck Ridel Gavi Teitz gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Haonan Wang Hela Basa Helmut Grohne Hiroki Narukawa Hyman Huang(黄勇) Ian Wienand Ioanna Alifieraki Ivan Teterevkov Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen jason lee Jean-Baptiste Holcroft Jia Zhou Jianan Gao Jim Fehlig Jin Yan Jing Qi Jinsheng Zhang Jiri Denemark Joachim Falk John Ferlan John Levon John Levon Jonathan Watt Jonathon Jongsma Julio Faracco Justin Gatzen Ján Tomko Kashyap Chamarthy Kevin Locke Kim InSoo Koichi Murase Kristina Hanicova Laine Stump Laszlo Ersek Lee Yarwood Lei Yang Lena Voytek Liang Yan Liang Yan Liao Pingfang Lin Ma Lin Ma Lin Ma Liu Yiding Lubomir Rintel Luke Yue Luyao Zhong luzhipeng Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Martin Pitt Masayoshi Mizuma Matej Cepl Matt Coleman Matt Coleman Mauro Matteo Cascella Max Goodhart Maxim Nestratov Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Moteen Shah Moteen Shah Muha Aliss Nathan Neal Gompa Nick Chevsky Nick Shyrokovskiy Nickys Music Group Nico Pache Nicolas Lécureuil Nicolas Lécureuil Nikolay Shirokovskiy Nikolay Shirokovskiy Nikolay Shirokovskiy Niteesh Dubey Olaf Hering Olesya Gerasimenko Or Ozeri Orion Poplawski Pany Paolo Bonzini Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano
[ovmf test] 170696: regressions - FAIL
flight 170696 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170696/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 83 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1184 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 72 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[PATCH v4 5/6] tools: Use new byteswap helper
Include new header to use new byteswap helper
No functional change.
Signed-off-by: Lin Liu
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
tools/libs/guest/xg_dom_decompress_unsafe_xz.c | 5 +
tools/libs/guest/xg_dom_decompress_unsafe_zstd.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
index fc48198741..493427d517 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
@@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
return cpu_to_le32(*p);
}
+static inline u32 le32_to_cpu(u32 val)
+{
+ return le32_to_cpup((const u32 *)&val);
+}
+
#define __force
#define always_inline
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
index 01eaf6..b06f2e767f 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
@@ -31,7 +31,8 @@ typedef uint64_t __be64;
#define __BYTEORDER_HAS_U64__
#define __TYPES_H__ /* xen/types.h guard */
-#include "../../xen/include/xen/byteorder/little_endian.h"
+#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#include "../../xen/include/xen/byteorder.h"
#define __ASM_UNALIGNED_H__ /* asm/unaligned.h guard */
#include "../../xen/include/xen/unaligned.h"
#include "../../xen/include/xen/xxhash.h"
--
2.27.0
[PATCH v4 3/6] arm64/find_next_bit: Remove ext2_swab()
ext2 has nothing to do with this logic. Clean up the code with
xen/byteswap.h which now has an unsigned long helper.
No functional change.
Signed-off-by: Lin Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Volodymyr Babchuk
---
xen/arch/arm/arm64/lib/find_next_bit.c | 36 +-
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c
b/xen/arch/arm/arm64/lib/find_next_bit.c
index 8ebf8bfe97..e3b3720ff4 100644
--- a/xen/arch/arm/arm64/lib/find_next_bit.c
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -161,30 +161,6 @@ EXPORT_SYMBOL(find_first_zero_bit);
#ifdef __BIG_ENDIAN
-/* include/linux/byteorder does not support "unsigned long" type */
-static inline unsigned long ext2_swabp(const unsigned long * x)
-{
-#if BITS_PER_LONG == 64
- return (unsigned long) __swab64p((u64 *) x);
-#elif BITS_PER_LONG == 32
- return (unsigned long) __swab32p((u32 *) x);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
-
-/* include/linux/byteorder doesn't support "unsigned long" type */
-static inline unsigned long ext2_swab(const unsigned long y)
-{
-#if BITS_PER_LONG == 64
- return (unsigned long) __swab64((u64) y);
-#elif BITS_PER_LONG == 32
- return (unsigned long) __swab32((u32) y);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
-
#ifndef find_next_zero_bit_le
unsigned long find_next_zero_bit_le(const void *addr, unsigned
long size, unsigned long offset)
@@ -199,7 +175,7 @@ unsigned long find_next_zero_bit_le(const void *addr,
unsigned
size -= result;
offset &= (BITS_PER_LONG - 1UL);
if (offset) {
- tmp = ext2_swabp(p++);
+ tmp = bswap_ul(*p++);
tmp |= (~0UL >> (BITS_PER_LONG - offset));
if (size < BITS_PER_LONG)
goto found_first;
@@ -217,7 +193,7 @@ unsigned long find_next_zero_bit_le(const void *addr,
unsigned
}
if (!size)
return result;
- tmp = ext2_swabp(p);
+ tmp = bswap_ul(*p);
found_first:
tmp |= ~0UL << size;
if (tmp == ~0UL)/* Are any bits zero? */
@@ -226,7 +202,7 @@ found_middle:
return result + ffz(tmp);
found_middle_swap:
- return result + ffz(ext2_swab(tmp));
+ return result + ffz(bswap_ul(tmp));
}
EXPORT_SYMBOL(find_next_zero_bit_le);
#endif
@@ -245,7 +221,7 @@ unsigned long find_next_bit_le(const void *addr, unsigned
size -= result;
offset &= (BITS_PER_LONG - 1UL);
if (offset) {
- tmp = ext2_swabp(p++);
+ tmp = bswap_ul(*p++);
tmp &= (~0UL << offset);
if (size < BITS_PER_LONG)
goto found_first;
@@ -264,7 +240,7 @@ unsigned long find_next_bit_le(const void *addr, unsigned
}
if (!size)
return result;
- tmp = ext2_swabp(p);
+ tmp = bswap_ul(*p);
found_first:
tmp &= (~0UL >> (BITS_PER_LONG - size));
if (tmp == 0UL) /* Are any bits set? */
@@ -273,7 +249,7 @@ found_middle:
return result + __ffs(tmp);
found_middle_swap:
- return result + __ffs(ext2_swab(tmp));
+ return result + __ffs(bswap_ul(tmp));
}
EXPORT_SYMBOL(find_next_bit_le);
#endif
--
2.27.0
[PATCH v4 1/6] xen: implement byteswap
swab() is massively over complicated and can be simplified
by re-implementing using compiler builtins.
The compilers provide builtin function to swap bytes.
* gcc: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
* clang: https://clang.llvm.org/docs/LanguageExtensions.html
This patch introduces a new byteswapping infrastructure in
terms of compiler builtins and bswapXX(), so the swab() infrastructure
can be retired.
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Volodymyr Babchuk
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Wei Liu
Cc: "Roger Pau Monné"
Changes in v4:
- Move `PASTE` definition to xen/compiler.h to support tools
- Revert emacs magics
Changes in v3:
- Check __has_builtin instead of GNUC version
Changes in v2:
- Add fallback for compilers without __builtin_bswap
- Implement with plain C instead of macros
---
xen/arch/arm/include/asm/byteorder.h | 6 ++-
xen/arch/x86/include/asm/byteorder.h | 34 ++---
xen/include/xen/byteorder.h | 56
xen/include/xen/byteswap.h | 44 ++
xen/include/xen/compiler.h | 24
xen/include/xen/lib.h| 4 --
6 files changed, 132 insertions(+), 36 deletions(-)
create mode 100644 xen/include/xen/byteorder.h
create mode 100644 xen/include/xen/byteswap.h
diff --git a/xen/arch/arm/include/asm/byteorder.h
b/xen/arch/arm/include/asm/byteorder.h
index 9c712c4788..b6a33b23c0 100644
--- a/xen/arch/arm/include/asm/byteorder.h
+++ b/xen/arch/arm/include/asm/byteorder.h
@@ -1,9 +1,11 @@
#ifndef __ASM_ARM_BYTEORDER_H__
#define __ASM_ARM_BYTEORDER_H__
-#define __BYTEORDER_HAS_U64__
+#ifndef __BYTE_ORDER__
+ #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#endif
-#include
+#include
#endif /* __ASM_ARM_BYTEORDER_H__ */
/*
diff --git a/xen/arch/x86/include/asm/byteorder.h
b/xen/arch/x86/include/asm/byteorder.h
index 1f77e502a5..82aadee7bd 100644
--- a/xen/arch/x86/include/asm/byteorder.h
+++ b/xen/arch/x86/include/asm/byteorder.h
@@ -1,36 +1,10 @@
#ifndef __ASM_X86_BYTEORDER_H__
#define __ASM_X86_BYTEORDER_H__
-#include
-#include
+#ifndef __BYTE_ORDER__
+ #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#endif
-static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
-{
-asm("bswap %0" : "=r" (x) : "0" (x));
-return x;
-}
-
-static inline __attribute_const__ __u64 ___arch__swab64(__u64 val)
-{
-union {
-struct { __u32 a,b; } s;
-__u64 u;
-} v;
-v.u = val;
-asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
-: "=r" (v.s.a), "=r" (v.s.b)
-: "0" (v.s.a), "1" (v.s.b));
-return v.u;
-}
-
-/* Do not define swab16. Gcc is smart enough to recognize "C" version and
- convert it into rotation or exhange. */
-
-#define __arch__swab64(x) ___arch__swab64(x)
-#define __arch__swab32(x) ___arch__swab32(x)
-
-#define __BYTEORDER_HAS_U64__
-
-#include
+#include
#endif /* __ASM_X86_BYTEORDER_H__ */
diff --git a/xen/include/xen/byteorder.h b/xen/include/xen/byteorder.h
new file mode 100644
index 00..2ec434e6a6
--- /dev/null
+++ b/xen/include/xen/byteorder.h
@@ -0,0 +1,56 @@
+#ifndef __XEN_BYTEORDER_H__
+#define __XEN_BYTEORDER_H__
+
+#include
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+
+# ifndef __LITTLE_ENDIAN
+# define __LITTLE_ENDIAN 1234
+# endif
+
+# ifndef __LITTLE_ENDIAN_BITFIELD
+# define __LITTLE_ENDIAN_BITFIELD
+# endif
+
+# define cpu_to_le64(x) (x)
+# define le64_to_cpu(x) (x)
+# define cpu_to_le32(x) (x)
+# define le32_to_cpu(x) (x)
+# define cpu_to_le16(x) (x)
+# define le16_to_cpu(x) (x)
+# define cpu_to_be64(x) bswap64(x)
+# define be64_to_cpu(x) bswap64(x)
+# define cpu_to_be32(x) bswap32(x)
+# define be32_to_cpu(x) bswap32(x)
+# define cpu_to_be16(x) bswap16(x)
+# define be16_to_cpu(x) bswap16(x)
+
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+
+# ifndef __BIG_ENDIAN
+# define __BIG_ENDIAN 4321
+# endif
+
+# ifndef __BIG_ENDIAN_BITFIELD
+# define __BIG_ENDIAN_BITFIELD
+# endif
+
+# define cpu_to_le64(x) bswap64(x)
+# define le64_to_cpu(x) bswap64(x)
+# define cpu_to_le32(x) bswap32(x)
+# define le32_to_cpu(x) bswap32(x)
+# define cpu_to_le16(x) bswap16(x)
+# define le16_to_cpu(x) bswap16(x)
+# define cpu_to_be64(x) (x)
+# define be64_to_cpu(x) (x)
+# define cpu_to_be32(x) (x)
+# define be32_to_cpu(x) (x)
+# define cpu_to_be16(x) (x)
+# define be16_to_cpu(x) (x)
+
+#else
+# error "Unknown Endianness"
+#endif /* __BYTE_ORDER__ */
+
+#endif /* __XEN_BYTEORDER_H__ */
diff --git a/xen/include/xen/byteswap.h b/xen/include/xen/byteswap.h
new file mode 100644
index 00..d2e371fbe7
--- /dev/null
+++ b/xen/include/xen/byteswap.h
@@ -0,0 +1,44 @@
+#ifndef __XEN_BYTESWAP_H__
+#define __XEN_BYTESWAP_H__
+
+#include
+#include
+
+#if !__has_builtin(__builtin_bswap16)
+static always_inline uint16_t __builtin_bswap16(uint16_t val)
+{
+return ((val &
[PATCH v4 2/6] crypto/vmac: Simplify code with byteswap
This file has its own implementation of swap bytes. Clean up
the code with xen/byteswap.h.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Stefano Stabellini
Cc: Wei Liu
xen/crypto/vmac.c | 76 ++-
1 file changed, 3 insertions(+), 73 deletions(-)
diff --git a/xen/crypto/vmac.c b/xen/crypto/vmac.c
index 294dd16a52..acb4e015f5 100644
--- a/xen/crypto/vmac.c
+++ b/xen/crypto/vmac.c
@@ -8,6 +8,7 @@
/* start for Xen */
#include
+#include
#include
#include
#include
@@ -50,7 +51,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /* Poly
key mask */
* MUL64: 64x64->128-bit multiplication
* PMUL64: assumes top bits cleared on inputs
* ADD128: 128x128->128-bit addition
- * GET_REVERSED_64: load and byte-reverse 64-bit word
* --- */
/* --- */
@@ -68,22 +68,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
#define PMUL64 MUL64
-#define GET_REVERSED_64(p)\
-({uint64_t x; \
- asm ("bswapq %0" : "=r" (x) : "0"(*(uint64_t *)(p))); x;})
-
-/* --- */
-#elif (__GNUC__ && __i386__)
-/* --- */
-
-#define GET_REVERSED_64(p)\
-({ uint64_t x;\
-uint32_t *tp = (uint32_t *)(p); \
-asm ("bswap %%edx\n\t" \
- "bswap %%eax" \
-: "=A"(x) \
-: "a"(tp[1]), "d"(tp[0]));\
-x; })
/* --- */
#elif (__GNUC__ && __ppc64__)
@@ -103,37 +87,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
#define PMUL64 MUL64
-#define GET_REVERSED_64(p)\
-({ uint32_t hi, lo, *_p = (uint32_t *)(p);\
- asm volatile ("lwbrx %0, %1, %2" : "=r"(lo) : "b%"(0), "r"(_p) ); \
- asm volatile ("lwbrx %0, %1, %2" : "=r"(hi) : "b%"(4), "r"(_p) ); \
- ((uint64_t)hi << 32) | (uint64_t)lo; } )
-
-/* --- */
-#elif (__GNUC__ && (__ppc__ || __PPC__))
-/* --- */
-
-#define GET_REVERSED_64(p)\
-({ uint32_t hi, lo, *_p = (uint32_t *)(p);\
- asm volatile ("lwbrx %0, %1, %2" : "=r"(lo) : "b%"(0), "r"(_p) ); \
- asm volatile ("lwbrx %0, %1, %2" : "=r"(hi) : "b%"(4), "r"(_p) ); \
- ((uint64_t)hi << 32) | (uint64_t)lo; } )
-
-/* --- */
-#elif (__GNUC__ && (__ARMEL__ || __ARM__))
-/* --- */
-
-#define bswap32(v)\
-({ uint32_t tmp,out; \
-asm volatile( \
-"eor%1, %2, %2, ror #16\n"\
-"bic%1, %1, #0x00ff\n"\
-"mov%0, %2, ror #8\n" \
-"eor%0, %0, %1, lsr #8" \
-: "=r" (out), "=&r" (tmp) \
-: "r" (v)); \
-out;})
-
/* --- */
#elif _MSC_VER
/* --- */
@@ -154,11 +107,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
(rh) += (ih) + ((rl) < (_il)); \
}
-#if _MSC_VER >= 1300
-#define GET_REVERSED_64(p) _byteswap_uint64(*(uint64_t *)(p))
-#pragma intrinsic(_byteswap_uint64)
-#endif
-
#if _MSC_VER >= 1400 && \
(!defined(__INTEL_COMPILER) || __INTEL_COMPILER >= 1000)
#define MUL32(i1,i2)(__emulu((uint32_t)(i1),(uint32_t)(i2)))
@@ -219,24 +167,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Po
[PATCH v4 0/6] Implement byteswap and update references
Lin Liu (6): xen: implement byteswap crypto/vmac: Simplify code with byteswap arm64/find_next_bit: Remove ext2_swab() xen: Switch to byteswap tools: Use new byteswap helper byteorder: Remove byteorder .../libs/guest/xg_dom_decompress_unsafe_xz.c | 5 + .../guest/xg_dom_decompress_unsafe_zstd.c | 3 +- xen/arch/arm/arm64/lib/find_next_bit.c| 36 +--- xen/arch/arm/include/asm/byteorder.h | 6 +- xen/arch/x86/include/asm/byteorder.h | 34 +--- xen/common/device_tree.c | 44 ++--- xen/common/libelf/libelf-private.h| 6 +- xen/common/xz/private.h | 2 +- xen/crypto/vmac.c | 76 +--- xen/include/xen/byteorder.h | 56 ++ xen/include/xen/byteorder/big_endian.h| 102 -- xen/include/xen/byteorder/generic.h | 68 --- xen/include/xen/byteorder/little_endian.h | 102 -- xen/include/xen/byteorder/swab.h | 183 -- xen/include/xen/byteswap.h| 44 + xen/include/xen/compiler.h| 24 +++ xen/include/xen/lib.h | 4 - xen/include/xen/unaligned.h | 12 +- 18 files changed, 180 insertions(+), 627 deletions(-) create mode 100644 xen/include/xen/byteorder.h delete mode 100644 xen/include/xen/byteorder/big_endian.h delete mode 100644 xen/include/xen/byteorder/generic.h delete mode 100644 xen/include/xen/byteorder/little_endian.h delete mode 100644 xen/include/xen/byteorder/swab.h create mode 100644 xen/include/xen/byteswap.h -- 2.27.0
[PATCH v4 4/6] xen: Switch to byteswap
Update to use byteswap to swap bytes.
No functional change.
Signed-off-by: Lin Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Wei Liu
Changes in v4:
- Revert the __force in type casting
Changes in v3:
- Update xen/common/device_tree.c to use be32_to_cpu
- Keep const in type cast in unaligned.h
---
xen/common/device_tree.c | 44 +++---
xen/common/libelf/libelf-private.h | 6 ++--
xen/common/xz/private.h| 2 +-
xen/include/xen/unaligned.h| 12
4 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 4aae281e89..70d3be3be6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -171,7 +171,7 @@ bool_t dt_property_read_u32(const struct dt_device_node *np,
if ( !val || len < sizeof(*out_value) )
return 0;
-*out_value = be32_to_cpup(val);
+*out_value = be32_to_cpu(*val);
return 1;
}
@@ -264,7 +264,7 @@ int dt_property_read_variable_u32_array(const struct
dt_device_node *np,
count = sz;
while ( count-- )
-*out_values++ = be32_to_cpup(val++);
+*out_values++ = be32_to_cpu(*val++);
return sz;
}
@@ -490,7 +490,7 @@ static int __dt_n_addr_cells(const struct dt_device_node
*np, bool_t parent)
ip = dt_get_property(np, "#address-cells", NULL);
if ( ip )
-return be32_to_cpup(ip);
+return be32_to_cpu(*ip);
} while ( np->parent );
/* No #address-cells property for the root node */
return DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
@@ -507,7 +507,7 @@ int __dt_n_size_cells(const struct dt_device_node *np,
bool_t parent)
ip = dt_get_property(np, "#size-cells", NULL);
if ( ip )
-return be32_to_cpup(ip);
+return be32_to_cpu(*ip);
} while ( np->parent );
/* No #address-cells property for the root node */
return DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
@@ -660,7 +660,7 @@ static void dt_bus_pci_count_cells(const struct
dt_device_node *np,
static unsigned int dt_bus_pci_get_flags(const __be32 *addr)
{
unsigned int flags = 0;
-u32 w = be32_to_cpup(addr);
+u32 w = be32_to_cpu(*addr);
switch((w >> 24) & 0x03) {
case 0x01:
@@ -1077,7 +1077,7 @@ dt_irq_find_parent(const struct dt_device_node *child)
if ( parp == NULL )
p = dt_get_parent(child);
else
-p = dt_find_node_by_phandle(be32_to_cpup(parp));
+p = dt_find_node_by_phandle(be32_to_cpu(*parp));
child = p;
} while ( p && dt_get_property(p, "#interrupt-cells", NULL) == NULL );
@@ -1110,7 +1110,7 @@ unsigned int dt_number_of_irq(const struct dt_device_node
*device)
intlen /= sizeof(*intspec);
dt_dprintk(" using 'interrupts' property\n");
-dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
+dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpu(*intspec), intlen);
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
@@ -1241,7 +1241,7 @@ int dt_for_each_irq_map(const struct dt_device_node *dev,
imaplen -= addrsize + intsize;
/* Get the interrupt parent */
-ipar = dt_find_node_by_phandle(be32_to_cpup(imap));
+ipar = dt_find_node_by_phandle(be32_to_cpu(*imap));
imap++;
--imaplen;
@@ -1358,8 +1358,8 @@ static int dt_irq_map_raw(const struct dt_device_node
*parent,
int match, i;
dt_dprintk("dt_irq_map_raw: par=%s,intspec=[0x%08x
0x%08x...],ointsize=%d\n",
- parent->full_name, be32_to_cpup(intspec),
- be32_to_cpup(intspec + 1), ointsize);
+ parent->full_name, be32_to_cpu(*intspec),
+ be32_to_cpu(*(intspec+1)), ointsize);
ipar = parent;
@@ -1471,7 +1471,7 @@ static int dt_irq_map_raw(const struct dt_device_node
*parent,
dt_dprintk(" -> match=%d (imaplen=%d)\n", match, imaplen);
/* Get the interrupt parent */
-newpar = dt_find_node_by_phandle(be32_to_cpup(imap));
+newpar = dt_find_node_by_phandle(be32_to_cpu(*imap));
imap++;
--imaplen;
@@ -1565,7 +1565,7 @@ int dt_device_get_raw_irq(const struct dt_device_node
*device,
intlen /= sizeof(*intspec);
dt_dprintk(" using 'interrupts' property\n");
-dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
+dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpu(*intspec), intlen);
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
@@ -1676,7 +1676,7 @@ static int __dt_parse_phandle_with_args(const struct
dt_device_node *np,
* If phandle is 0, then it is an empty entry with no
* arguments. Skip forward to the next entry.
* */
-phandle = be32_to_cpup(list++);
+phandle = be32_to
[PATCH v4 6/6] byteorder: Remove byteorder
include/xen/byteswap.h has simplify the interface, just clean
the old interface
No functional change
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Stefano Stabellini
Cc: Wei Liu
---
xen/include/xen/byteorder/big_endian.h| 102
xen/include/xen/byteorder/generic.h | 68
xen/include/xen/byteorder/little_endian.h | 102
xen/include/xen/byteorder/swab.h | 183 --
4 files changed, 455 deletions(-)
delete mode 100644 xen/include/xen/byteorder/big_endian.h
delete mode 100644 xen/include/xen/byteorder/generic.h
delete mode 100644 xen/include/xen/byteorder/little_endian.h
delete mode 100644 xen/include/xen/byteorder/swab.h
diff --git a/xen/include/xen/byteorder/big_endian.h
b/xen/include/xen/byteorder/big_endian.h
deleted file mode 100644
index 40eb80a390..00
--- a/xen/include/xen/byteorder/big_endian.h
+++ /dev/null
@@ -1,102 +0,0 @@
-#ifndef __XEN_BYTEORDER_BIG_ENDIAN_H__
-#define __XEN_BYTEORDER_BIG_ENDIAN_H__
-
-#ifndef __BIG_ENDIAN
-#define __BIG_ENDIAN 4321
-#endif
-#ifndef __BIG_ENDIAN_BITFIELD
-#define __BIG_ENDIAN_BITFIELD
-#endif
-
-#include
-#include
-
-#define __constant_cpu_to_le64(x) ((__force __le64)___constant_swab64((x)))
-#define __constant_le64_to_cpu(x) ___constant_swab64((__force
__u64)(__le64)(x))
-#define __constant_cpu_to_le32(x) ((__force __le32)___constant_swab32((x)))
-#define __constant_le32_to_cpu(x) ___constant_swab32((__force
__u32)(__le32)(x))
-#define __constant_cpu_to_le16(x) ((__force __le16)___constant_swab16((x)))
-#define __constant_le16_to_cpu(x) ___constant_swab16((__force
__u16)(__le16)(x))
-#define __constant_cpu_to_be64(x) ((__force __be64)(__u64)(x))
-#define __constant_be64_to_cpu(x) ((__force __u64)(__be64)(x))
-#define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x))
-#define __constant_be32_to_cpu(x) ((__force __u32)(__be32)(x))
-#define __constant_cpu_to_be16(x) ((__force __be16)(__u16)(x))
-#define __constant_be16_to_cpu(x) ((__force __u16)(__be16)(x))
-#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
-#define __le64_to_cpu(x) __swab64((__force __u64)(__le64)(x))
-#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
-#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
-#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
-#define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
-#define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
-#define __be64_to_cpu(x) ((__force __u64)(__be64)(x))
-#define __cpu_to_be32(x) ((__force __be32)(__u32)(x))
-#define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
-#define __cpu_to_be16(x) ((__force __be16)(__u16)(x))
-#define __be16_to_cpu(x) ((__force __u16)(__be16)(x))
-
-static inline __le64 __cpu_to_le64p(const __u64 *p)
-{
-return (__force __le64)__swab64p(p);
-}
-static inline __u64 __le64_to_cpup(const __le64 *p)
-{
-return __swab64p((__u64 *)p);
-}
-static inline __le32 __cpu_to_le32p(const __u32 *p)
-{
-return (__force __le32)__swab32p(p);
-}
-static inline __u32 __le32_to_cpup(const __le32 *p)
-{
-return __swab32p((__u32 *)p);
-}
-static inline __le16 __cpu_to_le16p(const __u16 *p)
-{
-return (__force __le16)__swab16p(p);
-}
-static inline __u16 __le16_to_cpup(const __le16 *p)
-{
-return __swab16p((__u16 *)p);
-}
-static inline __be64 __cpu_to_be64p(const __u64 *p)
-{
-return (__force __be64)*p;
-}
-static inline __u64 __be64_to_cpup(const __be64 *p)
-{
-return (__force __u64)*p;
-}
-static inline __be32 __cpu_to_be32p(const __u32 *p)
-{
-return (__force __be32)*p;
-}
-static inline __u32 __be32_to_cpup(const __be32 *p)
-{
-return (__force __u32)*p;
-}
-static inline __be16 __cpu_to_be16p(const __u16 *p)
-{
-return (__force __be16)*p;
-}
-static inline __u16 __be16_to_cpup(const __be16 *p)
-{
-return (__force __u16)*p;
-}
-#define __cpu_to_le64s(x) __swab64s((x))
-#define __le64_to_cpus(x) __swab64s((x))
-#define __cpu_to_le32s(x) __swab32s((x))
-#define __le32_to_cpus(x) __swab32s((x))
-#define __cpu_to_le16s(x) __swab16s((x))
-#define __le16_to_cpus(x) __swab16s((x))
-#define __cpu_to_be64s(x) do {} while (0)
-#define __be64_to_cpus(x) do {} while (0)
-#define __cpu_to_be32s(x) do {} while (0)
-#define __be32_to_cpus(x) do {} while (0)
-#define __cpu_to_be16s(x) do {} while (0)
-#define __be16_to_cpus(x) do {} while (0)
-
-#include
-
-#endif /* __XEN_BYTEORDER_BIG_ENDIAN_H__ */
diff --git a/xen/include/xen/byteorder/generic.h
b/xen/include/xen/byteorder/generic.h
deleted file mode 100644
index 8a0006b755..00
--- a/xen/include/xen/byteorder/generic.h
+++ /dev/null
@@ -1,68 +0,0 @@
-#ifndef __XEN_BYTEORDER_GENERIC_H__
-#define __XEN_BYTEORDER_GENERIC_H__
-
-/*
- * Generic Byte-reordering support
- *
- * The "... p" macros, like le64_to_cpup, can be used with pointers
- * to unaligned data, but there will be a performance penalty
[ovmf test] 170697: regressions - FAIL
flight 170697 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170697/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 83 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1185 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 73 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH 3/5] x86/perf: expose LBR format in PERF_CAPABILITIES
On Mon, May 23, 2022 at 10:12:55AM +0200, Jan Beulich wrote:
> On 20.05.2022 16:58, Andrew Cooper wrote:
> > On 20/05/2022 15:19, Jan Beulich wrote:
> >> On 20.05.2022 16:10, Andrew Cooper wrote:
> >>> On 20/05/2022 14:37, Roger Pau Monne wrote:
> --- a/xen/include/public/arch-x86/cpufeatureset.h
> +++ b/xen/include/public/arch-x86/cpufeatureset.h
> @@ -135,7 +135,7 @@ XEN_CPUFEATURE(SSSE3, 1*32+ 9) /*A
> Supplemental Streaming SIMD Extensio
> XEN_CPUFEATURE(FMA, 1*32+12) /*A Fused Multiply Add */
> XEN_CPUFEATURE(CX16, 1*32+13) /*A CMPXCHG16B */
> XEN_CPUFEATURE(XTPR, 1*32+14) /* Send Task Priority Messages
> */
> -XEN_CPUFEATURE(PDCM, 1*32+15) /* Perf/Debug Capability MSR */
> +XEN_CPUFEATURE(PDCM, 1*32+15) /*S Perf/Debug Capability MSR */
> >>> This is the bit which requires more toolstack logic to safely enable.
> >>> Using 's' for off-by-default is fine if we want to get the series in now.
> >>>
> >>> But before we expose the MSR generally, we need to:
> >>>
> >>> 1) Put the configuration in msr_policy so the toolstack can reason about
> >>> it
> >>> 2) Reject migration attempts to destinations where the LBR format changes
> >> Since this could be quite restrictive, and since people needing to know
> >> they need to hide this feature for migration to work, I guess this would
> >> further want qualifying by "did the guest actually use LBRs so far"?
> >
> > In practice, it's every major generation ("tock" on Intel's old model),
> > so isn't actually limiting the kinds of heterogeneous setups used in
> > production. (Migration gets steadily less stable the further apart the
> > two CPUs are.)
> >
> > As to dynamic, no - that would be a security bug in a cloud scenario,
> > because there must not be anything the guest can do to interfere with
> > the manageability.
> >
> > Use of LBR is rare, as demonstrated by the fact that noone has
> > complained about the fact that migrating such a VM will malfunction.
> >
> > As we now have a way of reporting "no model-specific LBR",
>
> Which only rather new guest kernels will know to look for. Hence ...
>
> > I'm tempted
> > to suggest that VMs get no LBR by default, and someone wanting LBR has
> > to opt in, which is also an explicit agreement to the migration limitation.
>
> ... while in principle I agree with this, I see a practical issue.
I think it should be fine to expose no model-specific LBR support in
PERF_CAPABILITIES, but we shouldn't change the behavior of
DEBUGCTLMSR.LBR exposed to guests if the underlying platform has
model-specific LBRs and those are known to Xen.
That way old guest kernels that ignore PERF_CAPABILITIES.LBR_FORMAT
will continue to work, while newish kernels that check the format will
avoid using LBRs.
In case we introduce a guest config option to enable LBR, should we
then expose the native LBR format in PERF_CAPABILITIES? Or would it
be better to just keep the current model and not expose
PERF_CAPABILITIES at all (and don't report PDCM in CPUID in that
case).
Thanks, Roger.
Re: [PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime
Hi,
On 23/05/2022 10:13, Michal Orzel wrote:
Introduce a command line parameter "maxcpus" on Arm to allow adjusting
the number of CPUs to activate.
The current definition "maxcpus" is not really suitable for big.LITTLE
systems as you have no flexibility to say how many types of each cores
you want to boot.
Instead, Xen will pick-up the first CPUs it parsed from the firmware tables.
So what's your use-case/target?
Currently the limit is defined by the
config option CONFIG_NR_CPUS. Such parameter already exists on x86.
Define a parameter "maxcpus" and a corresponding static variable
max_cpus in Arm smpboot.c. Modify function smp_get_max_cpus to take
max_cpus as a limit and to return proper unsigned int instead of int.
Take the opportunity to remove redundant variable cpus from start_xen
function and to directly assign the return value from smp_get_max_cpus
to nr_cpu_ids (global variable in Xen used to store the number of CPUs
actually activated).
Signed-off-by: Michal Orzel
---
max_cpus is also defined in x86 setup.c. It would be possible to join
these definitions in xen/common/cpu.c. However in that case, max_cpus
would become global which is not really what we want.
If we move the global variable, then I would also expect to move the
parsing parsing (i.e. smp_get_max_cpus()). So why would max_cpus end up
to be global? Is it because the x86 would continue to use it?
There is already
global nr_cpu_ids used everywhere and max_cpus being used only in x86
start_xen and Arm smp_get_max_cpus should be kept local. Also there are
already lots of places in Xen using max_cpus (local versions) and that
would start to be hard to read (variable shadowing).
We should avoid variable shadowing.
---
docs/misc/xen-command-line.pandoc | 2 +-
xen/arch/arm/include/asm/smp.h| 2 +-
xen/arch/arm/setup.c | 10 --
xen/arch/arm/smpboot.c| 18 --
4 files changed, 18 insertions(+), 14 deletions(-)
The patch looks ok to me (see one coding style comment below). I haven't
acked it because I am waiting to get more input on your use-cases.
[...]
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index 9bb32a301a..22fede6600 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -43,6 +43,10 @@ cpumask_t cpu_possible_map;
struct cpuinfo_arm cpu_data[NR_CPUS];
+/* maxcpus: maximum number of CPUs to activate. */
+static unsigned int __initdata max_cpus;
+integer_param("maxcpus", max_cpus);
+
/* CPU logical map: map xen cpuid to an MPIDR */
register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
@@ -277,16 +281,18 @@ void __init smp_init_cpus(void)
"unless the cpu affinity of all domains is specified.\n");
}
-int __init
-smp_get_max_cpus (void)
+unsigned int __init smp_get_max_cpus(void)
{
-int i, max_cpus = 0;
+unsigned int i, cpus = 0;
+
+if ( ( !max_cpus ) || ( max_cpus > nr_cpu_ids ) )
Coding style: We don't add space in the inner parentheses. I.e:
if ( (!max_cpus) || (max_cpus > nr_cpu_ids) )
+max_cpus = nr_cpu_ids;
-for ( i = 0; i < nr_cpu_ids; i++ )
+for ( i = 0; i < max_cpus; i++ )
if ( cpu_possible(i) )
-max_cpus++;
+cpus++;
-return max_cpus;
+return cpus;
}
void __init
--
Julien Grall
Re: [PATCH v4 1/6] xen: implement byteswap
On Mon, May 23, 2022 at 05:52:17AM -0400, Lin Liu wrote:
> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
> index 933aec09a9..ae029afa14 100644
> --- a/xen/include/xen/compiler.h
> +++ b/xen/include/xen/compiler.h
> @@ -185,4 +185,28 @@
> # define CLANG_DISABLE_WARN_GCC_COMPAT_END
> #endif
>
> +#ifndef __has_builtin
> +/*
> + * Backwards compatibility for GCC < 10.
> + * All supported versions of Clang support __has_builtin
> + * */
> +#define __has_builtin(x) GCC_has ## x
> +
> +#define GCC_has__builtin_bswap16 (CONFIG_GCC_VERSION >= 40800)
> +#define GCC_has__builtin_bswap32 (CONFIG_GCC_VERSION >= 40400)
> +#define GCC_has__builtin_bswap64 (CONFIG_GCC_VERSION >= 40400)
> +#endif
> +
> +#ifndef __ORDER_LITTLE_ENDIAN__
> +# define __ORDER_LITTLE_ENDIAN__ 1234
> +#endif
> +
> +#ifndef __ORDER_BIG_ENDIAN__
> +# define __ORDER_BIG_ENDIAN__ 4321
> +#endif
> +
> +/* Indirect macros required for expanded argument pasting. */
> +#define PASTE_(a, b) a ## b
> +#define PASTE(a, b) PASTE_(a, b)
I think it would be better if byteswap.h included lib.h, rather than
moving the PASTE define into compiler.h.
Likewise the __ORDER_{BIG,LITTLE}_ENDIAN__ defines would be better
placed in byteswap.h itself if possible IMO, since it's not strictly
related to the compiler.
Thanks, Roger.
Re: [PATCH v4 3/6] arm64/find_next_bit: Remove ext2_swab()
Hi, On 23/05/2022 10:52, Lin Liu wrote: ext2 has nothing to do with this logic. Clean up the code with xen/byteswap.h which now has an unsigned long helper. It looks like my comment in v3 wasn't addressed. This could possibly be done on commit if there are no other version. No functional change. Signed-off-by: Lin Liu You forgot to carry the tags from Andrew and I. Cheers, -- Julien Grall
Re: [PATCH v4 4/6] xen: Switch to byteswap
Hi, On 23/05/2022 10:52, Lin Liu wrote: Update to use byteswap to swap bytes. I am still objecting on switching from be*_to_cpup() to be*_to_cpu(). I will not Nack, however the strict minimum is to explain why you want to replace the helpers as I think the reason that was currently provided is incorrect. Cheers, -- Julien Grall
Re: [PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime
Hi Julien,
On 23.05.2022 12:05, Julien Grall wrote:
> Hi,
>
> On 23/05/2022 10:13, Michal Orzel wrote:
>> Introduce a command line parameter "maxcpus" on Arm to allow adjusting
>> the number of CPUs to activate.
>
> The current definition "maxcpus" is not really suitable for big.LITTLE
> systems as you have no flexibility to say how many types of each cores you
> want to boot.
>
> Instead, Xen will pick-up the first CPUs it parsed from the firmware tables.
>
>
> So what's your use-case/target?
>
- use cases where we have no big little (although even on big.LITTLE limiting
this number makes sense if we do not care about the types)
- debug cases where we want to set maxcpus=1
>> Currently the limit is defined by the
>> config option CONFIG_NR_CPUS. Such parameter already exists on x86.
>>
>> Define a parameter "maxcpus" and a corresponding static variable
>> max_cpus in Arm smpboot.c. Modify function smp_get_max_cpus to take
>> max_cpus as a limit and to return proper unsigned int instead of int.
>>
>> Take the opportunity to remove redundant variable cpus from start_xen
>> function and to directly assign the return value from smp_get_max_cpus
>> to nr_cpu_ids (global variable in Xen used to store the number of CPUs
>> actually activated).
>>
>> Signed-off-by: Michal Orzel
>> ---
>> max_cpus is also defined in x86 setup.c. It would be possible to join
>> these definitions in xen/common/cpu.c. However in that case, max_cpus
>> would become global which is not really what we want.
>
> If we move the global variable, then I would also expect to move the parsing
> parsing (i.e. smp_get_max_cpus()). So why would max_cpus end up to be global?
> Is it because the x86 would continue to use it?
>
Yes, that would involve more x86 modifications that actual Arm coding. That is
why I wanted to avoid it.
>> There is already
>> global nr_cpu_ids used everywhere and max_cpus being used only in x86
>> start_xen and Arm smp_get_max_cpus should be kept local. Also there are
>> already lots of places in Xen using max_cpus (local versions) and that
>> would start to be hard to read (variable shadowing).
>
> We should avoid variable shadowing.
>
>> ---
>> docs/misc/xen-command-line.pandoc | 2 +-
>> xen/arch/arm/include/asm/smp.h | 2 +-
>> xen/arch/arm/setup.c | 10 --
>> xen/arch/arm/smpboot.c | 18 --
>> 4 files changed, 18 insertions(+), 14 deletions(-)
>
> The patch looks ok to me (see one coding style comment below). I haven't
> acked it because I am waiting to get more input on your use-cases.
>
>
> [...]
>
>> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
>> index 9bb32a301a..22fede6600 100644
>> --- a/xen/arch/arm/smpboot.c
>> +++ b/xen/arch/arm/smpboot.c
>> @@ -43,6 +43,10 @@ cpumask_t cpu_possible_map;
>> struct cpuinfo_arm cpu_data[NR_CPUS];
>> +/* maxcpus: maximum number of CPUs to activate. */
>> +static unsigned int __initdata max_cpus;
>> +integer_param("maxcpus", max_cpus);
>> +
>> /* CPU logical map: map xen cpuid to an MPIDR */
>> register_t __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] =
>> MPIDR_INVALID };
>> @@ -277,16 +281,18 @@ void __init smp_init_cpus(void)
>> "unless the cpu affinity of all domains is
>> specified.\n");
>> }
>> -int __init
>> -smp_get_max_cpus (void)
>> +unsigned int __init smp_get_max_cpus(void)
>> {
>> - int i, max_cpus = 0;
>> + unsigned int i, cpus = 0;
>> +
>> + if ( ( !max_cpus ) || ( max_cpus > nr_cpu_ids ) )
>
> Coding style: We don't add space in the inner parentheses. I.e:
Noted, thanks.
>
> if ( (!max_cpus) || (max_cpus > nr_cpu_ids) )
>
>> + max_cpus = nr_cpu_ids;
>> - for ( i = 0; i < nr_cpu_ids; i++ )
>> + for ( i = 0; i < max_cpus; i++ )
>> if ( cpu_possible(i) )
>> - max_cpus++;
>> + cpus++;
>> - return max_cpus;
>> + return cpus;
>> }
>> void __init
>
Cheers,
Michal
Re: [OSSTEST PATCH v2] ts-xen-build-prep: Install newer NASM version, to build OVMF
On Fri, May 20, 2022 at 05:57:43PM +0100, Ian Jackson wrote:
> Anthony PERARD writes ("[OSSTEST PATCH v2] ts-xen-build-prep: Install newer
> NASM version, to build OVMF"):
> > Recent versions of OVMF now need a version of NASM that is newer
> > than the one available on Debian oldstable/buster. They want to use
> > NASM 2.15.05 [1], which is available in Debian stable/bullseye. The
> > need to use a newer version started with d3febfd9ade3 ("MdePkg:
> > Replace Opcode with the corresponding instructions.").
> >
> > There is no backport package available but the nasm package from
> > Debian Bullseye can easily be installed on Buster as it has few
> > dependencies and are already satisfied.
> >
> > [1]
> > https://github.com/tianocore/edk2/commit/6a890db161cd6d378bec3499a1e774db3f5a27a7
> > ("BaseTools: Upgrade the version of NASM tool")
>
> LGTM assuming Roger is also happy...
>
> Acked-by: Ian Jackson
Sure, I'm gonna push this now then.
Thanks both, Roger.
[xen-unstable test] 170687: trouble: broken/fail/pass
flight 170687 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/170687/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-qemuu-freebsd12-amd64 broken Tests which are failing intermittently (not blocking): test-amd64-amd64-qemuu-freebsd12-amd64 25 capture-logs(25) broken pass in 170657 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 debian-hvm-install fail in 170657 pass in 170687 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170657 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170657 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170657 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 170657 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 170657 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170657 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170657 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170657 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170657 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 170657 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 170657 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170657 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-i386-libvirt-raw 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass
[ovmf test] 170698: regressions - FAIL
flight 170698 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170698/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1186 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 74 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH v4 13/21] IOMMU/x86: prefill newly allocate page tables
On 23.05.2022 11:10, Roger Pau Monné wrote:
> On Mon, May 23, 2022 at 08:49:27AM +0200, Jan Beulich wrote:
>> On 20.05.2022 16:38, Roger Pau Monné wrote:
>>> On Fri, May 20, 2022 at 04:28:14PM +0200, Roger Pau Monné wrote:
On Fri, May 20, 2022 at 02:36:02PM +0200, Jan Beulich wrote:
> On 20.05.2022 14:22, Roger Pau Monné wrote:
>> On Fri, May 20, 2022 at 01:13:28PM +0200, Jan Beulich wrote:
>>> On 20.05.2022 13:11, Jan Beulich wrote:
On 20.05.2022 12:47, Roger Pau Monné wrote:
> On Thu, May 19, 2022 at 02:12:04PM +0200, Jan Beulich wrote:
>> On 06.05.2022 13:16, Roger Pau Monné wrote:
>>> On Mon, Apr 25, 2022 at 10:40:55AM +0200, Jan Beulich wrote:
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -115,7 +115,19 @@ static void set_iommu_ptes_present(unsig
while ( nr_ptes-- )
{
-set_iommu_pde_present(pde, next_mfn, 0, iw, ir);
+ASSERT(!pde->next_level);
+ASSERT(!pde->u);
+
+if ( pde > table )
+ASSERT(pde->ign0 == find_first_set_bit(pde - table));
+else
+ASSERT(pde->ign0 == PAGE_SHIFT - 3);
>>>
>>> I think PAGETABLE_ORDER would be clearer here.
>>
>> I disagree - PAGETABLE_ORDER is a CPU-side concept. It's not used
>> anywhere
>> in IOMMU code afaics.
>
> Isn't PAGE_SHIFT also a CPU-side concept in the same way? I'm not
> sure what's the rule for declaring that PAGE_SHIFT is fine to use in
> IOMMU code but not PAGETABLE_ORDER.
Hmm, yes and no. But for consistency with other IOMMU code I may want
to switch to PAGE_SHIFT_4K.
>>>
>>> Except that, with the plan to re-use pt_update_contig_markers() for CPU-
>>> side re-coalescing, there I'd prefer to stick to PAGE_SHIFT.
>>
>> Then can PAGETABLE_ORDER be used instead of PAGE_SHIFT - 3?
>
> pt_update_contig_markers() isn't IOMMU code; since I've said I'd switch
> to PAGE_SHIFT_4K in IOMMU code I'm having a hard time seeing how I could
> at the same time start using PAGETABLE_ORDER there.
I've got confused by the double reply and read it as if you where
going to stick to using PAGE_SHIFT everywhere as proposed originally.
> What I maybe could do is use PTE_PER_TABLE_SHIFT in AMD code and
> LEVEL_STRIDE in VT-d one. Yet I'm not sure that would be fully correct/
> consistent, ...
>
>> IMO it makes the code quite easier to understand.
>
> ... or in fact helping readability.
Looking at pt_update_contig_markers() we hardcode CONTIG_LEVEL_SHIFT
to 9 there, which means all users must have a page table order of 9.
It seems to me we are just making things more complicated than
necessary by trying to avoid dependencies between CPU and IOMMU
page-table sizes and definitions, when the underlying mechanism to set
->ign0 has those assumptions baked in.
Would it help if you introduced a PAGE_TABLE_ORDER in page-defs.h?
>>>
>>> Sorry, should be PAGE_TABLE_ORDER_4K.
>>
>> Oh, good that I looked here before replying to the earlier mail: I'm
>> afraid I view PAGE_TABLE_ORDER_4K as not very useful. From an
>> abstract POV, what is the base unit meant to be that the order is
>> is based upon? PAGE_SHIFT? Or PAGE_SHIFT_4K? I think such an
>> ambiguity is going to remain even if we very clearly spelled out what
>> we mean things to be, as one would always need to go back to that
>> comment to check which of the two possible ways it is.
>>
>> Furthermore I'm not convinced PAGETABLE_ORDER is really meant to be
>> associated with a particular page size anyway: PAGE_TABLE_ORDER_2M
>> imo makes no sense at all. And page-defs.h is not supposed to
>> express any platform properties anyway, it's merely an accumulation
>> of (believed) useful constants.
>>
>> Hence the only thing which I might see as a (remote) option is
>> IOMMU_PAGE_TABLE_ORDER (for platforms where all IOMMU variants have
>> all page table levels using identical sizes, which isn't a given, but
>> which would hold for x86 and hence for the purpose here).
>
> Since you already define a page table order in pt-contig-markers.h
> (CONTIG_NR) it might be possible to export and use that? In fact the
> check done here would be even more accurate if it was done using the
> same constant that's used in pt_update_contig_markers(), because the
> purpose here is to check that the vendor specific code to init the
> page tables has used the correct value.
Hmm, yes, let me do that. It'll be a little odd in the header itself
(as I'll need to exclude the bulk of it when CONTIG_MASK is not
defined), but apart from that it should indeed end up being better.
Re: [PATCH v4 1/6] xen: implement byteswap
On 23.05.2022 12:07, Roger Pau Monné wrote:
> On Mon, May 23, 2022 at 05:52:17AM -0400, Lin Liu wrote:
>> diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h
>> index 933aec09a9..ae029afa14 100644
>> --- a/xen/include/xen/compiler.h
>> +++ b/xen/include/xen/compiler.h
>> @@ -185,4 +185,28 @@
>> # define CLANG_DISABLE_WARN_GCC_COMPAT_END
>> #endif
>>
>> +#ifndef __has_builtin
>> +/*
>> + * Backwards compatibility for GCC < 10.
>> + * All supported versions of Clang support __has_builtin
>> + * */
>> +#define __has_builtin(x) GCC_has ## x
>> +
>> +#define GCC_has__builtin_bswap16 (CONFIG_GCC_VERSION >= 40800)
>> +#define GCC_has__builtin_bswap32 (CONFIG_GCC_VERSION >= 40400)
>> +#define GCC_has__builtin_bswap64 (CONFIG_GCC_VERSION >= 40400)
>> +#endif
>> +
>> +#ifndef __ORDER_LITTLE_ENDIAN__
>> +# define __ORDER_LITTLE_ENDIAN__ 1234
>> +#endif
>> +
>> +#ifndef __ORDER_BIG_ENDIAN__
>> +# define __ORDER_BIG_ENDIAN__ 4321
>> +#endif
>> +
>> +/* Indirect macros required for expanded argument pasting. */
>> +#define PASTE_(a, b) a ## b
>> +#define PASTE(a, b) PASTE_(a, b)
>
> I think it would be better if byteswap.h included lib.h, rather than
> moving the PASTE define into compiler.h.
+1
> Likewise the __ORDER_{BIG,LITTLE}_ENDIAN__ defines would be better
> placed in byteswap.h itself if possible IMO, since it's not strictly
> related to the compiler.
These need to live in per-arch headers, i.e. asm/byteorder.h.
Jan
Re: [PATCH v4 1/6] xen: implement byteswap
On 23.05.2022 13:00, Jan Beulich wrote:
> On 23.05.2022 12:07, Roger Pau Monné wrote:
>> Likewise the __ORDER_{BIG,LITTLE}_ENDIAN__ defines would be better
>> placed in byteswap.h itself if possible IMO, since it's not strictly
>> related to the compiler.
>
> These need to live in per-arch headers, i.e. asm/byteorder.h.
Or rather not. __BYTE_ORDER__ looks to come from the compiler, so
#define-ing respective constants in compiler.h would seem quite
reasonable to me.
Jan
Re: [PATCH v4 4/6] xen: Switch to byteswap
On 23.05.2022 12:12, Julien Grall wrote: > On 23/05/2022 10:52, Lin Liu wrote: >> Update to use byteswap to swap bytes. > > I am still objecting on switching from be*_to_cpup() to be*_to_cpu(). And I agree. Especially the cast to explicitly aligned types in get_unaligned_*() is rather unhelpful (and kind of a lie) imo. Jan > I will not Nack, however the strict minimum is to explain why you want > to replace the helpers as I think the reason that was currently provided > is incorrect. > > Cheers, >
Re: [PATCH v4 5/6] tools: Use new byteswap helper
On 23.05.2022 11:52, Lin Liu wrote:
> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
> return cpu_to_le32(*p);
> }
>
> +static inline u32 le32_to_cpu(u32 val)
> +{
> + return le32_to_cpup((const u32 *)&val);
> +}
Why the cast? And why not uint32_t?
Jan
[ovmf test] 170700: regressions - FAIL
flight 170700 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170700/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1187 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 75 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[ovmf test] 170701: regressions - FAIL
flight 170701 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170701/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1188 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 76 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[ovmf test] 170702: regressions - FAIL
flight 170702 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170702/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1189 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 77 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[ovmf test] 170703: regressions - FAIL
flight 170703 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170703/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1190 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 78 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH] x86/flushtlb: remove flush_area check on system state
On Wed, May 18, 2022 at 10:49:22AM +0200, Jan Beulich wrote:
> On 16.05.2022 16:31, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/include/asm/flushtlb.h
> > +++ b/xen/arch/x86/include/asm/flushtlb.h
> > @@ -146,7 +146,8 @@ void flush_area_mask(const cpumask_t *, const void *va,
> > unsigned int flags);
> > #define flush_mask(mask, flags) flush_area_mask(mask, NULL, flags)
> >
> > /* Flush all CPUs' TLBs/caches */
> > -#define flush_area_all(va, flags) flush_area_mask(&cpu_online_map, va,
> > flags)
> > +#define flush_area(va, flags) \
> > +flush_area_mask(&cpu_online_map, (const void *)(va), flags)
>
> I have to admit that I would prefer if we kept the "_all" name suffix,
> to continue to clearly express the scope of the flush. I'm also not
> really happy to see the cast being added globally now.
But there where no direct callers of flush_area_all(), so the name was
just relevant for it's use in flush_area(). With that now gone I
don't see a need for a flush_area_all(), as flush_area_mask() is more
appropriate.
> > --- a/xen/arch/x86/smp.c
> > +++ b/xen/arch/x86/smp.c
> > @@ -262,7 +262,8 @@ void flush_area_mask(const cpumask_t *mask, const void
> > *va, unsigned int flags)
> > {
> > unsigned int cpu = smp_processor_id();
> >
> > -ASSERT(local_irq_is_enabled());
> > +/* Local flushes can be performed with interrupts disabled. */
> > +ASSERT(local_irq_is_enabled() || cpumask_equal(mask, cpumask_of(cpu)));
>
> Further down we use cpumask_subset(mask, cpumask_of(cpu)),
> apparently to also cover the case where mask is empty. I think
> you want to do so here as well.
Hm, yes. I guess that's cheaper than adding an extra:
if ( cpumask_empty() )
return;
check at the start of the function.
> > if ( (flags & ~(FLUSH_VCPU_STATE | FLUSH_ORDER_MASK)) &&
> > cpumask_test_cpu(cpu, mask) )
>
> I suppose we want a further precaution here: Despite the
> !cpumask_subset(mask, cpumask_of(cpu)) below I think we want to
> extend what c64bf2d2a625 ("x86: make CPU state flush requests
> explicit") and later changes (isolating uses of FLUSH_VCPU_STATE
> from other FLUSH_*) did and exclude the use of FLUSH_VCPU_STATE
> for the local CPU altogether.
If we really want to exclude the use of FLUSH_VCPU_STATE for the local
CPU, we might wish to add this as a separate ASSERT, so that such
checking doesn't depend on !local_irq_is_enabled():
ASSERT(local_irq_is_enabled() || cpumask_subset(mask, cpumask_of(cpu));
ASSERT(!cpumask_subset(mask, cpumask_of(cpu)) || !(flags & FLUSH_VCPU_STATE));
> That's because if such somehow made
> it into the conditional below here, it would still involve an IPI.
Sorry, I'm confused by this: if the mask is empty there should be no
IPI involved at all? And we shouldn't even get into the second
conditional on the function.
Thanks, Roger.
[PATCH v5 5/6] tools: Use new byteswap helper
Include new header to use new byteswap helper
No functional change.
Signed-off-by: Lin Liu
---
Cc: Wei Liu
Cc: Anthony PERARD
Cc: Juergen Gross
---
tools/libs/guest/xg_dom_decompress_unsafe_xz.c | 5 +
tools/libs/guest/xg_dom_decompress_unsafe_zstd.c | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
index fc48198741..493427d517 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
@@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
return cpu_to_le32(*p);
}
+static inline u32 le32_to_cpu(u32 val)
+{
+ return le32_to_cpup((const u32 *)&val);
+}
+
#define __force
#define always_inline
diff --git a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
index 01eaf6..b06f2e767f 100644
--- a/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
+++ b/tools/libs/guest/xg_dom_decompress_unsafe_zstd.c
@@ -31,7 +31,8 @@ typedef uint64_t __be64;
#define __BYTEORDER_HAS_U64__
#define __TYPES_H__ /* xen/types.h guard */
-#include "../../xen/include/xen/byteorder/little_endian.h"
+#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#include "../../xen/include/xen/byteorder.h"
#define __ASM_UNALIGNED_H__ /* asm/unaligned.h guard */
#include "../../xen/include/xen/unaligned.h"
#include "../../xen/include/xen/xxhash.h"
--
2.27.0
[PATCH v5 6/6] byteorder: Remove byteorder
include/xen/byteswap.h has simplify the interface, just clean
the old interface
No functional change
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Stefano Stabellini
Cc: Wei Liu
---
xen/include/xen/byteorder/big_endian.h| 102
xen/include/xen/byteorder/generic.h | 68
xen/include/xen/byteorder/little_endian.h | 102
xen/include/xen/byteorder/swab.h | 183 --
4 files changed, 455 deletions(-)
delete mode 100644 xen/include/xen/byteorder/big_endian.h
delete mode 100644 xen/include/xen/byteorder/generic.h
delete mode 100644 xen/include/xen/byteorder/little_endian.h
delete mode 100644 xen/include/xen/byteorder/swab.h
diff --git a/xen/include/xen/byteorder/big_endian.h
b/xen/include/xen/byteorder/big_endian.h
deleted file mode 100644
index 40eb80a390..00
--- a/xen/include/xen/byteorder/big_endian.h
+++ /dev/null
@@ -1,102 +0,0 @@
-#ifndef __XEN_BYTEORDER_BIG_ENDIAN_H__
-#define __XEN_BYTEORDER_BIG_ENDIAN_H__
-
-#ifndef __BIG_ENDIAN
-#define __BIG_ENDIAN 4321
-#endif
-#ifndef __BIG_ENDIAN_BITFIELD
-#define __BIG_ENDIAN_BITFIELD
-#endif
-
-#include
-#include
-
-#define __constant_cpu_to_le64(x) ((__force __le64)___constant_swab64((x)))
-#define __constant_le64_to_cpu(x) ___constant_swab64((__force
__u64)(__le64)(x))
-#define __constant_cpu_to_le32(x) ((__force __le32)___constant_swab32((x)))
-#define __constant_le32_to_cpu(x) ___constant_swab32((__force
__u32)(__le32)(x))
-#define __constant_cpu_to_le16(x) ((__force __le16)___constant_swab16((x)))
-#define __constant_le16_to_cpu(x) ___constant_swab16((__force
__u16)(__le16)(x))
-#define __constant_cpu_to_be64(x) ((__force __be64)(__u64)(x))
-#define __constant_be64_to_cpu(x) ((__force __u64)(__be64)(x))
-#define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x))
-#define __constant_be32_to_cpu(x) ((__force __u32)(__be32)(x))
-#define __constant_cpu_to_be16(x) ((__force __be16)(__u16)(x))
-#define __constant_be16_to_cpu(x) ((__force __u16)(__be16)(x))
-#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
-#define __le64_to_cpu(x) __swab64((__force __u64)(__le64)(x))
-#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
-#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
-#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
-#define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
-#define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
-#define __be64_to_cpu(x) ((__force __u64)(__be64)(x))
-#define __cpu_to_be32(x) ((__force __be32)(__u32)(x))
-#define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
-#define __cpu_to_be16(x) ((__force __be16)(__u16)(x))
-#define __be16_to_cpu(x) ((__force __u16)(__be16)(x))
-
-static inline __le64 __cpu_to_le64p(const __u64 *p)
-{
-return (__force __le64)__swab64p(p);
-}
-static inline __u64 __le64_to_cpup(const __le64 *p)
-{
-return __swab64p((__u64 *)p);
-}
-static inline __le32 __cpu_to_le32p(const __u32 *p)
-{
-return (__force __le32)__swab32p(p);
-}
-static inline __u32 __le32_to_cpup(const __le32 *p)
-{
-return __swab32p((__u32 *)p);
-}
-static inline __le16 __cpu_to_le16p(const __u16 *p)
-{
-return (__force __le16)__swab16p(p);
-}
-static inline __u16 __le16_to_cpup(const __le16 *p)
-{
-return __swab16p((__u16 *)p);
-}
-static inline __be64 __cpu_to_be64p(const __u64 *p)
-{
-return (__force __be64)*p;
-}
-static inline __u64 __be64_to_cpup(const __be64 *p)
-{
-return (__force __u64)*p;
-}
-static inline __be32 __cpu_to_be32p(const __u32 *p)
-{
-return (__force __be32)*p;
-}
-static inline __u32 __be32_to_cpup(const __be32 *p)
-{
-return (__force __u32)*p;
-}
-static inline __be16 __cpu_to_be16p(const __u16 *p)
-{
-return (__force __be16)*p;
-}
-static inline __u16 __be16_to_cpup(const __be16 *p)
-{
-return (__force __u16)*p;
-}
-#define __cpu_to_le64s(x) __swab64s((x))
-#define __le64_to_cpus(x) __swab64s((x))
-#define __cpu_to_le32s(x) __swab32s((x))
-#define __le32_to_cpus(x) __swab32s((x))
-#define __cpu_to_le16s(x) __swab16s((x))
-#define __le16_to_cpus(x) __swab16s((x))
-#define __cpu_to_be64s(x) do {} while (0)
-#define __be64_to_cpus(x) do {} while (0)
-#define __cpu_to_be32s(x) do {} while (0)
-#define __be32_to_cpus(x) do {} while (0)
-#define __cpu_to_be16s(x) do {} while (0)
-#define __be16_to_cpus(x) do {} while (0)
-
-#include
-
-#endif /* __XEN_BYTEORDER_BIG_ENDIAN_H__ */
diff --git a/xen/include/xen/byteorder/generic.h
b/xen/include/xen/byteorder/generic.h
deleted file mode 100644
index 8a0006b755..00
--- a/xen/include/xen/byteorder/generic.h
+++ /dev/null
@@ -1,68 +0,0 @@
-#ifndef __XEN_BYTEORDER_GENERIC_H__
-#define __XEN_BYTEORDER_GENERIC_H__
-
-/*
- * Generic Byte-reordering support
- *
- * The "... p" macros, like le64_to_cpup, can be used with pointers
- * to unaligned data, but there will be a performance penalty
[PATCH v5 1/6] xen: implement byteswap
swab() is massively over complicated and can be simplified
by re-implementing using compiler builtins.
The compilers provide builtin function to swap bytes.
* gcc: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
* clang: https://clang.llvm.org/docs/LanguageExtensions.html
This patch introduces a new byteswapping infrastructure in
terms of compiler builtins and bswapXX(), so the swab() infrastructure
can be retired.
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Volodymyr Babchuk
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Wei Liu
Cc: "Roger Pau Monné"
Changes in v5:
- Move `PASTE` back to xen/lib.h
- Define `PASTE` for tools in xen-tools/libs.h
Changes in v4:
- Move `PASTE` definition to xen/compiler.h to support tools
- Revert emacs magics
Changes in v3:
- Check __has_builtin instead of GNUC version
Changes in v2:
- Add fallback for compilers without __builtin_bswap
- Implement with plain C instead of macros
---
tools/include/xen-tools/libs.h | 4 ++
xen/arch/arm/include/asm/byteorder.h | 6 ++-
xen/arch/x86/include/asm/byteorder.h | 34 ++---
xen/include/xen/byteorder.h | 56
xen/include/xen/byteswap.h | 44 ++
xen/include/xen/compiler.h | 20 ++
6 files changed, 132 insertions(+), 32 deletions(-)
create mode 100644 xen/include/xen/byteorder.h
create mode 100644 xen/include/xen/byteswap.h
diff --git a/tools/include/xen-tools/libs.h b/tools/include/xen-tools/libs.h
index a16e0c3807..fc12ac84c6 100644
--- a/tools/include/xen-tools/libs.h
+++ b/tools/include/xen-tools/libs.h
@@ -63,4 +63,8 @@
#define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
#endif
+/* Indirect macros required for expanded argument pasting. */
+#define PASTE_(a, b) a ## b
+#define PASTE(a, b) PASTE_(a, b)
+
#endif /* __XEN_TOOLS_LIBS__ */
diff --git a/xen/arch/arm/include/asm/byteorder.h
b/xen/arch/arm/include/asm/byteorder.h
index 9c712c4788..b6a33b23c0 100644
--- a/xen/arch/arm/include/asm/byteorder.h
+++ b/xen/arch/arm/include/asm/byteorder.h
@@ -1,9 +1,11 @@
#ifndef __ASM_ARM_BYTEORDER_H__
#define __ASM_ARM_BYTEORDER_H__
-#define __BYTEORDER_HAS_U64__
+#ifndef __BYTE_ORDER__
+ #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#endif
-#include
+#include
#endif /* __ASM_ARM_BYTEORDER_H__ */
/*
diff --git a/xen/arch/x86/include/asm/byteorder.h
b/xen/arch/x86/include/asm/byteorder.h
index 1f77e502a5..82aadee7bd 100644
--- a/xen/arch/x86/include/asm/byteorder.h
+++ b/xen/arch/x86/include/asm/byteorder.h
@@ -1,36 +1,10 @@
#ifndef __ASM_X86_BYTEORDER_H__
#define __ASM_X86_BYTEORDER_H__
-#include
-#include
+#ifndef __BYTE_ORDER__
+ #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
+#endif
-static inline __attribute_const__ __u32 ___arch__swab32(__u32 x)
-{
-asm("bswap %0" : "=r" (x) : "0" (x));
-return x;
-}
-
-static inline __attribute_const__ __u64 ___arch__swab64(__u64 val)
-{
-union {
-struct { __u32 a,b; } s;
-__u64 u;
-} v;
-v.u = val;
-asm("bswapl %0 ; bswapl %1 ; xchgl %0,%1"
-: "=r" (v.s.a), "=r" (v.s.b)
-: "0" (v.s.a), "1" (v.s.b));
-return v.u;
-}
-
-/* Do not define swab16. Gcc is smart enough to recognize "C" version and
- convert it into rotation or exhange. */
-
-#define __arch__swab64(x) ___arch__swab64(x)
-#define __arch__swab32(x) ___arch__swab32(x)
-
-#define __BYTEORDER_HAS_U64__
-
-#include
+#include
#endif /* __ASM_X86_BYTEORDER_H__ */
diff --git a/xen/include/xen/byteorder.h b/xen/include/xen/byteorder.h
new file mode 100644
index 00..2ec434e6a6
--- /dev/null
+++ b/xen/include/xen/byteorder.h
@@ -0,0 +1,56 @@
+#ifndef __XEN_BYTEORDER_H__
+#define __XEN_BYTEORDER_H__
+
+#include
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+
+# ifndef __LITTLE_ENDIAN
+# define __LITTLE_ENDIAN 1234
+# endif
+
+# ifndef __LITTLE_ENDIAN_BITFIELD
+# define __LITTLE_ENDIAN_BITFIELD
+# endif
+
+# define cpu_to_le64(x) (x)
+# define le64_to_cpu(x) (x)
+# define cpu_to_le32(x) (x)
+# define le32_to_cpu(x) (x)
+# define cpu_to_le16(x) (x)
+# define le16_to_cpu(x) (x)
+# define cpu_to_be64(x) bswap64(x)
+# define be64_to_cpu(x) bswap64(x)
+# define cpu_to_be32(x) bswap32(x)
+# define be32_to_cpu(x) bswap32(x)
+# define cpu_to_be16(x) bswap16(x)
+# define be16_to_cpu(x) bswap16(x)
+
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+
+# ifndef __BIG_ENDIAN
+# define __BIG_ENDIAN 4321
+# endif
+
+# ifndef __BIG_ENDIAN_BITFIELD
+# define __BIG_ENDIAN_BITFIELD
+# endif
+
+# define cpu_to_le64(x) bswap64(x)
+# define le64_to_cpu(x) bswap64(x)
+# define cpu_to_le32(x) bswap32(x)
+# define le32_to_cpu(x) bswap32(x)
+# define cpu_to_le16(x) bswap16(x)
+# define le16_to_cpu(x) bswap16(x)
+# define cpu_to_be64(x) (x)
+# define be64_to_cpu(x) (x)
+# define cpu_to_be32(x) (x)
+# define be32_to_cpu(x) (x)
[PATCH v5 2/6] crypto/vmac: Simplify code with byteswap
This file has its own implementation of swap bytes. Clean up
the code with xen/byteswap.h.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Stefano Stabellini
Cc: Wei Liu
xen/crypto/vmac.c | 76 ++-
1 file changed, 3 insertions(+), 73 deletions(-)
diff --git a/xen/crypto/vmac.c b/xen/crypto/vmac.c
index 294dd16a52..acb4e015f5 100644
--- a/xen/crypto/vmac.c
+++ b/xen/crypto/vmac.c
@@ -8,6 +8,7 @@
/* start for Xen */
#include
+#include
#include
#include
#include
@@ -50,7 +51,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /* Poly
key mask */
* MUL64: 64x64->128-bit multiplication
* PMUL64: assumes top bits cleared on inputs
* ADD128: 128x128->128-bit addition
- * GET_REVERSED_64: load and byte-reverse 64-bit word
* --- */
/* --- */
@@ -68,22 +68,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
#define PMUL64 MUL64
-#define GET_REVERSED_64(p)\
-({uint64_t x; \
- asm ("bswapq %0" : "=r" (x) : "0"(*(uint64_t *)(p))); x;})
-
-/* --- */
-#elif (__GNUC__ && __i386__)
-/* --- */
-
-#define GET_REVERSED_64(p)\
-({ uint64_t x;\
-uint32_t *tp = (uint32_t *)(p); \
-asm ("bswap %%edx\n\t" \
- "bswap %%eax" \
-: "=A"(x) \
-: "a"(tp[1]), "d"(tp[0]));\
-x; })
/* --- */
#elif (__GNUC__ && __ppc64__)
@@ -103,37 +87,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
#define PMUL64 MUL64
-#define GET_REVERSED_64(p)\
-({ uint32_t hi, lo, *_p = (uint32_t *)(p);\
- asm volatile ("lwbrx %0, %1, %2" : "=r"(lo) : "b%"(0), "r"(_p) ); \
- asm volatile ("lwbrx %0, %1, %2" : "=r"(hi) : "b%"(4), "r"(_p) ); \
- ((uint64_t)hi << 32) | (uint64_t)lo; } )
-
-/* --- */
-#elif (__GNUC__ && (__ppc__ || __PPC__))
-/* --- */
-
-#define GET_REVERSED_64(p)\
-({ uint32_t hi, lo, *_p = (uint32_t *)(p);\
- asm volatile ("lwbrx %0, %1, %2" : "=r"(lo) : "b%"(0), "r"(_p) ); \
- asm volatile ("lwbrx %0, %1, %2" : "=r"(hi) : "b%"(4), "r"(_p) ); \
- ((uint64_t)hi << 32) | (uint64_t)lo; } )
-
-/* --- */
-#elif (__GNUC__ && (__ARMEL__ || __ARM__))
-/* --- */
-
-#define bswap32(v)\
-({ uint32_t tmp,out; \
-asm volatile( \
-"eor%1, %2, %2, ror #16\n"\
-"bic%1, %1, #0x00ff\n"\
-"mov%0, %2, ror #8\n" \
-"eor%0, %0, %1, lsr #8" \
-: "=r" (out), "=&r" (tmp) \
-: "r" (v)); \
-out;})
-
/* --- */
#elif _MSC_VER
/* --- */
@@ -154,11 +107,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Poly key mask */
(rh) += (ih) + ((rl) < (_il)); \
}
-#if _MSC_VER >= 1300
-#define GET_REVERSED_64(p) _byteswap_uint64(*(uint64_t *)(p))
-#pragma intrinsic(_byteswap_uint64)
-#endif
-
#if _MSC_VER >= 1400 && \
(!defined(__INTEL_COMPILER) || __INTEL_COMPILER >= 1000)
#define MUL32(i1,i2)(__emulu((uint32_t)(i1),(uint32_t)(i2)))
@@ -219,24 +167,6 @@ const uint64_t mpoly = UINT64_C(0x1fff1fff); /*
Po
[PATCH v5 4/6] xen: Switch to byteswap
Update to use byteswap to swap bytes
be*_to_cpup(p) is short for be*to_cpu(*p), update to use latter
one explictly
No functional change.
Signed-off-by: Lin Liu
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Wei Liu
Changes in v5:
- Add git message to explain be*to_cpu helper
Changes in v4:
- Revert the __force in type casting
Changes in v3:
- Update xen/common/device_tree.c to use be32_to_cpu
- Keep const in type cast in unaligned.h
---
xen/common/device_tree.c | 44 +++---
xen/common/libelf/libelf-private.h | 6 ++--
xen/common/xz/private.h| 2 +-
xen/include/xen/unaligned.h| 12
4 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 4aae281e89..70d3be3be6 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -171,7 +171,7 @@ bool_t dt_property_read_u32(const struct dt_device_node *np,
if ( !val || len < sizeof(*out_value) )
return 0;
-*out_value = be32_to_cpup(val);
+*out_value = be32_to_cpu(*val);
return 1;
}
@@ -264,7 +264,7 @@ int dt_property_read_variable_u32_array(const struct
dt_device_node *np,
count = sz;
while ( count-- )
-*out_values++ = be32_to_cpup(val++);
+*out_values++ = be32_to_cpu(*val++);
return sz;
}
@@ -490,7 +490,7 @@ static int __dt_n_addr_cells(const struct dt_device_node
*np, bool_t parent)
ip = dt_get_property(np, "#address-cells", NULL);
if ( ip )
-return be32_to_cpup(ip);
+return be32_to_cpu(*ip);
} while ( np->parent );
/* No #address-cells property for the root node */
return DT_ROOT_NODE_ADDR_CELLS_DEFAULT;
@@ -507,7 +507,7 @@ int __dt_n_size_cells(const struct dt_device_node *np,
bool_t parent)
ip = dt_get_property(np, "#size-cells", NULL);
if ( ip )
-return be32_to_cpup(ip);
+return be32_to_cpu(*ip);
} while ( np->parent );
/* No #address-cells property for the root node */
return DT_ROOT_NODE_SIZE_CELLS_DEFAULT;
@@ -660,7 +660,7 @@ static void dt_bus_pci_count_cells(const struct
dt_device_node *np,
static unsigned int dt_bus_pci_get_flags(const __be32 *addr)
{
unsigned int flags = 0;
-u32 w = be32_to_cpup(addr);
+u32 w = be32_to_cpu(*addr);
switch((w >> 24) & 0x03) {
case 0x01:
@@ -1077,7 +1077,7 @@ dt_irq_find_parent(const struct dt_device_node *child)
if ( parp == NULL )
p = dt_get_parent(child);
else
-p = dt_find_node_by_phandle(be32_to_cpup(parp));
+p = dt_find_node_by_phandle(be32_to_cpu(*parp));
child = p;
} while ( p && dt_get_property(p, "#interrupt-cells", NULL) == NULL );
@@ -1110,7 +1110,7 @@ unsigned int dt_number_of_irq(const struct dt_device_node
*device)
intlen /= sizeof(*intspec);
dt_dprintk(" using 'interrupts' property\n");
-dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
+dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpu(*intspec), intlen);
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
@@ -1241,7 +1241,7 @@ int dt_for_each_irq_map(const struct dt_device_node *dev,
imaplen -= addrsize + intsize;
/* Get the interrupt parent */
-ipar = dt_find_node_by_phandle(be32_to_cpup(imap));
+ipar = dt_find_node_by_phandle(be32_to_cpu(*imap));
imap++;
--imaplen;
@@ -1358,8 +1358,8 @@ static int dt_irq_map_raw(const struct dt_device_node
*parent,
int match, i;
dt_dprintk("dt_irq_map_raw: par=%s,intspec=[0x%08x
0x%08x...],ointsize=%d\n",
- parent->full_name, be32_to_cpup(intspec),
- be32_to_cpup(intspec + 1), ointsize);
+ parent->full_name, be32_to_cpu(*intspec),
+ be32_to_cpu(*(intspec+1)), ointsize);
ipar = parent;
@@ -1471,7 +1471,7 @@ static int dt_irq_map_raw(const struct dt_device_node
*parent,
dt_dprintk(" -> match=%d (imaplen=%d)\n", match, imaplen);
/* Get the interrupt parent */
-newpar = dt_find_node_by_phandle(be32_to_cpup(imap));
+newpar = dt_find_node_by_phandle(be32_to_cpu(*imap));
imap++;
--imaplen;
@@ -1565,7 +1565,7 @@ int dt_device_get_raw_irq(const struct dt_device_node
*device,
intlen /= sizeof(*intspec);
dt_dprintk(" using 'interrupts' property\n");
-dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
+dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpu(*intspec), intlen);
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
@@ -1676,7 +1676,7 @@ static int __dt_parse_phandle_with_args(const struct
dt_device_node *np,
* If phandle is 0, then it is an empty entry with no
[PATCH v5 0/6] Implement byteswap and update references
Lin Liu (6): xen: implement byteswap crypto/vmac: Simplify code with byteswap arm64/find_next_bit: Remove ext2_swab() xen: Switch to byteswap tools: Use new byteswap helper byteorder: Remove byteorder .../libs/guest/xg_dom_decompress_unsafe_xz.c | 5 + .../guest/xg_dom_decompress_unsafe_zstd.c | 3 +- xen/arch/arm/arm64/lib/find_next_bit.c| 36 +--- xen/arch/arm/include/asm/byteorder.h | 6 +- xen/arch/x86/include/asm/byteorder.h | 34 +--- xen/common/device_tree.c | 44 ++--- xen/common/libelf/libelf-private.h| 6 +- xen/common/xz/private.h | 2 +- xen/crypto/vmac.c | 76 +--- xen/include/xen/byteorder.h | 56 ++ xen/include/xen/byteorder/big_endian.h| 102 -- xen/include/xen/byteorder/generic.h | 68 --- xen/include/xen/byteorder/little_endian.h | 102 -- xen/include/xen/byteorder/swab.h | 183 -- xen/include/xen/byteswap.h| 52 + xen/include/xen/compiler.h| 20 ++ xen/include/xen/unaligned.h | 12 +- 17 files changed, 184 insertions(+), 623 deletions(-) create mode 100644 xen/include/xen/byteorder.h delete mode 100644 xen/include/xen/byteorder/big_endian.h delete mode 100644 xen/include/xen/byteorder/generic.h delete mode 100644 xen/include/xen/byteorder/little_endian.h delete mode 100644 xen/include/xen/byteorder/swab.h create mode 100644 xen/include/xen/byteswap.h -- 2.27.0
Re: [PATCH v5 3/6] arm64/find_next_bit: Remove ext2_swab()
Hi, On 23/05/2022 15:50, Lin Liu wrote: ext2 has nothing to do with this logic. You have again not addressed my comment. If you don't understand my comment then please ask. Cheers, -- Julien Grall
Re: [PATCH v5 4/6] xen: Switch to byteswap
Hi, On 23/05/2022 15:50, Lin Liu wrote: Update to use byteswap to swap bytes be*_to_cpup(p) is short for be*to_cpu(*p), update to use latter one explictly But why? I really don't have a suggestion on the comment because I disagree (and AFAICT Jan as well) with the approach. In any case, I think it would be helpful if you participate in the discussion rather than sending a new version quickly. This would make sure you don't spend time on resending with unfinished discussion. Cheers, -- Julien Grall
Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list
On 19/05/2022 16:20, Scott Branden wrote: > [...] >> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter >> designed to run in x86 only or you have other architectures' use cases? > The adapter may be used in any PCIe design that supports DMA. > So it may be possible to run in arm64 servers. >> >> [...] >> With that said, and given this is a lightweight notifier that ideally >> should run ASAP, I'd keep this one in the hypervisor list. We can >> "adjust" the semantic of this list to include lightweight notifiers that >> reset adapters. > Sounds the best to keep system operating as tested today. >> >> With that said, Petr has a point - not always such list is going to be >> called before kdump. So, that makes me think in another idea: what if we >> have another list, but not on panic path, but instead in the custom >> crash_shutdown()? Drivers could add callbacks there that must execute >> before kexec/kdump, no matter what. > It may be beneficial for some other drivers but for our use we would > then need to register for the panic path and the crash_shutdown path. > We notify the VK card for 2 purposes: one to stop DMA so memory stop > changing during a kdump. And also to get the card into a good state so > resets happen cleanly. Thanks Scott! With that, I guess it's really better to keep this notifier in this hypervisor/early list - I'm planning to do that for V2. Unless Petr or somebody has strong feelings against that, of course. Cheers, Guilherme
[PATCH v5 3/6] arm64/find_next_bit: Remove ext2_swab()
ext2 has nothing to do with this logic. Clean up the code with
xen/byteswap.h which now has an unsigned long helper.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Julien Grall
Reviewed-by: Andrew Cooper
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Bertrand Marquis
Cc: Volodymyr Babchuk
---
xen/arch/arm/arm64/lib/find_next_bit.c | 36 +-
1 file changed, 6 insertions(+), 30 deletions(-)
diff --git a/xen/arch/arm/arm64/lib/find_next_bit.c
b/xen/arch/arm/arm64/lib/find_next_bit.c
index 8ebf8bfe97..e3b3720ff4 100644
--- a/xen/arch/arm/arm64/lib/find_next_bit.c
+++ b/xen/arch/arm/arm64/lib/find_next_bit.c
@@ -161,30 +161,6 @@ EXPORT_SYMBOL(find_first_zero_bit);
#ifdef __BIG_ENDIAN
-/* include/linux/byteorder does not support "unsigned long" type */
-static inline unsigned long ext2_swabp(const unsigned long * x)
-{
-#if BITS_PER_LONG == 64
- return (unsigned long) __swab64p((u64 *) x);
-#elif BITS_PER_LONG == 32
- return (unsigned long) __swab32p((u32 *) x);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
-
-/* include/linux/byteorder doesn't support "unsigned long" type */
-static inline unsigned long ext2_swab(const unsigned long y)
-{
-#if BITS_PER_LONG == 64
- return (unsigned long) __swab64((u64) y);
-#elif BITS_PER_LONG == 32
- return (unsigned long) __swab32((u32) y);
-#else
-#error BITS_PER_LONG not defined
-#endif
-}
-
#ifndef find_next_zero_bit_le
unsigned long find_next_zero_bit_le(const void *addr, unsigned
long size, unsigned long offset)
@@ -199,7 +175,7 @@ unsigned long find_next_zero_bit_le(const void *addr,
unsigned
size -= result;
offset &= (BITS_PER_LONG - 1UL);
if (offset) {
- tmp = ext2_swabp(p++);
+ tmp = bswap_ul(*p++);
tmp |= (~0UL >> (BITS_PER_LONG - offset));
if (size < BITS_PER_LONG)
goto found_first;
@@ -217,7 +193,7 @@ unsigned long find_next_zero_bit_le(const void *addr,
unsigned
}
if (!size)
return result;
- tmp = ext2_swabp(p);
+ tmp = bswap_ul(*p);
found_first:
tmp |= ~0UL << size;
if (tmp == ~0UL)/* Are any bits zero? */
@@ -226,7 +202,7 @@ found_middle:
return result + ffz(tmp);
found_middle_swap:
- return result + ffz(ext2_swab(tmp));
+ return result + ffz(bswap_ul(tmp));
}
EXPORT_SYMBOL(find_next_zero_bit_le);
#endif
@@ -245,7 +221,7 @@ unsigned long find_next_bit_le(const void *addr, unsigned
size -= result;
offset &= (BITS_PER_LONG - 1UL);
if (offset) {
- tmp = ext2_swabp(p++);
+ tmp = bswap_ul(*p++);
tmp &= (~0UL << offset);
if (size < BITS_PER_LONG)
goto found_first;
@@ -264,7 +240,7 @@ unsigned long find_next_bit_le(const void *addr, unsigned
}
if (!size)
return result;
- tmp = ext2_swabp(p);
+ tmp = bswap_ul(*p);
found_first:
tmp &= (~0UL >> (BITS_PER_LONG - size));
if (tmp == 0UL) /* Are any bits set? */
@@ -273,7 +249,7 @@ found_middle:
return result + __ffs(tmp);
found_middle_swap:
- return result + __ffs(ext2_swab(tmp));
+ return result + __ffs(bswap_ul(tmp));
}
EXPORT_SYMBOL(find_next_bit_le);
#endif
--
2.27.0
[ovmf test] 170704: regressions - FAIL
flight 170704 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170704/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1191 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 79 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH] x86/flushtlb: remove flush_area check on system state
On 23.05.2022 16:37, Roger Pau Monné wrote:
> On Wed, May 18, 2022 at 10:49:22AM +0200, Jan Beulich wrote:
>> On 16.05.2022 16:31, Roger Pau Monne wrote:
>>> --- a/xen/arch/x86/include/asm/flushtlb.h
>>> +++ b/xen/arch/x86/include/asm/flushtlb.h
>>> @@ -146,7 +146,8 @@ void flush_area_mask(const cpumask_t *, const void *va,
>>> unsigned int flags);
>>> #define flush_mask(mask, flags) flush_area_mask(mask, NULL, flags)
>>>
>>> /* Flush all CPUs' TLBs/caches */
>>> -#define flush_area_all(va, flags) flush_area_mask(&cpu_online_map, va,
>>> flags)
>>> +#define flush_area(va, flags) \
>>> +flush_area_mask(&cpu_online_map, (const void *)(va), flags)
>>
>> I have to admit that I would prefer if we kept the "_all" name suffix,
>> to continue to clearly express the scope of the flush. I'm also not
>> really happy to see the cast being added globally now.
>
> But there where no direct callers of flush_area_all(), so the name was
> just relevant for it's use in flush_area(). With that now gone I
> don't see a need for a flush_area_all(), as flush_area_mask() is more
> appropriate.
And flush_area_all() is shorthand for flush_area_mask(&cpu_online_map, ...).
That's more clearly distinguished from flush_area_local() than simply
flush_area(); the latter was okay-ish with its mm.c-only exposure, but imo
isn't anymore when put in a header.
>>> --- a/xen/arch/x86/smp.c
>>> +++ b/xen/arch/x86/smp.c
>>> @@ -262,7 +262,8 @@ void flush_area_mask(const cpumask_t *mask, const void
>>> *va, unsigned int flags)
>>> {
>>> unsigned int cpu = smp_processor_id();
>>>
>>> -ASSERT(local_irq_is_enabled());
>>> +/* Local flushes can be performed with interrupts disabled. */
>>> +ASSERT(local_irq_is_enabled() || cpumask_equal(mask, cpumask_of(cpu)));
>>
>> Further down we use cpumask_subset(mask, cpumask_of(cpu)),
>> apparently to also cover the case where mask is empty. I think
>> you want to do so here as well.
>
> Hm, yes. I guess that's cheaper than adding an extra:
>
> if ( cpumask_empty() )
> return;
>
> check at the start of the function.
>
>>> if ( (flags & ~(FLUSH_VCPU_STATE | FLUSH_ORDER_MASK)) &&
>>> cpumask_test_cpu(cpu, mask) )
>>
>> I suppose we want a further precaution here: Despite the
>> !cpumask_subset(mask, cpumask_of(cpu)) below I think we want to
>> extend what c64bf2d2a625 ("x86: make CPU state flush requests
>> explicit") and later changes (isolating uses of FLUSH_VCPU_STATE
>> from other FLUSH_*) did and exclude the use of FLUSH_VCPU_STATE
>> for the local CPU altogether.
>
> If we really want to exclude the use of FLUSH_VCPU_STATE for the local
> CPU, we might wish to add this as a separate ASSERT, so that such
> checking doesn't depend on !local_irq_is_enabled():
>
> ASSERT(local_irq_is_enabled() || cpumask_subset(mask, cpumask_of(cpu));
> ASSERT(!cpumask_subset(mask, cpumask_of(cpu)) || !(flags & FLUSH_VCPU_STATE));
>
>
>> That's because if such somehow made
>> it into the conditional below here, it would still involve an IPI.
>
> Sorry, I'm confused by this: if the mask is empty there should be no
> IPI involved at all? And we shouldn't even get into the second
> conditional on the function.
Should perhaps have made more explicit that "somehow" means a hypothetical
way, perhaps even as a result of some further breakage somewhere.
Jan
Re: [PATCH v5 4/6] xen: Switch to byteswap
On 23/05/2022 15:56, Julien Grall wrote: > Hi, > > On 23/05/2022 15:50, Lin Liu wrote: >> Update to use byteswap to swap bytes >> be*_to_cpup(p) is short for be*to_cpu(*p), update to use latter >> one explictly > > But why? Because deleting code obfuscation constructs *is* the point of the cleanup. > I really don't have a suggestion on the comment because I disagree > (and AFAICT Jan as well) with the approach. Dropping the obfuscation has uncovered pre-existing bugs in the hypervisor. The series stands on its own merit. While I can't help if you like it or not, it really does bring an improvement to code quality and legibility. If you have no technical objections, and no suggestions for how to do it differently while retaining the quality and legibility improvements, then "I don't like it" doesn't block it going in. I specifically do like this change, because it does improve the codebase. ~Andrew
Re: [PATCH v5 4/6] xen: Switch to byteswap
Hi Andrew, On 23/05/2022 16:38, Andrew Cooper wrote: On 23/05/2022 15:56, Julien Grall wrote: Hi, On 23/05/2022 15:50, Lin Liu wrote: Update to use byteswap to swap bytes be*_to_cpup(p) is short for be*to_cpu(*p), update to use latter one explictly But why? Because deleting code obfuscation constructs *is* the point of the cleanup. I really don't have a suggestion on the comment because I disagree (and AFAICT Jan as well) with the approach. Dropping the obfuscation has uncovered pre-existing bugs in the hypervisor. The series stands on its own merit. I am guessing you mean that we don't handle unaligned access? If so, yes I agree this helped with that. While I can't help if you like it or not, it really does bring an improvement to code quality and legibility. If you have no technical objections, and no suggestions for how to do it differently while retaining the quality and legibility improvements, then "I don't like it" doesn't block it going in. And you don't like the existing code :). I am willing to compromise, but for that I need to understand why the existing code is technically not correct. So far, all the arguments you provided in v3 was either a matter of taste or IMHO bogus. Your taste is nor better nor worse than mine. At which, we need someone else to break the tie. If I am not mistaken, Jan is also objecting on the proposal. At which point, we are 2 vs 1. So there are three choices here: 1) You find two others maintainers (including on Arm maintainer) to agree with you 2) You provide arguments that will sway one of us in your side 3) We keep be32_cpu*() (they are simple wrapper and I am willing to write the code). Cheers, -- Julien Grall
[ovmf test] 170706: regressions - FAIL
flight 170706 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170706/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1192 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 80 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
Re: [PATCH V2 5/7] dt-bindings: Add xen,dev-domid property description for xen-grant DMA ops
On 19.05.22 09:03, Oleksandr wrote:
Hello Stefano, all
On 19.05.22 04:06, Stefano Stabellini wrote:
Hello Stefano, all
On Thu, 19 May 2022, Oleksandr wrote:
On Wed, May 18, 2022 at 5:06 PM Oleksandr wrote:
On 18.05.22 17:32, Arnd Bergmann wrote:
On Sat, May 7, 2022 at 7:19 PM Oleksandr Tyshchenko
wrote:
This would mean having a device
node for the grant-table mechanism that can be referred to using the
'iommus'
phandle property, with the domid as an additional argument.
I assume, you are speaking about something like the following?
xen_dummy_iommu {
compatible = "xen,dummy-iommu";
#iommu-cells = <1>;
};
virtio@3000 {
compatible = "virtio,mmio";
reg = <0x3000 0x100>;
interrupts = <41>;
/* The device is located in Xen domain with ID 1 */
iommus = <&xen_dummy_iommu 1>;
};
Right, that's that's the idea,
thank you for the confirmation
except I would not call it a 'dummy'.
From the perspective of the DT, this behaves just like an IOMMU,
even if the exact mechanism is different from most hardware IOMMU
implementations.
well, agree
It does not quite fit the model that Linux currently uses for
iommus,
as that has an allocator for dma_addr_t space
yes (# 3/7 adds grant-table based allocator)
, but it would think it's
conceptually close enough that it makes sense for the binding.
Interesting idea. I am wondering, do we need an extra actions for
this
to work in Linux guest (dummy IOMMU driver, etc)?
It depends on how closely the guest implementation can be made to
resemble a normal iommu. If you do allocate dma_addr_t addresses,
it may actually be close enough that you can just turn the grant-table
code into a normal iommu driver and change nothing else.
Unfortunately, I failed to find a way how use grant references at the
iommu_ops level (I mean to fully pretend that we are an IOMMU
driver). I am
not too familiar with that, so what is written below might be wrong
or at
least not precise.
The normal IOMMU driver in Linux doesn’t allocate DMA addresses by
itself, it
just maps (IOVA-PA) what was requested to be mapped by the upper
layer. The
DMA address allocation is done by the upper layer (DMA-IOMMU which
is the glue
layer between DMA API and IOMMU API allocates IOVA for PA?). But,
all what we
need here is just to allocate our specific grant-table based DMA
addresses
(DMA address = grant reference + offset in the page), so let’s say
we need an
entity to take a physical address as parameter and return a DMA
address (what
actually commit #3/7 is doing), and that’s all. So working at the
dma_ops
layer we get exactly what we need, with the minimal changes to guest
infrastructure. In our case the Xen itself acts as an IOMMU.
Assuming that we want to reuse the IOMMU infrastructure somehow for
our needs.
I think, in that case we will likely need to introduce a new
specific IOVA
allocator (alongside with a generic one) to be hooked up by the
DMA-IOMMU
layer if we run on top of Xen. But, even having the specific IOVA
allocator to
return what we indeed need (DMA address = grant reference + offset
in the
page) we will still need the specific minimal required IOMMU driver
to be
present in the system anyway in order to track the mappings(?) and
do nothing
with them, returning a success (this specific IOMMU driver should
have all
mandatory callbacks implemented).
I completely agree, it would be really nice to reuse generic IOMMU
bindings
rather than introducing Xen specific property if what we are trying to
implement in current patch series fits in the usage of "iommus" in
Linux
more-less. But, if we will have to add more complexity/more
components to the
code for the sake of reusing device tree binding, this raises a
question
whether that’s worthwhile.
Or I really missed something?
I think Arnd was primarily suggesting to reuse the IOMMU Device Tree
bindings, not necessarily the IOMMU drivers framework in Linux (although
that would be an added bonus.)
I know from previous discussions with you that making the grant table
fit in the existing IOMMU drivers model is difficult, but just reusing
the Device Tree bindings seems feasible?
I started experimenting with that. As wrote in a separate email, I got
a deferred probe timeout,
after inserting required nodes into guest device tree, which seems to
be a consequence of the unavailability of IOMMU, I will continue to
investigate this question.
I have experimented with that. Yes, just reusing the Device Tree
bindings is technically feasible (and we are able to do this by only
touching grant-dma-ops.c), although deferred probe timeout still stands
(as there is no IOMMU driver being present actually).
[ 0.583771] virtio-mmio 200.virtio: deferred probe timeout,
ignoring dependency
[ 0.615556] virtio_blk virtio0: [vda] 4096000 512-byte logical blocks
(2.10 GB/1.95 GiB)
Below the working diff (on top of current series):
diff --git a/drivers
[ovmf test] 170708: regressions - FAIL
flight 170708 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170708/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1193 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 81 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[ovmf test] 170709: regressions - FAIL
flight 170709 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170709/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64 6 xen-buildfail REGR. vs. 168254 build-i3866 xen-buildfail REGR. vs. 168254 build-i386-xsm6 xen-buildfail REGR. vs. 168254 build-amd64-xsm 6 xen-buildfail REGR. vs. 168254 Tests which did not succeed, but are not blocking: build-amd64-libvirt 1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1194 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 82 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm fail build-i386-xsm fail build-amd64 fail build-i386 fail build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Not pushing. (No revision log; it would be 6968 lines long.)
[PATCH] xen/arm: setup: nr_banks should be unsigned int
From: Julien Grall
It is not possible to have a negative number of banks. So switch
to unsigned int.
The type change is also propagated to any users of nr_banks that
were using "int" (there are not that many).
Note that fdt_num_mem_rsv() can actually returns a negative value
in case of an error. So the return should be checked before assigning
the result to an unsigned variable.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain_build.c | 9 +
xen/arch/arm/efi/efi-dom0.c | 4 ++--
xen/arch/arm/include/asm/setup.h | 6 +++---
xen/arch/arm/setup.c | 17 +
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index aa41bdd0..6ecb6673a3cd 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -111,7 +111,8 @@ static bool __init insert_11_bank(struct domain *d,
struct page_info *pg,
unsigned int order)
{
-int res, i;
+unsigned int i;
+int res;
mfn_t smfn;
paddr_t start, size;
@@ -264,7 +265,7 @@ static void __init allocate_memory_11(struct domain *d,
const unsigned int min_order = get_order_from_bytes(MB(4));
struct page_info *pg;
unsigned int order = get_allocation_size(kinfo->unassigned_mem);
-int i;
+unsigned int i;
bool lowmem = true;
unsigned int lowmem_bitsize = min(32U, arch_get_dma_bitsize());
@@ -1022,8 +1023,8 @@ static int __init make_memory_node(const struct domain *d,
int addrcells, int sizecells,
struct meminfo *mem)
{
-int res, i;
-int reg_size = addrcells + sizecells;
+unsigned int i;
+int res, reg_size = addrcells + sizecells;
int nr_cells = 0;
/* Placeholder for memory@ + a 64-bit number + \0 */
char buf[24];
diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
index 494420eaa23e..aae0f979112a 100644
--- a/xen/arch/arm/efi/efi-dom0.c
+++ b/xen/arch/arm/efi/efi-dom0.c
@@ -34,14 +34,14 @@
/* Constant to indicate "Xen" in unicode u16 format */
static const CHAR16 xen_efi_fw_vendor[] = {0x0058, 0x0065, 0x006E, 0x};
-size_t __init estimate_efi_size(int mem_nr_banks)
+size_t __init estimate_efi_size(unsigned int mem_nr_banks)
{
size_t size;
size_t est_size = sizeof(EFI_SYSTEM_TABLE);
size_t ect_size = sizeof(EFI_CONFIGURATION_TABLE);
size_t emd_size = sizeof(EFI_MEMORY_DESCRIPTOR);
size_t fw_vendor_size = sizeof(xen_efi_fw_vendor);
-int acpi_mem_nr_banks = 0;
+unsigned int acpi_mem_nr_banks = 0;
if ( !acpi_disabled )
acpi_mem_nr_banks = bootinfo.acpi.nr_banks;
diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/setup.h
index 7a1e1d67989c..2bb01ecfa88f 100644
--- a/xen/arch/arm/include/asm/setup.h
+++ b/xen/arch/arm/include/asm/setup.h
@@ -30,7 +30,7 @@ struct membank {
};
struct meminfo {
-int nr_banks;
+unsigned int nr_banks;
struct membank bank[NR_MEM_BANKS];
};
@@ -93,7 +93,7 @@ extern domid_t max_init_domid;
void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
-size_t estimate_efi_size(int mem_nr_banks);
+size_t estimate_efi_size(unsigned int mem_nr_banks);
void acpi_create_efi_system_table(struct domain *d,
struct membank tbl_add[]);
@@ -109,7 +109,7 @@ void create_dom0(void);
void discard_initial_modules(void);
void fw_unreserved_regions(paddr_t s, paddr_t e,
- void (*cb)(paddr_t, paddr_t), int first);
+ void (*cb)(paddr_t, paddr_t), unsigned int first);
size_t boot_fdt_info(const void *fdt, paddr_t paddr);
const char *boot_fdt_cmdline(const void *fdt);
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index db1768c03f03..b30bccbaa7df 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -201,9 +201,17 @@ static void __init processor_id(void)
static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
void (*cb)(paddr_t, paddr_t),
- int first)
+ unsigned int first)
{
-int i, nr = fdt_num_mem_rsv(device_tree_flattened);
+unsigned int i, nr;
+int rc;
+
+rc = fdt_num_mem_rsv(device_tree_flattened);
+if ( rc < 0 )
+panic("Unable to retrieve the number of reserved regions (rc=%d)\n",
+ rc);
+
+nr = rc;
for ( i = first; i < nr ; i++ )
{
@@ -249,7 +257,8 @@ static void __init dt_unreserved_regions(paddr_t s, paddr_t
e,
}
void __init fw_unreserved_regions(paddr_t s, paddr_t e,
- void (*cb)(paddr_t, paddr_t), int first)
+ void (*cb)(paddr_t, paddr_t),
+ unsigned int first)
{
if ( acpi_d
[PATCH] xen/arm: Remove most of the *_VIRT_END defines
From: Julien Grall At the moment, *_VIRT_END may either point to the address after the end or the last address of the region. The lack of consistency make quite difficult to reason with them. Furthermore, there is a risk of overflow in the case where the address points past to the end. I am not aware of any cases, so this is only a latent bug. Start to solve the problem by removing all the *_VIRT_END exclusively used by the Arm code and add *_VIRT_SIZE when it is not present. Take the opportunity to rename BOOT_FDT_SLOT_SIZE to BOOT_FDT_VIRT_SIZE for better consistency and use _AT(vaddr_t, ). Signed-off-by: Julien Grall I noticed that a few functions in Xen expect [start, end[. This is risky as we may end up with end < start if the region is defined right at the top of the address space. I haven't yet tackle this issue. But I would at least like to get rid of *_VIRT_END. --- xen/arch/arm/include/asm/config.h | 18 -- xen/arch/arm/livepatch.c | 2 +- xen/arch/arm/mm.c | 13 - 3 files changed, 17 insertions(+), 16 deletions(-) diff --git a/xen/arch/arm/include/asm/config.h b/xen/arch/arm/include/asm/config.h index 3e2a55a91058..66db618b34e7 100644 --- a/xen/arch/arm/include/asm/config.h +++ b/xen/arch/arm/include/asm/config.h @@ -111,12 +111,11 @@ #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE) #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060) -#define BOOT_FDT_SLOT_SIZE MB(4) -#define BOOT_FDT_VIRT_END (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE) +#define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) #ifdef CONFIG_LIVEPATCH #define LIVEPATCH_VMAP_START _AT(vaddr_t,0x00a0) -#define LIVEPATCH_VMAP_END (LIVEPATCH_VMAP_START + MB(2)) +#define LIVEPATCH_VMAP_SIZE_AT(vaddr_t, MB(2)) #endif #define HYPERVISOR_VIRT_START XEN_VIRT_START @@ -132,18 +131,18 @@ #define FRAMETABLE_VIRT_END(FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - 1) #define VMAP_VIRT_START_AT(vaddr_t,0x1000) +#define VMAP_VIRT_SIZE _AT(vaddr_t, GB(1) - MB(256)) #define XENHEAP_VIRT_START _AT(vaddr_t,0x4000) -#define XENHEAP_VIRT_END _AT(vaddr_t,0x7fff) -#define DOMHEAP_VIRT_START _AT(vaddr_t,0x8000) -#define DOMHEAP_VIRT_END _AT(vaddr_t,0x) +#define XENHEAP_VIRT_SIZE _AT(vaddr_t, GB(1)) -#define VMAP_VIRT_ENDXENHEAP_VIRT_START +#define DOMHEAP_VIRT_START _AT(vaddr_t,0x8000) +#define DOMHEAP_VIRT_SIZE _AT(vaddr_t, GB(2)) #define DOMHEAP_ENTRIES1024 /* 1024 2MB mapping slots */ /* Number of domheap pagetable pages required at the second level (2MB mappings) */ -#define DOMHEAP_SECOND_PAGES ((DOMHEAP_VIRT_END - DOMHEAP_VIRT_START + 1) >> FIRST_SHIFT) +#define DOMHEAP_SECOND_PAGES (DOMHEAP_VIRT_SIZE >> FIRST_SHIFT) #else /* ARM_64 */ @@ -152,12 +151,11 @@ #define SLOT0_ENTRY_SIZE SLOT0(1) #define VMAP_VIRT_START GB(1) -#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1)) +#define VMAP_VIRT_SIZE GB(1) #define FRAMETABLE_VIRT_START GB(32) #define FRAMETABLE_SIZEGB(32) #define FRAMETABLE_NR (FRAMETABLE_SIZE / sizeof(*frame_table)) -#define FRAMETABLE_VIRT_END(FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - 1) #define DIRECTMAP_VIRT_START SLOT0(256) #define DIRECTMAP_SIZE (SLOT0_ENTRY_SIZE * (265-256)) diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c index 75e8adcfd6a1..57abc746e60b 100644 --- a/xen/arch/arm/livepatch.c +++ b/xen/arch/arm/livepatch.c @@ -175,7 +175,7 @@ void __init arch_livepatch_init(void) void *start, *end; start = (void *)LIVEPATCH_VMAP_START; -end = (void *)LIVEPATCH_VMAP_END; +end = start + LIVEPATCH_VMAP_SIZE; vm_init_type(VMAP_XEN, start, end); diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c index be37176a4725..0607c65f95cd 100644 --- a/xen/arch/arm/mm.c +++ b/xen/arch/arm/mm.c @@ -128,9 +128,11 @@ static DEFINE_PAGE_TABLE(xen_first); /* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32-bit) */ static DEFINE_PER_CPU(lpae_t *, xen_pgtable); #define THIS_CPU_PGTABLE this_cpu(xen_pgtable) -/* xen_dommap == pages used by map_domain_page, these pages contain +/* + * xen_dommap == pages used by map_domain_page, these pages contain * the second level pagetables which map the domheap region - * DOMHEAP_VIRT_START...DOMHEAP_VIRT_END in 2MB chunks. */ + * starting at DOMHEAP_VIRT_START in 2MB chunks. + */ static DEFINE_PER_CPU(lpae_t *, xen_dommap); /* Root of the trie for cpu0, other CPU's PTs are dynamically allocated */ static DEFINE_PAGE_TABLE(cpu0_pgtable); @@ -476,7 +478,7 @@ mfn_t domain_page_map_to_mfn(const void *ptr) int slot = (va - DOMHEAP_VIRT_START) >> SECOND_SHIFT; unsigned long offset = (va>>THIRD_SHIFT) & XEN_PT_LPAE_ENTRY_MASK; -if ( va >= VMAP_VIRT_START && va < VMAP_VIRT_END ) +if ( (va >= VMAP_VIRT_START) && ((VMAP_VIRT_START - va) < VMAP_VIRT
Re: [PATCH 13/16] xen/arm32: setup: Move out the code to populate the boot allocator
On 23/05/2022 08:28, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 20.05.2022 14:09, Julien Grall wrote:
From: Julien Grall
In a follow-up patch, we will want to populate the boot allocator
separately for arm64. The code will end up to be very similar to the one
on arm32. So move out the code in a new helper populate_boot_allocator().
For now the code is still protected by CONFIG_ARM_32 to avoid any build
failure on arm64.
Take the opportunity to replace mfn_add(xen_mfn_start, xenheap_pages) with
xenheap_mfn_end as they are equivalent.
Signed-off-by: Julien Grall
---
Changes in v4:
- Patch added
---
xen/arch/arm/setup.c | 90 +---
1 file changed, 51 insertions(+), 39 deletions(-)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index d5d0792ed48a..3d5a2283d4ef 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -637,10 +637,58 @@ static void __init init_staticmem_pages(void)
}
#ifdef CONFIG_ARM_32
+/*
+ * Populate the boot allocator. All the RAM but the following regions
+ * will be added:
+ * - Modules (e.g., Xen, Kernel)
+ * - Reserved regions
+ * - Xenheap
+ */
+static void __init populate_boot_allocator(void)
+{
+unsigned int i;
Shouldn't this be an int (as it was previously) because ...
+const struct meminfo *banks = &bootinfo.mem;
+
+for ( i = 0; i < banks->nr_banks; i++ )
... nr_banks is int ?
Hmmm... AFAIK banks->nr_banks never hold a negative value, so I am not
sure why it was introduced as an "int".
Looking through the code, we seem to have a mix of "unsigned int" and
"int". There seem to be less on the latter, so I have sent a patch to
switch nr_banks to "unsigned int" [1].
This is based on this series thought and I would like to keep the
"unsigned int" here.
Apart from that:
Reviewed-by: Michal Orzel
Thanks! Please let me know if this reviewed-by hold.
Cheers,
[1] https://lore.kernel.org/xen-devel/20220523194631.66262-1-jul...@xen.org
--
Julien Grall
Re: [PATCH] xen/arm: Allow setting the number of CPUs to activate at runtime
On 23/05/2022 11:21, Michal Orzel wrote: Hi Julien, Hi Michal, On 23.05.2022 12:05, Julien Grall wrote: Hi, On 23/05/2022 10:13, Michal Orzel wrote: Introduce a command line parameter "maxcpus" on Arm to allow adjusting the number of CPUs to activate. The current definition "maxcpus" is not really suitable for big.LITTLE systems as you have no flexibility to say how many types of each cores you want to boot. Instead, Xen will pick-up the first CPUs it parsed from the firmware tables. So what's your use-case/target? - use cases where we have no big little (although even on big.LITTLE limiting this number makes sense if we do not care about the types) This may make sense in debug build, but for prod I think you need some certainty how which CPUs you are going to use. So I would like a warning in the documentation "maxcpus" that in big.LITTLE system, there are no guarantee on which types will be used. This is technically a lie, but I don't want a user to start relying on how Xen will parse the DT. - debug cases where we want to set maxcpus=1 Thanks for the clarification. I would be happy to add my tag with a warning in the documentation. Cheers, -- Julien Grall
Re: [PATCH] xen/iommu: dt: Check the return value of xsm_deassign_dtdevice()
On 23/05/2022 08:00, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 22.05.2022 18:59, Julien Grall wrote:
From: Julien Grall
xsm_deasign_dtdevice() will indicate whether the caller is allowed
s/deasign/deassign/
Good spot! I will fix it on commit unless there are any objections.
to issue the operation. So the return value has to be checked.
Spotted by clang static analyzer.
Fixes: fe36483c ("xen/passthrough: Extend XEN_DOMCTL_*assign_device to support
DT device")
Signed-off-by: Julien Grall
Apart from that:
Reviewed-by: Michal Orzel
Thanks!
Cheers,
--
Julien Grall
[ovmf test] 170710: all pass - PUSHED
flight 170710 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/170710/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf a21a3438f795deecb24e1843c1636f95c485017c baseline version: ovmf b1b89f9009f2390652e0061bd7b24fc40732bc70 Last test of basis 168254 2022-02-28 10:41:46 Z 84 days Failing since168258 2022-03-01 01:55:31 Z 83 days 1195 attempts Testing same since 170593 2022-05-20 06:42:41 Z3 days 83 attempts People who touched revisions under test: Abdul Lateef Attar Abdul Lateef Attar via groups.io Abner Chang Akihiko Odaki Anthony PERARD Bandaru, Purna Chandra Rao Bo Chang Ke Bob Feng Chao Li Chao, Zhuoran Chen Lin Z Chen, Christine Chen, Lin Z Corvin Köhne Dandan Bi dann frazier Dun Tan duntan Feng, Bob C Gerd Hoffmann Gua Guo Guo Dong Guomin Jiang Hao A Wu Heng Luo Hua Ma Huang, Li-Xia Jagadeesh Ujja Jake Garver Jake Garver via groups.io Jason Jason Lou Jiewen Yao Ke, Bo-ChangX Ken Lautner Kenneth Lautner Kun Qin Kuo, Ted Laszlo Ersek Lean Sheng Tan Leif Lindholm Li, Yi1 Li, Zhihao Liming Gao Liu Liu Yun Liu Yun Y Liu, Zhiguang Lixia Huang Lou, Yun Ma, Hua Mara Sophie Grosch Mara Sophie Grosch via groups.io Matt DeVillier Michael D Kinney Michael Kubacki Michael Kubacki Min M Xu Min Xu Oliver Steffen Patrick Rudolph Peter Grehan Purna Chandra Rao Bandaru Ray Ni Rebecca Cran Rebecca Cran Sami Mujawar Sean Rhodes Sean Rhodes sean@starlabs.systems Sebastien Boeuf Sunny Wang Tan, Dun Ted Kuo Tom Lendacky Wenyi Xie wenyi,xie via groups.io Xiaolu.Jiang Xie, Yuanhao Yi Li yi1 li Yu Pu Yuanhao Xie Yuwei Chen Zhiguang Liu Zhihao Li Zhuoran Chao jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git b1b89f9009..a21a3438f7 a21a3438f795deecb24e1843c1636f95c485017c -> xen-tested-master
RE: [PATCH] xen/arm: setup: nr_banks should be unsigned int
Hi Julien,
> -Original Message-
> From: Xen-devel On Behalf Of
> Julien Grall
> Sent: 2022年5月24日 3:47
> To: xen-devel@lists.xenproject.org
> Cc: Michal Orzel ; Julien Grall ;
> Stefano Stabellini ; Julien Grall ;
> Bertrand Marquis ; Volodymyr Babchuk
>
> Subject: [PATCH] xen/arm: setup: nr_banks should be unsigned int
>
> From: Julien Grall
>
> It is not possible to have a negative number of banks. So switch
> to unsigned int.
>
> The type change is also propagated to any users of nr_banks that
> were using "int" (there are not that many).
>
> Note that fdt_num_mem_rsv() can actually returns a negative value
> in case of an error. So the return should be checked before assigning
> the result to an unsigned variable.
>
> Signed-off-by: Julien Grall
> ---
> xen/arch/arm/domain_build.c | 9 +
> xen/arch/arm/efi/efi-dom0.c | 4 ++--
> xen/arch/arm/include/asm/setup.h | 6 +++---
> xen/arch/arm/setup.c | 17 +
> 4 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index aa41bdd0..6ecb6673a3cd 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -111,7 +111,8 @@ static bool __init insert_11_bank(struct domain *d,
>struct page_info *pg,
>unsigned int order)
> {
> -int res, i;
> +unsigned int i;
> +int res;
> mfn_t smfn;
> paddr_t start, size;
>
> @@ -264,7 +265,7 @@ static void __init allocate_memory_11(struct domain *d,
> const unsigned int min_order = get_order_from_bytes(MB(4));
> struct page_info *pg;
> unsigned int order = get_allocation_size(kinfo->unassigned_mem);
> -int i;
> +unsigned int i;
>
> bool lowmem = true;
> unsigned int lowmem_bitsize = min(32U, arch_get_dma_bitsize());
> @@ -1022,8 +1023,8 @@ static int __init make_memory_node(const struct
> domain *d,
> int addrcells, int sizecells,
> struct meminfo *mem)
> {
> -int res, i;
> -int reg_size = addrcells + sizecells;
> +unsigned int i;
> +int res, reg_size = addrcells + sizecells;
> int nr_cells = 0;
> /* Placeholder for memory@ + a 64-bit number + \0 */
> char buf[24];
> diff --git a/xen/arch/arm/efi/efi-dom0.c b/xen/arch/arm/efi/efi-dom0.c
> index 494420eaa23e..aae0f979112a 100644
> --- a/xen/arch/arm/efi/efi-dom0.c
> +++ b/xen/arch/arm/efi/efi-dom0.c
> @@ -34,14 +34,14 @@
> /* Constant to indicate "Xen" in unicode u16 format */
> static const CHAR16 xen_efi_fw_vendor[] = {0x0058, 0x0065, 0x006E,
> 0x};
>
> -size_t __init estimate_efi_size(int mem_nr_banks)
> +size_t __init estimate_efi_size(unsigned int mem_nr_banks)
> {
> size_t size;
> size_t est_size = sizeof(EFI_SYSTEM_TABLE);
> size_t ect_size = sizeof(EFI_CONFIGURATION_TABLE);
> size_t emd_size = sizeof(EFI_MEMORY_DESCRIPTOR);
> size_t fw_vendor_size = sizeof(xen_efi_fw_vendor);
> -int acpi_mem_nr_banks = 0;
> +unsigned int acpi_mem_nr_banks = 0;
>
> if ( !acpi_disabled )
> acpi_mem_nr_banks = bootinfo.acpi.nr_banks;
> diff --git a/xen/arch/arm/include/asm/setup.h
> b/xen/arch/arm/include/asm/setup.h
> index 7a1e1d67989c..2bb01ecfa88f 100644
> --- a/xen/arch/arm/include/asm/setup.h
> +++ b/xen/arch/arm/include/asm/setup.h
> @@ -30,7 +30,7 @@ struct membank {
> };
>
> struct meminfo {
> -int nr_banks;
> +unsigned int nr_banks;
> struct membank bank[NR_MEM_BANKS];
> };
>
> @@ -93,7 +93,7 @@ extern domid_t max_init_domid;
>
> void copy_from_paddr(void *dst, paddr_t paddr, unsigned long len);
>
> -size_t estimate_efi_size(int mem_nr_banks);
> +size_t estimate_efi_size(unsigned int mem_nr_banks);
>
> void acpi_create_efi_system_table(struct domain *d,
>struct membank tbl_add[]);
> @@ -109,7 +109,7 @@ void create_dom0(void);
>
> void discard_initial_modules(void);
> void fw_unreserved_regions(paddr_t s, paddr_t e,
> - void (*cb)(paddr_t, paddr_t), int first);
> + void (*cb)(paddr_t, paddr_t), unsigned int
> first);
>
> size_t boot_fdt_info(const void *fdt, paddr_t paddr);
> const char *boot_fdt_cmdline(const void *fdt);
> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
> index db1768c03f03..b30bccbaa7df 100644
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -201,9 +201,17 @@ static void __init processor_id(void)
>
> static void __init dt_unreserved_regions(paddr_t s, paddr_t e,
> void (*cb)(paddr_t, paddr_t),
> - int first)
> + unsigned int first)
> {
> -int i, nr = fdt_num_mem_rsv(device_tree_flattened);
> +unsigned int i, nr;
> +int rc;
> +
> +rc = fdt_n
Re: [PATCH 10/16] xen/arm: add Persistent Map (PMAP) infrastructure
Hi Julien,
On 2022/5/20 20:09, Julien Grall wrote:
From: Wei Liu
The basic idea is like Persistent Kernel Map (PKMAP) in Linux. We
pre-populate all the relevant page tables before the system is fully
set up.
We will need it on Arm in order to rework the arm64 version of
xenheap_setup_mappings() as we may need to use pages allocated from
the boot allocator before they are effectively mapped.
This infrastructure is not lock-protected therefore can only be used
before smpboot. After smpboot, map_domain_page() has to be used.
This is based on the x86 version [1] that was originally implemented
by Wei Liu.
The PMAP infrastructure is implemented in common code with some
arch helpers to set/clear the page-table entries and convertion
between a fixmap slot to a virtual address...
As mfn_to_xen_entry() now needs to be exported, take the opportunity
to swich the parameter attr from unsigned to unsigned int.
[1]
Signed-off-by: Wei Liu
Signed-off-by: Hongyan Xia
[julien: Adapted for Arm]
Signed-off-by: Julien Grall
---
Changes in v4:
- Move xen_fixmap in fixmap.h and add a comment about its usage.
- Update comments
- Use DECLARE_BITMAP()
- Replace local_irq_{enable, disable} with an ASSERT() as there
should be no user of pmap() in interrupt context.
Changes in v3:
- s/BITS_PER_LONG/BITS_PER_BYTE/
- Move pmap to common code
Changes in v2:
- New patch
Cc: Jan Beulich
Cc: Wei Liu
Cc: Andrew Cooper
Cc: Roger Pau Monné
---
xen/arch/arm/Kconfig | 1 +
xen/arch/arm/include/asm/fixmap.h | 24 +++
xen/arch/arm/include/asm/lpae.h | 8
xen/arch/arm/include/asm/pmap.h | 32 ++
xen/arch/arm/mm.c | 7 +--
xen/common/Kconfig| 3 ++
xen/common/Makefile | 1 +
xen/common/pmap.c | 72 +++
xen/include/xen/pmap.h| 16 +++
9 files changed, 158 insertions(+), 6 deletions(-)
create mode 100644 xen/arch/arm/include/asm/pmap.h
create mode 100644 xen/common/pmap.c
create mode 100644 xen/include/xen/pmap.h
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index ecfa6822e4d3..a89a67802aa9 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -14,6 +14,7 @@ config ARM
select HAS_DEVICE_TREE
select HAS_PASSTHROUGH
select HAS_PDX
+ select HAS_PMAP
select IOMMU_FORCE_PT_SHARE
config ARCH_DEFCONFIG
diff --git a/xen/arch/arm/include/asm/fixmap.h
b/xen/arch/arm/include/asm/fixmap.h
index 1cee51e52ab9..365a2385a087 100644
--- a/xen/arch/arm/include/asm/fixmap.h
+++ b/xen/arch/arm/include/asm/fixmap.h
@@ -5,20 +5,44 @@
#define __ASM_FIXMAP_H
#include
+#include
/* Fixmap slots */
#define FIXMAP_CONSOLE 0 /* The primary UART */
#define FIXMAP_MISC 1 /* Ephemeral mappings of hardware */
#define FIXMAP_ACPI_BEGIN 2 /* Start mappings of ACPI tables */
#define FIXMAP_ACPI_END(FIXMAP_ACPI_BEGIN + NUM_FIXMAP_ACPI_PAGES - 1)
/* End mappings of ACPI tables */
+#define FIXMAP_PMAP_BEGIN (FIXMAP_ACPI_END + 1) /* Start of PMAP */
+#define FIXMAP_PMAP_END (FIXMAP_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of PMAP
*/
+
+#define FIXMAP_LAST FIXMAP_PMAP_END
+
+#define FIXADDR_START FIXMAP_ADDR(0)
+#define FIXADDR_TOP FIXMAP_ADDR(FIXMAP_LAST)
#ifndef __ASSEMBLY__
+/*
+ * Direct access to xen_fixmap[] should only happen when {set,
+ * clear}_fixmap() is unusable (e.g. where we would end up to
+ * recursively call the helpers).
+ */
+extern lpae_t xen_fixmap[XEN_PT_LPAE_ENTRIES];
+
/* Map a page in a fixmap entry */
extern void set_fixmap(unsigned map, mfn_t mfn, unsigned attributes);
/* Remove a mapping from a fixmap entry */
extern void clear_fixmap(unsigned map);
+#define fix_to_virt(slot) ((void *)FIXMAP_ADDR(slot))
+
+static inline unsigned int virt_to_fix(vaddr_t vaddr)
+{
+BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+
+return ((vaddr - FIXADDR_START) >> PAGE_SHIFT);
+}
+
#endif /* __ASSEMBLY__ */
#endif /* __ASM_FIXMAP_H */
diff --git a/xen/arch/arm/include/asm/lpae.h b/xen/arch/arm/include/asm/lpae.h
index aecb320dec45..fc19cbd84772 100644
--- a/xen/arch/arm/include/asm/lpae.h
+++ b/xen/arch/arm/include/asm/lpae.h
@@ -4,6 +4,7 @@
#ifndef __ASSEMBLY__
#include
+#include
/*
* WARNING! Unlike the x86 pagetable code, where l1 is the lowest level and
@@ -168,6 +169,13 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned
int level)
third_table_offset(addr)\
}
+/*
+ * Standard entry type that we'll use to build Xen's own pagetables.
+ * We put the same permissions at every level, because they're ignored
+ * by the walker in non-leaf entries.
+ */
+lpae_t mfn_to_xen_entry(mfn_t mfn, unsigned int attr);
+
#endif /* __ASSEMBLY__ */
/*
diff --git a/xen/arch/arm/include/asm/pmap.h b/xen/a
RE: [PATCH v5 6/6] byteorder: Remove byteorder
Hi Lin,
> -Original Message-
> From: Xen-devel On Behalf Of Lin
> Liu
> Sent: 2022年5月23日 22:51
> To: xen-devel@lists.xenproject.org
> Cc: Lin Liu ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Julien Grall ; Bertrand
> Marquis ; Stefano Stabellini
> ; Wei Liu
> Subject: [PATCH v5 6/6] byteorder: Remove byteorder
>
> include/xen/byteswap.h has simplify the interface, just clean
> the old interface
There is a typo. s/ simplify/simplified /.
Best wishes
Jiamei Xie
>
> No functional change
>
> Signed-off-by: Lin Liu
> Reviewed-by: Andrew Cooper
> ---
> Cc: Andrew Cooper
> Cc: George Dunlap
> Cc: Jan Beulich
> Cc: Julien Grall
> Cc: Bertrand Marquis
> Cc: Stefano Stabellini
> Cc: Wei Liu
> ---
> xen/include/xen/byteorder/big_endian.h| 102
> xen/include/xen/byteorder/generic.h | 68
> xen/include/xen/byteorder/little_endian.h | 102
> xen/include/xen/byteorder/swab.h | 183 --
> 4 files changed, 455 deletions(-)
> delete mode 100644 xen/include/xen/byteorder/big_endian.h
> delete mode 100644 xen/include/xen/byteorder/generic.h
> delete mode 100644 xen/include/xen/byteorder/little_endian.h
> delete mode 100644 xen/include/xen/byteorder/swab.h
>
> diff --git a/xen/include/xen/byteorder/big_endian.h
> b/xen/include/xen/byteorder/big_endian.h
> deleted file mode 100644
> index 40eb80a390..00
> --- a/xen/include/xen/byteorder/big_endian.h
> +++ /dev/null
> @@ -1,102 +0,0 @@
> -#ifndef __XEN_BYTEORDER_BIG_ENDIAN_H__
> -#define __XEN_BYTEORDER_BIG_ENDIAN_H__
> -
> -#ifndef __BIG_ENDIAN
> -#define __BIG_ENDIAN 4321
> -#endif
> -#ifndef __BIG_ENDIAN_BITFIELD
> -#define __BIG_ENDIAN_BITFIELD
> -#endif
> -
> -#include
> -#include
> -
> -#define __constant_cpu_to_le64(x) ((__force
> __le64)___constant_swab64((x)))
> -#define __constant_le64_to_cpu(x) ___constant_swab64((__force
> __u64)(__le64)(x))
> -#define __constant_cpu_to_le32(x) ((__force
> __le32)___constant_swab32((x)))
> -#define __constant_le32_to_cpu(x) ___constant_swab32((__force
> __u32)(__le32)(x))
> -#define __constant_cpu_to_le16(x) ((__force
> __le16)___constant_swab16((x)))
> -#define __constant_le16_to_cpu(x) ___constant_swab16((__force
> __u16)(__le16)(x))
> -#define __constant_cpu_to_be64(x) ((__force __be64)(__u64)(x))
> -#define __constant_be64_to_cpu(x) ((__force __u64)(__be64)(x))
> -#define __constant_cpu_to_be32(x) ((__force __be32)(__u32)(x))
> -#define __constant_be32_to_cpu(x) ((__force __u32)(__be32)(x))
> -#define __constant_cpu_to_be16(x) ((__force __be16)(__u16)(x))
> -#define __constant_be16_to_cpu(x) ((__force __u16)(__be16)(x))
> -#define __cpu_to_le64(x) ((__force __le64)__swab64((x)))
> -#define __le64_to_cpu(x) __swab64((__force __u64)(__le64)(x))
> -#define __cpu_to_le32(x) ((__force __le32)__swab32((x)))
> -#define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
> -#define __cpu_to_le16(x) ((__force __le16)__swab16((x)))
> -#define __le16_to_cpu(x) __swab16((__force __u16)(__le16)(x))
> -#define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
> -#define __be64_to_cpu(x) ((__force __u64)(__be64)(x))
> -#define __cpu_to_be32(x) ((__force __be32)(__u32)(x))
> -#define __be32_to_cpu(x) ((__force __u32)(__be32)(x))
> -#define __cpu_to_be16(x) ((__force __be16)(__u16)(x))
> -#define __be16_to_cpu(x) ((__force __u16)(__be16)(x))
> -
> -static inline __le64 __cpu_to_le64p(const __u64 *p)
> -{
> -return (__force __le64)__swab64p(p);
> -}
> -static inline __u64 __le64_to_cpup(const __le64 *p)
> -{
> -return __swab64p((__u64 *)p);
> -}
> -static inline __le32 __cpu_to_le32p(const __u32 *p)
> -{
> -return (__force __le32)__swab32p(p);
> -}
> -static inline __u32 __le32_to_cpup(const __le32 *p)
> -{
> -return __swab32p((__u32 *)p);
> -}
> -static inline __le16 __cpu_to_le16p(const __u16 *p)
> -{
> -return (__force __le16)__swab16p(p);
> -}
> -static inline __u16 __le16_to_cpup(const __le16 *p)
> -{
> -return __swab16p((__u16 *)p);
> -}
> -static inline __be64 __cpu_to_be64p(const __u64 *p)
> -{
> -return (__force __be64)*p;
> -}
> -static inline __u64 __be64_to_cpup(const __be64 *p)
> -{
> -return (__force __u64)*p;
> -}
> -static inline __be32 __cpu_to_be32p(const __u32 *p)
> -{
> -return (__force __be32)*p;
> -}
> -static inline __u32 __be32_to_cpup(const __be32 *p)
> -{
> -return (__force __u32)*p;
> -}
> -static inline __be16 __cpu_to_be16p(const __u16 *p)
> -{
> -return (__force __be16)*p;
> -}
> -static inline __u16 __be16_to_cpup(const __be16 *p)
> -{
> -return (__force __u16)*p;
> -}
> -#define __cpu_to_le64s(x) __swab64s((x))
> -#define __le64_to_cpus(x) __swab64s((x))
> -#define __cpu_to_le32s(x) __swab32s((x))
> -#define __le32_to_cpus(x) __swab32s((x))
> -#define __cpu_to_le16s(x) __swab16s((x))
> -#define __le16_to_cpus(x) __swab16s((x))
> -#define __cpu_to_be64s(x) do {} while (0)
> -#define __be64_to_cpus(x) do {} while (0)
> -#define __cpu_to_be32s(x) do {}
[linux-linus test] 170711: tolerable FAIL - PUSHED
flight 170711 linux-linus real [real] flight 170713 linux-linus real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/170711/ http://logs.test-lab.xenproject.org/osstest/logs/170713/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 170713-retest Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 170684 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 170684 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 170684 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 170684 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 170684 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 170684 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 170684 test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 170684 test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qcow2 14 migrate-support-checkfail never pass test-amd64-amd64-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-raw 14 migrate-support-checkfail never pass test-arm64-arm64-libvirt-raw 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 14 migrate-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: linux1e57930e9f4083ad5854ab6eadffe790a8167fb4 baseline version: linux4b0986a3613c92f4ec1bdc7f60ec66fea135991f Last test of basis 170684 2022-05-23 00:41:51 Z1 days Testing same since 170711 2022-05-23 19:39:57 Z0 days1 attempts People who touched revisions under test: Akira Yokosawa Alexander Aring Ammar Faizi Ard Biesheuvel Bagas Sanjaya Baskov Evgeniy Chunwei Lu David Vernet
RE: [PATCH] xen/arm: Remove most of the *_VIRT_END defines
(resend again, seems the first one is failed) > -Original Message- > From: Xen-devel On Behalf Of > Julien Grall > Sent: 2022年5月24日 3:50 > To: xen-devel@lists.xenproject.org > Cc: jul...@xen.org; Julien Grall ; Stefano Stabellini > ; Bertrand Marquis ; > Volodymyr Babchuk ; Konrad Rzeszutek Wilk > ; Ross Lagerwall > Subject: [PATCH] xen/arm: Remove most of the *_VIRT_END defines > > From: Julien Grall > > At the moment, *_VIRT_END may either point to the address after the end > or the last address of the region. > > The lack of consistency make quite difficult to reason with them. > > Furthermore, there is a risk of overflow in the case where the address > points past to the end. I am not aware of any cases, so this is only a > latent bug. > > Start to solve the problem by removing all the *_VIRT_END exclusively used > by the Arm code and add *_VIRT_SIZE when it is not present. > > Take the opportunity to rename BOOT_FDT_SLOT_SIZE to BOOT_FDT_VIRT_SIZE > for better consistency and use _AT(vaddr_t, ). > > Signed-off-by: Julien Grall > > > > I noticed that a few functions in Xen expect [start, end[. This is risky > as we may end up with end < start if the region is defined right at the > top of the address space. > > I haven't yet tackle this issue. But I would at least like to get rid > of *_VIRT_END. > --- > xen/arch/arm/include/asm/config.h | 18 -- > xen/arch/arm/livepatch.c | 2 +- > xen/arch/arm/mm.c | 13 - > 3 files changed, 17 insertions(+), 16 deletions(-) > > diff --git a/xen/arch/arm/include/asm/config.h > b/xen/arch/arm/include/asm/config.h > index 3e2a55a91058..66db618b34e7 100644 > --- a/xen/arch/arm/include/asm/config.h > +++ b/xen/arch/arm/include/asm/config.h > @@ -111,12 +111,11 @@ > #define FIXMAP_ADDR(n)(_AT(vaddr_t,0x0040) + (n) * PAGE_SIZE) > > #define BOOT_FDT_VIRT_START_AT(vaddr_t,0x0060) > -#define BOOT_FDT_SLOT_SIZE MB(4) > -#define BOOT_FDT_VIRT_END (BOOT_FDT_VIRT_START + BOOT_FDT_SLOT_SIZE) > +#define BOOT_FDT_VIRT_SIZE _AT(vaddr_t, MB(4)) > > #ifdef CONFIG_LIVEPATCH > #define LIVEPATCH_VMAP_START _AT(vaddr_t,0x00a0) > -#define LIVEPATCH_VMAP_END (LIVEPATCH_VMAP_START + MB(2)) > +#define LIVEPATCH_VMAP_SIZE_AT(vaddr_t, MB(2)) > #endif > > #define HYPERVISOR_VIRT_START XEN_VIRT_START > @@ -132,18 +131,18 @@ > #define FRAMETABLE_VIRT_END(FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - > 1) > > #define VMAP_VIRT_START_AT(vaddr_t,0x1000) > +#define VMAP_VIRT_SIZE _AT(vaddr_t, GB(1) - MB(256)) > > #define XENHEAP_VIRT_START _AT(vaddr_t,0x4000) > -#define XENHEAP_VIRT_END _AT(vaddr_t,0x7fff) > -#define DOMHEAP_VIRT_START _AT(vaddr_t,0x8000) > -#define DOMHEAP_VIRT_END _AT(vaddr_t,0x) > +#define XENHEAP_VIRT_SIZE _AT(vaddr_t, GB(1)) > > -#define VMAP_VIRT_ENDXENHEAP_VIRT_START > +#define DOMHEAP_VIRT_START _AT(vaddr_t,0x8000) > +#define DOMHEAP_VIRT_SIZE _AT(vaddr_t, GB(2)) > > #define DOMHEAP_ENTRIES1024 /* 1024 2MB mapping slots */ > > /* Number of domheap pagetable pages required at the second level (2MB > mappings) */ > -#define DOMHEAP_SECOND_PAGES ((DOMHEAP_VIRT_END - DOMHEAP_VIRT_START + > 1) >> FIRST_SHIFT) > +#define DOMHEAP_SECOND_PAGES (DOMHEAP_VIRT_SIZE >> FIRST_SHIFT) > > #else /* ARM_64 */ > > @@ -152,12 +151,11 @@ > #define SLOT0_ENTRY_SIZE SLOT0(1) > > #define VMAP_VIRT_START GB(1) > -#define VMAP_VIRT_END(VMAP_VIRT_START + GB(1)) > +#define VMAP_VIRT_SIZE GB(1) > > #define FRAMETABLE_VIRT_START GB(32) > #define FRAMETABLE_SIZEGB(32) > #define FRAMETABLE_NR (FRAMETABLE_SIZE / sizeof(*frame_table)) > -#define FRAMETABLE_VIRT_END(FRAMETABLE_VIRT_START + FRAMETABLE_SIZE - > 1) > > #define DIRECTMAP_VIRT_START SLOT0(256) > #define DIRECTMAP_SIZE (SLOT0_ENTRY_SIZE * (265-256)) > diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c > index 75e8adcfd6a1..57abc746e60b 100644 > --- a/xen/arch/arm/livepatch.c > +++ b/xen/arch/arm/livepatch.c > @@ -175,7 +175,7 @@ void __init arch_livepatch_init(void) > void *start, *end; > > start = (void *)LIVEPATCH_VMAP_START; > -end = (void *)LIVEPATCH_VMAP_END; > +end = start + LIVEPATCH_VMAP_SIZE; > > vm_init_type(VMAP_XEN, start, end); > > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c > index be37176a4725..0607c65f95cd 100644 > --- a/xen/arch/arm/mm.c > +++ b/xen/arch/arm/mm.c > @@ -128,9 +128,11 @@ static DEFINE_PAGE_TABLE(xen_first); > /* xen_pgtable == root of the trie (zeroeth level on 64-bit, first on 32- > bit) */ > static DEFINE_PER_CPU(lpae_t *, xen_pgtable); > #define THIS_CPU_PGTABLE this_cpu(xen_pgtable) > -/* xen_dommap == pages used by map_domain_page, these pages contain > +/* > + * xen_dommap == pages used by map_domain_page, these pages contain > * the second level pagetables which map the d
Re: [GIT PULL] xen: branch for v5.19-rc1
The pull request you sent on Mon, 23 May 2022 07:31:04 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > for-linus-5.19-rc1-tag has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d61306047533eb6f63a7bd51dfa7f868503bf0ba Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH 13/16] xen/arm32: setup: Move out the code to populate the boot allocator
On 23.05.2022 21:51, Julien Grall wrote:
>
>
> On 23/05/2022 08:28, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>>
>> On 20.05.2022 14:09, Julien Grall wrote:
>>> From: Julien Grall
>>>
>>> In a follow-up patch, we will want to populate the boot allocator
>>> separately for arm64. The code will end up to be very similar to the one
>>> on arm32. So move out the code in a new helper populate_boot_allocator().
>>>
>>> For now the code is still protected by CONFIG_ARM_32 to avoid any build
>>> failure on arm64.
>>>
>>> Take the opportunity to replace mfn_add(xen_mfn_start, xenheap_pages) with
>>> xenheap_mfn_end as they are equivalent.
>>>
>>> Signed-off-by: Julien Grall
>>>
>>> ---
>>>
>>> Changes in v4:
>>> - Patch added
>>> ---
>>> xen/arch/arm/setup.c | 90 +---
>>> 1 file changed, 51 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
>>> index d5d0792ed48a..3d5a2283d4ef 100644
>>> --- a/xen/arch/arm/setup.c
>>> +++ b/xen/arch/arm/setup.c
>>> @@ -637,10 +637,58 @@ static void __init init_staticmem_pages(void)
>>> }
>>> #ifdef CONFIG_ARM_32
>>> +/*
>>> + * Populate the boot allocator. All the RAM but the following regions
>>> + * will be added:
>>> + * - Modules (e.g., Xen, Kernel)
>>> + * - Reserved regions
>>> + * - Xenheap
>>> + */
>>> +static void __init populate_boot_allocator(void)
>>> +{
>>> + unsigned int i;
>> Shouldn't this be an int (as it was previously) because ...
>>> + const struct meminfo *banks = &bootinfo.mem;
>>> +
>>> + for ( i = 0; i < banks->nr_banks; i++ )
>> ... nr_banks is int ?
>
> Hmmm... AFAIK banks->nr_banks never hold a negative value, so I am not sure
> why it was introduced as an "int".
>
> Looking through the code, we seem to have a mix of "unsigned int" and "int".
> There seem to be less on the latter, so I have sent a patch to switch
> nr_banks to "unsigned int" [1].
That's great, thanks.
>
> This is based on this series thought and I would like to keep the "unsigned
> int" here.
>
>>
>> Apart from that:
>> Reviewed-by: Michal Orzel
>
> Thanks! Please let me know if this reviewed-by hold.
Definitely yes.
>
> Cheers,
>
> [1] https://lore.kernel.org/xen-devel/20220523194631.66262-1-jul...@xen.org
>
Cheers,
Michal
