[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: Next steps with pv_ops for Xen
Derek Murray wrote: > Ultimately, fork calls dup_mm, which calls, dup_mmap, which calls > copy_{page,pud,pmd,pte}_range, which calls copy_one_pte, which calls > set_pte_at, which hypercalls HYPERVISOR_update_va_mapping. > > The hypercall will not succeed and will return an error code > indicating the reason for this. Therefore the PTE will not be set. > There appears to be no way to propagate this error through the Linux > VM code, because there is no concept of a PTE update failing. I could > add return codes to all those functions, but I don't fancy their > chances upstream.... Could we use one of the software-defined bits in the PTE to indicate that this is a foreign/granted PTE, and have set_pte_at behave differently if you pass it a pte with this bit set? J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |