[PATCH 18/26] KVM: PPC: KVM PV guest stubs

Alexander Graf agraf at suse.de
Sun Jun 27 20:38:11 EST 2010


Am 27.06.2010 um 12:16 schrieb Avi Kivity <avi at redhat.com>:

> On 06/27/2010 12:47 PM, Alexander Graf wrote:
>>
>> Am 27.06.2010 um 10:28 schrieb Avi Kivity <avi at redhat.com>:
>>
>>> On 06/26/2010 02:25 AM, Alexander Graf wrote:
>>>> We will soon start and replace instructions from the text section  
>>>> with
>>>> other, paravirtualized versions. To ease the readability of those  
>>>> patches
>>>> I split out the generic looping and magic page mapping code out.
>>>>
>>>> This patch still only contains stubs. But at least it loops  
>>>> through the
>>>> text section :).
>>>>
>>>>
>>>> +
>>>> +static void kvm_check_ins(u32 *inst)
>>>> +{
>>>> +    u32 _inst = *inst;
>>>> +    u32 inst_no_rt = _inst&  ~KVM_MASK_RT;
>>>> +    u32 inst_rt = _inst&  KVM_MASK_RT;
>>>> +
>>>> +    switch (inst_no_rt) {
>>>> +    }
>>>> +
>>>> +    switch (_inst) {
>>>> +    }
>>>> +
>>>> +    flush_icache_range((ulong)inst, (ulong)inst + 4);
>>>> +}
>>>>
>>>
>>> Shouldn't we flush only if we patched something?
>>
>> We introduce the patching in the next patches. This is only a  
>> preparation stub.
>
> Well, unless I missed something, this remains unconditional after  
> all the patches.
>
> A helper patch(pc, replacement) could patch and flush in one go.

Oh I see what you mean. While not necessary, it would save a few  
cycles on guest bootup.

>
>>
>>>
>>>> +
>>>> +static void kvm_use_magic_page(void)
>>>> +{
>>>> +    u32 *p;
>>>> +    u32 *start, *end;
>>>> +
>>>> +    /* Tell the host to map the magic page to -4096 on all CPUs */
>>>> +
>>>> +    on_each_cpu(kvm_map_magic_page, NULL, 1);
>>>> +
>>>> +    /* Now loop through all code and find instructions */
>>>> +
>>>> +    start = (void*)_stext;
>>>> +    end = (void*)_etext;
>>>> +
>>>> +    for (p = start; p<  end; p++)
>>>> +        kvm_check_ins(p);
>>>> +}
>>>> +
>>>>
>>>
>>> Or, flush the entire thing here.
>>
>> I did that at first. It breaks. During the patching we may take  
>> interrupts (pahe faults for example) that contain just patched  
>> instructions. And really, hell breaks loose if we don't flush it  
>> immediately :). I was hoping at first a 32 bit replace would be  
>> atomic in cache, but the cpu tried to execute invalid instructions,  
>> so it must have gotten some intermediate state.
>
> Surprising.  Maybe you need a flush after writing to the out-of-line  
> code?

I do that too now :). Better flush too often that too rarely. It's not  
_that_ expensive after all.

Alex



More information about the Linuxppc-dev mailing list