> On 28 Jul 2020, at 21:04, Stefano Stabellini wrote:
>
> On Tue, 28 Jul 2020, Bertrand Marquis wrote:
>> At the moment on Arm, a Linux guest running with KTPI enabled will
>> cause the following error when a context switch happens in user mode:
>> (XEN) p2m.c:1890: d1v0: Failed to walk page-t
flight 152270 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152270/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 744ad444e5306ef68edbe899b5f5dc87e82c146b
baseline version:
ovmf 3887820e5fecdb9e948f8
flight 152251 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152251/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 18 leak-check/check fail REGR. vs. 152233
Tests which did no
flight 152267 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152267/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 151947
test-amd64-amd64-xl-qemuu-win7-amd64 17 g
On 28/07/2020 19:52, Christopher Clark wrote:
Hi Christopher,
wow, this quickly got out of hand. I never meant to downplay anyone's
work here, but on this particular platform some things might look a bit
different than normal. See below.
> On Tue, Jul 28, 2020 at 11:16 AM Stefano Stabellini
> w
flight 152269 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152269/
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 Tue, Jul 28, 2020 at 10:01:33PM +0100, Andrew Cooper wrote:
> On 28/07/2020 21:00, Jan Beulich wrote:
> > On 28.07.2020 09:41, Norbert Kaminski wrote:
> >> I'm trying to add support for the firmware updates with the UEFI
> >> capsule in
> >> Qubes OS. I've got the troubles with reading ESRT (EFI
flight 152246 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152246/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which are fa
On 28/07/2020 21:00, Jan Beulich wrote:
> On 28.07.2020 09:41, Norbert Kaminski wrote:
>> I'm trying to add support for the firmware updates with the UEFI
>> capsule in
>> Qubes OS. I've got the troubles with reading ESRT (EFI System
>> Resource Table)
>> in the dom0, which is based on the EFI memo
On 28.07.2020 09:41, Norbert Kaminski wrote:
I'm trying to add support for the firmware updates with the UEFI capsule in
Qubes OS. I've got the troubles with reading ESRT (EFI System Resource Table)
in the dom0, which is based on the EFI memory map. The EFI_MEMMAP is not
enabled despite the loade
On 28.07.2020 17:52, Bertrand Marquis wrote:
At the moment on Arm, a Linux guest running with KTPI enabled will
cause the following error when a context switch happens in user mode:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
The error is caused by the virtual address
On 28.07.2020 16:51, Andrew Cooper wrote:
On 15/07/2020 11:49, Jan Beulich wrote:
Use ALTERNATIVE directly, such that at the use sites it is visible that
alternative code patching is in use. Similarly avoid hiding the fact in
SAVE_ALL.
No change to generated code.
Signed-off-by: Jan Beulich
On 28.07.2020 16:29, Andrew Cooper wrote:
On 15/07/2020 11:48, Jan Beulich wrote:
Now that I've done this I'm not longer sure which direction is better to
follow: On one hand this introduces dead code (even if just NOPs) into
CET-SS-disabled builds. Otoh this is a step towards breaking the tool
On 28.07.2020 15:59, Andrew Cooper wrote:
On 27/07/2020 20:47, Jan Beulich wrote:
On 27.07.2020 16:55, Roger Pau Monné wrote:
On Wed, Jul 15, 2020 at 12:48:14PM +0200, Jan Beulich wrote:
--- /dev/null
+++ b/xen/include/asm-x86/asm-defns.h
Maybe this could be asm-insn.h or a different name? I
On 28.07.2020 15:55, Andrew Cooper wrote:
On 15/07/2020 11:48, Jan Beulich wrote:
--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -20,6 +20,7 @@ $(call as-option-add,CFLAGS,CC,"rdrand %
$(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
$(call as-option-add,CFLAGS,CC
flight 152261 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152261/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3887820e5fecdb9e948f88eb4e92298f6c3dd86f
baseline version:
ovmf ffde22468e2f0e93b51f9
On Tue, 28 Jul 2020, Bertrand Marquis wrote:
> At the moment on Arm, a Linux guest running with KTPI enabled will
> cause the following error when a context switch happens in user mode:
> (XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
>
> The error is caused by the virtual
On Tue, Jul 28, 2020 at 11:16 AM Stefano Stabellini
wrote:
>
> On Tue, 28 Jul 2020, André Przywara wrote:
> > On 28/07/2020 11:39, Alejandro wrote:
> > > Hello,
> > >
> > > El dom., 26 jul. 2020 a las 22:25, André Przywara
> > > () escribió:
> > >> So this was actually my first thought: The firmwa
On Tue, 28 Jul 2020, Roger Pau Monné wrote:
> On Mon, Jul 27, 2020 at 05:06:25PM -0700, Stefano Stabellini wrote:
> > On Mon, 27 Jul 2020, Roger Pau Monné wrote:
> > > On Sat, Jul 25, 2020 at 10:59:50AM +0100, Julien Grall wrote:
> > > > On Sat, 25 Jul 2020 at 00:46, Stefano Stabellini
> > > > wr
On Tue, 28 Jul 2020, André Przywara wrote:
> On 28/07/2020 11:39, Alejandro wrote:
> > Hello,
> >
> > El dom., 26 jul. 2020 a las 22:25, André Przywara
> > () escribió:
> >> So this was actually my first thought: The firmware (U-Boot SPL) sets up
> >> some basic CPU frequency (888 MHz for H6 [1]),
On Jul 28, 2020, at 13:19, Srinivas Bangalore wrote:
>
>
>>
>> I struggled to find your comment inline as your e-mail client doesn't
>> quote my answer. Please configure your e-mail client to use some form
>> of quoting (the usual is '>').
>>
>> [] Done! Sorry about that.
>
> Thanks this i
On 28.07.2020 12:15, Andrew Cooper wrote:
The Xen domctl ABI currently relies on the union containing a field with
alignment of 8.
32bit projects which only copy the used subset of functionality end up with an
ABI breakage if they don't have at least one uint64_aligned_t field copied.
I'm enti
On 28.07.2020 11:26, Andrew Cooper wrote:
Does this work?
diff --git a/xen/arch/x86/hvm/hpet.c b/xen/arch/x86/hvm/hpet.c
index ca94e8b453..638f6174de 100644
--- a/xen/arch/x86/hvm/hpet.c
+++ b/xen/arch/x86/hvm/hpet.c
@@ -62,8 +62,7 @@
#define timer_int_route(h, n) MASK_EXTR(timer_config(
On Tue, Jul 28, 2020 at 06:12:46PM +0100, Julien Grall wrote:
> Hi Roger,
>
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> > > Hi,
> > >
> > > On 27/07/2020 10:13, Roger Pau Monne wrote:
> > > > To be used in order to create forei
On Tue, Jul 28, 2020 at 06:06:25PM +0100, Andrew Cooper wrote:
> On 28/07/2020 17:59, Roger Pau Monné wrote:
> > On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> >> Hi,
> >>
> >> On 27/07/2020 10:13, Roger Pau Monne wrote:
> >>> To be used in order to create foreign mappings. This is
> I struggled to find your comment inline as your e-mail client doesn't
> quote my answer. Please configure your e-mail client to use some form
> of quoting (the usual is '>').
>
> [] Done! Sorry about that.
Thanks this is a good start. Unfortunately, it doesn't fully help it when you
have a r
Hi Roger,
On 28/07/2020 17:59, Roger Pau Monné wrote:
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devi
On 28/07/2020 17:59, Roger Pau Monné wrote:
> On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
>> Hi,
>>
>> On 27/07/2020 10:13, Roger Pau Monne wrote:
>>> To be used in order to create foreign mappings. This is based on the
>>> ZONE_DEVICE facility which is used by persistent memory d
On Tue, Jul 28, 2020 at 05:48:23PM +0100, Julien Grall wrote:
> Hi,
>
> On 27/07/2020 10:13, Roger Pau Monne wrote:
> > To be used in order to create foreign mappings. This is based on the
> > ZONE_DEVICE facility which is used by persistent memory devices in
> > order to create struct pages and k
On 27/07/2020 23:09, Srinivas Bangalore wrote:
Hi,
On 24/07/2020 16:01, Srinivas Bangalore wrote:
Hi Julien,
Hello,
Thanks for the tips. Comments inline...
I struggled to find your comment inline as your e-mail client doesn't quote
my answer. Please configure your e-mail client to us
Hi,
On 27/07/2020 10:13, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kerne
At the moment on Arm, a Linux guest running with KTPI enabled will
cause the following error when a context switch happens in user mode:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
The error is caused by the virtual address for the runstate area
registered by the guest
On 23/07/2020 11:25, Jan Beulich wrote:
> On 23.07.2020 11:40, Andrew Cooper wrote:
>> On 22/07/2020 17:13, Jan Beulich wrote:
>>> On 22.07.2020 17:15, Andrew Cooper wrote:
* Rename nr to nr_frames. A plain 'nr' is confusing to follow in the the
lower levels.
* Use DIV_ROUND_UP
flight 152241 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152241/
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 15/07/2020 11:49, Jan Beulich wrote:
> Use ALTERNATIVE directly, such that at the use sites it is visible that
> alternative code patching is in use. Similarly avoid hiding the fact in
> SAVE_ALL.
>
> No change to generated code.
>
> Signed-off-by: Jan Beulich
Definitely +1 to not hiding the S
On 15/07/2020 11:48, Jan Beulich wrote:
> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
> to introduce a number of #ifdef-s to make the build work with older tool
> chains. Introduce an assembler macro covering for tool chains not
> knowing of CET-SS, allowing some conditi
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, bumping the
> library minor version and providing compatiblity for the non-Linu
On 28/07/2020 12:37, Andrew Cooper wrote:
> diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
> index 9f0cae52c0..122d1e7596 100644
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -4013,6 +4013,72 @@ static int gnttab_get_shared_frame_mfn(struct domain
> *d,
>
On 27/07/2020 20:47, Jan Beulich wrote:
> On 27.07.2020 16:55, Roger Pau Monné wrote:
>> On Wed, Jul 15, 2020 at 12:48:14PM +0200, Jan Beulich wrote:
>>> --- /dev/null
>>> +++ b/xen/include/asm-x86/asm-defns.h
>>
>> Maybe this could be asm-insn.h or a different name? I find it
>> confusing to have
On 7/28/20 7:42 AM, Roger Pau Monne wrote:
> In order to protect against the header being included multiple times
> on the same compilation unit.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Boris Ostrovsky
On 15/07/2020 11:48, Jan Beulich wrote:
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -20,6 +20,7 @@ $(call as-option-add,CFLAGS,CC,"rdrand %
> $(call as-option-add,CFLAGS,CC,"rdfsbase %rax",-DHAVE_AS_FSGSBASE)
> $(call as-option-add,CFLAGS,CC,"xsaveopt (%rax)",-DHAVE_AS_XSAVEOPT
On 28/07/2020 12:09, Eslam Elnikety wrote:
> On 28.07.20 11:26, Andrew Cooper wrote:
>> On 28/07/2020 09:33, Eslam Elnikety wrote:
>>> The macro timer_int_route_cap evalutes to a 64 bit value. Extend the
>>> size of left side of timer_int_route_valid to match.
>>>
>>> This bug was discovered and re
flight 152249 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152249/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf ffde22468e2f0e93b51f97b801e6c7a181088c61
baseline version:
ovmf a44f558a84c67cd88b821
In order to protect against the header being included multiple times
on the same compilation unit.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-devel@lists.xenproject.org
---
This is required as a pre-patch to use ZONE_DEVICE, or else
New architectures shouldn't be forced to implement no-op stubs for unused
functionality.
Introduce CONFIG_ARCH_ACQUIRE_RESOURCE which can be opted in to, and provide
compatibility logic in xen/mm.h
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pa
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, bumping the
library minor version and providing compatiblity for the non-Linux builds.
Its not possible to reuse the IOCTL_PRIV
Copy the nr_frames from the correct structure, so the caller doesn't
unconditionally receive 0.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Wei Liu
CC: Julien Grall
CC: Paul Durrant
CC: Michał Lesz
Calling XENMEM_acquire_resource with a NULL frame_list is a request for the
size of the resource, but the returned 32 is bogus.
If someone tries to follow it for XENMEM_resource_ioreq_server, the acquire
call will fail as IOREQ servers currently top out at 2 frames, and it is only
half the size of
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 28 July 2020 11:09
> To: qemu-de...@nongnu.org
> Cc: Paul Durrant ; Paolo Bonzini ;
> xen-devel@lists.xenproject.org;
> Stefano Stabellini ; Anthony Perard
> ; Philippe
> Mathieu-Daudé ; Paul Durrant ; Peter
> Maydell
>
> Subj
The existing logic doesn't function in the general case for mapping a guests
grant table, due to arbitrary 32 frame limit, and the default grant table
limit being 64.
In order to start addressing this, rework the existing grant table logic by
implementing a single gnttab_acquire_resource(). This
I thought this was going to be a very simple small bugfix for Michał's
Processor Trace series. Serves me right for expecting it not to be full of
bear traps...
The sole implementation of acquire_resource never asks for size, so its little
surprise that Xen is broken for compat callers, and return
On 28/07/2020 11:39, Alejandro wrote:
> Hello,
>
> El dom., 26 jul. 2020 a las 22:25, André Przywara
> () escribió:
>> So this was actually my first thought: The firmware (U-Boot SPL) sets up
>> some basic CPU frequency (888 MHz for H6 [1]), which is known to never
>> overheat the chip, even under
Hello,
El dom., 26 jul. 2020 a las 22:25, André Przywara
() escribió:
> So this was actually my first thought: The firmware (U-Boot SPL) sets up
> some basic CPU frequency (888 MHz for H6 [1]), which is known to never
> overheat the chip, even under full load. So any concern from your side
> about
Hi Andrew,
On 28/07/2020 11:15, Andrew Cooper wrote:
The Xen domctl ABI currently relies on the union containing a field with
alignment of 8.
32bit projects which only copy the used subset of functionality end up with an
ABI breakage if they don't have at least one uint64_aligned_t field copied
Patchew URL: https://patchew.org/QEMU/20200728100925.10454-1-phi...@redhat.com/
Hi,
This series failed the docker-quick@centos7 build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST SCRIPT BEGIN ===
#
The Xen domctl ABI currently relies on the union containing a field with
alignment of 8.
32bit projects which only copy the used subset of functionality end up with an
ABI breakage if they don't have at least one uint64_aligned_t field copied.
Insert explicit padding, and some build assertions to
On Tue, 28 Jul 2020 at 11:00, Philippe Mathieu-Daudé wrote:
> Apparently kvm_enabled() checks CONFIG_KVM_IS_POSSIBLE instead
> of CONFIG_KVM, I suppose to bypass this limitation (from osdep.h):
>
> 21 #ifdef NEED_CPU_H
> 22 # ifdef CONFIG_KVM
> 24 # define CONFIG_KVM_IS_POSSIBLE
> 25 # endif
> On Jul 27, 2020, at 5:04 PM, Julien Grall wrote:
>
> Hmmm I forgot to CC George. Sorry for that.
>
> On 27/07/2020 17:04, Julien Grall wrote:
>> From: Julien Grall
>> The operator + will just concatenate two strings. As the result, the
>> configure cmdline for "xentools" will look like:
>>
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
On 7/28/20 11:56 AM, Philippe Mathieu-Daudé wrote:
> On 7/28/20 11:53 AM, Peter Maydell wrote:
>> On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé
>> wrote:
>>> I'd rather uninline xen_enabled() but I'm not sure this has perf
>>> penalties. Paolo is that OK to uninline it?
>
> I suppose no b
On 7/28/20 11:53 AM, Peter Maydell wrote:
> On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé
> wrote:
>> I'd rather uninline xen_enabled() but I'm not sure this has perf
>> penalties. Paolo is that OK to uninline it?
I suppose no because it is in various hot paths:
exec.c:588:if (xen_en
On Tue, 28 Jul 2020 at 10:51, Philippe Mathieu-Daudé wrote:
> I'd rather uninline xen_enabled() but I'm not sure this has perf
> penalties. Paolo is that OK to uninline it?
Can we just follow the same working pattern we already have
for kvm_enabled() etc ?
thanks
-- PMM
On 7/28/20 11:27 AM, Peter Maydell wrote:
> On Tue, 28 Jul 2020 at 10:19, Paul Durrant wrote:
>>
>> From: Paul Durrant
>>
>> The recent commit da278d58a092 "accel: Move Xen accelerator code under
>> accel/xen/" introduced a subtle semantic change, making xen_enabled() always
>> return false unles
On Tue, 28 Jul 2020 at 10:19, Paul Durrant wrote:
>
> From: Paul Durrant
>
> The recent commit da278d58a092 "accel: Move Xen accelerator code under
> accel/xen/" introduced a subtle semantic change, making xen_enabled() always
> return false unless CONFIG_XEN is defined prior to inclusion of syse
On 28/07/2020 09:33, Eslam Elnikety wrote:
> The macro timer_int_route_cap evalutes to a 64 bit value. Extend the
> size of left side of timer_int_route_valid to match.
>
> This bug was discovered and resolved using Coverity Static Analysis
> Security Testing (SAST) by Synopsys, Inc.
>
> Signed-off
From: Paul Durrant
The recent commit da278d58a092 "accel: Move Xen accelerator code under
accel/xen/" introduced a subtle semantic change, making xen_enabled() always
return false unless CONFIG_XEN is defined prior to inclusion of sysemu/xen.h,
which appears to be the normal case. This causes var
On Mon, Jul 27, 2020 at 09:47:52PM +0200, Jan Beulich wrote:
> On 27.07.2020 16:55, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 12:48:14PM +0200, Jan Beulich wrote:
> > > --- /dev/null
> > > +++ b/xen/include/asm-x86/asm-defns.h
> >
> > Maybe this could be asm-insn.h or a different name? I
On Tue, Jul 28, 2020 at 08:33:57AM +, Eslam Elnikety wrote:
> The macro timer_int_route_cap evalutes to a 64 bit value. Extend the
> size of left side of timer_int_route_valid to match.
I'm very dull with this things, so forgive me.
Isn't the left side just promoted to an unsigned 64bit value
On Mon, Jul 27, 2020 at 09:50:23PM +0200, Jan Beulich wrote:
> On 27.07.2020 17:00, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 12:48:46PM +0200, Jan Beulich wrote:
> > Should the setssbsy be quoted, or it doesn't matter? I'm asking
> > because the same construction used by CLAC/STAC doesn't
On Mon, Jul 27, 2020 at 05:06:25PM -0700, Stefano Stabellini wrote:
> On Mon, 27 Jul 2020, Roger Pau Monné wrote:
> > On Sat, Jul 25, 2020 at 10:59:50AM +0100, Julien Grall wrote:
> > > On Sat, 25 Jul 2020 at 00:46, Stefano Stabellini
> > > wrote:
> > > >
> > > > On Fri, 24 Jul 2020, Julien Grall
On Tue, Jul 28, 2020 at 08:06:17AM +, Rahul Singh wrote:
>
>
> > On 24 Jul 2020, at 3:44 pm, Roger Pau Monné wrote:
> >
> > On Thu, Jul 23, 2020 at 04:40:21PM +0100, Rahul Singh wrote:
> >> +
> >> +struct pci_host_bridge *bridge = pci_find_host_bridge(sbdf.seg,
> >> sbdf.bus);
> >> +
>
flight 152233 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152233/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 17 guest-start.2fail REGR. vs. 152045
Tests which did not succeed
> On 24 Jul 2020, at 3:44 pm, Roger Pau Monné wrote:
>
> On Thu, Jul 23, 2020 at 04:40:21PM +0100, Rahul Singh wrote:
>> XEN during boot will read the PCI device tree node “reg” property
>> and will map the PCI config space to the XEN memory.
>>
>> XEN will read the “linux, pci-domain” propert
flight 152247 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152247/
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
Hello all,
I'm trying to add support for the firmware updates with the UEFI capsule in
Qubes OS. I've got the troubles with reading ESRT (EFI System Resource
Table)
in the dom0, which is based on the EFI memory map. The EFI_MEMMAP is not
enabled despite the loaded drivers (CONFIG_EFI, CONFIG_EF
On 28.07.20 09:10, Souptick Joarder wrote:
Hi Boris,
On Sun, Jul 12, 2020 at 9:01 AM Souptick Joarder wrote:
This series contains few clean up, minor bug fixes and
Convert get_user_pages() to pin_user_pages().
I'm compile tested this, but unable to run-time test,
so any testing help is much
Hi Boris,
On Sun, Jul 12, 2020 at 9:01 AM Souptick Joarder wrote:
>
> This series contains few clean up, minor bug fixes and
> Convert get_user_pages() to pin_user_pages().
>
> I'm compile tested this, but unable to run-time test,
> so any testing help is much appriciated.
>
> v2:
> Addre
flight 152244 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/152244/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a44f558a84c67cd88b8215d4c076123cf58438f4
baseline version:
ovmf 6074f57e5b19c4cfd45a1
78 matches
Mail list logo
