On 26.08.22 16:32, Emanuele Giuseppe Esposito wrote: > > > Am 26/08/2022 um 16:15 schrieb David Hildenbrand: >> On 16.08.22 12:12, Emanuele Giuseppe Esposito wrote: >>> Instead of sending a single ioctl every time ->region_* or ->log_* >>> callbacks are called, "queue" all memory regions in a list that will >>> be emptied only when committing. >>> >> >> Out of interest, how many such regions does the ioctl support? As many >> as KVM theoretically supports? (32k IIRC) >> > > I assume you mean for the new ioctl, but yes that's a good question. > > The problem here is that we could have more than a single update per > memory region. So we are not limited anymore to the number of regions, > but the number of operations * number of region. > > I was thinking, maybe when pre-processing QEMU could divide a single > transaction into multiple atomic operations (ie operations on the same > memory region)? That way avoid sending a single ioctl with 32k * > #operation elements. Is that what you mean? Oh, so we're effectively collecting slot updates and not the complete "slot" view, got it. Was the kernel series already sent so I can have a look? Note that there are some possible slot updates (like a split, or a merge) that involve multiple slots and that would have to be part of the same "transaction" to be atomic. -- Thanks, David / dhildenb
