Re: [PATCH v3 00/21] xen: simplify frontend side ring setup

value for an invalid grant reference in order to make the functions idempotent. Changes in V3: - new patches 1 and 2, comments addressed Changes in V2: - new patch 9 and related changes in patches 10-18 For the patches that I was explicitly copied on: Reviewed-by: Boris Ostrovsky

Re: [PATCH 0/5] xen: cleanup detection of non-essential pv devices

On 11/22/21 3:20 AM, Juergen Gross wrote: On 22.10.21 08:47, Juergen Gross wrote: Today the non-essential pv devices are hard coded in the xenbus driver and this list is lacking multiple entries. This series reworks the detection logic of non-essential devices by adding a flag for that

Re: [PATCH 0/5] xen: cleanup detection of non-essential pv devices

ls-front.c    |  1 +   drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++---   include/xen/xenbus.h   |  1 +   sound/xen/xen_snd_front.c  |  1 +   8 files changed, 10 insertions(+), 11 deletions(-) Any further comments? Reviewed-by: Boris Ostrovsk

Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays

On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote: >> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote: >>> So one thing that has been on my mind for a while: I'd really like >>> to kill the separate dma ops in

Re: [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

On 12/11/20 7:37 AM, Thomas Gleixner wrote: > On Fri, Dec 11 2020 at 13:10, Jürgen Groß wrote: >> On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: >>> On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu

Re: [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

On 12/10/20 2:26 PM, Thomas Gleixner wrote: > All event channel setups bind the interrupt on CPU0 or the target CPU for > percpu interrupts and overwrite the affinity mask with the corresponding > cpumask. That does not make sense. > > The XEN implementation of irqchip::irq_set_affinity()

Re: [patch 24/30] xen/events: Remove unused bind_evtchn_to_irq_lateeoi()

On 12/10/20 2:26 PM, Thomas Gleixner wrote: > Signed-off-by: Thomas Gleixner > Cc: Boris Ostrovsky > Cc: Juergen Gross > Cc: Stefano Stabellini > Cc: xen-de...@lists.xenproject.org > --- > drivers/xen/events/events_base.c |6 -- > 1 file changed, 6 deletions(

Re: [PATCH 10/11] x86/xen: open code alloc_vm_area in arch_gnttab_valloc

On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replace the last call to alloc_vm_area with an open coded version using > an iterator in struct gnttab_vm_area instead of the triple indirection > magic in alloc_vm_area. > > Signed-off-by: Christoph Hellwig Reviewed-by:

Re: [PATCH 09/11] xen/xenbus: use apply_to_page_range directly in xenbus_map_ring_pv

On 9/24/20 9:58 AM, Christoph Hellwig wrote: > Replacing alloc_vm_area with get_vm_area_caller + apply_page_range > allows to fill put the phys_addr values directly instead of doing > another loop over all addresses. > > Signed-off-by: Christoph Hellwig Reviewed-by: Boris Ostr

Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc

On 9/22/20 11:27 AM, Christoph Hellwig wrote: > On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote: >> On 9/22/20 10:58 AM, Christoph Hellwig wrote: >>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote: This will end up incrementing

Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc

On 9/22/20 10:58 AM, Christoph Hellwig wrote: > On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote: >> This will end up incrementing area->ptes pointer. So perhaps something like >> >> >> pte_t **ptes = area->ptes; >> >> if (apply_to_page_range(_mm, (unsigned

Re: [PATCH 6/6] x86/xen: open code alloc_vm_area in arch_gnttab_valloc

On 9/18/20 12:37 PM, Christoph Hellwig wrote: > > +static int gnttab_apply(pte_t *pte, unsigned long addr, void *data) > +{ > + pte_t ***p = data; > + > + **p = pte; > + (*p)++; > + return 0; > +} > + > static int arch_gnttab_valloc(struct gnttab_vm_area *area, unsigned >

Re: [PATCH v2 4/4] xen: add helpers to allocate unpopulated memory

On 7/24/20 10:34 AM, David Hildenbrand wrote: > CCing Dan > > On 24.07.20 14:42, Roger Pau Monne wrote: >> diff --git a/drivers/xen/unpopulated-alloc.c >> b/drivers/xen/unpopulated-alloc.c >> new file mode 100644 >> index ..aaa91cefbbf9 >> --- /dev/null >> +++

Re: [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert

On 11/7/19 3:36 PM, Jason Gunthorpe wrote: > On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > >>> So, I suppose it can be relaxed to a null test and a WARN_ON that it >>> hasn't changed? >> You mean >> >> if (use_pt

Re: [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert

On 11/4/19 9:31 PM, Jason Gunthorpe wrote: > On Mon, Nov 04, 2019 at 05:03:31PM -0500, Boris Ostrovsky wrote: >> On 10/28/19 4:10 PM, Jason Gunthorpe wrote: >>> @@ -445,17 +438,9 @@ static void gntdev_vma_close(struct vm_area_struct >>> *vma) >>> struct gn

Re: [PATCH v2 09/15] xen/gntdev: use mmu_range_notifier_insert

ed until the original VMA is destroyed. > > It is unclear if any of this is even sane, but at least a lot of duplicate > code is removed. I didn't have a chance to look at the patch itself yet but as a heads-up --- it crashes dom0. -boris > > Cc: Oleksandr Andrushchenko

Re: [PATCH] dma-buf: add struct dma_buf_attach_info v2

On 4/30/19 7:10 AM, Christian König wrote: > diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c > index 2c4f324f8626..cacca830b482 100644 > --- a/drivers/xen/gntdev-dmabuf.c > +++ b/drivers/xen/gntdev-dmabuf.c > @@ -608,6 +608,7 @@ dmabuf_imp_to_refs(struct gntdev_dmabuf_priv

Re: [Xen-devel][PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

On 12/18/18 11:15 AM, Noralf Trønnes wrote: > > Den 30.11.2018 08.42, skrev Oleksandr Andrushchenko: >> From: Oleksandr Andrushchenko >> >> Use page directory based shared buffer implementation >> now available as common code for Xen frontend drivers. >> >> Remove flushing of shared buffer on

Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: > Hello, Juergen, Boris! > > As this DRM part of the series is the only one which needs ack/nack > > (and it might take quite some time to complete) could we please > > merge the patches 1 and 3 now that already have ack/r-b? > TBH I am not

Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation

On 12/17/18 10:03 AM, Oleksandr Andrushchenko wrote: > On 12/17/18 4:52 PM, Boris Ostrovsky wrote: >> On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: >>> Hello, Juergen, Boris! >>> >>> As this DRM part of the series is the only one which needs ack/nack &

Re: [Xen-devel][PATCH v2 1/3] xen: Introduce shared buffer helpers for page directory...

and display > frontend drivers without functional changes with the intention > to remove shared code from the corresponding drivers. > > Signed-off-by: Oleksandr Andrushchenko Acked-by: Boris Ostrovsky ___ dri-devel mailing list dri-devel@

Re: [PATCH 0/9] Use vm_insert_range

On 11/21/18 1:24 AM, Souptick Joarder wrote: > On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder wrote: >> Previouly drivers have their own way of mapping range of >> kernel pages/memory into user vma and this was done by >> invoking vm_insert_page() within a loop. >> >> As this pattern is common

Re: [PATCH 0/9] Use vm_insert_range

On 11/21/18 2:56 PM, Souptick Joarder wrote: > On Thu, Nov 22, 2018 at 1:08 AM Boris Ostrovsky > wrote: >> On 11/21/18 1:24 AM, Souptick Joarder wrote: >>> On Thu, Nov 15, 2018 at 9:09 PM Souptick Joarder >>> wrote: >>>> Previouly drivers have their own

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/23/2018 09:26 AM, Oleksandr Andrushchenko wrote: > On 07/23/2018 11:38 AM, Oleksandr Andrushchenko wrote: >> >>> data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c: In function >>> ‘gntdev_ioctl_dmabuf_exp_from_refs’: >>> /data/upstream/linux-xen/drivers/xen/gntdev-dmabuf.c:503:6: warning:

Re: [PATCH v5 0/8] xen: dma-buf support for grant device

On 07/20/2018 05:01 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > This work is in response to my previous attempt to introduce Xen/DRM > zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based > frontends/backends. There is also an existing hyper_dmabuf

Re: [PATCH v4 0/9] xen: dma-buf support for grant device

On 07/02/2018 09:12 AM, Oleksandr Andrushchenko wrote: > On 07/02/2018 11:20 AM, Juergen Gross wrote: >> On 02/07/18 09:10, Oleksandr Andrushchenko wrote: >>> Hello, Boris, Juergen! >>> >>> Do you think I can re-base the series (which already has >>> all required R-b's from Xen community) onto the

Re: [PATCH v3 0/9] xen: dma-buf support for grant device

On 06/14/2018 02:47 AM, Oleksandr Andrushchenko wrote: > Hi, Boris! > > It seems that I have resolved all the issues now which > were mainly cleanup and code movement and 5 of 9 patches > already have r-b's. Do you, as the primary reviewer of the > series, think I can push (hopefully) the final

Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

On 06/13/2018 05:04 AM, Oleksandr Andrushchenko wrote: > On 06/13/2018 06:14 AM, Boris Ostrovsky wrote: >> >> >> On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote: >> >>>   int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 >

Re: [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality

On 06/13/2018 07:57 AM, Oleksandr Andrushchenko wrote: > On 06/13/2018 05:58 AM, Boris Ostrovsky wrote: >> >> >> On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: >>> >>> + >>> +static struct gntdev_dmabuf * >>> +dmabuf_exp_w

Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/13/2018 02:26 AM, Oleksandr Andrushchenko wrote: On 06/13/2018 03:47 AM, Boris Ostrovsky wrote: On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h new file mode 100644

Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko diff --git a/include/xen/mem-reservation.h b/include/xen/mem-reservation.h new file mode 100644 index ..e0939387278d --- /dev/null +++ b/include/xen/mem-reservation.h @@ -0,0 +1,64 @@ +/*

Re: [PATCH v3 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

. Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky with a small nit below --- drivers/xen/Kconfig | 13 ++ drivers/xen/grant-table.c | 97 +++ include/xen/grant_table.h | 18 3 files changed, 128 insertions

Re: [PATCH v3 5/9] xen/gntdev: Allow mappings for DMA buffers

* Fix this call of_dma_configure() with a NULL node to set "Fix this by calling ..." I think. +* default DMA ops. +*/ + of_dma_configure(priv->dma_dev, NULL); +#endif pr_debug("priv %p\n", priv); return 0; With

Re: [PATCH v3 6/9] xen/gntdev: Make private routines/structures accessible

+}; With that fixed, Reviewed-by: Boris Ostrovsky ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/9] xen/balloon: Share common memory reservation routines

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: One more thing: please add a comment here saying that frames array is array of PFNs (in Xen granularity), which is what XENMEM_populate_physmap requires. And remove (or update to name the actual call you are making) the corresponding

Re: [PATCH v3 9/9] xen/gntdev: Implement dma-buf import functionality

On 06/12/2018 09:42 AM, Oleksandr Andrushchenko wrote: int gntdev_dmabuf_imp_release(struct gntdev_dmabuf_priv *priv, u32 fd) { - return -EINVAL; + struct gntdev_dmabuf *gntdev_dmabuf; + struct dma_buf_attachment *attach; + struct dma_buf *dma_buf; + +

Re: [PATCH v3 8/9] xen/gntdev: Implement dma-buf export functionality

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko 1. Create a dma-buf from grant references provided by the foreign domain. By default dma-buf is backed by system memory pages, but by providing GNTDEV_DMA_FLAG_XXX flags it can also be created as

Re: [PATCH v3 7/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/12/2018 09:41 AM, Oleksandr Andrushchenko wrote: diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c index a09db23e9663..e82660d81d7e 100644 --- a/drivers/xen/gntdev.c +++ b/drivers/xen/gntdev.c @@ -48,6 +48,9 @@ #include #include "gntdev-common.h" +#ifdef

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/08/2018 01:59 PM, Stefano Stabellini wrote: >    @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)    map->unmap_ops[i].handle = map->map_ops[i].handle;    if (use_ptemod)   

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

(Stefano, question for you at the end) On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:19 AM, Boris Ostrovsky wrote: >> On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote: >>>> On

Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:48 AM, Boris Ostrovsky wrote: >> On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote: >>> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote: >>>> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko

[PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote: > On 06/07/2018 12:32 AM, Boris Ostrovsky wrote: >> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: >>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: >>>>> diff --git a/drivers/xen/gntdev.c b

Re: [PATCH v2 3/9] xen/balloon: Share common memory reservation routines

On 06/06/2018 03:24 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 07:37 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> diff --git a/include/xen/mem-reservation.h >>> b/include/xen/mem-reservation.h >>> new fil

Re: [Xen-devel] [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

On 06/06/2018 08:46 AM, Oleksandr Andrushchenko wrote: > On 06/05/2018 01:36 AM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Allow creating grant device context for use by kernel mod

Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 11:49 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> +struct gntdev_dmabuf_export_args { >> +    int dummy; >> +}; >> >> Please define the

Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote: > On 06/05/2018 01:07 AM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> + >> +static struct sg_table * >> +dmabuf_exp_ops_map_dma_buf(struct dma_buf_attachment *atta

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote: > On 06/04/2018 11:12 PM, Boris Ostrovsky wrote: >> On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: >> @@ -121,8 +146,27 @@ static void gntdev_free_map(struct grant_map *map) >>   if (map == NULL) >>    

Re: [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Allow mappings for DMA backed buffers if grant table module > supports such: this extends grant device to not only map buffers > made of balloon pages, but also from buffers allocated with > dma_alloc_xxx.

Re: [PATCH v2 8/9] xen/gntdev: Implement dma-buf import functionality

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > /* -- */ > > +static int > +dmabuf_imp_grant_foreign_access(struct page **pages, u32 *refs, > + int count, int domid) > +{ > + grant_ref_t

Re: [PATCH v2 9/9] xen/gntdev: Expose gntdev's dma-buf API for in-kernel use

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Allow creating grant device context for use by kernel modules which > require functionality, provided by gntdev. Export symbols for dma-buf > API provided by the module. Can you give an example of who'd be

Re: [PATCH v2 7/9] xen/gntdev: Implement dma-buf export functionality

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 1. Create a dma-buf from grant references provided by the foreign >domain. By default dma-buf is backed by system memory pages, but >by providing GNTDEV_DMA_FLAG_XXX flags it can also be created >

Re: [PATCH v2 4/9] xen/grant-table: Allow allocating buffers suitable for DMA

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Extend grant table module API to allow allocating buffers that can > be used for DMA operations and mapping foreign grant references > on top of those. > The resulting buffer is similar to the one allocated

Re: [PATCH v2 6/9] xen/gntdev: Add initial support for dma-buf UAPI

On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Add UAPI and IOCTLs for dma-buf grant device driver extension: > the extension allows userspace processes and kernel modules to > use Xen backed dma-buf implementation. With this extension grant >

Re: [PATCH 0/8] xen: dma-buf support for grant device

On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote: > On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote: >> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: >>> >>> >>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >>> >>>>

Re: [PATCH 0/8] xen: dma-buf support for grant device

On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote: > On 05/31/2018 04:46 AM, Boris Ostrovsky wrote: >> >> >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> >>> >>> Oleksandr Andrushchenko (8): >>>    xen/grant-table: Make set/c

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/30/2018 01:46 PM, Oleksandr Andrushchenko wrote: > On 05/30/2018 06:54 PM, Boris Ostrovsky wrote: >> >> >> BTW, I also think you can further simplify >> xenmem_reservation_va_mapping_* routines by bailing out right away if >> xen_feature(XENFEAT_auto_transl

Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote: > On 05/29/2018 10:10 PM, Boris Ostrovsky wrote: >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> +/** >> + * gnttab_dma_free_pages - free DMAable pages >> + * @args: arguments to the function >> +

Re: [PATCH 0/8] xen: dma-buf support for grant device

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: Oleksandr Andrushchenko (8): xen/grant-table: Make set/clear page private code shared xen/balloon: Move common memory reservation routines to a module xen/grant-table: Allow allocating buffers suitable for DMA xen/gntdev:

Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

On 05/30/2018 01:49 PM, Oleksandr Andrushchenko wrote: > On 05/30/2018 06:20 PM, Boris Ostrovsky wrote: >> On 05/30/2018 02:34 AM, Oleksandr Andrushchenko wrote: >>> On 05/29/2018 10:10 PM, Boris Ostrovsky wrote: >>>> On 05/25/2018 11:33 AM,

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/30/2018 04:29 AM, Oleksandr Andrushchenko wrote: > On 05/29/2018 11:03 PM, Boris Ostrovsky wrote: >> On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote: >>> On 05/29/2018 09:04 PM, Boris Ostrovsky wrote: >>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > + > +void xenmem_reservation_va_mapping_update(unsigned long count, > + struct page **pages, > + xen_pfn_t *frames) > +{ > +#ifdef CONFIG_XEN_HAVE_PVMMU > + int

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/29/2018 02:22 PM, Oleksandr Andrushchenko wrote: > On 05/29/2018 09:04 PM, Boris Ostrovsky wrote: >> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: >> @@ -463,11 +457,6 @@ static enum bp_state >> increase_reservation(unsigned long nr_pages) >>   int r

Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko Reviewed-b

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Memory {increase|decrease}_reservation and VA mappings update/reset > code used in balloon driver can be made common, so other drivers can > also re-use the same functionality without open-coding. > Create

Re: [PATCH 5/8] xen/gntdev: Add initial support for dma-buf UAPI

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > > +/* > + * Create a dma-buf [1] from grant references @refs of count @count provided > + * by the foreign domain @domid with flags @flags. > + * > + * By default dma-buf is backed by system memory pages, but by providing > + * one of the

Re: [PATCH 3/8] xen/grant-table: Allow allocating buffers suitable for DMA

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Extend grant table module API to allow allocating buffers that can > be used for DMA operations and mapping foreign grant references > on top of those. > The resulting buffer is similar to the one allocated

Re: [PATCH 4/8] xen/gntdev: Allow mappings for DMA buffers

On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote: > > struct unmap_notify { > @@ -96,10 +104,28 @@ struct grant_map { > struct gnttab_unmap_grant_ref *kunmap_ops; > struct page **pages; > unsigned long pages_vm_start; > + > +#ifdef CONFIG_XEN_GRANT_DMA_ALLOC > + /* >

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote: > On 05/21/2018 11:36 PM, Boris Ostrovsky wrote: >> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote: >>> On 05/21/2018 09:53 PM, Boris Ostrovsky wrote: >>>> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wr

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/22/2018 02:27 PM, Oleksandr Andrushchenko wrote: > On 05/22/2018 09:02 PM, Boris Ostrovsky wrote: >> On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote: >>> On 05/22/2018 05:33 PM, Boris Ostrovsky wrote: >>>> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wr

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/22/2018 11:00 AM, Oleksandr Andrushchenko wrote: > On 05/22/2018 05:33 PM, Boris Ostrovsky wrote: >> On 05/22/2018 01:55 AM, Oleksandr Andrushchenko wrote: >>> On 05/21/2018 11:36 PM, Boris Ostrovsky wrote: >>>> On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wr

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote: > On 05/19/2018 01:04 AM, Boris Ostrovsky wrote: >> On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >> >> A commit message w

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 03:13 PM, Oleksandr Andrushchenko wrote: > On 05/21/2018 09:53 PM, Boris Ostrovsky wrote: >> On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote: >>> On 05/21/2018 07:35 PM, Boris Ostrovsky wrote: >>>> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wr

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/21/2018 01:32 PM, Oleksandr Andrushchenko wrote: > On 05/21/2018 07:35 PM, Boris Ostrovsky wrote: >> On 05/21/2018 01:40 AM, Oleksandr Andrushchenko wrote: >>> On 05/19/2018 01:04 AM, Boris Ostrovsky wrote: >>>> On 05/17/2018 04:26 AM, Oleksandr Andrushchenk

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko A commit message would be useful. > > Signed-off-by: Oleksandr Andrushchenko > > for (i = 0; i < nr_pages; i++) { > -

Re: [Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 49 +++ >

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: > On 04/23/2018 02:52 PM, Wei Liu wrote: >> On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: > the gntdev. > > I think this is generic enough that it could be implemented by a > device not tied to

Re: [PATCH RESEND v2 0/2] drm/xen-front: Add support for Xen PV display frontend

On 03/13/2018 12:21 PM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello! > > Resending with all the patches squashed on Daniel's request. Which of the two series are we supposed to review? The 8-patch one or this? (I hope it's the

Re: [PATCH v3] drm/xen-front: Add support for Xen PV display frontend

. So for that you can tack on my Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote: > On 02/27/2018 01:47 AM, Boris Ostrovsky wrote: >> On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: >>> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: >>>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenk

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 05:26 PM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> +static struct xen_gem_object *gem_create(struct drm_device *dev, >>> size_t size) >>> +{ &g

Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling

On 02/23/2018 02:00 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 01:50 AM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> + >>> +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id) >>> +{ >>&g

Re: [PATCH 6/9] drm/xen-front: Introduce DRM/KMS virtual display driver

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > + > +struct drm_driver xen_drm_driver = { > + .driver_features = DRIVER_GEM | DRIVER_MODESET | > + DRIVER_PRIME | DRIVER_ATOMIC, > + .lastclose = lastclose, > +

Re: [PATCH 5/9] drm/xen-front: Implement handling of shared display buffers

On 02/23/2018 02:53 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 02:25 AM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> static int __init xen_drv_init(void) >>> { >>> +/* At the moment we only support case

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 02/23/2018 01:37 AM, Oleksandr Andrushchenko wrote: > On 02/23/2018 12:23 AM, Boris Ostrovsky wrote: >> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: >>> +static struct xenbus_driver xen_driver = { >>> +.ids = xen_drv_ids, >>> +.pro

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > +static struct xen_gem_object *gem_create(struct drm_device *dev, size_t size) > +{ > + struct xen_drm_front_drm_info *drm_info = dev->dev_private; > + struct xen_gem_object *xen_obj; > + int ret; > + > + size =

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > +static struct xenbus_driver xen_driver = { > + .ids = xen_drv_ids, > + .probe = xen_drv_probe, > + .remove = xen_drv_remove, > + .otherend_changed = backend_on_changed, What does "_on_" stand for? -boris

Re: [PATCH 4/9] drm/xen-front: Implement Xen event channel handling

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > + > +static irqreturn_t evtchnl_interrupt_ctrl(int irq, void *dev_id) > +{ > + struct xen_drm_front_evtchnl *evtchnl = dev_id; > + struct xen_drm_front_info *front_info = evtchnl->front_info; > + struct xendispl_resp *resp; > +

Re: [PATCH 3/9] drm/xen-front: Read driver configuration from Xen store

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > + > +static int cfg_connector(struct xen_drm_front_info *front_info, > + struct xen_drm_front_cfg_connector *connector, > + const char *path, int index) > +{ > + char *connector_path; > + > + connector_path =

Re: [PATCH 5/9] drm/xen-front: Implement handling of shared display buffers

On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote: > > static int __init xen_drv_init(void) > { > + /* At the moment we only support case with XEN_PAGE_SIZE == PAGE_SIZE */ > + BUILD_BUG_ON(XEN_PAGE_SIZE != PAGE_SIZE); Why BUILD_BUG_ON? This should simply not load if page sizes

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/28/2017 04:12 AM, Christian König wrote: > > > How about the attached patch? It limits the newly added MMIO space to > the upper 256GB of the address space. That should still be enough for > most devices, but we avoid both issues with Xen dom0 as most likely > problems with memory hotplug as

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 09:12 AM, Boris Ostrovsky wrote: > > > On 11/23/2017 03:11 AM, Christian König wrote: >> Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: >>> On 11/22/2017 11:54 AM, Christian König wrote: >>>> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/23/2017 03:11 AM, Christian König wrote: Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky: On 11/22/2017 11:54 AM, Christian König wrote: Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: On 11/22/2017 05:09 AM, Christian König wrote: Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 05:09 AM, Christian König wrote: > Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >> On 11/21/2017 08:34 AM, Christian König wrote: >>> Hi Boris, >>> >>> attached are two patches. >>> >>> The first one is a trivial fix fo

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/22/2017 11:54 AM, Christian König wrote: > Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky: >> On 11/22/2017 05:09 AM, Christian König wrote: >>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky: >>>> On 11/21/2017 08:34 AM, Christian König wrote: >>>&g

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

l problem was (on Xen)? Thanks. -boris > > Thanks for the help, > Christian. > > Am 20.11.2017 um 17:33 schrieb Boris Ostrovsky: >> On 11/20/2017 11:07 AM, Christian König wrote: >>> Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >>>> (and then it breaks d

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 11/20/2017 11:07 AM, Christian König wrote: > Am 20.11.2017 um 16:51 schrieb Boris Ostrovsky: >> >> (and then it breaks differently as a Xen guest --- we hung on the last >> pci_read_config_dword(), I haven't looked at this at all yet) > > Hui? How does this

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

On 10/18/2017 09:58 AM, Christian König wrote: > From: Christian König > > Most BIOS don't enable this because of compatibility reasons. > > Manually enable a 64bit BAR of 64GB size so that we have > enough room for PCI devices. > > v2: style cleanups, increase size, add