flight 187783 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 20 debian-hvm-install/l1/l2 fail REGR. vs.
187720
Tests whi
flight 187786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187786/
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 187776 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187776/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 187763
test-amd64-amd64-xl-qemuu-win7-amd64
flight 187773 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187773/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187753
test-amd64-amd64-libvirt 15 migrate-s
flight 187770 qemu-mainline real [real]
flight 187782 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187770/
http://logs.test-lab.xenproject.org/osstest/logs/187782/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Wed, Sep 18, 2024 at 02:05:54PM +0100, Alejandro Vallejo wrote:
> Moves sti directly after the cr2 read and immediately after the #PF
> handler.
I think you need to add some context about why this is needed, iow:
avoid corrupting %cr2 if a nested 3PF happens.
> While in the area, remove redund
flight 187769 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187769/
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 187754
Tests which did not suc
flight 187778 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187778/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 222e2854fe6bed443686e3809f155fd7b824fabd
baseline version:
ovmf c3580093520809cbfe2ab
Hi Shawn,
On Thu, 2024-09-19 at 16:10 -0500, Shawn Anastasio wrote:
> Hi Oleksii,
>
> On 9/17/24 11:15 AM, Oleksii Kurochko wrote:
> > Introduce a new `.dev.info` section in the PPC linker script to
> > handle device-specific information. This section is required by
> > common code (common/device
Hi Shawn,
On Thu, 2024-09-19 at 16:05 -0500, Shawn Anastasio wrote:
> Hi Oleksii,
>
> On 9/17/24 11:15 AM, Oleksii Kurochko wrote:
> > Introduce conditional macros to define device
> > information sections based on the configuration of ACPI
> > or device tree support. These sections are required
Ignore this one, I forgot to cleanup my output folder before
re-generating the patch series. The correct 2/3 is:
"xen/livepatch: do Xen build-id check earlier"
Thanks, Roger.
On 2024/9/19 06:49, Stefano Stabellini wrote:
> On Thu, 12 Sep 2024, Jiqian Chen wrote:
>> On PVH dom0, when passthrough a device to domU, QEMU and xl tools
>> want to use gsi number to do pirq mapping, see QEMU code
>> xen_pt_realize->xc_physdev_map_pirq, and xl code
>> pci_add_dm_done->xc_physdev
alternatives is used both at boot time, and when loading livepatch payloads.
While for the former it makes sense to panic, it's not useful for the later, as
for livepatches it's possible to fail to load the livepatch if alternatives
cannot be resolved and continue operating normally.
Relax the BUG
The check against the expected Xen build ID should be done ahead of attempting
to apply the alternatives contained in the livepatch.
If the CPUID in the alternatives patching data is out of the scope of the
running Xen featureset the BUG() in _apply_alternatives() will trigger thus
bringing the sy
Hello,
Following series attempts to improve the loading of livepatches,
specifically by doing the Xen build ID check ahead of processing any of
the sections in the livepatch payload (alternatives, bug frames...).
Thanks, Roger.
Roger Pau Monne (3):
xen/livepatch: simplify and unify logic in pr
The following sections: .note.gnu.build-id, .livepatch.xen_depends and
.livepatch.depends are mandatory and ensured to be present by
check_special_sections() before prepare_payload() is called.
Simplify the logic in prepare_payload() by introducing a generic function to
parse the sections that con
The check against the expected Xen build ID should be done ahead of attempting
to apply the alternatives contained in the livepatch.
If the CPUID in the alternatives patching data is out of the scope of the
running Xen featureset the BUG() in _apply_alternatives() will trigger thus
bringing the sy
Hi Michal,
On 19/09/2024 12:42, Michal Orzel wrote:
Attempt to attach an overlay (xl dt-overlay attach) to a domain without
first adding this overlay to Xen (xl dt-overlay add) results in an
overlay track entry being NULL in handle_attach_overlay_nodes(). This
leads to NULL pointer dereference a
flight 187775 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187775/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c3580093520809cbfe2abd0e702d53707b7782a9
baseline version:
ovmf 3a3b12cbdae2e89b0e365
On Thu, Sep 19, 2024 at 10:19:49PM +0200, Andrew Cooper wrote:
> On 19/09/2024 4:27 pm, Roger Pau Monne wrote:
> > Leaving active interrupt sources targeting APIC IDs that are offline can be
> > problematic on AMD machines during shutdown.
>
> What exactly qualifies as "offline" here?
>
> We don'
Hi Michal,
On 19/09/2024 12:42, Michal Orzel wrote:
The assumption stated in the comment that the code will never get there
is incorrect. It's enough for the target-path to be incorrect (i.e. user
error), which will lead to an incorrect overall node path and we will end
up in this "unreachable"
21 matches
Mail list logo
