On 13.03.2024 17:31, George Dunlap wrote:
> On Wed, Mar 13, 2024 at 2:00 PM Jan Beulich wrote:
>>
>> When not holding the PoD lock across the entire region covering P2M
>> update and stats update, the entry count - if to be incorrect at all -
>> should indicate too large a value in preference to a
On 14.03.2024 00:40, Stefano Stabellini wrote:
> Roger kindly volunteered to step up as IOMMU Maintainer.
>
> Signed-off-by: Stefano Stabellini
Acked-by: Jan Beulich
On 13.03.2024 20:30, Jason Andryuk wrote:
> A new ELF note will specify the alignment for a relocatable PVH kernel.
> ELF notes are suitable for vmlinux and other ELF files, so this
> Linux-specific bzImage parsing in unnecessary.
Hmm, shouldn't the order of attempts to figure the alignment be ELF
On 13.03.2024 22:02, Jason Andryuk wrote:
> On 2024-03-13 15:30, Jason Andryuk wrote:
>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>> +static paddr_t __init find_kernel_memory(
>> +const struct domain *d, struct elf_binary *elf,
>> +const struct elf_dom_pa
In xen spinlock code there are several violations of MISRA rule 21.1
(identifiers starting with "__" or "_[A-Z]").
Fix them by using trailing underscores instead.
Signed-off-by: Juergen Gross
---
V5:
- new patch (Julien Grall)
---
xen/include/xen/spinlock.h | 28 ++--
1
Instead of being able to use normal spinlocks as recursive ones, too,
make recursive spinlocks a special lock type.
This will make the spinlock structure smaller in production builds and
add type-safety.
This allows to increase the maximum number of physical cpus from 4095
to 65535 without increa
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 the new type.
Define the initializer helpers and use th
Rename the recursive spin_lock() functions by replacing the trailing
"_recursive" with a leading "r".
Switch the parameter to be a pointer to rspinlock_t.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Acked-by: Julien Grall
Acked-by: Jan Beulich
---
V2:
- new patch
V5:
- let rspin_tr
Struct lock_profile contains a pointer to the spinlock it is associated
with. Prepare support of differing spinlock_t and rspinlock_t types by
adding a type indicator of the pointer. Use the highest bit of the
block_cnt member for this indicator in order to not grow the struct
while hurting only th
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-by: Juergen Gross
---
V2:
- new patch
V5:
- don't regr
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
---
V2:
- new patch
V5:
- avoid MISRA violation (Julien Grall)
- keep wrapper functions (Jan Beulich)
Add rspin_is_locked() and rspin_barrier() in order to prepare differing
spinlock_t and rspinlock_t types.
Signed-off-by: Juergen Gross
---
V2:
- partially carved out from V1 patch, partially new
V5:
- let rspin_is_locked() return bool (Jan Beulich)
---
xen/arch/x86/mm/p2m-pod.c | 2 +-
xen/
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.
Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
---
V2:
- rename functions (Jan Beulich)
- get rid o
Allow 16 bits per cpu number, which is the limit imposed by
spinlock_tickets_t.
This will allow up to 65535 cpus, while increasing only the size of
recursive spinlocks in debug builds from 8 to 12 bytes.
The current Xen limit of 4095 cpus is imposed by SPINLOCK_CPU_BITS
being 12. There are machin
On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF load types, specify a new
> optional PE binary load type. This new type is a useful addition since
> PE binaries can be signed and verified (i.e. used with Secure Boot).
And the consideration to have ELF signa
On 14.03.2024 08:20, Juergen Gross wrote:
> With lock handling now allowing up to 16384 cpus (spinlocks can handle
> 65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
> the number of cpus to be configured to 16383.
>
> The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES
With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
the number of cpus to be configured to 16383.
The new limit is imposed by IOMMU_CMD_BUFFER_MAX_ENTRIES and
QINVAL_MAX_ENTRY_NR required to be larger than 2
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 possible writer, and a 12 bit
counter for readers. Th
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 mixture of both usage variants
needs to be
- in pro
Switch the remaining trylock and is_locked variants to return bool.
Signed-off-by: Juergen Gross
---
V5:
- new patch (Jan Beulich)
---
xen/common/spinlock.c | 4 ++--
xen/include/xen/spinlock.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/common/spinlock.c b/
On 14.03.2024 08:20, Juergen Gross wrote:
> In xen spinlock code there are several violations of MISRA rule 21.1
> (identifiers starting with "__" or "_[A-Z]").
>
> Fix them by using trailing underscores instead.
>
> Signed-off-by: Juergen Gross
I can live with the changes as they are, but befo
On 14.03.2024 00:23, Stefano Stabellini wrote:
> Xen makes assumptions about the size of integer types on the various
> architectures. Document these assumptions.
This all reads as if we required exact widths. Is that really the case? Imo
we e.g. merely depend upon sizeof(int) >= 4 * CHAR_BITS. (I
Place an "#if 0" before grep fodder #define-s and remove
the #undef-s.
This addresses violations of MISRA C:2012 Rules 20.5 ("#undef should
not be used") and 5.5 ("Identifiers shall be distinct from macro
names").
No functional change.
Signed-off-by: Federico Serafini
---
xen/include/xen/iommu
The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send_guest_cmd
allows not to accidentally pass a smaller array or assume that
send_iommu_command handles array sizes >4 correctly.
No fu
On 13.03.2024 15:26, Andrew Cooper wrote:
> The macro named RESTORE_ALL has several problems. It adjusts the stack
> pointer despite this not being clear to the caller. It also goes against
> recommendations in the optimisation guides because of trying to do too many
> things at once. (i.e. ther
On 13.03.2024 15:26, Andrew Cooper wrote:
> There is only a single user now, and it's the one odd case. Inline and
> simplify it to just the compat case.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
> In principle we want to delay the %rsp adjustment un
Hi, I saw this on the list and have concerns:
Original Message
On 14 Mar 2024, 6:24 pm, Jan Beulich via Grub-devel < grub-de...@gnu.org> wrote:
On 13.03.2024 16:07, Ross Lagerwall wrote:
>> In addition to the existing address and ELF load types, specify a new
>> optional PE binar
On 14.03.2024 08:42, Nicola Vetrini wrote:
> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
> to a function that expects arrays of size 4, therefore
> specifying explicitly the size also in amd_iommu_send_guest_cmd
> allows not to accidentally pass a smaller array or assume that
> send_i
On Thu, Mar 14, 2024 at 7:36 AM Jan Beulich wrote:
>
> On 14.03.2024 00:23, Stefano Stabellini wrote:
> > Xen makes assumptions about the size of integer types on the various
> > architectures. Document these assumptions.
>
> This all reads as if we required exact widths. Is that really the case?
On 2024-03-14 09:32, Jan Beulich wrote:
On 14.03.2024 08:42, Nicola Vetrini wrote:
The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
to a function that expects arrays of size 4, therefore
specifying explicitly the size also in amd_iommu_send_guest_cmd
allows not to accidentally pass a sm
On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>
> On 13.03.2024 16:07, Ross Lagerwall wrote:
> > In addition to the existing address and ELF load types, specify a new
> > optional PE binary load type. This new type is a useful addition since
> > PE binaries can be signed and verified (i.e. us
On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> from the elf headers. For Linux, this defaults to 0x100 (16MB), but
> it can be configured.
>
> Unfortunately there exist firmwares that have reserved reg
On Thu, Mar 14, 2024 at 08:06:27AM +0100, Jan Beulich wrote:
> On 14.03.2024 00:40, Stefano Stabellini wrote:
> > Roger kindly volunteered to step up as IOMMU Maintainer.
> >
> > Signed-off-by: Stefano Stabellini
>
> Acked-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks.
On 14.03.24 08:32, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
In xen spinlock code there are several violations of MISRA rule 21.1
(identifiers starting with "__" or "_[A-Z]").
Fix them by using trailing underscores instead.
Signed-off-by: Juergen Gross
I can live with the
On 14.03.24 08:26, Jan Beulich wrote:
On 14.03.2024 08:20, Juergen Gross wrote:
With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks can handle 16384 cpus), raise the allowed limit for
the number of cpus to be configured to 16383.
The new limit is imposed b
flight 185020 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185020/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail REGR.
vs. 185003
bui
On 14/03/2024 7:37 am, Federico Serafini wrote:
> Place an "#if 0" before grep fodder #define-s and remove
> the #undef-s.
>
> This addresses violations of MISRA C:2012 Rules 20.5 ("#undef should
> not be used") and 5.5 ("Identifiers shall be distinct from macro
> names").
>
> No functional change.
On 14.03.2024 10:25, Nicola Vetrini wrote:
> On 2024-03-14 09:32, Jan Beulich wrote:
>> On 14.03.2024 08:42, Nicola Vetrini wrote:
>>> The 'cmd' parameter of amd_iommu_send_guest_cmd is passed
>>> to a function that expects arrays of size 4, therefore
>>> specifying explicitly the size also in amd_
Add pseudo-keyword fallthrough to make explicit the intention of the
code and meet requirements to deviate MISRA C:2012 Rule 16.3
("An unconditional `break' statement shall terminate every
switch-clause").
No functional change.
Signed-off-by: Federico Serafini
---
xen/common/perfc.c | 2 ++
1 f
On 14.03.2024 13:25, Federico Serafini wrote:
> Add pseudo-keyword fallthrough to make explicit the intention of the
> code and meet requirements to deviate MISRA C:2012 Rule 16.3
> ("An unconditional `break' statement shall terminate every
> switch-clause").
>
> No functional change.
>
> Signed-
On 2024-03-14 03:12, Jan Beulich wrote:
On 13.03.2024 22:02, Jason Andryuk wrote:
On 2024-03-13 15:30, Jason Andryuk wrote:
+/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
+static paddr_t __init find_kernel_memory(
+const struct domain *d, struct elf_binary *elf
On 11.03.2024 09:59, Simone Ballarin wrote:
> From: Maria Celeste Cesario
>
> Add inclusion guard 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.
> ---
> C
On 2024-03-14 03:11, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.
Hmm, shouldn't the order of a
Hi Ayan,
On 07/03/2024 12:39, Ayan Kumar Halder wrote:
Hi,
Refer
https://lore.kernel.org/all/alpine.DEB.2.22.394.2312071341540.1265976@ubuntu-linux-20-04-desktop/T/
for the previous discussion on this issue.
Also, the linux earlycon hvc driver has been fixed.
See
https://git.kernel.org/pub/s
On 13.03.2024 20:30, Jason Andryuk wrote:
> @@ -217,6 +225,15 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary
> *elf,
> case XEN_ELFNOTE_PHYS32_ENTRY:
> parms->phys_entry = val;
> break;
> +
> +case XEN_ELFNOTE_L1_MFN_VALID:
> +if ( elf_uval(elf, note, de
On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/include/public/elfnote.h
> +++ b/xen/include/public/elfnote.h
> @@ -194,6 +194,17 @@
> */
> #define XEN_ELFNOTE_PHYS32_ENTRY 18
>
> +/*
> + * Physical loading constraints for PVH kernels
> + *
> + * Used to place constraints on the guest ph
Hi Henry,
On 28/02/2024 01:58, Henry Wang wrote:
In the common sysctl command XEN_SYSCTL_physinfo, the value of
cores_per_socket is calculated based on the cpu_core_mask of CPU0.
Currently on Arm this is a fixed value 1 (can be checked via xl info),
which is not correct. This is because during t
On Wed, Mar 6, 2024 at 4:41 PM Roger Pau Monné wrote:
>
> On Wed, Mar 06, 2024 at 01:15:48PM +0800, flyingpeng...@gmail.com wrote:
> > From: Peng Hao
> >
> > From: Peng Hao
> >
> > Use kmap_local_page() instead of kmap_atomic() which has been
> > deprecated.
> >
> > Signed-off-by: Peng Hao
> >
From: Peng Hao
Use kmap_local_page() instead of kmap_atomic() which has been
deprecated.
Signed-off-by: Peng Hao
---
drivers/block/xen-blkback/blkback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/block/xen-blkback/blkback.c
b/drivers/block/xen-blkback/bl
On 13.03.2024 20:30, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -537,6 +537,108 @@ static paddr_t __init find_memory(
> return INVALID_PADDR;
> }
>
> +static bool __init check_load_address(
> +const struct domain *d, const struc
On 14.03.2024 14:01, Jason Andryuk wrote:
> On 2024-03-14 03:11, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> A new ELF note will specify the alignment for a relocatable PVH kernel.
>>> ELF notes are suitable for vmlinux and other ELF files, so this
>>> Linux-specific bzImage
On 14.03.2024 10:30, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
>>
>> On 13.03.2024 16:07, Ross Lagerwall wrote:
>>> In addition to the existing address and ELF load types, specify a new
>>> optional PE binary load type. This new type is a useful addition since
>>>
On 13/03/2024 5:48 pm, Andrew Cooper wrote:
> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>> xen/arch/arm/include/asm/bitops.h | 2 +-
>> xen/arch/ppc/include/asm/bitops.h | 1 -
>> xen/arch/x86/include/asm/bitops.h | 30 +-
>> xen/common/bitops.c | 7 +
On 13.03.2024 16:35, Matthew Barnes wrote:
> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
> (for HVM guests) to construct ACPI tables for guests.
>
> Currently, libacpi only uses APIC entries to enumerate processors for
> guests in the MADT.
>
> The APIC ID field in APIC
On 2024-03-14 05:48, Roger Pau Monné wrote:
On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there e
Hi Julien,
You will find here above the answers to your questions.
Thank you very much for your help.
Best regards,
Dominique
-Message d'origine-
De : Julien Grall mailto:jul...@xen.org>>
Envoyé : jeudi 29 février 2024 12:52
À : LARRIEU Dominique
mailto:dominique.larr...@t
On 13.03.2024 18:27, Andrew Cooper wrote:
> * Rename __attribute_pure__ to just __pure before it gains users.
> * Identify the areas of xen/bitops.h which are a mess.
> * Create common/bitops.c for compile and runtime testing. This provides a
>statement of the ABI, and a confirmation that a
On 2024-03-14 09:21, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/include/public/elfnote.h
+++ b/xen/include/public/elfnote.h
@@ -194,6 +194,17 @@
*/
#define XEN_ELFNOTE_PHYS32_ENTRY 18
+/*
+ * Physical loading constraints for PVH kernels
+ *
+ * Used to place
On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/arch/arm/include/asm/bitops.h
> +++ b/xen/arch/arm/include/asm/bitops.h
> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
> }
>
>
> -#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
> +#define arch_ffs(x) ({ uns
On 14.03.2024 15:13, Jason Andryuk wrote:
> On 2024-03-14 09:21, Jan Beulich wrote:
>> On 13.03.2024 20:30, Jason Andryuk wrote:
>>> --- a/xen/include/public/elfnote.h
>>> +++ b/xen/include/public/elfnote.h
>>> @@ -194,6 +194,17 @@
>>>*/
>>> #define XEN_ELFNOTE_PHYS32_ENTRY 18
>>>
>>> +/*
On Thu, Mar 14, 2024 at 09:28:43PM +0800, flyingpeng...@gmail.com wrote:
> From: Peng Hao
>
> Use kmap_local_page() instead of kmap_atomic() which has been
> deprecated.
>
> Signed-off-by: Peng Hao
Acked-by: Roger Pau Monné
Thanks, Roger.
Hi Julien,
On 3/14/2024 9:27 PM, Julien Grall wrote:
Hi Henry,
On 28/02/2024 01:58, Henry Wang wrote:
diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
index a84e706d77..d9ebd55d4a 100644
--- a/xen/arch/arm/smpboot.c
+++ b/xen/arch/arm/smpboot.c
@@ -66,7 +66,6 @@ static bool cpu_is_
On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
>
> On 14.03.2024 10:30, Ross Lagerwall wrote:
> > On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
> >>
> >> On 13.03.2024 16:07, Ross Lagerwall wrote:
> >>> In addition to the existing address and ELF load types, specify a new
> >>> optional
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 @@ struct page_info *iommu_alloc_pgtable(struct domain_iommu
> *hd,
> if ( contig_mask )
> {
> /* See pt-contig-markers.h for a de
On 14.03.2024 15:24, Ross Lagerwall wrote:
> On Thu, Mar 14, 2024 at 1:37 PM Jan Beulich wrote:
>> On 14.03.2024 10:30, Ross Lagerwall wrote:
>>> On Thu, Mar 14, 2024 at 7:24 AM Jan Beulich wrote:
On 13.03.2024 16:07, Ross Lagerwall wrote:
> In addition to the existing address and ELF lo
On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> On 2024-03-14 05:48, Roger Pau Monné wrote:
> > On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
> > > Xen tries to load a PVH dom0 kernel at the fixed guest physical address
> > > from the elf headers. For Linux, this
On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> Start cleaning it up with ffs() and friends. Across the board, this adds:
>
> * Functioning bitops without arch-specific asm
It turns out that RISC-V doesn't have a CLZ instruction in the base
ISA. As a consequence, __builtin_ffs() emits a library c
Hi Stefano,
> On 14 Mar 2024, at 00:04, Stefano Stabellini wrote:
>
> On Wed, 13 Mar 2024, Jan Beulich wrote:
>> On 13.03.2024 01:28, Stefano Stabellini wrote:
>>> --- a/docs/misra/rules.rst
>>> +++ b/docs/misra/rules.rst
>>> @@ -478,6 +478,30 @@ maintainers if you want to suggest a change.
>>>
On 14.03.2024 15:33, Roger Pau Monné wrote:
> On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
>> On 2024-03-14 05:48, Roger Pau Monné wrote:
>>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
@@ -234,6 +235,17 @@ elf_errorstatus elf_xen_parse_note(struct elf_bina
On 14.03.2024 15:45, Andrew Cooper wrote:
> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>> Start cleaning it up with ffs() and friends. Across the board, this adds:
>>
>> * Functioning bitops without arch-specific asm
>
> It turns out that RISC-V doesn't have a CLZ instruction in the base
> ISA.
flight 185033 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185033/
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 185029 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185029/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 14 guest-start fail REGR. vs. 185019
test-armhf-armhf-l
On 14/03/2024 3:33 pm, Jan Beulich wrote:
> On 14.03.2024 15:45, Andrew Cooper wrote:
>> On 13/03/2024 5:27 pm, Andrew Cooper wrote:
>>> Start cleaning it up with ffs() and friends. Across the board, this adds:
>>>
>>> * Functioning bitops without arch-specific asm
>> It turns out that RISC-V doe
On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/common/bitops.c
> +++ b/xen/common/bitops.c
> @@ -47,6 +47,18 @@ static void test_ffs(void)
> CHECK(ffsl, 1UL << (BITS_PER_LONG - 1), BITS_PER_LONG);
> if ( BITS_PER_LONG > 32 )
> CHECK(ffsl, 1UL << 32, 33);
> +
> +/*
> +
On 13.03.2024 18:27, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/bitops.h
> +++ b/xen/arch/x86/include/asm/bitops.h
> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned
> long val, unsigned int max)
> r__;
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
> Signed-off-by: Vaishali Th
On 13.03.2024 17:41, Vaishali Thakkar wrote:
> Currently only raw _np_ctrl is being printed. It can
> be informational to know about which particular bits
> are enabled. So, this commit adds the bit-by-bit decode
> for np, sev and sev_es bits.
>
> Note that while, only np is enabled in certain sce
We'd like to thank Kevin, so far the VT-d maintainer, for his past
contributions, while at the same time we'd like to reflect reality as it
has been for quite some time. Have VT-d maintainership (and for symmetry
also AMD IOMMU's) fall back to the maintainers of general x86. This also
brings things
On 14/03/2024 2:16 pm, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
>> --- a/xen/arch/arm/include/asm/bitops.h
>> +++ b/xen/arch/arm/include/asm/bitops.h
>> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>> }
>>
>>
>> -#define ffs(x) ({ unsigned int __t = (x); fls(
On 14/03/2024 4:22 pm, Jan Beulich wrote:
> We'd like to thank Kevin, so far the VT-d maintainer, for his past
> contributions, while at the same time we'd like to reflect reality as it
> has been for quite some time. Have VT-d maintainership (and for symmetry
> also AMD IOMMU's) fall back to the m
On Thu, 2024-03-14 at 16:33 +0100, Jan Beulich wrote:
> On 14.03.2024 15:45, Andrew Cooper wrote:
> > On 13/03/2024 5:27 pm, Andrew Cooper wrote:
> > > Start cleaning it up with ffs() and friends. Across the board,
> > > this adds:
> > >
> > > * Functioning bitops without arch-specific asm
> >
On 14.03.2024 17:23, Andrew Cooper wrote:
> On 14/03/2024 2:16 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/arch/arm/include/asm/bitops.h
>>> +++ b/xen/arch/arm/include/asm/bitops.h
>>> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>>> }
>>>
>>>
Update ECLAIR configuration of MISRA C:2012 Rule 8.3 to deviate
violations involving parameter name "unused":
it makes explicit the intention of not using the parameter within
the function.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
docs/misra
On Thu, 2024-03-14 at 15:30 +0100, 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 @@ struct page_info *iommu_alloc_pgtable(struct
> > domain_iommu *hd,
> > if ( cont
On Thu, Mar 14, 2024 at 04:30:05PM +0100, Jan Beulich wrote:
> On 14.03.2024 15:33, Roger Pau Monné wrote:
> > On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
> >> On 2024-03-14 05:48, Roger Pau Monné wrote:
> >>> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
>
On 14.03.2024 17:48, Oleksii wrote:
> On Thu, 2024-03-14 at 15:30 +0100, 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 @@ struct page_info *iommu_alloc_pgtable(struct
>
On 2024-03-14 11:30, Jan Beulich wrote:
On 14.03.2024 15:33, Roger Pau Monné wrote:
On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
On 2024-03-14 05:48, Roger Pau Monné wrote:
On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jason Andryuk wrote:
@@ -234,6 +235,17 @@ elf_errorstatus el
On 14.03.2024 17:59, Jason Andryuk wrote:
> On 2024-03-14 11:30, Jan Beulich wrote:
>> On 14.03.2024 15:33, Roger Pau Monné wrote:
>>> On Thu, Mar 14, 2024 at 09:51:22AM -0400, Jason Andryuk wrote:
On 2024-03-14 05:48, Roger Pau Monné wrote:
> On Wed, Mar 13, 2024 at 03:30:21PM -0400, Jaso
On 14/03/2024 3:59 pm, Jan Beulich wrote:
> On 13.03.2024 18:27, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/bitops.h
>> +++ b/xen/arch/x86/include/asm/bitops.h
>> @@ -401,18 +401,6 @@ static always_inline unsigned int __scanbit(unsigned
>> long val, unsigned int max)
>> r__;
From: Julien Grall
The script docs/support-matrix-generate throw the following error on the
latest staging.
MDCCSR_EL0
DBGDTR_EL0
DBGDTRTX_EL0
DBGDTRRX_EL0
DBGDSCRINT
DBGDTRTXINT
DBGDTRRXINT
^ cannot parse status codeblock line:
MDCCSR_EL0
? at docs/parse-support-md line 172, chunk 1.
With th
On 14/03/2024 5:39 pm, Julien Grall wrote:
> From: Julien Grall
>
> The script docs/support-matrix-generate throw the following error on the
> latest staging.
>
> MDCCSR_EL0
> DBGDTR_EL0
> DBGDTRTX_EL0
> DBGDTRRX_EL0
> DBGDSCRINT
> DBGDTRTXINT
> DBGDTRRXINT
> ^ cannot parse status codeblock line:
On 14/03/2024 17:41, Andrew Cooper wrote:
On 14/03/2024 5:39 pm, Julien Grall wrote:
From: Julien Grall
The script docs/support-matrix-generate throw the following error on the
latest staging.
MDCCSR_EL0
DBGDTR_EL0
DBGDTRTX_EL0
DBGDTRRX_EL0
DBGDSCRINT
DBGDTRTXINT
DBGDTRRXINT
^ cannot parse
Hi Jan,
I'm revisiting this series in preparation for a v3 and had some
follow-up comments.
On 12/21/23 1:06 AM, Jan Beulich wrote:
> On 15.12.2023 03:44, Shawn Anastasio wrote:
>> In the initial mm-radix implementation, the in-memory partition and
>> process tables required to configure the MMU
flight 185035 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185035/
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 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 @@ struct page_info *iommu_alloc_pgtable(struct
>> domain_iommu *hd,
>> if ( contig_mask )
>>
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 @@ struct page_info *iommu_alloc_pgtable(struct
>>>
flight 185023 linux-linus real [real]
flight 185038 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185023/
http://logs.test-lab.xenproject.org/osstest/logs/185038/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
I have not been active in the Xen community for some time. Update the
MAINTAINERS file to reflect reality.
Signed-off-by: Wei Liu
---
It has been a pleasure working with all of you. I'm sure we will cross
paths in the future.
Seabios is in need for a new owner. For now I left my name there.
---
On 2024-03-14 09:31, Jan Beulich wrote:
On 13.03.2024 20:30, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,108 @@ static paddr_t __init find_memory(
return INVALID_PADDR;
}
+static bool __init check_load_address(
+cons
On Thu, 14 Mar 2024, Wei Liu wrote:
> I have not been active in the Xen community for some time. Update the
> MAINTAINERS file to reflect reality.
>
> Signed-off-by: Wei Liu
Acked-by: Stefano Stabellini
> ---
> It has been a pleasure working with all of you. I'm sure we will cross
> paths in
1 - 100 of 135 matches
Mail list logo
