Skip to content
Snippets Groups Projects
  • David Hildenbrand's avatar
    23ad8dec
    virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE · 23ad8dec
    David Hildenbrand authored
    
    With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, we signal the VM that reading
    unplugged memory is not supported. We have to fail feature negotiation
    in case the guest does not support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE.
    
    First, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is required to properly handle
    memory backends (or architectures) without support for the shared zeropage
    in the hypervisor cleanly. Without the shared zeropage, even reading an
    unpopulated virtual memory location can populate real memory and
    consequently consume memory in the hypervisor. We have a guaranteed shared
    zeropage only on MAP_PRIVATE anonymous memory.
    
    Second, we want VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE to be the default
    long-term as even populating the shared zeropage can be problematic: for
    example, without THP support (possible) or without support for the shared
    huge zeropage with THP (unlikely), the PTE page tables to hold the shared
    zeropage entries can consume quite some memory that cannot be reclaimed
    easily.
    
    Third, there are other optimizations+features (e.g., protection of
    unplugged memory, reducing the total memory slot size and bitmap sizes)
    that will require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE.
    
    We really only support x86 targets with virtio-mem for now (and
    Linux similarly only support x86), but that might change soon, so prepare
    for different targets already.
    
    Add a new "unplugged-inaccessible" tristate property for x86 targets:
    - "off" will keep VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE unset and legacy
      guests working.
    - "on" will set VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and stop legacy guests
      from using the device.
    - "auto" selects the default based on support for the shared zeropage.
    
    Warn in case the property is set to "off" and we don't have support for the
    shared zeropage.
    
    For existing compat machines, the property will default to "off", to
    not change the behavior but eventually warn about a problematic setup.
    Short-term, we'll set the property default to "auto" for new QEMU machines.
    Mid-term, we'll set the property default to "on" for new QEMU machines.
    Long-term, we'll deprecate the parameter and disallow legacy
    guests completely.
    
    The property has to match on the migration source and destination. "auto"
    will result in the same VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE setting as long
    as the qemu command line (esp. memdev) match -- so "auto" is good enough
    for migration purposes and the parameter doesn't have to be migrated
    explicitly.
    
    Reviewed-by: default avatarMichal Privoznik <mprivozn@redhat.com>
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Message-Id: <20211217134039.29670-3-david@redhat.com>
    Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    23ad8dec
    History
    virtio-mem: Support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE
    David Hildenbrand authored
    
    With VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE, we signal the VM that reading
    unplugged memory is not supported. We have to fail feature negotiation
    in case the guest does not support VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE.
    
    First, VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE is required to properly handle
    memory backends (or architectures) without support for the shared zeropage
    in the hypervisor cleanly. Without the shared zeropage, even reading an
    unpopulated virtual memory location can populate real memory and
    consequently consume memory in the hypervisor. We have a guaranteed shared
    zeropage only on MAP_PRIVATE anonymous memory.
    
    Second, we want VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE to be the default
    long-term as even populating the shared zeropage can be problematic: for
    example, without THP support (possible) or without support for the shared
    huge zeropage with THP (unlikely), the PTE page tables to hold the shared
    zeropage entries can consume quite some memory that cannot be reclaimed
    easily.
    
    Third, there are other optimizations+features (e.g., protection of
    unplugged memory, reducing the total memory slot size and bitmap sizes)
    that will require VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE.
    
    We really only support x86 targets with virtio-mem for now (and
    Linux similarly only support x86), but that might change soon, so prepare
    for different targets already.
    
    Add a new "unplugged-inaccessible" tristate property for x86 targets:
    - "off" will keep VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE unset and legacy
      guests working.
    - "on" will set VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE and stop legacy guests
      from using the device.
    - "auto" selects the default based on support for the shared zeropage.
    
    Warn in case the property is set to "off" and we don't have support for the
    shared zeropage.
    
    For existing compat machines, the property will default to "off", to
    not change the behavior but eventually warn about a problematic setup.
    Short-term, we'll set the property default to "auto" for new QEMU machines.
    Mid-term, we'll set the property default to "on" for new QEMU machines.
    Long-term, we'll deprecate the parameter and disallow legacy
    guests completely.
    
    The property has to match on the migration source and destination. "auto"
    will result in the same VIRTIO_MEM_F_UNPLUGGED_INACCESSIBLE setting as long
    as the qemu command line (esp. memdev) match -- so "auto" is good enough
    for migration purposes and the parameter doesn't have to be migrated
    explicitly.
    
    Reviewed-by: default avatarMichal Privoznik <mprivozn@redhat.com>
    Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
    Message-Id: <20211217134039.29670-3-david@redhat.com>
    Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
    Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>