On Thu, Jul 03, 2014 at 06:45:03PM +0200, Jan Kiszka wrote: > On 2014-07-03 12:02, Michael S. Tsirkin wrote: > > On Thu, Jul 03, 2014 at 10:43:57AM +0200, Jan Kiszka wrote: > >> On 2014-07-03 10:26, Le Tan wrote: > >>> In map_page() in hw/ide/ahci.c, replace cpu_physical_memory_map() and > >>> cpu_physical_memory_unmap() with dma_memory_map() and dma_memory_unmap(), > >>> because ahci devices should not access memory directly but via their > >>> address > >>> space. Add an AddressSpace parameter to map_page(). In order to call > >>> map_page(), we should pass the AHCIState.as as the AddressSpace argument. > >> > >> BTW, when doing "git grep cpu_physical_memory_map hw", there are some > >> more cases that should be checked (for x86). I suppose vhost is > >> incompatible with an IOMMU, > > > > vhost can be made to work: you just need to > > update its memory tables as appropriate. > > But see below > > > >> but plain virtio should work, > > > > It doesn't: all guests pass in physical addresses at the moment. > > You mean they do not put virtio devices into IOMMU domains, or they do > put them but ignore any translation rules that are not 1:1?
Look at the code. We just pass in physical addresses ignoring which iommu domain device ended up with. > > We discussed requiring this for virtio 1.0, but in the end, > > most people thought that passing through virtio devices > > isn't worthwhile. > > It should be consistent at least. If virtio is not translated, we have > to exclude such devices via ACPI tables from the scope of our IOMMUs. I didn't know this is possible. How does one do this? > > We can certainly add that as an option, with a feature bit. > > > > If you feel otherwise, you can comment on the latest spec draft. > > Does the spec at least state that "virtio devices are not subject to any > guest configured IOMMU translation"? Is is this left undefined? > > Jan > > I don't think we have anything like this. -- MST
