Avi Kivity wrote:
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?
No, hardware only uses it with a running vcpu, but I realised my own
fault while changing the code to vcpu->request style.
For s390 I need to update the KVM->arch and *all*
vcpu->arch->sie_block... data synchronously.
That makes the "per vcpu resync on next entry" approach not feasible.
On the other hand I realized at the same moment that the livelock should
be no issue for us, because as I mentioned:
a) only one memslot
b) a vcpu can't run without memslot
So I don't even need to kick out vcpu's, they just should not be running.
Until we ever support multiple slots, or updates of the existing single
slot this should be ok, so is the bugfix patch this should be.
To avoid a theoretical deadlock in case other code is changing (badly)
it should be fair to aquire the lock with mutex_trylock and return
-EINVAL if we did not get all locks.
[...]
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.
As long as we have the special conditions mentioned above I think its ok
to implement it the way I do it now.
I agree that if we ever support multiple memslots we should strive for a
common solution.
p.s. the second patch in the series ensures that a vcpu really never
runs without a memslot being set as this was another bug we had.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
--
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
