On 18.10.2023 02:48, Stefano Stabellini wrote:
> On Mon, 16 Oct 2023, Jan Beulich wrote:
>> On 29.09.2023 00:24, Stefano Stabellini wrote:
>>> If it is not a MISRA requirement, then I think we should go for the path
>>> of least resistance and try to make the smallest amount of changes
>>>
flight 183403 xen-unstable real [real]
flight 183406 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183403/
http://logs.test-lab.xenproject.org/osstest/logs/183406/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Roger,
> On Oct 17, 2023, at 16:29, Roger Pau Monne wrote:
>
> The mapping of memory regions below the 1MB mark was all done by the PVH dom0
> builder code, causing the region to be avoided by the arch specific IOMMU
> hardware domain initialization code. That lead to the IOMMU being
Hi Julien,
> On Oct 18, 2023, at 02:13, Julien Grall wrote:
>
> Hi Henry,
>
> On 17/10/2023 06:55, Henry Wang wrote:
>>> On Oct 14, 2023, at 02:22, Julien Grall wrote:
>>>
>>> Hi Henry,
>>>
>>> On 09/10/2023 02:03, Henry Wang wrote:
diff --git a/xen/arch/arm/include/asm/p2m.h
Hi Roger,
> On Oct 17, 2023, at 21:09, Roger Pau Monne wrote:
>
> SAGAW is a bitmap field, with bits 1 and 2 signaling support for AGAW 1 and
> AGAW 2 respectively. According to the Intel VT-d specification, an IOMMU
> might
> support multiple AGAW values.
>
> The AGAW value for each device
flight 183404 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183404/
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
On Tue, 17 Oct 2023, Julien Grall wrote:
> Hi Stefano,
>
> On 16/10/2023 21:47, Stefano Stabellini wrote:
> > On Mon, 16 Oct 2023, Bertrand Marquis wrote:
> > > > On 16 Oct 2023, at 15:38, Julien Grall wrote:
> > > >
> > > >
> > > >
> > > > On 16/10/2023 14:31, Bertrand Marquis wrote:
> > > >
On Mon, 16 Oct 2023, Jan Beulich wrote:
> On 29.09.2023 00:24, Stefano Stabellini wrote:
> > On Thu, 28 Sep 2023, Jan Beulich wrote:
> >> On 28.09.2023 15:17, Simone Ballarin wrote:
> >>> On 28/09/23 14:51, Jan Beulich wrote:
> On 28.09.2023 14:46, Simone Ballarin wrote:
> > On 13/09/23
From: David Woodhouse
The xencons_connect_backend() function allocates a local interdomain
event channel with xenbus_alloc_evtchn(), then calls
bind_interdomain_evtchn_to_irq_lateeoi() to bind to that port# on the
*remote* domain.
That doesn't work very well:
(qemu) device_add
flight 183399 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183399/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 12 debian-hvm-install fail in
183392 pass in 183399
On 17/10/2023 14:12, Philippe Mathieu-Daudé wrote:
Access to QemuInputHandlerState::handler are read-only.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/virtio/virtio-input.h | 2 +-
include/ui/input.h | 2 +-
chardev/msmouse.c| 2 +-
On Mon, 15 Oct 2023, Julien Grall wrote:
> On 16/10/2023 16:07, Bertrand Marquis wrote:
> > > On 16 Oct 2023, at 16:46, Julien Grall wrote:
> > > CC Henry
> > >
> > > Hi Alexey,
> > >
> > > On 16/10/2023 15:24, Alexey Klimov wrote:
> > > > On Mon, 16 Oct 2023 at 15:13, Luca Fancellu
> > > >
On Tue, 2023-10-17 at 19:25 +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> When QEMU is exiting, qemu_cleanup() calls net_cleanup(), which deletes
> the NIC from underneath the xen-net-device. When xen_netdev_unrealize()
> is later called via the xenbus exit notifier, it crashes.
>
>
This has been on my TODO list for a while, and Paul's since 2019. Having
converted the console driver just to get PV guests booting, I figured I
should do this one while I still remember how.
The fact that net_cleanup() frees my NIC from underneath me confused
me for a while. Not entirely sure
From: David Woodhouse
Signed-off-by: David Woodhouse
---
hw/net/meson.build| 2 +-
hw/net/trace-events | 9 +
hw/net/xen_nic.c | 426 +-
hw/xenpv/xen_machine_pv.c | 1 -
4 files changed, 342 insertions(+), 96 deletions(-)
diff
From: David Woodhouse
When the Xen guest asks to unplug *emulated* NICs, it's kind of unhelpful
also to unplug the peer of the *Xen* PV NIC.
Signed-off-by: David Woodhouse
---
hw/i386/xen/xen_platform.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
From: David Woodhouse
The default NIC creation seems a bit hackish to me. I don't understand
why each platform ha to call pci_nic_init_nofail() from a point in the
code where it actually has a pointer to the PCI bus, and then we have
the special cases for things like ne2k_isa.
If
From: David Woodhouse
When QEMU is exiting, qemu_cleanup() calls net_cleanup(), which deletes
the NIC from underneath the xen-net-device. When xen_netdev_unrealize()
is later called via the xenbus exit notifier, it crashes.
Signed-off-by: David Woodhouse
---
hw/net/xen_nic.c | 8 +++-
1
Hi Henry,
On 17/10/2023 06:55, Henry Wang wrote:
On Oct 14, 2023, at 02:22, Julien Grall wrote:
Hi Henry,
On 09/10/2023 02:03, Henry Wang wrote:
diff --git a/xen/arch/arm/include/asm/p2m.h b/xen/arch/arm/include/asm/p2m.h
index 940495d42b..a9622dac9a 100644
---
On Tue, 2023-10-17 at 12:21 +0200, Kevin Wolf wrote:
> Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> > From: David Woodhouse
> >
> > There's no need to force the user to assign a vdev. We can automatically
> > assign one, starting at xvda and searching until we find the first disk
>
On 10/10/23 14:51, Daniel P. Berrangé wrote:
> On Tue, Oct 10, 2023 at 02:41:22PM +0300, Dmitry Osipenko wrote:
>> On 9/15/23 14:11, Huang Rui wrote:
>>> Configure context init feature flag for virglrenderer.
>>>
>>> Originally-by: Antonio Caggiano
>>> Signed-off-by: Huang Rui
>>> ---
>>>
>>> V4
On 17/10/2023 18:26, Jan Beulich wrote:
On 17.10.2023 17:24, Nicola Vetrini wrote:
On 16/10/2023 16:52, Jan Beulich wrote:
On 09.10.2023 08:54, Nicola Vetrini wrote:
--- a/xen/include/xen/consoled.h
+++ b/xen/include/xen/consoled.h
@@ -12,7 +12,7 @@ size_t consoled_guest_tx(char c);
#else
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsistent usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc:
Introduce x86_64 %rip-relative addressing to PER_CPU_VAR macro.
Instructions using %rip-relative address operand are one byte shorter
than their absolute address counterparts and are also compatible with
position independent executable (-fpie) build. The patch reduces
code size of a test kernel
PER_CPU_VAR macro should be applied to a symbol and its addend.
Inconsistent usage is currently harmless, but needs to be corrected
before %rip-relative addressing is introduced to PER_CPU_VAR macro.
No functional changes intended.
Cc: Juergen Gross
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc:
On 17.10.2023 17:24, Nicola Vetrini wrote:
> On 16/10/2023 16:52, Jan Beulich wrote:
>> On 09.10.2023 08:54, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/consoled.h
>>> +++ b/xen/include/xen/consoled.h
>>> @@ -12,7 +12,7 @@ size_t consoled_guest_tx(char c);
>>>
>>> #else
>>>
>>> -size_t
Now, concrete action items. Nicola, I think we should look into having
a
larger-than-usual ECLAIR scan every week which includes all of Intel
files and in general as much as possible of the codebase.
This can be arranged. I'll keep you posted about this.
--
Nicola Vetrini, BSc
Software
On 16/10/2023 16:52, Jan Beulich wrote:
On 09.10.2023 08:54, Nicola Vetrini wrote:
--- a/xen/include/xen/consoled.h
+++ b/xen/include/xen/consoled.h
@@ -12,7 +12,7 @@ size_t consoled_guest_tx(char c);
#else
-size_t consoled_guest_tx(char c) { return 0; }
+static inline size_t
The page is pretty nice overall and I quite liked it. Just a few extra
questions below, as I'm not familiar with this side of things,
On Mon, Oct 16, 2023 at 05:24:50PM +0100, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper
> ---
> CC: George Dunlap
> CC: Jan Beulich
> CC: Stefano
flight 183395 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183395/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 183351
test-armhf-armhf-libvirt-raw 15
Hi,
On 17/10/2023 15:07, Michal Orzel wrote:
On 17/10/2023 14:52, Julien Grall wrote:
The macro load_paddr() requires to know the offset between the
physical location of Xen and the virtual location.
When using the MPU, x20 will always be 0. Rather than wasting
a register for a compile-time
flight 183393 linux-linus real [real]
flight 183401 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183393/
http://logs.test-lab.xenproject.org/osstest/logs/183401/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Julien,
On 17/10/2023 14:52, Julien Grall wrote:
>
>
> The macro load_paddr() requires to know the offset between the
> physical location of Xen and the virtual location.
>
> When using the MPU, x20 will always be 0. Rather than wasting
> a register for a compile-time constant value, it
On 16/10/23 10:53, Julien Grall wrote:
Hi,
On 13/10/2023 16:24, Federico Serafini wrote:
Add missing parameter names, no functional change.
Signed-off-by: Federico Serafini
---
xen/arch/arm/include/asm/gic.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git
On Tue, Oct 17, 2023 at 5:13 PM Philippe Mathieu-Daudé
wrote:
>
> Access to QemuInputHandlerState::handler are read-only.
>
> Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Marc-André Lureau
> ---
> include/hw/virtio/virtio-input.h | 2 +-
> include/ui/input.h | 2 +-
>
Hi Jan,
On 17/10/2023 07:11, Jan Beulich wrote:
On 16.10.2023 20:06, Julien Grall wrote:
Instead, it would be best to find a way to help Eclair to detect this is
not an issue and also improve readability. Would the following help Eclair?
diff --git a/xen/common/domain.c b/xen/common/domain.c
Access to QemuInputHandlerState::handler are read-only.
Signed-off-by: Philippe Mathieu-Daudé
---
include/hw/virtio/virtio-input.h | 2 +-
include/ui/input.h | 2 +-
chardev/msmouse.c| 2 +-
chardev/wctablet.c | 2 +-
hw/char/escc.c
SAGAW is a bitmap field, with bits 1 and 2 signaling support for AGAW 1 and
AGAW 2 respectively. According to the Intel VT-d specification, an IOMMU might
support multiple AGAW values.
The AGAW value for each device is set in the device context entry, however
there's a caveat related to the
The macro load_paddr() requires to know the offset between the
physical location of Xen and the virtual location.
When using the MPU, x20 will always be 0. Rather than wasting
a register for a compile-time constant value, it would be best if
we can avoid using load_paddr() altogher in the common
flight 183396 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183396/
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 183392 xen-unstable real [real]
flight 183398 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/183392/
http://logs.test-lab.xenproject.org/osstest/logs/183398/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 17.10.23 12:09, Andrew Cooper wrote:
On 17/10/2023 6:24 am, Juergen Gross wrote:
On 16.10.23 18:24, Andrew Cooper wrote:
+command to ``xenstored``. This instructs ``xenstored`` to connect to
the
+guest's xenstore ring, and fire the ``@introduceDomain`` watch. The
firing of
+this watch is
Am 16.10.2023 um 17:19 hat David Woodhouse geschrieben:
> From: David Woodhouse
>
> There's no need to force the user to assign a vdev. We can automatically
> assign one, starting at xvda and searching until we find the first disk
> name that's unused.
>
> This means we can now allow '-drive
On 17.10.2023 12:15, Andrew Cooper wrote:
> On 17/10/2023 7:34 am, Jan Beulich wrote:
>> On 16.10.2023 18:24, Andrew Cooper wrote:
>>> +Termination
>>> +---
>>> +
>>> +The VM runs for a period of time, but eventually stops. It can stop for a
>>> +number of reasons, including:
>>> +
>>> +
On 17/10/2023 7:34 am, Jan Beulich wrote:
> On 16.10.2023 18:24, Andrew Cooper wrote:
>> +Termination
>> +---
>> +
>> +The VM runs for a period of time, but eventually stops. It can stop for a
>> +number of reasons, including:
>> +
>> + * Directly at the guest kernel's request, via the
flight 183397 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183397/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 772ec92577a8c786b6c9f8643fa60f1cf893bcd9
baseline version:
ovmf
On 17/10/2023 6:24 am, Juergen Gross wrote:
> On 16.10.23 18:24, Andrew Cooper wrote:
>> +command to ``xenstored``. This instructs ``xenstored`` to connect to
>> the
>> +guest's xenstore ring, and fire the ``@introduceDomain`` watch. The
>> firing of
>> +this watch is the signal to all other
On 17.10.2023 11:43, Nicola Vetrini wrote:
> On 17/10/2023 10:26, Jan Beulich wrote:
>> On 17.10.2023 10:12, Nicola Vetrini wrote:
>>> On 17/10/2023 09:02, Jan Beulich wrote:
On 16.10.2023 18:05, Nicola Vetrini wrote:
> On 16/10/2023 17:45, Jan Beulich wrote:
>> On 12.10.2023 17:28,
Hi Stefano,
On 16/10/2023 21:47, Stefano Stabellini wrote:
On Mon, 16 Oct 2023, Bertrand Marquis wrote:
On 16 Oct 2023, at 15:38, Julien Grall wrote:
On 16/10/2023 14:31, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 16 Oct 2023, at 11:07, Julien Grall wrote:
Hi,
On 13/10/2023
On 16/10/2023 16:29, Jan Beulich wrote:
On 09.10.2023 08:54, Nicola Vetrini wrote:
--- a/xen/arch/x86/mm/mem_access.c
+++ b/xen/arch/x86/mm/mem_access.c
@@ -249,7 +249,7 @@ bool p2m_mem_access_check(paddr_t gpa, unsigned
long gla,
return (p2ma != p2m_access_n2rwx);
}
-int
On 17/10/2023 10:26, Jan Beulich wrote:
On 17.10.2023 10:12, Nicola Vetrini wrote:
On 17/10/2023 09:02, Jan Beulich wrote:
On 16.10.2023 18:05, Nicola Vetrini wrote:
On 16/10/2023 17:45, Jan Beulich wrote:
On 12.10.2023 17:28, Nicola Vetrini wrote:
The definition of MC_NCLASSES contained a
On Tue, Oct 17, 2023 at 11:21:47AM +0200, Jan Beulich wrote:
> On 17.10.2023 11:13, Roger Pau Monné wrote:
> > On Tue, Oct 17, 2023 at 08:50:45AM +0100, Andrew Cooper wrote:
> >> On 17/10/2023 8:44 am, Jan Beulich wrote:
> >>> On 13.10.2023 17:38, Alejandro Vallejo wrote:
> Fix adapted off
On 17/10/2023 10:13 am, Roger Pau Monné wrote:
> On Tue, Oct 17, 2023 at 08:50:45AM +0100, Andrew Cooper wrote:
>> On 17/10/2023 8:44 am, Jan Beulich wrote:
>>> On 13.10.2023 17:38, Alejandro Vallejo wrote:
Fix adapted off Linux's mailing list:
On 17.10.2023 11:13, Roger Pau Monné wrote:
> On Tue, Oct 17, 2023 at 08:50:45AM +0100, Andrew Cooper wrote:
>> On 17/10/2023 8:44 am, Jan Beulich wrote:
>>> On 13.10.2023 17:38, Alejandro Vallejo wrote:
Fix adapted off Linux's mailing list:
On Tue, Oct 17, 2023 at 08:50:45AM +0100, Andrew Cooper wrote:
> On 17/10/2023 8:44 am, Jan Beulich wrote:
> > On 13.10.2023 17:38, Alejandro Vallejo wrote:
> >> Fix adapted off Linux's mailing list:
> >>
> >> https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
On 16/10/2023 17:49, Jan Beulich wrote:
On 12.10.2023 17:28, Nicola Vetrini wrote:
--- a/xen/include/xen/types.h
+++ b/xen/include/xen/types.h
@@ -22,6 +22,14 @@ typedef signed long ssize_t;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
+/*
+ * Users of this macro are expected to pass a positive
The mapping of memory regions below the 1MB mark was all done by the PVH dom0
builder code, causing the region to be avoided by the arch specific IOMMU
hardware domain initialization code. That lead to the IOMMU being enabled
without reserved regions in the low 1MB identity mapped in the p2m for
On Mon, Oct 16, 2023 at 04:55:30PM +0200, Jan Beulich wrote:
> On 16.10.2023 16:51, Roger Pau Monné wrote:
> > On Mon, Oct 16, 2023 at 04:07:22PM +0200, Jan Beulich wrote:
> >> On 16.10.2023 15:51, Roger Pau Monné wrote:
> >>> On Mon, Oct 16, 2023 at 03:32:54PM +0200, Jan Beulich wrote:
> On
On 17.10.2023 10:12, Nicola Vetrini wrote:
> On 17/10/2023 09:02, Jan Beulich wrote:
>> On 16.10.2023 18:05, Nicola Vetrini wrote:
>>> On 16/10/2023 17:45, Jan Beulich wrote:
On 12.10.2023 17:28, Nicola Vetrini wrote:
> The definition of MC_NCLASSES contained a violation of MISRA C:2012
On 17/10/2023 08:51, Jan Beulich wrote:
On 16.10.2023 18:49, Nicola Vetrini wrote:
On 16/10/2023 15:43, Jan Beulich wrote:
On 11.10.2023 14:46, Nicola Vetrini wrote:
--- a/xen/include/xen/compiler.h
+++ b/xen/include/xen/compiler.h
@@ -109,13 +109,16 @@
#define offsetof(a,b)
On 17/10/2023 09:02, Jan Beulich wrote:
On 16.10.2023 18:05, Nicola Vetrini wrote:
On 16/10/2023 17:45, Jan Beulich wrote:
On 12.10.2023 17:28, Nicola Vetrini wrote:
The definition of MC_NCLASSES contained a violation of MISRA C:2012
Rule 10.1, therefore by moving it as an enumeration
On 30.08.2023 17:53, Alejandro Vallejo wrote:
> Currently there's a printk statement triggered when no ucode loading
> facilities are discovered. This statement should have severity INFO rather
> than WARNING because it's not reporting anything wrong. Warnings ought
> to be reserved for
On 17/10/2023 8:44 am, Jan Beulich wrote:
> On 13.10.2023 17:38, Alejandro Vallejo wrote:
>> Fix adapted off Linux's mailing list:
>>
>> https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
> Why reference the bug report when there's a proper commit
On 13.10.2023 17:38, Alejandro Vallejo wrote:
> Fix adapted off Linux's mailing list:
>
> https://lore.kernel.org/lkml/d99589f4-bc5d-430b-87b2-72c20370c...@exactcode.com/T/#u
Why reference the bug report when there's a proper commit (f454b18e07f5) now?
Plus in any event a short summary of the
On 16.10.2023 18:05, Nicola Vetrini wrote:
> On 16/10/2023 17:45, Jan Beulich wrote:
>> On 12.10.2023 17:28, Nicola Vetrini wrote:
>>> The definition of MC_NCLASSES contained a violation of MISRA C:2012
>>> Rule 10.1, therefore by moving it as an enumeration constant resolves
>>> the
>>>
On 16.10.2023 18:36, Nicola Vetrini wrote:
> On 16/10/2023 17:42, Jan Beulich wrote:
>> On 12.10.2023 17:28, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/io_apic.h
>>> +++ b/xen/arch/x86/include/asm/io_apic.h
>>> @@ -14,9 +14,10 @@
>>> * Copyright (C) 1997, 1998, 1999, 2000 Ingo
On 17.10.2023 00:34, Stefano Stabellini wrote:
> On Mon, 16 Oct 2023, Jan Beulich wrote:
>> On 09.10.2023 08:54, Nicola Vetrini wrote:
>>> As stated in rules.rst, functions used only in asm code
>>> are allowed to have no prior declaration visible when being
>>> defined, hence these functions are
On 16.10.2023 18:49, Nicola Vetrini wrote:
> On 16/10/2023 15:43, Jan Beulich wrote:
>> On 11.10.2023 14:46, Nicola Vetrini wrote:
>>> --- a/xen/include/xen/compiler.h
>>> +++ b/xen/include/xen/compiler.h
>>> @@ -109,13 +109,16 @@
>>>
>>> #define offsetof(a,b) __builtin_offsetof(a,b)
>>>
>>> +/*
On 16.10.2023 19:05, Nicola Vetrini wrote:
> On 16/10/2023 16:50, Jan Beulich wrote:
>> On 09.10.2023 08:54, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/include/asm/compat.h
>>> +++ b/xen/arch/x86/include/asm/compat.h
>>> @@ -13,6 +13,7 @@ typedef unsigned long full_ptr_t;
>>>
>>> struct domain;
On 16.10.2023 18:24, Andrew Cooper wrote:
> +Creation
> +
> +
> +Within Xen, the ``domain_create()`` function is used to allocate and perform
> +bare minimum construction of a domain. The :term:`control domain` accesses
> +this functionality via the ``DOMCTL_createdomain`` hypercall.
> +
flight 183394 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/183394/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a445e1a42ccf3cb9f70537c7cd80ece689bf4d9a
baseline version:
ovmf
On 16.10.2023 20:06, Julien Grall wrote:
> Instead, it would be best to find a way to help Eclair to detect this is
> not an issue and also improve readability. Would the following help Eclair?
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 30c227967345..ab16124eabd6 100644
>
On 12.10.2023 17:28, Nicola Vetrini wrote:
> BUILD_BUG_ON is the preferred way to induce a build error
> upon statically determined incorrect conditions.
>
> This also fixes a MISRA C:2012 Rule 10.1 violation in the
> previous formulation.
>
> Signed-off-by: Nicola Vetrini
Hmm, looking back
73 matches
Mail list logo
