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 the Arm CPU online
process at boot time, setup_cpu_si
flight 185108 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185108/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-credit1 14 guest-start fail in 185071 pass in 185108
test-armhf-armhf-xl-rtds 14 gue
On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 20.03.2024 09:50, Simone Ballarin wrote:
> > MISRA C:2012 Rule 17.1 states:
> > The features of `' shall not be used
> >
> > The Xen community wants to avoid using variadic functions except for
> > specific circumstances where it feels appropriate by st
On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 20.03.2024 09:51, Simone Ballarin wrote:
> > MISRA C Rule 20.7 states: "The features of `' shall not be used"
> >
> > The Xen community wants to avoid using variadic functions except for
> > specific circumstances where it feels appropriate by strict co
On Wed, 20 Mar 2024, Jan Beulich wrote:
> > - the public interface is described in a C header so it makes sense for
> > the corresponding implementation to be in C
> >
> > - the C entry point is often both the entry point in C and also common
> > code
> >
> > - depending on the architecture,
On Wed, 20 Mar 2024, Jan Beulich wrote:
> On 19.03.2024 21:58, Jason Andryuk wrote:
> > --- a/xen/arch/x86/hvm/dom0_build.c
> > +++ b/xen/arch/x86/hvm/dom0_build.c
> > @@ -537,6 +537,97 @@ static paddr_t __init find_memory(
> > return INVALID_PADDR;
> > }
> >
> > +static bool __init check_l
> Subject: Re: [PATCH 1/2] xen/arm: Add imx8q{m,x} platform glue
>
> On Wed, 20 Mar 2024, Julien Grall wrote:
> > Hi John,
> >
> > On 20/03/2024 16:24, John Ernberg wrote:
> > > Hi Bertrand,
> > >
> > > On 3/13/24 11:07, Bertrand Marquis wrote:
> > > > Hi,
> > > >
> > > > > On 8 Mar 2024, at 15:04
On Wed, 20 Mar 2024, Julien Grall wrote:
> Hi John,
>
> On 20/03/2024 16:24, John Ernberg wrote:
> > Hi Bertrand,
> >
> > On 3/13/24 11:07, Bertrand Marquis wrote:
> > > Hi,
> > >
> > > > On 8 Mar 2024, at 15:04, Julien Grall wrote:
> > > >
> > > > Hi John,
> > > >
> > > > Thank you for the r
flight 185106 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185106/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stop fail blocked in 185099
test-armhf-armhf-libvirt 16 save
On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> > On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > > Currently, RISC-V requires two extensions: _zbb and _zihintpause.
> >
> > Do we really require Zbb already?
> After an introductio
Some boot mechanisms, including the new linux file_load kexec systemcall
used by system firmware v2.10 on RaptorCS systems will try to honor the
physical address field of the ELF LOAD section header, which will fail
when the address is based off of XEN_VIRT_START (0xc000).
To ensure th
On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> > Currently, RISC-V requires two extensions: _zbb and _zihintpause.
>
> Do we really require Zbb already?
After an introduction of Andrew C. patches [1] it is requited for
__builtin_ffs{l}
[1]
h
This is similar to what is being done on x86.
Signed-off-by: Ayan Kumar Halder
---
xen/arch/arm/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 424744ad5e..3d110685bc 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -
On 20/03/2024 6:00 pm, Shawn Anastasio wrote:
> Some boot mechanisms, including the new linux file_load kexec systemcall
> used by system firmware v2.10 on RaptorCS systems will try to honor the
> physical address field of the ELF LOAD section header, which will fail
> when the address is based off
On 3/15/24 4:16 AM, Jan Beulich wrote:
> On 14.03.2024 23:15, Shawn Anastasio wrote:
>> Arm's setup.c contains a collection of functions for parsing memory map
>> and other boot information from a device tree. Since these routines are
>> generally useful on any architecture that supports device tre
On 3/14/24 5:15 PM, Shawn Anastasio wrote:
> In the initial mm-radix implementation, the in-memory partition and
> process tables required to configure the MMU, as well as the page tables
> themselves were all allocated statically since the boot allocator was
> not yet available.
>
> Now that it i
Some boot mechanisms, including the new linux file_load kexec systemcall
used by system firmware v2.10 on RaptorCS systems will try to honor the
physical address field of the ELF LOAD section header, which will fail
when the address is based off of XEN_VIRT_START (0xc000).
To ensure th
Hi Dmitry,
Do you have any feedback, or can you pick up this patch? It solves a
real issue affecting udev, which crashes the Debian installer and
breaks the mouse for Gnome.
Or would you be okay if this patch went in via the Xen tree?
Thanks,
Jason
On Wed, Nov 1, 2023 at 10:11 AM Jason Andryuk
Hi John,
On 20/03/2024 16:24, John Ernberg wrote:
Hi Bertrand,
On 3/13/24 11:07, Bertrand Marquis wrote:
Hi,
On 8 Mar 2024, at 15:04, Julien Grall wrote:
Hi John,
Thank you for the reply.
On 08/03/2024 13:40, John Ernberg wrote:
On 3/7/24 00:07, Julien Grall wrote:
> Ping on the wat
On Wed, Mar 20, 2024 at 05:15:06PM +0100, Cédric Le Goater wrote:
> Sure, or I will in a v6. Markus had a comment on 8/14.
Yeah, I can handle both if they're the only ones. Thanks,
--
Peter Xu
On Mon, Mar 18, 2024 at 04:55:09PM +, Anthony PERARD wrote:
> 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-m
On Mon, Mar 18, 2024 at 04:55:44PM +, Anthony PERARD wrote:
> Xen 4.17 doesn't build with Debian Bookworm. It fails to build
> IPXE/etherboot, on "amd64". So we keep using Debian Buster on Xen 4.18
> and earlier branches. Xen 4.18 builds 4.17 via job "build-amd64-prev".
>
> Xen 4.17 would need
On Mon, Mar 18, 2024 at 04:55:43PM +, Anthony PERARD wrote:
> QEMU doesn't build on buster anymore.
>
> This should be remove once bookworm is the default suite.
Is this change required anymore, patch 35 makes bookworm the default,
hence it seems pointless to switch QEMU just one patch ahead.
On Mon, Mar 18, 2024 at 04:55:42PM +, Anthony PERARD wrote:
> When starting the installation of the L2 guest, L0 kills L1. Switching
> the L2 guest back to Debian Buster works fine, so do that to prevent
> regression in the test.
>
> Part of the logs from the host L0:
>
> > domain_crash calle
On Mon, Mar 18, 2024 at 04:55:19PM +, Anthony PERARD wrote:
> 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.
I'm kind of puzzled by this, as cubietruck a
On Wed, Mar 20, 2024 at 04:20:00PM +0100, Roger Pau Monné wrote:
> On Mon, Mar 18, 2024 at 04:55:11PM +, Anthony PERARD wrote:
> > Newer version of Debian and thus git would use this automatically, no
> > need to force it.
> >
> > Signed-off-by: Anthony PERARD
> > ---
> > Osstest/TestSupport
On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> On 20.03.2024 14:57, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path there's
Hi Bertrand,
On 3/13/24 11:07, Bertrand Marquis wrote:
> Hi,
>
>> On 8 Mar 2024, at 15:04, Julien Grall wrote:
>>
>> Hi John,
>>
>> Thank you for the reply.
>>
>> On 08/03/2024 13:40, John Ernberg wrote:
>>> On 3/7/24 00:07, Julien Grall wrote:
> Ping on the watchdog discussion bits.
On 3/20/24 15:42, Peter Xu wrote:
On Wed, Mar 20, 2024 at 07:49:05AM +0100, Cédric Le Goater wrote:
Modify all .log_global_start() handlers to take an Error** parameter
and return a bool. Adapt memory_global_dirty_log_start() to interrupt
on the first error the loop on handlers. In such case, a
On Fri, Mar 08, 2024 at 04:19:20PM +0100, zithro / Cyril Rébert wrote:
> Questions (unblocking):
> - why a double space between all sentences ?
It's an English thing maybe?
Wikipedia has an article about it:
https://en.wikipedia.org/wiki/Sentence_spacing
But actually, single space seems like it
On 20.03.2024 16:46, George Dunlap wrote:
> On Wed, Mar 20, 2024 at 1:45 PM Jan Beulich wrote:
>>
>> On 18.03.2024 17:35, Andrew Cooper wrote:
>>> @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic,
>>> uint32_t lvtt,
>>> delta = delta * vlapic->hw.timer_divis
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> 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
Reviewed-by: George Dunlap
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> (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 lin
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Taken from Linux-6.4.0-rc1
>
> Xen's bitops.h consists of several Linux's headers:
> * linux/arch/include/asm/bitops.h:
> * The following function were removed as they aren't used in Xen:
> * test_and_set_bit_lock
> * clear_bit_unloc
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> This logically drops the cycles parameter, as it's now encoded directly in the
> event code.
So to make Jan's comment more specific, what about something like this:
This primarily consists of converting the cycles parameter into the
approp
On Wed, Mar 20, 2024 at 1:45 PM Jan Beulich wrote:
>
> On 18.03.2024 17:35, Andrew Cooper wrote:
> > @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic,
> > uint32_t lvtt,
> > delta = delta * vlapic->hw.timer_divisor / old_divisor;
> > }
> >
> > -
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- a/xen/lib/find-next-bit.c
> +++ b/xen/lib/find-next-bit.c
> @@ -9,6 +9,7 @@
> * 2 of the License, or (at your option) any later version.
> */
> #include
> +#include
>
> #include
Hmm, no, a library source would better not include this he
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Return type was left 'int' because of the following compilation error:
>
> ./include/xen/kernel.h:18:21: error: comparison of distinct pointer types
> lacks a cast [-Werror]
>18 | (void) (&_x == &_y);\
> |
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The patch introduces the following generic functions:
> * test_bit
> * generic___test_and_set_bit
> * generic___test_and_clear_bit
> * generic___test_and_change_bit
>
> Also, the patch introduces the following generics which are
> used by the function
On 20/03/2024 3:09 pm, Jan Beulich wrote:
> On 20.03.2024 14:57, Roger Pau Monne wrote:
>> There's no reason to force HVM guests to have a valid vcpu_info area when
>> initializing a vCPU, as the vCPU can also be brought online using the local
>> APIC, and on that path there's no requirement for vc
On Mon, Mar 18, 2024 at 04:55:11PM +, Anthony PERARD wrote:
> 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/O
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> 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.
>
> Sign
On Wed, Mar 20, 2024 at 07:49:07AM +0100, Cédric Le Goater wrote:
> Now that the log_global*() handlers take an Error** parameter and
> return a bool, do the same for memory_global_dirty_log_start() and
> memory_global_dirty_log_stop(). The error is reported in the callers
> for now and it will be
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> 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: Andr
On 20.03.2024 14:57, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up. N
On Wed, Mar 20, 2024 at 12:16 PM George Dunlap wrote:
>
> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
> wrote:
> >
> > 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
On 20.03.2024 15:06, Andrew Cooper wrote:
> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>> There's no reason to force HVM guests to have a valid vcpu_info area when
>> initializing a vCPU, as the vCPU can also be brought online using the local
>> APIC, and on that path there's no requirement for
Cédric Le Goater writes:
> Now that the log_global*() handlers take an Error** parameter and
> return a bool, do the same for memory_global_dirty_log_start() and
> memory_global_dirty_log_stop(). The error is reported in the callers
> for now and it will be propagated in the call stack in the nex
> On 20 Mar 2024, at 10:57, Michal Orzel wrote:
>
> Hi Luca,
>
> On 12/03/2024 14:03, Luca Fancellu wrote:
>>
>>
>> The function find_unallocated_memory is using the same code to
>> loop through 3 structure of the same type, in order to avoid
>> code duplication, rework the code to have only
On 20.03.2024 15:06, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
>> On 20.03.2024 11:46, Roger Pau Monné wrote:
>>> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
fun
On Wed, Mar 20, 2024 at 07:49:05AM +0100, Cédric Le Goater wrote:
> Modify all .log_global_start() handlers to take an Error** parameter
> and return a bool. Adapt memory_global_dirty_log_start() to interrupt
> on the first error the loop on handlers. In such case, a rollback is
> performed to stop
On 20/03/2024 2:26 pm, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 02:06:27PM +, Andrew Cooper wrote:
>> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought onli
On 19.03.2024 21:58, Jason Andryuk wrote:
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -537,6 +537,97 @@ static paddr_t __init find_memory(
> return INVALID_PADDR;
> }
>
> +static bool __init check_load_address(
> +const struct domain *d, const struct
On Wed, Mar 20, 2024 at 02:06:27PM +, Andrew Cooper wrote:
> On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
> > There's no reason to force HVM guests to have a valid vcpu_info area when
> > initializing a vCPU, as the vCPU can also be brought online using the local
> > APIC, and on that path the
On Thu, Jul 13, 2023 at 04:53:57PM -0700, Elliott Mitchell wrote:
> Normal behavior is to be silent. Generating a message for the preferred
> input can be mistaken for an error. As such remove this message to match
> other conditions.
>
> Signed-off-by: Elliott Mitchell
Acked-by: Anthony PERAR
On 20/03/2024 1:57 pm, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up.
On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> On 20.03.2024 11:46, Roger Pau Monné wrote:
> > On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> >> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> >> functions") having removed the sole place where d-
flight 185101 linux-linus real [real]
flight 185112 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185101/
http://logs.test-lab.xenproject.org/osstest/logs/185112/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On 19.03.2024 21:58, Jason Andryuk wrote:
> --- a/xen/common/libelf/libelf-dominfo.c
> +++ b/xen/common/libelf/libelf-dominfo.c
> @@ -101,26 +101,30 @@ elf_errorstatus elf_xen_parse_note(struct elf_binary
> *elf,
> /* *INDENT-OFF* */
> static const struct {
> const char *name;
> -
There's no reason to force HVM guests to have a valid vcpu_info area when
initializing a vCPU, as the vCPU can also be brought online using the local
APIC, and on that path there's no requirement for vcpu_info to be setup ahead
of the bring up. Note an HVM vCPU can operate normally without making
On 18.03.2024 17:35, Andrew Cooper wrote:
> 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
On 18.03.2024 17:35, Andrew Cooper wrote:
> This logically drops the cycles parameter, as it's now encoded directly in the
> event code.
That encoding is an internal detail of the new API; for the purposes of the
callers the pattern looks to be that ...
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/
On 18.03.2024 17:35, Andrew Cooper wrote:
> @@ -736,9 +736,19 @@ static void vlapic_update_timer(struct vlapic *vlapic,
> uint32_t lvtt,
> delta = delta * vlapic->hw.timer_divisor / old_divisor;
> }
>
> -TRACE_2_LONG_3D(TRC_HVM_EMUL_LAPIC_START_TIMER, TRC_PAR_LONG(d
On Wed, Mar 20, 2024 at 1:13 PM Jan Beulich wrote:
>
> On 20.03.2024 13:19, Andrew Cooper wrote:
> > On 20/03/2024 12:16 pm, George Dunlap wrote:
> >> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
> >> wrote:
> >>> There is no need for bitfields anywhere - use more sensible types. There
> >>>
On 20.03.2024 13:19, Andrew Cooper wrote:
> On 20/03/2024 12:16 pm, George Dunlap wrote:
>> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
>> wrote:
>>> 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
On 20.03.2024 12:58, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
> wrote:
>>
>> 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 throu
On Wed, Mar 20, 2024 at 12:19 PM Andrew Cooper
wrote:
>
> On 20/03/2024 12:16 pm, George Dunlap wrote:
> > On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
> > wrote:
> >> There is no need for bitfields anywhere - use more sensible types. There
> >> is
> >> also no need to cast 'd' to (unsigned c
On 20.03.2024 12:45, Andrew Cooper wrote:
> On 20/03/2024 8:12 am, Jan Beulich wrote:
>> On 19.03.2024 18:40, Andrew Cooper wrote:
>>> It occurs to me that I need this hunk too.
>>>
>>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>>> index 25d329ce486f..bf3f9ec01e6e 100755
>>> ---
flight 185109 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185109/
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 20/03/2024 12:16 pm, George Dunlap wrote:
> On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper
> wrote:
>> 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 t
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> 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.
Hey And
On Mon, Mar 18, 2024 at 4:36 PM Andrew Cooper wrote:
>
> 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
On 20/03/2024 8:12 am, Jan Beulich wrote:
> On 19.03.2024 18:40, Andrew Cooper wrote:
>> It occurs to me that I need this hunk too.
>>
>> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
>> index 25d329ce486f..bf3f9ec01e6e 100755
>> --- a/xen/tools/gen-cpuid.py
>> +++ b/xen/tools/gen-cp
On Tue, Mar 19, 2024 at 02:46:59PM +, Ross Lagerwall wrote:
> On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote:
> >
> > On Wed, Mar 13, 2024 at 03:07:42PM +, Ross Lagerwall wrote:
> > > Currently, multiboot2-compatible bootloaders can load ELF binaries and
> > > a.out binaries. The pr
On 2024-03-18 17:35, Andrew Cooper wrote:
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 handlin
On 20.03.2024 11:46, Roger Pau Monné wrote:
> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
>> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
>> functions") having removed the sole place where d->g_iommu would be set
>> to non-NULL, guest_iommu_add_ppr_log() will
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> The function find_unallocated_memory is using the same code to
> loop through 3 structure of the same type, in order to avoid
> code duplication, rework the code to have only one loop that
> goes through all the structures.
>
> Signed-off
On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> With a02174c6c885 ("amd/iommu: clean up unused guest iommu related
> functions") having removed the sole place where d->g_iommu would be set
> to non-NULL, guest_iommu_add_ppr_log() will unconditionally bail the
> latest from its 2nd if
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> Introduce a new helper function in the static-memory module
> that can be called to manage static memory banks, this is
> done to reuse the code when other modules would like to
> manage static memory banks that are not part of the
> reser
On Tue, Jan 09, 2024 at 03:38:34PM +, Alejandro Vallejo wrote:
> This allows toolstack to synthesise sensible topologies for guests. In
> particular, this patch causes x2APIC IDs to be packed according to the
> topology now exposed to the guests on leaf 0xb.
>
> Signed-off-by: Alejandro Vallej
On Tue, Jan 09, 2024 at 03:38:33PM +, Alejandro Vallejo wrote:
> Implements the helper for mapping vcpu_id to x2apic_id given a valid
> topology in a policy. The algo is written with the intention of extending
> it to leaves 0x1f and e26 in the future.
>
> Toolstack doesn't set leaf 0xb and th
On Tue, Mar 19, 2024 at 1:22 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 too small one, to
> avoid functions bailing ear
On Tue, Mar 19, 2024 at 05:20:35PM +0100, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
> > This allows the initial x2APIC ID to be sent on the migration stream. The
> > hardcoded mapping x2apic_id=2*vcpu_id is maintained for the time being.
> > Given t
On 19/03/2024 13:10, Michal Orzel wrote:
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
Currently the 'stuct meminfo' is defining a static defined array of
'struct membank' of NR_MEM_BANKS elements, some feature like
shared memory don't require such amount of memory allocation but
migh
On 20.03.2024 09:51, Simone Ballarin wrote:
> MISRA C Rule 20.7 states: "The features of `' shall not be used"
>
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
>
> Functions hypercall_create_continu
On 20.03.2024 09:50, Simone Ballarin wrote:
> MISRA C:2012 Rule 17.1 states:
> The features of `' shall not be used
>
> The Xen community wants to avoid using variadic functions except for
> specific circumstances where it feels appropriate by strict code review.
>
> Add deviation for functions r
On 19/03/2024 17:45, Julien Grall wrote:
Hi Anthony,
On 19/03/2024 15:15, Anthony PERARD wrote:
Commit d638e304f13a introduced a bullet list, but parse-support-md
choke on it as it doesn't know what to do about it.
Introduce ri_BulletList() so that r_content() will find this new
function an
On 19.03.2024 21:35, Andrew Cooper wrote:
> On 25/01/2024 2:12 pm, Jan Beulich wrote:
>> "watchdog_timeout=0" is documented to disable the watchdog. Make sure
>> this also is true when there's a subsequent "watchdog" command line
>> option (and no further "watchdog_timeout=" one).
>
> We also docu
On 20/03/2024 06:35, Jürgen Groß wrote:
On 19.03.24 12:30, Andrew Cooper wrote:
The single user wants this the sane way around. Write it as a normal
static
inline just like rspin_lock().
Fixes: cc3e8df542ed ("xen/spinlock: add
rspin_[un]lock_irq[save|restore]()")
Signed-off-by: Andrew Co
MISRA C Rule 20.7 states: "The features of `' shall not be used"
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Functions hypercall_create_continuation and hypercall_xlat_continuation
are special hyperc
On Tue, Jan 09, 2024 at 03:38:32PM +, Alejandro Vallejo wrote:
> As part of topology correction efforts, APIC IDs can no longer be derived
> strictly through the vCPU ID alone. Bring in the machinery for policy
> retrieval and parsing in order to generate the proper MADT table and wake
> the ap
MISRA C:2012 Rule 17.1 states:
The features of `' shall not be used
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Add deviation for functions related to console output (printk and similar).
Signed-off
On 20/03/2024 09:35, Jan Beulich wrote:> If you send using Outlook, why don't
you simply send the patch(es) as
replies to the cover letter? That's what I'm doing using Thunderbird
(i.e. like you I'm not using "git send-email").
Jan
I do use "git send-email" actually, I have it set up to use t
MISRA C Rule 20.7 states: "The features of `' shall not be used".
The Xen community wants to avoid using variadic functions except for
specific circumstances where it feels appropriate by strict code review.
Functions hypercall_create_continuation and hypercall_xlat_continuation
are special hyper
On 20.03.2024 08:59, Rafaël Kooi wrote:
> On 20/03/2024 08:55, Jan Beulich wrote:
>> On 20.03.2024 08:48, Rafaël Kooi wrote:
>>> V2: Now without test emails ending up on the mailing list. And with the
>>> correct title prefix.
>>>
>>> I noticed that the systemd services referenced the XENCONSOLED_A
On 19.03.2024 12:30, Andrew Cooper wrote:
> The single user wants this the sane way around. Write it as a normal static
> inline just like rspin_lock().
>
> Fixes: cc3e8df542ed ("xen/spinlock: add rspin_[un]lock_irq[save|restore]()")
> Signed-off-by: Andrew Cooper
Notwithstanding Jürgen's R-b I
On 19.03.2024 18:40, Andrew Cooper wrote:
> It occurs to me that I need this hunk too.
>
> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
> index 25d329ce486f..bf3f9ec01e6e 100755
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -329,6 +329,10 @@ def crunch_numbers(
On Tue, Mar 19, 2024 at 07:58:56PM +, Andrew Cooper wrote:
> Require 's' to be superpage aligned if given over a superpage mapping. This
> is expected to be the case in practice, and prevents the v getting misaligned
> over superpages during the processing loop.
>
> Rmove the requirement for
On 20/03/2024 08:55, Jan Beulich wrote:
On 20.03.2024 08:48, Rafaël Kooi wrote:
V2: Now without test emails ending up on the mailing list. And with the
correct title prefix.
I noticed that the systemd services referenced the XENCONSOLED_ARGS
variable, but it was missing from xencommons.
I actua
On 20.03.2024 08:48, Rafaël Kooi wrote:
> V2: Now without test emails ending up on the mailing list. And with the
> correct title prefix.
>
> I noticed that the systemd services referenced the XENCONSOLED_ARGS
> variable, but it was missing from xencommons.
> I actually ran into this when experime
1 - 100 of 112 matches
Mail list logo
