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: Sander Eikelenboom <linux@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Date: Thu, 21 Jan 2010 15:28:42 +0000
Cc: Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, Weidong Han <weidong.han@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jan 2010 07:29:03 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rE6LPclAXKygv1D11xgR1Ng05rFtbLmROC5XtjnFo6o=; b=mMkONfMd2v7HL5ux40mNrzsT1EonKEfyGj6+EPuKciae9SJeJJMBjWpBlr+7TI1dGg mP90k8AWd4SopSQc0ii01wyZrP/VEqFQYgQimLKUnO/clCc7YnJsVi+uz4St/DcsOtiE OiahRoBpIGPFUeMyuhFGCDw1Qc9s3EpS3Fbd4=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s6V1fVowRUANnYg0wb+J/JJ/Y6eya5Pn/jrfGtRMvlEepYYu6UKlzUO1jbOFyLtYRE H8+Zi0ZJuw5efrKz9AsHO78PicxPNHCgnUBC0s+ULvq3rfcCar737gL0YP0qmOH5t9Aa tYstBLB2filOma7AulxFZAgojmk4kj0kZgehM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1192755422.20100121151714@xxxxxxxxxxxxxx>
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: <C77DDC8C.6F44%keir.fraser@xxxxxxxxxxxxx> <4B583122.6030002@xxxxxxxxx> <4B58465C.40508@xxxxxxxxxxxxxx> <4B584CAF.10909@xxxxxxxxx> <1192755422.20100121151714@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Jan 21, 2010 at 2:17 PM, 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)

Supermicro were fairly cooperative but they wanted to know *exactly*
what was wrong, i.e. wanted me to show them the incorrect values and
how to fix them, I tried to work it out but failed :(.

I had the same problem on a Dell system, who went down the "we dont
support xen" route, but again they would have been willing to take it
further if I could show them which values were incorrect.

If we had a diagnostic tool that could verify the settings and output
detailed explanations of any problems that would really help to give
manufacturers the info they need to fix the bios.

Andy

> 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>
>>>>
>>>
>>>
>
>
>
>
>
>
> --
> Best regards,
>  Sander                            mailto:linux@xxxxxxxxxxxxxx
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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

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