flight 186832 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186832/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 43b7a856fad2e25b1b5bddeb6cb08881a29caf4d
baseline version:
ovmf 6b4dd3625b24fbb9ac5d6
flight 186831 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186831/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6b4dd3625b24fbb9ac5d6d931dd11ff50e288a79
baseline version:
ovmf 55b043732d20305c769c6
flight 186829 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186829/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 55b043732d20305c769c6243e0a9a6e1f5ae879d
baseline version:
ovmf 690f13fcb4a7b74b30091
On Tue, 16 Jul 2024, Jan Beulich wrote:
> On 16.07.2024 02:43, Stefano Stabellini wrote:
> > On Mon, 15 Jul 2024, Jan Beulich wrote:
> >> On 13.07.2024 00:38, Stefano Stabellini wrote:
> >>> On Wed, 3 Jul 2024, Jan Beulich wrote:
> I further have to note that, as indicated during the earlier d
flight 186826 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186826/
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 186822 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186822/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 690f13fcb4a7b74b30091c7067a18bb7971982d8
baseline version:
ovmf f9c373c8388f819166e57
On Tue, Jul 16, 2024 at 03:55:58PM +0200, Anthony PERARD wrote:
> On Tue, Jul 16, 2024 at 10:22:18AM +0200, Juergen Gross wrote:
> > On 16.07.24 09:46, Jan Beulich wrote:
> > > On 16.07.2024 09:33, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 16/07/2024 08:24, Jan Beulich wrote:
> > > > > On
On Tue, 16 Jul 2024, Michal Orzel wrote:
> When $BOOT_CMD is bootefi, there shall be no '-' between $kernel_addr
> and $device_tree_addr.
>
> Fixes: 3fa89f8f9853 ("Add support for BOOT_CMD")
> Signed-off-by: Michal Orzel
I think and if/else would have been more readable but it is fine anyway.
Th
The pull request you sent on Mon, 15 Jul 2024 07:47:32 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-6.11-rc1-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f83e38fc9f1092f8a7a65ff2ea6a1ea6502efaf0
Thank you!
--
Deet-doot-dot, I
flight 186816 linux-linus real [real]
flight 186824 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186816/
http://logs.test-lab.xenproject.org/osstest/logs/186824/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
flight 186821 xen-unstable-smoke real [real]
flight 186823 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186821/
http://logs.test-lab.xenproject.org/osstest/logs/186823/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On Mon May 13, 2024 at 2:40 PM BST, Elias El Yandouzi wrote:
> From: Wei Liu
>
> It is going to be needed by HVM and idle domain as well, because without
> the direct map, both need a mapcache to map pages.
>
> This commit lifts the mapcache variable up and initialise it a bit earlier
> for PV and
Hi Jan,
On 14/05/2024 16:03, Jan Beulich wrote:
On 13.05.2024 15:40, Elias El Yandouzi wrote:
--- a/xen/arch/x86/pv/dom0_build.c
+++ b/xen/arch/x86/pv/dom0_build.c
@@ -382,6 +382,10 @@ int __init dom0_construct_pv(struct domain *d,
l3_pgentry_t *l3tab = NULL, *l3start = NULL;
l2_pge
On 09.07.2024 12: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 case is just trying to
> r
On 16.07.2024 17:03, Matthew Barnes wrote:
> On Tue, Jul 09, 2024 at 08:40:18AM +0200, Jan Beulich wrote:
>> On 08.07.2024 17:42, Matthew Barnes wrote:
>>> Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
>>> startup.
>>>
>>> There are efforts to support a maximum of 128 vCPUs, whic
Hi all,
We intend to branch for Xen 4.19 in the next couple of days.
As part of the process, it is easier to branch when staging == master.
Therefore I would like to ask a commit moratorium.
Please don't commit anything (even patches released-acked) until further
notice.
Cheers,
--
Julien G
On Tue, Jul 09, 2024 at 08:40:18AM +0200, Jan Beulich wrote:
> On 08.07.2024 17:42, Matthew Barnes wrote:
> > Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
> > startup.
> >
> > There are efforts to support a maximum of 128 vCPUs, which would involve
> > bumping the OVMF constant
On 12.07.2024 15:07, Fouad Hilly wrote:
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -90,6 +90,16 @@ struct ucode_mod_blob {
> size_t size;
> };
>
> +struct microcode_patch_with_flags {
> +unsigned int flags;
> +struct microcode_patch *pat
On 12.07.2024 15:07, Fouad Hilly wrote:
> --- a/tools/misc/xen-ucode.c
> +++ b/tools/misc/xen-ucode.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> static xc_interface *xch;
>
> @@ -71,12 +72,29 @@ static void show_curr_cpu(FILE *f)
> }
> }
>
> +static voi
On 09.07.2024 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
On Tue, Jul 16, 2024 at 10:22:18AM +0200, Juergen Gross wrote:
> On 16.07.24 09:46, Jan Beulich wrote:
> > On 16.07.2024 09:33, Julien Grall wrote:
> > > Hi,
> > >
> > > On 16/07/2024 08:24, Jan Beulich wrote:
> > > > On 16.07.2024 09:22, Julien Grall wrote:
> > > > > On 16/07/2024 07:47, Jan Beul
flight 186817 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186817/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f9c373c8388f819166e57365197bc423d56209a6
baseline version:
ovmf 1bb9f47739ae7993191a3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-31143 / XSA-458
version 2
double unlock in x86 guest IRQ handling
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2024-31144 / XSA-459
version 2
Xapi: Metadata injection attack against backup/restore functionality
UPDATES IN VERSION 2
Public release.
ISSUE DESCRIPTION
flight 186814 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186814/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186788
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 15.07.2024 12:30, Jan Beulich wrote:
> On 15.07.2024 12:07, Andrew Cooper wrote:
>> I see two options.
>>
>> 1) Activate Systemd by default on Linux now (as it's basically free), or
>> 2) Update CHANGELOG to note this behaviour
>>
>> Personally I think 2 is the better option, because we don't sp
flight 186812 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186812/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-freebsd11-amd64 21 guest-start/freebsd.repeat fail pass
in 186800
test-armhf-armhf-libv
flight 186811 linux-linus real [real]
flight 186815 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186811/
http://logs.test-lab.xenproject.org/osstest/logs/186815/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
When $BOOT_CMD is bootefi, there shall be no '-' between $kernel_addr
and $device_tree_addr.
Fixes: 3fa89f8f9853 ("Add support for BOOT_CMD")
Signed-off-by: Michal Orzel
---
Note: using this command would be a good opportunity for a Xen EFI boot CI test
on Arm64 when the stub is not responsible f
On 16.07.24 09:46, Jan Beulich wrote:
On 16.07.2024 09:33, Julien Grall wrote:
Hi,
On 16/07/2024 08:24, Jan Beulich wrote:
On 16.07.2024 09:22, Julien Grall wrote:
On 16/07/2024 07:47, Jan Beulich wrote:
On 15.07.2024 18:56, Julien Grall wrote:
On 15/07/2024 16:50, Andrew Cooper wrote:
An
On 15.07.2024 18:48, Federico Serafini wrote:
> MISRA C Rule 16.3 states that "An unconditional `break' statement shall
> terminate every switch-clause".
>
> Add pseudo keyword fallthrough or missing break statement
> to address violations of the rule.
>
> As a defensive measure, return an error
On 16.07.2024 09:33, Julien Grall wrote:
> Hi,
>
> On 16/07/2024 08:24, Jan Beulich wrote:
>> On 16.07.2024 09:22, Julien Grall wrote:
>>> On 16/07/2024 07:47, Jan Beulich wrote:
On 15.07.2024 18:56, Julien Grall wrote:
> On 15/07/2024 16:50, Andrew Cooper wrote:
>> An earlier part of
Hi,
On 16/07/2024 08:24, Jan Beulich wrote:
On 16.07.2024 09:22, Julien Grall wrote:
On 16/07/2024 07:47, Jan Beulich wrote:
On 15.07.2024 18:56, Julien Grall wrote:
On 15/07/2024 16:50, Andrew Cooper wrote:
An earlier part of the checklist states:
* change xen-unstable README. The ban
On 16.07.2024 09:22, Julien Grall wrote:
> On 16/07/2024 07:47, Jan Beulich wrote:
>> On 15.07.2024 18:56, Julien Grall wrote:
>>> On 15/07/2024 16:50, Andrew Cooper wrote:
An earlier part of the checklist states:
* change xen-unstable README. The banner (generated using figlet)
Hi Jan,
On 16/07/2024 07:47, Jan Beulich wrote:
On 15.07.2024 18:56, Julien Grall wrote:
On 15/07/2024 16:50, Andrew Cooper wrote:
An earlier part of the checklist states:
* change xen-unstable README. The banner (generated using figlet) should
say:
- "Xen 4.5" in releases and on
On 16.07.2024 02:43, Stefano Stabellini wrote:
> On Mon, 15 Jul 2024, Jan Beulich wrote:
>> On 13.07.2024 00:38, Stefano Stabellini wrote:
>>> On Wed, 3 Jul 2024, Jan Beulich wrote:
I further have to note that, as indicated during the earlier discussion,
I still cannot see how occasional
On 16/07/24 09:08, Jan Beulich wrote:
On 15.07.2024 18:48, Federico Serafini wrote:
Add break or pseudo keyword fallthrough to address violations of
MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
every switch-clause".
No functional change.
Signed-off-by: Federico Serafi
On 16/07/24 08:59, Jan Beulich wrote:
On 15.07.2024 18:48, Federico Serafini wrote:
This patch series fixes a missing escape in a deviation and addresses some
violations.
Federico Serafini (9):
automation/eclair: fix deviation of MISRA C Rule 16.3
x86/cpuid: use fallthrough pseudo keyword
On 15.07.2024 18:48, Federico Serafini wrote:
> Add break or pseudo keyword fallthrough to address violations of
> MISRA C Rule 16.3: "An unconditional `break' statement shall terminate
> every switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> Reviewed-by: Stefano
On 15.07.2024 18:48, Federico Serafini wrote:
> Add missing break statements to address violations of MISRA C Rule
> 16.3: "An unconditional `break' statement shall terminate every
> switch-clause".
>
> No functional change.
>
> Signed-off-by: Federico Serafini
> Reviewed-by: Stefano Stabellini
On 15.07.2024 18:48, Federico Serafini wrote:
> This patch series fixes a missing escape in a deviation and addresses some
> violations.
>
> Federico Serafini (9):
> automation/eclair: fix deviation of MISRA C Rule 16.3
> x86/cpuid: use fallthrough pseudo keyword
> x86/domctl: address a viol
41 matches
Mail list logo
