flight 135096 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135096/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135003 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135003/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134763
build-i386-pvops
flight 135097 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
build-i386-pvops
On 4/22/19 1:26 AM, Mathieu Tarral wrote:
The problem is that RtlUserThreadStart is paged-out, so i'm trying to reach it
via singlestepping as a backup solution.
FWIW, you can just use xc_hvm_inject_trap() with a TRAP_page_fault
parameter to cause the OS to bring a paged out page back into ma
flight 135000 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135000/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm broken in 134634
build-arm64
On 21/04/2019 23:26, Mathieu Tarral wrote:
Answering out of order.
> I discussed this bug on IRC with andyhpp, who convinced me to move the
> discussion on the mailing list.
> Apparently the singlestepping in Xen was in a poor quality state because of
> multiple layers of refactoring.
What I s
flight 84088 distros-debian-sid real [real]
http://osstest.xensource.com/osstest/logs/84088/
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
flight 135103 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135103/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
Print log at level XENLOG_ERR (instead XENLOG_INFO) as domain_crash()
indicates there is fatal error.
Signed-off-by: Dongli Zhang
---
xen/common/grant_table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index 80728ea..72
On Sat, Apr 20, 2019 at 07:27:55PM -0400, Daniel P. Smith wrote:
> On 4/18/19 9:11 AM, George Dunlap wrote:
> > On 4/18/19 2:52 AM, Daniel P. Smith wrote:
> >> This deals with two casting issues for compiling under go 1.11:
> >> - explicitly cast to *C.xentoollog_logger for Ctx.logger pointer
> >>
flight 135107 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135107/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
version targeted for testi
flight 135111 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135111/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
freebsd 8752233742e58f015043521829fd0792f1728c6e
baseline version:
freebsd 55a254f7734
flight 135118 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135118/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
CONFIG_EARLY_PRINTK can only be set when CONFIG_DEBUG is enabled. It can
be quite convenient to only modify the target.
However, the target clean will not include the .config. This means
CONFIG_DEBUG is not enabled and therefore make will throw an error
preventing clean to continue.
The check is
The pattern _AC(1, UL{,L}) << X is commonly used in the headers to make
define usuable in both assembly and C.
So introduce _BITUL and _BITULL to make the code slightly more readable.
The idea has been taken from Linux (see include/uapi/linux.h).
Signed-off-by: Julien Grall
---
xen/include/xen
Hi all,
This is the second part of the boot/memory rework for Xen on Arm. This
part contains mostly clean-up & fixes found during the rework.
The first part of the rework is "xen/arm: TLB flush helpers rework" [1].
For convenience, I provided a branch with all the patches applied based
on next-4
So far, we don't init specific core initialization at boot. So remove
the comment.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm64/head.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/arch/arm/arm64/head.S b/xen/arch/arm/arm64/head.S
index cb30d6f22e..ad446e7345 100644
--- a/xen/ar
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor syst
The current value of HSCTLR_BASE for Arm64 is pretty wrong. It would
actually turn on SCTLR_EL2.nAA (bit 6) on hardware implementing
ARMv8.4-LSE.
Furthermore, the documentation of what is cleared/set in SCTLR_EL2 is
also not correct and looks like to be a verbatim copy from Arm32.
HSCTLR_BASE is
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for CPU0 domheap is unnecessary.
Furthermore, CPU0 page-tables are part of Xen binary and will already be
zeroed beforehand. So it
At the moment, the earlyprintk messages are interleaved with the
instructions. This makes more difficult to read the objdump output.
Introduce a new macro to add a string in .rodata.str and use it for all
the earlyprintk messages.
Signed-off-by: Julien Grall
---
I haven't done a similar change
The two helpers {destroy, modify}_xen_mappings don't check that the
start is always before the end. This should never happen but if it
happens, it will result to unexpected behavior.
Catch such issues earlier on by adding an ASSERT in destroy_xen_mappings
and modify_xen_mappings.
Signed-off-by: J
There are no reason to consider the HW CPU ID will be 0 when the
processor is part of a uniprocessor system. At best, this will result to
conflicting output as the rest of Xen use the value directly read from
MPIDR_EL1.
So remove the zeroing and logic to check if the CPU is part of a
uniprocessor
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 1 -
xen/arch/arm/arm64/head.S | 1 -
xen/arch/arm/setup.c | 3 +--
3 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/
None of the parameters of secondary_start are actually used. So turn
secondary_start to a function with no parameters.
Also modify the assembly code to avoid setting-up the registers before
calling secondary_start.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 6 +++---
xen/arch/a
The function create_xen_entries may be concurrently called. So we need
to protect with a spinlock to avoid corruption the page-tables.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index fa0f41bd0
We currently use the very long version __attribute__((__aligned(4096)))
to align page-tables. Thankfully there is a shorter version to make
the code more readable.
While modifying the attribute:
1) Move it before the variable name as we do in other part of Xen
2) Switch to PAGE_SIZE instea
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much earlier in the
boot process. The earliest setup_page_tables() can be called is after
traps have been ini
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This may result to TLB conflict abort.
Rather than dealing with Break-Before-Make in set_fixmap, every call to
set_fixmap is paired with a call to clear_fixmap.
Signed-off-by: Julien Grall
---
The boot code is using r2 and r3 to hold the page-table entry value.
While r2 is always updated before storing the value, this is not always
the case for r3.
Thankfully today, r3 will always be zero when we care. But this is
difficult to track and error-prone.
So always zero r3 within the few ins
The co-processor registers MAIR0 and MAIR1 are managed by EL1. So there
are no need to initialize them during Xen boot.
Signed-off-by: Julien Grall
---
xen/arch/arm/arm32/head.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/arch/arm/arm32/head.S b/xen/arch/arm/arm32/head.S
index d42a1
The newly introduced macro _BITUL makes the code more readable.
Signed-off-by: Julien Grall
---
xen/include/asm-arm/processor.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index c6f56490b
CONFIG_EARLY_PRINTK can only be set when CONFIG_DEBUG is enabled. It can
be quite convenient to only modify the target.
However, the target clean will not include the .config. This means
CONFIG_DEBUG is not enabled and therefore make will throw an error
preventing clean to continue.
The check is
The page-table walker is configured to use the same shareability and
cacheability as the access performed when updating the page-tables. This
means cleaning the cache for secondary CPUs runtime page-tables is
unnecessary.
Signed-off-by: Julien Grall
---
xen/arch/arm/mm.c | 3 ---
1 file changed,
The SCTLR_* are currently used for SCTLR/HSCTLR (arm32) and
SCTLR_EL1/SCTLR_EL2 (arm64).
The naming scheme is actually quite confusing because they may only be
defined for an archicture (or even an exception level). So it is not easy
for the developer to know which one to use.
The naming scheme i
flight 135008 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135008/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow216 guest-saverestore.2 fail REGR. vs. 133989
build-i386
On Sun, 21 Apr 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 4/20/19 12:20 AM, Stefano Stabellini wrote:
> > On Wed, 27 Feb 2019, Julien Grall wrote:
> > > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > index 30cfb01..5b8fcc5 100644
> > > > --- a/xen/arch/arm/p2m.c
> > > > +++ b/x
Hi,
On 22/04/2019 18:33, Stefano Stabellini wrote:
> On Sun, 21 Apr 2019, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 4/20/19 12:20 AM, Stefano Stabellini wrote:
>>> On Wed, 27 Feb 2019, Julien Grall wrote:
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 30cfb01..5b8fcc5 100
flight 135128 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135128/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135010 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135010/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 134015
test-amd64-amd64-xl-q
flight 135124 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135124/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 134977
build-i386-pvops
flight 135143 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135143/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
On Sun, 21 Apr 2019, Julien Grall wrote:
> > > > diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> > > > index 30cfb01..5b8fcc5 100644
> > > > --- a/xen/arch/arm/p2m.c
> > > > +++ b/xen/arch/arm/p2m.c
> > > > @@ -1068,9 +1068,24 @@ int unmap_regions_p2mt(struct domain *d,
> > > >int map_mm
On Tue, 26 Feb 2019, Julien Grall wrote:
> Hi Stefano,
>
> On 26/02/2019 23:07, Stefano Stabellini wrote:
> > reserved-memory regions should be mapped as normal memory. At the
> > moment, they get remapped as device memory in dom0 because Xen doesn't
> > know any better. Add an explicit check for
flight 135014 qemu-upstream-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135014/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134
On Monday 22 April 2019 11:22, Razvan Cojocaru
wrote:
> On 4/22/19 1:26 AM, Mathieu Tarral wrote:
>
> > The problem is that RtlUserThreadStart is paged-out, so i'm trying to reach
> > it via singlestepping as a backup solution.
>
> FWIW, you can just use xc_hvm_inject_trap() with a TRAP_page_fa
flight 135155 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135017 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133846
Tests which did not suc
flight 135158 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135158/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-i386 10 debian-hvm-install fail REGR. vs.
133991
Tests
flight 135021 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/135021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 133923
build-i386-pvops
50 matches
Mail list logo
