Hi Stefano,
> On 23 Jul 2024, at 23:41, Stefano Stabellini wrote:
>
> In practice, we are already following R18.6 and we have zero violations
> reported by ECLAIR (there are some cautions being reported.)
>
> Signed-off-by: Stefano Stabellini
Acked-by: Bertrand Marquis
Cheers
Bertrand
>
>
On 18.07.2024 18:48, Andrew Cooper wrote:
> While the purpose of this series is patch 6, it has a side effect of reducing
> the number of system calls substantally.
>
> Using a strace of test-xenstore as an example, we go from this:
>
> rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[],
>
On 24.07.2024 08:07, Juergen Gross wrote:
> On 24.07.24 03:08, kernel test robot wrote:
>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
>> linux-next
>> head: 368990a7fe30737c990f628a60d26d9854a9e690
>> commit: 368990a7fe30737c990f628a60d26d9854a9e690 [12/12] xen: fix mult
On 23.07.2024 18:24, Alejandro Vallejo wrote:
> On Tue Jul 23, 2024 at 5:09 PM BST, Roger Pau Monné wrote:
>> On Tue, Jul 23, 2024 at 04:37:12PM +0100, Alejandro Vallejo wrote:
>>> On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
--- a/xen/arch/x86/include/asm/alternative.h
+++
On 2024-07-24 02:18, victorm.l...@amd.com wrote:
From: Victor Lira
Hi,
Add a script that extracts the names of symbols in linker scripts.
Signed-off-by: Victor Lira
---
Note:
Not included are the "." location name or symbol names enclosed in
quotes
since the files dont't use any.
---
Cc
On 24.07.24 03:08, kernel test robot wrote:
tree: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
head: 368990a7fe30737c990f628a60d26d9854a9e690
commit: 368990a7fe30737c990f628a60d26d9854a9e690 [12/12] xen: fix multicall
debug data referencing
config: x86_64-randconfig
On 24.07.2024 00:40, Stefano Stabellini wrote:
> On Tue, 23 Jul 2024, Jan Beulich wrote:
>> On 23.07.2024 10:15, Alessandro Zucchelli wrote:
>>> This section explains which format should be followed by header
>>> inclusion guards via a drop-down list of rules.
>>>
>>> No functional change.
>>>
>>>
(re-adding xen-devel@)
On 23.07.2024 14:57, Matthew Barnes wrote:
> On Mon, Jul 22, 2024 at 01:37:11PM +0200, Jan Beulich wrote:
>> On 19.07.2024 16:21, Matthew Barnes wrote:
>>> Currently, OVMF is hard-coded to set up a maximum of 64 vCPUs on
>>> startup.
>>>
>>> There are efforts to support a ma
On 23.07.2024 15:47, Alejandro Vallejo wrote:
> On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
>> +if ( (eax >> 16) != 0x8000 || eax < 0x8000U )
>> +blexit(L"In 64bit mode, but no extended CPUID leaves?!?");
>
> I'm not sure about the condition even for the old code. If
flight 186975 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186975/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 9bc7a361200215fc5065dfaa6d90d4eb50fec00c
baseline version:
ovmf f5901ff2a472a5418ee6f
flight 186971 xen-unstable real [real]
flight 186976 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186971/
http://logs.test-lab.xenproject.org/osstest/logs/186976/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm6
Hello,
Stefano, on IRC, suggested that I start a discussion on this mailing
list regarding my intention to bring up a fully function XEN on Apple
Silicon (M1 and beyond).
I am in the process of getting up to speed on your governance
policies, applied for Coverity access to use some of the known i
tree: https://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git linux-next
head: 368990a7fe30737c990f628a60d26d9854a9e690
commit: 368990a7fe30737c990f628a60d26d9854a9e690 [12/12] xen: fix multicall
debug data referencing
config: x86_64-randconfig-012-20240724
(https://download.01.org/0day-c
flight 186965 xen-4.19-testing real [real]
flight 186974 xen-4.19-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186965/
http://logs.test-lab.xenproject.org/osstest/logs/186974/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
From: Victor Lira
Add a script that extracts the names of symbols in linker scripts.
Signed-off-by: Victor Lira
---
Note:
Not included are the "." location name or symbol names enclosed in quotes
since the files dont't use any.
---
Cc: Stefano Stabellini
Cc: roberto.bagn...@bugseng.com
Cc: con
On Sat, 20 Jul 2024, Marek Marczykowski-Górecki wrote:
> `cp --preserve=xattr` doesn't work in docker when SELinux is enabled. It
> tries to set the "security.selinux" xattr, but SELinux (or overlay fs?)
> denies it.
> Workaround it by skipping selinux.selinux xattr copying.
>
> Signed-off-by: Ma
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> Edit inclusion guards in asm-generic header files in order to make them
> consistent with the estabilished naming convention.
>
> No functional change.
>
> Signed-off-by: Alessandro Zucchelli
Reviewed-by: Stefano Stabellini
On Tue, 23 Jul 2024, Jan Beulich wrote:
> On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> > This section explains which format should be followed by header
> > inclusion guards via a drop-down list of rules.
> >
> > No functional change.
> >
> > Signed-off-by: Alessandro Zucchelli
>
> As ind
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> This addresses violations of MISRA C:2012 Rule 4.10 which states as
> following: Precautions shall be taken in order to prevent the contents
> of a header file being included more than once.
>
> Changes are made for autogenerated header files: inc
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> From: Maria Celeste Cesario
>
> Modify creation rule for asm-offsets.h to conform to
> the new standard and to not generate conflicting guards
> between architectures (which is a violation of the directive).
> Modify generic-y creation rule to ge
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> From: Maria Celeste Cesario
>
> Modify creation rule for asm-offsets.h to conform to
> the new standard and to not generate conflicting guards
> between architectures (which is a violation of the directive).
> Modify generic-y creation rule to ge
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Amend generation script, add inclusion guards to address violations
> of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
> to prevent the contents of a header file being included more than
> once").
>
On Tue, 23 Jul 2024, Alessandro Zucchelli wrote:
> From: Simone Ballarin
>
> Some headers, under specific circumstances (documented in a comment at
> the beginning of the file), explicitly do not have strict inclusion
> guards: the caller is responsible for including them correctly.
>
> These fi
In practice, we are already following R18.6 and we have zero violations
reported by ECLAIR (there are some cautions being reported.)
Signed-off-by: Stefano Stabellini
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 80e5e972ad..0cb2fb8f24 100644
--- a/docs/misra/rules.rst
+++ b/doc
On Tue, 23 Jul 2024, Andrew Cooper wrote:
> Coverity complains about it being invalid. It turns out that it is a GCC-ism
> to treat ll and L equivalently. C99 only permits L to mean long double.
>
> Convert all uses of L in to alternatives, either l, ll or PRI.64 depending on
> the operand type.
This allows for marginally better code generation including the use of BT
rather than SHR/TEST.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/include/asm/apic.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/include
They're all within a 12 bit range of their respective bases, and this prevents
all the MSR coordinates being calculated in %rcx.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
There's one unpleasant surprise hidden:
add/remove: 0/0 grow/shrink: 2/6 up/down: 18/-99 (-81
flight 186970 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186970/
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
XenServer's instance of coverity complains of OVERFLOW_BEFORE_WIDEN in
mask_and_ack_level_ioapic_irq(), which is ultimately because of v being
unsigned long, and (1U << ...) being 32 bits.
Introduce a apic_tmr_read() helper like we already have for ISR and IRR, and
use it to remove the opencoded a
flight 186963 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186963/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 8 xen-bootfail REGR. vs. 186827
test-amd64-amd64-do
flight 186972 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186972/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f5901ff2a472a5418ee6ff790c3b86cf9c3f54f1
baseline version:
ovmf da591416ee8fddb1b691d
On 23/07/2024 18:28, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 19:25 +0200, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 16:49 +0100, Julien Grall wrote:
Hi Oleksii,
On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 12:02 +0200, Jan Beuli
On 2024-07-23 13:34, Andrew Cooper wrote:
On 23/07/2024 6:31 pm, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
On 2024-07-23 11:04, Anthony PERARD wrote:
On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
"$dev" needs to be set correctly
From: Nikola Jelic
Added PE/COFF generic image header which shall be used for EFI
application format for x86/risc-v. x86 and risc-v source shall be adjusted
to use this header in following commits. pe.h header is taken over from
linux kernel with minor changes in terms of formatting and structure
Coverity complains about it being invalid. It turns out that it is a GCC-ism
to treat ll and L equivalently. C99 only permits L to mean long double.
Convert all uses of L in to alternatives, either l, ll or PRI.64 depending on
the operand type. This in turn removes some unnecessary casts which
On 23/07/2024 6:31 pm, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
>> On 2024-07-23 11:04, Anthony PERARD wrote:
>>> On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
"$dev" needs to be set correctly for backendtype=phy as well as
>>
On Tue, 2024-07-23 at 11:04 -0400, Jason Andryuk wrote:
> On 2024-07-23 11:04, Anthony PERARD wrote:
> > On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
> > > "$dev" needs to be set correctly for backendtype=phy as well as
> > > backendtype=tap. Move the setting into the conditional
On Tue, 2024-07-23 at 19:25 +0200, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-23 at 16:49 +0100, Julien Grall wrote:
> > Hi Oleksii,
> >
> > On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
> > > On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> > > > On 23.07.2024 10:55, olek
On Tue, 2024-07-23 at 16:49 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> > > On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-07-23 at 10:36 +0200, Jan Beul
flight 186968 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186968/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf da591416ee8fddb1b691d157e3c61bdc7a994b79
baseline version:
ovmf f96298d75cebfe2a77071
On Mon, Jul 15, 2024 at 04:36:03PM +0100, Matthew Barnes wrote:
> Currently, lsevtchn aborts its event channel enumeration when it hits
> its first hypercall error, namely:
> * When an event channel doesn't exist at the specified port
> * When the event channel is owned by Xen
>
> lsevtchn does no
flight 186966 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186966/
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
On Tue Jul 23, 2024 at 5:09 PM BST, Roger Pau Monné wrote:
> On Tue, Jul 23, 2024 at 04:37:12PM +0100, Alejandro Vallejo wrote:
> > On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
> > > Clang will generate machine code that only resets the low 8 bits of %rdi
> > > between loop calls, le
On Tue, Jul 23, 2024 at 04:37:12PM +0100, Alejandro Vallejo wrote:
> On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
> > Yet another clang code generation issue when using altcalls.
> >
> > The issue this time is with using loop constructs around
> > alternative_{,v}call
> > instances
Hi Oleksii,
On 23/07/2024 16:36, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
On 23.07.2024 10:02, Oleksii Kurochko wrote:
On Mon, Jul 22, 2
On Tue, 2024-07-23 at 12:02 +0200, Jan Beulich wrote:
> On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> > > On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > > > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > > > wrote:
> > > > >
On Tue Jul 23, 2024 at 10:31 AM BST, Roger Pau Monne wrote:
> Yet another clang code generation issue when using altcalls.
>
> The issue this time is with using loop constructs around alternative_{,v}call
> instances using parameter types smaller than the register size.
>
> Given the following exam
On 2024-07-23 11:04, Anthony PERARD wrote:
On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
"$dev" needs to be set correctly for backendtype=phy as well as
backendtype=tap. Move the setting into the conditional, so it can be
handled properly for each.
(dev could be captured durin
On Mon, Jul 15, 2024 at 07:46:31PM -0400, Jason Andryuk wrote:
> "$dev" needs to be set correctly for backendtype=phy as well as
> backendtype=tap. Move the setting into the conditional, so it can be
> handled properly for each.
>
> (dev could be captured during tap-ctl allocate for blktap module
Hi,
I'm observing a crash like the one below when trying to resume from S3.
It happens on Xen nested in KVM (QEMU 9.0, Linux 6.9.3) but only on AMD.
The very same software stack on Intel works just fine. QEMU is running
with "-cpu host,+svm,+invtsc -machine q35,kernel-irqchip=split -device
amd-iom
On 23/07/2024 2:45 pm, Jason Andryuk wrote:
> On 2024-07-23 08:30, Juergen Gross wrote:
>> On 23.07.24 14:25, Andrew Cooper wrote:
>>> On 23/07/2024 10:37 am, Jürgen Groß wrote:
On 22.07.24 18:25, Andrew Cooper wrote:
> With the input data now conveniently arranged, use writev()/sendmsg()
On 2024-07-23 08:30, Juergen Gross wrote:
On 23.07.24 14:25, Andrew Cooper wrote:
On 23/07/2024 10:37 am, Jürgen Groß wrote:
On 22.07.24 18:25, Andrew Cooper wrote:
With the input data now conveniently arranged, use writev()/sendmsg()
instead
of decomposing it into write() calls.
This causes
On 2024-07-18 12:48, Andrew Cooper wrote:
It's very rude for a library to play with signals behind the back of the
application, no matter ones views on the default behaviour of SIGPIPE under
POSIX. Even if the application doesn't care about the xenstored socket, it my
care about others.
This lo
On 2024-07-23 08:08, Jürgen Groß wrote:
On 23.07.24 14:07, Andrew Cooper wrote:
On 23/07/2024 10:33 am, Jürgen Groß wrote:
On 18.07.24 18:48, Andrew Cooper wrote:
It will determine whether to use writev() or sendmsg().
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
-
Well, damn. At least it was found rather quickly.
On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
> EFI systems can run with NX disabled, as has been discovered on a Broadwell
> Supermicro X10SRM-TF system.
>
> Prior to commit fc3090a47b21 ("x86/boot: Clear XD_DISABLE from the early boot
flight 186964 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186964/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f96298d75cebfe2a7707157ed644eb86bf6d46ca
baseline version:
ovmf 46eb0ca29bf6bd84381af
On Mon Jul 22, 2024 at 11:18 AM BST, Andrew Cooper wrote:
> Make the "no extended leaves" case fatal and remove one level of indentation.
> Defer the max-leaf aquisition until it is first used.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monn
On 2024-07-18 12:48, Andrew Cooper wrote:
Right now there are two completely different struct xs_handle definitions,
depend on #ifdef USE_PTHREAD. One is especially well hidden, and often
escapes updates.
Rework struct xs_handle using some interior ifdefary. It's slightly longer,
but much easi
On Tue, 2024-07-23 at 14:33 +0100, Julien Grall wrote:
> On 23/07/2024 14:27, oleksii.kuroc...@gmail.com wrote:
> > Hello Julien,
>
> Hi Oleksii,
>
>
> > On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> > > > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> > > > index 7d09e781bf
On 2024-07-18 12:48, Andrew Cooper wrote:
We would like to writev() the whole outgoing message, which is hard given the
current need to prepend the locally-constructed xsd_sockmsg.
Instead, have the caller provide xsd_sockmsg in iovec[0]. This in turn drops
the t and type parameters from xs_tal
On Mon, 2024-07-22 at 19:04 +0200, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-07-22 at 17:25 +0200, Jan Beulich wrote:
> > On 22.07.2024 16:36, Oleksii wrote:
> > > On Mon, 2024-07-22 at 14:42 +0200, Jan Beulich wrote:
> > > > On 12.07.2024 18:22, Oleksii Kurochko wrote:
> > > > > --- a/xen/a
On 23/07/2024 14:27, oleksii.kuroc...@gmail.com wrote:
Hello Julien,
Hi Oleksii,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
index 7d09e781bf..d69a174b5d 100644
--- a/xen/arch/riscv/mm.c
+++ b/xen/arch/riscv/mm.c
@@ -49,6 +49
On 23/07/2024 13:58, oleksii.kuroc...@gmail.com wrote:
Hi Julien,
Hi Oleksii,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
+/* Fixmap slots */
+#define FIX_PMAP_BEGIN (0) /* Start of PMAP */
+#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of
PMAP */
... here i
Hello Julien,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> > diff --git a/xen/arch/riscv/mm.c b/xen/arch/riscv/mm.c
> > index 7d09e781bf..d69a174b5d 100644
> > --- a/xen/arch/riscv/mm.c
> > +++ b/xen/arch/riscv/mm.c
> > @@ -49,6 +49,9 @@ stage1_pgtbl_root[PAGETABLE_ENTRIES];
> > pte
Hi Julien,
On Sun, 2024-07-21 at 09:46 +0100, Julien Grall wrote:
> > +/* Fixmap slots */
> > +#define FIX_PMAP_BEGIN (0) /* Start of PMAP */
> > +#define FIX_PMAP_END (FIX_PMAP_BEGIN + NUM_FIX_PMAP - 1) /* End of
> > PMAP */
>
> ... here is seems to be inclusive. Furthermore if you had 32-bit
>
On 23.07.24 14:25, Andrew Cooper wrote:
On 23/07/2024 10:37 am, Jürgen Groß wrote:
On 22.07.24 18:25, Andrew Cooper wrote:
With the input data now conveniently arranged, use writev()/sendmsg()
instead
of decomposing it into write() calls.
This causes all requests to be submitted with a single
On 23/07/2024 10:37 am, Jürgen Groß wrote:
> On 22.07.24 18:25, Andrew Cooper wrote:
>> With the input data now conveniently arranged, use writev()/sendmsg()
>> instead
>> of decomposing it into write() calls.
>>
>> This causes all requests to be submitted with a single system call,
>> rather
>> th
On 23.07.24 14:07, Andrew Cooper wrote:
On 23/07/2024 10:33 am, Jürgen Groß wrote:
On 18.07.24 18:48, Andrew Cooper wrote:
It will determine whether to use writev() or sendmsg().
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/store/xs.c | 5 +
On 23/07/2024 10:33 am, Jürgen Groß wrote:
> On 18.07.24 18:48, Andrew Cooper wrote:
>> It will determine whether to use writev() or sendmsg().
>>
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Anthony PERARD
>> CC: Juergen Gross
>> ---
>> tools/libs/store/xs.c | 5 +
>> 1 file changed, 5
flight 186960 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186960/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186952
test-amd64-amd64-xl-qemut-win7-amd64
On 18.07.24 18:48, Andrew Cooper wrote:
It's very rude for a library to play with signals behind the back of the
application, no matter ones views on the default behaviour of SIGPIPE under
POSIX. Even if the application doesn't care about the xenstored socket, it my
care about others.
This logi
flight 186962 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186962/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 46eb0ca29bf6bd84381af8506e0d9b1755f767d9
baseline version:
ovmf c5ab17430b2579dd79e3c
Hi all,
Xen 4.19-rc4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.19.0-rc4
For your convenience there is also a tarball and the signature at:
https://downloads.xenproject.org/release/xen/4.19.0-rc4/xen-4.19.0-rc4.tar.gz
And the signature is at:
https://downloa
Rather than invoking make for individual .i and/or .i targets, it may be
desirable to simply add -save-temps to $(CFLAGS) for some (or all)
source files. That, however, triggers a tautological compare warning
with at least gcc13 / gcc14. Apparently such warnings are suppressed
when the compiler kno
On Tue, Jul 23, 2024 at 12:25:32PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Jul 22, 2024 at 11:18:38AM +0100, Andrew Cooper wrote:
> > EFI systems can run with NX disabled, as has been discovered on a Broadwell
> > Supermicro X10SRM-TF system.
> >
> > Prior to commit fc3090a47b21 ("x86/b
On Mon, Jul 22, 2024 at 11:18:38AM +0100, Andrew Cooper wrote:
> EFI systems can run with NX disabled, as has been discovered on a Broadwell
> Supermicro X10SRM-TF system.
>
> Prior to commit fc3090a47b21 ("x86/boot: Clear XD_DISABLE from the early boot
> path"), the logic to unlock NX was common
On Mon, Jul 22, 2024 at 11:18:37AM +0100, Andrew Cooper wrote:
> Make the "no extended leaves" case fatal and remove one level of indentation.
> Defer the max-leaf aquisition until it is first used.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Marek Marczykowski-Górecki
On 23.07.2024 11:31, Roger Pau Monne wrote:
> Yet another clang code generation issue when using altcalls.
>
> The issue this time is with using loop constructs around alternative_{,v}call
> instances using parameter types smaller than the register size.
>
> Given the following example code:
>
>
On 23.07.2024 10:55, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
>> On 23.07.2024 10:02, Oleksii Kurochko wrote:
>>> On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
>>> wrote:
>> On 22/07/2024 15:44, Oleksii Kurochko wrote:
> /* Map a 4k page
On Tue, 2024-07-23 at 11:31 +0200, Roger Pau Monne wrote:
> Yet another clang code generation issue when using altcalls.
>
> The issue this time is with using loop constructs around
> alternative_{,v}call
> instances using parameter types smaller than the register size.
>
> Given the following ex
On Tue, Jul 16, 2024 at 3:59 PM Jan Beulich wrote:
>
> 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_f
On Tue, Jul 16, 2024 at 3:51 PM Jan Beulich wrote:
>
> 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 +7
On Fri, Jul 12, 2024 at 2:27 PM Jan Beulich wrote:
>
> On 12.07.2024 15:07, Fouad Hilly wrote:
> > @@ -79,6 +81,8 @@ static void usage(FILE *stream, const char *name)
> > "options:\n"
> > " -h, --helpdisplay this help\n"
> > " -s, --show-cpu-inf
On 22.07.24 18:25, Andrew Cooper wrote:
With the input data now conveniently arranged, use writev()/sendmsg() instead
of decomposing it into write() calls.
This causes all requests to be submitted with a single system call, rather
than at least two. While in principle short writes can occur, th
On 18.07.24 18:48, Andrew Cooper wrote:
It will determine whether to use writev() or sendmsg().
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Juergen Gross
---
tools/libs/store/xs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/libs/store/xs.c b/tools/libs/store/
Yet another clang code generation issue when using altcalls.
The issue this time is with using loop constructs around alternative_{,v}call
instances using parameter types smaller than the register size.
Given the following example code:
static void bar(bool b)
{
unsigned int i;
for ( i
On 18.07.24 18:48, Andrew Cooper wrote:
Right now there are two completely different struct xs_handle definitions,
depend on #ifdef USE_PTHREAD. One is especially well hidden, and often
escapes updates.
Rework struct xs_handle using some interior ifdefary. It's slightly longer,
but much easier
On 18.07.24 18:48, Andrew Cooper wrote:
We would like to writev() the whole outgoing message, which is hard given the
current need to prepend the locally-constructed xsd_sockmsg.
Instead, have the caller provide xsd_sockmsg in iovec[0]. This in turn drops
the t and type parameters from xs_talkv
On Tue, 2024-07-23 at 10:36 +0200, Jan Beulich wrote:
> On 23.07.2024 10:02, Oleksii Kurochko wrote:
> > On Mon, Jul 22, 2024 at 7:27 PM Julien Grall
> > wrote:
> > > > > On 22/07/2024 15:44, Oleksii Kurochko wrote:
> > > > /* Map a 4k page in a fixmap entry */
> > > > void set_fixmap(unsi
flight 186959 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186959/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 186923
test-amd64-amd64-libvirt-xsm 15 migrate-s
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
> This section explains which format should be followed by header
> inclusion guards via a drop-down list of rules.
>
> No functional change.
>
> Signed-off-by: Alessandro Zucchelli
As indicated in reply to v4, this wants (imo needs) to move to t
On 23.07.2024 10:02, Oleksii Kurochko wrote:
> On Mon, Jul 22, 2024 at 7:27 PM Julien Grall wrote:
On 22/07/2024 15:44, Oleksii Kurochko wrote:
>>> /* Map a 4k page in a fixmap entry */
>>> void set_fixmap(unsigned map, mfn_t mfn, unsigned int flags)
>>> {
>>> pte_t pte;
>
From: Maria Celeste Cesario
Edit inclusion guards in order to make them consistent with the
estabilished naming conventions.
No functional change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Reviewed-by: Stefano Stabellini
Signed-off-by: Alessandro Zucchelli
---
C
This section explains which format should be followed by header
inclusion guards via a drop-down list of rules.
No functional change.
Signed-off-by: Alessandro Zucchelli
---
Changes in v5:
- edit inclusion guards naming conventions, according to feedback
received
---
CODING_STYLE | 21 ++
From: Maria Celeste Cesario
Modify creation rule for asm-offsets.h to conform to
the new standard and to not generate conflicting guards
between architectures (which is a violation of the directive).
Modify generic-y creation rule to generate code without violations
and to conform to the new stan
This addresses violations of MISRA C:2012 Rule 4.10 which states as
following: Precautions shall be taken in order to prevent the contents
of a header file being included more than once.
Changes are made for autogenerated header files: include/xen/compile.h
and include/xen/hypercall-defs.h.
No fu
From: Simone Ballarin
Amend inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
Inclusion guards must appear at the beginning of the headers
(comments are permitted a
From: Simone Ballarin
Amend generation script, add inclusion guards to address violations
of MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order
to prevent the contents of a header file being included more than
once").
This patch amends the Makefile adding the required inclusion gu
From: Maria Celeste Cesario
Add or modify inclusion guards to address violations of
MISRA C:2012 Directive 4.10 ("Precautions shall be taken in order to
prevent the contents of a header file being included more than once").
Mechanical change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by:
From: Nicola Vetrini
Add safe deviation for *.c files, as estabilished in past discussion.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-by: Nicola Vetrini
Signed-off-by: Alessandro Zucchelli
Reviewed-by: Stefano Stabellini
---
Changes in v4:
- split the
1 - 100 of 112 matches
Mail list logo
