search for: kvm_set_user_memory_region

...the > problem? > > Or did I misunderstand the role of the proxy? Hi Gerd, it's starting to look to me that we're talking a bit past the other, so I have pasted below a few words describing my current plan regarding the 3 key scenarios that I'm addressing. I mention below KVM_SET_USER_MEMORY_REGION, but I guess we can discuss alternatives such as the one you are proposing using PCI BARs at a later stage. I really think that whatever we come up with needs to support 3D clients as well. Creation of shareable buffer by guest ------------------------------------------------- 1. Client requ...

...d allow qemu running > > > > independant from the desktop session. > > > > > > Regarding synchronizing buffers, this will stop becoming needed in > > > subsequent commits as all shared memory is allocated in the host and > > > mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > > > --verbose please. The qemu patches linked from the cover letter not > > exactly helpful in understanding how all this is supposed to work. > > A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it > and pass the FD to the compositor (via...

...d allow qemu running > > > > independant from the desktop session. > > > > > > Regarding synchronizing buffers, this will stop becoming needed in > > > subsequent commits as all shared memory is allocated in the host and > > > mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > > > --verbose please. The qemu patches linked from the cover letter not > > exactly helpful in understanding how all this is supposed to work. > > A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it > and pass the FD to the compositor (via...

...qemu to get access to the buffers. The later would allow qemu running > > independant from the desktop session. > > Regarding synchronizing buffers, this will stop becoming needed in > subsequent commits as all shared memory is allocated in the host and > mapped to the guest via KVM_SET_USER_MEMORY_REGION. --verbose please. The qemu patches linked from the cover letter not exactly helpful in understanding how all this is supposed to work. > This is already the case for buffers passed from the compositor to the > clients (see patch 2/2), and I'm working on the equivalent for buffers >...

...qemu to get access to the buffers. The later would allow qemu running > > independant from the desktop session. > > Regarding synchronizing buffers, this will stop becoming needed in > subsequent commits as all shared memory is allocated in the host and > mapped to the guest via KVM_SET_USER_MEMORY_REGION. --verbose please. The qemu patches linked from the cover letter not exactly helpful in understanding how all this is supposed to work. > This is already the case for buffers passed from the compositor to the > clients (see patch 2/2), and I'm working on the equivalent for buffers >...

...eable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical address space management is done by the guest. All pci bars are mapped by the guest firmware for example (or by the guest OS in...

...eable buffer by guest > ------------------------------------------------- > > 1. Client requests virtio driver to create a buffer suitable for sharing > with host (DRM_VIRTGPU_RESOURCE_CREATE) client or guest proxy? > 4. QEMU maps that buffer to the guest's address space > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver That part is problematic. The host can't simply allocate something in the physical address space, because most physical address space management is done by the guest. All pci bars are mapped by the guest firmware for example (or by the guest OS in...

...s to the buffers. The later would allow qemu running >>> independant from the desktop session. >> >> Regarding synchronizing buffers, this will stop becoming needed in >> subsequent commits as all shared memory is allocated in the host and >> mapped to the guest via KVM_SET_USER_MEMORY_REGION. > > --verbose please. The qemu patches linked from the cover letter not > exactly helpful in understanding how all this is supposed to work. A client will allocate a buffer with DRM_VIRTGPU_RESOURCE_CREATE, export it and pass the FD to the compositor (via the proxy). During resource c...

...has to create > the shareable buffer and keep it in sync with the client's non-shareable > buffer at the right times, by intercepting wl_surface.commit messages and > copying buffer contents. Ok. > > > 4. QEMU maps that buffer to the guest's address space > > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver > > > > That part is problematic. The host can't simply allocate something in > > the physical address space, because most physical address space > > management is done by the guest. All pci bars are mapped by the guest >...

...has to create > the shareable buffer and keep it in sync with the client's non-shareable > buffer at the right times, by intercepting wl_surface.commit messages and > copying buffer contents. Ok. > > > 4. QEMU maps that buffer to the guest's address space > > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver > > > > That part is problematic. The host can't simply allocate something in > > the physical address space, because most physical address space > > management is done by the guest. All pci bars are mapped by the guest >...

...hinking of clients that would allocate the buffer for wl_shm_pool with DRM_VIRTGPU_RESOURCE_CREATE or equivalent. Then that buffer would be exported and the fd passed using the standard wl_shm protocol. >>>> 4. QEMU maps that buffer to the guest's address space >>>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver >>> >>> That part is problematic. The host can't simply allocate something in >>> the physical address space, because most physical address space >>> management is done by the guest. All pci bars are mapped by the...

...t's the guest proxy what has to create the shareable buffer and keep it in sync with the client's non-shareable buffer at the right times, by intercepting wl_surface.commit messages and copying buffer contents. >> 4. QEMU maps that buffer to the guest's address space >> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver > > That part is problematic. The host can't simply allocate something in > the physical address space, because most physical address space > management is done by the guest. All pci bars are mapped by the guest > firmware for exampl...

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers available in both

Hi, Sorry for joining the party late. Had a broken finger and was offline for a bunch of weeks (and a buif backlog afterwards ...). > This is to allow clients running within VMs to be able to communicate > with a compositor in the host. Clients will use the communication > protocol that the compositor supports, and virtio-gpu will assist with > making buffers available in both

...has to > create the shareable buffer and keep it in sync with the client's > non-shareable buffer at the right times, by intercepting > wl_surface.commit messages and copying buffer contents. > >>> 4. QEMU maps that buffer to the guest's address space >>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver >> >> That part is problematic.? The host can't simply allocate something in >> the physical address space, because most physical address space >> management is done by the guest.? All pci bars are mapped by the guest >>...

...has to > create the shareable buffer and keep it in sync with the client's > non-shareable buffer at the right times, by intercepting > wl_surface.commit messages and copying buffer contents. > >>> 4. QEMU maps that buffer to the guest's address space >>> (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver >> >> That part is problematic.? The host can't simply allocate something in >> the physical address space, because most physical address space >> management is done by the guest.? All pci bars are mapped by the guest >>...

...------------------------------------ > > > > 1. Client requests virtio driver to create a buffer suitable for sharing > > with host (DRM_VIRTGPU_RESOURCE_CREATE) > > client or guest proxy? > > > 4. QEMU maps that buffer to the guest's address space > > (KVM_SET_USER_MEMORY_REGION), passes the guest PFN to the virtio driver > > That part is problematic. The host can't simply allocate something in > the physical address space, because most physical address space > management is done by the guest. All pci bars are mapped by the guest > firmware for exampl...

...ntire lifetime of +the calling process. It does not have any user-visibe effect other than a small +performance penalty. + +2. ioctl calls to the kvm-vm file descriptor +KVM does support the following ioctls on s390 that are common with other +architectures and do behave the same: +KVM_CREATE_VCPU +KVM_SET_USER_MEMORY_REGION (*) see note +KVM_GET_DIRTY_LOG (**) see note + +Notes: +* kvm does only allow exactly one memory slot on s390, which has to start + at guest absolute address zero and at a user address that is aligned on any + page boundary. This hardware "limitation" allows us to have a few u...

...ntire lifetime of +the calling process. It does not have any user-visibe effect other than a small +performance penalty. + +2. ioctl calls to the kvm-vm file descriptor +KVM does support the following ioctls on s390 that are common with other +architectures and do behave the same: +KVM_CREATE_VCPU +KVM_SET_USER_MEMORY_REGION (*) see note +KVM_GET_DIRTY_LOG (**) see note + +Notes: +* kvm does only allow exactly one memory slot on s390, which has to start + at guest absolute address zero and at a user address that is aligned on any + page boundary. This hardware "limitation" allows us to have a few u...

...needs some help from > qemu to get access to the buffers. The later would allow qemu running > independant from the desktop session. Regarding synchronizing buffers, this will stop becoming needed in subsequent commits as all shared memory is allocated in the host and mapped to the guest via KVM_SET_USER_MEMORY_REGION. This is already the case for buffers passed from the compositor to the clients (see patch 2/2), and I'm working on the equivalent for buffers from the guest to the host (clients still have to create buffers with DRM_VIRTGPU_RESOURCE_CREATE but they will be only backend by host memory so no ca...