This run is configured for baseline tests only.
flight 72504 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-i386-pvgrub 7 xen-boot
flight 116714 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116714/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which did not
flight 116711 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116711/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-armhf-xsm
flight 116707 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116707/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-win10-i386 broken
test-amd64-i386-rumprun-i386
Hi all,
I recently updated from xen-4.6.6 to xen-4.8.2 and I am unable to start any
guest that previously worked without issue under 4.6.6. The create process
fails with the following:
libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
w=0x9cea28
This run is configured for baseline tests only.
flight 72503 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72503/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install
On Thu, Nov 30, 2017 at 01:22:37PM +, Julien Grall wrote:
> Hi Daniel,
>
> On 30/11/17 13:06, Daniel Kiper wrote:
> >On Wed, Nov 29, 2017 at 05:08:12PM +, Julien Grall wrote:
> >>The properties #address-cells and #size-cells are used to know the
> >>number of cells for ranges provided by
flight 116692 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116692/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 116571
On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> This patch series adds support for booting Linux as PVH guest.
>
> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> platform grub is booted as a standalone image directly by Xen.
>
> For booting Linux kernel it is
flight 116698 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116698/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 116651
test-armhf-armhf-libvirt-raw 13
On 27/11/17 14:41, Jan Beulich wrote:
On 27.11.17 at 14:02, wrote:
>> Xen 4.8 and later virtualises CPUID Faulting support for guests. However,
>> the
>> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
>> that the current cpuid faulting
On 11/29/2017 6:44 AM, Paolo Bonzini wrote:
I actually like this patch, except that I'd get the e820 memory map from
fw_cfg (see the first part of
https://github.com/bonzini/qboot/blob/master/fw_cfg.c, and extract_e820
inhttps://github.com/bonzini/qboot/blob/master/main.c) instead of the
second
2017-11-30 12:20+0100, Paolo Bonzini:
> On 30/11/2017 10:33, Fabian Grünbichler wrote:
> >
> > It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which
> > the symptoms disappeared until this series was merged, which contains
> >
> > 369ea8242c0fb5239b4ddf0dc568f694bd244de4
All these are functions which are invoked from elsewhere, but they are
not typical C functions. So we annotate them (as global) using the new
SYM_CODE_START. All these were not balanced with any END, so mark their
ends by SYM_CODE_END, appropriatelly.
Signed-off-by: Jiri Slaby
>>> On 30.11.17 at 15:15, wrote:
> On 11/30/2017 2:27 AM, Jan Beulich wrote:
> On 29.11.17 at 18:38, wrote:
> In the case of bus or slot reset, our goal is to reset connected PCIe
> fabric/card/endpoint.
> The connected
Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros:
8 OBJECT LOCAL DEFAULT6 gdt
000832 OBJECT LOCAL DEFAULT6 gdt_start
0028 0 OBJECT LOCAL DEFAULT6 gdt_end
0028 256 OBJECT LOCAL DEFAULT6 early_stack
0128 0 OBJECT LOCAL DEFAULT6
These are all functions which are invoked from elsewhere, so we annotate
them as global using the new SYM_FUNC_START. And their ENDPROC's by
SYM_FUNC_END.
And make sure ENTRY/ENDPROC is not defined on X86_64, given these were
the last users.
Signed-off-by: Jiri Slaby
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So introduce macros with clear use to annotate assembly as follows:
a) Support
There is a couple of assembly functions, which are invoked only locally
in the file they are defined. In C, we mark them "static". In assembly,
annotate them using SYM_{FUNC,CODE}_START_LOCAL (and switch their
ENDPROC to SYM_{FUNC,CODE}_END too). Whether FUNC or CODE depends on
ENDPROC/END for a
_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.
Jann validly points out that with a caller bogusly requesting a zero-
element batch with non-zero high command bits (the ones used for
continuation encoding), the assertion right before the call to
hypercall_create_continuation() would trigger. A similar situation would
arise afaict for non-empty
>>> On 28.11.17 at 15:05, wrote:
> A call to handle_hvm_io_completion() is needed for completing I/O
> that requires external emulation. Such completion should be requested when
> hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
> completed. This is
On 11/30/2017 2:27 AM, Jan Beulich wrote:
On 29.11.17 at 18:38, wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed
On 11/30/2017 2:29 AM, Jan Beulich wrote:
On 29.11.17 at 20:44, wrote:
So, we will use the following sequence to reset the requested
device/function.
- FLR (as first option)
- BUS/SLOT reset (as fall-back option) if FLR is not supported or any
issue with FLR
It
flight 116680 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116680/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail REGR. vs. 115539
Tests which are
Hi Daniel,
On 30/11/17 13:06, Daniel Kiper wrote:
On Wed, Nov 29, 2017 at 05:08:12PM +, Julien Grall wrote:
The properties #address-cells and #size-cells are used to know the
number of cells for ranges provided by "regs". If they don't exist, the
value are resp. 2 and 1.
Currently, when
On Wed, Nov 29, 2017 at 05:08:12PM +, Julien Grall wrote:
> The properties #address-cells and #size-cells are used to know the
> number of cells for ranges provided by "regs". If they don't exist, the
> value are resp. 2 and 1.
>
> Currently, when multiboot nodes are created it is assumed that
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-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
flight 116663 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116663/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ws16-amd64 7 xen-boot fail REGR. vs. 116628
osstest service owner writes ("[xen-unstable test] 116642: regressions - FAIL"):
> flight 116642 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/116642/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-17045 / XSA-247
version 3
Missing p2m error checking in PoD code
UPDATES IN VERSION 3
CVE assigned.
Fixed "Reported-by" tags in patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-17044 / XSA-246
version 3
x86: infinite loop due to missing PoD error checking
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2017-17046 / XSA-245
version 2
ARM: Some memory not scrubbed at boot
UPDATES IN VERSION 2
CVE assigned.
NOTE REGARDING LACK OF EMBARGO
>>> On 30.11.17 at 12:33, wrote:
> On 30/11/17 09:10, Jan Beulich wrote:
>> Olaf has observed this assertion to trigger after an aborted migration
>> of a PV guest (it remains to be determined why there is a page fault in
>> the first place here:
>>
>> (XEN) Xen call
flight 72501 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72501/
Perfect :-)
All tests in this flight passed as required
baseline version:
flight 72484
jobs:
build-amd64 pass
This run is configured for baseline tests only.
flight 72500 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72500/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 19
flight 116671 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116671/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken in 116625
Tests
On 30/11/2017 10:33, Fabian Grünbichler wrote:
>
> It was reverted in 785373b4c38719f4af6775845df6be1dfaea120f after which
> the symptoms disappeared until this series was merged, which contains
>
> 369ea8242c0fb5239b4ddf0dc568f694bd244de4 mm/rmap: update to new mmu_notifier
> semantic v2
>
>
flight 116665 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116665/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail in
116623 pass in 116665
flight 116628 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 7 xen-boot fail REGR. vs. 115643
>>> On 30.11.17 at 09:23, wrote:
> On Wed, Nov 29, Jan Beulich wrote:
>
>> Ah, I see. But then still I don't see why at least on half way
>> recent Xen /sys/hypervisor/properties/features wouldn't have
>> the information you're after (and even more precise, because
>> down the
>>> On 29.11.17 at 20:44, wrote:
> So, we will use the following sequence to reset the requested
> device/function.
>
> - FLR (as first option)
> - BUS/SLOT reset (as fall-back option) if FLR is not supported or any
> issue with FLR
It looks to me as if the slot
>>> On 29.11.17 at 18:38, wrote:
>>> In the case of bus or slot reset, our goal is to reset connected PCIe
>>> fabric/card/endpoint.
>>> The connected card/endpoint can be multi-function device. So, same
>>> walk-through and checking
>>> is needed irrespective of type of
43 matches
Mail list logo