[Xen-devel] [linux-linus test] 115438: regressions - FAIL

[osstest service owner]

flight 115438 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115438/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  6 xen-install  fail in 115414 pass in 115438
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
pass in 115414

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linux5f479447d983111c039f1d6d958553c1ad1b2ff1
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z   13 days
Failing since114781  2017-10-20 01:00:47 Z   12 days   20 attempts
Testing same since   115414  2017-10-31 03:43:24 Z1 days2 attempts


422 people touched revisions under test,
not listing them all

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

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

[Christoffer Dall]

On Wed, Nov 1, 2017 at 9:58 AM, Stefano Stabellini
 wrote:

[]

>
>> ### List register management
>>
>> A list register (LR) holds the state of a virtual interrupt, which will
>> be used by the GIC hardware to simulate an IRQ life cycle for a guest.
>> Each GIC hardware implementation can choose to implement a number of LRs,
>> having four of them seems to be a common value. This design here does not
>> try to manage the LRs very cleverly, instead on every guest exit every LR
>> in use will be synced to the emulated state, then cleared. Upon guest entry
>> the top priority virtual IRQs will be inserted into the LRs. If there are
>> more pending or active IRQs than list registers, the GIC management IRQ
>> will be configured to notify the hypervisor of a free LR (once the guest
>> has EOIed one IRQ). This will trigger a normal exit, which will go through
>> the normal cleanup/repopulate scheme, possibly now queuing the leftover
>> interrupt(s).
>> To facilitate quick guest exit and entry times, the VGIC maintains the list
>> of pending or active interrupts (ap\_list) sorted by their priority. Active
>> interrupts always go first on the list, since a guest and the hardware GIC
>> expect those to stay until they have been explicitly deactivated. Failure
>> in keeping active IRQs around will result in error conditions in the GIC.
>> The second sort criteria for the ap\_list is their priority, so higher
>> priority pending interrupt always go first into the LRs.
>
> The suggestion of using this model in Xen was made in the past already.
> I always objected for the reason that we don't actually know how many
> LRs the hardware provides, potentially very many, and it is expensive
> and needless to read/write them all every time on entry/exit.
>
> I would prefer to avoid that, but I'll be honest: I can be convinced
> that that model of handling LRs is so much simpler that it is worth it.
> I am more concerned about the future maintainance of a separate new
> driver developed elsewhere.

[Having just spent a fair amount of time optimizing KVM/ARM and
measuring GIC interaction, I'll comment on this and leave it up to
Andre to drive the rest of the discussion].

In KVM we currently only ever touch an LR when we absolutely have to.
For example, if there are no interrupts, we do not touch an LR.

When you do have an interrupt in flight, and have programmed one or
more LRs, you have to either read back that LR, or read one of the
status registers to figure out if the interrupt has become inactive
(and should potentially be injected again).  I measured both on KVM
for various workloads and it was faster to never read the status
registers, but simply read back the LRs that were in use when entering
the guest.

You can potentially micro-optimize slightly by remembering the exit
value of an LR (and not clearing it on guest exit), but you have to
pay the cost in terms of additional logic during VCPU migration and
when you enter a VM again, maintaining a mapping of the LR and the
virtual state, to avoid rewriting the same value to the LR again.  We
tried that in KVM and could not measure any benefit using either a
pinned or oversubscribed workload; I speculate that the number of
times you exit with unprocessed interrupts in the LRs is extremely
rare.

In terms of the number of LRs, I stil haven't seen an implementation
with anything else than 4 LRs.

-Christoffer

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

[Xen-devel] [qemu-mainline bisection] complete build-armhf

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-armhf
testid xen-build

Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  qemuu git://git.qemu.org/qemu.git
  Bug introduced:  aef45d51d1204f3335fb99de6658e0c5612c2b67
  Bug not present: f90ea7ba7c5ae7010ee0ce062207ae42530f57d6
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/115451/


  commit aef45d51d1204f3335fb99de6658e0c5612c2b67
  Author: Daniel P. Berrange 
  Date:   Fri Sep 29 11:11:56 2017 +0100
  
  build: automatically handle GIT submodule checkout for dtc
  
  Currently if DTC is required by configure and not available in the host
  OS install, we exit with an error message telling the user to checkout a
  git submodule or install the library.
  
  This introduces automatic handling of the git submodule checkout process
  and enables it for dtc. This only runs if building from GIT, so users of
  release tarballs still need the system library install. The current state
  of the git checkout is stashed in .git-submodule-status, and a helper
  program is used to determine if this state matches the desired submodule
  state. A dependency against 'Makefile' ensures that the submodule state
  is refreshed at the start of the build process
  
  Signed-off-by: Daniel P. Berrange 
  Message-id: 20170929101201.21039-2-berra...@redhat.com
  
  [ kraxel: use /bin/sh not bash for scripts/git-submodule.sh ]
  [ kraxel: fix Makefile dependencies ]
  
  Signed-off-by: Gerd Hoffmann 
  
  [fixup] Makefile dep


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/qemu-mainline/build-armhf.xen-build 
--summary-out=tmp/115458.bisection-summary --basis-template=114507 
--blessings=real,real-bisect qemu-mainline build-armhf xen-build
Searching for failure / basis pass:
 115452 fail [host=arndale-bluewater] / 114507 [host=arndale-westfield] 114409 
[host=cubietruck-braque] 114279 [host=cubietruck-braque] 114148 
[host=cubietruck-braque] 114106 ok.
Failure / basis pass flights: 115452 / 114106
Tree: qemuu git://git.qemu.org/qemu.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 47ba789c97c8d201d01058b00a14d8a9a85fcfe9 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
Basis pass 530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
Generating revisions with ./adhoc-revtuple-generator  
git://git.qemu.org/qemu.git#530049bc1dcc24c1178a29d99ca08b6dd08413e0-47ba789c97c8d201d01058b00a14d8a9a85fcfe9
 
git://xenbits.xen.org/xen.git#dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e-24fb44e971a62b345c7b6ca3c03b454a1e150abe
Loaded 3794 nodes in revision graph
Searching for test results:
 114083 [host=arndale-metrocentre]
 114106 pass 530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 114148 [host=cubietruck-braque]
 114279 [host=cubietruck-braque]
 114409 [host=cubietruck-braque]
 114474 [host=arndale-metrocentre]
 114506 pass irrelevant
 114475 [host=arndale-westfield]
 114507 [host=arndale-westfield]
 114645 fail irrelevant
 114651 fail irrelevant
 114667 [host=arndale-metrocentre]
 114786 fail 063833a6ec2a6747e27c5f9866bb44c7e8de1265 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 114703 fail 861cd431c99e56ddb5953ca1da164a9c32b477ca 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 114830 [host=arndale-metrocentre]
 115129 fail e822e81e350825dd94f41ee2538ff1432b812eb9 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115141 fail e822e81e350825dd94f41ee2538ff1432b812eb9 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115169 [host=arndale-lakeside]
 115162 [host=arndale-lakeside]
 115252 pass 567d0a19c7998fa366598b83d5a6e5f0759d3ea9 
28f2ad440a08908010abec43b7ccc3283051e943
 115245 pass 8df8d529ed958de4e23dcbf38bd34eff1a4716f2 
f17d2cd2ffeda70aba8788910e9d088415562c8b
 115237 fail 2ff408de9c080f2fb5a94ebf6a209c6180c64933 
765c2035a765c426c130c1f2cc009af60a99b1bd
 115175 [host=arndale-lakeside]
 115228 [host=arndale-lakeside]
 115198 fail 3d7196d43bfe12efe98568cb60057e273652b99b 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115183 fail a61837da0f2122e01685f6b7aad3226c9a6fc289 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115223 pass 48ae1f60d8c9a770e6da64407984d84e25253c69 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115201 pass 530049bc1dcc24c1178a29d99ca08b6dd08413e0 
dbc4b6e13a5d0dd8967cde7ff7000ab1ed88625e
 115239 pass cf5f7937b05c84d5565134f058c00cd48304a117 
cc08c73c8c1f5ba5ed0f8274548db6725e1c3157
 115216 fail a61837da0f2122e01685f6b7aad3226c9a6fc289 
24fb44e971a62b345c7b6ca3c03b454a1e150abe
 115220 fail 

[Xen-devel] [linux-4.9 test] 115432: regressions - FAIL

[osstest service owner]

flight 115432 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115432/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
115411

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail in 115411 like 114814
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114814
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxd785062ef20f9b2cd8cedcafea55ca8264f25f3e
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z   11 days
Failing since114845  2017-10-21 16:14:17 Z   10 days   18 attempts
Testing same since   115296  2017-10-27 11:07:37 Z4 days8 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexandre Belloni 
  Andrew Morton 
  Andrey Konovalov 
  Anoob Soman 
  Arend van Spriel 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Hutchings 
  Ben Skeggs 
  Bin Liu 
  Borislav Petkov 
  Brian Foster 
  Carlos Maiolino 
  Christoph Biedl 

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Stefano Stabellini]

On Tue, 31 Oct 2017, Peter Maydell wrote:
> On 31 October 2017 at 18:51, Stefano Stabellini  
> wrote:
> > On Tue, 31 Oct 2017, Peter Maydell wrote:
> >> On 31 October 2017 at 17:01, Stefano Stabellini  
> >> wrote:
> >> > Fixing QEMU is harder than I expected. Would it be possible to update
> >> > id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?
> >>
> >> At that point we've already called register_cp_regs_for_features(),
> >> which is where we read cpu->id_aa64pfr0 when we're creating the
> >> cpreg. So if you change it after that it's too late. But that
> >> function is called at CPU realize time, which is before we've
> >> created the GIC object...
> >
> > What about something along the lines of
> >
> > diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> > index 9e18b41..0851071 100644
> > --- a/hw/arm/virt.c
> > +++ b/hw/arm/virt.c
> > @@ -1401,6 +1400,10 @@ static void machvirt_init(MachineState *machine)
> >  object_property_set_link(cpuobj, OBJECT(secure_sysmem),
> >   "secure-memory", _abort);
> >  }
> > +if (vms->gic_version == 3) {
> > +ARMCPU *cpu = ARM_CPU(cpuobj);
> > +cpu->id_aa64pfr0 |= 0x0100;
> > +}
> >
> >  object_property_set_bool(cpuobj, true, "realized", NULL);
> >  object_unref(cpuobj);
> 
> Definitely not -- the virt board should not be poking about inside the
> internals of the CPU object.
> 
> The slightly cleaned up version of this idea is that you give the
> CPU an object property for "claim the GICv3 registers exist in the
> ID registers" and have virt.c set it. That feels like an ugly
> workaround for something we really ought not to have to tell the
> board about at all, though.

Something like the following?

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9e18b41..369d36b 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1401,6 +1401,9 @@ static void machvirt_init(MachineState *machine)
 object_property_set_link(cpuobj, OBJECT(secure_sysmem),
  "secure-memory", _abort);
 }
+if (vms->gic_version == 3) {
+object_property_set_bool(cpuobj, true, "gicv3-sysregs", NULL);
+}
 
 object_property_set_bool(cpuobj, true, "realized", NULL);
 object_unref(cpuobj);
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 88578f3..259cad1 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1690,6 +1690,7 @@ static Property arm_cpu_properties[] = {
 DEFINE_PROP_UINT64("mp-affinity", ARMCPU,
 mp_affinity, ARM64_AFFINITY_INVALID),
 DEFINE_PROP_INT32("node-id", ARMCPU, node_id, CPU_UNSET_NUMA_NODE_ID),
+DEFINE_PROP_BOOL("gicv3-sysregs", ARMCPU, gicv3_sysregs, false),
 DEFINE_PROP_END_OF_LIST()
 };
 
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 89d49cd..0015b37 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -657,6 +657,9 @@ struct ARMCPU {
 /* Should CPU start in PSCI powered-off state? */
 bool start_powered_off;
 
+/* GICv3 sysregs present */
+bool gicv3_sysregs;
+
 /* Current power state, access guarded by BQL */
 ARMPSCIState power_state;
 
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 37af750..6f21900 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4687,7 +4687,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 { .name = "ID_AA64PFR0_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 0,
   .access = PL1_R, .type = ARM_CP_CONST,
-  .resetvalue = cpu->id_aa64pfr0 },
+  .resetvalue = cpu->gicv3_sysregs ? (cpu->id_aa64pfr0|0x0100) 
:
+  cpu->id_aa64pfr0 },
 { .name = "ID_AA64PFR1_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 0, .crm = 4, .opc2 = 1,
   .access = PL1_R, .type = ARM_CP_CONST,

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

[Xen-devel] [qemu-mainline test] 115452: regressions - FAIL

[osstest service owner]

flight 115452 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115452/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  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
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  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-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 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-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [RFC] ARM: New (Xen) VGIC design document

[Stefano Stabellini]

On Wed, 11 Oct 2017, Andre Przywara wrote:
> Hi,
> 
> (CC:ing some KVM/ARM folks involved in the VGIC)
> 
> starting with the addition of the ITS support we were seeing more and
> more issues with the current implementation of our ARM Generic Interrupt
> Controller (GIC) emulation, the VGIC.
> Among other approaches to fix those issues it was proposed to copy the
> VGIC emulation used in KVM. This one was suffering from very similar
> issues, and a clean design from scratch lead to a very robust and
> capable re-implementation. Interestingly this implementation is fairly
> self-contained, so it seems feasible to copy it. Hopefully we only need
> minor adjustments, possibly we can even copy it verbatim with some
> additional glue layer code.
>
> Stefano asked for getting a design overview, to assess the feasibility
> of copying the KVM code without reviewing tons of code in the first
> place.
> So to follow Xen rules for new features, this design document below is
> an attempt to describe the current KVM VGIC design - in a hypervisor
> agnostic session. It is a bit of a retro-fit design description, as it
> is not strictly forward-looking only, but actually describing the
> existing implemenation [1].
> 
> Please have a look and let me know:
> 1) if this document has the right scope
> 2) if this document has the right level of detail
> 3) if there are points missing from the document
> 3) if the design in general is a fit

Please read the following statements as genuine questions and concerns.
Most ideas on this document are good. Some of them I have even suggested
them myself in the context of GIC improvements for Xen. I asked for a
couple of clarifications.

But I don't see why we cannot implement these ideas on top of the
existing code, rather than with a separate codebase, ending up with two
drivers. I would prefer a natual evolution. Specifically, the following
improvements would be simple and would give us most of the benefits on
top of the current codebase:
- adding the irq lock, and the refcount
- taking both vcpu locks when necessary (on migration code for example
  it would help a lot), the lower vcpu_id first
- level irq emulation


If we do end up with a second separate driver for technical or process
reasons, I would expect the regular Xen submission/review process to be
followed. The code style will be different, the hooks into the rest of
the hypervisors will be different and things will be generally changed.
The new V/GIC might be derived from KVM, but it should end up looking
and feeling like a 100% genuine Xen component. After all, we'll
maintain it going forward. I don't want a copy of a Linux driver with
glue code. The Xen community cannot be expected not to review the
submission, but if we review it, then we'll ask for changes. Once we
change the code, there will be no point in keeping the Linux code
separate with glue code. We should fully adapt it to Xen.

That is what was done in the past when KVM took code from Xen (for
example async shadow pagetables). I am eager to avoid a situation like
the current SMMU driver in Xen, which comes from Linux, and we are not
entirely sure how to maintain it.


> Appreciate any feedback!
> 
> Cheers,
> Andre.
> 
> ---
> 
> VGIC design
> ===
> 
> This document describes the design of an ARM Generic Interrupt Controller 
> (GIC)
> emulation. It is meant to emulate a GIC for a guest in an virtual machine,
> the common name for that is VGIC (from "virtual GIC").
> 
> This design was the result of a one-week-long design session with some
> engineers in a room, triggered by ever-increasing difficulties in maintaining
> the existing GIC emulation in the KVM hypervisor. The design eventually
> materialised as an alternative VGIC implementation in the Linux kernel
> (merged into Linux v4.7). As of Linux v4.8 the previous VGIC implementation
> was removed, so it is now the current code used by Linux.
> Although being used in KVM, the actual design of this VGIC is rather 
> hypervisor
> agnostic and can be used by other hypervisors as well, in particular for Xen.
> 
> GIC hardware virtualization support
> ---
> 
> The ARM Generic Interrupt Controller (since v2) supports the virtualization
> extensions, which allows some parts of the interrupt life cycle to be handled
> purely inside the guest without exiting into the hypervisor.
> In the GICv2 and GICv3 architecture this covers mostly the "interrupt
> acknowledgement", "priority drop" and "interrupt deactivate" actions.
> So a guest can handle most of the interrupt processing code without
> leaving EL1 and trapping into the hypervisor. To accomplish
> this, the GIC holds so called "list registers" (LRs), which shadow the
> interrupt state for any virtual interrupt. Injecting an interrupt to a guest
> involves setting up one LR with the interrupt number, its priority and initial
> state (mostly "pending"), then entering the guest. Any 

[Xen-devel] [PATCH v6 1/1] xen/time: do not decrease steal time after live migration on xen

[Dongli Zhang]

After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock() might be less than this_rq()->prev_steal_time which is
derived from previous return value of xen_steal_clock().

For instance, steal time of each vcpu is 335 before live migration.

cpu  198 0 368 200064 1962 0 0 1340 0 0
cpu0 38 0 81 50063 492 0 0 335 0 0
cpu1 65 0 97 49763 634 0 0 335 0 0
cpu2 38 0 81 50098 462 0 0 335 0 0
cpu3 56 0 107 50138 374 0 0 335 0 0

After live migration, steal time is reduced to 312.

cpu  200 0 370 200330 1971 0 0 1248 0 0
cpu0 38 0 82 50123 500 0 0 312 0 0
cpu1 65 0 97 49832 634 0 0 312 0 0
cpu2 39 0 82 50167 462 0 0 312 0 0
cpu3 56 0 107 50207 374 0 0 312 0 0

Since runstate times are cumulative and cleared during xen live migration
by xen hypervisor, the idea of this patch is to accumulate runstate times
to global percpu variables before live migration suspend. Once guest VM is
resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
runstate times and previously accumulated times stored in global percpu
variables. Comments before the call of HYPERVISOR_suspend() has been
removed as it is inaccurate. The call can return an error code (e.g.,
possibly -EPERM in the future).

Similar and more severe issue would impact prior linux 4.8-4.10 as
discussed by Michael Las at
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,
which would overflow steal time and lead to 100% st usage in top command
for linux 4.8-4.10. A backport of this patch would fix that issue.

References: 
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest
Signed-off-by: Dongli Zhang 

---
Changed since v1:
  * relocate modification to xen_get_runstate_snapshot_cpu

Changed since v2:
  * accumulate runstate times before live migration

Changed since v3:
  * do not accumulate times in the case of guest checkpointing

Changed since v4:
  * allocate array of vcpu_runstate_info to reduce number of memory allocation

Changed since v5:
  * remove old incorrect comments above hypercall and mention in commit message
  * rename xen_accumulate_runstate_time() to xen_manage_runstate_time()
  * move global static pointer into xen_manage_runstate_time
  * change warn and alert to pr_warn_once() or pr_warn()
  * change kcalloc to kmalloc_array
  * do not add RUNSTATE_max to change Xen ABI and use 4 in the code instead

---
 drivers/xen/manage.c  |  7 ++---
 drivers/xen/time.c| 71 +--
 include/xen/xen-ops.h |  1 +
 3 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index c425d03..8835065 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -72,18 +72,15 @@ static int xen_suspend(void *data)
}
 
gnttab_suspend();
+   xen_manage_runstate_time(-1);
xen_arch_pre_suspend();
 
-   /*
-* This hypercall returns 1 if suspend was cancelled
-* or the domain was merely checkpointed, and 0 if it
-* is resuming in a new domain.
-*/
si->cancelled = HYPERVISOR_suspend(xen_pv_domain()
? virt_to_gfn(xen_start_info)
: 0);
 
xen_arch_post_suspend(si->cancelled);
+   xen_manage_runstate_time(si->cancelled ? 1 : 0);
gnttab_resume();
 
if (!si->cancelled) {
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..65a0b25 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -19,6 +19,8 @@
 /* runstate info updated by Xen */
 static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
 
+static DEFINE_PER_CPU(u64[4], old_runstate_time);
+
 /* return an consistent snapshot of 64-bit time/counter value */
 static u64 get64(const u64 *p)
 {
@@ -47,8 +49,8 @@ static u64 get64(const u64 *p)
return ret;
 }
 
-static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
- unsigned int cpu)
+static void xen_get_runstate_snapshot_cpu_delta(
+ struct vcpu_runstate_info *res, unsigned int cpu)
 {
u64 state_time;
struct vcpu_runstate_info *state;
@@ -66,6 +68,71 @@ static void xen_get_runstate_snapshot_cpu(struct 
vcpu_runstate_info *res,
 (state_time & XEN_RUNSTATE_UPDATE));
 }
 
+static void xen_get_runstate_snapshot_cpu(struct vcpu_runstate_info *res,
+ unsigned int cpu)
+{
+   int i;
+
+   xen_get_runstate_snapshot_cpu_delta(res, cpu);
+
+   for (i = 0; i < 4; i++)
+   res->time[i] += per_cpu(old_runstate_time, cpu)[i];
+}
+
+void xen_manage_runstate_time(int action)
+{
+   static struct vcpu_runstate_info *runstate_delta;
+   struct vcpu_runstate_info state;
+   int cpu, i;
+

Re: [Xen-devel] [PATCH 3/3] x86/svm: add virtual VMLOAD/VMSAVE support

[Brian Woods]

On Tue, Oct 31, 2017 at 10:15:08PM +, Andrew Cooper wrote:
> 
> The style in this file is quite hit and miss, but we expect new code to
> conform to the standards.  In this case, the correct style is:
> 
> if ( cpu_has_svm_vloadsave )
> {
> 
> This can be fixed on commit if there are no other comments.
> 
> All 3 patches Reviewed-by: Andrew Cooper 
> 
> ~Andrew
> 

My mistake.  Years of lknf has made it a habit.  I'll make sure to
double check next time.  Attached is the git format-patch for that
commit.

-- 
Brian Woods
>From b0d7916a5a35096cb7309922176631f7e57efdf1 Mon Sep 17 00:00:00 2001
From: Brian Woods 
Date: Tue, 31 Oct 2017 14:13:01 -0500
Subject: [PATCH 3/3] x86/svm: add virtual VMLOAD/VMSAVE support
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On AMD family 17h server processors, there is a feature called virtual
VMLOAD/VMSAVE.  This allows a nested hypervisor to preform a VMLOAD or
VMSAVE without needing to be intercepted by the host hypervisor.
Virtual VMLOAD/VMSAVE requires the host hypervisor to be in long mode
and nested page tables to be enabled.  For more information about it
please see:

AMD64 Architecture Programmer’s Manual Volume 2: System Programming
http://support.amd.com/TechDocs/24593.pdf
Section: VMSAVE and VMLOAD Virtualization (Section 15.33.1)

This patch series adds support to check for and enable the virtual
VMLOAD/VMSAVE features if available.

Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/svm.c  | 1 +
 xen/arch/x86/hvm/svm/svmdebug.c | 2 ++
 xen/arch/x86/hvm/svm/vmcb.c | 8 
 3 files changed, 11 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c8ffb17515..60b1288a31 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1669,6 +1669,7 @@ const struct hvm_function_table * __init start_svm(void)
 P(cpu_has_svm_nrips, "Next-RIP Saved on #VMEXIT");
 P(cpu_has_svm_cleanbits, "VMCB Clean Bits");
 P(cpu_has_svm_decode, "DecodeAssists");
+P(cpu_has_svm_vloadsave, "Virtual VMLOAD/VMSAVE");
 P(cpu_has_pause_filter, "Pause-Intercept Filter");
 P(cpu_has_tsc_ratio, "TSC Rate MSR");
 #undef P
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 89ef2db932..7145e2f5ca 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -55,6 +55,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct *vmcb)
vmcb->exitinfo1, vmcb->exitinfo2);
 printk("np_enable = %#"PRIx64" guest_asid = %#x\n",
vmcb_get_np_enable(vmcb), vmcb_get_guest_asid(vmcb));
+printk("virtual vmload/vmsave = %d  virt_ext = %#"PRIx64"\n",
+   vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes);
 printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n",
vmcb_get_cpl(vmcb), vmcb_get_efer(vmcb), vmcb->star, vmcb->lstar);
 printk("CR0 = 0x%016"PRIx64" CR2 = 0x%016"PRIx64"\n",
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 997e7597e0..eccc1e28bf 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,6 +200,14 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
+
+/* use virtual VMLOAD/VMSAVE if available */
+if ( cpu_has_svm_vloadsave )
+{
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
+vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
+}
 }
 else
 {
-- 
2.11.0

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

Re: [Xen-devel] [PATCH 3/3] x86/svm: add virtual VMLOAD/VMSAVE support

[Andrew Cooper]

On 31/10/17 22:03, brian.wo...@amd.com wrote:
> From: Brian Woods 
>
> On AMD family 17h server processors, there is a feature called virtual
> VMLOAD/VMSAVE.  This allows a nested hypervisor to preform a VMLOAD or
> VMSAVE without needing to be intercepted by the host hypervisor.
> Virtual VMLOAD/VMSAVE requires the host hypervisor to be in long mode
> and nested page tables to be enabled.  For more information about it
> please see:
>
> AMD64 Architecture Programmer’s Manual Volume 2: System Programming
> http://support.amd.com/TechDocs/24593.pdf
> Section: VMSAVE and VMLOAD Virtualization (Section 15.33.1)
>
> This patch series adds support to check for and enable the virtual
> VMLOAD/VMSAVE features if available.
>
> Signed-off-by: Brian Woods 
> ---
>  xen/arch/x86/hvm/svm/svm.c  | 1 +
>  xen/arch/x86/hvm/svm/svmdebug.c | 2 ++
>  xen/arch/x86/hvm/svm/vmcb.c | 7 +++
>  3 files changed, 10 insertions(+)
>
> diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
> index c8ffb17515..60b1288a31 100644
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -1669,6 +1669,7 @@ const struct hvm_function_table * __init start_svm(void)
>  P(cpu_has_svm_nrips, "Next-RIP Saved on #VMEXIT");
>  P(cpu_has_svm_cleanbits, "VMCB Clean Bits");
>  P(cpu_has_svm_decode, "DecodeAssists");
> +P(cpu_has_svm_vloadsave, "Virtual VMLOAD/VMSAVE");
>  P(cpu_has_pause_filter, "Pause-Intercept Filter");
>  P(cpu_has_tsc_ratio, "TSC Rate MSR");
>  #undef P
> diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
> index 89ef2db932..7145e2f5ca 100644
> --- a/xen/arch/x86/hvm/svm/svmdebug.c
> +++ b/xen/arch/x86/hvm/svm/svmdebug.c
> @@ -55,6 +55,8 @@ void svm_vmcb_dump(const char *from, const struct 
> vmcb_struct *vmcb)
> vmcb->exitinfo1, vmcb->exitinfo2);
>  printk("np_enable = %#"PRIx64" guest_asid = %#x\n",
> vmcb_get_np_enable(vmcb), vmcb_get_guest_asid(vmcb));
> +printk("virtual vmload/vmsave = %d  virt_ext = %#"PRIx64"\n",
> +   vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes);
>  printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = 
> %#"PRIx64"\n",
> vmcb_get_cpl(vmcb), vmcb_get_efer(vmcb), vmcb->star, vmcb->lstar);
>  printk("CR0 = 0x%016"PRIx64" CR2 = 0x%016"PRIx64"\n",
> diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
> index 997e7597e0..cc35d00bb7 100644
> --- a/xen/arch/x86/hvm/svm/vmcb.c
> +++ b/xen/arch/x86/hvm/svm/vmcb.c
> @@ -200,6 +200,13 @@ static int construct_vmcb(struct vcpu *v)
>  
>  /* PAT is under complete control of SVM when using nested paging. */
>  svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
> +
> +/* use virtual VMLOAD/VMSAVE if available */
> +if (cpu_has_svm_vloadsave) {

The style in this file is quite hit and miss, but we expect new code to
conform to the standards.  In this case, the correct style is:

if ( cpu_has_svm_vloadsave )
{

This can be fixed on commit if there are no other comments.

All 3 patches Reviewed-by: Andrew Cooper 

~Andrew

> +vmcb->virt_ext.fields.vloadsave_enable = 1;
> +vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
> +vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
> +}
>  }
>  else
>  {


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

[Xen-devel] [PATCH 2/3] x86/svm: add virtual VMLOAD/VMSAVE feature definition

[brian . woods]

From: Brian Woods 

Adding support for enabling the virtual VMLOAD/VMSAVE feature..

Signed-off-by: Brian Woods 
---
 xen/include/asm-x86/hvm/svm/svm.h  | 2 ++
 xen/include/asm-x86/hvm/svm/vmcb.h | 1 +
 2 files changed, 3 insertions(+)

diff --git a/xen/include/asm-x86/hvm/svm/svm.h 
b/xen/include/asm-x86/hvm/svm/svm.h
index 0956f860ef..4edf7b002d 100644
--- a/xen/include/asm-x86/hvm/svm/svm.h
+++ b/xen/include/asm-x86/hvm/svm/svm.h
@@ -64,6 +64,7 @@ extern u32 svm_feature_flags;
 #define SVM_FEATURE_FLUSHBYASID6 /* TLB flush by ASID support */
 #define SVM_FEATURE_DECODEASSISTS  7 /* Decode assists support */
 #define SVM_FEATURE_PAUSEFILTER   10 /* Pause intercept filter support */
+#define SVM_FEATURE_VLOADSAVE 15 /* virtual vmload/vmsave */
 
 #define cpu_has_svm_feature(f) test_bit(f, _feature_flags)
 #define cpu_has_svm_npt   cpu_has_svm_feature(SVM_FEATURE_NPT)
@@ -74,6 +75,7 @@ extern u32 svm_feature_flags;
 #define cpu_has_svm_decodecpu_has_svm_feature(SVM_FEATURE_DECODEASSISTS)
 #define cpu_has_pause_filter  cpu_has_svm_feature(SVM_FEATURE_PAUSEFILTER)
 #define cpu_has_tsc_ratio cpu_has_svm_feature(SVM_FEATURE_TSCRATEMSR)
+#define cpu_has_svm_vloadsave cpu_has_svm_feature(SVM_FEATURE_VLOADSAVE)
 
 #define SVM_PAUSEFILTER_INIT3000
 
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index beec1f6c0e..1d3d45f6d7 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -359,6 +359,7 @@ typedef union
 struct
 {
 u64 lbr_enable:1;
+u64 vloadsave_enable:1;
 } fields;
 } virt_ext_t;
 
-- 
2.11.0


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

[Xen-devel] [PATCH 1/3] x86/svm: rename lbr control field in vmcb

[brian . woods]

From: Brian Woods 

Rename the lbr_control field in the vmcb for future/upcoming changes.

Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/nestedsvm.c| 10 +-
 xen/arch/x86/hvm/svm/svm.c  |  2 +-
 xen/include/asm-x86/hvm/svm/nestedsvm.h |  4 ++--
 xen/include/asm-x86/hvm/svm/vmcb.h  |  6 +++---
 4 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/nestedsvm.c b/xen/arch/x86/hvm/svm/nestedsvm.c
index 1de896e456..5513f7a388 100644
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -174,7 +174,7 @@ int nsvm_vcpu_reset(struct vcpu *v)
 svm->ns_exception_intercepts = 0;
 svm->ns_general1_intercepts = 0;
 svm->ns_general2_intercepts = 0;
-svm->ns_lbr_control.bytes = 0;
+svm->ns_virt_ext.bytes = 0;
 
 svm->ns_hap_enabled = 0;
 svm->ns_vmcb_guestcr3 = 0;
@@ -521,12 +521,12 @@ static int nsvm_vmcb_prepare4vmrun(struct vcpu *v, struct 
cpu_user_regs *regs)
 /* Pending Interrupts */
 n2vmcb->eventinj = ns_vmcb->eventinj;
 
-/* LBR virtualization */
+/* LBR and other virtualization */
 if (!vcleanbit_set(lbr)) {
-svm->ns_lbr_control = ns_vmcb->lbr_control;
+svm->ns_virt_ext = ns_vmcb->virt_ext;
 }
-n2vmcb->lbr_control.bytes =
-n1vmcb->lbr_control.bytes | ns_vmcb->lbr_control.bytes;
+n2vmcb->virt_ext.bytes =
+n1vmcb->virt_ext.bytes | ns_vmcb->virt_ext.bytes;
 
 /* NextRIP - only evaluated on #VMEXIT. */
 
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index b9cf423fd9..c8ffb17515 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1997,7 +1997,7 @@ static int svm_msr_write_intercept(unsigned int msr, 
uint64_t msr_content)
 vmcb_set_debugctlmsr(vmcb, msr_content);
 if ( !msr_content || !cpu_has_svm_lbrv )
 break;
-vmcb->lbr_control.fields.enable = 1;
+vmcb->virt_ext.fields.lbr_enable = 1;
 svm_disable_intercept_for_msr(v, MSR_IA32_DEBUGCTLMSR);
 svm_disable_intercept_for_msr(v, MSR_IA32_LASTBRANCHFROMIP);
 svm_disable_intercept_for_msr(v, MSR_IA32_LASTBRANCHTOIP);
diff --git a/xen/include/asm-x86/hvm/svm/nestedsvm.h 
b/xen/include/asm-x86/hvm/svm/nestedsvm.h
index 4b36c25c5d..a619b6131b 100644
--- a/xen/include/asm-x86/hvm/svm/nestedsvm.h
+++ b/xen/include/asm-x86/hvm/svm/nestedsvm.h
@@ -46,8 +46,8 @@ struct nestedsvm {
 uint32_t ns_general1_intercepts;
 uint32_t ns_general2_intercepts;
 
-/* Cached real lbr of the l2 guest */
-lbrctrl_t ns_lbr_control;
+/* Cached real lbr and other virtual extentions of the l2 guest */
+virt_ext_t ns_virt_ext;
 
 /* Cached real MSR permission bitmaps of the l2 guest */
 unsigned long *ns_cached_msrpm;
diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
b/xen/include/asm-x86/hvm/svm/vmcb.h
index 01ce20b0bd..beec1f6c0e 100644
--- a/xen/include/asm-x86/hvm/svm/vmcb.h
+++ b/xen/include/asm-x86/hvm/svm/vmcb.h
@@ -358,9 +358,9 @@ typedef union
 u64 bytes;
 struct
 {
-u64 enable:1;
+u64 lbr_enable:1;
 } fields;
-} lbrctrl_t;
+} virt_ext_t;
 
 typedef union
 {
@@ -427,7 +427,7 @@ struct vmcb_struct {
 u64 res08[2];
 eventinj_t  eventinj;   /* offset 0xA8 */
 u64 _h_cr3; /* offset 0xB0 - cleanbit 4 */
-lbrctrl_t lbr_control;  /* offset 0xB8 */
+virt_ext_t virt_ext;/* offset 0xB8 */
 vmcbcleanbits_t cleanbits;  /* offset 0xC0 */
 u32 res09;  /* offset 0xC4 */
 u64 nextrip;/* offset 0xC8 */
-- 
2.11.0


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

[Xen-devel] [PATCH 0/3] x86/svm: virtual VMLOAD/VMSAVE

[brian . woods]

From: Brian Woods 

x86/svm: virtual VMLOAD/VMSAVE

On AMD family 17h server processors, there is a feature called virtual
VMLOAD/VMSAVE.  This allows a nested hypervisor to preform a VMLOAD or
VMSAVE without needing to be intercepted by the host hypervisor.
Virtual VMLOAD/VMSAVE requires the host hypervisor to be in long mode
and nested page tables to be enabled.  For more information about it
please see:

AMD64 Architecture Programmer’s Manual Volume 2: System Programming
http://support.amd.com/TechDocs/24593.pdf
Section: VMSAVE and VMLOAD Virtualization (Section 15.33.1)

This patch series adds support to check for and enable the virtual
VMLOAD/VMSAVE features if available.

Signed-off-by: Brian Woods 

Brian Woods (3):
  x86/svm: rename lbr control field in vmcb
  x86/svm: add virtual VMLOAD/VMSAVE feature definition
  x86/svm: add virtual VMLOAD/VMSAVE support

 xen/arch/x86/hvm/svm/nestedsvm.c| 10 +-
 xen/arch/x86/hvm/svm/svm.c  |  3 ++-
 xen/arch/x86/hvm/svm/svmdebug.c |  2 ++
 xen/arch/x86/hvm/svm/vmcb.c |  7 +++
 xen/include/asm-x86/hvm/svm/nestedsvm.h |  4 ++--
 xen/include/asm-x86/hvm/svm/svm.h   |  2 ++
 xen/include/asm-x86/hvm/svm/vmcb.h  |  7 ---
 7 files changed, 24 insertions(+), 11 deletions(-)

-- 
2.11.0


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

[Xen-devel] [PATCH 3/3] x86/svm: add virtual VMLOAD/VMSAVE support

[brian . woods]

From: Brian Woods 

On AMD family 17h server processors, there is a feature called virtual
VMLOAD/VMSAVE.  This allows a nested hypervisor to preform a VMLOAD or
VMSAVE without needing to be intercepted by the host hypervisor.
Virtual VMLOAD/VMSAVE requires the host hypervisor to be in long mode
and nested page tables to be enabled.  For more information about it
please see:

AMD64 Architecture Programmer’s Manual Volume 2: System Programming
http://support.amd.com/TechDocs/24593.pdf
Section: VMSAVE and VMLOAD Virtualization (Section 15.33.1)

This patch series adds support to check for and enable the virtual
VMLOAD/VMSAVE features if available.

Signed-off-by: Brian Woods 
---
 xen/arch/x86/hvm/svm/svm.c  | 1 +
 xen/arch/x86/hvm/svm/svmdebug.c | 2 ++
 xen/arch/x86/hvm/svm/vmcb.c | 7 +++
 3 files changed, 10 insertions(+)

diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index c8ffb17515..60b1288a31 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1669,6 +1669,7 @@ const struct hvm_function_table * __init start_svm(void)
 P(cpu_has_svm_nrips, "Next-RIP Saved on #VMEXIT");
 P(cpu_has_svm_cleanbits, "VMCB Clean Bits");
 P(cpu_has_svm_decode, "DecodeAssists");
+P(cpu_has_svm_vloadsave, "Virtual VMLOAD/VMSAVE");
 P(cpu_has_pause_filter, "Pause-Intercept Filter");
 P(cpu_has_tsc_ratio, "TSC Rate MSR");
 #undef P
diff --git a/xen/arch/x86/hvm/svm/svmdebug.c b/xen/arch/x86/hvm/svm/svmdebug.c
index 89ef2db932..7145e2f5ca 100644
--- a/xen/arch/x86/hvm/svm/svmdebug.c
+++ b/xen/arch/x86/hvm/svm/svmdebug.c
@@ -55,6 +55,8 @@ void svm_vmcb_dump(const char *from, const struct vmcb_struct 
*vmcb)
vmcb->exitinfo1, vmcb->exitinfo2);
 printk("np_enable = %#"PRIx64" guest_asid = %#x\n",
vmcb_get_np_enable(vmcb), vmcb_get_guest_asid(vmcb));
+printk("virtual vmload/vmsave = %d  virt_ext = %#"PRIx64"\n",
+   vmcb->virt_ext.fields.vloadsave_enable, vmcb->virt_ext.bytes);
 printk("cpl = %d efer = %#"PRIx64" star = %#"PRIx64" lstar = %#"PRIx64"\n",
vmcb_get_cpl(vmcb), vmcb_get_efer(vmcb), vmcb->star, vmcb->lstar);
 printk("CR0 = 0x%016"PRIx64" CR2 = 0x%016"PRIx64"\n",
diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 997e7597e0..cc35d00bb7 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -200,6 +200,13 @@ static int construct_vmcb(struct vcpu *v)
 
 /* PAT is under complete control of SVM when using nested paging. */
 svm_disable_intercept_for_msr(v, MSR_IA32_CR_PAT);
+
+/* use virtual VMLOAD/VMSAVE if available */
+if (cpu_has_svm_vloadsave) {
+vmcb->virt_ext.fields.vloadsave_enable = 1;
+vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMLOAD;
+vmcb->_general2_intercepts &= ~GENERAL2_INTERCEPT_VMSAVE;
+}
 }
 else
 {
-- 
2.11.0


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

[Xen-devel] [qemu-mainline test] 115444: regressions - FAIL

[osstest service owner]

flight 115444 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115444/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  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
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  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-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 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-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [PATCH] gdbsx: prefer privcmd character device

[Elena Ufimtseva]

On Tue, Oct 31, 2017 at 03:25:39PM +, Wei Liu wrote:
> On Tue, Oct 31, 2017 at 10:20:11AM -0500, Doug Goldstein wrote:
> > Prefer using the character device over the proc file if the character
> > device exists.
> > 
> > CC: Elena Ufimtseva 
> > CC: Ian Jackson 
> > CC: Stefano Stabellini 
> > CC: Wei Liu 
> > Signed-off-by: Doug Goldstein 
> > ---
> > So this was originally submitted with 9c89dc95201 and 7d418eab3b6 and
> > was rejected since the goal was to convert gdbsx to use libxc but that
> > hasn't happened. /dev/xen/privcmd should be preferred and this change
> > makes that happen. It would be nice if we landed this with the plan
> > to convert gdbsx happening when it happens.
> 
> Oh well... I think this is fine.
> 
> Elena has the final verdict.

I think this is fine.
I will look into the conversion and relevant discussions if I find them and
see what can be done.

Thanks!

Meanwhile,
Reviewed-by: Elena Ufimtseva 

Elena

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

[Xen-devel] [xen-unstable test] 115419: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-install  fail in 115378 pass in 115419
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 115378 pass 
in 115419
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115378 pass 
in 115419
 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail in 115378 pass in 
115419
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail in 115401 
pass in 115419
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115362
 test-armhf-armhf-xl   6 xen-installfail pass in 115378
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeat  fail pass in 115378
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail pass in 115401

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 13 migrate-support-check fail in 115378 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 115378 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114644
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z   14 days
Failing since114670  2017-10-18 05:03:38 Z   13 days   21 

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Peter Maydell]

On 31 October 2017 at 18:51, Stefano Stabellini  wrote:
> On Tue, 31 Oct 2017, Peter Maydell wrote:
>> On 31 October 2017 at 17:01, Stefano Stabellini  
>> wrote:
>> > Fixing QEMU is harder than I expected. Would it be possible to update
>> > id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?
>>
>> At that point we've already called register_cp_regs_for_features(),
>> which is where we read cpu->id_aa64pfr0 when we're creating the
>> cpreg. So if you change it after that it's too late. But that
>> function is called at CPU realize time, which is before we've
>> created the GIC object...
>
> What about something along the lines of
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index 9e18b41..0851071 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1401,6 +1400,10 @@ static void machvirt_init(MachineState *machine)
>  object_property_set_link(cpuobj, OBJECT(secure_sysmem),
>   "secure-memory", _abort);
>  }
> +if (vms->gic_version == 3) {
> +ARMCPU *cpu = ARM_CPU(cpuobj);
> +cpu->id_aa64pfr0 |= 0x0100;
> +}
>
>  object_property_set_bool(cpuobj, true, "realized", NULL);
>  object_unref(cpuobj);

Definitely not -- the virt board should not be poking about inside the
internals of the CPU object.

The slightly cleaned up version of this idea is that you give the
CPU an object property for "claim the GICv3 registers exist in the
ID registers" and have virt.c set it. That feels like an ugly
workaround for something we really ought not to have to tell the
board about at all, though.

thanks
-- PMM

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

[Xen-devel] [PATCH RFC for-next] x86/mm: introduce and use virt_to_xen_l4e

[Wei Liu]

Avoid open-coding in a lot of places.

No functional change.

Signed-off-by: Wei Liu 
---
Is this patch useful or is open-coding preferred?
---
 xen/arch/x86/mm.c  | 14 +++---
 xen/arch/x86/x86_64/mm.c   | 36 +---
 xen/include/asm-x86/page.h |  5 +
 3 files changed, 29 insertions(+), 26 deletions(-)

diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index a20fdcaea4..cd70aba60c 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -363,7 +363,7 @@ void __init arch_init_memory(void)
 if ( l3tab )
 {
 const l3_pgentry_t *l3idle =
-l4e_to_l3e(idle_pg_table[l4_table_offset(split_va)]);
+l4e_to_l3e(*virt_to_xen_l4e(split_va));
 
 for ( i = 0; i < l3_table_offset(split_va); ++i )
 l3tab[i] = l3idle[i];
@@ -1575,12 +1575,12 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
 
 /* Slot 256: RO M2P (if applicable). */
 l4t[l4_table_offset(RO_MPT_VIRT_START)] =
-ro_mpt ? idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)]
+ro_mpt ? *virt_to_xen_l4e(RO_MPT_VIRT_START)
: l4e_empty();
 
 /* Slot 257: PCI MMCFG. */
 l4t[l4_table_offset(PCI_MCFG_VIRT_START)] =
-idle_pg_table[l4_table_offset(PCI_MCFG_VIRT_START)];
+*virt_to_xen_l4e(PCI_MCFG_VIRT_START);
 
 /* Slot 258: Self linear mappings. */
 ASSERT(!mfn_eq(l4mfn, INVALID_MFN));
@@ -1609,7 +1609,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
 l4_pgentry_t *next;
 
 memcpy([l4_table_offset(XEN_VIRT_START)],
-   _pg_table[l4_table_offset(XEN_VIRT_START)],
+   virt_to_xen_l4e(XEN_VIRT_START),
(ROOT_PAGETABLE_FIRST_XEN_SLOT + root_pgt_pv_xen_slots -
 l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
 
@@ -1629,7 +1629,7 @@ void init_xen_l4_slots(l4_pgentry_t *l4t, mfn_t l4mfn,
   : ROOT_PAGETABLE_XEN_SLOTS);
 
 memcpy([l4_table_offset(XEN_VIRT_START)],
-   _pg_table[l4_table_offset(XEN_VIRT_START)],
+   virt_to_xen_l4e(XEN_VIRT_START),
(ROOT_PAGETABLE_FIRST_XEN_SLOT + slots -
 l4_table_offset(XEN_VIRT_START)) * sizeof(*l4t));
 }
@@ -1643,7 +1643,7 @@ bool fill_ro_mpt(mfn_t mfn)
 if ( !l4e_get_intpte(l4tab[l4_table_offset(RO_MPT_VIRT_START)]) )
 {
 l4tab[l4_table_offset(RO_MPT_VIRT_START)] =
-idle_pg_table[l4_table_offset(RO_MPT_VIRT_START)];
+*virt_to_xen_l4e(RO_MPT_VIRT_START);
 ret = true;
 }
 unmap_domain_page(l4tab);
@@ -4476,7 +4476,7 @@ static l3_pgentry_t *virt_to_xen_l3e(unsigned long v)
 {
 l4_pgentry_t *pl4e;
 
-pl4e = _pg_table[l4_table_offset(v)];
+pl4e = virt_to_xen_l4e(v);
 if ( !(l4e_get_flags(*pl4e) & _PAGE_PRESENT) )
 {
 bool locking = system_state > SYS_STATE_boot;
diff --git a/xen/arch/x86/x86_64/mm.c b/xen/arch/x86/x86_64/mm.c
index 34cd8457cf..87edfe0a7e 100644
--- a/xen/arch/x86/x86_64/mm.c
+++ b/xen/arch/x86/x86_64/mm.c
@@ -133,7 +133,7 @@ static int m2p_mapped(unsigned long spfn)
 l2_pgentry_t *l2_ro_mpt;
 
 va = RO_MPT_VIRT_START + spfn * sizeof(*machine_to_phys_mapping);
-l3_ro_mpt = l4e_to_l3e(idle_pg_table[l4_table_offset(va)]);
+l3_ro_mpt = l4e_to_l3e(*virt_to_xen_l4e(va));
 
 switch ( l3e_get_flags(l3_ro_mpt[l3_table_offset(va)]) &
  (_PAGE_PRESENT |_PAGE_PSE))
@@ -166,7 +166,7 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info 
*info)
   v += n << PAGE_SHIFT )
 {
 n = L2_PAGETABLE_ENTRIES * L1_PAGETABLE_ENTRIES;
-l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
+l3e = l4e_to_l3e(*virt_to_xen_l4e(v))[
 l3_table_offset(v)];
 if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
 continue;
@@ -193,7 +193,7 @@ static int share_hotadd_m2p_table(struct mem_hotadd_info 
*info)
   v != RDWR_COMPAT_MPT_VIRT_END;
   v += 1 << L2_PAGETABLE_SHIFT )
 {
-l3e = l4e_to_l3e(idle_pg_table[l4_table_offset(v)])[
+l3e = l4e_to_l3e(*virt_to_xen_l4e(v))[
 l3_table_offset(v)];
 if ( !(l3e_get_flags(l3e) & _PAGE_PRESENT) )
 continue;
@@ -226,7 +226,7 @@ static void destroy_compat_m2p_mapping(struct 
mem_hotadd_info *info)
 if ( emap > ((RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2) 
)
 emap = (RDWR_COMPAT_MPT_VIRT_END - RDWR_COMPAT_MPT_VIRT_START) >> 2;
 
-l3_ro_mpt = 
l4e_to_l3e(idle_pg_table[l4_table_offset(HIRO_COMPAT_MPT_VIRT_START)]);
+l3_ro_mpt = l4e_to_l3e(*virt_to_xen_l4e(HIRO_COMPAT_MPT_VIRT_START));
 
 
ASSERT(l3e_get_flags(l3_ro_mpt[l3_table_offset(HIRO_COMPAT_MPT_VIRT_START)]) & 
_PAGE_PRESENT);
 
@@ -261,7 +261,7 @@ static void destroy_m2p_mapping(struct mem_hotadd_info 
*info)
 unsigned 

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Stefano Stabellini]

On Tue, 31 Oct 2017, Peter Maydell wrote:
> On 31 October 2017 at 17:01, Stefano Stabellini  
> wrote:
> > Fixing QEMU is harder than I expected. Would it be possible to update
> > id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?
> 
> At that point we've already called register_cp_regs_for_features(),
> which is where we read cpu->id_aa64pfr0 when we're creating the
> cpreg. So if you change it after that it's too late. But that
> function is called at CPU realize time, which is before we've
> created the GIC object...

What about something along the lines of

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 9e18b41..0851071 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1401,6 +1400,10 @@ static void machvirt_init(MachineState *machine)
 object_property_set_link(cpuobj, OBJECT(secure_sysmem),
  "secure-memory", _abort);
 }
+if (vms->gic_version == 3) {
+ARMCPU *cpu = ARM_CPU(cpuobj);
+cpu->id_aa64pfr0 |= 0x0100;
+}
 
 object_property_set_bool(cpuobj, true, "realized", NULL);
 object_unref(cpuobj);

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

Re: [Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

[Wei Liu]

On Tue, Oct 31, 2017 at 01:51:44PM +, Wei Liu wrote:
> First version of this series can be found at [0].
> 
> This version contains workaround for Arndale boards. They are now functional.
> 
> A bunch of test cases failed:
> 
> 1. Rumpkernel tests -- I've sent an email to Antti for advice.
> 2. Windows tests -- They don't look different from normal flights. 
> 3. memdisk-try-append -- Osstest couldn't find some file. I don't think it is
>related to the code I modified.
> 4. guest-localmigrate/x10 for xl-qcow2 test -- Guest kernel bug.
> 5. nested hvm amd, pvhv2 -- Expected failure.
> 
> Example flight:
> http://logs.test-lab.xenproject.org/osstest/logs/115404/
> 
> The armhf d-i failure is fixed with an additional patch ("Skip bootloader
> installaion for arm32 on Stretch) on top of the code for 15404, in:
> 
> http://logs.test-lab.xenproject.org/osstest/logs/115404/

This should be 115433.

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

Re: [Xen-devel] [PATCH v2] xen: support 52 bit physical addresses in pv guests

[Boris Ostrovsky]

On 10/27/2017 01:49 PM, Juergen Gross wrote:
> Physical addresses on processors supporting 5 level paging can be up to
> 52 bits wide. For a Xen pv guest running on such a machine those
> physical addresses have to be supported in order to be able to use any
> memory on the machine even if the guest itself does not support 5 level
> paging.
>
> So when reading/writing a MFN from/to a pte don't use the kernel's
> PTE_PFN_MASK but a new XEN_PTE_MFN_MASK allowing full 40 bit wide MFNs.
>
> Signed-off-by: Juergen Gross 


Applied to for-linus-4.15

-boris


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

Re: [Xen-devel] [PATCH v8 00/13] introduce the Xen PV Calls frontend

[Boris Ostrovsky]

On 10/30/2017 06:40 PM, Stefano Stabellini wrote:
> Hi all,
>
> this series introduces the frontend for the newly introduced PV Calls
> procotol.
>
> PV Calls is a paravirtualized protocol that allows the implementation of
> a set of POSIX functions in a different domain. The PV Calls frontend
> sends POSIX function calls to the backend, which implements them and
> returns a value to the frontend and acts on the function call.
>
> For more information about PV Calls, please read:
>
> https://xenbits.xen.org/docs/unstable/misc/pvcalls.html
>
> This patch series only implements the frontend driver. It doesn't
> attempt to redirect POSIX calls to it. The functions exported in
> pvcalls-front.h are meant to be used for that. A separate patch series
> will be sent to use them and hook them into the system.
>
>
> Changes in v8:
> - cast to uintptr_t instead of uint64_t
> - cast to uintptr_t before casting to struct sock_mapping*
> - check return values of copy_from/to_iter
>
>
> Stefano Stabellini (13):
>   xen/pvcalls: introduce the pvcalls xenbus frontend
>   xen/pvcalls: implement frontend disconnect
>   xen/pvcalls: connect to the backend
>   xen/pvcalls: implement socket command and handle events
>   xen/pvcalls: implement connect command
>   xen/pvcalls: implement bind command
>   xen/pvcalls: implement listen command
>   xen/pvcalls: implement accept command
>   xen/pvcalls: implement sendmsg
>   xen/pvcalls: implement recvmsg
>   xen/pvcalls: implement poll command
>   xen/pvcalls: implement release command
>   xen: introduce a Kconfig option to enable the pvcalls frontend
>
>  drivers/xen/Kconfig |   11 +
>  drivers/xen/Makefile|1 +
>  drivers/xen/pvcalls-front.c | 1277 
> +++
>  drivers/xen/pvcalls-front.h |   28 +
>  4 files changed, 1317 insertions(+)
>  create mode 100644 drivers/xen/pvcalls-front.c
>  create mode 100644 drivers/xen/pvcalls-front.h


Applied to for-linus-4.15

-boris

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

Re: [Xen-devel] [PATCH for-4.10] common/multicall: Increase debugability for bad hypercalls

[Wei Liu]

On Tue, Oct 31, 2017 at 05:18:52PM +, Andrew Cooper wrote:
> While investigating an issue (in a new codepath I'd introduced, as it turns
> out), leaving interrupts disabled manifested as a subsequent op in the
> multicall failing a check_lock() test.
> 
> The codepath would have hit the ASSERT_NOT_IN_ATOMIC on the return-to-guest
> path, had it not hit the check_lock() first.
> 
> Call ASSERT_NOT_IN_ATOMIC() after each operation in the multicall, to make
> failures more obvious.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.10] common/multicall: Increase debugability for bad hypercalls

[George Dunlap]

On 10/31/2017 05:18 PM, Andrew Cooper wrote:
> While investigating an issue (in a new codepath I'd introduced, as it turns
> out), leaving interrupts disabled manifested as a subsequent op in the
> multicall failing a check_lock() test.
> 
> The codepath would have hit the ASSERT_NOT_IN_ATOMIC on the return-to-guest
> path, had it not hit the check_lock() first.
> 
> Call ASSERT_NOT_IN_ATOMIC() after each operation in the multicall, to make
> failures more obvious.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

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

[Xen-devel] [PATCH for-4.10] common/multicall: Increase debugability for bad hypercalls

[Andrew Cooper]

While investigating an issue (in a new codepath I'd introduced, as it turns
out), leaving interrupts disabled manifested as a subsequent op in the
multicall failing a check_lock() test.

The codepath would have hit the ASSERT_NOT_IN_ATOMIC on the return-to-guest
path, had it not hit the check_lock() first.

Call ASSERT_NOT_IN_ATOMIC() after each operation in the multicall, to make
failures more obvious.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 

As with the related check_lock() patch, this only affects debug builds, so is
a very low risk change for 4.10
---
 xen/common/multicall.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/xen/common/multicall.c b/xen/common/multicall.c
index c7af4e0..d98e59d 100644
--- a/xen/common/multicall.c
+++ b/xen/common/multicall.c
@@ -66,6 +66,13 @@ do_multicall(
 
 disp = arch_do_multicall_call(mcs);
 
+/*
+ * In the unlikley event that a hypercall has left interrupts,
+ * spinlocks, or other things in a bad way, continuting the multicall
+ * will typically lead to far more subtle issues to debug.
+ */
+ASSERT_NOT_IN_ATOMIC();
+
 #ifndef NDEBUG
 {
 /*
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Peter Maydell]

On 31 October 2017 at 17:01, Stefano Stabellini  wrote:
> Fixing QEMU is harder than I expected. Would it be possible to update
> id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?

At that point we've already called register_cp_regs_for_features(),
which is where we read cpu->id_aa64pfr0 when we're creating the
cpreg. So if you change it after that it's too late. But that
function is called at CPU realize time, which is before we've
created the GIC object...

thanks
-- PMM

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

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Stefano Stabellini]

On Tue, 31 Oct 2017, Peter Maydell wrote:
> On 19 October 2017 at 15:46, Peter Maydell  wrote:
> > On 18 October 2017 at 01:10, Stefano Stabellini  
> > wrote:
> >> Advertise the presence of the GIC system register interface (1<<24)
> >> according to H9.248 of the ARM ARM.
> >>
> >> This patch allows Xen to boot on QEMU aarch64.
> >>
> >> Signed-off-by: Stefano Stabellini 
> >>
> >> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> >> index 670c07a..a451763 100644
> >> --- a/target/arm/cpu64.c
> >> +++ b/target/arm/cpu64.c
> >> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
> >>  cpu->id_isar3 = 0x01112131;
> >>  cpu->id_isar4 = 0x00011142;
> >>  cpu->id_isar5 = 0x00011121;
> >> -cpu->id_aa64pfr0 = 0x;
> >> +cpu->id_aa64pfr0 = 0x0100;
> >>  cpu->id_aa64dfr0 = 0x10305106;
> >>  cpu->pmceid0 = 0x;
> >>  cpu->pmceid1 = 0x;
> >> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
> >>  cpu->id_isar3 = 0x01112131;
> >>  cpu->id_isar4 = 0x00011142;
> >>  cpu->id_isar5 = 0x00011121;
> >> -cpu->id_aa64pfr0 = 0x;
> >> +cpu->id_aa64pfr0 = 0x0100;
> >>  cpu->id_aa64dfr0 = 0x10305106;
> >>  cpu->id_aa64isar0 = 0x00011120;
> >>  cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */
> >
> > Whoops -- we missed this when we added the GICv3 support, because
> > Linux doesn't check it.
> >
> > Applied to target-arm.next, thanks.
> 
> Unfortunately I've just noticed that this breaks booting Linux
> in the "not using gicv3" case. This is because we don't actually
> define the GICv3 cpu interface registers unless the board
> instantiates a GICv3. We mustn't advertise the GICv3 sysregs
> in the ID register unless we actually have them.
> 
> Not sure how best to fix this -- it's a consequence of the
> design decision we made to have the sysregs implementation
> be in the gicv3 code. There's no useful feature bit in the CPU
> to hang this off either, it's an effect of whether the board
> model happens to wire up a gicv3 or not. So we can only figure
> this out fairly late on (probably at CPU reset time), which
> is a bit tedious for getting ID reg values right.
> 
> In the meantime I've dropped this patch from target-arm.next.

Fixing QEMU is harder than I expected. Would it be possible to update
id_aa64pfr0 at CPU reset time? Like cpu->id_aa64pfr0 |= 0x0100; ?

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

Re: [Xen-devel] Commit moratorium to staging

[Roger Pau Monné]

On Tue, Oct 31, 2017 at 10:49:35AM +, Julien Grall wrote:
> Hi all,
> 
> Master lags 15 days behind staging due to tests failing reliably on some of
> the hardware in osstest (see [1]).
> 
> At the moment a force push is not feasible because the same tests passes on
> different hardware (see [2]).

I've been looking into this, and I'm afraid I don't yet have a cause
for those issues. I'm going to post what I've found so far, maybe
someone is able to spot something I'm missing.

Since I assumed this was somehow related to the ACPI PM1A_STS/EN
blocks (which is how the power button even gets notified to the OS),
I've added the following instrumentation to the pmtimer.c code:

diff --git a/xen/arch/x86/hvm/pmtimer.c b/xen/arch/x86/hvm/pmtimer.c
index 435647ff1e..051fc46df8 100644
--- a/xen/arch/x86/hvm/pmtimer.c
+++ b/xen/arch/x86/hvm/pmtimer.c
@@ -61,9 +61,15 @@ static void pmt_update_sci(PMTState *s)
 ASSERT(spin_is_locked(>lock));
 
 if ( acpi->pm1a_en & acpi->pm1a_sts & SCI_MASK )
+{
+printk("asserting SCI IRQ\n");
 hvm_isa_irq_assert(s->vcpu->domain, SCI_IRQ, NULL);
+}
 else
+{
+printk("de-asserting SCI IRQ\n");
 hvm_isa_irq_deassert(s->vcpu->domain, SCI_IRQ);
+}
 }
 
 void hvm_acpi_power_button(struct domain *d)
@@ -73,6 +79,7 @@ void hvm_acpi_power_button(struct domain *d)
 if ( !has_vpm(d) )
 return;
 
+printk("hvm_acpi_power_button for d%d\n", d->domain_id);
 spin_lock(>lock);
 d->arch.hvm_domain.acpi.pm1a_sts |= PWRBTN_STS;
 pmt_update_sci(s);
@@ -86,6 +93,7 @@ void hvm_acpi_sleep_button(struct domain *d)
 if ( !has_vpm(d) )
 return;
 
+printk("hvm_acpi_sleep_button for d%d\n", d->domain_id);
 spin_lock(>lock);
 d->arch.hvm_domain.acpi.pm1a_sts |= PWRBTN_STS;
 pmt_update_sci(s);
@@ -170,6 +178,7 @@ static int handle_evt_io(
 
 if ( dir == IOREQ_WRITE )
 {
+printk("write PM1a addr: %#x val: %#x\n", addr, *val);
 /* Handle this I/O one byte at a time */
 for ( i = bytes, data = *val;
   i > 0;
@@ -197,6 +206,8 @@ static int handle_evt_io(
  bytes, *val, port);
 }
 }
+printk("result pm1a_sts: %#x pm1a_en: %#x\n",
+  acpi->pm1a_sts, acpi->pm1a_en);
 /* Fix up the SCI state to match the new register state */
 pmt_update_sci(s);
 }

I've then rerun the failing test, and this is what I got in the
failure case (ie: windows ignoring the power event):

(XEN) hvm_acpi_power_button for d14
(XEN) asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0x1
(XEN) result pm1a_sts: 0x100 pm1a_en: 0x320
(XEN) asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0x100
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ
(XEN) write PM1a addr: 0x2 val: 0x320
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ

Strangely enough, the second time I've tried the same command (xl
shutdown -wF ...) on the same guest, it succeed and windows shut down
without issues, this is the log in that case:

(XEN) hvm_acpi_power_button for d14
(XEN) asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0x1
(XEN) result pm1a_sts: 0x100 pm1a_en: 0x320
(XEN) asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0x100
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ
(XEN) write PM1a addr: 0x2 val: 0x320
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ
(XEN) write PM1a addr: 0x2 val: 0x320
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ
(XEN) write PM1a addr: 0 val: 0x8000
(XEN) result pm1a_sts: 0 pm1a_en: 0x320
(XEN) de-asserting SCI IRQ

I have to admit I have no idea why Windows clears the STS power bit
and then completely ignores it on certain occasions.

I'm also afraid I have no idea how to debug Windows in order to know
why this event is acknowledged but ignored.

I've also tried to reproduce the same with a Debian guest, by doing
the same amount of save/restores and migrations, and finally issuing a
xl trigger  power, but Debian has always worked fine and
shut down.

Any comments are welcome.

Roger.

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

[Xen-devel] [qemu-mainline test] 115431: regressions - FAIL

[osstest service owner]

flight 115431 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115431/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  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
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  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-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 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-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [PATCH 5/5] docs: add PV sound device config

[Oleksandr Grytsov]

On Mon, Oct 30, 2017 at 8:00 PM, Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:

> On Mon, Oct 02, 2017 at 12:49:24PM +0300, Oleksandr Grytsov wrote:
> > +=item 

Re: [Xen-devel] [PATCH] gdbsx: prefer privcmd character device

[Wei Liu]

On Tue, Oct 31, 2017 at 10:20:11AM -0500, Doug Goldstein wrote:
> Prefer using the character device over the proc file if the character
> device exists.
> 
> CC: Elena Ufimtseva 
> CC: Ian Jackson 
> CC: Stefano Stabellini 
> CC: Wei Liu 
> Signed-off-by: Doug Goldstein 
> ---
> So this was originally submitted with 9c89dc95201 and 7d418eab3b6 and
> was rejected since the goal was to convert gdbsx to use libxc but that
> hasn't happened. /dev/xen/privcmd should be preferred and this change
> makes that happen. It would be nice if we landed this with the plan
> to convert gdbsx happening when it happens.

Oh well... I think this is fine.

Elena has the final verdict.

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

[Xen-devel] [PATCH] gdbsx: prefer privcmd character device

[Doug Goldstein]

Prefer using the character device over the proc file if the character
device exists.

CC: Elena Ufimtseva 
CC: Ian Jackson 
CC: Stefano Stabellini 
CC: Wei Liu 
Signed-off-by: Doug Goldstein 
---
So this was originally submitted with 9c89dc95201 and 7d418eab3b6 and
was rejected since the goal was to convert gdbsx to use libxc but that
hasn't happened. /dev/xen/privcmd should be preferred and this change
makes that happen. It would be nice if we landed this with the plan
to convert gdbsx happening when it happens.
---
 tools/debugger/gdbsx/xg/xg_main.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/debugger/gdbsx/xg/xg_main.c 
b/tools/debugger/gdbsx/xg/xg_main.c
index 7ebf91435b..cc640d1d82 100644
--- a/tools/debugger/gdbsx/xg/xg_main.c
+++ b/tools/debugger/gdbsx/xg/xg_main.c
@@ -126,9 +126,11 @@ xg_init()
 int flags, saved_errno;
 
 XGTRC("E\n");
-if ((_dom0_fd=open("/proc/xen/privcmd", O_RDWR)) == -1) {
-perror("Failed to open /proc/xen/privcmd\n");
-return -1;
+if ((_dom0_fd=open("/dev/xen/privcmd", O_RDWR)) == -1) {
+if ((_dom0_fd=open("/proc/xen/privcmd", O_RDWR)) == -1) {
+perror("Failed to open /dev/xen/privcmd or /proc/xen/privcmd\n");
+return -1;
+}
 }
 /* Although we return the file handle as the 'xc handle' the API
  * does not specify / guarentee that this integer is in fact
-- 
2.13.6


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

Re: [Xen-devel] [PATCH 1/5] libxl: add PV sound device

[Oleksandr Grytsov]

On Mon, Oct 30, 2017 at 7:39 PM, Wei Liu  wrote:

> On Mon, Oct 02, 2017 at 12:49:20PM +0300, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > Add PV sound device described in sndif.h
> >
> > Signed-off-by: Oleksandr Grytsov 
>
> [...]
> >
> >  libxl__console_backend = Enumeration("console_backend", [
> > diff --git a/tools/libxl/libxl_vsnd.c b/tools/libxl/libxl_vsnd.c
> > new file mode 100644
> > index 000..26885f9
> > --- /dev/null
> > +++ b/tools/libxl/libxl_vsnd.c
> > @@ -0,0 +1,307 @@
> > +/*
> > + * Copyright (C) 2016 EPAM Systems Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as
> published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU Lesser General Public License for more details.
> > + */
> > +
> > +#include "libxl_internal.h"
> > +#include "xen/io/sndif.h"
> > +
>
> Use  -- this is not a local header.
>
> > +
> > +static unsigned int libxl__rates_to_str_vsnd(char *str, uint32_t
> *sample_rates,
> > + int num_sample_rates)
> > +{
> > +unsigned int len;
> > +int i;
> > +
> > +len = 0;
> > +
> > +if (num_sample_rates == 0) {
> > +return len;
> > +}
>
> Coding style.
>
> > +
> > +for (i = 0; i < num_sample_rates - 1; i++) {
> > +if (str) {
> > +len += sprintf([len], "%u,", sample_rates[i]);
>
> libxl__sprintf(NOGC, ...)
>

I need to increment len here. So libxl__sprintf is not suitable.


>
> > +} else {
> > +len += snprintf(NULL, 0, "%u,", sample_rates[i]);
> > +}
> > +}
> > +
> > +if (str) {
> > +len += sprintf([len], "%u", sample_rates[i]);
> > +} else {
> > +len += snprintf(NULL, 0, "%u", sample_rates[i]);
> > +}
> > +
> > +return len;
> > +}
> > +
> [...]
> > +
> > +static int libxl__set_params_vsnd(libxl__gc *gc, char *path,
> > +  libxl_vsnd_params *params,
> flexarray_t *front)
> > +{
> > +char *buffer;
> > +int len;
> > +int rc;
> > +
> > +if (params->sample_rates) {
> > +// calculate required string size;
>
> Coding style.
>
> > +len = libxl__rates_to_str_vsnd(NULL, params->sample_rates,
> > +   params->num_sample_rates);
> > +
> > +if (len) {
> > +buffer = libxl__malloc(gc, len + 1);
> > +
> > +libxl__rates_to_str_vsnd(buffer, params->sample_rates,
> > + params->num_sample_rates);
> > +rc = flexarray_append_pair(front,
> > +   GCSPRINTF("%s"XENSND_FIELD_
> SAMPLE_RATES,
> > + path), buffer);
> > +if (rc) return rc;
>
> goto out please.
>
> Please fix these coding style issues throughout this series.j
>



-- 
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/5] libxl: add PV sound device

[Wei Liu]

On Tue, Oct 31, 2017 at 04:51:48PM +0200, Oleksandr Grytsov wrote:
> > > +
> > > +if (params->sample_rates) {
> > > +// calculate required string size;
> >
> > Coding style.
> 
> 
> Sorry, could you specify more precisely what has to be changed in this
> place?
> 

We use /* ... */ for comments.

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

Re: [Xen-devel] [PATCH 1/5] libxl: add PV sound device

[Oleksandr Grytsov]

On Mon, Oct 30, 2017 at 7:39 PM, Wei Liu  wrote:

> On Mon, Oct 02, 2017 at 12:49:20PM +0300, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > Add PV sound device described in sndif.h
> >
> > Signed-off-by: Oleksandr Grytsov 
>
> [...]
> >
> >  libxl__console_backend = Enumeration("console_backend", [
> > diff --git a/tools/libxl/libxl_vsnd.c b/tools/libxl/libxl_vsnd.c
> > new file mode 100644
> > index 000..26885f9
> > --- /dev/null
> > +++ b/tools/libxl/libxl_vsnd.c
> > @@ -0,0 +1,307 @@
> > +/*
> > + * Copyright (C) 2016 EPAM Systems Inc.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU Lesser General Public License as
> published
> > + * by the Free Software Foundation; version 2.1 only. with the special
> > + * exception on linking described in file LICENSE.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU Lesser General Public License for more details.
> > + */
> > +
> > +#include "libxl_internal.h"
> > +#include "xen/io/sndif.h"
> > +
>
> Use  -- this is not a local header.
>
> > +
> > +static unsigned int libxl__rates_to_str_vsnd(char *str, uint32_t
> *sample_rates,
> > + int num_sample_rates)
> > +{
> > +unsigned int len;
> > +int i;
> > +
> > +len = 0;
> > +
> > +if (num_sample_rates == 0) {
> > +return len;
> > +}
>
> Coding style.
>
> > +
> > +for (i = 0; i < num_sample_rates - 1; i++) {
> > +if (str) {
> > +len += sprintf([len], "%u,", sample_rates[i]);
>
> libxl__sprintf(NOGC, ...)
>
> > +} else {
> > +len += snprintf(NULL, 0, "%u,", sample_rates[i]);
> > +}
> > +}
> > +
> > +if (str) {
> > +len += sprintf([len], "%u", sample_rates[i]);
> > +} else {
> > +len += snprintf(NULL, 0, "%u", sample_rates[i]);
> > +}
> > +
> > +return len;
> > +}
> > +
> [...]
> > +
> > +static int libxl__set_params_vsnd(libxl__gc *gc, char *path,
> > +  libxl_vsnd_params *params,
> flexarray_t *front)
> > +{
> > +char *buffer;
> > +int len;
> > +int rc;
> > +
> > +if (params->sample_rates) {
> > +// calculate required string size;
>
> Coding style.


Sorry, could you specify more precisely what has to be changed in this
place?


>
> > +len = libxl__rates_to_str_vsnd(NULL, params->sample_rates,
> > +   params->num_sample_rates);
> > +
> > +if (len) {
> > +buffer = libxl__malloc(gc, len + 1);
> > +
> > +libxl__rates_to_str_vsnd(buffer, params->sample_rates,
> > + params->num_sample_rates);
> > +rc = flexarray_append_pair(front,
> > +   GCSPRINTF("%s"XENSND_FIELD_
> SAMPLE_RATES,
> > + path), buffer);
> > +if (rc) return rc;
>
> goto out please.
>
> Please fix these coding style issues throughout this series.j
>



-- 
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [linux-linus test] 115414: regressions - FAIL

[osstest service owner]

flight 115414 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115414/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-xsm  6 xen-install  fail REGR. vs. 114682
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114682

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114682
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114682
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114682
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114682
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 114682
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114682
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114682
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass

version targeted for testing:
 linux5f479447d983111c039f1d6d958553c1ad1b2ff1
baseline version:
 linuxebe6e90ccc6679cb01d2b280e4b61e6092d4bedb

Last test of basis   114682  2017-10-18 09:54:11 Z   13 days
Failing since114781  2017-10-20 01:00:47 Z   11 days   19 attempts
Testing same since   115414  2017-10-31 03:43:24 Z0 days1 attempts


422 people touched revisions under test,
not listing them all

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 

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 10/31/2017 5:03 AM, Goel, Sameer wrote:

On 10/12/2017 3:03 PM, Manish Jaggi wrote:

ACPI/IORT Support in Xen.
--

I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending the scope
and including all that is required to support ACPI/IORT in Xen. Presenting for 
review
first _draft_ of design of ACPI/IORT support in Xen. Not complete though.

Discussed is the parsing and generation of IORT table for Dom0 and DomUs.
It is proposed that IORT be parsed and the information in saved into xen 
data-structure
say host_iort_struct and is reused by all xen subsystems like ITS / SMMU etc.

Since this is first draft is open to technical comments, modifications
and suggestions. Please be open and feel free to add any missing points / 
additions.

1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Future Work and TODOs

1. What is IORT. What are its components ?

IORT refers to Input Output remapping table. It is essentially used to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships between
devices.

A general structure of IORT is has nodes which have information about PCI RC,
SMMU, ITS and Platform devices. Using an IORT table relationship between
RID -> StreamID -> DeviceId can be obtained. More specifically which device is
behind which SMMU and which interrupt controller, this topology is described in
IORT Table.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

For a non-pci device RID could be simply an ID.

Each iort_node contains an ID map array to translate from one ID into another.
IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is present in PCI RC node,SMMU node, Named component node etc
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---
Currently Xen passes host IORT table to dom0 without any modifications.
For DomU no IORT table is passed.

3. IORT for Dom0
-
IORT for Dom0 is prepared by xen and it is fairly similar to the host iort.
However few nodes could be removed removed or modified. For instance
- host SMMU nodes should not be present
- ITS group nodes are same as host iort but, no stage2 mapping is done for them.
- platform nodes (named components) may be selectively present depending on the
case where xen is using some. This could be controlled by  xen command line.
- More items : TODO

4. IORT for DomU
---
  

IORT for DomU is generated by the toolstack. IORT topology is different when
DomU supports device passthrough.

At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
Additional node can be added if platform device is assigned to domU.
No extra node should be required for PCI device pass-through.

It is proposed that the idrange of PCIRC and ITS group be constant for domUs.
In case if PCI PT,using a domctl toolstack can communicate
physical RID: virtual RID, deviceID: virtual deviceID to xen.

It is assumed that domU PCI Config access would be trapped in Xen. The RID at
which assigned device is enumerated would be the one provided by the domctl,
domctl_set_deviceid_mapping

TODO: device assign domctl i/f.

Note: This should suffice the virtual deviceID support pointed by Andre. [4]
We might not need this domctl if assign_device hypercall is extended to provide 
this information.

5. Parsing of IORT in Xen
--

I think a Linux like approach will solve the following use cases:
1. Identify the SMMU devices and initialize the devices as needed.
2. API function to setup SMMUs in response to a discovery notification from DOM0
- We will still need a path for non pcie devices.
- I agree with Andre that the use cases for the named nodes in IORT should 
be treated the same as PCIe RC devices.
3. The concept of fwnode is still valid as per 4.14 and we can try reuse most 
of the parsing code.

The idea is parse one use at multiple places.
- IORT creation for Dom0
- smmu init
- finding smmu for a deviceID when pci_assign_device is called by dom0


Manish, I looked at your old patch and had a couple of questions before I 
comment more on this design. From an initial
glance, it seems that you should be able to hide SMMUs by calling the already 
defined API functions in the iort.c implementation
(for most part :)).

Yes some of the parsing functions can be replaced with APIs.



I am wondering if we really need to keep a list of parsed nodes. Or which use 
case apart from hw dom IORT mandates this?
For all cases I believe where a mapping lookup of Devid-smmu-pcirc is 
required.

IORT nodes can be saved in structures so that IORT table parsing can be done
once and is reused by all xen subsystems like ITS / SMMU etc, domain 

[Xen-devel] [OSSTEST PATCH v2 10/19] ts-debian-fixup: use correct resume device

[Wei Liu]

See code comment for explanation.

Signed-off-by: Wei Liu 
---
 ts-debian-fixup | 12 
 1 file changed, 12 insertions(+)

diff --git a/ts-debian-fixup b/ts-debian-fixup
index 288766d..9a63c61 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -175,6 +175,18 @@ sub otherfixupcfg () {
 $extra .= " iommu=soft";
 }
 
+# There might be stale entries in /etc/initramfs-tools/conf.d/resume which
+# get stored in the initramfs. That introduces delay in guest booting which
+# might cause tests to fail.
+#
+# This is particularly prominent in stretch when it tries to scan for the
+# inexistent device(s) for a long time. See also Debian bug #784810.
+#
+# Override that in kernel command line with the correct swap partition.
+$cfg =~ m/'phy:.+-swap,(xvda\d+),.*'/;
+$extra .= " resume=/dev/$1";
+logm("change resume device to $1");
+
 $cfg =~ s/^extra\s*=\s*['"](.*)['"]/extra = '$1 $extra'/mg;
 };
 
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 12/19] ts-xen-build-prep: install e2fslibs-dev

[Wei Liu]

The in-tree libfsimage ext2fs implementation can't handle 64bit
enabled ext4, which is the default in stretch.

Installing e2fslibs-dev causes libfsimage to pick up the packaged
ext2fs implementation.

Signed-off-by: Wei Liu 
---
 ts-xen-build-prep | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 80bfb30..8b4b08a 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -225,6 +225,12 @@ sub prep () {
 push(@packages, qw(texinfo autopoint libpciaccess-dev));
 }
 
+# The in-tree ext4 support in libfsimage can't cope with 64bit ext4 on
+# 32bit build. Use the packaged library.
+if ($ho->{Suite} !~ m/squeeze|wheezy|jessie/) {
+push(@packages, qw(e2fslibs-dev));
+}
+
 target_install_packages($ho, @packages);
 target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
 # workaround for Debian #595728
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 15/19] Add clk_ignore_unused for stretch for arm hosts

[Wei Liu]

Without that parameter we lose uart output.

Signed-off-by: Wei Liu 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index e7fb020..2bfd5ae 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -240,7 +240,7 @@ END
push @xenkopt, $xenkopt;
# http://bugs.xenproject.org/xen/bug/45
push @xenkopt, "clk_ignore_unused"
-   if $ho->{Suite} =~ m/wheezy|jessie/;
+   if $ho->{Suite} =~ m/wheezy|jessie|stretch/;
 
$xenkopt = join ' ', @xenkopt;
logm("Dom0 Linux options: $xenkopt");
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 19/19] Switch to Debian Stretch

[Wei Liu]

Signed-off-by: Wei Liu 
---
 Osstest.pm| 2 +-
 production-config | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Osstest.pm b/Osstest.pm
index ceb62ca..f2e4dfa 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -86,7 +86,7 @@ our %c = qw(
 
 Images images
 
-DebianSuite jessie
+DebianSuite stretch
 DebianMirrorSubpath debian
 
 TestHostKeypairPath id_rsa_osstest
diff --git a/production-config b/production-config
index 0e6a51e..251d82f 100644
--- a/production-config
+++ b/production-config
@@ -93,10 +93,12 @@ TftpNetbootGroup osstest
 # Update with ./mg-debian-installer-update(-all)
 TftpDiVersion_wheezy 2016-06-08
 TftpDiVersion_jessie 2017-04-06
+TftpDiVersion_stretch 2017-10-11
 
 # For ISO installs
 DebianImageVersion_wheezy 7.2.0
 DebianImageVersion_jessie 8.2.0
+DebianImageVersion_stretch 9.2.1
 
 # These should normally be the same.
 # Update with ./mg-cpu-microcode-update
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 13/19] TestSupport: add dpkg option when installing packages

[Wei Liu]

Upgrading configuration file of nbd-client is controlled by dpkg in
stretch. Add dpkg option to keep old configuration file(s).

Signed-off-by: Wei Liu 
---
 Osstest/TestSupport.pm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 6d5e667..238be9e 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -527,7 +527,8 @@ sub target_run_apt {
 my ($ho, @aptopts) = @_;
 target_cmd_root($ho,
 "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \\
-with-lock-ex -w /var/lock/osstest-apt apt-get @aptopts", 3000);
+with-lock-ex -w /var/lock/osstest-apt \\
+apt-get -o Dpkg::Options::=\"--force-confold\" @aptopts", 3000);
 }
 sub target_install_packages {
 my ($ho, @packages) = @_;
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 17/19] Skip bootloader installation for arm32 in Stretch

[Wei Liu]

Signed-off-by: Wei Liu 
---
 Osstest/Debian.pm | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 2c3bcf4..b2d5007 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1027,6 +1027,11 @@ END
$preseed_file.= (<

[Xen-devel] [OSSTEST PATCH v2 16/19] Set mac address in interfaces(5) if force-mac-address is set

[Wei Liu]

ff9e0d8cbd generated a udev rule for setting the mac address. But that
udev rule is not copied into the target so reboot after installation
will fail.

We can copy the udev rule to target system so the reboot after
installation works, but then the generated udev rules will end up in
initramfs, which means the guest (which uses host's initrd)  will use
the same rune to set conflicting mac address.

Put the mac address in interfaces(5). We still need to keep the udev
rule for the initrd overlay otherwise host installation will fail.

Signed-off-by: Wei Liu 
---
 Osstest/Debian.pm | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 2bfd5ae..2c3bcf4 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1207,6 +1207,16 @@ END
preseed_hook_command($ho, 'late_command', $sfx, $cmds);
 }
 
+my $wantphysif= get_host_property($ho,'interface force','auto');
+if ($wantphysif ne 'auto' && $ho->{Flags}{'force-mac-address'}) {
+   preseed_hook_command($ho, 'late_command', $sfx, <{Ether}/' /target/etc/network/interfaces
+END
+}
+
 if ( $ho->{Flags}{'need-uboot-bootscr'} ) {
my @bootargs = uboot_common_kernel_bootargs($ho);
 
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 18/19] make-flight: don't test pvgrub for Xen XXX

[Wei Liu]

XXX Need to pin down the version of Xen when the upgrade to stretch is
complete because osstest configuration is branched for each version.

Signed-off-by: Wei Liu 
---
 make-flight | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/make-flight b/make-flight
index 76620c1..b0f1e69 100755
--- a/make-flight
+++ b/make-flight
@@ -827,7 +827,22 @@ test_matrix_do_one () {
   #do_passthrough_tests
 
   do_pygrub_tests
-  do_pvgrub_tests
+
+  # pvgrub1 tests for version < XXX only
+  case "$xenbranch" in
+  xen-4.3-testing) test_pvgrub=y ;;
+  xen-4.4-testing) test_pvgrub=y ;;
+  xen-4.5-testing) test_pvgrub=y ;;
+  xen-4.6-testing) test_pvgrub=y ;;
+  xen-4.7-testing) test_pvgrub=y ;;
+  xen-4.8-testing) test_pvgrub=y ;;
+  xen-4.9-testing) test_pvgrub=y ;;
+  *)   test_pvgrub=n ;;
+  esac
+
+  if [ x$test_pvgrub = xy ]; then
+  do_pvgrub_tests
+  fi
 
   do_xtf_tests
   do_livepatch_tests
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 11/19] ts-debian-hvm-install: disable new nic naming scheme

[Wei Liu]

This is required to fix nested hvm test. The L1 host is installed by
this script. We want the L1 host to not use the new nic naming scheme.

Signed-off-by: Wei Liu 
---
 ts-debian-hvm-install | 13 +
 1 file changed, 13 insertions(+)

diff --git a/ts-debian-hvm-install b/ts-debian-hvm-install
index 54d5d1c..afe8dc9 100755
--- a/ts-debian-hvm-install
+++ b/ts-debian-hvm-install
@@ -114,6 +114,19 @@ set -ex
 in-target sed -i 's/^deb *cdrom/#&/g' /etc/apt/sources.list
 END
 
+# Do not use "Predictable Network Interface Names" -- this can break
+# nested HVM tests.
+# 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
+#
+# See also
+# https://www.debian.org/releases/stretch/example-preseed.txt
+my $netifnames = "";
+$netifnames = <{Suite} =~ m/stretch/;
+d-i debian-installer/add-kernel-opts string net.ifnames=0
+END
+
+$preseed_file .= "$netifnames";
+
 $preseed_file .= preseed_hook_cmds();
 
 return $preseed_file;
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 14/19] ts-guests-nbd-mirror: make it work with stretch

[Wei Liu]

On the server side, only add oldstyle= and port= on Wheezy and Jessie.
Stretch doesn't support or need those anymore.

On the client side, generate new style configuration file.

Signed-off-by: Wei Liu 
---
 ts-guests-nbd-mirror | 47 +++
 1 file changed, 43 insertions(+), 4 deletions(-)

diff --git a/ts-guests-nbd-mirror b/ts-guests-nbd-mirror
index 3032204..7bcc02c 100755
--- a/ts-guests-nbd-mirror
+++ b/ts-guests-nbd-mirror
@@ -60,15 +60,19 @@ sub configserver () {
 [generic]
 user = root
 END
-$scfg .= <{Suite} =~ m/sarge|lenny|squeeze/;
+
+$scfg .= <{Suite} =~ m/wheezy|jessie/;
 oldstyle = true
 END
+
 foreach my $v (@vols) {
$v->{Port}= unique_incrementing_runvar("${srvhost}_nextport",4000);
$v->{Path}= "/dev/$v->{Gho}{Vg}/$v->{Lv}";
$scfg.=<{Ix}]
 exportname = $v->{Path}
+END
+   $scfg.=<{Suite} =~ m/wheezy|jessie/;
 port = $v->{Port}
 END
 }
@@ -79,9 +83,7 @@ END
 target_install_packages($sho, qw(nbd-server));
 }
 
-sub configclient () {
-target_cmd_root($cho, "dpkg --purge nbd-client ||:");
-
+sub configclient_pre_stretch () {
 my $mydaemon= '/root/nbd-client-async';
 target_putfilecontents_root_stash($cho,10,<<'END',$mydaemon);
 #!/bin/sh
@@ -107,7 +109,44 @@ NBD_PORT[$v->{Ix}]=$v->{Port}
 END
 }
 target_putfilecontents_root_stash($cho,10,$ccfg,"/etc/nbd-client");
+}
+
+sub configclient_stretch () {
+my $ccfg = <{Name} export$v->{Ix}
+END
+}
+
+target_putfilecontents_root_stash($cho,10,$ccfg,"/etc/nbdtab");
+}
+
+sub configclient () {
+target_cmd_root($cho, "dpkg --purge nbd-client ||:");
+
+if ($cho->{Suite} !~ m/stretch/) {
+configclient_pre_stretch();
+} else {
+configclient_stretch();
+}
+
 target_install_packages($cho, qw(nbd-client));
+
+if ($cho->{Suite} !~ m/squeeze|wheezy|jessie/) {
+   foreach my $v (@vols) {
+   my $nbddev = "nbd$v->{Ix}";
+   target_cmd_root($cho, <{Gho}{Vg}
+if ! test -L $v->{Path}; then ln -s /dev/$nbddev $v->{Path}; fi
+END
+   }
+   target_cmd_root($cho, "/etc/init.d/nbd-client start");
+}
 }
 
 sub shuffleconfigs () {
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 03/19] ts-xen-build-prep: install packages for suites >jessie

[Wei Liu]

Stubdom build needs texinfo.

Libvirt build needs autopoint.

QEMU build needs libpciaccess-dev.

Signed-off-by: Wei Liu 
---
 ts-xen-build-prep | 4 
 1 file changed, 4 insertions(+)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 7718cff..80bfb30 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -221,6 +221,10 @@ sub prep () {
# jessie (>jessie?)
push(@packages, "libnl-route-3-dev");
 }
+if ($ho->{Suite} !~ m/squeeze|wheezy|jessie/) {
+push(@packages, qw(texinfo autopoint libpciaccess-dev));
+}
+
 target_install_packages($ho, @packages);
 target_cmd_root($ho, "chmod -R a+r /usr/share/git-core/templates");
 # workaround for Debian #595728
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 08/19] ts-guests-nbd-mirror: use target_{get, put}file_root to transfter cfg

[Wei Liu]

The original code used target_cmd_output_root which caused a trailing
new line to be deleted, which caused libvirt converter to fail.

It wasn't discovered until now because we appended too many "\n".

Use target_{get,put}file_root to do the job.

Signed-off-by: Wei Liu 
---
 ts-guests-nbd-mirror | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/ts-guests-nbd-mirror b/ts-guests-nbd-mirror
index ca8300d..3032204 100755
--- a/ts-guests-nbd-mirror
+++ b/ts-guests-nbd-mirror
@@ -115,8 +115,11 @@ sub shuffleconfigs () {
my $gn= $gns[$i];
my $gho= $ghos[$i];
my $cfgpath= $r{ "$gho->{Guest}_cfgpath" };
-   my $cfgdata= target_cmd_output_root($sho,"cat $cfgpath");
-   target_putfilecontents_root_stash($cho,10,$cfgdata,$cfgpath);
+   my $file= $cfgpath;
+   $file=~ s,/,-,g;
+   $file= "$stash/".hostnamepath($cho)."--$file";
+   target_getfile_root($sho, 60, $cfgpath, $file);
+   target_putfile_root($cho, 60, $file, $cfgpath);
 }
 }
 
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 00/19] Upgrade to Stretch

[Wei Liu]

First version of this series can be found at [0].

This version contains workaround for Arndale boards. They are now functional.

A bunch of test cases failed:

1. Rumpkernel tests -- I've sent an email to Antti for advice.
2. Windows tests -- They don't look different from normal flights. 
3. memdisk-try-append -- Osstest couldn't find some file. I don't think it is
   related to the code I modified.
4. guest-localmigrate/x10 for xl-qcow2 test -- Guest kernel bug.
5. nested hvm amd, pvhv2 -- Expected failure.

Example flight:
http://logs.test-lab.xenproject.org/osstest/logs/115404/

The armhf d-i failure is fixed with an additional patch ("Skip bootloader
installaion for arm32 on Stretch) on top of the code for 15404, in:

http://logs.test-lab.xenproject.org/osstest/logs/115404/

Cc: Julien Grall 

[0] <20171020103840.32762-1-wei.l...@citrix.com>

Wei Liu (19):
  gitignore: ignore vim swap file
  ts-xen-build-prep: only install w3c-dtd-xhtml for suites jessie
  ts-xen-install: install some packages on stretch
  Debian.pm: use sysvinit-core instead of systemd
  ts-leak-check: suppress systemd-shim, which leaks in stretch
  ts-host-install: don't use the new nic naming scheme
  ts-guests-nbd-mirror: use target_{get,put}file_root to transfter cfg
  ts-debian-fixup: merge origin extra= to our own
  ts-debian-fixup: use correct resume device
  ts-debian-hvm-install: disable new nic naming scheme
  ts-xen-build-prep: install e2fslibs-dev
  TestSupport: add dpkg option when installing packages
  ts-guests-nbd-mirror: make it work with stretch
  Add clk_ignore_unused for stretch for arm hosts
  Set mac address in interfaces(5) if force-mac-address is set
  Skip bootloader installation for arm32 in Stretch
  make-flight: don't test pvgrub for Xen XXX
  Switch to Debian Stretch

 .gitignore |  1 +
 Osstest.pm |  2 +-
 Osstest/Debian.pm  | 19 --
 Osstest/TestSupport.pm |  3 ++-
 make-flight| 17 +++-
 production-config  |  2 ++
 ts-debian-fixup| 14 -
 ts-debian-hvm-install  | 13 
 ts-guests-nbd-mirror   | 54 --
 ts-host-install|  4 
 ts-leak-check  |  1 +
 ts-xen-build-prep  | 15 +-
 ts-xen-install |  3 +++
 13 files changed, 135 insertions(+), 13 deletions(-)

-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 01/19] gitignore: ignore vim swap file

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 425506b..f7e5b77 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
 *~
 *.bak
+*.swp
 tmp
 *.tmp
 bisection.ps
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 02/19] ts-xen-build-prep: only install w3c-dtd-xhtml for suites

[Wei Liu]

That package is not included in Stretch.

That package was installed because libvirt build needed it. However
libvirt builds fine without it in Stretch.

Signed-off-by: Wei Liu 
---
 ts-xen-build-prep | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ts-xen-build-prep b/ts-xen-build-prep
index 3e98364..7718cff 100755
--- a/ts-xen-build-prep
+++ b/ts-xen-build-prep
@@ -206,9 +206,12 @@ sub prep () {
   libglib2.0-dev liblzma-dev pkg-config
   autoconf automake libtool xsltproc
   libxml2-utils libxml2-dev
-  libdevmapper-dev w3c-dtd-xhtml libxml-xpath-perl
+  libdevmapper-dev libxml-xpath-perl
   ccache nasm checkpolicy ebtables);
 
+if ($ho->{Suite} =~ m/squeeze|wheezy|jessie/) {
+   push(@packages, "w3c-dtd-xhtml");
+}
 if ($ho->{Suite} !~ m/squeeze|wheezy/) {
push(@packages, qw(ocaml-nox ocaml-findlib));
 }
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 04/19] ts-xen-install: install some packages on stretch

[Wei Liu]

The "route" command is now in that package.

libnl is needed when running xl.

Signed-off-by: Wei Liu 
---
 ts-xen-install | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ts-xen-install b/ts-xen-install
index ec907c5..d4c25c7 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -57,6 +57,9 @@ sub packages () {
libsdl1.2debian libglib2.0-0 liblzma5
   qemu-utils
netcat-openbsd));
+if ($ho->{Suite} =~ m/stretch/) {
+target_install_packages($ho, 'net-tools libnl-route-3-200');
+}
 if ($ho->{Suite} =~ m/jessie/) {
 target_install_packages($ho, 'libnl-route-3-200');
 }
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 09/19] ts-debian-fixup: merge origin extra= to our own

[Wei Liu]

The original extra= was not removed, so there were two extra= in the
resulting config file.

It wasn't a problem for xl because the second extra= took precedence.
However libvirt tests would only pick up the first extra= --  they
worked by chance.

Fix this issue by merging the original.

Signed-off-by: Wei Liu 
---
 ts-debian-fixup | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-debian-fixup b/ts-debian-fixup
index f29971d..288766d 100755
--- a/ts-debian-fixup
+++ b/ts-debian-fixup
@@ -175,7 +175,7 @@ sub otherfixupcfg () {
 $extra .= " iommu=soft";
 }
 
-$cfg .= "\nextra='$extra'\n";
+$cfg =~ s/^extra\s*=\s*['"](.*)['"]/extra = '$1 $extra'/mg;
 };
 
 sub writecfg () {
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 05/19] Debian.pm: use sysvinit-core instead of systemd

[Wei Liu]

Install that packages for suites >wheezy, because they use systemd as
the default init.

Signed-off-by: Wei Liu 
---
 Osstest/Debian.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 845027a..e7fb020 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -827,7 +827,7 @@ sub preseed_base ($$$;@) {
 
 # Systemd doesn't honor osstest-confirm-booted service, which
 # breaks ts-leak-check.  Fall back to SysV init for now.
-if ( $suite =~ /jessie/ ) {
+if ( $suite !~ /squeeze|wheezy/ ) {
preseed_hook_command($ho, 'late_command', $sfx, <

[Xen-devel] [OSSTEST PATCH v2 07/19] ts-host-install: don't use the new nic naming scheme

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 ts-host-install | 4 
 1 file changed, 4 insertions(+)

diff --git a/ts-host-install b/ts-host-install
index 11c14a7..7339858 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -271,6 +271,10 @@ END
 # why this is repeated.
 push @hocmdline, "console=$console" unless $console eq "NONE";
 
+# Don't use "Predictable Network Interface Names"
+# 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
+push @hocmdline, "net.ifnames=0" if $ho->{Suite} =~ m/stretch/;
+
 push @hocmdline,
 get_host_property($ho, "linux-boot-append $ho->{Suite}", ''),
 get_host_property($ho, "linux-boot-append $ho->{Suite} $r{arch}", '');
-- 
2.11.0


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

[Xen-devel] [OSSTEST PATCH v2 06/19] ts-leak-check: suppress systemd-shim, which leaks in stretch

[Wei Liu]

Signed-off-by: Wei Liu 
Acked-by: Ian Jackson 
---
 ts-leak-check | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ts-leak-check b/ts-leak-check
index 678d069..41e6245 100755
--- a/ts-leak-check
+++ b/ts-leak-check
@@ -202,6 +202,7 @@ xenstore /vm
 xenstore /libxl
 
 process .* udevd
+process .* /.+/systemd-shim
 
 file /var/run/xenstored/db
 file /var/run/xenstored/db.debug
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v3 3/7] libxl: introduce a new structure to represent static shared memory regions

[Wei Liu]

On Thu, Oct 19, 2017 at 10:36:31AM +0800, Zhongze Liu wrote:
> Add a new structure to the IDL familiy to represent static shared memory 
> regions
> as proposed in the proposal "Allow setting up shared memory areas between VMs
> from xl config file" (see [1]).
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
> 
> Signed-off-by: Zhongze Liu 
> Reviewed-by: Stefano Stabellini 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v3 1/7] libxc: add xc_domain_remove_from_physmap to wrap XENMEM_remove_from_physmap

[Wei Liu]

On Thu, Oct 19, 2017 at 10:36:29AM +0800, Zhongze Liu wrote:
> This is for the proposal "Allow setting up shared memory areas between VMs
> from xl config file". See:
> 
>   https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
> 
> Then plan is to use XENMEM_add_to_physmap_batch to map the shared pages from
> one domU to another and use XENMEM_remove_from_physmap to cancel the sharing.
> A wrapper to XENMEM_add_to_physmap_batch was added in the following commit:
> 
>   commit 20e725e9364cff4a29945f66986ecd88cca8743d
> 
> Now add the wrapper to XENMEM_remove_from_physmap.
> 
> Signed-off-by: Zhongze Liu 
> Reviewed-by: Stefano Stabellini 
> Acked-by: Wei Liu 
> 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> Cc: Stefano Stabellini 
> Cc: Julien Grall 
> Cc: xen-devel@lists.xen.org
> ---
>  tools/libxc/include/xenctrl.h |  4 
>  tools/libxc/xc_domain.c   | 11 +++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 666db0b919..0d8364ea4b 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1415,6 +1415,10 @@ int xc_domain_add_to_physmap_batch(xc_interface *xch,
> xen_pfn_t *gfpns,
> int *errs);
>  
> +int xc_domain_remove_from_physmap(xc_interface *xch,
> +  domid_t domid,

We recently made changes to use uint32_t for domid.

You can keep my ack after the change.

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

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Julien Grall]

Hi Manish,

On 10/31/2017 12:05 PM, Manish Jaggi wrote:

On 10/27/2017 7:35 PM, Andre Przywara wrote:

When PCI device passthrough is supported, the PCIRC is itself virtual
(emulated by Xen).
One can have any number of virtual PCIRC  and may be virtual SMMUs.
Hence the topology can vary.

I think I don't disagree, my initial comment was just about the
confusion that this "IORT topology is *different* from" term created.

Ok, I will move it in a different section and remove the term "different".



Now read the below lines.

At a minimum domU IORT should include a single PCIRC and ITS Group.
Similar PCIRC can be added in DSDT.
Additional node can be added if platform device is assigned to domU.
No extra node should be required for PCI device pass-through.

Again I don't fully understand this last sentence.

The last line is continuation of the first line "At a minimum..."

OK, but still I don't get how we would end up with an IORT without
(pass-throughed) PCI devices in the first place?

If hypothetically a platform device uses MSI.


I would move out of the equation platform device passthrough. Most of 
use case I am aware is around embedded and controlled environment. It 
would be difficult to provide a generic way for Server.


To give a bit more details, when using device-tree the user needs to 
provide a partial device-tree describing the device passthrough. For 
ACPI, you would need to do the same but with DSDT.



I will let Sameer comment on it.
Our platform does not have a Named Component node in IORT.


[...]


6. IORT Generation
---
There would be a common code to generate IORT table from
iort_table_struct.

That sounds useful, but we would need to be careful with sharing code
between Xen and the tool stack. Has this actually been done before?

I added the code sharing part here, but I am not hopeful that this would
work as it would require lot of code change on toolstack.
A simple difference is that the acpi header structures have different
member variables. This is same for other structures.
So we might have to create a lot of defines in common code for sharing
and possibility of errors.

See: struct acpi_header in acpi2_0.h (tools/libacpi)
and struct acpi_table_header in actbl.h (xen/include/acpi)
What do you think about this difference in basic structures in toolstack 
and xen code.
When we write a common library should I include a #define for mapping 
xen structure to toolstack.
Would it have more overhead than duplication, that is an implementation 
issue.

That is why I preferred a domctl, so xen coud prepare IORT for DomU.

I don't this it's justified to move a simple table generation task
into Xen, just to allow code sharing. After all this does not require
any Xen internal knowledge. So it should be done definitely in the
toolstack.

Yes. Fully agree.
The point here is duplication or code reuse.
See above.
Can we please focus on what matters, i.e what is necessary from an 
high-level perspective to support IORT in the hypervisor.


We can discuss about code sharing/duplication when we get to the support 
IORT for the guests.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Manish Jaggi]

On 10/27/2017 7:35 PM, Andre Przywara wrote:

Hi,

Hey Andre,


On 25/10/17 09:22, Manish Jaggi wrote:


On 10/23/2017 7:27 PM, Andre Przywara wrote:

Hi Manish,

On 12/10/17 22:03, Manish Jaggi wrote:

ACPI/IORT Support in Xen.
--

I had sent out patch series [0] to hide smmu from Dom0 IORT. Extending
the scope
and including all that is required to support ACPI/IORT in Xen.
Presenting for review
first _draft_ of design of ACPI/IORT support in Xen. Not complete
though.

Discussed is the parsing and generation of IORT table for Dom0 and
DomUs.
It is proposed that IORT be parsed and the information in saved into xen
data-structure
say host_iort_struct and is reused by all xen subsystems like ITS / SMMU
etc.

Since this is first draft is open to technical comments, modifications
and suggestions. Please be open and feel free to add any missing points
/ additions.

1. What is IORT. What are its components ?
2. Current Support in Xen
3. IORT for Dom0
4. IORT for DomU
5. Parsing of IORT in Xen
6. Generation of IORT
7. Future Work and TODOs

1. What is IORT. What are its components ?

IORT refers to Input Output remapping table. It is essentially used
to find
information about the IO topology (PCIRC-SMMU-ITS) and relationships
between
devices.

A general structure of IORT is has nodes which have information about
PCI RC,
SMMU, ITS and Platform devices. Using an IORT table relationship between
RID -> StreamID -> DeviceId can be obtained. More specifically which
device is
behind which SMMU and which interrupt controller, this topology is
described in
IORT Table.

RID is a requester ID in PCI context,
StreamID is the ID of the device in SMMU context,
DeviceID is the ID programmed in ITS.

For a non-pci device RID could be simply an ID.

Each iort_node contains an ID map array to translate from one ID into
another.
IDmap Entry {input_range, output_range, output_node_ref, id_count}
This array is present in PCI RC node,SMMU node, Named component node etc
and can reference to a SMMU or ITS node.

2. Current Support of IORT
---
Currently Xen passes host IORT table to dom0 without any modifications.
For DomU no IORT table is passed.

3. IORT for Dom0
-
IORT for Dom0 is prepared by xen and it is fairly similar to the host
iort.
However few nodes could be removed removed or modified. For instance
- host SMMU nodes should not be present
- ITS group nodes are same as host iort but, no stage2 mapping is done
for them.

What do you mean with stage2 mapping?

Please ignore this line. Copy paste error. Read it as follows

- ITS group nodes are same as host iort.
(though I would modify the same as in next draft)


- platform nodes (named components) may be selectively present depending
on the case where xen is using some. This could be controlled by  xen
command
line.

Mmh, I am not so sure platform devices described in the IORT (those
which use MSIs!) are so much different from PCI devices here. My
understanding is those platform devices are network adapters, for
instance, for which Xen has no use.

ok.

So I would translate "Named Components" or "platform devices" as devices
just not using the PCIe bus (so no config space and no (S)BDF), but
being otherwise the same from an ITS or SMMU point of view.

Correct.

- More items : TODO

I think we agreed upon rewriting the IORT table instead of patching it?

yes. In fact if you look at my patch v2 on IORT SMMU hiding, it was
_rewriting_ most of Dom0 IORT and not patching it.

I was just after the wording above:
"IORT for Dom0 is prepared by xen and it is fairly similar to the host
iort. However few nodes could be removed removed or modified."
... which sounds a bit like you alter the h/w IORT.
It would be good to clarify this by explicitly mentioning the
parsing/generation cycle, as this is a fundamental design decision.

Sure will do that. Thanks for pointing that.

We can have a IRC discussion on this.

I think apart from rewriting, the other tasks which were required that
are handled in this epic task
- parse IORT and save in xen internal data structures
- common code to generate IORT for dom0/domU
- All xen code that parses IORT multiple times use now the xen internal
data structures.

Yes, that sounds about right.

:)



(I have explained this in this mail below)

So to some degree your statements are true, but when we rewrite the IORT
table without SMMUs (and possibly without other components like the
PMUs), it would be kind of a stretch to call it "fairly similar to the
host IORT". I think "based on the host IORT" would be more precise.

Yes. Based on host IORT is better,thanks.

4. IORT for DomU
-
IORT for DomU is generated by the toolstack. IORT topology is different
when DomU supports device passthrough.

Can you elaborate on that? Different compared to what? My understanding
is that without device passthrough there would be no IORT in 

[Xen-devel] [linux-4.9 test] 115411: regressions - FAIL

[osstest service owner]

flight 115411 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115411/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 114814

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114814
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114814
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linuxd785062ef20f9b2cd8cedcafea55ca8264f25f3e
baseline version:
 linux5d7a76acad403638f635c918cc63d1d44ffa4065

Last test of basis   114814  2017-10-20 20:51:56 Z   10 days
Failing since114845  2017-10-21 16:14:17 Z9 days   17 attempts
Testing same since   115296  2017-10-27 11:07:37 Z4 days7 attempts


People who touched revisions under test:
  Alan Stern 
  Alex Deucher 
  Alexandre Belloni 
  Andrew Morton 
  Andrey Konovalov 
  Anoob Soman 
  Arend van Spriel 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Hutchings 
  Ben Skeggs 
  Bin Liu 
  Borislav Petkov 
  Brian Foster 
  Carlos Maiolino 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  Christophe JAILLET 
  

Re: [Xen-devel] [PATCH] aarch64: advertise the GIC system register interface

[Peter Maydell]

On 19 October 2017 at 15:46, Peter Maydell  wrote:
> On 18 October 2017 at 01:10, Stefano Stabellini  
> wrote:
>> Advertise the presence of the GIC system register interface (1<<24)
>> according to H9.248 of the ARM ARM.
>>
>> This patch allows Xen to boot on QEMU aarch64.
>>
>> Signed-off-by: Stefano Stabellini 
>>
>> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
>> index 670c07a..a451763 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -136,7 +136,7 @@ static void aarch64_a57_initfn(Object *obj)
>>  cpu->id_isar3 = 0x01112131;
>>  cpu->id_isar4 = 0x00011142;
>>  cpu->id_isar5 = 0x00011121;
>> -cpu->id_aa64pfr0 = 0x;
>> +cpu->id_aa64pfr0 = 0x0100;
>>  cpu->id_aa64dfr0 = 0x10305106;
>>  cpu->pmceid0 = 0x;
>>  cpu->pmceid1 = 0x;
>> @@ -196,7 +196,7 @@ static void aarch64_a53_initfn(Object *obj)
>>  cpu->id_isar3 = 0x01112131;
>>  cpu->id_isar4 = 0x00011142;
>>  cpu->id_isar5 = 0x00011121;
>> -cpu->id_aa64pfr0 = 0x;
>> +cpu->id_aa64pfr0 = 0x0100;
>>  cpu->id_aa64dfr0 = 0x10305106;
>>  cpu->id_aa64isar0 = 0x00011120;
>>  cpu->id_aa64mmfr0 = 0x1122; /* 40 bit physical addr */
>
> Whoops -- we missed this when we added the GICv3 support, because
> Linux doesn't check it.
>
> Applied to target-arm.next, thanks.

Unfortunately I've just noticed that this breaks booting Linux
in the "not using gicv3" case. This is because we don't actually
define the GICv3 cpu interface registers unless the board
instantiates a GICv3. We mustn't advertise the GICv3 sysregs
in the ID register unless we actually have them.

Not sure how best to fix this -- it's a consequence of the
design decision we made to have the sysregs implementation
be in the gicv3 code. There's no useful feature bit in the CPU
to hang this off either, it's an effect of whether the board
model happens to wire up a gicv3 or not. So we can only figure
this out fairly late on (probably at CPU reset time), which
is a bit tedious for getting ID reg values right.

In the meantime I've dropped this patch from target-arm.next.

thanks
-- PMM

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

Re: [Xen-devel] [RFC] [Draft Design] ACPI/IORT Support in Xen.

[Julien Grall]

Hi Sameer,

On 10/30/2017 11:33 PM, Goel, Sameer wrote:

On 10/12/2017 3:03 PM, Manish Jaggi wrote:

5. Parsing of IORT in Xen
--

I think a Linux like approach will solve the following use cases:
1. Identify the SMMU devices and initialize the devices as needed.
2. API function to setup SMMUs in response to a discovery notification from DOM0
- We will still need a path for non pcie devices.
- I agree with Andre that the use cases for the named nodes in IORT should 
be treated the same as PCIe RC devices.
3. The concept of fwnode is still valid as per 4.14 and we can try reuse most 
of the parsing code.

Manish, I looked at your old patch and had a couple of questions before I 
comment more on this design. From an initial
glance, it seems that you should be able to hide SMMUs by calling the already 
defined API functions in the iort.c implementation
(for most part :)).

I am wondering if we really need to keep a list of parsed nodes. Or which use 
case apart from hw dom IORT mandates this?
I want to see the parsing separated from the generation. This means we 
need a list of parsed nodes for the IORT.


As we have them in hand, I was thinking to re-use them than lookup the IORT.

Cheers,

--
Julien Grall

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

[Xen-devel] [qemu-mainline test] 115421: regressions - trouble: blocked/broken/fail/pass

[osstest service owner]

flight 115421 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115421/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvopsbroken
 build-armhf-pvops 4 host-install(4)broken REGR. vs. 114507
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  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
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  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-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 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-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)  

[Xen-devel] [distros-debian-snapshot test] 72400: tolerable FAIL

[Platform Team regression test user]

flight 72400 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/72400/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-amd64-current-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-i386-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-amd64-i386-weekly-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-amd64-amd64-weekly-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-amd64-i386-daily-netboot-pygrub 10 debian-di-install fail like 72348
 test-amd64-amd64-amd64-daily-netboot-pvgrub 10 debian-di-install fail like 
72348
 test-amd64-i386-i386-daily-netboot-pvgrub 10 debian-di-install fail like 72348
 test-amd64-i386-amd64-daily-netboot-pygrub 10 debian-di-install fail like 72348
 test-armhf-armhf-armhf-daily-netboot-pygrub 10 debian-di-install fail like 
72348
 test-amd64-i386-i386-weekly-netinst-pygrub 10 debian-di-install fail like 72348
 test-amd64-i386-i386-current-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-i386-amd64-current-netinst-pygrub 10 debian-di-install fail like 
72348
 test-amd64-amd64-i386-current-netinst-pygrub 10 debian-di-install fail like 
72348

baseline version:
 flight   72348

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [PATCH v5 1/1] xen/time: do not decrease steal time after live migration on xen

[Boris Ostrovsky]

On 10/30/2017 11:13 PM, Dongli Zhang wrote:

Hi Boris,

On 10/31/2017 08:58 AM, Boris Ostrovsky wrote:



On 10/30/2017 08:14 PM, Dongli Zhang wrote:

Hi Boris,

On 10/30/2017 09:34 PM, Boris Ostrovsky wrote:

On 10/30/2017 04:03 AM, Dongli Zhang wrote:

After guest live migration on xen, steal time in /proc/stat
(cpustat[CPUTIME_STEAL]) might decrease because steal returned by
xen_steal_lock() might be less than this_rq()->prev_steal_time which is
derived from previous return value of xen_steal_clock().

For instance, steal time of each vcpu is 335 before live migration.

cpu  198 0 368 200064 1962 0 0 1340 0 0
cpu0 38 0 81 50063 492 0 0 335 0 0
cpu1 65 0 97 49763 634 0 0 335 0 0
cpu2 38 0 81 50098 462 0 0 335 0 0
cpu3 56 0 107 50138 374 0 0 335 0 0

After live migration, steal time is reduced to 312.

cpu  200 0 370 200330 1971 0 0 1248 0 0
cpu0 38 0 82 50123 500 0 0 312 0 0
cpu1 65 0 97 49832 634 0 0 312 0 0
cpu2 39 0 82 50167 462 0 0 312 0 0
cpu3 56 0 107 50207 374 0 0 312 0 0

Since runstate times are cumulative and cleared during xen live migration
by xen hypervisor, the idea of this patch is to accumulate runstate times
to global percpu variables before live migration suspend. Once guest VM is
resumed, xen_get_runstate_snapshot_cpu() would always return the sum of new
runstate times and previously accumulated times stored in global percpu
variables.

Similar and more severe issue would impact prior linux 4.8-4.10 as
discussed by Michael Las at
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest,

which would overflow steal time and lead to 100% st usage in top command
for linux 4.8-4.10. A backport of this patch would fix that issue.

References:
https://0xstubs.org/debugging-a-flaky-cpu-steal-time-counter-on-a-paravirtualized-xen-guest

Signed-off-by: Dongli Zhang 

---
Changed since v1:
* relocate modification to xen_get_runstate_snapshot_cpu

Changed since v2:
* accumulate runstate times before live migration

Changed since v3:
* do not accumulate times in the case of guest checkpointing

Changed since v4:
* allocate array of vcpu_runstate_info to reduce number of memory allocation

---
   drivers/xen/manage.c |  2 ++
   drivers/xen/time.c   | 68
++--
   include/xen/interface/vcpu.h |  2 ++
   include/xen/xen-ops.h|  1 +
   4 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c
index c425d03..3dc085d 100644
--- a/drivers/xen/manage.c
+++ b/drivers/xen/manage.c
@@ -72,6 +72,7 @@ static int xen_suspend(void *data)
   }
 gnttab_suspend();
+xen_accumulate_runstate_time(-1);
   xen_arch_pre_suspend();
 /*
@@ -84,6 +85,7 @@ static int xen_suspend(void *data)
  : 0);
 xen_arch_post_suspend(si->cancelled);
+xen_accumulate_runstate_time(si->cancelled);


I am not convinced that the comment above HYPERVISOR_suspend() is
correct. The call can return an error code and so if it returns -EPERM
(which AFAICS it can't now but might in the future) then
xen_accumulate_runstate_time() will do wrong thing.


I would split xen_accumulate_runstate_time() into two functions to avoid the
-EPERM issue, as one is for saving and another is for accumulation, 
respectively.

Otherwise, can you use xen_accumulate_runstate_time(2) for saving before suspend
and xen_accumulate_runstate_time(si->cancelled) after resume?



I'd probably just say something like

si->cancelled = HYPERVISOR_suspend() ? 1 : 0;


As the call of HYPERVISOR_suspend() takes 3 lines, I would make it as below and
I think gcc would optimize it.

-   /*
-* This hypercall returns 1 if suspend was cancelled
-* or the domain was merely checkpointed, and 0 if it
-* is resuming in a new domain.
-*/
 si->cancelled = HYPERVISOR_suspend(xen_pv_domain()
 ? virt_to_gfn(xen_start_info)
 : 0);
+   si->cancelled = si->cancelled ? 1 : 0;



Or xen_manage_runstate_time(si->cancelled ? 1 : 0) --- that way you 
preserve si->cancelled if anyone cares later (which at the moment nooone 
does) Either way I think is fine.







and keep xen_accumulate_runstate_time() as is (maybe rename it to
xen_manage_runstate_time()). And also remove the comment above the hypercall as
it is incorrect (but please mention the reason in the commit message)







   gnttab_resume();
 if (!si->cancelled) {
diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..cf3afb9 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -19,6 +19,9 @@
   /* runstate info updated by Xen */
   static DEFINE_PER_CPU(struct vcpu_runstate_info, xen_runstate);
   +static DEFINE_PER_CPU(u64[RUNSTATE_max], old_runstate_time);
+static struct vcpu_runstate_info *runstate_delta;


I'd move this inside 

Re: [Xen-devel] [PATCH 3/6] libxl: add backend type to vkb

[Oleksandr Grytsov]

On Mon, Oct 30, 2017 at 8:11 PM, Wei Liu  wrote:

> On Thu, Oct 05, 2017 at 12:07:08PM +0300, Oleksandr Grytsov wrote:
> > From: Oleksandr Grytsov 
> >
> > New field backend_type is added to vkb device
> > in order to have QEMU and user space backend
> > simultaneously. Each vkb backend shall read
> > appropriate XS entry and service only own
> > frontends.
> >
> > Signed-off-by: Oleksandr Grytsov 
> > ---
> >  tools/libxl/libxl_create.c  |  4 
> >  tools/libxl/libxl_dm.c  |  2 ++
> >  tools/libxl/libxl_types.idl |  7 +++
> >  tools/libxl/libxl_vkb.c | 10 +-
> >  tools/xl/xl_parse.c |  4 
> >  5 files changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index f813114..7268f7f 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1349,6 +1349,7 @@ static void domcreate_launch_dm(libxl__egc *egc,
> libxl__multidev *multidev,
> >  }
> >
> >  libxl_device_vkb_init();
> > +vkb.backend_type = LIBXL_VKB_BACKEND_QEMU;
>
> Hmm... See below.
>
> >  libxl__device_add(gc, domid, __vkb_devtype, );
> >  libxl_device_vkb_dispose();
> >
> > @@ -1376,6 +1377,9 @@ static void domcreate_launch_dm(libxl__egc *egc,
> libxl__multidev *multidev,
> >  for (i = 0; i < d_config->num_vfbs; i++) {
> >  libxl__device_add(gc, domid, __vfb_devtype,
> >_config->vfbs[i]);
> > +}
> > +
> > +for (i = 0; i < d_config->num_vkbs; i++) {
> >  libxl__device_add(gc, domid, __vkb_devtype,
> >_config->vkbs[i]);
> >  }
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 98f89a9..d8b0ee7 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -1728,6 +1728,8 @@ static int 
> > libxl__vfb_and_vkb_from_hvm_guest_config(libxl__gc
> *gc,
> >
> >  vkb->backend_domid = 0;
> >  vkb->devid = 0;
> > +vkb->backend_type = LIBXL_VKB_BACKEND_QEMU;
> > +
> >  return 0;
> >  }
> >
> > diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> > index cd0c06f..65cd81a 100644
> > --- a/tools/libxl/libxl_types.idl
> > +++ b/tools/libxl/libxl_types.idl
> > @@ -240,6 +240,12 @@ libxl_checkpointed_stream =
> Enumeration("checkpointed_stream", [
> >  (2, "COLO"),
> >  ])
> >
> > +libxl_vkb_backend = Enumeration("vkb_backend", [
> > +(0, "UNKNOWN"),
> > +(1, "QEMU"),
> > +(2, "LINUX")
> > +])
>
> Originally this is only internal detail, but now you want to expose
> this.  You need to set the default value for this; otherwise you could
> break migration.
>

Yes, I will set default to QEMU.


>
> And then you also need to provide a setdefault function for
> libxl_device_vkb.
>
> Also I'm a bit confused because the LINUX type is not used in this
> series.
>

LINUX type will be used by the linux backend. libxl just set the xenstore
entry.
The linux backend will service only frontend which has LINUX type.

-- 
Best Regards,
Oleksandr Grytsov.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.10] common/spinlock: Improve the output from check_lock() if it trips

[George Dunlap]

On 10/31/2017 10:49 AM, Andrew Cooper wrote:
> If check_lock() triggers, a crash will occur.  Instead of simply identifying
> "the irq context was different", indicate the expected and current irq
> context.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: George Dunlap 

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

Re: [Xen-devel] [PATCH] MAINTAINERS: Make Christian Lindig maintainer for ocaml tools

[Wei Liu]

On Tue, Oct 17, 2017 at 05:44:11PM +0100, Ian Jackson wrote:
> oxenstored is our default implementation of xenstore, for platforms
> that have ocaml support.  We need it to be maintained.  Dave Scott,
> the only existing maintainer, has had limited availability.
> 
> Christian has been reveiwing patches and offering opinions where
> necessary, although activity in this area has been quiet and there has
> not been a great deal of new development.
> 
> Christian's contributions have been sensible and I think it would be a
> good idea now to formally make him a maintainer.
> 
> CC: Christian Lindig 
> CC: David Scott 
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH for-4.10] common/spinlock: Improve the output from check_lock() if it trips

[Wei Liu]

On Tue, Oct 31, 2017 at 10:49:10AM +, Andrew Cooper wrote:
> If check_lock() triggers, a crash will occur.  Instead of simply identifying
> "the irq context was different", indicate the expected and current irq
> context.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v7 for-next 02/12] pci: introduce a type to store a SBDF

[Wei Liu]

On Wed, Oct 18, 2017 at 12:40:24PM +0100, Roger Pau Monne wrote:
> That provides direct access to all the members that constitute a SBDF.
> The only function switched to use it is hvm_pci_decode_addr, because
> it makes following patches simpler.
> 
> Suggested-by: Andrew Cooper 
> Signed-off-by: Roger Pau Monné 
> Reviewed-by: Paul Durrant 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v7 for-next 08/12] xen: introduce rangeset_consume_ranges

[Wei Liu]

On Wed, Oct 18, 2017 at 12:40:30PM +0100, Roger Pau Monne wrote:
> This function allows to iterate over a rangeset while removing the
> processed regions.
> 
> This will be used in order to split processing of large memory areas
> when mapping them into the guest p2m.
> 
> Signed-off-by: Roger Pau Monné 

Reviewed-by: Wei Liu 

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

[Xen-devel] [libvirt test] 115415: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  bc8a99ef06417a2303ccab455f9f045e2a617916
baseline version:
 libvirt  dc162adb9094b5f0e5c847ce2da726b7ab5e2068

Last test of basis   115312  2017-10-28 04:21:42 Z3 days
Testing same since   115415  2017-10-31 04:20:24 Z0 days1 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 pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 test-armhf-armhf-libvirt-raw pass
 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=bc8a99ef06417a2303ccab455f9f045e2a617916
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
 export PERLLIB=.:.
 PERLLIB=.:.
+++ 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 
bc8a99ef06417a2303ccab455f9f045e2a617916
+ branch=libvirt
+ revision=bc8a99ef06417a2303ccab455f9f045e2a617916
+ . 

[Xen-devel] [PATCH for-4.10] common/spinlock: Improve the output from check_lock() if it trips

[Andrew Cooper]

If check_lock() triggers, a crash will occur.  Instead of simply identifying
"the irq context was different", indicate the expected and current irq
context.

Signed-off-by: Andrew Cooper 
---
CC: George Dunlap 
CC: Jan Beulich 
CC: Konrad Rzeszutek Wilk 
CC: Stefano Stabellini 
CC: Tim Deegan 
CC: Wei Liu 
CC: Julien Grall 

check_lock() only exists in debug builds, which makes this a low risk change
for 4.10.
---
 xen/common/spinlock.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
index 44b07b7..8f2ba08 100644
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -44,7 +44,13 @@ static void check_lock(struct lock_debug *debug)
 if ( unlikely(debug->irq_safe != irq_safe) )
 {
 int seen = cmpxchg(>irq_safe, -1, irq_safe);
-BUG_ON(seen == !irq_safe);
+
+if ( seen == !irq_safe )
+{
+printk("CHECKLOCK FAILURE: prev irqsafe: %d, curr irqsafe %d\n",
+   seen, irq_safe);
+BUG();
+}
 }
 }
 
-- 
2.1.4


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

[Xen-devel] Commit moratorium to staging

[Julien Grall]

Hi all,

Master lags 15 days behind staging due to tests failing reliably on some 
of the hardware in osstest (see [1]).


At the moment a force push is not feasible because the same tests passes 
on different hardware (see [2]).


Please avoid committing any more patches unless it is fixing a test 
failure in osstest.


Tree will be re-opened once we get a push.

Cheers,

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg03351.html
[2] 
https://lists.xenproject.org/archives/html/xen-devel/2017-10/msg02932.html


--
Julien Grall

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

Re: [Xen-devel] [PATCH 4/4] libxl: move ibxl_devid_to_device_... to LIBXL_DEFINE_DEVID_TO_DEVICE

[Wei Liu]

On Thu, Oct 05, 2017 at 12:30:48PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 3/4] libxl: move libxl__device_from_ to LIBXL_DEFINE_DEVICE_FROM_TYPE

[Wei Liu]

On Thu, Oct 05, 2017 at 12:30:47PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> LIBXL_DEFINE_DEVICE_FROM_TYPE uses libxl__..._devtype.type to
> be assigned as device and backend type.
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/4] libxl: use libxl__device_kind in LIBXL_DEFINE_UPDATE_DEVID

[Wei Liu]

On Thu, Oct 05, 2017 at 12:30:46PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> Use libxl__..._devtype.type to update device id.
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/4] libxl: use libxl__device_kind to get device XS entry

[Wei Liu]

On Thu, Oct 05, 2017 at 12:30:45PM +0300, Oleksandr Grytsov wrote:
> From: Oleksandr Grytsov 
> 
> On adding to XS name of device is taken from
> libxl__device_kind enum. On getting device from XS
> the name is hardcoded. It leads to potential
> mistmatch errors. The patch is using libxl__device_kind
> everywere to have one source of device name.
> 
> Signed-off-by: Oleksandr Grytsov 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 2/4 v3] libxl: Change the type of console_mfn to xen_pfn_t

[Wei Liu]

On Tue, Oct 31, 2017 at 12:25:06PM +0530, Bhupinder Thakur wrote:
> Currently the type of console mfn is unsigned long in libxl. This may be
> an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are
> 64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the
> type of console_mfn is changed to xen_pfn_t.
> 
> Also the name console_mfn is misleading as it is actually a gfn. This
> patch also modifies the name to console_gfn.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH 1/4 v3 for-4.10] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

[Wei Liu]

Change the tag to for-4.10.

Julien, this is needed to fix vuart emulation.

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

Re: [Xen-devel] [PATCH 4/4 v3] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

[Wei Liu]

On Tue, Oct 31, 2017 at 12:25:08PM +0530, Bhupinder Thakur wrote:
> xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for 
> initializing ring-ref.
> Since the type of ring_ref is changed to xen_pfn_t (which is an unsigned 
> value) assigning -1
> appeared to be confusing. For clarity, XEN_INVALID_PFN is introduced.
> 
> Signed-off-by: Bhupinder Thakur 

Acked-by: Wei Liu 

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

[Xen-devel] [qemu-mainline test] 115417: regressions - FAIL

[osstest service owner]

flight 115417 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/115417/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 114507
 build-amd64-xsm   6 xen-buildfail REGR. vs. 114507
 build-i386-xsm6 xen-buildfail REGR. vs. 114507
 build-amd64   6 xen-buildfail REGR. vs. 114507
 build-armhf   6 xen-buildfail REGR. vs. 114507
 build-armhf-xsm   6 xen-buildfail REGR. vs. 114507

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt-xsm  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
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  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-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 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-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 

Re: [Xen-devel] [examine test] 115400: regressions - FAIL

[Roger Pau Monné]

On Mon, Oct 30, 2017 at 06:48:46PM +, osstest service owner wrote:
> flight 115400 examine real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/115400/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  examine-elbling0  2 hosts-allocate broken REGR. vs. 
> 115392
>  examine-godello0  4 memdisk-try-append   fail REGR. vs. 
> 115392
> 
> Tests which did not succeed, but are not blocking:
>  examine-godello1  4 memdisk-try-append   fail  like 
> 115392

I've looked at the failures, and the symptom is the same, the loader
seems to receive a key press that stops the autoboot timeout and drops
into the loader prompt:

Oct 30 16:59:55.887295 Hit [Enter] to boot immediately, or any other key for 
command prompt.
Oct 30 16:59:55.895262 
Oct 30 16:59:55.895297 
Oct 30 16:59:55.895324 Type '?' for a list of commands, 'help' for more 
detailed help.
Oct 30 16:59:55.903265 OK

I will look into this later.

Roger.

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

[Xen-devel] [xen-unstable test] 115401: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stopfail REGR. vs. 114644
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop   fail REGR. vs. 114644
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail in 115378 REGR. vs. 
114644

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-rtds  6 xen-install  fail in 115378 pass in 115401
 test-amd64-i386-libvirt-qcow2 17 guest-start/debian.repeat fail in 115378 pass 
in 115401
 test-amd64-i386-xl-raw 19 guest-start/debian.repeat fail in 115378 pass in 
115401
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 115378 pass 
in 115401
 test-amd64-amd64-libvirt-vhd 17 guest-start/debian.repeat fail in 115378 pass 
in 115401
 test-armhf-armhf-xl-vhd  15 guest-start/debian.repeat  fail pass in 115362
 test-armhf-armhf-xl   6 xen-installfail pass in 115378
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail pass in 115378
 test-amd64-amd64-xl-qcow219 guest-start/debian.repeat  fail pass in 115378

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl 13 migrate-support-check fail in 115378 never pass
 test-armhf-armhf-xl 14 saverestore-support-check fail in 115378 never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 114644
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 114644
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 114644
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 114644
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 114644
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 114644
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  bb2c1a1cc98a22e2d4c14b18421aa7be6c2adf0d
baseline version:
 xen  24fb44e971a62b345c7b6ca3c03b454a1e150abe

Last test of basis   114644  2017-10-17 10:49:11 Z   13 days
Failing since114670  2017-10-18 05:03:38 Z   13 days   20 

[Xen-devel] [PATCH 1/4 v3] libxl: Fix the bug introduced in commit "libxl: use correct type modifier for vuart_gfn"

[Bhupinder Thakur]

In libxl__device_vuart_add vuart_gfn is getting stored as a hex value:

> flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));

However, xenstore reads this value as a decimal value and tries to map the
wrong address and fails.

This patch introduces a new format specifier "PRIu_xen_pfn" which formats the 
value as a
decimal value.

Signed-off-by: Bhupinder Thakur 
Acked-by: Wei Liu 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 
CC: Jan Beulich 
CC: Andrew Cooper 

 tools/libxl/libxl_console.c   | 2 +-
 xen/include/public/arch-arm.h | 1 +
 xen/include/public/arch-x86/xen.h | 1 +
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index c05dc28..6bfc0e5 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -376,7 +376,7 @@ int libxl__device_vuart_add(libxl__gc *gc, uint32_t domid,
 flexarray_append(ro_front, "port");
 flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->vuart_port));
 flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%"PRI_xen_pfn, state->vuart_gfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, state->vuart_gfn));
 flexarray_append(ro_front, "limit");
 flexarray_append(ro_front, GCSPRINTF("%d", LIBXL_XENCONSOLE_LIMIT));
 flexarray_append(ro_front, "type");
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 5708cd2..05fd11c 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -274,6 +274,7 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_core_regs_t);
 
 typedef uint64_t xen_pfn_t;
 #define PRI_xen_pfn PRIx64
+#define PRIu_xen_pfn PRIu64
 
 /* Maximum number of virtual CPUs in legacy multi-processor guests. */
 /* Only one. All other VCPUS must use VCPUOP_register_vcpu_info */
diff --git a/xen/include/public/arch-x86/xen.h 
b/xen/include/public/arch-x86/xen.h
index ff91831..3b0b1d6 100644
--- a/xen/include/public/arch-x86/xen.h
+++ b/xen/include/public/arch-x86/xen.h
@@ -75,6 +75,7 @@ __DeFiNe__ __DECL_REG_LO16(name) e ## name
 #ifndef __ASSEMBLY__
 typedef unsigned long xen_pfn_t;
 #define PRI_xen_pfn "lx"
+#define PRIu_xen_pfn "lu"
 #endif
 
 #define XEN_HAVE_PV_GUEST_ENTRY 1
-- 
2.7.4


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

[Xen-devel] [PATCH 2/4 v3] libxl: Change the type of console_mfn to xen_pfn_t

[Bhupinder Thakur]

Currently the type of console mfn is unsigned long in libxl. This may be
an issue for 32-bit toolstack running on 64-bit Xen, where the pfn are
64 bit. To ensure that console_mfn can hold any valid 64-bit pfn, the
type of console_mfn is changed to xen_pfn_t.

Also the name console_mfn is misleading as it is actually a gfn. This
patch also modifies the name to console_gfn.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/libxc/include/xenctrl_compat.h |  2 +-
 tools/libxc/xc_foreign_memory.c  |  4 ++--
 tools/libxl/libxl_console.c  |  2 +-
 tools/libxl/libxl_create.c   | 10 +-
 tools/libxl/libxl_dom.c  | 12 ++--
 tools/libxl/libxl_internal.h |  2 +-
 tools/libxl/libxl_save_helper.c  |  6 +++---
 7 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/tools/libxc/include/xenctrl_compat.h 
b/tools/libxc/include/xenctrl_compat.h
index a655e47..5ee72bf 100644
--- a/tools/libxc/include/xenctrl_compat.h
+++ b/tools/libxc/include/xenctrl_compat.h
@@ -26,7 +26,7 @@
  */
 void *xc_map_foreign_range(xc_interface *xch, uint32_t dom,
 int size, int prot,
-unsigned long mfn );
+xen_pfn_t pfn);
 
 void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, int prot,
const xen_pfn_t *arr, int num );
diff --git a/tools/libxc/xc_foreign_memory.c b/tools/libxc/xc_foreign_memory.c
index 4053d26..c1f114a 100644
--- a/tools/libxc/xc_foreign_memory.c
+++ b/tools/libxc/xc_foreign_memory.c
@@ -33,7 +33,7 @@ void *xc_map_foreign_pages(xc_interface *xch, uint32_t dom, 
int prot,
 
 void *xc_map_foreign_range(xc_interface *xch,
uint32_t dom, int size, int prot,
-   unsigned long mfn)
+   xen_pfn_t pfn)
 {
 xen_pfn_t *arr;
 int num;
@@ -46,7 +46,7 @@ void *xc_map_foreign_range(xc_interface *xch,
 return NULL;
 
 for ( i = 0; i < num; i++ )
-arr[i] = mfn + i;
+arr[i] = pfn + i;
 
 ret = xc_map_foreign_pages(xch, dom, prot, arr, num);
 free(arr);
diff --git a/tools/libxl/libxl_console.c b/tools/libxl/libxl_console.c
index 6bfc0e5..f2ca689 100644
--- a/tools/libxl/libxl_console.c
+++ b/tools/libxl/libxl_console.c
@@ -329,7 +329,7 @@ int libxl__device_console_add(libxl__gc *gc, uint32_t domid,
 flexarray_append(ro_front, "port");
 flexarray_append(ro_front, GCSPRINTF("%"PRIu32, state->console_port));
 flexarray_append(ro_front, "ring-ref");
-flexarray_append(ro_front, GCSPRINTF("%lu", state->console_mfn));
+flexarray_append(ro_front, GCSPRINTF("%"PRIu_xen_pfn, 
state->console_mfn));
 } else {
 flexarray_append(front, "state");
 flexarray_append(front, GCSPRINTF("%d", XenbusStateInitialising));
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index f15fb21..26870ca 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1134,7 +1134,7 @@ static void domcreate_bootloader_done(libxl__egc *egc,
 }
 
 void libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
-  xen_pfn_t console_mfn, void *user)
+  xen_pfn_t console_gfn, void *user)
 {
 libxl__save_helper_state *shs = user;
 libxl__domain_create_state *dcs = shs->caller_state;
@@ -1142,7 +1142,7 @@ void 
libxl__srm_callout_callback_restore_results(xen_pfn_t store_mfn,
 libxl__domain_build_state *const state = >build_state;
 
 state->store_mfn =store_mfn;
-state->console_mfn =  console_mfn;
+state->console_gfn =  console_gfn;
 shs->need_results =   0;
 }
 
@@ -1740,7 +1740,7 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
 libxl__domain_create_state *dcs;
 libxl__domain_build_state *state;
 libxl__domain_save_state *dss;
-const char *console_tty, *xs_store_mfn, *xs_console_mfn;
+const char *console_tty, *xs_store_mfn, *xs_console_gfn;
 char *dom_path;
 uint32_t domid_out;
 int rc;
@@ -1781,12 +1781,12 @@ static int do_domain_soft_reset(libxl_ctx *ctx,
 
 rc = libxl__xs_read_checked(gc, XBT_NULL,
 GCSPRINTF("%s/console/ring-ref", dom_path),
-_console_mfn);
+_console_gfn);
 if (rc) {
 LOGD(ERROR, domid_soft_reset, "failed to read console/ring-ref.");
 goto out;
 }
-state->console_mfn = xs_console_mfn ? atol(xs_console_mfn): 0;
+state->console_gfn = xs_console_gfn ? atol(xs_console_gfn): 0;
 
 rc = libxl__xs_read_mandatory(gc, XBT_NULL,
  

[Xen-devel] [PATCH 3/4 v3] xenconsole: Change the type of ring_ref to xen_pfn_t in console_create_ring

[Bhupinder Thakur]

Currently, ring_ref is read as an integer in console_create_ring which could 
lead to
truncation of the value as it is reading a 64-bit value.

The fix is to modify the type of ring_ref to xen_pfn_t and use the correct 
format
specifier to read the value correctly for all architectures.

Signed-off-by: Bhupinder Thakur 
Acked-by: Wei Liu 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/console/daemon/io.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index e22009a..1839973 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -19,6 +19,7 @@
 
 #define _GNU_SOURCE
 
+#include 
 #include "utils.h"
 #include "io.h"
 #include 
@@ -81,6 +82,12 @@ static unsigned int nr_fds;
 
 #define ROUNDUP(_x,_w) (((unsigned long)(_x)+(1UL<<(_w))-1) & ~((1UL<<(_w))-1))
 
+#if defined(CONFIG_ARM)
+# define SCNi_xen_pfn SCNi64
+#else
+# define SCNi_xen_pfn "li"
+#endif
+
 struct buffer {
char *data;
size_t consumed;
@@ -98,7 +105,7 @@ struct console {
struct buffer buffer;
char *xspath;
char *log_suffix;
-   int ring_ref;
+   xen_pfn_t ring_ref;
xenevtchn_handle *xce_handle;
int xce_pollfd_idx;
int event_count;
@@ -661,12 +668,13 @@ static void console_unmap_interface(struct console *con)
  
 static int console_create_ring(struct console *con)
 {
-   int err, remote_port, ring_ref, rc;
+   int err, remote_port, rc;
+   xen_pfn_t ring_ref;
char *type, path[PATH_MAX];
struct domain *dom = con->d;
 
err = xs_gather(xs, con->xspath,
-   "ring-ref", "%u", _ref,
+   "ring-ref", "%"SCNi_xen_pfn, _ref,
"port", "%i", _port,
NULL);
 
@@ -705,7 +713,7 @@ static int console_create_ring(struct console *con)
con->interface = xc_map_foreign_range(
xc, dom->domid, XC_PAGE_SIZE,
PROT_READ|PROT_WRITE,
-   (unsigned long)ring_ref);
+   ring_ref);
if (con->interface == NULL) {
err = EINVAL;
goto out;
-- 
2.7.4


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

[Xen-devel] [PATCH 4/4 v3] xenconsole: Define and use a macro XEN_INVALID_PFN instead of -1

[Bhupinder Thakur]

xenconsole will use a new macro XEN_INVALID_PFN instead of -1 for initializing 
ring-ref.
Since the type of ring_ref is changed to xen_pfn_t (which is an unsigned value) 
assigning -1
appeared to be confusing. For clarity, XEN_INVALID_PFN is introduced.

Signed-off-by: Bhupinder Thakur 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Stefano Stabellini 
CC: Julien Grall 

This patch is as per the review of commit fa1f157
libxl: Fix the bug introduced in commit "libxl: use correct type

 tools/console/daemon/io.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/console/daemon/io.c b/tools/console/daemon/io.c
index 1839973..aa291db 100644
--- a/tools/console/daemon/io.c
+++ b/tools/console/daemon/io.c
@@ -62,6 +62,8 @@
 /* Duration of each time period in ms */
 #define RATE_LIMIT_PERIOD 200
 
+#define XEN_INVALID_PFN (~(xen_pfn_t)0)
+
 extern int log_reload;
 extern int log_guest;
 extern int log_hv;
@@ -658,12 +660,12 @@ static void console_unmap_interface(struct console *con)
 {
if (con->interface == NULL)
return;
-   if (xgt_handle && con->ring_ref == -1)
+   if (xgt_handle && con->ring_ref == XEN_INVALID_PFN)
xengnttab_unmap(xgt_handle, con->interface, 1);
else
munmap(con->interface, XC_PAGE_SIZE);
con->interface = NULL;
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
 }
  
 static int console_create_ring(struct console *con)
@@ -698,7 +700,7 @@ static int console_create_ring(struct console *con)
free(type);
 
/* If using ring_ref and it has changed, remap */
-   if (ring_ref != con->ring_ref && con->ring_ref != -1)
+   if (ring_ref != con->ring_ref && con->ring_ref != XEN_INVALID_PFN)
console_unmap_interface(con);
 
if (!con->interface && xgt_handle && con->use_gnttab) {
@@ -706,7 +708,7 @@ static int console_create_ring(struct console *con)
con->interface = xengnttab_map_grant_ref(xgt_handle,
dom->domid, GNTTAB_RESERVED_CONSOLE,
PROT_READ|PROT_WRITE);
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
}
if (!con->interface) {
/* Fall back to xc_map_foreign_range */
@@ -812,7 +814,7 @@ static int console_init(struct console *con, struct domain 
*dom, void **data)
con->master_pollfd_idx = -1;
con->slave_fd = -1;
con->log_fd = -1;
-   con->ring_ref = -1;
+   con->ring_ref = XEN_INVALID_PFN;
con->local_port = -1;
con->remote_port = -1;
con->xce_pollfd_idx = -1;
-- 
2.7.4


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