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