On 07.10.2019 12:41, Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.
>
> Fixes:
On 24.10.19 05:53, Anshuman Khandual wrote:
On 10/22/2019 10:42 PM, David Hildenbrand wrote:
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes. Hotplugged memory never has
holes. That memory is already online.
Why hot plugged memory
(+Ian and Stefano)
Hi,
On 10/24/19 8:13 AM, Jürgen Groß wrote:
On 24.10.19 08:47, osstest service owner wrote:
flight 143061 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 143061 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm broken
On 15.10.2019 17:47, Roger Pau Monne wrote:
> When interrupt remapping is enabled as part of enabling x2APIC the
> IO-APIC entries also need to be translated to the new format and added
> to the interrupt remapping table.
>
> This prevents IOMMU interrupt remapping faults when booting on
>
Hi Oleksandr,
On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU). So, even if it is not used by Xen it will
On 23.10.2019 22:33, Pry Mar wrote:
> Hello xen-devel,
>
> https://paste.debian.net/plain/1109374
>
> shows my traces from a healthy CentOS 8, xen-4.12.1 dom0 when trying
> to launch a pv install of the newly released ub1910. The source is a
> block-attached ISO and the kernel/ramdisk was copied
On 15.10.2019 17:47, Roger Pau Monne wrote:
> There's no need to save and restore the IO-APIC entries, the entries
> prior to suspension have already been saved by ioapic_suspend, and
> will be restored by ioapic_resume. Note that at the point where
> resume_x2apic gets called the IO-APIC has not
On Thu, Oct 24, 2019 at 09:13:14AM +0200, Jürgen Groß wrote:
> On 24.10.19 08:47, osstest service owner wrote:
> > flight 143061 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/143061/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> >
Hi Lars,
Sorry for the late response, the Unikraft team is certainly happy to support
this code of conduct.
Thanks,
-- Felipe
On 27.09.19, 06:22, "Xen-devel on behalf of Lars Kurth"
wrote:
From: Lars Kurth
This series proposes a concrete version of the Xen Project
CoC
On 23.10.19 18:23, George Dunlap wrote:
Both are now potentially asynchronous; pass in 'nil' to retain
synchronous behavior.
Signed-off-by: George Dunlap
Release-acked-by: Juergen Gross
Juergen
___
Xen-devel mailing list
On 24.10.19 10:57, Julien Grall wrote:
Hi Oleksandr,
On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen (device_get_class(iommu_node)
returns DEVICE_IOMMU).
On 24.10.19 08:47, osstest service owner wrote:
flight 143061 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143061/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
flight 143072 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143072/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 95d2883647dd8bf91f65cde87e73cede1dcc6574
baseline version:
ovmf
From: Paul Durrant
The vif-route script should only call 'ip route' when 'ipcmd' has been
set, otherwise it will fail due to an incorrect command string.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
This appears to have been broken forever.
---
tools/hotplug/Linux/vif-route
We discussed on irc the problems I have been having trying to get
buster's released kernel to run on the rochesters, which is wanted to
upgrade osstest to buster (which is currently Debian stable).
Unfortunately our previous conversations don't seem to have been
recorded anywhere. Let's try at
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Introduce gengotypes.py to generate Go code the from IDL. As a first step,
> implement 'enum' type generation.
>
> As a result of the newly-generated code, remove the existing, and now
> conflicting definitions in xenlight.go.
On Mon, Oct 7, 2019 at 3:41 AM Jan Beulich wrote:
>
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot; adjust BUG_IF_WRONG_CR3
> as well just in case.
I'm
On 24/10/2019 17:11, Andy Lutomirski wrote:
>> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
>> +#endif
>> +
>> .section .entry.text, "ax"
>>
>> /*
>> @@ -172,7 +183,7 @@
>> ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
>> .if \no_user_check == 0
>> /*
On Thu, Oct 24, 2019 at 9:32 AM Andrew Cooper wrote:
>
> On 24/10/2019 17:11, Andy Lutomirski wrote:
> >> +# define USER_SEGMENT_RPL_MASK (SEGMENT_RPL_MASK & ~1)
> >> +#endif
> >> +
> >> .section .entry.text, "ax"
> >>
> >> /*
> >> @@ -172,7 +183,7 @@
> >> ALTERNATIVE "jmp
On 10/7/19 4:13 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Remove the PKGSOURCES variable since adding xenlight_types.go
> and xenlight_helpers.go to this list breaks the rest of the
> Makefile.
>
> Add xenlight_%.go target for generated files, and use full
> file names within install,
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define KeyValueList builtin type, analagous to libxl_key_value_list as
> map[string]string, and implement its fromC and toC functions.
>
> Signed-off-by: Nick Rosbrook
> ---
> Cc: George Dunlap
> Cc: Ian Jackson
> Cc: Wei Liu
Not much clue in the logs. The crash params are weird though... certainly
not matching the doc. (
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0xac--hal-memory-allocation)
but then again they are not always to be believed.
There are some odd looking IOMMU faults in
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Signed-off-by: Nick Rosbrook
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Thursday, October 24, 2019 9:37 AM, Julien Grall wrote:
>Hi,
>
>Jumping into the conversation.
>
>On 24/10/2019 14:06, Jeff Kubascik wrote:
>> We would like to remove our current two developers who are listed as M: for
>> the
>> ARINC653 scheduler code. Since M: is just a "Mail patches to"
flight 143103 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143103/
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
Anthony PERARD writes ("Re: [XEN PATCH for-4.13 v7 11/11] libxl: On ARM, reject
future new passthrough modes too"):
> On Wed, Oct 23, 2019 at 02:00:13PM +0100, Ian Jackson wrote:
> > +case LIBXL_PASSTHROUGH_DISABLED;
>
> That looks strange, there a semicolon ^ here instead of a colon ':'.
>
On 10/7/19 4:12 PM, Nick Rosbrook wrote:
> From: Nick Rosbrook
>
> Define Defbool as struct analagous to the C type, and define the type
> 'defboolVal' that represent true, false, and default defbool values.
>
> Implement Set, Unset, SetIfDefault, IsDefault, Val, and String functions
> on
On 23/10/2019 17:48, Anthony PERARD wrote:
> Current description of the file by `file`:
> common/Kconfig: Non-ISO extended-ASCII text
>
> Change that byte to an ascii quote so the file can become properly
> encoded, and all ASCII.
>
> Signed-off-by: Anthony PERARD
Acked-by: Andrew Cooper
I
On 23.10.2019 15:58, Andrew Cooper wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -361,9 +361,23 @@ config FAST_SYMBOL_LOOKUP
>
> If unsure, say Y.
>
> +config ENFORCE_UNIQUE_SYMBOLS
> + bool "Enforce unique symbols" if LIVEPATCH
> + default y if LIVEPATCH
On 24/10/2019, 12:22, "Wei Liu" wrote:
On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> >
> > Signed-off-by: Wei Liu
> > ---
> > CONTRIBUTING | 1 -
> > 1 file changed, 1 deletion(-)
flight 143070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvshim 12 guest-start fail REGR. vs. 142915
ZONE_DEVICE (a.k.a. device memory) is no longer marked PG_reserved. Update
the comment.
While at it, make it match what the code is acutally doing (reject vs.
accept).
Cc: Kees Cook
Cc: Andrew Morton
Cc: "Isaac J. Manjarres"
Cc: "Matthew Wilcox (Oracle)"
Cc: Qian Cai
Cc: Thomas Gleixner
Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions -
trouble: broken/fail/pass"):
> On 24.10.19 12:48, Ian Jackson wrote:
> > There is a known bug with two of our arm64 boxes, where they lose some
> > of the output during boot. This is not important for operational use
Everything should be prepared to stop setting pages PG_reserved when
initializing the memmap on memory hotplug. Most importantly, we
stop marking ZONE_DEVICE pages PG_reserved.
a) We made sure that any code that relied on PG_reserved to detect
ZONE_DEVICE memory will no longer rely on
On 24.10.19 14:14, Lars Kurth wrote:
On 24/10/2019, 12:22, "Wei Liu" wrote:
On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> >
> > Signed-off-by: Wei Liu
> > ---
> > CONTRIBUTING | 1
Blktap2 is gone and tools/libs is missing in the document.
Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
Release-acked-by: Juergen Gross https://lists.xenproject.org/mailman/listinfo/xen-devel
It is certainly nice to have less users of the direct map. My non-EFI
builds already work without the direct map now but once I start testing
EFI, it is nice to have one less thing to worry about.
How important and performance-critical is this? If we really want to
avoid switching the page table,
On 24.10.2019 15:06, Jeff Kubascik wrote:
> We would like to remove our current two developers who are listed as M: for
> the
> ARINC653 scheduler code. Since M: is just a "Mail patches to" designation, I'm
> now leaning towards the L: designation, as the two appear roughly equivalent
> in
>
flight 143063 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143063/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken in 143025
test-amd64-amd64-xl-pvshim 18
On 24.10.19 13:06, Wei Liu wrote:
Blktap2 is gone.
Signed-off-by: Wei Liu
---
CONTRIBUTING | 1 -
1 file changed, 1 deletion(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 47f53e9a49..4fff4fd9f6 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -13,7 +13,6 @@ Most of the Xen Project code
Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.13] CONTRIBUTING: drop reference
to blktap2"):
> On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> > Mind adding tools/libs instead?
>
> Sure. That can be done.
>
> Because tools/libs' code is mostly split from libxc and friends, I
>
On Tue, Oct 22, 2019 at 9:14 PM Julien Grall wrote:
>
> Hi Oleksandr,
>
> Apologies for the late answer.
>
> On 16/10/2019 14:09, Oleksandr Grytsov wrote:
> > On Mon, Oct 14, 2019 at 12:28 PM Julien Grall wrote:
> > Thanks to point me out for this old thread. I completely forgot about it
> > (I
On 24.10.19 12:48, Ian Jackson wrote:
Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions -
trouble: broken/fail/pass"):
On 24.10.19 08:47, osstest service owner wrote:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs.
142750
I'm not sure
On Thu, Oct 24, 2019 at 01:13:13PM +0200, Jürgen Groß wrote:
> On 24.10.19 13:06, Wei Liu wrote:
> > Blktap2 is gone.
> >
> > Signed-off-by: Wei Liu
> > ---
> > CONTRIBUTING | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/CONTRIBUTING b/CONTRIBUTING
> > index
On 23.10.19 09:26, David Hildenbrand wrote:
On 22.10.19 23:54, Dan Williams wrote:
Hi David,
Thanks for tackling this!
Thanks for having a look :)
[...]
I am probably a little bit too careful (but I don't want to break things).
In most places (besides KVM and vfio that are nuts), the
Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
as well as what
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -59,7 +59,9 @@ appropriate branch.
Descriptions of section
Blktap2 is gone.
Signed-off-by: Wei Liu
---
CONTRIBUTING | 1 -
1 file changed, 1 deletion(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 47f53e9a49..4fff4fd9f6 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -13,7 +13,6 @@ Most of the Xen Project code is licensed under GPLv2, but a
number
The relationships between the headers are analogous to the various data
sections:
setup_header = .data
boot_params/setup_data = .bss
What is missing from the above list? That's right:
kernel_info = .rodata
We have been (ab)using .data for things that could go into .rodata or .bss for
a
Hi,
Due to very limited space in the setup_header this patch series introduces new
kernel_info struct which will be used to convey information from the kernel to
the bootloader. This way the boot protocol can be extended regardless of the
setup_header limitations. Additionally, the patch series
This field contains maximal allowed type for setup_data.
Now bump the setup_header version in arch/x86/boot/header.S.
Suggested-by: H. Peter Anvin (Intel)
Signed-off-by: Daniel Kiper
Reviewed-by: Konrad Rzeszutek Wilk
Reviewed-by: Ross Philipson
Reviewed-by: H. Peter Anvin (Intel)
---
This is the result of a recent discussion with Michal ([1], [2]). Right
now we set all pages PG_reserved when initializing hotplugged memmaps. This
includes ZONE_DEVICE memory. In case of system memory, PG_reserved is
cleared again when onlining the memory, in case of ZONE_DEVICE memory
never.
In
On 10/21/2019 7:43 AM, Wei Liu wrote:
> CAUTION: This email originated from outside the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
> On Mon, Oct 21, 2019 at 12:29:45PM +0100, George Dunlap wrote:
>> On 8/30/19 10:28
On 24.10.19 15:45, Jan Beulich wrote:
Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
as well as what
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
Signed-off-by: Jan Beulich
Release-acked-by: Juergen Gross
Juergen
Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable test] 143061:
regressions - trouble: broken/fail/pass"):
> 2019-10-23 23:16:59 Z power: failed to reboot (using SSH): status 65280 at
> Osstest/TestSupport.pm line 550.
...
> power: all approaches to rebooting italia1 failed!
>
> It seems
On 24.10.19 12:05, Jürgen Groß wrote:
On 24.10.19 10:57, Julien Grall wrote:
Hi Oleksandr,
On 10/16/19 11:08 AM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We always skip the IOMMU device when creating DT for hwdom if there is
an appropriate driver for it in Xen
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite maybe_pte_to_page() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Christophe
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite hash_page_do_lazy_icache() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc:
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
Rewrite __ioremap_check_ram() to make sure the function produces the
same result once we stop setting ZONE_DEVICE pages PG_reserved.
Cc: Dave Hansen
Cc: Andy Lutomirski
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc:
On 10/24/19 2:45 PM, Jan Beulich wrote:
> Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
> as well as what
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
>
> Signed-off-by: Jan Beulich
LGTM.
Acked-by: George Dunlap
>
> --- a/MAINTAINERS
>
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
flight 143085 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 143023
build-i386-libvirt
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 issue further.
Suggestions welcome.
The boot log
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we
The .file assembler directives generated by the compiler do not include
any path components (gcc) or just the ones specified on the command line
(clang, at least version 5), and hence multiple identically named source
files (in different directories) may produce identically named static
symbols
On 24.10.19 14:13, Ian Jackson wrote:
Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions -
trouble: broken/fail/pass"):
On 24.10.19 12:48, Ian Jackson wrote:
There is a known bug with two of our arm64 boxes, where they lose some
of the output during boot. This is
On Thu, Oct 24, 2019 at 01:11:22PM +, Xia, Hongyan wrote:
> It is certainly nice to have less users of the direct map. My non-EFI
> builds already work without the direct map now but once I start testing
> EFI, it is nice to have one less thing to worry about.
Note this is just yet another
On 24.10.19 12:41, Andrew Cooper wrote:
On 23/10/2019 17:48, Anthony PERARD wrote:
Current description of the file by `file`:
common/Kconfig: Non-ISO extended-ASCII text
Change that byte to an ascii quote so the file can become properly
encoded, and all ASCII.
Signed-off-by: Anthony
Jürgen Groß writes ("Re: [Xen-devel] [xen-unstable test] 143061: regressions -
trouble: broken/fail/pass"):
> On 24.10.19 08:47, osstest service owner wrote:
> > test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs.
> > 142750
>
> I'm not sure what has gone wrong here? The
The setup_data is a bit awkward to use for extremely large data objects,
both because the setup_data header has to be adjacent to the data object
and because it has a 32-bit length field. However, it is important that
intermediate stages of the boot process have a way to identify which
chunks of
Our onlining/offlining code is unnecessarily complicated. Only memory
blocks added during boot can have holes (a range that is not
IORESOURCE_SYSTEM_RAM). Hotplugged memory never has holes (e.g., see
add_memory_resource()). All boot memory is alread online.
Therefore, when we stop allowing to
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we
Right now, ZONE_DEVICE memory is always set PG_reserved. We want to
change that.
KVM has this weird use case that you can map anything from /dev/mem
into the guest. pfn_valid() is not a reliable check whether the memmap
was initialized and can be touched. pfn_to_online_page() makes sure
that we
Hi,
Jumping into the conversation.
On 24/10/2019 14:06, Jeff Kubascik wrote:
On 10/21/2019 7:43 AM, Wei Liu wrote:
CAUTION: This email originated from outside the organization. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On Mon, Oct
flight 143087 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143087/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-examine 8 reboot fail REGR. vs. 133580
flight 143111 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143111/
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
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl
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
flight 143118 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143118/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 broken
build-amd64
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)
> - Added review tags (thanks all for reviewing!)
>
>
Philippe,
Do you intend to submit v3? The
* 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
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
On Thu, 24 Oct 2019, Julien Grall wrote:
> (+Ian and Stefano)
>
> Hi,
>
> On 10/24/19 8:13 AM, Jürgen Groß wrote:
> > On 24.10.19 08:47, osstest service owner wrote:
> > > flight 143061 xen-unstable real [real]
> > > http://logs.test-lab.xenproject.org/osstest/logs/143061/
> > >
> > >
On Thu, Oct 24, 2019 at 03:45:20PM +0200, Jan Beulich wrote:
> Let's reflect reality, its use by add_maintainers.pl / get_maintainer.pl,
> as well as what
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches says.
>
> Signed-off-by: Jan Beulich
Acked-by: Wei Liu
flight 143094 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 broken
test-amd64-i386-xl-qemuu-ovmf-amd64 4
> 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
package, then I would be in favor of not doing so. IMO, a
> One standard practice when making a series is to try to avoid any
> regressions, including build regressions, in the middle of the series.
> This is particularly helpful to aid in bisections, but in this case it
> makes it easier to observe the action of the `gengotypes.py` script (and
> how
flight 143089 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143089/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-xsm broken
test-amd64-amd64-xl-credit1
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: Friday, October 25, 2019 1:28 AM
>
> * 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
flight 143097 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143097/
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 in 143009 REGR. vs.
139698
Tests which
branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf
flight 143127 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143127/
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
flight 143104 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/143104/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-boot fail REGR. vs. 142915
Just to make things annoying, I also get the following message in the
logs for correctly operating Linux PVH DomU's:
(XEN) AMD-Vi: IO_PAGE_FAULT: domain = 0, device id = 0x2600, fault
address = 0xfffdf800, flags = 0x8
As such, I think we're back to zero clues at the moment as to what
93 matches
Mail list logo
