[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] netif & grant tables
> You are right, it's not the grant tables per se that need the privileged > bit to be set, but other functions need it and keep backends from working. > > Here are two code paths from the network backend: I suspected it might be something like this. There's no reason for those to require privilege either: they can fairly trivially be converted to use grant tables too. Once it's fully grant-table-ified it shouldn't be necessary to make such domains be privileged. Full grant tables support also a pre-req for the point to point "snappable frontend" connections directly between domains with high bandwidth requirements. Cheers, Mark > from netback/interface.c calls > > linux-2.6.11-xen-sparse/arch/xen/i386/mm/ioremap.c:direct_remap_area_pages( >) calls > HYPERVISOR_mmu_update calls > xen/arch/x86/mm.c:do_mmu_update calls > set_foreigndom() which has an IS_PRIV() in the path > > -> The direct_remap_area_pages call fails if a domain does not have the > privilege bit set. > > > netback/netback.c: alloc_mfn() calls > HYPERVISOR_dom_mem_op(MEMOP_increase_reservation, mfn_list, > MAX_MFN_ALLOC, 0); > xen/common/dom_mem_ops.c:do_dom_mem_op() is called which has a > IS_PRIV() in the path > > > > Stefan > > > What I meant was that since grant tables are an explicit capability (you > > can > > > only map a page of another dom if it gave you an explicit grant) there's > > no > > > need for mappings in the IO path to require special privileges at all. > > If > > > someone gave you a grant, they must trust you enough to access that > > page. > > > Cheers, > > Mark > > > > > Stefan > > > > > > > Cheers, > > > > Mark > > > > > > > > > The privilege does so far not > > > > > only mean to do dom 0 ops, but seems to also limit guest domains > > of > > > > doing > > > > > > > > other things - like the backend problem I see. I agree, though, > > that > > > > for > > > > > > > > grant table support a backend should not need privileges. > > > > > > > > > > > Cheers, > > > > > > Mark > > > > > > > > > > Cheers, > > > > > Stefan > > > > > > > > _______________________________________________ > > > > Xen-devel mailing list > > > > Xen-devel@xxxxxxxxxxxxxxxxxxx > > > > http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |