The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task to __{start,end}_init_stack.
Note other arch
On 18.03.24 08:14, Xin Li (Intel) wrote:
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rename __{start,end}_init_task to
flight 185069 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185062
test-amd64-amd64-xl-qemuu-win7-amd64
On 15.03.2024 15:45, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 2:13 PM Jan Beulich wrote:
>> On 15.03.2024 14:55, Julien Grall wrote:
>>> On 15/03/2024 13:24, Jan Beulich wrote:
On 15.03.2024 13:17, George Dunlap wrote:
> On Fri, Mar 15, 2024 at 11:57 AM Jan Beulich wrote:
>>> I
On 15.03.2024 19:05, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/configs/tiny64_defconfig
> +++ b/xen/arch/riscv/configs/tiny64_defconfig
> @@ -7,6 +7,23 @@
> # CONFIG_GRANT_TABLE is not set
> # CONFIG_SPECULATIVE_HARDEN_ARRAY is not set
> # CONFIG_MEM_ACCESS is not set
> +# CONFIG_ARGO is no
On 3/14/24 17:04, Jan Beulich wrote:
On 13.03.2024 17:41, Vaishali Thakkar wrote:
The suffix _guest is redundant for asid bit. Drop it
to avoid adding extra code volume.
While we're here, replace 0/1 with false/true and use
VMCB accessors instead of open coding.
Suggested-by: Andrew Cooper
Si
On 16.03.2024 01:43, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:59, Stefano Stabellini wrote:
>>> On Mon, 11 Mar 2024, Simone Ballarin wrote:
On 11/03/24 14:56, Jan Beulich wrote:
> On 11.03.2024 13:00, Simone Ballarin wrote:
>> On 11/03/24
On 16.03.2024 01:07, Stefano Stabellini wrote:
> On Fri, 15 Mar 2024, Jan Beulich wrote:
>> On 14.03.2024 23:17, Stefano Stabellini wrote:
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document these assumptions.
>>
>> My prior reservation wrt exact vs
On 14.03.2024 19:51, Andrew Cooper wrote:
> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
>>> On 13.03.2024 18:27, Andrew Cooper wrote:
--- a/xen/drivers/passthrough/x86/iommu.c
+++ b/xen/drivers/passthrough/x86/iommu.c
@@ -641,7 +641,7 @@ s
On Fri, Mar 15, 2024 at 07:57:04PM +, Andrew Cooper wrote:
> Right now, check_nmi_watchdog() has two processing loops over all online CPUs
> using prev_nmi_count as storage.
>
> Use a cpumask_t instead (1/32th as much initdata) and have wait_for_nmis()
> make the determination of whether it is
On Fri, Mar 15, 2024 at 12:13:22PM +, Andrew Cooper wrote:
> The use of __clear_bit() forces dmask to be spilled to the stack, and
> interferes with the compiler heuristcs for some upcoming improvements to the
> ffs() code generation.
>
> First, shrink dmask to just the active vectors by makin
On Fri, Mar 15, 2024 at 03:48:46PM +, Anthony PERARD wrote:
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/osstest.git br.linux-6.1-v2
>
> Hi,
>
> A set of patch which lead to using Linux 6.1 instead of 4.19 as a default
> kernel on x86.
>
> I'
I can only guess that using block_speculation() there was a leftover
from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
SPECULATIVE_HARDEN_BRANCH.
Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always
inline")
Signed-off-by: Jan Beulich
---
Noticed while backporting to 4.
The start/stop1/etc linkage scheme predates struct virtual_region, and as
setup_virtual_regions() shows, it's awkward to express in the new scheme.
Change the linker to provide explicit start/stop symbols for each bugframe
type, and change virtual_region to have a stop pointer rather than a count.
Bugframe linkage is identical in all architectures. This is not surprising
given that it is (now) only consumed by common/virtual_region.c
Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
structure.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beuli
All other actions it used to perform have been converted to build-time
initialisation. The extable setup can done at build time too.
This is one fewer setup step required to get exceptions working.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
CC: Stefano S
Given 3 statically initialised objects, its easy to link the list at build
time. There's no need to do it during runtime at boot (and with IRQs-off,
even).
As a consequence, register_virtual_region() can now move inside ifdef
CONFIG_LIVEPATCH like unregister_virtual_region().
Signed-off-by: Andr
There is nothing that setup_virtual_regions() does which can't be done at
build time. Make this happen.
Importantly, this removes logic from needed prior to setting up exceptions.
Andrew Cooper (4):
xen/link: Introduce a common BUGFRAMES definition
xen/virtual-region: Rework how bugframe lin
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted to
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter
On Mon, Mar 18, 2024 at 11:54 AM Nicola Vetrini
wrote:
>
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future use
On Mon, Mar 18, 2024 at 11:42:43AM +0100, Roger Pau Monné wrote:
> On Fri, Mar 15, 2024 at 03:48:46PM +, Anthony PERARD wrote:
> > Anthony PERARD (3):
> > make-fligh: Fix freebsd guest test test-id
> > mfi-common: Rework toolstack-disk_format test matrix
> > ap-common: Switch to Linux 6.1
On 18/03/2024 10:54 am, Jan Beulich wrote:
> I can only guess that using block_speculation() there was a leftover
> from, earlier on, SPECULATIVE_HARDEN_LOCK depending on
> SPECULATIVE_HARDEN_BRANCH.
>
> Fixes: 197ecd838a2a ("locking: attempt to ensure lock wrappers are always
> inline")
> Signed-
On 18/03/2024 9:13 am, Jan Beulich wrote:
> On 14.03.2024 19:51, Andrew Cooper wrote:
>> On 14/03/2024 6:47 pm, Andrew Cooper wrote:
>>> On 14/03/2024 2:30 pm, Jan Beulich wrote:
On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/p
flight 185071 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185071/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit1 18 guest-start/debian.repeat fail in 185063 REGR.
vs. 184921
Tests whic
On 15.03.2024 16:55, Nicola Vetrini wrote:
> Delete unused functions from 'iommu_guest.c'.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini
> ---
> guest_iommu_add_ptr_log has still one caller, but even that seems
> suspicious.
As said, it should be dropped. You remove ...
> -/* Dom
On 18.03.2024 12:04, Andrew Cooper wrote:
> Bugframe linkage is identical in all architectures. This is not surprising
> given that it is (now) only consumed by common/virtual_region.c
>
> Introduce a common BUGFRAMES define in xen.lds.h ahead of rearranging their
> structure.
>
> No functional
On 18.03.2024 12:04, Andrew Cooper wrote:
> The start/stop1/etc linkage scheme predates struct virtual_region, and as
> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>
> Change the linker to provide explicit start/stop symbols for each bugframe
> type, and change virtua
On 18/03/2024 1:17 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> The start/stop1/etc linkage scheme predates struct virtual_region, and as
>> setup_virtual_regions() shows, it's awkward to express in the new scheme.
>>
>> Change the linker to provide explicit start/stop symb
On 18.03.2024 12:04, Andrew Cooper wrote:
> Given 3 statically initialised objects, its easy to link the list at build
> time. There's no need to do it during runtime at boot (and with IRQs-off,
> even).
Hmm, technically that's correct, but isn't the overall result more fragile,
in being more err
On 18.03.2024 12:04, Andrew Cooper wrote:
> --- a/xen/common/virtual_region.c
> +++ b/xen/common/virtual_region.c
> @@ -39,6 +39,11 @@ static struct virtual_region core = {
> { __start_bug_frames_2, __stop_bug_frames_2 },
> { __start_bug_frames_3, __stop_bug_frames_3 },
> },
On 18.03.2024 14:24, Andrew Cooper wrote:
> On 18/03/2024 1:17 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -9,12 +9,25 @@
>>> #include
>>> #include
>>>
>>> +extern const struct bug_frame
On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> It will be useful for error reporting in a subsequent patch.
>
> Signed-off-by: Marek Marczykowski-Górecki
In principle
Acked-by: Jan Beulich
However, ...
> --- a/xen/drivers/passthrough/iommu.c
> +++ b/xen/drivers/passthrough/iommu.c
>
On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> The IOMMU driver checks if RMRR/IVMD are marked as reserved in memory
> map. This should be true for addresses coming from the firmware, but
> when extra pages used by Xen itself are included in the mapping, those
> are taken from usable RAM
On 18/03/2024 1:29 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> --- a/xen/common/virtual_region.c
>> +++ b/xen/common/virtual_region.c
>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>> { __start_bug_frames_2, __stop_bug_frames_2 },
>> { __star
On 18/03/2024 1:25 pm, Jan Beulich wrote:
> On 18.03.2024 12:04, Andrew Cooper wrote:
>> Given 3 statically initialised objects, its easy to link the list at build
>> time. There's no need to do it during runtime at boot (and with IRQs-off,
>> even).
> Hmm, technically that's correct, but isn't th
On 13.03.2024 13:24, George Dunlap wrote:
> Currently (nested) SVM features we're willing to expose to the guest
> are defined in calculate_host_policy, and stored in host_cpu_policy.
> This is the wrong place for this; move it into
> calculate_hvm_max_policy(), and store it in hvm_max_cpu_policy.
On 13.03.2024 13:24, George Dunlap wrote:
> The primary purpose of TSC scaling, from our perspective, is to
> maintain the fiction of an "invariant TSC" across migrates between
> platforms with different clock speeds.
>
> On AMD, the TscRateMSR CPUID bit is unconditionally enabled in the
> "host c
On 13.03.2024 13:24, George Dunlap wrote:
> In order to make implementation and testing tractable, we will require
> specific host functionality. Add a nested_virt bit to hvm_funcs.caps,
> and return an error if a domain is created with nested virt and this
> bit isn't set. Create VMX and SVM cal
On 18.03.2024 14:49, Andrew Cooper wrote:
> On 18/03/2024 1:29 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> --- a/xen/common/virtual_region.c
>>> +++ b/xen/common/virtual_region.c
>>> @@ -39,6 +39,11 @@ static struct virtual_region core = {
>>> { __start_bug_fram
On 18.03.2024 14:54, Andrew Cooper wrote:
> On 18/03/2024 1:25 pm, Jan Beulich wrote:
>> On 18.03.2024 12:04, Andrew Cooper wrote:
>>> Given 3 statically initialised objects, its easy to link the list at build
>>> time. There's no need to do it during runtime at boot (and with IRQs-off,
>>> even).
On 14.03.2024 08:20, Juergen Gross wrote:
> Introduce a new type "rspinlock_t" to be used for recursive spinlocks.
>
> For now it is only an alias of spinlock_t, so both types can still be
> used for recursive spinlocks. This will be changed later, though.
>
> Switch all recursive spinlocks to th
On Mon, 2024-03-18 at 08:54 +0100, Jan Beulich wrote:
> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > --- a/xen/arch/riscv/configs/tiny64_defconfig
> > +++ b/xen/arch/riscv/configs/tiny64_defconfig
> > @@ -7,6 +7,23 @@
> > # CONFIG_GRANT_TABLE is not set
> > # CONFIG_SPECULATIVE_HARDEN_ARRAY i
On 14.03.2024 08:20, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
> rspin_unlock_irqrestore() for the console lock, add those functions
> to spinlock handling and use them where needed.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with two remarks:
> -
On 14.03.2024 08:20, Juergen Gross wrote:
> Add another function level in spinlock.c hiding the spinlock_t layout
> from the low level locking code.
>
> This is done in preparation of introducing rspinlock_t for recursive
> locks without having to duplicate all of the locking code.
>
> Signed-off
On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
> spinlock_tickets_t *t)
>
> int _spin_is_locked(const spinlock_t *lock)
> {
> -/*
> - * Recursive locks ma
On 14.03.2024 08:20, Juergen Gross wrote:
> Recursive and normal spinlocks are sharing the same data structure for
> representation of the lock. This has two major disadvantages:
>
> - it is not clear from the definition of a lock, whether it is intended
> to be used recursive or not, while a mi
On 14.03.2024 08:20, Juergen Gross wrote:
> Switch the remaining trylock and is_locked variants to return bool.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
On 14.03.2024 08:20, Juergen Gross wrote:
> --- a/xen/include/xen/spinlock.h
> +++ b/xen/include/xen/spinlock.h
> @@ -8,16 +8,16 @@
> #include
> #include
>
> -#define SPINLOCK_CPU_BITS 12
> +#define SPINLOCK_CPU_BITS 16
>
> #ifdef CONFIG_DEBUG_LOCKS
> union lock_debug {
> -uint16_t
On 18.03.24 15:57, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
spinlock_tickets_t *t)
int _spin_is_locked(const spinlock_t *lock)
{
-/*
On 14.03.2024 08:20, Juergen Gross wrote:
> The rwlock handling is limiting the number of cpus to 4095 today. The
> main reason is the use of the atomic_t data type for the main lock
> handling, which needs 2 bits for the locking state (writer waiting or
> write locked), 12 bits for the id of a pos
On 18.03.2024 16:31, Jürgen Groß wrote:
> On 18.03.24 15:57, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
>>> spinlock_tickets_t *t)
>>>
On 18.03.24 16:44, Jan Beulich wrote:
On 18.03.2024 16:31, Jürgen Groß wrote:
On 18.03.24 15:57, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -395,14 +395,7 @@ static bool always_inline spin_is_locked_common(const
spin
On Mon, Mar 18, 2024 at 02:40:21PM +0100, Jan Beulich wrote:
> On 12.03.2024 17:25, Marek Marczykowski-Górecki wrote:
> > It will be useful for error reporting in a subsequent patch.
> >
> > Signed-off-by: Marek Marczykowski-Górecki
>
> In principle
> Acked-by: Jan Beulich
> However, ...
>
> >
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
Reviewed-by: Jan
On 18.03.24 16:08, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
--- a/xen/include/xen/spinlock.h
+++ b/xen/include/xen/spinlock.h
@@ -8,16 +8,16 @@
#include
#include
-#define SPINLOCK_CPU_BITS 12
+#define SPINLOCK_CPU_BITS 16
#ifdef CONFIG_DEBUG_LOCKS
union lo
On 18.03.2024 16:55, Jürgen Groß wrote:
> On 18.03.24 15:43, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> Instead of special casing rspin_lock_irqsave() and
>>> rspin_unlock_irqrestore() for the console lock, add those functions
>>> to spinlock handling and use them where nee
On 18.03.24 16:39, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
The rwlock handling is limiting the number of cpus to 4095 today. The
main reason is the use of the atomic_t data type for the main lock
handling, which needs 2 bits for the locking state (writer waiting or
write loc
On 18.03.2024 17:00, Jürgen Groß wrote:
> On 18.03.24 16:39, Jan Beulich wrote:
>> On 14.03.2024 08:20, Juergen Gross wrote:
>>> @@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
>>>
>>> static inline bool _is_write_locked_by_me(unsigned int cnts)
>>> {
>>> -BUILD_BUG_O
On 18.03.24 16:59, Jan Beulich wrote:
On 18.03.2024 16:55, Jürgen Groß wrote:
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handl
On 18.03.24 17:05, Jan Beulich wrote:
On 18.03.2024 17:00, Jürgen Groß wrote:
On 18.03.24 16:39, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
@@ -36,14 +36,16 @@ void queue_write_lock_slowpath(rwlock_t *lock);
static inline bool _is_write_locked_by_me(unsigned int cnts)
On 18.03.2024 17:05, Jürgen Groß wrote:
> On 18.03.24 16:59, Jan Beulich wrote:
>> On 18.03.2024 16:55, Jürgen Groß wrote:
>>> On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
> rspin_unlock_irqrestore(
On 18.03.24 17:08, Jan Beulich wrote:
On 18.03.2024 17:05, Jürgen Groß wrote:
On 18.03.24 16:59, Jan Beulich wrote:
On 18.03.2024 16:55, Jürgen Groß wrote:
On 18.03.24 15:43, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin
flight 185081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185081/
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 185072 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185072/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-libvirt-raw 17 guest-start/debian.repeat fail in 185061 pass
in 185072
test-amd64-amd64-xl-qe
Rework the trace API to unify it (remove the HVM specific obfuscation), and
remove MISRA violations.
v3:
* Delete TRACE_PARAM64()
Andrew Cooper (7):
xen/trace: Introduce new API
xen/credit2: Clean up trace handling
xen/rt: Clean up trace handling
xen/sched: Clean up trace handling
xen:
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *. Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Dario Faggioli
---
CC: Georg
There is no need for bitfields anywhere - use more sensible types. There is
also no need to cast 'd' to (unsigned char *) before passing it to a function
taking void *. Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
Reviewed-by: Dar
This logically drops the cycles parameter, as it's now encoded directly in the
event code.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall
CC: Nicola Vetrini
CC: consult...@bugseng.com
v3
trace() and trace_time(), in function form for struct arguments, and macro
form for simple uint32_t list arguments.
This will be used to clean up the mess of macros which exists throughout the
codebase, as well as eventually dropping __trace_var().
There is intentionally no macro to split a 64-bi
Most uses of bitfields and __packed are unnecessary. There is also no need to
cast 'd' to (unsigned char *) before passing it to a function taking void *.
Switch to new trace_time() API.
No functional change.
Signed-off-by: Andrew Cooper
Reviewed-by: Dario Faggioli
---
CC: George Dunlap
CC: J
(Almost) no functional change.
irq_move_cleanup_interrupt() changes two smp_processor_id() calls to the 'me'
local variable which manifests as a minor code improvement. All other
differences in the compiled binary are to do with line numbers changing.
Some conversion notes:
* HVMTRACE_LONG_[234
With all users updated to the new API, drop the old API. This includes all of
asm/hvm/trace.h, which allows us to drop some includes.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: George Dunlap
CC: Stefano Stabellini
CC: Julien Grall
CC: Nicola Vetrini
CC: consul
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
On 18.03.2024 12:53, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/osstest.git br.bookworm-v1
Hi,
I intend to push this series in two waves.
First, push up to commit "Temporally switch "qemu-mainline" branch to
Bookworm". This is to test that osstest still works fine if w
The Debian #778564 bug report is still open, the ntp.conf file doesn't
contain the setting from NtpServer after installation, so we still
need to edit ntp.conf on Bookworm.
Signed-off-by: Anthony PERARD
---
ts-host-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-ho
Instead of "grub-installer/no-nvram" proposed in Debian bug #789798,
we have "grub-installer/update-nvram". Make use of it, and remove
workaround.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm
Signed-off-by: Anthony PERARD
---
ts-host-install | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/ts-host-install b/ts-host-install
index f79a1beb..61433e64 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -151,7 +151,13 @@ END
my $ntpserver = get_target_pro
$@ expand to two or more words, but fail() only take one argument.
So if there's more than one argument left, fail() only shows the first
one, and don't event display "not found".
Signed-off-by: Anthony PERARD
---
mgi-common | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mgi
grub-installer on arndale-* machine fails with Debian Bookworm. It
tries to install "grub-pc" which doesn't exist. Skip installation.
Somehow, cubietruck-* installation works fine.
Signed-off-by: Anthony PERARD
---
Osstest/Debian.pm | 8
1 file changed, 8 insertions(+)
diff --git a/Os
Signed-off-by: Anthony PERARD
---
production-config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/production-config b/production-config
index 2c44805c..6345c40c 100644
--- a/production-config
+++ b/production-config
@@ -101,6 +101,8 @@ DebianImageVersion_jessie 8.2.0
DebianImageVersion_s
Newer version of Debian and thus git would use this automatically, no
need to force it.
Signed-off-by: Anthony PERARD
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f0e087aa..0dded9b2 100644
---
This schema doesn't work. Even if the udev rule is there, the name of
the different NIC are different from one boot to the next. On a
machine (sabro*) with 3 different NIC, the name of each interface is
basically random and could take on of three name, "eth[0-2]".
net.ifnames=0 does still mean tha
Otherwise, the change to the config file isn't taken into account
until the next reboot.
Signed-off-by: Anthony PERARD
---
ts-host-install | 5 +
1 file changed, 5 insertions(+)
diff --git a/ts-host-install b/ts-host-install
index 00277485..43ed9285 100755
--- a/ts-host-install
+++ b/ts-hos
Signed-off-by: Anthony PERARD
---
mg-debian-installer-update | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mg-debian-installer-update b/mg-debian-installer-update
index 4fb4bc21..31b8a192 100755
--- a/mg-debian-installer-update
+++ b/mg-debian-installer-update
@@ -10
libc6-xen packaged have been removed from Debian Bookworm.
Signed-off-by: Anthony PERARD
---
ts-xen-install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-xen-install b/ts-xen-install
index bf55d4e5..3a913fce 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -64,7 +64,7
1 - 100 of 141 matches
Mail list logo
