> > A fixed array does mean you wouldn't have to worry about whether qemu
> > supports the more advanced struct format if fields are added -- you
> > can just unconditionally write it, as long as it's backwards
> > compatible. Unless you hit the limit of the pre-determined array
> > size, that is. And if that gets made higher for future expansion,
> > that's even more data that has to get transferred, before it's really
> needed.
>
> Yes, it is. And I don't see how we could easily avoid it. Maybe just pass
> in a random __user pointer that we directly write to from kernel space and
> tell qemu how big and what type a tlb entry is?
>
> struct request_ppc_tlb {
> int tlb_type;
> int tlb_entries;
> uint64_t __user *tlb_data
> };
>
> in qemu:
>
> struct request_ppc_tlb req;
> reg.tlb_data = qemu_malloc(PPC_TLB_SIZE_MAX); r = do_ioctl(REQUEST_PPC_TLB,
> &req); if (r == -ENOMEM) {
> cpu_abort(env, "TLB too big");
> }
>
> switch (reg.tlb_type) {
> case PPC_TLB_xxx:
> copy_reg_to_tlb_for_xxx(env, reg.tlb_data); }
>
> something like this. Then we should be flexible enough for the foreseeable
> future and make it possible for kernel space to switch MMU modes in case we
> need that.
Suggested change to this would be to have Qemu set tlb_type as
an _input_ argument. If KVM supports it, that type gets used,
else an error is returned. This would allow Qemu to tell
the kernel what type of MMU it is prepared to support. Without
this Qemu would just have to error out if the type returned is
unknown.
Stuart
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
