| Message ID | 20250213-virtio-shm-page-size-v1-0-5ee1f9984350@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | virtio: obtain SHM page size from device | expand |
On Thu, Feb 13, 2025 at 04:49:14PM +0100, Sergio Lopez wrote: > There's an incresing number of machines supporting multiple page sizes > and, on these machines, the host and a guest can be running with > different pages sizes. > > In addition to this, there might be devices that have a required and/or > preferred page size for mapping memory. > > In this series, we extend virtio_shm_region with a field to hold the > page size. This field has a 16-bit size to accommodate into the existing > padding virtio_pci_cap, simplifying the introduction of this additional > data into the structure. The device will provide the page size in format > PAGE_SIZE >> 12. > > The series also extends the PCI and MMIO transports to obtain the > corresponding value from the device. For the PCI one, it should be safe > since we're using an existing 16-bit padding in the virtio_pci_cap > struct. For MMIO, we need to access a new register, so there's a risk > the VMM may overreact and crash the VM. I've checked libkrun, > firecracker, cloud-hypervisor and crosvm, and all of them should deal > with the unexpected MMIO read gracefully. QEMU doesn't support SHM for > the MMIO transport, so that isn't a concern either. > > How the SHM page size information is used depends on each device. Some > may silently round up allocations, some may expose this information to > userspace. This series includes a patch that extends virtio-gpu to > expose the information via the VIRTGPU_GETPARAM ioctl, as an example of > the second approach. > > This patch series is an RFC because it requires changes to the VIRTIO > specifications. This patch series will be used as a reference to > propose such changes. > > Signed-off-by: Sergio Lopez <slp@redhat.com> don't you want to negotiate the page size with the driver then? > --- > Sergio Lopez (5): > virtio_config: add page_size field to virtio_shm_region > virtio: introduce VIRTIO_F_SHM_PAGE_SIZE > virtio-pci: extend virtio_pci_cap to hold page_size > virtio-mmio: read shm region page size > drm/virtio: add VIRTGPU_PARAM_HOST_SHM_PAGE_SIZE to params > > drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++ > drivers/virtio/virtio_mmio.c | 13 +++++++++++++ > drivers/virtio/virtio_pci_modern.c | 31 ++++++++++++++++++++++++++++--- > drivers/virtio/virtio_ring.c | 2 ++ > include/linux/virtio_config.h | 1 + > include/uapi/drm/virtgpu_drm.h | 1 + > include/uapi/linux/virtio_config.h | 7 ++++++- > include/uapi/linux/virtio_mmio.h | 3 +++ > include/uapi/linux/virtio_pci.h | 2 +- > 9 files changed, 60 insertions(+), 5 deletions(-) > --- > base-commit: 4dc1d1bec89864d8076e5ab314f86f46442bfb02 > change-id: 20250213-virtio-shm-page-size-6e9a08c7ded1 > > Best regards, > -- > Sergio Lopez <slp@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes: > On Thu, Feb 13, 2025 at 04:49:14PM +0100, Sergio Lopez wrote: >> There's an incresing number of machines supporting multiple page sizes >> and, on these machines, the host and a guest can be running with >> different pages sizes. >> >> In addition to this, there might be devices that have a required and/or >> preferred page size for mapping memory. >> >> In this series, we extend virtio_shm_region with a field to hold the >> page size. This field has a 16-bit size to accommodate into the existing >> padding virtio_pci_cap, simplifying the introduction of this additional >> data into the structure. The device will provide the page size in format >> PAGE_SIZE >> 12. >> >> The series also extends the PCI and MMIO transports to obtain the >> corresponding value from the device. For the PCI one, it should be safe >> since we're using an existing 16-bit padding in the virtio_pci_cap >> struct. For MMIO, we need to access a new register, so there's a risk >> the VMM may overreact and crash the VM. I've checked libkrun, >> firecracker, cloud-hypervisor and crosvm, and all of them should deal >> with the unexpected MMIO read gracefully. QEMU doesn't support SHM for >> the MMIO transport, so that isn't a concern either. >> >> How the SHM page size information is used depends on each device. Some >> may silently round up allocations, some may expose this information to >> userspace. This series includes a patch that extends virtio-gpu to >> expose the information via the VIRTGPU_GETPARAM ioctl, as an example of >> the second approach. >> >> This patch series is an RFC because it requires changes to the VIRTIO >> specifications. This patch series will be used as a reference to >> propose such changes. >> >> Signed-off-by: Sergio Lopez <slp@redhat.com> > > > don't you want to negotiate the page size with the > driver then? It's not really a negotiation. If the device presents the feature, the driver must honor the page size, either directly by rejecting or rounding up allocations, indirectly by informing userspace, or both. If the driver can't accomodate to the page size, it must refrain from using the Shared Memory Region. Thanks, Sergio.
There's an incresing number of machines supporting multiple page sizes and, on these machines, the host and a guest can be running with different pages sizes. In addition to this, there might be devices that have a required and/or preferred page size for mapping memory. In this series, we extend virtio_shm_region with a field to hold the page size. This field has a 16-bit size to accommodate into the existing padding virtio_pci_cap, simplifying the introduction of this additional data into the structure. The device will provide the page size in format PAGE_SIZE >> 12. The series also extends the PCI and MMIO transports to obtain the corresponding value from the device. For the PCI one, it should be safe since we're using an existing 16-bit padding in the virtio_pci_cap struct. For MMIO, we need to access a new register, so there's a risk the VMM may overreact and crash the VM. I've checked libkrun, firecracker, cloud-hypervisor and crosvm, and all of them should deal with the unexpected MMIO read gracefully. QEMU doesn't support SHM for the MMIO transport, so that isn't a concern either. How the SHM page size information is used depends on each device. Some may silently round up allocations, some may expose this information to userspace. This series includes a patch that extends virtio-gpu to expose the information via the VIRTGPU_GETPARAM ioctl, as an example of the second approach. This patch series is an RFC because it requires changes to the VIRTIO specifications. This patch series will be used as a reference to propose such changes. Signed-off-by: Sergio Lopez <slp@redhat.com> --- Sergio Lopez (5): virtio_config: add page_size field to virtio_shm_region virtio: introduce VIRTIO_F_SHM_PAGE_SIZE virtio-pci: extend virtio_pci_cap to hold page_size virtio-mmio: read shm region page size drm/virtio: add VIRTGPU_PARAM_HOST_SHM_PAGE_SIZE to params drivers/gpu/drm/virtio/virtgpu_ioctl.c | 5 +++++ drivers/virtio/virtio_mmio.c | 13 +++++++++++++ drivers/virtio/virtio_pci_modern.c | 31 ++++++++++++++++++++++++++++--- drivers/virtio/virtio_ring.c | 2 ++ include/linux/virtio_config.h | 1 + include/uapi/drm/virtgpu_drm.h | 1 + include/uapi/linux/virtio_config.h | 7 ++++++- include/uapi/linux/virtio_mmio.h | 3 +++ include/uapi/linux/virtio_pci.h | 2 +- 9 files changed, 60 insertions(+), 5 deletions(-) --- base-commit: 4dc1d1bec89864d8076e5ab314f86f46442bfb02 change-id: 20250213-virtio-shm-page-size-6e9a08c7ded1 Best regards,