From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Fri, 22 Jan 2010 10:12:27 +0800 Message-ID: <4B59098B.6000108@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Sander Eikelenboom , "Cihula, Joseph" , Noboru Iwamatsu , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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" 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 >>>> >>>> >>>> >>>> >>>>> 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 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 >>>>> >>>>> >>>> >>>> >> >> >> >> > > >