Hi, > Abilities to disable the IOMMU as a choice? Performance impact on > various systems and interactions with other projects that have gone to > some length to work within S/G and its performance characteristics. > How will this affect them? Cache effects? Interactions with some VM > work currently being undertaken? > > I can't imagine such a major change being closed/approved/automatic. Performance is driver dependant. There is no way a single project team can test the gamut of drivers out there and certify that the IOMMU will give acceptable performance for all needs (which is itself a subjective opinion). We have always planned to provide the ability to disable the IOMMU on a per driver basis. Does that address your performance concerns ?
Vikram Matthew Jacob wrote: > On 09/03/08 16:34, Jerry Gilliam wrote: >> I am sponsoring the following fast-track for Vikram Hegde. This >> case presents an overview and architectural details on an IOMMU >> for AMD cpus. This information is being presented for information >> only, for discussion and future reference. As there's nothing to >> approve, I believe Closed Approved Automatic is appropriate. >> >> >> >> > > Abilities to disable the IOMMU as a choice? Performance impact on > various systems and interactions with other projects that have gone to > some length to work within S/G and its performance characteristics. > How will this affect them? Cache effects? Interactions with some VM > work currently being undertaken? > > I can't imagine such a major change being closed/approved/automatic.
