<div dir="ltr">Interesting thread. I would like to thank you to all for very/extremely interesting read. And this thread forced me to start thinking/focusing about these problems you have outlined here.<div><br></div><div>I have no idea how things are handled in Coreboot regarding VT-x and VT-d. I do know how these two HW extensions are handled in UEFI/legacy BIOS. You either enable/disable them, independently, or not. So, if you, for example, do not set VT-x, you are not able to bring any kind of HYP/VMMs, doing true MMU xlation. The same applies for VT-d. If not set, not able to do any IOMMU xlation.</div><div><br></div><div>I tried to find in Coreboot 4.4 (from August 2016) both VT-x and VT-d settings, but was not able to find any switches in .config. My question here is: <i><u>how HW extensions for INTEL/AMD VT-x and VT-d are handled - enabled/disabled in Coreboot?</u></i></div><div><br></div><div>Let me now switch to another part of this thread, main part: BME (Bus Master Enable). This is a different topic, but related to VTs. I would agree with Ron (Minnic) on his comment that minimum of the HW should be configured in Coreboot, so my take on this is that BME should be NOT enabled anyhow, anywhere, and left to actual OS to do this. Since Coreboot is true Linux oriented, I would say that kernel should properly go over PCIe discovery algorithm/PCIe tree discovered and set properly bridges with BME (by configuring kernel .config).</div><div><br></div><div>In this lieu, I would like to propose two addendums: one already proposed by several people (Ron): to have added BME algorithm to ram-stage of Coreboot, which will print warnings for any bridge which has BME bit set, and other one: to create critical Bugzilla against Linus's (Torvalds) crew (<a href="http://kernel.org">kernel.org</a>) to add proper handling of BMEs in <a href="http://kernel.org">kernel.org</a>: <a href="https://bugzilla.kernel.org/">https://bugzilla.kernel.org/</a> .</div><div><br></div><div>About security aspects... It is to be taken into the account <i style="text-decoration:underline">AFTER</i> proposed changes (logical steps), since we divide and conquer, don't we? </div><div><br></div><div>Thank you,</div><div>Zoran</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 21, 2016 at 10:15 PM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Mon, Nov 21, 2016 at 10:54 AM Rudolf Marek <<a href="mailto:r.marek@assembler.cz" target="_blank">r.marek@assembler.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="m_4942085384411326343gmail_msg">
<br class="m_4942085384411326343gmail_msg">
BME is ignored by Intel integrated graphics - the DMA runs even if the BME is<br class="m_4942085384411326343gmail_msg">
clear (this happens on core i7 chipsets for example) Thus thatswhy it needs RMRR<br class="m_4942085384411326343gmail_msg">
IOMMU range for VGA...<br class="m_4942085384411326343gmail_msg"><br class="m_4942085384411326343gmail_msg"></blockquote><div><br></div><div><br></div></span><div>wow. It's amazing how many of the PCI violations I've dealt with over the years have been for intel chips :-) </div></div></div>
<br>--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/<wbr>mailman/listinfo/coreboot</a><br></blockquote></div><br></div>