[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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?

 -- 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.