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 ("
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 ex
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_E
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-i386
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:
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().
>
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-i386
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/cpu
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
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-i386
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:
>
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.
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
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-i386
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 inserti
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.
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 introd
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: Stefan
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
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
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
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-i386
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/cpufeaturese
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
yo
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_COMPA
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
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
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
> system
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. Th
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 whic
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-i386
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 2
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
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
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 (
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)
> +{
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-i386
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-i386
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-i386
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-i386
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 fl
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 inserti
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
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 introd
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: Stefan
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
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
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
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 t
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 arm6
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
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-i386
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 cp
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
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 obfuscati
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-i386
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 Oleksa
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-i386
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-i386
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
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
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 th
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"
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 is
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 b1b89f9009f2390652e00
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:
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
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
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-
(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 Rzeszut
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
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 c
72 matches
Mail list logo
