[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access
From: |
Alexander Graf |
Subject: |
[Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access |
Date: |
Wed, 9 Feb 2011 18:03:07 +0100 |
On 07.02.2011, at 20:56, Yoder Stuart-B08248 wrote:
>
>
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Monday, February 07, 2011 12:52 PM
>> To: Alexander Graf
>> Cc: Yoder Stuart-B08248; Wood Scott-B07421; address@hidden;
>> address@hidden; address@hidden
>> Subject: Re: RFC: New API for PPC for vcpu mmu access
>>
>> On Mon, 7 Feb 2011 17:49:51 +0100
>> Alexander Graf <address@hidden> wrote:
>>
>>>
>>> On 07.02.2011, at 17:40, Yoder Stuart-B08248 wrote:
>>>
>>>> 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.
>>
>> What happens if a get is done before the first set, and there are multiple
>> MMU type options for this hardware, with differing entry sizes?
>>
>> Qemu would have to know beforehand how large to make the buffer.
>>
>> We could say that going forward, it's expected that qemu will do a TLB set
>> (either a full one, or a lightweight alternative) after creating a vcpu.
>> For compatibility, if this doesn't happen before the vcpu is run, the TLB
>> is created and initialized as it is today, but no new Qemu-visible features
>> will be enabled that way.
>
> Since I think the normal thing Qemu would want to do is determine
> the type/size before allocating space for the TLB, we could just
> pass in NULL for tlb_data on the first set. If tlb_data is
> NULL we just set the MMU type and return the size (and type).
It could also pass in some sort of max size - as long as nobody touches that
memory it's almost for free.
Alex
- [Qemu-devel] RFC: New API for PPC for vcpu mmu access, (continued)
- [Qemu-devel] RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/02
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/02
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/02
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/03
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/04
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/07
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/07
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access,
Alexander Graf <=
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/07
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/09
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/09
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/10
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/11
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/11