> Jules, Brian, could you maybe try the attach QEMU patch and see if that
> works?
I applied the patch to the latest release QEMU (5.1.0), and successfully
ran these types of guests:
PVHVM Linux
PVHVM FreeBSD
PV NetBSD
PVH NetBSD
--
- Brian
On Mon, Sep 28, 2020 at 08:21:08PM +0200, David Hildenbrand wrote:
>Page isolation doesn't actually touch the pages, it simply isolates
>pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>
>We already place pages to the tail of the freelists when undoing
>isolation via
On Mon, Sep 28, 2020 at 08:21:09PM +0200, David Hildenbrand wrote:
>__free_pages_core() is used when exposing fresh memory to the buddy
>during system boot and when onlining memory in generic_online_page().
>
>generic_online_page() is used in two cases:
>
>1. Direct memory onlining in
Hi Jan,
On 28/09/2020 11:56, Jan Beulich wrote:
There's no global lock around the updating of this global piece of data.
Make use of cmpxchg() to avoid two entities racing with their updates.
Signed-off-by: Jan Beulich
---
TBD: Initially I used cmpxchgptr() here, until realizing Arm doesn't
Hello,
> On 26 Sep 2020, at 9:55 pm, Julien Grall wrote:
>
> From: Julien Grall
>
> Hi all,
>
> Xen on ARM has been broken for quite a while on ACPI systems. This
> series aims to fix it.
We also observed the panic after enabling the ACPI for ARM N1SDP board earlier.
(XEN) Xen call trace:
Hello,
> On 26 Sep 2020, at 9:55 pm, Julien Grall wrote:
>
> From: Julien Grall
>
> The functions acpi_os_{un,}map_memory() are meant to be arch-agnostic
> while the __acpi_os_{un,}map_memory() are meant to be arch-specific.
>
> Currently, the former are still containing x86 specific code.
>
Hi Jan,
On 28/09/2020 12:00, Jan Beulich wrote:
There's no need to expose them.
We are going to need them for LiveUpdate and Non-cooperative Live
Migration as the save/restore is happening outside of event_fifo.c.
This is because we tried to keep all the save/restore code in a separate
On Tue, Sep 29, 2020 at 7:54 AM Durrant, Paul wrote:
>
> > -Original Message-
> > From: Lengyel, Tamas
> > Sent: 28 September 2020 15:17
> > To: p...@xen.org; xen-devel@lists.xenproject.org
> > Cc: Durrant, Paul ; 'Andrew Cooper'
> > ; 'Daniel De
> > Graaf' ; 'George Dunlap' ;
> > 'Ian
flight 155080 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155080/
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
Hi Jan,
On 28/09/2020 11:58, Jan Beulich wrote:
Before and after XSA-342 there has been an asymmetry in how not really
usable ports get treated in do_poll(): Ones beyond a certain boundary
(max_evtchns originally, valid_evtchns subsequently) did get refused
with -EINVAL, while lower ones were
Quoting Christoph Hellwig (2020-09-28 15:37:41)
> On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote:
> > I think we have a gap that after splitting the drm-intel-next pull requests
> > into
> > two the drm-intel/for-linux-next branch is now missing material from
> >
On 21.09.2020 13:51, Trammell Hudson wrote:
> The config file, kernel, initrd, etc should only be freed if they
> are allocated with the UEFI allocator.
>
> Signed-off-by: Trammell Hudson
> Reviewed-by: Roger Pau Monné
Strictly speaking with the changes done from v5 to v6 this tag
would have
Hello
> On 26 Sep 2020, at 9:55 pm, Julien Grall wrote:
>
> From: Julien Grall
>
> Dom0less requires a device-tree. However, since commit 6e3e77120378
> "xen/arm: setup: Relocate the Device-Tree later on in the boot", the
> device-tree will not get unflatten when using ACPI.
>
> This will
On 29.09.2020 14:26, Julien Grall wrote:
> On 28/09/2020 12:00, Jan Beulich wrote:
>> There's no need to expose them.
>
> We are going to need them for LiveUpdate and Non-cooperative Live
> Migration as the save/restore is happening outside of event_fifo.c.
>
> This is because we tried to keep
On 29.09.2020 15:03, Julien Grall wrote:
> On 28/09/2020 12:02, Jan Beulich wrote:
>> There's no need to serialize all sending of vIRQ-s; all that's needed
>> is serialization against the closing of the respective event channels
>> (by means of a barrier). To facilitate the conversion, introduce a
Hi Jan,
On 28/09/2020 11:56, Jan Beulich wrote:
Callers have no business knowing the state of the Xen end of an event
channel.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -933,6 +933,11 @@ int
On Mon, Sep 21, 2020 at 12:05:51PM +0200, Jan Beulich wrote:
> On 21.08.2020 09:45, Jan Beulich wrote:
> > On 20.08.2020 18:28, Andrew Cooper wrote:
> >> On 20/08/2020 16:34, Roger Pau Monne wrote:
> >>> Currently the dpci EOI callback is only executed for specific EOIs.
> >>> This is wrong as
On 29.09.2020 12:21, Julien Grall wrote:
> On 28/09/2020 11:57, Jan Beulich wrote:
>> evtchn_fifo_set_pending() (invoked with the per-channel lock held) has
>> two uses of the channel's priority field. The field gets updated by
>> evtchn_fifo_set_priority() with only the per-domain event_lock
> -Original Message-
> From: Tamas K Lengyel
> Sent: 29 September 2020 13:06
> To: Durrant, Paul
> Cc: Lengyel, Tamas ; p...@xen.org;
> xen-devel@lists.xenproject.org; Andrew
> Cooper ; Daniel De Graaf ;
> George Dunlap
> ; Ian Jackson ; Jan
> Beulich ;
> Julien Grall ; Marek
Hi Jan,
On 28/09/2020 12:01, Jan Beulich wrote:
Both evtchn->priority and evtchn->notify_vcpu_id could, prior to recent
locking adjustments, change behind the back of
evtchn_fifo_set_pending(). Neither the queue's priority nor the vCPU's
vcpu_id fields have similar properties, so they seem
flight 155016 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155016/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 154350
On 29.09.2020 12:27, Roger Pau Monné wrote:
> On Mon, Sep 21, 2020 at 12:05:51PM +0200, Jan Beulich wrote:
>> On 21.08.2020 09:45, Jan Beulich wrote:
>>> On 20.08.2020 18:28, Andrew Cooper wrote:
On 20/08/2020 16:34, Roger Pau Monne wrote:
> Currently the dpci EOI callback is only
Hi,
On 9/28/20 12:36 PM, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 28, 2020 at 07:02:19AM +0200, Jürgen Groß wrote:
>> On 27.09.20 13:14, Marek Marczykowski-Górecki wrote:
>>> Hi all,
>>>
>>> I get kernel panic on 'floppy' module load. If I blacklist the module,
>>> then everything works.
Hi Jan,
On 28/09/2020 12:02, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier). To facilitate the conversion, introduce a new
rw_barrier().
Looking at the code
On Mon, Sep 28, 2020 at 08:21:07PM +0200, David Hildenbrand wrote:
>__putback_isolated_page() already documents that pages will be placed to
>the tail of the freelist - this is, however, not the case for
>"order >= MAX_ORDER - 2" (see buddy_merge_likely()) - which should be
>the case for all
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/agC9HJZX7SuaTDV3j8rrnOqA/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the
> -Original Message-
> From: Lengyel, Tamas
> Sent: 28 September 2020 15:17
> To: p...@xen.org; xen-devel@lists.xenproject.org
> Cc: Durrant, Paul ; 'Andrew Cooper'
> ; 'Daniel De
> Graaf' ; 'George Dunlap' ;
> 'Ian Jackson'
> ; 'Jan Beulich' ; 'Julien
> Grall' ;
> 'Marek
On 9/29/20 8:09 AM, Souptick Joarder wrote:
> On Fri, Sep 11, 2020 at 8:12 PM wrote:
>>
>> On 9/6/20 2:51 AM, Souptick Joarder wrote:
>>> In 2019, we introduced pin_user_pages*() and now we are converting
>>> get_user_pages*() to the new API as appropriate. [1] & [2] could
>>> be referred for
On 29.09.20 11:36, Wei Yang wrote:
> On Mon, Sep 28, 2020 at 08:21:09PM +0200, David Hildenbrand wrote:
>> __free_pages_core() is used when exposing fresh memory to the buddy
>> during system boot and when onlining memory in generic_online_page().
>>
>> generic_online_page() is used in two cases:
On Mon, Sep 21, 2020 at 07:51:10AM -0400, Trammell Hudson wrote:
> The config file, kernel, initrd, etc should only be freed if they
> are allocated with the UEFI allocator.
>
> Signed-off-by: Trammell Hudson
> Reviewed-by: Roger Pau Monné
> ---
> xen/common/efi/boot.c | 10 ++
> 1
On 29.09.2020 12:45, Roger Pau Monné wrote:
> On Mon, Sep 21, 2020 at 07:51:10AM -0400, Trammell Hudson wrote:
>> --- a/xen/common/efi/boot.c
>> +++ b/xen/common/efi/boot.c
>> @@ -102,6 +102,7 @@ union string {
>>
>> struct file {
>> UINTN size;
>> +bool need_to_free;
>> union {
Hello,
> On 26 Sep 2020, at 9:55 pm, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 022387ee1ad3 "xen/arm: mm: Don't open-code Xen PT update in
> {set, clear}_fixmap()" enforced that each set_fixmap() should be
> paired with a clear_fixmap(). Any failure to follow the model would
>
On Fri, Sep 11, 2020 at 8:12 PM wrote:
>
>
> On 9/6/20 2:51 AM, Souptick Joarder wrote:
> > In 2019, we introduced pin_user_pages*() and now we are converting
> > get_user_pages*() to the new API as appropriate. [1] & [2] could
> > be referred for more information. This is case 5 as per document
On Mon, 2020-09-28 at 12:58 +0200, Jan Beulich wrote:
> Before and after XSA-342 there has been an asymmetry in how not
> really
> usable ports get treated in do_poll(): Ones beyond a certain boundary
> (max_evtchns originally, valid_evtchns subsequently) did get refused
> with -EINVAL, while
On 28.09.2020 13:25, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 28 September 2020 11:44
>>
>> For one it was wrong to send the request only upon a completed
>> hypercall: Even if only part of it completed before getting preempted,
>> invalidation ought to occur. Therefore fold the two
On 29.09.20 11:18, Wei Yang wrote:
> On Mon, Sep 28, 2020 at 08:21:08PM +0200, David Hildenbrand wrote:
>> Page isolation doesn't actually touch the pages, it simply isolates
>> pageblocks and moves all free pages to the MIGRATE_ISOLATE freelist.
>>
>> We already place pages to the tail of the
Hi Jan,
On 28/09/2020 11:57, Jan Beulich wrote:
evtchn_fifo_set_pending() (invoked with the per-channel lock held) has
two uses of the channel's priority field. The field gets updated by
evtchn_fifo_set_priority() with only the per-domain event_lock held,
i.e. the two reads may observe two
On Tue, Sep 29, 2020 at 12:58:20PM +0200, Jan Beulich wrote:
> On 29.09.2020 12:27, Roger Pau Monné wrote:
> > On Mon, Sep 21, 2020 at 12:05:51PM +0200, Jan Beulich wrote:
> >> On 21.08.2020 09:45, Jan Beulich wrote:
> >>> On 20.08.2020 18:28, Andrew Cooper wrote:
> On 20/08/2020 16:34, Roger
On Tue, Sep 29, 2020 at 03:27:43PM +0300, Denis Efremov wrote:
> Hi,
>
> On 9/28/20 12:36 PM, Marek Marczykowski-Górecki wrote:
> > On Mon, Sep 28, 2020 at 07:02:19AM +0200, Jürgen Groß wrote:
> >> On 27.09.20 13:14, Marek Marczykowski-Górecki wrote:
> >>> Hi all,
> >>>
> >>> I get kernel panic
On Mon, Sep 28, 2020 at 08:21:06PM +0200, David Hildenbrand wrote:
>Let's prepare for additional flags and avoid long parameter lists of bools.
>Follow-up patches will also make use of the flags in __free_pages_ok(),
>however, I wasn't able to come up with a better name for the type - should
>be
On Mon, Sep 28, 2020 at 08:21:10PM +0200, David Hildenbrand wrote:
>As we no longer shuffle via generic_online_page() and when undoing
>isolation, we can simplify the comment.
>
>We now effectively shuffle only once (properly) when onlining new
>memory.
>
>Cc: Andrew Morton
>Cc: Alexander Duyck
Hi Jan,
On 28/09/2020 11:57, Jan Beulich wrote:
While there don't look to be any problems with this right now, the lock
order implications from holding the lock can be very difficult to follow
(and may be easy to violate unknowingly).
I think this is a good idea given that we are disabling
On 29.09.2020 12:16, Julien Grall wrote:
> On 28/09/2020 11:57, Jan Beulich wrote:
>> While there don't look to be any problems with this right now, the lock
>> order implications from holding the lock can be very difficult to follow
>> (and may be easy to violate unknowingly).
>
> I think this
On Tue, Sep 29, 2020 at 01:00:06PM +0200, Jan Beulich wrote:
> On 29.09.2020 12:45, Roger Pau Monné wrote:
> > On Mon, Sep 21, 2020 at 07:51:10AM -0400, Trammell Hudson wrote:
> >> --- a/xen/common/efi/boot.c
> >> +++ b/xen/common/efi/boot.c
> >> @@ -102,6 +102,7 @@ union string {
> >>
> >>
Hi,
On 28/09/2020 12:00, Jan Beulich wrote:
There's no ECS_CLOSED; correct a comment naming it.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers,
--
Julien Grall
On Mon, Mar 23, 2020 at 01:09:49AM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 19, 2020 at 01:28:10AM +0100, Dario Faggioli wrote:
> > [Adding Juergen]
> >
> > On Wed, 2020-03-18 at 23:10 +0100, Marek Marczykowski-Górecki wrote:
> > > On Wed, Mar 18, 2020 at 02:50:52PM +, Andrew
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
Nested Virt is the final special case in legacy CPUID handling. Pass the
(poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to break
the semantic dependency on HVM_PARAM_NESTEDHVM.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
CC: Anthony
On 29.09.20 14:41, Marek Marczykowski-Górecki wrote:
On Tue, Sep 29, 2020 at 03:27:43PM +0300, Denis Efremov wrote:
Hi,
On 9/28/20 12:36 PM, Marek Marczykowski-Górecki wrote:
On Mon, Sep 28, 2020 at 07:02:19AM +0200, Jürgen Groß wrote:
On 27.09.20 13:14, Marek Marczykowski-Górecki wrote:
Hi
On 28.09.2020 18:44, Roger Pau Monné wrote:
> On Mon, Sep 28, 2020 at 01:02:43PM +0200, Jan Beulich wrote:
>> Especially for the use in evtchn_move_pirqs() (called when moving a vCPU
>> across pCPU-s) and the ones in EOI handling in PCI pass-through code,
>> serializing perhaps an entire domain
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well.
For most GEM backends, this simply change the returned type. GEM VRAM
helpers are also updated to indicate whether the returned framebuffer
Instances of struct dma_buf_map should be useful throughout DRM's
memory management code. Furthermore, several drivers can now use
generic fbdev emulation.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 24 ++--
1 file changed, 22 insertions(+), 2
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff
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_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions.
For
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 28 ++--
drivers/gpu/drm/drm_internal.h | 5 +++--
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
Signed-off-by: Thomas Zimmermann
---
include/drm/ttm/ttm_bo_api.h | 24
flight 155018 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155018/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow210 debian-di-installfail REGR. vs. 152631
On Mon, Sep 28, 2020 at 3:49 AM Jan Beulich wrote:
>
> On 25.09.2020 20:08, Jason Andryuk wrote:
> > On Fri, Sep 25, 2020 at 12:02 PM Julien Grall wrote:
> >>
> >> Hi Jan,
> >>
> >> On 25/09/2020 16:36, Jan Beulich wrote:
> >>> On 25.09.2020 16:33, Julien Grall wrote:
> On 25/09/2020 14:58,
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 11:56
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 01/12] evtchn: refuse
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:00
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 07/12] evtchn: cut short
On Tue, Sep 29, 2020 at 5:35 PM Christian König
wrote:
>
> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
> > The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
> > from and instance of TTM's kmap_obj and initializes struct dma_buf_map
> > with these values. Helpful for
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 11:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 02/12] evtchn: avoid race in
On 29.09.2020 17:44, Paul Durrant wrote:
>> From: Xen-devel On Behalf Of Jan
>> Beulich
>> Sent: 28 September 2020 11:57
>>
>> @@ -81,7 +82,7 @@ static uint8_t get_xen_consumer(xen_even
>> for ( i = 0; i < ARRAY_SIZE(xen_consumers); i++ )
>> {
>> if ( xen_consumers[i] == NULL
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 11:58
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 04/12] evtchn:
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 11:59
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
> ; Dario Faggioli
> Subject: [PATCH 05/12]
Hi Alex,
On 29/09/2020 16:29, Alex Bennée wrote:
Julien Grall writes:
From: Julien Grall
Hi all,
Xen on ARM has been broken for quite a while on ACPI systems. This
series aims to fix it.
Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems
to only support 5.1). So I
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 11:59
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 06/12] evtchn: don't bypass
On 29.09.2020 15:48, Andrew Cooper wrote:
> --- a/tools/libs/guest/xg_cpuid_x86.c
> +++ b/tools/libs/guest/xg_cpuid_x86.c
> @@ -427,7 +427,7 @@ static int xc_cpuid_xend_policy(
>
> int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool restore,
>const
On 29.09.20 17:16, Marek Marczykowski-Górecki wrote:
On Tue, Sep 29, 2020 at 05:07:11PM +0200, Jürgen Groß wrote:
On 29.09.20 16:27, Marek Marczykowski-Górecki wrote:
On Mon, Mar 23, 2020 at 01:09:49AM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Mar 19, 2020 at 01:28:10AM +0100, Dario
On 29/09/2020 15:05, Jan Beulich wrote:
> On 29.09.2020 15:48, Andrew Cooper wrote:
>> --- a/tools/libs/guest/xg_cpuid_x86.c
>> +++ b/tools/libs/guest/xg_cpuid_x86.c
>> @@ -427,7 +427,7 @@ static int xc_cpuid_xend_policy(
>>
>> int xc_cpuid_apply_policy(xc_interface *xch, uint32_t domid, bool
On Sat, Sep 26, 2020 at 06:47:08PM -0700, Elliott Mitchell wrote:
> On the ARM device I'm trying to get operational the boot got distinctly
> further along so appears to be a distinct ACPI improvement here.
Just in case it wasn't clear, that does amount to:
Tested-by: Elliott Mitchell
Now to
On 29.09.20 16:27, Marek Marczykowski-Górecki wrote:
On Mon, Mar 23, 2020 at 01:09:49AM +0100, Marek Marczykowski-Górecki wrote:
On Thu, Mar 19, 2020 at 01:28:10AM +0100, Dario Faggioli wrote:
[Adding Juergen]
On Wed, 2020-03-18 at 23:10 +0100, Marek Marczykowski-Górecki wrote:
On Wed, Mar
On Tue, Sep 29, 2020 at 05:07:11PM +0200, Jürgen Groß wrote:
> On 29.09.20 16:27, Marek Marczykowski-Górecki wrote:
> > On Mon, Mar 23, 2020 at 01:09:49AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Thu, Mar 19, 2020 at 01:28:10AM +0100, Dario Faggioli wrote:
> > > > [Adding Juergen]
> > > >
> -Original Message-
> From: Durrant, Paul
> Sent: Tuesday, September 29, 2020 8:14 AM
> To: Tamas K Lengyel
> Cc: Lengyel, Tamas ; p...@xen.org; xen-
> de...@lists.xenproject.org; Andrew Cooper ;
> Daniel De Graaf ; George Dunlap
> ; Ian Jackson ; Jan
> Beulich ; Julien Grall ; Marek
>
Julien Grall writes:
> From: Julien Grall
>
> Hi all,
>
> Xen on ARM has been broken for quite a while on ACPI systems. This
> series aims to fix it.
>
> Unfortunately I don't have a system with ACPI v6.0 or later (QEMU seems
> to only support 5.1). So I did only some light testing.
I was
On 21.09.2020 13:51, Trammell Hudson wrote:
> @@ -624,6 +626,22 @@ static bool __init read_file(EFI_FILE_HANDLE dir_handle,
> CHAR16 *name,
> return true;
> }
>
> +static bool __init read_section(const EFI_LOADED_IMAGE *image,
> +CHAR16 *name, struct file
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
We could completely drop that if we use the same
> -Original Message-
> From: Xen-devel On Behalf Of Jan
> Beulich
> Sent: 28 September 2020 12:00
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; George Dunlap
> ; Ian
> Jackson ; Julien Grall ; Wei Liu
> ; Stefano Stabellini
>
> Subject: [PATCH 08/12] evtchn: ECS_CLOSED =>
Hi Jan,
On 29/09/2020 14:37, Jan Beulich wrote:
On 29.09.2020 15:03, Julien Grall wrote:
On 28/09/2020 12:02, Jan Beulich wrote:
There's no need to serialize all sending of vIRQ-s; all that's needed
is serialization against the closing of the respective event channels
(by means of a barrier).
On Tuesday, September 29, 2020 6:17 AM, Jan Beulich wrote:
> On 21.09.2020 13:51, Trammell Hudson wrote:
> [...]
> > Reviewed-by: Roger Pau Monné roger@citrix.com
>
> Strictly speaking with the changes done from v5 to v6 this tag
> would have needed dropping. I guess Roger is fine with it
Julien Grall writes:
> Hi Alex,
>
> On 29/09/2020 16:29, Alex Bennée wrote:
>>
>> Julien Grall writes:
>>
>>> From: Julien Grall
>>>
>>> Hi all,
>>>
>>> Xen on ARM has been broken for quite a while on ACPI systems. This
>>> series aims to fix it.
>>>
>>> Unfortunately I don't have a system
On Tuesday, September 29, 2020 11:37 AM, Jan Beulich wrote:
> On 21.09.2020 13:51, Trammell Hudson wrote:
> [...]
> > - file->need_to_free = false;
>
> In patch 2 you don't bother clearing the field, presumably because
> it's static data and hence zero-filled anyway. This same assumption
>
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
> Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
>> The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
>> from and instance of TTM's kmap_obj and initializes struct dma_buf_map
>> with these values. Helpful for
flight 155089 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155089/
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
The config file, kernel, initrd, etc should only be freed if they
are allocated with the UEFI allocator. On x86 the ucode, and on
ARM the dtb, are also marked as need_to_free.
Signed-off-by: Trammell Hudson
---
xen/arch/arm/efi/efi-boot.h | 2 +-
xen/arch/x86/efi/efi-boot.h | 2 +-
This patch adds support for bundling the xen.efi hypervisor, the xen.cfg
configuration file, the Linux kernel and initrd, as well as the XSM,
and architectural specific files into a single "unified" EFI executable.
This allows an administrator to update the components independently
without
If a unified Xen image is used, then the bundled configuration,
Xen command line, dom0 kernel, and ramdisk are prefered over
any files listed in the config file or provided on the command line.
Unlike the shim based verification, the PE signature on a unified image
covers all of the
branch xen-4.11-testing
xenbranch xen-4.11-testing
job test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb
This patch series adds support for bundling the xen.efi hypervisor,
the xen.cfg configuration file, the Linux kernel and initrd, as well
as the XSM, and architectural specific files into a single "unified"
EFI executable. This allows an administrator to update the components
independently without
Add a separate function to display the address ranges used by
the files and call `efi_arch_handle_module()` on the modules.
Signed-off-by: Trammell Hudson
Acked-by: Jan Beulich
---
xen/common/efi/boot.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff
This patch wraps the EFI OutputString() method so that they can be
called with const arguments. The OutputString method does not modify
its argument, although the prototype is missing const, so it is necssary
to cast away the const when calling it.
Signed-off-by: Trammell Hudson
---
flight 155067 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155067/
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
flight 155017 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 12 guest-start fail REGR. vs. 154611
flight 155045 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155045/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2793a49565488e419d10ba029c838f4b7efdba38
baseline version:
ovmf
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
This is the second version of providing a base to support device MSI (non
PCI based) and on top of that support for IMS (Interrupt Message Storm)
based devices in a halfways architecture independent way.
The first version can be found
flight 155020 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155020/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 154718
Tests which did not succeed,
On 29/09/2020 22:11, Alex Bennée wrote:
Hi,
> Julien Grall writes:
>
>> Hi Alex,
>>
>> On 29/09/2020 16:29, Alex Bennée wrote:
>>>
>>> Julien Grall writes:
>>>
From: Julien Grall
Hi all,
Xen on ARM has been broken for quite a while on ACPI systems. This
series
On Tue, Sep 29, 2020 at 6:00 PM wrote:
>
>
> On 9/29/20 8:09 AM, Souptick Joarder wrote:
> > On Fri, Sep 11, 2020 at 8:12 PM wrote:
> >>
> >> On 9/6/20 2:51 AM, Souptick Joarder wrote:
> >>> In 2019, we introduced pin_user_pages*() and now we are converting
> >>> get_user_pages*() to the new API
flight 155049 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155049/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 152554
test-amd64-amd64-xl-qemuu-ws16-amd64 17
1 - 100 of 105 matches
Mail list logo
