On Mon, 2015-04-27 at 08:48 -0700, Linus Torvalds wrote: > On Mon, Apr 27, 2015 at 8:39 AM, Alex Williamson > <alex.william...@redhat.com> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
