On 29.09.2020 20:17, Trammell Hudson wrote:
> 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 i
On 29.09.2020 20:17, Trammell Hudson wrote:
> 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
non-Arm parts:
Reviewed-by: Jan Be
On Tue, Sep 29 2020 at 16:03, Megha Dey wrote:
> On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
>> #9 is obviously just for the folks interested in IMS
>>
>
> I see that the tip tree (as of 9/29) has most of these patches but
> notice that the DEV_MSI related patches
>
> haven't made it. I have te
On 29.09.2020 18:31, Paul Durrant wrote:
>> -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
On 29.09.2020 18:31, Paul Durrant wrote:
>> -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
On 29.09.2020 19:18, Julien Grall wrote:
> On 29/09/2020 14:37, Jan Beulich wrote:
>> On 29.09.2020 15:03, Julien Grall wrote:
>>> I am thinking that it may be easier to hold the write lock when doing
>>> the update.
>>
>> ... perhaps this is indeed better. I have to admit that I never
>> fully und
On 29.09.2020 19:20, Jason Andryuk wrote:
> On Mon, Sep 28, 2020 at 3:49 AM Jan Beulich wrote:
>> On 25.09.2020 20:08, Jason Andryuk wrote:
>>> Also, a domain label can transition (change) at runtime.
>>> Dropping the send check would latch the permission at bind time which
>>> would not necessar
flight 155052 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx broken
test-amd64-i386-xl-qemut-debianhvm-i3
flight 155021 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/155021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 6 xen-install fail REGR.
vs. 152332
test-amd
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 g
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 dd5c7e3c5282b084daa5b
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
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 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
test-amd64-i386-li
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 ai
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, b
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 here
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
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 https://gitlab.com/keycod
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 1
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 Xen+config+ker
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
---
xen/common/
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 +-
xen/common
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 requirin
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
> would
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 bein
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 TTM-bas
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,
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).
> -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 evtc
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 di
> -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 u
> -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 =>
> -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] evtch
> -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: evtchn_set_pri
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
test-amd64-i386-x
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: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 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 TTM-ba
> -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 EVTCHNO
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 *f
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 struct
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 hop
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 lo
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 re
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 Fag
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]
> > > >
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 to
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 modi
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 +++--
drivers/gpu/d
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
ad
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 deletions
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 --gi
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 drivers
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
include
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 18
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 isn
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 Coo
> -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
> M
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 uint3
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
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.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 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 b
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 lower
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 a
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
tes
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
> > drm-intel/drm-int
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
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 mo
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 bette
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: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
dir
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
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 1
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 ac
> -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 Marczykow
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 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
> -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 Marczykowski-G
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 held,
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
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
> resu
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 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 document.
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 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 {
> >>
> >> stru
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 {
>>
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 executed
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 is
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 file
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 non-
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 diffe
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 ne
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 int
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 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 free
1 - 100 of 112 matches
Mail list logo