Am 26/08/2022 um 16:44 schrieb David Hildenbrand: > 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? I am going to send it today. I got something working, but it's a little bit messy on the invalid slots part. > > 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. > > Limiting the size of operations in the IOCTL can be something for the future. Currently it's already pretty complicated as it is (in the KVM side), plus I don't see ioctls with more than 8 requests. Thank you, Emanuele
