On 11.01.2023 23:29, Andrew Cooper wrote:
> For posterity,
> https://gitlab.com/xen-project/people/andyhhp/xen/-/jobs/3585379553 is
> the issue in question.
>
> In file included from arch/x86/hvm/hvm.c:82:
> ./include/compat/hvm/hvm_op.h:6:10: fatal error: ../trace.h: No such
> file or directory
On 11.01.2023 22:05, Andrew Cooper wrote:
> On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/vmx/vmx.c
>> +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> @@ -1428,10 +1428,19 @@ static void cf_check vmx_update_host_cr3(struct vcpu
>> *v)
>>
>> void vmx_update_debug_state(struct vcpu
flight 175730 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175730/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月11日 0:47
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject:
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月11日 0:38
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org
> Subject:
On 11.01.23 18:48, Julien Grall wrote:
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative value. Then
it would not work.
A good example imagine you have a transaction removing nodes from tree but
not adding any. Then the
flight 175733 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
flight 175732 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175732/
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
flight 175726 xen-unstable real [real]
flight 175731 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/175726/
http://logs.test-lab.xenproject.org/osstest/logs/175731/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
> From: Andrew Cooper
> Sent: Monday, January 9, 2023 8:08 PM
>
> Ice Lake (server at least) has both Arch LBR and model-specific LBR. Sapphire
> Rapids does not have model-specific LBR at all. I.e. On SPR and later,
> model_specific_lbr will always be NULL, so we must make changes to avoid
>
> From: Andrew Cooper
> Sent: Monday, January 9, 2023 8:08 PM
>
> There is no point repeating this calculation at runtime, especially as it is
> in the fallback path of the WRSMR/RDMSR handlers.
>
> Move the infrastructure higher in vmx.c to avoid forward declarations,
> renaming
On 11/01/2023 1:53 pm, Jan Beulich wrote:
> v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
> v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
> hash table are all only ever written with valid MFNs or INVALID_MFN.
> Avoid the somewhat expensive mfn_valid()
On 11/01/2023 1:56 pm, Jan Beulich wrote:
> The "n" input is a GFN/MFN value and hence bounded by the physical
> address bits in use on a system. The hash quality won't improve by also
> including the upper always-zero bits in the calculation. To keep things
> as compile-time-constant as they were
flight 175729 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
On 11/01/2023 1:57 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/mm/shadow/common.c
> +++ b/xen/arch/x86/mm/shadow/common.c
> @@ -2264,6 +2264,29 @@ void shadow_prepare_page_type_change(str
> shadow_remove_all_shadows(d, page_to_mfn(page));
> }
>
> +/*
> + * Removes
On 11/01/2023 1:57 pm, Jan Beulich wrote:
> Make HVM=y release build behavior prone against array overrun, by
> (ab)using array_access_nospec(). This is in particular to guard against
> e.g. SH_type_unused making it here unintentionally.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
>
> ---
On 11/01/2023 6:17 pm, Anthony PERARD wrote:
> Some compat headers depends on other compat headers that may not have
> been generated due to config option.
>
> This would be a generic way to deal with deps, instead of
> headers-$(call or $(CONFIG_TRACEBUFFER),$(CONFIG_HVM)) += compat/trace.h
>
flight 175723 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
On 11/01/2023 11:45 am, Jan Beulich wrote:
> On 11.01.2023 12:39, Andrew Cooper wrote:
>> The bigger issue with stuff accounting is that nothing AFAICT accounts
>> for the fact that any hypercall potentially empties the RSB in otherwise
>> synchronous program flow.
> But that's not just at
flight 175727 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175727/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
On 13/12/2022 4:31 pm, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index a0d5e8d6ab..3d7c471a3f 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -1290,6 +1296,17 @@ static int construct_vmcs(struct vcpu *v)
>
flight 175728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175728/
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
Some compat headers depends on other compat headers that may not have
been generated due to config option.
This would be a generic way to deal with deps, instead of
headers-$(call or $(CONFIG_TRACEBUFFER),$(CONFIG_HVM)) += compat/trace.h
This is just an RFC, as it only deals with "hvm_op.h"
Hi,
On 11/01/2023 09:27, Juergen Gross wrote:
On 20.12.22 22:50, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -115,47 +117,32 @@ hashtable_expand(struct hashtable *h)
if (h->primeindex == (prime_table_length - 1)) return 0;
newsize =
Hi Juergen,
On 11/01/2023 08:59, Juergen Gross wrote:
... to make sure domain_nbentry_add() is not returning a negative
value. Then it would not work.
A good example imagine you have a transaction removing nodes from tree
but not adding any. Then the "ret" would be negative.
Meanwhile the
Hi Juergen,
On 11/01/2023 06:41, Juergen Gross wrote:
On 20.12.22 20:39, Julien Grall wrote:
+static void fire_special_watches(const char *name)
+{
+ void *ctx = talloc_new(NULL);
+ struct node *node;
+
+ if (!ctx)
+ return;
+
+ node = read_node(NULL, ctx, name);
+
+ if
Hi Juergen,
On 11/01/2023 06:36, Juergen Gross wrote:
On 20.12.22 20:01, Julien Grall wrote:
On 13/12/2022 16:00, Juergen Gross wrote:
When a domain has been released by Xen tools, remove all its
registered watches. This avoids sending watch events to the dead domain
when all the nodes
(+Stefano)
On 10/01/2023 14:20, El Mesdadi Youssef ESK UILD7 wrote:
Hello,
I'm trying to measure the performance of Xen on the S32G3 microprocessor,
unfortunately, after following the BSP-Linux to install Xen, I found that
Xentrace is not available or not compatible with ARM
Hi Luca,
On 11/01/2023 14:38, Luca Fancellu wrote:
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and the number of SVE register bits that are allowed
for this domain.
The field is used also to allow or
Hi Luca,
As this is an RFC, I will be mostly making general comments.
On 11/01/2023 14:38, Luca Fancellu wrote:
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 99577adb6c69..8ea3843ea8e8 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -181,6 +181,8 @@ static
flight 175725 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175725/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
Hi Luca,
On 11/01/2023 14:38, Luca Fancellu wrote:
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using
flight 175720 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175720/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-freebsd10-i386 7 xen-install fail pass in 175714
test-amd64-i386-pair 10
On 1/10/23 3:16 AM, Michael S. Tsirkin wrote:
> On Tue, Jan 10, 2023 at 02:08:34AM -0500, Chuck Zmudzinski wrote:
>> Intel specifies that the Intel IGD must occupy slot 2 on the PCI bus,
>> as noted in docs/igd-assign.txt in the Qemu source code.
>>
>> Currently, when the xl toolstack is used to
On 1/11/23 17:03, Jan Beulich wrote:
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
@@ -116,7 +115,11 @@ static int __init cf_check parse_iommu_param(const char *s)
iommu_verbose = 1;
}
else if ( (val = parse_boolean("amd-iommu-perdev-intremap", s, ss))
>=
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> @@ -116,7 +115,11 @@ static int __init cf_check parse_iommu_param(const char
> *s)
> iommu_verbose = 1;
> }
> else if ( (val = parse_boolean("amd-iommu-perdev-intremap", s, ss))
> >= 0 )
> +#ifdef CONFIG_AMD_IOMMU
On 04.01.2023 09:44, Xenia Ragiadakou wrote:
> Introduce two new Kconfig options, AMD_IOMMU and INTEL_IOMMU, to allow code
> specific to each IOMMU technology to be separated and, when not required,
> stripped. AMD_IOMMU will be used to enable IOMMU support for platforms that
> implement the AMD
On 1/11/23 15:17, Jan Beulich wrote:
On 11.01.2023 13:30, Xenia Ragiadakou wrote:
Could you please help me understand also
why __signed__ keyword is required when declaring __{u,s}?
I mean why __{u,s} cannot be declared using the signed type
specifier, just like {u,s}?
I'm afraid I can't,
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> Create empty mappings in the second e820 pass. Also, destroy existing
> direct map mappings created in the first pass.
Could you remind me (perhaps say a word here) why these need creating then
in the first place?
Jan
Add a command line parameter to allow Dom0 the use of SVE resources,
the command line parameter dom0_sve controls the feature on this
domain and sets the maximum SVE vector length for Dom0.
Signed-off-by: Luca Fancellu
---
docs/misc/xen-command-line.pandoc| 12
When a guest is allowed to use SVE, expose the SVE features through
the identification registers.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/arm64/vsysreg.c | 39 ++--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/arm64/vsysreg.c
Add a device tree property in the dom0less domU configuration
to enable the guest to use SVE.
Update documentation.
Signed-off-by: Luca Fancellu
---
docs/misc/arm/device-tree/booting.txt | 7 +++
xen/arch/arm/domain_build.c | 7 +++
2 files changed, 14 insertions(+)
diff
SVE has a new exception class with code 0x19, introduce the new code
and handle the exception.
Signed-off-by: Luca Fancellu
---
xen/arch/arm/include/asm/processor.h | 1 +
xen/arch/arm/traps.c | 12
2 files changed, 13 insertions(+)
diff --git
Add sve parameter in XL configuration to allow guests to use
SVE feature.
Signed-off-by: Luca Fancellu
---
docs/man/xl.cfg.5.pod.in | 11 +++
tools/golang/xenlight/helpers.gen.go | 2 ++
tools/golang/xenlight/types.gen.go | 1 +
tools/include/libxl.h| 5
On 16.12.2022 12:48, Julien Grall wrote:
> @@ -597,22 +598,43 @@ static unsigned long init_node_heap(int node, unsigned
> long mfn,
> needed = 0;
> }
> else if ( *use_tail && nr >= needed &&
> - arch_mfns_in_directmap(mfn + nr - needed, needed) &&
>
Add sve_vl_bits field to arch_domain and xen_arch_domainconfig
structure, to allow the domain to have an information about the
SVE feature and the number of SVE register bits that are allowed
for this domain.
The field is used also to allow or forbid a domain to use SVE,
because a value equal to
Save/restore context switch for SVE, allocate memory to contain
the Z0-31 registers whose length is maximum 2048 bits each and
FFR who can be maximum 256 bits, the allocated memory depends on
how many bits is the vector length for the domain and how many bits
are supported by the platform.
Save
This serie is introducing the possibility for Dom0 and DomU guests to use
sve/sve2 instructions.
SVE feature introduces new instruction and registers to improve performances on
floating point operations.
The SVE feature is advertised using the ID_AA64PFR0_EL1 register, SVE field, and
when
Enable Xen to handle the SVE extension, add code in cpufeature module
to handle ZCR SVE register, disable trapping SVE feature on system
boot, it will be restored later on vcpu creation and running.
While there, correct coding style for the comment on coprocessor
trapping.
Change the KConfig
On 16.12.2022 12:48, Julien Grall wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1648,6 +1648,22 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>
> numa_initmem_init(0, raw_max_page);
>
> +/*
> + * When we do not have a direct map, memory for
flight 175718 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175718/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 175684
test-amd64-amd64-libvirt-vhd 19
The original issue has been reported on AMD Bulldozer-based CPUs where
ucode loading loses the LWP feature bit in order to gain the IBPB bit.
LWP disabling is per-SMT/CMT core modification and needs to happen on
each sibling thread despite the shared microcode engine. Otherwise,
logical CPUs will
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> When there is not an always-mapped direct map, xenheap allocations need
> to be mapped and unmapped on-demand.
Hmm, that's still putting mappings in the directmap, which I thought we
mean to be doing away with. If that's just a
On 16.12.2022 12:48, Julien Grall wrote:
> From: Hongyan Xia
>
> When mfn is not in direct map, never use mfn_to_virt for any mappings.
>
> We replace mfn_x(mfn) <= PFN_DOWN(__pa(HYPERVISOR_VIRT_END - 1)) with
> arch_mfns_in_direct_map(mfn, 1) because these two are equivalent. The
> extra
Make HVM=y release build behavior prone against array overrun, by
(ab)using array_access_nospec(). This is in particular to guard against
e.g. SH_type_unused making it here unintentionally.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/arch/x86/mm/shadow/private.h
+++
There's nothing really mode specific in this function anymore (the
varying number of valid entries in v->arch.paging.shadow.shadow_table[]
is dealt with fine by the zero check, and we have other similar cases of
iterating through the full array in common.c), and hence there's neither
a need to
The "n" input is a GFN/MFN value and hence bounded by the physical
address bits in use on a system. The hash quality won't improve by also
including the upper always-zero bits in the calculation. To keep things
as compile-time-constant as they were before, use PADDR_BITS (not
paddr_bits) for loop
First of all move the almost loop-invariant condition out of the loop;
transform it into an altered loop boundary. Since the new local variable
wants to be "unsigned int" and named without violating name space rules,
convert the loop induction variable accordingly.
Signed-off-by: Jan Beulich
---
Like for the various HVM-only types, save a little bit of code by suitably
"masking" this type out when !PV32.
Signed-off-by: Jan Beulich
---
I wasn't really sure whether it would be worthwhile to also update the
"#else" part of shadow_size(). Doing so would be a little tricky, as the
type to
v->arch.paging.shadow.shadow_table[], v->arch.paging.shadow.oos[],
v->arch.paging.shadow.oos_{snapshot[],fixup[].smfn[]} as well as the
hash table are all only ever written with valid MFNs or INVALID_MFN.
Avoid the somewhat expensive mfn_valid() when checking MFNs coming from
these arrays.
The "domain" in there has become meaningless; drop it.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,15 +1640,15 @@ bool shadow_hash_delete(struct domain *d
return true;
}
-typedef int
flight 175722 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175722/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
The domain based variant is easily usable by shadow_audit_tables(); all
that's needed is conversion of the callback functions.
Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
--- a/xen/arch/x86/mm/shadow/common.c
+++ b/xen/arch/x86/mm/shadow/common.c
@@ -1640,59 +1640,11 @@ bool
Rather than doing a separate hash walk (and then even using the vCPU
variant, which is to go away), do the up-pointer-clearing right in
sh_unpin(), as an alternative to the (now further limited) enlisting on
a "free floating" list fragment. This utilizes the fact that such list
fragments are
... or so I hope. The main observation was that we still have both
hash_vcpu_for_each() and hash_domain_for_each(), where the latter was
introduced in 2014/15 to replace the former. Only some eight years
later we can now complete this conversion. Everything else addresses
other things noticed
flight 175721 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175721/
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
flight 175717 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm 8 xen-boot fail REGR. vs. 173462
On 11.01.2023 12:44, Julien Grall wrote:
> From: Julien Grall
>
> Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
> a structure that should not be used by any common code.
>
> The structure init_info is used to store information to setup the CPU
> currently being
On 11.01.2023 13:30, Xenia Ragiadakou wrote:
> Could you please help me understand also
> why __signed__ keyword is required when declaring __{u,s}?
> I mean why __{u,s} cannot be declared using the signed type
> specifier, just like {u,s}?
I'm afraid I can't, as this looks to have been
On 1/11/23 13:38, Jan Beulich wrote:
On 11.01.2023 11:22, Xenia Ragiadakou wrote:
On 1/11/23 11:08, Jan Beulich wrote:
On 11.01.2023 09:47, Oleksii wrote:
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
On 10.01.2023 16:17, Oleksii Kurochko wrote:
Signed-off-by: Oleksii Kurochko
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-6.2-rc4-tag
xen: branch for v6.2-rc4
It contains:
- 2 cleanup patches
- a fix of a memory leak in the Xen pvfront driver
- a fix of a locking issue in the Xen hypervisor console
> On 11 Jan 2023, at 11:44, Julien Grall wrote:
>
> From: Julien Grall
>
> Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
> a structure that should not be used by any common code.
>
> The structure init_info is used to store information to setup the CPU
>
On 11.01.23 12:30, Greg Kroah-Hartman wrote:
The driver core is changing to pass some pointers as const, so move
to_xenbus_device() to use container_of_const() to handle this change.
to_xenbus_device() now properly keeps the const-ness of the pointer passed
into it, while as before it could be
On Wed, Jan 11, 2023 at 9:44 PM Julien Grall wrote:
>
> From: Julien Grall
>
> Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
> a structure that should not be used by any common code.
>
> The structure init_info is used to store information to setup the CPU
>
On 11/01/2023 11:44 am, Julien Grall wrote:
> From: Julien Grall
>
> Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
> a structure that should not be used by any common code.
>
> The structure init_info is used to store information to setup the CPU
> currently being
On 11.01.2023 12:39, Andrew Cooper wrote:
> The bigger issue with stuff accounting is that nothing AFAICT accounts
> for the fact that any hypercall potentially empties the RSB in otherwise
> synchronous program flow.
But that's not just at hypercall boundaries, but effectively anywhere
(i.e.
From: Julien Grall
Both x86 and (soon) RISC-V version of init.h are empty. On Arm, it contains
a structure that should not be used by any common code.
The structure init_info is used to store information to setup the CPU
currently being brought-up. setup.h seems to be more suitable even though
On 11/01/2023 11:20 am, Peter Zijlstra wrote:
> On Mon, Jan 09, 2023 at 04:05:31AM +, Joan Bruguera wrote:
>> This fixes wakeup for me on both QEMU and real HW
>> (just a proof of concept, don't merge)
>>
>> diff --git a/arch/x86/kernel/callthunks.c b/arch/x86/kernel/callthunks.c
>> index
On 11.01.2023 11:22, Xenia Ragiadakou wrote:
>
> On 1/11/23 11:08, Jan Beulich wrote:
>> On 11.01.2023 09:47, Oleksii wrote:
>>> On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
On 10.01.2023 16:17, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes
The driver core is changing to pass some pointers as const, so move
to_xenbus_device() to use container_of_const() to handle this change.
to_xenbus_device() now properly keeps the const-ness of the pointer passed
into it, while as before it could be lost.
Cc: Juergen Gross
Cc: Stefano
On 11/01/2023 11:44, Andrew Cooper wrote:
>
>
> On 10/01/2023 4:25 pm, Oleksii Kurochko wrote:
>> All RISCV_64-related stuff was renamed to be consistent with
>> ARM (arm32 is cross build as RISCV_64).
>>
>> The patch is based on the following patch series:
>> [PATCH *] Basic early_printk and
On 10/01/2023 4:25 pm, Oleksii Kurochko wrote:
> All RISCV_64-related stuff was renamed to be consistent with
> ARM (arm32 is cross build as RISCV_64).
>
> The patch is based on the following patch series:
> [PATCH *] Basic early_printk and smoke test implementation
>
> Signed-off-by: Oleksii
On 1/11/23 11:08, Jan Beulich wrote:
On 11.01.2023 09:47, Oleksii wrote:
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
On 10.01.2023 16:17, Oleksii Kurochko wrote:
Signed-off-by: Oleksii Kurochko
---
Changes in V3:
- Nothing changed
---
Changes in V2:
- Remove unneeded
Hi Jan,
> -Original Message-
> From: Jan Beulich
> Sent: 2023年1月10日 18:00
> To: Wei Chen
> Cc: nd ; Stefano Stabellini ; Julien
> Grall ; Bertrand Marquis ;
> Volodymyr Babchuk ; Andrew Cooper
> ; George Dunlap ; Wei
> Liu ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH v2 01/17]
On Fri, 2023-01-06 at 10:36 +, Paul Durrant wrote:
> The scaling information in subleaf 1 should match the values set by KVM in
> the 'vcpu_info' sub-structure 'time_info' (a.k.a. pvclock_vcpu_time_info)
> which is shared with the guest, but is not directly available to the VMM.
> The offset
On Fri, 2023-01-06 at 10:35 +, Paul Durrant wrote:
> A subsequent patch will need to acquire the CPUID leaf range for emulated
> Xen so explicitly pass the signature of the hypervisor we're interested in
> to the new function. Also introduce a new kvm_hypervisor_cpuid structure
> so we can
flight 175719 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175719/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175623
build-amd64
On 10.01.2023 16:18, Anthony PERARD wrote:
> The configure option "--enable-trace-backend" isn't accepted anymore
> and we should use "--enable-trace-backends" instead which was
> introduce in 2014 and allow multiple backends.
>
> "--enable-trace-backends" was introduced by:
> 5b808275f3bb
On 20.12.22 22:50, Julien Grall wrote:
Hi Juergen,
On 13/12/2022 16:00, Juergen Gross wrote:
@@ -115,47 +117,32 @@ hashtable_expand(struct hashtable *h)
if (h->primeindex == (prime_table_length - 1)) return 0;
newsize = primes[++(h->primeindex)];
- newtable = (struct entry
On 11.01.2023 09:47, Oleksii wrote:
> On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
>> On 10.01.2023 16:17, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V3:
>>> - Nothing changed
>>> ---
>>> Changes in V2:
>>> - Remove unneeded now types from
On 20.12.22 21:18, Julien Grall wrote:
Hi,
On 13/12/2022 16:00, Juergen Gross wrote:
The accounting for the number of nodes of a domain in an active
transaction is not working correctly, as it allows to create arbitrary
number of nodes. The transaction will finally fail due to exceeding
the
On 20.12.22 21:15, Julien Grall wrote:
Hi,
On 13/12/2022 16:00, Juergen Gross wrote:
Rework the interface and the internals of the per-domain node
accounting:
- rename the functions to domain_nbentry_*() in order to better match
the related counter name
- switch from node pointer to domid
On Tue, 2023-01-10 at 17:58 +0100, Jan Beulich wrote:
> On 10.01.2023 16:17, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V3:
> > - Nothing changed
> > ---
> > Changes in V2:
> > - Remove unneeded now types from
>
> I guess you went a little too
Hello,
I installed the pixman package, but Xen can't find it.
On Tuesday, December 20, 2022 at 02:05:48 PM GMT+3:30, Jason Long
wrote:
Hello,
How to solve the pixman error:
$ sudo ./configure
checking build system type... x86_64-pc-solaris2.11
checking host system type...
flight 175714 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175714/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 175694
test-armhf-armhf-libvirt 16
95 matches
Mail list logo
