>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
|
Home