flight 175938 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175938/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
test-armhf-armhf-libvirt-qcow2
On 18.01.2023 00:32, Andrew Cooper wrote:
> On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
>> +struct sbiret sbi_ecall(unsigned long ext, unsigned long fid,
>> +unsigned long arg0, unsigned long arg1,
>> +unsigned long arg2, unsigned long arg3,
>> +
On 17.01.2023 21:19, Andrew Cooper wrote:
> On 19/10/2022 8:39 am, Jan Beulich wrote:
>> This is to facilitate subsequent re-use of this code.
>>
>> While doing so add const in a number of places, extending to
>> gtime_to_gtsc() and then for symmetry also its inverse function.
>>
>> Signed-off-by:
On 17.01.23 10:11, 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 as interface, as all nodes have the
owner fi
On 17.01.2023 19:48, Andrew Cooper wrote:
> On 11/01/2023 1:54 pm, Jan Beulich wrote:
>> 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
On 17.01.2023 20:28, Per Bilse wrote:
> On 17/01/2023 15:55, Jan Beulich wrote:
>> On 16.01.2023 18:21, Per Bilse wrote:
>>> + config REBOOT_METHOD_XEN
>>> + bool "xen"
>>> + help
>>> + Use Xen SCHEDOP hypercall (if running under Xen as a
>>> guest).
>>
>> T
flight 175951 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175951/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 4 hos
On 17.01.23 23:36, Julien Grall wrote:
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Today check_store() is only testing the correctness of the node tree.
Add verification of the accounting data (number of nodes) and correct
NIT: one too many space before 'and'.
the data if it is
On 17.01.23 23:15, Julien Grall wrote:
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
@@ -2604,6 +2607,8 @@ static void usage(void)
" -N, --no-fork to request that the daemon does not fork,\n"
" -P, --output-pid to request that the pid of the daemon is output,\n"
On 17.01.23 23:03, Julien Grall wrote:
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Letting hashtable_remove() return the value of the removed element is
not used anywhere in Xenstore, and it conflicts with a hashtable
created specifying the HASHTABLE_FREE_VALUE flag.
So just drop ret
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Monday, January 9, 2023 6:58 PM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v1 06/13] xen/arm: assign shared memory to o
On Tue, 17 Jan 2023 19:15:57 -0500
Chuck Zmudzinski wrote:
> On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> > On Mon, 16 Jan 2023 13:00:53 -0500
> > Chuck Zmudzinski wrote:
> >
> > > On 1/16/23 10:33, Igor Mammedov wrote:
> > > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > > Chuck Zmudzinski wro
flight 175933 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175933/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-armhf-armhf-xl-multivcpu
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:37
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 05/40] xen/arm64: prepare for moving MMU related
> code
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:24
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk ; Jiamei Xie
>
> Subject: Re: [PATCH v2 04/40] xen/arm: add an option to define X
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:17
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 03/40] xen/arm: adjust Xen TLB helpers for Armv8-
> R64
flight 175932 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175932/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt-raw broken
test-armhf-armhf-libvirt-raw 5 host-ins
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:09
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 02/40] xen/arm: make ARM_EFI selectable for Arm64
>
> H
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:46
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 07/40] xen/arm64: add .text.idmap for Xen identity
> map
Thanks, I've been testing those patches on my real system (i5-7200U) for
the last day with no problems so far, waking from s2ram works as well.
I can also no longer see those `sarq $5, %gs:0x1337` with %gs=0 on QEMU.
Regards,
- Joan
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2023年1月18日 7:49
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Stefano Stabellini
> ; Bertrand Marquis ;
> Volodymyr Babchuk
> Subject: Re: [PATCH v2 08/40] xen/arm: use PA == VA for
> EARLY_UART_VIRTUAL_AD
On Tue, Jan 17, 2023 at 12:40 AM Oleksii Kurochko
wrote:
>
> Add check if there is a message 'Hello from C env' presents
> in log file to be sure that stack is set and C part of early printk
> is working.
>
> Signed-off-by: Oleksii Kurochko
> Acked-by: Stefano Stabellini
Reviewed-by: Alistair F
On Tue, Jan 17, 2023 at 12:39 AM Oleksii Kurochko
wrote:
>
> From: Bobby Eshleman
>
> Originally SBI implementation for Xen was introduced by
> Bobby Eshleman but it was removed
> all the stuff for simplicity except SBI call for putting
> character to console.
>
> The patch introduces sbi_putch
flight 175949 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175949/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
build-amd64 6 xen
On Tue, 17 Jan 2023 at 23:57, Andrew Cooper
wrote:
> On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> > diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
> > index e69de29bb2..e139e44873 100644
> > --- a/xen/arch/riscv/Kconfig.debug
> > +++ b/xen/arch/riscv/Kconfig.debug
>
On 1/17/2023 6:04 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> > >> > On Thu,
On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/Kconfig.debug b/xen/arch/riscv/Kconfig.debug
> index e69de29bb2..e139e44873 100644
> --- a/xen/arch/riscv/Kconfig.debug
> +++ b/xen/arch/riscv/Kconfig.debug
> @@ -0,0 +1,6 @@
> +config EARLY_PRINTK
> +bool "Enable earl
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
There is no VMSA support on Armv8-R AArch64, so we can not map early
UART to FIXMAP_CONSOLE. Instead, we use PA == VA to define
EARLY_UART_VIRTUAL_ADDRESS on Armv8-R AArch64.
Signed-off-by: Wei Chen
Your signed-off-by is miss
Hi,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
Only the first 4KB of Xen image will be mapped as identity
(PA == VA). At the moment, Xen guarantees this by having
everything that needs to be used in the identity mapping
in head.S before _end_boot and checking at link time if this
f
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
We want to reuse head.S for MPU systems, but there are some
code implemented for MMU systems only. We will move such
code to another MMU specific file. But before that, we will
do some preparations in this patch to make them easi
On 16/01/2023 2:39 pm, Oleksii Kurochko wrote:
> diff --git a/xen/arch/riscv/sbi.c b/xen/arch/riscv/sbi.c
> new file mode 100644
> index 00..dc0eb44bc6
> --- /dev/null
> +++ b/xen/arch/riscv/sbi.c
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Taken and mo
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
On Armv8-A, Xen has a fixed virtual start address (link address
too) for all Armv8-A platforms. In an MMU based system, Xen can
map its loaded address to this virtual start address. So, on
Armv8-A platforms, the Xen start address
On Mon, Jan 16, 2023 at 04:39:31PM +0200, Oleksii Kurochko wrote:
> Because printk() relies on a serial driver (like the ns16550 driver)
> and drivers require working virtual memory (ioremap()) there is not
> print functionality early in Xen boot.
>
> The patch introduces the basic stuff of early_
On Mon, Jan 16, 2023 at 04:39:30PM +0200, Oleksii Kurochko wrote:
> From: Bobby Eshleman
>
> Originally SBI implementation for Xen was introduced by
> Bobby Eshleman but it was removed
> all the stuff for simplicity except SBI call for putting
> character to console.
>
> The patch introduces s
Hi,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
From Arm ARM Supplement of Armv8-R AArch64 (DDI 0600A) [1],
section D1.6.2 TLB maintenance instructions, we know that
Armv8-R AArch64 permits an implementation to cache stage 1
VMSAv8-64 and stage 2 PMSAv8-64 attributes as a common en
Hi Penny,
On 13/01/2023 05:28, Penny Zheng wrote:
From: Wei Chen
Currently, ARM_EFI will mandatorily selected by Arm64.
Even if the user knows for sure that their images will not
start in the EFI environment, they can't disable the EFI
support for Arm64. This means there will be about 3K lines
Am 4. Januar 2023 14:44:31 UTC schrieb Bernhard Beschow :
>This series first renders TYPE_PIIX3_XEN_DEVICE redundant and finally removes
>
>it. The motivation is to 1/ decouple PIIX from Xen and 2/ to make Xen in the PC
>
>machine agnostic to the precise southbridge being used. 2/ will become
>
Hi Andrew,
On 17/01/2023 22:20, Andrew Cooper wrote:
On 24/11/2022 9:29 pm, Julien Grall wrote:
Hi Jan,
I am still digesting this series and replying with some initial comments.
On 19/10/2022 09:43, Jan Beulich wrote:
The registration by virtual/linear address has downsides: At least on
x86
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Using a tab for separating the command from the options in the output
of "xenstore-control help" results in a rather ugly list.
Use a fixed size for the command instead.
Signed-off-by: Juergen Gross
Rwviewed-by: Julien Grall
Cheers,
-
flight 175950 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175950/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Today check_store() is only testing the correctness of the node tree.
Add verification of the accounting data (number of nodes) and correct
NIT: one too many space before 'and'.
the data if it is wrong.
Do the initial check_store() cal
On 24/11/2022 9:29 pm, Julien Grall wrote:
> Hi Jan,
>
> I am still digesting this series and replying with some initial comments.
>
> On 19/10/2022 09:43, Jan Beulich wrote:
>> The registration by virtual/linear address has downsides: At least on
>> x86 the access is expensive for HVM/PVH domains.
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
@@ -2604,6 +2607,8 @@ static void usage(void)
" -N, --no-fork to request that the daemon does not fork,\n"
" -P, --output-pidto request that the pid of the daemon is output,\n"
" -T, --trace-file giving the file fo
On 19/10/2022 8:43 am, Jan Beulich wrote:
> The registration by virtual/linear address has downsides: At least on
> x86 the access is expensive for HVM/PVH domains. Furthermore for 64-bit
> PV domains the areas are inaccessible (and hence cannot be updated by
> Xen) when in guest-user mode.
They'r
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Letting hashtable_remove() return the value of the removed element is
not used anywhere in Xenstore, and it conflicts with a hashtable
created specifying the HASHTABLE_FREE_VALUE flag.
So just drop returning the value.
Any reason this can'
flight 175947 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175947/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
flight 175944 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175944/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 175746
Tests which
On 19/10/2022 8:40 am, Jan Beulich wrote:
> In preparation of the introduction of new vCPU operations allowing to
> register the respective areas (one of the two is x86-specific) by
> guest-physical address, add the necessary domain cleanup hooks.
What are the two areas you're discussing here?
I
flight 175931 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175931/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm broken
build-i386
flight 175946 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175946/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 19/10/2022 8:41 am, Jan Beulich wrote:
> --- a/xen/arch/x86/time.c
> +++ b/xen/arch/x86/time.c
> @@ -1462,12 +1462,34 @@ static void __update_vcpu_system_time(st
> v->arch.pv.pending_system_time = _u;
> }
>
> +static void write_time_guest_area(struct vcpu_time_info *map,
> +
flight 175945 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175945/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 19/10/2022 8:39 am, Jan Beulich wrote:
> This is to facilitate subsequent re-use of this code.
>
> While doing so add const in a number of places, extending to
> gtime_to_gtsc() and then for symmetry also its inverse function.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
> ---
> I
flight 175943 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175943/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 17/01/2023 15:55, Jan Beulich wrote:
> On 16.01.2023 18:21, Per Bilse wrote:
>> +config REBOOT_SYSTEM_DEFAULT
>> +default y
>> +bool "Xen-defined reboot method"
>
> May I ask that you swap the two lines? (Personally I consider kconfig
> too forgiving here - it doesn't make a lot of sens
On 12/01/2023 10:42 am, Jan Beulich wrote:
> On 12.01.2023 11:31, Andrew Cooper wrote:
>> On 12/01/2023 9:47 am, Jan Beulich wrote:
>>> On 12.01.2023 00:15, Andrew Cooper wrote:
On 11/01/2023 1:57 pm, Jan Beulich wrote:
> Make HVM=y release build behavior prone against array overrun, by
>>
On 11/01/2023 1:54 pm, Jan Beulich wrote:
> 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
Acked-by: Andrew Cooper
flight 175936 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175936/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 175746
Tests which
On 11/01/2023 1:54 pm, Jan Beulich wrote:
> 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 varia
flight 175942 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175942/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
flight 175941 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175941/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
zeroeth_table_offset is not accessed by ARM_32.
Also, when 32 bit physical addresses are used (ie ARM_PA_32=y), this
causes an overflow.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - Removed the duplicate declaration for DECLARE_OFFSETS.
xen/arch/arm/include/asm/lpae.h | 4
xen
Refer ARM IHI 0062D.c ID070116 (SMMU 2.0 spec), 17-360, 17.3.9,
SMMU_CBn_TTBR0 is a 64 bit register. Thus, one can use
writeq_relaxed_non_atomic() to write to it instead of invoking
writel_relaxed() twice for lower half and upper half of the register.
This also helps us as p2maddr is 'paddr_t' (wh
VTCR.T0SZ should be set as 0x20 to support 32bit IPA.
Refer ARM DDI 0487I.a ID081822, G8-9824, G8.2.171, VTCR,
"Virtualization Translation Control Register" for the bit descriptions.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - New patch.
xen/arch/arm/p2m.c | 10 +++---
1 file
One should now be able to use 'paddr_t' to represent address and size.
Consequently, one should use 'PRIpaddr' as a format specifier for paddr_t.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Rebased the patch.
xen/arch/arm/domain_build.c| 9 +
xen/arch/arm/gic-
In the subsequent patch, we introduce "CONFIG_ARM_PA_32" to support
32 bit physical addresses. Thus, the code specific to
"Large Page Address Extension" (ie LPAE) should be enclosed within
"ifndef CONFIG_ARM_PA_32".
Refer xen/arch/arm/include/asm/short-desc.h, "short_desc_l1_supersec_t"
unsigned i
In future, we wish to support 32 bit physical address.
However, one can only read u64 values from the DT. Thus, we need to
typecast the values appropriately from u64 to paddr_t.
device_tree_get_reg() should now be able to return paddr_t. This is
invoked by various callers to get DT address and siz
We have introduced a new config option to support 32 bit physical address.
By default, it is disabled.
ARM_PA_32 cannot be enabled on ARM_64 as the memory management unit works
on 48bit physical addresses.
On ARM_32, it can be used on systems where large page address extension is
not supported.
Si
dt_device_get_address() can accept u64 only for address and size. The
various callers will use 'paddr_t' datatype for address and size.
'paddr_t' is currently defined as u64, but we may support u32 as well.
Thus, we need an appropriate wrapper which can handle this type
conversion.
The callers wil
1. One should use 'PRIpaddr' to display 'paddr_t' variables.
2. One should use 'PRIx64' to display 'u64' in hex format. The current
use of 'PRIpaddr' for printing PTE is buggy as this is not a physical
address.
Signed-off-by: Ayan Kumar Halder
---
Changes from -
v1 - 1. Moved the patch earlier.
bankbase, banksize and bankend are used to hold values of type 'unsigned
long long'. This can be represented as 'uint64_t' instead of 'paddr_t'.
This will ensure consistency with allocate_static_memory() (where we use
'uint64_t' for rambase and ramsize).
In future, paddr_t can be used for 'uin32_t
In an earlier commit (7c1de0038895), "ns16550.io_size" was u32 and
"io_size" was u64. Thus, the ASSERT() was needed to check if the values
are the same.
However, in a later commit (c9f8e0aee507), "ns16550.io_size" was changed
to u64. Thus, the ASSERT() became redundant.
So, now as "io_size" and "u
Hi All,
Please have a look at
https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg01465.html
for the context.
The benefits of using 32 bit physical addresses are as follows :-
1. It helps to use Xen on platforms (for eg R52) which supports 32 bit
physical addresses and has no suppor
On 17/01/2023 4:21 pm, Jason Andryuk wrote:
> On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper
> wrote:
>> Recently in XenServer, we have encountered problems caused by both
>> XENVER_extraversion and XENVER_commandline having fixed bounds.
>>
>> More than just the invariant size, the APIs/ABIs also
flight 175940 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175940/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 16/01/2023 6:10 pm, Anthony PERARD wrote:
> The get-fields.sh which generate all the include/compat/.xlat/*.h
> headers is quite slow. It takes for example nearly 3 seconds to
> generate platform.h on a recent machine, or 2.3 seconds for memory.h.
>
> Rewriting the mix of shell/sed/python into a
> On 17 Jan 2023, at 16:55, Anthony PERARD wrote:
>
> On Tue, Jan 17, 2023 at 04:07:24PM +, Luca Fancellu wrote:
>>> On 16 Jan 2023, at 18:10, Anthony PERARD wrote:
>>> diff --git a/xen/tools/compat-xlat-header.py
>>> b/xen/tools/compat-xlat-header.py
>>> new file mode 100644
>>> index 00
On Tue, Jan 17, 2023 at 04:07:24PM +, Luca Fancellu wrote:
> > On 16 Jan 2023, at 18:10, Anthony PERARD wrote:
> > diff --git a/xen/tools/compat-xlat-header.py
> > b/xen/tools/compat-xlat-header.py
> > new file mode 100644
> > index 00..c1b361ac56
> > --- /dev/null
> > +++ b/xen/tools
flight 175939 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175939/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On Fri, Jan 13, 2023 at 6:08 PM Andrew Cooper wrote:
>
> Recently in XenServer, we have encountered problems caused by both
> XENVER_extraversion and XENVER_commandline having fixed bounds.
>
> More than just the invariant size, the APIs/ABIs also broken by typedef-ing an
> array, and using an unq
> On 16 Jan 2023, at 18:10, Anthony PERARD wrote:
>
> The get-fields.sh which generate all the include/compat/.xlat/*.h
> headers is quite slow. It takes for example nearly 3 seconds to
> generate platform.h on a recent machine, or 2.3 seconds for memory.h.
>
> Rewriting the mix of shell/sed/
flight 175937 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175937/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 16.01.2023 18:21, Per Bilse wrote:
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -306,6 +306,101 @@ config MEM_SHARING
> bool "Xen memory sharing support (UNSUPPORTED)" if UNSUPPORTED
> depends on HVM
>
> +config REBOOT_SYSTEM_DEFAULT
> + default y
> + bool
On 17.01.23 15:08, Julien Grall wrote:
Hi Juergen,
On 17/01/2023 09:11, 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
On 17.01.23 15:02, Julien Grall wrote:
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross 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 (n
On Tue, Jan 17, 2023 at 4:32 PM Juergen Gross wrote:
>
> On 17.01.23 15:09, Rafael J. Wysocki wrote:
> > On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross wrote:
> >>
> >> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> >>> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
>
> Commit f1e5
On 17.01.23 15:09, Rafael J. Wysocki wrote:
On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross wrote:
On 13.01.23 20:40, Rafael J. Wysocki wrote:
On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed on
flight 175935 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175935/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> > >> > On Thu,
On 1/17/2023 5:35 AM, Igor Mammedov wrote:
> On Mon, 16 Jan 2023 13:00:53 -0500
> Chuck Zmudzinski wrote:
>
> > On 1/16/23 10:33, Igor Mammedov wrote:
> > > On Fri, 13 Jan 2023 16:31:26 -0500
> > > Chuck Zmudzinski wrote:
> > >
> > >> On 1/13/23 4:33 AM, Igor Mammedov wrote:
> > >> > On Thu,
On 13/01/2023 12:56, El Mesdadi Youssef ESK UILD7 wrote:
Hello Julien,
Hi,
xentrace should work on upstream Xen. What did you version did you try?
While building my image using the BSP-linux of NXP, the version that was
downloaded is Xen 4.14.
Do you know where the source are download
flight 175934 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175934/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 175747
build-i386
On 17/01/2023 14:17, El Mesdadi Youssef ESK UILD7 wrote:
Hello everyone,
Hi,
My name is Youssef, I am an electrical Eng. student and right now I'm working
on my thesis using Xen hypervisor on an S32G3 microprocessor (ARM
architecture). After building my Yocto-Image using the Linux-BSP of th
Hello everyone,
My name is Youssef, I am an electrical Eng. student and right now I'm working
on my thesis using Xen hypervisor on an S32G3 microprocessor (ARM
architecture). After building my Yocto-Image using the Linux-BSP of the
microprocessor, I noticed that Xentrace and Xenalyze are not wo
On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross wrote:
>
> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> > On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
> >>
> >> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> >> Xen PV guest") missed one code path accessing real_m
flight 175930 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/175930/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-arm64-xsm
Hi Juergen,
On 17/01/2023 09:11, 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 number of nodes quota, but before c
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Move all code related to struct changed_domain from
xenstored_transaction.c to xenstored_domain.c.
This will be needed later in order to simplify the accounting data
updates in cases of errors during a request.
Split the code to have a more
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross wrote:
Instead of storing a pointer to the path which is prepended to
relative paths in struct watch, just use the length of the prepended
path.
It should be noted that the now removed special case of the
relative path being "" in get_watch_path()
Hi Juergen,
On 17/01/2023 09:11, Juergen Gross 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 (node)
+
1 - 100 of 162 matches
Mail list logo
