similar to: [RFC PATCH 02/19] drivers/vhost: Convert to use 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/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). > >

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

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

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

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

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

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

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

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/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

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

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,

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

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

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

On 3/27/23 19:14, Alistair Popple wrote: > Device exclusive page table entries are used to prevent CPU access to > a page whilst it is being accessed from a device. Typically this is > used to implement atomic operations when the underlying bus does not > support atomic access. When a CPU thread encounters a device exclusive > entry it locks the page and restores the original entry

On Tue, Mar 28, 2023 at 01:14:34PM +1100, Alistair Popple wrote: > +++ b/mm/memory.c > @@ -3623,8 +3623,19 @@ static vm_fault_t remove_device_exclusive_entry(struct vm_fault *vmf) > struct vm_area_struct *vma = vmf->vma; > struct mmu_notifier_range range; > > - if (!folio_lock_or_retry(folio, vma->vm_mm, vmf->flags)) > + /* > + * We need a page reference to

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the

This series adds support for the use of user virtual addresses in the vDPA simulator devices. The main reason for this change is to lift the pinning of all guest memory. Especially with virtio devices implemented in software. The next step would be to generalize the code in vdpa-sim to allow the implementation of in-kernel software devices. Similar to vhost, but using vDPA so we can reuse the