similar to: [PATCH] vhost_vdpa: Fix potential underflow in vhost_vdpa_mmap()

Given the need for 4K doorbell such that QEMU can easily map, ect, and assuming that I have a HW device which exposes 2 VQ's, with a notification area off of BAR3, offset=whatever, notifier_multiplier=4, we don't need to have 2 x 4K pages mapped into the VM for both doorbells do we? The guest driver would ring DB0 at BAR4+offset, and DB1 at BAR4+offset+(4*1). The 4K per DB is useful how?

Currently the doorbell is relayed via eventfd which may have significant overhead because of the cost of vmexits or syscall. This patch introduces mmap() based doorbell mapping which can eliminate the overhead caused by vmexit or syscall. To ease the userspace modeling of the doorbell layout (usually virtio-pci), this patch starts from a doorbell per page model. Vhost-vdpa only support the

On 2020/5/29 ??5:16, Mika Penttil? wrote: > Hi, > > On 29.5.2020 11.03, Jason Wang wrote: >> Currently the doorbell is relayed via eventfd which may have >> significant overhead because of the cost of vmexits or syscall. This >> patch introduces mmap() based doorbell mapping which can eliminate the >> overhead caused by vmexit or syscall. > > Just wondering.

Hi all: This series introduce basic functionality of doorbell mapping support for vhost-vDPA. Userspace program may use mmap() to map a the doorbell of a specific virtqueue into its address space. This is help to reudce the syscall or vmexit overhead. A new vdpa_config_ops was introduced to report the location of the doorbell, vhost_vdpa may then choose to map the doorbell when: - The doorbell

Hi all: This series introduce basic functionality of doorbell mapping support for vhost-vDPA. Userspace program may use mmap() to map a the doorbell of a specific virtqueue into its address space. This is help to reudce the syscall or vmexit overhead. A new vdpa_config_ops was introduced to report the location of the doorbell, vhost_vdpa may then choose to map the doorbell when: - The doorbell

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see

Hi Jason, I love your patch! Yet something to improve: [auto build test ERROR on vhost/linux-next] [also build test ERROR on linus/master v5.7 next-20200529] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop

On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >> Hi Jason, >> >> I love your patch! Yet something to improve: >> >> [auto build test ERROR on vhost/linux-next] >> [also build test ERROR on linus/master v5.7 next-20200529] >> [if your patch is applied to the wrong git tree, please drop

On 2020/6/2 ??9:31, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: >> On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: >>> On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >>>> Hi Jason, >>>> >>>> I love your patch! Yet something to improve: >>>> >>>> [auto build

On 2020/6/2 ??9:31, Michael S. Tsirkin wrote: > On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: >> On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: >>> On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: >>>> Hi Jason, >>>> >>>> I love your patch! Yet something to improve: >>>> >>>> [auto build

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: > Hi Jason, > > I love your patch! Yet something to improve: > > [auto build test ERROR on vhost/linux-next] > [also build test ERROR on linus/master v5.7 next-20200529] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system. BTW, we also suggest to use

On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: > > On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: > > > Hi Jason, > > > > > > I love your patch! Yet something to improve: > > > > > > [auto build test ERROR on vhost/linux-next] > > > [also build

On Wed, Jun 03, 2020 at 12:18:44PM +0800, Jason Wang wrote: > > On 2020/6/2 ??9:31, Michael S. Tsirkin wrote: > > On Tue, Jun 02, 2020 at 02:49:38PM +0800, Jason Wang wrote: > > > On 2020/6/2 ??12:56, Michael S. Tsirkin wrote: > > > > On Tue, Jun 02, 2020 at 03:22:49AM +0800, kbuild test robot wrote: > > > > > Hi Jason, > > > > >

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

Hi Colin, On 12 September 2017 at 10:45, Colin King <colin.king at canonical.com> wrote: > From: Colin Ian King <colin.king at canonical.com> > > Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel > log with qxl_mmap information messages. The following example code > illustrates this: > > int main(void) > { > int fd =

Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> Reviewed-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/radeon/radeon_object.h | 2 +- drivers/gpu/drm/virtio/virtgpu_drv.h