On Thu, Feb 17, 2011 at 01:32:15PM +0800, Fengzhe Zhang wrote:
> On 2011/2/16 23:47, Konrad Rzeszutek Wilk wrote:
> >On Wed, Feb 16, 2011 at 10:20:21AM -0500, Konrad Rzeszutek Wilk wrote:
> >>On Wed, Feb 16, 2011 at 10:06:38AM -0500, Konrad Rzeszutek Wilk wrote:
> >>>On Wed, Feb 16, 2011 at 10:26:20PM +0800, Zhang, Fengzhe wrote:
> >>>>iomem: Prevent Dom0 pci bus from allocating RAM as I/O space
> >>>
> >>>Is there a bug # associated with this? Is this associated with the
> >>>intel-agp
> >>>driver trying to ioremap the scratch page and bombing out?
> >
> >Also did you try to revert 0b56d9994ebe34df77fa156d2068ad93b7877b44 and see
> >how that works? Here is the revert attached
> >
>
> I tried this patch and it can indeed avoid system crash.
Jeremy,
Could you revert 0b56d9994ebe34df77fa156d2068ad93b7877b44 please?
>
> However, I still doubt if the igb device is working correctly. The
OK, that is a different bug, if it is a bug.
> sequence that igb driver do ioremap is like this:
>
> 1. igb calls function pci_ubs_alloc_resource to get some non-RAM pages.
> 2. igb sets the phys_addr of the pages in some BAR.
> 3. igb ioremaps these pages.
>
> After patching, it looks like ioremap gets some mfn allocated by
> Xen. But what set in BAR is still phys_addr. If igb device tries to
No. It just sets the PTE to the PFN.
> access the pages directly, would Xen be able to intercept and
> translate it? And also, how the contiguity of mfns be guaranteed?
B/c we don't touch the P2M mapping. We bypass that altogether
and set the PTE with the phys_addr (which is based on the BARs).
We can do that since those PFN's belong to the DOMID_IO which
has a different mechanism for checking the MFN continuity (it
uses ranges).
>
> -Fengzhe
>
> _______________________________________________
> 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
|
Home