[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access

[Alexander Graf]

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