Re: Re: [Xen-users] VT-D RMRR is incorrect

[jwatte <nabble.com@xxxxxxxxxxxxxxx>]

> (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address
> bf7dbfff


This is a shot-in-the-dark guess:
Is there some way to treat an entry like this as if it wasn't there at all?

Theory: If some BIOS programmer set aside two records to be used for various
needs, and then on boot detected that one of them wasn't needed (say,
integrated graphics not present, so 0 MB reserved?), perhaps said BIOS
programmer would just set the range to be 0 bytes, rather than go through
the effort to remove the entire record? What could go wrong if the parser
just treated entries mapping 0 byte ranges (like this one) as if they didn't
exist? 



Christian Tramnitz wrote:
> 
> Ross Philipson schrieb:
> 
>> Anyway, I am working on a workaround that I will be pushing upstream 
>> this week. A parameter will allow you to include reserved memory regions 
>> in the mappings. It is not ideal (less secure) but better than hanging 
>> or crashing…
> 
> 
> Hi Ross,
> 
> I tried your patch from you other post, but even with the new parameter 
> enabled I still get the DMAR error messages and vt-d being disabled:
> 
> (XEN) Command line: dom0_mem=1024M iommu=1 iommu_include_reserved=1
> ...
> (XEN) [VT-D]dmar.c:486: found ACPI_DMAR_RMRR
> (XEN) [VT-D]dmar.c:376: RMRR error: base_addr bf7dc000 end_address
> bf7dbfff
> (XEN) Failed to parse ACPI DMAR.  Disabling VT-d.
> 
> 
> Best regards,
>     Christian
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/VT-D-RMRR-is-incorrect-tp22005500p22479357.html
Sent from the Xen - User mailing list archive at Nabble.com.


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