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

[Julien Grall <julien.grall@xxxxxxx>]

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?
Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel