From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Lyon Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Thu, 21 Jan 2010 15:28:42 +0000 Message-ID: References: <4B583122.6030002@intel.com> <4B58465C.40508@jp.fujitsu.com> <4B584CAF.10909@intel.com> <1192755422.20100121151714@eikelenboom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1192755422.20100121151714@eikelenboom.it> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Sander Eikelenboom Cc: Noboru Iwamatsu , "Cihula, Joseph" , Weidong Han , "xen-devel@lists.xensource.com" , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org On Thu, Jan 21, 2010 at 2:17 PM, Sander Eikelenboom wrote: > Hello Weidong, > > The problem is most vendor's just don't fix it and ignore the problem com= pletely. > 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 soft= ware, 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, b= ut 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 im= plementation 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) al= so suffers RMRR problem when another graphics card is inserted which switch= es off the IGD). > > Although i think in my case your patch will work around that for me. Perh= aps a third option is needed, which does all the workarounds possible and w= arns 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 >>> >>> >>> >>>> Keir Fraser wrote: >>>> >>>>> On 21/01/2010 10:19, "Weidong Han" 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 ema= il. >>>>> >>>>> 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 >>>> >>> >>> > > > > > > > -- > Best regards, > =A0Sander =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mailto:l= inux@eikelenboom.it > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >