Re: [Xen-devel] [TESTDAY] Test report

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel