flight 129413 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129413/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 7 xen-boot fail REGR. vs. 128921
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemut-win10-i386
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-credit2
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Hi Julien,
> >>
> >>>
> >>> Just have a question, does XEN ARM support RTC in domu? To support
> >>> Android
> >> in DomU, RTC is needed for alarm, but I did not find information
> >> about RTC on xen for domu. So this need a new RTC paravirtualization
> >> driver?
> Any suggestions?
> >>
> >>
flight 129412 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129412/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
For both PC and Q35 machine types, we can set it at the PCI host
bridge creation time.
Signed-off-by: Samuel Ortiz
---
hw/i386/pc_piix.c | 1 +
hw/i386/pc_q35.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index f5b139a3eb..f1f0de3585 100644
---
From: Sebastien Boeuf
Instead of using the machine type specific method find_i440fx() to
retrieve the PCI bus, this commit aims to rely on the fact that the
PCI bus is known by the structure AcpiPciHpState.
When the structure is initialized through acpi_pcihp_init() call,
it saves the PCI bus,
For building the MCFG table, we need to track a given machine
type PCI host pointer, and we can't get it from the bus pointer alone.
As piix returns a PCI bus pointer, we simply modify its builder to
return a PCI host pointer instead.
Signed-off-by: Samuel Ortiz
---
include/hw/i386/pc.h | 21
In order to decouple ACPI APIs from specific machine types, we are
creating an ACPI builder interface that each ACPI platform can choose to
implement.
This way, a new machine type can re-use the high level ACPI APIs and
define some custom table build methods, without having to duplicate most
of
This is the standard way of building SRAT on x86 platfoms. But future
machine types could decide to define their own custom SRAT build method
through the ACPI builder methods.
Moreover, we will also need to reach build_srat() from outside of
acpi-build in order to use it as the ACPI builder SRAT
From: Yang Zhong
When using the generated memory hotplug AML, the iasl
compiler would give the following error:
dsdt.dsl 266: Return (MOST (_UID, Arg0, Arg1, Arg2))
Error 6080 - Called method returns no value ^
Signed-off-by: Yang Zhong
---
hw/acpi/memory_hotplug.c | 10 +-
1 file
All PC machine type derivatives will use the same ACPI table build
methods. But with that change in place, any new x86 machine type will be
able to re-use the acpi-build API and customize part of it by defining
its own ACPI table build methods.
Reviewed-by: Philippe Mathieu-Daudé
Tested-by:
From: Sebastien Boeuf
The ACPI hotplug support for PCI devices APIs are not x86 or even
machine type specific. In order for future machine types to be able to
re-use that code, we export it through the architecture agnostic
hw/acpi folder.
Reviewed-by: Philippe Mathieu-Daudé
Tested-by:
From: Yang Zhong
Now that the ACPI builder methods are added, we can reach the ACPI
configuration pointer from the MachineState pointer. From there we can
get to the PCI host pointer and return it.
This makes the PCI host getter an ACPI, architecture agnostic function.
Signed-off-by: Yang
It is going to be used by the PC machine type as the MADT table builder
method and thus needs to be exported outside of acpi-build.c
Also, now that the generic build_madt() API is exported, we have to
rename the ARM static one in order to avoid build time conflicts.
Reviewed-by: Philippe
This property is currently defined under i386/pc while it only describes
a region size that's eventually fetched from the AML ACPI code.
We can make it more generic and shareable across machine types by moving
it to memory-device.h instead.
Signed-off-by: Samuel Ortiz
---
include/hw/i386/pc.h
From: Yang Zhong
The _OSC AML table is almost identical between the i386 Q35 and arm virt
machine types. We can make it slightly more generic and share it across
all PCIe architectures.
Signed-off-by: Yang Zhong
---
include/hw/acpi/acpi-defs.h | 14 +++
include/hw/acpi/aml-build.h | 2 +-
The PCI hole properties are not pc or i386 specific. They belong to the
PCI host header instead.
Signed-off-by: Samuel Ortiz
---
include/hw/i386/pc.h | 5 -
include/hw/pci/pci_host.h | 6 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/include/hw/i386/pc.h
From: Yang Zhong
The ACPI MCFG getter is not x86 specific and could be called from
anywhere within generic ACPI API, so let's export it.
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Yang Zhong
---
include/hw/acpi/aml-build.h | 1 +
XSDT is the 64-bit version of the legacy ACPI RSDT (Root System
Description Table). RSDT only allow for 32-bit addressses and have thus
been deprecated. Since ACPI version 2.0, RSDPs should point at XSDTs and
no longer RSDTs, although RSDTs are still supported for backward
compatibility.
Since
ACPI tables are platform and machine type and even architecture
agnostic, and as such we want to provide an internal ACPI API that
only depends on platform agnostic information.
For the x86 architecture, in order to build ACPI tables independently
from the PC or Q35 machine types, we are moving a
This is going to be needed by the hardware reduced implementation, so
let's export it.
Once the ACPI builder methods and getters will be implemented, the
acpi_get_pci_host() implementation will become hardware agnostic.
Signed-off-by: Samuel Ortiz
---
include/hw/acpi/aml-build.h | 2 ++
The hardware-reduced API will need to build RSDP as well, so we should
export this routine.
Signed-off-by: Samuel Ortiz
---
include/hw/acpi/aml-build.h | 3 +++
hw/arm/virt-acpi-build.c| 2 +-
hw/i386/acpi-build.c| 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git
This is going to be needed by the Hardware-reduced ACPI routines.
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
Signed-off-by: Samuel Ortiz
---
include/hw/acpi/aml-build.h | 2 ++
hw/acpi/aml-build.c | 8
hw/i386/acpi-build.c| 8
3
This patch set provides an ACPI code reorganization in preparation for
adding a shared hardware-reduced ACPI API to QEMU.
The changes are coming from the NEMU [1] project where we're defining
a new x86 machine type: i386/virt. This is an EFI only, ACPI
hardware-reduced platform that is built on
For both x86 and ARM architectures, the internal RSDP build API can
return void as the current return value is unused.
Signed-off-by: Samuel Ortiz
---
hw/arm/virt-acpi-build.c | 4 +---
hw/i386/acpi-build.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git
Hello Ian,
On Mon, Oct 29, 2018 at 08:55:09PM +, Paraschiv, Andra-Irina wrote:
>
>
> On Mon, Oct 29, 2018 at 04:58:22PM +0200, Pasi Kärkkäinen wrote:
> > Hi,
> >
> > On Wed, Oct 24, 2018 at 04:20:35PM +0100, Ian Jackson wrote:
> > > Andra Paraschiv writes ("[PATCH RESEND
flight 129405 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129405/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 16 guest-start/debian.repeat fail in 129375 pass
in 129405
flight 129400 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129400/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 129369
test-armhf-armhf-libvirt 14
This run is configured for baseline tests only.
flight 75568 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75568/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
flight 129389 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129389/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs.
125898
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-freebsd10-amd64
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
Found the references of these in
https://lists.xenproject.org/archives/html/xen-devel/2017-02/msg03120.html
proposal to split PV, PVHVM and PVH code in kernel.
There is no mention of any change or requirement from Xen perspective. Any
other way to track this problem?
On Sun, Nov 4, 2018 at 6:37
I've built a dom0 kernel 4.14 with SMP support. The dom0 kernel crashes
when I'm downloading a large file on host. It does not crash if I have
nosmp boot option on xen command line.
my .config SMP options are
[root@f6029920339a wip-kernel-4.14.78]# grep SMP .config
CONFIG_X86_64_*SMP*=y
flight 129406 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129406/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 2cf113891a38cc05434bc9876ffc107a990887be
baseline version:
xen
flight 129375 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/129375/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken in 129346
Tests
36 matches
Mail list logo
