Christian Ehrhardt wrote:
The bad thing on vcpu->request in that case is that I don't want the
async behaviour of vcpu->requests in that case, I want the memory slot
updated in all vcpu's when the ioctl is returning.
You mean, the hardware can access the vcpu control block even when the
vcpu is not running?
Looking at vcpu->request based solution I don't find the
synchronization I need. The changes to
vcpu->arch.guest_origin/guest_memsize and the changes to
vcpu->arch.sie_block->gmsor/gmslm need to happen without the vcpu
running.
Therefor i want the vcpu lock _before_ I update the both structs,
otherwise it could be racy (at least on s390).
On the other hand while it is very++ unlikely to happen you are still
right that it could theoretically livelock there.
I might use vcpu->request in to not enter vcpu run again after such a
"kick" out of guest state.
It would be checked on vcpu_run enter and could then drop the lock,
call schedule, relock and check the flag again until it is cleared.
I'm not yet happy with this solution as I expect it to end up in
something like a reference count which then would not fit into the
existing vcpu->request flags :-/
As I mentioned above the changes to vcpu->arch and
vcpu->arch->sie_block have to be exclusive with the vcpu not running.
If I would find something as "transport" for the information I have on
set_memory_slot (origin/size) until the next vcpu_run entry I could do
both changes there synchronously.
The information can be found in kvm->memslots.
In that case I could really use your suggested solution with
vcpu->request, kick out unconditionally and set values on next
(re-)entry.
Hmmm .. Maybe I can find all I need on reentry in vcpu->kvm->memslots[].
Err...
If I can change it that way it will definitely require some testing.
... to be continued :-)
I definitely recommend it -- would bring s390 more in line with the
other ports (I know it's a backward step for you :)
Note our plan is to change slots_lock to RCU, so it's even better if you
use memslots.
--
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
