[Xen-devel] [TESTDAY] Test report (salvator-x)

[Iurii Artemenko]

* Hardware:
Salvator-X board with Renesas R-Car H3 SoC (ARM64)

* Software:
XEN 4.10-rc0
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/reboot/shutdown
Guest domain reboot from its console

* Comments:

On DomU startup messages like following appeared:

root@salvator-x:/home# (XEN) grant_table.c:1688:d0v2 Expanding d6 grant 
table from 0 to 1 frames
[179368.283423] rcar_gen3_thermal e61a8000.thermal: Can't register thermal 
zone
(XEN) d6v0: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d6v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d6v2: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d6v3: vGICD: unhandled word write 0x to ICACTIVER0
[179368.737451] xen-blkback: backend/vbd/6/51713: using 4 queues, protocol 
1 (arm-abi) persistent grants

Raisin is not functional as described [2]:

root@salvator-x:/raisin# ./raise test
No config file found, copying default config
[raisin] I don't know distro unknown. It might be missing packages.
[raisin] I don't know distro unknown. It might be missing packages.
[raisin] I don't know distro unknown. Cannot install packages.

[1] http://elinux.org/R-Car/Boards/Yocto-Gen3
[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test

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

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

[Stefano Stabellini]

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 0x to ICACTIVER0
> > (XEN) d1v1: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d1v2: vGICD: unhandled word write 0x to ICACTIVER0
> > (XEN) d1v3: vGICD: unhandled word write 0x 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=0x00063772 -> mfn=0x0072abb0: pfn=0x00063772
> > -> mfn=0x00727aad already exists
> > [   65.834442] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x0006374e -> mfn=0x0072abb0: pfn=0x0006374e
> > -> mfn=0x00727aad already exists
> > [   66.025979] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x0006379c -> mfn=0x0072abb3: pfn=0x0006379c
> > -> mfn=0x0072abb1 already exists
> > [   66.273534] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x00063731 -> mfn=0x00727c3d: pfn=0x00063731
> > -> mfn=0x00727c3e already exists
> > [   66.328245] xen_add_phys_to_mach_entry: cannot add
> > pfn=0x000637ee -> mfn=0x00727c3f: pfn=0x000637ee
> > -> mfn=0x00727c3d 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

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

[Julien Grall]

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 0x to ICACTIVER0
(XEN) d1v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v2: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v3: vGICD: unhandled word write 0x 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=0x00063772 -> mfn=0x0072abb0: pfn=0x00063772
-> mfn=0x00727aad already exists
[   65.834442] xen_add_phys_to_mach_entry: cannot add
pfn=0x0006374e -> mfn=0x0072abb0: pfn=0x0006374e
-> mfn=0x00727aad already exists
[   66.025979] xen_add_phys_to_mach_entry: cannot add
pfn=0x0006379c -> mfn=0x0072abb3: pfn=0x0006379c
-> mfn=0x0072abb1 already exists
[   66.273534] xen_add_phys_to_mach_entry: cannot add
pfn=0x00063731 -> mfn=0x00727c3d: pfn=0x00063731
-> mfn=0x00727c3e already exists
[   66.328245] xen_add_phys_to_mach_entry: cannot add
pfn=0x000637ee -> mfn=0x00727c3f: pfn=0x000637ee
-> mfn=0x00727c3d 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

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

[Stefano Stabellini]

On Tue, 23 May 2017, Andrii Anisov wrote:
> Raisin is not functional as described [2]:
> 
> root@salvator-x-domx:/raisin# ./raise test
> No config file found, copying default config
> [raisin] I don't know distro unknown. It might be missing packages.
> [raisin] I don't know distro unknown. It might be missing packages.
> [raisin] I don't know distro unknown. Cannot install packages.
> 
> [1] http://elinux.org/R-Car/Boards/Yocto-Gen3
> [2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test

Hi Andrii,

thanks for testing! I have just run `raise test` on ARM64 to double
check: it works OK as long as it can recognize the distro and find the
host kernel and initrd appropriately (for example, as I was using a
custom built xen and dom0 kernel I had to use the appended patch).

In your case the problem is that you are using yocto and basically there
is no yocto support in raisin at the moment: it cannot recognize it as a
distro, therefore it cannot figure out if bridge-utils is already
installed for example. It would be nice to have yocto support for it
though, I don't think it would be hard to come up with a patch and it
gives you a very quick way to do testing! ;-)


diff --git a/lib/common-tests.sh b/lib/common-tests.sh
index c07bb18..80b61d5 100644
--- a/lib/common-tests.sh
+++ b/lib/common-tests.sh
@@ -163,20 +163,11 @@ function check_guest_alive() {
 }
 
 function get_host_kernel() {
-echo "/boot/vmlinuz-`uname -r`"
+echo "/boot/kernel"
 }
 
 function get_host_initrd() {
-if [[ $DISTRO = "Debian" ]]
-then
-echo "/boot/initrd.img-`uname -r`"
-elif [[ $DISTRO = "Fedora" ]]
-then
-echo "/boot/initramfs-`uname -r`".img
-else
-echo "$PREPEND I don't know how to find the initrd" >&2
-exit 1
-fi
+echo ""
 }
 
 function cirros_network_init() {


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

[Xen-devel] [TESTDAY] Test report

[Andrii Anisov]

* 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 0x to ICACTIVER0
(XEN) d1v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v2: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v3: vGICD: unhandled word write 0x to ICACTIVER0
[   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=0x00063772 -> mfn=0x0072abb0: pfn=0x00063772 
-> mfn=0x00727aad already exists
[   65.834442] xen_add_phys_to_mach_entry: cannot add 
pfn=0x0006374e -> mfn=0x0072abb0: pfn=0x0006374e 
-> mfn=0x00727aad already exists
[   66.025979] xen_add_phys_to_mach_entry: cannot add 
pfn=0x0006379c -> mfn=0x0072abb3: pfn=0x0006379c 
-> mfn=0x0072abb1 already exists
[   66.273534] xen_add_phys_to_mach_entry: cannot add 
pfn=0x00063731 -> mfn=0x00727c3d: pfn=0x00063731 
-> mfn=0x00727c3e already exists
[   66.328245] xen_add_phys_to_mach_entry: cannot add 
pfn=0x000637ee -> mfn=0x00727c3f: pfn=0x000637ee 
-> mfn=0x00727c3d already exists


root@salvator-x-domx:

Raisin is not functional as described [2]:

root@salvator-x-domx:/raisin# ./raise test
No config file found, copying default config
[raisin] I don't know distro unknown. It might be missing packages.
[raisin] I don't know distro unknown. It might be missing packages.
[raisin] I don't know distro unknown. Cannot install packages.

[1] http://elinux.org/R-Car/Boards/Yocto-Gen3
[2] https://wiki.xenproject.org/wiki/Xen_ARM_Manual_Smoke_Test

--

*Andrii Anisov*



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

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

[Julien Grall]

On 16/05/16 14:41, Edgar E. Iglesias wrote:

On Mon, May 16, 2016 at 02:20:24PM +0100, Julien Grall wrote:
No, they are not necessary. We have a few options.

1. If we do nothing, the ZynqMP boards with PCIe support won't even boot
dom0.

2. A safe option is to disable the PCIe node in the ZynqMP platform.
That'll boot dom0 but PCIe won't be functional.

3. If we get something like this patch in, we'll get dom0 to boot with
PCIe support hopefully working in dom0.

Thanks for the review. I'll spin a proper patch and we can discuss/consider
if it's worth merging for 4.7 or if we go with option nr 2.


Please mention the options in the patch, and if possible the pros/cons.

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Edgar E. Iglesias]

On Mon, May 16, 2016 at 02:20:24PM +0100, Julien Grall wrote:
> Hello Edgar,
> 
> On 14/05/16 20:04, Edgar E. Iglesias wrote:
> >On Sat, May 14, 2016 at 07:15:55PM +0100, Julien Grall wrote:
> >You can see that it is used in the interrupt-map properties.
> >IIUC, the interrupt lines connected to the pcie_intc controller
> >are simply going to be combined into the "intx" line IRQ 116 on
> >going from the pcie bridge towards the gic.
> >
> >I don't think we need to do much than to ignore the node but what
> >we present to dom0 must look the same..
> 
> I think you are right. I expect the platform to only have one main interrupt
> controller (i.e the GIC), the others would be connected to the main one.
> 
> Therefore, the interrupts will have no meaning for the GIC and could be
> ignored.
> 
> FWIW, we already have a such check in handle_device.

Thanks Julien, I'll have a look at handle_device.


> 
> >
> >>
> >>>
> >>>Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
> >>>without PCIe support).
> >>>
> >>>Does it make sense to try to fix this problem this late inte the
> >>>release cycle? (I can have a closer look and propose a possible fix
> >>>for discussion)
> >>
> >>I would try to fix it in Xen 4.7 if the patch is simple. Otherwise we could
> >>backport it after the release.
> >
> >OK, great.
> >I'll have a closer look too then.
> >
> >I was trying this, but it may be too permissive:
> >
> >diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> >index 0ed86a7..68cb162 100644
> >--- a/xen/common/device_tree.c
> >+++ b/xen/common/device_tree.c
> >@@ -1176,6 +1176,15 @@ int dt_for_each_irq_map(const struct dt_device_node 
> >*dev,
> >  for ( i = 0; i < pintsize; i++ )
> >  dt_raw_irq.specifier[i] = dt_read_number(imap + i, 1);
> >
> >+if (dt_raw_irq.controller != dt_interrupt_controller) {
> 
> Coding style.
> 
> >+/* If this is not the main interrupt controller, we assume
> >+ * it's part of a bus-bridge and ignore remapping IRQs for it.
> >+ * Xen only supports one interrupt controller at the moment.  */
> 
> This comment is not true for every case. The interrupt controller may not be
> part of the bus-bridge.
> 
> One platform with multiple interrupt controller, I expect to always see one
> main controller, the others would be connected to the main one. So, the
> interrupt will have no meaning for the GIC.
> 
> >+imap += pintsize;
> >+imaplen -= pintsize;
> 
> I would add a dt_printk to mention that the IRQ has been skipped.
> 
> >+continue;
> >+}
> 
> Please send a formal patch to the ML. What would be the drawback if this
> patch doesn't reach Xen 4.7? I.e Are PCI devices necessary to run the
> platform?

No, they are not necessary. We have a few options.

1. If we do nothing, the ZynqMP boards with PCIe support won't even boot
   dom0.

2. A safe option is to disable the PCIe node in the ZynqMP platform.
   That'll boot dom0 but PCIe won't be functional.

3. If we get something like this patch in, we'll get dom0 to boot with
   PCIe support hopefully working in dom0.

Thanks for the review. I'll spin a proper patch and we can discuss/consider
if it's worth merging for 4.7 or if we go with option nr 2.

Best regards,
Edgar

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Julien Grall]

Hello Edgar,

On 14/05/16 20:04, Edgar E. Iglesias wrote:

On Sat, May 14, 2016 at 07:15:55PM +0100, Julien Grall wrote:
You can see that it is used in the interrupt-map properties.
IIUC, the interrupt lines connected to the pcie_intc controller
are simply going to be combined into the "intx" line IRQ 116 on
going from the pcie bridge towards the gic.

I don't think we need to do much than to ignore the node but what
we present to dom0 must look the same..


I think you are right. I expect the platform to only have one main 
interrupt controller (i.e the GIC), the others would be connected to the 
main one.


Therefore, the interrupts will have no meaning for the GIC and could be 
ignored.


FWIW, we already have a such check in handle_device.







Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
without PCIe support).

Does it make sense to try to fix this problem this late inte the
release cycle? (I can have a closer look and propose a possible fix
for discussion)


I would try to fix it in Xen 4.7 if the patch is simple. Otherwise we could
backport it after the release.


OK, great.
I'll have a closer look too then.

I was trying this, but it may be too permissive:

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..68cb162 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1176,6 +1176,15 @@ int dt_for_each_irq_map(const struct dt_device_node *dev,
  for ( i = 0; i < pintsize; i++ )
  dt_raw_irq.specifier[i] = dt_read_number(imap + i, 1);

+if (dt_raw_irq.controller != dt_interrupt_controller) {


Coding style.


+/* If this is not the main interrupt controller, we assume
+ * it's part of a bus-bridge and ignore remapping IRQs for it.
+ * Xen only supports one interrupt controller at the moment.  */


This comment is not true for every case. The interrupt controller may 
not be part of the bus-bridge.


One platform with multiple interrupt controller, I expect to always see 
one main controller, the others would be connected to the main one. So, 
the interrupt will have no meaning for the GIC.



+imap += pintsize;
+imaplen -= pintsize;


I would add a dt_printk to mention that the IRQ has been skipped.


+continue;
+}


Please send a formal patch to the ML. What would be the drawback if this 
patch doesn't reach Xen 4.7? I.e Are PCI devices necessary to run the 
platform?


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Wei Liu]

On Sat, May 14, 2016 at 09:04:35PM +0200, Edgar E. Iglesias wrote:
[...]
> > Was PCIe working on Xen 4.6? If yes, it's the regression and we could
> > consider it as a blocker for the release (CC Wei for that).
> 
> No, these PCIe nodes were added recently.
> The device tree bindings were different before but after discussing
> with the upstream Linux folks they got changed.
> 

OK, so this is not a blocker for 4.7.

It would be OK to have a board specific quirk for 4.7 though so that
people just don't blindly stumble upon this issue. From my point of view
I would happily accept one such patch because you're the de facto
maintainer of that board. :-)

Anything that touches common code will be scrutinised though. The patch
you posted looks very hacky to me at first glance.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Edgar E. Iglesias]

On Sat, May 14, 2016 at 07:15:55PM +0100, Julien Grall wrote:
> Hello Edgar,
> 
> Thank you for the testing.
> 
> On 13/05/2016 21:34, Edgar E. Iglesias wrote:
> >* Hardware: ZCU102 ZynqMP board
> >* Software: Rolled my own dom0 linux
> >* Tested: Start dom0
> >
> >The test fails with the following error:
> >(XEN) I/O virtualisation enabled
> >(XEN)  - Dom0 mode: Relaxed
> >(XEN) Interrupt remapping enabled
> >(XEN) *** LOADING DOMAIN 0 ***
> >(XEN) Loading kernel from boot module @ 0008
> >(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
> >(XEN) BANK[0] 0x002000-0x004000 (512MB)
> >(XEN) Grant table range: 0x007fe0-0x007fe5f000
> >(XEN) smmu: /amba/smmu@fd80: d0: p2maddr 0x7ff64000
> >(XEN) Device tree generation failed (-22).
> 
> 
> You could uncomment //#define DEBUG_DT in domain_build.c, rebuild and paste
> the log here?

Yes, I've pasted it to the end of the email.

> 
> >
> >It's the PCIe node that is causing trouble, the bindings are here:
> >http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> >
> >It's that inner interrupt-controller node that is causing problems as
> >Xen/ARM only supports one interrupt-controller node (IIUC).
> 
> It should not matter, unless the interrupt controller is used to describe
> some interrupts in device-tree.
> 
> Is this node used later in the DT?

Actually it is only used from the PCIe node itself. Pasting the device tree 
node:

pcie: pcie@fd0e {
compatible = "xlnx,nwl-pcie-2.11";
status = "disabled";
#address-cells = <3>;
#size-cells = <2>;
#interrupt-cells = <1>;
device_type = "pci";
interrupt-parent = <>;
interrupts = <0 118 4>,
 <0 116 4>,
 <0 115 4>, /* MSI_1 [63...32] */
 <0 114 4>; /* MSI_0 [31...0] */
interrupt-names = "misc", "intx", "msi_1", "msi_0";
reg = <0x0 0xfd0e 0x0 0x1000>,
  <0x0 0xfd48 0x0 0x1000>,
  <0x0 0xe000 0x0 0x100>;
reg-names = "breg", "pcireg", "cfg";
ranges = <0x0200 0x 0xe100 0x 
0xe100 0 0x0f00>;
interrupt-map-mask = <0x0 0x0 0x0 0x7>;
interrupt-map = <0x0 0x0 0x0 0x1 _intc 0x1>,
<0x0 0x0 0x0 0x2 _intc 0x2>,
<0x0 0x0 0x0 0x3 _intc 0x3>,
<0x0 0x0 0x0 0x4 _intc 0x4>;
pcie_intc: legacy-interrupt-controller {
interrupt-controller;
#address-cells = <0>;
#interrupt-cells = <1>;
};
};


You can see that it is used in the interrupt-map properties.
IIUC, the interrupt lines connected to the pcie_intc controller
are simply going to be combined into the "intx" line IRQ 116 on
going from the pcie bridge towards the gic.

I don't think we need to do much than to ignore the node but what
we present to dom0 must look the same..

> 
> >
> >Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
> >without PCIe support).
> >
> >Does it make sense to try to fix this problem this late inte the
> >release cycle? (I can have a closer look and propose a possible fix
> >for discussion)
> 
> I would try to fix it in Xen 4.7 if the patch is simple. Otherwise we could
> backport it after the release.

OK, great.
I'll have a closer look too then.

I was trying this, but it may be too permissive:

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..68cb162 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1176,6 +1176,15 @@ int dt_for_each_irq_map(const struct dt_device_node *dev,
 for ( i = 0; i < pintsize; i++ )
 dt_raw_irq.specifier[i] = dt_read_number(imap + i, 1);
 
+if (dt_raw_irq.controller != dt_interrupt_controller) {
+/* If this is not the main interrupt controller, we assume
+ * it's part of a bus-bridge and ignore remapping IRQs for it.
+ * Xen only supports one interrupt controller at the moment.  */
+imap += pintsize;
+imaplen -= pintsize;
+continue;
+}


> 
> >
> >Or should we disable the PCIe for ZynqMP for now and try to fix this
> >properly for 4.8?
> 
> Was PCIe working on Xen 4.6? If yes, it's the regression and we could
> consider it as a blocker for the release (CC Wei for that).

No, these PCIe nodes 

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

[Julien Grall]

Hello Edgar,

Thank you for the testing.

On 13/05/2016 21:34, Edgar E. Iglesias wrote:

* Hardware: ZCU102 ZynqMP board
* Software: Rolled my own dom0 linux
* Tested: Start dom0

The test fails with the following error:
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0008
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x002000-0x004000 (512MB)
(XEN) Grant table range: 0x007fe0-0x007fe5f000
(XEN) smmu: /amba/smmu@fd80: d0: p2maddr 0x7ff64000
(XEN) Device tree generation failed (-22).



You could uncomment //#define DEBUG_DT in domain_build.c, rebuild and 
paste the log here?




It's the PCIe node that is causing trouble, the bindings are here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt

It's that inner interrupt-controller node that is causing problems as
Xen/ARM only supports one interrupt-controller node (IIUC).


It should not matter, unless the interrupt controller is used to 
describe some interrupts in device-tree.


Is this node used later in the DT?



Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
without PCIe support).

Does it make sense to try to fix this problem this late inte the
release cycle? (I can have a closer look and propose a possible fix
for discussion)


I would try to fix it in Xen 4.7 if the patch is simple. Otherwise we 
could backport it after the release.




Or should we disable the PCIe for ZynqMP for now and try to fix this
properly for 4.8?


Was PCIe working on Xen 4.6? If yes, it's the regression and we could 
consider it as a blocker for the release (CC Wei for that).


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report

[Edgar E. Iglesias]

* Hardware: ZCU102 ZynqMP board
* Software: Rolled my own dom0 linux
* Tested: Start dom0

The test fails with the following error:
(XEN) I/O virtualisation enabled
(XEN)  - Dom0 mode: Relaxed
(XEN) Interrupt remapping enabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) Loading kernel from boot module @ 0008
(XEN) Allocating 1:1 mappings totalling 512MB for dom0:
(XEN) BANK[0] 0x002000-0x004000 (512MB)
(XEN) Grant table range: 0x007fe0-0x007fe5f000
(XEN) smmu: /amba/smmu@fd80: d0: p2maddr 0x7ff64000
(XEN) Device tree generation failed (-22).

It's the PCIe node that is causing trouble, the bindings are here:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt

It's that inner interrupt-controller node that is causing problems as
Xen/ARM only supports one interrupt-controller node (IIUC).

Disabling the pcie node for zynqmp boards gets dom0 to boot (obviously
without PCIe support).

Does it make sense to try to fix this problem this late inte the
release cycle? (I can have a closer look and propose a possible fix
for discussion)

Or should we disable the PCIe for ZynqMP for now and try to fix this
properly for 4.8?

Any ideas/suggestions?

Best regards,
Edgar

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report

[Tamas K Lengyel]

* Hardware: Intel(R) Xeon(R) CPU E5-2430
* Sofware: Debian Jessie dom0
* Functionality tested:
xl save/resume
vm_event/mem_access/monitor/altp2m

Comment: everything works as expected.

Cheers,
Tamas

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

[Meng Xu]

On Fri, May 13, 2016 at 5:31 AM, Wei Liu  wrote:
> On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
>> * Hardware:
>> CPU: Intel Core2 Quad Q9400
>> Total Memory: 2791088 kB
>>
>> * Software:
>> Ubuntu 14.04
>> Linux kernel: 3.13.0-68
>>
>> * Guest operating systems:
>> Ubuntu 14.04 (PV)
>>
>> * Functionality tested:
>> xl sched-rtds (for set/get per-VCPU parameters)
>>
>> * Comments:
>> All examples about "xl sched-rtds" in xl mannual page
>> 
>> have been tested,
>> and all run successfully.
>>
>> If users type in wrong parameters (e.g., budget > period), the
>> error/warnning messages
>> are returned correctly as well.
>>
>
> Good, so RTDS works as expected. Thanks for your report.

Hi Wei,

I'd like to share some of my experience with the improved RTDS scheduler.
It is not a formal report. But hopefully it is some useful information.

I have been using the improved RTDS in the staging for a while. I
haven't seen any weird issue. Because I also modify the other parts of
Xen a bit, so the test is not for xen 4.7-rc2 though. That's why we
have Chong test the xen 4.7-rc2. Thank you very much, Chong, for your
nice test report! :-)

The workload types I run are:
1) Compile linux or xen kernels in parallel. The number of compiling
jobs is usually double the number of cores allocated for dom0.
2) Run cpu-intensive task or memory-intensive task,which access a large array.

Best,

Meng

-- 
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [TESTDAY] Test report - xl sched-rtds

[Wei Liu]

On Thu, May 12, 2016 at 02:00:06PM -0500, Chong Li wrote:
> * Hardware:
> CPU: Intel Core2 Quad Q9400
> Total Memory: 2791088 kB
> 
> * Software:
> Ubuntu 14.04
> Linux kernel: 3.13.0-68
> 
> * Guest operating systems:
> Ubuntu 14.04 (PV)
> 
> * Functionality tested:
> xl sched-rtds (for set/get per-VCPU parameters)
> 
> * Comments:
> All examples about "xl sched-rtds" in xl mannual page
> 
> have been tested,
> and all run successfully.
> 
> If users type in wrong parameters (e.g., budget > period), the
> error/warnning messages
> are returned correctly as well.
> 

Good, so RTDS works as expected. Thanks for your report.

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report - xl sched-rtds

[Chong Li]

* Hardware:
CPU: Intel Core2 Quad Q9400
Total Memory: 2791088 kB

* Software:
Ubuntu 14.04
Linux kernel: 3.13.0-68

* Guest operating systems:
Ubuntu 14.04 (PV)

* Functionality tested:
xl sched-rtds (for set/get per-VCPU parameters)

* Comments:
All examples about "xl sched-rtds" in xl mannual page

have been tested,
and all run successfully.

If users type in wrong parameters (e.g., budget > period), the
error/warnning messages
are returned correctly as well.

Chong Li


-- 
Chong Li
Department of Computer Science and Engineering
Washington University in St.louis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [TESTDAY] Test report of ARM CubieTruck with Xen 4.7 (staging)

[Julien Grall]

Hi Konrad,

Thank you for testing Xen ARM on the cubietruck!

On 30/03/16 16:30, Konrad Rzeszutek Wilk wrote:

*Hardware: ARM CubieTruck A20 (2GB).

*Software:  Linaro 14.04 with
  - Xen 4.7 (829e03c acpi: drop CONFIG_ACPI_BOOT and use CONFIG_ACPI instead + 
xsplice.v5)
  - Linux v4.5 (with revert of 88f8b1bb41c6208f81b6a480244533ded7b59493 "
stmmac: Fix 'eth0: No PHY found' regression")
  - Linux v4.4
  - Linux v4.3
  - Linux v4.2

*Guest operating systems: Ubuntu 14.04

*Functionality tested: ARM Manual Smoke Test

*Comments:

I get these:

(XEN) Freed 260kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v0: vGICD: unhandled word write 0x to ICACTIVER0


Xen doesn't currently emulate the registers I*ACTIVERn. For now, it's 
not a big problem as the usage of I*ACTIVER0 is very limited. This will 
need to be supported properly when migration will be added for ARM.


Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report of ARM CubieTruck with Xen 4.7 (staging)

[Konrad Rzeszutek Wilk]

*Hardware: ARM CubieTruck A20 (2GB).

*Software:  Linaro 14.04 with
 - Xen 4.7 (829e03c acpi: drop CONFIG_ACPI_BOOT and use CONFIG_ACPI instead + 
xsplice.v5)
 - Linux v4.5 (with revert of 88f8b1bb41c6208f81b6a480244533ded7b59493 "
   stmmac: Fix 'eth0: No PHY found' regression")
 - Linux v4.4
 - Linux v4.3
 - Linux v4.2

*Guest operating systems: Ubuntu 14.04

*Functionality tested: ARM Manual Smoke Test

*Comments:

I get these:

(XEN) Freed 260kB init memory.
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER4
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER8
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER12
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER16
(XEN) d0v0: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d0v1: vGICD: unhandled word write 0x to ICACTIVER0
(XEN) d1v0: vGICD: unhandled word write 0x to ICACTIVER0

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report

[Tamas K Lengyel]

* Hardware:

Intel(R) Core(TM) i7-2600 CPU, DQ67SW motherboard

* Software:

Xen 4.6 rc4, Ubuntu 14.04 LTS, Kernel 4.2 with all Xen modules built-in

* Guest operating systems:

Windows 7 SP1 x86 and x64, Ubuntu 14.04, Ubuntu 15.04

* Functionality tested:

xl save/restore
pvgrub2
VT-d device pass-through (rdm_policy=relaxed is now required for some
devices)
XSM with secondary control domain
VM event subsystem on x86: mem_access, int3, cr events
Mem_sharing

* Comments:

Everything works as expected.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Wei Liu]

On Thu, Oct 01, 2015 at 10:59:05AM -0600, Tamas K Lengyel wrote:
> * Hardware:
> 
> Intel(R) Core(TM) i7-2600 CPU, DQ67SW motherboard
> 
> * Software:
> 
> Xen 4.6 rc4, Ubuntu 14.04 LTS, Kernel 4.2 with all Xen modules built-in
> 
> * Guest operating systems:
> 
> Windows 7 SP1 x86 and x64, Ubuntu 14.04, Ubuntu 15.04
> 
> * Functionality tested:
> 
> xl save/restore
> pvgrub2
> VT-d device pass-through (rdm_policy=relaxed is now required for some
> devices)
> XSM with secondary control domain
> VM event subsystem on x86: mem_access, int3, cr events
> Mem_sharing
> 

Wow, this is quite a few test cases.

> * Comments:
> 
> Everything works as expected.

Great! Thank you for your report!

Wei.
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

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

[Konrad Rzeszutek Wilk]

On Sat, Dec 13, 2014 at 09:23:48AM +, Juergen Schinker wrote:
 Subject: [TESTDAY] Test report Xen 4.5.0-RC3
  
 * Hardware:
  Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
  32G Ram
 
 * Software:
   Debian Jessie
 
 * Guest operating systems:
   Debian Jessie
 * Functionality tested:
   xl
   pygrub
 
 * Comments:
 
 had to compile with
 configure --enable-githttp --enable-systemd


Thank you for posting that!
 
 ___
 Xen-devel mailing list
 Xen-devel@lists.xen.org
 http://lists.xen.org/xen-devel

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [TESTDAY] Test report Xen 4.5.0-RC3

[Juergen Schinker]

Subject: [TESTDAY] Test report Xen 4.5.0-RC3
 
* Hardware:
 Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (4cores -1 socket)
 32G Ram

* Software:
  Debian Jessie

* Guest operating systems:
  Debian Jessie
* Functionality tested:
  xl
  pygrub

* Comments:

had to compile with
configure --enable-githttp --enable-systemd

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel