flight 188086 linux-linus real [real]
flight 188090 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/188086/
http://logs.test-lab.xenproject.org/osstest/logs/188090/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On 14/10/2024 20:11, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
Sorry I missed something.
/*
* Maps the various sections of Xen (described in xen.lds.S) as different MPU
* regions.
@@ -68,10 +92,11 @@
* Inputs:
* lr : Address to return to.
*
- * Clobbers x0 - x5
+ * Clobbers x0 -
On 14/10/2024 20:03, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/head.S
new file mode 100644
index 00..4a21bc815c
--- /dev/null
+++ b/xen/arch/arm/arm64/mpu/head.S
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: GPL-2.0-
flight 188088 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188088/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-pvhv2-intel 17 guest-saverestore fail pass in 188085
test-amd64-amd64-xl-qemut-stubdo
Hi Julien,
Sorry for the slow replies.
On 08/10/2024 23:31, Julien Grall wrote:
> Hi,
>
> On 08/10/2024 20:01, Andrei Cherechesu wrote:
>> Hi Julien,
>>
>> On 04/10/2024 19:24, Julien Grall wrote:
>>>
>>>
>>> On 04/10/2024 16:37, Andrei Cherechesu wrote:
Hi Julien, Stefano,
>>>
>>> Hi Andre
Hi Ayan,
On 15/10/2024 16:56, Ayan Kumar Halder wrote:
On 14/10/2024 20:03, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
diff --git a/xen/arch/arm/arm64/mpu/head.S b/xen/arch/arm/arm64/mpu/
head.S
new file mode 100644
index 00..4a21bc815c
--- /dev/null
+++ b/xen/arch/arm/arm64/mpu/head
On 15.10.2024 11:11, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-10-15 at 08:33 +0200, Jan Beulich wrote:
>> On 10.10.2024 17:30, Oleksii Kurochko wrote:
>>> --- a/xen/arch/riscv/setup.c
>>> +++ b/xen/arch/riscv/setup.c
>>> @@ -50,6 +50,8 @@ void __init noreturn start_xen(unsigned long
>>> boo
On Tue, Oct 15, 2024 at 09:25:11AM +0100, Frediano Ziglio wrote:
> This series came from part of the work of removing duplications between
> boot code and rewriting part of code from assembly to C.
Acked-by: Marek Marczykowski-Górecki
> Changes since v1, more details in specific commits:
> - sty
On Thu Oct 10, 2024 at 8:54 AM BST, Jan Beulich wrote:
> On 09.10.2024 19:57, Alejandro Vallejo wrote:
> > On Wed Oct 9, 2024 at 3:45 PM BST, Jan Beulich wrote:
> >> On 01.10.2024 14:38, Alejandro Vallejo wrote:
> >>> --- a/xen/lib/x86/policy.c
> >>> +++ b/xen/lib/x86/policy.c
> >>> @@ -2,6 +2,94 @
pci_intx() is a hybrid function which sometimes performs devres
operations, depending on whether pcim_enable_device() has been used to
enable the pci_dev. This sometimes-managed nature of the function is
problematic. Notably, it causes the function to allocate under some
circumstances which makes i
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
broadcom/bnx2x and brocade/bna enable their PCI-Device with
pci_enable_device(). Thus,
@Driver-Maintainers: Your driver might be touched by patch "Remove
devres from pci_intx()". You might want to take a look.
Changes since the RFC [1]:
- Add a patch deprecating pci{m}_intx(). (Heiner, Andy, Me)
- Add Acked-by's already given.
- Export pcim_intx() as a GPL function. (Alex)
-
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
cardreader/rtsx_pcr.c and tifm_7xx1.c enable their PCI-Device with
pci_enable_device().
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
xen enables its PCI-Device with pci_enable_device(). Thus, it
needs the never-managed v
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
hda_intel enables its PCI-Device with pcim_enable_device(). Thus, it needs
the always-m
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
All users in ata enable their PCI-Device with pcim_enable_device(). Thus,
they need the
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
MSI sets up its own separate devres callback implicitly in
pcim_setup_msi_release(). Th
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
hw/amd and how/intel enable their PCI-Device with pci_enable_device().
Thus, they need
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
qtnfmac enables its PCI-Device with pcim_enable_device(). Thus, it needs
the always-man
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
vfio enables its PCI-Device with pci_enable_device(). Thus, it
needs the never-managed
pci_intx() is a hybrid function which can sometimes be managed through
devres. This hybrid nature is undesirable.
Since all users of pci_intx() have by now been ported either to
always-managed pcim_intx() or never-managed pci_intx_unmanaged(), the
devres functionality can be removed from pci_intx(
pci_intx() is a hybrid function which can sometimes be managed through
devres. To remove this hybrid nature from pci_intx(), it is necessary to
port users to either an always-managed or a never-managed version.
All users of amd_mp2_pci_remove(), where pci_intx() is used, call
pcim_enable_device(),
pci_intx() and its managed counterpart pcim_intx() only exist for older
drivers which have not been ported yet for various reasons. Future
drivers should preferably use pci_alloc_irq_vectors().
Mark pci_intx() and pcim_intx() as deprecated and encourage usage of
pci_alloc_irq_vectors() in its plac
flight 188089 libvirt real [real]
flight 188096 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/188089/
http://logs.test-lab.xenproject.org/osstest/logs/188096/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-li
On Tue, 2024-10-15 at 08:33 +0200, Jan Beulich wrote:
> On 10.10.2024 17:30, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/setup.c
> > +++ b/xen/arch/riscv/setup.c
> > @@ -50,6 +50,8 @@ void __init noreturn start_xen(unsigned long
> > bootcpu_id,
> > _end - _start, fal
flight 188091 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188091/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 081cf576a226e70ce4134dda19baf977d0b8bc64
baseline version:
ovmf 21767dcf4e04ade9e679f
On Mon, Oct 14, 2024 at 05:32:26PM +0100, Frediano Ziglio wrote:
> On Mon, Oct 14, 2024 at 4:31 PM Anthony PERARD
> wrote:
> >
> > On Mon, Oct 14, 2024 at 09:53:28AM +0100, Frediano Ziglio wrote:
> > > diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> > > index 1199291d2b..23a
On 14/10/2024 9:53 am, Frediano Ziglio wrote:
> diff --git a/xen/tools/combine_two_binaries.py
> b/xen/tools/combine_two_binaries.py
> new file mode 100755
> index 00..138c59287e
> --- /dev/null
> +++ b/xen/tools/combine_two_binaries.py
> @@ -0,0 +1,207 @@
>
> +if args.output is not None:
Doing previous testing with an Alder Lake Intel machine with the
"x86/boot: Improve MBI2 structure check" commit test started to fail.
Removing the commit makes the tests succeed however there was not apparent
reason (looking at the code) for the failure.
So I instrumented code to output the struct
Tag structure should contain at least the tag header.
Entire tag structure must be contained inside MBI2 data.
Signed-off-by: Frediano Ziglio
Reviewed-by: Jan Beulich
---
Changes since v6:
- compare against total_size every time to avoid overflows.
Changes since v7:
- check for tag type being M
This series came from part of the work of removing duplications between
boot code and rewriting part of code from assembly to C.
Changes since v1, more details in specific commits:
- style updates;
- comments and descriptions improvements;
- other improvements.
Changes since v2:
- rebased on mast
On 15/10/2024 1:59 pm, Marek Marczykowski-Górecki wrote:
> On Tue, Oct 15, 2024 at 09:25:11AM +0100, Frediano Ziglio wrote:
>> This series came from part of the work of removing duplications between
>> boot code and rewriting part of code from assembly to C.
> Acked-by: Marek Marczykowski-Górecki
On Mon, Oct 14, 2024 at 09:53:29AM +0100, Frediano Ziglio wrote:
> diff --git a/xen/arch/x86/boot/Makefile b/xen/arch/x86/boot/Makefile
> index 23ad274c89..ca258a9729 100644
> --- a/xen/arch/x86/boot/Makefile
> +++ b/xen/arch/x86/boot/Makefile
> @@ -1,12 +1,16 @@
> obj-bin-y += head.o
> obj-bin-y
flight 188094 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188094/
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 14/10/2024 19:43, Luca Fancellu wrote:
Hi Ayan,
Hi Luca,
On 10 Oct 2024, at 15:03, 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 MP
Hi,
On 14/10/2024 19:53, Luca Fancellu wrote:
+ Frediano for suggestion about header protection define name
+++ b/xen/arch/arm/include/asm/mpu/layout.h
@@ -0,0 +1,33 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef __ARM_MPU_LAYOUT_H__
+#define __ARM_MPU_LAYOUT_H__
I think we are mo
In PVH dom0, when passthrough a device to domU, QEMU code
xen_pt_realize->xc_physdev_map_pirq wants to use gsi, but in current codes
the gsi number is got from file /sys/bus/pci/devices//irq, that is
wrong, because irq is not equal with gsi, they are in different spaces, so
pirq mapping fails.
To
flight 188107 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188107/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a232e0cd2fe2bb882a5dd0cafe322a2899a44d51
baseline version:
ovmf 92c1274467fff3209d3bd
flight 188095 xen-unstable real [real]
flight 188106 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/188095/
http://logs.test-lab.xenproject.org/osstest/logs/188106/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On Tue, 2024-10-15 at 13:53 -0600, Alex Williamson wrote:
> On Tue, 15 Oct 2024 20:51:23 +0200
> Philipp Stanner wrote:
>
> > pci_intx() and its managed counterpart pcim_intx() only exist for
> > older
> > drivers which have not been ported yet for various reasons. Future
> > drivers should prefe
On Tue, Oct 15, 2024 at 08:51:23PM +0200, Philipp Stanner wrote:
> pci_intx() and its managed counterpart pcim_intx() only exist for older
> drivers which have not been ported yet for various reasons. Future
> drivers should preferably use pci_alloc_irq_vectors().
>
> Mark pci_intx() and pcim_intx
flight 188097 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188097/
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 188099 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188099/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b3efbda1660372f3973c29cde0e92528862c4171
baseline version:
ovmf 081cf576a226e70ce4134
flight 188102 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/188102/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 92c1274467fff3209d3bd29c2ed994b7f2be3efe
baseline version:
ovmf b3efbda1660372f3973c2
On Tue, 15 Oct 2024 20:51:23 +0200
Philipp Stanner wrote:
> pci_intx() and its managed counterpart pcim_intx() only exist for older
> drivers which have not been ported yet for various reasons. Future
> drivers should preferably use pci_alloc_irq_vectors().
>
> Mark pci_intx() and pcim_intx() as
45 matches
Mail list logo
