On 08/17/2012 09:39 PM, Marcelo Tosatti wrote:
>
> Yes. Well, Avi mentioned earlier that there are users for change of GPA
> base. But, if my understanding is correct, the code that emulates
> change of BAR in QEMU is:
>
> /* now do the real mapping */
> if (r->addr != PCI_BAR_UNMAPPED) {
> memory_region_del_subregion(r->address_space, r->memory);
> }
> r->addr = new_addr;
> if (r->addr != PCI_BAR_UNMAPPED) {
> memory_region_add_subregion_overlap(r->address_space,
> r->addr, r->memory, 1);
>
> These translate to two kvm_set_user_memory ioctls.
Not directly. These functions change a qemu-internal memory map, which
is then transferred to kvm. Those two calls might be in a transaction
(they aren't now), in which case the memory map update is atomic.
So indeed we issue two ioctls now, but that's a side effect of the
implementation, not related to those two calls being separate.
>
> "> Without taking into consideration backwards compatibility, userspace
> > can first delete the slot and later create a new one.
>
> Current qemu will in fact do that. Not sure about older ones.
> "
>
> Avi, where it does that?
By "that" I meant first deleting the first slot and then creating a new one.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
