From: Wei Yang
> On Wed, Jun 25, 2014 at 02:12:34PM +1000, Alexey Kardashevskiy wrote:
> >On 06/25/2014 11:12 AM, Wei Yang wrote:
> >> On Tue, Jun 24, 2014 at 08:06:32PM +1000, Alexey Kardashevskiy wrote:
> >>> On 06/10/2014 11:56 AM, Wei Yang wrote:
> >>>> Current iommu_table of a PE is a static field. This will have a problem when
> >>>> iommu_free_table is called.
> >>>
> >>> What kind of problem? This table is per PE and PE is not going anywhere.
> >>>
> >>
> >> Yes, for Bus PE, they will always sit in the system. When VF PE introduced,
> >> they could be released on the fly. When they are released, so do the iommu
> >> table for the PE.
> >
> >iommu_table is a part of PE struct. When PE is released, iommu_table will
> >go with it as well. Why to make is a pointer? I would understand it if you
> >added reference counting there but no - iommu_table's lifetime is equal to
> >PE lifetime.
> >
>
> Yes, iommu_talbe's life time equals to PE lifetime, so when releasing a PE we
> need to release the iommu table. Currently, there is one function to release
> the iommu table, iommu_free_table() which takes a pointer of the iommu_table
> and release it.
>
> If the iommu table in PE is just a part of PE, it will have some problem to
> release it with iommu_free_table(). That's why I make it a pointer in PE
> structure.
What are the sizes of the iommu table and the PE structure?
If the table is a round number of pages then you probably don't want to
embed it inside the PE structure.
David
��.n��������+%������w��{.n�����{���"�)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
