Hi All,
I am seeing the following message in the "dmesg" output of a driver domain.
[Thu Oct 8 20:57:04 2020] xen-blkback: Scheduled work from previous purge is
still busy, cannot purge list
[Thu Oct 8 20:57:11 2020] xen-blkback: Scheduled work from previous purge is
still busy, cannot purge
flight 155760 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155760/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On 10/12/20 10:07 PM, Jason Andryuk wrote:
> Xen was broken by commit 1583a3898853 ("cpus: extract out qtest-specific
> code to accel/qtest"). Xen relied on qemu_init_vcpu() calling
> qemu_dummy_start_vcpu() in the default case, but that was replaced by
> g_assert_not_reached().
>
> Add a
On 10/12/20 10:07 PM, Jason Andryuk wrote:
> Xen was left behind when CpusAccel became mandatory and fails the assert
> in qemu_init_vcpu(). It relied on the same dummy cpu threads as qtest.
> Move the qtest cpu functions to a common location and reuse them for
> Xen.
>
> Jason Andryuk (2):
>
LBR, C-state MSRs and if_pschange_mc erratum applicability should correspond
to Ice Lake desktop according to External Design Specification vol.2.
Signed-off-by: Igor Druzhinin
---
xen/arch/x86/acpi/cpu_idle.c | 1 +
xen/arch/x86/hvm/vmx/vmx.c | 3 ++-
2 files changed, 3 insertions(+), 1
From: Chen Yu
On ICX platform, the C1E auto-promotion is enabled by default.
As a result, the CPU might fall into C1E more offen than previous
platforms. So disable C1E auto-promotion and expose C1E as a separate
idle state.
Beside C1 and C1E, the exit latency of C6 was measured
by a dedicated
flight 155751 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155751/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
flight 155736 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155736/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
flight 155743 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155743/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
On Mon, Oct 12, 2020 at 02:45:06PM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> We already have a generic PCI_DEVFN() macro in "hw/pci/pci.h"
> to pack the PCI slot/function identifiers, use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
ppc part
Acked-by: David
On Mon, Oct 12, 2020 at 02:45:04PM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> We already have a generic PCI_FUNC() macro in "hw/pci/pci.h" to
> extract the PCI function identifier, use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
Acked-by: David Gibson
> ---
>
On Mon, Oct 12, 2020 at 02:45:03PM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> We already have a generic PCI_BUILD_BDF() macro in "hw/pci/pci.h"
> to pack these values, use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
pnv part
Acked-by: David Gibson
> ---
>
On Mon, Oct 12, 2020 at 02:45:05PM +0200, Philippe Mathieu-Daudé wrote:
> From: Philippe Mathieu-Daudé
>
> We already have a generic PCI_SLOT() macro in "hw/pci/pci.h"
> to extract the PCI slot identifier, use it.
>
> Signed-off-by: Philippe Mathieu-Daudé
ppc parts
Acked-by: David Gibson
>
On Sat, 10 Oct 2020, Julien Grall wrote:
> Hi,
>
> On 10/10/2020 12:42, Trammell Hudson wrote:
> > On Friday, October 9, 2020 10:27 PM, Andrew Cooper
> > wrote:
> > > [...]
> > > Looks like arm64 is crashing fairly early on boot.
> > >
> > > This is probably caused by "efi: Enable booting
On Mon, Oct 12, 2020 at 09:02:54PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote:
> > On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> > > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > > > kmap_atomic() is always
flight 155748 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155748/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On Mon, Oct 12, 2020 at 12:02:14PM -0700, Stefano Stabellini wrote:
> On Sat, 10 Oct 2020, Julien Grall wrote:
> > Therefore, I think the code should not try to find the STAO. Instead, it
> > should check whether the SPCR table is present.
>
> Yes, that makes sense, but that brings me to the next
Xen was broken by commit 1583a3898853 ("cpus: extract out qtest-specific
code to accel/qtest"). Xen relied on qemu_init_vcpu() calling
qemu_dummy_start_vcpu() in the default case, but that was replaced by
g_assert_not_reached().
Add a minimal "CpusAccel" for xen using the dummy-cpu
Xen was left behind when CpusAccel became mandatory and fails the assert
in qemu_init_vcpu(). It relied on the same dummy cpu threads as qtest.
Move the qtest cpu functions to a common location and reuse them for
Xen.
Jason Andryuk (2):
accel: move qtest CpusAccel functions to a common
On Mon, Oct 12, 2020 at 12:53:54PM -0700, Ira Weiny wrote:
> On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> > On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > > kmap_atomic() is always preferred over kmap()/kmap_thread().
> > > kmap_atomic() is _much_ more
On Mon, Oct 12, 2020 at 05:44:38PM +0100, Matthew Wilcox wrote:
> On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> > kmap_atomic() is always preferred over kmap()/kmap_thread().
> > kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> > always CPU-local and never
flight 155741 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155741/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
From: Masami Hiramatsu
[ Upstream commit 5a0677110b73dd3e1766f89159701bfe8ac06808 ]
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the
From: Masami Hiramatsu
[ Upstream commit 5a0677110b73dd3e1766f89159701bfe8ac06808 ]
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the
From: Masami Hiramatsu
[ Upstream commit 5a0677110b73dd3e1766f89159701bfe8ac06808 ]
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the
From: Masami Hiramatsu
[ Upstream commit 5a0677110b73dd3e1766f89159701bfe8ac06808 ]
Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
address conversion.
In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
to gfn by virt_to_gfn() macro. However, since the
On Sat, 10 Oct 2020, Julien Grall wrote:
> On 28/09/2020 07:47, Masami Hiramatsu wrote:
> > Hello,
>
> Hi Masami,
>
> > This made progress with my Xen boot on DeveloperBox (
> > https://www.96boards.org/product/developerbox/ ) with ACPI.
> >
>
> I have reviewed the patch attached and I have a
> On Oct 7, 2020, at 11:19 AM, Anastasiia Lukianenko
> wrote:
>
> Hi all,
>
> On Thu, 2020-10-01 at 10:06 +, George Dunlap wrote:
>>> On Oct 1, 2020, at 10:06 AM, Anastasiia Lukianenko <
>>> anastasiia_lukiane...@epam.com> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, 2020-09-30 at 10:24 +,
flight 155734 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155734/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
On Mon, Oct 12, 2020 at 09:28:29AM -0700, Dave Hansen wrote:
> kmap_atomic() is always preferred over kmap()/kmap_thread().
> kmap_atomic() is _much_ more lightweight since its TLB invalidation is
> always CPU-local and never broadcast.
>
> So, basically, unless you *must* sleep while the mapping
flight 155729 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
On 10/12/20 9:19 AM, Eric Biggers wrote:
> On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
>>> And I still don't really understand. After this patchset, there is still
>>> code
>>> nearly identical to the above (doing a temporary mapping just for a memcpy)
>>> that
>>> would still be
On Sun, Oct 11, 2020 at 11:56:35PM -0700, Ira Weiny wrote:
> >
> > And I still don't really understand. After this patchset, there is still
> > code
> > nearly identical to the above (doing a temporary mapping just for a memcpy)
> > that
> > would still be using kmap_atomic().
>
> I don't
flight 155717 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155717/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
Hi all,
On Wed, 2020-10-07 at 18:07 -0700, Stefano Stabellini wrote:
> On Wed, 7 Oct 2020, Anastasiia Lukianenko wrote:
> > On Thu, 2020-10-01 at 10:06 +, George Dunlap wrote:
> > > > On Oct 1, 2020, at 10:06 AM, Anastasiia Lukianenko <
> > > > anastasiia_lukiane...@epam.com> wrote:
> > > >
Obtaining the microcode revision on Intel CPUs is complicated for backwards
compatibility reasons. Update apply_microcode() to use a slightly more
efficient CPUID invocation, now that the documentation has been updated to
confirm that any CPUID instruction is fine, not just CPUID.1
On 10/12/20 3:55 PM, BALATON Zoltan wrote:
On Mon, 12 Oct 2020, Philippe Mathieu-Daudé wrote:
From: Philippe Mathieu-Daudé
The PCI_ADDR() macro use generic PCI fields shifted by 8-bit.
Rewrite it extracting the shift operation one layer.
Signed-off-by: Philippe Mathieu-Daudé
---
On Mon, 12 Oct 2020, Philippe Mathieu-Daudé wrote:
From: Philippe Mathieu-Daudé
The PCI_ADDR() macro use generic PCI fields shifted by 8-bit.
Rewrite it extracting the shift operation one layer.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/bonito.c | 4 ++--
1 file changed, 2
All interrupts and exceptions pass a struct cpu_user_regs up into C. This
contains the legacy vm86 fields from 32bit days, which are beyond the
hardware-pushed frame.
Accessing these fields is generally illegal, as they are logically out of
bounds for anything other than an interrupt/exception
> On Oct 12, 2020, at 12:31 AM, Nick Rosbrook wrote:
>
> There is a standard format for generated Go code header comments, as set
> by [1]. Modify gengotypes.py to follow this standard, and use the
> additional
>
> // source:
>
> convention used by protoc-gen-go.
>
> This change is
> On Oct 12, 2020, at 12:31 AM, Nick Rosbrook wrote:
>
> Currently, in order to 'import idl' in gengotypes.py, we derive the path
> of the libxl source directory from the XEN_ROOT environment variable, and
> append that to sys.path so python can see idl.py. Since the the recent move of
>
flight 155728 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155728/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 12 October 2020 13:45
> To: qemu-de...@nongnu.org
> Cc: Peter Maydell ; qemu-...@nongnu.org;
> qemu-triv...@nongnu.org; Paul
> Durrant ; Aurelien Jarno ;
> qemu-...@nongnu.org; Philippe Mathieu-
> Daudé ; Michael S. Tsirkin ;
From: Philippe Mathieu-Daudé
We already have a generic PCI_SLOT() macro in "hw/pci/pci.h"
to extract the PCI slot identifier, use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/hppa/dino.c| 2 +-
hw/i386/xen/xen-hvm.c | 2 +-
hw/isa/piix3.c| 2 +-
hw/mips/gt64xxx_pci.c | 2
Trivial patches using the generic PCI macros from "hw/pci/pci.h".
Philippe Mathieu-Daudé (5):
hw/pci-host/bonito: Make PCI_ADDR() macro more readable
hw/pci-host: Use the PCI_BUILD_BDF() macro from 'hw/pci/pci.h'
hw/pci-host/uninorth: Use the PCI_FUNC() macro from 'hw/pci/pci.h'
hw: Use
From: Philippe Mathieu-Daudé
We already have a generic PCI_DEVFN() macro in "hw/pci/pci.h"
to pack the PCI slot/function identifiers, use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/arm/virt.c | 3 ++-
hw/pci-host/uninorth.c | 6 ++
2 files changed, 4 insertions(+), 5
From: Philippe Mathieu-Daudé
We already have a generic PCI_FUNC() macro in "hw/pci/pci.h" to
extract the PCI function identifier, use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/uninorth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/pci-host/uninorth.c
From: Philippe Mathieu-Daudé
The PCI_ADDR() macro use generic PCI fields shifted by 8-bit.
Rewrite it extracting the shift operation one layer.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/bonito.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
From: Philippe Mathieu-Daudé
We already have a generic PCI_BUILD_BDF() macro in "hw/pci/pci.h"
to pack these values, use it.
Signed-off-by: Philippe Mathieu-Daudé
---
hw/pci-host/bonito.c | 3 +--
hw/pci-host/pnv_phb4.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid guest-start
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 155712 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155712/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken in 155673
Tests
On Mon, Oct 12, 2020 at 12:26:06PM +0200, Jürgen Groß wrote:
> > > @@ -807,6 +807,15 @@ static inline temp_mm_state_t
> > > use_temporary_mm(struct mm_struct *mm)
> > > temp_mm_state_t temp_state;
> > > lockdep_assert_irqs_disabled();
> > > +
> > > + /*
> > > + * Make sure
flight 155714 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155714/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cc942105ede58a300ba46f3df0edfa86b3abd4dd
baseline version:
ovmf
flight 155713 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155713/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
On 12.10.20 12:13, Peter Zijlstra wrote:
On Fri, Oct 09, 2020 at 04:42:25PM +0200, Juergen Gross wrote:
When running in lazy TLB mode the currently active page tables might
be the ones of a previous process, e.g. when running a kernel thread.
This can be problematic in case kernel code is
On Fri, Oct 09, 2020 at 04:42:25PM +0200, Juergen Gross wrote:
> When running in lazy TLB mode the currently active page tables might
> be the ones of a previous process, e.g. when running a kernel thread.
>
> This can be problematic in case kernel code is being modified via
> text_poke() in a
> -Original Message-
> From: Jürgen Groß
> Sent: 12 October 2020 10:56
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Andrew Cooper' ; 'George Dunlap'
> ; 'Ian
> Jackson' ; 'Jan Beulich' ; 'Julien
> Grall' ;
> 'Stefano Stabellini' ; 'Wei Liu'
> Subject: Re: [PATCH v2 1/2]
On 12.10.20 11:48, Paul Durrant wrote:
-Original Message-
From: Xen-devel On Behalf Of Juergen
Gross
Sent: 12 October 2020 10:28
To: xen-devel@lists.xenproject.org
Cc: Juergen Gross ; Andrew Cooper ;
George Dunlap
; Ian Jackson ; Jan Beulich
; Julien
Grall ; Stefano Stabellini ; Wei
> -Original Message-
> From: Xen-devel On Behalf Of Juergen
> Gross
> Sent: 12 October 2020 10:28
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Jan Beulich
> ; Julien
> Grall ; Stefano Stabellini ; Wei Liu
>
> Subject:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.
The second patch is modifying the per
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intact. For this purpose
the event channel contains
On 12.10.20 11:10, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.
The second patch is modifying the per
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intact. For this purpose
the event channel contains
flight 155724 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155724/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
flight 155721 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155721/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On 2020/10/12 13:28, Ira Weiny wrote:
> On Sat, Oct 10, 2020 at 10:20:34AM +0800, Coly Li wrote:
>> On 2020/10/10 03:50, ira.we...@intel.com wrote:
>>> From: Ira Weiny
>>>
>>> These kmap() calls are localized to a single thread. To avoid the over
>>> head of global PKRS updates use the new
On Fri, Oct 09, 2020 at 06:30:36PM -0700, Eric Biggers wrote:
> On Sat, Oct 10, 2020 at 01:39:54AM +0100, Matthew Wilcox wrote:
> > On Fri, Oct 09, 2020 at 02:34:34PM -0700, Eric Biggers wrote:
> > > On Fri, Oct 09, 2020 at 12:49:57PM -0700, ira.we...@intel.com wrote:
> > > > The kmap() calls in
flight 155716 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155716/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 8 xen-boot fail REGR. vs. 155584
Tests which
71 matches
Mail list logo
