Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

[Daniel Vetter]

On Tue, Jun 17, 2014 at 08:21:31AM +0100, David Woodhouse wrote:
> On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote:
> > We've always been struggling with stolen handling, and we've' always
> > been struggling with vt-d stuff. Also pass-through seems to be a major
> > pain (I've never tried myself). Given all that I'm voting for keeping
> > the RMRR and everything else as much like for the normal case since I
> > have no idea what exactly must be remapped and what's optional. The
> > gpu is definitely keeping a lot of it's own private stuff in various
> > chunks of stolen memory.
> 
> Keeping it like the normal case is distinctly non-trivial. I raised that
> possibility, and it's hard. You have to make the guests' address maps
> match the host, in that the E820-reserved regions used for DMA and
> listed in RMRRs must also appear as reserved for the guests.
> 
> That was bad enough when it was just 'BIOS might be doing something evil
> behind our back' and we didn't need to let the guest *access* those
> pages. But in the i915 case we do actually map and access the stolen
> region too, so the task is even harder. We'd need to be able to decide
> when those regions should actually be mapped into the guest.

Hm, we check some registers (which iirc are set up by the bios) for stolen
to detect the address and size. And if that's there we use it. So not sure
what to do really.

For my understanding: The tricky part with RMRR isn't the mapping, but
making sure that the gues memory layout has the corresponding range
properly marked as reserved in the e820 map (i.e. like on real machines)?
I guess we wouldn't need to care about the actual memory since the host
linux can't access it either (without i915.ko).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/