On 17.01.2012, at 12:31, Paul Mackerras wrote:
> On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
>
>> The thing I was getting at was not the map during the lifetime, but
>> the map during registration. Currently we have:
>>
>> 1) Set VPA to x
>> 2) Assign feature y to VPA
>> 3)
On Tue, Jan 17, 2012 at 10:27:26AM +0100, Alexander Graf wrote:
> The thing I was getting at was not the map during the lifetime, but
> the map during registration. Currently we have:
>
> 1) Set VPA to x
> 2) Assign feature y to VPA
> 3) Use VPA
>
> 1 and 2 are the slow path, 3 occurs more frequ
On 17.01.2012, at 06:56, Paul Mackerras wrote:
> On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>>
>> On 20.12.2011, at 11:22, Paul Mackerras wrote:
>
>>> @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu
>>> *vcpu,
>>>flags &= 7;
>>>if (flag
On Mon, Jan 16, 2012 at 02:04:29PM +0100, Alexander Graf wrote:
>
> On 20.12.2011, at 11:22, Paul Mackerras wrote:
> > @@ -152,6 +152,8 @@ static unsigned long do_h_register_vpa(struct kvm_vcpu
> > *vcpu,
> > flags &= 7;
> > if (flags == 0 || flags == 4)
>
> This could probably use a ne
On 20.12.2011, at 11:22, Paul Mackerras wrote:
> The PAPR API allows three sorts of per-virtual-processor areas to be
> registered (VPA, SLB shadow buffer, and dispatch trace log), and
> furthermore, these can be registered and unregistered for another
> virtual CPU. Currently we just update the
The PAPR API allows three sorts of per-virtual-processor areas to be
registered (VPA, SLB shadow buffer, and dispatch trace log), and
furthermore, these can be registered and unregistered for another
virtual CPU. Currently we just update the vcpu fields pointing to
these areas at the time of regis
