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
>>> violation
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 e
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 (f454b18e07f5)
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 recoverable
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 constant
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) __builtin_offset
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 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 1
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 P
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 value.
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 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:
https://lore.kernel.org/lkml/d99589f4-b
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:
https://lore.kernel.org/lkml/d99589f
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 Lin
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 vi
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 p2m_set_altp2m
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 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, Ni
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 comp
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 a445e1a42ccf3cb9f7053
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 ``S
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:
>>> +
>>> + *
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 if=
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 t
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):
test-amd6
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 1
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 h
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 value
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 |
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
i
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 +-
> char
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 a/x
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 woul
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):
test-amd64-
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 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 saveresto
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 Stabellin
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 consoled_guest_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 Eng
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 console
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: Bori
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 bui
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: Da
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
-
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 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
> >
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
--- a/xen/arch/arm/include/asm/p2
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 fi
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 qmp_device_add(
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 a/hw/i386/xen/xe
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 --
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 w
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.
>
>
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
> > > > wro
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 +-
chardev/wctablet.
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
test-amd64-amd
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 xen-console,id=co
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 10
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:
> > > >
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 1
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 i
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 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 enabled
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):
test-amd6
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
>>> overall,
65 matches
Mail list logo
