similar to: [PATCH] xen/gnttab: add deferred freeing logic

Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/drivers/xen/core/gnttab.c +++ b/drivers/xen/core/gnttab.c @@ -35,6 +35,7 @@ #include <linux/sched.h> #include <linux/mm.h> #include <linux/seqlock.h> +#include <linux/timer.h> #include <xen/interface/xen.h> #include <xen/gnttab.h> #include <asm/pgtable.h> @@ -183,35 +184,119 @@ int

Add a semaphore to protect gnttab_list from exhaustion, and disable callbacks during allocation/free. Fix the network frontend accordingly. Signed-off-by: Samuel Thibault <samuel.thibault@citrix.com> diff -r bb961bda7eff extras/mini-os/gnttab.c --- a/extras/mini-os/gnttab.c Sun Nov 25 21:24:48 2007 +0000 +++ b/extras/mini-os/gnttab.c Mon Nov 26 11:50:31 2007 +0000 @@ -18,6 +18,7 @@

When using mmu interval notifiers, the underlying VMA range that the interval is tracking might be expanded or shrunk. Add a helper function to allow the interval to be updated safely from the ops->invalidate() callback in response to VMA range changes. This is effectively removing and inserting the mmu interval notifier but more efficient. Signed-off-by: Ralph Campbell <rcampbell at

From: Jason Gunthorpe <jgg at mellanox.com> Of the 13 users of mmu_notifiers, 8 of them use only invalidate_range_start/end() and immediately intersect the mmu_notifier_range with some kind of internal list of VAs. 4 use an interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list of some kind (scif_dma, vhost, gntdev, hmm) And the remaining 5 either don't use

From: Jason Gunthorpe <jgg at mellanox.com> Of the 13 users of mmu_notifiers, 8 of them use only invalidate_range_start/end() and immediately intersect the mmu_notifier_range with some kind of internal list of VAs. 4 use an interval tree (i915_gem, radeon_mn, umem_odp, hfi1). 4 use a linked list of some kind (scif_dma, vhost, gntdev, hmm) And the remaining 5 either don't use

- introduce local variables (shortcuts for frequently used <dom>->grant_table) - adjust first parameter of mapcount() - drop lock acquisition from gnttab_get_version() - remove hard tabs and adjust formatting Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Thomas <andrew.thomas@oracle.com> --- a/xen/common/grant_table.c +++ b/xen/common/grant_table.c @@

On Tue, Nov 05, 2019 at 01:23:46PM -0800, John Hubbard wrote: > On 10/28/19 1:10 PM, Jason Gunthorpe wrote: > > From: Jason Gunthorpe <jgg at mellanox.com> > > > > Now that we have KERNEL_HEADER_TEST all headers are generally compile > > tested, so relying on makefile tricks to avoid compiling code that depends > > on CONFIG_MMU_NOTIFIER is more annoying.

On 10/28/19 1:10 PM, Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Now that we have KERNEL_HEADER_TEST all headers are generally compile > tested, so relying on makefile tricks to avoid compiling code that depends > on CONFIG_MMU_NOTIFIER is more annoying. > > Instead follow the usual pattern and provide most of the header with only > the

This patch cleans up some 80-odd warnings I was seeing when compiling the xenpci driver, all completely trivial. It also replaces the use of asm for calling cpuid with the __cpuid compiler intrinsic, and modifies calling code accordingly. I''m pretty sure my mailer going to mangle the inline patch (below) so I''m attaching the pristine version. (will try to fix for next time) --

mmu_interval_notifier_remove() can't be called safely from inside the invalidate() callback because it sleeps waiting for invalidate callbacks to finish. Removals might be needed when the invalidate() callback is for munmap() (i.e., the event type MMU_NOTIFY_UNMAP), and the interval being tracked is no longer needed. Add a new function mmu_interval_notifier_put() which is safe to call from

This patch is cleaned up of the patch which was sent as http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00324.html # HG changeset patch # User yamahata@valinux.co.jp # Date 1181545986 -32400 # Node ID 69e2dd4e06c405a92717c5f1818f5096e1dc0bcd # Parent d5e0eb7dd069c0ffc1854da81aa143ccfb0ad66e make dma address conversion logic of gnttab dma arch specific. gnttab_dma_map_page() and

I haven't had enough time to fully understand the deferred logic in this change. I spotted one problem, see comments inline. On 2019-10-28 4:10 p.m., Jason Gunthorpe wrote: > From: Jason Gunthorpe <jgg at mellanox.com> > > Of the 13 users of mmu_notifiers, 8 of them use only > invalidate_range_start/end() and immediately intersect the > mmu_notifier_range with some kind

Hi, When running domUs with pygrub, I get errors: .... xen be core: xen be core: can''t open gnttab device can''t open gnttab device xen be core: xen be core: can''t open gnttab device can''t open gnttab device xen be core: xen be core: can''t open gnttab device ..... domUs start, but these errors continue on dom0 Configuration: dom0: Ubuntu 8.10

I have two dell servers running arch linux and xen 4.3 One of them had after installing lates xen 4.3 had been showing this error message" failed to add gnttab to physmap " I reverted back to git pull from 02/17/13 and virtual machines start fine. Can sommone point me in righ direction what could be causing the error message _______________________________________________ Xen-users

Legacy (non-pvops) gntdev drivers may require this operation to be performed when the number of grants intended to be used simultaneously exceeds a certain driver specific default limit, and qemu''s qdisk driver is an example of needing to do so. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- a/tools/libxc/xc_linux_osdep.c +++ b/tools/libxc/xc_linux_osdep.c @@ -541,6 +541,27 @@

This patch implements the xenidc_channel interface using grant tables but leaves the channel bring-up and tear-down sequencing to a derived class (xenidc_gnttab_channel implements that). This code is part of the implementation of the xenidc_endpoint used for interdomain communication by the USB driver. Signed-off-by: Harry Butterworth <butterwo@uk.ibm.com>

Also remove unused xenbus_{,un}map_ring(), adjust types, and clean up header inclusion. Signed-off-by: Jan Beulich <jbeulich@novell.com> --- a/drivers/xen/blkback/blkback.c +++ b/drivers/xen/blkback/blkback.c @@ -41,6 +41,8 @@ #include <linux/list.h> #include <linux/delay.h> #include <xen/balloon.h> +#include <xen/evtchn.h> +#include <xen/gnttab.h>

On Wed, Nov 06, 2019 at 09:08:07PM -0500, Jerome Glisse wrote: > > > > Extra credit: IMHO, this clearly deserves to all be in a new mmu_range_notifier.h > > header file, but I know that's extra work. Maybe later as a follow-up patch, > > if anyone has the time. > > The range notifier should get the event too, it would be a waste, i think it is > an oversight

From: Matt Wilson <msw@amazon.com> Commit f62805f1 introduced a bug where lazy MMU mode isn''t exited if a m2p_add/remove_override call fails. Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Anthony

On Wed, Nov 06, 2019 at 04:23:21PM -0800, John Hubbard wrote: > On 10/28/19 1:10 PM, Jason Gunthorpe wrote: [...] > > /** > > * enum mmu_notifier_event - reason for the mmu notifier callback > > @@ -32,6 +34,9 @@ struct mmu_notifier_range; > > * access flags). User should soft dirty the page in the end callback to make > > * sure that anyone relying on