Re: [GIT PULL] Intel IOMMU for 4.1

[David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3948 bytes --]

On Mon, 2015-04-27 at 08:48 -0700, Linus Torvalds wrote:
> On Mon, Apr 27, 2015 at 8:39 AM, Alex Williamson
> <alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > 
> > Since this got pulled anyway, do you plan to follow-up with 
> > patches to
> > limit the graphics RMRR exception to the known and acceptable uses 
> > and
> > document them, or should I send a revert patch?  I don't think 
> > what we
> > have here is acceptable going forward or being backported to 
> > stable.
> > Thanks,
> 
> Does anybody actually *care* about RMRR?
> 
> The thing is shit. We know it's shit. We already had Linda pipe up to
> tell us that there are bogus RMRR's for ever slot in older machines.
> And we already ignore RMRR for USB controllers because it was just
> useless garbage.

RMRR for USB controllers was useless garbage because any operating
system new enough to enable the IOMMU is *also* going to have USB
support, so shouldn't need to rely on the BIOS doing legacy
keyboard/mouse emulation. Which is the only reason the firmware would
need to keep doing DMA from the USB controllers after we boot.

They could have just said "quiesce the USB BIOS stuff before turning
on the IOMMU" and they wouldn't have needed RMRR for USB.

But even so, we don't just "ignore" the RMRR. We do set it the 1:1
mapping as requested, otherwise we'd get a stream of faults and the
BIOS might even lock up in SMM code if its error handling is crap.


The thing we *don't* do is faithfully preserve that 1:1 mapping for
ever. If we assign the device to a VM guest, the RMRR mapping is lost.

We've never preserved those mappings, and it's only ever been a
problem on the insane crap that HP does with firmware-controlled DMA
from stuff like storage controllers, which persists even at runtime
after we're *using* said controller.

(You might think it would have been easy enough for them to do their
special DMA from another B-D-F but perhaps that would have been too
easy for us.)

It's extremely hard to preserve those mappings when assigning to a
guest, because we'd actually have to poke a corresponding hole in the
guest's physical address space (because in this case GPA==IOVA and
those IOVAs are being used by the BIOS with a 1:1 mapping to HPA).

Hence Alex's patch which blacklisted the 'unknown' RMRR-afflicted
devices and prevented them from being assigned to guests (and also it
seems from honouring 'iommu=pt'; qv.).

> Is there any reason to *not* just ignore RMRR for all video devices
> like we do now? Seriously?

The video case is actually the *sanest* use of RMRR. With a
framebuffer in main memory, the RMRR is the only thing that lets the
graphics device continue to render pixels from the framebuffer after
the IOMMU is initialised. So we *definitely* can't just 'ignore' the
RMRR there. And we don't.

But assignment of such graphics devices to guests *has* allegedly been
working (and iommu=pt is kind of nice too because of the performance
issues), and there's no reason for them to be excluded. They can be
lumped in with the USB devices as "OK to assign to guests".  We lose
the 1:1 mapping indicated by the RMRR but that's OK because the guest
has to initialise the hardware entirely for itself and set up its
*own* framebuffer.

> I'm *so* not impressed with firmware tables. These things are always
> uniformly wrong. We should strive to generate the information from 
> our actual hardware knowledge, with BIOS tables being the absolutely
> least trusted source of information.

... which is why the whole of the VT-d design, exposing this crap
through firmware tables instead of hardware discoverability, makes me
cringe. But while I am tilting at windmills internally to at least get
people to realise why that's such a design flaw, we still have to deal
with this crap. And with the insane things that HP abuse it for.

-- 
dwmw2

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]