On 15.10.2020 12:49, Jürgen Groß wrote:
> On 15.10.20 12:09, Jan Beulich wrote:
>> On 15.10.2020 09:58, Jürgen Groß wrote:
>>> After a short discussion on IRC yesterday I promised to send a mail
>>> how I think we could get rid of creating dynamic links especially
>>> for header files in the Xen bu
On 16.10.20 08:58, Jan Beulich wrote:
On 15.10.2020 12:41, Jürgen Groß wrote:
On 15.10.20 12:09, Jan Beulich wrote:
On 15.10.2020 09:58, Jürgen Groß wrote:
- tools/include/xen/foreign -> tools/include/xen-foreign:
Get rid of tools/include/xen-foreign and generate the headers directly
On 16.10.2020 09:25, Jürgen Groß wrote:
> On 16.10.20 08:58, Jan Beulich wrote:
>> On 15.10.2020 12:41, Jürgen Groß wrote:
>>> On 15.10.20 12:09, Jan Beulich wrote:
On 15.10.2020 09:58, Jürgen Groß wrote:
> - tools/include/xen/foreign -> tools/include/xen-foreign:
> Get rid of too
Hi Jan,
On 16/10/2020 07:29, Jan Beulich wrote:
On 15.10.2020 18:44, Oleksandr Tyshchenko wrote:
@@ -1067,7 +1068,14 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
*/
if ( p2m_is_valid(orig_pte) &&
!mfn_eq(lpae_get_mfn(*entry), lpae_get_mfn(orig_pte)) )
+{
+#i
Instead of calling send_guest_vcpu_virq() from NMI context use the
NMI continuation framework for that purpose. This avoids taking locks
in NMI mode.
Signed-off-by: Juergen Gross
---
xen/arch/x86/oprofile/nmi_int.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/xen/a
Instead of using a softirq pci_serr_error() can use NMI continuation
for issuing an error message.
Signed-off-by: Juergen Gross
---
xen/arch/x86/traps.c | 9 +++--
xen/include/asm-x86/softirq.h | 5 ++---
2 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/tr
Move sending of a virq event for oprofile to the local vcpu from NMI
to normal interrupt context.
This has been tested with a small test patch using the continuation
framework of patch 1 for all NMIs and doing a print to console in
the continuation handler.
Version 1 of this small series was sent
Actions in NMI context are rather limited as e.g. locking is rather
fragile.
Add a generic framework to continue processing in normal interrupt
context after leaving NMI processing.
This is done by a high priority interrupt vector triggered via a
self IPI from NMI context, which will then call th
On 16.10.2020 10:41, Julien Grall wrote:
> On 16/10/2020 07:29, Jan Beulich wrote:
>> Given how p2m_free_entry() works (or is supposed to work in the
>> long run), is the new code you add guaranteed to only alter leaf
>> entries?
>
> This path may also be called with tables. I think we want to mov
flight 155881 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155881/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d25fd8710d6c8fc11582210fb1f8480c0d98416b
baseline version:
ovmf 19c87b7d446c3273e84b2
On 19.08.2020 18:52, Don Slutz wrote:
> From: Don Slutz
>
> Also added missing TRAP_DEBUG & VLAPIC.
>
> Signed-off-by: Don Slutz
> CC: Don Slutz
> ---
> Acked-by: Ian Campbell
>
> v14:
> Reworked to current code.
> Added VMPORT_SEND because I wanted to see it during testing.
>
> v13:
>
On 15/10/2020 13:07, Jan Beulich wrote:
On 14.10.2020 13:40, Julien Grall wrote:
Hi Jan,
On 13/10/2020 15:26, Jan Beulich wrote:
On 13.10.2020 16:20, Jürgen Groß wrote:
On 13.10.20 15:58, Jan Beulich wrote:
On 12.10.2020 11:27, Juergen Gross wrote:
The queue for a fifo event is depending
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in
kern
Hi all,
On Tue, 2020-10-13 at 14:30 +0200, Jan Beulich wrote:
> On 12.10.2020 20:09, George Dunlap wrote:
> > > On Oct 7, 2020, at 11:19 AM, Anastasiia Lukianenko <
> > > anastasiia_lukiane...@epam.com> wrote:
> > > So I want to know if the community is ready to add new formatting
> > > options an
Hi Juergen,
On 12/10/2020 10:27, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabl
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
Looks good.
Reviewed-by: Sam Ravnborg
On 11.09.2020 12:34, Jan Beulich wrote:
> When a page table page gets de-validated, its type reference count drops
> to zero (and PGT_validated gets cleared), but its type remains intact.
> XEN_DOMCTL_getpageframeinfo3, therefore, so far reported prior usage for
> such pages. An intermediate write
Hi,
On 16/10/2020 10:42, Anastasiia Lukianenko wrote:
Thanks for your advices, which helped me improve the checker. I
understand that there are still some disagreements about the
formatting, but as I said before, the checker cannot be very flexible
and take into account all the author's ideas.
flight 155885 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155885/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
Hi Sam
On Fri, 16 Oct 2020 12:08:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> > To do framebuffer updates, one needs memcpy from system memory and a
> > pointer-increment function. Add both interfaces with documentation.
> >
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intact. For this purpose
the event channel contains last_prior
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.
The second patch is modifying the per ev
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed f
On 15/10/2020 08:27, Jan Beulich wrote:
> On 14.10.2020 20:00, Andrew Cooper wrote:
>> On 13/10/2020 16:51, Jan Beulich wrote:
>>> On 12.10.2020 15:49, Andrew Cooper wrote:
All interrupts and exceptions pass a struct cpu_user_regs up into C. This
contains the legacy vm86 fields from 32bi
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_op
On 16.10.2020 12:58, Andrew Cooper wrote:
> On 15/10/2020 08:27, Jan Beulich wrote:
>> On 14.10.2020 20:00, Andrew Cooper wrote:
>>> On 13/10/2020 16:51, Jan Beulich wrote:
On 12.10.2020 15:49, Andrew Cooper wrote:
> All interrupts and exceptions pass a struct cpu_user_regs up into C. Thi
flight 155880 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155880/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 19 guest-start.2fail REGR. vs. 155788
Tests which did not succeed
On 16/10/2020 12:03, Jan Beulich wrote:
> On 16.10.2020 12:58, Andrew Cooper wrote:
>> On 15/10/2020 08:27, Jan Beulich wrote:
>>> On 14.10.2020 20:00, Andrew Cooper wrote:
On 13/10/2020 16:51, Jan Beulich wrote:
> On 12.10.2020 15:49, Andrew Cooper wrote:
>> All interrupts and excepti
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:05PM +0200, Thomas Zimmermann wrote:
> To do framebuffer updates, one needs memcpy from system memory and a
> pointer-increment function. Add both interfaces with documentation.
>
> Signed-off-by: Thomas Zimmermann
> ---
> include/linux/dma-buf-map.h | 7
Hi
On Fri, 16 Oct 2020 12:58:54 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct
Hi,
-Original Message-
From: Julien Grall
Sent: пятница, 16 октября 2020 г. 13:24
To: Anastasiia Lukianenko ; jbeul...@suse.com;
george.dun...@citrix.com
Cc: Artem Mygaiev ; vicooo...@gmail.com;
xen-devel@lists.xenproject.org; committ...@xenproject.org;
viktor.mitin...@gmail.com; Volo
On 16.10.2020 13:24, Andrew Cooper wrote:
> On a tangent, what are your views WRT backport beyond 4.14?
>
> Back then, it was #DB which was adjacent to the guard frame (which was
> not present), but it doesn't use show_registers() by default, so I think
> the problem is mostly hidden.
I wasn't fu
Hi Thomas.
On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> At least sparc64 requires I/O-specific access to framebuffers. This
> patch updates the fbdev console accordingly.
>
> For drivers with direct access to the framebuffer memory, the callback
> functions in struct fb_op
On 16/10/2020 12:55, Jan Beulich wrote:
> On 16.10.2020 13:24, Andrew Cooper wrote:
>> On a tangent, what are your views WRT backport beyond 4.14?
>>
>> Back then, it was #DB which was adjacent to the guard frame (which was
>> not present), but it doesn't use show_registers() by default, so I think
On 16.10.2020 11:36, Julien Grall wrote:
> On 15/10/2020 13:07, Jan Beulich wrote:
>> On 14.10.2020 13:40, Julien Grall wrote:
>>> On 13/10/2020 15:26, Jan Beulich wrote:
On 13.10.2020 16:20, Jürgen Groß wrote:
> Especially Julien was rather worried by the current situation. In
> case
On 16.10.2020 14:07, Andrew Cooper wrote:
> On 16/10/2020 12:55, Jan Beulich wrote:
>> On 16.10.2020 13:24, Andrew Cooper wrote:
>>> On a tangent, what are your views WRT backport beyond 4.14?
>>>
>>> Back then, it was #DB which was adjacent to the guard frame (which was
>>> not present), but it do
Hi
On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
> Hi Thomas.
>
> On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> > For drivers with direct
This is a workaround. There is a problem with hoat key setup in a
group of hosts, which means that when a pair test reuses a host set up
by a different test, we can get
Host key verification failed.
during the src-to-dst migration.
Signed-off-by: Ian Jackson
---
ts-host-reuse | 1 +
1 file c
On Fri, Oct 16, 2020 at 02:19:42PM +0200, Thomas Zimmermann wrote:
> Hi
>
> On Fri, 16 Oct 2020 14:03:47 +0200 Sam Ravnborg wrote:
>
> > Hi Thomas.
> >
> > On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote:
> > > At least sparc64 requires I/O-specific access to framebuffers. Thi
On Thu, Oct 15, 2020 at 03:01:48AM +0200, Marek Marczykowski-Górecki wrote:
> On Sun, Oct 11, 2020 at 06:11:39PM -0700, Elliott Mitchell wrote:
> > Unexpectedly the environment variable which needs to be passed is
> > $LDSHARED and not $LD. Otherwise Python may find the build `ld` instead
> > of t
On Thu, Oct 15, 2020 at 02:17:18PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("[PATCH] tools/gdbsx: drop stray recursion into
> tools/include/"):
> > Doing so isn't appropriate here - this gets done very early in the build
> > process. If the directory is mean to to be buildable on its own,
>
On Thu, Oct 15, 2020 at 10:16:09AM +0100, Bertrand Marquis wrote:
> Add a check for snprintf return code and ignore the entry if we get an
> error. This should in fact never happen and is more a trick to make gcc
> happy and prevent compilation errors.
>
> This is solving the following gcc warning
On Fri, Oct 16, 2020 at 01:26:49PM +, Wei Liu wrote:
> On Thu, Oct 15, 2020 at 02:17:18PM +0100, Ian Jackson wrote:
> > Jan Beulich writes ("[PATCH] tools/gdbsx: drop stray recursion into
> > tools/include/"):
> > > Doing so isn't appropriate here - this gets done very early in the build
> > >
On 16/10/2020 08:34, Jan Beulich wrote:
> On 16.10.2020 02:39, Igor Druzhinin wrote:
>> ACPI specification contains statements describing memory marked with regular
>> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
>> really do it if it wants kexec or similar functionali
> On 16 Oct 2020, at 14:28, Wei Liu wrote:
>
> On Thu, Oct 15, 2020 at 10:16:09AM +0100, Bertrand Marquis wrote:
>> Add a check for snprintf return code and ignore the entry if we get an
>> error. This should in fact never happen and is more a trick to make gcc
>> happy and prevent compilation
On 16/10/2020 14:34, Sander Eikelenboom wrote:
> On 16/10/2020 08:34, Jan Beulich wrote:
>> On 16.10.2020 02:39, Igor Druzhinin wrote:
>>> ACPI specification contains statements describing memory marked with regular
>>> "ACPI data" type as reclaimable by the guest. Although the guest shouldn't
>>>
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tre
If for some reason the hardware reset is not working, print a message to
the user every 5 seconds to warn him that the system did not reset
properly and Xen is still looping.
The message is printed infinitely so that someone connecting to a serial
console with no history would see the message comi
flight 155895 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155895/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Tue, Oct 13, 2020 at 10:05:11AM -0400, Jason Andryuk wrote:
> Xen was broken by commit 1583a3898853 ("cpus: extract out qtest-specific
> code to accel/qtest"). Xen relied on qemu_init_vcpu() calling
> qemu_dummy_start_vcpu() in the default case, but that was replaced by
> g_assert_not_reached()
On 16.10.2020 15:48, Igor Druzhinin wrote:
> On 16/10/2020 14:34, Sander Eikelenboom wrote:
>> On 16/10/2020 08:34, Jan Beulich wrote:
>>> On 16.10.2020 02:39, Igor Druzhinin wrote:
ACPI specification contains statements describing memory marked with
regular
"ACPI data" type as recl
On Tue, Oct 13, 2020 at 03:05:06PM -0400, Jason Andryuk wrote:
> xen-save-devices-state doesn't currently generate a vmdesc, so restore
> always triggers "Expected vmdescription section, but got 0". This is
> not a problem when restore comes from a file. However, when QEMU runs
> in a linux stubd
On 15/10/2020 09:01, Jan Beulich wrote:
> On 14.10.2020 15:57, Andrew Cooper wrote:
>> On 13/10/2020 16:58, Jan Beulich wrote:
>>> On 09.10.2020 17:09, Andrew Cooper wrote:
At the time of XSA-170, the x86 instruction emulator really was broken, and
would allow arbitrary non-canonical valu
Hi Paul,
On 05/10/2020 10:49, Paul Durrant wrote:
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 791f0a2592..75e855625a 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1130,6 +1130,18 @@ struct xen_domctl_vuart_op {
Hi Paul,
On 05/10/2020 10:49, Paul Durrant wrote:
From: Paul Durrant
... sub-operation of XEN_DOMCTL_iommu_ctl.
This patch adds a new sub-operation into the domctl. The code in iommu_ctl()
is extended to call a new arch-specific iommu_set_allocation() function which
will be called with the IO
On Fri, Oct 16, 2020 at 11:38 AM Anthony PERARD
wrote:
>
> On Tue, Oct 13, 2020 at 03:05:06PM -0400, Jason Andryuk wrote:
> > xen-save-devices-state doesn't currently generate a vmdesc, so restore
> > always triggers "Expected vmdescription section, but got 0". This is
> > not a problem when rest
Hi Paul,
On 05/10/2020 10:49, Paul Durrant wrote:
From: Paul Durrant
Set these flags prior to the calls to arch_iommu_domain_init() and the
implementation init() method. There is no reason to hide this information from
those functions and the value of 'hap_pt_share' will be needed by a
modific
On Thu, Oct 15, 2020 at 11:16 AM Jason Andryuk wrote:
>
> On Thu, Oct 15, 2020 at 7:31 AM Roger Pau Monné wrote:
> >
> > On Wed, Oct 14, 2020 at 08:37:06PM +0100, Andrew Cooper wrote:
> > > On 14/10/2020 20:28, Jason Andryuk wrote:
> > > > Hi,
> > > >
> > > > Bug opened at https://gitlab.freedesk
On Thu, Oct 15, 2020 at 11:14 AM Jan Beulich wrote:
>
> On 15.10.2020 16:50, Jason Andryuk wrote:
> > On Thu, Oct 15, 2020 at 3:00 AM Jan Beulich wrote:
> >> And why is there no bounds check of ->phys_entry paralleling the
> >> ->virt_entry one?
> >
> > What is the purpose of this checking? It's
https://gitlab.com/martyros/go-xen branch `working/xenops` contains a
super-basic mock-up of a unix domain xenopsd based on the golang libxl bindings.
To use:
* Install Xen >= 4.14 on your target system
* Make sure you have go >= 1.11 installed
* Clone & build the server
$ git clone https://g
This workaround is no longer needed because I have fixed the problem
properly.
Also, it didn't work anyway, because at that point $ho isn't set, so
all this did was produce some Perl warnings.
This reverts commit f3668acae2c6201c680dc7b4e9085ab184136d7e.
---
ts-host-reuse | 1 -
1 file changed,
This should match only "*_host" and "host". We don't want it matching
"*host" without a "_".
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index f2d8a0e1..5e6b15d9 100644
When a multi-host job reuses host(s) from earlier jobs, the set of
hosts set up in the on-host known_hosts files may be insufficient,
since the hosts we are using now may not have been in any of the
flight's runvars when the earlier job set them up.
So we need to update the known_hosts. We use th
On Fri, Oct 16, 2020 at 12:01:47PM -0400, Jason Andryuk wrote:
> On Fri, Oct 16, 2020 at 11:38 AM Anthony PERARD
> wrote:
> >
> > On Tue, Oct 13, 2020 at 03:05:06PM -0400, Jason Andryuk wrote:
> > > xen-save-devices-state doesn't currently generate a vmdesc, so restore
> > > always triggers "Expec
Signed-off-by: Ian Jackson
---
sg-run-job | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sg-run-job b/sg-run-job
index c64ae026..69ee715b 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -42,10 +42,11 @@ proc per-host-finish {} {
}
proc run-job {job} {
-global jobinfo
We do not currently tear down the nbd, and that means the next test
cannot remove our LVs.
Signed-off-by: Ian Jackson
---
sg-run-job | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sg-run-job b/sg-run-job
index 69ee715b..bc5a0c8f 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -581,6 +581,8 @@
On Fri, Oct 16, 2020 at 12:44 PM Anthony PERARD
wrote:
>
> On Fri, Oct 16, 2020 at 12:01:47PM -0400, Jason Andryuk wrote:
> > On Fri, Oct 16, 2020 at 11:38 AM Anthony PERARD
> > wrote:
> > >
> > > On Tue, Oct 13, 2020 at 03:05:06PM -0400, Jason Andryuk wrote:
> > > > xen-save-devices-state doesn'
flight 155891 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155891/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a7d977040bd82b89d1fe5ef32d488bfd10db2dbc
baseline version:
ovmf d25fd8710d6c8fc115822
flight 155900 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155900/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 155886 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155886/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 155888 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155888/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 13 guest-startfail REGR. vs. 152631
test-amd64-amd64-
flight 155892 qemu-upstream-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155892/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 12 debian-di-installfail REGR. vs. 151900
Test
On Mon, Sep 28, 2020 at 10:00:35PM +0900, Masami Hiramatsu wrote:
> I've missed the explanation of the attached patch. This prototype
> patch was also needed for booting up the Xen on my box (for the system
> which has no SPCR).
I'm pretty sure of this on the hardware I'm dealing with, but don't k
flight 155894 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155894/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pair 27 guest-migrate/dst_host/src_host fail pass in 155880
test-armhf-armhf-xl-vhd 17
On Fri, Oct 16, 2020 at 03:33:23PM -0700, Elliott Mitchell wrote:
> On the device I'm on (Raspberry PI 4B with Tianocore -> GRUB -> Xen) I
> discovered a SPCR table shows up if I boot with the device the output is
> plugged into is powered down. I'm guessing this causes Tianocore to
> advise GRUB/
75 matches
Mail list logo
