flight 148773 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148773/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-build fail in 148690 REGR. vs. 148666
Tests which are failing
flight 148771 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148771/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
146121
Tests which a
In the unlikley case that patch application completes, but the resutling
revision isn't expected, sig->rev doesn't get updated to match reality.
It will get adjusted the next time collect_cpu_info() gets called, but in the
meantime Xen might operate on a state value. Nothing good will come of thi
This is clearly a typo.
Fixes: 9da23943ccd "microcode: introduce a global cache of ucode patch"
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x8
There is only a single user of raw_smp_processor_id() left in the tree (and it
is unconditionally compiled out). Drop the alias from all architectures.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babc
Use it to simplify the x86 microcode logic, taking the opportunity to drop the
-ENOMEM printks.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/cpu/microcode/amd.c | 9 ++---
xen/arch/x86/cpu/microcode/intel.c | 7 ++-
xen/include/
Two minor bugfixes, and two minor cleanups with minor benefits to other code
as well.
There is no dependency on the remaining pieces of the Part 1 series.
Andrew Cooper (4):
x86/ucode/amd: Fix assertion in compare_patch()
x86/ucode: Fix error paths in apply_microcode()
xen: Drop raw_smp_pro
flight 148786 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148786/
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 148770 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148770/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
133580
Regressions
The current usage of nvmx_update_apicv is not clear: it is deeply
intertwined with the Ack interrupt on exit VMEXIT control.
The code in nvmx_update_apicv should update the SVI (in service interrupt)
field of the guest interrupt status only when the Ack interrupt on
exit is set, as it is used to r
Hello,
This is a fixup of a wrong previous bugfix. It has been tested on the
debina0 osstest host and it fixes the interrupt injection issues seen
there when running the nested HVM tests. I mention this explicitly
because albeit I don't expect it I don't discard it might cause issues
on other boxe
Current code in nvmx_update_apicv set the guest interrupt status field
but doesn't update the exit bitmap, which can cause issues of lost
interrupts on the L1 hypervisor if vmx_intr_assist gets
short-circuited by nvmx_intr_intercept returning true.
Extract the code to update the exit bitmap from v
This reverts commit f96e1469ad06b61796c60193daaeb9f8a96d7458.
The commit is wrong, as the whole point of nvmx_update_apicv is to
update the guest interrupt status field when the Ack on exit VMEXIT
control feature is enabled.
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/hvm/vmx/vvmx.c | 7 +--
Hello,
This is the remaining of the assisted TLB flush series. This last set of
patches enable the usage of the Xen assisted flush when running nested
on Xen.
Thanks, Roger.
Roger Pau Monne (3):
x86/tlb: introduce a flush HVM ASIDs flag
x86/tlb: allow disabling the TLB clock
x86/tlb: use X
Introduce a specific flag to request a HVM guest linear TLB flush,
which is an ASID/VPID tickle that forces a guest linear to guest
physical TLB flush for all HVM guests.
This was previously unconditionally done in each pre_flush call, but
that's not required: HVM guests not using shadow don't req
The TLB clock is helpful when running Xen on bare metal because when
doing a TLB flush each CPU is IPI'ed and can keep a timestamp of the
last flush.
This is not the case however when Xen is running virtualized, and the
underlying hypervisor provides mechanism to assist in performing TLB
flushes:
Use Xen's L0 HVMOP_flush_tlbs hypercall in order to perform flushes.
This greatly increases the performance of TLB flushes when running
with a high amount of vCPUs as a Xen guest, and is specially important
when running in shim mode.
The following figures are from a PV guest running `make -j32 xen
On 20/03/2020 16:16, Jan Beulich wrote:
> On 20.03.2020 17:10, Andrew Cooper wrote:
>> On 20/03/2020 15:15, Jan Beulich wrote:
>>> On 20.03.2020 15:50, Andrew Cooper wrote:
On 20/03/2020 13:51, Jan Beulich wrote:
> On 19.03.2020 16:26, Andrew Cooper wrote:
>> The data layout for struct
Vladimir Sementsov-Ogievskiy writes:
> 20.03.2020 16:58, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
[...]
>>> I will not be surprised, if we missed some more interesting cases :)
>>> But we should proceed. What is our plan? Will you queue v10 for 5.1?
>>
>> v10's PATCH 1+2
Vladimir Sementsov-Ogievskiy writes:
> Script adds ERRP_AUTO_PROPAGATE macro invocation where appropriate and
> does corresponding changes in code (look for details in
> include/qapi/error.h)
>
> Usage example:
> spatch --sp-file scripts/coccinelle/auto-propagated-errp.cocci \
> --macro-file scr
On 20.03.2020 17:10, Andrew Cooper wrote:
> On 20/03/2020 15:15, Jan Beulich wrote:
>> On 20.03.2020 15:50, Andrew Cooper wrote:
>>> On 20/03/2020 13:51, Jan Beulich wrote:
On 19.03.2020 16:26, Andrew Cooper wrote:
> The data layout for struct microcode_patch is extremely poor, and
> u
The run* targets can be used to test whatever the tool chain is capable
of building, as long as at least the main harness source file builds.
Don't probe the tools chain, in particular to avoid issuing the warning,
in this case. While looking into this I also noticed the wording of the
respective c
On 20/03/2020 15:15, Jan Beulich wrote:
> On 20.03.2020 15:50, Andrew Cooper wrote:
>> On 20/03/2020 13:51, Jan Beulich wrote:
>>> On 19.03.2020 16:26, Andrew Cooper wrote:
The data layout for struct microcode_patch is extremely poor, and
unnecessarily complicated. Almost all of it is op
On 18.03.2020 18:32, Paul Durrant wrote:
> From: Paul Durrant
>
> ... to cover xenheap and PGC_extra pages.
>
> PGC_extra pages are intended to hold data structures that are associated
> with a domain and may be mapped by that domain. They should not be treated
> as 'normal' guest pages (i.e. RA
On 18.03.2020 12:46, David Woodhouse wrote:
> From: David Woodhouse
>
> The creation of dom0 can be relatively self-contained. Shift it into
> a separate function and simplify __start_xen() a little bit.
>
> This is a cleanup in its own right, but will be even more desireable
> when live update
On 20.03.20 15:58, David Woodhouse wrote:
On Fri, 2020-03-20 at 14:12 +, Ian Jackson wrote:
Jürgen Groß writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort
xenstore-ls if a node disappears while iterating"):
No, you just don't care for the transaction to succeed or fail (IMO
flight 148763 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148763/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 14486
On Fri, 2020-03-20 at 13:33 +, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel On Behalf Of David
> > Woodhouse
> > Sent: 19 March 2020 21:22
> > To: xen-devel@lists.xenproject.org
> > Cc: Stefano Stabellini ; Julien Grall
> > ; Wei Liu ;
> > Andrew Cooper ; Ian Jackso
On 20.03.2020 15:50, Andrew Cooper wrote:
> On 20/03/2020 13:51, Jan Beulich wrote:
>> On 19.03.2020 16:26, Andrew Cooper wrote:
>>> The data layout for struct microcode_patch is extremely poor, and
>>> unnecessarily complicated. Almost all of it is opaque to core.c, with the
>>> exception of free
On Fri, Mar 20, 2020 at 03:59:35PM +0100, Jan Beulich wrote:
> On 20.03.2020 15:49, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 02:27:36PM +, Julien Grall wrote:
> >>
> >>
> >> On 20/03/2020 14:22, Roger Pau Monné wrote:
> >>> static inline void filtered_flush_tlb_mask(uint32_t tlbflush_
On 20.03.2020 15:49, Roger Pau Monné wrote:
> On Fri, Mar 20, 2020 at 02:27:36PM +, Julien Grall wrote:
>>
>>
>> On 20/03/2020 14:22, Roger Pau Monné wrote:
>>> static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
>>> {
>>> cpumask_t mask;
>>>
>>> cpumask_copy(&mask
On Fri, 2020-03-20 at 14:12 +, Ian Jackson wrote:
> Jürgen Groß writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort
> xenstore-ls if a node disappears while iterating"):
> > No, you just don't care for the transaction to succeed or fail (IMO it
> > should never fail as you are re
On 20.03.2020 15:17, Julien Grall wrote:
> Hi,
>
> On 20/03/2020 13:19, Jan Beulich wrote:
>> On 20.03.2020 10:12, Julien Grall wrote:
>>> On 20/03/2020 09:01, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
> On 19.03.2020 20:07, Julien Grall wrote:
>>
On Fri, Mar 20, 2020 at 02:43:38PM +, Julien Grall wrote:
> Hi,
>
> On 20/03/2020 14:27, Julien Grall wrote:
> >
> >
> > On 20/03/2020 14:22, Roger Pau Monné wrote:
> > > static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
> > > {
> > > cpumask_t mask;
> > >
> > >
On 20/03/2020 13:51, Jan Beulich wrote:
> On 19.03.2020 16:26, Andrew Cooper wrote:
>> The data layout for struct microcode_patch is extremely poor, and
>> unnecessarily complicated. Almost all of it is opaque to core.c, with the
>> exception of free_patch().
>>
>> Move the responsibility for free
On Fri, Mar 20, 2020 at 02:27:36PM +, Julien Grall wrote:
>
>
> On 20/03/2020 14:22, Roger Pau Monné wrote:
> > static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
> > {
> > cpumask_t mask;
> >
> > cpumask_copy(&mask, &cpu_online_map);
> > tlbflush_filter(&
On 20.03.2020 15:27, Andrew Cooper wrote:
> On 20/03/2020 13:56, Jan Beulich wrote:
>> On 20.03.2020 14:40, Andrew Cooper wrote:
>>> On 20/03/2020 13:37, Jan Beulich wrote:
On 19.03.2020 16:26, Andrew Cooper wrote:
> Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use
Hi,
On 20/03/2020 14:27, Julien Grall wrote:
On 20/03/2020 14:22, Roger Pau Monné wrote:
static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
{
cpumask_t mask;
cpumask_copy(&mask, &cpu_online_map);
tlbflush_filter(&mask, tlbflush_timestamp);
if ( !cpuma
David Woodhouse writes ("Re: [Xen-devel] [PATCH 2/2] tools/xenstore: Accumulate
errors in xenstore-ls and exit appropriately"):
> It's patch 1 which I really care about; this part is just yak shaving
> at Ian's prompting.
Hi. Thanks for working on this cleanup.
I confess that while reviewing yo
20.03.2020 16:58, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
19.03.2020 13:45, Markus Armbruster wrote:
Vladimir Sementsov-Ogievskiy writes:
[...]
So, understanding that there no such cases in the whole tree, and even
if your patch works faster on the whole tree, I still
On 20/03/2020 13:56, Jan Beulich wrote:
> On 20.03.2020 14:40, Andrew Cooper wrote:
>> On 20/03/2020 13:37, Jan Beulich wrote:
>>> On 19.03.2020 16:26, Andrew Cooper wrote:
Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use a
switch statement in early_microcode_init(
On 20/03/2020 14:22, Roger Pau Monné wrote:
static inline void filtered_flush_tlb_mask(uint32_t tlbflush_timestamp)
{
cpumask_t mask;
cpumask_copy(&mask, &cpu_online_map);
tlbflush_filter(&mask, tlbflush_timestamp);
if ( !cpumask_empty(&mask) )
{
perfc_incr(ne
On Fri, Mar 20, 2020 at 02:16:47PM +0100, Jan Beulich wrote:
> On 20.03.2020 10:01, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
> >> On 19.03.2020 20:07, Julien Grall wrote:
> >>> On 19/03/2020 18:43, Roger Pau Monné wrote:
> On Thu, Mar 19, 2020 at
Hi,
On 20/03/2020 13:19, Jan Beulich wrote:
On 20.03.2020 10:12, Julien Grall wrote:
On 20/03/2020 09:01, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
On 19.03.2020 20:07, Julien Grall wrote:
On 19/03/2020 18:43, Roger Pau Monné wrote:
On Thu, Mar 19,
Jürgen Groß writes ("Re: [Xen-devel] [PATCH 1/2] tools/xenstore: Do not abort
xenstore-ls if a node disappears while iterating"):
> No, you just don't care for the transaction to succeed or fail (IMO it
> should never fail as you are reading only).
>
> So just wrap everything into a transaction.
On 20.03.20 15:11, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH 1/2] tools/xenstore: Do not abort xenstore-ls if a
node disappears while iterating"):
On 19.03.20 21:40, David Woodhouse wrote:
From: David Woodhouse
...
For the specific case of ENOENT it seems reasonable to declare that
Jürgen Groß writes ("Re: [PATCH 1/2] tools/xenstore: Do not abort xenstore-ls
if a node disappears while iterating"):
> On 19.03.20 21:40, David Woodhouse wrote:
> > From: David Woodhouse
...
> > For the specific case of ENOENT it seems reasonable to declare that,
> > but for the timing, we might
Vladimir Sementsov-Ogievskiy writes:
> 19.03.2020 13:45, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy writes:
[...]
>>> So, understanding that there no such cases in the whole tree, and even
>>> if your patch works faster on the whole tree, I still don't want to
>>> drop inheritance,
On 20.03.2020 14:40, Andrew Cooper wrote:
> On 20/03/2020 13:37, Jan Beulich wrote:
>> On 19.03.2020 16:26, Andrew Cooper wrote:
>>> Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use a
>>> switch statement in early_microcode_init() rather than probing each vendor
>>> in
>>>
On 20.03.2020 14:33, Paul Durrant wrote:
>> -Original Message-
>> From: Xen-devel On Behalf Of David
>> Woodhouse
>> Sent: 19 March 2020 21:22
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -491,7 +491,8 @@ void share_xen_page_with_guest(struct page_info *page,
>> struct
On 19.03.2020 16:26, Andrew Cooper wrote:
> The data layout for struct microcode_patch is extremely poor, and
> unnecessarily complicated. Almost all of it is opaque to core.c, with the
> exception of free_patch().
>
> Move the responsibility for freeing the patch into the free_patch() hook,
> wh
On 20/03/2020 13:37, Jan Beulich wrote:
> On 19.03.2020 16:26, Andrew Cooper wrote:
>> Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use a
>> switch statement in early_microcode_init() rather than probing each vendor in
>> turn. This allows the microcode_ops pointer to becom
On 19.03.2020 16:26, Andrew Cooper wrote:
> Drop microcode_init_{intel,amd}(), export {intel,amd}_ucode_ops, and use a
> switch statement in early_microcode_init() rather than probing each vendor in
> turn. This allows the microcode_ops pointer to become local to core.c.
>
> As there are no exter
> -Original Message-
> From: Xen-devel On Behalf Of David
> Woodhouse
> Sent: 19 March 2020 21:22
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ;
> Andrew Cooper ; Ian Jackson
> ; George Dunlap
> ; hongy...@amazon.com; Jan Beulich
> ; Volodymy
On 20.03.2020 10:12, Julien Grall wrote:
> On 20/03/2020 09:01, Roger Pau Monné wrote:
>> On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
>>> On 19.03.2020 20:07, Julien Grall wrote:
On 19/03/2020 18:43, Roger Pau Monné wrote:
> On Thu, Mar 19, 2020 at 06:07:44PM +, Julien
On 20.03.2020 10:01, Roger Pau Monné wrote:
> On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
>> On 19.03.2020 20:07, Julien Grall wrote:
>>> On 19/03/2020 18:43, Roger Pau Monné wrote:
On Thu, Mar 19, 2020 at 06:07:44PM +, Julien Grall wrote:
>
>
> On 19/03/2020 1
On 3/19/20 11:09 PM, Marek Marczykowski-Górecki wrote:
> xen_pcibk_get_interrupt_type() assumes INTERRUPT_TYPE_NONE being 0
> (initialize ret to 0 and return as INTERRUPT_TYPE_NONE).
> Fix the definition to make INTERRUPT_TYPE_NONE really 0, and also shift
> other values to not leave holes.
> But
> -Original Message-
> From: Xen-devel On Behalf Of David
> Woodhouse
> Sent: 19 March 2020 21:22
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Julien Grall
> ; Wei Liu ;
> Andrew Cooper ; Ian Jackson
> ; George Dunlap
> ; hongy...@amazon.com; Jan Beulich
> ; Volodymy
On Fri, 2020-03-20 at 11:03 +, Paul Durrant wrote:
> > +val = NULL;
> > +/* Don't repeat an error message if xs_read() already
> > failed */
> > +if (val)
>
> How can the code get here? The line above the comment always sets val to NULL.
Oops,
flight 148758 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148758/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-intel 17 guest-saverestore.2 fail REGR. vs. 148611
Tests which did no
On 20.03.20 12:19, David Woodhouse wrote:
On Fri, 2020-03-20 at 07:34 +0100, Jürgen Groß wrote:
Have you thought about the possibility to do the complete handling in a
single transaction? This would ensure a complete consistent picture
from the time the operation has started. Any inconsistency s
On Fri, 2020-03-20 at 07:34 +0100, Jürgen Groß wrote:
> Have you thought about the possibility to do the complete handling in a
> single transaction? This would ensure a complete consistent picture
> from the time the operation has started. Any inconsistency should be
> reported as an error then.
On Fri, Mar 20, 2020 at 10:36:49AM +, Julien Grall wrote:
> Hi,
>
> On 20/03/2020 10:24, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 10:08:33AM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 20/03/2020 10:00, Roger Pau Monné wrote:
> > > > On Fri, Mar 20, 2020 at 10:42:14AM +0100,
> -Original Message-
> From: Xen-devel On Behalf Of David
> Woodhouse
> Sent: 19 March 2020 20:40
> To: xen-devel@lists.xenproject.org
> Cc: Juergen Gross ; Ian Jackson ;
> Wei Liu
> Subject: [Xen-devel] [PATCH 2/2] tools/xenstore: Accumulate errors in
> xenstore-ls and exit
> appropri
flight 148775 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148775/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
Hi,
On 20/03/2020 10:24, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 10:08:33AM +, Julien Grall wrote:
Hi,
On 20/03/2020 10:00, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 10:42:14AM +0100, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 09:12:16AM +, Julien Grall wrote:
Hi Rog
On Fri, Mar 20, 2020 at 10:08:33AM +, Julien Grall wrote:
> Hi,
>
> On 20/03/2020 10:00, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 10:42:14AM +0100, Roger Pau Monné wrote:
> > > On Fri, Mar 20, 2020 at 09:12:16AM +, Julien Grall wrote:
> > > > Hi Roger,
> > > >
> > > > On 20/03/2
Hi,
On 20/03/2020 10:00, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 10:42:14AM +0100, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 09:12:16AM +, Julien Grall wrote:
Hi Roger,
On 20/03/2020 09:01, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
O
On Fri, Mar 20, 2020 at 10:42:14AM +0100, Roger Pau Monné wrote:
> On Fri, Mar 20, 2020 at 09:12:16AM +, Julien Grall wrote:
> > Hi Roger,
> >
> > On 20/03/2020 09:01, Roger Pau Monné wrote:
> > > On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
> > > > On 19.03.2020 20:07, Julien
On Fri, Mar 20, 2020 at 09:12:16AM +, Julien Grall wrote:
> Hi Roger,
>
> On 20/03/2020 09:01, Roger Pau Monné wrote:
> > On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
> > > On 19.03.2020 20:07, Julien Grall wrote:
> > > > Hi,
> > > >
> > > > On 19/03/2020 18:43, Roger Pau Monn
Hi Roger,
On 20/03/2020 09:01, Roger Pau Monné wrote:
On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
On 19.03.2020 20:07, Julien Grall wrote:
Hi,
On 19/03/2020 18:43, Roger Pau Monné wrote:
On Thu, Mar 19, 2020 at 06:07:44PM +, Julien Grall wrote:
On 19/03/2020 17:38, Ro
On Fri, Mar 20, 2020 at 08:21:19AM +0100, Jan Beulich wrote:
> On 19.03.2020 20:07, Julien Grall wrote:
> > Hi,
> >
> > On 19/03/2020 18:43, Roger Pau Monné wrote:
> >> On Thu, Mar 19, 2020 at 06:07:44PM +, Julien Grall wrote:
> >>>
> >>>
> >>> On 19/03/2020 17:38, Roger Pau Monné wrote:
> >>>
flight 148761 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148761/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0c8ea9fe1adbbee230ee0c68f28b68ca2b0534bc
baseline version:
ovmf 1b6b4a83e1d85e4883706
On 19.03.2020 20:07, Julien Grall wrote:
> Hi,
>
> On 19/03/2020 18:43, Roger Pau Monné wrote:
>> On Thu, Mar 19, 2020 at 06:07:44PM +, Julien Grall wrote:
>>>
>>>
>>> On 19/03/2020 17:38, Roger Pau Monné wrote:
On Thu, Mar 19, 2020 at 04:21:23PM +, Julien Grall wrote:
>> Why c
The run* targets can be used to test whatever the tool chain is capable
of building, as long as at least the main harness source file builds.
Don't issue the warning in this case. While looking into this I also
noticed the wording of the respective comment isn't quite right, which
therefore gets al
75 matches
Mail list logo
