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 a
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 0dab57708de64284ac83f
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.
>
> 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 No
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 4a723d3d7fd1cbbc28c92
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 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
test-amd
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
> cra
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 du
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 X
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 d
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
Xen-devel@li
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 13
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 X
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
https://lists.xenproject.org/mailman/l
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
https://lists.xenproject.org/mail
flight 75485 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75485/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
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 inherit
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 o
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
---
xen/arc
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 fault.
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
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 Gra
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
___
Xen-d
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:
> >
> > panic("Timed out waiting for alternatives self-NMI to
On 10/23/18 2: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
Acked-by: Julien Grall
Cheers,
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad
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 1
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: Tamas
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, they
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:
>>>
>>> panic("Tim
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.
>
> Signed-off
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 hvm_monito
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 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
>>> +++ b/xen/arch/x86/h
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 situa
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 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
flight 128922 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128922/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-xsm-freebsd broken
build-amd64-xen-freebsd
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
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 1
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 do_sgi(
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.
Un
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: Ensur
Devices that expose their interrupt status registers via system
registers (e.g. Statistical profiling, CPU PMU, DynamIQ PMU, arch timer,
vgic (although unused by Linux), ...) rely on a context synchronising
operation on the CPU to ensure that the updated status register is
visible to the CPU when h
Den 08. okt. 2018 16:32, skrev Boris Ostrovsky:
>
> Are these two patches still needed? ISTR they were written originally
> to deal with guest trying to use device that was previously assigned to
> another guest. But pcistub_put_pci_dev() calls
> __pci_reset_function_locked() which first tries F
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
test-armhf-arm
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
examine-arndale-metroce
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
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
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:
>
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 1
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
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
C
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 68099b52b0fcc1d458641
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 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 041d89bc0f0119df37a5f
flight 128929 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128929/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128861
test-amd64-i386-xl-q
flight 128933 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128933/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128910
test-armhf-armhf-libvirt 14 sav
flight 128954 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128954/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a58a421c3629e5f28b4a6887c28da4ee6976cd61
baseline version:
ovmf 90c64aada8a14dca551aa
62 matches
Mail list logo
