From: Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>
To: Liu Yu-B13201 <B13201-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0
Date: Thu, 16 Sep 2010 13:44:01 +0200 [thread overview]
Message-ID: <4C920301.4060104@suse.de> (raw)
In-Reply-To: <A9833F0F7901024DA08417AA5A9887D921DD39-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
Liu Yu-B13201 wrote:
>
>
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf-l3A5Bk7waGM@public.gmane.org]
>> Sent: Friday, September 10, 2010 7:24 AM
>> To: Liu Yu-B13201
>> Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Subject: Re: [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0
>>
>>
>> On 08.09.2010, at 11:40, Liu Yu wrote:
>>
>>
>>> Current guest TLB1 is mapped to host TLB1.
>>> As host kernel only provides 4K uncontinuous pages,
>>> we have to break guest large mapping into 4K shadow mappings.
>>> These 4K shadow mappings are then mapped into host TLB1 on fly.
>>> As host TLB1 only has 13 free entries, there's serious tlb miss.
>>>
>>> Since e500v2 has a big number of TLB0 entries,
>>> it should be help to map those 4K shadow mappings to host TLB0.
>>> To achieve this, we need to unlink guest tlb and host tlb,
>>> So that guest TLB1 mappings can route to any host TLB0
>>>
>> entries freely.
>>
>>> Pages/mappings are considerred in the same kind as host tlb entry.
>>> This patch remove the link between pages and guest tlb
>>>
>> entry to do the unlink.
>>
>>> And keep host_tlb0_ref in each vcpu to trace pages.
>>> Then it's easy to map guest TLB1 to host TLB0.
>>>
>>> In guest ramdisk boot test(guest mainly uses TLB1),
>>> with this patch, the tlb miss number get down 90%.
>>>
>>> Signed-off-by: Liu Yu <yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>>> ---
>>> arch/powerpc/include/asm/kvm_e500.h | 7 +-
>>> arch/powerpc/kvm/e500.c | 4 +
>>> arch/powerpc/kvm/e500_tlb.c | 280
>>>
>> ++++++++++++-----------------------
>>
>>> arch/powerpc/kvm/e500_tlb.h | 1 +
>>> 4 files changed, 104 insertions(+), 188 deletions(-)
>>>
>>>
>
>
>>> -static unsigned int tlb1_entry_num;
>>> +static inline unsigned int get_tlb0_entry_offset(u32
>>>
>> eaddr, u32 esel)
>>
>>> +{
>>> + return ((eaddr & 0x7F000) >> (12 - host_tlb0_assoc_bit) |
>>> + (esel & (host_tlb0_assoc - 1)));
>>> +}
>>>
>>> void kvmppc_dump_tlbs(struct kvm_vcpu *vcpu)
>>> {
>>> @@ -62,11 +68,6 @@ static inline unsigned int tlb0_get_next_victim(
>>> return victim;
>>> }
>>>
>>> -static inline unsigned int tlb1_max_shadow_size(void)
>>> -{
>>> - return tlb1_entry_num - tlbcam_index;
>>> -}
>>> -
>>> static inline int tlbe_is_writable(struct tlbe *tlbe)
>>> {
>>> return tlbe->mas3 & (MAS3_SW|MAS3_UW);
>>> @@ -100,7 +101,7 @@ static inline u32
>>>
>> e500_shadow_mas2_attrib(u32 mas2, int usermode)
>>
>>> /*
>>> * writing shadow tlb entry to host TLB
>>> */
>>> -static inline void __write_host_tlbe(struct tlbe *stlbe)
>>> +static inline void __host_tlbe_write(struct tlbe *stlbe)
>>> {
>>> mtspr(SPRN_MAS1, stlbe->mas1);
>>> mtspr(SPRN_MAS2, stlbe->mas2);
>>> @@ -109,25 +110,22 @@ static inline void
>>>
>> __write_host_tlbe(struct tlbe *stlbe)
>>
>>> __asm__ __volatile__ ("tlbwe\n" : : );
>>> }
>>>
>>> -static inline void write_host_tlbe(struct kvmppc_vcpu_e500
>>>
>> *vcpu_e500,
>>
>>> - int tlbsel, int esel, struct tlbe *stlbe)
>>> +static inline u32 host_tlb0_write(struct kvmppc_vcpu_e500
>>>
>> *vcpu_e500,
>>
>>> + u32 gvaddr, struct tlbe *stlbe)
>>> {
>>> - local_irq_disable();
>>> - if (tlbsel == 0) {
>>> - __write_host_tlbe(stlbe);
>>> - } else {
>>> - unsigned register mas0;
>>> + unsigned register mas0;
>>>
>>> - mas0 = mfspr(SPRN_MAS0);
>>> + local_irq_disable();
>>>
>> Do you have to disable interrupts for a tlb write? If you get
>> preempted before the write, the entry you overwrite could be
>> different. But you don't protect against that either way. And
>> if you get preempted afterwards, you could lose the entry.
>> But since you enable interrupts beyond that, that could
>> happen either way too.
>>
>> So what's the reason for the disable here?
>>
>>
>
> Hello Alex,
>
> Doesn't local_irq_disable() also disable preempt?
> The reason to disable interrupts is because it's possible to have tlb
> misses in interrupt service route.
>
Yes, local_irq_disable disables preempt. That's exactly what I was
referring to :).
I don't understand the statement about the service route. A tlb miss
still arrives with local_irq_disable.
Alex
next prev parent reply other threads:[~2010-09-16 11:44 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-08 9:40 [PATCH 0/2] kvm/e500v2: MMU optimization Liu Yu
[not found] ` <1283938806-2981-1-git-send-email-yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-09-08 9:40 ` [PATCH 1/2] kvm/e500v2: Remove shadow tlb Liu Yu
2010-09-08 9:40 ` [PATCH 2/2] kvm/e500v2: mapping guest TLB1 to host TLB0 Liu Yu
[not found] ` <1283938806-2981-3-git-send-email-yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-09-09 23:24 ` Alexander Graf
[not found] ` <E759E1E3-7457-41B7-B36E-75FA42E107B1-l3A5Bk7waGM@public.gmane.org>
2010-09-15 9:29 ` Alexander Graf
2010-09-16 11:35 ` Liu Yu-B13201
[not found] ` <A9833F0F7901024DA08417AA5A9887D921DD39-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-16 11:44 ` Alexander Graf [this message]
2010-09-17 8:47 ` Liu Yu-B13201
[not found] ` <A9833F0F7901024DA08417AA5A9887D921DE82-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-17 10:19 ` Alexander Graf
2010-09-17 11:28 ` Liu Yu-B13201
[not found] ` <A9833F0F7901024DA08417AA5A9887D921DE99-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-17 11:34 ` Alexander Graf
2010-09-17 12:33 ` Liu Yu-B13201
2010-09-17 12:34 ` Alexander Graf
[not found] ` <1283938806-2981-2-git-send-email-yu.liu-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2010-09-08 16:06 ` [PATCH 1/2] kvm/e500v2: Remove shadow tlb Hollis Blanchard
2010-09-09 11:16 ` Liu Yu-B13201
[not found] ` <A9833F0F7901024DA08417AA5A9887D91BF24A-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-09 18:13 ` Hollis Blanchard
[not found] ` <4C8923D2.5070308-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2010-09-09 23:26 ` Alexander Graf
[not found] ` <C1EBC75A-91B0-49D9-8AD5-571C6BAF22B7-l3A5Bk7waGM@public.gmane.org>
2010-09-09 23:39 ` Hollis Blanchard
2010-09-09 23:42 ` Alexander Graf
2010-09-08 16:07 ` [PATCH 0/2] kvm/e500v2: MMU optimization Hollis Blanchard
[not found] ` <4C87B4AB.7010009-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2010-09-09 11:03 ` Liu Yu-B13201
[not found] ` <A9833F0F7901024DA08417AA5A9887D91BF248-bKEhWGtIRUJ4Lp7cDGe+DVjVikpgYyvb5NbjCUgZEJk@public.gmane.org>
2010-09-09 16:23 ` Hollis Blanchard
2010-09-10 2:59 ` Liu Yu-B13201
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C920301.4060104@suse.de \
--to=agraf-l3a5bk7wagm@public.gmane.org \
--cc=B13201-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
--cc=kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox