Le Mardi 28 Mars 2006 15:04, Tian, Kevin a écrit :
> 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.
Two questions:
It seems your mechanism still need to trust the domains. So we need to add
checks for itc/ptc.
However, can a granted page be mapped several times ?
If so, tracking is necessary and has a cost.
From my point of view and my experience, flushing all the tlb/vhpt is really
costly (and even more with SMP-g), but it is necessary.
Currently, we *don't* flush tlb/vhpt after unmapping granted page. This
really creates instability (at least of gcc segfaults).
I don't have yet a magic solution. I think we need to fix gcc segfault bug
first, and then we need to improve performance.
Tristan.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home