[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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
    [   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?


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.