On Thu, 25 May 2017, Julien Grall wrote: > Hi Andrii, > > On 23/05/17 18:03, Andrii Anisov wrote: > > * Hardware: > > Salvator-X board with Renesas R-Car H3 SoC (ARM64) > > > > * Software: > > XEN 4.9-rc6 > > System based on Renesas Yocto 2.19.0 BSP [1] > > Linux kernel 4.9 > > > > * Guest operating systems: > > The same system as dom0. > > > > * Functionality tested: > > xl create/restart/shutdown > > Guest domain reboot from its console > > PV NET (nfsroot in domU) , PV Block (copy from xvda to nfsroot in DomU) > > > > * Comments: > > > > On DomU startup messages like following appeared: > > > > root@salvator-x-domx:~# (XEN) printk: 9 messages suppressed. > > (XEN) d1v0: vGICD: unhandled word write 0xffffffff to ICACTIVER0 > > (XEN) d1v1: vGICD: unhandled word write 0xffffffff to ICACTIVER0 > > (XEN) d1v2: vGICD: unhandled word write 0xffffffff to ICACTIVER0 > > (XEN) d1v3: vGICD: unhandled word write 0xffffffff to ICACTIVER0 > > The vGIC emulation does not emulate I*ACTIVER* registers so far. But Linux > only accesses them at boot to ensure the firmware didn't leave interrupt in > active state. They are harmless for now. > > > [ 65.333062] xen-blkback: backend/vbd/1/51713: using 4 queues, > > protocol 1 (arm-abi) persistent grants > > [ 65.357846] xen-blkback: backend/vbd/1/51714: using 4 queues, > > protocol 1 (arm-abi) persistent grants > > [ 65.514054] vif vif-1-0 vif1.0: Guest Rx ready > > [ 65.518485] IPv6: ADDRCONF(NETDEV_CHANGE): vif1.0: link becomes > > ready > > [ 65.525021] xenbr0: port 2(vif1.0) entered blocking state > > [ 65.530359] xenbr0: port 2(vif1.0) entered forwarding state > > [ 65.815976] xen_add_phys_to_mach_entry: cannot add > > pfn=0x0000000000063772 -> mfn=0x000000000072abb0: pfn=0x0000000000063772 > > -> mfn=0x0000000000727aad already exists > > [ 65.834442] xen_add_phys_to_mach_entry: cannot add > > pfn=0x000000000006374e -> mfn=0x000000000072abb0: pfn=0x000000000006374e > > -> mfn=0x0000000000727aad already exists > > [ 66.025979] xen_add_phys_to_mach_entry: cannot add > > pfn=0x000000000006379c -> mfn=0x000000000072abb3: pfn=0x000000000006379c > > -> mfn=0x000000000072abb1 already exists > > [ 66.273534] xen_add_phys_to_mach_entry: cannot add > > pfn=0x0000000000063731 -> mfn=0x0000000000727c3d: pfn=0x0000000000063731 > > -> mfn=0x0000000000727c3e already exists > > [ 66.328245] xen_add_phys_to_mach_entry: cannot add > > pfn=0x00000000000637ee -> mfn=0x0000000000727c3f: pfn=0x00000000000637ee > > -> mfn=0x0000000000727c3d already exists > > I was expecting Stefano to answer here as he knows better than me this part of > the code. > > Linux is storing the conversion between pfn (guest frame number) to the mfn > (machine frame number) in an RB-tree. This will be used by the swiotlb code to > know if a buffer is contiguous in the physical RAM. > > In your case, the log says that there was already a mapping pfn <-> mfn in the > tree. It looks to me the previous mapping has not been removed correctly. > > Are you able to reproduce this reliably? If so, can you try to figure out who > added the first mapping pfn <-> mfn?
Sorry, I skimmed over the email and missed those warnings. Julien, you are correct. The mappings are added by set_foreign_p2m_mapping, which is called on gnttab_map_refs, and should be removed by clear_foreign_p2m_mapping, called by gnttab_unmap_refs. Maybe the mapping function is called twice or the unmapping function is not called when it should? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel