On 15.02.2011, at 00:49, Scott Wood wrote:
> On Tue, 15 Feb 2011 00:39:51 +0100
> Alexander Graf wrote:
>
>> On 14.02.2011, at 22:16, Scott Wood wrote:
>>
>>> On Mon, 14 Feb 2011 21:19:19 +0100
>>> Alexander Graf wrote:
>> The struct name should also have
>> a version indicator - it's
On Tue, 15 Feb 2011 00:39:51 +0100
Alexander Graf wrote:
> On 14.02.2011, at 22:16, Scott Wood wrote:
>
> > On Mon, 14 Feb 2011 21:19:19 +0100
> > Alexander Graf wrote:
> The struct name should also have
> a version indicator - it's the data descriptor only a single specific
> mm
On 14.02.2011, at 22:16, Scott Wood wrote:
> On Mon, 14 Feb 2011 21:19:19 +0100
> Alexander Graf wrote:
>
>> There's no nack here :). The only thing that needs to change is the
>> anonymous part, as that's a gnu extension. Just name the structs and unions
>> and all is well.
>
> Ah, I though
On Mon, 14 Feb 2011 21:19:19 +0100
Alexander Graf wrote:
> There's no nack here :). The only thing that needs to change is the anonymous
> part, as that's a gnu extension. Just name the structs and unions and all is
> well.
Ah, I thought it was an aesthetic objection -- didn't realize it was a
On 14.02.2011, at 18:11, Scott Wood wrote:
> On Sun, 13 Feb 2011 23:43:40 +0100
> Alexander Graf wrote:
>
>>> struct kvmppc_book3e_tlb_entry {
>>>union {
>>>__u64 mas8_1;
>>>struct {
>>>__u32 mas8;
>>>__u32 mas1;
>>>};
>>>};
>>>__u64
On Sun, 13 Feb 2011 23:43:40 +0100
Alexander Graf wrote:
> > struct kvmppc_book3e_tlb_entry {
> > union {
> > __u64 mas8_1;
> > struct {
> > __u32 mas8;
> > __u32 mas1;
> > };
> > };
> > __u64 mas2;
> > un
On 12.02.2011, at 01:57, Scott Wood wrote:
> On Fri, 11 Feb 2011 22:07:11 +0100
> Alexander Graf wrote:
>
>>
>> On 11.02.2011, at 21:53, Scott Wood wrote:
>>
>>> On Fri, 11 Feb 2011 02:41:35 +0100
>>> Alexander Graf wrote:
>>>
>> Maybe we should go with Avi's proposal after all and simp
On Fri, 11 Feb 2011 22:07:11 +0100
Alexander Graf wrote:
>
> On 11.02.2011, at 21:53, Scott Wood wrote:
>
> > On Fri, 11 Feb 2011 02:41:35 +0100
> > Alexander Graf wrote:
> >
> Maybe we should go with Avi's proposal after all and simply keep the
> full soft-mmu synced between kerne
On 11.02.2011, at 21:53, Scott Wood wrote:
> On Fri, 11 Feb 2011 02:41:35 +0100
> Alexander Graf 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 cop
On Fri, 11 Feb 2011 02:41:35 +0100
Alexander Graf 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
> >> sp
On 11.02.2011, at 01:22, Alexander Graf wrote:
>
> On 11.02.2011, at 01:20, Alexander Graf wrote:
>
>>
>> On 10.02.2011, at 19:51, Scott Wood wrote:
>>
>>> On Thu, 10 Feb 2011 12:45:38 +0100
>>> Alexander Graf wrote:
>>>
Ok, thinking about this a bit more. You're basically proposing a
On 11.02.2011, at 01:20, Alexander Graf wrote:
>
> On 10.02.2011, at 19:51, Scott Wood wrote:
>
>> On Thu, 10 Feb 2011 12:45:38 +0100
>> Alexander Graf wrote:
>>
>>> Ok, thinking about this a bit more. You're basically proposing a list of
>>> tlb set calls, with each array field identifying o
On 10.02.2011, at 19:51, Scott Wood wrote:
> On Thu, 10 Feb 2011 12:45:38 +0100
> Alexander Graf wrote:
>
>> Ok, thinking about this a bit more. You're basically proposing a list of
>> tlb set calls, with each array field identifying one tlb set call. What
>> I was thinking of was a full TLB sy
On Thu, 10 Feb 2011 12:45:38 +0100
Alexander Graf wrote:
> Ok, thinking about this a bit more. You're basically proposing a list of
> tlb set calls, with each array field identifying one tlb set call. What
> I was thinking of was a full TLB sync, so we could keep qemu's internal
> TLB representat
On Thu, Feb 10, 2011 at 12:55:22PM +0100, Alexander Graf wrote:
> Scott Wood wrote:
> > On Thu, 3 Feb 2011 10:19:06 +0100
> > Alexander Graf wrote:
> >
> >
> >> Yeah, that one's tricky. Usually the way the memory resolver in qemu works
> >> is as follows:
> >>
> >> * kvm goes to qemu
> >> *
Scott Wood wrote:
> On Thu, 3 Feb 2011 10:19:06 +0100
> Alexander Graf wrote:
>
>
>> Yeah, that one's tricky. Usually the way the memory resolver in qemu works
>> is as follows:
>>
>> * kvm goes to qemu
>> * qemu fetches all mmu and register data from kvm
>> * qemu runs its mmu resolution f
Scott Wood wrote:
> On Wed, 9 Feb 2011 18:21:40 +0100
> Alexander Graf wrote:
>
>
>> On 07.02.2011, at 21:15, Scott Wood wrote:
>>
>>
>>> That's pretty much what the proposed API does -- except it uses a void
>>> pointer instead of uint64_t *.
>>>
>> Oh? Did I miss something there?
On Thu, 3 Feb 2011 10:19:06 +0100
Alexander Graf wrote:
> Yeah, that one's tricky. Usually the way the memory resolver in qemu works is
> as follows:
>
> * kvm goes to qemu
> * qemu fetches all mmu and register data from kvm
> * qemu runs its mmu resolution function as if the target was emul
On Wed, 9 Feb 2011 18:21:40 +0100
Alexander Graf wrote:
>
> On 07.02.2011, at 21:15, Scott Wood wrote:
>
> > That's pretty much what the proposed API does -- except it uses a void
> > pointer instead of uint64_t *.
>
> Oh? Did I miss something there? The proposal looked as if it only transfers
On 07.02.2011, at 21:15, Scott Wood wrote:
> On Mon, 7 Feb 2011 16:43:02 +0100
> Alexander Graf wrote:
>
>> On 04.02.2011, at 23:33, Scott Wood wrote:
>>
>>> On Thu, 3 Feb 2011 10:19:06 +0100
>>> Alexander Graf wrote:
>>>
Makes sense. So we basically need an ioctl that tells KVM the MMU
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; kvm-...@vger.kernel.org;
>> k...@vger.kernel.org; qemu-devel@nongnu.o
On 02/07/2011 07:30 PM, Yoder Stuart-B08248 wrote:
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
> On Behalf Of Avi Kivity
> Sent: Monday, February 07, 2011 11:14 AM
> To: Alexander Graf
> Cc: Wood Scott-B07421; Yoder Stuart-B0824
> > 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
> -Original Message-
> From: kvm-ppc-ow...@vger.kernel.org [mailto:kvm-ppc-ow...@vger.kernel.org]
> On Behalf Of Avi Kivity
> Sent: Monday, February 07, 2011 11:14 AM
> To: Alexander Graf
> Cc: Wood Scott-B07421; Yoder Stuart-B08248; kvm-...@vger.kernel.org;
> k...@vger.kernel.org; qemu-d
On Mon, 7 Feb 2011 17:49:51 +0100
Alexander Graf 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
On 04.02.2011, at 23:33, Scott Wood wrote:
> On Thu, 3 Feb 2011 10:19:06 +0100
> Alexander Graf wrote:
>
>> On 02.02.2011, at 23:08, Scott Wood wrote:
>>> On Wed, 2 Feb 2011 22:33:41 +0100
>>> Alexander Graf wrote:
This seems to fine-grained. I'd prefer a list of all TLB entries to be
>>
> -Original Message-
> From: Wood Scott-B07421
> Sent: Monday, February 07, 2011 12:52 PM
> To: Alexander Graf
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; kvm-...@vger.kernel.org;
> k...@vger.kernel.org; qemu-devel@nongnu.org
> Subject: Re: RFC: New API for PPC for vcpu mmu access
>
>
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
On Mon, 7 Feb 2011 16:43:02 +0100
Alexander Graf wrote:
> On 04.02.2011, at 23:33, Scott Wood wrote:
>
> > On Thu, 3 Feb 2011 10:19:06 +0100
> > Alexander Graf wrote:
> >
> >> Makes sense. So we basically need an ioctl that tells KVM the MMU type and
> >> TLB size. Remember, the userspace too
On 02/03/2011 11:19 AM, Alexander Graf wrote:
>
> I have no idea what things will look like 10 years down the road, but
> currently e500mc has 576 entries (512 TLB0, 64 TLB1).
That sums up to 64 * 576 bytes, which is 36kb. Ouch. Certainly nothing we want
to transfer every time qemu feels like
On Thu, 3 Feb 2011 10:19:06 +0100
Alexander Graf wrote:
> On 02.02.2011, at 23:08, Scott Wood wrote:
> > On Wed, 2 Feb 2011 22:33:41 +0100
> > Alexander Graf wrote:
> >> This seems to fine-grained. I'd prefer a list of all TLB entries to be
> >> pushed in either direction. What's the foreseeabl
On 02.02.2011, at 23:34, Yoder Stuart-B08248 wrote:
>
>
>> -Original Message-
>> From: Alexander Graf [mailto:ag...@suse.de]
>> Sent: Wednesday, February 02, 2011 3:34 PM
>> To: Yoder Stuart-B08248
>> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; qemu-devel@nongnu.org
>> Subject: R
On 02.02.2011, at 23:08, Scott Wood wrote:
> On Wed, 2 Feb 2011 22:33:41 +0100
> Alexander Graf wrote:
>
>>
>> On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote:
>>
>>> Below is a proposal for a new API for PPC to allow KVM clients
>>> to set MMU state in a vcpu.
>>>
>>> BookE processors ha
> -Original Message-
> From: Alexander Graf [mailto:ag...@suse.de]
> Sent: Wednesday, February 02, 2011 3:34 PM
> To: Yoder Stuart-B08248
> Cc: kvm-...@vger.kernel.org; k...@vger.kernel.org; qemu-devel@nongnu.org
> Subject: Re: RFC: New API for PPC for vcpu mmu access
>
>
> On 02.02.201
On Wed, 2 Feb 2011 22:33:41 +0100
Alexander Graf wrote:
>
> On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote:
>
> > Below is a proposal for a new API for PPC to allow KVM clients
> > to set MMU state in a vcpu.
> >
> > BookE processors have one or more software managed TLBs and
> > currently
On 02.02.2011, at 21:33, Yoder Stuart-B08248 wrote:
> Below is a proposal for a new API for PPC to allow KVM clients
> to set MMU state in a vcpu.
>
> BookE processors have one or more software managed TLBs and
> currently there is no mechanism for Qemu to initialize
> or access them. This is n
36 matches
Mail list logo
