>>> On 16.01.17 at 10:25, <firemet...@users.sourceforge.net> wrote: > Here are some relevant logs, please help comment what's going on here and > what's the next step of diagnose. > It appears that the fault address 0xcfxxxxxx falls within the host RMRR > region.
Might be a problem in the RMRR setup itself, when the guest gets the device assigned. But I'm not sure, as you've provided only fragments of the log, instead of the full one (allowing to see in which order the messages got logged). In any event the addresses are, as you say, properly within the device's RMRR range. That RMRR setup has changed dramatically (from being basically non-existent in the older versions), especially for USB devices (I don't think I can conclude what type of device 0000:02:00.0 is). There are messages logged with various failures in that process, but some would be issued by debug hypervisors only. A good first step (before possibly doing actual code instrumentation) would therefore be to retry with a debug hypervisor, and post the full log (huge amounts of trailing IOMMU fault messages may of course be stripped as long as they're sufficiently similar, to keep the overall log size manageable). > However, the hvmloader is setting up memory region starting from address > 0xe0000000. > Is the hvmloader memory map relevant here? No, it shouldn't be. > Unfortunately the iommu.c does not provide detailed log on the mapping > except a simple 'd2:PCI: map 0000:00:02.0' If we made it so, it would become unreasonably verbose. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
