On Thu, Mar 15, 2018 at 03:04:55PM +0000, Jean-Philippe Brucker wrote:
> Introduce memory types RAM and DEVICE, along with a way for subsystems to
> query the global memory banks. This is required by VFIO, which will need
> to pin and map guest RAM so that assigned devices can safely do DMA to it.
> Depending on the architecture, the physical map is made of either one or
> two RAM regions. In addition, this new memory types API paves the way to
> reserved memory regions introduced in a subsequent patch.
>
> For the moment we put vesa and ivshmem memory into the DEVICE category, so
> they don't have to be pinned. This means that physical devices assigned
> with VFIO won't be able to DMA to the vesa frame buffer or ivshmem. In
> order to do that, simply changing the type to "RAM" would work. But to
> keep the types consistent, it would be better to introduce flags such as
> KVM_MEM_TYPE_DMA that would complement both RAM and DEVICE type. We could
> then reuse the API for generating firmware information (that is, for x86
> bios; DT supports reserved-memory description).
>
> Reviewed-by: Punit Agrawal <punit.agrawal@xxxxxxx>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@xxxxxxx>
> ---
> arm/kvm.c | 2 +-
> hw/pci-shmem.c | 4 ++--
> hw/vesa.c | 2 +-
> include/kvm/kvm.h | 44 +++++++++++++++++++++++++++++++++++++++++++-
> kvm.c | 31 ++++++++++++++++++++++++++++++-
> mips/kvm.c | 6 +++---
> powerpc/kvm.c | 2 +-
> x86/kvm.c | 6 +++---
> 8 files changed, 84 insertions(+), 13 deletions(-)
>
> diff --git a/arm/kvm.c b/arm/kvm.c
> index 2ab436e8df5b..b824f637e3fd 100644
> --- a/arm/kvm.c
> +++ b/arm/kvm.c
> @@ -34,7 +34,7 @@ void kvm__init_ram(struct kvm *kvm)
> phys_size = kvm->ram_size;
> host_mem = kvm->ram_start;
>
> - err = kvm__register_mem(kvm, phys_start, phys_size, host_mem);
> + err = kvm__register_ram(kvm, phys_start, phys_size, host_mem);
> if (err)
> die("Failed to register %lld bytes of memory at physical "
> "address 0x%llx [err %d]", phys_size, phys_start, err);
> diff --git a/hw/pci-shmem.c b/hw/pci-shmem.c
> index 107043e9d8df..f92bc75544d7 100644
> --- a/hw/pci-shmem.c
> +++ b/hw/pci-shmem.c
> @@ -387,8 +387,8 @@ int pci_shmem__init(struct kvm *kvm)
> if (mem == NULL)
> return -EINVAL;
>
> - kvm__register_mem(kvm, shmem_region->phys_addr, shmem_region->size,
> - mem);
> + kvm__register_dev_mem(kvm, shmem_region->phys_addr, shmem_region->size,
> + mem);
> return 0;
> }
> dev_init(pci_shmem__init);
> diff --git a/hw/vesa.c b/hw/vesa.c
> index a9a1d3e2cd9b..f3c5114cf4fe 100644
> --- a/hw/vesa.c
> +++ b/hw/vesa.c
> @@ -73,7 +73,7 @@ struct framebuffer *vesa__init(struct kvm *kvm)
> if (mem == MAP_FAILED)
> ERR_PTR(-errno);
>
> - kvm__register_mem(kvm, VESA_MEM_ADDR, VESA_MEM_SIZE, mem);
> + kvm__register_dev_mem(kvm, VESA_MEM_ADDR, VESA_MEM_SIZE, mem);
>
> vesafb = (struct framebuffer) {
> .width = VESA_WIDTH,
> diff --git a/include/kvm/kvm.h b/include/kvm/kvm.h
> index 90463b8c31aa..570615664519 100644
> --- a/include/kvm/kvm.h
> +++ b/include/kvm/kvm.h
> @@ -34,6 +34,14 @@ enum {
> KVM_VMSTATE_PAUSED,
> };
>
> +enum kvm_mem_type {
> + KVM_MEM_TYPE_RAM = 1 << 1,
> + KVM_MEM_TYPE_DEVICE = 1 << 2,
Just curious, but is there a reason not to start this from '1 << 0'?
Will
