flight 168819 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168819/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Thanks Philippe,
In the patch subject, 'generic_destroy_vcpu_thread()' should be changed to
'common_vcpu_thread_destroy()'.
Same goes for the next patch (Free cpu->halt_cond).
Thanks/regards,
-Mark
On 3/23/2022 12:17 PM, Philippe Mathieu-Daudé wrote:
From: Mark Kanda
Free cpu->thread in a
On 3/23/2022 1:56 PM, Philippe Mathieu-Daudé wrote:
On 23/3/22 18:17, Philippe Mathieu-Daudé wrote:
From: Mark Kanda
Create cpu_address_space_destroy() to free a CPU's cpu_ases list.
This seems incorrect...
vCPU hotunplug related leak reported by Valgrind:
==132362== 216 bytes in 1
On 24.03.22 02:42, Stefano Stabellini wrote:
I am pretty sure the reasons have to do with old x86 PV guests, so I am
CCing Juergen and Boris.
Hi,
While we've been working on the rust-vmm virtio backends on Xen we
obviously have to map guest memory info the userspace of the daemon.
However
flight 168817 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168817/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168814 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168814/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168807 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168807/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 168797
test-armhf-armhf-libvirt 16
On Wed, 23 Mar 2022, Bertrand Marquis wrote:
> > On 22 Mar 2022, at 21:28, Stefano Stabellini wrote:
> >
> > From: Stefano Stabellini
> >
> > The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> > kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> >
I am pretty sure the reasons have to do with old x86 PV guests, so I am
CCing Juergen and Boris.
> Hi,
>
> While we've been working on the rust-vmm virtio backends on Xen we
> obviously have to map guest memory info the userspace of the daemon.
> However following the logic of what is going on
flight 168813 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168813/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168812 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168812/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168808 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168808/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 168800 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168800/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 6 xen-buildfail REGR. vs. 168709
Tests which did not
flight 168806 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168806/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 22/03/2022 09:17, Luca Miccio wrote:
Hi Julien,
Hi Luca,
- way_size: The size of a LLC way in bytes. This value is mainly used
to calculate the maximum available colors on the platform.
We should only add command line option when they are a strong use case.
In documentation, you
flight 168805 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168805/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 23/3/22 18:17, Philippe Mathieu-Daudé wrote:
From: Mark Kanda
Create cpu_address_space_destroy() to free a CPU's cpu_ases list.
This seems incorrect...
vCPU hotunplug related leak reported by Valgrind:
==132362== 216 bytes in 1 blocks are definitely lost in loss record 7,119 of
8,549
Hi,
On 23/03/2022 13:58, Luca Fancellu wrote:
On 22 Mar 2022, at 14:01, Julien Grall wrote:
Hi,
On 22/03/2022 09:52, Luca Fancellu wrote:
Can you document why this is necessary on x86 but not on other architectures?
Hi Julien,
I received the warning by Juergen here:
flight 168804 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168804/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
From: Mark Kanda
Free cpu->thread in a new AccelOpsClass::destroy_vcpu_thread() handler
generic_destroy_vcpu_thread().
vCPU hotunplug related leak reported by Valgrind:
==102631== 8 bytes in 1 blocks are definitely lost in loss record 1,037 of
8,555
==102631==at 0x4C3ADBB: calloc
From: Philippe Mathieu-Daudé
Reorg TCG AccelOpsClass initialization to emphasis icount
mode share more code with single-threaded TCG.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/tcg-accel-ops.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git
From: Philippe Mathieu-Daudé
Move TCG cflags initialization to thread handler.
Remove the duplicated assert checks.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/tcg-accel-ops-mttcg.c | 5 ++---
accel/tcg/tcg-accel-ops-rr.c| 7 +++
2 files changed, 5 insertions(+), 7
From: Mark Kanda
vCPU hotunplug related leak reported by Valgrind:
==102631== 56 bytes in 1 blocks are definitely lost in loss record 5,089 of
8,555
==102631==at 0x4C3ADBB: calloc (vg_replace_malloc.c:1117)
==102631==by 0x69EE4CD: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.5600.4)
From: Philippe Mathieu-Daudé
Introduce an empty common_vcpu_thread_destroy() function, and
provide a AccelOpsClass::destroy_vcpu_thread_precheck() callback
so accelerators can choose whether to call common_vcpu_thread_destroy.
Signed-off-by: Philippe Mathieu-Daudé
---
From: Philippe Mathieu-Daudé
Introduce precheck/postcheck handlers which will help to
refactor code common to the various create_vcpu_thread()
implementations.
Signed-off-by: Philippe Mathieu-Daudé
---
include/sysemu/accel-ops.h | 4
softmmu/cpus.c | 8 +++-
2 files
From: Philippe Mathieu-Daudé
We are going to extract common pattern from rr_start_vcpu_thread().
First extract the rr_create_vcpu_thread_precheck() helper.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/tcg-accel-ops-rr.c | 7 +++
accel/tcg/tcg-accel-ops-rr.h | 1 +
2 files changed,
From: Philippe Mathieu-Daudé
All accelerators implement a very similar create_vcpu_thread()
handler. Extract the common part as common_vcpu_thread_create(),
which only requires the AccelOpsClass::vcpu_thread_fn() routine
and the accelerator AccelOpsClass::thread_name for debugging
purpose.
The
From: Philippe Mathieu-Daudé
TCG/RR is special and creates a single vCPU. It only have
to release its resources once. Implement the .precheck()
for that purpose.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/tcg/tcg-accel-ops-rr.c | 9 +
accel/tcg/tcg-accel-ops.c| 1 +
2 files
From: Philippe Mathieu-Daudé
Both the comment and the hvf_enabled() check are duplicated
at the beginning of hvf_cpu_thread_fn(), which is the thread
callback created by hvf_start_vcpu_thread(). Remove.
Signed-off-by: Philippe Mathieu-Daudé
---
accel/hvf/hvf-accel-ops.c | 6 --
1 file
From: Philippe Mathieu-Daudé
Both xsave_buf and hvf_caps are allocated in hvf_arch_init_vcpu(),
free them in hvf_arch_vcpu_destroy().
Reported-by: Mark Kanda
Suggested-by: Igor Mammedov
Signed-off-by: Philippe Mathieu-Daudé
---
target/i386/hvf/hvf.c | 2 ++
1 file changed, 2 insertions(+)
From: Philippe Mathieu-Daudé
Fix vCPU hot-unplug related leak reported by Valgrind:
==132362== 4,096 bytes in 1 blocks are definitely lost in loss record 8,440
of 8,549
==132362==at 0x4C3B15F: memalign (vg_replace_malloc.c:1265)
==132362==by 0x4C3B288: posix_memalign
From: Mark Kanda
Create cpu_address_space_destroy() to free a CPU's cpu_ases list.
vCPU hotunplug related leak reported by Valgrind:
==132362== 216 bytes in 1 blocks are definitely lost in loss record 7,119 of
8,549
==132362==at 0x4C3ADBB: calloc (vg_replace_malloc.c:1117)
==132362==
From: Philippe Mathieu-Daudé
Hi,
This is a respin of Mark 'vCPU hotunplug related memory leaks' v3:
https://lore.kernel.org/qemu-devel/20220321141409.3112932-1-mark.ka...@oracle.com/
Instead I refactored to extract the common common_vcpu_thread_create()
from all accelerators (except TCG/RR,
flight 168801 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168801/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed, Mar 23, 2022 at 05:49:43PM +0100, Michal Hocko wrote:
> > The bug here is that prior to commit a81461b0546c ("xen/gntdev: update
> > to new mmu_notifier semantic") wired the mn_invl_range_start() which
> > takes a mutex to invalidate_page, which is defined to run in an atomic
> > context.
On Wed 23-03-22 13:31:46, Jason Gunthorpe wrote:
> On Wed, Mar 23, 2022 at 10:45:30AM +0100, Michal Hocko wrote:
> > [Let me add more people to the CC list - I am not really sure who is the
> > most familiar with all the tricks that mmu notifiers might do]
> >
> > On Wed 23-03-22 09:43:59,
On Wed, Mar 23, 2022 at 09:54:24AM +0100, Roger Pau Monn?? wrote:
>
> 2. When uploading Px states, what's the meaning of the shared_type
> field in xen_processor_performance? I've looked at the usage of the
> field by Xen, and first of all it seems to be a layering violation
> because the values
On Wed, Mar 23, 2022 at 10:45:30AM +0100, Michal Hocko wrote:
> [Let me add more people to the CC list - I am not really sure who is the
> most familiar with all the tricks that mmu notifiers might do]
>
> On Wed 23-03-22 09:43:59, Juergen Gross wrote:
> > Hi,
> >
> > during analysis of a
flight 168797 linux-linus real [real]
flight 168802 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/168797/
http://logs.test-lab.xenproject.org/osstest/logs/168802/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 23.03.2022 16:43, Rahul Singh wrote:
> in dom0less system. This patch introduce the new feature to support the
> signaling between two domUs in dom0less system.
>
> Signed-off-by: Rahul Singh
> ---
> docs/designs/dom0less-evtchn.md | 96 +
> 1 file changed, 96
On Wed, Mar 23, 2022 at 07:42:48AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 23, 2022 at 06:38:22AM +0900, Ryusuke Konishi wrote:
> > This looks because the mask of GFP_KERNEL is removed along with
> > the removal of mpage_alloc().
> >
>
> > The default value of the gfp flag is set to
in dom0less system. This patch introduce the new feature to support the
signaling between two domUs in dom0less system.
Signed-off-by: Rahul Singh
---
docs/designs/dom0less-evtchn.md | 96 +
1 file changed, 96 insertions(+)
create mode 100644
On Wed, Mar 23, 2022 at 02:44:18PM +, Raphael Ning wrote:
> From: Raphael Ning
>
> Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall
> to return on success, because it assumes that the hypercall always
> triggers an immediate reboot. However, for Live Update, the
On Wed, Mar 23, 2022 at 02:20:52PM +, Raphael Ning wrote:
>
> On 23/03/2022 14:08, Simon Horman wrote:
> > Hi Raphael,
> > thanks for your patch. Overall I think this is good.
> >
> > Unfortunately I am seeing a build failure with this patch applied.
> >
> > ../../kexec/kexec-xen.c:292:6:
From: Raphael Ning
Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall
to return on success, because it assumes that the hypercall always
triggers an immediate reboot. However, for Live Update, the hypercall
merely schedules the kexec operation and returns; the actual reboot
On 23/03/2022 14:08, Simon Horman wrote:
> Hi Raphael,
> thanks for your patch. Overall I think this is good.
>
> Unfortunately I am seeing a build failure with this patch applied.
>
> ../../kexec/kexec-xen.c:292:6: error: conflicting types for ‘xen_kexec_exec’
> 292 | void
On Mon, Mar 14, 2022 at 09:21:15AM +, Raphael Ning wrote:
> From: Raphael Ning
>
> Currently, my_exec() does not expect the Xen KEXEC_CMD_kexec hypercall
> to return on success, because it assumes that the hypercall always
> triggers an immediate reboot. However, for Live Update, the
flight 168794 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168794/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 12 debian-hvm-install fail in
168786 pass in 168794
> On 22 Mar 2022, at 14:01, Julien Grall wrote:
>
> Hi,
>
> On 22/03/2022 09:52, Luca Fancellu wrote:
>
> Can you document why this is necessary on x86 but not on other
> architectures?
Hi Julien,
I received the warning by Juergen here:
flight 168799 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168799/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Andrew,
On 23/03/2022 12:36, Andrew Cooper wrote:
On 22/03/2022 20:28, Stefano Stabellini wrote:
From: Stefano Stabellini
The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
kernel, certain versions of Linux will use an UNPREDICATABLE NOP
encoding, sometimes resulting
On 22/03/2022 20:28, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> encoding, sometimes resulting in an unbootable kernel. Whether the
>
On 23.03.22 12:22, Luca Fancellu wrote:
On 23 Mar 2022, at 11:10, Luca Fancellu wrote:
On 23 Mar 2022, at 08:58, Juergen Gross wrote:
The result field of struct vscsiif_response is lacking a detailed
definition. Today the Linux kernel internal scsi definitions are being
used, which is
On 23.03.22 12:10, Luca Fancellu wrote:
On 23 Mar 2022, at 08:58, Juergen Gross wrote:
The result field of struct vscsiif_response is lacking a detailed
definition. Today the Linux kernel internal scsi definitions are being
used, which is not a sane interface for a PV device driver.
Add
On Thu, Mar 17, 2022 at 09:58:15AM +0100, Roger Pau Monné wrote:
> On Wed, Mar 16, 2022 at 09:13:15AM +, Jane Malalane wrote:
> > Introduce a new per-domain creation x86 specific flag to
> > select whether hardware assisted virtualization should be used for
> > x{2}APIC.
> >
> > A per-domain
On Wed, Mar 16, 2022 at 09:13:14AM +, Jane Malalane wrote:
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index e1e1fa14e6..77ce0b2121 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -343,6 +343,15 @@ static int
On Wed, Mar 23, 2022 at 11:19:50AM +, Andrew Cooper wrote:
> On 21/03/2022 15:04, Roger Pau Monné wrote:
> > On Mon, Mar 21, 2022 at 01:58:28PM +, Andrew Cooper wrote:
> >> By default, workflows run in all forks, but the Coverity token is specific
> >> to
> >> us, causing all other runs
> On 23 Mar 2022, at 11:10, Luca Fancellu wrote:
>
>
>
>> On 23 Mar 2022, at 08:58, Juergen Gross wrote:
>>
>> The result field of struct vscsiif_response is lacking a detailed
>> definition. Today the Linux kernel internal scsi definitions are being
>> used, which is not a sane interface
On 21/03/2022 15:04, Roger Pau Monné wrote:
> On Mon, Mar 21, 2022 at 01:58:28PM +, Andrew Cooper wrote:
>> By default, workflows run in all forks, but the Coverity token is specific to
>> us, causing all other runs to fail.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by: Roger Pau Monné
>
>
> On 23 Mar 2022, at 08:58, Juergen Gross wrote:
>
> The result field of struct vscsiif_response is lacking a detailed
> definition. Today the Linux kernel internal scsi definitions are being
> used, which is not a sane interface for a PV device driver.
>
> Add macros to change that by using
Introduce CodeQL support for Xen and analyze the C, Python and Go
files.
Note than when analyzing Python or Go we avoid building the hypervisor
and only build the tools.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
Changes since v2:
- Remove explicit 'staging' branch
[Let me add more people to the CC list - I am not really sure who is the
most familiar with all the tricks that mmu notifiers might do]
On Wed 23-03-22 09:43:59, Juergen Gross wrote:
> Hi,
>
> during analysis of a customer's problem on a 4.12 based kernel
> (deadlock due to a blocking mmu
Hi,
On 10/03/2022 07:34, Juergen Gross wrote:
@@ -1520,7 +1460,10 @@ static bool check_multicall_32bit_clean(struct
multicall_entry *multi)
{
int i;
-for ( i = 0; i < arm_hypercall_table[multi->op].nr_args; i++ )
+if ( multi->op >= ARRAY_SIZE(hypercall_args) )
+
On Wed, Mar 23, 2022 at 3:42 PM Christoph Hellwig wrote:
>
> On Wed, Mar 23, 2022 at 06:38:22AM +0900, Ryusuke Konishi wrote:
> > This looks because the mask of GFP_KERNEL is removed along with
> > the removal of mpage_alloc().
> >
>
> > The default value of the gfp flag is set to
flight 168796 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168796/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
The result field of struct vscsiif_response is lacking a detailed
definition. Today the Linux kernel internal scsi definitions are being
used, which is not a sane interface for a PV device driver.
Add macros to change that by using today's values in the XEN namespace.
Signed-off-by: Juergen
Hello,
I was looking at implementing ACPI Cx and Px state uploading from
FreeBSD dom0, as my main test box is considerably slower without Xen
knowing about the Px states. That has raised a couple of questions.
1. How to figure out what features to report available by OSPM when
calling the _PDC
Hi Stefano,
> On 22 Mar 2022, at 21:28, Stefano Stabellini wrote:
>
> From: Stefano Stabellini
>
> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> encoding, sometimes resulting in an unbootable
Hi,
during analysis of a customer's problem on a 4.12 based kernel
(deadlock due to a blocking mmu notifier in a Xen driver) I came
across upstream patches 93065ac753e4 ("mm, oom: distinguish
blockable mode for mmu notifiers") et al.
The backtrace of the blocked tasks was typically something
> On 22 Mar 2022, at 15:23, Jan Beulich wrote:
>
> Now that x86'es check-endbr.sh script uses it, also make it available
> consistently with other tool chain components.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Luca Fancellu
Cheers,
Luca
>
> --- a/config/StdGNU.mk
> +++
flight 168791 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168791/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 168784
test-armhf-armhf-libvirt 16
Hi Stefano,
On 22.03.2022 21:38, Stefano Stabellini wrote:
> Add a minimal ARM32 smoke test based on qemu-system-arm, as provided by
> the test-artifacts qemu container. The minimal test simply boots Xen
> (built from previous build stages) and Dom0.
>
> The test needs a working kernel and
On 22.03.2022 21:28, Stefano Stabellini wrote:
> From: Stefano Stabellini
>
> The first 32 bytes of zImage are NOPs. When CONFIG_EFI is enabled in the
> kernel, certain versions of Linux will use an UNPREDICATABLE NOP
> encoding, sometimes resulting in an unbootable kernel. Whether the
>
flight 168793 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/168793/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 23.03.2022 01:22, Stefano Stabellini wrote:
> On Tue, 15 Mar 2022, Daniel P. Smith wrote:
>> On 1/28/22 16:33, Stefano Stabellini wrote:
>>> From: Luca Miccio
>>>
>>> The xenstore event channel will be allocated for dom0less domains. It is
>>> necessary to have access to the
On Wed, Mar 23, 2022 at 06:38:22AM +0900, Ryusuke Konishi wrote:
> This looks because the mask of GFP_KERNEL is removed along with
> the removal of mpage_alloc().
>
> The default value of the gfp flag is set to GFP_HIGHUSER_MOVABLE by
> inode_init_always().
> So, __GFP_HIGHMEM hits the gfp
76 matches
Mail list logo
