flight 187361 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187361/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5a06afa7dd8ba8e99178fec9525be9e3fd2a4d3a
baseline version:
ovmf 0e8af8803489a10d4edc6
Add MISRA C:2012 Rules 13.2 and 18.2 to the monitored set.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/monitored.ecl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl
b/automation/eclair_analysis/ECLAIR/monitored.ecl
On Fri, Aug 23, 2024 at 6:19 PM Andrew Cooper wrote:
>
> On 22/08/2024 10:06 am, Andrii Sultanov wrote:
> > This plugin intends to hide the unstable Xenctrl interface under a
> > stable one. In case of the change in the interface, a V2 of this plugin
> > would need to be produced, but V1 with the
On 26/08/2024 11:37 am, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> 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_bit
On 26.08.2024 21:44, rtrk wrote:
> @@ -105,33 +55,29 @@ static bool __init pe_name_compare(const struct
> PeSectionHeader *sect,
> const void *__init pe_find_section(const void *image, const UINTN image_size,
> const CHAR16 *section_name, UINTN
> *size_out)
>
On 26/08/2024 11:39 am, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> They are no more, and won't be returning in this form.
> And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
> Not overly nice I would say.
If we ever regain a genuine need for the 8 or
> It seems that location for ocaml libs is in $(OCAMLDESTDIR), any reason
> to deviate from that?
OCAMLDESTDIR is only defined in tools/ocaml/common.make, and is unavailable
at the top-level directories level of the autoconf infrastructure (which
generates the
paths.ml file), as far as I understan
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 "query-command-line-options"
to find out if "-run-with chroot=dir" is available. Then use it in
place of "-chroot".
Resolves:
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 "-chroot" and "-run-with chroot=dir".
This patch implement the machinery to spawn QEMU, and to run the QMP
command "query-command-line
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.libxl-qemu-cmdline-probe-v1
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 "-chroot" and "-r
"-runas" is deprecated since QEMU 9.1 and will be remove in a future
release.
Signed-off-by: Anthony PERARD
---
tools/libs/light/libxl_dm.c | 12 ++--
tools/libs/light/libxl_internal.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/tools/libs/light/libxl_dm
On 21.08.2024 18:06, Oleksii Kurochko wrote:
> In Xen, memory-ordered atomic operations are not necessary,
This is an interesting statement. I'd like to suggest that you at least
limit it to the two constructs in question, rather than stating this
globally for everything.
> based on {read,write}_
On 27.08.2024 11:49, Andrew Cooper wrote:
> On 26/08/2024 11:39 am, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> They are no more, and won't be returning in this form.
>> And what's the plan? Use hweight32((uint8_t)...) in an open-coded manner?
>> Not overly nice I would say.
On 21.08.2024 18:06, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/config.h
> +++ b/xen/arch/riscv/include/asm/config.h
> @@ -41,8 +41,10 @@
> * Start addr | End addr | Slot | area description
> *
> ===
Hi,
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 configuration.
Thus, this patch introduces a choice between MMU a
On 26/08/2024 12:40 pm, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
> --- a/xen/include/xen/bitops.h
> +++ b/xen/include/xen/bitops.h
> @@ -35,6 +35,12 @@ extern void __bitop_bad_size(void);
> unsigned int __pure generic_ffsl(unsigned long x);
> unsigned int __pure generic_flsl
flight 187355 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187355/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail pass
in 187350
Tests which did not suc
On 26/08/2024 2:07 pm, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> A few RFC points.
>>
>> * I throught we had an x86 general lib-y but I can't find one, hence why
>> it's
>>still in xen/lib/ for now.
> We indeed have nothing like that yet. The file name should then imo
flight 187362 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187362/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ccda91c28628aa70bca614f1f7b71ad7b5ca61e0
baseline version:
ovmf 5a06afa7dd8ba8e99178f
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_rcu does not exit
from "...?
kfree_rcu is called when the rc
Special casing in x86emul_decode() can be dropped, while overrides done
in decode_0f38() can move into ext0f38_table[]. That table's S/G
prefetch entries aren't needed anymore either.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/decode.c
+++ b/xen/arch/x86/x86_emulate/decode.c
@@ -4
Following the improvements to Xen's bitops, fls() does constant propagation in
all cases. Use it, and drop the local opencoded helper.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
On 27.08.2024 12:39, Andrew Cooper wrote:
> On 26/08/2024 12:40 pm, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>> --- a/xen/include/xen/bitops.h
>> +++ b/xen/include/xen/bitops.h
>> @@ -35,6 +35,12 @@ extern void __bitop_bad_size(void);
>> unsigned int __pure generic_ffsl(unsi
On 24/08/2024 01:00, Andrew Cooper wrote:
>
>
> ... which is better optimised for scalar values, rather than using the
> arbitrary-sized bitmap helpers.
>
> Additionally, unlike other vgic helpers, this takes both a domain and vcpu
> pointer. The domain parameter isn't used, and the callers
On 26/08/2024 12:55 pm, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> ... and drop generic_hweight64().
>>
>> 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 cha
On 26/08/2024 11:30 am, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> 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
>>
On 27/08/2024 11:11 am, Jan Beulich wrote:
> On 27.08.2024 11:49, Andrew Cooper wrote:
>> On 26/08/2024 11:39 am, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
They are no more, and won't be returning in this form.
>>> And what's the plan? Use hweight32((uint8_t)...) in an o
On 26/08/2024 12:59 pm, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
>> ... and drop generic_hweight32().
>>
>> As noted previously, the only two users of hweight32() and they're both
>> singleton callers in __init paths, so it's not interesting to have a sub-GPR
>> optimised gene
On 24/08/2024 01:01, Andrew Cooper wrote:
>
>
> The existing expression is just a very complicated way of expressing a loop
> over all bits of target->list. Simplify the expression.
>
> While here, fix the two gprintk()'s. Because of a quotes vs line continuation
> issue, there's a long str
On 27/08/2024 1:13 pm, Michal Orzel wrote:
>
> On 24/08/2024 01:01, Andrew Cooper wrote:
>>
>> The existing expression is just a very complicated way of expressing a loop
>> over all bits of target->list. Simplify the expression.
>>
>> While here, fix the two gprintk()'s. Because of a quotes vs l
On 27/08/2024 12:41 pm, Jan Beulich wrote:
> On 27.08.2024 12:39, Andrew Cooper wrote:
>> On 26/08/2024 12:40 pm, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -35,6 +35,12 @@ extern void __bitop_bad_siz
On 24/08/2024 4:57 am, Christoph Hellwig wrote:
DMA ops are a helper for architectures and not for drivers to override
the DMA implementation. Unfortunately driver authors keep ignoring
this. Make this more clear by renaming the symbol to ARCH_DMA_OPS,
have the three drivers overriding it depen
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 27.08.2024 13:17, Andrew Cooper wrote:
> On 26/08/2024 2:07 pm, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> A few RFC points.
>>>
>>> * I throught we had an x86 general lib-y but I can't find one, hence why
>>> it's
>>>still in xen/lib/ for now.
>> We indeed have no
On 27.08.2024 14:01, Andrew Cooper wrote:
> On 26/08/2024 11:30 am, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> --- a/xen/common/bitops.c
>>> +++ b/xen/common/bitops.c
>>> @@ -84,8 +84,32 @@ static void __init test_fls(void)
>>> CHECK(fls64, 0x8001ULL, 64);
On 27/08/2024 14:20, Andrew Cooper wrote:
>
>
> On 27/08/2024 1:13 pm, Michal Orzel wrote:
>>
>> On 24/08/2024 01:01, Andrew Cooper wrote:
>>>
>>> The existing expression is just a very complicated way of expressing a loop
>>> over all bits of target->list. Simplify the expression.
>>>
>>> Wh
On 27/08/2024 1:39 pm, 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
>
On 27.08.2024 13:50, Andrew Cooper wrote:
> On 26/08/2024 12:55 pm, Jan Beulich wrote:
>> On 23.08.2024 01:06, Andrew Cooper wrote:
>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -302,6 +302,14 @@ static always_inline __pure unsigned int
>>> hweightl(unsigned long x)
On 27.08.2024 14:59, Andrew Cooper wrote:
> On 27/08/2024 1:39 pm, 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) )
>>
On 27/08/2024 2:04 pm, Jan Beulich wrote:
> On 27.08.2024 14:59, Andrew Cooper wrote:
>> On 27/08/2024 1:39 pm, 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 *im
flight 187357 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187357/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187318
test-amd64-amd64-libvirt-xsm 15 migrate-s
On Mon, Aug 26, 2024 at 11:59:28PM -0400, 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
^ was?
> and changed from pcidevs_lock() to read_lock(&d->pci_lo
On 27/08/2024 2:00 pm, Jan Beulich wrote:
> On 27.08.2024 13:50, Andrew Cooper wrote:
>> On 26/08/2024 12:55 pm, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -302,6 +302,14 @@ static always_inline __
On Tue, Aug 27, 2024 at 03:04:54PM +0200, Jan Beulich wrote:
> On 27.08.2024 14:59, Andrew Cooper wrote:
> > On 27/08/2024 1:39 pm, 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,
From: Nikola Jelic
Adapted x86 efi parser and mkreloc utility to use generic PE header
(efi/pe.h), instead of locally defined structures for each component.
Signed-off-by: Nikola Jelic
Signed-off-by: Milan Djokic
---
Changes in V2:
- Using pe header constants instead of hardcoded values (mag
On 21.08.2024 18:06, Oleksii Kurochko wrote:
> Introduce struct pcpu_info to store pCPU-related information.
> Initially, it includes only processor_id and hart id, but it
> will be extended to include guest CPU information and
> temporary variables for saving/restoring vCPU registers.
>
> Add set
On Tue, Aug 27, 2024 at 02:07:07PM +0100, Andrew Cooper wrote:
> On 27/08/2024 2:04 pm, Jan Beulich wrote:
> > On 27.08.2024 14:59, Andrew Cooper wrote:
> >> On 27/08/2024 1:39 pm, Roger Pau Monne wrote:
> >>> --- a/xen/arch/x86/dom0_build.c
> >>> +++ b/xen/arch/x86/dom0_build.c
> >>> @@ -612,7 +61
On 27.08.2024 15:51, Roger Pau Monné wrote:
> On Tue, Aug 27, 2024 at 02:07:07PM +0100, Andrew Cooper wrote:
>> On 27/08/2024 2:04 pm, Jan Beulich wrote:
>>> On 27.08.2024 14:59, Andrew Cooper wrote:
On 27/08/2024 1:39 pm, Roger Pau Monne wrote:
> --- a/xen/arch/x86/dom0_build.c
> +++
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 macros and some code to use them) and (in case of PE)
> > normal executable relocations.
> > Remove all normal execu
... 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 that find_{first,next}_bit() are no longer in use, the
seg_reg_{accessed,dirty} fields aren't forced to be u
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, these are spilled to the stack despite
the __{set,
All patches are independent. Patch 4 has been posted before, with only a
request for some wording changes.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1428997960
Andrew Cooper (4):
xen/evtchn: Use bitmap_for_each() in evtchn_check_pollers()
x86/hvm: Use for_each_set_bit() i
It is a preprocessor-identical opencoding.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Stefano Stabellini
CC: Julien Grall
---
xen/common/event_channel.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
ind
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, and would avoid multiple
atomic updates to the same IRR word.
Rewrite it from scratch, explaining
On 27/08/2024 1:50 pm, Jan Beulich wrote:
> On 27.08.2024 14:01, Andrew Cooper wrote:
>> On 26/08/2024 11:30 am, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
--- a/xen/common/bitops.c
+++ b/xen/common/bitops.c
@@ -84,8 +84,32 @@ static void __init test_fls(void)
>
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 "kfr
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
> @@ -12,8 +12,41 @@
> #ifndef __ASM_RISCV_SBI_H__
> #define __ASM_RISCV_SBI_H__
>
> +#include
> +
> #define SBI_EXT_0_1_CONSOLE_PUTCHAR 0x1
>
> +#define S
On 27/08/2024 2:25 pm, Andrew Cooper wrote:
> On 27/08/2024 2:00 pm, Jan Beulich wrote:
>> On 27.08.2024 13:50, Andrew Cooper wrote:
>>> On 26/08/2024 12:55 pm, Jan Beulich wrote:
On 23.08.2024 01:06, Andrew Cooper wrote:
>>> Again, this is modelled after f[fl]s64() which have the same
>>> exp
flight 187363 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187363/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf efaf8931bbfa33a81b8792fbf9e2ccc239d53204
baseline version:
ovmf ccda91c28628aa70bca61
On Mon, Aug 19, 2024 at 4:50 PM Jan Beulich wrote:
>
> On 19.08.2024 17:30, Frediano Ziglio wrote:
> > On Mon, Aug 19, 2024 at 3:30 PM Jan Beulich wrote:
> >> On 19.08.2024 16:16, Frediano Ziglio wrote:
> >>> On Thu, Aug 8, 2024 at 9:54 AM Jan Beulich wrote:
> On 08.08.2024 10:00, Frediano
On 27/08/2024 1:47 pm, Jan Beulich wrote:
> On 27.08.2024 13:17, Andrew Cooper wrote:
>> On 26/08/2024 2:07 pm, Jan Beulich wrote:
>>> On 23.08.2024 01:06, Andrew Cooper wrote:
A few RFC points.
* I throught we had an x86 general lib-y but I can't find one, hence why
it's
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()
> - pt_check_entry()
>
> To support these operations, add functions for
On 27.08.2024 16:32, Andrew Cooper wrote:
> On 27/08/2024 2:25 pm, Andrew Cooper wrote:
>> On 27/08/2024 2:00 pm, Jan Beulich wrote:
>>> On 27.08.2024 13:50, Andrew Cooper wrote:
On 26/08/2024 12:55 pm, Jan Beulich wrote:
> On 23.08.2024 01:06, Andrew Cooper wrote:
Again, this is mode
On 27.08.2024 16:59, Andrew Cooper wrote:
> On 27/08/2024 1:47 pm, Jan Beulich wrote:
>> On 27.08.2024 13:17, Andrew Cooper wrote:
>>> On 26/08/2024 2:07 pm, Jan Beulich wrote:
On 23.08.2024 01:06, Andrew Cooper wrote:
> @@ -475,4 +476,24 @@ static always_inline unsigned int arch_flsl(unsi
On Fri, Aug 23, 2024 at 06:05:03PM +0100, Javi Merino wrote:
> diff --git a/tools/libs/light/libxl_console.c
> b/tools/libs/light/libxl_console.c
> index a563c9d3c7f9..012fd996fba9 100644
> --- a/tools/libs/light/libxl_console.c
> +++ b/tools/libs/light/libxl_console.c
> @@ -774,12 +774,14 @@ libx
On Fri, Aug 23, 2024 at 06:05:04PM +0100, Javi Merino wrote:
> When reading the console, xen overwrites the contents of the buffer,
> so there is no need to zero the buffer before passing it to xen.
> Instead, add a NULL at the end of the buffer.
>
> While we are at it, change the zalloc() of the
On Fri, Aug 23, 2024 at 06:05:05PM +0100, Javi Merino wrote:
> Despite its name, libxl_xen_console_read_line() does not read a line,
> it fills the buffer with as many characters as fit. Update the
> documentation to reflect the real behaviour of the function. Rename
> line_r to avoid confusion s
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 macros and some code to use them) and (in case of PE)
>>> normal exe
On 27.08.2024 16:56, Frediano Ziglio wrote:
> On Mon, Aug 19, 2024 at 4:50 PM Jan Beulich wrote:
>>
>> On 19.08.2024 17:30, Frediano Ziglio wrote:
>>> On Mon, Aug 19, 2024 at 3:30 PM Jan Beulich wrote:
On 19.08.2024 16:16, Frediano Ziglio wrote:
> Could I ouput the trampoline in a code s
On 27.08.2024 15:57, Andrew Cooper wrote:
> It is a preprocessor-identical opencoding.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
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 that find_{first,next}_bit() are no longer in use, the
On 27/08/2024 2:57 pm, 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, and would avoid multiple
> atomic updates to the
On 27/08/2024 12:24 pm, Jan Beulich wrote:
> Special casing in x86emul_decode() can be dropped, while overrides done
> in decode_0f38() can move into ext0f38_table[]. That table's S/G
> prefetch entries aren't needed anymore either.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
flight 187358 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187358/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187342
test-amd64-amd64-xl-qemut-win7-amd64
flight 187364 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187364/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b2a431868c4ae0ad99def0a504d2fe097e16cd4f
baseline version:
ovmf efaf8931bbfa33a81b879
flight 187365 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187365/
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 187367 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187367/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a0594ca403e77f68b317cc15b9b5c6b39e36e0fb
baseline version:
ovmf b2a431868c4ae0ad99def
flight 187360 qemu-mainline real [real]
flight 187370 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187360/
http://logs.test-lab.xenproject.org/osstest/logs/187370/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
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 "-chroot" and "-run-with chroot=dir".
This patch implement the machinery to spawn QEMU, a
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 "query-command-line-options"
to find out if "-run-with chroot=dir" is available. T
On 2024-08-27 06:03, Anthony PERARD wrote:
"-runas" is deprecated since QEMU 9.1 and will be remove in a future
release.
Signed-off-by: Anthony PERARD
Reviewed-by: Jason Andryuk
for_each_set_bit() allocates its own variable intentionally as loop-scope
only. Unfortunately, this causes the inner 'i' to shadow the outer 'i'.
Drop the outermost 'i' and 'vcpuid' variables, moving them into a more narrow
scope and correcting them to be unsigned which they should have been all
flight 187369 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187369/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc7bb9a86e61ef80c225510f941dfc64dc9b4560
baseline version:
ovmf a0594ca403e77f68b317c
flight 187372 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187372/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ded4191e1087c56e0bdeb118fd519d18cb353ef3
baseline version:
ovmf cc7bb9a86e61ef80c2255
flight 187373 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187373/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 39a999eb1decf486c615489174912f2d278636d1
baseline version:
ovmf ded4191e1087c56e0bdeb
vdpa_sim has been fixed to not override the dma_map_ops in commit
6c3d329e6486 ("vdpa_sim: get rid of DMA ops"), so don't select the
symbol and don't depend on HAS_DMA.
Signed-off-by: Christoph Hellwig
---
drivers/vdpa/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a
DMA ops are a helper for architectures and not for drivers to override
the DMA implementation.
Unfortunately driver authors keep ignoring this. Make the fact more
clear by renaming the symbol to ARCH_HAS_DMA_OPS and having the two drivers
overriding their dma_ops depend on that. These drivers sh
Hi all,
we've had a long standing problems where drivers try to hook into the
DMA_OPS mechanisms to override them for something that is not DMA, or
to introduce additional dispatching.
Now that we are not using DMA_OPS support for dma-iommu and can build
kernels without DMA_OPS support on many co
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_DMA_OPS
Rename to ARCH_HAS_DMA_OPS in v2 is missing here
> depends on X
flight 187368 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187368/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187355
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 187375 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187375/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 25da777d95c0e76b3e0a15ff617870105c228b7b
baseline version:
ovmf 39a999eb1decf486c6154
91 matches
Mail list logo
