On 28/08/2024 01:45, Andrew Cooper wrote:
>
>
> for_each_set_bit() allocates its own variable intentionally as loop-scope
> only. Unfortunately, this causes the inner 'i' to shadow the outer 'i'.
NIT: I'd mention it violates MISRA R5.3
>
> Drop the outermost 'i' and 'vcpuid' variables, movi
On Tue, Aug 27, 2024 at 4:50 PM Jan Beulich wrote:
>
> On 27.08.2024 15:56, Frediano Ziglio wrote:
> > On Mon, Aug 26, 2024 at 9:21 AM Jan Beulich wrote:
> >>
> >> On 22.08.2024 17:29, Frediano Ziglio wrote:
> >>> The trampoline could have "manual" relocation entries (created
> >>> by assembly ma
On 27.08.2024 15:57, Andrew Cooper wrote:
> In the HPET_STATUS handling, the use of __clear_bit(i, &new_val) is the only
> thing causing it to be spilled to the stack. Furthemore we only care about
> the bottom 3 bits, so rewrite it to be a plain for loop.
>
> For the {start,stop}_timer variables
For partial writes the non-written parts of registers are folded into
the full 64-bit value from what they're presently set to. That's wrong
to do though when the behavior is write-1-to-clear: Writes not
including to low 3 bits would unconditionally clear all ISR bits which
are presently set. Re-ca
On 27.08.2024 15:57, Andrew Cooper wrote:
> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
> the CPU and dirties it even if there's nothing outstanding, but the final
> for_each_set_bit() is O(256) when O(8) would do,
Nit: That's bitmap_for_each() now, I think. And ag
Add virt_addr macro to make more clear the address we want and making
symbol search easier.
We don't generate direct absolute symbols to virtual addresses to avoid
linker warnings.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/boot/trampoline.S | 3 ++-
xen/arch/x86/boot/wakeup.S | 2 +-
x
The trampoline could have "manual" relocation entries (created
by assembly macros and some code to use them) and (in case of PE)
normal executable relocations.
Remove some normal executable ones. In this way we don't have to
worry about applying both correctly (they need proper order
which is hard
On Tue, 2024-08-27 at 12:06 +0200, Jan Beulich wrote:
> On 21.08.2024 18:06, Oleksii Kurochko wrote:
> > In Xen, memory-ordered atomic operations are not necessary,
>
> This is an interesting statement.
I looked at the definition of build_atomic_{write,read}() for other
architectures and didn't fi
On 28.08.2024 11:21, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-27 at 12:06 +0200, Jan Beulich wrote:
>> On 21.08.2024 18:06, Oleksii Kurochko wrote:
>>> In Xen, memory-ordered atomic operations are not necessary,
>>
>> This is an interesting statement.
> I looked at the definition of buil
flight 187378 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187378/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 99e4c8ea93fa0e98bc1bdb968e9d5bb42ff5d39c
baseline version:
ovmf 25da777d95c0e76b3e0a1
On 28/08/2024 8:06 am, Michal Orzel wrote:
>
> On 28/08/2024 01:45, Andrew Cooper wrote:
>>
>> for_each_set_bit() allocates its own variable intentionally as loop-scope
>> only. Unfortunately, this causes the inner 'i' to shadow the outer 'i'.
> NIT: I'd mention it violates MISRA R5.3
Done.
>
>>
On 27.08.2024 14:39, Roger Pau Monne wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++ b/xen/arch/x86/dom0_build.c
> @@ -612,7 +612,24 @@ int __init construct_dom0(struct domain *d, const
> module_t *image,
> if ( is_hvm_domain(d) )
> rc = dom0_construct_pvh(d, image, image_headroom, in
On Tue, 2024-08-27 at 12:29 +0200, Jan Beulich wrote:
> >
> > +
> > +/*
> > + * 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 pte_t xen_fixmap[];
>
> I'm af
On 28/08/2024 10:49 am, Jan Beulich wrote:
> On 27.08.2024 14:39, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/dom0_build.c
>> +++ b/xen/arch/x86/dom0_build.c
>> @@ -612,7 +612,24 @@ int __init construct_dom0(struct domain *d, const
>> module_t *image,
>> if ( is_hvm_domain(d) )
>> r
On 27.08.2024 05:59, Stewart Hildebrand wrote:
> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
> and changed from pcidevs_lock() to read_lock(&d->pci_lock). However, one
> call path wasn't updated to
On 28.08.2024 11:53, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-27 at 12:29 +0200, Jan Beulich wrote:
>>>
>>> +
>>> +/*
>>> + * 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 helper
flight 187371 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187371/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-qcow2broken
test-amd64-amd64-xl-qemuu-dmrestrict-amd
On Tue, 2024-08-27 at 15:44 +0200, Jan Beulich wrote:
> On 21.08.2024 18:06, Oleksii Kurochko wrote:
>
> > --- a/xen/arch/riscv/include/asm/smp.h
> > +++ b/xen/arch/riscv/include/asm/smp.h
> > @@ -5,6 +5,10 @@
> > #include
> > #include
> >
> > +#include
> > +
> > +#define INVALID_HARTID UL
These are final 2 patches of the series for making VMX/SVM support in Xen
configurable:
https://lore.kernel.org/xen-devel/cover.1723110344.git.sergiy_kib...@epam.com/
Minor changes comparing to v6, changelogs are provided per-patch.
-Sergiy
Xenia Ragiadakou (2):
ioreq: do not build arch_vc
From: Xenia Ragiadakou
VIO_realmode_completion is specific to vmx realmode and thus the function
arch_vcpu_ioreq_completion() has actual handling work only in VMX-enabled build,
as for the rest x86 and ARM build configurations it is basically a stub.
Here a separate configuration option ARCH_VCP
On 28/08/2024 10:00 am, Jan Beulich wrote:
> For partial writes the non-written parts of registers are folded into
> the full 64-bit value from what they're presently set to. That's wrong
> to do though when the behavior is write-1-to-clear: Writes not
> including to low 3 bits would unconditionall
From: Xenia Ragiadakou
Provide the user with configuration control over the cpu virtualization support
in Xen by making AMD_SVM and INTEL_VMX options user selectable.
To preserve the current default behavior, both options depend on HVM and
default to value of HVM.
To prevent users from unknowin
Move the logic that disables SMAP so it's only performed when building a PV
dom0, PVH dom0 builder doesn't require disabling SMAP.
The fixes tag is to account for the wrong usage of cpu_has_smap in
create_dom0(), it should instead have used
boot_cpu_has(X86_FEATURE_XEN_SMAP). Fix while moving the
On 28.08.2024 13:06, Andrew Cooper wrote:
> On 28/08/2024 10:00 am, Jan Beulich wrote:
>> For partial writes the non-written parts of registers are folded into
>> the full 64-bit value from what they're presently set to. That's wrong
>> to do though when the behavior is write-1-to-clear: Writes not
On 28.08.2024 13:30, Roger Pau Monne wrote:
> Move the logic that disables SMAP so it's only performed when building a PV
> dom0, PVH dom0 builder doesn't require disabling SMAP.
>
> The fixes tag is to account for the wrong usage of cpu_has_smap in
> create_dom0(), it should instead have used
> b
On 28/08/2024 12:50 pm, Jan Beulich wrote:
> On 28.08.2024 13:30, Roger Pau Monne wrote:
>> Move the logic that disables SMAP so it's only performed when building a PV
>> dom0, PVH dom0 builder doesn't require disabling SMAP.
>>
>> The fixes tag is to account for the wrong usage of cpu_has_smap in
On 28.08.2024 12:56, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-27 at 15:44 +0200, Jan Beulich wrote:
>> On 21.08.2024 18:06, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/include/asm/smp.h
>>> +++ b/xen/arch/riscv/include/asm/smp.h
>>> @@ -5,6 +5,10 @@
>>> #include
>>> #include
>>>
flight 187380 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187380/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 90d0ec17e7074905de347ccf2accdd6b8e8ee968
baseline version:
ovmf 99e4c8ea93fa0e98bc1bd
On Tue, 27 Aug 2024 13:19:59 +0200 Paolo Abeni wrote:
> On 8/22/24 20:11, Jeongjun Park wrote:
> > During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
> > kfree_rcu does not exist inside the rcu read critical section, so if
>
> The above wording is confusing, do you mean "kfree_
On Wed, Aug 28, 2024 at 12:51:23PM +0100, Andrew Cooper wrote:
> On 28/08/2024 12:50 pm, Jan Beulich wrote:
> > On 28.08.2024 13:30, Roger Pau Monne wrote:
> >> Move the logic that disables SMAP so it's only performed when building a PV
> >> dom0, PVH dom0 builder doesn't require disabling SMAP.
>
On Tue, 2024-08-27 at 16:19 +0200, Jan Beulich wrote:
> On 21.08.2024 18:06, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/include/asm/sbi.h
> > +++ b/xen/arch/riscv/include/asm/sbi.h
> > @@ -31,4 +64,34 @@ struct sbiret sbi_ecall(unsigned long ext,
> > unsigned long fid,
> > */
> > void sbi_
Update ECLAIR configuration of MISRA C:2012 Rule 20.7 ("Expressions
resulting from the expansion of macro parameters shall be enclosed in
parentheses") to tag as 'safe' the expansions of arguments surrounded
by the following tokens: '{', '}' and ';'.
Remove redundant comment-based deviations.
Sig
... rather than having each library implement its own subset.
Signed-off-by: Andrew Cooper
---
CC: Christian Lindig
CC: David Scott
CC: Edwin Török
CC: Rob Hoes
CC: Andrii Sultanov
Broken out of a larger series, to help Andrii with his dynlib work.
---
tools/ocaml/libs/xc/Makefile|
flight 187379 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187379/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
The oss-fuzz infrastructure collects runtime coverage information for debugging
and fuzzing evaluation. Currently it appears broken due to missing C files.
This is because the fuzzer's Makefile only symlinks the C files from various
locations in the Xen source tree into the build folder. These syml
On 28/08/2024 2:38 pm, Tamas K Lengyel wrote:
> The oss-fuzz infrastructure collects runtime coverage information for
> debugging
> and fuzzing evaluation. Currently it appears broken due to missing C files.
> This is because the fuzzer's Makefile only symlinks the C files from various
> locations
On Wed, Aug 28, 2024 at 2:30 PM Andrew Cooper wrote:
>
> ... rather than having each library implement its own subset.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Christian Lindig
> CC: David Scott
> CC: Edwin Török
> CC: Rob Hoes
> CC: Andrii Sultanov
>
> Broken out of a larger series, to
flight 187374 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187374/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187357
test-amd64-amd64-libvirt-xsm 15 migrate-s
On Wed, Aug 28, 2024 at 3:15 PM Edwin Torok wrote:
>
> On Wed, Aug 28, 2024 at 2:30 PM Andrew Cooper
> wrote:
> >
> > ... rather than having each library implement its own subset.
> >
> > Signed-off-by: Andrew Cooper
> > ---
> > CC: Christian Lindig
> > CC: David Scott
> > CC: Edwin Török
>
On 28/08/2024 3:15 pm, Edwin Torok wrote:
> On Wed, Aug 28, 2024 at 2:30 PM Andrew Cooper
> wrote:
>> ... rather than having each library implement its own subset.
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Christian Lindig
>> CC: David Scott
>> CC: Edwin Török
>> CC: Rob Hoes
>> CC: A
On Wed, Aug 28, 2024 at 3:20 PM Andrew Cooper wrote:
>
> On 28/08/2024 3:15 pm, Edwin Torok wrote:
> > On Wed, Aug 28, 2024 at 2:30 PM Andrew Cooper
> > wrote:
> >> ... rather than having each library implement its own subset.
> >>
> >> Signed-off-by: Andrew Cooper
> >> ---
> >> CC: Christian L
flight 187382 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187382/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a0ac7cf67afd382b4bd13a402bb6100a435b5b7b
baseline version:
ovmf 90d0ec17e7074905de347
On Tue, Aug 27, 2024 at 06:17:05PM -0400, Jason Andryuk wrote:
> On 2024-08-27 06:03, Anthony PERARD wrote:
> > From: Anthony PERARD
> >
> > Starting with QEMU 9.0, the option "-chroot", that we use for the
> > "dmrestrict" feature, is removed. We need to find out which to use
> > between "-chroo
On Tue, Aug 27, 2024 at 06:20:42PM -0400, Jason Andryuk wrote:
> On 2024-08-27 06:03, Anthony PERARD wrote:
> > QEMU 9.0 have removed "-chroot" command line option, which have been
> > deprecated since QEMU 8.1 in favor of "-run-with chroot=dir".
> >
> > Look into the result of the QMP command "qu
On 27/08/2024 11:37, Julien Grall wrote:
Hi,
Hi Julien,
On 23/08/2024 17:31, Ayan Kumar Halder wrote:
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg STATIC_MEMORY) will be selected
by the MPU configura
On 27/08/2024 5:07 pm, Jan Beulich wrote:
> On 27.08.2024 15:57, Andrew Cooper wrote:
>> ... which is more consise than the opencoded form.
>>
>> Also, for production VMs, ~100% of emulations are simple MOVs, so it is
>> likely
>> that there are no segments to write back.
>>
>> Furthermore, now th
Hi,
On 23/08/2024 17:31, Ayan Kumar Halder wrote:
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address
On 28.08.2024 15:12, Federico Serafini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -565,6 +565,10 @@ of this macro do not lead to developer confusion, and
> can thus be deviated."
> -config=MC3R1.R20.7,reports+={saf
On 28.08.2024 16:44, Andrew Cooper wrote:
> On 27/08/2024 5:07 pm, Jan Beulich wrote:
>> On 27.08.2024 15:57, Andrew Cooper wrote:
>>> +for_each_set_bit ( seg, dirty )
>>> +hvm_set_segment_register(curr, seg, &hvmemul_ctxt->seg_reg[seg]);
>>> +
>>> +hvmemul_ctxt->seg_reg_dirty = 0;
Hi,
On 23/08/2024 17:31, Ayan Kumar Halder wrote:
Define enable_boot_cpu_mm() for the AArch64-V8R system.
Like boot-time page table in MMU system, we need a boot-time MPU
protection region configuration in MPU system so Xen can fetch code and
data from normal memory.
START_ADDRESS + 2MB memory
On 28.08.2024 15:11, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-08-27 at 16:19 +0200, Jan Beulich wrote:
>> On 21.08.2024 18:06, Oleksii Kurochko wrote:
>>> @@ -38,7 +51,265 @@ struct sbiret sbi_ecall(unsigned long ext,
>>> unsigned long fid,
>>> return ret;
>>> }
>>>
>>> +static int
On Tue, 2024-08-27 at 17:00 +0200, Jan Beulich wrote:
> On 21.08.2024 18:06, Oleksii Kurochko wrote:
> > Implement map_pages_to_xen() which requires several
> > functions to manage page tables and entries:
> > - pt_update()
> > - pt_mapping_level()
> > - pt_update_entry()
> > - pt_next_level()
> >
flight 187383 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187383/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1fd2f9ec8f16cc8efb949888db94eb42006f77c6
baseline version:
ovmf a0ac7cf67afd382b4bd13
On Mon, May 06, 2024 at 02:33:20AM +0200, Marek Marczykowski-Górecki wrote:
> Call pci_default_write_config() only after resolving any handlers from
> XenPTRegInfo structures, and only with a value updated with those
> handlers. This is important for two reasons:
> 1. XenPTRegInfo has ro_mask which
On Mon, May 06, 2024 at 02:33:21AM +0200, Marek Marczykowski-Górecki wrote:
> Update it to get XENFEAT_dm_msix_all_writes for the next patch.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Anthony PERARD
Thanks,
--
Anthony Perard | Vates XCP-ng Developer
XCP-ng & Xen Orchestra -
On Mon, May 06, 2024 at 02:33:22AM +0200, Marek Marczykowski-Górecki wrote:
> diff --git a/hw/xen/xen_pt_msi.c b/hw/xen/xen_pt_msi.c
> index 09cca4e..836cc9c 100644
> --- a/hw/xen/xen_pt_msi.c
> +++ b/hw/xen/xen_pt_msi.c
> @@ -493,7 +501,12 @@ static uint64_t pci_msix_read(void *opaque, hwaddr addr
On 28/08/2024 9:13 am, Jan Beulich wrote:
> On 27.08.2024 15:57, Andrew Cooper wrote:
>> In the HPET_STATUS handling, the use of __clear_bit(i, &new_val) is the only
>> thing causing it to be spilled to the stack. Furthemore we only care about
>> the bottom 3 bits, so rewrite it to be a plain for
On 28/08/2024 10:19 am, Jan Beulich wrote:
> On 27.08.2024 15:57, Andrew Cooper wrote:
>> There are two issues. First, pi_test_and_clear_on() pulls the cache-line to
>> the CPU and dirties it even if there's nothing outstanding, but the final
>> for_each_set_bit() is O(256) when O(8) would do,
> N
flight 187384 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187384/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 84e7b74c8c643c59ee32d4da769f48a3c8c277a4
baseline version:
ovmf 1fd2f9ec8f16cc8efb949
On 28/08/2024 3:56 pm, Jan Beulich wrote:
> On 28.08.2024 16:44, Andrew Cooper wrote:
>> On 27/08/2024 5:07 pm, Jan Beulich wrote:
>>> On 27.08.2024 15:57, Andrew Cooper wrote:
+for_each_set_bit ( seg, dirty )
+hvm_set_segment_register(curr, seg, &hvmemul_ctxt->seg_reg[seg]);
On 28/08/2024 2:02 pm, Roger Pau Monné wrote:
> On Wed, Aug 28, 2024 at 12:51:23PM +0100, Andrew Cooper wrote:
>> On 28/08/2024 12:50 pm, Jan Beulich wrote:
>>> On 28.08.2024 13:30, Roger Pau Monne wrote:
Move the logic that disables SMAP so it's only performed when building a PV
dom0, PV
Hi Ayan,
The title is a bit confusing. It implies seconary CPU bringup used to
work on the MPU. However, you are adding a stub for enable_secondary_cpu_mm.
Also, I am not entirely this is really sufficient to disable CPU
bringup. There will be plenty of initialization done for secondary CPUs.
Hi,
On 28/08/2024 15:44, Ayan Kumar Halder wrote:
On 27/08/2024 11:37, Julien Grall wrote:
Hi,
Hi Julien,
On 23/08/2024 17:31, Ayan Kumar Halder wrote:
There are features in the forthcoming patches which are dependent on
MPU. For eg fixed start address.
Also, some of the Xen features (eg S
On 28/08/2024 7:08 pm, Andrew Cooper wrote:
> On 28/08/2024 10:19 am, Jan Beulich wrote:
>> On 27.08.2024 15:57, Andrew Cooper wrote:
>>> + * get it back again.
>>> + */
>>> +for ( unsigned int i = 0; i < ARRAY_SIZE(vec._64); ++i )
>>> +vec._64[i] = xchg(&desc->pir[i], 0);
>>> +
flight 187376 linux-linus real [real]
flight 187385 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187376/
http://logs.test-lab.xenproject.org/osstest/logs/187385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 187387 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187387/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 319835abb8517fde84bff31740fb1e61b33a3ae8
baseline version:
ovmf 84e7b74c8c643c59ee32d
Recent additions have undone prior tidying at the top of the file.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/in
All of the ffs()/fls() infrastructure is in fact (attr) const, because it
doesn't even read global state. This allows the compiler even more
flexibility to optimise.
No functional change.
Reported-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefan
There are 6 remaining callers in Xen:
* The two hweight32() calls, _domain_struct_bits() and efi_find_gop_mode(),
are __init only.
* The two hweight_long() calls are both in bitmap_weight().
* The two hweight64() calls are hv_vpset_nr_banks() and x86_emulate().
Only bitmap_weight() and
They are no more. No functional change.
Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/arch/
It has existed in x86 CPUs since 2008, so we're only 16 years late adding
support. With all the other scafolding in place, implement arch_hweightl()
for x86.
The only complication is that the call to arch_generic_hweightl() is behind
the compilers back. Address this by writing it in ASM and ensu
... and drop generic_hweight32().
As noted previously, the only two users of hweight32() are in __init paths.
The int-optimised form of generic_hweight() is only two instructions shorter
than the long-optimised form, and even then only on architectures which lack
fast multiplication, so there's n
The next phase of bitops cleanup. This series:
1) Untangles the mess around hweight()
2) Removes some unwise uses of hweight()
3) Makes it work transparently for RISC-V
4) Use the POPCNT instruction on x86 when available
See individual patches for v2 changes.
https://gitlab.com/xen-project/
This will be used to simplify real logic in the following patch. Add compile
and boot time testing as with other bitops.
Because the expression is so simple, implement it as a function-like macro
which is generic on the type of it's argument, rather than having multiple
variants.
Testing functio
Using hweight() is an especially expensive way of determining simply if
multiple bits are set in a value. Worse, 4 of the 10 hweight() calls in Xen
are of this form.
Switch to the new multiple_bits_set() helper. This is far more efficient than
the longhand hweight() algorithm and, owing to its s
There's no need for the name to be so verbose.
No functional change.
Suggest-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC:
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
CC: Oleksii Kurochko
CC: Shawn Anastasio
---
xen/common/bitmap.c
... and drop generic_hweight{32,64}().
This is identical on all architectures except ARM32. Add one extra SELF_TEST
to check that hweight64() works when the input is split in half.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabelli
flight 187386 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187386/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 187377 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187377/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
187368 pass in 187377
test-amd64-am
On Wed, 28 Aug 2024, Sergiy Kibrik wrote:
> From: Xenia Ragiadakou
>
> VIO_realmode_completion is specific to vmx realmode and thus the function
> arch_vcpu_ioreq_completion() has actual handling work only in VMX-enabled
> build,
> as for the rest x86 and ARM build configurations it is basically
flight 187389 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187389/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 7cde720e5126a47dadfb63ec9fd11b637620102d
baseline version:
ovmf 319835abb8517fde84bff
On Wed, 28 Aug 2024 21:52:12 +0900 Jeongjun Park wrote:
> > The loop runs with irq disabled, the RCU critical section extends over
> > it, uninterrupted.
>
> Basically, list_for_each_entry_rcu is specified to be used under the
> protection
> of rcu_read_lock(), but this is not the case with xen
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski :
On Fri, 23 Aug 2024 03:11:09 +0900 you wrote:
> During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
> kfree_rcu does not exist inside the rcu read critical section, so if
> kfree_rcu is called when
On Mon, 26 Aug 2024, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Fixes the CI failure introduced by 95764a0817.
>
> Update xilinx-smoke tests to use the "expect" utility for early exit from
> tests. Generalize the script "qemu-key.exp" to be used by both QEMU and
> hardware tests. Add a
On Tue, 27 Aug 2024, Federico Serafini wrote:
> Add MISRA C:2012 Rules 13.2 and 18.2 to the monitored set.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/monitored.ecl | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
On Mon, 29 Jul 2024, Stefano Stabellini wrote:
> On Mon, 29 Jul 2024, Federico Serafini wrote:
> > Add defensive return statement at the end of an unreachable
> > default case. Other than improve safety, this meets the requirements
> > to deviate a violation of MISRA C Rule 16.3: "An unconditional
On Wed, 28 Aug 2024, Federico Serafini wrote:
> Update ECLAIR configuration of MISRA C:2012 Rule 20.7 ("Expressions
> resulting from the expansion of macro parameters shall be enclosed in
> parentheses") to tag as 'safe' the expansions of arguments surrounded
> by the following tokens: '{', '}' and
On Fri, 26 Jul 2024, Jan Beulich wrote:
> On 25.07.2024 21:01, victorm.l...@amd.com wrote:
> > From: Victor Lira
> >
> > Requested-by: Jan Beulich
> > Signed-off-by: Victor Lira
>
> Looks okay to me now, just that I don't see ...
>
> > --- /dev/null
> > +++ b/automation/eclair_analysis/linker
On 8/28/2024 5:25 PM, Stefano Stabellini wrote:
xilinx-smoke-dom0-x86_64-gcc-debug:
extends: .xilinx-x86_64
+ variables:
+TEST_TIMEOUT: 500
I think we need to add something similar for .xilinx-arm64
The timeout should be set in test.yaml otherwise we'll default to 1500
I will add t
flight 187391 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187391/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 41a51d173557350ec8bcf64075a3e97730bf70dd
baseline version:
ovmf 7cde720e5126a47dadfb6
flight 187393 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187393/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 383f729ac096b8deb279933fce86e83a5f7f5ec7
baseline version:
ovmf 41a51d173557350ec8bcf
From: Victor Lira
Fix flaw in qemu-*.sh tests that producess a false success. The following
lines produces success despite the "expect" script producing nonzero exit
status.
set +e
...
./automation/scripts/qemu-key.exp | sed 's/\r\+$//'
(end of file)
The "set +e" is sometimes needed
While developing a patch to update xilinx tests to use the "expect"
utility I found that with the current use of "expect" in the *qemu-*
*scripts,
it is possible for the test to produce a *false success *if the expect
script returns nonzero due to the following lines
set +e
...
./automa
On Wed, Aug 28, 2024 at 08:21:14AM +0200, Andreas Larsson wrote:
> On 2024-08-28 08:10, Christoph Hellwig wrote:
> > --- a/drivers/xen/Kconfig
> > +++ b/drivers/xen/Kconfig
> > @@ -177,8 +177,8 @@ config XEN_GRANT_DMA_ALLOC
> >
> > config SWIOTLB_XEN
> > def_bool y
> > + depends on ARCH_DM
flight 187381 qemu-mainline real [real]
flight 187396 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187381/
http://logs.test-lab.xenproject.org/osstest/logs/187396/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 187392 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187392/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
With the original code I observe
In function ‘__irq_to_desc’,
inlined from ‘route_irq_to_guest’ at arch/arm/irq.c:465:12:
arch/arm/irq.c:54:16: error: array subscript -2 is below array bounds of
‘irq_desc_t[32]’ {aka ‘struct irq_desc[32]’} [-Werror=array-bounds=]
54 | return &this_
flight 187394 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187394/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2fe9b6c22fcc9b8617b95d4a2cf091fea4f66537
baseline version:
ovmf 383f729ac096b8deb2799
On 28.08.2024 20:56, Andrew Cooper wrote:
> On 28/08/2024 3:56 pm, Jan Beulich wrote:
>> On 28.08.2024 16:44, Andrew Cooper wrote:
>>> On 27/08/2024 5:07 pm, Jan Beulich wrote:
On 27.08.2024 15:57, Andrew Cooper wrote:
> +for_each_set_bit ( seg, dirty )
> +hvm_set_segment_r
1 - 100 of 103 matches
Mail list logo
