On 09.10.2019 20:56, Paul Durrant wrote:
> On Wed, 9 Oct 2019 at 19:21, Andrew Cooper wrote:
>>
>> c/s c0902a9a143a refactored hvm_enable() a little, but dropped the logic
>> which
>> cleared hap_supported in the case that the user had asked for it off.
>>
>> This results in Xen booting up, claim
On 09.10.2019 22:40, Igor Druzhinin wrote:
> Signed-off-by: Igor Druzhinin
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On 09.10.2019 22:40, Igor Druzhinin wrote:
> --- a/xen/arch/x86/efi/efi-boot.h
> +++ b/xen/arch/x86/efi/efi-boot.h
> @@ -528,9 +528,15 @@ static void __init
> efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
> bpp = set_color(mode_info->PixelInformation.BlueMask, bpp,
>
On 09.10.2019 22:40, Igor Druzhinin wrote:
> If a bootloader is using native driver instead of EFI GOP it might
> reset graphics mode to be different from what has been originally set
> by firmware. While booting through MB2 Xen either need to parse video
> setting passed by MB2 and use them instea
On 09.10.19 22:40, Igor Druzhinin wrote:
Igor Druzhinin (3):
efi/boot: add missing pointer dereference in set_color
x86/efi: properly handle 0 in pixel reserved bitmask
efi/boot: make sure graphics mode is set while booting through MB2
xen/arch/x86/efi/efi-boot.h | 12 +---
x
flight 142487 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142487/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-examine 8 reboot fail like 142431
test-amd64-i386-libvirt-pair 10 xen-bo
xen_auto_xlat_grant_frames.vaddr is definitely NULL in this case.
So the address printing is unnecessary.
Signed-off-by: Fuqian Huang
---
drivers/xen/grant-table.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 7e
On 09.10.19 11:49, Jan Beulich wrote:
On 09.10.2019 10:33, Roger Pau Monne wrote:
The current implementation of host_maskall makes it sticky across
assign and deassign calls, which means that once a guest forces Xen to
set host_maskall the maskall bit is not going to be cleared until a
call to P
On 10.10.19 10:32, Fuqian Huang wrote:
xen_auto_xlat_grant_frames.vaddr is definitely NULL in this case.
So the address printing is unnecessary.
Signed-off-by: Fuqian Huang
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@
flight 142502 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142502/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
test-amd64-amd
Hi Stefano,
On 10/10/19 1:42 AM, Stefano Stabellini wrote:
make_cpus_node() is using a static buffer to generate the FDT node name.
While mpdir_aff is a 64-bit integer, we only ever use the bits [23:0] as
only AFF{0, 1, 2} are supported for now.
To avoid any potential issues in the future, chec
On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote:
> Hi,
>
> Questions and comments below...
> Thanks.
>
> On 10/9/19 3:53 AM, Daniel Kiper wrote:
>
> > Suggested-by: H. Peter Anvin
> > Signed-off-by: Daniel Kiper
> > Reviewed-by: Konrad Rzeszutek Wilk
> > Reviewed-by: Ross Philipson
On Wed, Oct 09, 2019 at 07:13:45PM +0800, Chao Gao wrote:
> On Wed, Oct 09, 2019 at 10:33:21AM +0200, Roger Pau Monne wrote:
> >The current implementation of host_maskall makes it sticky across
> >assign and deassign calls, which means that once a guest forces Xen to
> >set host_maskall the maskall
Hello,
The following series contain two 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 think it would be nice to have those in
4.13.
Than
On Intel hardware there's currently no translation of already enabled
IO-APIC pins when interrupt remapping is enabled on the IOMMU, hence
introduce a logic similar to the one used in x2apic_bsp_setup in order
to save and mask all IO-APIC pins, and then translate and restore them
after interrupt re
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
hardware that has unmasked IO-APIC pins.
Reported-by: Andrew C
flight 142542 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142542/
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 Thu, Oct 10, 2019 at 01:03:38PM +0200, 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
On Intel hardware there's currently no translation of already enabled
IO-APIC pins when interrupt remapping is enabled on the IOMMU, hence
introduce a logic similar to the one used in x2apic_bsp_setup in order
to save and mask all IO-APIC pins, and then translate and restore them
after interrupt re
Hello,
The following series contain two 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 think it would be nice to have those in
4.13.
The
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
hardware that has unmasked IO-APIC pins.
Reported-by: Andrew C
On 10.10.2019 13:33, Roger Pau Monne wrote:
> When interrupt remapping is enabled as part of enabling x2APIC the
Perhaps "unmasked" instead of "the"?
> IO-APIC entries also need to be translated to the new format and added
> to the interrupt remapping table.
>
> This prevents IOMMU interrupt rem
On 10.10.2019 13:33, Roger Pau Monne wrote:
> On Intel hardware there's currently no translation of already enabled
> IO-APIC pins when interrupt remapping is enabled on the IOMMU, hence
> introduce a logic similar to the one used in x2apic_bsp_setup in order
> to save and mask all IO-APIC pins, an
On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
> On 10.10.2019 13:33, Roger Pau Monne wrote:
> > When interrupt remapping is enabled as part of enabling x2APIC the
>
> Perhaps "unmasked" instead of "the"?
>
> > IO-APIC entries also need to be translated to the new format and added
>
On 10/10/2019 08:13, Jan Beulich wrote:
> On 09.10.2019 22:40, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/efi/efi-boot.h
>> +++ b/xen/arch/x86/efi/efi-boot.h
>> @@ -528,9 +528,15 @@ static void __init
>> efi_arch_video_init(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop,
>> bpp = set_color(mode_info-
Hi all,
following on from a discussion on IRC and on various other places, I think we
need to try and rationalize how we handle documentation.
What we have now and what we may get in future
* http://xenbits.xen.org/docs/unstable/ (GPL-2)
* http://xenbits.xen.org/docs/sphinx-unstable-staging/ (CC
On 10.10.2019 14:13, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
>> On 10.10.2019 13:33, Roger Pau Monne wrote:
>>> When interrupt remapping is enabled as part of enabling x2APIC the
>>
>> Perhaps "unmasked" instead of "the"?
>>
>>> IO-APIC entries also ne
On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
> On 10.10.2019 14:13, Roger Pau Monné wrote:
> > On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 13:33, Roger Pau Monne wrote:
> >>> When interrupt remapping is enabled as part of enabling x2APIC the
> >>
On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
> On 10.10.2019 14:13, Roger Pau Monné wrote:
> > On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 13:33, Roger Pau Monne wrote:
> >>> When interrupt remapping is enabled as part of enabling x2APIC the
> >>
On 10.10.2019 15:12, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
>> On 10.10.2019 14:13, Roger Pau Monné wrote:
>>> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
On 10.10.2019 13:33, Roger Pau Monne wrote:
> When interrupt remappin
From: Oleksandr Andrushchenko
During domain reboot its configuration is partially reused
to re-create a new domain, but iomem's GFN field for the
iomem is only restored for those memory ranges, which are
configured in form of [IOMEM_START,NUM_PAGES[@GFN], but not for
those in form of [IOMEM_START
On 10.10.2019 15:29, Roger Pau Monné wrote:
> On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
>> On 10.10.2019 14:13, Roger Pau Monné wrote:
>>> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
On 10.10.2019 13:33, Roger Pau Monne wrote:
> When interrupt remappin
On 10/9/19 7:42 AM, Oleksandr Andrushchenko wrote:
> On 10/8/19 10:41 PM, Rob Herring wrote:
>> As the removed comments say, these aren't DT based devices.
>> of_dma_configure() is going to stop allowing a NULL DT node and calling
>> it will no longer work.
>>
>> The comment is also now out of date
From: Oleksandr Grytsov
Some platforms need more compatible property values in device
tree root node in addition to "xen,xenvm-%d.%d" and "xen,xenvm"
values that are given by Xen by default.
Specify in domain configuration file which values should be added
by providing "dtb_compatible" list of st
flight 142556 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142556/
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
Hi,
Hmm, it looks like I forgot this patch before the freeze. Juergen, are you happy
with this to go in Xen 4.13?
Cheers,
On 15/08/2019 18:29, Julien Grall wrote:
dtb_load() can be called by other domain than dom0. To avoid confusion
in the log, print the correct domain.
Signed-off-by: Juli
On 10/10/19 2:43 AM, Daniel Kiper wrote:
> On Wed, Oct 09, 2019 at 05:43:31PM -0700, Randy Dunlap wrote:
>> Hi,
>>
>> Questions and comments below...
>> Thanks.
>>
>> On 10/9/19 3:53 AM, Daniel Kiper wrote:
>>
>>> Suggested-by: H. Peter Anvin
>>> Signed-off-by: Daniel Kiper
>>> Reviewed-by: Konra
Hi,
Juergen, would you be happy if this patch is committed for Xen 4.13?
Cheers,
On 02/10/2019 23:27, Stefano Stabellini wrote:
On Tue, 13 Aug 2019, Julien Grall wrote:
The binding for the dom0less module does not match Xen implementation.
Any module should contain the compatible "multiboot,m
On 10.10.19 16:45, Julien Grall wrote:
Hi,
Juergen, would you be happy if this patch is committed for Xen 4.13?
Yes, you can add my:
Release-acked-by: Juergen Gross
Juergen
Cheers,
On 02/10/2019 23:27, Stefano Stabellini wrote:
On Tue, 13 Aug 2019, Julien Grall wrote:
The binding for
On 09/10/2019 12:57, Artem Mygaiev wrote:
Hi Julien
Hi,
On Fri, 2019-10-04 at 17:42 +0100, Julien Grall wrote:
flask_assign_{, dt}device() may be used to check whether you can test
if
a device is assigned. In this case, the domain will be NULL.
However, flask_iommu_resource_use_perm() wil
+Juergen
On 03/10/2019 02:22, Stefano Stabellini wrote:
On Sat, 21 Sep 2019, Julien Grall wrote:
At the moment, boot pagetables are only cleared once at boot. This means
when booting CPU2 (and onwards) then boot pagetables will not be
cleared.
To keep the interface exactly the same for all sec
Hi,
On Thu, 2019-10-10 at 15:48 +0100, Julien Grall wrote:
>
> On 09/10/2019 12:57, Artem Mygaiev wrote:
> > Hi Julien
>
> Hi,
>
> > On Fri, 2019-10-04 at 17:42 +0100, Julien Grall wrote:
> > > flask_assign_{, dt}device() may be used to check whether you can test
> > > if
> > > a device is assi
We are going to change the libxl API in a moment and this change will
make it simpler.
Signed-off-by: Ian Jackson
Reviewed-by: Anthony PERARD
---
tools/xl/xl_vmcontrol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/xl/xl_vmcontrol.c b/tools/xl/xl_vmcontrol.c
i
No functional change. This will let us refer to it in code we are
about to add to this function.
Signed-off-by: Ian Jackson
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create.c | 17 -
tools/libxl/libxl_dm.c | 7 ++-
tools/libxl/libxl_inte
This should calculate the extra memory needed for shadow and iommu,
the defaults for which depend on values in c_info. So we need this to
have the complete domain config available.
And the defaults should actually be updated and stored. So make it
non-const.
We provide the usual kind of compati
Defaulting is supposed to be done by libxl. So these calculations
should be here in libxl. libxl__domain_config_setdefault has all the
necessary information including the values of max_memkb and max_vcpus.
The overall functional effect depends on the caller:
For xl, no change. The code moves f
According to git log -G:
0x040700 was introduced in 304400459ef0 (aka 4.7.0-rc1~481)
"tools/libxl: rename remus device to checkpoint device"
0x040800 was introduced in 57f8b13c7240 (aka 4.8.0-rc1~437)
"libxl: memory size in kb requires 64 bit variable"
It is surprising that no-one noticed th
Break out this into a new function. We are going to want to call it
from a new call site.
Unfortunately not all of the defaults can be moved into the new
function without changing the order in which things are done. That
does not seem wise at this stage of the release. The effect is that
additi
No functional change. This will let us make it into a pointer without
textual change other than to the definition.
While we are here, fix some style errors (missing { }).
Signed-off-by: Ian Jackson
---
v2: New patch in this version of the series.
---
tools/libxl/libxl_create.c | 16 ---
These are now redundant because shadow_memkb and iommu_memkb are now
defaulted automatically by libxl_domain_need_memory and
libxl_domain_create etc. Callers should not now call these; instead,
they should just let libxl take care of it.
libxl_get_required_shadow_memory was introduced in f89f5558
This is v2 of my series to sort out the shadow/iommu memory and pci
passthrough situation. I think this series will mask the bug which is
currently blocking staging propagating to master.
I had some difficulty testing this, as the test box under my desk
doesn't do PT and I didn't want to wait to
LIBXL_PASSTHROUGH_UNKNOWN (aka "ENABLED" in an earlier uncommitted
version of this code) is doing double duty. We actually need all of
the following to be specificable:
* default ("unknown"): enable PT iff we have devices to
pass through specified in the initial config file.
* "enabled" (a
Hi,
On 10/8/19 4:25 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to hwdom even if it is not used by Xen.
Therefore exposing the properties that describe relationship between
master devices and IOMMUs does not make any sense.
According to the:
1.
Ian Jackson writes ("[XEN PATCH for-4.13 v2 0/9] libxl memkb & pt defaulting"):
> This is v2 of my series to sort out the shadow/iommu memory and pci
> passthrough situation. I think this series will mask the bug which is
> currently blocking staging propagating to master.
I have pushed this to:
On Thu, Oct 10, 2019 at 03:46:45PM +0200, Jan Beulich wrote:
> On 10.10.2019 15:12, Roger Pau Monné wrote:
> > On Thu, Oct 10, 2019 at 02:55:02PM +0200, Jan Beulich wrote:
> >> On 10.10.2019 14:13, Roger Pau Monné wrote:
> >>> On Thu, Oct 10, 2019 at 01:54:06PM +0200, Jan Beulich wrote:
> On
On 10.10.19 18:18, Julien Grall wrote:
Hi,
Hi Julien
On 10/8/19 4:25 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to hwdom even if it is not used by
Xen.
Therefore exposing the properties that describe relationship between
master devices
On Thu, Oct 10, 2019 at 9:00 AM Boris Ostrovsky
wrote:
>
> On 10/9/19 7:42 AM, Oleksandr Andrushchenko wrote:
> > On 10/8/19 10:41 PM, Rob Herring wrote:
> >> As the removed comments say, these aren't DT based devices.
> >> of_dma_configure() is going to stop allowing a NULL DT node and calling
>
Hi,
On 10/10/19 4:27 PM, Oleksandr wrote:
On 10.10.19 18:18, Julien Grall wrote:
Hi,
Hi Julien
On 10/8/19 4:25 PM, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
We don't passthrough IOMMU device to hwdom even if it is not used by
Xen.
Therefore exposing the properties that
Hi Brian,
Thank you for the patch.
On 10/9/19 8:47 PM, Brian Woods wrote:
It's possible for a misconfigured device tree to cause Xen to crash when
there are overlapping addresses in the memory modules. Add a warning
when printing the addresses to let the user know there's a possible
issue when
On 10.10.19 18:32, Julien Grall wrote:
Hi,
Hi
[1]
https://lists.xenproject.org/archives/html/xen-devel/2019-10/msg00104.html
---
xen/arch/arm/domain_build.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/
On 10/10/19 11:32 AM, Rob Herring wrote:
> On Thu, Oct 10, 2019 at 9:00 AM Boris Ostrovsky
> wrote:
>> On 10/9/19 7:42 AM, Oleksandr Andrushchenko wrote:
>>> On 10/8/19 10:41 PM, Rob Herring wrote:
As the removed comments say, these aren't DT based devices.
of_dma_configure() is going to
On 01/10/2019 12:35, Anthony PERARD wrote:
> Rewrite of the commit message:
>
> Before the problematic commit, libxl used to ignore error when
> destroying (force == true) a passthrough device, especially error that
> happens when dealing with the DM.
>
> Since fae4880c45fe, if the DM failed to d
Hi Stefano,
On 08/10/2019 23:24, Stefano Stabellini wrote:
On Tue, 8 Oct 2019, Julien Grall wrote:
On 10/8/19 1:18 AM, Stefano Stabellini wrote:
On Mon, 7 Oct 2019, Julien Grall wrote:
Hi,
On 03/10/2019 02:02, Stefano Stabellini wrote:
On Fri, 20 Sep 2019, Julien Grall wrote:
That's not co
On 10/10/2019 13:34, Lars Kurth wrote:
> Hi all,
>
> following on from a discussion on IRC and on various other places, I think we
> need to try and rationalize how we handle documentation.
>
> What we have now and what we may get in future
> * http://xenbits.xen.org/docs/unstable/ (GPL-2)
> * htt
The current implementations of xen_{map, unmap}_table() expect
{map, unmap}_domain_page() to be usable. Those helpers are used to
map/unmap page tables while update Xen page-tables.
Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT update in
{set, clear}_fixmap()", setup_fixmap() will m
On 10/10/2019, 18:05, "Andrew Cooper" wrote:
On 10/10/2019 13:34, Lars Kurth wrote:
> Hi all,
>
> following on from a discussion on IRC and on various other places, I
think we need to try and rationalize how we handle documentation.
>
> What we have now and what we may
flight 142518 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142518/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 22 guest-migrate/src_host/dst_host fail REGR.
vs. 141822
test-amd6
flight 142557 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142557/
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
flight 142533 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142533/
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 142535 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142535/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-qcow2 16 guest-start.2 fail REGR. vs. 142252
Tests which did not suc
flight 142521 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142521/
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 142565 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142565/
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 Thu, 10 Oct 2019, Julien Grall wrote:
> The current implementations of xen_{map, unmap}_table() expect
> {map, unmap}_domain_page() to be usable. Those helpers are used to
> map/unmap page tables while update Xen page-tables.
>
> Since commit 022387ee1a "xen/arm: mm: Don't open-code Xen PT upda
On Thu, 10 Oct 2019, Julien Grall wrote:
> On 08/10/2019 23:24, Stefano Stabellini wrote:
> > On Tue, 8 Oct 2019, Julien Grall wrote:
> > > On 10/8/19 1:18 AM, Stefano Stabellini wrote:
> > > > On Mon, 7 Oct 2019, Julien Grall wrote:
> > > > > Hi,
> > > > >
> > > > > On 03/10/2019 02:02, Stefano S
On Thu, 10 Oct 2019, Lars Kurth wrote:
> * Would we ever include API docs generated from GPLv2 code? E.g. for safety
> use-cases?
> @Stefano, @Artem: I guess this one is for you.
> I suppose if we would have a similar issue for a safety manual
> I am also assuming we would want to use sphinx docs
On Tue, 8 Oct 2019, Rob Herring wrote:
> As the removed comments say, these aren't DT based devices.
> of_dma_configure() is going to stop allowing a NULL DT node and calling
> it will no longer work.
>
> The comment is also now out of date as of commit 9ab91e7c5c51 ("arm64:
> default to the direc
Committers,
Please don't push any new patch to staging because we want to have a
push to master for 4.13-RC1.
Another email will be sent once the moratorium is lifted.
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.x
flight 142548 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142548/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
140282
test-amd64-amd
flight 142539 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/142539/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 7 xen-boot fail REGR. vs. 133580
test-amd64-i386-xl-
79 matches
Mail list logo
