[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space in 2.6.32.27 tree.
> > 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. Then it's just a workaround to the crash. The PFN allocated in dom0 is actually Xen RAM page, thus the driver may corrupt the page which actually belongs to Xen or other domain. > > > 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). I'm still not persuaded this is a reasonable fix. I'm still thinking Xen can't use the PFN from dom0, it's guest PFN allocated in dom0 according to its e820 which falls into host RAM range. Thanks! -Xin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |