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
--
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
