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: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Weidong Han <weidong.han@xxxxxxxxx>
Date: Fri, 22 Jan 2010 10:12:27 +0800
Cc: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jan 2010 18:12:51 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx>
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: <C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)
Keir Fraser wrote:
If we want to keep iommu=1 as default, then it is unacceptable to fail to
boot on a fairly wide range of modern systems. We have to warn-and-disable,
partially or completely, unless iommu=force is specified. Or we need to
revert to iommu=0 as the default.

What do you think, Weidong?
Yes. I agree to warn-and-disable for these BIOS issues, and consider security more when iommu=force. Therefore I will implement a patch based on Nororu's patch.

Regards,
Weidong

 -- Keir

On 21/01/2010 14:17, "Sander Eikelenboom" <linux@xxxxxxxxxxxxxx> wrote:

Hello Weidong,

The problem is most vendor's just don't fix it and ignore the problem
completely.
Most often hiding them selves behind: come back when it's a problem with
Microsoft Windows, that the only single thing we support (and no other
software, so no vmware, no xen, no linux, perhaps even no hypervisor)
Well I don't know if the virtual pc in windows 7 supports an iommu now, but it
didn't in the past as far as i know, so any complain bounces off, and there it
all seems to end for them.

Besides that i don't know if they do know what the problems with there
implementation in BIOS is when someone reports it.
I think some behind the scenes pressure from Intel to vendors might help to
solve some of them.
(my Q35 chipset, "Intel V-PRO" marketed motherboard (so much for that) also
suffers RMRR problem when another graphics card is inserted which switches off
the IGD).

Although i think in my case your patch will work around that for me. Perhaps a
third option is needed, which does all the workarounds possible and warns
about potential security problem when requested ?

--
Sander






Thursday, January 21, 2010, 1:46:39 PM, you wrote:

Noboru Iwamatsu wrote:
Hi Weidong,

I re-send the DRHD-fix patch.

If DRHD does not have existent devices, ignore it.
If DRHD has both existent and non-existent devices, consider it invalid
and not register.
Although you patch workarounds your buggy BIOS, but we still need to
enable it for security purpose as I mentioned in previous mail. We
needn't workaround / fix all BIOS issues in software. I think security
is more important for this specific BIOS issue. Did you report the BIOS
issue to your OEM vendor? maybe it's better to get it fixed in BIOS.
Regards,
Weidong
According to this patch and yours, my machine successfully booted
with vt-d enabled.

Signed-off-by: Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>


Keir Fraser wrote:
On 21/01/2010 10:19, "Weidong Han" <weidong.han@xxxxxxxxx> wrote:

Sorry this is typo.
I mean:
So, I think RMRR that has no-existent device is "invalid"
and whole RMRR should be ignored.
looks reasonable.

Keir, I Acks Noboru's rmrr patch. Or do you want us to merge them to one
patch?
Merge them up, re-send with both sign-off and acked-by all in one email.

Thanks,
Keir

Sorry, I disagree with Noboru after thinking it again. If the RMRR has
both no-existent device and also has existent devices in its scope, we
should not ignore it because the existent devices under its scope will
be impacted without the RMRR. so I suggest to print a warning instead of
ignore it. Attached a patch for it.

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







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

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