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.
Out of interest, can you explain why?
Sure I'll try to give an example.
a) The whole guest has "one" memory slot representing all it's
memory. Therefore some important values like guest_origin and
guest_memsize (one slot so it's just addr+size) are kept at VM level
in kvm->arch.
It should really be kept in kvm->memslots[0]->{userspace_addr,
npages}. This is common to all architectures.
As I said wanted to do that, but due to the need to relocate my work
environment to a new laptop I was a bit stalled the last few days.
A patch series implementing it in a streamlined (storing in memslots
only, slots_lock, vcpu->request, ...) way will soon appear on the list.
[...]
c) we have other code e.g. all our copy_from/to_guest stuff that uses
the kvm->arch values
You want to drop these and use kvm_read_guest() / kvm_write_guest().
I put it on my "low-prio-but-very-useful todo list" to take a look at
that too as one of the next opportunities to streamline our code.
[...]
--
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
