All,
am I the only one to see
xl: libxl.c:339: libxl_defbool_val: Assertion `!libxl_defbool_is_default(db)'
failed.
for any kind of (x86) guest being created, including simple XTF ones?
I haven't taken a closer look at the code yet, but with this I wonder
how even a smoke push could have occurr
Am Wed, 22 May 2019 01:11:54 -0600
schrieb "Jan Beulich" :
> libxl__domain_build_info_setdefault (gc=0x7fffdee0, b_info=0x7fffdb80)
> at libxl_create.c:143
This is libxl_defbool_val(b_info->device_model_stubdomain).
Due to the lack of a proper way to describe all the dependencies wit
On Wed, May 22, 2019 at 09:25:44AM +0200, Olaf Hering wrote:
> Am Wed, 22 May 2019 01:11:54 -0600
> schrieb "Jan Beulich" :
>
> > libxl__domain_build_info_setdefault (gc=0x7fffdee0,
> > b_info=0x7fffdb80)
> > at libxl_create.c:143
>
> This is libxl_defbool_val(b_info->device_model_st
flight 136592 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 136156
test-armhf-armhf-x
>>> On 22.05.19 at 09:25, wrote:
> Am Wed, 22 May 2019 01:11:54 -0600
> schrieb "Jan Beulich" :
>
>> libxl__domain_build_info_setdefault (gc=0x7fffdee0,
> b_info=0x7fffdb80)
>> at libxl_create.c:143
>
> This is libxl_defbool_val(b_info->device_model_stubdomain).
>
> Due to the lack
>>> On 22.05.19 at 00:24, wrote:
> The only use of asm/vpl011.h is protected by the CONFIG_SBSA_VUART_CONSOLE
> define so lets protect the include as well.
>
> Signed-off-by: Alistair Francis
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-de
>>> On 21.05.19 at 23:25, wrote:
> MAINTAINERS | 6 ++
> xen/arch/arm/Kconfig | 7 +++
> xen/arch/arm/Makefile | 1 +
> xen/arch/arm/domain.c | 18 ++
> xen/arch/arm/setup.c | 2 +
> xen/arch/arm/tee/Makefile | 1 +
> xen/arch
On 22/05/2019 09:45, Jan Beulich wrote:
On 21.05.19 at 23:25, wrote:
MAINTAINERS | 6 ++
xen/arch/arm/Kconfig | 7 +++
xen/arch/arm/Makefile | 1 +
xen/arch/arm/domain.c | 18 ++
xen/arch/arm/setup.c | 2 +
xen/arch/arm/t
On Mon, May 20, 2019 at 09:17:19AM -0600, Jan Beulich wrote:
> >>> On 20.05.19 at 13:40, wrote:
> > On Fri, May 17, 2019 at 04:48:21AM -0600, Jan Beulich wrote:
> >> fixup_irqs() skips interrupts without action. Hence such interrupts can
> >> retain affinity to just offline CPUs. With "noirqbalanc
There is no user of the preempt_count for non-debug builds. This series
removes it for that case.
Juergen Gross (3):
xen: drop in_atomic()
xen: drop preempt_count() for non-debug builds
xen: build common/preempt.c only with CONFIG_DEBUG
xen/arch/x86/hvm/hvm.c| 16
xen/
Currently there is only one user of in_atomic(), and that is in an
#ifdef 0 section. This has been so since Xen 4.1, so chances are
rather slim we suddenly want to enable it again.
Dropping in_atomic() will remove the last user of preempt_count()
in non-debug builds enabling further optimizations.
preempt_count() and the associated per-cpu variable __preempt_count
are tested in debug build only. So drop them for non-debug builds.
Signed-off-by: Juergen Gross
---
xen/common/preempt.c | 2 +-
xen/include/xen/preempt.h | 6 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff -
There is nothing left in common/preempt.c in non-debug builds.
Signed-off-by: Juergen Gross
---
xen/common/Makefile | 2 +-
xen/common/preempt.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 33d03b862f..d6576a3fc3 100644
--
>>> On 20.05.19 at 14:55, wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful in the case of emulated instructions that cause
> page-walks on access protected pages.
>
> We use hvmemul_map_linear_addr() ro intercept r/w access and
> hvmemul_insn_fetch()
On 22/05/2019 10:45, Juergen Gross wrote:
> Currently there is only one user of in_atomic(), and that is in an
> #ifdef 0 section. This has been so since Xen 4.1, so chances are
> rather slim we suddenly want to enable it again.
>
> Dropping in_atomic() will remove the last user of preempt_count()
On 22/05/2019 10:45, Juergen Gross wrote:
> preempt_count() and the associated per-cpu variable __preempt_count
> are tested in debug build only. So drop them for non-debug builds.
>
> Signed-off-by: Juergen Gross
I'd be tempted to fold patches 2 and 3 together, because they are both
the same cha
On Wed, May 22, 2019 at 02:40:51AM -0600, Jan Beulich wrote:
> >>> On 22.05.19 at 09:25, wrote:
> > Am Wed, 22 May 2019 01:11:54 -0600
> > schrieb "Jan Beulich" :
> >
> >> libxl__domain_build_info_setdefault (gc=0x7fffdee0,
> > b_info=0x7fffdb80)
> >> at libxl_create.c:143
> >
> > T
>>> On 22.05.19 at 11:27, wrote:
>
> On 22/05/2019 09:45, Jan Beulich wrote:
> On 21.05.19 at 23:25, wrote:
>>> MAINTAINERS | 6 ++
>>> xen/arch/arm/Kconfig | 7 +++
>>> xen/arch/arm/Makefile | 1 +
>>> xen/arch/arm/domain.c | 18 ++
>>> On 22.05.19 at 11:45, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>
> ASSERT(is_hvm_vcpu(v));
>
> -/*
> - * XXX Disable for 4.1.0: PV-on-HVM drivers will do grant-table ops
> -
>>> On 22.05.19 at 11:45, wrote:
> @@ -26,9 +28,11 @@ DECLARE_PER_CPU(unsigned int, __preempt_count);
> preempt_count()--; \
> } while (0)
>
> -#ifndef NDEBUG
> void ASSERT_NOT_IN_ATOMIC(void);
> +
> #else
> +#define preempt_disable()barrier();
> +#define pre
On 22/05/2019 12:00, Andrew Cooper wrote:
> On 22/05/2019 10:45, Juergen Gross wrote:
>> preempt_count() and the associated per-cpu variable __preempt_count
>> are tested in debug build only. So drop them for non-debug builds.
>>
>> Signed-off-by: Juergen Gross
>
> I'd be tempted to fold patches
>>> On 22.05.19 at 12:00, wrote:
> On 22/05/2019 10:45, Juergen Gross wrote:
>> preempt_count() and the associated per-cpu variable __preempt_count
>> are tested in debug build only. So drop them for non-debug builds.
>>
>> Signed-off-by: Juergen Gross
>
> I'd be tempted to fold patches 2 and 3
On 22/05/2019 12:12, Jan Beulich wrote:
On 22.05.19 at 11:45, wrote:
>> @@ -26,9 +28,11 @@ DECLARE_PER_CPU(unsigned int, __preempt_count);
>> preempt_count()--; \
>> } while (0)
>>
>> -#ifndef NDEBUG
>> void ASSERT_NOT_IN_ATOMIC(void);
>> +
>> #else
>> +#def
On 22/05/2019 12:10, Jan Beulich wrote:
On 22.05.19 at 11:45, wrote:
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>
>> ASSERT(is_hvm_vcpu(v));
>>
>> -/*
>> - * XXX Disable for 4.1.0:
On 22/05/2019 12:18, Jan Beulich wrote:
On 22.05.19 at 12:00, wrote:
>> On 22/05/2019 10:45, Juergen Gross wrote:
>>> preempt_count() and the associated per-cpu variable __preempt_count
>>> are tested in debug build only. So drop them for non-debug builds.
>>>
>>> Signed-off-by: Juergen Gross
On 22/05/2019 11:18, Jan Beulich wrote:
On 22.05.19 at 12:00, wrote:
>> On 22/05/2019 10:45, Juergen Gross wrote:
>>> preempt_count() and the associated per-cpu variable __preempt_count
>>> are tested in debug build only. So drop them for non-debug builds.
>>>
>>> Signed-off-by: Juergen Gross
flight 136753 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136753/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 4973997f70860c10093ce34294be0c588ddc8cf3
baseline version:
xen ae0e
flight 136752 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136752/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Hi Jan,
On 22/05/2019 11:02, Jan Beulich wrote:
On 22.05.19 at 11:27, wrote:
On 22/05/2019 09:45, Jan Beulich wrote:
On 21.05.19 at 23:25, wrote:
MAINTAINERS | 6 ++
xen/arch/arm/Kconfig | 7 +++
xen/arch/arm/Makefile | 1 +
xen/arch/arm/
On 21/05/2019 10:55, Julien Grall wrote:
Hi Jan,
On 5/21/19 10:43 AM, Jan Beulich wrote:
On 21.05.19 at 11:35, wrote:
On 5/21/19 10:26 AM, Jan Beulich wrote:
On 20.05.19 at 20:12, wrote:
As this is now Xen and tools only, I am wondering whether the check on
GNU_C is still nec
>>> On 22.05.19 at 14:20, wrote:
>
> On 21/05/2019 10:55, Julien Grall wrote:
>> Hi Jan,
>>
>> On 5/21/19 10:43 AM, Jan Beulich wrote:
>> On 21.05.19 at 11:35, wrote:
On 5/21/19 10:26 AM, Jan Beulich wrote:
On 20.05.19 at 20:12, wrote:
>> As this is now Xen and too
>>> On 22.05.19 at 12:19, wrote:
> On 22/05/2019 12:10, Jan Beulich wrote:
> On 22.05.19 at 11:45, wrote:
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>>>
>>> ASSERT(is_hvm_vcpu(v));
>>>
>>
On 22.05.2019 12:56, Jan Beulich wrote:
On 20.05.19 at 14:55, wrote:
>> This patch aims to have mem access vm events sent from the emulator.
>> This is useful in the case of emulated instructions that cause
>> page-walks on access protected pages.
>>
>> We use hvmemul_map_linear_addr() ro i
(+Artem)
Hi Jan,
On 22/05/2019 13:29, Jan Beulich wrote:
On 22.05.19 at 14:20, wrote:
On 21/05/2019 10:55, Julien Grall wrote:
Hi Jan,
On 5/21/19 10:43 AM, Jan Beulich wrote:
On 21.05.19 at 11:35, wrote:
On 5/21/19 10:26 AM, Jan Beulich wrote:
On 20.05.19 at 20:12, wrote:
As
On 22/05/2019 14:34, Jan Beulich wrote:
On 22.05.19 at 12:19, wrote:
>> On 22/05/2019 12:10, Jan Beulich wrote:
>> On 22.05.19 at 11:45, wrote:
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3185,22 +3185,6 @@ static enum hvm_translation_result __hvm_copy(
>
> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 20 May 2019 13:55
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
> ; Wei Liu ; Roger Pau Monne
> ;
> rcojoc...@bitdefender.com; ta...@tklengyel.com; Geo
>>> On 22.05.19 at 14:59, wrote:
> On 22.05.2019 12:56, Jan Beulich wrote:
> On 20.05.19 at 14:55, wrote:
>>> First we try to send a vm event and if the event is sent then emulation
>>> returns X86EMUL_ACCESS_EXCEPTION. If the event is not sent then the
>>> emulation goes on as expected.
>>
>>> Despite what was said before you're still doing things a 2nd time
>>> here just because of hvmemul_send_vm_event()'s needs, even
>>> if that function ends up bailing right away.
>>
>> I don't understand what things are done 2 times. Can you please explain?
>
> You add code above that exists a
On 5/22/19 2:13 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
>> Sent: 20 May 2019 13:55
>> To: xen-devel@lists.xenproject.org
>> Cc: Paul Durrant ; jbeul...@suse.com; Andrew Cooper
>> ; Wei Liu ; Roger Pau Monne
>> ;
>> rco
>>> On 22.05.19 at 15:50, wrote:
> Isn't it safer to move the hvmemul_send_vm_event() form
> hvmemul_insn_fetch() to __hvmemul_read()?
Possibly - I can't tell whether that'll fit all your needs. I also
don't recall whether this was proposed before and there
were reasons speaking against doing so
flight 136598 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136598/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 48f43c2c56eeaea63a6b7cb811a21b2a86904d86
baseline version:
ovmf 1887b995a3598795dba87
Since QEMU 2.10 (or qemu-xen-4.10), qemu locks disk images to avoid
them been re-opened in a different qemu process.
With Xen, there are two issues:
- For HVM guests, a disk image can be open twice! One by the
emulation driver, and one by the PV backend.
- During migration, the qemu process of t
On Wed, May 22, 2019 at 03:51:40PM +0100, Anthony PERARD wrote:
> Since QEMU 2.10 (or qemu-xen-4.10), qemu locks disk images to avoid
> them been re-opened in a different qemu process.
>
> With Xen, there are two issues:
> - For HVM guests, a disk image can be open twice! One by the
> emulation
flight 136603 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136603/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 135251
build-arm64
Ping?
On 5/13/19 2:56 PM, Ross Lagerwall wrote:
During a suspend/resume, the xenwatch thread waits for all outstanding
xenstore requests and transactions to complete. This does not work
correctly for transactions started by userspace because it waits for
them to complete after freezing userspace
x86_cpuid_copy_to_buffer() currently serialises the full content of the
various subleaf unions. While leaves 4, 0xb and 0xd don't have a concrete
max_subleaf field, they do have well defined upper bounds.
Diffing the results of `xen-cpuid -p` shows the resutling saving:
@@ -1,5 +1,5 @@
Xen
Hi,
Answering to myself.
On 10/05/2019 15:34, Julien Grall wrote:
On 10/05/2019 15:19, Jan Beulich wrote:
On 10.05.19 at 16:04, wrote:
On 10/05/2019 14:45, Jan Beulich wrote:
On 10.05.19 at 15:41, wrote:
The point here, we keep within the hypervisor the idea of what's valid or
invalid. Th
alternative_callN using inline assemble to generate the alternative
patch sites should be using the ALTERNATIVE C preprocessor macro
rather than the ALTERNATIVE assembly macro, the more that using the
assembly macro in an inline assembly instance causes the following
error on llvm based toolchains:
flight 136597 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136597/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 129313
Tests which did not
On Mon, May 20, 2019 at 09:26:37AM -0600, Jan Beulich wrote:
> >>> On 20.05.19 at 16:04, wrote:
> > On Fri, May 17, 2019 at 04:52:32AM -0600, Jan Beulich wrote:
> >> Use valid_irq_vector() rather than "> 0".
> >>
> >> Also replace an open-coded use of IRQ_VECTOR_UNASSIGNED.
> >>
> >> Signed-off-
Forget about this version, I've updated the subject and commit
message and forgot to re-generate the patch.
On Wed, May 22, 2019 at 05:38:10PM +0100, Roger Pau Monne wrote:
> alternative_callN using inline assemble to generate the alternative
> patch sites should be using the ALTERNATIVE C preproc
alternative_callN using inline assembly to generate the alternative
patch sites should be using the ALTERNATIVE C preprocessor macro
rather than the ALTERNATIVE assembly macro, the more that using the
assembly macro in an inline assembly instance causes the following
error on llvm based toolchains:
flight 136594 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
test-amd64-amd64-xl
Am Wed, 22 May 2019 15:51:40 +0100
schrieb Anthony PERARD :
> Can you give it a try with one of the affected qemu? (qemu-xen-4.10 or
> qemu-xen-4.11)
Thanks for the patch. Unfortunately there is no easy way to trigger the race.
Is the changed code path also exercised for PV domUs?
Olaf
pgpLmBW
Hello Julien, Jan
On Wed, 2019-05-22 at 14:00 +0100, Julien Grall wrote:
> (+Artem)
>
> Hi Jan,
>
> On 22/05/2019 13:29, Jan Beulich wrote:
> > > > > On 22.05.19 at 14:20, <
> > > > > julien.gr...@arm.com
> > > > > > wrote:
> > > On 21/05/2019 10:55, Julien Grall wrote:
> > > > Hi Jan,
> > > >
flight 136600 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136600/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 135859
test-amd64-amd64-xl-qemuu-ws16-amd64 17 g
DSDT for qemu-xen lacks _STA method of PCI slot object. If _STA method
doesn't exist then the slot is assumed to be always present and active
which in conjunction with _EJ0 method makes every device ejectable for
an OS even if it's not the case.
qemu-kvm is able to dynamically add _EJ0 method only
flight 136606 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136606/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd cb9788efd6dd2c8377e001d8a85c722ba926f6cf
baseline version:
freebsd 35c027f3215
On Tue, 21 May 2019, Alistair Francis wrote:
> The only use of asm/vpl011.h is protected by the CONFIG_SBSA_VUART_CONSOLE
> define so lets protect the include as well.
>
> Signed-off-by: Alistair Francis
Acked-by: Stefano Stabellini
> ---
> v3:
> - Rework commit title and message
> - Spl
flight 136609 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136609/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 136321
test-armhf-armhf-libvirt-raw 13 saveresto
From: Stefano Stabellini
On arm64 swiotlb is already initialized by mem_init. We don't want to
initialize it twice, the memory is already allocated. Detect this
condition in swiotlb-xen and skip the second initialization.
Signed-off-by: Stefano Stabellini
---
There are other issues which I fo
flight 136644 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136644/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 127792
build-amd64
flight 136637 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136637/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check
flight 136638 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136638/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvopsbroken in 134504
build-arm64
flight 136651 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/136651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-prev 6 xen-buildfail REGR. vs. 133596
build-amd64
65 matches
Mail list logo
