Re: [PATCH 08/11] KVM: implement multiple address spaces

[Radim KrÄmÃÅ]

2015-05-18 15:48+0200, Paolo Bonzini:
> +If KVM_CAP_MULTI_ADDRESS_SPACE is available, bits 16-31 of "slot"
> +specifies the address space which is being modified.  They must be
> +less than the value that KVM_CHECK_EXTENSION returns for the
> +KVM_CAP_MULTI_ADDRESS_SPACE capability.

> +                                         Slots in separate address spaces
> +are unrelated;

I'd prefer to decouple address spaces and slots.  KVM_GET_DIRTY_LOG
could stay the same if we said that a slot can be in multiple address
spaces.  (Well, we could do that even now, by searching for slots that
differ only in address space id and pointing them to same dirty bitmap.
This even makes sense, which is a sign of lacking design :)

The main drawback is that forcing decoupling on existing IOCTLs would be
really awkward ... we'd need to have new API for address spaces;
there are two basic operations on an address space:
  add and remove slot (needs: slot id, address space id)
which would give roughly the same functionality as this patch.
(To maximixe compatibility, there could be a default address space and a
 slot flag that doesn't automatically add it there.)

On top of this, we could allow hierarchical address spaces, so very similar
address spaces (like SMM) would be easier to set up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/