On 10/15/2009 06:22 PM, Jan Kiszka wrote:
Better to split sse from fpu since we already know it is about to be
replaced.
The idea is to reuse the existing state structures, including struct
kvm_fpu. This allows to provide the avoid substates for all archs and
simplifies the migration (see my qemu conversion patch). I think, once
we need support for new/wider registers in x86, we can introduce new
KVM_X86_VCPU_STATE_FPU_WHATEVER substates that are able to replace the
old one.
Makes sense, especially if we keep the list instead of the structure.
+
+struct kvm_vcpu_substate {
+ __u32 type;
+ __u32 pad;
+ __s64 offset;
+};
+
+#define KVM_MAX_VCPU_SUBSTATES 64
+
+struct kvm_vcpu_state {
+ __u32 nsubstates; /* number of elements in substates */
+ __u32 nprocessed; /* return value: successfully processed substates */
+ struct kvm_vcpu_substate substates[0];
+};
+
Wouldn't having an ordinary struct with lots of reserved space be
simpler? If we add a bitmask, we can even selectively get/set the
fields we want (important if new state extends old state: avx vs sse).
Simpler - hmm, maybe. But also less flexible. This would establish a
static order inside this constantly growing mega struct. And a user only
interested in something small at its end would still have to allocate
memory for the whole thing (maybe megabytes in the future, who knows?).
And this mega struct will always carry all the legacy substates, even if
they aren't used anymore in practice.
I hope cpu state doesn't grow into megabytes, or we'll have problems
live migrating them. But I see your point. The initial split assumed
userspace would be interested in optimizing access (we used to have many
more exits, and really old versions relied on qemu for emulation), that
turned out not to be the case, but it's better to keep this capability
for other possible userspaces. So let's go ahead with the list.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
--
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
