search for: umap

...ges > will be process and sent to the destination, it's not optimal. First, the likelihood of such a situation is marginal, there's no point optimizing for it specifically. And second, even if that happens, you inflate the balloon right before the migration and the free memory will get umapped very quickly, so this case is covered nicely by the same technique that works for more realistic cases, too. Roman.

...ges > will be process and sent to the destination, it's not optimal. First, the likelihood of such a situation is marginal, there's no point optimizing for it specifically. And second, even if that happens, you inflate the balloon right before the migration and the free memory will get umapped very quickly, so this case is covered nicely by the same technique that works for more realistic cases, too. Roman.

.... ; Configuration file for smbd. ; ============================================================================ [global] printing = sysv printcap name = /etc/printcap load printers = yes keepalive = 60 guest account = nobody socket options = TCP_NODELAY username map = /opt/samba/lib/umap read prediction = False oplocks = no debug level = 11 lock directory = /opt/samba/lib/locks kernel oplocks = no ole locking compatibility = no share modes = yes locking = yes strict locking = yes [pc] path = /NEWPC public = yes only guest = yes writable = yes print...

...ing through set_map() - Reuse vhost IOTLB, so for type 1), simply forward update/invalidate request via IOMMU API, for type 2), send IOTLB to vDPA device driver via set_map(), device driver may choose to send diffs or rebuild all mapping at their will Technically we can use vhost IOTLB API (map/umap) for building VHOST_SET_MEM_TABLE, but to avoid device to process the each request, it looks to me we need new UAPI which seems sub optimal. What's you thought? Thanks >

...ing through set_map() - Reuse vhost IOTLB, so for type 1), simply forward update/invalidate request via IOMMU API, for type 2), send IOTLB to vDPA device driver via set_map(), device driver may choose to send diffs or rebuild all mapping at their will Technically we can use vhost IOTLB API (map/umap) for building VHOST_SET_MEM_TABLE, but to avoid device to process the each request, it looks to me we need new UAPI which seems sub optimal. What's you thought? Thanks >

..., so for type 1), simply forward update/invalidate >> request via IOMMU API, for type 2), send IOTLB to vDPA device driver via >> set_map(), device driver may choose to send diffs or rebuild all mapping at >> their will >> >> Technically we can use vhost IOTLB API (map/umap) for building >> VHOST_SET_MEM_TABLE, but to avoid device to process the each request, it >> looks to me we need new UAPI which seems sub optimal. >> >> What's you thought? >> >> Thanks > I suspect we can't completely avoid a new UAPI. AFAIK, memory...

It is impossible to have a zero length segment in descriptor tables using "normal" segments. One of many ways to properly protect segments to zero length is to map the base to an umapped page. Create a nicer way to do this, and stop subtracting 1 from the length passed to set_limit (note calling set limit with a zero limit does something very bad! - not anymore). Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/include/asm-i386/desc.h =======...

...If anybody has turned this off please send me your configuration file. Here is the latest config file I have tried. Thanks for any help, David. [global] printing = sysv printcap name = /etc/printcap load printers = yes keepalive = 60 guest account = nobody username map = /opt/samba/lib/umap read prediction = False oplocks = no debug level = 11 lock directory = /opt/samba/lib/locks kernel oplocks = no ole locking compatibility = no share modes = yes locking = yes strict locking = yes [pc] path = /NEWPC public = yes only guest = yes writable = yes prin...

...end me their smb.conf file I would really appreciate it. Thanks in advance, David. (My current smb.conf file) [global] printing = sysv printcap name = /etc/printcap load printers = yes keepalive = 60 guest account = nobody socket options = TCP_NODELAY username map = /opt/samba/lib/umap read prediction = False oplocks = no debug level = 11 lock directory = /opt/samba/lib/locks kernel oplocks = no ole locking compatibility = no share modes = yes locking = yes strict locking = yes [pc] path = /NEWPC public = yes only guest = yes writable = yes print...

It is impossible to have a zero length segment in descriptor tables using "normal" segments. One of many ways to properly protect segments to zero length is to map the base to an umapped page. Create a nicer way to do this, and stop subtracting 1 from the length passed to set_limit (note calling set limit with a zero limit does something very bad! - not anymore). Signed-off-by: Zachary Amsden <zach@vmware.com> Index: linux-2.6.14-zach-work/include/asm-i386/desc.h =======...

..._wo32(mem, 0x0208, lower_32_bits(nv_device_resource_len(device, 1) - 1)); > - nv_wo32(mem, 0x020c, upper_32_bits(nv_device_resource_len(device, 1) - 1)); > - > - priv->base.alloc = nouveau_bar_alloc; > - priv->base.kmap = nvc0_bar_kmap; > priv->base.umap = nvc0_bar_umap; > priv->base.unmap = nvc0_bar_unmap; > priv->base.flush = nv84_bar_flush; > @@ -176,12 +177,16 @@ nvc0_bar_dtor(struct nouveau_object *object) > nouveau_gpuobj_ref(NULL, &priv->bar[1].pgd); > nouveau_gpuobj_ref(NULL, &...

...ent to the destination, it's not optimal. > > First, the likelihood of such a situation is marginal, there's no point > optimizing for it specifically. > > And second, even if that happens, you inflate the balloon right before > the migration and the free memory will get umapped very quickly, so this > case is covered nicely by the same technique that works for more > realistic cases, too. Although I wonder which is cheaper; that would be fairly expensive for the guest wouldn't it? And you'd somehow have to kick the guest before migration to do the balloo...

...rtions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c index 160d27f..9907a25 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c @@ -67,7 +67,10 @@ nv50_bar_umap(struct nouveau_bar *bar, struct nouveau_mem *mem, if (ret) return ret; - nouveau_vm_map(vma, mem); + if (mem->pages) + nouveau_vm_map_sg(vma, 0, mem->size << 12, mem); + else + nouveau_vm_map(vma, mem); return 0; } diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/nvc0....

...- Reuse vhost IOTLB, so for type 1), simply forward update/invalidate > request via IOMMU API, for type 2), send IOTLB to vDPA device driver via > set_map(), device driver may choose to send diffs or rebuild all mapping at > their will > > Technically we can use vhost IOTLB API (map/umap) for building > VHOST_SET_MEM_TABLE, but to avoid device to process the each request, it > looks to me we need new UAPI which seems sub optimal. > > What's you thought? > > Thanks I suspect we can't completely avoid a new UAPI. > > >

...pper_32_bits(priv->bar[1].pgd->addr)); - nv_wo32(mem, 0x0208, lower_32_bits(nv_device_resource_len(device, 1) - 1)); - nv_wo32(mem, 0x020c, upper_32_bits(nv_device_resource_len(device, 1) - 1)); - - priv->base.alloc = nouveau_bar_alloc; - priv->base.kmap = nvc0_bar_kmap; priv->base.umap = nvc0_bar_umap; priv->base.unmap = nvc0_bar_unmap; priv->base.flush = nv84_bar_flush; @@ -201,7 +202,9 @@ nvc0_bar_init(struct nouveau_object *object) nv_mask(priv, 0x100c80, 0x00000001, 0x00000000); nv_wr32(priv, 0x001704, 0x80000000 | priv->bar[1].mem->addr >> 12); -...

...39;s not optimal. > > > > First, the likelihood of such a situation is marginal, there's no > > point optimizing for it specifically. > > > > And second, even if that happens, you inflate the balloon right before > > the migration and the free memory will get umapped very quickly, so > > this case is covered nicely by the same technique that works for more > > realistic cases, too. > > Although I wonder which is cheaper; that would be fairly expensive for the > guest wouldn't it? And you'd somehow have to kick the guest before &...

...39;s not optimal. > > > > First, the likelihood of such a situation is marginal, there's no > > point optimizing for it specifically. > > > > And second, even if that happens, you inflate the balloon right before > > the migration and the free memory will get umapped very quickly, so > > this case is covered nicely by the same technique that works for more > > realistic cases, too. > > Although I wonder which is cheaper; that would be fairly expensive for the > guest wouldn't it? And you'd somehow have to kick the guest before &...

...pper_32_bits(priv->bar[1].pgd->addr)); - nv_wo32(mem, 0x0208, lower_32_bits(nv_device_resource_len(device, 1) - 1)); - nv_wo32(mem, 0x020c, upper_32_bits(nv_device_resource_len(device, 1) - 1)); - - priv->base.alloc = nouveau_bar_alloc; - priv->base.kmap = nvc0_bar_kmap; priv->base.umap = nvc0_bar_umap; priv->base.unmap = nvc0_bar_unmap; priv->base.flush = nv84_bar_flush; @@ -176,12 +177,16 @@ nvc0_bar_dtor(struct nouveau_object *object) nouveau_gpuobj_ref(NULL, &priv->bar[1].pgd); nouveau_gpuobj_ref(NULL, &priv->bar[1].mem); - if (priv->bar[0].vm)...

On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's point of view,

On Thu, Mar 03, 2016 at 05:46:15PM +0000, Dr. David Alan Gilbert wrote: > * Liang Li (liang.z.li at intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a lot of CPU cycles. > > > > From guest's point of view,