qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH RFC] memory: pause all vCPUs for the duration of memory trans


From: David Hildenbrand
Subject: Re: [PATCH RFC] memory: pause all vCPUs for the duration of memory transactions
Date: Tue, 27 Oct 2020 14:35:04 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

Same applies to all other kinds of operations (splitting, punching out,
...) as you also mentioned.

One question from a QEMU newbie though: why do you put
kvm_ioctl_inhibit_begin()/kvm_ioctl_inhibit_end() to kvm_region_resize()
only and not taking it all the way up to
memory_region_transaction_begin()/memory_region_transaction_end() to
support atomicity for all kinds of updates right away?

The clean way to implement it for memory_region_transaction_begin()/memory_region_transaction_end() is by implementing
->begin()
->commit()
callbacks for the KVM MemoryListener, and doing it in there, in KVM code.


Now, I wasn't sure how this might affect real-time workloads, where you really don't want to kick CPUs out of KVM. You can make a lot of operations without requiring this handling like

1. Adding regions (memory hotplug)
2. Removing regions (memory hotunplug)
3. Enabling/disabling dirty logging

Resize/split(/move/...) are the problematic operations where we would need that handling. Modifying the size/location of existing slots.

One way to tackle it would be to "sense" upfront if such "modifying" operations will be required, communicating that via "->begin()", and letting the KVM notifier decide based on that information whether to get everything out of KVM. Sounds feasible.


The second question is whether you plan to sumbit this any time soon)

Once we have an agreement on how to proceed, either I can try to dedicate some time, or if you have some time, you can pickup my work and make it also handle the other problematic cases (as discussed e.g., ^).

--
Thanks,

David / dhildenb




reply via email to

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