flight 128953 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128953/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 90c64aada8a14dca551aa48bc5a5763a39933525
baseline version:
ovmf
Commit 4855c92dbb7 "xen-swiotlb: fix the check condition for
xen_swiotlb_free_coherent" only fixed memory address check condition
on xen_swiotlb_free_coherent(), when memory was not physically
contiguous and tried to exchanged with Xen via
xen_destroy_contiguous_region it will lead kernel panic.
flight 128952 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128952/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 041d89bc0f0119df37a5fce1d0f16495ff905089
baseline version:
ovmf
From: Stefano Stabellini
Introduce a device tree binding for Xen reserved-memory regions. They
are used to share memory across VMs from the VM config files. (See
static_shm config option.)
Signed-off-by: Stefano Stabellini
Cc: julien.gr...@arm.com
---
Changes in v3:
- remove fallback version
On Tue, 23 Oct 2018, Milan Boberic wrote:
> > Just add an && irq != 1023 to the if check.
> Added it and now when I create bare-metal guest it prints only once:
>
> (XEN) DEBUG irq=0
> (XEN) d1v0 No valid vCPU found for vIRQ32 in the target list (0x2). Skip it
> (XEN) d1v0 No valid vCPU found for
flight 128951 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128951/
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
On 23/10/2018 23:01, Ross Philipson wrote:
> On 10/23/2018 12:58 PM, Andrew Cooper wrote:
>> On 23/10/18 17:42, Ross Philipson wrote:
>>> On 10/23/2018 11:31 AM, Jason Andryuk wrote:
On Tue, Oct 23, 2018 at 10:46 AM Andrew Cooper
wrote:
> On 23/10/18 15:01, Jason Andryuk wrote:
On 10/23/2018 12:58 PM, Andrew Cooper wrote:
> On 23/10/18 17:42, Ross Philipson wrote:
>> On 10/23/2018 11:31 AM, Jason Andryuk wrote:
>>> On Tue, Oct 23, 2018 at 10:46 AM Andrew Cooper
>>> wrote:
On 23/10/18 15:01, Jason Andryuk wrote:
> On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper
flight 128925 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128925/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128847
test-amd64-i386-xl-qemuu-win7-amd64 17
flight 128948 examine real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128948/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
examine-laxton1 2 hosts-allocate broken REGR. vs. 127984
flight 128950 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128950/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
Hi all,
The first two patches resolves to out-of-order bug in the GIC code. They are
candidate for backporting.
The last patch is an relaxation in the barrier used when sending an SGI.
Cheers,
Julien Grall (4):
xen/arm: gic: Ensure we have an ISB between ack and do_IRQ()
xen/arm: gic:
When an IPI is generated by a CPU, the pattern looks roughly like:
dsb(sy);
On the receiving CPU we rely on the fact that, once we've taken the
interrupt, then the freshly written shared data must be visible to us.
Put another way, the CPU isn't going to speculate taking an interrupt.
When sending an SGI to another CPU, we require a barrier to ensure that
any pending stores to normal memory are made visible to the recipient
before the interrupt arrives.
For GICv2, rather than using dsb(sy) before writel_gicd, we can instead
use dsb(ishst), since we just need to ensure that any
Signed-off-by: Julien Grall
---
xen/arch/arm/gic.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
index 30c0fba0d7..0108e9603c 100644
--- a/xen/arch/arm/gic.c
+++ b/xen/arch/arm/gic.c
@@ -363,7 +363,6 @@ void gic_disable_cpu(void)
static void
flight 128947 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128947/
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
This run is configured for baseline tests only.
flight 75486 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75486/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 23/10/18 17:42, Ross Philipson wrote:
>
> On 10/23/2018 11:31 AM, Jason Andryuk wrote:
>> On Tue, Oct 23, 2018 at 10:46 AM Andrew Cooper
>> wrote:
>>> On 23/10/18 15:01, Jason Andryuk wrote:
On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper
wrote:
> On 23/10/18 11:59, Sergey Dyasli
On 10/23/2018 11:31 AM, Jason Andryuk wrote:
> On Tue, Oct 23, 2018 at 10:46 AM Andrew Cooper
> wrote:
>> On 23/10/18 15:01, Jason Andryuk wrote:
>>> On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper
>>> wrote:
On 23/10/18 11:59, Sergey Dyasli wrote:
> In certain scenarios, NMIs might be
On Tue, Oct 23, 2018 at 10:46 AM Andrew Cooper
wrote:
>
> On 23/10/18 15:01, Jason Andryuk wrote:
> > On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper
> > wrote:
> >> On 23/10/18 11:59, Sergey Dyasli wrote:
> >>> In certain scenarios, NMIs might be disabled during Xen boot process.
> >>> Such
On 10/23/18 6:08 PM, Andrew Cooper wrote:
> On 23/10/18 15:54, Razvan Cojocaru wrote:
>> On 10/23/18 5:35 PM, Andrew Cooper wrote:
>>> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
>>> index 2a41ccc..f1a196f 100644
>>> --- a/xen/arch/x86/hvm/monitor.c
>>> +++
On 10/23/18 5:35 PM, Andrew Cooper wrote:
> The may_defer booleans were introduced with the monitor infrastructure, but
> their purpose is not obvious and not described anywhere.
>
> They exist to avoid triggering nested monitoring events from introspection
> activities, but with the introduction
On 23/10/18 15:54, Razvan Cojocaru wrote:
> On 10/23/18 5:35 PM, Andrew Cooper wrote:
>> diff --git a/xen/arch/x86/hvm/monitor.c b/xen/arch/x86/hvm/monitor.c
>> index 2a41ccc..f1a196f 100644
>> --- a/xen/arch/x86/hvm/monitor.c
>> +++ b/xen/arch/x86/hvm/monitor.c
>> @@ -36,6 +36,9 @@ bool
On 10/23/18 5:35 PM, Andrew Cooper wrote:
> When applying vm_event actions, monitoring events can nest and effectively
> livelock the vcpu. Introduce a boolean which is set for a specific portion of
> the hvm_do_resume() path, which causes the hvm_monitor_* helpers to exit
> early.
>
>
On 23/10/18 15:01, Jason Andryuk wrote:
> On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper
> wrote:
>> On 23/10/18 11:59, Sergey Dyasli wrote:
>>> In certain scenarios, NMIs might be disabled during Xen boot process.
>>> Such situation will cause alternative_instructions() to:
>>>
>>>
This is another split-out part of of the v1 debugging series. It is semi-RFC
as it as only had extremely light testing.
Andrew Cooper (2):
x86/monitor: Introduce a boolean to suppress nested monitoring events
x86/hvm: Drop the may_defer boolean from hvm_* helpers
xen/arch/x86/hvm/emulate.c
When applying vm_event actions, monitoring events can nest and effectively
livelock the vcpu. Introduce a boolean which is set for a specific portion of
the hvm_do_resume() path, which causes the hvm_monitor_* helpers to exit
early.
Signed-off-by: Andrew Cooper
---
CC: Razvan Cojocaru
CC:
The may_defer booleans were introduced with the monitor infrastructure, but
their purpose is not obvious and not described anywhere.
They exist to avoid triggering nested monitoring events from introspection
activities, but with the introduction of the general monitor.suppress
infrastructure,
flight 128946 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128946/
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
On 10/23/18 4:51 PM, Andrew Cooper wrote:
> Altp2m aids monitoring guest memory, not hypervisor memory. Also, put its
> common name in brackets to aid searching.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Razvan Cojocaru
Thanks,
Razvan
___
Altp2m aids monitoring guest memory, not hypervisor memory. Also, put its
common name in brackets to aid searching.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
CC: Wei Liu
CC: Julien
On 10/23/18 1:52 PM, Andrii Anisov wrote:
Hello Julien,
Hi,
In case you are ordering those includes in the alphabetical order,
shouldn't be `asm/...` includes placed above `xen/...`?
The common headers (e.g xen/) should be placed before architecture
specific (asm/). They should then be
This patch is a pre-requisite for the one fixing VGA logdirty
freezes when using altp2m. It only concerns itself with the
ranges allocation / deallocation / initialization part. While
touching the code, I've switched global_logdirty from bool_t
to bool.
Signed-off-by: Razvan Cojocaru
---
When an new altp2m view is created very early on guest boot, the
display will freeze (although the guest will run normally). This
may also happen on resizing the display. The reason is the way
Xen currently (mis)handles logdirty VGA: it intentionally
misconfigures VGA pages so that they will
Hello,
This series aims to prevent the display from freezing when
enabling altp2m and switching to a new view (and assorted problems
when resizing the display). Since the last version of the series,
what was previously the second (and last) patch has been split in
two patches, the first of which
This patch is a pre-requisite for fixing the logdirty VGA issue
(display freezes when switching to a new altp2m view early in a
domain's lifetime), but sent separately for easier review.
The new ept_set_ad_sync() function has been added to update all
active altp2ms' ept.ad. New altp2ms will
Hello Julien,
In case you are ordering those includes in the alphabetical order,
shouldn't be `asm/...` includes placed above `xen/...`?
--
*Andrii Anisov*
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Tamas, could you please give this a spin?
https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2
It _should_ solve the crashes.
Thanks,
Razvan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On 23/10/18 11:59, Sergey Dyasli wrote:
> In certain scenarios, NMIs might be disabled during Xen boot process.
> Such situation will cause alternative_instructions() to:
>
> panic("Timed out waiting for alternatives self-NMI to hit");
>
> This bug was originally seen when using Tboot to boot
Hello Stefano,
On 25.09.18 01:55, Stefano Stabellini wrote:
> Compile platform code that doesn't have its own specific kconfig option
> only if ALL32_PLAT or ALL64_PLAT depending on the architecture. The
> benefit is that choosing one of the platforms available as a menu
> option allows the user
flight 128921 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128921/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail like
128892
test-amd64-i386-libvirt
Hello Stefano,
On 25.09.18 01:55, Stefano Stabellini wrote:
> Add a Kconfig option to select no specific platform support.
>
> Signed-off-by: Stefano Stabellini
Reviewed-by: Andrii Anisov
--
*Andrii Anisov*
___
Xen-devel mailing list
In certain scenarios, NMIs might be disabled during Xen boot process.
Such situation will cause alternative_instructions() to:
panic("Timed out waiting for alternatives self-NMI to hit");
This bug was originally seen when using Tboot to boot Xen.
To prevent this from happening, enable NMIs
On 23/10/18 11:21, Sergey Dyasli wrote:
> In certain scenarios, NMIs might be disabled during Xen boot process.
> Such situation will cause alternative_instructions() to:
>
> panic("Timed out waiting for alternatives self-NMI to hit");
>
> This bug was originally seen when using tboot to boot
On Mon, Oct 22, 2018 at 8:33 PM Konrad Rzeszutek Wilk wrote:
>
> one tiny fix for the Xen SWIOTLB mechanism that occasionally happened with
> devices that didn't allocate size in power of two but rather some odd
> sizes. We neglected to make the memory coherent leading to all kinds of fun
>
flight 128920 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128920/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 10 debian-hvm-install fail REGR.
vs. 125898
This run is configured for baseline tests only.
flight 75483 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75483/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128944 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128944/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 68099b52b0fcc1d45864154954d776d91afb33e0
baseline version:
ovmf
> Just add an && irq != 1023 to the if check.
Added it and now when I create bare-metal guest it prints only once:
(XEN) DEBUG irq=0
(XEN) d1v0 No valid vCPU found for vIRQ32 in the target list (0x2). Skip it
(XEN) d1v0 No valid vCPU found for vIRQ33 in the target list (0x2). Skip it
(XEN) d1v0
Any thoughts on this are appreciated.
Thanks,
Alex
On 18.10.2018 12:02, Alexandru Stefan ISAILA wrote:
> This patch adds a couple of regs to the vm_event that are used by
> the introspection. The base, limit and ar
> bits are compressed into a uint64_t union so as not to enlarge the
> vm_event.
flight 128943 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128943/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 4a723d3d7fd1cbbc28c92f14361761831ad27bab
baseline version:
ovmf
Hi all!
After a lot of struggle I can now report a pretty serious bug in
the vtpmmgr 2.0 implementation:
- To make a the VTPM contents permenent, surviving a reboot
you have to seal the contents using the Pearl scripts in the
source directory calc.pl and manage-vtpmmgr.pl
- If you are using
52 matches
Mail list logo
