similar to: [RFC PATCH 02/19] drivers/vhost: Convert to use vm_account

Displaying 20 results from an estimated 200 matches similar to: "[RFC PATCH 02/19] drivers/vhost: Convert to use vm_account"

2023 Jan 24
0
[RFC PATCH 01/19] mm: Introduce vm_account
> +/** > + * vm_account_init - Initialise a new struct vm_account. > + * @vm_account: pointer to uninitialised vm_account. > + * @task: task to charge against. > + * @user: user to charge against. Must be non-NULL for VM_ACCOUNT_USER. > + * @flags: flags to use when charging to vm_account. > + * > + * Initialise a new uninitialiused struct vm_account. Takes references >
2023 Mar 24
1
[PATCH v3 8/8] vdpa_sim: add support for user VA
? 2023/3/21 23:48, Stefano Garzarella ??: > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the bus supports user VA > (e.g. vhost-vdpa). > >
2023 Mar 14
1
[PATCH v2 8/8] vdpa_sim: add support for user VA
On Thu, Mar 2, 2023 at 7:35?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: false) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the
2023 Mar 23
1
[PATCH v3 8/8] vdpa_sim: add support for user VA
On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > The new "use_va" module parameter (default: true) is used in > vdpa_alloc_device() to inform the vDPA framework that the device > supports VA. > > vringh is initialized to use VA only when "use_va" is true and the > user's mm has been bound. So, only when the
2023 Mar 21
1
[PATCH v3 4/8] vringh: support VA with iotlb
vDPA supports the possibility to use user VA in the iotlb messages. So, let's add support for user VA in vringh to use it in the vDPA simulators. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - refactored avoiding code duplication [Eugenio] v2: - replace kmap_atomic() with kmap_local_page() [see previous patch] - fix cast warnings when
2023 Mar 23
1
[PATCH v3 4/8] vringh: support VA with iotlb
On Tue, Mar 21, 2023 at 11:43?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > vDPA supports the possibility to use user VA in the iotlb messages. > So, let's add support for user VA in vringh to use it in the vDPA > simulators. > > Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> > --- > > Notes: > v3: > - refactored
2023 Mar 21
1
[PATCH v3 2/8] vhost-vdpa: use bind_mm/unbind_mm device callbacks
When the user call VHOST_SET_OWNER ioctl and the vDPA device has `use_va` set to true, let's call the bind_mm callback. In this way we can bind the device to the user address space and directly use the user VA. The unbind_mm callback is called during the release after stopping the device. Signed-off-by: Stefano Garzarella <sgarzare at redhat.com> --- Notes: v3: - added `case
2023 Mar 23
1
[PATCH v3 2/8] vhost-vdpa: use bind_mm/unbind_mm device callbacks
On Tue, Mar 21, 2023 at 11:42?PM Stefano Garzarella <sgarzare at redhat.com> wrote: > > When the user call VHOST_SET_OWNER ioctl and the vDPA device > has `use_va` set to true, let's call the bind_mm callback. > In this way we can bind the device to the user address space > and directly use the user VA. > > The unbind_mm callback is called during the release after
2020 Oct 01
0
[PATCH] vhost-vdpa: fix page pinning leakage in error path
Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have
2020 Oct 01
0
[PATCH v2] vhost-vdpa: fix page pinning leakage in error path
Pinned pages are not properly accounted particularly when mapping error occurs on IOTLB update. Clean up dangling pinned pages for the error path. As the inflight pinned pages, specifically for memory region that strides across multiple chunks, would need more than one free page for book keeping and accounting. For simplicity, pin pages for all memory in the IOVA range in one go rather than have
2023 Mar 23
2
[PATCH v3 8/8] vdpa_sim: add support for user VA
On Thu, Mar 23, 2023 at 11:42:07AM +0800, Jason Wang wrote: >On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> The new "use_va" module parameter (default: true) is used in >> vdpa_alloc_device() to inform the vDPA framework that the device >> supports VA. >> >> vringh is initialized to use VA only when
2020 Nov 03
0
[PATCH 1/2] Revert "vhost-vdpa: fix page pinning leakage in error path"
On 2020/10/30 ??3:45, Si-Wei Liu wrote: > This reverts commit 7ed9e3d97c32d969caded2dfb6e67c1a2cc5a0b1. > > Signed-off-by: Si-Wei Liu <si-wei.liu at oracle.com> > --- > drivers/vhost/vdpa.c | 119 +++++++++++++++++++++------------------------------ > 1 file changed, 48 insertions(+), 71 deletions(-) I saw this has been reverted there
2023 Mar 24
1
[PATCH v3 8/8] vdpa_sim: add support for user VA
On Fri, Mar 24, 2023 at 10:54:39AM +0800, Jason Wang wrote: >On Thu, Mar 23, 2023 at 5:50?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> On Thu, Mar 23, 2023 at 11:42:07AM +0800, Jason Wang wrote: >> >On Tue, Mar 21, 2023 at 11:48?PM Stefano Garzarella <sgarzare at redhat.com> wrote: >> >> >> >> The new "use_va"
2023 Feb 16
0
[PATCH v2] vhost/vdpa: Add MSI translation tables to iommu for software-managed MSI
? 2023/2/7 20:08, Nanyong Sun ??: > From: Rong Wang <wangrong68 at huawei.com> > > Once enable iommu domain for one device, the MSI > translation tables have to be there for software-managed MSI. > Otherwise, platform with software-managed MSI without an > irq bypass function, can not get a correct memory write event > from pcie, will not get irqs. > The solution is
2019 Sep 03
2
[RFC] Moving RELRO segment
On Fri, Aug 30, 2019 at 4:54 AM Fāng-ruì Sòng <maskray at google.com> wrote: > > > Old: R RX RW(RELRO) RW > > > New: R(R+RELRO) RX RW; R includes the traditional R part and the > > > RELRO part > > > Runtime (before relocation resolving): RW RX RW > > > Runtime (after relocation resolving): R RX RW > > > > > I actually see two
2019 Aug 28
3
[RFC] Moving RELRO segment
Hey all, TL;DR: Moving RELRO segment to be immediately after read-only segment so that the dynamic linker has the option to merge the two virtual memory areas at run time. This is an RFC for moving RELRO segment. Currently, lld orders ELF sections in the following order: R, RX, RWX, RW, and RW contains RELRO. At run time, after RELRO is write-protected, we'd have VMAs in the order of: R, RX,
2023 Mar 02
8
[PATCH v2 0/8] vdpa_sim: add support for user VA
v2: - rebased on Linus' tree, commit ae3419fbac84 ("vc_screen: don't clobber return value in vcs_read") - removed `struct task_struct *owner` param (unused for now, maybe ?useful to support cgroups) [Jason] - add unbind_mm callback [Jason] - call the new unbind_mm callback during the release [Jason] - avoid to call bind_mm callback after the reset, since the device ?is not
2023 Mar 10
0
[PATCH] vhost-vdpa: cleanup memory maps when closing vdpa fds
On Wed, Feb 15, 2023 at 01:15:55PM +0800, Longpeng (Mike, Cloud Infrastructure Service Product Dept.) wrote: > > > ? 2023/2/15 10:56, Jason Wang ??: > > On Wed, Feb 15, 2023 at 10:49 AM Longpeng (Mike, Cloud Infrastructure > > Service Product Dept.) <longpeng2 at huawei.com> wrote: > > > > > > > > > > > > ? 2023/2/15 10:00, Jason
2019 Aug 29
2
[RFC] Moving RELRO segment
On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX
2019 Aug 29
3
[RFC] Moving RELRO segment
Hello Vic, I don't have a lot to add myself. I think that majority of the input needs to come from the OS stakeholders. My main concern is if it requires work on every platform to take advantage or avoid regressions then perhaps it is worth adding as an option rather than changing the default. Some questions: - Does this need work in every OS for correctness of programs? For example you