On 04.08.2020 18:41, Nick Rosbrook wrote:
> On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
>>
>> On 04.08.2020 17:57, Wei Liu wrote:
>>> On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
On 04.08.2020 17:50, Wei Liu wrote:
> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beu
flight 152461 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152461/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail REGR. vs. 152418
Tests which did n
flight 152477 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152477/
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 152456 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152456/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 14 xen-boot/l1 fail REGR. vs. 151065
test-amd64-i386-x
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Without "dma-coherent" property present in virtio-mmio device node,
> guest assumes it is non-coherent and making non-cacheable accesses
> to the vring when the DMA API is used for vring operations.
> But virtio-mmio
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch makes possible to forward Guest MMIO accesses
> to a device emulator on Arm and enables that support for
> Arm64.
>
> Also update XSM code a bit to let DM op be used on Arm.
> New arch DM op will be intro
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch adds ability to the device emulator to notify otherend
> (some entity running in the guest) using a SPI and implements Arm
> specific bits for it. Proposed interface allows emulator to set
> the logical le
On Tue, 4 Aug 2020, Julien Grall wrote:
> On 04/08/2020 08:49, Paul Durrant wrote:
> > > diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
> > > index 931404c..b5fc066 100644
> > > --- a/tools/libxc/xc_dom_arm.c
> > > +++ b/tools/libxc/xc_dom_arm.c
> > > @@ -26,11 +26,19 @@
> > > #
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch adds basic support for configuring and assisting virtio-disk
> backend (emualator) which is intended to run out of Qemu and could be run
> in any domain.
>
> Xenstore was chosen as a communication interfa
On Mon, 3 Aug 2020, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> This patch makes possible to use device passthrough again.
>
> Signed-off-by: Oleksandr Tyshchenko
> ---
> tools/libxl/libxl_arm.c | 33 +++--
> 1 file changed, 23 insertions(+), 10 del
flight 152473 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152473/
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 152459 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152459/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf aa211bb6ef8edc70d2e6dfdab01a7d29e53f1ee2
baseline version:
ovmf bbb8a818583853ec4bb78
On Tue, 4 Aug 2020, Julien Grall wrote:
> On 04/08/2020 12:10, Oleksandr wrote:
> > On 04.08.20 10:45, Paul Durrant wrote:
> > > > +static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
> > > > +{
> > > > + return ioreq->state == STATE_IOREQ_READY &&
> > > > + !ioreq->dat
On Tue, Aug 4, 2020 at 12:02 PM Jan Beulich wrote:
>
> On 04.08.2020 17:57, Wei Liu wrote:
> > On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
> >> On 04.08.2020 17:50, Wei Liu wrote:
> >>> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
> On 04.08.2020 17:22, Nick R
This will make it easier to see perf changes etc.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 8
1 file changed, 8 insertions(+)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 28d576db..61572c2d 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -117,17 +11
On 04.08.2020 17:57, Wei Liu wrote:
> On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
>> On 04.08.2020 17:50, Wei Liu wrote:
>>> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
On 04.08.2020 17:22, Nick Rosbrook wrote:
> On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wr
On Tue, Aug 04, 2020 at 05:53:49PM +0200, Jan Beulich wrote:
> On 04.08.2020 17:50, Wei Liu wrote:
> > On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
> >> On 04.08.2020 17:22, Nick Rosbrook wrote:
> >>> On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
>
> On Mon, Aug 03, 2020
On 04.08.2020 17:50, Wei Liu wrote:
> On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
>> On 04.08.2020 17:22, Nick Rosbrook wrote:
>>> On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
> While this doesn't address
On Tue, 4 Aug 2020, Jürgen Groß wrote:
> On 11.07.20 00:34, Stefano Stabellini wrote:
> > Hi all,
> >
> > This series is a collection of fixes to get Linux running on the RPi4 as
> > dom0. Conceptually there are only two significant changes:
> >
> > - make sure not to call virt_to_page on vmalloc
On Tue, Aug 04, 2020 at 05:30:40PM +0200, Jan Beulich wrote:
> On 04.08.2020 17:22, Nick Rosbrook wrote:
> > On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
> >>
> >> On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
> >>> While this doesn't address the real problem I've run into (attemp
On 04.08.2020 16:46, Andrew Cooper wrote:
> On 04/08/2020 10:36, Jan Beulich wrote:
>> See the code comment that's being extended. Additionally a few more
>> zap_fpsel() invocations are needed - whenever we stored state after
>> there potentially having been a context switch behind our backs.
>>
>>
On 04.08.2020 15:52, Julien Grall wrote:
> On 04/08/2020 12:10, Oleksandr wrote:
>> On 04.08.20 10:45, Paul Durrant wrote:
+static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
+{
+ return ioreq->state == STATE_IOREQ_READY &&
+ !ioreq->data_is_ptr &&
On 04/08/2020 16:26, Jan Beulich wrote:
> Commit 5af040ef8b57 clearly should also have updated the comment, not
> just the #define-s.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 04.08.2020 17:22, Nick Rosbrook wrote:
> On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
>>
>> On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
>>> While this doesn't address the real problem I've run into (attempting to
>>> update r/o source files), not recursing into tools/golang/x
Commit 5af040ef8b57 clearly should also have updated the comment, not
just the #define-s.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-x86/config.h
+++ b/xen/include/asm-x86/config.h
@@ -144,18 +144,16 @@ extern unsigned char boot_edid_info[128]
* 0x82d0 - 0x82d03fff [
On Tue, Aug 4, 2020 at 10:17 AM Wei Liu wrote:
>
> On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
> > While this doesn't address the real problem I've run into (attempting to
> > update r/o source files), not recursing into tools/golang/xenlight/ is
> > enough to fix the build for me
On 03/08/2020 15:47, Jan Beulich wrote:
> ... and a few fixes resulting from this work. This completes what
> was started for legacy encoded GPR insns in a rush before 4.14.
>
> There's one thing I'm still planning on top of both this and the
> EVEX-disp8 checking: For all encodings we produce via
On 04/08/2020 10:36, Jan Beulich wrote:
> See the code comment that's being extended. Additionally a few more
> zap_fpsel() invocations are needed - whenever we stored state after
> there potentially having been a context switch behind our backs.
>
> Reported-by: Andrew Cooper
> Signed-off-by: Jan
On Tue, Jul 28, 2020 at 03:14:39PM +0100, Andrew Cooper wrote:
> On 28/07/2020 12:37, Andrew Cooper wrote:
> > With the Xen side of this interface fixed to return real sizes, userspace
> > needs to be able to make the query.
> >
> > Introduce xenforeignmemory_resource_size() for the purpose, bumpin
On Mon, Aug 03, 2020 at 10:06:32AM +0200, Jan Beulich wrote:
> While this doesn't address the real problem I've run into (attempting to
> update r/o source files), not recursing into tools/golang/xenlight/ is
> enough to fix the build for me for the moment. I don't currently see why
> 60db5da62ac0
From: Paul Durrant
It's confusing and not consistent with the terminology introduced with 'dfn_t'.
Just call them IOMMU page tables.
Also remove a pointless check of the 'acpi_drhd_units' list in
vtd_dump_page_table_level(). If the list is empty then IOMMU mappings would
not have been enabled fo
From: Paul Durrant
Sharing of HAP tables is now VT-d specific so the operation is never defined
for AMD IOMMU any more. There's also no need to pro-actively set vtd.pgd_maddr
when using shared EPT as it is straightforward to simply define a helper
function to return the appropriate value in the s
From: Paul Durrant
This removes the need for much shifting, masking and several magic numbers.
On the whole it makes the code quite a bit more readable.
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v4:
- New in v4
---
xen/drivers/passthrough/vtd/iommu.c | 8 ++--
xen/drivers/passthroug
From: Paul Durrant
As with a prior patch for context_entry, this removes the need for much
shifting, masking and several magic numbers.
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v4:
- New in v4
---
xen/drivers/passthrough/vtd/iommu.c | 9 ++---
xen/drivers/passthrough/vtd/iommu.h | 55
From: Paul Durrant
This makes the code a little easier to read and also makes it more consistent
with iremap_entry.
Also take the opportunity to tidy up the implementation of device_in_domain().
Signed-off-by: Paul Durrant
---
Cc: Kevin Tian
v4:
- New in v4
---
xen/drivers/passthrough/vtd/
Hi Paul,
On 04/08/2020 08:49, Paul Durrant wrote:
diff --git a/tools/libxc/xc_dom_arm.c b/tools/libxc/xc_dom_arm.c
index 931404c..b5fc066 100644
--- a/tools/libxc/xc_dom_arm.c
+++ b/tools/libxc/xc_dom_arm.c
@@ -26,11 +26,19 @@
#include "xg_private.h"
#include "xc_dom.h"
-#define NR_MAGIC_PA
Hi,
On 04/08/2020 12:10, Oleksandr wrote:
On 04.08.20 10:45, Paul Durrant wrote:
+static inline bool hvm_ioreq_needs_completion(const ioreq_t *ioreq)
+{
+ return ioreq->state == STATE_IOREQ_READY &&
+ !ioreq->data_is_ptr &&
+ (ioreq->type != IOREQ_TYPE_PIO || ioreq->dir !
From: Paul Durrant
The VT-d and AMD IOMMU implementations both use the general x86 IOMMU page
table allocator and ARM always shares page tables with CPU. Hence there is no
need to retain the free_page_table() method or the tasklet which invokes it.
Signed-off-by: Paul Durrant
Reviewed-by: Jan B
From: Paul Durrant
v4:
- Added three more patches to convert root_entry, context_entry and
dma_pte to bit fields.
Paul Durrant (14):
x86/iommu: re-arrange arch_iommu to separate common fields...
x86/iommu: add common page-table allocator
x86/iommu: convert VT-d code to use new page tab
From: Paul Durrant
This patch avoids calling iommu_iotlb_flush() for each individual GNTTABOP and
insteads calls iommu_iotlb_flush_all() at the end of the hypercall. This
should mean batched map/unmap operations perform better but may be slightly
detrimental to singleton performance.
Suggested-b
From: Paul Durrant
The 'legacy' functions do implicit flushing so amend the callers to do the
appropriate flushing.
Unfortunately, because of the structure of the P2M code, we cannot remove
the per-CPU 'iommu_dont_flush_iotlb' global and the optimization it
facilitates. It is now checked directl
From: Paul Durrant
... from those specific to VT-d or AMD IOMMU, and put the latter in a union.
There is no functional change in this patch, although the initialization of
the 'mapped_rmrrs' list occurs slightly later in iommu_domain_init() since
it is now done (correctly) in VT-d specific code
From: Paul Durrant
This patch converts the AMD IOMMU code to use the new page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
Signed-off-by: Paul Durr
From: Paul Durrant
This patch converts the VT-d code to use the new IOMMU page table allocator
function. This allows all the free-ing code to be removed (since it is now
handled by the general x86 code) which reduces TLB and cache thrashing as well
as shortening the code.
The scope of the mappin
From: Paul Durrant
At the moment iommu_map() and iommu_unmap() take a page order but not a
count, whereas iommu_iotlb_flush() takes a count but not a page order.
This patch simply makes them consistent with each other.
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Jan Be
From: Paul Durrant
This patch adds a full I/O TLB flush to the error paths of iommu_map() and
iommu_unmap().
Without this change callers need constructs such as:
rc = iommu_map/unmap(...)
err = iommu_flush(...)
if ( !rc )
rc = err;
With this change, it can be simplified to:
rc = iommu_map/u
From: Paul Durrant
Instead of having separate page table allocation functions in VT-d and AMD
IOMMU code, we could use a common allocation function in the general x86 code.
This patch adds a new allocation function, iommu_alloc_pgtable(), for this
purpose. The function adds the page table pages
> -Original Message-
> From: Ian Jackson
> Sent: 04 August 2020 12:35
> To: p...@xen.org
> Cc: xen-devel@lists.xenproject.org; 'Paul Durrant' ;
> 'Wei Liu'
> Subject: RE: [PATCH v2 4/4] tools/hotplug: modify set_mtu() to inform the
> frontend via xenstore
>
> Paul Durrant writes ("RE:
On 04/08/2020 11:13, Jan Beulich wrote:
> I have no explanation how I managed to overlook these while putting
> together what is now b6a907f8c83d ("x86emul: replace UB shifts").
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
I've just checked, and GCC 9.3.0 does convert this pattern bac
> -Original Message-
> From: Oleksandr
> Sent: 04 August 2020 12:51
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Oleksandr Tyshchenko' ; 'Jan Beulich'
> ; 'Andrew
> Cooper' ; 'Wei Liu' ; 'Roger Pau
> Monné' ;
> 'George Dunlap' ; 'Ian Jackson'
> ; 'Julien Grall'
> ; 'Stefano
flight 152432 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152432/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs.
152332
test-armhf-armhf
>
> are available in the Git repository at:
>
> https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git
> tags/pull-xen-20200804
>
> for you to fetch changes up to 8e0ef068942e4152f0d23e76ca1f5e35dc4456f7:
>
> accel/xen: Fix xen_enabled() behavior o
On 04.08.20 14:23, Paul Durrant wrote:
diff --git a/xen/include/xen/hvm/ioreq.h b/xen/include/xen/hvm/ioreq.h
new file mode 100644
index 000..40b7b5e
--- /dev/null
+++ b/xen/include/xen/hvm/ioreq.h
@@ -0,0 +1,89 @@
+/*
+ * hvm.h: Hardware virtual machine assist interface definitions.
+ *
Paul Durrant writes ("RE: [PATCH v2 4/4] tools/hotplug: modify set_mtu() to
inform the frontend via xenstore"):
> > -Original Message-
> > From: Ian Jackson
> > Sent: 04 August 2020 12:14
> > To: Paul Durrant
> > Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Wei
> > Liu
> > Subjec
> -Original Message-
> From: Oleksandr
> Sent: 04 August 2020 12:10
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: 'Oleksandr Tyshchenko' ; 'Jan Beulich'
> ; 'Andrew
> Cooper' ; 'Wei Liu' ; 'Roger Pau
> Monné' ;
> 'George Dunlap' ; 'Ian Jackson'
> ; 'Julien Grall'
> ; 'Stefano
> -Original Message-
> From: Ian Jackson
> Sent: 04 August 2020 12:14
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Paul Durrant ; Wei
> Liu
> Subject: Re: [PATCH v2 4/4] tools/hotplug: modify set_mtu() to inform the
> frontend via xenstore
>
> Paul Durrant writes ("[PATCH
Paul Durrant writes ("[PATCH v2 4/4] tools/hotplug: modify set_mtu() to inform
the frontend via xenstore"):
> From: Paul Durrant
>
> set_mtu() currently sets the backend vif MTU but does not inform the frontend
> what it is. This patch adds code to write the MTU into a xenstore node. See
> netif
Paul Durrant writes ("[PATCH v2 3/4] public/io/netif: specify MTU override
node"):
> From: Paul Durrant
>
> There is currently no documentation to state what MTU a frontend should
> adertise to its network stack. It has however long been assumed that the
> default value of 1500 is correct.
>
>
On 04.08.20 10:45, Paul Durrant wrote:
Hi Paul
-Original Message-
From: Oleksandr Tyshchenko
Sent: 03 August 2020 19:21
To: xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko ; Jan Beulich
; Andrew
Cooper ; Wei Liu ; Roger Pau Monné
;
George Dunlap ; Ian Jackson
; Julien Gral
Paul Durrant writes ("[PATCH v2 2/4] tools/hotplug: combine add/online and
remove/offline in vif-bridge..."):
> From: Paul Durrant
>
> ... as they are in vif-route.
>
> The script is invoked with online/offline for vifs and add/remove for taps.
> The operations that are necessary, however, are
Paul Durrant writes ("[PATCH v2 1/4] tools/hotplug: add remove_from_bridge()
and improve debug output"):
> From: Paul Durrant
>
> This patch adds a remove_from_bridge() function into xen-network-common.sh
> to partner with the existing add_to_bridge() function. The code in
> add_to_bridge() is a
flight 152454 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152454/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
I have no explanation how I managed to overlook these while putting
together what is now b6a907f8c83d ("x86emul: replace UB shifts").
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -9735,7 +9735,7 @@ x86_emulate(
See the code comment that's being extended. Additionally a few more
zap_fpsel() invocations are needed - whenever we stored state after
there potentially having been a context switch behind our backs.
Reported-by: Andrew Cooper
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/test_x86_
From: Philippe Mathieu-Daudé
CONFIG_XEN is generated by configure and stored in "config-target.h",
which is (obviously) only include for target-specific objects.
This is a problem for target-agnostic objects as CONFIG_XEN is never
defined and xen_enabled() is always inlined as 'false'.
Fix by fo
erard/qemu-dm.git
tags/pull-xen-20200804
for you to fetch changes up to 8e0ef068942e4152f0d23e76ca1f5e35dc4456f7:
accel/xen: Fix xen_enabled() behavior on target-agnostic objects (2020-08-04
10:21:35 +0100)
xen patc
On Tue, Aug 04, 2020 at 09:49:30AM +0200, Philippe Mathieu-Daudé wrote:
> CONFIG_XEN is generated by configure and stored in "config-target.h",
> which is (obviously) only include for target-specific objects.
> This is a problem for target-agnostic objects as CONFIG_XEN is never
> defined and xen_e
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 04 August 2020 09:35
> To: p...@xen.org; qemu-de...@nongnu.org
> Cc: 'Peter Maydell' ; 'Anthony Perard'
> ; 'Paolo
> Bonzini' ; 'Stefano Stabellini'
> ; xen-
> de...@lists.xenproject.org; 'Paul Durrant'
> Subject: Re: [PATCH-fo
Hi Paul,
On 8/4/20 9:57 AM, Paul Durrant wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé
>> Sent: 04 August 2020 08:50
>> To: qemu-de...@nongnu.org
>> Cc: Peter Maydell ; Anthony Perard
>> ; Paolo
>> Bonzini ; Stefano Stabellini ;
>> xen-
>> de...@lists.xenproject.org; Paul
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 04 August 2020 08:50
> To: qemu-de...@nongnu.org
> Cc: Peter Maydell ; Anthony Perard
> ; Paolo
> Bonzini ; Stefano Stabellini ;
> xen-
> de...@lists.xenproject.org; Paul Durrant ; Philippe
> Mathieu-Daudé ;
> Paul Durrant
> S
CONFIG_XEN is generated by configure and stored in "config-target.h",
which is (obviously) only include for target-specific objects.
This is a problem for target-agnostic objects as CONFIG_XEN is never
defined and xen_enabled() is always inlined as 'false'.
Fix by following the KVM schema, definin
Since v1: Fix build error reported by Peter:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg727251.html
Now following KVM implementation closely.
Philippe Mathieu-Daudé (1):
accel/xen: Fix xen_enabled() behavior on target-agnostic objects
include/sysemu/xen.h | 18 ++
> -Original Message-
> From: Xen-devel On Behalf Of
> Oleksandr Tyshchenko
> Sent: 03 August 2020 19:21
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ;
> Andrew Cooper ; Ian Jackson
> ; George Dunlap
> ; Oleksandr Tyshchenko
> ; Julien Grall
>
flight 152418 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152418/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail in
152389 pass in 152418
test-armhf-ar
> -Original Message-
> From: Oleksandr Tyshchenko
> Sent: 03 August 2020 19:21
> To: xen-devel@lists.xenproject.org
> Cc: Oleksandr Tyshchenko ; Jan Beulich
> ; Andrew
> Cooper ; Wei Liu ; Roger Pau Monné
> ;
> George Dunlap ; Ian Jackson
> ; Julien Grall
> ; Stefano Stabellini ; Paul D
On 03.08.2020 18:40, Andrew Cooper wrote:
> On 03/08/2020 15:47, Jan Beulich wrote:
>> ... and a few fixes resulting from this work. This completes what
>> was started for legacy encoded GPR insns in a rush before 4.14.
>>
>> There's one thing I'm still planning on top of both this and the
>> EVEX-
flight 152422 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152422/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bbb8a818583853ec4bb7804e78ed1d304b709d33
baseline version:
ovmf e557442e3f7ec7bee2d88
77 matches
Mail list logo
