Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro

[Scott Wood <scottwood@freescale.com>]

On 09/12/2012 04:45 PM, Alexander Graf wrote:
> 
> 
> On 12.09.2012, at 23:38, Scott Wood <scottwood@freescale.com> wrote:
> 
>> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>>
>>>
>>> On 12.09.2012, at 15:18, Mihai Caraman <mihai.caraman@freescale.com> wrote:
>>>
>>>> The current form of DO_KVM macro restricts its use to one call per input
>>>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>>>> definition.
>>>> Duplicate calls of DO_KVM are required by distinct implementations of
>>>> exeption handlers which are delegated at runtime.
>>>
>>> Not sure I understand what you're trying to achieve here. Please elaborate ;)
>>
>> On 64-bit book3e we compile multiple versions of the TLB miss handlers,
>> and choose from them at runtime.  
> 
> Why?

Because one size does not fit all, and we try to not force a separate
kernel build based on what sort of TLB miss handler a piece of hardware
wants.  Some of the differences are too large to be sanely handled by
feature fixups.

>> Without this patch, we get duplicate
>> label errors if more than one variant of the same exception uses DO_KVM.
> 
> Makes sense. The proposed solution also looks good. Just quickly walk me through the reasoning for the runtime check again please.

To start with, you have a TLB miss handler for when partial hardware
tablewalk is used (only the final page table level is looked up in
hardware, so we still need a TLB miss handler to load indirect entries),
and one where that feature is not available.  Then you have the "bolted"
variant used by e5500, which is faster than the generic version because
it doesn't have to deal with recursive faults.  So far the bolted
version is the only one with DO_KVM.

I posted a patch to add another variant, for e6500-style hardware
tablewalk, which shares the bolted prolog/epilog (besides prolog/epilog
performance, e6500 is incompatible with the IBM tablewalk code for
various reasons).  That caused us to have two DO_KVMs for the same
exception type.

-Scott