[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: |
Fri, 11 Feb 2011 22:07:11 +0100 |
On 11.02.2011, at 21:53, Scott Wood wrote:
> On Fri, 11 Feb 2011 02:41:35 +0100
> Alexander Graf <address@hidden> wrote:
>
>>>> Maybe we should go with Avi's proposal after all and simply keep the full
>>>> soft-mmu synced between kernel and user space? That way we only need a
>>>> setup call at first, no copying in between and simply update the user
>>>> space version whenever something changes in the guest. We need to store
>>>> the TLB's contents off somewhere anyways, so all we need is an additional
>>>> in-kernel array with internal translation data, but that can be separate
>>>> from the guest visible data, right?
>
> Hmm, the idea is growing on me.
>
>> So then everything we need to get all the functionality we need is a hint
>> from kernel to user space that something changed and vice versa.
>>
>> From kernel to user space is simple. We can just document that after every
>> RUN, all fields can be modified.
>> From user space to kernel, we could modify the entries directly and then
>> pass in an ioctl that passes in a dirty bitmap to kernel space. KVM can then
>> decide what to do with it. I guess the easiest implementation for now would
>> be to ignore the bitmap and simply flush the shadow tlb.
>>
>> That gives us the flush almost for free. All we need to do is set the tlb to
>> all zeros (should be done by env init anyways) and pass in the "something
>> changed" call. KVM can then decide to simply drop all of its shadow state or
>> loop through every shadow entry and flush it individually. Maybe we should
>> give a hint on the amount of flushes, so KVM can implement some threshold.
>
> OK. We'll also need a config ioctl to specify MMU type/size and the address
> of the arrays.
Right, a setup call basically :).
Alex
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, (continued)
- [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/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 <=
- [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/13
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Scott Wood, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Alexander Graf, 2011/02/14
- [Qemu-devel] Re: RFC: New API for PPC for vcpu mmu access, Avi Kivity, 2011/02/07
- [Qemu-devel] RE: RFC: New API for PPC for vcpu mmu access, Yoder Stuart-B08248, 2011/02/07