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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>From: Isaku Yamahata
>Sent: 2006年3月24日 17:46
>
>* grant table API proposal
>The current grant table API depends on xen/x86 deeply.
>There are four kind of addresses related to grant table.
>user virtual address, kernel virtual address, pseudo physical address and
>machine address.
>xen/x86 grant table uses user virtual address, kernel virtual address and
>machine address.

If possible, I suggest you to use terms defined in include/public/xen.h from 
now on:
Gpfn/gmfn/mfn/pfn,
with clear explanation in head of that file. :-)

Also XENFEAT_auto_translated_physmap is one mode you may be interested to 
take it as reference. Within that mode, gpfn equals to gmfn with p2m table 
managed 
by xen hypervisor, which is exactly like your case for ia64 dom0. Grant table 
has 
been changed a lot to accommodate that mode, and so do para-drivers.

Yes, it's possible that ia64 dom0 may need more interface abstraction to make 
it 
working, but I think it would be easier/quicker/cleaner for you to reuse code 
path for 
that mode.

>grant table mapping
>grant_entry_t::frame should be architecture specific.
>  - xen/x86: mfn
>  - xen/IA64: pfn

Then in this case:
        - Normal x86: gmfn (gmfn == mfn)
        - Translated x86/IA64: gmfn (gmfn != mfn)

>define a arch-specific macro like virt_to_gnttab_mapaddr().
>define a arch-specific function which allocates a mapping area.

Since frame within grant table entry is gmfn and xen is aware whether this gmfn 
equals to mfn or not, there's no need to change concept of host_addr and you 
can 
just deliver a dummy va address.

>
>
>* grant table read-only mapping
>Current it is not implemented on xen/IA64 yet.
>Xen/IA64 software address translation page table entry has unused bits.
>In fact only present bit and ppn entry is only used. So other unused
>bits can be used to record read-only.
>Perhaps translate_domain_pte() needs modification.

I assume you're talking about vTLB, instead of mTLB. vTLB entry may not be 
suitable 
to contain that information. Since the read-only limitation may be imposed to 
part of a 
large vTLB entry, then save read-only bit in large vTLB entry is incorrect. 

More important from your design, xenlinux will allocate virtual address to that 
shared 
frame later after grant table operation, and then grant table handler within 
Xen 
doesn't know which vTLB to record yet.

How about record read-only property in the p2m table of that domain? Later when 
inserting entry into VHPT table and mTLB, p2m entry can be checked to set 
read-only 
flag.

>Because blkback, netback determines a number of entries which is used
>based I/O ring entry size which is proportional to page size.
>On the other hand netback limits maximum entries another way.
>Not based on I/O ring size or page size.
>These parameter should be adjusted somehow. Perhaps benchmark is needed.

Yes, need to be changed.

>- read only grant table mapping
>  When unmapping of read only grant table mapping, tlb won't be flushed.
>  A malicious domain might be able to read a unmapped page, but it
>  can't modify a page.
>  A granting domain must not use a granted page for important data.

Just be curious about last sentence. :-) How do you define the "important" 
here? It 
may not be important to crash the granting domain, which however may reveal 
user 
"important" information since that page may keep content of files.

>
>- trust privileged domains
>  Xen/IA64 trust privileged domain(dom0) to flush tlb cache.

What do you mean by "trust"? Purge instruction still traps to xen since 
xenlinux is 
running as less privilege level. Maybe I didn't understand your point here.

>
>- reserve pseudo physical address space or virtual address space
>  (for grant table mapping)
>  With hypercall, a domain registers grant table mapping regions to xen.
>  So xen can flush registered virtual address region.

That may be issue for vnif case, since skb buffer is allocated from slab. If 
you force to 
use reserved physical frames, it means you have to copy data from time to time.

>
>- memory copy
>  abandon grant table. resort to memory copy.

Worthy of more thinking. Especially if this model need less hypercalls, maybe 
overhead of memory copy is better than one of several context switches. :-)

>
>- 64MB of contiguous (P==M+delta)
>  - move I/O area, efi area and acpi table to high pseudo physical address.

May take as an optimization solution, which however is chosen upon resource 
status 
instead of static limitation.

I may not understand all the content well, and if yes please correct me.

Thanks,
Kevin

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