[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: blktap: Sync with XCP, dropping zero-copy.
On 11/17/2010 01:57 PM, Daniel Stodden wrote: > On Wed, 2010-11-17 at 16:02 -0500, Jeremy Fitzhardinge wrote: >> On 11/17/2010 12:21 PM, Daniel Stodden wrote: >>> And, like all granted frames, not owning them implies they are not >>> resolvable via mfn_to_pfn, thereby failing in follow_page, thereby gup() >>> without the VM_FOREIGN hack. >> Hm, I see. Well, I wonder if using _PAGE_SPECIAL would help (it is put >> on usermode ptes which don't have a backing struct page). After all, >> there's no fundamental reason why it would need a pfn; the mfn in the >> pte is what's actually needed to ultimately generate a DMA descriptor. > The kernel needs the page structs at least for locking and refcounting. Yeah. > There's also a some trickier stuff in there. Like redirtying disk-backed > user memory after read completion, in case it's been laundered. (So that > an AIO on unpinned user memory doesn't subsequently get flashed back > when cycling through swap, if I understood that thing correctly.) > > Doesn't apply for blktap (it's all reserved pages). All I mean is: I > wouldn't exactly see some innocent little dio hack or so shape up in > there. > > Kernel allowing to DMA into a bare pfnmap -- From the platform POV, I'd > agree. E.g. there's a concept of devices DMA-ing into arbitrary I/O > memory space, not host memory, on some bus architectures. PCI would come > to my mind (the old shared medium stuff, unsure about those newfangled > P-t-P topologies). But not in Linux, so I presently don't see anybody > upstream bothering to make block-I/O request addressing more forgiving > than it is. > > PAGE_SPECIAL -- to the kernel, that means the opposite: page structs > which aren't backed by 'real' memory, so gup(), for example, is told to > fail (how nasty). It's pfns with no corresponding struct page - it's the pte level equivalent of VM_PFNMAP at the VMA level. But you're right that we can't do without struct pages. So we're back to needing a way of mapping from a random mfn to a pfn so we can find the corresponding struct page. I would be tempted to put a layer over m2p to allow local m2p mappings to override the global m2p table. > In contrast, VM_FOREIGN is non-memory backed by page > structs. Yep. J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |