[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo


  • To: "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Tue, 28 Mar 2006 21:04:19 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 28 Mar 2006 13:06:36 +0000
  • List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcZSYvf2DpK229bxShCr4K9QWy6nigABFF0g
  • Thread-topic: [Xen-ia64-devel] [RFC] grant table API clean up and performancetuning memo

>From: Isaku Yamahata [mailto:yamahata@xxxxxxxxxxxxx]
>Sent: 2006年3月28日 20:27
>
>Without tracking a virtual address corresponding to a granted page,
>xen/ia64 have to flush all tlb/vhpt.
>I.e. xen/ia64 has to do something like
>    vhpt_flush();
>    flush_tlb_all();
>Here vhpt_flush() flushes the whole of vhpt table.
>
>On the other hand, dom0 knows the virtual address so
>dom0 may issues ptc.ga with page size (16KB by default).
>It results in vcpu_ptc_ga() of xen/ia64.
>It does
>    vhpt_flush_address(vadr,addr_range);
>    ia64_global_tlb_purge(vadr,vadr+addr_range,PAGE_SHIFT);
>Here vhpt flush range is 16kb.
>
>If xen/ia64 tracks a virtual address somehow,
>Xen/ia64 can flush vhpt with page size range so this become
>meaningless.
>

See your point now. :-) So how about pass the virtual address prepared 
for the granted page in host_addr at mapping time, though it's dom0 to 
setup mapping right after(or even before) the grant mapping call? By 
this way, though grant table doesn't setup the va mapping for guest, va is 
recorded and later you can take that info to do more accurate flush.

Thanks,
Kevin

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.