flight 181806 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181806/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e674096accc8e57cd0dd84679905e1222423251e
baseline version:
ovmf
flight 181794 linux-linus real [real]
flight 181803 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181794/
http://logs.test-lab.xenproject.org/osstest/logs/181803/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 181802 ovmf real [real]
flight 181804 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181802/
http://logs.test-lab.xenproject.org/osstest/logs/181804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
flight 181791 xen-unstable real [real]
flight 181800 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181791/
http://logs.test-lab.xenproject.org/osstest/logs/181800/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 6/28/23 6:32 AM, Andrew Cooper wrote:
> Hello,
Hi Andrew,
> This wasn't a formal discussion point at XenSummit, but Oleksii pointed
> out that it was still a problem, hence this thread.
>
> As we take on more architectures, it becomes more and more important for
> things to be handled in a
flight 181798 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181798/
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
flight 181789 libvirt real [real]
flight 181796 libvirt real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/181789/
http://logs.test-lab.xenproject.org/osstest/logs/181796/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Notice 1
winpvdrvbuild.xenproject.org potentially compromised
ISSUE DESCRIPTION
=
Software running on the Xen Project hosted subdomain
winpvdrvbuild.xenproject.org is outdated and
On 13/07/2023 04:12, Penny Zheng wrote:
Thanks ayan for pointing out that RES0 is not suitable for storing
software-only flags, agreed.
Then, maybe we should refine the existing "struct pr_t" to store these
sw bits, like:
```
typedef union {
struct {
uint8_t tran:1; /*
Hi,
On 14/07/2023 08:04, Michal Orzel wrote:
Thanks. So, let's keep it as is and one day we may just choose a side
and do refactoring globally for consistency.
The series is now committed.
Cheers,
--
Julien Grall
Hi,
On 05/07/2023 23:55, Stefano Stabellini wrote:
On Tue, 4 Jul 2023, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
With enabling both CONFIG_UBSAN and CONFIG_IPMMU_VMSA I have got the following
splat when an IOMMU driver tried to setup page tables:
(XEN) ipmmu:
On Thu, Jul 13, 2023 at 02:18:29PM +0200, Jan Beulich wrote:
> On 13.07.2023 13:29, Roger Pau Monné wrote:
> > So to recap, I think we are in agreement that calling enable_IO_APIC()
> > just ahead of the call to setup_local_APIC() is the preferred
> > solution?
>
> Well, yes and no. My preferred
The current logic to init the local APIC and the IO-APIC does init the
local APIC LVTERR/ESR before doing any sanitation on the IO-APIC pin
configuration. It's already noted on enable_IO_APIC() that Xen
shouldn't trust the IO-APIC being empty at bootup.
At XenServer we have a system where the
On Tue, Jul 04, 2023 at 11:56:54AM +0200, Roger Pau Monné wrote:
> On Tue, Jul 04, 2023 at 10:37:38AM +0100, Anthony PERARD wrote:
> > On Wed, Jun 28, 2023 at 02:31:39PM +0200, Roger Pau Monné wrote:
> > > On Fri, Jun 23, 2023 at 03:04:21PM +, osstest service owner wrote:
> > > > flight 181558
On 14/07/23 16:32, Luca Fancellu wrote:
On 14 Jul 2023, at 15:20, Luca Fancellu wrote:
On 14 Jul 2023, at 12:49, Nicola Vetrini wrote:
The macro 'testop' expands to a function that declares the local
variable 'oldbit', which is written before being set, but is such a
way that is not
Hmm, I intended this to be xen/x86: as a subject.
Fixed locally, but I won't resend for just this.
~Andrew
On 14.07.2023 15:10, Andrew Cooper wrote:
> For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
> it is undefined behaviour to mutate them.
>
> Swap char *'s to const char *'s for variables which hold string literals.
>
> This fixes several violations of MISRA Rule
On 14.07.2023 15:04, Andrew Cooper wrote:
> Typedef-ing a naked pointer like this an anti-pattern which is best avoided.
> Furthermore, it's bad to pass a string literate in a mutable type. Delete the
> type entirely, and replace it with a plain 'const char *'.
>
> This highlights two futher
>>> "id": "SAF-2-safe",
>>> +"analyser": {
>>> +"eclair": "MC3R1.R9.1"
>>> +},
>>> +"name": "Rule 9.1: initializer not needed",
>>> +"text": "The following local variables are possibly subject to
>>> being read before
> On 14 Jul 2023, at 15:20, Luca Fancellu wrote:
>
>
>
>> On 14 Jul 2023, at 12:49, Nicola Vetrini wrote:
>>
>> The macro 'testop' expands to a function that declares the local
>> variable 'oldbit', which is written before being set, but is such a
>> way that is not amenable to automatic
> On 14 Jul 2023, at 12:49, Nicola Vetrini wrote:
>
> The macro 'testop' expands to a function that declares the local
> variable 'oldbit', which is written before being set, but is such a
> way that is not amenable to automatic checking.
>
> Therefore, a deviation comment, is introduced to
On 14/07/2023 2:44 pm, Nicola Vetrini wrote:
>
> On 14/07/23 15:04, Andrew Cooper wrote:
>> Typedef-ing a naked pointer like this an anti-pattern which is best
>> avoided.
>
> s/this an/this is an/
>
>> Furthermore, it's bad to pass a string literate in a mutable type.
>> Delete the
>
>
On 14/07/23 15:04, Andrew Cooper wrote:
Typedef-ing a naked pointer like this an anti-pattern which is best avoided.
s/this an/this is an/
Furthermore, it's bad to pass a string literate in a mutable type. Delete the
s/literate/literal/
type entirely, and replace it with a plain
Hi Andrew,
On 14/07/2023 14:10, Andrew Cooper wrote:
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule
Hi Andrew,
On 14/07/2023 11:59, Andrew Cooper wrote:
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule
Hi,
On 14/07/2023 12:49, Nicola Vetrini wrote:
This patch aims to fix some occurrences of possibly uninitialized
variables, that may be read before being written. This behaviour would
violate MISRA C:2012 Rule 9.1, besides being generally undesirable.
In all the analyzed cases, such accesses
There are no callers, and the non-stub implementation is #if 0'd out, with the
internal trying to perform an AML invocation.
There's no plausible way that code is getting un-#if 0'd, so drop it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC:
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an
Hi,
On 14/07/2023 12:49, Nicola Vetrini wrote:
The macro 'testop' expands to a function that declares the local
variable 'oldbit', which is written before being set, but is such a
way that is not amenable to automatic checking.
The code is pretty straightforward. So I am not entirely sure why
Typedef-ing a naked pointer like this an anti-pattern which is best avoided.
Furthermore, it's bad to pass a string literate in a mutable type. Delete the
type entirely, and replace it with a plain 'const char *'.
This highlights two futher bugs. acpi_get_table() already had a mismatch in
types
Hi Nicola,
On 14/07/2023 12:49, Nicola Vetrini wrote:
This patch aims to fix some occurrences of possibly uninitialized
variables, that may be read before being written. This behaviour would
violate MISRA C:2012 Rule 9.1, besides being generally undesirable.
In all the analyzed cases, such
This patch aims to fix some occurrences of possibly uninitialized
variables, that may be read before being written. This behaviour would
violate MISRA C:2012 Rule 9.1, besides being generally undesirable.
In all the analyzed cases, such accesses were actually safe, but it's
quite difficult to
The function 'guest_walk_tables' contains an initialization
pattern for the pointee of parameter 'perms' that is not easy
for automatic checkers to reason about.
A modified pattern that does not alter the semantics of the
code is introduced.
A const qualifier is added in 'xen/arch/arm/dm.c'
The macro 'testop' expands to a function that declares the local
variable 'oldbit', which is written before being set, but is such a
way that is not amenable to automatic checking.
Therefore, a deviation comment, is introduced to document this situation.
A similar reasoning applies to macro
This patch aims to fix some occurrences of possibly uninitialized
variables, that may be read before being written. This behaviour would
violate MISRA C:2012 Rule 9.1, besides being generally undesirable.
In all the analyzed cases, such accesses were actually safe, but it's
quite difficult to
This patch series is aimed at discussing different categories of
patterns concerning local variables that are possibly not
initialized in all code paths, which results in hard-to-prove
correctness. The main categories are as follows:
1. Variables initialized by passing a pointer to them to a
flight 181783 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/181783/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 22 guest-start/debian.repeat fail REGR. vs. 180278
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an
For pre-ANSI-C compatibility reasons, string literals have a mutable type, but
it is undefined behaviour to mutate them.
Swap char *'s to const char *'s for variables which hold string literals.
This fixes several violations of MISRA Rule 7.4:
A string literal shall not be assigned to an
On 14.07.2023 12:27, Alejandro Vallejo wrote:
> On Thu, Jul 13, 2023 at 05:12:09PM +0200, Jan Beulich wrote:
>> On 07.07.2023 18:07, Alejandro Vallejo wrote:
>>> --- a/xen/include/xen/mm.h
>>> +++ b/xen/include/xen/mm.h
>>> @@ -31,6 +31,17 @@
>>> * (i.e. all devices assigned to) a guest share
Hi,
On Thu, Jul 13, 2023 at 05:12:09PM +0200, Jan Beulich wrote:
> On 07.07.2023 18:07, Alejandro Vallejo wrote:
> > --- a/xen/include/xen/mm.h
> > +++ b/xen/include/xen/mm.h
> > @@ -31,6 +31,17 @@
> > * (i.e. all devices assigned to) a guest share a single DMA address
> > space
> > *
The issue that this patch attempts to address is S3 related.
Currently, suspending a XEN guest multiple times does not work.
This happens because PIIX4 PM io space gets unmapped during S3
resume and any accesses performed to trigger subsequent suspends
are not handled. So, the guest spins on the
Hi Jan,
On 11/07/2023 13:29, Jan Beulich wrote:
On 10.07.2023 22:59, Julien Grall wrote:
---
I'm not really certain about XEN_DOMCTL_irq_permission: With pIRQ-s not
used, the prior pIRQ -> IRQ translation cannot have succeeded on Arm, so
quite possibly the entire domctl is unused there? Yet
Hi,
On 14/07/2023 07:56, Jan Beulich wrote:
On 13.07.2023 19:49, Oleksii wrote:
On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote:
On 13.07.2023 15:36, Oleksii wrote:
On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
I don't understand. My earlier comment was affecting all checks
of
On 14.07.2023 10:10, Federico Serafini wrote:
> Change parameter names in function definitions to match the
> corresponding delcarations thus fixing violations of MISRA C:2012
> Rule 8.3 ("All declarations of an object or function shall use the same
> names and type qualifiers").
>
>
Change parameter names in function definitions to match the
corresponding delcarations thus fixing violations of MISRA C:2012
Rule 8.3 ("All declarations of an object or function shall use the same
names and type qualifiers").
Signed-off-by: Federico Serafini
---
xen/arch/x86/cpu/mcheck/mce.c
Hi
Am 13.07.23 um 17:14 schrieb Tvrtko Ursulin:
On 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this
On 14.07.2023 05:44, Elliott Mitchell wrote:
> On Fri, Jul 14, 2023 at 03:24:59AM +0200, Marek Marczykowski-Górecki wrote:
>> On Thu, Jul 13, 2023 at 05:16:40PM -0700, Elliott Mitchell wrote:
>>> The better to encourage moving to setting via string mode names.
>>
>> The numeric values needs to
Hi Julien,
On 13/07/2023 20:15, Julien Grall wrote:
>
>
> On 12/07/2023 08:01, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>>
>> On 11/07/2023 18:07, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 11/07/2023 09:29, Michal Orzel wrote:
At the moment, we limit the allocation
On 13.07.2023 19:49, Oleksii wrote:
> On Thu, 2023-07-13 at 16:26 +0200, Jan Beulich wrote:
>> On 13.07.2023 15:36, Oleksii wrote:
>>> On Thu, 2023-07-13 at 15:27 +0200, Jan Beulich wrote:
I don't understand. My earlier comment was affecting all checks
of
uart->irq alike, as I'm
On 13.07.2023 18:47, Elliott Mitchell wrote:
> On Thu, Jul 13, 2023 at 03:12:55PM +0200, Jan Beulich wrote:
>> On 17.03.2023 20:53, Elliott Mitchell wrote:
>>> --- a/xen/arch/x86/apic.c
>>> +++ b/xen/arch/x86/apic.c
>>> @@ -1419,12 +1420,13 @@ static void cf_check error_interrupt(struct
>>>
On Sat, Jul 8, 2023 at 11:47 AM Stefano Stabellini
wrote:
> On Sat, 1 Jul 2023, Christopher Clark wrote:
> > To convert the x86 boot logic from multiboot to boot module structures,
> > change the bootstrap map function to accept a boot module parameter.
> >
> > To allow incremental change from
52 matches
Mail list logo
