flight 186784 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186784/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186771
test-amd64-amd64-xl-qemuu-ws16-amd64
Hi,
Something has changed between -rc1 and -rc2 that systemd units are not
installed anymore by default.
Reproducer:
./configure --prefix=/usr
make dist-tools
ls dist/install/usr/lib/systemd/system
It does work, if I pass --enable-systemd to ./configure.
My guess is the actual cha
flight 186786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186786/
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
On Tue, 2 Jul 2024, Federico Serafini wrote:
> On 01/07/24 10:47, Jan Beulich wrote:
> > On 26.06.2024 11:28, Federico Serafini wrote:
> > > @@ -2798,11 +2800,12 @@ void hvm_emulate_one_vm_event(enum emul_kind kind,
> > > unsigned int trapnr,
> > > hvio->mmio_insn_bytes = sizeof(hvio->mmi
As discussed during the last MISRA C meeting, add Rule 12.2 to the list
of MISRA C rules we accept, together with an explanation that we use gcc
-fsanitize=undefined alone to check for violations.
Signed-off-by: Stefano Stabellini
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 2e
On Wed, 3 Jul 2024, Jan Beulich wrote:
> On 01.07.2024 15:46, Alessandro Zucchelli wrote:
> > This section explains which format should be followed by header
> > inclusion guards via a drop-down list of rules.
>
> Ah, so this answers my earlier question regarding where the naming
> rules are spell
On Wed, 3 Jul 2024, Jan Beulich wrote:
> public/x86: don't include common xen.h from arch-specific one
>
> No other arch-*.h does so, and arch-x86/xen.h really just takes the role
> of arch-x86_32.h and arch-x86_64.h (by those two forwarding there). With
> xen.h itself including the per-arch heade
On Mon, 1 Jul 2024, Alessandro Zucchelli wrote:
> From: Nicola Vetrini
>
> Add safe deviation for *.c files, as estabilished in past discussion.
>
> Signed-off-by: Maria Celeste Cesario
> Signed-off-by: Simone Ballarin
> Signed-off-by: Nicola Vetrini
> Signed-off-by: Alessandro Zucchelli
>
On Mon, 1 Jul 2024, Alessandro Zucchelli wrote:
> From: Maria Celeste Cesario
>
> Add or modify inclusion guards to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
> prevent the contents of a header file being included more than once").
> Mechanical ch
On Wed, 3 Jul 2024, Jan Beulich wrote:
> On 01.07.2024 15:36, Alessandro Zucchelli wrote:
> > --- a/xen/include/xen/err.h
> > +++ b/xen/include/xen/err.h
> > @@ -1,5 +1,6 @@
> > -#if !defined(__XEN_ERR_H__) && !defined(__ASSEMBLY__)
> > -#define __XEN_ERR_H__
> > +#ifndef INCLUDE_XEN_ERR_H
> > +#de
On Mon, 1 Jul 2024, Jan Beulich wrote:
> On 01.07.2024 15:36, Alessandro Zucchelli wrote:
> > --- a/xen/arch/x86/efi/efi-boot.h
> > +++ b/xen/arch/x86/efi/efi-boot.h
> > @@ -3,6 +3,11 @@
> > * is intended to be included by common/efi/boot.c _only_, and
> > * therefore can define arch specific g
On Tue, 9 Jul 2024, Jan Beulich wrote:
> On 09.07.2024 09:38, Alessandro Zucchelli wrote:
> > On 2024-07-01 16:21, Jan Beulich wrote:
> >> On 01.07.2024 15:36, Alessandro Zucchelli wrote:
> >>> --- a/xen/arch/x86/Makefile
> >>> +++ b/xen/arch/x86/Makefile
> >>> @@ -260,17 +260,18 @@ $(objtree)/arch
On Mon, 1 Jul 2024, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Add inclusion guard to address violations of
> MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
> Mechanical change.
>
> S
On Mon, 1 Jul 2024, Jan Beulich wrote:
> On 01.07.2024 13:10, Alessandro Zucchelli wrote:
> > From: Simone Ballarin
> >
> > Add deviation comments to address violations of
> > MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> > to prevent the contents of a header file being incl
flight 186783 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186783/
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
On Tue, 9 Jul 2024, Jan Beulich wrote:
> On 09.07.2024 11:34, Nicola Vetrini wrote:
> > --- a/xen/include/xen/bitmap.h
> > +++ b/xen/include/xen/bitmap.h
> > @@ -103,18 +103,16 @@ extern int bitmap_allocate_region(unsigned long
> > *bitmap, int pos, int order);
> > #define bitmap_switch(nbits, ze
On 26/06/2024 2:39 am, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> This patch adds a bunch of rules to rules.rst that are uncontroversial
> and have zero violations in Xen. As such, they have been approved for
> adoption.
>
> All the ones that regard the standard library have the link
flight 186776 linux-linus real [real]
flight 186782 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186776/
http://logs.test-lab.xenproject.org/osstest/logs/186782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186780 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186780/
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 186781 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186781/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d4dbe5e101dcb86974f8dce3505b38343b83b432
baseline version:
ovmf 807ab61359061003c1541
On 12/07/2024 5:44 pm, Anthony PERARD wrote:
> On Fri, Jul 12, 2024 at 11:49:07AM +0100, Andrew Cooper wrote:
>> The containers are exactly as per 20.04 (Focal). However, this now brings us
>> to 5 releases * 4 build jobs worth of Ubuntu testing, which is overkill.
>>
>> The oldest and newest tool
On Fri, Jul 12, 2024 at 11:49:07AM +0100, Andrew Cooper wrote:
> The containers are exactly as per 20.04 (Focal). However, this now brings us
> to 5 releases * 4 build jobs worth of Ubuntu testing, which is overkill.
>
> The oldest and newest toolchains are the most likely to find problems with n
On Fri, Jul 12, 2024 at 11:48:55AM +0100, Andrew Cooper wrote:
> Exactly as per 18.04 (Bionic). This saves ~500M:
>
> registry.gitlab.com/xen-project/xen/ubuntu20.04-x86_64 1.06GB
> registry.gitlab.com/xen-project/xen/ubuntufocal 1.57GB
>
> Signed-off-by: A
Current patch series introduces device tree mapping for RISC-V
and necessary things for that such as:
- Fixmap mapping
- pmap
- Xen page table processing
Also, it introduces common stuff for working with fdt which is
based on the patches from [1]:
[PATCH v4 2/6] xen/device-tree: Move Arm's setup
Enable GENERIC_PT functionalities for RISC-V and also introduce some
RISC-V specific functions necessary to make the GENERIC_PT code
work and compilable.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/arch/riscv/Kconfig | 1 +
xen/arch/riscv
Introduce function which allows to map FDT to Xen.
Also, initialization of device_tree_flattened happens using early_fdt_map.
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- rework early_fdt_map to use map_pages_to_xen()
- move call early_fdt_map() to C code after MMU is enabled.
---
xen
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
Signed-off-by: Oleksii Kurochko
---
Changes in V6:
- update the version of
From: Shawn Anastasio
Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree. Since these routines are
generally useful on any architecture that supports device tree booting,
move them into xen/common/device-tree.
Suggested-by: Julie
At least, between Arm and RISC-V most of the code related to Xen page
table handling are common.
This GENERIC_PT code is based on Arm's arm/mmu/pt.c except some minor
changes such as introduction of the following functions:
* get_root_page()
* xen_pt_check_contig()
* set_pte_table_bit()
*
Introduce a function to set up fixmap mappings and L0 page
table for fixmap.
Additionally, defines were introduced in riscv/config.h to
calculate the FIXMAP_BASE address.
This involved introducing BOOT_FDT_VIRT_{START, SIZE} and
XEN_SIZE, XEN_VIRT_END.
Also, the check of Xen size was updated in t
Introduces arch_pmap_{un}map functions and select HAS_PMAP
for CONFIG_RISCV.
Additionaly it was necessary to introduce functions:
- mfn_to_xen_entry
- mfn_to_pte
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- newly introduced patch
---
xen/arch/riscv/Kconfig| 1 +
xen/arch
Signed-off-by: Oleksii Kurochko
---
Changes in V2:
- move 'select HAS_DEVICE_TREE' to CONFIG_RISCV.
---
Changes in V1:
- new patch
---
xen/arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/riscv/Kconfig b/xen/arch/riscv/Kconfig
index f531e96657..259eea8d3b 100644
-
The patch series is based on:
Enable build of full Xen for RISC-V [1]
which haven't fully been merged yet.
The patch series provides a basic implementation of exception handling.
It can do only basic things such as decode a cause of an exception,
save/restore registers and execute "wfi" instru
The patch introduces stuff needed to decode a reason of an
exception.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
Acked-by: Jan Beulich
---
Changes in V10:
- add Acked-by: Jan Beulich
---
Changes in V9:
- This patch was reverted as breaks both release and randconfig builds.
Signed-off-by: Oleksii Kurochko
Acked-by: Alistair Francis
---
Changes in V10:
- wrap test_macros_from_bug_h() under "#ifdef CONFIG_SELF_TESTS"
- update the commit title to: "xen/riscv: test basic exception handling stuff"
---
Changes in V9:
- s/early_printk/printk as common code is now avail
To have working BUG(), WARN(), ASSERT, run_in_exception_handler()
it is needed to enable GENERIC_BUG_FRAME.
Also, is needed to be included for the reason that panic() and
printk() are used in common/bug.c and RISC-V fails if it is not included
with the following errors:
common/bug.c:69:9: erro
As common code is available it is better to use printk() instead
of early_printk().
Also the printing of "Hello from RISC-V world" is dropped as
it is useless and "All set up is enough".
Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
---
Changes in V10:
- add Acked-by: Jan Beulich
---
trap_init() wasn't declared with the __init attribute to avoid removing
__init when multi-CPU support for Xen is added.
Signed-off-by: Oleksii Kurochko
Reviewed-by: Alistair Francis
---
Changes in V10:
- update the commit message
---
Changes in V9:
- drop inclusion of in setup.c
- drop #inc
On 12/07/2024 3:29 pm, Anthony PERARD wrote:
> On Fri, Jul 12, 2024 at 11:48:29AM +0100, Andrew Cooper wrote:
>> diff --git a/automation/build/ubuntu/16.04-x86_64.dockerfile
>> b/automation/build/ubuntu/16.04-x86_64.dockerfile
>> new file mode 100644
>> +python3-setuptools
> Another thing,
On Fri, Jul 12, 2024 at 11:48:29AM +0100, Andrew Cooper wrote:
> diff --git a/automation/build/ubuntu/16.04-x86_64.dockerfile
> b/automation/build/ubuntu/16.04-x86_64.dockerfile
> new file mode 100644
> +python3-setuptools
Another thing,
I've just notice that "python3-setuptools" was ori
flight 186771 xen-unstable real [real]
flight 186779 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186771/
http://logs.test-lab.xenproject.org/osstest/logs/186779/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 12/07/2024 3:12 pm, Anthony PERARD wrote:
> On Fri, Jul 12, 2024 at 11:48:42AM +0100, Andrew Cooper wrote:
>> As with 16.04 (Focal), except that ninja-build is available so QEMU can be
> ^ Xenial
>
> These names all mixed up after a while :-)
Bah, yes. This is one of the few c
On Fri, Jul 12, 2024 at 11:48:42AM +0100, Andrew Cooper wrote:
> As with 16.04 (Focal), except that ninja-build is available so QEMU can be
^ Xenial
These names all mixed up after a while :-)
> built.
>
> This halves the size of the container:
>
> registry.gitlab.com/xen-pro
On 12.07.2024 16:00, Andrew Cooper wrote:
> On 12/07/2024 2:46 pm, Juergen Gross wrote:
>> On 12.07.24 12:35, Jürgen Groß wrote:
>>> On 09.07.24 15:08, Jason Andryuk wrote:
After acpixtract & iasl:
$ grep -ir FEEC *
dsdt.dsl: OperationRegion (ECMM, SystemMemory, 0xFEEC2000, 0x
On 12/07/2024 3:02 pm, Anthony PERARD wrote:
> On Fri, Jul 12, 2024 at 11:48:29AM +0100, Andrew Cooper wrote:
>> diff --git a/automation/scripts/containerize
>> b/automation/scripts/containerize
>> index 0ff53b6fe4e1..5fc41c36a27c 100755
>> --- a/automation/scripts/containerize
>> +++ b/automation
On Fri, Jul 12, 2024 at 11:48:29AM +0100, Andrew Cooper wrote:
> diff --git a/automation/scripts/containerize b/automation/scripts/containerize
> index 0ff53b6fe4e1..5fc41c36a27c 100755
> --- a/automation/scripts/containerize
> +++ b/automation/scripts/containerize
> @@ -52,9 +52,9 @@ case "_${CONT
On 12/07/2024 2:46 pm, Juergen Gross wrote:
> On 12.07.24 12:35, Jürgen Groß wrote:
>> On 09.07.24 15:08, Jason Andryuk wrote:
>>> On 2024-07-09 06:56, Jürgen Groß wrote:
On 09.07.24 09:01, Jan Beulich wrote:
> On 09.07.2024 08:36, Jürgen Groß wrote:
>> On 09.07.24 08:24, Jan Beulich w
On Fri, Jul 12, 2024 at 11:48:29AM +0100, Andrew Cooper wrote:
> Rework the container to be non-root, use heredocs for legibility, and use use
> apt-get --no-install-recommends to keep the size down.
>
> Ubuntu Xenial has no ninja-build package, so can't build the QEMU referenced
> by Xen 4.16. T
flight 186773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186773/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186760
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 12.07.24 12:35, Jürgen Groß wrote:
On 09.07.24 15:08, Jason Andryuk wrote:
On 2024-07-09 06:56, Jürgen Groß wrote:
On 09.07.24 09:01, Jan Beulich wrote:
On 09.07.2024 08:36, Jürgen Groß wrote:
On 09.07.24 08:24, Jan Beulich wrote:
On 08.07.2024 23:30, Jason Andryuk wrote:
From the bac
On 12.07.2024 15:07, Fouad Hilly wrote:
> @@ -79,6 +81,8 @@ static void usage(FILE *stream, const char *name)
> "options:\n"
> " -h, --helpdisplay this help\n"
> " -s, --show-cpu-info show CPU information\n"
> +" -f, --force
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
Introducing usage() to handle usage\help messages in a common block.
show_curr_cpu is printed to stdout only.
Signed-off-by: Fouad Hilly
---
[v5]
1- Update message description.
2- re-arrange static
Pass xen-ucode flags to do low level checks on micorocde version and
utilize it to allow for microcode downgrade or reapply the same version of the
microcode.
ucode_force is required to be passed to a low level Intel and AMD for version
checks to be done.
While adding ucode_force, opt_ucode_allow_s
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
This change is required to enable developers to load ucode that is t
Introduce --force option to xen-ucode to force skipping microcode version
check, which
allows the user to update x86 microcode even if both versions are the same or
downgrade.
xc_microcode_update() refactored to accept flags and utilize
xenpf_microcode_update2.
Signed-off-by: Fouad Hilly
Revie
Refactor microcode_update() by adding flags field.
struct xenpf_microcode_update2 added with uint32_t flags field.
Introduce XENPF_microcode_update2 hypercall with flags field.
Signed-off-by: Fouad Hilly
Reviewed-by: Andrew Cooper
---
[v5]
1- Update commit message to include the full name of XEN
On Fri, Jul 12, 2024 at 01:55:38PM +0100, Andrew Cooper wrote:
> See prior patch for most discussion.
>
> Despite appearing to be a fixed release (and therefore not marked as permitted
> failure), the dockerfile references the `leap` tag which is rolling in
> practice. Switch to 15.6 explicitly,
flight 186778 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186778/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 807ab61359061003c154174799b1e184cb089b46
baseline version:
ovmf 2b6d0eb43439891e64175
On 12.07.2024 14:46, Teddy Astie wrote:
> Hello Jan,
>
> Le 12/07/2024 à 12:46, Jan Beulich a écrit :
>> On 11.07.2024 21:20, Alejandro Vallejo wrote:
>>> On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
--- /dev/null
+++ b/xen/common/pv-iommu.c
@@ -0,0 +1,328 @@
+/* SPDX
See prior patch for most discussion.
Despite appearing to be a fixed release (and therefore not marked as permitted
failure), the dockerfile references the `leap` tag which is rolling in
practice. Switch to 15.6 explicitly, for better test stability.
Vs tumbleweed, use `zypper update` rather tha
On 12/07/2024 1:33 pm, Anthony PERARD wrote:
> On Fri, Jul 12, 2024 at 12:14:26PM +0100, Andrew Cooper wrote:
>> while removed are:
>>
>> bc # ?
> I don't know why, but this one is also installed by osstest. The commit
> adding it doesn't say why it was needed.
>
> Also, looks l
Hello Jan,
Le 12/07/2024 à 12:46, Jan Beulich a écrit :
> On 11.07.2024 21:20, Alejandro Vallejo wrote:
>> On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
>>> --- /dev/null
>>> +++ b/xen/common/pv-iommu.c
>>> @@ -0,0 +1,328 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/*
>>> + * xen/
On Fri, Jul 12, 2024 at 12:14:26PM +0100, Andrew Cooper wrote:
> while removed are:
>
> bc # ?
I don't know why, but this one is also installed by osstest. The commit
adding it doesn't say why it was needed.
Also, looks like many QEMU containers are installing `bc`, but I can
On 12/07/2024 12:39 pm, Oleksii wrote:
> On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote:
>> For starters, they're slightly smaller:
>>
>> $ docker image list
>> registry.gitlab.com/xen-project/xen/debian 12-riscv64
>> 772MB
>> registry.gitlab.com/xen-project/xen/debian
On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote:
> The containers are both much smaller, with stable toolchains over
> time, and
> this at least means we're not doing all testing with a single
> compiler.
>
> Rename the jobs to follow to sort coherently ($DISTRO-$VERSION-$ARCH-
> *) and
> r
On Thu, 2024-07-11 at 12:15 +0100, Andrew Cooper wrote:
> For starters, they're slightly smaller:
>
> $ docker image list
> registry.gitlab.com/xen-project/xen/debian 12-riscv64
> 772MB
> registry.gitlab.com/xen-project/xen/debian 11-riscv64
> 422MB
Do we really ne
Hi all,
The July community call recording has been uploaded:
https://youtu.be/BEFmzqxf2Wo
Many thanks,
Kelly Choi
Community Manager
Xen Project
Existing as suse:opensuse-tumbleweed is a historical quirk, and adjusted for
consistency with all the other containers.
Make it non-root, use heredocs for legibility, and use the zypper long names
for the benefit of those wondering what was being referenced or duplicated.
Trim the dependencies su
From: "Edgar E. Iglesias"
This fixes the clobbering of the entry->next pointer when
unmapping the first entry in a bucket of a mapcache.
Fixes: 123acd816d ("xen: mapcache: Unmap first entries in buckets")
Reported-by: Anthony PERARD
Signed-off-by: Edgar E. Iglesias
Reviewed-by: Anthony PERARD
The containers are exactly as per 20.04 (Focal). However, this now brings us
to 5 releases * 4 build jobs worth of Ubuntu testing, which is overkill.
The oldest and newest toolchains are the most likely to find problems with new
code, so reduce the middle 3 releases (18/20/22) to just a single sm
On 12.07.2024 11:08, Fonyuy-Asheri Caleb wrote:
>>> I was able to locate the failure point to the file
>>> xen/arch/x86/domctl.c with the following check.
>>>
>>> if( evc->size>> evc->size>PV_XSAVE_SIZE(xfeature_mask) )
>>> gotovcpuextstate_out;
>>
>> It is certainly more complicated than that.
>>
Exactly as per 18.04 (Bionic). This saves ~500M:
registry.gitlab.com/xen-project/xen/ubuntu20.04-x86_64 1.06GB
registry.gitlab.com/xen-project/xen/ubuntufocal 1.57GB
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
CC: Roger Pau Monn
Rework the container to be non-root, use heredocs for legibility, and use use
apt-get --no-install-recommends to keep the size down.
Ubuntu Xenial has no ninja-build package, so can't build the QEMU referenced
by Xen 4.16. Therefore, drop the dependencies too.
This saves ~500M:
registry.gitla
As with 16.04 (Focal), except that ninja-build is available so QEMU can be
built.
This halves the size of the container:
registry.gitlab.com/xen-project/xen/ubuntu18.04-x86_64 860MB
registry.gitlab.com/xen-project/xen/ubuntubionic 1.44GB
Signed-off-by: Andre
On 11.07.2024 21:20, Alejandro Vallejo wrote:
> On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
>> --- /dev/null
>> +++ b/xen/common/pv-iommu.c
>> @@ -0,0 +1,328 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * xen/common/pv_iommu.c
>> + *
>> + * PV-IOMMU hypercall interface.
>> +
flight 186777 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186777/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2b6d0eb43439891e641750cd5054b1bc3fb40e72
baseline version:
ovmf 2e7230f1ba65e0ec9e6a3
On 09.07.24 15:08, Jason Andryuk wrote:
On 2024-07-09 06:56, Jürgen Groß wrote:
On 09.07.24 09:01, Jan Beulich wrote:
On 09.07.2024 08:36, Jürgen Groß wrote:
On 09.07.24 08:24, Jan Beulich wrote:
On 08.07.2024 23:30, Jason Andryuk wrote:
From the backtrace, it looks like the immediate cas
Hello Alejandro,
>> +#define PVIOMMU_MAX_PAGES 256 /* Move to Kconfig ? */
>
> It probably wants to be a cmdline argument, I think.
>
Maybe, but in that sense, I think it should be a domain-specific limit
rather than a global one. (e.g ability to prevent a DomU from having a
very permissive l
Hi Andrew,
>> I was able to locate the failure point to the file
>> xen/arch/x86/domctl.c with the following check.
>>
>> if( evc->size> evc->size>PV_XSAVE_SIZE(xfeature_mask) )
>> gotovcpuextstate_out;
>
> It is certainly more complicated than that.
>
> What that's saying is that Xen doesn't
Hello Alejandro, thanks for reply !
Le 11/07/2024 à 20:26, Alejandro Vallejo a écrit :
> Disclaimer: I haven't looked at the code yet.
>
> On Thu Jul 11, 2024 at 3:04 PM BST, Teddy Astie wrote:
>> Some operating systems want to use IOMMU to implement various features (e.g
>> VFIO) or DMA protectio
flight 186774 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186774/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2e7230f1ba65e0ec9e6a3e191cca3a8b04e22ca8
baseline version:
ovmf 72d6e247b781cca65aac7
10.07.24 13:19, Jan Beulich:
looking through these changes once again I wonder why can't we just move
stub to the header like this:
in xen/include/xen/ioreq.h:
#ifdef arch_vcpu_ioreq_completion
#ifdef CONFIG_VMX
bool arch_vcpu_ioreq_completion(enum vio_completion completion);
#else
static inli
flight 186766 linux-linus real [real]
flight 186775 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186766/
http://logs.test-lab.xenproject.org/osstest/logs/186775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
83 matches
Mail list logo
