[Xen-devel] Linux 4.4 boot crash on xen 4.5.3 with dom0_mem == max

[Ed Swierk]

I'm trying to figure out a crash when booting a Linux 4.4 dom0 on
a recent stable xen 4.5. I'm capping the dom0 memory by setting
dom0_mem=18432M,max:18432M on the xen command line, and the kernel
config has CONFIG_XEN_BALLOON unset.

The crash seems dependent on the contents of the e820 table; identical
hardware with a different BIOS version does not crash.

I instrumented various functions arch/x86/xen/setup.c, and isolated
the problem to the final call to xen_del_extra_mem() in
xen_remap_memory(). The BUG_ON(n_pfns > size_r) assertion is triggered
in the "Start of region" block.

...
[0.00] Released 0 page(s)
[0.00] e820: BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0005] usable
[0.00] Xen: [mem 0x0006-0x00067fff] reserved
[0.00] Xen: [mem 0x00068000-0x0009afff] usable
[0.00] Xen: [mem 0x000a-0x000f] reserved
[0.00] Xen: [mem 0x0010-0x75afdfff] usable
[0.00] Xen: [mem 0x75bab000-0x7a1f5fff] usable
[0.00] Xen: [mem 0x7b7d7000-0x7b7f] usable
[0.00] Xen: [mem 0x7bf0-0x7bff] usable
[0.00] Xen: [mem 0xc7ffc000-0xc7ffcfff] reserved
[0.00] Xen: [mem 0xfbffc000-0xfbffcfff] reserved
[0.00] Xen: [mem 0xfec0-0xfec01fff] reserved
[0.00] Xen: [mem 0xfec4-0xfec40fff] reserved
[0.00] Xen: [mem 0xfed2-0xfed2] usable
[0.00] Xen: [mem 0xfee0-0xfeef] reserved
[0.00] Xen: [mem 0x0001-0x000505de9fff] usable
[0.00] bootconsole [xenboot0] enabled
[0.00] debug: ignoring loglevel setting.
[0.00] NX (Execute Disable) protection: active
[0.00] e820: user-defined physical RAM map:
[0.00] user: [mem 0x-0x0005] usable
[0.00] user: [mem 0x0006-0x00067fff] reserved
[0.00] user: [mem 0x00068000-0x0009afff] usable
[0.00] user: [mem 0x000a-0x000f] reserved
[0.00] user: [mem 0x0010-0x75afdfff] usable
[0.00] user: [mem 0x75bab000-0x7a1f5fff] usable
[0.00] user: [mem 0x7b7d7000-0x7b7f] usable
[0.00] user: [mem 0x7bf0-0x7bff] usable
[0.00] user: [mem 0x8000-0x8fff] reserved
[0.00] user: [mem 0xc7ffc000-0xc7ffcfff] reserved
[0.00] user: [mem 0xfbffc000-0xfbffcfff] reserved
[0.00] user: [mem 0xfec0-0xfec01fff] reserved
[0.00] user: [mem 0xfec4-0xfec40fff] reserved
[0.00] user: [mem 0xfed2-0xfed2] usable
[0.00] user: [mem 0xfee0-0xfeef] reserved
[0.00] user: [mem 0x0001-0x000505de9fff] usable
[0.00] SMBIOS 2.7 present.
[0.00] DMI: ABCD, BIOS SE5C610.86B.01.01.0009.C1.060120151350 06/01/2015
[0.00] Hypervisor detected: Xen
[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0x505dea max_arch_pfn = 0x4
[0.00] MTRR: Disabled
[0.00] e820: last_pfn = 0xfed30 max_arch_pfn = 0x4
[0.00] Scanning 1 areas for low memory corruption
[0.00] Base memory trampoline at [88095000] 95000 size 24576
[0.00] BRK [0x02f67000, 0x02f67fff] PGTABLE
[0.00] BRK [0x02f68000, 0x02f68fff] PGTABLE
[0.00] BRK [0x02f69000, 0x02f69fff] PGTABLE
[0.00] BRK [0x02f6a000, 0x02f6afff] PGTABLE
[0.00] BRK [0x02f6b000, 0x02f6bfff] PGTABLE
[0.00] BRK [0x02f6c000, 0x02f6cfff] PGTABLE
[0.00] RAMDISK: [mem 0x0400-0x14afefff]
[0.00] ACPI: Early table checksum verification disabled
[0.00] ACPI: RSDP 0x000F0460 24 (v02 INTEL )
[0.00] ACPI: XSDT 0x7B78D188 CC (v01 INTEL  S2600WT  
 INTL 0113)
[0.00] ACPI: FACP 0x7B7D2000 F4 (v04 INTEL  S2600WT  
 INTL 20091013)
[0.00] ACPI: DSDT 0x7B798000 0313B2 (v02 INTEL  S2600WT  
0003 INTL 20091013)
[0.00] ACPI: FACS 0x7B6FC000 40
[0.00] ACPI: HPET 0x7B7D1000 38 (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: APIC 0x7B7D 00085C (v03 INTEL  S2600WT  
 INTL 20091013)
[0.00] ACPI: MCFG 0x7B7CF000 3C (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: MSCT 0x7B7CE000 90 (v01 INTEL  S2600WT  
0001 INTL 20091013)
[0.00] ACPI: SLIT 

[Xen-devel] [xen-4.6-testing test] 94491: regressions - FAIL

[osstest service owner]

flight 94491 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94491/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93932
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93932

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z7 days
Failing since 94000  2016-05-10 18:10:33 Z6 days   10 attempts
Testing same since94036  2016-05-11 15:51:26 Z5 days9 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 

[Xen-devel] [qemu-upstream-4.3-testing test] 94494: trouble: blocked/broken

[osstest service owner]

flight 94494 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94494/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  100 days
Testing same since93977  2016-05-10 11:09:16 Z6 days   17 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Meng Xu]

On Mon, May 16, 2016 at 7:27 PM, Kyle Temkin  wrote:
> Hi, Meng:
>

Hi Kyle,

> Julien is correct-- a coworker and I are working on support for Tegra
> SoCs, and we've made pretty good progress; there's work yet to be
> done, but we have dom0 and guests booting on the Jetson TK1, Jetson
> TX1, and the Google Pixel C. We hope to get a patch set out soon--
> unfortunately, our employer has to take some time to verify that
> everything's okay to be open-sourced, so I can't send out our
> work-in-progress just yet. We'll have an RFC patchset out soon, I
> hope!

Looking forward to your RFC patchset... Could you please cc. me when
you send out your RFC patchset. I really love to have a look at (maybe
review) it.

>
> There are two main hardware differences that cause Tegra SoCs to have
> trouble with Xen:
>
> - The primary interrupt controller for those systems isn't a single
> GIC, as Xen expects. Instead, there's an NVIDIA Legacy Interrupt
> Controller (LIC, or ICTLR) that gates all peripheral interrupts before
> passing them to a standard GICv2. This interrupt controller has to be
> programmed to ensure Xen can receive interrupts from the hardware
> (e.g. serial), programmed to ensure that interrupts for pass-through
> devices are correctly unmasked, and virtualized so dom0 can program
> the "sections" related to interrupts not being routed to Xen or to a
> domain for hardware passthrough.
>
> - The serial controller on the Tegra SoCs doesn't behave in the same
> was as most NS16550-compatibles; it actually adheres to the NS16550
> spec a little more rigidly than most compatible controllers. A
> coworker (Chris Patterson, cc'd) figured out what was going on; from
> what I understand, most 16550s generate the "transmit ready" interrupt
> once, when the device first can accept new FIFO entries. Both the
> original 16550 and the Tegra implementation generate the "transmit
> ready" interrupt /continuously/ when there's space available in the
> FIFO, slewing the CPU with a stream of constant interrupts.

I see. Thank you very much for explaining this so clearly! :-)

>
> What you're seeing is likely a symptom of the first difference. In
> your logs, you see messages that indicate Xen is having trouble
> correctly routing IRQ that are parented by the legacy interrupt
> controller:
>
>> irq 0 not connected to primary controller.Connected to 
>> /interrupt-controller@60004000

Right. I see the root issue now.  Thank you so much for pointing it out!

>
> The issue here is that Xen is currently explicitly opting not to route
> legacy-interrupt-controller interrupts, as they don't belong to the
> primary GIC. As a result, these interrupts never make it to dom0. The
> logic that needs to be tweaked is here:
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain_build.c;h=00dc07af637b67153d33408f34331700dff84f93;hb=HEAD#l1137
>
> We re-write this logic in our forthcoming patch-set to be more
> general. As an interim workaround, you might opt to rewrite that logic
> so LIC interrupts (which have an interrupt-parent compatible with
> "tegra124-ictlr", in your case) can be routed by Xen, as well. Off the
> top of my head, a workaround might look like:
>
> /*
> * Don't map IRQ that have no physical meaning
> * ie: IRQ whose controller is not the GIC
> */
> - if ( rirq.controller != dt_interrupt_controller )
> +if ( (rirq.controller != dt_interrupt_controller) &&
> (!dt_device_is_compatible(rirq.controller, "tegra124-ictlr") )

It should have "nvidia" before "tegra124-ictlr". ;-)
After change it to
!dt_device_is_compatible(rirq.controller, "nvidia , tegra124-ictlr")

dom0 boots up~~~ :-D

>
> Of course, that's off-the-cuff code I haven't tried, but hopefully it
> should help to get you started.

Sure! It does work and get me started! I really appreciate your help
and explanation!

Looking forward to your RFC patch set. :-)

Thank you again for your help and time in this issue! It helps a lot!

Best Regards,

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] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Tian, Kevin]

> From: Xu, Quan
> Sent: Monday, May 16, 2016 11:26 PM
> 
> On May 13, 2016 11:28 PM, Jan Beulich  wrote:
> > >>> On 22.04.16 at 12:54,  wrote:
> > > --- a/docs/misc/xen-command-line.markdown
> > > +++ b/docs/misc/xen-command-line.markdown
> > > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also
> > specified vpmu will be turned off.
> > >  As the virtualisation is not 100% safe, don't use the vpmu flag on
> > > production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
> > >
> > > +### vtd\_qi\_timeout (VT-d)
> > > +> `= `
> > > +
> > > +> Default: `1`
> > > +
> > > +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
> > > +
> > > +By default, the timeout is 1ms. When you see error 'Queue invalidate
> > > +wait descriptor timed out', try increasing this value.
> >
> > So when someone enables ATS, will the 1ms timeout apply to the dev iotlb
> > invalidations too?
> 
> Yes,
> The timeout is the same for IOTLB, Context, IEC and Device-TLB invalidation.
> 
> > If so, that's surely too short, and would ideally be adjusted
> > automatically, but the need for a higher timeout in that case should in any
> > event be mentioned here.
> 
> I can try to use 1ms for IOTLB, Context and  IEC invalidation. As mentioned, 
> 1 ms is
> enough for IOTLB, Context and  IEC invalidation.
> What about 10 ms for Device-TLB (10 ms is just a higher timeout,  no specific 
> meaning)?

I remember in earlier discussion we agreed to use 1ms as the default for both
IOMMU-side and device-side flushes. For device-side flushes, we checked internal
HW team that 1ms is a reasonable threshold for integrated devices. It's likely
insufficient for discrete devices. We may check any automatic adjustment method
later when it becomes a real problem. For now, please elaborate above 
information
in the text.

> 
> >
> > Apart from that aspect this patch seems to be ready, but will clearly need 
> > a VT-
> > d maintainer's ack.
> >
> 
> Thanks for your review. I will also test this patch against the last commit ( 
> I am still out
> of office and I will do it around this Wednesday).
> 

Jan, do you want me to ack this series now, or wait until previous series 
handling error is checked in? (I thought you wanted the later in one of
your replies earlier). Either way is OK to me. :-)

Thanks
Kevin

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

[Xen-devel] [xen-4.5-testing test] 94488: regressions - FAIL

[osstest service owner]

flight 94488 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94488/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 94469
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 94469

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 94469 like 93989
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 93928
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
93989

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 94469 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 94469 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z6 days
Testing same since94030  2016-05-11 13:08:55 Z5 days9 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  

[Xen-devel] [ovmf test] 94497: regressions - FAIL

[osstest service owner]

flight 94497 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94497/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf f85d3ce2efc21da5d874b3e4d880e5682c6fe7cb
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  160 days
Failing since 65593  2015-12-08 23:44:51 Z  160 days  271 attempts
Testing same since94493  2016-05-16 18:46:00 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hegde, Nagaraj P nagaraj-p.he...@hpe.com
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  

Re: [Xen-devel] xen: 82599 passthrough problem

[liuenliang]

Thank you for your reply.
For the first question, the BUG I hit is :

static irq_guest_action_t *__pirq_guest_unbind(
struct domain *d, int pirq, struct irq_desc *desc)
{
unsigned intirq;
irq_guest_action_t *action;
cpumask_t   cpu_eoi_map;
int i;

action = (irq_guest_action_t *)desc->action;
irq = desc - irq_desc;

if ( unlikely(action == NULL) )
{
dprintk(XENLOG_G_WARNING, "dom%d: pirq %d: desc->action is NULL!\n",
d->domain_id, pirq);
return NULL;
}

BUG_ON(!(desc->status & IRQ_GUEST));

for ( i = 0; (i < action->nr_guests) && (action->guest[i] != d); i++ ) 
continue;

BUG_ON(i == action->nr_guests);  // (This BUG_ON is hit)

For the second question, there are no more information from the panic on the 
console, and I do not care about that because I trigger panic when BUG_ON is 
hit. 
So my question is what the reason of the BUG_ON is, and how can I fix it.
Thanks.


Enliang Liu
Best Regards

-Original Message-
From: Andrew Cooper [mailto:andrew.coop...@citrix.com] 
Sent: Monday, May 16, 2016 5:56 PM
To: liuenliang; xen-devel@lists.xen.org
Cc: Fanhenglong; Hanweidong (Randy)
Subject: Re: [Xen-devel] xen: 82599 passthrough problem

On 16/05/16 04:41, liuenliang wrote:
> Hi,all:
>
> I also met this problem when passthrough 82599 to domU by SRIOV, and the call 
> stack as follows:
> (XEN) Xen call trace:
> (XEN)[] panic+0xc3/0x1a0
> (XEN)[] symbols_lookup+0x22/0x2a0
> (XEN)[] syscall_enter+0x88/0x8d
> (XEN)[] syscall_enter+0x88/0x8d
> (XEN)[] __print_symbol+0x8a/0xc0
> (XEN)[] syscall_enter+0x88/0x8d
> (XEN)[] show_stack+0x110/0x180
> (XEN)[] __pirq_guest_unbind+0x2d8/0x340
> (XEN)[] __pirq_guest_unbind+0x2d8/0x340
> (XEN)[] do_invalid_op+0x394/0x420
> (XEN)[] handle_exception_saved+0x30/0x6e
> (XEN)[] __pirq_guest_unbind+0x2d6/0x340
> (XEN)[] domain_spin_lock_irq_desc+0x64/0xa0
> (XEN)[] pirq_guest_unbind+0x5d/0x160
> (XEN)[] pci_release_devices+0x129/0x220
> (XEN)[] domain_relinquish_resources+0xa8/0x2a0
> (XEN)[] domain_kill+0x84/0x100
> (XEN)[] do_domctl+0x9c4/0x1620
> (XEN)[] syscall_enter+0x88/0x8d
>
>
> 1) The version of xen-syms is xen-syms-4.1.2_115 and the passthrough is done 
> via 'pci='. 
> 2) I using qemu-xen, and the version is 1.2.2.
> 3) This happens when I reboot the guest(HVM), but not happens all the time.
>
> BTW, the bug "corruption  caused by race conditions between device allocation 
> and deallocation to a domain." is fixed.(the link is:
> http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=15a9f34d1b1a6c50f2
> da046a6e4c6726a230d089)
>
> So, anyone who knows what is the problem and any advices? Thanks.

There are several things going on there.

First of all, you look to have hit a BUG or a WARN:

(XEN)[] __pirq_guest_unbind+0x2d6/0x340

and while trying to dump the stack to the console, you hit a further panic in:

(XEN)[] symbols_lookup+0x22/0x2a0

For the first one, use addr2line on your debug symbols to find which
BUG() you hit, which might help you diagnose the issue.

For the second one, is there any further information from the panic on the 
console?

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

[Xen-devel] [ovmf test] 94493: regressions - FAIL

[osstest service owner]

flight 94493 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94493/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf f85d3ce2efc21da5d874b3e4d880e5682c6fe7cb
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  160 days
Failing since 65593  2015-12-08 23:44:51 Z  160 days  270 attempts
Testing same since94493  2016-05-16 18:46:00 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hegde, Nagaraj P nagaraj-p.he...@hpe.com
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  

[Xen-devel] [xen-unstable test] 94487: tolerable FAIL - PUSHED

[osstest service owner]

flight 94487 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94487/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 94461
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 94461
 build-i386-rumpuserxen6 xen-buildfail   like 94461
 build-amd64-rumpuserxen   6 xen-buildfail   like 94461
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94461
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94461
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94461
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94461

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
baseline version:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf

Last test of basis94461  2016-05-16 03:01:36 Z0 days
Testing same since94487  2016-05-16 15:18:47 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Kyle Temkin]

Hi, Meng:

Julien is correct-- a coworker and I are working on support for Tegra
SoCs, and we've made pretty good progress; there's work yet to be
done, but we have dom0 and guests booting on the Jetson TK1, Jetson
TX1, and the Google Pixel C. We hope to get a patch set out soon--
unfortunately, our employer has to take some time to verify that
everything's okay to be open-sourced, so I can't send out our
work-in-progress just yet. We'll have an RFC patchset out soon, I
hope!

There are two main hardware differences that cause Tegra SoCs to have
trouble with Xen:

- The primary interrupt controller for those systems isn't a single
GIC, as Xen expects. Instead, there's an NVIDIA Legacy Interrupt
Controller (LIC, or ICTLR) that gates all peripheral interrupts before
passing them to a standard GICv2. This interrupt controller has to be
programmed to ensure Xen can receive interrupts from the hardware
(e.g. serial), programmed to ensure that interrupts for pass-through
devices are correctly unmasked, and virtualized so dom0 can program
the "sections" related to interrupts not being routed to Xen or to a
domain for hardware passthrough.

- The serial controller on the Tegra SoCs doesn't behave in the same
was as most NS16550-compatibles; it actually adheres to the NS16550
spec a little more rigidly than most compatible controllers. A
coworker (Chris Patterson, cc'd) figured out what was going on; from
what I understand, most 16550s generate the "transmit ready" interrupt
once, when the device first can accept new FIFO entries. Both the
original 16550 and the Tegra implementation generate the "transmit
ready" interrupt /continuously/ when there's space available in the
FIFO, slewing the CPU with a stream of constant interrupts.

What you're seeing is likely a symptom of the first difference. In
your logs, you see messages that indicate Xen is having trouble
correctly routing IRQ that are parented by the legacy interrupt
controller:

> irq 0 not connected to primary controller.Connected to 
> /interrupt-controller@60004000

The issue here is that Xen is currently explicitly opting not to route
legacy-interrupt-controller interrupts, as they don't belong to the
primary GIC. As a result, these interrupts never make it to dom0. The
logic that needs to be tweaked is here:

http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/arm/domain_build.c;h=00dc07af637b67153d33408f34331700dff84f93;hb=HEAD#l1137

We re-write this logic in our forthcoming patch-set to be more
general. As an interim workaround, you might opt to rewrite that logic
so LIC interrupts (which have an interrupt-parent compatible with
"tegra124-ictlr", in your case) can be routed by Xen, as well. Off the
top of my head, a workaround might look like:

/*
* Don't map IRQ that have no physical meaning
* ie: IRQ whose controller is not the GIC
*/
- if ( rirq.controller != dt_interrupt_controller )
+if ( (rirq.controller != dt_interrupt_controller) &&
(!dt_device_is_compatible(rirq.controller, "tegra124-ictlr") )

Of course, that's off-the-cuff code I haven't tried, but hopefully it
should help to get you started.

--Kyle

On Mon, May 16, 2016 at 3:39 PM, Meng Xu  wrote:
> Hi Julien,
>
> On Mon, May 16, 2016 at 1:33 PM, Julien Grall  wrote:
>> (CC Kyle who is also working on Tegra?)
>>
>> Hi Meng,
>>
>> Many people are working on Nvidia platform with different issues :/. I have
>> CCed another person which IIRC is also working on it.
>
> Sure. It's good to know others are also interested in this platform.
> It will be more useful to fix it... :-)
>
>>
>> On 16/05/16 17:33, Meng Xu wrote:
>>>
>>> On Mon, May 16, 2016 at 7:33 AM, Julien Grall 
>>> wrote:


 On 15/05/16 20:35, Meng Xu wrote:
>
>
> I'm trying to run Xen on NVIDIA Jetson TK1 board. (Right now, Xen does
> not support the Jetson board officially. But I'm thinking it may be
> very interesting and useful to see it happens, since it has GPU inside
> which is quite popular in automotive.)
>
> Now I encountered some problem to boot dom0 in Xen environment. I want
> to debug the issues and maybe fix the issues, but I'm not so sure how
> I should debug the issue more efficiently. I really appreciate it if
> you advise me a little bit about the method of how to fix the issue.
> :-)
>
> ---Below is the details
>
> I noticed the Dushyant from IBM also tried to run Xen on the Jetson
> board. (http://www.gossamer-threads.com/lists/xen/devel/422519). I
> used the same Linux kernel (Jan Kiszka's development tree -
> http://git.kiszka.org/linux.git/, branch queues/assorted) and Ian's
> Xen repo. with the hack for Jetson board. I can see the dom0 kernel
> can boot to some extend and then "stall/spin" before the dom0 kernel
> fully boot up.
>
> In order to figure out the possible issue, I boot the exact same Linux
> kernel in 

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

[Tony S]

On Mon, May 16, 2016 at 3:38 PM, Tony S  wrote:
> On Mon, May 16, 2016 at 5:37 AM, Dario Faggioli
>  wrote:
>> [Adding George again, and a few Linux/Xen folks]
>>
>> On Sat, 2016-05-14 at 18:25 -0600, Tony S wrote:
>>> In virtualized environments, sometimes we need to limit the CPU
>>> resources to a virtual machine(VM). For example in Xen, we use
>>> $ xl sched-credit -d 1 -c 50
>>>
>>> to limit the CPU resource of dom 1 as half of
>>> one physical CPU core. If the VM CPU resource is capped, the process
>>> inside the VM will have a vruntime accounting problem. Here, I report
>>> my findings about Linux process scheduler under the above scenario.
>>>
>> Thanks for this other report as well. :-)
>>
>> All you say makes sense to me, and I will think about it. I'm not sure
>> about one thing, though...
>>
>
> Hi Dario,
>
> Thank you for your reply.
>
>
>>> Description
>>> Linux CFS relies on delta_exec to charge the vruntime of processes.
>>> The variable delta_exec is the difference of a process starts and
>>> stops running on a CPU. This works well in physical machine. However,
>>> in virtual machine under capped resources, some processes might be
>>> accounted with inaccurate vruntime.
>>>
>>> For example, suppose we have a VM which has one vCPU and is capped to
>>> have as much as 50% of a physical CPU. When process A inside the VM
>>> starts running and the CPU resource of that VM runs out, the VM will
>>> be paused. Next round when the VM is allocated new CPU resource and
>>> starts running again, process A stops running and is put back to the
>>> runqueue. The delta_exec of process A is accounted as its "real
>>> execution time" plus the paused time of its VM. That will make the
>>> vruntime of process A much larger than it should be and process A
>>> would not be scheduled again for a long time until the vruntimes of
>>> other
>>> processes catch it.
>>> ---
>>>
>>>
>>> Analysis
>>> When a process stops running and is going to put back to the
>>> runqueue,
>>> update_curr() will be executed.
>>> [src/kernel/sched/fair.c]
>>>
>>> static void update_curr(struct cfs_rq *cfs_rq)
>>> {
>>> ... ...
>>> delta_exec = now - curr->exec_start;
>>> ... ...
>>> curr->exec_start = now;
>>> ... ...
>>> curr->sum_exec_runtime += delta_exec;
>>> schedstat_add(cfs_rq, exec_clock, delta_exec);
>>> curr->vruntime += calc_delta_fair(delta_exec, curr);
>>> update_min_vruntime(cfs_rq);
>>> ... ...
>>> }
>>>
>>> "now" --> the right now time
>>> "exec_start" --> the time when the current process is put on the CPU
>>> "delta_exec" --> the time difference of a process between it starts
>>> and stops running on the CPU
>>>
>>> When a process starts running before its VM is paused and the process
>>> stops running after its VM is unpaused, the delta_exec will include
>>> the VM suspend time which is pretty large compared to the real
>>> execution time of a process.
>>>
>> ... but would that also apply to a VM that is not scheduled --just
>> because of pCPU contention, not because it was paused-- for a few time?
>>
>
> Thanks for your suggestion. I have tried to see whether this issue
> exists on pCPU sharing today. Unfortunately, I found this issue was
> there, not only for capping case, but also for pCPU sharing case.
>
> In the above both cases, the process vruntime accounting in guest OS
> has "vruntime jump", which might cause that victim process to have
> poor and unpredictable performance.
>
> In the cloud, from my point of view, the VM exists in three scenarios:
> 1, dedicated hardware(in this case, VM = Physical Machine);
> 2, part of dedicated hardware(using capping, like Amazon EC2 T2.small 
> instance);
> 3, sharing with other VMs on the same hardware;
>
> Both case#2 and case#3 will be influenced due to the issue I mentioned.
>
>
>> Isn't there anything in place in Xen or Linux (the latter being better
>> suitable for something like this, IMHO) to compensate for that?
>>
>
> No. I do not think so. I think this is a bug in Linux kernel under
> virtualization(vmm platform is Xen).
>
>> I have to admit I haven't really ever checked myself, maybe either
>> George or our Linux people do know more?
>
> The issue behind it is that the process execution calculation(e.g.,
> delta_exec) in virtualized environment should not be calculated as it
> did in physical enviroment.
>
> Here are two solutions to fix it:
>
> 1) Based on the vcpu->runstate.time(running/runnable/block/offline)
> changes, to determine how much time the process on this VCPU is
> running, instead of just "delta_exec = now - exec_start";
>
> 2) Build another clock inside the guest OS which records the exect
> time that the VCPU runs. All vruntime calculation is based on this
> clock, instead of hyperivosr clock/time(real clock).
>
> Thanks.
>

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

[Boris Ostrovsky]

On 05/16/2016 05:38 PM, Tony S wrote:
> The issue behind it is that the process execution calculation(e.g.,
> delta_exec) in virtualized environment should not be calculated as it
> did in physical enviroment.
>
> Here are two solutions to fix it:
>
> 1) Based on the vcpu->runstate.time(running/runnable/block/offline)
> changes, to determine how much time the process on this VCPU is
> running, instead of just "delta_exec = now - exec_start";
>
> 2) Build another clock inside the guest OS which records the exect
> time that the VCPU runs. All vruntime calculation is based on this
> clock, instead of hyperivosr clock/time(real clock).

Looks like CONFIG_PARAVIRT_TIME_ACCOUNTING is used for adjusting process
times. KVM uses it but Xen doesn't.

-boris


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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On May 16, 2016 6:25 PM, "Doug Goldstein"  wrote:
>
> On 5/16/16 3:18 PM, Dagaen Golomb wrote:
> > On Mon, May 16, 2016 at 3:56 PM, Dagaen Golomb 
wrote:
> >> On Mon, May 16, 2016 at 3:52 PM, Dagaen Golomb 
wrote:
> >>> On Mon, May 16, 2016 at 3:12 PM, Doug Goldstein 
wrote:
>  On 5/16/16 11:20 AM, Dagaen Golomb wrote:
> > On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb <
dgol...@seas.upenn.edu> wrote:
> >> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb <
dgol...@seas.upenn.edu> wrote:
> >>> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein <
car...@cardoe.com> wrote:
>  On 5/15/16 8:41 PM, Dagaen Golomb wrote:
> >> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>  On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> > Hi All,
> >
> > I'm having an interesting issue. I am working on a project
that
> > requires me to share memory between dom0 and domUs. I have
this
> > successfully working using the grant table and the XenStore
to
> > communicate grefs.
> >
> > My issue is this. I have one domU running Ubuntu 12.04 with
a default
> > 3.8.x kernel that has no issue reading or writing from the
XenStore.
> > My work also requires some kernel modifications, and we
have made
> > these changes in the 4.1.0 kernel. In particular, we've
only added a
> > simple hypercall. This modified kernel is what dom0 is
running, on top
> > of Xen 4.7 rc1.
> 
>  Without reading the rest of the thread but seeing the kernel
versions.
>  Can you check how you're communicating to xenstore? Is it via
>  /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14
will give you
>  deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and
newer should
>  prefer /dev/xen/xenbus. Same thing can happen with privcmd
but making
>  that default didn't land until Xen 4.7. Since you're on the
right
>  versions I expect you're using /dev/xen/xenbus but you never
know.
> >>>
> >>> How do I know which is being used? /dev/xen/xenbus is there
and so is
> >>> process/xen/xenbus. Could this be a problem with header
version
> >>> mismatches or something similar? I'm using the xen/xenstore.h
header
> >>> file for all of my xenstore interactions. I'm running Xen 4.7
so it
> >>> should be in /dev/, and the old kernel is before 3.14 but the
new one
> >>> is after, but I would presume the standard headers are
updated to
> >>> account for this. Is there an easy way to check for this?
Also, would
> >>> the same issue cause writes to fails? Because writes from the
same
> >>> domain work fine, and appear to other domains using
xenstore-ls.
> >>>
> >>> Regards,
> >>> Dagaen Golomb
> >>>
> >>
> >> Use strace on the process and see what gets opened.
> >
> > Ah, of course. It seems both the working and non-working
domains are
> > using /proc/...
> >
> > Regards,
> > Dagaen Golomb
> >
> 
> 
>  How are you starting them? Can you confirm its attempting /dev/
first?
>  Xen 4.7 should prefer /dev/.
> >
> > For all kernels in my domU, without setting any environment
variables
> > they use /proc/.
> > For 4.1.0 this did not work, but works with /dev/ when using
> > environment variable.
> > Is this supposed to try /dev/ before /proc/? Because this doesn't
> > appear the case according to strace.
> > I think this is a bug.
> >
> > Regards,
> > Dagaen Golomb
> >
> 
>  Is your domU using Xen 4.7 compiled utilities? or are you using
distro
>  provided xenstore libraries?
> >>>
> >>> I am using the newest binaries available from the distro repo (Ubuntu
> >>> 12.04), so version 4.4.
> >>> I'm going to guess you might say this is part of the issue. 4.4 and
> >>> 4.7 aren't really *that* far off, though.
> >>> Legacy interfaces should not be breaking, so I still think this is a
> >>> bug that needs to be addressed somewhere, maybe by determining what
> >>> exactly the issue is with new kernels and /proc/ tree XenStore access,
> >>> if thisis what older tools will be using.
> >>
> >> Should I try to use newer utilities? What would be the easiest method
> >> of acquiring and installing them?
> >> Should building and installing the *-tools directives in the xen
> >> source do the trick? I'd like to see if this fixes the issue.
> >
> > I installed a package for xenstore-utils 4.6, and installed over the
> > 4.4 in my guest. Issue persists.
> >
> > Regards,
> > Dagaen Golomb
> >
>
> Changing Xen bits won't help until you use Xen 4.7. The underlying issue
> 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Doug Goldstein]

On 5/16/16 3:18 PM, Dagaen Golomb wrote:
> On Mon, May 16, 2016 at 3:56 PM, Dagaen Golomb  wrote:
>> On Mon, May 16, 2016 at 3:52 PM, Dagaen Golomb  
>> wrote:
>>> On Mon, May 16, 2016 at 3:12 PM, Doug Goldstein  wrote:
 On 5/16/16 11:20 AM, Dagaen Golomb wrote:
> On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  
> wrote:
>> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
>> wrote:
>>> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  
>>> wrote:
 On 5/15/16 8:41 PM, Dagaen Golomb wrote:
>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
 On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a 
> default
> 3.8.x kernel that has no issue reading or writing from the 
> XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only 
> added a
> simple hypercall. This modified kernel is what dom0 is running, 
> on top
> of Xen 4.7 rc1.

 Without reading the rest of the thread but seeing the kernel 
 versions.
 Can you check how you're communicating to xenstore? Is it via
 /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give 
 you
 deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer 
 should
 prefer /dev/xen/xenbus. Same thing can happen with privcmd but 
 making
 that default didn't land until Xen 4.7. Since you're on the right
 versions I expect you're using /dev/xen/xenbus but you never know.
>>>
>>> How do I know which is being used? /dev/xen/xenbus is there and so 
>>> is
>>> process/xen/xenbus. Could this be a problem with header version
>>> mismatches or something similar? I'm using the xen/xenstore.h header
>>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>>> should be in /dev/, and the old kernel is before 3.14 but the new 
>>> one
>>> is after, but I would presume the standard headers are updated to
>>> account for this. Is there an easy way to check for this? Also, 
>>> would
>>> the same issue cause writes to fails? Because writes from the same
>>> domain work fine, and appear to other domains using xenstore-ls.
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>> Use strace on the process and see what gets opened.
>
> Ah, of course. It seems both the working and non-working domains are
> using /proc/...
>
> Regards,
> Dagaen Golomb
>


 How are you starting them? Can you confirm its attempting /dev/ first?
 Xen 4.7 should prefer /dev/.
>
> For all kernels in my domU, without setting any environment variables
> they use /proc/.
> For 4.1.0 this did not work, but works with /dev/ when using
> environment variable.
> Is this supposed to try /dev/ before /proc/? Because this doesn't
> appear the case according to strace.
> I think this is a bug.
>
> Regards,
> Dagaen Golomb
>

 Is your domU using Xen 4.7 compiled utilities? or are you using distro
 provided xenstore libraries?
>>>
>>> I am using the newest binaries available from the distro repo (Ubuntu
>>> 12.04), so version 4.4.
>>> I'm going to guess you might say this is part of the issue. 4.4 and
>>> 4.7 aren't really *that* far off, though.
>>> Legacy interfaces should not be breaking, so I still think this is a
>>> bug that needs to be addressed somewhere, maybe by determining what
>>> exactly the issue is with new kernels and /proc/ tree XenStore access,
>>> if thisis what older tools will be using.
>>
>> Should I try to use newer utilities? What would be the easiest method
>> of acquiring and installing them?
>> Should building and installing the *-tools directives in the xen
>> source do the trick? I'd like to see if this fixes the issue.
> 
> I installed a package for xenstore-utils 4.6, and installed over the
> 4.4 in my guest. Issue persists.
> 
> Regards,
> Dagaen Golomb
> 

Changing Xen bits won't help until you use Xen 4.7. The underlying issue
is the Linux kernel interface is broken from 3.14 and on.

-- 
Doug Goldstein

Re: [Xen-devel] [PATCHv1 0/2] xen/xenfs: fix /proc/xen/xenbus

[Doug Goldstein]

On 5/16/16 12:44 PM, David Vrabel wrote:
> "Fix" /proc/xen/xenbus by making it a symlink to the working
> /dev/xen/xenbus.  Do the same for /proc/xen/privcmd so it matches.
> 
> If there's agreement on this approach I'll resend to Cc the fs
> maintainers.
> 
> David
> 

Looks good to me. Looks like the bits you're using were introduced in
4.2 which explains why I believed some more infra needed to be wired up.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable baseline-only test] 44420: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44420 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44420/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 test-amd64-i386-qemut-rhel6hvm-intel  3 host-install(3) broken REGR. vs. 44418
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 20 leak-check/check fail REGR. 
vs. 44418

Regressions which are regarded as allowable (not blocking):
 build-armhf-xsm   3 host-install(3)  broken like 44418
 build-armhf-pvops 3 host-install(3)  broken like 44418
 build-armhf   3 host-install(3)  broken like 44418
 build-amd64-rumpuserxen   6 xen-buildfail   like 44418
 build-i386-rumpuserxen6 xen-buildfail   like 44418
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44418
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 44418

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis44418  2016-05-15 06:19:24 Z1 days
Testing same since44420  2016-05-16 12:49:49 Z0 days1 attempts


People who touched revisions under test:
  Jim Fehlig 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvops   

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

[Tony S]

On Mon, May 16, 2016 at 5:37 AM, Dario Faggioli
 wrote:
> [Adding George again, and a few Linux/Xen folks]
>
> On Sat, 2016-05-14 at 18:25 -0600, Tony S wrote:
>> In virtualized environments, sometimes we need to limit the CPU
>> resources to a virtual machine(VM). For example in Xen, we use
>> $ xl sched-credit -d 1 -c 50
>>
>> to limit the CPU resource of dom 1 as half of
>> one physical CPU core. If the VM CPU resource is capped, the process
>> inside the VM will have a vruntime accounting problem. Here, I report
>> my findings about Linux process scheduler under the above scenario.
>>
> Thanks for this other report as well. :-)
>
> All you say makes sense to me, and I will think about it. I'm not sure
> about one thing, though...
>

Hi Dario,

Thank you for your reply.


>> Description
>> Linux CFS relies on delta_exec to charge the vruntime of processes.
>> The variable delta_exec is the difference of a process starts and
>> stops running on a CPU. This works well in physical machine. However,
>> in virtual machine under capped resources, some processes might be
>> accounted with inaccurate vruntime.
>>
>> For example, suppose we have a VM which has one vCPU and is capped to
>> have as much as 50% of a physical CPU. When process A inside the VM
>> starts running and the CPU resource of that VM runs out, the VM will
>> be paused. Next round when the VM is allocated new CPU resource and
>> starts running again, process A stops running and is put back to the
>> runqueue. The delta_exec of process A is accounted as its "real
>> execution time" plus the paused time of its VM. That will make the
>> vruntime of process A much larger than it should be and process A
>> would not be scheduled again for a long time until the vruntimes of
>> other
>> processes catch it.
>> ---
>>
>>
>> Analysis
>> When a process stops running and is going to put back to the
>> runqueue,
>> update_curr() will be executed.
>> [src/kernel/sched/fair.c]
>>
>> static void update_curr(struct cfs_rq *cfs_rq)
>> {
>> ... ...
>> delta_exec = now - curr->exec_start;
>> ... ...
>> curr->exec_start = now;
>> ... ...
>> curr->sum_exec_runtime += delta_exec;
>> schedstat_add(cfs_rq, exec_clock, delta_exec);
>> curr->vruntime += calc_delta_fair(delta_exec, curr);
>> update_min_vruntime(cfs_rq);
>> ... ...
>> }
>>
>> "now" --> the right now time
>> "exec_start" --> the time when the current process is put on the CPU
>> "delta_exec" --> the time difference of a process between it starts
>> and stops running on the CPU
>>
>> When a process starts running before its VM is paused and the process
>> stops running after its VM is unpaused, the delta_exec will include
>> the VM suspend time which is pretty large compared to the real
>> execution time of a process.
>>
> ... but would that also apply to a VM that is not scheduled --just
> because of pCPU contention, not because it was paused-- for a few time?
>

Thanks for your suggestion. I have tried to see whether this issue
exists on pCPU sharing today. Unfortunately, I found this issue was
there, not only for capping case, but also for pCPU sharing case.

In the above both cases, the process vruntime accounting in guest OS
has "vruntime jump", which might cause that victim process to have
poor and unpredictable performance.

In the cloud, from my point of view, the VM exists in three scenarios:
1, dedicated hardware(in this case, VM = Physical Machine);
2, part of dedicated hardware(using capping, like Amazon EC2 T2.small instance);
3, sharing with other VMs on the same hardware;

Both case#2 and case#3 will be influenced due to the issue I mentioned.


> Isn't there anything in place in Xen or Linux (the latter being better
> suitable for something like this, IMHO) to compensate for that?
>

No. I do not think so. I think this is a bug in Linux kernel under
virtualization(vmm platform is Xen).

> I have to admit I haven't really ever checked myself, maybe either
> George or our Linux people do know more?

The issue behind it is that the process execution calculation(e.g.,
delta_exec) in virtualized environment should not be calculated as it
did in physical enviroment.

Here are two solutions to fix it:

1) Based on the vcpu->runstate.time(running/runnable/block/offline)
changes, to determine how much time the process on this VCPU is
running, instead of just "delta_exec = now - exec_start";

2) Build another clock inside the guest OS which records the exect
time that the VCPU runs. All vruntime calculation is based on this
clock, instead of hyperivosr clock/time(real clock).

Thanks.

>
>> This issue will make a great performance harm to the victim process.
>> If the process is an I/O-bound workload, its throughput and latency
>> will be influenced. If the process is a CPU-bound workload, this
>> issue
>> will make its vruntime "unfair" compared 

[Xen-devel] [qemu-upstream-4.3-testing test] 94492: trouble: blocked/broken

[osstest service owner]

flight 94492 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94492/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  100 days
Testing same since93977  2016-05-10 11:09:16 Z6 days   16 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 3:56 PM, Dagaen Golomb  wrote:
> On Mon, May 16, 2016 at 3:52 PM, Dagaen Golomb  wrote:
>> On Mon, May 16, 2016 at 3:12 PM, Doug Goldstein  wrote:
>>> On 5/16/16 11:20 AM, Dagaen Golomb wrote:
 On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  
 wrote:
> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
> wrote:
>> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  
>> wrote:
>>> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
 Hi All,

 I'm having an interesting issue. I am working on a project that
 requires me to share memory between dom0 and domUs. I have this
 successfully working using the grant table and the XenStore to
 communicate grefs.

 My issue is this. I have one domU running Ubuntu 12.04 with a 
 default
 3.8.x kernel that has no issue reading or writing from the 
 XenStore.
 My work also requires some kernel modifications, and we have made
 these changes in the 4.1.0 kernel. In particular, we've only added 
 a
 simple hypercall. This modified kernel is what dom0 is running, on 
 top
 of Xen 4.7 rc1.
>>>
>>> Without reading the rest of the thread but seeing the kernel 
>>> versions.
>>> Can you check how you're communicating to xenstore? Is it via
>>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give 
>>> you
>>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer 
>>> should
>>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but 
>>> making
>>> that default didn't land until Xen 4.7. Since you're on the right
>>> versions I expect you're using /dev/xen/xenbus but you never know.
>>
>> How do I know which is being used? /dev/xen/xenbus is there and so is
>> process/xen/xenbus. Could this be a problem with header version
>> mismatches or something similar? I'm using the xen/xenstore.h header
>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>> should be in /dev/, and the old kernel is before 3.14 but the new one
>> is after, but I would presume the standard headers are updated to
>> account for this. Is there an easy way to check for this? Also, would
>> the same issue cause writes to fails? Because writes from the same
>> domain work fine, and appear to other domains using xenstore-ls.
>>
>> Regards,
>> Dagaen Golomb
>>
>
> Use strace on the process and see what gets opened.

 Ah, of course. It seems both the working and non-working domains are
 using /proc/...

 Regards,
 Dagaen Golomb

>>>
>>>
>>> How are you starting them? Can you confirm its attempting /dev/ first?
>>> Xen 4.7 should prefer /dev/.

 For all kernels in my domU, without setting any environment variables
 they use /proc/.
 For 4.1.0 this did not work, but works with /dev/ when using
 environment variable.
 Is this supposed to try /dev/ before /proc/? Because this doesn't
 appear the case according to strace.
 I think this is a bug.

 Regards,
 Dagaen Golomb

>>>
>>> Is your domU using Xen 4.7 compiled utilities? or are you using distro
>>> provided xenstore libraries?
>>
>> I am using the newest binaries available from the distro repo (Ubuntu
>> 12.04), so version 4.4.
>> I'm going to guess you might say this is part of the issue. 4.4 and
>> 4.7 aren't really *that* far off, though.
>> Legacy interfaces should not be breaking, so I still think this is a
>> bug that needs to be addressed somewhere, maybe by determining what
>> exactly the issue is with new kernels and /proc/ tree XenStore access,
>> if thisis what older tools will be using.
>
> Should I try to use newer utilities? What would be the easiest method
> of acquiring and installing them?
> Should building and installing the *-tools directives in the xen
> source do the trick? I'd like to see if this fixes the issue.

I installed a package for xenstore-utils 4.6, and installed over the
4.4 in my guest. Issue persists.

Regards,
Dagaen Golomb

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 3:52 PM, Dagaen Golomb  wrote:
> On Mon, May 16, 2016 at 3:12 PM, Doug Goldstein  wrote:
>> On 5/16/16 11:20 AM, Dagaen Golomb wrote:
>>> On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  
>>> wrote:
 On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
 wrote:
> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  
> wrote:
>> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
 On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
>>> Hi All,
>>>
>>> I'm having an interesting issue. I am working on a project that
>>> requires me to share memory between dom0 and domUs. I have this
>>> successfully working using the grant table and the XenStore to
>>> communicate grefs.
>>>
>>> My issue is this. I have one domU running Ubuntu 12.04 with a 
>>> default
>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>>> My work also requires some kernel modifications, and we have made
>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>>> simple hypercall. This modified kernel is what dom0 is running, on 
>>> top
>>> of Xen 4.7 rc1.
>>
>> Without reading the rest of the thread but seeing the kernel 
>> versions.
>> Can you check how you're communicating to xenstore? Is it via
>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give 
>> you
>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer 
>> should
>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>> that default didn't land until Xen 4.7. Since you're on the right
>> versions I expect you're using /dev/xen/xenbus but you never know.
>
> How do I know which is being used? /dev/xen/xenbus is there and so is
> process/xen/xenbus. Could this be a problem with header version
> mismatches or something similar? I'm using the xen/xenstore.h header
> file for all of my xenstore interactions. I'm running Xen 4.7 so it
> should be in /dev/, and the old kernel is before 3.14 but the new one
> is after, but I would presume the standard headers are updated to
> account for this. Is there an easy way to check for this? Also, would
> the same issue cause writes to fails? Because writes from the same
> domain work fine, and appear to other domains using xenstore-ls.
>
> Regards,
> Dagaen Golomb
>

 Use strace on the process and see what gets opened.
>>>
>>> Ah, of course. It seems both the working and non-working domains are
>>> using /proc/...
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>>
>> How are you starting them? Can you confirm its attempting /dev/ first?
>> Xen 4.7 should prefer /dev/.
>>>
>>> For all kernels in my domU, without setting any environment variables
>>> they use /proc/.
>>> For 4.1.0 this did not work, but works with /dev/ when using
>>> environment variable.
>>> Is this supposed to try /dev/ before /proc/? Because this doesn't
>>> appear the case according to strace.
>>> I think this is a bug.
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>> Is your domU using Xen 4.7 compiled utilities? or are you using distro
>> provided xenstore libraries?
>
> I am using the newest binaries available from the distro repo (Ubuntu
> 12.04), so version 4.4.
> I'm going to guess you might say this is part of the issue. 4.4 and
> 4.7 aren't really *that* far off, though.
> Legacy interfaces should not be breaking, so I still think this is a
> bug that needs to be addressed somewhere, maybe by determining what
> exactly the issue is with new kernels and /proc/ tree XenStore access,
> if thisis what older tools will be using.

Should I try to use newer utilities? What would be the easiest method
of acquiring and installing them?
Should building and installing the *-tools directives in the xen
source do the trick? I'd like to see if this fixes the issue.

Regards,
Dagaen Golomb

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 3:12 PM, Doug Goldstein  wrote:
> On 5/16/16 11:20 AM, Dagaen Golomb wrote:
>> On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  
>> wrote:
>>> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
>>> wrote:
 On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  wrote:
> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
>>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
>> Hi All,
>>
>> I'm having an interesting issue. I am working on a project that
>> requires me to share memory between dom0 and domUs. I have this
>> successfully working using the grant table and the XenStore to
>> communicate grefs.
>>
>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>> My work also requires some kernel modifications, and we have made
>> these changes in the 4.1.0 kernel. In particular, we've only added a
>> simple hypercall. This modified kernel is what dom0 is running, on 
>> top
>> of Xen 4.7 rc1.
>
> Without reading the rest of the thread but seeing the kernel versions.
> Can you check how you're communicating to xenstore? Is it via
> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
> that default didn't land until Xen 4.7. Since you're on the right
> versions I expect you're using /dev/xen/xenbus but you never know.

 How do I know which is being used? /dev/xen/xenbus is there and so is
 process/xen/xenbus. Could this be a problem with header version
 mismatches or something similar? I'm using the xen/xenstore.h header
 file for all of my xenstore interactions. I'm running Xen 4.7 so it
 should be in /dev/, and the old kernel is before 3.14 but the new one
 is after, but I would presume the standard headers are updated to
 account for this. Is there an easy way to check for this? Also, would
 the same issue cause writes to fails? Because writes from the same
 domain work fine, and appear to other domains using xenstore-ls.

 Regards,
 Dagaen Golomb

>>>
>>> Use strace on the process and see what gets opened.
>>
>> Ah, of course. It seems both the working and non-working domains are
>> using /proc/...
>>
>> Regards,
>> Dagaen Golomb
>>
>
>
> How are you starting them? Can you confirm its attempting /dev/ first?
> Xen 4.7 should prefer /dev/.
>>
>> For all kernels in my domU, without setting any environment variables
>> they use /proc/.
>> For 4.1.0 this did not work, but works with /dev/ when using
>> environment variable.
>> Is this supposed to try /dev/ before /proc/? Because this doesn't
>> appear the case according to strace.
>> I think this is a bug.
>>
>> Regards,
>> Dagaen Golomb
>>
>
> Is your domU using Xen 4.7 compiled utilities? or are you using distro
> provided xenstore libraries?

I am using the newest binaries available from the distro repo (Ubuntu
12.04), so version 4.4.
I'm going to guess you might say this is part of the issue. 4.4 and
4.7 aren't really *that* far off, though.
Legacy interfaces should not be breaking, so I still think this is a
bug that needs to be addressed somewhere, maybe by determining what
exactly the issue is with new kernels and /proc/ tree XenStore access,
if thisis what older tools will be using.

Regards,
Dagaen Golomb

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

Re: [Xen-devel] [HACKATHON 2016] ARM Status

[Konrad Rzeszutek Wilk]

On Thu, May 05, 2016 at 04:41:51PM +0100, Steve Capper wrote:
> [Apologies for the late send]
> 
> Xen - ARM Status
> 
> There was discussion on the following items:
> 
> *) Booting Xen on 64-bit ARM SoC
>   o) Unfortunately Xen was executed in EL1.
>   o) Advice was given that the firmware should boot the Xen in EL2.
>   o) The ARMv7 secure mode switch to Hyp trick is not valid on AArch64.
> 
> *) ARMv7 Cubietruck bringup was also discussed
>   o) One pain point mentioned was debugging the DomU guest
>   o) There are no debug capabilities for a Xen guest, but
>   o) There are a set of hyp calls that can be placed in the guest to
>  aid with debugging.
>   o) The documentation on these hyp calls needs refreshing in a wiki
>  somewhere?
>   o) Details of these can be found at: xen/arch/arm/traps.c
> 
> *) There is no list of names/ownership for HW platforms
>   o) This is due to it being non-trivial to deduce a name from wiki
>  activity.
>   o) If people care about a board, they should make themselves known.

I care about the CubieBoard5. I hadn't actually been able to do 
much on it as the default loaded firmware does not seem to be
able to read any microSD card so I am afraid to update the uboot.


> 
> Cheers,
> -- 
> Steve
> 
> ___
> 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] Question about running Xen on NVIDIA Jetson-TK1

[Meng Xu]

Hi Julien,

On Mon, May 16, 2016 at 1:33 PM, Julien Grall  wrote:
> (CC Kyle who is also working on Tegra?)
>
> Hi Meng,
>
> Many people are working on Nvidia platform with different issues :/. I have
> CCed another person which IIRC is also working on it.

Sure. It's good to know others are also interested in this platform.
It will be more useful to fix it... :-)

>
> On 16/05/16 17:33, Meng Xu wrote:
>>
>> On Mon, May 16, 2016 at 7:33 AM, Julien Grall 
>> wrote:
>>>
>>>
>>> On 15/05/16 20:35, Meng Xu wrote:


 I'm trying to run Xen on NVIDIA Jetson TK1 board. (Right now, Xen does
 not support the Jetson board officially. But I'm thinking it may be
 very interesting and useful to see it happens, since it has GPU inside
 which is quite popular in automotive.)

 Now I encountered some problem to boot dom0 in Xen environment. I want
 to debug the issues and maybe fix the issues, but I'm not so sure how
 I should debug the issue more efficiently. I really appreciate it if
 you advise me a little bit about the method of how to fix the issue.
 :-)

 ---Below is the details

 I noticed the Dushyant from IBM also tried to run Xen on the Jetson
 board. (http://www.gossamer-threads.com/lists/xen/devel/422519). I
 used the same Linux kernel (Jan Kiszka's development tree -
 http://git.kiszka.org/linux.git/, branch queues/assorted) and Ian's
 Xen repo. with the hack for Jetson board. I can see the dom0 kernel
 can boot to some extend and then "stall/spin" before the dom0 kernel
 fully boot up.

 In order to figure out the possible issue, I boot the exact same Linux
 kernel in native environment on one CPU and collected the boot log
 information in [1]. I also boot the same Linux kernel as dom0 in Xen
 environment and collected the boot log information in [2].

 In Xen environment, dom0 hangs after the following message
 [   10.541010] NET: Registered protocol family 10
 6mip6: Mobile IPv6
 [   10.542510] mi

 In native environment, the kernel has the following log after
 initializing NET.
 [2.934693] NET: Registered protocol family 10
 [2.940611] mip6: Mobile IPv6
 [2.943645] sit: IPv6 over IPv4 tunneling driver
 [2.951303] NET: Registered protocol family 17
 [2.955800] NET: Registered protocol family 15
 [2.960257] can: controller area network core (rev 20120528 abi 9)
 [2.966617] NET: Registered protocol family 29
 [2.971098] can: raw protocol (rev 20120528)
 [2.975384] can: broadcast manager protocol (rev 20120528 t)
 [2.981088] can: netlink gateway (rev 20130117) max_hops=1
 [2.986734] Bluetooth: RFCOMM socket layer initialized
 [2.991979] Bluetooth: RFCOMM ver 1.11
 [2.995757] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
 [3.001109] Bluetooth: BNEP socket layer initialized
 [3.006089] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
 [3.012052] Bluetooth: HIDP socket layer initialized
 [3.017894] Registering SWP/SWPB emulation handler
 [3.029675] tegra-pcie 1003000.pcie-controller: 2x1, 1x1
 configuration
 [3.036586] +3.3V_SYS: supplied by +VDD_MUX
 [3.040857] +3.3V_LP0: supplied by +3.3V_SYS
 [3.045509] +1.35V_LP0(sd2): supplied by +5V_SYS
 [3.050201] +1.05V_RUN_AVDD: supplied by +1.35V_LP0(sd2)
 [3.057131] tegra-pcie 1003000.pcie-controller: probing port 0, using
 2 lanes
 [3.066479] tegra-pcie 1003000.pcie-controller: Slot present pin
 change, signature: 0008

 I'm suspecting that my dom0 kernel hangs when it tries to initialize
 "can: controller area network core ". However, from Dushyant's post at
 http://www.gossamer-threads.com/lists/xen/devel/422519,  it seems
 Dushyant's dom0 kernel hangs when it tries to initialize pci_bus. (The
 linux config I used may be different form Dushyant's. That could be
 the reason.)

 Right now, the system just hangs and has no output indicating what the
 problem could be. Although there are a lot of error message before the
 system hangs, I'm not that sure if I should start with solving all of
 those error messages. Maybe some errors can be ignored?

 My questions are:
 1) Do you have suggestion on how to see more information about the
 reason why the dom0 hangs?
>>>
>>>
>>>
>>> Have you tried to dump the registers using Xen console (CTLR-x 3 times
>>> then 0) and see where it get stucks?
>>
>>
>>
>> I tried to type CTLR -x 3 times and then 0, nothing happens... :-(
>> Just to confirm, once the system got stuck, I directly type Ctrl-x for
>> three times on the host's screen. Am I correct?
>
>
> Sorry, I forgot the default way to switch console is CTLR-a three times.
>
> On my configuration I modified the default 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Doug Goldstein]

On 5/16/16 11:20 AM, Dagaen Golomb wrote:
> On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  
> wrote:
>> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
>> wrote:
>>> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  wrote:
 On 5/15/16 8:41 PM, Dagaen Golomb wrote:
>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
 On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.

 Without reading the rest of the thread but seeing the kernel versions.
 Can you check how you're communicating to xenstore? Is it via
 /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
 deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
 prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
 that default didn't land until Xen 4.7. Since you're on the right
 versions I expect you're using /dev/xen/xenbus but you never know.
>>>
>>> How do I know which is being used? /dev/xen/xenbus is there and so is
>>> process/xen/xenbus. Could this be a problem with header version
>>> mismatches or something similar? I'm using the xen/xenstore.h header
>>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>>> should be in /dev/, and the old kernel is before 3.14 but the new one
>>> is after, but I would presume the standard headers are updated to
>>> account for this. Is there an easy way to check for this? Also, would
>>> the same issue cause writes to fails? Because writes from the same
>>> domain work fine, and appear to other domains using xenstore-ls.
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>> Use strace on the process and see what gets opened.
>
> Ah, of course. It seems both the working and non-working domains are
> using /proc/...
>
> Regards,
> Dagaen Golomb
>


 How are you starting them? Can you confirm its attempting /dev/ first?
 Xen 4.7 should prefer /dev/.
> 
> For all kernels in my domU, without setting any environment variables
> they use /proc/.
> For 4.1.0 this did not work, but works with /dev/ when using
> environment variable.
> Is this supposed to try /dev/ before /proc/? Because this doesn't
> appear the case according to strace.
> I think this is a bug.
> 
> Regards,
> Dagaen Golomb
> 

Is your domU using Xen 4.7 compiled utilities? or are you using distro
provided xenstore libraries?

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCHv1 0/2] xen/xenfs: fix /proc/xen/xenbus

[Boris Ostrovsky]

On 05/16/2016 01:44 PM, David Vrabel wrote:
> "Fix" /proc/xen/xenbus by making it a symlink to the working
> /dev/xen/xenbus.  Do the same for /proc/xen/privcmd so it matches.
>
> If there's agreement on this approach I'll resend to Cc the fs
> maintainers.

Looks good to me.

-boris


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

[Xen-devel] [ovmf test] 94490: regressions - FAIL

[osstest service owner]

flight 94490 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94490/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 7b1fe7acdca15be49a9421156b799ed7394f7bac
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  160 days
Failing since 65593  2015-12-08 23:44:51 Z  159 days  269 attempts
Testing same since94482  2016-05-16 12:45:20 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hegde, Nagaraj P nagaraj-p.he...@hpe.com
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  

Re: [Xen-devel] [BUG] Bugs existing Xen's credit scheduler cause long tail latency issues

[Tony S]

On Mon, May 16, 2016 at 5:30 AM, Dario Faggioli
 wrote:
> [Adding George, and avoiding trimming, for his benefit]
>
> On Sat, 2016-05-14 at 22:11 -0600, Tony S wrote:
>> Hi all,
>>
> Hi Tony,
>
>> When I was running latency-sensitive applications in VMs on Xen, I
>> found some bugs in the credit scheduler which will cause long tail
>> latency in I/O-intensive VMs.
>>
> Ok, first of all, thanks for looking into and reporting this.
>
> This is certainly something we need to think about... For now, just a
> couple of questions.

Hi Dario,

Thank you for your reply. :-)

>
>> (1) Problem description
>>
>> Description
>> My test environment is as follows: Hypervisor(Xen 4.5.0), Dom 0(Linux
>> 3.18.21), Dom U(Linux 3.18.21).
>>
>> Environment setup:
>> We created two 1-vCPU, 4GB-memory VMs and pinned them onto one
>> physical CPU core. One VM(denoted as I/O-VM) ran Sockperf server
>> program; the other VM ran a compute-bound task, e.g., SPECCPU 2006 or
>> simply a loop(denoted as CPU-VM). A client on another physical
>> machine
>> sent UDP requests to the I/O-VM.
>>
> So, just to be sure I've understood, you have 2 VMs, each with 1 vCPU,
> *both* pinned on the *same* pCPU, is this the case?
>

Yes.

>> Here are my tail latency results (micro-second):
>> Case   Avg  90%   99%99.9%  99.99%
>> #1 108   &  114&  128 &  129 &  130
>> #2 7811  &  13892  &  14874   &  15315   &  16383
>> #3 943   &  131&  21755   &  26453   &  26553
>> #4 116   &  96 &  105 &  8217&  13472
>> #5 116   &  117&  129 &  131 &  132
>>
>> Bug 1, 2, and 3 will be discussed below.
>>
>> Case #1:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> idling (no processes running).
>>
>> Case #2:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0
>>
>> Case #3:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 fixed
>>
>> Case #4:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 fixed
>>
>> Case #5:
>> I/O-VM was processing Sockperf requests from clients; CPU-VM was
>> running a compute-bound task.
>> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 & 3 fixed
>>
>> ---
>>
>>
>> (2) Problem analysis
>>
>> Analysis
>>
>> [Bug1]: The VCPU that ran CPU-intensive workload could be mistakenly
>> boosted due to CPU affinity.
>>
>> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02853.
>> html
>>
>> We have already discussed this bug and a potential patch in the above
>> link. Although the discussed patch improved the tail latency, i.e.,
>> reducing the 90th percentile latency, the long tail latency is till
>> not bounded. Next, we discussed two new bugs that inflict latency
>> hike
>> at the very far end of the tail.
>>
> Right, and there is a fix upstream for this. It's not the patch you
> proposed in the thread linked above, but it should have had the same
> effect.
>
> Can you perhaps try something more recent thatn 4.5 (4.7-rc would be
> great) and confirm that the number still look similar?

I have tried the latest stable version Xen 4.6 today. Here is my results:

Case   Avg  90%   99%99.9%  99.99%
#1 91 &  93 &  101   &  105   &  110
#2 22506 & 43011  &  231946  &  259501   &  265561
#3 917   &  95&  25257   &  30048   &  30756
#4 110   &  95 &  102 &  12448&  13255
#5 114   &  118   &  130 &  134 &  136

It seems that case#2 is much worse. The other cases are similar. My
raw latency data is pasted below.

For xen 4.7-rc, I have some installment issues on my machine,
therefore I have not tried that.


Raw data is as follows. Hope this could help you understand the issues
better. :-)
# case 1:
sockperf: > avg-lat= 91.688 (std-dev=2.950)
sockperf: --->  observation =  110.647
sockperf: ---> percentile  99.99 =  110.647
sockperf: ---> percentile  99.90 =  105.242
sockperf: ---> percentile  99.50 =  101.531
sockperf: ---> percentile  99.00 =  101.066
sockperf: ---> percentile  95.00 =   97.016
sockperf: ---> percentile  90.00 =   93.294
sockperf: ---> percentile  75.00 =   92.157
sockperf: ---> percentile  50.00 =   91.437
sockperf: ---> percentile  25.00 =   90.786
sockperf: --->  observation =   73.071


# case 2:
sockperf: > avg-lat=90019.931 (std-dev=136620.722)
sockperf: --->  observation = 637712.152
sockperf: ---> percentile  99.99 = 637712.152
sockperf: ---> percentile  99.90 = 632901.547
sockperf: ---> percentile  99.50 = 615972.778
sockperf: ---> percentile  99.00 = 599698.318
sockperf: ---> percentile  95.00 = 428857.020
sockperf: ---> 

[Xen-devel] [PATCHv1 2/2] xen/xenfs: replace xenbus and privcmd with symlinks

[David Vrabel]

/proc/xen/xenbus does not work correctly.  A read blocked waiting for
a xenbus message will deadlock a write to the same file handle due to
the requirement for atomic file position updates on regular files.

/proc/xen/xenbus and /proc/xen/privcmd are supposed to be identical to
the character devices /dev/xen/xenbus and /dev/xen/privcmd so replace
the files with symlinks.

Signed-off-by: David Vrabel 
---
 drivers/xen/xenfs/super.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/xenfs/super.c b/drivers/xen/xenfs/super.c
index 8559a71..09c239e 100644
--- a/drivers/xen/xenfs/super.c
+++ b/drivers/xen/xenfs/super.c
@@ -45,16 +45,16 @@ static const struct file_operations capabilities_file_ops = 
{
 static int xenfs_fill_super(struct super_block *sb, void *data, int silent)
 {
static struct tree_descr xenfs_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{""},
};
 
static struct tree_descr xenfs_init_files[] = {
-   [2] = { "xenbus", _xenbus_fops, S_IRUSR|S_IWUSR },
+   [2] = { "xenbus", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/xenbus" 
},
{ "capabilities", _file_ops, S_IRUGO },
-   { "privcmd", _privcmd_fops, S_IRUSR|S_IWUSR },
+   { "privcmd", NULL, S_IFLNK | S_IRWXUGO, "/dev/xen/privcmd" },
{ "xsd_kva", _kva_file_ops, S_IRUSR|S_IWUSR},
{ "xsd_port", _port_file_ops, S_IRUSR|S_IWUSR},
 #ifdef CONFIG_XEN_SYMS
-- 
2.1.4


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

[Xen-devel] [xen-unstable-smoke test] 94489: tolerable all pass - PUSHED

[osstest service owner]

flight 94489 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94489/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  2c86f0e1ac35b4c9e9502d969693f3264d3eda1e
baseline version:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83

Last test of basis94483  2016-05-16 13:01:21 Z0 days
Testing same since94489  2016-05-16 16:00:59 Z0 days1 attempts


People who touched revisions under test:
  Peng Fan 
  Stefano Stabellini 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=2c86f0e1ac35b4c9e9502d969693f3264d3eda1e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
2c86f0e1ac35b4c9e9502d969693f3264d3eda1e
+ branch=xen-unstable-smoke
+ revision=2c86f0e1ac35b4c9e9502d969693f3264d3eda1e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x2c86f0e1ac35b4c9e9502d969693f3264d3eda1e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

[Xen-devel] [PATCHv1 1/2] libfs: allow simple_fill_super() to add symlinks

[David Vrabel]

simple_fill_super() will add symlinks if an entry has mode & S_IFLNK.
The target is provided in the new "link" field.

Signed-off-by: David Vrabel 
---
 fs/libfs.c | 23 ---
 include/linux/fs.h |  2 +-
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/fs/libfs.c b/fs/libfs.c
index f3fa82c..894e182 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -500,6 +500,8 @@ int simple_fill_super(struct super_block *s, unsigned long 
magic,
if (!root)
return -ENOMEM;
for (i = 0; !files->name || files->name[0]; i++, files++) {
+   char *link = NULL;
+
if (!files->name)
continue;
 
@@ -509,17 +511,32 @@ int simple_fill_super(struct super_block *s, unsigned 
long magic,
"with an index of 1!\n", __func__,
s->s_type->name);
 
+   if (files->mode & S_IFLNK) {
+   link = kstrdup(files->link, GFP_KERNEL);
+   if (!link)
+   goto out;
+   }
+
dentry = d_alloc_name(root, files->name);
-   if (!dentry)
+   if (!dentry) {
+   kfree(link);
goto out;
+   }
inode = new_inode(s);
if (!inode) {
dput(dentry);
+   kfree(link);
goto out;
}
-   inode->i_mode = S_IFREG | files->mode;
+   inode->i_mode = files->mode;
+   if (files->mode & S_IFLNK) {
+   inode->i_op = _symlink_inode_operations;
+   inode->i_link = link;
+   } else {
+   inode->i_fop = files->ops;
+   inode->i_mode |= S_IFREG;
+   }
inode->i_atime = inode->i_mtime = inode->i_ctime = CURRENT_TIME;
-   inode->i_fop = files->ops;
inode->i_ino = i;
d_add(dentry, inode);
}
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 70e61b5..8a09998 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2897,7 +2897,7 @@ extern const struct file_operations simple_dir_operations;
 extern const struct inode_operations simple_dir_inode_operations;
 extern void make_empty_dir_inode(struct inode *inode);
 extern bool is_empty_dir_inode(struct inode *inode);
-struct tree_descr { char *name; const struct file_operations *ops; int mode; };
+struct tree_descr { char *name; const struct file_operations *ops; int mode; 
char *link; };
 struct dentry *d_alloc_name(struct dentry *, const char *);
 extern int simple_fill_super(struct super_block *, unsigned long, struct 
tree_descr *);
 extern int simple_pin_fs(struct file_system_type *, struct vfsmount **mount, 
int *count);
-- 
2.1.4


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

[Xen-devel] [PATCHv1 0/2] xen/xenfs: fix /proc/xen/xenbus

[David Vrabel]

"Fix" /proc/xen/xenbus by making it a symlink to the working
/dev/xen/xenbus.  Do the same for /proc/xen/privcmd so it matches.

If there's agreement on this approach I'll resend to Cc the fs
maintainers.

David


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

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Julien Grall]

(CC Kyle who is also working on Tegra?)

Hi Meng,

Many people are working on Nvidia platform with different issues :/. I 
have CCed another person which IIRC is also working on it.


On 16/05/16 17:33, Meng Xu wrote:

On Mon, May 16, 2016 at 7:33 AM, Julien Grall  wrote:


On 15/05/16 20:35, Meng Xu wrote:


I'm trying to run Xen on NVIDIA Jetson TK1 board. (Right now, Xen does
not support the Jetson board officially. But I'm thinking it may be
very interesting and useful to see it happens, since it has GPU inside
which is quite popular in automotive.)

Now I encountered some problem to boot dom0 in Xen environment. I want
to debug the issues and maybe fix the issues, but I'm not so sure how
I should debug the issue more efficiently. I really appreciate it if
you advise me a little bit about the method of how to fix the issue.
:-)

---Below is the details

I noticed the Dushyant from IBM also tried to run Xen on the Jetson
board. (http://www.gossamer-threads.com/lists/xen/devel/422519). I
used the same Linux kernel (Jan Kiszka's development tree -
http://git.kiszka.org/linux.git/, branch queues/assorted) and Ian's
Xen repo. with the hack for Jetson board. I can see the dom0 kernel
can boot to some extend and then "stall/spin" before the dom0 kernel
fully boot up.

In order to figure out the possible issue, I boot the exact same Linux
kernel in native environment on one CPU and collected the boot log
information in [1]. I also boot the same Linux kernel as dom0 in Xen
environment and collected the boot log information in [2].

In Xen environment, dom0 hangs after the following message
[   10.541010] NET: Registered protocol family 10
6mip6: Mobile IPv6
[   10.542510] mi

In native environment, the kernel has the following log after initializing NET.
[2.934693] NET: Registered protocol family 10
[2.940611] mip6: Mobile IPv6
[2.943645] sit: IPv6 over IPv4 tunneling driver
[2.951303] NET: Registered protocol family 17
[2.955800] NET: Registered protocol family 15
[2.960257] can: controller area network core (rev 20120528 abi 9)
[2.966617] NET: Registered protocol family 29
[2.971098] can: raw protocol (rev 20120528)
[2.975384] can: broadcast manager protocol (rev 20120528 t)
[2.981088] can: netlink gateway (rev 20130117) max_hops=1
[2.986734] Bluetooth: RFCOMM socket layer initialized
[2.991979] Bluetooth: RFCOMM ver 1.11
[2.995757] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[3.001109] Bluetooth: BNEP socket layer initialized
[3.006089] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[3.012052] Bluetooth: HIDP socket layer initialized
[3.017894] Registering SWP/SWPB emulation handler
[3.029675] tegra-pcie 1003000.pcie-controller: 2x1, 1x1 configuration
[3.036586] +3.3V_SYS: supplied by +VDD_MUX
[3.040857] +3.3V_LP0: supplied by +3.3V_SYS
[3.045509] +1.35V_LP0(sd2): supplied by +5V_SYS
[3.050201] +1.05V_RUN_AVDD: supplied by +1.35V_LP0(sd2)
[3.057131] tegra-pcie 1003000.pcie-controller: probing port 0, using 2 lanes
[3.066479] tegra-pcie 1003000.pcie-controller: Slot present pin
change, signature: 0008

I'm suspecting that my dom0 kernel hangs when it tries to initialize
"can: controller area network core ". However, from Dushyant's post at
http://www.gossamer-threads.com/lists/xen/devel/422519,  it seems
Dushyant's dom0 kernel hangs when it tries to initialize pci_bus. (The
linux config I used may be different form Dushyant's. That could be
the reason.)

Right now, the system just hangs and has no output indicating what the
problem could be. Although there are a lot of error message before the
system hangs, I'm not that sure if I should start with solving all of
those error messages. Maybe some errors can be ignored?

My questions are:
1) Do you have suggestion on how to see more information about the
reason why the dom0 hangs?



Have you tried to dump the registers using Xen console (CTLR-x 3 times then 0) 
and see where it get stucks?



I tried to type CTLR -x 3 times and then 0, nothing happens... :-(
Just to confirm, once the system got stuck, I directly type Ctrl-x for
three times on the host's screen. Am I correct?


Sorry, I forgot the default way to switch console is CTLR-a three times.

On my configuration I modified the default character to avoid issue with 
screen.




Maybe the serial console is not correctly set up?


It's likely to be a problem with the serial drivers in driver. Can you 
tried CTLR-a before the kernel is booting?



The serial console configuration I used is as follows, could you have
a quick look to see if it's because I configure the serial
incorrectly?


I am not familiar with the Nvidia board. If the serial configuration is 
working for baremetal, then it should work for Xen.




I used screen program to attach to the serial port.
The command I used is $screen /dev/ttyUSB0 115200n8 on the host machine.

On the board, I set up the device 

Re: [Xen-devel] [PATCH net-next v4 0/4] xen-netback: support for control ring

[David Miller]

From: Paul Durrant 
Date: Fri, 13 May 2016 09:37:25 +0100

> My recent patch to import an up-to-date include/xen/interface/io/netif.h
> from the Xen Project brought in the necessary definitions to support the
> new control shared ring and protocol. This patch series updates xen-netback
> to support the new ring.
> 
> Patch #1 adds the necessary boilerplate to map the control ring and handle
> messages. No implementation of the new protocol is included in this patch
> so that it can be kept to a reasonable size.
> 
> Patch #2 adds the protocol implementation.
> 
> Patch #3 adds support for passing has values calculated by xen-netback to
> capable frontends.
> 
> Patch #4 adds support for accepting hash values calculated by capable
> frontends and using them the set the socket buffer hash.

Series applied, thanks.

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94480: trouble: blocked/broken

[osstest service owner]

flight 94480 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94480/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z  100 days
Testing same since93977  2016-05-10 11:09:16 Z6 days   15 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Julien Grall]

On 16/05/16 18:26, Konrad Rzeszutek Wilk wrote:


Have you tried to dump the registers using Xen console (CTLR-x 3 times then 0) 
and see where it get stucks?



I tried to type CTLR -x 3 times and then 0, nothing happens... :-(
Just to confirm, once the system got stuck, I directly type Ctrl-x for
three times on the host's screen. Am I correct?


I think it is 'Ctrl-A', and since you are using screen you need to
'pass'through the Ctrl-A by doing 'ctrl-a-A' or something like that
three or six times.


Hmmm yes, I forgot that I modified the switching character on my 
configuration. Sorry for the noise.


Meng, you can pass conswitch=x to Xen command line to havet he 
'pass'through problem.


Regards,

--
Julien Grall

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

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Konrad Rzeszutek Wilk]

> >
> > Have you tried to dump the registers using Xen console (CTLR-x 3 times then 
> > 0) and see where it get stucks?
> 
> 
> I tried to type CTLR -x 3 times and then 0, nothing happens... :-(
> Just to confirm, once the system got stuck, I directly type Ctrl-x for
> three times on the host's screen. Am I correct?

I think it is 'Ctrl-A', and since you are using screen you need to
'pass'through the Ctrl-A by doing 'ctrl-a-A' or something like that
three or six times.


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

Re: [Xen-devel] [PATCH v3 4/9] arm/vm_event: get/set registers

[Julien Grall]

On 16/05/16 17:26, Tamas K Lengyel wrote:


On May 16, 2016 09:59, "Julien Grall" > wrote:
 >>  > By defining 2 distinct structures, it will be more difficult for the
 >> introspection tools to inspect registers of an Aarch64 domain running in
 >> AArch32 mode. They wouldn't be able to re-use code for AArch32 domain
 >> because the structure fields are different.
 >>  >
 >>  > The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping
 >> between AArch32 state and AArch64 state. If you use it to define the
 >> layout of a common structure, the support of AArch32 state for AArch64
 >> domain will come free.
 >>  >
 >>
 >> If the guest is running in 32-bit mode Xen will fill the 32-bit struct,
 >> so doing a common struct is not strictly necessary. It also requires a
 >> bunch if union declarations to match the names between that I would
 >> prefer to avoid. IMHO it's cleaner to do the struct definitions
 >> separately and then do a union on top.
 >
 >
 > That is not true. is_domain_32bit will check if the domain is
configured to run 32-bit or 64-bit in EL1 (i.e the kernel level).
 >
 > So if you have a guest with 64-bit kernel and 32-bit userspace, Xen
will always fill the 64-bit structure, even when the userspace is running.
 >

Hm fair point. It complicates things a bit though either way as the
event subscriber wouldn't know which mode it received the event from
without doing some extra checks. So I guess Xen should transmit that
information too, at which point it could also just pick the right struct
to fill with the current setup.


Not really, CPSR.M[4] tells you if the execution state were AArch32 or 
AArch64. vm_event_regs_* contains the cpsr fields, so the event

subscriber can determine the mode.

Actually, not all the registers in vm_event_regs_arm32 makes sense when 
the guest is a 64-bit domain. For instance, spsr_svc is for the EL1 (i.e 
kernel).


Hence the suggestion to use a structure very similar to 
vcpu_guest_core_regs.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH] x86/cpuid: Avoid unconditionally clobbering ITSC for guests

[Andrew Cooper]

In general, Invariant TSC is not a feature which can be advertised to guests,
because it cannot be guaranteed across migrate.  domain_cpuid() goes so far as
to deliberately clobber the feature flag under a number of circumstances.

Because ITSC is absent from the static {pv,hvm}_featureset masks, c/s b648feff
"xen/x86: Improvements to in-hypervisor cpuid sanity checks" caused ITSC to be
unconditionally masked out.

As an interim solution, include the hosts idea of ITSC along with the static
{pv,hvm}_featureset when restricting the guests view of features.  This causes
the hardware domain, and VMs explicitly configured with ITSC and no-migrate to
be offered ITSC (subject to hardware availability).

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/hvm/hvm.c | 3 ++-
 xen/arch/x86/traps.c   | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 7492030..5040a5c 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3509,7 +3509,8 @@ void hvm_cpuid(unsigned int input, unsigned int *eax, 
unsigned int *ebx,
 break;
 
 case 0x8007:
-*edx &= hvm_featureset[FEATURESET_e7d];
+*edx &= (hvm_featureset[FEATURESET_e7d] |
+ (host_featureset[FEATURESET_e7d] & 
cpufeat_mask(X86_FEATURE_ITSC)));
 break;
 
 case 0x8008:
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 0052ab8..1ef8401 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1142,7 +1142,8 @@ void pv_cpuid(struct cpu_user_regs *regs)
 break;
 
 case 0x8007:
-d &= pv_featureset[FEATURESET_e7d];
+d &= (pv_featureset[FEATURESET_e7d] |
+  (host_featureset[FEATURESET_e7d] & 
cpufeat_mask(X86_FEATURE_ITSC)));
 break;
 
 case 0x8008:
-- 
2.1.4


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

[Xen-devel] [xen-4.6-testing test] 94474: regressions - FAIL

[osstest service owner]

flight 94474 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94474/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93932
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93932
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93932

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  426783e661da942f8b7871613479db4daa6a16c3
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z6 days
Failing since 94000  2016-05-10 18:10:33 Z5 days9 attempts
Testing same since94036  2016-05-11 15:51:26 Z5 days8 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Meng Xu]

On Mon, May 16, 2016 at 7:33 AM, Julien Grall  wrote:
>
> On 15/05/16 20:35, Meng Xu wrote:
>>
>> Hi Julien and Ian,
>
>
> Hello Meng,


Hi Julien,


>
>>
>> I'm trying to run Xen on NVIDIA Jetson TK1 board. (Right now, Xen does
>> not support the Jetson board officially. But I'm thinking it may be
>> very interesting and useful to see it happens, since it has GPU inside
>> which is quite popular in automotive.)
>>
>> Now I encountered some problem to boot dom0 in Xen environment. I want
>> to debug the issues and maybe fix the issues, but I'm not so sure how
>> I should debug the issue more efficiently. I really appreciate it if
>> you advise me a little bit about the method of how to fix the issue.
>> :-)
>>
>> ---Below is the details
>>
>> I noticed the Dushyant from IBM also tried to run Xen on the Jetson
>> board. (http://www.gossamer-threads.com/lists/xen/devel/422519). I
>> used the same Linux kernel (Jan Kiszka's development tree -
>> http://git.kiszka.org/linux.git/, branch queues/assorted) and Ian's
>> Xen repo. with the hack for Jetson board. I can see the dom0 kernel
>> can boot to some extend and then "stall/spin" before the dom0 kernel
>> fully boot up.
>>
>> In order to figure out the possible issue, I boot the exact same Linux
>> kernel in native environment on one CPU and collected the boot log
>> information in [1]. I also boot the same Linux kernel as dom0 in Xen
>> environment and collected the boot log information in [2].
>>
>> In Xen environment, dom0 hangs after the following message
>> [   10.541010] NET: Registered protocol family 10
>> 6mip6: Mobile IPv6
>> [   10.542510] mi
>>
>> In native environment, the kernel has the following log after initializing 
>> NET.
>> [2.934693] NET: Registered protocol family 10
>> [2.940611] mip6: Mobile IPv6
>> [2.943645] sit: IPv6 over IPv4 tunneling driver
>> [2.951303] NET: Registered protocol family 17
>> [2.955800] NET: Registered protocol family 15
>> [2.960257] can: controller area network core (rev 20120528 abi 9)
>> [2.966617] NET: Registered protocol family 29
>> [2.971098] can: raw protocol (rev 20120528)
>> [2.975384] can: broadcast manager protocol (rev 20120528 t)
>> [2.981088] can: netlink gateway (rev 20130117) max_hops=1
>> [2.986734] Bluetooth: RFCOMM socket layer initialized
>> [2.991979] Bluetooth: RFCOMM ver 1.11
>> [2.995757] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> [3.001109] Bluetooth: BNEP socket layer initialized
>> [3.006089] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
>> [3.012052] Bluetooth: HIDP socket layer initialized
>> [3.017894] Registering SWP/SWPB emulation handler
>> [3.029675] tegra-pcie 1003000.pcie-controller: 2x1, 1x1 configuration
>> [3.036586] +3.3V_SYS: supplied by +VDD_MUX
>> [3.040857] +3.3V_LP0: supplied by +3.3V_SYS
>> [3.045509] +1.35V_LP0(sd2): supplied by +5V_SYS
>> [3.050201] +1.05V_RUN_AVDD: supplied by +1.35V_LP0(sd2)
>> [3.057131] tegra-pcie 1003000.pcie-controller: probing port 0, using 2 
>> lanes
>> [3.066479] tegra-pcie 1003000.pcie-controller: Slot present pin
>> change, signature: 0008
>>
>> I'm suspecting that my dom0 kernel hangs when it tries to initialize
>> "can: controller area network core ". However, from Dushyant's post at
>> http://www.gossamer-threads.com/lists/xen/devel/422519,  it seems
>> Dushyant's dom0 kernel hangs when it tries to initialize pci_bus. (The
>> linux config I used may be different form Dushyant's. That could be
>> the reason.)
>>
>> Right now, the system just hangs and has no output indicating what the
>> problem could be. Although there are a lot of error message before the
>> system hangs, I'm not that sure if I should start with solving all of
>> those error messages. Maybe some errors can be ignored?
>>
>> My questions are:
>> 1) Do you have suggestion on how to see more information about the
>> reason why the dom0 hangs?
>
>
> Have you tried to dump the registers using Xen console (CTLR-x 3 times then 
> 0) and see where it get stucks?


I tried to type CTLR -x 3 times and then 0, nothing happens... :-(
Just to confirm, once the system got stuck, I directly type Ctrl-x for
three times on the host's screen. Am I correct?

Maybe the serial console is not correctly set up?
The serial console configuration I used is as follows, could you have
a quick look to see if it's because I configure the serial
incorrectly?

I used screen program to attach to the serial port.
The command I used is $screen /dev/ttyUSB0 115200n8 on the host machine.

On the board, I set up the device tree's /chosen node as follows:
#
fdt print /chosen

chosen {

xen,xen-bootargs = "console=dtuart dtuart=serial0
dom0_mem=512M loglvl=all guest_loglvl=all dom0_max_vcpus=1
dom0_vcpus_pin maxcpus=1";

bootargs = "console=dtuart dtuart=serial0 dom0_mem=512M
loglvl=all guest_loglvl=all dom0_max_vcpus=1 dom0_vcpus_pin
maxcpus=1";

  

Re: [Xen-devel] [PATCH v2 0/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Julien Grall]

Hi Wei,

On 16/05/16 16:47, Wei Liu wrote:

On Mon, May 16, 2016 at 05:03:54PM +0200, Edgar E. Iglesias wrote:

From: "Edgar E. Iglesias" 

I'm sending this as a v2 considering that I previously posted a diff
in email discussions.

This patch fixes an DT problem with the ZynqMP PCIe node.
Today, we try to remap IRQs regardless of if they are directly
connected to the primary controller or not. If they are indirectly
connected via secondary IRQ controllers, we abort the boot with
an error.

The ZynqMP PCIe DTS bindings were upstreamed to Linux after Xen 4.6, so
this issue is not a regression.
PCIe is also not generally a critical feature of current ZynqMP boards,
i.e the boards are functional without PCIe although for some users PCIe
may be more or less critical.

As I see it we have two options:

1. A safe option is to disable the PCIe node in the ZynqMP platform.
We can then fix this with calm for 4.8.
+ It will fix the dom0 boot.
+ Very safe and unintrusive.
- PCIe will not be functional.

2. Apply this patch to 4.7
+ It will fix the dom0 boot.
+ PCIe will be functional.
- Intrusive fix. Although the fix really only affects a case that
  otherwise would have resulted in an aborted boot of dom0.

I'm happy to submit a patch for option nr 1 if you guys feel that's
safer/better at this point.



I'm a bit wary that this patch touches common code because the issue you
describe seems to be board specific.


Quite a few platforms (e.g Exynos, Tegra, ZynqMP) provide multiple 
interrupt controllers in cascade, with a GIC has the main controller.
We solved the issue for device in handle_device, but not when mapping 
interrupts associated to a bus.


Even if this code touches common code, there is only one caller 
(map_device_children) and the call will only be done for PCI bus. So the 
patch is not as scary as it looks like :).


It's also unclear why this would

make PCIe function on ZynqMP from the commit message.

I admit I don't know much about ARM so I will leave the further review
and judgement to ARM maintainers. I don't think OSSTest will pick up bug
in this patch FWIW.


Correct, there are no ARM platforms with PCI in OSSTest.
Nonetheless, this patch is not too risky as the usage of the function is 
very limited.


IIRC, we currently support 4 platforms with PCI: X-Gene, 
Seattle/Overdrive, Juno, and ZynqMP.


I gave a try on Juno r2 and I have not noticed any regression. I can 
give a try on X-Gene and Seattle if necessary.


For me the change is good to go in Xen 4.7. Stefano do you have any opinion?

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 4/9] arm/vm_event: get/set registers

[Tamas K Lengyel]

On May 16, 2016 09:59, "Julien Grall"  wrote:
>
> Hi Tamas,
>
>
> On 16/05/16 16:37, Tamas K Lengyel wrote:
>>
>>
>> On May 16, 2016 04:14, "Julien Grall" > > wrote:
>>  > On 04/05/16 15:51, Tamas K Lengyel wrote:
>>  >>
>>  >> diff --git a/xen/include/asm-arm/vm_event.h
>> b/xen/include/asm-arm/vm_event.h
>>  >> index a3fc4ce..814d0da 100644
>>  >> --- a/xen/include/asm-arm/vm_event.h
>>  >> +++ b/xen/include/asm-arm/vm_event.h
>>  >> @@ -48,15 +48,10 @@ void vm_event_register_write_resume(struct vcpu
>> *v, vm_event_response_t *rsp)
>>  >>   /* Not supported on ARM. */
>>  >>   }
>>  >>
>>  >> -static inline
>>  >> -void vm_event_set_registers(struct vcpu *v, vm_event_response_t
*rsp)
>>  >> -{
>>  >> -/* Not supported on ARM. */
>>  >> -}
>>  >> +void vm_event_set_registers(struct vcpu *v, vm_event_response_t
*rsp);
>>  >>
>>  >> -static inline void vm_event_fill_regs(vm_event_request_t *req)
>>  >> -{
>>  >> -/* Not supported on ARM. */
>>  >> -}
>>  >> +void vm_event_fill_regs(vm_event_request_t *req,
>>  >> +const struct cpu_user_regs *regs,
>>  >> +struct domain *d);
>>  >>
>>  >>   #endif /* __ASM_ARM_VM_EVENT_H__ */
>>  >> diff --git a/xen/include/public/vm_event.h
>> b/xen/include/public/vm_event.h
>>  >> index 3acf217..fabeee8 100644
>>  >> --- a/xen/include/public/vm_event.h
>>  >> +++ b/xen/include/public/vm_event.h
>>  >> @@ -129,8 +129,8 @@
>>  >>   #define VM_EVENT_X86_XCR0   3
>>  >>
>>  >>   /*
>>  >> - * Using a custom struct (not hvm_hw_cpu) so as to not fill
>>  >> - * the vm_event ring buffer too quickly.
>>  >> + * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and
ARM
>>  >
>>  >
>>  > You may want to rework this sentence as hvm_hw_cpu does not exist on
>> ARM/ARM64.
>>
>> IMHO the point gets across even if we don't name the ARM structs
>> specifically.
>
>
> It was more for more correctness from an ARM point of view. But fair
enough.
>
>
>>
>>  >
>>  >> + * so as to not fill the vm_event ring buffer too quickly.
>>  >>*/
>>  >>   struct vm_event_regs_x86 {
>>  >>   uint64_t rax;
>>  >> @@ -168,6 +168,54 @@ struct vm_event_regs_x86 {
>>  >>   uint32_t _pad;
>>  >>   };
>>  >>
>>  >> +struct vm_event_regs_arm32 {
>>  >> +uint32_t r0_usr;
>>  >> +uint32_t r1_usr;
>>  >> +uint32_t r2_usr;
>>  >> +uint32_t r3_usr;
>>  >> +uint32_t r4_usr;
>>  >> +uint32_t r5_usr;
>>  >> +uint32_t r6_usr;
>>  >> +uint32_t r7_usr;
>>  >> +uint32_t r8_usr;
>>  >> +uint32_t r9_usr;
>>  >> +uint32_t r10_usr;
>>  >> +uint32_t r12_usr;
>>  >> +uint32_t lr_usr;
>>  >> +uint32_t sp_usr;
>>  >> +uint32_t sp_svc;
>>  >> +uint32_t spsr_svc;
>>  >> +uint32_t fp;
>>  >> +uint32_t pc;
>>  >> +uint32_t cpsr;
>>  >> +uint32_t ttbr0;
>>  >> +uint32_t ttbr1;
>>  >> +};
>>  >> +
>>  >> +struct vm_event_regs_arm64 {
>>  >> +uint64_t x0;
>>  >> +uint64_t x1;
>>  >> +uint64_t x2;
>>  >> +uint64_t x3;
>>  >> +uint64_t x4;
>>  >> +uint64_t x5;
>>  >> +uint64_t x6;
>>  >> +uint64_t x7;
>>  >> +uint64_t x8;
>>  >> +uint64_t x9;
>>  >> +uint64_t x10;
>>  >> +uint64_t x16;
>>  >> +uint64_t lr;
>>  >> +uint64_t sp_el0;
>>  >> +uint64_t sp_el1;
>>  >> +uint32_t spsr_el1;
>>  >> +uint64_t fp;
>>  >> +uint64_t pc;
>>  >> +uint32_t cpsr;
>>  >> +uint64_t ttbr0;
>>  >> +uint64_t ttbr1;
>>  >> +};
>>  >
>>  >
>>  > By defining 2 distinct structures, it will be more difficult for the
>> introspection tools to inspect registers of an Aarch64 domain running in
>> AArch32 mode. They wouldn't be able to re-use code for AArch32 domain
>> because the structure fields are different.
>>  >
>>  > The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping
>> between AArch32 state and AArch64 state. If you use it to define the
>> layout of a common structure, the support of AArch32 state for AArch64
>> domain will come free.
>>  >
>>
>> If the guest is running in 32-bit mode Xen will fill the 32-bit struct,
>> so doing a common struct is not strictly necessary. It also requires a
>> bunch if union declarations to match the names between that I would
>> prefer to avoid. IMHO it's cleaner to do the struct definitions
>> separately and then do a union on top.
>
>
> That is not true. is_domain_32bit will check if the domain is configured
to run 32-bit or 64-bit in EL1 (i.e the kernel level).
>
> So if you have a guest with 64-bit kernel and 32-bit userspace, Xen will
always fill the 64-bit structure, even when the userspace is running.
>

Hm fair point. It complicates things a bit though either way as the event
subscriber wouldn't know which mode it received the event from without
doing some extra checks. So I guess Xen should transmit that information
too, at which point it could also just pick the right struct to fill with

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 12:11 PM, Dagaen Golomb  wrote:
> On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  
> wrote:
>> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  wrote:
>>> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
 Hi All,

 I'm having an interesting issue. I am working on a project that
 requires me to share memory between dom0 and domUs. I have this
 successfully working using the grant table and the XenStore to
 communicate grefs.

 My issue is this. I have one domU running Ubuntu 12.04 with a default
 3.8.x kernel that has no issue reading or writing from the XenStore.
 My work also requires some kernel modifications, and we have made
 these changes in the 4.1.0 kernel. In particular, we've only added a
 simple hypercall. This modified kernel is what dom0 is running, on top
 of Xen 4.7 rc1.
>>>
>>> Without reading the rest of the thread but seeing the kernel versions.
>>> Can you check how you're communicating to xenstore? Is it via
>>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
>>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
>>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>>> that default didn't land until Xen 4.7. Since you're on the right
>>> versions I expect you're using /dev/xen/xenbus but you never know.
>>
>> How do I know which is being used? /dev/xen/xenbus is there and so is
>> process/xen/xenbus. Could this be a problem with header version
>> mismatches or something similar? I'm using the xen/xenstore.h header
>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>> should be in /dev/, and the old kernel is before 3.14 but the new one
>> is after, but I would presume the standard headers are updated to
>> account for this. Is there an easy way to check for this? Also, would
>> the same issue cause writes to fails? Because writes from the same
>> domain work fine, and appear to other domains using xenstore-ls.
>>
>> Regards,
>> Dagaen Golomb
>>
>
> Use strace on the process and see what gets opened.

 Ah, of course. It seems both the working and non-working domains are
 using /proc/...

 Regards,
 Dagaen Golomb

>>>
>>>
>>> How are you starting them? Can you confirm its attempting /dev/ first?
>>> Xen 4.7 should prefer /dev/.

For all kernels in my domU, without setting any environment variables
they use /proc/.
For 4.1.0 this did not work, but works with /dev/ when using
environment variable.
Is this supposed to try /dev/ before /proc/? Because this doesn't
appear the case according to strace.
I think this is a bug.

Regards,
Dagaen Golomb

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

[Xen-devel] [ovmf test] 94482: regressions - FAIL

[osstest service owner]

flight 94482 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94482/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf 7b1fe7acdca15be49a9421156b799ed7394f7bac
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  160 days
Failing since 65593  2015-12-08 23:44:51 Z  159 days  268 attempts
Testing same since94482  2016-05-16 12:45:20 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hegde, Nagaraj P nagaraj-p.he...@hpe.com
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  

Re: [Xen-devel] [PATCH V2 1/2] x86/hvm: Add check when register io handler

[Paul Durrant]

> -Original Message-
> From: Suravee Suthikulpanit [mailto:suravee.suthikulpa...@amd.com]
> Sent: 16 May 2016 17:03
> To: Paul Durrant; xen-devel@lists.xen.org; George Dunlap;
> jbeul...@suse.com
> Subject: Re: [PATCH V2 1/2] x86/hvm: Add check when register io handler
> 
> Hi Paul,
> 
> On 05/16/2016 03:01 AM, Paul Durrant wrote:
> >> -Original Message-
> >> >From:suravee.suthikulpa...@amd.com
> >> >[mailto:suravee.suthikulpa...@amd.com]
> >> >Sent: 13 May 2016 20:37
> >> >To:xen-devel@lists.xen.org; George Dunlap;jbeul...@suse.com
> >> >Cc: Paul Durrant; Suravee Suthikulpanit; Suravee Suthikulpanit
> >> >Subject: [PATCH V2 1/2] x86/hvm: Add check when register io handler
> >> >
> >> >From: Suravee Suthikulpanit
> >> >
> >> >At the time of registering HVM I/O handler, the HVM domain might
> >> >not have been initialized,
> > I/O handler registration is internal to Xen so any caller that attempt to
> register before domain initialization should be removed and replaced with
> one that does it at the right time.
> 
> Ok. I'll just remove that call for now.
> 
> >> >which means the hvm_domain.io_handler
> >> >would be NULL. In the hvm_next_io_handler(), this should be checked
> >> >before returning and referencing the array. Also, the io_handler_count
> >> >should only be incremented on success.
> >> >
> >> >So, this patch adds error handling in hvm_next_io_handler.
> >> >
> > This isn't necessary. An ASSERT would be preferable so that buggy callers
> can be easily caught.
> 
> Ok, I'll update the patch to ASSERT() and send it out. Although, just
> want to make sure that you think it should really be doing assert and
> not warning + handling error? It seems quite aggressive to crash the
> hypervisor simply because some io handler are not properly call.
> 

That's a reasonable argument, but IMO since all the callers are in the 
hypervisor and ASSERTs only affect debug builds I think it's reasonable.

  Paul

> Thanks,
> Suravee

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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 12:03 PM, Dagaen Golomb  wrote:
> On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  wrote:
>> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
 On 5/15/16 8:28 PM, Dagaen Golomb wrote:
>> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
>>> Hi All,
>>>
>>> I'm having an interesting issue. I am working on a project that
>>> requires me to share memory between dom0 and domUs. I have this
>>> successfully working using the grant table and the XenStore to
>>> communicate grefs.
>>>
>>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>>> My work also requires some kernel modifications, and we have made
>>> these changes in the 4.1.0 kernel. In particular, we've only added a
>>> simple hypercall. This modified kernel is what dom0 is running, on top
>>> of Xen 4.7 rc1.
>>
>> Without reading the rest of the thread but seeing the kernel versions.
>> Can you check how you're communicating to xenstore? Is it via
>> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
>> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
>> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
>> that default didn't land until Xen 4.7. Since you're on the right
>> versions I expect you're using /dev/xen/xenbus but you never know.
>
> How do I know which is being used? /dev/xen/xenbus is there and so is
> process/xen/xenbus. Could this be a problem with header version
> mismatches or something similar? I'm using the xen/xenstore.h header
> file for all of my xenstore interactions. I'm running Xen 4.7 so it
> should be in /dev/, and the old kernel is before 3.14 but the new one
> is after, but I would presume the standard headers are updated to
> account for this. Is there an easy way to check for this? Also, would
> the same issue cause writes to fails? Because writes from the same
> domain work fine, and appear to other domains using xenstore-ls.
>
> Regards,
> Dagaen Golomb
>

 Use strace on the process and see what gets opened.
>>>
>>> Ah, of course. It seems both the working and non-working domains are
>>> using /proc/...
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>>
>> How are you starting them? Can you confirm its attempting /dev/ first?
>> Xen 4.7 should prefer /dev/.
>
> The previous versions used /proc/ as well according to strace, but
> worked. According to others, this may be an issue with newer kernels
> (3.14+) using /proc/.
>
> I experimented with our 4.1.0 kernel. At first it still wasn't working
> because I was using sudo as the program needs superuser access... each
> time this cleared out any environment.
> Using sudo su, then setting the environment to use /dev/, and then
> running the program successfully reads! I'll consider this the
> solution. Thanks everyone.
>
> Now to make this environment setting apply to all users/shells,
> directly from boot. I guess /etc/bashrc will do the trick?

Also, this wasn't fixed when I recompiled on this kernel, so if the
newer headers point to /dev/ instead of /proc/, it must be using the
old headers for the 3.2/3.13 kernels even though its running 4.1.0.
I thought installing the kernel did headers as well, does it not? Or
do I need to place custom kernel headers myself?

Regards,
Dagaen Golomb

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

[Xen-devel] [PATCH RFC] Tmem cleanups for 4.7 (hopefully?).

[Konrad Rzeszutek Wilk]

Hey,

These four little cleanups move the bulk of tmem control ops
from tmem.c to tmem_control.c.

Last release I moved the control tmem ops from being part of tmem
hypercall to be part of the syscall subops - and this is the next
step in this cleanup. (See
http://lists.xen.org/archives/html/xen-devel/2015-10/msg03313.html)
which will allow me to follow up on the other steps:
 b) Fix the toolstack (cleanup)
 c) tmem tze, dedup, and zlib code drop

Anyhow sorry for this being so tardy - xSplice had more attention :-)

Regression tests show no problems.

The patches themselves have no functionality changes thought I was itching
to remove most of the counters. I will do that going forward, but need
to figure out which ones make sense or if some of them can be coalesced.

 xen/common/Makefile|   2 +-
 xen/common/tmem.c  | 618 +
 xen/common/tmem_control.c  | 443 +
 xen/include/xen/tmem_control.h |  33 +++
 xen/include/xen/tmem_xen.h | 128 +
 5 files changed, 672 insertions(+), 552 deletions(-)

Konrad Rzeszutek Wilk (4):
  tmem: Move global stats in a tmem_statistics structure
  tmem: Wrap atomic_t in struct tmem_statistics as well.
  tmem: Move global_ individual variables in a global structure.
  tmem: Move bulk of tmem control functions in its own file.


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

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Dagaen Golomb]

On Mon, May 16, 2016 at 11:55 AM, Doug Goldstein  wrote:
> On 5/15/16 8:41 PM, Dagaen Golomb wrote:
>>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
> On 5/15/16 11:40 AM, Dagaen Golomb wrote:
>> Hi All,
>>
>> I'm having an interesting issue. I am working on a project that
>> requires me to share memory between dom0 and domUs. I have this
>> successfully working using the grant table and the XenStore to
>> communicate grefs.
>>
>> My issue is this. I have one domU running Ubuntu 12.04 with a default
>> 3.8.x kernel that has no issue reading or writing from the XenStore.
>> My work also requires some kernel modifications, and we have made
>> these changes in the 4.1.0 kernel. In particular, we've only added a
>> simple hypercall. This modified kernel is what dom0 is running, on top
>> of Xen 4.7 rc1.
>
> Without reading the rest of the thread but seeing the kernel versions.
> Can you check how you're communicating to xenstore? Is it via
> /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
> deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
> prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
> that default didn't land until Xen 4.7. Since you're on the right
> versions I expect you're using /dev/xen/xenbus but you never know.

 How do I know which is being used? /dev/xen/xenbus is there and so is
 process/xen/xenbus. Could this be a problem with header version
 mismatches or something similar? I'm using the xen/xenstore.h header
 file for all of my xenstore interactions. I'm running Xen 4.7 so it
 should be in /dev/, and the old kernel is before 3.14 but the new one
 is after, but I would presume the standard headers are updated to
 account for this. Is there an easy way to check for this? Also, would
 the same issue cause writes to fails? Because writes from the same
 domain work fine, and appear to other domains using xenstore-ls.

 Regards,
 Dagaen Golomb

>>>
>>> Use strace on the process and see what gets opened.
>>
>> Ah, of course. It seems both the working and non-working domains are
>> using /proc/...
>>
>> Regards,
>> Dagaen Golomb
>>
>
>
> How are you starting them? Can you confirm its attempting /dev/ first?
> Xen 4.7 should prefer /dev/.

The previous versions used /proc/ as well according to strace, but
worked. According to others, this may be an issue with newer kernels
(3.14+) using /proc/.

I experimented with our 4.1.0 kernel. At first it still wasn't working
because I was using sudo as the program needs superuser access... each
time this cleared out any environment.
Using sudo su, then setting the environment to use /dev/, and then
running the program successfully reads! I'll consider this the
solution. Thanks everyone.

Now to make this environment setting apply to all users/shells,
directly from boot. I guess /etc/bashrc will do the trick?

Regards,
Dagaen Golomb

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

Re: [Xen-devel] [PATCH V2 1/2] x86/hvm: Add check when register io handler

[Suravee Suthikulpanit]

Hi Paul,

On 05/16/2016 03:01 AM, Paul Durrant wrote:

-Original Message-
>From:suravee.suthikulpa...@amd.com
>[mailto:suravee.suthikulpa...@amd.com]
>Sent: 13 May 2016 20:37
>To:xen-devel@lists.xen.org; George Dunlap;jbeul...@suse.com
>Cc: Paul Durrant; Suravee Suthikulpanit; Suravee Suthikulpanit
>Subject: [PATCH V2 1/2] x86/hvm: Add check when register io handler
>
>From: Suravee Suthikulpanit
>
>At the time of registering HVM I/O handler, the HVM domain might
>not have been initialized,

I/O handler registration is internal to Xen so any caller that attempt to 
register before domain initialization should be removed and replaced with one 
that does it at the right time.


Ok. I'll just remove that call for now.


>which means the hvm_domain.io_handler
>would be NULL. In the hvm_next_io_handler(), this should be checked
>before returning and referencing the array. Also, the io_handler_count
>should only be incremented on success.
>
>So, this patch adds error handling in hvm_next_io_handler.
>

This isn't necessary. An ASSERT would be preferable so that buggy callers can 
be easily caught.


Ok, I'll update the patch to ASSERT() and send it out. Although, just 
want to make sure that you think it should really be doing assert and 
not warning + handling error? It seems quite aggressive to crash the 
hypervisor simply because some io handler are not properly call.


Thanks,
Suravee

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

[Xen-devel] [PATCH RFC 4/4] tmem: Move bulk of tmem control functions in its own file.

[Konrad Rzeszutek Wilk]

The functionality that is related to migration is left inside
tmem.c. The list of control operations that are in tmem_control
with XEN_SYSCTL_TMEM_OP prefix are:

DESTROY, FLUSH, FREEZE, THAW, LIST, QUERY_FREEABLE_MB
SAVE_GET_CLIENT_CAP, SAVE_GET_CLIENT_FLAGS,
SAVE_GET_CLIENT_WEIGHT, SAVE_GET_MAXPOOLS,
SAVE_GET_POOL_FLAGS, SAVE_GET_POOL_NPAGES
SAVE_GET_POOL_UUID, SAVE_GET_VERSION
SET_CAP, SET_COMPRESS, SET_WEIGHT

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/Makefile|   2 +-
 xen/common/tmem.c  | 514 +
 xen/common/tmem_control.c  | 443 +++
 xen/include/xen/tmem_control.h |  33 +++
 xen/include/xen/tmem_xen.h | 128 ++
 5 files changed, 609 insertions(+), 511 deletions(-)
 create mode 100644 xen/common/tmem_control.c
 create mode 100644 xen/include/xen/tmem_control.h

diff --git a/xen/common/Makefile b/xen/common/Makefile
index afd84b6..537bdfd 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -68,7 +68,7 @@ obj-$(crash_debug) += gdbstub.o
 
 obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o kernel.o memory.o 
multicall.o xlat.o)
 
-tmem-y := tmem.o tmem_xen.o
+tmem-y := tmem.o tmem_xen.o tmem_control.o
 tmem-$(CONFIG_COMPAT) += compat/tmem_xen.o
 obj-$(CONFIG_TMEM) += $(tmem-y)
 
diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 70cb61e..efaafc4 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -27,50 +27,7 @@
 
 #define TMEM_SPEC_VERSION 1
 
-/* Global statistics (none need to be locked). */
-struct tmem_statistics {
-unsigned long total_tmem_ops;
-unsigned long errored_tmem_ops;
-unsigned long total_flush_pool;
-unsigned long alloc_failed;
-unsigned long alloc_page_failed;
-unsigned long evicted_pgs;
-unsigned long evict_attempts;
-unsigned long relinq_pgs;
-unsigned long relinq_attempts;
-unsigned long max_evicts_per_relinq;
-unsigned long low_on_memory;
-unsigned long deduped_puts;
-unsigned long tot_good_eph_puts;
-int global_obj_count_max;
-int global_pgp_count_max;
-int global_pcd_count_max;
-int global_page_count_max;
-int global_rtree_node_count_max;
-long global_eph_count_max;
-unsigned long failed_copies;
-unsigned long pcd_tot_tze_size;
-unsigned long pcd_tot_csize;
-/* Global counters (should use long_atomic_t access). */
-atomic_t global_obj_count;
-atomic_t global_pgp_count;
-atomic_t global_pcd_count;
-atomic_t global_page_count;
-atomic_t global_rtree_node_count;
-};
-
-#define atomic_inc_and_max(_c) do { \
-atomic_inc(_stats._c); \
-if ( _atomic_read(tmem_stats._c) > tmem_stats._c##_max ) \
-tmem_stats._c##_max = _atomic_read(tmem_stats._c); \
-} while (0)
-
-#define atomic_dec_and_assert(_c) do { \
-atomic_dec(_stats._c); \
-ASSERT(_atomic_read(tmem_stats._c) >= 0); \
-} while (0)
-
-static struct tmem_statistics tmem_stats = {
+struct tmem_statistics tmem_stats = {
 .global_obj_count = ATOMIC_INIT(0),
 .global_pgp_count = ATOMIC_INIT(0),
 .global_pcd_count = ATOMIC_INIT(0),
@@ -80,81 +37,6 @@ static struct tmem_statistics tmem_stats = {
 
 / CORE DATA STRUCTURES /
 
-#define MAX_POOLS_PER_DOMAIN 16
-#define MAX_GLOBAL_SHARED_POOLS  16
-
-struct tmem_pool;
-struct tmem_page_descriptor;
-struct tmem_page_content_descriptor;
-struct client {
-struct list_head client_list;
-struct tmem_pool *pools[MAX_POOLS_PER_DOMAIN];
-struct domain *domain;
-struct xmem_pool *persistent_pool;
-struct list_head ephemeral_page_list;
-long eph_count, eph_count_max;
-domid_t cli_id;
-uint32_t weight;
-uint32_t cap;
-bool_t compress;
-bool_t frozen;
-bool_t shared_auth_required;
-/* For save/restore/migration. */
-bool_t live_migrating;
-bool_t was_frozen;
-struct list_head persistent_invalidated_list;
-struct tmem_page_descriptor *cur_pgp;
-/* Statistics collection. */
-unsigned long compress_poor, compress_nomem;
-unsigned long compressed_pages;
-uint64_t compressed_sum_size;
-uint64_t total_cycles;
-unsigned long succ_pers_puts, succ_eph_gets, succ_pers_gets;
-/* Shared pool authentication. */
-uint64_t shared_auth_uuid[MAX_GLOBAL_SHARED_POOLS][2];
-};
-
-struct share_list {
-struct list_head share_list;
-struct client *client;
-};
-
-#define POOL_PAGESHIFT (PAGE_SHIFT - 12)
-#define OBJ_HASH_BUCKETS 256 /* Must be power of two. */
-#define OBJ_HASH_BUCKETS_MASK (OBJ_HASH_BUCKETS-1)
-
-struct tmem_pool {
-bool_t shared;
-bool_t persistent;
-bool_t is_dying;
-struct client *client;
-uint64_t uuid[2]; /* 0 for private, non-zero for shared. */
-uint32_t pool_id;
-rwlock_t pool_rwlock;
-struct rb_root obj_rb_root[OBJ_HASH_BUCKETS]; /* Protected by pool_rwlock. 
*/
-struct list_head share_list; /* Valid if 

[Xen-devel] [PATCH RFC 1/4] tmem: Move global stats in a tmem_statistics structure

[Konrad Rzeszutek Wilk]

And adjust the macro: atomic_inc_and_max to update the structure.

Sadly one entry: pool->pgp_count cannot use this macro anymore
so unroll the macro for this instance.

No functional change. The name has the 'tmem_stats' as it will
be eventually non-local.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/tmem.c | 135 +-
 1 file changed, 73 insertions(+), 62 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index 16e249a..d362eae 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -28,25 +28,32 @@
 #define TMEM_SPEC_VERSION 1
 
 /* Global statistics (none need to be locked). */
-static unsigned long total_tmem_ops = 0;
-static unsigned long errored_tmem_ops = 0;
-static unsigned long total_flush_pool = 0;
-static unsigned long alloc_failed = 0, alloc_page_failed = 0;
-static unsigned long evicted_pgs = 0, evict_attempts = 0;
-static unsigned long relinq_pgs = 0, relinq_attempts = 0;
-static unsigned long max_evicts_per_relinq = 0;
-static unsigned long low_on_memory = 0;
-static unsigned long deduped_puts = 0;
-static unsigned long tot_good_eph_puts = 0;
-static int global_obj_count_max = 0;
-static int global_pgp_count_max = 0;
-static int global_pcd_count_max = 0;
-static int global_page_count_max = 0;
-static int global_rtree_node_count_max = 0;
-static long global_eph_count_max = 0;
-static unsigned long failed_copies;
-static unsigned long pcd_tot_tze_size = 0;
-static unsigned long pcd_tot_csize = 0;
+struct tmem_statistics {
+unsigned long total_tmem_ops;
+unsigned long errored_tmem_ops;
+unsigned long total_flush_pool;
+unsigned long alloc_failed;
+unsigned long alloc_page_failed;
+unsigned long evicted_pgs;
+unsigned long evict_attempts;
+unsigned long relinq_pgs;
+unsigned long relinq_attempts;
+unsigned long max_evicts_per_relinq;
+unsigned long low_on_memory;
+unsigned long deduped_puts;
+unsigned long tot_good_eph_puts;
+int global_obj_count_max;
+int global_pgp_count_max;
+int global_pcd_count_max;
+int global_page_count_max;
+int global_rtree_node_count_max;
+long global_eph_count_max;
+unsigned long failed_copies;
+unsigned long pcd_tot_tze_size;
+unsigned long pcd_tot_csize;
+};
+
+static struct tmem_statistics tmem_stats;
 
 / CORE DATA STRUCTURES /
 
@@ -225,8 +232,8 @@ static atomic_t global_rtree_node_count = ATOMIC_INIT(0);
 
 #define atomic_inc_and_max(_c) do { \
 atomic_inc(&_c); \
-if ( _atomic_read(_c) > _c##_max ) \
-_c##_max = _atomic_read(_c); \
+if ( _atomic_read(_c) > tmem_stats._c##_max ) \
+tmem_stats._c##_max = _atomic_read(_c); \
 } while (0)
 
 #define atomic_dec_and_assert(_c) do { \
@@ -273,7 +280,7 @@ static void *tmem_malloc(size_t size, struct tmem_pool 
*pool)
 v = xmem_pool_alloc(size, tmem_mempool);
 }
 if ( v == NULL )
-alloc_failed++;
+tmem_stats.alloc_failed++;
 return v;
 }
 
@@ -300,7 +307,7 @@ static struct page_info *tmem_alloc_page(struct tmem_pool 
*pool)
 else
 pfp = __tmem_alloc_page();
 if ( pfp == NULL )
-alloc_page_failed++;
+tmem_stats.alloc_page_failed++;
 else
 atomic_inc_and_max(global_page_count);
 return pfp;
@@ -437,20 +444,20 @@ static void pcd_disassociate(struct tmem_page_descriptor 
*pgp, struct tmem_pool
 {
 /* Compressed data. */
 tmem_free(pcd_cdata, pool);
-pcd_tot_csize -= pcd_csize;
+tmem_stats.pcd_tot_csize -= pcd_csize;
 }
 else if ( pcd_size != PAGE_SIZE )
 {
 /* Trailing zero data. */
-pcd_tot_tze_size -= pcd_size;
+tmem_stats.pcd_tot_tze_size -= pcd_size;
 if ( pcd_size )
 tmem_free(pcd_tze, pool);
 } else {
 /* Real physical page. */
 if ( tmem_tze_enabled() )
-pcd_tot_tze_size -= PAGE_SIZE;
+tmem_stats.pcd_tot_tze_size -= PAGE_SIZE;
 if ( tmem_compression_enabled() )
-pcd_tot_csize -= PAGE_SIZE;
+tmem_stats.pcd_tot_csize -= PAGE_SIZE;
 tmem_free_page(pool,pfp);
 }
 write_unlock(_tree_rwlocks[firstbyte]);
@@ -533,7 +540,7 @@ static int pcd_associate(struct tmem_page_descriptor *pgp, 
char *cdata, pagesize
  */
 if ( cdata == NULL )
 tmem_free_page(pgp->us.obj->pool,pgp->pfp);
-deduped_puts++;
+tmem_stats.deduped_puts++;
 goto match;
 }
 }
@@ -559,7 +566,7 @@ static int pcd_associate(struct tmem_page_descriptor *pgp, 
char *cdata, pagesize
 {
 memcpy(pcd->cdata,cdata,csize);
 pcd->size = csize;
-pcd_tot_csize += csize;
+tmem_stats.pcd_tot_csize += csize;
 } else if ( pfp_size == 0 ) {
 ASSERT(tmem_tze_enabled());
 pcd->size = 0;
@@ -568,15 +575,15 @@ static int 

[Xen-devel] [PATCH RFC 3/4] tmem: Move global_ individual variables in a global structure.

[Konrad Rzeszutek Wilk]

Put them all in one structure to make it easier to
figure out what can be removed. The structure is called
'tmem_global' as it will be eventually non-static.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/tmem.c | 76 +--
 1 file changed, 40 insertions(+), 36 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index b58ab4d..70cb61e 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -222,13 +222,6 @@ struct tmem_page_content_descriptor {
 struct rb_root pcd_tree_roots[256]; /* Choose based on first byte of page. */
 rwlock_t pcd_tree_rwlocks[256]; /* Poor man's concurrency for now. */
 
-static LIST_HEAD(global_ephemeral_page_list); /* All pages in ephemeral pools. 
*/
-
-static LIST_HEAD(global_client_list);
-
-static struct tmem_pool *global_shared_pools[MAX_GLOBAL_SHARED_POOLS] = { 0 };
-static bool_t global_shared_auth = 0;
-static atomic_t client_weight_total = ATOMIC_INIT(0);
 static int tmem_initialized = 0;
 
 struct xmem_pool *tmem_mempool = 0;
@@ -245,8 +238,20 @@ static DEFINE_SPINLOCK(pers_lists_spinlock);
 #define ASSERT_SPINLOCK(_l) ASSERT(spin_is_locked(_l))
 #define ASSERT_WRITELOCK(_l) ASSERT(rw_is_write_locked(_l))
 
-static long global_eph_count; /* Atomicity depends on eph_lists_spinlock. */
+struct tmem_global {
+struct list_head ephemeral_page_list;  /* All pages in ephemeral pools. */
+struct list_head client_list;
+struct tmem_pool *shared_pools[MAX_GLOBAL_SHARED_POOLS];
+bool_t shared_auth;
+atomic_t client_weight_total;
+long eph_count;  /* Atomicity depends on eph_lists_spinlock. */
+};
 
+struct tmem_global tmem_global = {
+.ephemeral_page_list = LIST_HEAD_INIT(tmem_global.ephemeral_page_list),
+.client_list = LIST_HEAD_INIT(tmem_global.client_list),
+.client_weight_total = ATOMIC_INIT(0),
+};
 
 /*
  * There two types of memory allocation interfaces in tmem.
@@ -724,8 +729,8 @@ static void pgp_delist_free(struct tmem_page_descriptor 
*pgp)
 ASSERT(client->eph_count >= 0);
 list_del_init(>us.client_eph_pages);
 if ( !list_empty(>global_eph_pages) )
-global_eph_count--;
-ASSERT(global_eph_count >= 0);
+tmem_global.eph_count--;
+ASSERT(tmem_global.eph_count >= 0);
 list_del_init(>global_eph_pages);
 spin_unlock(_lists_spinlock);
 }
@@ -1126,9 +1131,9 @@ static int shared_pool_quit(struct tmem_pool *pool, 
domid_t cli_id)
 if (pool->shared_count)
 return pool->shared_count;
 for (s_poolid = 0; s_poolid < MAX_GLOBAL_SHARED_POOLS; s_poolid++)
-if ( (global_shared_pools[s_poolid]) == pool )
+if ( (tmem_global.shared_pools[s_poolid]) == pool )
 {
-global_shared_pools[s_poolid] = NULL;
+tmem_global.shared_pools[s_poolid] = NULL;
 break;
 }
 return 0;
@@ -1209,7 +1214,7 @@ static struct client *client_create(domid_t cli_id)
 for ( i = 0; i < MAX_GLOBAL_SHARED_POOLS; i++)
 client->shared_auth_uuid[i][0] =
 client->shared_auth_uuid[i][1] = -1L;
-list_add_tail(>client_list, _client_list);
+list_add_tail(>client_list, _global.client_list);
 INIT_LIST_HEAD(>ephemeral_page_list);
 INIT_LIST_HEAD(>persistent_invalidated_list);
 tmem_client_info("ok\n");
@@ -1245,13 +1250,13 @@ static void client_flush(struct client *client)
 
 static bool_t client_over_quota(struct client *client)
 {
-int total = _atomic_read(client_weight_total);
+int total = _atomic_read(tmem_global.client_weight_total);
 
 ASSERT(client != NULL);
 if ( (total == 0) || (client->weight == 0) ||
   (client->eph_count == 0) )
 return 0;
-return ( ((global_eph_count*100L) / client->eph_count ) >
+return ( ((tmem_global.eph_count*100L) / client->eph_count ) >
  ((total*100L) / client->weight) );
 }
 
@@ -1280,7 +1285,7 @@ static bool_t tmem_try_to_evict_pgp(struct 
tmem_page_descriptor *pgp, bool_t *ho
 {
 pgp->eviction_attempted++;
 list_del(>global_eph_pages);
-
list_add_tail(>global_eph_pages,_ephemeral_page_list);
+
list_add_tail(>global_eph_pages,_global.ephemeral_page_list);
 list_del(>us.client_eph_pages);
 
list_add_tail(>us.client_eph_pages,>ephemeral_page_list);
 goto pcd_unlock;
@@ -1320,9 +1325,9 @@ static int tmem_evict(void)
 if ( tmem_try_to_evict_pgp(pgp, _pool_rwlock) )
 goto found;
 }
-else if ( !list_empty(_ephemeral_page_list) )
+else if ( !list_empty(_global.ephemeral_page_list) )
 {
-list_for_each_entry(pgp, _ephemeral_page_list, global_eph_pages)
+list_for_each_entry(pgp, _global.ephemeral_page_list, 
global_eph_pages)
 if ( tmem_try_to_evict_pgp(pgp, _pool_rwlock) )
  

Re: [Xen-devel] [PATCH v3 4/9] arm/vm_event: get/set registers

[Julien Grall]

Hi Tamas,

On 16/05/16 16:37, Tamas K Lengyel wrote:


On May 16, 2016 04:14, "Julien Grall" > wrote:
 > On 04/05/16 15:51, Tamas K Lengyel wrote:
 >>
 >> diff --git a/xen/include/asm-arm/vm_event.h
b/xen/include/asm-arm/vm_event.h
 >> index a3fc4ce..814d0da 100644
 >> --- a/xen/include/asm-arm/vm_event.h
 >> +++ b/xen/include/asm-arm/vm_event.h
 >> @@ -48,15 +48,10 @@ void vm_event_register_write_resume(struct vcpu
*v, vm_event_response_t *rsp)
 >>   /* Not supported on ARM. */
 >>   }
 >>
 >> -static inline
 >> -void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
 >> -{
 >> -/* Not supported on ARM. */
 >> -}
 >> +void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
 >>
 >> -static inline void vm_event_fill_regs(vm_event_request_t *req)
 >> -{
 >> -/* Not supported on ARM. */
 >> -}
 >> +void vm_event_fill_regs(vm_event_request_t *req,
 >> +const struct cpu_user_regs *regs,
 >> +struct domain *d);
 >>
 >>   #endif /* __ASM_ARM_VM_EVENT_H__ */
 >> diff --git a/xen/include/public/vm_event.h
b/xen/include/public/vm_event.h
 >> index 3acf217..fabeee8 100644
 >> --- a/xen/include/public/vm_event.h
 >> +++ b/xen/include/public/vm_event.h
 >> @@ -129,8 +129,8 @@
 >>   #define VM_EVENT_X86_XCR0   3
 >>
 >>   /*
 >> - * Using a custom struct (not hvm_hw_cpu) so as to not fill
 >> - * the vm_event ring buffer too quickly.
 >> + * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
 >
 >
 > You may want to rework this sentence as hvm_hw_cpu does not exist on
ARM/ARM64.

IMHO the point gets across even if we don't name the ARM structs
specifically.


It was more for more correctness from an ARM point of view. But fair enough.



 >
 >> + * so as to not fill the vm_event ring buffer too quickly.
 >>*/
 >>   struct vm_event_regs_x86 {
 >>   uint64_t rax;
 >> @@ -168,6 +168,54 @@ struct vm_event_regs_x86 {
 >>   uint32_t _pad;
 >>   };
 >>
 >> +struct vm_event_regs_arm32 {
 >> +uint32_t r0_usr;
 >> +uint32_t r1_usr;
 >> +uint32_t r2_usr;
 >> +uint32_t r3_usr;
 >> +uint32_t r4_usr;
 >> +uint32_t r5_usr;
 >> +uint32_t r6_usr;
 >> +uint32_t r7_usr;
 >> +uint32_t r8_usr;
 >> +uint32_t r9_usr;
 >> +uint32_t r10_usr;
 >> +uint32_t r12_usr;
 >> +uint32_t lr_usr;
 >> +uint32_t sp_usr;
 >> +uint32_t sp_svc;
 >> +uint32_t spsr_svc;
 >> +uint32_t fp;
 >> +uint32_t pc;
 >> +uint32_t cpsr;
 >> +uint32_t ttbr0;
 >> +uint32_t ttbr1;
 >> +};
 >> +
 >> +struct vm_event_regs_arm64 {
 >> +uint64_t x0;
 >> +uint64_t x1;
 >> +uint64_t x2;
 >> +uint64_t x3;
 >> +uint64_t x4;
 >> +uint64_t x5;
 >> +uint64_t x6;
 >> +uint64_t x7;
 >> +uint64_t x8;
 >> +uint64_t x9;
 >> +uint64_t x10;
 >> +uint64_t x16;
 >> +uint64_t lr;
 >> +uint64_t sp_el0;
 >> +uint64_t sp_el1;
 >> +uint32_t spsr_el1;
 >> +uint64_t fp;
 >> +uint64_t pc;
 >> +uint32_t cpsr;
 >> +uint64_t ttbr0;
 >> +uint64_t ttbr1;
 >> +};
 >
 >
 > By defining 2 distinct structures, it will be more difficult for the
introspection tools to inspect registers of an Aarch64 domain running in
AArch32 mode. They wouldn't be able to re-use code for AArch32 domain
because the structure fields are different.
 >
 > The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping
between AArch32 state and AArch64 state. If you use it to define the
layout of a common structure, the support of AArch32 state for AArch64
domain will come free.
 >

If the guest is running in 32-bit mode Xen will fill the 32-bit struct,
so doing a common struct is not strictly necessary. It also requires a
bunch if union declarations to match the names between that I would
prefer to avoid. IMHO it's cleaner to do the struct definitions
separately and then do a union on top.


That is not true. is_domain_32bit will check if the domain is configured 
to run 32-bit or 64-bit in EL1 (i.e the kernel level).


So if you have a guest with 64-bit kernel and 32-bit userspace, Xen will 
always fill the 64-bit structure, even when the userspace is running.


Regards,

--
Julien Grall

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

[Xen-devel] [PATCH RFC 2/4] tmem: Wrap atomic_t in struct tmem_statistics as well.

[Konrad Rzeszutek Wilk]

The macros: atomic_inc_and_max and atomic_dec_and_assert
use also the 'stats' to access them. Had to open-code
access to pool->pgp_count as it would not work anymore.

No functional change.

Signed-off-by: Konrad Rzeszutek Wilk 
---
 xen/common/tmem.c | 57 +++
 1 file changed, 32 insertions(+), 25 deletions(-)

diff --git a/xen/common/tmem.c b/xen/common/tmem.c
index d362eae..b58ab4d 100644
--- a/xen/common/tmem.c
+++ b/xen/common/tmem.c
@@ -51,9 +51,32 @@ struct tmem_statistics {
 unsigned long failed_copies;
 unsigned long pcd_tot_tze_size;
 unsigned long pcd_tot_csize;
+/* Global counters (should use long_atomic_t access). */
+atomic_t global_obj_count;
+atomic_t global_pgp_count;
+atomic_t global_pcd_count;
+atomic_t global_page_count;
+atomic_t global_rtree_node_count;
 };
 
-static struct tmem_statistics tmem_stats;
+#define atomic_inc_and_max(_c) do { \
+atomic_inc(_stats._c); \
+if ( _atomic_read(tmem_stats._c) > tmem_stats._c##_max ) \
+tmem_stats._c##_max = _atomic_read(tmem_stats._c); \
+} while (0)
+
+#define atomic_dec_and_assert(_c) do { \
+atomic_dec(_stats._c); \
+ASSERT(_atomic_read(tmem_stats._c) >= 0); \
+} while (0)
+
+static struct tmem_statistics tmem_stats = {
+.global_obj_count = ATOMIC_INIT(0),
+.global_pgp_count = ATOMIC_INIT(0),
+.global_pcd_count = ATOMIC_INIT(0),
+.global_page_count = ATOMIC_INIT(0),
+.global_rtree_node_count = ATOMIC_INIT(0),
+};
 
 / CORE DATA STRUCTURES /
 
@@ -222,24 +245,7 @@ static DEFINE_SPINLOCK(pers_lists_spinlock);
 #define ASSERT_SPINLOCK(_l) ASSERT(spin_is_locked(_l))
 #define ASSERT_WRITELOCK(_l) ASSERT(rw_is_write_locked(_l))
 
-/* Global counters (should use long_atomic_t access). */
-static long global_eph_count = 0; /* Atomicity depends on eph_lists_spinlock. 
*/
-static atomic_t global_obj_count = ATOMIC_INIT(0);
-static atomic_t global_pgp_count = ATOMIC_INIT(0);
-static atomic_t global_pcd_count = ATOMIC_INIT(0);
-static atomic_t global_page_count = ATOMIC_INIT(0);
-static atomic_t global_rtree_node_count = ATOMIC_INIT(0);
-
-#define atomic_inc_and_max(_c) do { \
-atomic_inc(&_c); \
-if ( _atomic_read(_c) > tmem_stats._c##_max ) \
-tmem_stats._c##_max = _atomic_read(_c); \
-} while (0)
-
-#define atomic_dec_and_assert(_c) do { \
-atomic_dec(&_c); \
-ASSERT(_atomic_read(_c) >= 0); \
-} while (0)
+static long global_eph_count; /* Atomicity depends on eph_lists_spinlock. */
 
 
 /*
@@ -685,7 +691,8 @@ static void pgp_free(struct tmem_page_descriptor *pgp)
 }
 pgp_free_data(pgp, pool);
 atomic_dec_and_assert(global_pgp_count);
-atomic_dec_and_assert(pool->pgp_count);
+atomic_dec(>pgp_count);
+ASSERT(_atomic_read(pool->pgp_count) >= 0);
 pgp->size = -1;
 if ( is_persistent(pool) && pool->client->live_migrating )
 {
@@ -2210,11 +2217,11 @@ static int tmemc_list_global(tmem_cli_va_param_t buf, 
int off, uint32_t len,
   "Ec:%ld,Em:%ld,Oc:%d,Om:%d,Nc:%d,Nm:%d,Pc:%d,Pm:%d,"
   "Fc:%d,Fm:%d,Sc:%d,Sm:%d,Ep:%lu,Gd:%lu,Zt:%lu,Gz:%lu\n",
   global_eph_count, tmem_stats.global_eph_count_max,
-  _atomic_read(global_obj_count), tmem_stats.global_obj_count_max,
-  _atomic_read(global_rtree_node_count), 
tmem_stats.global_rtree_node_count_max,
-  _atomic_read(global_pgp_count), tmem_stats.global_pgp_count_max,
-  _atomic_read(global_page_count), tmem_stats.global_page_count_max,
-  _atomic_read(global_pcd_count), tmem_stats.global_pcd_count_max,
+  _atomic_read(tmem_stats.global_obj_count), 
tmem_stats.global_obj_count_max,
+  _atomic_read(tmem_stats.global_rtree_node_count), 
tmem_stats.global_rtree_node_count_max,
+  _atomic_read(tmem_stats.global_pgp_count), 
tmem_stats.global_pgp_count_max,
+  _atomic_read(tmem_stats.global_page_count), 
tmem_stats.global_page_count_max,
+  _atomic_read(tmem_stats.global_pcd_count), 
tmem_stats.global_pcd_count_max,
  
tmem_stats.tot_good_eph_puts,tmem_stats.deduped_puts,tmem_stats.pcd_tot_tze_size,
  tmem_stats.pcd_tot_csize);
 if ( sum + n >= len )
-- 
2.5.5


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

[Xen-devel] [xen-4.6-testing bisection] complete build-armhf-libvirt

[osstest service owner]

branch xen-4.6-testing
xenbranch xen-4.6-testing
job build-armhf-libvirt
testid libvirt-build

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://xenbits.xen.org/libvirt.git
  Bug introduced:  e744065679ccba8471d28b2cf6e93f443cd20c8c
  Bug not present: 744d74fafd0048c01a2b5cc18d1b03917ece8886
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/94486/


  commit e744065679ccba8471d28b2cf6e93f443cd20c8c
  Author: Jim Fehlig 
  Date:   Thu Apr 14 16:10:32 2016 -0600
  
  libxl: use LIBXL_API_VERSION 0x040200
  
  To ensure the libvirt libxl driver will build with future versions
  of Xen where the libxl API may change in incompatible ways,
  explicitly use LIBXL_API_VERSION 0x040200. The libxl driver
  does use new libxl APIs that have been added since Xen 4.2, but
  currently it does not make use of any changes made to existing
  APIs such as libxl_domain_create_restore or libxl_set_vcpuaffinity.
  The version can be bumped if/when the libxl driver consumes the
  changed APIs.
  
  Further details can be found in the following discussion thread
  
  https://www.redhat.com/archives/libvir-list/2016-April/msg00178.html
  Signed-off-by: Jim Fehlig 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.6-testing/build-armhf-libvirt.libvirt-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.6-testing/build-armhf-libvirt.libvirt-build
 --summary-out=tmp/94486.bisection-summary --basis-template=93932 
--blessings=real,real-bisect xen-4.6-testing build-armhf-libvirt libvirt-build
Searching for failure / basis pass:
 94452 fail [host=cubietruck-picasso] / 94000 [host=arndale-bluewater] 93932 
[host=arndale-metrocentre] 92181 [host=arndale-metrocentre] 88309 
[host=arndale-westfield] 88153 [host=arndale-metrocentre] 87889 
[host=arndale-westfield] 86632 [host=arndale-westfield] 86551 
[host=arndale-lakeside] 85893 [host=arndale-lakeside] 85324 
[host=cubietruck-metzinger] 84924 [host=arndale-westfield] 83820 
[host=cubietruck-metzinger] 83674 [host=arndale-metrocentre] 83120 
[host=arndale-lakeside] 83001 [host=arndale-westfield] 81632 
[host=arndale-metrocentre] 78701 [host=arndale-metrocentre] 78528 
[host=arndale-westfield] 77441 [host=arndale-lakeside] 77259 
[host=arndale-bluewater] 76950 [host=arndale-metrocentre] 67098 
[host=arndale-bluewater] 66942 [host=arndale-bluewater] 66794 
[host=arndale-bluewater] 66648 [host=arndale-lakeside] 66537 
[host=arndale-lakeside] 66394 [host=arndale-bluewater] 65639 
[host=arndale-lakeside] 65355 [host=arndale-westfield] 65327 
[host=arndale-metrocentre] 65299 [host=arndale-westfield] 65283 
[host=arndale-metrocentre] 65256 [host=arndale-westfield] 65241 
[host=arndale-westfield] 65227 [host=arndale-westfield] 65210 
[host=arndale-westfield] 65182 [host=arndale-westfield] 65158 
[host=arndale-metrocentre] 65136 [host=arndale-westfield] 65112 
[host=arndale-bluewater] 65088 [host=arndale-metrocentre] 65028 
[host=arndale-bluewater] 64988 [host=arndale-metrocentre] 64935 
[host=arndale-metrocentre] 64755 [host=arndale-metrocentre] 64505 
[host=arndale-metrocentre] 64270 [host=arndale-bluewater] 64153 
[host=cubietruck-braque] 64055 [host=arndale-metrocentre] 63449 
[host=arndale-metrocentre] 63359 [host=arndale-bluewater] 63216 
[host=arndale-bluewater] 63162 [host=cubietruck-braque] 62677 
[host=arndale-metrocentre] 62603 [host=arndale-lakeside] 62535 
[host=arndale-westfield] 62328 [host=arndale-metrocentre] 62163 
[host=arndale-metrocentre] 62089 [host=arndale-metrocentre] 62015 
[host=cubietruck-braque] 61839 [host=arndale-metrocentre] 61745 
[host=arndale-westfield] template as basis? using template as basis.
Failure / basis pass flights: 94452 / 93932
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 9055faebd426b44ad2c3bb97d6b8b0dd3496ab35 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
14a60f98e0cd16e2636afb136129ed7f11cbfce0 
426783e661da942f8b7871613479db4daa6a16c3
Basis pass 8b62c65d24bdb20121d3147b4f4dc98bac4f024b 
6cc32c63e80bc1a30c521b2f07f2b54909b59892 
62936f64308aae81530b1273ad2c248b6476e62e 
39546d1360d954c2d0e2ff71dc74851e7081f61f
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#8b62c65d24bdb20121d3147b4f4dc98bac4f024b-9055faebd426b44ad2c3bb97d6b8b0dd3496ab35
 

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Doug Goldstein]

On 5/15/16 8:41 PM, Dagaen Golomb wrote:
>> On 5/15/16 8:28 PM, Dagaen Golomb wrote:
 On 5/15/16 11:40 AM, Dagaen Golomb wrote:
> Hi All,
>
> I'm having an interesting issue. I am working on a project that
> requires me to share memory between dom0 and domUs. I have this
> successfully working using the grant table and the XenStore to
> communicate grefs.
>
> My issue is this. I have one domU running Ubuntu 12.04 with a default
> 3.8.x kernel that has no issue reading or writing from the XenStore.
> My work also requires some kernel modifications, and we have made
> these changes in the 4.1.0 kernel. In particular, we've only added a
> simple hypercall. This modified kernel is what dom0 is running, on top
> of Xen 4.7 rc1.

 Without reading the rest of the thread but seeing the kernel versions.
 Can you check how you're communicating to xenstore? Is it via
 /dev/xen/xenbus or /proc/xen/xenbus? Anything after 3.14 will give you
 deadlocks if you try to use /proc/xen/xenbus. Xen 4.6 and newer should
 prefer /dev/xen/xenbus. Same thing can happen with privcmd but making
 that default didn't land until Xen 4.7. Since you're on the right
 versions I expect you're using /dev/xen/xenbus but you never know.
>>>
>>> How do I know which is being used? /dev/xen/xenbus is there and so is
>>> process/xen/xenbus. Could this be a problem with header version
>>> mismatches or something similar? I'm using the xen/xenstore.h header
>>> file for all of my xenstore interactions. I'm running Xen 4.7 so it
>>> should be in /dev/, and the old kernel is before 3.14 but the new one
>>> is after, but I would presume the standard headers are updated to
>>> account for this. Is there an easy way to check for this? Also, would
>>> the same issue cause writes to fails? Because writes from the same
>>> domain work fine, and appear to other domains using xenstore-ls.
>>>
>>> Regards,
>>> Dagaen Golomb
>>>
>>
>> Use strace on the process and see what gets opened.
> 
> Ah, of course. It seems both the working and non-working domains are
> using /proc/...
> 
> Regards,
> Dagaen Golomb
> 


How are you starting them? Can you confirm its attempting /dev/ first?
Xen 4.7 should prefer /dev/.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 0/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Wei Liu]

On Mon, May 16, 2016 at 05:03:54PM +0200, Edgar E. Iglesias wrote:
> From: "Edgar E. Iglesias" 
> 
> I'm sending this as a v2 considering that I previously posted a diff
> in email discussions.
> 
> This patch fixes an DT problem with the ZynqMP PCIe node.
> Today, we try to remap IRQs regardless of if they are directly
> connected to the primary controller or not. If they are indirectly
> connected via secondary IRQ controllers, we abort the boot with
> an error.
> 
> The ZynqMP PCIe DTS bindings were upstreamed to Linux after Xen 4.6, so
> this issue is not a regression.
> PCIe is also not generally a critical feature of current ZynqMP boards,
> i.e the boards are functional without PCIe although for some users PCIe
> may be more or less critical.
> 
> As I see it we have two options:
> 
> 1. A safe option is to disable the PCIe node in the ZynqMP platform.
>We can then fix this with calm for 4.8.
>+ It will fix the dom0 boot.
>+ Very safe and unintrusive.
>- PCIe will not be functional.
> 
> 2. Apply this patch to 4.7
>+ It will fix the dom0 boot.
>+ PCIe will be functional.
>- Intrusive fix. Although the fix really only affects a case that
>  otherwise would have resulted in an aborted boot of dom0.
> 
> I'm happy to submit a patch for option nr 1 if you guys feel that's
> safer/better at this point.
> 

I'm a bit wary that this patch touches common code because the issue you
describe seems to be board specific. It's also unclear why this would
make PCIe function on ZynqMP from the commit message. 

I admit I don't know much about ARM so I will leave the further review
and judgement to ARM maintainers. I don't think OSSTest will pick up bug
in this patch FWIW.

Wei.

> Best regards,
> Edgar
> 
> ChangeLog:
> 
> v1 -> v2:
> * Rephrased comment no longer mentioning bus-bridges.
> * Fixed coding style issues.
> * Added a dt_dprintk to log skipped IRQs.
> 
> 
> Edgar E. Iglesias (1):
>   xen/device-tree: Do not remap IRQs for secondary IRQ controllers
> 
>  xen/common/device_tree.c | 16 
>  1 file changed, 16 insertions(+)
> 
> -- 
> 2.5.0
> 

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

Re: [Xen-devel] Backport requests to stable for Xen ARM

[Stefano Stabellini]

On Mon, 16 May 2016, Julien Grall wrote:
> Hello,
> 
> It has been a while without any ARM backport request. Ian Campbell
> used to keep a list of backport fixes for Xen ARM and apply them
> to stable. Now that he left, I am not sure who will do it.
> 
> I would be fine to keep the list of patches, although I am not
> a committer. Stefano do you plan to apply the backport?

I would be fine with doing that, but I am not sure who is responsible
for backporting commits to stable trees. Any committer can do that, or
do we have a set of stable maintainers? 


> I would like to request backport for the following patches:
> 
> xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2 
> commit c0516182ff86d77375c35517036535c0df61c7e1 and depends on commit 
> edd429c9cc2af99df9dda10002cc59011edf0cac
> up to Xen 4.4
> 
> xen/arm: Force broadcast of TLB and instruction cache maintenance instructions
> commit e2faa286faa36da36ee14f6bc973043013001724
> up to Xen 4.4
> 
> arm: Fix asynchronous aborts (SError exceptions) due to bogus PTE
> commit 0ebb6832f043ecfc6a3dcab8a7ba5c4070901ab7
> up to Xen 4.5
> 
> xen/arm: ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN
> commit 68778eeaa3babedba9677400f63f1e7564bba561
> up to Xen 4.6
> 
> xen/arm64: ensure that the correct SP is used for exceptions
> commit b7e5aee0a36487d6205c1633add25fd430d3b6d7
> 
> Note that whilst it would be nice to get
> "xen/arm64: correctly emulate the {w, x}zr registers" backported,
> the patch depends on lots of IO emulation rework. So I have
> not included it in the backport request.
> 
> Regards,
> 
> -- 
> Julien Grall
> 

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

Re: [Xen-devel] [PATCH v3 4/9] arm/vm_event: get/set registers

[Tamas K Lengyel]

On May 16, 2016 04:14, "Julien Grall"  wrote:
>
> Hi Tamas,
>
>
> On 04/05/16 15:51, Tamas K Lengyel wrote:
>>
>> diff --git a/xen/include/asm-arm/vm_event.h
b/xen/include/asm-arm/vm_event.h
>> index a3fc4ce..814d0da 100644
>> --- a/xen/include/asm-arm/vm_event.h
>> +++ b/xen/include/asm-arm/vm_event.h
>> @@ -48,15 +48,10 @@ void vm_event_register_write_resume(struct vcpu *v,
vm_event_response_t *rsp)
>>   /* Not supported on ARM. */
>>   }
>>
>> -static inline
>> -void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
>> -{
>> -/* Not supported on ARM. */
>> -}
>> +void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);
>>
>> -static inline void vm_event_fill_regs(vm_event_request_t *req)
>> -{
>> -/* Not supported on ARM. */
>> -}
>> +void vm_event_fill_regs(vm_event_request_t *req,
>> +const struct cpu_user_regs *regs,
>> +struct domain *d);
>>
>>   #endif /* __ASM_ARM_VM_EVENT_H__ */
>> diff --git a/xen/include/public/vm_event.h
b/xen/include/public/vm_event.h
>> index 3acf217..fabeee8 100644
>> --- a/xen/include/public/vm_event.h
>> +++ b/xen/include/public/vm_event.h
>> @@ -129,8 +129,8 @@
>>   #define VM_EVENT_X86_XCR0   3
>>
>>   /*
>> - * Using a custom struct (not hvm_hw_cpu) so as to not fill
>> - * the vm_event ring buffer too quickly.
>> + * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM
>
>
> You may want to rework this sentence as hvm_hw_cpu does not exist on
ARM/ARM64.

IMHO the point gets across even if we don't name the ARM structs
specifically.

>
>> + * so as to not fill the vm_event ring buffer too quickly.
>>*/
>>   struct vm_event_regs_x86 {
>>   uint64_t rax;
>> @@ -168,6 +168,54 @@ struct vm_event_regs_x86 {
>>   uint32_t _pad;
>>   };
>>
>> +struct vm_event_regs_arm32 {
>> +uint32_t r0_usr;
>> +uint32_t r1_usr;
>> +uint32_t r2_usr;
>> +uint32_t r3_usr;
>> +uint32_t r4_usr;
>> +uint32_t r5_usr;
>> +uint32_t r6_usr;
>> +uint32_t r7_usr;
>> +uint32_t r8_usr;
>> +uint32_t r9_usr;
>> +uint32_t r10_usr;
>> +uint32_t r12_usr;
>> +uint32_t lr_usr;
>> +uint32_t sp_usr;
>> +uint32_t sp_svc;
>> +uint32_t spsr_svc;
>> +uint32_t fp;
>> +uint32_t pc;
>> +uint32_t cpsr;
>> +uint32_t ttbr0;
>> +uint32_t ttbr1;
>> +};
>> +
>> +struct vm_event_regs_arm64 {
>> +uint64_t x0;
>> +uint64_t x1;
>> +uint64_t x2;
>> +uint64_t x3;
>> +uint64_t x4;
>> +uint64_t x5;
>> +uint64_t x6;
>> +uint64_t x7;
>> +uint64_t x8;
>> +uint64_t x9;
>> +uint64_t x10;
>> +uint64_t x16;
>> +uint64_t lr;
>> +uint64_t sp_el0;
>> +uint64_t sp_el1;
>> +uint32_t spsr_el1;
>> +uint64_t fp;
>> +uint64_t pc;
>> +uint32_t cpsr;
>> +uint64_t ttbr0;
>> +uint64_t ttbr1;
>> +};
>
>
> By defining 2 distinct structures, it will be more difficult for the
introspection tools to inspect registers of an Aarch64 domain running in
AArch32 mode. They wouldn't be able to re-use code for AArch32 domain
because the structure fields are different.
>
> The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping between
AArch32 state and AArch64 state. If you use it to define the layout of a
common structure, the support of AArch32 state for AArch64 domain will come
free.
>

If the guest is running in 32-bit mode Xen will fill the 32-bit struct, so
doing a common struct is not strictly necessary. It also requires a bunch
if union declarations to match the names between that I would prefer to
avoid. IMHO it's cleaner to do the struct definitions separately and then
do a union on top.

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

Re: [Xen-devel] [PATCH v10 1/3] vt-d: add a timeout parameter for Queued Invalidation

[Xu, Quan]

On May 13, 2016 11:28 PM, Jan Beulich  wrote:
> >>> On 22.04.16 at 12:54,  wrote:
> > --- a/docs/misc/xen-command-line.markdown
> > +++ b/docs/misc/xen-command-line.markdown
> > @@ -1532,6 +1532,16 @@ Note that if **watchdog** option is also
> specified vpmu will be turned off.
> >  As the virtualisation is not 100% safe, don't use the vpmu flag on
> > production systems (see http://xenbits.xen.org/xsa/advisory-163.html)!
> >
> > +### vtd\_qi\_timeout (VT-d)
> > +> `= `
> > +
> > +> Default: `1`
> > +
> > +Specify the timeout of the VT-d Queued Invalidation in milliseconds.
> > +
> > +By default, the timeout is 1ms. When you see error 'Queue invalidate
> > +wait descriptor timed out', try increasing this value.
> 
> So when someone enables ATS, will the 1ms timeout apply to the dev iotlb
> invalidations too?

Yes,
The timeout is the same for IOTLB, Context, IEC and Device-TLB invalidation.

> If so, that's surely too short, and would ideally be adjusted
> automatically, but the need for a higher timeout in that case should in any
> event be mentioned here.

I can try to use 1ms for IOTLB, Context and  IEC invalidation. As mentioned, 1 
ms is enough for IOTLB, Context and  IEC invalidation.
What about 10 ms for Device-TLB (10 ms is just a higher timeout,  no specific 
meaning)?

> 
> Apart from that aspect this patch seems to be ready, but will clearly need a 
> VT-
> d maintainer's ack.
> 

Thanks for your review. I will also test this patch against the last commit ( I 
am still out of office and I will do it around this Wednesday).

Quan


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

Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Stefano Stabellini]

On Mon, 16 May 2016, Boris Ostrovsky wrote:
> On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> > On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> >> On 04/27/2016 09:40 AM, David Vrabel wrote:
> >>> On 27/04/16 14:38, Boris Ostrovsky wrote:
>  int xen_nr_legacy_irqs()
>  {
>   if (xen_hvm_domain())
>   return nr_legacy_irqs();
>   if (xen_initial_domain())
>   return NR_IRQS_LEGACY;
>   return 0;
>  }
> >>> Yeah, if that does the right thing...
> >> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> >> domain explicitly. Which would be ugly.
> > I guess we all forgot about this patch, in the meantime the merge window
> > has opened.
> >
> > Should we go ahead with:
> >
> > http://marc.info/?l=linux-kernel=146115812124261=2
> >
> > ?
> > It might not be complete, but it is certainly an improvement.
> 
> Yes, I think what you have there is the best option. What I suggested
> above won't work and adding another check for HVM domain in 
> xen_allocate_irq_gsi() won't look good (although it does work).
> 
> It will need to go to stable as well (4.4+ ?)

All right, I'll commit it to for-linus-4.7 with
 Cc: sta...@vger.kernel.org

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

[Xen-devel] [xen-4.5-testing test] 94469: regressions - FAIL

[osstest service owner]

flight 94469 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94469/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt5 libvirt-build fail REGR. vs. 93989
 build-amd64-libvirt   5 libvirt-build fail REGR. vs. 93989
 build-armhf-libvirt   5 libvirt-build fail REGR. vs. 93989

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 93989
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93989
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93989
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93989
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 93989

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  1334fa937ad269e9f476fc6a69fd895f5fc99864
baseline version:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3

Last test of basis93989  2016-05-10 14:43:18 Z6 days
Testing same since94030  2016-05-11 13:08:55 Z5 days8 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 

[Xen-devel] [PATCH v2 0/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

I'm sending this as a v2 considering that I previously posted a diff
in email discussions.

This patch fixes an DT problem with the ZynqMP PCIe node.
Today, we try to remap IRQs regardless of if they are directly
connected to the primary controller or not. If they are indirectly
connected via secondary IRQ controllers, we abort the boot with
an error.

The ZynqMP PCIe DTS bindings were upstreamed to Linux after Xen 4.6, so
this issue is not a regression.
PCIe is also not generally a critical feature of current ZynqMP boards,
i.e the boards are functional without PCIe although for some users PCIe
may be more or less critical.

As I see it we have two options:

1. A safe option is to disable the PCIe node in the ZynqMP platform.
   We can then fix this with calm for 4.8.
   + It will fix the dom0 boot.
   + Very safe and unintrusive.
   - PCIe will not be functional.

2. Apply this patch to 4.7
   + It will fix the dom0 boot.
   + PCIe will be functional.
   - Intrusive fix. Although the fix really only affects a case that
 otherwise would have resulted in an aborted boot of dom0.

I'm happy to submit a patch for option nr 1 if you guys feel that's
safer/better at this point.

Best regards,
Edgar

ChangeLog:

v1 -> v2:
* Rephrased comment no longer mentioning bus-bridges.
* Fixed coding style issues.
* Added a dt_dprintk to log skipped IRQs.


Edgar E. Iglesias (1):
  xen/device-tree: Do not remap IRQs for secondary IRQ controllers

 xen/common/device_tree.c | 16 
 1 file changed, 16 insertions(+)

-- 
2.5.0


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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

To solve that, I install xen and tools in the guest, so as to access its
domain id and vcpu info to overcome the 'domain is null' error. Now the
problem is solved, but errors comes at 'domain != DOMID_SELF' checking
.
The DOMID_SELF is always 32752 (0x7FF0), while a.domain is the domid of the
guest, which induce the checking failed and exit. Any helps?

2016-05-16 17:06 GMT+08:00 Big Strong :

> Your opinion is inspiring. During the past days, I've tried to directly
> call HVMOP_altp2m_vcpu_enable_notify in guest by ioctl, this time it fails
> for "domain is null" checking.
> 
>  I
> thought it might because the guest is not able to achieve the vcpu info
> of its current state
> .
> While in dom0, this is not a problem. But dom0 is unable to
> call  HVMOP_altp2m_vcpu_enable_notify for the guest. How can I solve this
> contradiction?
>
> 2016-05-12 23:17 GMT+08:00 Wei Liu :
>
>> On Thu, May 12, 2016 at 09:00:12PM +0800, Big Strong wrote:
>> > I'm still not very clear why would do_altp2m_op change the domain to
>> > current domain (which is dom0 in my case) when the cmd is
>> > HVMOP_altp2m_vcpu_enable_notify
>> > <
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6198
>> >.
>> > As to my case, it would prevent the dom0 to set the #ve info page for
>> other
>> > domUs because the check of is_hvm_domain would fail
>> > <
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/hvm.c;hb=743289d0296268fe6bad64531a24d8053afeb062#l6204
>> >and
>> > the function will returns directly.
>> >
>>
>> Maybe the intent of that HVMOP is to get called directly by the guest
>> that is interested in such event?
>>
>> I looks like a natural restriction to me because the vcpu needs to set
>> up handler for #ve AIUI. It's not likely that Dom0 can do this for
>> arbitrary guest.
>>
>> Wei.
>>
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v2 1/1] xen/device-tree: Do not remap IRQs for secondary IRQ controllers

[Edgar E. Iglesias]

From: "Edgar E. Iglesias" 

Do not remap IRQs connected to secondary interrupt controllers.
These IRQs have no meaning to us until they connect to the
primary controller.

Secondary IRQ controllers will at some point connect to the
primary controller (possibly via other IRQ controllers). We
map the IRQs at that last connection point.

Signed-off-by: Edgar E. Iglesias 
---
 xen/common/device_tree.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 0ed86a7..02a7ede 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1176,6 +1176,22 @@ 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 )
+{
+/* We don't map IRQs connected to secondary IRQ controllers as
+ * these IRQs have no meaning to us until they connect to the
+ * primary controller.
+ *
+ * Secondary IRQ controllers will at some point connect to
+ * the primary controller (possibly via other IRQ controllers).
+ * We map the IRQs at that last connection point.
+ */
+imap += pintsize;
+imaplen -= pintsize;
+dt_dprintk(" -> Skipped IRQ for secondary IRQ controller\n");
+continue;
+}
+
 ret = dt_irq_translate(_raw_irq, _irq);
 if ( ret )
 {
-- 
2.5.0


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

Re: [Xen-devel] unable to create domain after enabling XSM

[Big Strong]

Actually I did that, but the policy is not loaded at all. 'xl list -Z' show
no lable on guests. It seems like that the option 'xsm=xen-policy-4.6.0' is
ingnored during booting. (the policy file is moved to the same directory as
xen.cfg)

2016-05-16 21:43 GMT+08:00 Konrad Rzeszutek Wilk :

> On Mon, May 16, 2016 at 10:43:49AM +0100, Andrew Cooper wrote:
> > On 16/05/16 09:54, Big Strong wrote:
> > > Problem solved by booting xen with grub instead of efi. The deep
> > > reason is unknown.
> >
> > Ah - that is very useful to know, and now obvious.  EFI has no concept
> > of modules, which probably means the XSM policy doesn't get loaded.
>
> It does. You just add in xen.cfg:
> [konrad@x230 efi]$ more xen.cfg
> [global]
> default=xtt
>
> [xtt]
> options=console=com1,vga com1=115200,8n1 loglvl=all guest_loglvl=all
> kernel=vmlinuz console=hvc0
> ramdisk=initramfs.cpio.gz
> xsm=xenpolicy
>
> The 'xsm' attribute.
> ?
> >
> > FWIW, there is a plan to change how XSM policies are done in the future,
> > by embedding the policy at build time.
> >
> > ~Andrew
>
> > ___
> > 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] [xen-unstable-smoke test] 94483: tolerable all pass - PUSHED

[osstest service owner]

flight 94483 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94483/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
baseline version:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf

Last test of basis94428  2016-05-15 16:00:58 Z0 days
Testing same since94483  2016-05-16 13:01:21 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
+ branch=xen-unstable-smoke
+ revision=ad4aa3619f436e3ed79eea8498ac18aa8d5e6b83
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xad4aa3619f436e3ed79eea8498ac18aa8d5e6b83 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] Backport requests to stable for Xen ARM

[Julien Grall]

Hello,

It has been a while without any ARM backport request. Ian Campbell
used to keep a list of backport fixes for Xen ARM and apply them
to stable. Now that he left, I am not sure who will do it.

I would be fine to keep the list of patches, although I am not
a committer. Stefano do you plan to apply the backport?

I would like to request backport for the following patches:

xen/arm: traps: Correctly interpret the content of the register HPFAR_EL2 
commit c0516182ff86d77375c35517036535c0df61c7e1 and depends on commit 
edd429c9cc2af99df9dda10002cc59011edf0cac
up to Xen 4.4

xen/arm: Force broadcast of TLB and instruction cache maintenance instructions
commit e2faa286faa36da36ee14f6bc973043013001724
up to Xen 4.4

arm: Fix asynchronous aborts (SError exceptions) due to bogus PTE
commit 0ebb6832f043ecfc6a3dcab8a7ba5c4070901ab7
up to Xen 4.5

xen/arm: ignore writes to GICD_ICACTIVER ... GICD_ICACTIVERN
commit 68778eeaa3babedba9677400f63f1e7564bba561
up to Xen 4.6

xen/arm64: ensure that the correct SP is used for exceptions
commit b7e5aee0a36487d6205c1633add25fd430d3b6d7

Note that whilst it would be nice to get
"xen/arm64: correctly emulate the {w, x}zr registers" backported,
the patch depends on lots of IO emulation rework. So I have
not included it in the backport request.

Regards,

-- 
Julien Grall

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

[Xen-devel] [for-4.7 2/2] xen/arm: p2m: Release the p2m lock before undoing the mappings

[Julien Grall]

Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.

This is done by calling recursively apply_p2m_changes, however the
second call is done with the p2m lock taken which will result in a
deadlock for the current processor.

Fix it by moving the recursive call after the lock has been released.

Signed-off-by: Julien Grall 

---
I think we could unlock the p2m lock before freeing the temporary
mapping. Although, I played safe as this is a bug fix for Xen 4.7
and to be backported up to Xen 4.5.
---
 xen/arch/arm/p2m.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 68c67b0..838d004 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1184,6 +1184,14 @@ out:
 while ( (pg = page_list_remove_head(_pages)) )
 free_domheap_page(pg);
 
+for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
+{
+if ( mappings[level] )
+unmap_domain_page(mappings[level]);
+}
+
+spin_unlock(>lock);
+
 if ( rc < 0 && ( op == INSERT || op == ALLOCATE ) &&
  addr != start_gpaddr )
 {
@@ -1196,14 +1204,6 @@ out:
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
-for ( level = P2M_ROOT_LEVEL; level < 4; level ++ )
-{
-if ( mappings[level] )
-unmap_domain_page(mappings[level]);
-}
-
-spin_unlock(>lock);
-
 return rc;
 }
 
-- 
1.9.1


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

[Xen-devel] [for-4.7 0/2] xen/arm: Bug fixes in the P2M code

[Julien Grall]

Hello,

This small series fixes potential deadlock and the removal of unrelated
mapping when the P2M code fails to insert/allocate mappings.

This series contains bug fix for Xen 4.7 and candidate for backporting
up to Xen 4.5.

Yours sincerely,

Julien Grall (2):
  xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary
  xen/arm: p2m: Release the p2m lock before undoing the mappings

 xen/arch/arm/p2m.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

-- 
1.9.1


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

[Xen-devel] [for-4.7 1/2] xen/arm: p2m: apply_p2m_changes: Do not undo more than necessary

[Julien Grall]

Since commit 4b25423a "arch/arm: unmap partially-mapped memory regions",
Xen has been undoing the P2M mappings when an error occurred during
insertion or memory allocation.

The function apply_p2m_changes can work with region not-aligned to a
block size (2MB, 1G) or page size (4K). The mapping will be done by
splitting the region in a set of regions aligned to the size supported
by the page table.

The mapping of a region could fail when it is not possible to allocate
memory for an intermediate table (i.e a new or when shattering a block).

When the mapping is undone, the end of the region is computed using the
base address of the current region and the size of the failing level.
However the failing level may not be the leaf one, therefore unrelated
entries will be removed.

Fix it by removing the mapping from the start address up to the last
region that has been successfully mapped.

Signed-off-by: Julien Grall 

---
This patch is a bug fix for Xen 4.7 and candidate for backporting
up to Xen 4.5. Without this patch, Xen may undo mapping which are
not part of the region mapped when memory allocation has failed.

Note that Xen 4.7 has code to remove empty translation table (see
commit de5162b "xen/arm: p2m: Remove translation table when it's
empty"), however with this patch those tables will not be removed
in case of failure. This will be fixed after the release as
the change will be too intrusive for Xen 4.7.
---
 xen/arch/arm/p2m.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index db21433..68c67b0 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -1189,13 +1189,10 @@ out:
 {
 BUG_ON(addr == end_gpaddr);
 /*
- * addr keeps the address of the last successfully-inserted mapping,
- * while apply_p2m_changes() considers an address range which is
- * exclusive of end_gpaddr: add level_size to addr to obtain the
- * right end of the range
+ * addr keeps the address of the end of the last successfully-inserted
+ * mapping.
  */
-apply_p2m_changes(d, REMOVE,
-  start_gpaddr, addr + level_sizes[level], orig_maddr,
+apply_p2m_changes(d, REMOVE, start_gpaddr, addr, orig_maddr,
   mattr, 0, p2m_invalid, d->arch.p2m.default_access);
 }
 
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Boris Ostrovsky]

On 05/16/2016 07:23 AM, Stefano Stabellini wrote:
> On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
>> On 04/27/2016 09:40 AM, David Vrabel wrote:
>>> On 27/04/16 14:38, Boris Ostrovsky wrote:
 int xen_nr_legacy_irqs()
 {
  if (xen_hvm_domain())
  return nr_legacy_irqs();
  if (xen_initial_domain())
  return NR_IRQS_LEGACY;
  return 0;
 }
>>> Yeah, if that does the right thing...
>> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
>> domain explicitly. Which would be ugly.
> I guess we all forgot about this patch, in the meantime the merge window
> has opened.
>
> Should we go ahead with:
>
> http://marc.info/?l=linux-kernel=146115812124261=2
>
> ?
> It might not be complete, but it is certainly an improvement.

Yes, I think what you have there is the best option. What I suggested
above won't work and adding another check for HVM domain in 
xen_allocate_irq_gsi() won't look good (although it does work).

It will need to go to stable as well (4.4+ ?)

-boris

>
> Otherwise, please submit proper patches ASAP. I don't think we want to
> delay this fix until 4.8.


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

Re: [Xen-devel] [RFC 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

[Julien Grall]

Hi Konrad,

On 16/05/16 14:50, Konrad Rzeszutek Wilk wrote:

On Sat, May 14, 2016 at 07:04:19PM +0100, Julien Grall wrote:

Hi Konrad,

On 13/05/2016 21:37, Konrad Rzeszutek Wilk wrote:

diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
index 7a1b56b..aa7c5b1 100644
--- a/xen/arch/arm/cpufeature.c
+++ b/xen/arch/arm/cpufeature.c
@@ -24,6 +24,22 @@

  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);

+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
+ const char *info)
+{
+int i;
+
+for ( i = 0; caps[i].matches; i++ )
+{
+if ( !caps[i].matches([i]) )
+continue;
+
+if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
+printk("%s: %s\n", info, caps[i].desc);


dprintk?


No, this message is useful to know the list of "features" available for the
platform.


What about level? INFO?


INFO would be fine. I keep forgetting that the default is WARNING.

I will fix it in the next version.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC 11/16] xen/arm: Detect silicon revision and set cap bits accordingly

[Konrad Rzeszutek Wilk]

On Sat, May 14, 2016 at 07:04:19PM +0100, Julien Grall wrote:
> Hi Konrad,
> 
> On 13/05/2016 21:37, Konrad Rzeszutek Wilk wrote:
> >>diff --git a/xen/arch/arm/cpufeature.c b/xen/arch/arm/cpufeature.c
> >>index 7a1b56b..aa7c5b1 100644
> >>--- a/xen/arch/arm/cpufeature.c
> >>+++ b/xen/arch/arm/cpufeature.c
> >>@@ -24,6 +24,22 @@
> >>
> >>  DECLARE_BITMAP(cpu_hwcaps, ARM_NCAPS);
> >>
> >>+void update_cpu_capabilities(const struct arm_cpu_capabilities *caps,
> >>+ const char *info)
> >>+{
> >>+int i;
> >>+
> >>+for ( i = 0; caps[i].matches; i++ )
> >>+{
> >>+if ( !caps[i].matches([i]) )
> >>+continue;
> >>+
> >>+if ( !cpus_have_cap(caps[i].capability) && caps[i].desc )
> >>+printk("%s: %s\n", info, caps[i].desc);
> >
> >dprintk?
> 
> No, this message is useful to know the list of "features" available for the
> platform.

What about level? INFO?
> 
> Regards,
> 
> -- 
> Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://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] unable to create domain after enabling XSM

[Konrad Rzeszutek Wilk]

On Mon, May 16, 2016 at 10:43:49AM +0100, Andrew Cooper wrote:
> On 16/05/16 09:54, Big Strong wrote:
> > Problem solved by booting xen with grub instead of efi. The deep
> > reason is unknown.
> 
> Ah - that is very useful to know, and now obvious.  EFI has no concept
> of modules, which probably means the XSM policy doesn't get loaded.

It does. You just add in xen.cfg:
[konrad@x230 efi]$ more xen.cfg 
[global]
default=xtt

[xtt]
options=console=com1,vga com1=115200,8n1 loglvl=all guest_loglvl=all
kernel=vmlinuz console=hvc0
ramdisk=initramfs.cpio.gz
xsm=xenpolicy

The 'xsm' attribute.
?
> 
> FWIW, there is a plan to change how XSM policies are done in the future,
> by embedding the policy at build time.
> 
> ~Andrew

> ___
> 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

[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] Problem Reading from XenStore in DomU

[Dagaen Golomb]

Regards,
Dagaen Golomb
On May 16, 2016 09:13, "Jonathan Creekmore" 
wrote:
>
>
> Dagaen Golomb writes:
>
> > It does, being the custom kernel on version 4.1.0. But Dom0 uses this
same
> > exact kernel and reads/writes just fine! The only solution if this is
> > indeed the problem appears to be changing the kernel source we build on
or
> > some hacky method such as symlinking /proc/.. to /dev/.., there has to
be
> > an elegant real solution to this...
>
> When I was chasing down a similar problem back in August, I discovered
> that Dom0 accesses XenStore through a unix domain socket and not through
> the kernel interface, so hitting it through xenstore-ls always seemed to
> work. That is why Dom0 reads/writes to XenStore ok with the same kernel
> that fails for your DomU. When I moved XenStore to a stubdomain, I /did/
> see the problem in Dom0 with new enough kernels, which is why the
> XenStore access library was changed to prefer the dev device instead of
> the proc file.

Great, I'll try out the XENSTORED_PATH variable when I get the chance and
see if it resolves the issue.

Regards,
Dagaen Golomb

Regards,
Dagaen Golomb
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Problem Reading from XenStore in DomU

[Jonathan Creekmore]

Dagaen Golomb writes:

> It does, being the custom kernel on version 4.1.0. But Dom0 uses this same
> exact kernel and reads/writes just fine! The only solution if this is
> indeed the problem appears to be changing the kernel source we build on or
> some hacky method such as symlinking /proc/.. to /dev/.., there has to be
> an elegant real solution to this...

When I was chasing down a similar problem back in August, I discovered
that Dom0 accesses XenStore through a unix domain socket and not through
the kernel interface, so hitting it through xenstore-ls always seemed to
work. That is why Dom0 reads/writes to XenStore ok with the same kernel
that fails for your DomU. When I moved XenStore to a stubdomain, I /did/
see the problem in Dom0 with new enough kernels, which is why the
XenStore access library was changed to prefer the dev device instead of
the proc file.

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

[Xen-devel] [xen-unstable test] 94461: tolerable FAIL - PUSHED

[osstest service owner]

flight 94461 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94461/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 94442 pass in 
94461
 test-amd64-i386-qemuu-rhel6hvm-intel 9 redhat-install fail in 94442 pass in 
94461
 test-armhf-armhf-libvirt 7 host-ping-check-xen fail in 94442 pass in 94461
 test-armhf-armhf-xl-multivcpu  9 debian-installfail in 94442 pass in 94461
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 94442
 test-armhf-armhf-libvirt-xsm  4 host-ping-check-native  fail pass in 94442
 test-armhf-armhf-xl-arndale  15 guest-start/debian.repeat   fail pass in 94442
 test-armhf-armhf-xl-vhd   6 xen-bootfail pass in 94442

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 94368
 build-amd64-rumpuserxen   6 xen-buildfail   like 94368
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 94368
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 94368
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 94368
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 94368
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 94368

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 94442 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 94442 never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-check fail in 94442 never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-check fail in 94442 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass

version targeted for testing:
 xen  fcab4cec98ae1f56312744c19f608856261b20cf
baseline version:
 xen  4f6aea066fe2cf3bf4929d6dac1e558071566f73

Last test of basis94368  2016-05-15 05:56:52 Z1 days
Testing same since94442  2016-05-15 18:46:42 Z0 days2 attempts


People who touched revisions under test:
  Jim Fehlig 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm

[Xen-devel] [ovmf test] 94470: regressions - FAIL

[osstest service owner]

flight 94470 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94470/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-xsm5 xen-build fail REGR. vs. 65543
 build-amd64   5 xen-build fail REGR. vs. 65543
 build-amd64-xsm   5 xen-build fail REGR. vs. 65543
 build-i3865 xen-build fail REGR. vs. 65543

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a

version targeted for testing:
 ovmf bfba88bc68eed24c71ff500b740c3f563531d49c
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  160 days
Failing since 65593  2015-12-08 23:44:51 Z  159 days  267 attempts
Testing same since94464  2016-05-16 04:05:08 Z0 days2 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Maurice Ma 
  Michael Brown 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann <[mailto:sigmaepsilo...@gmail.com]>
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 

Re: [Xen-devel] potential problem with qdisk backend

[Stefano Stabellini]

On Wed, 11 May 2016, Juergen Gross wrote:
> On 06/05/16 13:41, Juergen Gross wrote:
> > Looking at the qdisk backend implementation I wondered whether
> > blkif_get_x86_32_req() is really correct, especially for the
> > BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
> > distinguish 32- and 64-bit layouts of blkif_request_discard while
> > qemu treats them to be the same.
> > 
> > Am I completely wrong here?
> 
> Adding some maintainers.
 
Yes, it seems to me that the internal alignment of the fields in struct
blkif_request_discard (as declared by xen/include/public/io/blkif.h)
differs between x86_32 and x86_64. The two different alignments are both
specified explicitly in Linux, by using __packed__ and explicit
padding.

On the other hand QEMU uses Xen's declaration of struct
blkif_request_discard without paying attention to the word size in the
guest. As a consequence it will work correctly only if the guest bitness
and the dom0 bitness match.

The discard struct should have two implementations in QEMU, like
blkif_x86_32_request and blkif_x86_64_request.

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

Re: [Xen-devel] [BUG] Linux process vruntime accounting in Xen

[Dario Faggioli]

[Adding George again, and a few Linux/Xen folks]

On Sat, 2016-05-14 at 18:25 -0600, Tony S wrote:
> In virtualized environments, sometimes we need to limit the CPU
> resources to a virtual machine(VM). For example in Xen, we use
> $ xl sched-credit -d 1 -c 50
> 
> to limit the CPU resource of dom 1 as half of
> one physical CPU core. If the VM CPU resource is capped, the process
> inside the VM will have a vruntime accounting problem. Here, I report
> my findings about Linux process scheduler under the above scenario.
> 
Thanks for this other report as well. :-)

All you say makes sense to me, and I will think about it. I'm not sure
about one thing, though...

> Description
> Linux CFS relies on delta_exec to charge the vruntime of processes.
> The variable delta_exec is the difference of a process starts and
> stops running on a CPU. This works well in physical machine. However,
> in virtual machine under capped resources, some processes might be
> accounted with inaccurate vruntime.
> 
> For example, suppose we have a VM which has one vCPU and is capped to
> have as much as 50% of a physical CPU. When process A inside the VM
> starts running and the CPU resource of that VM runs out, the VM will
> be paused. Next round when the VM is allocated new CPU resource and
> starts running again, process A stops running and is put back to the
> runqueue. The delta_exec of process A is accounted as its "real
> execution time" plus the paused time of its VM. That will make the
> vruntime of process A much larger than it should be and process A
> would not be scheduled again for a long time until the vruntimes of
> other
> processes catch it.
> ---
> 
> 
> Analysis
> When a process stops running and is going to put back to the
> runqueue,
> update_curr() will be executed.
> [src/kernel/sched/fair.c]
> 
> static void update_curr(struct cfs_rq *cfs_rq)
> {
> ... ...
> delta_exec = now - curr->exec_start;
> ... ...
> curr->exec_start = now;
> ... ...
> curr->sum_exec_runtime += delta_exec;
> schedstat_add(cfs_rq, exec_clock, delta_exec);
> curr->vruntime += calc_delta_fair(delta_exec, curr);
> update_min_vruntime(cfs_rq);
> ... ...
> }
> 
> "now" --> the right now time
> "exec_start" --> the time when the current process is put on the CPU
> "delta_exec" --> the time difference of a process between it starts
> and stops running on the CPU
> 
> When a process starts running before its VM is paused and the process
> stops running after its VM is unpaused, the delta_exec will include
> the VM suspend time which is pretty large compared to the real
> execution time of a process.
> 
... but would that also apply to a VM that is not scheduled --just
because of pCPU contention, not because it was paused-- for a few time?

Isn't there anything in place in Xen or Linux (the latter being better
suitable for something like this, IMHO) to compensate for that?

I have to admit I haven't really ever checked myself, maybe either
George or our Linux people do know more?

> This issue will make a great performance harm to the victim process.
> If the process is an I/O-bound workload, its throughput and latency
> will be influenced. If the process is a CPU-bound workload, this
> issue
> will make its vruntime "unfair" compared to other processes under
> CFS.
> 
> Because the CPU resource of some type VMs in the cloud are limited as
> the above describes(like Amazon EC2 t2.small instance), I doubt that
> will also harm the performance of public cloud instances.
> ---
> 
> 
> My test environment is as follows: Hypervisor(Xen 4.5.0), Dom 0(Linux
> 3.18.21), Dom U(Linux 3.18.21). I also test longterm version Linux
> 3.18.30 and the latest longterm version, Linux 4.4.7. Those kernels
> all have this issue.
> 
> Please confirm this bug. Thanks.
> 
> 
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)



signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] Question about running Xen on NVIDIA Jetson-TK1

[Julien Grall]

On 15/05/16 20:35, Meng Xu wrote:

Hi Julien and Ian,


Hello Meng,



I'm trying to run Xen on NVIDIA Jetson TK1 board. (Right now, Xen does
not support the Jetson board officially. But I'm thinking it may be
very interesting and useful to see it happens, since it has GPU inside
which is quite popular in automotive.)

Now I encountered some problem to boot dom0 in Xen environment. I want
to debug the issues and maybe fix the issues, but I'm not so sure how
I should debug the issue more efficiently. I really appreciate it if
you advise me a little bit about the method of how to fix the issue.
:-)

---Below is the details

I noticed the Dushyant from IBM also tried to run Xen on the Jetson
board. (http://www.gossamer-threads.com/lists/xen/devel/422519). I
used the same Linux kernel (Jan Kiszka's development tree -
http://git.kiszka.org/linux.git/, branch queues/assorted) and Ian's
Xen repo. with the hack for Jetson board. I can see the dom0 kernel
can boot to some extend and then "stall/spin" before the dom0 kernel
fully boot up.

In order to figure out the possible issue, I boot the exact same Linux
kernel in native environment on one CPU and collected the boot log
information in [1]. I also boot the same Linux kernel as dom0 in Xen
environment and collected the boot log information in [2].

In Xen environment, dom0 hangs after the following message
[   10.541010] NET: Registered protocol family 10
6mip6: Mobile IPv6
[   10.542510] mi

In native environment, the kernel has the following log after initializing NET.
[2.934693] NET: Registered protocol family 10
[2.940611] mip6: Mobile IPv6
[2.943645] sit: IPv6 over IPv4 tunneling driver
[2.951303] NET: Registered protocol family 17
[2.955800] NET: Registered protocol family 15
[2.960257] can: controller area network core (rev 20120528 abi 9)
[2.966617] NET: Registered protocol family 29
[2.971098] can: raw protocol (rev 20120528)
[2.975384] can: broadcast manager protocol (rev 20120528 t)
[2.981088] can: netlink gateway (rev 20130117) max_hops=1
[2.986734] Bluetooth: RFCOMM socket layer initialized
[2.991979] Bluetooth: RFCOMM ver 1.11
[2.995757] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[3.001109] Bluetooth: BNEP socket layer initialized
[3.006089] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[3.012052] Bluetooth: HIDP socket layer initialized
[3.017894] Registering SWP/SWPB emulation handler
[3.029675] tegra-pcie 1003000.pcie-controller: 2x1, 1x1 configuration
[3.036586] +3.3V_SYS: supplied by +VDD_MUX
[3.040857] +3.3V_LP0: supplied by +3.3V_SYS
[3.045509] +1.35V_LP0(sd2): supplied by +5V_SYS
[3.050201] +1.05V_RUN_AVDD: supplied by +1.35V_LP0(sd2)
[3.057131] tegra-pcie 1003000.pcie-controller: probing port 0, using 2 lanes
[3.066479] tegra-pcie 1003000.pcie-controller: Slot present pin
change, signature: 0008

I'm suspecting that my dom0 kernel hangs when it tries to initialize
"can: controller area network core ". However, from Dushyant's post at
http://www.gossamer-threads.com/lists/xen/devel/422519,  it seems
Dushyant's dom0 kernel hangs when it tries to initialize pci_bus. (The
linux config I used may be different form Dushyant's. That could be
the reason.)

Right now, the system just hangs and has no output indicating what the
problem could be. Although there are a lot of error message before the
system hangs, I'm not that sure if I should start with solving all of
those error messages. Maybe some errors can be ignored?

My questions are:
1) Do you have suggestion on how to see more information about the
reason why the dom0 hangs?


Have you tried to dump the registers using Xen console (CTLR-x 3 times 
then 0) and see where it get stucks?


Regards,

--
Julien Grall

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

Re: [Xen-devel] [BUG] Bugs existing Xen's credit scheduler cause long tail latency issues

[Dario Faggioli]

[Adding George, and avoiding trimming, for his benefit]

On Sat, 2016-05-14 at 22:11 -0600, Tony S wrote:
> Hi all,
> 
Hi Tony,

> When I was running latency-sensitive applications in VMs on Xen, I
> found some bugs in the credit scheduler which will cause long tail
> latency in I/O-intensive VMs.
> 
Ok, first of all, thanks for looking into and reporting this.

This is certainly something we need to think about... For now, just a
couple of questions.

> (1) Problem description
> 
> Description
> My test environment is as follows: Hypervisor(Xen 4.5.0), Dom 0(Linux
> 3.18.21), Dom U(Linux 3.18.21).
> 
> Environment setup:
> We created two 1-vCPU, 4GB-memory VMs and pinned them onto one
> physical CPU core. One VM(denoted as I/O-VM) ran Sockperf server
> program; the other VM ran a compute-bound task, e.g., SPECCPU 2006 or
> simply a loop(denoted as CPU-VM). A client on another physical
> machine
> sent UDP requests to the I/O-VM.
> 
So, just to be sure I've understood, you have 2 VMs, each with 1 vCPU,
*both* pinned on the *same* pCPU, is this the case?

> Here are my tail latency results (micro-second):
> Case   Avg  90%   99%99.9%  99.99%
> #1 108   &  114&  128 &  129 &  130
> #2 7811  &  13892  &  14874   &  15315   &  16383
> #3 943   &  131&  21755   &  26453   &  26553
> #4 116   &  96 &  105 &  8217&  13472
> #5 116   &  117&  129 &  131 &  132
> 
> Bug 1, 2, and 3 will be discussed below.
> 
> Case #1:
> I/O-VM was processing Sockperf requests from clients; CPU-VM was
> idling (no processes running).
> 
> Case #2:
> I/O-VM was processing Sockperf requests from clients; CPU-VM was
> running a compute-bound task.
> Hypervisor is the native Xen 4.5.0
> 
> Case #3:
> I/O-VM was processing Sockperf requests from clients; CPU-VM was
> running a compute-bound task.
> Hypervisor is the native Xen 4.5.0 with bug 1 fixed
> 
> Case #4:
> I/O-VM was processing Sockperf requests from clients; CPU-VM was
> running a compute-bound task.
> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 fixed
> 
> Case #5:
> I/O-VM was processing Sockperf requests from clients; CPU-VM was
> running a compute-bound task.
> Hypervisor is the native Xen 4.5.0 with bug 1 & 2 & 3 fixed
> 
> ---
> 
> 
> (2) Problem analysis
> 
> Analysis
> 
> [Bug1]: The VCPU that ran CPU-intensive workload could be mistakenly
> boosted due to CPU affinity.
> 
> http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02853.
> html
> 
> We have already discussed this bug and a potential patch in the above
> link. Although the discussed patch improved the tail latency, i.e.,
> reducing the 90th percentile latency, the long tail latency is till
> not bounded. Next, we discussed two new bugs that inflict latency
> hike
> at the very far end of the tail.
> 
Right, and there is a fix upstream for this. It's not the patch you
proposed in the thread linked above, but it should have had the same
effect.

Can you perhaps try something more recent thatn 4.5 (4.7-rc would be
great) and confirm that the number still look similar?

About this below here, I'll read carefully and think about it. Thanks
again.

> [Bug2]: In csched_acct() (by default every 30ms), a VCPU stops
> earning
> credits and is removed from the active CPU list(in
> __csched_vcpu_acct_stop_locked) if its credit is larger than the
> upper
> bound. Because the domain has only one VCPU and the VM will also be
> removed from the active domain list.
> 
> Every 10ms, csched_tick() --> csched_vcpu_acct() -->
> __csched_vcpu_acct_start() will be executed and tries to put inactive
> VCPUs back to the active list. However, __csched_vcpu_acct_start()
> will only put the current VCPU back to the active list. If an
> I/O-bound VCPU is not the current VCPU at the csched_tick(), it will
> not be put back to the active VCPU list. If so, the I/O-bound VCPU
> will likely miss the next credit refill in csched_acct() and can
> easily enter the OVER state. As such, the I/O-bound VM will be unable
> to be boosted and have very long latency. It takes at least one time
> slice (e.g., 30ms) before the I/O VM is activated and starts to
> receive credits.
> 
> [Possible Solution] Try to activate any inactive VCPUs back to active
> before next credit refill, instead of just the current VCPU.
> 
> 
> 
> [Bug 3]: The BOOST priority might be changed to UNDER before the
> boosted VCPU preempts the current running VCPU. If so, VCPU boosting
> can not take effect.
> 
> If a VCPU is in UNDER state and wakes up from sleep, it will be
> boosted in csched_vcpu_wake(). However, the boosting is successful
> only when __runq_tickle() preempts the current VCPU. It is possible
> that csched_acct() can run between csched_vcpu_wake() and
> __runq_tickle(), which will sometimes change the BOOST state back to
> UNDER if credit >0. If so, __runq_tickle() can fail as 

[Xen-devel] [libvirt test] 94465: tolerable FAIL - PUSHED

[osstest service owner]

flight 94465 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94465/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 libvirt  4b3a46ca6a8e836b75801bd27198c28cfe33f698
baseline version:
 libvirt  9055faebd426b44ad2c3bb97d6b8b0dd3496ab35

Last test of basis94142  2016-05-14 04:22:47 Z2 days
Testing same since94338  2016-05-15 04:20:41 Z1 days2 attempts


People who touched revisions under test:
  Michal Privoznik 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

+ branch=libvirt
+ revision=4b3a46ca6a8e836b75801bd27198c28cfe33f698
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt 
4b3a46ca6a8e836b75801bd27198c28cfe33f698
+ branch=libvirt
+ 

Re: [Xen-devel] [PATCH v4 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Julien Grall]

Hi Fu Wei,

(CC Stefano)

On 10/05/16 15:03, fu@linaro.org wrote:

From: Fu Wei 

delete: xen_linux, xen_initrd, xen_xsm
add: xen_module

This update bases on
 commit 0edd750e50698854068358ea53528100a9192902
 Author: Vladimir Serbinenko 
 Date:   Fri Jan 22 10:18:47 2016 +0100

 xen_boot: Remove obsolete module type distinctions.

Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.

Signed-off-by: Fu Wei 
---
  docs/grub.texi | 33 ++---
  1 file changed, 10 insertions(+), 23 deletions(-)

diff --git a/docs/grub.texi b/docs/grub.texi
index 82f6fa4..df6018a 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
@command{help}
  * videoinfo::   List available video modes
  @comment * xen_*::  Xen boot commands
  * xen_hypervisor::  Load xen hypervisor binary
-* xen_linux::   Load dom0 kernel for xen hypervisor
-* xen_initrd::  Load dom0 initrd for dom0 kernel
-* xen_xsm:: Load xen security module for xen hypervisor
+* xen_module::  Load xen modules for xen hypervisor
  @end menu


@@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any other 
binaries must be
  reloaded after using this command.
  @end deffn

-@node xen_linux
-@subsection xen_linux
+@node xen_module
+@subsection xen_module

-@deffn Command xen_linux file [arguments]
-Load a dom0 kernel image for xen hypervisor at the booting process of xen.
+@deffn Command xen_module [--nounzip] file [arguments]
+Load a module for xen hypervisor at the booting process of xen.
  The rest of the line is passed verbatim as the module command line.
+Modules should be loaded in the following order:
+The 1st module: dom0 kernel image
+The 2nd module: dom0 ramdisk (optional, if the ramdisk is present, it must
+always be the second module)
+If the XSM is present, it can be loaded at any time after the 1st module.


I find the instruction confusing. You wrote that XSM can be loaded any 
time after the 1st module, but just before you wrote that ramdisk should 
always be the first one.


What about:
"Modules should be loaded in the following order:
 - dom0 kernel image
 - dom0 ramdisk if present
 - XSM policy if present"

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] xen/x86: actually allocate legacy interrupts on PV guests

[Stefano Stabellini]

On Wed, 27 Apr 2016, Boris Ostrovsky wrote:
> On 04/27/2016 09:40 AM, David Vrabel wrote:
> > On 27/04/16 14:38, Boris Ostrovsky wrote:
> > > int xen_nr_legacy_irqs()
> > > {
> > >  if (xen_hvm_domain())
> > >  return nr_legacy_irqs();
> > >  if (xen_initial_domain())
> > >  return NR_IRQS_LEGACY;
> > >  return 0;
> > > }
> > Yeah, if that does the right thing...
> 
> I think it will break xen_allocate_irq_gsi() again, unless we check for HVM
> domain explicitly. Which would be ugly.

I guess we all forgot about this patch, in the meantime the merge window
has opened.

Should we go ahead with:

http://marc.info/?l=linux-kernel=146115812124261=2

?
It might not be complete, but it is certainly an improvement.

Otherwise, please submit proper patches ASAP. I don't think we want to
delay this fix until 4.8.

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

[Xen-devel] [qemu-upstream-4.3-testing test] 94472: trouble: blocked/broken

[osstest service owner]

flight 94472 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94472/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   99 days
Testing same since93977  2016-05-10 11:09:16 Z6 days   14 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Stefano Stabellini]

On Wed, 11 May 2016, Arnd Bergmann wrote:
> A bugfix patch for the xen balloon driver introduced a forward
> declaration for a static function that is conditionally compiled,
> causing a warning if only the declaration but not the definition
> are there:
> 
> drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
> 'static' but never defined [-Werror=unused-function]
>  static void release_memory_resource(struct resource *resource);
> 
> This removes the declaration again and instead moves the function
> definition to the right place, before its first caller and inside
> of the #ifdef protecting both.
> 
> The patch that introduced the warning is marked for stable
> backports, so if that gets applied to 4.4, so should this one.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit 
> PAE")
> Cc: sta...@vger.kernel.org

Reviewed-by: Stefano Stabellini 


>  drivers/xen/balloon.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index d46839f51e73..e4db19e88ab1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -151,8 +151,6 @@ static DECLARE_WAIT_QUEUE_HEAD(balloon_wq);
>  static void balloon_process(struct work_struct *work);
>  static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
>  
> -static void release_memory_resource(struct resource *resource);
> -
>  /* When ballooning out (allocating memory to return to Xen) we don't really
> want the kernel to try too hard since that can trigger the oom killer. */
>  #define GFP_BALLOON \
> @@ -248,6 +246,19 @@ static enum bp_state update_schedule(enum bp_state state)
>  }
>  
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
> +static void release_memory_resource(struct resource *resource)
> +{
> + if (!resource)
> + return;
> +
> + /*
> +  * No need to reset region to identity mapped since we now
> +  * know that no I/O can be in this region
> +  */
> + release_resource(resource);
> + kfree(resource);
> +}
> +
>  static struct resource *additional_memory_resource(phys_addr_t size)
>  {
>   struct resource *res;
> @@ -286,19 +297,6 @@ static struct resource 
> *additional_memory_resource(phys_addr_t size)
>   return res;
>  }
>  
> -static void release_memory_resource(struct resource *resource)
> -{
> - if (!resource)
> - return;
> -
> - /*
> -  * No need to reset region to identity mapped since we now
> -  * know that no I/O can be in this region
> -  */
> - release_resource(resource);
> - kfree(resource);
> -}
> -
>  static enum bp_state reserve_additional_memory(void)
>  {
>   long credit;
> -- 
> 2.7.0
> 

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

Re: [Xen-devel] [PATCH] Xen: don't warn about 2-byte wchar_t in efi

[Stefano Stabellini]

On Wed, 11 May 2016, Arnd Bergmann wrote:
> The XEN UEFI code has become available on the ARM architecture
> recently, but now causes a link-time warning:
> 
> ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 
> 4-byte wchar_t; use of wchar_t values across objects may fail
> 
> This seems harmless, because the efi code only uses 2-byte
> characters when interacting with EFI, so we don't pass on those
> strings to elsewhere in the system, and we just need to
> silence the warning.
> 
> It is not clear to me whether we actually need to build the file
> with the -fshort-wchar flag, but if we do, then we should also
> pass --no-wchar-size-warning to the linker, to avoid the warning.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific 
> UEFI runtime services")

Given that drivers/xen/efi.c doesn't actually use any wchar_t, it is not
clear to me whether we need to pass -fshort-wchar either. However this
patch is correct any, so I committed it to xentip.


>  drivers/xen/Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
> index 415f2869054b..8feab810aed9 100644
> --- a/drivers/xen/Makefile
> +++ b/drivers/xen/Makefile
> @@ -8,6 +8,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
>  CFLAGS_features.o:= $(nostackp)
>  
>  CFLAGS_efi.o += -fshort-wchar
> +LDFLAGS  += $(call ld-option, 
> --no-wchar-size-warning)
>  
>  dom0-$(CONFIG_ARM64) += arm-device.o
>  dom0-$(CONFIG_PCI) += pci.o
> -- 
> 2.7.0
> 

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

Re: [Xen-devel] [PATCH for-4.7] x86/compat: Cleanup and further debugging of SMAP/SMEP fixup

[Wei Liu]

On Mon, May 16, 2016 at 11:49:31AM +0100, Andrew Cooper wrote:
>  * Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid
>opencoding the invidial bits which are fixed up behind a 32bit PV guests
>back.
>  * In the debug case, perform the the AND and CMP on 64bit values rather than
>32bit values, to match the logic in then non-debug case.
>  * Show cr4_pv32_mask in the BUG register dump
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 

> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> ---
>  xen/arch/x86/setup.c   | 2 +-
>  xen/arch/x86/x86_64/compat/entry.S | 8 +---
>  xen/include/asm-x86/processor.h| 2 ++
>  3 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
> index 4c2d01a..de682e7 100644
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -1400,7 +1400,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
>  if ( cpu_has_smap )
>  set_in_cr4(X86_CR4_SMAP);
>  
> -cr4_pv32_mask = mmu_cr4_features & (X86_CR4_SMEP | X86_CR4_SMAP);
> +cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
>  
>  if ( cpu_has_fsgsbase )
>  set_in_cr4(X86_CR4_FSGSBASE);
> diff --git a/xen/arch/x86/x86_64/compat/entry.S 
> b/xen/arch/x86/x86_64/compat/entry.S
> index dbc3984..ee72ece 100644
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -204,7 +204,7 @@ ENTRY(cr4_pv32_restore)
>  push  %rdx
>  GET_CPUINFO_FIELD(cr4, dx)
>  mov   (%rdx), %rax
> -test  $X86_CR4_SMEP|X86_CR4_SMAP,%eax
> +test  $XEN_CR4_PV32_BITS, %eax
>  jnz   0f
>  orcr4_pv32_mask(%rip), %rax
>  mov   %rax, %cr4
> @@ -215,9 +215,11 @@ ENTRY(cr4_pv32_restore)
>  #ifndef NDEBUG
>  /* Check that _all_ of the bits intended to be set actually are. */
>  mov   %cr4, %rax
> -and   cr4_pv32_mask(%rip), %eax
> -cmp   cr4_pv32_mask(%rip), %eax
> +and   cr4_pv32_mask(%rip), %rax
> +cmp   cr4_pv32_mask(%rip), %rax
>  je1f
> +/* Cause cr4_pv32_mask to be visible in the BUG register dump. */
> +mov   cr4_pv32_mask(%rip), %rdx
>  BUG
>  1:
>  #endif
> diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
> index 4a6af0f..ddaaf2de 100644
> --- a/xen/include/asm-x86/processor.h
> +++ b/xen/include/asm-x86/processor.h
> @@ -151,6 +151,8 @@
>  
>  #define XEN_MINIMAL_CR4 (X86_CR4_PGE | X86_CR4_PAE)
>  
> +#define XEN_CR4_PV32_BITS (X86_CR4_SMEP|X86_CR4_SMAP)
> +
>  #define XEN_SYSCALL_MASK (X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\
>X86_EFLAGS_NT|X86_EFLAGS_DF|X86_EFLAGS_IF|\
>X86_EFLAGS_TF)
> -- 
> 2.1.4
> 

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

[Xen-devel] [PATCH for-4.7] x86/compat: Cleanup and further debugging of SMAP/SMEP fixup

[Andrew Cooper]

 * Abstract (X86_CR4_SMEP | X86_CR4_SMAP) behind XEN_CR4_PV32_BITS to avoid
   opencoding the invidial bits which are fixed up behind a 32bit PV guests
   back.
 * In the debug case, perform the the AND and CMP on 64bit values rather than
   32bit values, to match the logic in then non-debug case.
 * Show cr4_pv32_mask in the BUG register dump

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
---
 xen/arch/x86/setup.c   | 2 +-
 xen/arch/x86/x86_64/compat/entry.S | 8 +---
 xen/include/asm-x86/processor.h| 2 ++
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 4c2d01a..de682e7 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -1400,7 +1400,7 @@ void __init noreturn __start_xen(unsigned long mbi_p)
 if ( cpu_has_smap )
 set_in_cr4(X86_CR4_SMAP);
 
-cr4_pv32_mask = mmu_cr4_features & (X86_CR4_SMEP | X86_CR4_SMAP);
+cr4_pv32_mask = mmu_cr4_features & XEN_CR4_PV32_BITS;
 
 if ( cpu_has_fsgsbase )
 set_in_cr4(X86_CR4_FSGSBASE);
diff --git a/xen/arch/x86/x86_64/compat/entry.S 
b/xen/arch/x86/x86_64/compat/entry.S
index dbc3984..ee72ece 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -204,7 +204,7 @@ ENTRY(cr4_pv32_restore)
 push  %rdx
 GET_CPUINFO_FIELD(cr4, dx)
 mov   (%rdx), %rax
-test  $X86_CR4_SMEP|X86_CR4_SMAP,%eax
+test  $XEN_CR4_PV32_BITS, %eax
 jnz   0f
 orcr4_pv32_mask(%rip), %rax
 mov   %rax, %cr4
@@ -215,9 +215,11 @@ ENTRY(cr4_pv32_restore)
 #ifndef NDEBUG
 /* Check that _all_ of the bits intended to be set actually are. */
 mov   %cr4, %rax
-and   cr4_pv32_mask(%rip), %eax
-cmp   cr4_pv32_mask(%rip), %eax
+and   cr4_pv32_mask(%rip), %rax
+cmp   cr4_pv32_mask(%rip), %rax
 je1f
+/* Cause cr4_pv32_mask to be visible in the BUG register dump. */
+mov   cr4_pv32_mask(%rip), %rdx
 BUG
 1:
 #endif
diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processor.h
index 4a6af0f..ddaaf2de 100644
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -151,6 +151,8 @@
 
 #define XEN_MINIMAL_CR4 (X86_CR4_PGE | X86_CR4_PAE)
 
+#define XEN_CR4_PV32_BITS (X86_CR4_SMEP|X86_CR4_SMAP)
+
 #define XEN_SYSCALL_MASK (X86_EFLAGS_AC|X86_EFLAGS_VM|X86_EFLAGS_RF|\
   X86_EFLAGS_NT|X86_EFLAGS_DF|X86_EFLAGS_IF|\
   X86_EFLAGS_TF)
-- 
2.1.4


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

Re: [Xen-devel] problem on running xen on CentOS 7 on APM X-Gene Aarch64 platform

[Stefano Stabellini]

CC'ing xen-devel and Julien and George.

The grub2 package coming with CentOS is not capable of booting Xen on
arm64. When you do "yum update" after "yum install centos-release-xen",
you should be getting a new grub2 package with Xen support in it. But it
looks like that is not happening for you.

Maybe there is an even newer version of grub2 available from the main
CentOS repository which supersedes the one provided by
centos-release-xen? Or maybe the Xen aware grub2 package in
centos-release-xen has been dropped?

The Xen aware grub2 package is (used to be) grub2-efi 2.02-0.16.1.el17.



On Mon, 16 May 2016, Congfeng Jiang wrote:
> Hi Stefano,
> 
> Just add to my first email  that when I run commands
> 
>   "yum install centos-release-xen " AND "yum update"
> 
> 
> 
>   Then reboot the system, the system won't boot and said
> 
> "error: out of memory
> 
>  Press any key to continue..."
> 
> 
> 
>  I checked that when run "yum update" after  "yum install centos-release-xen "
> 
>  It  updated grub2-efi-2.02-0.16.1.el7.aarch64.rpm  and
> grub2-tools-2.02-0.16.1.el7.aarch64.rpm.
> 
> 
>   But I dont know what it updated.
> 
> 
>Thanks!
> 
> 
> Best,
> 
> 
> Congfeng
> 
> 
> 
> Hi Stefano,
> 
>  I 'm a student at Wayne State University in Detroit,Michigan.
> 
> 
> 
>  I tried to run xen on APM X-Gene Aarch64 platform with CentOS 7 but 
> failed.
> 
>  I followed your instructions here:
> https://blog.xenproject.org/2015/10/05/xen-in-centos-7-aarch64/
> 
>   However, when I run the following commands
> 
> yum install centos-release-xen
> yum update
> yum install xen libvirt
> 
> 
>  and edited the/etc/default/grub file with
> dtuart=/soc/serial@1c02 as you did.
>   And then
> grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
> 
>Actually after the "grub2-mkconfig ..."  command, the grub.cfg
> didn't change anything.
> The grub.cfg file is the same with before running such commands.
>  I thought maybe it is because that the board is UEFI, not
> U-booting? So it doesn't affect the grub.cfg file?
> 
>   The" yum install xen libvirt" only created a "Xen" directory in 
> /boot/efi/EFI/
>   and placed two files in the "Xen'" directory:
> Xen-4.6.0rc2x-4.el7.cfg.sample andXen-4.6.0-rc-4.el7.efi
>  and place files in /boot directory with file Xen-4.6.0-rc-4.el7 and some 
> links.
> 
>   I copied the vmlinuz-4.2.0-0.28.el7.1.aarch64 and
> initramfs-4.2.0-0.28.el7.1.aarch64.img
>  to /boot/efi/EFI/centos/Xen and wrote a configuration file named with
> Xen-4.6.0-rc-4.el7.cfg according to the sample .cfg file.
> 
> I also added an entry into the UEFI BOOT manager following the instructions :
>  http://wiki.xenproject.org/wiki/Xen_EFI
> 
> 
> 
>   After rebooting,
>If I chose to boot Xen, it printed 5 lines and stalled after "L3C 3 8MB"
>If I chose to boot my original system, it said:
> 
> error: out of memory
>  Press any key to continue...
> 
>To figure it out ,I tried the commands step by step ,and found that
> even if I just did
> yum install centos-release-xen
> and then reboot the system, the system won't boot and said:
> 
> error: out of memory
>  Press any key to continue...
> 
>Here I didn't started anything related to Xen except installing the
> centos-release-xen repo.
>I looks so weird.
>  This means that after "yum install centos-release-xen" the system
> is changed and resulted in the disability to boot which causing "out
> of memory".
> I did not know is it a bug because I can exactly reproduce it many times .
> 
> 
>   Here are the details of the platform:
>  ARM64 bit board: APM X-Gene , 8core/16GB Mem/500 HDD with UEFI support
>   OS: CentOS 7 for Aarch64,
> http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64-Everything.iso
>   Kernel: 4.2.0-0.28 after yum update(shipped with the above CentOS 7
> is 4.2.0-0.27)
> 
>   I greatly appreciate it if you can help me out.
> 
>Thanks!
> 
> Congfeng
> 
> Department of Computer Science
> Wayne State University
> Detroit 48201, MI
> 

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

Re: [Xen-devel] [PATCH V3 2/2] xen/arm: mm: clean up code in setup_pagetables

[Stefano Stabellini]

On Mon, 16 May 2016, Julien Grall wrote:
> Hi Peng,
> 
> On 12/05/16 12:48, Peng Fan wrote:
> > The base of address for the relocated xen needs to be mapped
> > at the same virtual address (BOOT_RELOC_VIRT_START) in both
> > the boot and runtime page tables. So we can merge the two pieces
> > of code into on code block
> 
> s/on/one/ and missing full stop.
> 
> > 
> > Also no need to use write_pte when mapping BOOT_RELOC_VIRT_START
> > in xen_second, because CPU0 is using boot page tables.
> > 
> > Signed-off-by: Peng Fan 
> > Cc: Stefano Stabellini 
> > Cc: Julien Grall 
> 
> With the typos above fixed:
> 
> Reviewed-by: Julien Grall 
> 
> Stefano, could you fix the typos before applying this series to your Xen 4.8
> branch?

Done

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

Re: [Xen-devel] [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Stefano Stabellini]

On Fri, 13 May 2016, Matt Fleming wrote:
> (Including more folks, quoting entire patch)
> 
> On Thu, 12 May, at 08:19:54PM, Shannon Zhao wrote:
> > From: Shannon Zhao 
> > 
> > The EFI DT parameters for bare metal are located under /chosen node,
> > while for Xen Dom0 they are located under /hyperviosr/uefi node. These
> > parameters under /chosen and /hyperviosr/uefi are not expected to appear
> > at the same time.
> > Parse these EFI parameters and initialize EFI like the way for bare
> > metal except the runtime services because the runtime services for Xen
> > Dom0 are available through hypercalls and they are always enabled. So it
> > sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and
> > bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES
> > flag is set already.
> > 
> > CC: Matt Fleming 
> > Signed-off-by: Shannon Zhao 
> > ---
> > v2: rebase it on top of EFI and Xen next branch, add some comments to
> > explain the codes. 
> > ---
> >  arch/arm/xen/enlighten.c   | 22 +++
> >  drivers/firmware/efi/arm-runtime.c |  5 +++
> >  drivers/firmware/efi/efi.c | 81 
> > ++
> >  3 files changed, 92 insertions(+), 16 deletions(-)
>  
> This looks good to me. Thanks for all the work Shannon.
> 
> Stefan, OK, let's figure out how to deal with this.
> 
> What I've done is merge xen/linux-next into the 'efi/xen-arm' topic
> branch and applied this patch here,
> 
>   
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/log/?h=efi/arm-xen
> 
> Yes, the merge includes some Xen patches that are not actually needed
> for any of the EFI patches, but Linus has complained about picking
> random commits of a tree to merge. At least this way this is all the
> Xen linux-next material.
> 
> If you're OK with this, and assuming no one else has any preferred
> methods, I'll send out a pull request to tip over the weekend.

I am OK with it. Thanks!


> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> > index 13e3e9f..d4f36eb 100644
> > --- a/arch/arm/xen/enlighten.c
> > +++ b/arch/arm/xen/enlighten.c
> > @@ -15,7 +15,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -261,6 +263,19 @@ static int __init fdt_find_hyper_node(unsigned long 
> > node, const char *uname,
> > !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
> > hyper_node.version = s + strlen(hyper_node.prefix);
> >  
> > +   /*
> > +* Check if Xen supports EFI by checking whether there is the
> > +* "/hypervisor/uefi" node in DT. If so, runtime services are available
> > +* through proxy functions (e.g. in case of Xen dom0 EFI implementation
> > +* they call special hypercall which executes relevant EFI functions)
> > +* and that is why they are always enabled.
> > +*/
> > +   if (IS_ENABLED(CONFIG_XEN_EFI)) {
> > +   if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
> > +   !efi_runtime_disabled())
> > +   set_bit(EFI_RUNTIME_SERVICES, );
> > +   }
> > +
> > return 0;
> >  }
> >  
> > @@ -352,6 +367,13 @@ static int __init xen_guest_init(void)
> > return -ENODEV;
> > }
> >  
> > +   /*
> > +* The fdt parsing codes have set EFI_RUNTIME_SERVICES if Xen EFI
> > +* parameters are found. Force enable runtime services.
> > +*/
> > +   if (efi_enabled(EFI_RUNTIME_SERVICES))
> > +   xen_efi_runtime_setup();
> > +
> > shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
> >  
> > if (!shared_info_page) {
> > diff --git a/drivers/firmware/efi/arm-runtime.c 
> > b/drivers/firmware/efi/arm-runtime.c
> > index 17ccf0a..c394b81 100644
> > --- a/drivers/firmware/efi/arm-runtime.c
> > +++ b/drivers/firmware/efi/arm-runtime.c
> > @@ -107,6 +107,11 @@ static int __init arm_enable_runtime_services(void)
> > return 0;
> > }
> >  
> > +   if (efi_enabled(EFI_RUNTIME_SERVICES)) {
> > +   pr_info("EFI runtime services access via paravirt.\n");
> > +   return 0;
> > +   }
> > +
> > pr_info("Remapping and enabling EFI services.\n");
> >  
> > mapsize = efi.memmap.map_end - efi.memmap.map;
> > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> > index 05509f3..1c6f9dd 100644
> > --- a/drivers/firmware/efi/efi.c
> > +++ b/drivers/firmware/efi/efi.c
> > @@ -472,12 +472,14 @@ device_initcall(efi_load_efivars);
> > FIELD_SIZEOF(struct efi_fdt_params, field) \
> > }
> >  
> > -static __initdata struct {
> > +struct params {
> > const char name[32];
> > const char propname[32];
> > int offset;
> > int size;
> > -} dt_params[] = {
> > +};
> > +
> > +static __initdata struct params fdt_params[] = {
> > UEFI_PARAM("System Table", 

Re: [Xen-devel] [PATCH v3 4/9] arm/vm_event: get/set registers

[Julien Grall]

Hi Tamas,

On 04/05/16 15:51, Tamas K Lengyel wrote:

diff --git a/xen/include/asm-arm/vm_event.h b/xen/include/asm-arm/vm_event.h
index a3fc4ce..814d0da 100644
--- a/xen/include/asm-arm/vm_event.h
+++ b/xen/include/asm-arm/vm_event.h
@@ -48,15 +48,10 @@ void vm_event_register_write_resume(struct vcpu *v, 
vm_event_response_t *rsp)
  /* Not supported on ARM. */
  }

-static inline
-void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp)
-{
-/* Not supported on ARM. */
-}
+void vm_event_set_registers(struct vcpu *v, vm_event_response_t *rsp);

-static inline void vm_event_fill_regs(vm_event_request_t *req)
-{
-/* Not supported on ARM. */
-}
+void vm_event_fill_regs(vm_event_request_t *req,
+const struct cpu_user_regs *regs,
+struct domain *d);

  #endif /* __ASM_ARM_VM_EVENT_H__ */
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index 3acf217..fabeee8 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -129,8 +129,8 @@
  #define VM_EVENT_X86_XCR0   3

  /*
- * Using a custom struct (not hvm_hw_cpu) so as to not fill
- * the vm_event ring buffer too quickly.
+ * Using custom vCPU structs (i.e. not hvm_hw_cpu) for both x86 and ARM


You may want to rework this sentence as hvm_hw_cpu does not exist on 
ARM/ARM64.



+ * so as to not fill the vm_event ring buffer too quickly.
   */
  struct vm_event_regs_x86 {
  uint64_t rax;
@@ -168,6 +168,54 @@ struct vm_event_regs_x86 {
  uint32_t _pad;
  };

+struct vm_event_regs_arm32 {
+uint32_t r0_usr;
+uint32_t r1_usr;
+uint32_t r2_usr;
+uint32_t r3_usr;
+uint32_t r4_usr;
+uint32_t r5_usr;
+uint32_t r6_usr;
+uint32_t r7_usr;
+uint32_t r8_usr;
+uint32_t r9_usr;
+uint32_t r10_usr;
+uint32_t r12_usr;
+uint32_t lr_usr;
+uint32_t sp_usr;
+uint32_t sp_svc;
+uint32_t spsr_svc;
+uint32_t fp;
+uint32_t pc;
+uint32_t cpsr;
+uint32_t ttbr0;
+uint32_t ttbr1;
+};
+
+struct vm_event_regs_arm64 {
+uint64_t x0;
+uint64_t x1;
+uint64_t x2;
+uint64_t x3;
+uint64_t x4;
+uint64_t x5;
+uint64_t x6;
+uint64_t x7;
+uint64_t x8;
+uint64_t x9;
+uint64_t x10;
+uint64_t x16;
+uint64_t lr;
+uint64_t sp_el0;
+uint64_t sp_el1;
+uint32_t spsr_el1;
+uint64_t fp;
+uint64_t pc;
+uint32_t cpsr;
+uint64_t ttbr0;
+uint64_t ttbr1;
+};


By defining 2 distinct structures, it will be more difficult for the 
introspection tools to inspect registers of an Aarch64 domain running in 
AArch32 mode. They wouldn't be able to re-use code for AArch32 domain 
because the structure fields are different.


The ARM ARM (see D1.20.1 in ARM DDI 0487A.i) provides a mapping between 
AArch32 state and AArch64 state. If you use it to define the layout of a 
common structure, the support of AArch32 state for AArch64 domain will 
come free.



+
  /*
   * mem_access flag definitions
   *
@@ -256,6 +304,8 @@ typedef struct vm_event_st {
  union {
  union {
  struct vm_event_regs_x86 x86;
+struct vm_event_regs_arm32 arm32;
+struct vm_event_regs_arm64 arm64;
  } regs;

  struct vm_event_emul_read_data emul_read_data;



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