mm: iommu: The Virtual Contiguous Memory Manager
in [Kernel]
|
Prev: [PATCH v2]kernel.h Move preprocessor #warning about using kernel headers in userpsace to types.h
Next: scsi/sg: remove casts from void*
From: Paul Walmsley on 1 Jul 2010 17:10 Randy, On Thu, 1 Jul 2010, Randy Dunlap wrote: > > + * @start_addr The starting address of the VCM region. > > + * @len The len of the VCM region. This must be at least > > + * vcm_min() bytes. > > and missing lots of struct members here. > If some of them are private, you can use: > > /* private: */ > ... > /* public: */ > comments in the struct below and then don't add the private ones to the > kernel-doc notation above. To avoid wasting space in structures, it makes sense to place fields smaller than the alignment width together in the structure definition. If one were to do this and follow your proposal, some structures may need multiple "private" and "public" comments, which seems undesirable. The alternative, wasting memory, also seems undesirable. Perhaps you might have a proposal for a way to resolve this? - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Randy Dunlap on 1 Jul 2010 18:00 On 07/01/10 13:59, Paul Walmsley wrote: > Randy, > > On Thu, 1 Jul 2010, Randy Dunlap wrote: > >>> + * @start_addr The starting address of the VCM region. >>> + * @len The len of the VCM region. This must be at least >>> + * vcm_min() bytes. >> >> and missing lots of struct members here. >> If some of them are private, you can use: >> >> /* private: */ >> ... >> /* public: */ >> comments in the struct below and then don't add the private ones to the >> kernel-doc notation above. > > To avoid wasting space in structures, it makes sense to place fields > smaller than the alignment width together in the structure definition. > If one were to do this and follow your proposal, some structures may need > multiple "private" and "public" comments, which seems undesirable. The > alternative, wasting memory, also seems undesirable. Perhaps you might > have a proposal for a way to resolve this? I don't know of a really good way. There are a few structs that have multiple private/public entries, and that is OK. Or you can describe all of the entries with kernel-doc notation. Or you can choose not to use kernel-doc notation on some structs. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on 1 Jul 2010 18:10 Andi Kleen wrote: >>> Also for me it's still quite unclear why we would want this code at all... >>> It doesn't seem to do anything you couldn't do with the existing interfaces. >> I don't know all that much about what Zach's done here, but from what >> he's said so far it looks like this help to manage lots of IOMMUs on a >> single system.. On x86 it seems like there's not all that many IOMMUs in >> comparison .. Zach mentioned 10 to 100 IOMMUs .. > > The current code can manage multiple IOMMUs fine. That's fair. The current code does manage multiple IOMMUs without issue for a static map topology. Its core function 'map' maps a physical chunk of some size into a IOMMU's address space and the kernel's address space for some domain. The VCMM provides a more abstract, global view with finer-grained control of each mapping a user wants to create. For instance, the symantics of iommu_map preclude its use in setting up just the IOMMU side of a mapping. With a one-sided map, two IOMMU devices can be pointed to the same physical memory without mapping that same memory into the kernel's address space. Additionally, the current IOMMU interface does not allow users to associate one page table with multiple IOMMUs unless the user explicitly wrote a muxed device underneith the IOMMU interface. This also could be done, but would have to be done for every such use case. Since the particular topology is run-time configurable all of these use-cases and more can be expressed without pushing the topology into the low-level IOMMU driver. The VCMM takes the long view. Its designed for a future in which the number of IOMMUs will go up and the ways in which these IOMMUs are composed will vary from system to system, and may vary at runtime. Already, there are ~20 different IOMMU map implementations in the kernel. Had the Linux kernel had the VCMM, many of those implementations could have leveraged the mapping and topology management of a VCMM, while focusing on a few key hardware specific functions (map this physical address, program the page table base register). -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 1 Jul 2010 18:10 On Thu, 2010-07-01 at 15:00 -0700, Zach Pfeffer wrote: > Additionally, the current IOMMU interface does not allow users to > associate one page table with multiple IOMMUs unless the user explicitly > wrote a muxed device underneith the IOMMU interface. This also could be > done, but would have to be done for every such use case. Since the > particular topology is run-time configurable all of these use-cases and > more can be expressed without pushing the topology into the low-level > IOMMU driver. > > The VCMM takes the long view. Its designed for a future in which the > number of IOMMUs will go up and the ways in which these IOMMUs are > composed will vary from system to system, and may vary at > runtime. Already, there are ~20 different IOMMU map implementations in > the kernel. Had the Linux kernel had the VCMM, many of those > implementations could have leveraged the mapping and topology management > of a VCMM, while focusing on a few key hardware specific functions (map > this physical address, program the page table base register). So if we include this code which "map implementations" could you collapse into this implementations ? Generally , what currently existing code can VCMM help to eliminate? Daniel -- Sent by a consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Hari Kanigeri on 1 Jul 2010 18:20
> > He demonstrated the usage of his code in one of the emails he sent out > initially. Did you go over that, and what (or how many) step would you > use with the current code to do the same thing? -- So is this patch set adding layers and abstractions to help the User ? If the idea is to share some memory across multiple devices, I guess you can achieve the same by calling the map function provided by iommu module and sharing the mapped address to the 10's or 100's of devices to access the buffers. You would only need a dedicated virtual pool per IOMMU device to manage its virtual memory allocations. Hari -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |