Further to my last, I downloaded the latest Windows Server 2016 ISO from
Microsoft.
Filename: Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO
Have attached as much of the log as I could get attempting to boot from
the ISO and having a blank LV as the install target.
The Windows e
flight 143123 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143123/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 6996ec88a244a2428beb81d126ee55d152f62a07
baseline version:
ovmf 95d2883647dd8bf91f65c
Support for the kernel as Xen 32-bit PV guest will soon be removed.
Issue a warning when booted as such.
Signed-off-by: Juergen Gross
---
arch/x86/xen/enlighten_pv.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
index 58f79a
On 25.10.2019 09:00, Steven Haigh wrote:
> Further to my last, I downloaded the latest Windows Server 2016 ISO from
> Microsoft.
>
> Filename: Windows_Server_2016_Datacenter_EVAL_en-us_14393_refresh.ISO
>
> Have attached as much of the log as I could get attempting to boot from
> the ISO and ha
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index cf5a7b8e1e..4aa0af5a12 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -764,6 +764,10 @@ void __init noreturn __start_xen(unsig
It will be used to gate Hyper-V related code outside of the guest
directory.
No functional change.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 3 +++
xen/include/asm-x86/guest/hyperv.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c
Provide a structure to store that information. The structure will be
accessed from other places later so make it public.
Signed-off-by: Wei Liu
---
xen/arch/x86/guest/hyperv/hyperv.c | 14 ++
xen/include/asm-x86/guest/hyperv.h | 12
2 files changed, 26 insertions(+)
dif
Taken from Linux commit b2d8b167e15bb5ec2691d1119c025630a247f649.
This is a pristine copy from Linux. It is not used yet and probably
doesn't compile. Changes to make it work will come later.
Signed-off-by: Wei Liu
---
xen/include/asm-x86/guest/hyperv-tlfs.h | 906
1 fi
Do the following:
1. include xen/types.h and xen/bitops.h
2. fix up invocations of BIT macro
Signed-off-by: Wei Liu
---
This can be squashed into previous patch if preferred.
---
xen/include/asm-x86/guest/hyperv-tlfs.h | 141
1 file changed, 71 insertions(+), 70 deletion
The hypervisor_setup method is not unique to Xen guest.
Signed-off-by: Wei Liu
---
xen/arch/x86/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 4aa0af5a12..044c45be36 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x8
Hi all
This series adds a clock source based on Hyper-V's reference TSC. The meat
is in the last patch.
With this series, Xen on Hyper-V no longer runs on emulated PIT.
(XEN) Platform timer is 2294.686MHz HYPER-V REFERENCE TSC
This series depends on [0].
Wei.
0: https://lists.xen.org/archives
Implement a clock source using Hyper-V's reference TSC page.
Signed-off-by: Wei Liu
---
Relevant spec:
https://github.com/MicrosoftDocs/Virtualization-Documentation/raw/live/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0C.pdf
Section 12.6.
---
xen/arch/x86/time.c | 87 ++
# patch -p1 < ../000-debug-patch-0.patch
patching file xen/arch/x86/hvm/hvm.c
Hunk #1 succeeded at 3373 (offset 1 line).
patching file xen/arch/x86/hvm/svm/svm.c
Hunk #1 succeeded at 2159 (offset -64 lines).
I've attached the output from around boot all the way until after the
Windows HVM DomU c
All,
the 4.11.3 stable release is due. I intend to wait for the XSA fixes
going public on the 31st, but not (much) longer. Please point out
backporting candidates that you find missing from the respective
stable trees. I have three ones queued which haven't passed the push
gate to the master branc
On Thursday, October 24, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:
>
>
> On Friday, October 18, 2019, Philippe Mathieu-Daudé
> wrote:
>
>> Changes since v1 [0]:
>> - Removed patch reintroducing DO_UPCAST() use (thuth)
>> - Took various patches out to reduce series (thuth)
>>
Hi all,
I am wondering whether we should tag livepatch-build-tools.git with Xen releases
Best Regards
Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17340 / XSA-284
version 3
grant table transfer issues on large hosts
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17346 / XSA-292
version 3
x86: insufficient TLB flushing when using PCID
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17342 / XSA-287
version 3
x86: steal_page violates page_struct access discipline
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17344 / XSA-290
version 3
missing preemption in x86 PV page table unvalidation
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17345 / XSA-291
version 3
x86/PV: page type reference counting issue with failed IOMMU update
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17341 / XSA-285
version 3
race with pass-through device hotplug
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17348 / XSA-294
version 3
x86 shadow: Insufficient TLB flushing when using PCID
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17351 / XSA-300
version 3
Linux: No grant table and foreign mapping limits
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
===
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2019-17343 / XSA-288
version 3
x86: Inconsistent PV IOMMU discipline
UPDATES IN VERSION 3
CVE assigned.
ISSUE DESCRIPTION
=
> On Oct 24, 2019, at 8:54 PM, Nick Rosbrook wrote:
>
>> So we *could* actually just `type KeyValueList struct { }`, and punt on
>> all these initialization questions until such time as it turns out that
>> they're needed.
>
> If there is no clear need for this type to be implemented in the Go
On 23.10.2019 15:58, Andrew Cooper wrote:
> evaluate_nospec() is incredibly fragile, and this is one giant bodge.
>
> To correctly protect jumps, the generated code needs to be of the form:
>
> cmp/test
> jcc 1f
> lfence
> ...
> 1: lfence
> ...
>
> Critically, the lfence mu
On 23.10.2019 15:58, Andrew Cooper wrote:
> Just as with CONFIG_SPECULATIVE_HARDEN_ARRAY, branch hardening should be
> configurable at compile time.
>
> The previous CONFIG_HVM was a consequence of what could be discussed publicly
> at the time the patches were submitted, and wasn't actually corre
flight 143151 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143151/
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 23.10.2019 15:58, Andrew Cooper wrote:
> l1tf-barrier is an inappropriate name, and came about because of restrictions
> on could be discussed publicly when the patches were proposed.
>
> In practice, it is for general Spectre v1 mitigations, and is necessary in all
> cases. An adversary which
On 23.10.2019 15:58, Andrew Cooper wrote:
> system.h isn't an appropriate place to live, now that asm/nospec.h exists.
> This should arguably have been part of c/s db591d6e76e
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 25/10/2019 13:03, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> evaluate_nospec() is incredibly fragile, and this is one giant bodge.
>>
>> To correctly protect jumps, the generated code needs to be of the form:
>>
>> cmp/test
>> jcc 1f
>> lfence
>> ...
>> 1
On 23.10.2019 15:58, Andrew Cooper wrote:
> This optimisation is not safe on ARM, because some CPUs do data value
> speculation, which is why the CSDB barrer was introduced.
So if an x86 CPU appeared which did so too, it would immediately be
unsafe as well aiui. I.e. we'd have to again go and fix
On 10/25/19 12:05 PM, Lars Kurth wrote:
Hi all,
I am wondering whether we should tag livepatch-build-tools.git with Xen
releases
I thought this had been discussed before but I can't find anything in my
archives.
IMO livepatch-build-tools is a separate tool that doesn't need to move
in l
> Ok, in that case let’s just leave the struct empty.
Ok, sounds like a plan.
> I think we basically have three options:
>
> 1. Try to arrange it so that the “zero” values correspond to “default” values
> in libxl; i.e., have DevID 0 -> libxl_devid -1, DevID 1 -> libxl_devid 0, &c
>
> 2. Add New
On 25/10/2019 13:27, Ross Lagerwall wrote:
> On 10/25/19 12:05 PM, Lars Kurth wrote:
>> Hi all,
>>
>> I am wondering whether we should tag livepatch-build-tools.git with
>> Xen releases
>>
>
> I thought this had been discussed before but I can't find anything in
> my archives.
I recall a discussio
On 25.10.2019 14:10, Andrew Cooper wrote:
> On 25/10/2019 13:03, Jan Beulich wrote:
>> On 23.10.2019 15:58, Andrew Cooper wrote:
>>> evaluate_nospec() is incredibly fragile, and this is one giant bodge.
>>>
>>> To correctly protect jumps, the generated code needs to be of the form:
>>>
>>> cmp/
On 25.10.2019 14:27, Ross Lagerwall wrote:
> On 10/25/19 12:05 PM, Lars Kurth wrote:
>> Hi all,
>>
>> I am wondering whether we should tag livepatch-build-tools.git with Xen
>> releases
>>
>
> I thought this had been discussed before but I can't find anything in my
> archives.
Iirc this was on
On 25/10/2019 13:24, Jan Beulich wrote:
> On 23.10.2019 15:58, Andrew Cooper wrote:
>> This optimisation is not safe on ARM, because some CPUs do data value
>> speculation, which is why the CSDB barrer was introduced.
> So if an x86 CPU appeared which did so too, it would immediately be
> unsafe as
On 15.10.2019 17:47, Roger Pau Monne wrote:
> Current AMD IOMMU code will attempt to create remapping entries for
> all IO-APIC pins, regardless of the delivery mode. AMD IOMMU
> implementation doesn't support remapping entries for IO-APIC pins with
> delivery mode set to SMI, MNI, INIT or ExtINT,
On 15.10.2019 17:47, Roger Pau Monne wrote:
> Hello,
>
> The following series contain fixes for issues found when enabling
> interrupt remapping and the IO-APIC already has unmasked pins. While I'm
> not aware of any system malfunctioning (apart from reporting IOMMU
> interrupt remapping faults) I
On Fri, Oct 25, 2019 at 03:19:57PM +0200, Jan Beulich wrote:
> On 15.10.2019 17:47, Roger Pau Monne wrote:
> > Hello,
> >
> > The following series contain fixes for issues found when enabling
> > interrupt remapping and the IO-APIC already has unmasked pins. While I'm
> > not aware of any system m
On 25.10.2019 14:58, Andrew Cooper wrote:
> On 25/10/2019 13:24, Jan Beulich wrote:
>> On 23.10.2019 15:58, Andrew Cooper wrote:
>>> @@ -21,9 +28,15 @@ static inline unsigned long
>>> array_index_mask_nospec(unsigned long index,
>>> {
>>> unsigned long mask;
>>>
>>> -asm volatile ( "cm
On 10/25/19 3:38 AM, Juergen Gross wrote:
> Support for the kernel as Xen 32-bit PV guest will soon be removed.
> Issue a warning when booted as such.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
> ---
> arch/x86/xen/enlighten_pv.c | 8
> 1 file changed, 8 insertions(
Andrew Cooper writes ("Re: [Xen-devel] Tagging livepatch-build-tools.git with
Xen releases"):
> On 25/10/2019 13:27, Ross Lagerwall wrote:
> > On 10/25/19 12:05 PM, Lars Kurth wrote:
> >> Hi all,
> >>
> >> I am wondering whether we should tag livepatch-build-tools.git with
> >> Xen releases
> >>
>
On 24.10.2019 05:45, Marek Marczykowski-Górecki wrote:
> Do not require switching page tables to access (static) information in
> the runtime services table itself, use directmap for this. This allows
> exiting early from XEN_EFI_query_capsule_capabilities,
> XEN_EFI_update_capsule and XEN_EFI_quer
On 24.10.2019 05:45, 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 called with 1:1 mapping, which
>isn't the case at this time
> - it uses directmap, which may go away soon
>
On 24.10.2019 05:45, Marek Marczykowski-Górecki wrote:
> Some UEFI implementations are not happy about lack of
> SetVirtualAddressMap() call. Likely abuse the address map change
> notification to do things beyond the necessary ConvertPointer() calls.
> Specifically, wihtout the SetVirtualAddressMap
On 30.09.2019 15:32, Roger Pau Monne wrote:
> ...and switch vPCI to use this infrastructure for long running
> physmap modification operations.
>
> This allows to get rid of the vPCI specific modifications done to
> handle_hvm_io_completion and allows generalizing the support for
> long-running op
On 23.10.2019 14:58, Roger Pau Monné wrote:
> On Wed, Oct 23, 2019 at 09:11:54AM +, Alexandru Stefan ISAILA wrote:
>>
>>
>> On 03.09.2019 20:24, Tamas K Lengyel wrote:
>>> On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
On 02.09.2019 10:11, Alexandru Stefan ISAILA wrote:
> --
On 25.10.2019 17:36, Alexandru Stefan ISAILA wrote:
>
>
> On 23.10.2019 14:58, Roger Pau Monné wrote:
>> On Wed, Oct 23, 2019 at 09:11:54AM +, Alexandru Stefan ISAILA wrote:
>>>
>>>
>>> On 03.09.2019 20:24, Tamas K Lengyel wrote:
On Tue, Sep 3, 2019 at 9:53 AM Jan Beulich wrote:
>
On 24.10.19 05:45, Marek Marczykowski-Górecki wrote:
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
On 24.10.19 19:27, Andrew Cooper wrote:
* Initialise all spinlock fields together
* No need for an atomic set_bit() to initialise domid_bitmap
* Avoid using partial-line printk()'s.
* Style fixes (too many, and too few spaces)
No functional change.
Signed-off-by: Andrew Cooper
Releas
On 25/10/2019 13:34, Jan Beulich wrote:
> On 25.10.2019 14:10, Andrew Cooper wrote:
>> On 25/10/2019 13:03, Jan Beulich wrote:
>>> On 23.10.2019 15:58, Andrew Cooper wrote:
evaluate_nospec() is incredibly fragile, and this is one giant bodge.
To correctly protect jumps, the generated
On 25.10.2019 17:27, Andrew Cooper wrote:
> On 25/10/2019 13:34, Jan Beulich wrote:
>> On 25.10.2019 14:10, Andrew Cooper wrote:
>>> The two choices to unblock 4.13 are this patch, or the previous version
>>> which made CONFIG_HARDEN_BRANCH depend on BROKEN, which was even more
>>> disliked.
>> Opt
The driver for the laxtons' network cards is not in 4.4 (and that's
quite old). Our ThunderX's may even require something more recent but
we will cross that bridge when we see it.
Effect is to drop the following jobs:
linux-4.1 *arm64*
linux-4.4 *arm64*
linux-4.9 *arm64*
(Checked by eyeb
Rather than merely 1000. Right now we have a troublesome FreeBSD
build problem which needs this!
Signed-off-by: Ian Jackson
---
adhoc-revtuple-generator | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index be3f3755..ac0f24
5s is so short that when a host fails to respond we aren't sure if it
was just very idle and ran off its PSU's internal energy storage for
that period.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm
Now we have two lists of things not supported on ARM: one of branches
where that's inherent in the branch somehow, and one for those where
the kernel is simply too old. The latter are going to differ between
armhf and arm64.
No functional change.
(Verified with standalone-generate-dump-flight-run
We aren't actually interested in bisecting the FreeBSD
version (usually, the anointed version) which was used as the platform
for the failed builds. We are thereby making the assumption that any
build failure (or indeed test failure) is the result in changes to the
recent FreeBSD being actually bu
flight 143128 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143128/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow broken
test-amd64-i386-xl-qemuu-win10-
On 25.10.19 17:48, Ian Jackson wrote:
Now we have two lists of things not supported on ARM: one of branches
where that's inherent in the branch somehow, and one for those where
the kernel is simply too old. The latter are going to differ between
armhf and arm64.
No functional change.
(Verified
osstest service owner writes ("[linux-linus test] 143128: regressions -
trouble: broken/fail/pass"):
> flight 143128 linux-linus real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143128/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which co
On 24/10/2019 12:57, Steven Haigh wrote:
> Hi all,
>
> I've managed to get the git master version of Xen on this affected
> system and tries to boot a Windows Server 2016 system. It crashes as
> per normal.
>
> I managed to get these logs, but I'm not quite sure what else to do to
> debug this issu
FIXME: The case where something failed when trying to acquired the
lock isn't handled yet.
This patch workaround the fact that it's not possible to connect
multiple time to a single QMP socket. QEMU listen on the socket with
a backlog value of 1, which mean that on Linux when concurrent thread
No functionnal changes.
Signed-off-by: Anthony PERARD
---
tools/libxl/libxl_disk.c| 6 +++---
tools/libxl/libxl_dm.c | 8
tools/libxl/libxl_dom_save.c| 2 +-
tools/libxl/libxl_dom_suspend.c | 2 +-
tools/libxl/libxl_domain.c | 8
tools/libxl/libxl
Allow to kill a child and deregister the callback associated with it.
The death isn't immediate will need to be collected later, so the
ev_child machinery register its own callback.
libxl__ev_child_kill() might be called by an AO operation that is
finishing/cleaning up without a chance for libxl
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.fix-ev_qmp-multi-connect-v1
Hi,
QEMU's QMP socket doesn't allow multiple concurrent connection. Also, it
listen() on the socket with a `backlog' of only 1. On Linux at least, once that
This lock will be used to prevent concurrent access the QEMU's QMP
socket. It is based on libxl__ev_devlock implementation and have the
same properties.
There is one addition to the ev_devlock API,
libxl__ev_qmplock_dispose, which allow to cancel the lock operation
while it is in Active state.
Si
flight 143133 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143133/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-livepatch7 xen-boot fail REGR. vs. 142750
test-amd64-i386-qe
flight 143165 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 143138 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143138/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 18 guest-localmigrate/x10 fail REGR. vs. 139698
Tests which are faili
On 10/25/19 17:40, Jan Beulich wrote:
> On 25.10.2019 17:27, Andrew Cooper wrote:
>> On 25/10/2019 13:34, Jan Beulich wrote:
>>> On 25.10.2019 14:10, Andrew Cooper wrote:
The two choices to unblock 4.13 are this patch, or the previous version
which made CONFIG_HARDEN_BRANCH depend on BROK
flight 143140 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143140/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host fail REGR. vs. 143023
test-amd64-amd64-libvir
flight 143178 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143178/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
This series of patches is to improve the parsing by pygrub of grub
configuration on Fedora. The current result of parsing is generally
that the second kernel listed is set as the default due to a
set default=1 line in grub.cfg which is only intended to be
reached after repeated boot failures.
The
This patch adds an example grub.cfg and grubenv file for reference
Signed-off-by: Michael Young
---
tools/pygrub/examples/fedora-31.grub.cfg | 200 +++
tools/pygrub/examples/fedora-31.grubenv | 5 +
2 files changed, 205 insertions(+)
create mode 100644 tools/pygrub/exampl
When a grub.cfg file is found this patch checks if there is grubenv
file in the same directory as the grub.cfg file. If there is it
passes the contents to parse().
Signed-off-by: Michael Young
---
tools/pygrub/src/pygrub | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-
This patch reads the contents of a grubenv file if available, and
uses the value of next_entry (in preference) or of saved_entry to
set the default kernel if there is a matching title or if it is a
number. If either next_entry or saved_entry is set and neither is
used then the default is set to 0.
flight 143143 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143143/
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. 142915
Regressions which
gcc (GCC) 9.2.0 complains:
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’:
xentoollog_stubs.c:93:16: error: initialization discards ‘const’ qualifier from
pointer target type [-Werror=discarded-qualifiers]
93 | value *func = caml_named_value(xtl->vmessage_cb) ;
|
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-xsm
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: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu g
flight 143153 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143153/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd 7 freebsd-buildfail REGR. vs. 141501
Tests which did
On 25.10.19 19:01, Andrew Cooper wrote:
On 24/10/2019 12:57, Steven Haigh wrote:
Hi all,
I've managed to get the git master version of Xen on this affected
system and tries to boot a Windows Server 2016 system. It crashes as
per normal.
I managed to get these logs, but I'm not quite sure what
flight 143155 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 7 xen-bootfail REGR. vs. 141776
Tests which di
85 matches
Mail list logo
