flight 142612 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142612/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 142436
test-amd64-i386-xl-pvshim12 guest-
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.4-rc3-tag
xen: fixes for 5.4-rc3
It contains the following patches:
- a patch to correct panic handling when running as a Xen guest
- a cleanup in the Xen grant driver to remove pr
flight 142613 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142613/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl broken
test-amd64-amd64-libvirt-xsm
Remove unused (#ifdef-ed out) code. Reviving it in its current shape
won't fly because:
- SetVirtualAddressMap() needs to be mapped with 1:1 mapping, which
isn't the case at this time
- it uses directmap, which is going away soon
- it uses directmap, which is mapped with NX, breaking EfiRunti
Some UEFI implementations are not happy about running in 1:1 addressing,
but really virtual address space. Specifically, some access
EfiBootServices{Code,Data}, or even totally unmapped areas. Example
crash of GetVariable() call on Thinkpad W540:
Xen call trace:
[<0080>] 000
Workaround buggy UEFI accessing boot services memory after ExitBootServices().
Patches discussed here:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html
Test results on few laptops:
Thinkpad x230, firmware version 2.77:
- without the patch: crashes on RS call (mapbs help
On 12/10/2019 15:36, Marek Marczykowski-Górecki wrote:
> SetVirtualAddressMap() can be called only once,
True.
> hence it's incompatible with kexec.
Most certainly not.
Linux unconditionally enters virtual mode, citing a huge slew of EFI
firmware bugs, and is perfectly capable of kexec-ing on t
On 12/10/2019 15:36, Marek Marczykowski-Górecki wrote:
> Remove unused (#ifdef-ed out) code. Reviving it in its current shape
> won't fly because:
> - SetVirtualAddressMap() needs to be mapped with 1:1 mapping, which
>isn't the case at this time
> - it uses directmap, which is going away soon
On Sat, Oct 12, 2019 at 05:29:34PM +0100, Andrew Cooper wrote:
> On 12/10/2019 15:36, Marek Marczykowski-Górecki wrote:
> > SetVirtualAddressMap() can be called only once,
>
> True.
>
> > hence it's incompatible with kexec.
>
> Most certainly not.
>
> Linux unconditionally enters virtual mode,
On Sat, Oct 12, 2019 at 07:00:43PM +0200, Marek Marczykowski-Górecki wrote:
> On Sat, Oct 12, 2019 at 05:29:34PM +0100, Andrew Cooper wrote:
> > On 12/10/2019 15:36, Marek Marczykowski-Górecki wrote:
> > > SetVirtualAddressMap() can be called only once,
> >
> > True.
> >
> > > hence it's incompat
On 12/10/2019 18:00, Marek Marczykowski-Górecki wrote:
>>> For this reason, make it an optional feature, depending on
>>> !KEXEC.
>> This presupposes (at Xen's build time) that a kexec'd kernel is going to
>> want/need to use runtime services. I'm not convinced this is
>> universally true,
> In fa
flight 142617 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-pairbroken
test-amd64-i386-xl-xsm
The xen-ucode utility is new with the late loading improvements in 4.13.
Update the documentation suitably.
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 Grall
CC: J
Hello all, hello Paul,
On a certain new mainboard with chipset C242 and Intel Xeon E-2136 I
notice a severe clock drift. This is from dom0:
# uptime
20:13:52 up 81 days, 1:41, 1 user, load average: 0.00, 0.00, 0.00
# hwclock
2019-10-12 20:27:37.204966+02:00
# date
Sat Oct 12 20:07:19 CEST
flight 142636 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142636/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 142423
test-amd64-amd64-xl-qemuu
flight 142628 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm broken
test-amd64-amd64-xl-qemuu-debia
The pull request you sent on Sat, 12 Oct 2019 12:51:31 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
> for-linus-5.4-rc3-tag
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/680b5b3c5d34b22695357e17b6bdd0abd83e6b1c
Thank you!
--
Deet-doot-dot, I
Workaround buggy UEFI accessing boot services memory after ExitBootServices().
Patches discussed here:
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00701.html
In addition to the tests below, I've tested kexec on xen.efi with this option
enabled and it (still) works.
Test result
Remove unused (#ifdef-ed out) code. Reviving it in its current shape
won't fly because:
- SetVirtualAddressMap() needs to be called with 1:1 mapping, which
isn't the case at this time
- it uses directmap, which may go away soon
- it uses directmap, which is mapped with NX, breaking EfiRuntime
Some UEFI implementations are not happy about running in 1:1 addressing,
but really virtual address space. Specifically, some access
EfiBootServices{Code,Data}, or even totally unmapped areas. Example
crash of GetVariable() call on Thinkpad W540:
Xen call trace:
[<0080>] 000
flight 142644 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142644/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 142584
test-armhf-armhf-libvirt-raw 13 saveresto
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xen
flight 142642 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142642/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 141822
test-armhf-armhf-xl-rtds
flight 142648 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142648/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 20 guest-start/debian.repeat fail REGR. vs. 139698
Tests which are faili
flight 142660 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142660/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow broken in 142613
test-amd64-
25 matches
Mail list logo
