qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()


From: David Hildenbrand
Subject: Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()
Date: Fri, 28 Feb 2020 15:19:45 -0500 (EST)


> Am 28.02.2020 um 20:55 schrieb Peter Xu <address@hidden>:
> 
> On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
>> +static void qemu_vfio_dma_map_resize(QEMUVFIOState *s, void *host,
>> +                                     size_t old_size, size_t new_size)
>> +{
>> +    IOVAMapping *m;
>> +    int index = 0;
>> +
>> +    qemu_mutex_lock(&s->lock);
>> +    m = qemu_vfio_find_mapping(s, host, &index);
>> +    if (!m) {
>> +        return;
>> +    }
>> +    assert(m->size == old_size);
>> +
>> +    /* Note: Not atomic - we need a new ioctl for that. */
>> +    qemu_vfio_undo_mapping(s, m->iova, m->size);
>> +    qemu_vfio_do_mapping(s, host, m->iova, new_size);
> 
> Another way to ask my previous question 1 (in the other reply): Can we
> simply map/unmap the extra, while keep the shared untouched?

As far as I understand the kernel implementation, unfortunately no. You might 
be able to grow (by mapping the delta), but shrinking is not possible AFAIR. 
And I *think* with many resizes, there could be an issue if I remember 
correctly.

Thanks!

> 
> Thanks,
> 
>> +
>> +    m->size = new_size;
>> +    assert(qemu_vfio_verify_mappings(s));
>> +
>> +    qemu_mutex_unlock(&s->lock);
>> +}
> 
> -- 
> Peter Xu
> 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]