WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking

To: weidong.han@xxxxxxxxx
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>
Date: Tue, 26 Jan 2010 15:38:40 +0900
Cc: linux@xxxxxxxxxxxxxx, joseph.cihula@xxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, allen.m.kay@xxxxxxxxx, keir.fraser@xxxxxxxxxxxxx
Delivery-date: Mon, 25 Jan 2010 22:39:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B5E82D1.8060206@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C7835076.74F1%keir.fraser@xxxxxxxxxxxxx> <4B5DA659.1030506@xxxxxxxxx> <4B5E4276.90308@xxxxxxxxxxxxxx> <4B5E82D1.8060206@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
Hi Weidong,

I implemented a patch for it. Noboru, pls have a try on your machine.
If you use default iommu=1, VT-d will be disabled with warning messages.
If you use iommu=workaround_bios_bug, it should enable VT-d and works
for you.
If you use iommu=force, it panics.

On my machine, each options have worked as described.

I tried:
xen-unstable c/s 20844 + drhd-ignore.patch + workaround-bios.patch

Thanks,
Noboru.

patch title: VT-d: add "iommu=workaround_bios_bug" option
patch description:
Add this option to workaround BIOS bugs. Currently it ignores DRHD if
"all" devices under its scope are not pci discoverable. This workarounds
a BIOS bug in some platforms to make VT-d work. But note that this
option doesn't guarantee security, because it might ignore DRHD.
So there are 3 options which handle BIOS bugs differently:
iommu=1 (default): If detect non-existent device under a DRHD's scope,
or find incorrect RMRR setting (base_address > end_address), disable
VT-d completely in Xen with warning messages. This guarantees security
when VT-d enabled, or just disable VT-d to let Xen work without VT-d.
iommu=force: it enforces to enable VT-d in Xen. If VT-d cannot be
enabled, it will crashes Xen. This is mainly for users who must need VT-d.
iommu=workaround_bogus_bios: it workarounds some BIOS bugs to make VT-d
still work. This might be insecure because there might be a device not
protected by any DRHD if the device is re-enabled by malicious s/w. This
is for users who want to use VT-d regardless of security.

Signed-off-by: Weidong Han <weidong.han@xxxxxxxxx>

Regards,
Weidong

Noboru Iwamatsu wrote:
Weidong, Keir,

I agree your suggestions.

Noboru.

Keir Fraser wrote:
On 25/01/2010 10:45, "Sander Eikelenboom" <linux@xxxxxxxxxxxxxx> wrote:

a) Could be discussed if panic should be default instead of disabling
iommu or
not, although there seem to be a lot of broken bioses, so that would
lead to a
lot of machines not booting.
Absolutely not acceptable. Warn and completely disable IOMMU is the
correct
default causing least pain to the most end users.

-- Keir

Agree. It should not crash Xen by default due to BIOS issues.
warn-and-disable is better. It won't impact common Xen users, and if a
user really wants to use VT-d, he can try iommu=workaround_bogus_bios,
or directly report to OEM vendor to get it fixed in BIOS. As VT-d is
used more and more widely, I think the BIOS issues will be found and
fixed more quickly than before, thus the situation should be better.

Regards,
Weidong









_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>