On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote: > >>> 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.
Yes, we could use the same struct for get and set. On set, it could transfer the mmu type, on get it could tell userspace the mmu type. Alex