From: Yang Zhang <yang.zhang.wz@gmail.com>
To: Steve Novakov <steve@stevenovakov.com>, kvm@vger.kernel.org
Subject: Re: X58 Virtualization w/ Linux
Date: Mon, 13 Jun 2016 09:46:05 +0800 [thread overview]
Message-ID: <2884c8b8-9ad3-cba7-d9ba-b94946775087@gmail.com> (raw)
In-Reply-To: <ecf1dd3d-e530-f42d-8f13-efb5ab60846c@stevenovakov.com>
On 2016/6/12 9:55, Steve Novakov wrote:
> Hello Yang,
>
>> allow_unsafe_interupts actually means the interrupt remapping on Intel
>> IOMMU which is a security feature. Without it, a malicious VM can
>> attack the host, see below document for more details:
>> http://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf
>>
>
> Should I take that to mean that "allow_unsafe_interrupts" is actually a
> security feature??? Is this the discussed "interrupt remapping" in the
Interrupt remapping not only a security feature, it also supports more
than 255 CPUs associate with x2apic. allow_unsafe_interrupts allows you
to enable IOMMU on the platform even without interrupt remapping because
first platform supporting IOMMU doesn't have interrupt remapping.
> whitepaper? I am interpreting that paper as saying that this interrupt
> remapping does *not* use the supplied DMAR table. Is that correct?
All the necessary information for IOMMU is located in ACPI tables not
only DMAR table. OS need to parse it before enabling the IOMMU.
>
>> Also, you can try to upgrade your BIOS to fix it.
>
> I'll take a look but I think I have the latest (which means, from ~2011
> probably) BIOS version.
>
> Could I also ask you outright what entire set of boot options you would
> pass when booting into a kvm system with IOMMU enabled? I would love
> some "default" set of boot options to compare to, as opposed to random
> ones from assorted forums.
Usually, i am using intel_iommu=on and everything works well. But in
your case, i guess you may also need intremap=off.
>
> Thank you for the prompt reply!
>
> Steve Novakov
> B.A.Sc Engineering Physics
> PhD Student - Physics
> University of Michigan - Ann Arbor
> On 6/11/2016 9:46 PM, Yang Zhang wrote:
>
--
best regards
yang
next prev parent reply other threads:[~2016-06-13 1:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-11 21:34 X58 Virtualization w/ Linux Steve Novakov
2016-06-12 1:46 ` Yang Zhang
2016-06-12 1:55 ` Steve Novakov
2016-06-12 2:54 ` Steve Novakov
2016-06-12 2:57 ` Steve Novakov
2016-06-13 1:46 ` Yang Zhang [this message]
2016-06-13 3:32 ` Steve Novakov
2016-06-13 20:11 ` Steve Novakov
2016-06-14 22:00 ` Steve Novakov
2016-06-15 5:04 ` Steve Novakov
2016-06-15 6:59 ` Paolo Bonzini
2016-06-15 15:40 ` Steve Novakov
2016-06-16 1:19 ` Yang Zhang
2016-06-16 1:22 ` Steve Novakov
2016-06-16 7:17 ` Paolo Bonzini
2016-06-20 2:07 ` Yang Zhang
2016-06-20 4:05 ` Steve Novakov
[not found] ` <97e6a96d-4139-2469-a8c9-f79df48727a6@stevenovakov.com>
2016-06-21 1:21 ` Yang Zhang
2016-06-21 1:24 ` Steve Novakov
2016-06-27 2:21 ` Yang Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2884c8b8-9ad3-cba7-d9ba-b94946775087@gmail.com \
--to=yang.zhang.wz@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=steve@stevenovakov.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox