On 4/29/24 5:16 PM, Andrew Cooper wrote:
Delete the boot time rendering of advanced features. It's entirely ad-hoc and
not even everything printed here is used by Xen. It is available in
`xen-cpuid` now.
With (only) svm_load_segs_{,prefetch}() declared now in svm.h, only svm.c and
domain.c
flight 185864 xen-4.17-testing real [real]
flight 185874 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185864/
http://logs.test-lab.xenproject.org/osstest/logs/185874/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 185873 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185873/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 88781ccd744c73acbbbe9767627860a538b9f3a2
baseline version:
ovmf
Hi Julien,
On 4/30/2024 1:34 AM, Julien Grall wrote:
On 29/04/2024 04:36, Henry Wang wrote:
Hi Jan, Julien, Stefano,
Hi Henry,
On 4/24/2024 2:05 PM, Jan Beulich wrote:
On 24.04.2024 05:34, Henry Wang wrote:
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1197,7
Hi Julien,
Sorry for the late reply,
On 4/25/2024 10:28 PM, Julien Grall wrote:
Hi,
On 25/04/2024 08:06, Henry Wang wrote:
Hi Julien,
On 4/24/2024 8:58 PM, Julien Grall wrote:
Hi Henry,
On 24/04/2024 04:34, Henry Wang wrote:
From: Vikram Garhwal
Enable interrupt assign/remove for
On 30-04-24, 03:11, Andrei Cherechesu wrote:
> Are there any other virtio device types you managed to test so far
> besides these ones (over virtio-mmio/virtio-grant)? Has anyone
> tested the rust-vmm vhost-device backends from Viresh with Xen?
I have tested them earlier with Xen emulated with
Hi Daniel,
On 4/30/2024 8:27 AM, Daniel P. Smith wrote:
On 4/25/24 23:14, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
Hi Daniel,
On 4/30/2024 8:31 AM, Daniel P. Smith wrote:
On 4/26/24 02:21, Jan Beulich wrote:
On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -76,6 +76,7 @@
*/
#define HVM_PARAM_STORE_PFN 1
#define
On 4/29/24 20:35, Daniel P. Smith wrote:
On 4/25/24 23:14, Henry Wang wrote:
For use cases such as Dom0less PV drivers, a mechanism to communicate
Dom0less DomU's static data with the runtime control plane (Dom0) is
needed. Since on Arm HVMOP is already the existing approach to address
such use
On 4/26/24 00:04, Jason Andryuk wrote:
An XSM hook for get_dom0_console is currently missing. Using XSM with
a PVH dom0 shows:
(XEN) FLASK: Denying unknown platform_op: 64.
Wire up the hook, and allow it for dom0.
Fixes: 4dd160583c ("x86/platform: introduce hypercall to get initial video
On 4/25/24 23:14, Henry Wang wrote:
For use cases such as Dom0less PV drivers, a mechanism to communicate
Dom0less DomU's static data with the runtime control plane (Dom0) is
needed. Since on Arm HVMOP is already the existing approach to address
such use cases (for example the allocation of
On 4/26/24 02:21, Jan Beulich wrote:
On 26.04.2024 05:14, Henry Wang wrote:
--- a/xen/include/public/hvm/params.h
+++ b/xen/include/public/hvm/params.h
@@ -76,6 +76,7 @@
*/
#define HVM_PARAM_STORE_PFN1
#define HVM_PARAM_STORE_EVTCHN 2
+#define HVM_PARAM_MAGIC_BASE_PFN3
On 4/25/24 23:14, Henry Wang wrote:
There are use cases (for example using the PV driver) in Dom0less
setup that require Dom0less DomUs start immediately with Dom0, but
initialize XenStore later after Dom0's successful boot and call to
the init-dom0less application.
An error message can seen
flight 185865 xen-4.18-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185865/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185724
On 12/04/2024 11:35, Edgar E. Iglesias wrote:
> On Fri, Apr 12, 2024 at 1:23 AM Stefano Stabellini
> wrote:
>
> -Vikram +Edgar
>
> On Thu, 11 Apr 2024, Andrei Cherechesu wrote:
>>> I've managed to successfully get a DomU up and running with the rootfs
>>> based on virtio-blk. I'm running QEMU
Hi Bertrand,
On 29/04/2024 08:20, Bertrand Marquis wrote:
From the comment in sched.h:
/*
* rcu_lock_domain_by_id() is more efficient than get_domain_by_id().
* This is the preferred function if the returned domain reference
* is short lived, but it cannot be used if the domain
flight 185863 linux-6.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185863/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 185746
Tests which did not
On 2023-12-18 15:48, Jan Beulich wrote:
... in order to also deny Dom0 access through the alias ports. Without
this it is only giving the impression of denying access to both PICs.
Unlike for CMOS/RTC, do detection very early, to avoid disturbing
normal
operation later on.
Like for CMOS/RTC a
On 2024-04-26 10:01, Andrew Cooper wrote:
modules_headroom is a misleading name as it applies strictly to mod[0] only,
and the movement loop is deeply unintuitive and completely undocumented.
Provide help to whomever needs to look at this code next.
Signed-off-by: Andrew Cooper
---
CC: Jan
Make use of the new xstate_uncompressed_size() helper rather than maintaining
the running calculation while accumulating feature components.
The rest of the CPUID data can come direct from the raw cpu policy. All
per-component data form an ABI through the behaviour of the X{SAVE,RSTOR}*
If max leaf is greater than 0xd but xsave not available to the guest, then the
current XSAVE size should not be filled in. This is a latent bug for now as
the guest max leaf is 0xd, but will become problematic in the future.
The comment concerning XSS state is wrong. VT-x doesn't manage
Various fixes and improvements to xsave image size calculations.
Since v1:
* Rebase over exposing XSAVEC. This has highlighted several latent bugs.
* Rework the uncompressed size handling. LWP / APX_F make for much sadness.
Be aware that Intel and AMD have different ABIs for the xstate
We're soon going to need a compressed helper of the same form.
The size of the uncompressed image depends on the single element with the
largest offset+size. Sadly this isn't always the element with the largest
index.
Retain the cross-check with hardware in debug builds, but forgo it normal
HVM_CPU_XSAVE_SIZE() may rewrite %xcr0 twice. Defer the caluclation it until
after we've decided to write out an XSAVE record.
Note in hvm_load_cpu_xsave_states() that there were versions of Xen which
wrote out a useless XSAVE record. This sadly limits out ability to tidy up
the existing
On 29/04/2024 04:36, Henry Wang wrote:
Hi Jan, Julien, Stefano,
Hi Henry,
On 4/24/2024 2:05 PM, Jan Beulich wrote:
On 24.04.2024 05:34, Henry Wang wrote:
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -1197,7 +1197,9 @@ struct xen_sysctl_dt_overlay {
#define
flight 185862 linux-linus real [real]
flight 185869 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185862/
http://logs.test-lab.xenproject.org/osstest/logs/185869/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Juergen,
On 29/04/2024 12:28, Jürgen Groß wrote:
On 29.04.24 13:04, Julien Grall wrote:
Hi Juergen,
Sorry for the late reply.
On 29/04/2024 11:33, Juergen Gross wrote:
On 08.04.24 09:10, Jan Beulich wrote:
On 27.03.2024 16:22, Juergen Gross wrote:
With lock handling now allowing up to
flight 185868 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185868/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 094727264f887e275444bd11d9d99c651a85c2e4
baseline version:
ovmf
On 29.04.2024 17:45, Alessandro Zucchelli wrote:
> Change #ifdef CONFIG_MEM_ACCESS by OR-ing defined(CONFIG_ARM),
> allowing asm/mem_access.h to be included in all ARM build configurations.
> This is to address the violation of MISRA C: 2012 Rule 8.4 which states:
> "A compatible declaration shall
On 27.04.2024 01:16, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
>> --- a/xen/arch/x86/cpu/mcheck/Makefile
>> +++ b/xen/arch/x86/cpu/mcheck/Makefile
>> @@ -1,12 +1,10 @@
>> -obj-y += amd_nonfatal.o
>> -obj-y += mce_amd.o
>> obj-y += mcaction.o
>> obj-y += barrier.o
>>
Commit 262fc47ac174 ('xen/balloon: don't use PV mode extra memory for zone
device allocations') removed the addition of the extra memory ranges to the
unpopulated range allocator, using those only for the balloon driver.
This forces the unpopulated allocator to attach hotplug ranges even when
On 27.04.2024 01:14, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Sergiy Kibrik wrote:
>> Add check for CONFIG_INTEL build option to conditional call of this routine,
>> so that if Intel support is disabled the call would be eliminated.
>>
>> No functional change intended.
>>
>> Signed-off-by:
Change #ifdef CONFIG_MEM_ACCESS by OR-ing defined(CONFIG_ARM),
allowing asm/mem_access.h to be included in all ARM build configurations.
This is to address the violation of MISRA C: 2012 Rule 8.4 which states:
"A compatible declaration shall be visible when an object or function
with external
On 23.04.2024 10:56, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -761,7 +761,8 @@ void mcheck_init(struct cpuinfo_x86 *c, bool bsp)
> {
> case X86_VENDOR_AMD:
> case X86_VENDOR_HYGON:
> -inited = amd_mcheck_init(c,
On 23.04.2024 10:54, Sergiy Kibrik wrote:
> Guard access to Intel-specific lmce_support & cmci_support variables in
> common MCE/VMCE code. These are set in Intel-specific parts of mcheck code
> and can potentially be skipped if building for non-intel platform by
> disabling CONFIG_INTEL option.
>
On 23.04.2024 10:52, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/cpu/mcheck/vmce.c
> +++ b/xen/arch/x86/cpu/mcheck/vmce.c
> @@ -141,12 +141,14 @@ static int bank_mce_rdmsr(const struct vcpu *v,
> uint32_t msr, uint64_t *val)
> case X86_VENDOR_CENTAUR:
> case X86_VENDOR_SHANGHAI:
>
On 23.04.2024 10:50, Sergiy Kibrik wrote:
> Since MCG_LMCE_P bit is specific to Intel CPUs
That's the case now. It could change going forward, and an underlying hypervisor
might also have (obscure?) reasons to surface it elsewhere.
> the code to check it can
> possibly be excluded from build if
On 23.04.2024 10:48, Sergiy Kibrik wrote:
> --- a/xen/arch/x86/include/asm/vpmu.h
> +++ b/xen/arch/x86/include/asm/vpmu.h
> @@ -11,6 +11,7 @@
> #define __ASM_X86_HVM_VPMU_H_
>
> #include
> +#include
>
> #define vcpu_vpmu(vcpu) (&(vcpu)->arch.vpmu)
> #define vpmu_vcpu(vpmu)
On 29/04/2024 4:16 pm, Andrew Cooper wrote:
> diff --git a/xen/tools/gen-cpuid.py b/xen/tools/gen-cpuid.py
> index bf3f9ec01e6e..f07b1f4cf905 100755
> --- a/xen/tools/gen-cpuid.py
> +++ b/xen/tools/gen-cpuid.py
> @@ -280,6 +280,9 @@ def crunch_numbers(state):
> # standard 3DNow in the
Do not allow_failure for triggered analyses:
introducing regressions of clean guidelines will cause a CI failure.
Signed-off-by: Federico Serafini
---
automation/gitlab-ci/analyze.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/automation/gitlab-ci/analyze.yaml
Patch 1/3 does some preparation work.
Patch 2/3, as the title says, removes allow_failure = true for triggered
analyses.
Patch 3/3 makes explicit that initally no files are tagged as adopted, this
is needed by the scheduled analysis.
Federico Serafini (3):
automation/eclair: tag Rule 7.2 as
Update ECLAIR configuration to consider no adopted files by default.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/analysis.ecl | 4
1 file changed, 4 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/analysis.ecl
Update ECLAIR configuration to consider Rule 7.2 as clean.
Temporarily remove the clean tag from Rules 1.1 and 8.2:
when violations of such rules will be addressed, the clean tag will be
reintroduced.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1
On 24.04.2024 18:34, Daniel P. Smith wrote:
> Move the crc and its state into struct gunzip_state. In the process, expand
> the
> only use of CRC_VALUE as it is hides what is being compared.
Andrew mentioned uint32_t only for the description, but I think you want
(maybe even need) to go further
Allocate two new feature leaves, and extend cpu_policy with the non-feature
fields too.
The CPUID dependency between the SVM bit on the whole SVM leaf is
intentionally deferred, to avoid transiently breaking nested virt.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC:
Delete the boot time rendering of advanced features. It's entirely ad-hoc and
not even everything printed here is used by Xen. It is available in
`xen-cpuid` now.
With (only) svm_load_segs_{,prefetch}() declared now in svm.h, only svm.c and
domain.c which need the header. Clean up all others.
This is (half) the series I've promised various people, to untangle some AMD
CPUID handling. It moves the SVM feature leaf into the standard
x86_capabilities[] infrastructure.
On a random Milan system, with this in place, xen-cpuid reports:
Dynamic sets:
Raw
For display purposes only right now.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Xenia Ragiadakou
CC: Sergiy Kibrik
CC: George Dunlap
CC: Andrei Semenov
CC: Vaishali Thakkar
This is only half the work to get SEV working nicely. The
Now that the SVM feature leaf has been included in normal feature handling, it
is available early enough for init_speculation_mitigations() to use.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Xenia Ragiadakou
CC:
These will replace svm_feature_flags and the SVM_FEATURE_* constants over the
next few changes. Take the opportunity to rationalise some names.
Drop the opencoded "inherit from host" logic in calculate_hvm_max_policy() and
use 'h'/'!' annotations. The logic needs to operate on fs, not the
On 24.04.2024 18:34, Daniel P. Smith wrote:
> --- a/xen/common/gzip/gunzip.c
> +++ b/xen/common/gzip/gunzip.c
> @@ -15,6 +15,8 @@ struct gunzip_state {
> size_t insize;
> /* Index of next byte to be processed in inbuf: */
> unsigned int inptr;
> +
> +unsigned long bytes_out;
>
On 24.04.2024 18:34, Daniel P. Smith wrote:
> --- a/xen/common/gzip/gunzip.c
> +++ b/xen/common/gzip/gunzip.c
> @@ -10,13 +10,12 @@ struct gunzip_state {
> unsigned char *window;
> /* window pointer: */
> unsigned int wp;
> -};
> -
> -static unsigned char *__initdata inbuf;
>
So it can be used by kpatch_process_special_sections() in further changes.
Non functional change.
Signed-off-by: Roger Pau Monné
---
create-diff-object.c | 74 ++--
1 file changed, 37 insertions(+), 37 deletions(-)
diff --git a/create-diff-object.c
When deciding whether there's content to generate a payload also take into
account whether special sections have changed. Initially account for changes
to alternative related section to cause the generation of a livepatch.
Note that accounting for hook sections is already done by
bug_frame related sections exclusively contain addresses that reference back to
the address where the BUG_INSTR is executed. As such, any change to the
contents of bug_frame sections (or it's relocations) will necessarily require a
change in the caller function, as the placement of the BUG_INSTR
The current runes assume that in the list of DWARF tags DW_AT_byte_size will
come after DW_AT_name, but that's not always the case. On one of my builds
I've seen:
DW_AT_name: (indirect string, offset: 0x3c45):
exception_table_entry
DW_AT_declaration : 1
<1>: Abbrev
XenServer uses quite long Xen version names, and encode such in the livepatch
filename, and it's currently running out of space in the file name.
Bump max filename size to 127, so it also matches the patch name length in the
hypervisor interface. Note the size of the buffer is 128 character, and
The current logic to detect changes in special sections elements will only
include group elements that reference function symbols that need including
(either because they have changed or are new).
This works fine in order to detect when a special section element needs
including because of the
Changes to special sections are not accounted for right now. For example a
change that only affects .altinstructions or .ex_table won't be included in the
livepatch payload, if none of the symbols referenced by those sections have
also changed.
Since it's not possible to know which elements in
The purpose of kpatch_regenerate_special_section() is fairly opaque without
spending a good amount of time and having quite a lot of knowledge about what
the special sections contains.
Introduce some comments in order to give context and describe the expected
functionality.
Signed-off-by: Roger
Hello,
The first 3 patches in the series attempt to fix some bugs, I don't
think they will be specially controversial or difficult to review (patch
1 was already posted standalone).
The rest of the patches are more convoluted, as they attempt to solve
some shortcomings when attempting to create
The size of the alt_instr structure in Xen is 14 instead of 12 bytes, adjust
it.
Signed-off-by: Roger Pau Monné
---
create-diff-object.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/create-diff-object.c b/create-diff-object.c
index fed360a9aa68..d8a2afbf2774 100644
---
On Mon, Apr 29, 2024 at 03:01:00PM +0200, Jan Beulich wrote:
> revert "x86/mm: re-implement get_page_light() using an atomic increment"
>
> This reverts commit c40bc0576dcc5acd4d7e22ef628eb4642f568533.
>
> That change aimed at eliminating an open-coded lock-like construct,
> which really isn't
On 24.04.2024 18:34, Daniel P. Smith wrote:
> Move the window pointer, outcnt/wp, into struct gunzip_data. It was
> erroneously
> labeled as outcnt and then define aliased to wp, this eliminates the aliasing
> and only refers to as wp, the window pointer.
>
> Signed-off-by: Daniel P. Smith
On 24.04.2024 18:34, Daniel P. Smith wrote:
> This commit refactors macros into proper static functions. It in-place expands
> the `flush_output` macro, allowing the clear removal of the dead code
> underneath the `underrun` label.
But it's NEXTBYTE() which uses the label, not flush_output(). I'm
On 17.04.2024 12:04, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,281 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Taken and modified from Linux.
> + *
> + * The following changes were done:
> + * - *
When the evtchn_status hypercall fails, it is not possible to determine
the cause of the error, since the library call returns -1 to the tool
and not the errno.
Because of this, lsevtchn is unable to determine whether to continue
event channel enumeration upon an evtchn_status hypercall error.
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
This results in lsevtchn missing potential relevant event channels with
higher port
lsevtchn terminates the loop when the hypercall returns an error, even
if there are still event channels with higher port numbers to be
enumerated over.
Continue the loop even on hypercall errors, and use the new status
identifiers for the evtchn_status hypercall, namely "port invalid" and
On 17.04.2024 12:04, Oleksii Kurochko wrote:
> +/*
> + * This function doesn't exist, so you'll get a linker error
> + * if something tries to do an invalid xchg().
> + */
> +extern void __bad_xchg(volatile void *ptr, int size);
> +
> +static always_inline unsigned long __xchg(volatile void *ptr,
On 26.04.2024 17:23, Oleksii Kurochko wrote:
> Now, the check-extension() macro has 1 argument instead of 2.
> This change helps to reduce redundancy around usage of extensions
> name (in the case of the zbb extension, the name was used 3 times).
>
> To implement this, a new variable was
On 29/04/2024 2:01 pm, Jan Beulich wrote:
> revert "x86/mm: re-implement get_page_light() using an atomic increment"
>
> This reverts commit c40bc0576dcc5acd4d7e22ef628eb4642f568533.
>
> That change aimed at eliminating an open-coded lock-like construct,
> which really isn't all that similar to,
revert "x86/mm: re-implement get_page_light() using an atomic increment"
This reverts commit c40bc0576dcc5acd4d7e22ef628eb4642f568533.
That change aimed at eliminating an open-coded lock-like construct,
which really isn't all that similar to, in particular, get_page(). The
function always
On 2024-04-29 14:44, Alessandro Zucchelli wrote:
Adjust ECLAIR configuration for rules: R21.14, R21.15, R21.16 by taking
into account mem* macros defined in the Xen sources as if they were
equivalent to the ones in Standard Library.
Signed-off-by: Alessandro Zucchelli
---
Adjust ECLAIR configuration for rules: R21.14, R21.15, R21.16 by taking
into account mem* macros defined in the Xen sources as if they were
equivalent to the ones in Standard Library.
Signed-off-by: Alessandro Zucchelli
---
automation/eclair_analysis/ECLAIR/analysis.ecl | 17 +
On 2024-04-25 02:28, Stefano Stabellini wrote:
On Tue, 23 Apr 2024, Nicola Vetrini wrote:
The count_args_ macro violates Rule 20.7, but it can't be made
compliant with Rule 20.7 without breaking its functionality. Since
it's very unlikely for this macro to be misused, it is deviated.
That is
Hi,
I'd like to dispute CVE-2024-26908: the issue fixed by upstream commit
3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 can in no way be triggered by
an unprivileged user or by a remote attack of the system, as it requires
hotplug of (virtual) cpus to the running system. This can be done only by
On 26.04.2024 16:01, Andrew Cooper wrote:
> The expression get more complicated when ->mod_end isn't being abused as a
> size field. Introduce and use a initrd_len local variable.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 26.04.2024 16:01, Andrew Cooper wrote:
> discard_initial_images() frees the memory backing the boot modules. It is
> called by dom0_construct_pv{,h}(), but obtains the module list by global
> pointer which is why there is no apparent link with the initrd pointer.
>
> Generally, module
On 26.04.2024 16:01, Andrew Cooper wrote:
> modules_headroom is a misleading name as it applies strictly to mod[0] only,
> and the movement loop is deeply unintuitive and completely undocumented.
>
> Provide help to whomever needs to look at this code next.
>
> Signed-off-by: Andrew Cooper
On 29.04.24 13:04, Julien Grall wrote:
Hi Juergen,
Sorry for the late reply.
On 29/04/2024 11:33, Juergen Gross wrote:
On 08.04.24 09:10, Jan Beulich wrote:
On 27.03.2024 16:22, Juergen Gross wrote:
With lock handling now allowing up to 16384 cpus (spinlocks can handle
65535 cpus, rwlocks
Hi Juergen,
Sorry for the late reply.
On 29/04/2024 11:33, Juergen Gross wrote:
On 08.04.24 09:10, Jan Beulich wrote:
On 27.03.2024 16:22, 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
On 25.04.24 19:32, Andrew Cooper wrote:
libsystemd is a giant dependency for one single function, but in the wake of
the xz backdoor, it turns out that even systemd leadership recommend against
linking against libsystemd for sd_notify().
Since commit 7b61011e1450 ("tools: make xenstore domain
flight 185860 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185860/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185839
On 08.04.24 09:10, Jan Beulich wrote:
On 27.03.2024 16:22, 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
On 29.04.2024 12:26, Petr Beneš wrote:
> On Mon, Apr 29, 2024 at 9:07 AM Jan Beulich wrote:
>>
>> On 28.04.2024 18:52, Petr Beneš wrote:
>>> From: Petr Beneš
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Petr Beneš
>>
>> Where did Stefano's R-b go?
>
> Oh no, I missed that one. Should I
On Mon, Apr 29, 2024 at 9:07 AM Jan Beulich wrote:
>
> On 28.04.2024 18:52, Petr Beneš wrote:
> > From: Petr Beneš
> >
> > No functional change.
> >
> > Signed-off-by: Petr Beneš
>
> Where did Stefano's R-b go?
>
> Jan
Oh no, I missed that one. Should I do v3?
Hi Julien,
On Fri, Apr 26, 2024 at 7:58 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 26/04/2024 09:47, Jens Wiklander wrote:
> > +static void notif_irq_enable(void *info)
> > +{
> > +struct notif_irq_info *irq_info = info;
> > +
> > +irq_info->ret = setup_irq(irq_info->irq, 0,
Hi Bertrand,
On Mon, Apr 29, 2024 at 9:20 AM Bertrand Marquis
wrote:
[...]
> >> +static void notif_irq_handler(int irq, void *data)
> >> +{
> >> +const struct arm_smccc_1_2_regs arg = {
> >> +.a0 = FFA_NOTIFICATION_INFO_GET_64,
> >> +};
> >> +struct arm_smccc_1_2_regs resp;
>
On 29/04/2024 8:49 am, Jan Beulich wrote:
> On 26.04.2024 18:08, Andrew Cooper wrote:
>> Some features need accumulating rather than intersecting to make migration
>> safe. Introduce the new '|' attribute for this purpose.
>>
>> Right now, it's only used by the Xapi toolstack, but it will be used
Hi Julien,
On Fri, Apr 26, 2024 at 9:07 PM Julien Grall wrote:
>
> Hi Jens,
>
> On 26/04/2024 09:47, Jens Wiklander wrote:
> > diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> > index d7306aa64d50..5224898265a5 100644
> > --- a/xen/arch/arm/irq.c
> > +++ b/xen/arch/arm/irq.c
> > @@ -155,7
On Wed, Mar 13, 2024 at 04:16:06PM +0100, Marek Marczykowski-Górecki wrote:
> QEMU needs to know whether clearing maskbit of a vector is really
> clearing, or was already cleared before. Currently Xen sends only
> clearing that bit to the device model, but not setting it, so QEMU
> cannot detect
On 26.04.2024 18:08, Andrew Cooper wrote:
> Some features need accumulating rather than intersecting to make migration
> safe. Introduce the new '|' attribute for this purpose.
>
> Right now, it's only used by the Xapi toolstack, but it will be used by
> xl/libxl when the full policy-object work
Hi Julien,
> On 26 Apr 2024, at 21:07, Julien Grall wrote:
>
> Hi Jens,
>
> On 26/04/2024 09:47, Jens Wiklander wrote:
>> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
>> index d7306aa64d50..5224898265a5 100644
>> --- a/xen/arch/arm/irq.c
>> +++ b/xen/arch/arm/irq.c
>> @@ -155,7 +155,7
On 26.04.2024 13:33, Andrew Cooper wrote:
> Hi,
>
> Based on a call a long while back, I experimented with -Wextra-semi.
> This is what lead to 8e36c668ca107 "xen: Drop superfluous semi-colons".
>
> However, there are a number of problems with getting this working
> fully. First, we need
On 28.04.2024 18:52, Petr Beneš wrote:
> From: Petr Beneš
>
> No functional change.
>
> Signed-off-by: Petr Beneš
Where did Stefano's R-b go?
Jan
On 29.04.2024 05:36, Henry Wang wrote:
> Hi Jan, Julien, Stefano,
>
> On 4/24/2024 2:05 PM, Jan Beulich wrote:
>> On 24.04.2024 05:34, Henry Wang wrote:
>>> --- a/xen/include/public/sysctl.h
>>> +++ b/xen/include/public/sysctl.h
>>> @@ -1197,7 +1197,9 @@ struct xen_sysctl_dt_overlay {
>>>
On 26.04.2024 17:26, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 25, 2024 at 01:15:34PM +0200, Jan Beulich wrote:
>> On 13.03.2024 16:16, Marek Marczykowski-Górecki wrote:
>>> +hwaddr = fix_to_virt(fixmap_idx) + PAGE_OFFSET(address);
>>> +
>>> +switch ( len )
>>> +{
>>> +case
On 26.04.2024 16:33, Stewart Hildebrand wrote:
> On 4/26/24 02:31, Jan Beulich wrote:
>> On 25.04.2024 22:45, Stewart Hildebrand wrote:
>>> The ->profile member is at different offsets in struct rspinlock and
>>> struct spinlock. When initializing the profiling bits of an rspinlock,
>>> an
99 matches
Mail list logo
