[Xen-devel] [linux-4.4 test] 140072: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim  20 guest-start/debian.repeat fail REGR. vs. 139698

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw 10 debian-di-install  fail pass in 140040
 test-armhf-armhf-xl-vhd  10 debian-di-install  fail pass in 140040

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 140040 never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 140040 never 
pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 140040 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 140040 never pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   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-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux3904234bd04fa7c40467e5d8b3301893fae16e87
baseline version:
 linux

Re: [Xen-devel] [PATCH] failing to set value to 0 in Grub2ConfigFile

[Steven Haigh]

I've had a tinker with the patch - I don't have a Fedora build system 
atm - so I just edited the file on the Dom0 and removed the pyc/pyo 
files. Same issue:


   pyGRUB  version 0.6

┌┐
│ Fedora (5.2.6-200.fc30.x86_64) 30 (Thirty) 
   │
│ Fedora (0-rescue-ee4b18b1898e4bf2b36ff71077b23b5e) 30 (Thirty) 
   │
│
   │
│
   │
│
   │
│
   │
│
   │
│
   │


└┘
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, 'a' to modify the kernel arguments
before booting, or 'c' for a command line.

The rescue entry is selected in the above example.

My crappy hack has been to edit /usr/libexec/xen/bin/pygrub and add 
sel=0 as follows:


   def image_index(self):
   if isinstance(self.cf.default, int):
   sel = self.cf.default
   elif self.cf.default.isdigit():
   sel = int(self.cf.default)
   sel = 0
   else:

I know this is horrible!

I'm still disabling BLSCFG in /etc/default/grub - otherwise the pygrub 
menu is completely empty.


I don't know what the solution is right now - but I do somewhat agree 
with ignoring anything inside an if statement in grub.cfg - as the 
logic is ignored anyway. Do you still need to read the grubenv in doing 
this?


I assume the read for grubenv is to get the 'saved_entry' value?

Steven Haigh

 net...@crc.id.au  https://www.crc.id.au
 +613 9001 6090    +614 1293 5897


On Wed, Aug 14, 2019 at 7:51 AM, "YOUNG, MICHAEL A." 
 wrote:

On Tue, 13 Aug 2019, Andrew Cooper wrote:


 On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
 I have been looking at the pygrub code to see if it is possible to 
cope
 with grub files with BLSCFG and spotted this minor issue in 
GrubConf.py
 where the code intends to replace ${saved_entry} and ${next_entry} 
with 0

 but doesn't succeed.

 Signed-off-by: Michael Young 


 Ah - this looks suspiciously like it might be the bugfix for an 
issue

 reported by Steven.

 Steven - do you mind giving this patch a try for your "Fedora 30 
DomU -

 pygrub always boots the second menu option" problem?


Sadly I don't think it is that simple and to it properly would require
parsing if clauses in the grub file and also reading variables from 
the

grubenv file.

I do however have an idea which might work which is to ignore 
anything in
if clauses, read the grubenv file (which I now have a hacky way of 
doing)

and treating the value of next_entry or saved_entry as the setting for
the default kernel to pick. If I finish a patch that does this I will 
post
it on the list, but I very much doubt it will be of commitable 
quality.


Michael Young

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




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

[Xen-devel] [linux-4.19 test] 140061: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313

Tests which are failing intermittently (not blocking):
 test-arm64-arm64-examine 11 examine-serial/bootloader fail in 139883 pass in 
140061
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
139883

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop 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
 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

version targeted for testing:
 linux893af1c79e42e53af0da22165b46eea135af0613
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  284 days
Failing since129412  2018-11-04 14:10:15 Z  282 days  196 attempts
Testing same since   139883  2019-08-09 23:10:54 Z4 days5 attempts


2437 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Dario Faggioli]

On Tue, 2019-08-13 at 14:14 -0700, Stefano Stabellini wrote:
> On Tue, 13 Aug 2019, Dario Faggioli wrote:
> > 
> > I am attaching an updated debug patch, with an additional printk
> > when
> > we reach the point, within the null scheduler, when the vcpu would
> > wake
> > up (to check whether the problem is that we never reach that point,
> > or
> > something else).
> 
> See attached.
>
Ok, so we're not missing an "online call" nor a wakeup.

As Julien has identified, we seem to be stuck in a loop.

Now, while staring at the code of that loop, I've seen that pick_cpu()
may mess up with the scratch cpumask for the CPU, which I don't think
is a good thing.

So, can you also try this third debug-patch?

Thanks and Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 26c6f0f129..f90b146209 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -455,6 +455,7 @@ static void null_vcpu_insert(const struct scheduler *ops, struct vcpu *v)
 
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "Not inserting %pv (not online!)\n", v);
 vcpu_schedule_unlock_irq(lock, v);
 return;
 }
@@ -516,6 +517,7 @@ static void null_vcpu_remove(const struct scheduler *ops, struct vcpu *v)
 /* If offline, the vcpu shouldn't be assigned, nor in the waitqueue */
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "Not removing %pv (wasn't online!)\n", v);
 ASSERT(per_cpu(npc, v->processor).vcpu != v);
 ASSERT(list_empty(>waitq_elem));
 goto out;
@@ -571,14 +573,17 @@ static void null_vcpu_wake(const struct scheduler *ops, struct vcpu *v)
  */
 if ( unlikely(per_cpu(npc, cpu).vcpu != v && list_empty(>waitq_elem)) )
 {
+cpumask_t mask;
+
+dprintk(XENLOG_G_INFO, "%pv is waking up after having been offline\n", v);
 spin_lock(>waitq_lock);
 list_add_tail(>waitq_elem, >waitq);
 spin_unlock(>waitq_lock);
 
-cpumask_and(cpumask_scratch_cpu(cpu), v->cpu_hard_affinity,
+cpumask_and(, v->cpu_hard_affinity,
 cpupool_domain_cpumask(v->domain));
 
-if ( !cpumask_intersects(>cpus_free, cpumask_scratch_cpu(cpu)) )
+if ( !cpumask_intersects(>cpus_free, ) )
 {
 dprintk(XENLOG_G_WARNING, "WARNING: d%dv%d not assigned to any CPU!\n",
 v->domain->domain_id, v->vcpu_id);
@@ -595,7 +600,7 @@ static void null_vcpu_wake(const struct scheduler *ops, struct vcpu *v)
  * - if we're racing already, and if there still are free cpus, try
  *   again.
  */
-while ( cpumask_intersects(>cpus_free, cpumask_scratch_cpu(cpu)) )
+while ( cpumask_intersects(>cpus_free, ) )
 {
 unsigned int new_cpu = pick_cpu(prv, v);
 
@@ -635,6 +640,8 @@ static void null_vcpu_sleep(const struct scheduler *ops, struct vcpu *v)
 }
 else if ( per_cpu(npc, cpu).vcpu == v )
 tickled = vcpu_deassign(prv, v);
+
+dprintk(XENLOG_G_INFO, "%pv is, apparently, going offline (tickled=%d)\n", v, tickled);
 }
 
 /* If v is not assigned to a pCPU, or is not running, no need to bother */
@@ -697,6 +704,8 @@ static void null_vcpu_migrate(const struct scheduler *ops, struct vcpu *v,
  */
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "%pv is, apparently, going offline\n", v);
+
 spin_lock(>waitq_lock);
 list_del_init(>waitq_elem);
 spin_unlock(>waitq_lock);


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

[Xen-devel] [ovmf test] 140068: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 073f2cede820782e37e31bd6664aa53b79bbade4
baseline version:
 ovmf ecc32c90ee4ad557205cb2725619a3cc2f45ebd0

Last test of basis   140047  2019-08-13 05:20:08 Z0 days
Testing same since   140068  2019-08-13 17:09:37 Z0 days1 attempts


People who touched revisions under test:
  Liming Gao 
  Marc W Chen 
  Shenglei Zhang 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   ecc32c90ee..073f2cede8  073f2cede820782e37e31bd6664aa53b79bbade4 -> 
xen-tested-master

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-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

version targeted for testing:
 xen  243cc95d485846e35f5e2445fdaafe77c8c114d2
baseline version:
 xen  24575e2c1b39d3f2c148d69bb1a87ca2ef2c6395

Last test of basis   140071  2019-08-13 18:03:58 Z0 days
Testing same since   140081  2019-08-13 22:00:32 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   24575e2c1b..243cc95d48  243cc95d485846e35f5e2445fdaafe77c8c114d2 -> smoke

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim   16 guest-localmigrate   fail REGR. vs. 139876
 test-armhf-armhf-xl   7 xen-boot fail REGR. vs. 139876

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-examine 11 examine-serial/bootloaderfail  like 139876
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 139876
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 139876
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 139876
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 139876
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 139876
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 139876
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 139876
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 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-amd64-amd64-libvirt-vhd 12 migrate-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-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  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-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  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
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  6a4a62534853b4d20b44990e0d56c665b1ff55ae
baseline version:
 xen  6c9639a72f0ca3a9430ef75f375877182281fdef

Last test of basis   139876  2019-08-09 18:46:56 Z4 days

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

[osstest service owner]

-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ws16-amd64 blocked 
 test-amd64-i386-xl-qemuu-ws16-amd64  blocked 
 test-armhf-armhf-xl-arndale  pass
 test-amd64-amd64-xl-credit1  blocked 
 test-arm64-arm64-xl-credit1  pass
 test-armhf-armhf-xl-credit1  pass
 test-amd64-amd64-xl-credit2  blocked 
 test-arm64-arm64-xl-credit2  pass
 test-armhf-armhf-xl-credit2  pass
 test-armhf-armhf-xl-cubietruck   pass
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrictblocked 
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-amd64-xl-qemuu-win10-i386 blocked 
 test-amd64-i386-xl-qemuu-win10-i386  blocked 
 test-amd64-amd64-qemuu-nested-intel  blocked 
 test-amd64-amd64-xl-pvhv2-intel  blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 test-armhf-armhf-xl-multivcpupass
 test-amd64-amd64-pairblocked 
 test-amd64-i386-pair blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-amd64-amd64-amd64-pvgrubblocked 
 test-amd64-amd64-i386-pvgrub blocked 
 test-amd64-amd64-xl-pvshim   blocked 
 test-amd64-i386-xl-pvshimblocked 
 test-amd64-amd64-pygrub  blocked 
 test-amd64-amd64-xl-qcow2blocked 
 test-armhf-armhf-libvirt-raw pass
 test-amd64-i386-xl-raw   blocked 
 test-amd64-amd64-xl-rtds blocked 
 test-armhf-armhf-xl-rtds pass
 test-arm64-arm64-xl-seattle  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  blocked 
 test-amd64-amd64-xl-shadow   blocked 
 test-amd64-i386-xl-shadowblocked 
 test-arm64-arm64-xl-thunderx pass
 test-amd64-amd64-libvirt-vhd blocked 
 test-armhf-armhf-xl-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


Not pushing.


commit 968ff692cf5096a9e0d33e7e4a7fff10edb63001
Merge: 5e7bcdcfe6 310cda5b5e
Author: Peter Maydell 
Date:   Tue Aug 13 11:35:30 2019 +0100

Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190813' 
into staging

ppc patch queue 2019-08-13 (last minute qemu-4.1 fixes)

Here's a very, very last minute pull request for qemu-4.1.  This fixes
two nasty bugs with the XIVE interrupt controller in "dual" mode
(where the guest decides which interrupt controller it wants to use).
One occurs when resetting the guest while I/O is active, and the other
with migration of hotplugged CPUs.

The timing here is very unfortunate.  Alas, we only spotted these bugs
very late, and I was sick last week, delaying analysis and fix even
further.

This series hasn't had nearly as much testing as I'd really like, but
I'd still like to squeeze it into qemu-4.1 if possible, since
definitely fixing two bad bugs seems like an acceptable tradeoff for
  

Re: [Xen-devel] Xen-unstable staging build broken by pvshim patches.

[Sander Eikelenboom]

On 13/08/2019 23:05, Andrew Cooper wrote:
> On 13/08/2019 22:03, Sander Eikelenboom wrote:
>> On 13/08/2019 15:31, Andrew Cooper wrote:
>>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
 On 13/08/2019 13:21, Andrew Cooper wrote:
> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
 On 08/08/2019 23:14, Andrew Cooper wrote:
> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>> On 08/08/2019 23:05, Andrew Cooper wrote:
>>> On 08/08/2019 21:59, Sander Eikelenboom wrote:
 Hi Andrew,

 It seems the pvshim patches in xen-unstable staging break the 
 build on my machine.
 I cloned a fresh tree to be sure, haven't checked which of the two 
 commits causes it:
 060f4eee0fb408b316548775ab921e16b7acd0e0 or 
 32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3

 --
 Sander



 [ -d //usr/local/lib/xen/boot ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -d -m0755 -p //usr/local/lib/xen/boot
 [ -d //usr/local/lib/debug/usr/local/lib/xen/boot ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -d -m0755 -p //usr/local/lib/debug/usr/local/lib/xen/boot
 [ ! -e hvmloader/hvmloader ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p hvmloader/hvmloader //usr/local/lib/xen/boot
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p seabios-dir/out/bios.bin 
 //usr/local/lib/xen/boot/seabios.bin
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p xen-dir/xen-shim //usr/local/lib/xen/boot/xen-shim
 install: cannot stat 'xen-dir/xen-shim': No such file or directory
 make[4]: *** [Makefile:52: install] Error 1
 make[4]: Leaving directory 
 '/usr/src/new/xen-unstable/tools/firmware'
 make[3]: *** 
 [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:237: 
 subdir-install-firmware] Error 2
 make[3]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make[2]: *** 
 [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:232: 
 subdirs-install] Error 2
 make[2]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make[1]: *** [Makefile:73: install] Error 2
 make[1]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make: *** [Makefile:131: install-tools] Error 2
>>> That's weird.
>>>
>>> Do you have the full log?  The real failure was somewhere earlier 
>>> where
>>> xen-shim didn't get started.
>>>
>>> ~Andrew
>>>
>> Hmm if forgot and thus forgot to mention my build script disables 
>> some stuff:
>> ./configure --disable-qemu-traditional --disable-stubdom 
>> --disable-docs --disable-rombios
>>
>> Could be that one of those doesn't work anymore.
> The only interesting one would be --disable-rombios, which does make
> changes in this area of the build, but everything I changed was inside
> the xen-dir/ directory so shouldn't interact.>
> ~Andrew
>
 It indeed seems to be some interaction with --disable-rombios, with 
 just
 a plain ./configure it builds fine.
 Logs when building with --disable-rombios are attached.
>>> Right.  So the build itself works, but the subsequent `make install` 
>>> fails.
>>>
>>> And to confirm, a build of 8d54a6adf (the parent of my first shim
>>> commit) works entirely fine?
>>>
>>> ~Andrew
>>>
>> Just rechecked, and yes that builds and installs fine (with 
>> --disable-rombios).
> Which base distro are you using?  I'm unable to reproduce any build
> failures locally.
>
> ~Andrew
>
 Debian 10 / Buster.
>>> Do you have your full build script available, and is it built fully from
>>> clean?
>>>
>>> How beefy is your build machine?  From the logs it is clearly a parallel
>>> build but I don't see an explicit -j in the logs.
>>>
>>> I still cant reproduce this, even in a buster container.
>>>
>>> ~Andrew
>>>
>> The machine is not that beefy, but a six core AMD, but no OOMs or anything.
>>
>> The script is basically just and some changing of dirs:
>> make clean && ./configure --disable-qemu-traditional --disable-stubdom 
>> --disable-docs --disable-rombios && make -j6 && make -j6 install
>>
>> I tried some variants just plain from the command line without any scripts:
>> After a fresh clone of 

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Julien Grall]

On Tue, 13 Aug 2019, 23:39 Dario Faggioli,  wrote:

> On Tue, 2019-08-13 at 19:43 +0100, Julien Grall wrote:
> > On 8/13/19 6:34 PM, Dario Faggioli wrote:
> > > On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> > > >
> > > So, unless the flag gets cleared again, or something else happens
> > > that
> > > makes the vCPU(s) fail the vcpu_runnable() check in
> > > domain_unpause()->vcpu_wake(), I don't see why the wakeup that let
> > > the
> > > null scheduler start scheduling the vCPU doesn't happen... as it
> > > instead does on x86 or !dom0less ARM (because, as far as I've
> > > understood, it's only dom0less that doesn't work, it this correct?)
> >
> > Yes, I quickly tried to use NULL scheduler with just dom0 and it
> > boots.
> >
> Ok.
>
> > Interestingly, I can't see the log:
> >
> > (XEN) Freed 328kB init memory.
> >
> > This is called as part of init_done before CPU0 goes into the idle
> > loop.
> >
> > Adding more debug, it is getting stuck when calling
> > domain_unpause_by_controller for dom0. Specifically vcpu_wake on
> > dom0v0.
> >
> Wait... Is this also with just dom0, or when trying dom0less with some
> domUs?
>

Dom0 is unpaused after all the domUs. In other words, the scheduler will
see domUs first.



> > The loop to assign a pCPU in null_vcpu_wake() is turning into an
> > infinite loop. Indeed the loop is trying to pick CPU0 for dom0v0 that
> > is
> > already used by dom1v0. So the problem is in pick_cpu() or the data
> > used
> > by it.
> >
> Ah, interesting...
>
> > It feels to me this is an affinity problem. Note that I didn't
> > request
> > to pin dom0 vCPUs.
> >
> Yep, looking better, I think I've seen something suspicious now. I'll
> send another debug patch.
>

You may want to see my last e-mail first just in case it rings a bell. :) I
did more debugging during the evening.

Cheers,



> Regards
> --
> Dario Faggioli, Ph.D
> http://about.me/dario.faggioli
> Virtualization Software Engineer
> SUSE Labs, SUSE https://www.suse.com/
> ---
> <> (Raistlin Majere)
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Dario Faggioli]

On Tue, 2019-08-13 at 19:43 +0100, Julien Grall wrote:
> On 8/13/19 6:34 PM, Dario Faggioli wrote:
> > On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> > > 
> > So, unless the flag gets cleared again, or something else happens
> > that
> > makes the vCPU(s) fail the vcpu_runnable() check in
> > domain_unpause()->vcpu_wake(), I don't see why the wakeup that let
> > the
> > null scheduler start scheduling the vCPU doesn't happen... as it
> > instead does on x86 or !dom0less ARM (because, as far as I've
> > understood, it's only dom0less that doesn't work, it this correct?)
> 
> Yes, I quickly tried to use NULL scheduler with just dom0 and it
> boots.
> 
Ok.

> Interestingly, I can't see the log:
> 
> (XEN) Freed 328kB init memory.
> 
> This is called as part of init_done before CPU0 goes into the idle
> loop.
> 
> Adding more debug, it is getting stuck when calling 
> domain_unpause_by_controller for dom0. Specifically vcpu_wake on
> dom0v0.
> 
Wait... Is this also with just dom0, or when trying dom0less with some
domUs?

> The loop to assign a pCPU in null_vcpu_wake() is turning into an 
> infinite loop. Indeed the loop is trying to pick CPU0 for dom0v0 that
> is 
> already used by dom1v0. So the problem is in pick_cpu() or the data
> used 
> by it.
> 
Ah, interesting...

> It feels to me this is an affinity problem. Note that I didn't
> request 
> to pin dom0 vCPUs.
> 
Yep, looking better, I think I've seen something suspicious now. I'll
send another debug patch.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Julien Grall]

Hi,

On 8/13/19 7:43 PM, Julien Grall wrote:
> 
> 
> On 8/13/19 6:34 PM, Dario Faggioli wrote:
>> On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
>>> Hi Dario,
>>>
>> Hello!
>>
>>> On 8/13/19 4:27 PM, Dario Faggioli wrote:
 On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
>
 In my (x86 and "dom0full") testbox, this seems to come from
 domain_unpause_by_systemcontroller(dom0) called by
 xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().

 I don't know if domain construction in an ARM dom0less system works
 similarly, though. What we want, is someone calling either
 vcpu_wake()
 or vcpu_unpause(), after having cleared _VPF_down from pause_flags.
>>>
>>> Looking at create_domUs() there is a call to
>>> domain_unpause_by_controller for each domUs.
>>>
>> Yes, I saw that. And I've seen the one done don dom0, at the end of
>> xen/arch/arm/setup.c:start_xen(), as well.
>>
>> Also, both construct_dom0() (still from start_xen()) and
>> construct_domU() (called from create_domUs()) call construct_domain(),
>> which does clear_bit(_VPF_down), setting the domain to online.
>>
>> So, unless the flag gets cleared again, or something else happens that
>> makes the vCPU(s) fail the vcpu_runnable() check in
>> domain_unpause()->vcpu_wake(), I don't see why the wakeup that let the
>> null scheduler start scheduling the vCPU doesn't happen... as it
>> instead does on x86 or !dom0less ARM (because, as far as I've
>> understood, it's only dom0less that doesn't work, it this correct?)
> 
> Yes, I quickly tried to use NULL scheduler with just dom0 and it boots.
> 
> Interestingly, I can't see the log:
> 
> (XEN) Freed 328kB init memory.
> 
> This is called as part of init_done before CPU0 goes into the idle loop.
> 
> Adding more debug, it is getting stuck when calling 
> domain_unpause_by_controller for dom0. Specifically vcpu_wake on dom0v0.
> 
> The loop to assign a pCPU in null_vcpu_wake() is turning into an 
> infinite loop. Indeed the loop is trying to pick CPU0 for dom0v0 that is 
> already used by dom1v0. So the problem is in pick_cpu() or the data used 
> by it.
> 
> It feels to me this is an affinity problem. Note that I didn't request 
> to pin dom0 vCPUs.

I did a bit more digging, as I pointed out before, pick_cpu() is
returning pCPU0. This is because per_cpu(ncp, 0) == NULL.

per_cpu(npc, 0) will be set by vcpu_assign(). AFAIU, the function
is called during scheduling. As CPU0 is not able to serve softirq until it
finishes to initialize, per_cpu(npc, 0) will still be NULL when trying to
wake dom0v0.

My knowledge of the scheduler is pretty limited, so I will leave to
Dario and George suggesting a fix :).

On a side note, I have tried to hack a bit the Dom0 vCPU allocation
to see if I can help you to reproduce it on x86. But I stumbled across
another error while bringing up d0v1:

(XEN) Assertion 'lock == per_cpu(schedule_data, v->processor).schedule_lock' 
failed at /home/julieng/works/xen/xen/include/xen/sched-if.h:108
(XEN) [ Xen-4.13-unstable  arm64  debug=y   Not tainted ]
(XEN) CPU:0

[...]

(XEN) Xen call trace:
(XEN)[<002251b8>] vcpu_wake+0x550/0x554 (PC)
(XEN)[<00224da4>] vcpu_wake+0x13c/0x554 (LR)
(XEN)[<00261624>] vpsci.c#do_common_cpu_on+0x134/0x1c4
(XEN)[<00261a04>] do_vpsci_0_2_call+0x294/0x3d0
(XEN)[<002612c0>] vsmc.c#vsmccc_handle_call+0x3a0/0x4b0
(XEN)[<00261484>] do_trap_hvc_smccc+0x28/0x4c
(XEN)[<00257efc>] do_trap_guest_sync+0x508/0x5d8
(XEN)[<0026542c>] entry.o#guest_sync_slowpath+0x9c/0xcc
(XEN) 
(XEN) 
(XEN) Panic on CPU 0:
(XEN) Assertion 'lock == per_cpu(schedule_data, v->processor).schedule_lock' 
failed at 
/home/julieng/works/xen/xen/include/xen/sched-***

I only try to create all the vCPU to pCPU 0 with the following code:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..ce92e3841f 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2004,7 +2004,7 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
 for ( i = 1, cpu = 0; i < d->max_vcpus; i++ )
 {
 cpu = cpumask_cycle(cpu, _online_map);
-if ( vcpu_create(d, i, cpu) == NULL )
+if ( vcpu_create(d, i, 0) == NULL )
 {
 printk("Failed to allocate dom0 vcpu %d on pcpu %d\n", i, cpu);
 break;

I am not entirely sure whether the problem is related.

Anyway, I have wrote the following patch to reproduce on Arm without
dom0less:

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..20246ae475 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2004,7 +2004,7 @@ static int __init construct_domain(struct domain *d, 
struct kernel_info *kinfo)
 for ( i = 1, cpu = 0; i 

[Xen-devel] [PATCH] xen/docs: arm: Update dom0less binding and example

[Julien Grall]

The binding for the dom0less module does not match Xen implementation.
Any module should contain the compatible "multiboot,module" to be
recognized.

This was clearly an oversight as other examples with Xen code base
provide the compatible "multiboot,module".

So fix the binding and the example associated to it.

Signed-off-by: Julien Grall 

---

Cc: viktor_mi...@epam.com

We probably want to consolidate all the dom0less documentation in
one place rather than having to fix documation issues in a multiple
places one by one.
---
 docs/misc/arm/device-tree/booting.txt | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/misc/arm/device-tree/booting.txt 
b/docs/misc/arm/device-tree/booting.txt
index 317a9e962a..0fafa01b5d 100644
--- a/docs/misc/arm/device-tree/booting.txt
+++ b/docs/misc/arm/device-tree/booting.txt
@@ -160,7 +160,7 @@ The kernel sub-node has the following properties:
 
 - compatible
 
-"multiboot,kernel"
+"multiboot,kernel", "multiboot,module"
 
 - reg
 
@@ -175,7 +175,7 @@ The ramdisk sub-node has the following properties:
 
 - compatible
 
-"multiboot,ramdisk"
+"multiboot,ramdisk", "multiboot,module"
 
 - reg
 
@@ -196,13 +196,13 @@ chosen {
 vpl011;
 
 module@0x4a00 {
-compatible = "multiboot,kernel";
+compatible = "multiboot,kernel", "multiboot,module";
 reg = <0x0 0x4a00 0xff>;
 bootargs = "console=ttyAMA0 init=/bin/sh";
 };
 
 module@0x4b00 {
-compatible = "multiboot,ramdisk";
+compatible = "multiboot,ramdisk", "multiboot,module";
 reg = <0x0 0x4b00 0xff>;
 };
 };
@@ -215,13 +215,13 @@ chosen {
 cpus = <1>;
 
 module@0x4c00 {
-compatible = "multiboot,kernel";
+compatible = "multiboot,kernel", "multiboot,module";
 reg = <0x0 0x4c00 0xff>;
 bootargs = "console=ttyAMA0 init=/bin/sh";
 };
 
 module@0x4d00 {
-compatible = "multiboot,ramdisk";
+compatible = "multiboot,ramdisk", "multiboot,module";
 reg = <0x0 0x4d00 0xff>;
 };
 };
-- 
2.11.0


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

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Stefano Stabellini]

On Tue, 13 Aug 2019, Dario Faggioli wrote:
> On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> > On Fri, 9 Aug 2019, Dario Faggioli wrote:
> > > Can you help me with this, e.g., by providing some more info and,
> > > if
> > > possible, logs?
> > 
> > I am attaching the logs. 
> >
> Thanks!
> 
> > Interestingly, I get a bunch of:
> > 
> > (XEN) *** LOADING DOMU cpus=1 memory=4KB ***
> > (XEN) sched_null.c:458: Not inserting d2v0 (not online!)
> > 
> > Maybe we are missing a call to online the vcpus somewhere in
> > xen/arch/arm/domain_build.c:construct_domain?
> > 
> Actually, those lines are normal, because vCPUs are created offline.
> (see the set_bit(_VPF_down) in vcpu_create()).
> 
> The problem is why aren't they coming up. Basically, you're missing a
> call to vcpu_wake().
> 
> In my (x86 and "dom0full") testbox, this seems to come from
> domain_unpause_by_systemcontroller(dom0) called by
> xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().
> 
> I don't know if domain construction in an ARM dom0less system works
> similarly, though. What we want, is someone calling either vcpu_wake()
> or vcpu_unpause(), after having cleared _VPF_down from pause_flags.
> 
> I am attaching an updated debug patch, with an additional printk when
> we reach the point, within the null scheduler, when the vcpu would wake
> up (to check whether the problem is that we never reach that point, or
> something else).

See attached.
(XEN) Xen version 4.13-unstable (sstabellini@) (aarch64-linux-gnu-gcc (Linaro 
GCC 5.3-2016.05) 5.3.1 20160412) debug=y  Tue Aug 13 14:12:29 PDT 2019
(XEN) Latest ChangeSet: Fri Dec 21 13:44:30 2018 + git:243cc95d48-dirty
(XEN) build-id: 95462325c4240e3913a88e8465cd8a3aaf007b53
(XEN) Processor: 410fd034: "ARM Limited", variant: 0x0, part 0xd03, rev 0x4
(XEN) 64-bit Execution:
(XEN)   Processor Features: 1100 
(XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN) Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 10305106 
(XEN)   Auxiliary Features:  
(XEN)   Memory Model Features: 1122 
(XEN)   ISA Features:  00011120 
(XEN) 32-bit Execution:
(XEN)   Processor Features: 1231:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 
(XEN)   Memory Model Features: 10101105 4000 0126 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121
(XEN) Using SMC Calling Convention v1.1
(XEN) Using PSCI v1.1
(XEN) SMP: Allowing 4 CPUs
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 5 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=f901
(XEN) gic_cpu_addr=f902
(XEN) gic_hyp_addr=f904
(XEN) gic_vcpu_addr=f906
(XEN) gic_maintenance_irq=25
(XEN) GICv2: Adjusting CPU interface base to 0xf902f000
(XEN) GICv2: 192 lines, 4 cpus (IID ).
(XEN) XSM Framework v1.0.0 initialized
(XEN) Initialising XSM SILO mode
(XEN) WARNING: hypervisor-timer IRQ26 is not level triggered.
(XEN) WARNING: virtual-timer IRQ27 is not level triggered.
(XEN) WARNING: NS-physical-timer IRQ30 is not level triggered.
(XEN) Using scheduler: null Scheduler (null)
(XEN) Initializing null scheduler
(XEN) WARNING: This is experimental software in development.
(XEN) Use at your own risk.
(XEN) Allocated console ring of 32 KiB.
(XEN) CPU0: Guest atomics will try 1 times before pausing the domain
(XEN) Bringing up CPU1
(XEN) WARNING: hypervisor-timer IRQ26 is not level triggered.
(XEN) WARNING: virtual-timer IRQ27 is not level triggered.
(XEN) WARNING: NS-physical-timer IRQ30 is not level triggered.
(XEN) CPU1: Guest atomics will try 1 times before pausing the domain
(XEN) Bringing up CPU2
(XEN) CPU 1 booted.
(XEN) WARNING: hypervisor-timer IRQ26 is not level triggered.
(XEN) WARNING: virtual-timer IRQ27 is not level triggered.
(XEN) WARNING: NS-physical-timer IRQ30 is not level triggered.
(XEN) CPU2: Guest atomics will try 1 times before pausing the domain
(XEN) CPU 2 booted.
(XEN) Bringing up CPU3
(XEN) WARNING: hypervisor-timer IRQ26 is not level triggered.
(XEN) WARNING: virtual-timer IRQ27 is not level triggered.
(XEN) WARNING: NS-physical-timer IRQ30 is not level triggered.
(XEN) CPU3: Guest atomics will try 1 times before pausing the domain
(XEN) CPU 3 booted.
(XEN) Brought up 4 CPUs
(XEN) P2M: 40-bit IPA with 40-bit PA and 8-bit VMID
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558
(XEN) smmu: /amba/smmu@fd80: probing hardware configuration...
(XEN) smmu: /amba/smmu@fd80: SMMUv2 with:
(XEN) smmu: /amba/smmu@fd80:stage 2 translation
(XEN) smmu: /amba/smmu@fd80:stream matching with 48 register 
groups, mask 0x7fff
(XEN) smmu: 

Re: [Xen-devel] [PATCH] failing to set value to 0 in Grub2ConfigFile

[Andrew Cooper]

On 13/08/2019 22:02, YOUNG, MICHAEL A. wrote:
> I have been looking at the pygrub code to see if it is possible to cope 
> with grub files with BLSCFG and spotted this minor issue in GrubConf.py 
> where the code intends to replace ${saved_entry} and ${next_entry} with 0 
> but doesn't succeed.
>
> Signed-off-by: Michael Young 

Ah - this looks suspiciously like it might be the bugfix for an issue
reported by Steven.

Steven - do you mind giving this patch a try for your "Fedora 30 DomU -
pygrub always boots the second menu option" problem?

~Andrew
>From a08eff9b1b881dc61f9427153706e2d5b3bd0e01 Mon Sep 17 00:00:00 2001
From: Michael Young 
Date: Tue, 13 Aug 2019 21:15:02 +0100
Subject: [PATCH] failing to set value to 0 in Grub2ConfigFile

In Grub2ConfigFile the code to handle ${saved_entry} and ${next_entry}
sets arg = "0" but this now does nothing following
"tools/pygrub: Make pygrub understand default entry in string format"
d1b93ea2615bd789ee28901f1f1c05ffb319cb61
which replaced arg.strip() with arg_strip in the following line.
This patch restores the previous behaviour.
---
 tools/pygrub/src/GrubConf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index 594139bac7..73f1bbed2f 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -440,7 +440,7 @@ class Grub2ConfigFile(_GrubConfigFile):
 arg_strip = arg.strip()
 if arg_strip == "${saved_entry}" or arg_strip == 
"${next_entry}":
 logging.warning("grub2's saved_entry/next_entry not 
supported")
-arg = "0"
+arg_strip = "0"
 setattr(self, self.commands[com], arg_strip)
 else:
 logging.info("Ignored directive %s" %(com,))
-- 
2.21.0

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

Re: [Xen-devel] Xen-unstable staging build broken by pvshim patches.

[Andrew Cooper]

On 13/08/2019 22:03, Sander Eikelenboom wrote:
> On 13/08/2019 15:31, Andrew Cooper wrote:
>> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>>> On 13/08/2019 13:21, Andrew Cooper wrote:
 On 09/08/2019 00:28, Sander Eikelenboom wrote:
> On 09/08/2019 00:44, Andrew Cooper wrote:
>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>>> On 08/08/2019 23:14, Andrew Cooper wrote:
 On 08/08/2019 22:16, Sander Eikelenboom wrote:
> On 08/08/2019 23:05, Andrew Cooper wrote:
>> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>>> Hi Andrew,
>>>
>>> It seems the pvshim patches in xen-unstable staging break the build 
>>> on my machine.
>>> I cloned a fresh tree to be sure, haven't checked which of the two 
>>> commits causes it:
>>> 060f4eee0fb408b316548775ab921e16b7acd0e0 or 
>>> 32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3
>>>
>>> --
>>> Sander
>>>
>>>
>>>
>>> [ -d //usr/local/lib/xen/boot ] || 
>>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>>> -d -m0755 -p //usr/local/lib/xen/boot
>>> [ -d //usr/local/lib/debug/usr/local/lib/xen/boot ] || 
>>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>>> -d -m0755 -p //usr/local/lib/debug/usr/local/lib/xen/boot
>>> [ ! -e hvmloader/hvmloader ] || 
>>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>>> -m0644 -p hvmloader/hvmloader //usr/local/lib/xen/boot
>>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>>> -m0644 -p seabios-dir/out/bios.bin 
>>> //usr/local/lib/xen/boot/seabios.bin
>>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>>> -m0644 -p xen-dir/xen-shim //usr/local/lib/xen/boot/xen-shim
>>> install: cannot stat 'xen-dir/xen-shim': No such file or directory
>>> make[4]: *** [Makefile:52: install] Error 1
>>> make[4]: Leaving directory 
>>> '/usr/src/new/xen-unstable/tools/firmware'
>>> make[3]: *** 
>>> [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:237: 
>>> subdir-install-firmware] Error 2
>>> make[3]: Leaving directory '/usr/src/new/xen-unstable/tools'
>>> make[2]: *** 
>>> [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:232: 
>>> subdirs-install] Error 2
>>> make[2]: Leaving directory '/usr/src/new/xen-unstable/tools'
>>> make[1]: *** [Makefile:73: install] Error 2
>>> make[1]: Leaving directory '/usr/src/new/xen-unstable/tools'
>>> make: *** [Makefile:131: install-tools] Error 2
>> That's weird.
>>
>> Do you have the full log?  The real failure was somewhere earlier 
>> where
>> xen-shim didn't get started.
>>
>> ~Andrew
>>
> Hmm if forgot and thus forgot to mention my build script disables 
> some stuff:
> ./configure --disable-qemu-traditional --disable-stubdom 
> --disable-docs --disable-rombios
>
> Could be that one of those doesn't work anymore.
 The only interesting one would be --disable-rombios, which does make
 changes in this area of the build, but everything I changed was inside
 the xen-dir/ directory so shouldn't interact.>
 ~Andrew

>>> It indeed seems to be some interaction with --disable-rombios, with just
>>> a plain ./configure it builds fine.
>>> Logs when building with --disable-rombios are attached.
>> Right.  So the build itself works, but the subsequent `make install` 
>> fails.
>>
>> And to confirm, a build of 8d54a6adf (the parent of my first shim
>> commit) works entirely fine?
>>
>> ~Andrew
>>
> Just rechecked, and yes that builds and installs fine (with 
> --disable-rombios).
 Which base distro are you using?  I'm unable to reproduce any build
 failures locally.

 ~Andrew

>>> Debian 10 / Buster.
>> Do you have your full build script available, and is it built fully from
>> clean?
>>
>> How beefy is your build machine?  From the logs it is clearly a parallel
>> build but I don't see an explicit -j in the logs.
>>
>> I still cant reproduce this, even in a buster container.
>>
>> ~Andrew
>>
> The machine is not that beefy, but a six core AMD, but no OOMs or anything.
>
> The script is basically just and some changing of dirs:
> make clean && ./configure --disable-qemu-traditional --disable-stubdom 
> --disable-docs --disable-rombios && make -j6 && make -j6 install
>
> I tried some variants just plain from the command line without any scripts:
> After a fresh clone of current xen-unstable staging branch.
>
> Fails:make clean && ./configure --disable-rombios && make -j6 && make -j6 
> install
> Fails:make clean && 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-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

version targeted for testing:
 xen  24575e2c1b39d3f2c148d69bb1a87ca2ef2c6395
baseline version:
 xen  6a4a62534853b4d20b44990e0d56c665b1ff55ae

Last test of basis   140013  2019-08-12 17:00:57 Z1 days
Testing same since   140071  2019-08-13 18:03:58 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  David Woodhouse 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-amd64-libvirt pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   6a4a625348..24575e2c1b  24575e2c1b39d3f2c148d69bb1a87ca2ef2c6395 -> smoke

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

[Xen-devel] [PATCH] failing to set value to 0 in Grub2ConfigFile

[YOUNG, MICHAEL A.]

I have been looking at the pygrub code to see if it is possible to cope 
with grub files with BLSCFG and spotted this minor issue in GrubConf.py 
where the code intends to replace ${saved_entry} and ${next_entry} with 0 
but doesn't succeed.

Signed-off-by: Michael Young 

From a08eff9b1b881dc61f9427153706e2d5b3bd0e01 Mon Sep 17 00:00:00 2001
From: Michael Young 
Date: Tue, 13 Aug 2019 21:15:02 +0100
Subject: [PATCH] failing to set value to 0 in Grub2ConfigFile

In Grub2ConfigFile the code to handle ${saved_entry} and ${next_entry}
sets arg = "0" but this now does nothing following
"tools/pygrub: Make pygrub understand default entry in string format"
d1b93ea2615bd789ee28901f1f1c05ffb319cb61
which replaced arg.strip() with arg_strip in the following line.
This patch restores the previous behaviour.
---
 tools/pygrub/src/GrubConf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/pygrub/src/GrubConf.py b/tools/pygrub/src/GrubConf.py
index 594139bac7..73f1bbed2f 100644
--- a/tools/pygrub/src/GrubConf.py
+++ b/tools/pygrub/src/GrubConf.py
@@ -440,7 +440,7 @@ class Grub2ConfigFile(_GrubConfigFile):
 arg_strip = arg.strip()
 if arg_strip == "${saved_entry}" or arg_strip == 
"${next_entry}":
 logging.warning("grub2's saved_entry/next_entry not 
supported")
-arg = "0"
+arg_strip = "0"
 setattr(self, self.commands[com], arg_strip)
 else:
 logging.info("Ignored directive %s" %(com,))
-- 
2.21.0

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

Re: [Xen-devel] Xen-unstable staging build broken by pvshim patches.

[Sander Eikelenboom]

On 13/08/2019 15:31, Andrew Cooper wrote:
> On 13/08/2019 12:51, Sander Eikelenboom wrote:
>> On 13/08/2019 13:21, Andrew Cooper wrote:
>>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
 On 09/08/2019 00:44, Andrew Cooper wrote:
> On 08/08/2019 23:34, Sander Eikelenboom wrote:
>> On 08/08/2019 23:14, Andrew Cooper wrote:
>>> On 08/08/2019 22:16, Sander Eikelenboom wrote:
 On 08/08/2019 23:05, Andrew Cooper wrote:
> On 08/08/2019 21:59, Sander Eikelenboom wrote:
>> Hi Andrew,
>>
>> It seems the pvshim patches in xen-unstable staging break the build 
>> on my machine.
>> I cloned a fresh tree to be sure, haven't checked which of the two 
>> commits causes it:
>> 060f4eee0fb408b316548775ab921e16b7acd0e0 or 
>> 32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3
>>
>> --
>> Sander
>>
>>
>>
>> [ -d //usr/local/lib/xen/boot ] || 
>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>> -d -m0755 -p //usr/local/lib/xen/boot
>> [ -d //usr/local/lib/debug/usr/local/lib/xen/boot ] || 
>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>> -d -m0755 -p //usr/local/lib/debug/usr/local/lib/xen/boot
>> [ ! -e hvmloader/hvmloader ] || 
>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>> -m0644 -p hvmloader/hvmloader //usr/local/lib/xen/boot
>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>> -m0644 -p seabios-dir/out/bios.bin 
>> //usr/local/lib/xen/boot/seabios.bin
>> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
>> -m0644 -p xen-dir/xen-shim //usr/local/lib/xen/boot/xen-shim
>> install: cannot stat 'xen-dir/xen-shim': No such file or directory
>> make[4]: *** [Makefile:52: install] Error 1
>> make[4]: Leaving directory '/usr/src/new/xen-unstable/tools/firmware'
>> make[3]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:237: 
>> subdir-install-firmware] Error 2
>> make[3]: Leaving directory '/usr/src/new/xen-unstable/tools'
>> make[2]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:232: 
>> subdirs-install] Error 2
>> make[2]: Leaving directory '/usr/src/new/xen-unstable/tools'
>> make[1]: *** [Makefile:73: install] Error 2
>> make[1]: Leaving directory '/usr/src/new/xen-unstable/tools'
>> make: *** [Makefile:131: install-tools] Error 2
> That's weird.
>
> Do you have the full log?  The real failure was somewhere earlier 
> where
> xen-shim didn't get started.
>
> ~Andrew
>
 Hmm if forgot and thus forgot to mention my build script disables some 
 stuff:
 ./configure --disable-qemu-traditional --disable-stubdom 
 --disable-docs --disable-rombios

 Could be that one of those doesn't work anymore.
>>> The only interesting one would be --disable-rombios, which does make
>>> changes in this area of the build, but everything I changed was inside
>>> the xen-dir/ directory so shouldn't interact.>
>>> ~Andrew
>>>
>> It indeed seems to be some interaction with --disable-rombios, with just
>> a plain ./configure it builds fine.
>> Logs when building with --disable-rombios are attached.
> Right.  So the build itself works, but the subsequent `make install` 
> fails.
>
> And to confirm, a build of 8d54a6adf (the parent of my first shim
> commit) works entirely fine?
>
> ~Andrew
>
 Just rechecked, and yes that builds and installs fine (with 
 --disable-rombios).
>>> Which base distro are you using?  I'm unable to reproduce any build
>>> failures locally.
>>>
>>> ~Andrew
>>>
>> Debian 10 / Buster.
> 
> Do you have your full build script available, and is it built fully from
> clean?
> 
> How beefy is your build machine?  From the logs it is clearly a parallel
> build but I don't see an explicit -j in the logs.
> 
> I still cant reproduce this, even in a buster container.
> 
> ~Andrew
> 

The machine is not that beefy, but a six core AMD, but no OOMs or anything.

The script is basically just and some changing of dirs:
make clean && ./configure --disable-qemu-traditional --disable-stubdom 
--disable-docs --disable-rombios && make -j6 && make -j6 install

I tried some variants just plain from the command line without any scripts:
After a fresh clone of current xen-unstable staging branch.

Fails:make clean && ./configure --disable-rombios && make -j6 && make -j6 
install
Fails:make clean && ./configure --disable-rombios && make -j4 && make -j4 
install
Fails:make clean && ./configure --disable-rombios && make -j2 && make -j2 
install
Succeeds: make clean && ./configure --disable-rombios && 

Re: [Xen-devel] Terminology for "guest" - Was: [PATCH] docs/sphinx: Introduction

[Sarah Newman]

On 8/13/19 1:43 AM, George Dunlap wrote:




On Aug 13, 2019, at 3:59 AM, Sarah Newman  wrote:

On 8/12/19 8:01 AM, Andrew Cooper wrote:

On 12/08/2019 15:53, George Dunlap wrote:

On 8/8/19 10:13 AM, Julien Grall wrote:

Hi Jan,

On 08/08/2019 10:04, Jan Beulich wrote:

On 08.08.2019 10:43, Andrew Cooper wrote:

On 08/08/2019 07:22, Jan Beulich wrote:

On 07.08.2019 21:41, Andrew Cooper wrote:

--- /dev/null
+++ b/docs/glossary.rst
@@ -0,0 +1,37 @@
+Glossary
+
+
+.. Terms should appear in alphabetical order
+
+.. glossary::
+
+   control domain
+ A :term:`domain`, commonly dom0, with the permission and
responsibility
+ to create and manage other domains on the system.
+
+   domain
+ A domain is Xen's unit of resource ownership, and generally has
at the
+ minimum some RAM and virtual CPUs.
+
+ The terms :term:`domain` and :term:`guest` are commonly used
+ interchangeably, but they mean subtly different things.
+
+ A guest is a single virtual machine.
+
+ Consider the case of live migration where, for a period of
time, one
+ guest will be comprised of two domains, while it is in transit.
+
+   domid
+ The numeric identifier of a running :term:`domain`.  It is
unique to a
+ single instance of Xen, used as the identifier in various APIs,
and is
+ typically allocated sequentially from 0.
+
+   guest
+ See :term:`domain`

I think you want to mention the usual distinction here: Dom0 is,
while a domain, commonly not considered a guest.

To be honest, I had totally forgotten about that.  I guess now is the
proper time to rehash it in public.

I don't think the way it currently gets used has a clear or coherent set
of rules, because I can't think of any to describe how it does get used.

Either there are a clear and coherent (and simple!) set of rules for
what we mean by "guest", at which point they can live here in the
glossary, or the fuzzy way it is current used should cease.

What's fuzzy about Dom0 not being a guest (due to being a part of the
host instead)?

Dom0 is not part of the host if you are using an hardware domain. I
actually thought we renamed everything in Xen from Dom0 to hwdom to
avoid the confusion.

I also would rather avoid to treat "dom0" as not a guest. In normal
setup this is a more privilege guest, in other setup this may just be a
normal guest (think about partitioning).

A literal guest is someone who doesn't live in the building (or work in
the buliding, if you're in a hotel).  The fact that the staff cleaning
rooms are restricted in their privileges doesn't make them guests of the
hotel.

The toolstack domain, the hardware domain, the driver domain, the
xenstore domain, and so on are all part of the host system, designed to
allow you to use Xen to do the thing you actually want to do: Run guests.

And it's important that we have a word that distinguishes "domains that
we only care about because they make it possible to run other domains",
and "domains that we actually want to run".  "guest / host" is a natural
terminology for these.

We already have the word "domain", which includes dom0, driver domains,
toolstack domains, hardware domains, as well as guest domains.  We don't
need "guest" to be a synonym for "domain".

So...
Please can someone propose wording simple, clear wording for what
"guest" means.


A potentially untrusted domain.


But wouldn’t that include both driver domains and stubdomains?


Then how about: a domain which does not provide Xen-related services.





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

Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx

[Roman Shaposhnik]

Hi Roger,

sorry for the delay -- I hope you will understand that I actually had
a good reason. See below:

On Mon, Aug 12, 2019 at 1:57 AM Roger Pau Monné  wrote:
>
> Ping?
>
> I know I've posted this quite recently, but have you been able to test
> the two proposed patches?
>
> ie: the one here and:
>
> https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg00643.html
>
> I would like to figure out exactly what's going on and fix this
> properly.

Turns out this may actually be related to the BIOS version on these
boxes. I have
one with the BIOS build from 06/07/2018 and the other one is from 2017. So with
2 of your proposed patches -- we now have a 2x2 test matrix. The awful
part seems
to be that the behavior looks to be slightly different.

I need an extra day to summarize it all and I'll follow up quickly. It
just so far I lost
time trying to figure out while the same build would behave
differently on different
boxes only to find out that the BIOS is different (and the really
awful part is that
they both report as version 5.0.1.1 -- it is only when you look at the timestamp
of the build -- that's where you see them being different :-( ).

Thanks,
Roman.

> On Wed, Aug 07, 2019 at 09:35:34AM +0200, Roger Pau Monné wrote:
> > On Tue, Aug 06, 2019 at 02:48:51PM -0700, Roman Shaposhnik wrote:
> > > On Tue, Aug 6, 2019 at 9:18 AM Roger Pau Monné  
> > > wrote:
> > > >
> > > > On Fri, Aug 02, 2019 at 10:05:40AM +0200, Roger Pau Monné wrote:
> > > > > On Thu, Aug 01, 2019 at 11:25:04AM -0700, Roman Shaposhnik wrote:
> > > > > > This patch completely fixes the problem for me!
> > > > > >
> > > > > > Thanks Roger! I'd love to see this in Xen 4.13
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > It's still not clear to me why the previous approach didn't work, but
> > > > > I think this patch is better because it removes the usage of
> > > > > {set/clear}_identity_p2m_entry from PV domains. I will submit this
> > > > > formally now.
> > > >
> > > > Sorry to bother again, but since we still don't understand why the
> > > > previous fix didn't work for you, and I can't reproduce this with my
> > > > hardware, could you give the attached patch a try?
> > >
> > > No worries -- and thanks for helping to get it over the finish line --
> > > this is much appreciated!
> > >
> > > I'm happy to say that this latest patch is also working just fine. So
> > > I guess this is the one that's going to land in Xen 4.13?
> >
> > No, not really, sorry this was still a debug patch.
> >
> > So I think the behaviour you are seeing can only be explained if the
> > IOMMU is already enabled by the firmware when booting into Xen, can
> > this be the case?
> >
> > I have a patch I would like you to try to confirm this, can you please
> > give it a spin and report back (ideally with the Xen boot log).
> >
> > Thanks, Roger.
> > ---8<---
> > diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> > index fef97c82f6..3605614aaf 100644
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -1341,7 +1341,7 @@ int set_identity_p2m_entry(struct domain *d, unsigned 
> > long gfn_l,
> >
> >  if ( !paging_mode_translate(p2m->domain) )
> >  {
> > -if ( !need_iommu_pt_sync(d) )
> > +if ( !has_iommu_pt(d) )
> >  return 0;
> >  return iommu_legacy_map(d, _dfn(gfn_l), _mfn(gfn_l), PAGE_ORDER_4K,
> >  IOMMUF_readable | IOMMUF_writable);
> > @@ -1432,7 +1432,7 @@ int clear_identity_p2m_entry(struct domain *d, 
> > unsigned long gfn_l)
> >
> >  if ( !paging_mode_translate(d) )
> >  {
> > -if ( !need_iommu_pt_sync(d) )
> > +if ( !has_iommu_pt(d) )
> >  return 0;
> >  return iommu_legacy_unmap(d, _dfn(gfn_l), PAGE_ORDER_4K);
> >  }
> > diff --git a/xen/drivers/passthrough/vtd/iommu.c 
> > b/xen/drivers/passthrough/vtd/iommu.c
> > index 5d72270c5b..9dd0ed7f63 100644
> > --- a/xen/drivers/passthrough/vtd/iommu.c
> > +++ b/xen/drivers/passthrough/vtd/iommu.c
> > @@ -2316,6 +2316,9 @@ static int __init vtd_setup(void)
> >   */
> >  for_each_drhd_unit ( drhd )
> >  {
> > +unsigned long flags;
> > +uint32_t val;
> > +
> >  iommu = drhd->iommu;
> >
> >  printk("Intel VT-d iommu %"PRIu32" supported page sizes: 4kB",
> > @@ -2351,6 +2354,22 @@ static int __init vtd_setup(void)
> >  if ( !vtd_ept_page_compatible(iommu) )
> >  iommu_hap_pt_share = 0;
> >
> > +spin_lock_irqsave(>register_lock, flags);
> > +val = dmar_readl(iommu->reg, DMAR_GSTS_REG);
> > +/*
> > + * TODO: needs to be revisited once Xen supports booting with an
> > + * already enabled IOMMU.
> > + */
> > +if ( val & DMA_GSTS_TES )
> > +{
> > +printk(XENLOG_WARNING VTDPREFIX
> > +   "IOMMU: DMA remapping already enabled, disabling it\n");
> > +dmar_writel(iommu->reg, 

Re: [Xen-devel] [PATCH 2/2] xen: Drop XEN_DOMCTL_{get, set}_machine_address_size

[Marek Marczykowski-Górecki]

On Tue, Aug 13, 2019 at 11:53:52AM +0100, Andrew Cooper wrote:
> This functionality is obsolete.  It was introduced by c/s 41296317a31 into
> Xend, but was never exposed in libxl.
> 
> Nothing limits this to PV guests, but it makes no sense for HVM guests.
> 
> Looking through the XenServer templates, this was used to work around bugs in
> the 32bit RHEL/CentOS 4.7 and 4.8 kernels (fixed in 4.9) and RHEL/CentOS/OEL
> 5.2 and 5.3 kernels (fixed in 5.4).  RHEL 4 as a major version went out of
> support in 2017, whereas the 5.2/5.3 kernels went out of support when 5.4 was
> released in 2009.
> 
> Signed-off-by: Andrew Cooper 

Python part:
Acked-by: Marek Marczykowski-Górecki 

Also, I confirm it isn't used in Qubes OS.

> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Ian Jackson 
> CC: Marek Marczykowski-Górecki 
> CC: Daniel De Graaf 
> CC: Christian Lindig 
> CC: Rob Hoes 
> 
> There may be some resulting simplifications which can be made to the heap
> allocator, but that involves untangling the other address clamping logic
> first.
> ---
>  tools/libxc/include/xenctrl.h   |  6 --
>  tools/libxc/xc_domain.c | 29 -
>  tools/ocaml/libs/xc/xenctrl.ml  |  5 -
>  tools/ocaml/libs/xc/xenctrl.mli |  5 -
>  tools/ocaml/libs/xc/xenctrl_stubs.c | 26 --
>  tools/python/xen/lowlevel/xc/xc.c   | 23 ---
>  xen/arch/x86/domctl.c   | 12 
>  xen/include/public/domctl.h | 11 ++-
>  xen/xsm/flask/hooks.c   |  2 --
>  xen/xsm/flask/policy/access_vectors |  4 ++--
>  10 files changed, 4 insertions(+), 119 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index a36896034a..c92386aab8 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1781,12 +1781,6 @@ int xc_domain_unbind_pt_spi_irq(xc_interface *xch,
>  uint16_t vspi,
>  uint16_t spi);
>  
> -int xc_domain_set_machine_address_size(xc_interface *xch,
> -uint32_t domid,
> -unsigned int width);
> -int xc_domain_get_machine_address_size(xc_interface *xch,
> -uint32_t domid);
> -
>  /* Set the target domain */
>  int xc_domain_set_target(xc_interface *xch,
>   uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 64ca513aae..e544218d2e 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2161,35 +2161,6 @@ int xc_domain_subscribe_for_suspend(
>  return do_domctl(xch, );
>  }
>  
> -int xc_domain_set_machine_address_size(xc_interface *xch,
> -   uint32_t domid,
> -   unsigned int width)
> -{
> -DECLARE_DOMCTL;
> -
> -memset(, 0, sizeof(domctl));
> -domctl.domain = domid;
> -domctl.cmd= XEN_DOMCTL_set_machine_address_size;
> -domctl.u.address_size.size = width;
> -
> -return do_domctl(xch, );
> -}
> -
> -
> -int xc_domain_get_machine_address_size(xc_interface *xch, uint32_t domid)
> -{
> -DECLARE_DOMCTL;
> -int rc;
> -
> -memset(, 0, sizeof(domctl));
> -domctl.domain = domid;
> -domctl.cmd= XEN_DOMCTL_get_machine_address_size;
> -
> -rc = do_domctl(xch, );
> -
> -return rc == 0 ? domctl.u.address_size.size : rc;
> -}
> -
>  int xc_domain_debug_control(xc_interface *xc, uint32_t domid, uint32_t sop, 
> uint32_t vcpu)
>  {
>  DECLARE_DOMCTL;
> diff --git a/tools/ocaml/libs/xc/xenctrl.ml b/tools/ocaml/libs/xc/xenctrl.ml
> index a57130a3c3..35958b94d5 100644
> --- a/tools/ocaml/libs/xc/xenctrl.ml
> +++ b/tools/ocaml/libs/xc/xenctrl.ml
> @@ -241,11 +241,6 @@ external domain_set_memmap_limit: handle -> domid -> 
> int64 -> unit
>  external domain_memory_increase_reservation: handle -> domid -> int64 -> unit
> = "stub_xc_domain_memory_increase_reservation"
>  
> -external domain_set_machine_address_size: handle -> domid -> int -> unit
> -   = "stub_xc_domain_set_machine_address_size"
> -external domain_get_machine_address_size: handle -> domid -> int
> -   = "stub_xc_domain_get_machine_address_size"
> -
>  external domain_cpuid_set: handle -> domid -> (int64 * (int64 option))
>  -> string option array
>  -> string option array
> diff --git a/tools/ocaml/libs/xc/xenctrl.mli b/tools/ocaml/libs/xc/xenctrl.mli
> index 476bbecb90..6c4268d453 100644
> --- a/tools/ocaml/libs/xc/xenctrl.mli
> +++ b/tools/ocaml/libs/xc/xenctrl.mli
> @@ -202,11 +202,6 @@ val pages_to_mib : int64 -> int64
>  external watchdog : handle -> int -> int32 -> int
>= "stub_xc_watchdog"
>  
> -external domain_set_machine_address_size: handle -> domid -> int -> unit
> -  = 

Re: [Xen-devel] [PATCH 1/2] xen: Drop XEN_DOMCTL_suppress_spurious_page_faults

[Marek Marczykowski-Górecki]

On Tue, Aug 13, 2019 at 11:53:51AM +0100, Andrew Cooper wrote:
> This functionality is obsolete.  It was introduced by c/s 39407bed9c0 into
> Xend, but never exposed in libxl.
> 
> While not explicitly limited to PV guests, this is PV-only by virtue of its
> position in the pagefault handler.
> 
> Looking though the XenServer templates, this was used to work around bugs in
> the 32bit RHEL/CentOS 4.{5..7} kernels (fixed in 4.8).  RHEL 4 as a major
> version when out if support in 2017.
> 
> Signed-off-by: Andrew Cooper 

Python part:
Acked-by: Marek Marczykowski-Górecki 

Also, I confirm it isn't used in Qubes OS.

> ---
> CC: Jan Beulich 
> CC: Wei Liu 
> CC: Roger Pau Monné 
> CC: Ian Jackson 
> CC: Marek Marczykowski-Górecki 
> CC: Daniel De Graaf 
> ---
>  tools/libxc/include/xenctrl.h   |  3 ---
>  tools/libxc/xc_domain.c | 12 
>  tools/python/xen/lowlevel/xc/xc.c   | 22 --
>  xen/arch/x86/domctl.c   |  4 
>  xen/arch/x86/traps.c| 14 --
>  xen/include/asm-x86/domain.h|  3 ---
>  xen/include/public/domctl.h |  7 +--
>  xen/xsm/flask/hooks.c   |  1 -
>  xen/xsm/flask/policy/access_vectors |  3 +--
>  9 files changed, 2 insertions(+), 67 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 0ff6ed9e70..a36896034a 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -1787,9 +1787,6 @@ int xc_domain_set_machine_address_size(xc_interface 
> *xch,
>  int xc_domain_get_machine_address_size(xc_interface *xch,
>  uint32_t domid);
>  
> -int xc_domain_suppress_spurious_page_faults(xc_interface *xch,
> -   uint32_t domid);
> -
>  /* Set the target domain */
>  int xc_domain_set_target(xc_interface *xch,
>   uint32_t domid,
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 05d771f2ce..64ca513aae 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -2190,18 +2190,6 @@ int xc_domain_get_machine_address_size(xc_interface 
> *xch, uint32_t domid)
>  return rc == 0 ? domctl.u.address_size.size : rc;
>  }
>  
> -int xc_domain_suppress_spurious_page_faults(xc_interface *xc, uint32_t domid)
> -{
> -DECLARE_DOMCTL;
> -
> -memset(, 0, sizeof(domctl));
> -domctl.domain = domid;
> -domctl.cmd= XEN_DOMCTL_suppress_spurious_page_faults;
> -
> -return do_domctl(xc, );
> -
> -}
> -
>  int xc_domain_debug_control(xc_interface *xc, uint32_t domid, uint32_t sop, 
> uint32_t vcpu)
>  {
>  DECLARE_DOMCTL;
> diff --git a/tools/python/xen/lowlevel/xc/xc.c 
> b/tools/python/xen/lowlevel/xc/xc.c
> index 188bfa34da..7e831a26a7 100644
> --- a/tools/python/xen/lowlevel/xc/xc.c
> +++ b/tools/python/xen/lowlevel/xc/xc.c
> @@ -786,22 +786,6 @@ static PyObject 
> *pyxc_dom_set_machine_address_size(XcObject *self,
>  Py_INCREF(zero);
>  return zero;
>  }
> -
> -static PyObject *pyxc_dom_suppress_spurious_page_faults(XcObject *self,
> -   PyObject *args,
> -   PyObject *kwds)
> -{
> -uint32_t dom;
> -
> -if (!PyArg_ParseTuple(args, "i", ))
> - return NULL;
> -
> -if (xc_domain_suppress_spurious_page_faults(self->xc_handle, dom) != 0)
> - return pyxc_error_to_exception(self->xc_handle);
> -
> -Py_INCREF(zero);
> -return zero;
> -}
>  #endif /* __i386__ || __x86_64__ */
>  
>  static PyObject *pyxc_gnttab_hvm_seed(XcObject *self,
> @@ -2436,12 +2420,6 @@ static PyMethodDef pyxc_methods[] = {
>"Set maximum machine address size for this domain.\n"
>" dom [int]: Identifier of domain.\n"
>" width [int]: Maximum machine address width.\n" },
> -
> -{ "domain_suppress_spurious_page_faults",
> -  (PyCFunction)pyxc_dom_suppress_spurious_page_faults,
> -  METH_VARARGS, "\n"
> -  "Do not propagate spurious page faults to this guest.\n"
> -  " dom [int]: Identifier of domain.\n" },
>  #endif
>  
>  { "dom_set_memshr", 
> diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
> index 2d45e5b8a8..34a6f88b8a 100644
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -988,10 +988,6 @@ long arch_do_domctl(
>  }
>  break;
>  
> -case XEN_DOMCTL_suppress_spurious_page_faults:
> -d->arch.suppress_spurious_page_faults = 1;
> -break;
> -
>  #ifdef CONFIG_HVM
>  case XEN_DOMCTL_debug_op:
>  {
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index 23069e25ec..350903add5 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -1452,20 +1452,6 @@ void do_page_fault(struct cpu_user_regs *regs)
>error_code, _p(addr));
>  }
>  
> -if ( unlikely(current->domain->arch.suppress_spurious_page_faults) )
> -{
> -

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Julien Grall]

On 8/13/19 6:34 PM, Dario Faggioli wrote:

On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:

Hi Dario,


Hello!


On 8/13/19 4:27 PM, Dario Faggioli wrote:

On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:



In my (x86 and "dom0full") testbox, this seems to come from
domain_unpause_by_systemcontroller(dom0) called by
xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().

I don't know if domain construction in an ARM dom0less system works
similarly, though. What we want, is someone calling either
vcpu_wake()
or vcpu_unpause(), after having cleared _VPF_down from pause_flags.


Looking at create_domUs() there is a call to
domain_unpause_by_controller for each domUs.


Yes, I saw that. And I've seen the one done don dom0, at the end of
xen/arch/arm/setup.c:start_xen(), as well.

Also, both construct_dom0() (still from start_xen()) and
construct_domU() (called from create_domUs()) call construct_domain(),
which does clear_bit(_VPF_down), setting the domain to online.

So, unless the flag gets cleared again, or something else happens that
makes the vCPU(s) fail the vcpu_runnable() check in
domain_unpause()->vcpu_wake(), I don't see why the wakeup that let the
null scheduler start scheduling the vCPU doesn't happen... as it
instead does on x86 or !dom0less ARM (because, as far as I've
understood, it's only dom0less that doesn't work, it this correct?)


Yes, I quickly tried to use NULL scheduler with just dom0 and it boots.

Interestingly, I can't see the log:

(XEN) Freed 328kB init memory.

This is called as part of init_done before CPU0 goes into the idle loop.

Adding more debug, it is getting stuck when calling 
domain_unpause_by_controller for dom0. Specifically vcpu_wake on dom0v0.


The loop to assign a pCPU in null_vcpu_wake() is turning into an 
infinite loop. Indeed the loop is trying to pick CPU0 for dom0v0 that is 
already used by dom1v0. So the problem is in pick_cpu() or the data used 
by it.


It feels to me this is an affinity problem. Note that I didn't request 
to pin dom0 vCPUs.


Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH] xen/arm: domain_build: Print the correct domain in dtb_load()

[Julien Grall]

dtb_load() can be called by other domain than dom0. To avoid confusion
in the log, print the correct domain.

Signed-off-by: Julien Grall 
---
 xen/arch/arm/domain_build.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..9b040f5e99 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1817,8 +1817,9 @@ static void __init dtb_load(struct kernel_info *kinfo)
 {
 unsigned long left;
 
-printk("Loading dom0 DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
-   kinfo->dtb_paddr, kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
+printk("Loading %pd DTB to 0x%"PRIpaddr"-0x%"PRIpaddr"\n",
+   kinfo->d, kinfo->dtb_paddr,
+   kinfo->dtb_paddr + fdt_totalsize(kinfo->fdt));
 
 left = copy_to_guest_phys_flush_dcache(kinfo->d, kinfo->dtb_paddr,
kinfo->fdt,
-- 
2.11.0


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-qemuu-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-qemuu-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-qemut-rhel6hvm-amd  7 xen-boot   fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-debianhvm-amd64  7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 133580
 test-amd64-i386-xl-qemut-win10-i386  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-win7-amd64  7 xen-boot  fail REGR. vs. 133580
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 133580
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 133580
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. vs. 
133580
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 133580
 test-amd64-amd64-xl-pvshim   16 guest-localmigrate   fail REGR. vs. 133580
 build-armhf-pvops 6 kernel-build fail REGR. vs. 133580
 test-amd64-i386-xl-pvshim 7 xen-boot fail REGR. vs. 133580

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-i386-xl-qemut-debianhvm-i386-xsm  7 xen-boot fail baseline untested
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 133580
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 

Re: [Xen-devel] [PATCH] x86/pv: Clean up cr3 handling in arch_set_info_guest()

[Andrew Cooper]

On 24/01/2019 22:10, Andrew Cooper wrote:
> On 24/01/2019 21:42, Julien Grall wrote:
>> Hi Andrew,
>>
>> On 12/21/18 1:46 PM, Andrew Cooper wrote:
>>> All of this code lives inside CONFIG_PV which means gfn == mfn, and the
>>> fill_ro_mpt() calls clearly show that the value is used untranslated.
>>>
>>> Change cr3_gfn to a suitably typed cr3_mfn, and replace
>>> get_page_from_gfn()
>>> with a straight mfn_to_page/get_page sequence, to avoid the
>>> implication that
>>> translation is going on.
>>>
>>> No functional change.
>>>
>>> Signed-off-by: Andrew Cooper 
>>> ---
>>> CC: Jan Beulich 
>>> CC: Wei Liu 
>>> CC: Roger Pau Monné 
>>> CC: Stefano Stabellini 
>>> CC: Julien Grall 
>>>
>>> Julien: This should simplify your "xen: Switch parameter in
>>> get_page_from_gfn
>>> to use typesafe gfn" patch.  In particular, I did a doubletake at
>>> fill_ro_mpt(_mfn(gfn_x(cr3_gfn))); when reviewing it.
>> I was looking at updating my patch and remembered you suggested to
>> rebase on top of this. Do you have any plan to resend the patch?
> I'll see if I can find some time tomorrow.

So maybe I was a little off ;)  Better late than never I suppose.

~Andrew

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

[Xen-devel] [linux-4.4 test] 140040: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvshim  20 guest-start/debian.repeat fail REGR. vs. 139698

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-arm64-arm64-xl-credit2   7 xen-boot fail   never pass
 test-arm64-arm64-xl   7 xen-boot fail   never pass
 test-arm64-arm64-xl-credit1   7 xen-boot fail   never pass
 test-arm64-arm64-examine  8 reboot   fail   never pass
 test-arm64-arm64-xl-seattle   7 xen-boot fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm  7 xen-boot fail   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-arm64-arm64-xl-thunderx  7 xen-boot fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail 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 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  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-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-xsm   7 xen-boot fail   never pass
 test-amd64-amd64-xl-qemut-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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail 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-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux3904234bd04fa7c40467e5d8b3301893fae16e87
baseline version:
 linuxdc16a7e5f36d65b25a1b66ade14356773ed52875

Last test of basis   139698  2019-08-04 07:48:30 Z9 days
Failing since139773  2019-08-06 16:40:26 Z7 days9 attempts
Testing same since   139968  2019-08-12 02:01:49 Z1 days

Re: [Xen-devel] [PATCH 3/3] xen/sched: add minimalistic idle scheduler for free cpus

[Dario Faggioli]

On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> Instead of having a full blown scheduler running for the free cpus
> add a very minimalistic scheduler for that purpose only ever
> scheduling
> the related idle vcpu. This has the big advantage of not needing any
> per-cpu, per-domain or per-scheduling unit data for free cpus and in
> turn simplifying moving cpus to and from cpupools a lot.
> 
> This new scheduler will just use a common lock for all free cpus.
> 
> As this new scheduler is not user selectable don't register it as an
> official scheduler, but just include it in schedule.c.
> 
> Signed-off-by: Juergen Gross 
>
This patch looks fine to me.

With the changelog adapted as I mentioned in my reply to patch 0, this
is:

Acked-by: Dario Faggioli 

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Dario Faggioli]

On Tue, 2019-08-13 at 17:52 +0100, Julien Grall wrote:
> Hi Dario,
> 
Hello!

> On 8/13/19 4:27 PM, Dario Faggioli wrote:
> > On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> > > 
> > In my (x86 and "dom0full") testbox, this seems to come from
> > domain_unpause_by_systemcontroller(dom0) called by
> > xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().
> > 
> > I don't know if domain construction in an ARM dom0less system works
> > similarly, though. What we want, is someone calling either
> > vcpu_wake()
> > or vcpu_unpause(), after having cleared _VPF_down from pause_flags.
> 
> Looking at create_domUs() there is a call to 
> domain_unpause_by_controller for each domUs.
> 
Yes, I saw that. And I've seen the one done don dom0, at the end of
xen/arch/arm/setup.c:start_xen(), as well.

Also, both construct_dom0() (still from start_xen()) and
construct_domU() (called from create_domUs()) call construct_domain(),
which does clear_bit(_VPF_down), setting the domain to online.

So, unless the flag gets cleared again, or something else happens that
makes the vCPU(s) fail the vcpu_runnable() check in
domain_unpause()->vcpu_wake(), I don't see why the wakeup that let the
null scheduler start scheduling the vCPU doesn't happen... as it
instead does on x86 or !dom0less ARM (because, as far as I've
understood, it's only dom0less that doesn't work, it this correct?)

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

[Julien Grall]

Hi,

On 8/12/19 11:28 PM, Stefano Stabellini wrote:

Change the signature of process_memory_node to match
device_tree_node_func. Thanks to this change, the next patch will be
able to use device_tree_for_each_node to call process_memory_node on all
the children of a provided node.

Return error if there is no reg property or if nr_banks is reached. Let
the caller deal with the error.

Signed-off-by: Stefano Stabellini 
---
Changes in v5:
- return -ENOENT if address_cells or size_cells are not properly set

Changes in v4:
- return error if there is no reg propery, remove printk
- return error if nr_banks is reached

Changes in v3:
- improve commit message
- check return value of process_memory_node

Changes in v2:
- new
---
  xen/arch/arm/bootfdt.c | 29 +++--
  1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index a872ea57d6..590b14304c 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -125,9 +125,10 @@ int __init device_tree_for_each_node(const void *fdt, int 
node,
  return 0;
  }
  
-static void __init process_memory_node(const void *fdt, int node,

-   const char *name,
-   u32 address_cells, u32 size_cells)
+static int __init process_memory_node(const void *fdt, int node,
+  const char *name, int depth,
+  u32 address_cells, u32 size_cells,
+  void *data)
  {
  const struct fdt_property *prop;
  int i;
@@ -137,18 +138,11 @@ static void __init process_memory_node(const void *fdt, 
int node,
  u32 reg_cells = address_cells + size_cells;
  
  if ( address_cells < 1 || size_cells < 1 )

-{
-printk("fdt: node `%s': invalid #address-cells or #size-cells",
-   name);
-return;
-}
+return -ENOENT;


I saw your answer on the previous version and didn't get the chance. 
Missing the "regs" property and wrong {address,size}-cells values are 
two different things.


In the former case, it just means the reserved-region will be allocated 
dynamically.


In the latter case, this is an error in the device-tree configuration. 
If you ignore it, you are at risk to not take into account a 
reserved-region.


I agree this is a bug in the Device-Tree, but doing basic sanity check 
for the users is always helpful.


With that in mind, I would keep the printk and return a different error 
here.



  
  prop = fdt_get_property(fdt, node, "reg", NULL);

  if ( !prop )
-{
-printk("fdt: node `%s': missing `reg' property\n", name);
-return;
-}
+return -ENOENT;
  
  cell = (const __be32 *)prop->data;

  banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
@@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, 
int node,
  bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
  bootinfo.mem.nr_banks++;
  }
+
+if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
+return -ENOSPC;
+return 0;
  }
  
  static void __init process_multiboot_node(const void *fdt, int node,

@@ -293,15 +291,18 @@ static int __init early_scan_node(const void *fdt,
u32 address_cells, u32 size_cells,
void *data)
  {
+int rc = 0;
+
  if ( device_tree_node_matches(fdt, node, "memory") )
-process_memory_node(fdt, node, name, address_cells, size_cells);
+rc = process_memory_node(fdt, node, name, depth,
+ address_cells, size_cells, NULL);


As a small NIT there are no way for the user to know that the parsing 
failed because of the reg property were missing. Could you print an 
error message either here or maybe in device_tree_for_each() to say 
parsing as failed for node N?



  else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, 
"xen,multiboot-module" ) ||
device_tree_node_compatible(fdt, node, "multiboot,module" )))
  process_multiboot_node(fdt, node, name, address_cells, size_cells);
  else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
  process_chosen_node(fdt, node, name, address_cells, size_cells);
  
-return 0;

+return rc;
  }
  
  static void __init early_print_info(void)




Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2 5/6] iommu/arm: Introduce iommu_add_dt_device API

[Julien Grall]

Hi,

On 8/13/19 5:05 PM, Oleksandr wrote:

On 13.08.19 16:49, Julien Grall wrote:

On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
Hmm, I was thinking how to end up with only one callback re-used 
(add_device), really didn't want to add a new one (of_xlate). But, I 
didn't take into the account that this stuff is a really 
driver-depended. So, likely yes, we need to provide of_xlate callback.



May I ask some questions to clarify:

1. Do you want me to introduce of_xlate callback in a separate patch 
(under CONFIG_ARM?)?


Preferably yes. I think this wants to be under CONFIG_HAS_DEVICE_TREE 
rather than CONFIG_ARM.



2. Can we avoid introducing new API for that callback?


Do you mean a wrapper for the callback? If so, yes.


iommu_add_dt_device will be able to call it directly.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: pass node to device_tree_for_each_node

[Julien Grall]

Hi,

On 8/12/19 11:28 PM, Stefano Stabellini wrote:

Add a new parameter to device_tree_for_each_node: node, the node to
start the search from. Passing 0 triggers the old behavior.

Set min_depth to depth of the current node + 1 and replace the for
loop with a do/while loop to avoid scanning siblings of the initial node
passed as an argument.

We need this change because in follow-up patches we want to be able to
use reuse device_tree_for_each_node to call a function for each children
nodes of a provided node and the node itself.


I have to say this would be fairly confusing for reserved-memory because 
you are only expecting to parse the subnode.


Furthermore, in the unlikely event to first node does have a property 
"regs", then #address-cells and #size-cells is going to be incorrect (we 
don't look up for its parent...).


So I think it would be best to consider to ignore the first node. This 
should not be an issue as none of the user care about the root node (i.e 
/). It would also makes the interface more straightforward.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 2/3] xen/sched: remove cpu from pool0 before removing it

[Dario Faggioli]

On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> Today a cpu which is removed from the system is taken directly from
> Pool0 to the offline state. This will conflict with the new idle
> scheduler, so remove it from Pool0 first. Additionally accept
> removing
> a free cpu instead of requiring it to be in Pool0.
> 
> For the resume failed case we need to call the scheduler code for
> that
> situation after the cpupool handling, so move the scheduler code into
> a function and call it from cpupool_cpu_remove_forced() and remove
> the
> CPU_RESUME_FAILED case from cpu_schedule_callback().
> 
> Note that we are calling now schedule_cpu_switch() in stop_machine
> context so we need to switch from spinlock_irq to spinlock_irqsave.
> 
> Signed-off-by: Juergen Gross 
> ---
> 
> --- a/xen/common/cpupool.c
> +++ b/xen/common/cpupool.c
> @@ -282,22 +282,14 @@ static int cpupool_assign_cpu_locked(struct
> cpupool *c, unsigned int cpu)
>  return 0;
>  }
>  
> -static long cpupool_unassign_cpu_helper(void *info)
> +static int cpupool_unassign_cpu_epilogue(struct cpupool *c)
>
in schedule.c, for a similar situation, we have used '_start' and
'_finish' as suffixes. What do you think about using those here too?

It's certainly a minor thing, I know, but I (personally) like them
better (especially than 'epilogue') and I think it gives us some
consistency (yes, sure, different files.. but scheduling and cpupools
are quite tightly related).

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Julien Grall]

Hi Dario,

On 8/13/19 4:27 PM, Dario Faggioli wrote:

On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:

On Fri, 9 Aug 2019, Dario Faggioli wrote:

Can you help me with this, e.g., by providing some more info and,
if
possible, logs?


I am attaching the logs.


Thanks!


Interestingly, I get a bunch of:

(XEN) *** LOADING DOMU cpus=1 memory=4KB ***
(XEN) sched_null.c:458: Not inserting d2v0 (not online!)

Maybe we are missing a call to online the vcpus somewhere in
xen/arch/arm/domain_build.c:construct_domain?


Actually, those lines are normal, because vCPUs are created offline.
(see the set_bit(_VPF_down) in vcpu_create()).

The problem is why aren't they coming up. Basically, you're missing a
call to vcpu_wake().

In my (x86 and "dom0full") testbox, this seems to come from
domain_unpause_by_systemcontroller(dom0) called by
xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().

I don't know if domain construction in an ARM dom0less system works
similarly, though. What we want, is someone calling either vcpu_wake()
or vcpu_unpause(), after having cleared _VPF_down from pause_flags.


Looking at create_domUs() there is a call to 
domain_unpause_by_controller for each domUs.


Cheers,

--
Julien Grall

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

[Xen-devel] [ovmf test] 140047: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf ecc32c90ee4ad557205cb2725619a3cc2f45ebd0
baseline version:
 ovmf a0792697bc54e5472e2126c6fbff8031868426a9

Last test of basis   140011  2019-08-12 16:12:54 Z1 days
Testing same since   140047  2019-08-13 05:20:08 Z0 days1 attempts


People who touched revisions under test:
  Albecki, Mateusz 
  Gao, Zhichao 
  Krzysztof Koch 
  Mateusz Albecki 
  Zhichao Gao 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  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 :

To xenbits.xen.org:/home/xen/git/osstest/ovmf.git
   a0792697bc..ecc32c90ee  ecc32c90ee4ad557205cb2725619a3cc2f45ebd0 -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Anthony PERARD]

On Tue, Aug 13, 2019 at 04:47:23PM +0100, Andrew Cooper wrote:
> Error between user and terminal. :)
> 
> I'd sync'd xl and libxl.so, but not libxlu.so

I actually made the same mistake first time I tried.

> Ok, so that is working now.  I think 'cmdline+=" dom0=pvh
> dom0-iommu=none"' is slightly less tortured syntax, but I guess there is
> no way that this isn't going to be horrible.
> 
> As for the general mechanism, how usable is += for anything other than
> cmdline?  Most strings in config files can't usefully be extended in
> this matter - if they need changing, they need changing wholesale.

That's true, but one could imaging some maybe bad example like adding a
suffix to the name of the guest: "name+='-ovmf';".
Going through `man xl.cfg', maybe a good example other than cmdline
could be "cpus+=',^1'" but maybe a space is fine here, or one could use
a list instead.
Other potential uses could be for "PATH", but in this case it would be
better reset the setting rather that attempting to add a suffix to an
existing one.

I wonder if instead of doing += on all strings, we should instead have
`xl' whitelist the few options where += would make sense. (and at that
point, it would be easy to add a ' ' where is make sense, like
"cmdline"s. But then, how to tell users that it can't do "name+='-new'"?
because xlu would just print a warning, and xl would keep going with
name="".  Try "xl create memory+=42" ;-).

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Oleksandr]

On 13.08.19 16:40, Julien Grall wrote:

Hi Oleksandr,


Hi Julien.




One more comment :).

On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+    struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+    if ( fwspec )


I would actually check the iommu_dev passed in parameter is the same 
as stored. We expect all device to be protected by only one IOMMU. So 
better to be safe than allow overriding ;).


Actually, it makes sense, will add appropriate check.


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [PATCH 1/3] xen/sched: populate cpupool0 only after all cpus are up

[Dario Faggioli]

On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> With core or socket scheduling we need to know the number of siblings
> per scheduling unit before we can setup the scheduler properly. In
> order to prepare that do cpupool0 population only after all cpus are
> up.
> 
> With that in place there is no need to create cpupool0 earlier, so
> do that just before assigning the cpus. Initialize free cpus with all
> online cpus at that time in order to be able to add the cpu notifier
> late, too.
> 
So, now that this series has been made independent, I think that
mentions to the core-scheduling one should be dropped.

I mean, it is at least possible that this series would go in, while the
core-scheduling one never will. And at that point, it would be very
hard, for someone doing archaeology, to understand what went on.

It seems to me that, this patch, simplifies cpupool initialization (as,
e.g., the direct call to the CPU_ONLINE notifier for the BSP was IMO
rather convoluted). And that is made possible by moving the
initialization itself to a later point, making all the online CPUs look
like free CPUs, and using the standard (internal) API directly (i.e.,
cpupool_assign_cpu_locked()) to add them to Pool-0.

So, I'd kill the very first sentence and rearrange the rest to include
at least a quick mention to the simplification that we achieve.

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Oleksandr]

On 13.08.19 18:28, Julien Grall wrote:

Hi,


Hi Julien




On 8/13/19 4:17 PM, Oleksandr wrote:


On 13.08.19 15:39, Julien Grall wrote:


xfree is able to deal with NULL pointer, so the check is not necessary.


Yes, the reason I left this check is to not perform an extra 
operation (dev_iommu_fwspec_set). Shall I drop this check anyway?


I can't see any issue to do the extra operation. This is not hotpath 
and it is harmless.


ok, will drop.






diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 20d865e..1853bd9 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -14,6 +14,8 @@
  #ifndef __ARCH_ARM_IOMMU_H__
  #define __ARCH_ARM_IOMMU_H__
  +#include 


iommu.h does not seem to use anything defined in iommu_fwspec.h. So 
why do you include it here?


I was thinking that every source which includes iommu.h will get 
iommu_fwspec.h included indirectly. No need to include iommu_fwspec.h 
in many sources.


This was a reason. Shall I included it directly where needed?


There are a few cases where iommu.h is required but not 
iommu_fwspec.h. In general, I would prefer if headers are only 
included when strictly necessary.


got it, will drop from here and include where necessary.


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [PATCH V2 5/6] iommu/arm: Introduce iommu_add_dt_device API

[Oleksandr]

On 13.08.19 16:49, Julien Grall wrote:

Hi Oleksandr,


Hi Julien




On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_fwspec" support.

New function parses the DT binding, prepares "dev->iommu_fwspec"
with correct information and calls the IOMMU driver using "add_device"
callback to register new DT device.
The IOMMU driver's responsibility is to check whether 
"dev->iommu_fwspec"

is initialized and mark that device as protected.

The additional benefit here is to avoid to go through the whole DT
multiple times in IOMMU driver trying to locate master devices which
belong to each IOMMU device being probed.

The upcoming IPMMU driver will have "add_device" callback implemented.

I hope, this patch won't break SMMU driver's functionality,
which doesn't have this callback implemented.


The last two sentence does not really belong to the commit message. So 
I think they should go after ---.


Anyway, the only concern for the SMMU is to not break the old 
bindings. New bindings are not supported, so it does not matter 
whether they are broken or not. Once this series is merged, we can 
have a look how new bindings for the SMMU can be supported.


Sounds reasonable.






[1] 
https://www.kernel.org/doc/Documentation/devicetree/bindings/iommu/iommu.txt


Signed-off-by: Oleksandr Tyshchenko 
---
  xen/arch/arm/domain_build.c | 12 ++
  xen/drivers/passthrough/arm/iommu.c | 45 
+

  xen/include/asm-arm/iommu.h |  3 +++
  3 files changed, 60 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..d67f7d4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1241,6 +1241,18 @@ static int __init handle_device(struct domain 
*d, struct dt_device_node *dev,

  u64 addr, size;
  bool need_mapping = !dt_device_for_passthrough(dev);
  +    if ( dt_parse_phandle(dev, "iommus", 0) )


I don't particularly like this check. dt_parse_phandle is non-trivial 
to execute.


TBH, what we should do is trying to call iommu_add_dt_device if IOMMU 
is enabled. We can then return a recognizable value to tell the device 
is not protected.


Well. Don't really mind.





+    {
+    dt_dprintk("%s add to iommu\n", dt_node_full_name(dev));
+    res = iommu_add_dt_device(dev);
+    if ( res )
+    {
+    printk(XENLOG_ERR "Failed to add %s to the IOMMU\n",
+   dt_node_full_name(dev));
+    return res;
+    }
+    }
+
  nirq = dt_number_of_irq(dev);
  naddr = dt_number_of_address(dev);
  diff --git a/xen/drivers/passthrough/arm/iommu.c 
b/xen/drivers/passthrough/arm/iommu.c

index 3195919..19516af 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -113,3 +113,48 @@ int arch_iommu_populate_page_table(struct domain 
*d)

  void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
  {
  }
+
+int __init iommu_add_dt_device(struct dt_device_node *np)
+{
+    const struct iommu_ops *ops = iommu_get_ops();
+    struct dt_phandle_args iommu_spec;
+    struct device *dev = dt_to_dev(np);
+    int rc = 1, index = 0;
+
+    if ( !iommu_enabled || !ops || !ops->add_device )
+    return 0;


While I agree that !iommu_enabled should return 0, for the two others 
I am not entirely sure this is the right thing to do.


!ops is definitely an error because if you have the IOMMU enabled then 
you should have ops installed.


Agree.





!ops->add_device means that you will not be able to add any device 
using the new bindings. IOW, the device will be unusable later one as 
most likely the IOMMU was configured to deny any transaction. 
Therefore, this should return an error.


The initial reason *was* to not break SMMU which hasn't had add_device 
callback implemented yet. But, I got your point regarding SMMU above 
(the only concern for the SMMU is to not break the old bindings), so 
agree here.






+
+    if ( dev_iommu_fwspec_get(dev) )
+    return -EEXIST;
+
+    /* According to the 
Documentation/devicetree/bindings/iommu/iommu.txt */


This file does not exist in Xen, so Linux should at least be mentioned 
in the comment.


Will do.





+    while ( !dt_parse_phandle_with_args(np, "iommus", "#iommu-cells",
+    index, _spec) )
+    {
+    if ( !dt_device_is_available(iommu_spec.np) )
+    break;
+
+    rc = iommu_fwspec_init(dev, _spec.np->dev);
+    if ( rc )
+    break;
+
+    rc = iommu_fwspec_add_ids(dev, iommu_spec.args, 1);


Here you assume that there will at least always be one cells and the 
first cell is the IDs. For a first, #iommu-cells may be 0 (and 
therefore no cells) when the master IOMMU device cannot be configured.


Furthermore, the content of the 

Re: [Xen-devel] [PATCH 0/3] xen/sched: use new idle scheduler for free cpus

[Dario Faggioli]

On Fri, 2019-08-02 at 15:07 +0200, Juergen Gross wrote:
> These three patches have been carved out from my core scheduling
> series
> as they are sufficiently independent to be applied even without the
> big
> series.
> 
> Without this little series there are messages like the following to
> be
> seen on the console when booting with smt=0:
> 
> (XEN) Adding cpu 1 to runqueue 0
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> (XEN) CPU 1 still not dead...
> 
> By assigning cpus to Cpupool-0 only after all cpus are up and by not
> using the more complicated credit2 scheduler for cpus not in any
> cpupool this situation can simply no longer happen, as parking the
> not
> to be started threads is done before.
> 
And this is not the only problem, solved by this series (or an
equivalent approach).

Right now, CPUs that are not in any pool, still belong to Pool-0's
scheduler. This forces us to make, within the scheduler, extra effort
to avoid actually running vCPUs on those.

In the case of Credit1, this also cause issue to weights
(re)distribution, as the number of CPUs available to the scheduler is
wrong.

So, we absolutely want something like this.

This is described in the changelog of commit e7191920261d ("xen:
credit2: never consider CPUs outside of our cpupool").

Would it be possible to mention this in one of the changelogs of the
series (patch 3 would be the best place, I think).

Thanks and Regards,
Dario
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Andrew Cooper]

On 13/08/2019 16:30, Anthony PERARD wrote:
> On Tue, Aug 13, 2019 at 04:06:33PM +0100, Andrew Cooper wrote:
>> On 13/08/2019 15:48, Anthony PERARD wrote:
>>> Handle += of both strings and lists.
>>>
>>> If += is used for config options expected to be numbers, then a
>>> warning is printed and the config option ignored (because xl ignores
>>> config options with errors).
>>>
>>> This is to be used for development purposes, where modifying config
>>> option can be done on the `xl create' command line.
>>>
>>> One could have a cmdline= in the cfg file, and specify cmdline+= on
>>> the `xl create` command line without the need to write the whole
>>> cmdline in `xl' command line but simply append to the one in the cfg file.
>>> Or add an extra vif or disk by simply having "vif += [ '', ];" in the
>>> `xl' cmdline.
>>>
>>> Signed-off-by: Anthony PERARD 
>>> ---
>>>
>>> Notes:
>>> Commiter, the libxlu_cfg_?.[hc] files needs to be regenerated. (with 
>>> make)
>>> 
>>> This is a different proposal to Andrew's patch:
>>> <20190805144910.20223-1-andrew.coop...@citrix.com>
>>> [PATCH] tools/xl: Make extra= usable in combination with cmdline=
>> I gave this a spin, but got:
>>
>> [root@fusebot ~]# ./xlplus create shim.cfg
>> ramdisk=\"/root/tests/selftest/test-hvm64-selftest\"
>> cmdline+=\"dom0=pvh\ dom0-iommu=none\"
>> Parsing config from shim.cfg
>> shim.cfg:19: config parsing error near `+="dom0=pvh': lexical error
>> warning: Config file looks like it contains Python code.
>> warning:  Arbitrary Python is no longer supported.
>> warning:  See http://wiki.xen.org/wiki/PythonInXlConfig
>> Failed to parse config: Invalid argument
> Either older version of `flex' behave differently, or you don't have it
> installed on your system. `make' seems to only print a warning if
> `flex' is missing.
>
> Also, I've only done concatenation of string, += doesn't add a ' ' in
> between. So for cmdline, it would needs to be cmdline+=\"\ dom0=pvh\".

Error between user and terminal. :)

I'd sync'd xl and libxl.so, but not libxlu.so

Ok, so that is working now.  I think 'cmdline+=" dom0=pvh
dom0-iommu=none"' is slightly less tortured syntax, but I guess there is
no way that this isn't going to be horrible.

As for the general mechanism, how usable is += for anything other than
cmdline?  Most strings in config files can't usefully be extended in
this matter - if they need changing, they need changing wholesale.

~Andrew

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

Re: [Xen-devel] dom0less + sched=null => broken in staging

[Dario Faggioli]

On Fri, 2019-08-09 at 11:30 -0700, Stefano Stabellini wrote:
> On Fri, 9 Aug 2019, Dario Faggioli wrote:
> > Can you help me with this, e.g., by providing some more info and,
> > if
> > possible, logs?
> 
> I am attaching the logs. 
>
Thanks!

> Interestingly, I get a bunch of:
> 
> (XEN) *** LOADING DOMU cpus=1 memory=4KB ***
> (XEN) sched_null.c:458: Not inserting d2v0 (not online!)
> 
> Maybe we are missing a call to online the vcpus somewhere in
> xen/arch/arm/domain_build.c:construct_domain?
> 
Actually, those lines are normal, because vCPUs are created offline.
(see the set_bit(_VPF_down) in vcpu_create()).

The problem is why aren't they coming up. Basically, you're missing a
call to vcpu_wake().

In my (x86 and "dom0full") testbox, this seems to come from
domain_unpause_by_systemcontroller(dom0) called by
xen/arch/x86/setup.c:init_done(), at the very end of __start_xen().

I don't know if domain construction in an ARM dom0less system works
similarly, though. What we want, is someone calling either vcpu_wake()
or vcpu_unpause(), after having cleared _VPF_down from pause_flags.

I am attaching an updated debug patch, with an additional printk when
we reach the point, within the null scheduler, when the vcpu would wake
up (to check whether the problem is that we never reach that point, or
something else).

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)

diff --git a/xen/common/sched_null.c b/xen/common/sched_null.c
index 26c6f0f129..e78afadf5c 100644
--- a/xen/common/sched_null.c
+++ b/xen/common/sched_null.c
@@ -455,6 +455,7 @@ static void null_vcpu_insert(const struct scheduler *ops, struct vcpu *v)
 
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "Not inserting %pv (not online!)\n", v);
 vcpu_schedule_unlock_irq(lock, v);
 return;
 }
@@ -516,6 +517,7 @@ static void null_vcpu_remove(const struct scheduler *ops, struct vcpu *v)
 /* If offline, the vcpu shouldn't be assigned, nor in the waitqueue */
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "Not removing %pv (wasn't online!)\n", v);
 ASSERT(per_cpu(npc, v->processor).vcpu != v);
 ASSERT(list_empty(>waitq_elem));
 goto out;
@@ -571,6 +573,7 @@ static void null_vcpu_wake(const struct scheduler *ops, struct vcpu *v)
  */
 if ( unlikely(per_cpu(npc, cpu).vcpu != v && list_empty(>waitq_elem)) )
 {
+dprintk(XENLOG_G_INFO, "%pv is waking up after having been offline\n", v);
 spin_lock(>waitq_lock);
 list_add_tail(>waitq_elem, >waitq);
 spin_unlock(>waitq_lock);
@@ -635,6 +638,8 @@ static void null_vcpu_sleep(const struct scheduler *ops, struct vcpu *v)
 }
 else if ( per_cpu(npc, cpu).vcpu == v )
 tickled = vcpu_deassign(prv, v);
+
+dprintk(XENLOG_G_INFO, "%pv is, apparently, going offline (tickled=%d)\n", v, tickled);
 }
 
 /* If v is not assigned to a pCPU, or is not running, no need to bother */
@@ -697,6 +702,8 @@ static void null_vcpu_migrate(const struct scheduler *ops, struct vcpu *v,
  */
 if ( unlikely(!is_vcpu_online(v)) )
 {
+dprintk(XENLOG_G_INFO, "%pv is, apparently, going offline\n", v);
+
 spin_lock(>waitq_lock);
 list_del_init(>waitq_elem);
 spin_unlock(>waitq_lock);


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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

[Volodymyr Babchuk]

Julien Grall writes:

> Hi,
>
> On 8/13/19 4:14 PM, Volodymyr Babchuk wrote:
>> Julien Grall writes:
>>> On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
 Stefano Stabellini writes:

>{
>device_tree_get_reg(, address_cells, size_cells, , 
> );
>if ( !size )
>continue;
> -bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
> -bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
> -bootinfo.mem.nr_banks++;
> +mem->bank[mem->nr_banks].start = start;
> +mem->bank[mem->nr_banks].size = size;
> +mem->nr_banks++;
>}
>
> -if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
> +if ( mem->nr_banks == NR_MEM_BANKS )
 Looks like you have the same off-by-one error, as in previous patch.
 I can see that it was there earlier. But it is good time to fix it.
>>>
>>> I don't think there was an off-by-one error before this series. So
>>> what do you mean?
>> I explained this in patch #2. Imagine that NR_MEM_BANKS = 1 and you have
>> one memory node in the dtb. You'll fill the first element of the array
>> and mem->nr_banks will become 1. This is absolutely normal. But check
>> above will fail, which is not right.
>
> Ok. So the off-by-one error has been introduced by this series. So
> this should be fixed in patch #2 not here.
Yes, sorry. I got lost in the code.

-- 
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Anthony PERARD]

On Tue, Aug 13, 2019 at 04:06:33PM +0100, Andrew Cooper wrote:
> On 13/08/2019 15:48, Anthony PERARD wrote:
> > Handle += of both strings and lists.
> >
> > If += is used for config options expected to be numbers, then a
> > warning is printed and the config option ignored (because xl ignores
> > config options with errors).
> >
> > This is to be used for development purposes, where modifying config
> > option can be done on the `xl create' command line.
> >
> > One could have a cmdline= in the cfg file, and specify cmdline+= on
> > the `xl create` command line without the need to write the whole
> > cmdline in `xl' command line but simply append to the one in the cfg file.
> > Or add an extra vif or disk by simply having "vif += [ '', ];" in the
> > `xl' cmdline.
> >
> > Signed-off-by: Anthony PERARD 
> > ---
> >
> > Notes:
> > Commiter, the libxlu_cfg_?.[hc] files needs to be regenerated. (with 
> > make)
> > 
> > This is a different proposal to Andrew's patch:
> > <20190805144910.20223-1-andrew.coop...@citrix.com>
> > [PATCH] tools/xl: Make extra= usable in combination with cmdline=
> 
> I gave this a spin, but got:
> 
> [root@fusebot ~]# ./xlplus create shim.cfg
> ramdisk=\"/root/tests/selftest/test-hvm64-selftest\"
> cmdline+=\"dom0=pvh\ dom0-iommu=none\"
> Parsing config from shim.cfg
> shim.cfg:19: config parsing error near `+="dom0=pvh': lexical error
> warning: Config file looks like it contains Python code.
> warning:  Arbitrary Python is no longer supported.
> warning:  See http://wiki.xen.org/wiki/PythonInXlConfig
> Failed to parse config: Invalid argument

Either older version of `flex' behave differently, or you don't have it
installed on your system. `make' seems to only print a warning if
`flex' is missing.

Also, I've only done concatenation of string, += doesn't add a ' ' in
between. So for cmdline, it would needs to be cmdline+=\"\ dom0=pvh\".

Thanks,

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Julien Grall]

Hi,

On 8/13/19 4:17 PM, Oleksandr wrote:


On 13.08.19 15:39, Julien Grall wrote:


xfree is able to deal with NULL pointer, so the check is not necessary.


Yes, the reason I left this check is to not perform an extra operation 
(dev_iommu_fwspec_set). Shall I drop this check anyway?


I can't see any issue to do the extra operation. This is not hotpath and 
it is harmless.




diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 20d865e..1853bd9 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -14,6 +14,8 @@
  #ifndef __ARCH_ARM_IOMMU_H__
  #define __ARCH_ARM_IOMMU_H__
  +#include 


iommu.h does not seem to use anything defined in iommu_fwspec.h. So 
why do you include it here?


I was thinking that every source which includes iommu.h will get 
iommu_fwspec.h included indirectly. No need to include iommu_fwspec.h in 
many sources.


This was a reason. Shall I included it directly where needed?


There are a few cases where iommu.h is required but not iommu_fwspec.h. 
In general, I would prefer if headers are only included when strictly 
necessary.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Oleksandr]

On 13.08.19 15:39, Julien Grall wrote:

Hi Oleksandr,


Hi Julien.




On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now) and ACPI (in future).

For that reason we can borrow the idea used in Linux these days
called "iommu_fwspec". Having this in, it will be possible
to configure IOMMU master interfaces of the device (device IDs)
from a single common place and avoid keeping almost identifical look-up


s/identifical/identical/


ok





implementations in each IOMMU driver.

There is no need to port the whole implementation of "iommu_fwspec"
to Xen, we could, probably, end up with a much simpler solution,
some "stripped down" version which fits our requirments.


s/requirments/requirements/


ok





+ */
+
+#include 
+#include 


Please order the headers alphabetically.

NIT: Can you a newline between xen and asm headers?


Will do





+#include 
+#include 



+
+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+    struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+    if ( fwspec )
+    return 0;
+
+    fwspec = xzalloc(struct iommu_fwspec);
+    if ( !fwspec )
+    return -ENOMEM;
+
+    fwspec->iommu_dev = iommu_dev;
+    dev_iommu_fwspec_set(dev, fwspec);
+
+    return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+    struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+    if ( fwspec )


xfree is able to deal with NULL pointer, so the check is not necessary.


Yes, the reason I left this check is to not perform an extra operation 
(dev_iommu_fwspec_set). Shall I drop this check anyway?





+    {
+    xfree(fwspec);
+    dev_iommu_fwspec_set(dev, NULL);
+    }
+}
+
+int iommu_fwspec_add_ids(struct device *dev, uint32_t *ids, int 
num_ids)


While I realize the prototype is coming from Linux, num_ids cannot be 
negative (the code below would not work properly). So the parameter 
should be unsigned.


Agree, will use unsigned.





+{
+    struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+    size_t size;
+    int i;


Any variable that can't be negative should be unsigned.


Yes, will follow.



diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
index 20d865e..1853bd9 100644
--- a/xen/include/asm-arm/iommu.h
+++ b/xen/include/asm-arm/iommu.h
@@ -14,6 +14,8 @@
  #ifndef __ARCH_ARM_IOMMU_H__
  #define __ARCH_ARM_IOMMU_H__
  +#include 


iommu.h does not seem to use anything defined in iommu_fwspec.h. So 
why do you include it here?


I was thinking that every source which includes iommu.h will get 
iommu_fwspec.h included indirectly. No need to include iommu_fwspec.h in 
many sources.


This was a reason. Shall I included it directly where needed?





+
  struct arch_iommu
  {
  /* Private information for the IOMMU drivers */
diff --git a/xen/include/asm-arm/iommu_fwspec.h 
b/xen/include/asm-arm/iommu_fwspec.h

new file mode 100644
index 000..0676285
--- /dev/null
+++ b/xen/include/asm-arm/iommu_fwspec.h
@@ -0,0 +1,65 @@
+/*
+ * xen/include/asm-arm/iommu_fwspec.h
+ *
+ * Contains a common structure to hold the per-device firmware data and
+ * declaration of functions used to maintain that data
+ *
+ * Based on Linux's iommu_fwspec support you can find at:
+ *    include/linux/iommu.h
+ *
+ * Copyright (C) 2019 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see 
.

+ */
+
+#ifndef __ARCH_ARM_IOMMU_FWSPEC_H__
+#define __ARCH_ARM_IOMMU_FWSPEC_H__
+
+/* per-device IOMMU instance data */
+struct iommu_fwspec {
+    /* device which represents this IOMMU H/W */


Did you intend to say "this device's IOMMU"?


Exactly)


--
Regards,

Oleksandr Tyshchenko


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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

[Julien Grall]

Hi,

On 8/13/19 4:14 PM, Volodymyr Babchuk wrote:

Julien Grall writes:

On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:

Stefano Stabellini writes:


   {
   device_tree_get_reg(, address_cells, size_cells, , );
   if ( !size )
   continue;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
-bootinfo.mem.nr_banks++;
+mem->bank[mem->nr_banks].start = start;
+mem->bank[mem->nr_banks].size = size;
+mem->nr_banks++;
   }

-if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
+if ( mem->nr_banks == NR_MEM_BANKS )

Looks like you have the same off-by-one error, as in previous patch.
I can see that it was there earlier. But it is good time to fix it.


I don't think there was an off-by-one error before this series. So
what do you mean?

I explained this in patch #2. Imagine that NR_MEM_BANKS = 1 and you have
one memory node in the dtb. You'll fill the first element of the array
and mem->nr_banks will become 1. This is absolutely normal. But check
above will fail, which is not right.


Ok. So the off-by-one error has been introduced by this series. So this 
should be fixed in patch #2 not here.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

[Volodymyr Babchuk]

Hi Julien,

Julien Grall writes:

> Hi,
>
> On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:
>>
>> Stefano Stabellini writes:
>>
>>> As we parse the device tree in Xen, keep track of the reserved-memory
>>> regions as they need special treatment (follow-up patches will make use
>>> of the stored information.)
>>>
>>> Reuse process_memory_node to add reserved-memory regions to the
>>> bootinfo.reserved_mem array.
>>>
>>> Refuse to continue once we reach the max number of reserved memory
>>> regions to avoid accidentally mapping any portions of them into a VM.
>>>
>>> Signed-off-by: Stefano Stabellini 
>>>
>>> ---
>>> Changes in v5:
>>> - remove unneeded cast
>>> - remove unneeded strlen check
>>> - don't pass address_cells, size_cells, depth to device_tree_for_each_node
>>>
>>> Changes in v4:
>>> - depth + 1 in process_reserved_memory_node
>>> - pass address_cells and size_cells to device_tree_for_each_node
>>> - pass struct meminfo * instead of a boolean to process_memory_node
>>> - improve in-code comment
>>> - use a separate process_reserved_memory_node (separate from
>>>process_memory_node) function wrapper to have different error handling
>>>
>>> Changes in v3:
>>> - match only /reserved-memory
>>> - put the warning back in place for reg not present on a normal memory
>>>region
>>> - refuse to continue once we reach the max number of reserved memory
>>>regions
>>>
>>> Changes in v2:
>>> - call process_memory_node from process_reserved_memory_node to avoid
>>>duplication
>>> ---
>>>   xen/arch/arm/bootfdt.c  | 41 +++--
>>>   xen/include/asm-arm/setup.h |  1 +
>>>   2 files changed, 36 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
>>> index 590b14304c..0b0e22a3d0 100644
>>> --- a/xen/arch/arm/bootfdt.c
>>> +++ b/xen/arch/arm/bootfdt.c
>>> @@ -136,6 +136,7 @@ static int __init process_memory_node(const void *fdt, 
>>> int node,
>>>   const __be32 *cell;
>>>   paddr_t start, size;
>>>   u32 reg_cells = address_cells + size_cells;
>>> +struct meminfo *mem = data;
>>>
>>>   if ( address_cells < 1 || size_cells < 1 )
>>>   return -ENOENT;
>>> @@ -147,21 +148,46 @@ static int __init process_memory_node(const void 
>>> *fdt, int node,
>>>   cell = (const __be32 *)prop->data;
>>>   banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
>>>
>>> -for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
>>> +for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
>> What is logic behind the second part of the loop condition?
>>
>> You know that if (banks > NR_MEM_BANKS) then you will exit with error. Do
>> you really need to iterate over loop in this case?
>
> Well, the error is ignored in the case of memory banks. So iterating
> over the first banks allows you to fill up bootinfo with as much as
> possible as RAM. The rest of the RAM will not be used by Xen.
Fair enough.

>>
>>>   {
>>>   device_tree_get_reg(, address_cells, size_cells, , 
>>> );
>>>   if ( !size )
>>>   continue;
>>> -bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
>>> -bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
>>> -bootinfo.mem.nr_banks++;
>>> +mem->bank[mem->nr_banks].start = start;
>>> +mem->bank[mem->nr_banks].size = size;
>>> +mem->nr_banks++;
>>>   }
>>>
>>> -if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
>>> +if ( mem->nr_banks == NR_MEM_BANKS )
>> Looks like you have the same off-by-one error, as in previous patch.
>> I can see that it was there earlier. But it is good time to fix it.
>
> I don't think there was an off-by-one error before this series. So
> what do you mean?
I explained this in patch #2. Imagine that NR_MEM_BANKS = 1 and you have
one memory node in the dtb. You'll fill the first element of the array
and mem->nr_banks will become 1. This is absolutely normal. But check
above will fail, which is not right.

-- 
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH] libxlu: Handle += in config files

[Andrew Cooper]

On 13/08/2019 15:48, Anthony PERARD wrote:
> Handle += of both strings and lists.
>
> If += is used for config options expected to be numbers, then a
> warning is printed and the config option ignored (because xl ignores
> config options with errors).
>
> This is to be used for development purposes, where modifying config
> option can be done on the `xl create' command line.
>
> One could have a cmdline= in the cfg file, and specify cmdline+= on
> the `xl create` command line without the need to write the whole
> cmdline in `xl' command line but simply append to the one in the cfg file.
> Or add an extra vif or disk by simply having "vif += [ '', ];" in the
> `xl' cmdline.
>
> Signed-off-by: Anthony PERARD 
> ---
>
> Notes:
> Commiter, the libxlu_cfg_?.[hc] files needs to be regenerated. (with make)
> 
> This is a different proposal to Andrew's patch:
> <20190805144910.20223-1-andrew.coop...@citrix.com>
> [PATCH] tools/xl: Make extra= usable in combination with cmdline=

I gave this a spin, but got:

[root@fusebot ~]# ./xlplus create shim.cfg
ramdisk=\"/root/tests/selftest/test-hvm64-selftest\"
cmdline+=\"dom0=pvh\ dom0-iommu=none\"
Parsing config from shim.cfg
shim.cfg:19: config parsing error near `+="dom0=pvh': lexical error
warning: Config file looks like it contains Python code.
warning:  Arbitrary Python is no longer supported.
warning:  See http://wiki.xen.org/wiki/PythonInXlConfig
Failed to parse config: Invalid argument

I can't any combination of syntax which xl is happy with.

~Andrew

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

Re: [Xen-devel] [PATCH v5 6/7] xen/arm: don't iomem_permit_access for reserved-memory regions

[Julien Grall]

Hi,

On 8/13/19 3:34 PM, Volodymyr Babchuk wrote:


Stefano Stabellini writes:


Don't allow reserved-memory regions to be remapped into any unprivileged
guests, until reserved-memory regions are properly supported in Xen. For
now, do not call iomem_permit_access on them, because giving
iomem_permit_access to dom0 means that the toolstack will be able to
assign the region to a domU.

Signed-off-by: Stefano Stabellini 
---

Changes in v5:
- fix check condition
- use strnicmp
- return error
- improve commit message

Changes in v4:
- compare the parent name with reserved-memory
- use dt_node_cmp

Changes in v3:
- new patch
---
  xen/arch/arm/domain_build.c | 24 
  1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 4c8404155a..e0c0c01c88 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1155,15 +1155,23 @@ static int __init map_range_to_domain(const struct 
dt_device_node *dev,
  bool need_mapping = !dt_device_for_passthrough(dev);
  int res;
  
-res = iomem_permit_access(d, paddr_to_pfn(addr),

-  paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
-if ( res )
+/*
+ * Don't give iomem permissions for reserved-memory ranges to domUs
+ * until reserved-memory support is complete.
+ */
+if ( strnicmp(dt_node_full_name(dev), "/reserved-memory",
+ strlen("/reserved-memory")) != 0 )

Why are you using strnicmp there? With such usage it is the same as
strcasecmp().


Definitely not, strcasecmp() will compare that the two strings exactly 
match (ignoring the case of the characters). Here we only want to check 
the first part of the patch, so we need to use the length-limited version.



But, if you want to find "/reserved-memory" anywhere in
dt_node_full_name(dev), then you probably want to use strcasestr()


For a first strcasestr() is not provided by the string lib in Xen. So 
you would need to implement it.


But then all the reserved-memory regions are under the node 
/reserved-memory. A path /a/b/reserved-memory is not a valid memory region.


On a side note, the check is still incorrect here because you would 
allow /reserved-memory@... or /reserved-memory-test to pass.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [RFC 1/6] xen/arm: Re-enable interrupt later in the trap path

[Dario Faggioli]

On Thu, 2019-08-08 at 17:07 +0300, Andrii Anisov wrote:
> On 06.08.19 16:09, Andrii Anisov wrote:
> > p.p.s. I'm looking through freertos as well to get wider look on
> > the available approaches
> 
> OK, basically Free-RTOS does not account the IRQ time separately. Yet
> its scheduling is very implementation dependent.
>
What do you mean with "Yet its scheduling is very implementation
dependant"?

> Any ideas about other open-source examples available for
> investigation?
> 
Zephyr, maybe?

Regards
-- 
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)



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

[Xen-devel] [PATCH] libxlu: Handle += in config files

[Anthony PERARD]

Handle += of both strings and lists.

If += is used for config options expected to be numbers, then a
warning is printed and the config option ignored (because xl ignores
config options with errors).

This is to be used for development purposes, where modifying config
option can be done on the `xl create' command line.

One could have a cmdline= in the cfg file, and specify cmdline+= on
the `xl create` command line without the need to write the whole
cmdline in `xl' command line but simply append to the one in the cfg file.
Or add an extra vif or disk by simply having "vif += [ '', ];" in the
`xl' cmdline.

Signed-off-by: Anthony PERARD 
---

Notes:
Commiter, the libxlu_cfg_?.[hc] files needs to be regenerated. (with make)

This is a different proposal to Andrew's patch:
<20190805144910.20223-1-andrew.coop...@citrix.com>
[PATCH] tools/xl: Make extra= usable in combination with cmdline=

 tools/libxl/libxlu_cfg.c  | 100 +-
 tools/libxl/libxlu_cfg_i.h|   1 +
 tools/libxl/libxlu_cfg_l.l|   1 +
 tools/libxl/libxlu_cfg_y.y|   4 +-
 tools/libxl/libxlu_internal.h |   1 +
 tools/libxl/libxlutil.h   |   5 ++
 6 files changed, 109 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxlu_cfg.c b/tools/libxl/libxlu_cfg.c
index 5838f6885e..72815d25dd 100644
--- a/tools/libxl/libxlu_cfg.c
+++ b/tools/libxl/libxlu_cfg.c
@@ -276,6 +276,14 @@ int xlu_cfg_get_long(const XLU_Config *cfg, const char *n,
 char *ep;
 
 e= find_atom(cfg,n,,dont_warn);  if (e) return e;
+if (set->op == XLU_OP_ADDITION) {
+if (!dont_warn)
+fprintf(cfg->report,
+"%s:%d: warning: can't use += with numbers"
+" for parameter `%s'\n",
+cfg->config_source, set->lineno, n);
+return EINVAL;
+}
 errno= 0; l= strtol(set->value->u.string, , 0);
 e= errno;
 if (errno) {
@@ -450,23 +458,111 @@ void xlu__cfg_list_append(CfgParseContext *ctx,
 list->u.list.nvalues++;
 }
 
+static int xlu__cfg_concat_vals(CfgParseContext *ctx,
+XLU_ConfigValue *prev,
+XLU_ConfigValue *to_add)
+{
+int r;
+
+if (prev->type != to_add->type) {
+xlu__cfgl_lexicalerror(ctx,
+   "can't add [list] to \"string\" or vice versa");
+return EINVAL;
+}
+
+switch (to_add->type) {
+case XLU_STRING: {
+char *new_string = NULL;
+
+r = asprintf(_string, "%s%s", prev->u.string,
+ to_add->u.string);
+if (r < 0) {
+return errno;
+}
+free(to_add->u.string);
+to_add->u.string = new_string;
+return 0;
+}
+case XLU_LIST: {
+XLU_ConfigList *const prev_list = >u.list;
+XLU_ConfigList *const cur_list = _add->u.list;
+int nvalues;
+
+if (prev->u.list.nvalues > INT_MAX - to_add->u.list.nvalues) {
+return ERANGE;
+}
+nvalues = prev->u.list.nvalues + to_add->u.list.nvalues;
+
+if (nvalues >= cur_list->avalues) {
+XLU_ConfigValue **new_vals;
+new_vals = realloc(cur_list->values,
+   nvalues * sizeof(*new_vals));
+if (!new_vals) {
+return ENOMEM;
+}
+cur_list->avalues = nvalues;
+cur_list->values = new_vals;
+}
+
+/* make space for `prev' into `to_add' */
+memmove(cur_list->values + prev_list->nvalues,
+cur_list->values,
+cur_list->nvalues * sizeof(XLU_ConfigValue *));
+/* move values from `prev' to `to_add' as the list in `prev' will
+ * not be reachable by find(). */
+memcpy(cur_list->values,
+   prev_list->values,
+   prev_list->nvalues * sizeof(XLU_ConfigValue *));
+cur_list->nvalues = nvalues;
+prev_list->nvalues = 0;
+memset(prev_list->values, 0,
+   prev_list->nvalues * sizeof(XLU_ConfigValue *));
+return 0;
+}
+default:
+abort();
+}
+return -1;
+}
+
 void xlu__cfg_set_store(CfgParseContext *ctx, char *name,
+enum XLU_Operation op,
 XLU_ConfigValue *val, int lineno) {
 XLU_ConfigSetting *set;
+int r;
 
-if (ctx->err) return;
+if (ctx->err) goto out;
 
 assert(name);
+
+if (op == XLU_OP_ADDITION) {
+/* If we have += concatenate with previous value with same name */
+XLU_ConfigSetting *prev_set = find(ctx->cfg, name);
+if (prev_set) {
+r = xlu__cfg_concat_vals(ctx, prev_set->value, val);
+if (r) {
+ctx->err = r;
+goto out;
+}
+}
+}
+
 set = malloc(sizeof(*set));
 if (!set) {
 ctx->err = errno;
-return;
+goto out;
 }
 set->name= name;

Re: [Xen-devel] [PATCH v5 4/7] xen/arm: early_print_info print reserved_mem

[Julien Grall]

Hi,

On 8/13/19 3:28 PM, Volodymyr Babchuk wrote:


Stefano Stabellini writes:


Improve early_print_info to also print the banks saved in
bootinfo.reserved_mem. Print them right after RESVD, increasing the same
index.

Since we are at it, also switch the existing RESVD print to use unsigned
int.

Signed-off-by: Stefano Stabellini 

Reviewed-by: Volodymyr Babchuk 

But, please see NIT below.


---
Changes in v5:
- switch to unsigned

Changes in v4:
- new patch
---
  xen/arch/arm/bootfdt.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 0b0e22a3d0..32153e6207 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -337,9 +337,10 @@ static int __init early_scan_node(const void *fdt,
  static void __init early_print_info(void)
  {
  struct meminfo *mi = 
+struct meminfo *mem_resv = _mem;
  struct bootmodules *mods = 
  struct bootcmdlines *cmds = 
-int i, nr_rsvd;
+unsigned int i, j, nr_rsvd;
  
  for ( i = 0; i < mi->nr_banks; i++ )

  printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
@@ -361,9 +362,15 @@ static void __init early_print_info(void)
  continue;
  /* fdt_get_mem_rsv returns length */
  e += s;
-printk(" RESVD[%d]: %"PRIpaddr" - %"PRIpaddr"\n",
+printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n",
   i, s, e);

NIT: I see no reason, why this printk is split into two lines, as nicely fits
into one line.


Not mentioning the wrong indentation in pretty much all this function 
;). I would prefer if we take care of the indentation issues in a patch 
before this one.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

[Julien Grall]

Hi,

On 8/13/19 3:23 PM, Volodymyr Babchuk wrote:


Stefano Stabellini writes:


As we parse the device tree in Xen, keep track of the reserved-memory
regions as they need special treatment (follow-up patches will make use
of the stored information.)

Reuse process_memory_node to add reserved-memory regions to the
bootinfo.reserved_mem array.

Refuse to continue once we reach the max number of reserved memory
regions to avoid accidentally mapping any portions of them into a VM.

Signed-off-by: Stefano Stabellini 

---
Changes in v5:
- remove unneeded cast
- remove unneeded strlen check
- don't pass address_cells, size_cells, depth to device_tree_for_each_node

Changes in v4:
- depth + 1 in process_reserved_memory_node
- pass address_cells and size_cells to device_tree_for_each_node
- pass struct meminfo * instead of a boolean to process_memory_node
- improve in-code comment
- use a separate process_reserved_memory_node (separate from
   process_memory_node) function wrapper to have different error handling

Changes in v3:
- match only /reserved-memory
- put the warning back in place for reg not present on a normal memory
   region
- refuse to continue once we reach the max number of reserved memory
   regions

Changes in v2:
- call process_memory_node from process_reserved_memory_node to avoid
   duplication
---
  xen/arch/arm/bootfdt.c  | 41 +++--
  xen/include/asm-arm/setup.h |  1 +
  2 files changed, 36 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 590b14304c..0b0e22a3d0 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -136,6 +136,7 @@ static int __init process_memory_node(const void *fdt, int 
node,
  const __be32 *cell;
  paddr_t start, size;
  u32 reg_cells = address_cells + size_cells;
+struct meminfo *mem = data;

  if ( address_cells < 1 || size_cells < 1 )
  return -ENOENT;
@@ -147,21 +148,46 @@ static int __init process_memory_node(const void *fdt, 
int node,
  cell = (const __be32 *)prop->data;
  banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));

-for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
+for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )

What is logic behind the second part of the loop condition?

You know that if (banks > NR_MEM_BANKS) then you will exit with error. Do
you really need to iterate over loop in this case?


Well, the error is ignored in the case of memory banks. So iterating 
over the first banks allows you to fill up bootinfo with as much as 
possible as RAM. The rest of the RAM will not be used by Xen.





  {
  device_tree_get_reg(, address_cells, size_cells, , );
  if ( !size )
  continue;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
-bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
-bootinfo.mem.nr_banks++;
+mem->bank[mem->nr_banks].start = start;
+mem->bank[mem->nr_banks].size = size;
+mem->nr_banks++;
  }

-if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
+if ( mem->nr_banks == NR_MEM_BANKS )

Looks like you have the same off-by-one error, as in previous patch.
I can see that it was there earlier. But it is good time to fix it.


I don't think there was an off-by-one error before this series. So what 
do you mean?


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 6/7] xen/arm: don't iomem_permit_access for reserved-memory regions

[Volodymyr Babchuk]

Stefano Stabellini writes:

> Don't allow reserved-memory regions to be remapped into any unprivileged
> guests, until reserved-memory regions are properly supported in Xen. For
> now, do not call iomem_permit_access on them, because giving
> iomem_permit_access to dom0 means that the toolstack will be able to
> assign the region to a domU.
>
> Signed-off-by: Stefano Stabellini 
> ---
>
> Changes in v5:
> - fix check condition
> - use strnicmp
> - return error
> - improve commit message
>
> Changes in v4:
> - compare the parent name with reserved-memory
> - use dt_node_cmp
>
> Changes in v3:
> - new patch
> ---
>  xen/arch/arm/domain_build.c | 24 
>  1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index 4c8404155a..e0c0c01c88 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1155,15 +1155,23 @@ static int __init map_range_to_domain(const struct 
> dt_device_node *dev,
>  bool need_mapping = !dt_device_for_passthrough(dev);
>  int res;
>  
> -res = iomem_permit_access(d, paddr_to_pfn(addr),
> -  paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
> -if ( res )
> +/*
> + * Don't give iomem permissions for reserved-memory ranges to domUs
> + * until reserved-memory support is complete.
> + */
> +if ( strnicmp(dt_node_full_name(dev), "/reserved-memory",
> + strlen("/reserved-memory")) != 0 )
Why are you using strnicmp there? With such usage it is the same as
strcasecmp(). But, if you want to find "/reserved-memory" anywhere in
dt_node_full_name(dev), then you probably want to use strcasestr()


>  {
> -printk(XENLOG_ERR "Unable to permit to dom%d access to"
> -   " 0x%"PRIx64" - 0x%"PRIx64"\n",
> -   d->domain_id,
> -   addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
> -return res;
> +res = iomem_permit_access(d, paddr_to_pfn(addr),
> +paddr_to_pfn(PAGE_ALIGN(addr + len - 1)));
> +if ( res )
> +{
> +printk(XENLOG_ERR "Unable to permit to dom%d access to"
> +" 0x%"PRIx64" - 0x%"PRIx64"\n",
> +d->domain_id,
> +addr & PAGE_MASK, PAGE_ALIGN(addr + len) - 1);
> +return res;
> +}
>  }
>  
>  if ( need_mapping )


-- 
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [RFC] Code of Conduct

[Lars Kurth]

Perfect: I updated this also in the google doc. I will leave the review open 
for a week or two (we do have summer holidays after all) and let people 
comment. I can then send a proper proposal, followed by a vote
Lars

On 12/08/2019, 15:35, "George Dunlap"  wrote:

On 8/12/19 3:27 PM, Lars Kurth wrote:
> I am wondering how you feel about the usage of  "participant". There are 
> a few instances left in the text. 
> 
> "Any report of harassment within the Xen Project community will be 
addressed
> swiftly. Participants asked to stop ..."
> 
> # Consequences of Unacceptable Behavior
> If a participant engages in harassing behaviour
> 
> I would probably also want to replace this with "Community member asked 
..." and "If a community member engages in ..."

Seems reasonable to me.

 -George


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

Re: [Xen-devel] [PATCH v5 4/7] xen/arm: early_print_info print reserved_mem

[Volodymyr Babchuk]

Stefano Stabellini writes:

> Improve early_print_info to also print the banks saved in
> bootinfo.reserved_mem. Print them right after RESVD, increasing the same
> index.
>
> Since we are at it, also switch the existing RESVD print to use unsigned
> int.
>
> Signed-off-by: Stefano Stabellini 
Reviewed-by: Volodymyr Babchuk 

But, please see NIT below.

> ---
> Changes in v5:
> - switch to unsigned
>
> Changes in v4:
> - new patch
> ---
>  xen/arch/arm/bootfdt.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 0b0e22a3d0..32153e6207 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -337,9 +337,10 @@ static int __init early_scan_node(const void *fdt,
>  static void __init early_print_info(void)
>  {
>  struct meminfo *mi = 
> +struct meminfo *mem_resv = _mem;
>  struct bootmodules *mods = 
>  struct bootcmdlines *cmds = 
> -int i, nr_rsvd;
> +unsigned int i, j, nr_rsvd;
>  
>  for ( i = 0; i < mi->nr_banks; i++ )
>  printk("RAM: %"PRIpaddr" - %"PRIpaddr"\n",
> @@ -361,9 +362,15 @@ static void __init early_print_info(void)
>  continue;
>  /* fdt_get_mem_rsv returns length */
>  e += s;
> -printk(" RESVD[%d]: %"PRIpaddr" - %"PRIpaddr"\n",
> +printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n",
>   i, s, e);
NIT: I see no reason, why this printk is split into two lines, as nicely fits
into one line.

>  }
> +for ( j = 0; j < mem_resv->nr_banks; j++, i++ )
> +{
> +printk(" RESVD[%u]: %"PRIpaddr" - %"PRIpaddr"\n", i,
> + mem_resv->bank[j].start,
> + mem_resv->bank[j].start + mem_resv->bank[j].size - 1);
> +}
>  printk("\n");
>  for ( i = 0 ; i < cmds->nr_mods; i++ )
>  printk("CMDLINE[%"PRIpaddr"]:%s %s\n", cmds->cmdline[i].start,


-- 
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

[Volodymyr Babchuk]

Stefano Stabellini writes:

> As we parse the device tree in Xen, keep track of the reserved-memory
> regions as they need special treatment (follow-up patches will make use
> of the stored information.)
>
> Reuse process_memory_node to add reserved-memory regions to the
> bootinfo.reserved_mem array.
>
> Refuse to continue once we reach the max number of reserved memory
> regions to avoid accidentally mapping any portions of them into a VM.
>
> Signed-off-by: Stefano Stabellini 
>
> ---
> Changes in v5:
> - remove unneeded cast
> - remove unneeded strlen check
> - don't pass address_cells, size_cells, depth to device_tree_for_each_node
>
> Changes in v4:
> - depth + 1 in process_reserved_memory_node
> - pass address_cells and size_cells to device_tree_for_each_node
> - pass struct meminfo * instead of a boolean to process_memory_node
> - improve in-code comment
> - use a separate process_reserved_memory_node (separate from
>   process_memory_node) function wrapper to have different error handling
>
> Changes in v3:
> - match only /reserved-memory
> - put the warning back in place for reg not present on a normal memory
>   region
> - refuse to continue once we reach the max number of reserved memory
>   regions
>
> Changes in v2:
> - call process_memory_node from process_reserved_memory_node to avoid
>   duplication
> ---
>  xen/arch/arm/bootfdt.c  | 41 +++--
>  xen/include/asm-arm/setup.h |  1 +
>  2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 590b14304c..0b0e22a3d0 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -136,6 +136,7 @@ static int __init process_memory_node(const void *fdt, 
> int node,
>  const __be32 *cell;
>  paddr_t start, size;
>  u32 reg_cells = address_cells + size_cells;
> +struct meminfo *mem = data;
>
>  if ( address_cells < 1 || size_cells < 1 )
>  return -ENOENT;
> @@ -147,21 +148,46 @@ static int __init process_memory_node(const void *fdt, 
> int node,
>  cell = (const __be32 *)prop->data;
>  banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
>
> -for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
> +for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
What is logic behind the second part of the loop condition?

You know that if (banks > NR_MEM_BANKS) then you will exit with error. Do
you really need to iterate over loop in this case?

>  {
>  device_tree_get_reg(, address_cells, size_cells, , );
>  if ( !size )
>  continue;
> -bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
> -bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
> -bootinfo.mem.nr_banks++;
> +mem->bank[mem->nr_banks].start = start;
> +mem->bank[mem->nr_banks].size = size;
> +mem->nr_banks++;
>  }
>
> -if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
> +if ( mem->nr_banks == NR_MEM_BANKS )
Looks like you have the same off-by-one error, as in previous patch.
I can see that it was there earlier. But it is good time to fix it.

>  return -ENOSPC;
>  return 0;
>  }
>
> +static int __init process_reserved_memory_node(const void *fdt, int node,
> +   const char *name, int depth,
> +   u32 address_cells,
> +   u32 size_cells,
> +   void *data)
> +{
> +int rc = process_memory_node(fdt, node, name, depth, address_cells,
> + size_cells, data);
> +
> +if ( rc == -ENOSPC )
> +panic("Max number of supported reserved-memory regions reached.");
> +else if ( rc != -ENOENT )
> +return rc;
> +return 0;
> +}
> +
> +static int __init process_reserved_memory(const void *fdt, int node,
> +  const char *name, int depth,
> +  u32 address_cells, u32 size_cells)
> +{
> +return device_tree_for_each_node(fdt, node,
> + process_reserved_memory_node,
> + _mem);
> +}
> +
>  static void __init process_multiboot_node(const void *fdt, int node,
>const char *name,
>u32 address_cells, u32 size_cells)
> @@ -295,7 +321,10 @@ static int __init early_scan_node(const void *fdt,
>
>  if ( device_tree_node_matches(fdt, node, "memory") )
>  rc = process_memory_node(fdt, node, name, depth,
> - address_cells, size_cells, NULL);
> + address_cells, size_cells, );
> +else if ( depth == 1 && !strcmp(name, "reserved-memory") )
I believe you want to use dt_node_cmp() there.

> +

[Xen-devel] [PATCH 2/1] toos/xenstat: Fix -Wunused-function issue

[Andrew Cooper]

When compiling xenstat with -Werror, Clang complains:

  src/xenstat.c:134:34: error: unused function 'parse' 
[-Werror,-Wunused-function]
  static inline unsigned long long parse(char *s, char *match)
   ^
  1 error generated.

Drop the function.  It really is unused.

Spotted by Travis-CI.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/xenstat/libxenstat/src/xenstat.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/tools/xenstat/libxenstat/src/xenstat.c 
b/tools/xenstat/libxenstat/src/xenstat.c
index bba143eb53..6f93d4e982 100644
--- a/tools/xenstat/libxenstat/src/xenstat.c
+++ b/tools/xenstat/libxenstat/src/xenstat.c
@@ -131,20 +131,6 @@ void xenstat_uninit(xenstat_handle * handle)
}
 }
 
-static inline unsigned long long parse(char *s, char *match)
-{
-   char *s1 = strstr(s,match);
-   unsigned long long ret;
-
-   if ( s1 == NULL )
-   return 0LL;
-   s1 += 2;
-   if ( *s1++ != ':' )
-   return 0LL;
-   sscanf(s1,"%llu",);
-   return ret;
-}
-
 xenstat_node *xenstat_get_node(xenstat_handle * handle, unsigned int flags)
 {
 #define DOMAIN_CHUNK_SIZE 256
-- 
2.11.0


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

Re: [Xen-devel] [PATCH v5 2/7] xen/arm: make process_memory_node a device_tree_node_func

[Volodymyr Babchuk]

Hi Stefano,

Stefano Stabellini writes:

> Change the signature of process_memory_node to match
> device_tree_node_func. Thanks to this change, the next patch will be
> able to use device_tree_for_each_node to call process_memory_node on all
> the children of a provided node.
>
> Return error if there is no reg property or if nr_banks is reached. Let
> the caller deal with the error.
>
> Signed-off-by: Stefano Stabellini 
> ---
> Changes in v5:
> - return -ENOENT if address_cells or size_cells are not properly set
>
> Changes in v4:
> - return error if there is no reg propery, remove printk
> - return error if nr_banks is reached
>
> Changes in v3:
> - improve commit message
> - check return value of process_memory_node
>
> Changes in v2:
> - new
> ---
>  xen/arch/arm/bootfdt.c | 29 +++--
>  1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index a872ea57d6..590b14304c 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -125,9 +125,10 @@ int __init device_tree_for_each_node(const void *fdt, 
> int node,
>  return 0;
>  }
>
> -static void __init process_memory_node(const void *fdt, int node,
> -   const char *name,
> -   u32 address_cells, u32 size_cells)
> +static int __init process_memory_node(const void *fdt, int node,
> +  const char *name, int depth,
> +  u32 address_cells, u32 size_cells,
> +  void *data)
>  {
>  const struct fdt_property *prop;
>  int i;
> @@ -137,18 +138,11 @@ static void __init process_memory_node(const void *fdt, 
> int node,
>  u32 reg_cells = address_cells + size_cells;
>
>  if ( address_cells < 1 || size_cells < 1 )
> -{
> -printk("fdt: node `%s': invalid #address-cells or #size-cells",
> -   name);
> -return;
> -}
> +return -ENOENT;
>
>  prop = fdt_get_property(fdt, node, "reg", NULL);
>  if ( !prop )
> -{
> -printk("fdt: node `%s': missing `reg' property\n", name);
> -return;
> -}
> +return -ENOENT;
>
>  cell = (const __be32 *)prop->data;
>  banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
> @@ -162,6 +156,10 @@ static void __init process_memory_node(const void *fdt, 
> int node,
>  bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
>  bootinfo.mem.nr_banks++;
>  }
> +
> +if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
> +return -ENOSPC;
Are you sure that this logic is correct?

For example, if NR_MEM_BANKS is 1, and we have exactly one memory node
in device tree, this function will fail. But it should not. I think you
want this condition: bootinfo.mem.nr_banks > NR_MEM_BANKS

> +return 0;
>  }
>
>  static void __init process_multiboot_node(const void *fdt, int node,
> @@ -293,15 +291,18 @@ static int __init early_scan_node(const void *fdt,
>u32 address_cells, u32 size_cells,
>void *data)
>  {
> +int rc = 0;
> +
>  if ( device_tree_node_matches(fdt, node, "memory") )
> -process_memory_node(fdt, node, name, address_cells, size_cells);
> +rc = process_memory_node(fdt, node, name, depth,
> + address_cells, size_cells, NULL);
>  else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, 
> "xen,multiboot-module" ) ||
>device_tree_node_compatible(fdt, node, "multiboot,module" )))
>  process_multiboot_node(fdt, node, name, address_cells, size_cells);
>  else if ( depth == 1 && device_tree_node_matches(fdt, node, "chosen") )
>  process_chosen_node(fdt, node, name, address_cells, size_cells);
>
> -return 0;
> +return rc;
>  }
>
>  static void __init early_print_info(void)


--
Volodymyr Babchuk at EPAM
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH] tools/xenstat: Fix -Wformat-truncation= issue

[Andrew Cooper]

Building with GCC 8.3 on Buster identifies:

  src/xenstat_linux.c: In function 'xenstat_collect_networks':
  src/xenstat_linux.c:307:32: warning: 'snprintf' output may be truncated before
  the last format character [-Wformat-truncation=]
snprintf(devNoBridge, 16, "p%s", devBridge);
  ^
  src/xenstat_linux.c:307:2: note: 'snprintf' output between 2 and 17 bytes into
  a destination of size 16
snprintf(devNoBridge, 16, "p%s", devBridge);
^~~

devNoBridge[] needs one charater more than devBridge[], so allocate one byte
more.  Replace a raw 16 in the snprintf() call with a sizeof() expression
instead.

Finally, libxenstat, unlike most of the rest of the Xen, doesn't use -Werror
which is why this issue went unnoticed in CI.  Fix this.

Signed-off-by: Andrew Cooper 
---
CC: Ian Jackson 
CC: Wei Liu 
---
 tools/xenstat/libxenstat/Makefile| 2 +-
 tools/xenstat/libxenstat/src/xenstat_linux.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/xenstat/libxenstat/Makefile 
b/tools/xenstat/libxenstat/Makefile
index 58f9d63de5..ea115ae0e6 100644
--- a/tools/xenstat/libxenstat/Makefile
+++ b/tools/xenstat/libxenstat/Makefile
@@ -31,7 +31,7 @@ OBJECTS-$(CONFIG_NetBSD) += src/xenstat_netbsd.o
 OBJECTS-$(CONFIG_FreeBSD) += src/xenstat_freebsd.o
 SONAME_FLAGS=-Wl,$(SONAME_LDFLAG) -Wl,libxenstat.so.$(MAJOR)
 
-CFLAGS+=-fPIC
+CFLAGS+=-fPIC -Werror
 CFLAGS+=-Isrc $(CFLAGS_libxenctrl) $(CFLAGS_libxenstore) $(CFLAGS_xeninclude) 
-include $(XEN_ROOT)/tools/config.h
 
 LDLIBS-y = $(LDLIBS_libxenstore) $(LDLIBS_libxenctrl) -lyajl
diff --git a/tools/xenstat/libxenstat/src/xenstat_linux.c 
b/tools/xenstat/libxenstat/src/xenstat_linux.c
index 9421ca43c8..7530349eee 100644
--- a/tools/xenstat/libxenstat/src/xenstat_linux.c
+++ b/tools/xenstat/libxenstat/src/xenstat_linux.c
@@ -264,7 +264,7 @@ int xenstat_collect_networks(xenstat_node * node)
 {
/* Helper variables for parseNetDevLine() function defined above */
int i;
-   char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, 
devNoBridge[16] = { 0 };
+   char line[512] = { 0 }, iface[16] = { 0 }, devBridge[16] = { 0 }, 
devNoBridge[17] = { 0 };
unsigned long long rxBytes, rxPackets, rxErrs, rxDrops, txBytes, 
txPackets, txErrs, txDrops;
 
struct priv_data *priv = get_priv_data(node->handle);
@@ -304,7 +304,7 @@ int xenstat_collect_networks(xenstat_node * node)
 
/* We get the bridge devices for use with bonding interface to get 
bonding interface stats */
getBridge("vir", devBridge, sizeof(devBridge));
-   snprintf(devNoBridge, 16, "p%s", devBridge);
+   snprintf(devNoBridge, sizeof(devNoBridge), "p%s", devBridge);
 
while (fgets(line, 512, priv->procnetdev)) {
xenstat_domain *domain;
-- 
2.11.0


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

Re: [Xen-devel] [PATCH V2 5/6] iommu/arm: Introduce iommu_add_dt_device API

[Julien Grall]

Hi Oleksandr,

On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

This patch adds new iommu_add_dt_device API for adding DT device
to the IOMMU using generic IOMMU DT binding [1] and previously
added "iommu_fwspec" support.

New function parses the DT binding, prepares "dev->iommu_fwspec"
with correct information and calls the IOMMU driver using "add_device"
callback to register new DT device.
The IOMMU driver's responsibility is to check whether "dev->iommu_fwspec"
is initialized and mark that device as protected.

The additional benefit here is to avoid to go through the whole DT
multiple times in IOMMU driver trying to locate master devices which
belong to each IOMMU device being probed.

The upcoming IPMMU driver will have "add_device" callback implemented.

I hope, this patch won't break SMMU driver's functionality,
which doesn't have this callback implemented.


The last two sentence does not really belong to the commit message. So I 
think they should go after ---.


Anyway, the only concern for the SMMU is to not break the old bindings. 
New bindings are not supported, so it does not matter whether they are 
broken or not. Once this series is merged, we can have a look how new 
bindings for the SMMU can be supported.




[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Oleksandr Tyshchenko 
---
  xen/arch/arm/domain_build.c | 12 ++
  xen/drivers/passthrough/arm/iommu.c | 45 +
  xen/include/asm-arm/iommu.h |  3 +++
  3 files changed, 60 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index d983677..d67f7d4 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1241,6 +1241,18 @@ static int __init handle_device(struct domain *d, struct 
dt_device_node *dev,
  u64 addr, size;
  bool need_mapping = !dt_device_for_passthrough(dev);
  
+if ( dt_parse_phandle(dev, "iommus", 0) )


I don't particularly like this check. dt_parse_phandle is non-trivial to 
execute.


TBH, what we should do is trying to call iommu_add_dt_device if IOMMU is 
enabled. We can then return a recognizable value to tell the device is 
not protected.



+{
+dt_dprintk("%s add to iommu\n", dt_node_full_name(dev));
+res = iommu_add_dt_device(dev);
+if ( res )
+{
+printk(XENLOG_ERR "Failed to add %s to the IOMMU\n",
+   dt_node_full_name(dev));
+return res;
+}
+}
+
  nirq = dt_number_of_irq(dev);
  naddr = dt_number_of_address(dev);
  
diff --git a/xen/drivers/passthrough/arm/iommu.c b/xen/drivers/passthrough/arm/iommu.c

index 3195919..19516af 100644
--- a/xen/drivers/passthrough/arm/iommu.c
+++ b/xen/drivers/passthrough/arm/iommu.c
@@ -113,3 +113,48 @@ int arch_iommu_populate_page_table(struct domain *d)
  void __hwdom_init arch_iommu_hwdom_init(struct domain *d)
  {
  }
+
+int __init iommu_add_dt_device(struct dt_device_node *np)
+{
+const struct iommu_ops *ops = iommu_get_ops();
+struct dt_phandle_args iommu_spec;
+struct device *dev = dt_to_dev(np);
+int rc = 1, index = 0;
+
+if ( !iommu_enabled || !ops || !ops->add_device )
+return 0;


While I agree that !iommu_enabled should return 0, for the two others I 
am not entirely sure this is the right thing to do.


!ops is definitely an error because if you have the IOMMU enabled then 
you should have ops installed.


!ops->add_device means that you will not be able to add any device using 
the new bindings. IOW, the device will be unusable later one as most 
likely the IOMMU was configured to deny any transaction. Therefore, this 
should return an error.



+
+if ( dev_iommu_fwspec_get(dev) )
+return -EEXIST;
+
+/* According to the Documentation/devicetree/bindings/iommu/iommu.txt */


This file does not exist in Xen, so Linux should at least be mentioned 
in the comment.



+while ( !dt_parse_phandle_with_args(np, "iommus", "#iommu-cells",
+index, _spec) )
+{
+if ( !dt_device_is_available(iommu_spec.np) )
+break;
+
+rc = iommu_fwspec_init(dev, _spec.np->dev);
+if ( rc )
+break;
+
+rc = iommu_fwspec_add_ids(dev, iommu_spec.args, 1);


Here you assume that there will at least always be one cells and the 
first cell is the IDs. For a first, #iommu-cells may be 0 (and therefore 
no cells) when the master IOMMU device cannot be configured.


Furthermore, the content of the #iommu-cells depends on the driver. This 
is why Linux provides a callback of_xlate to let the driver decide how 
to interpret it.


For instance, the SMMU can support either 1 or 2 cells. It also may need 
to look-up for other properties in the node (e.g stream-match-mask).


So I think we also want to provide the of_xlate in Xen.


+if ( rc )
+break;
+

Re: [Xen-devel] [PATCH v5 1/7] xen/arm: pass node to device_tree_for_each_node

[Volodymyr Babchuk]

Hi Stefano,

Stefano Stabellini writes:

> Add a new parameter to device_tree_for_each_node: node, the node to
> start the search from. Passing 0 triggers the old behavior.
>
> Set min_depth to depth of the current node + 1 and replace the for
> loop with a do/while loop to avoid scanning siblings of the initial node
> passed as an argument.
>
> We need this change because in follow-up patches we want to be able to
> use reuse device_tree_for_each_node to call a function for each children
> nodes of a provided node and the node itself.
>
> Signed-off-by: Stefano Stabellini 

You can have my

Reviewed-by: Volodymyr Babchuk 

providing that you'll fix formatting issue below.

> ---
> Changes in v5:
> - go back to v3
> - code style improvement in acpi/boot.c
> - improve comments and commit message
> - increase min_depth to avoid parsing siblings
> - replace for with do/while loop and increase min_depth to avoid
>   scanning siblings of the initial node
> - pass only node, calculate depth
>
> Changes in v3:
> - improve commit message
> - improve in-code comments
> - improve code style
>
> Changes in v2:
> - new
> ---
>  xen/arch/arm/acpi/boot.c  |  8 +---
>  xen/arch/arm/bootfdt.c| 19 ++-
>  xen/include/xen/device_tree.h |  6 +++---
>  3 files changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> index 9b29769a10..d4957cca06 100644
> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -246,9 +246,11 @@ int __init acpi_boot_table_init(void)
>   * - the device tree is not empty (it has more than just a /chosen node)
>   *   and ACPI has not been force enabled (acpi=force)
>   */
> -if ( param_acpi_off || ( !param_acpi_force
> - && 
> device_tree_for_each_node(device_tree_flattened,
> -   dt_scan_depth1_nodes, 
> NULL)))
> +if ( param_acpi_off)
> +goto disable;
> + if ( !param_acpi_force &&
> +  device_tree_for_each_node(device_tree_flattened, 0,
> +dt_scan_depth1_nodes, NULL) )
There is 3 tabs, followed by spaces.

This file missed emacs magic at the end. I think, this is cause for this
formatting issue.

>  goto disable;
>  
>  /*
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 891b4b66ff..a872ea57d6 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -77,6 +77,7 @@ static u32 __init device_tree_get_u32(const void *fdt, int 
> node,
>  /**
>   * device_tree_for_each_node - iterate over all device tree nodes
>   * @fdt: flat device tree.
> + * @node: node to start the search from
>   * @func: function to call for each node.
>   * @data: data to pass to @func.
>   *
> @@ -85,20 +86,17 @@ static u32 __init device_tree_get_u32(const void *fdt, 
> int node,
>   * Returns 0 if all nodes were iterated over successfully.  If @func
>   * returns a value different from 0, that value is returned immediately.
>   */
> -int __init device_tree_for_each_node(const void *fdt,
> +int __init device_tree_for_each_node(const void *fdt, int node,
>   device_tree_node_func func,
>   void *data)
>  {
> -int node;
> -int depth;
> +int depth = fdt_node_depth(fdt, node);
> +int min_depth = depth + 1;
>  u32 address_cells[DEVICE_TREE_MAX_DEPTH];
>  u32 size_cells[DEVICE_TREE_MAX_DEPTH];
>  int ret;
>  
> -for ( node = 0, depth = 0;
> -  node >=0 && depth >= 0;
> -  node = fdt_next_node(fdt, node, ) )
> -{
> +do {
>  const char *name = fdt_get_name(fdt, node, NULL);
>  u32 as, ss;
>  
> @@ -120,7 +118,10 @@ int __init device_tree_for_each_node(const void *fdt,
>  ret = func(fdt, node, name, depth, as, ss, data);
>  if ( ret != 0 )
>  return ret;
> -}
> +
> +node = fdt_next_node(fdt, node, );
> +} while ( node >= 0 && depth >= min_depth );
> +
>  return 0;
>  }
>  
> @@ -357,7 +358,7 @@ size_t __init boot_fdt_info(const void *fdt, paddr_t 
> paddr)
>  
>  add_boot_module(BOOTMOD_FDT, paddr, fdt_totalsize(fdt), false);
>  
> -device_tree_for_each_node((void *)fdt, early_scan_node, NULL);
> +device_tree_for_each_node((void *)fdt, 0, early_scan_node, NULL);
>  early_print_info();
>  
>  return fdt_totalsize(fdt);
> diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
> index 83156297e2..9a7a8f2dab 100644
> --- a/xen/include/xen/device_tree.h
> +++ b/xen/include/xen/device_tree.h
> @@ -158,9 +158,9 @@ typedef int (*device_tree_node_func)(const void *fdt,
>  
>  extern const void *device_tree_flattened;
>  
> -int device_tree_for_each_node(const void *fdt,
> - device_tree_node_func func,
> - void *data);
> +int 

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Julien Grall]

Hi Oleksandr,

One more comment :).

On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+if ( fwspec )


I would actually check the iommu_dev passed in parameter is the same as 
stored. We expect all device to be protected by only one IOMMU. So 
better to be safe than allow overriding ;).


Cheers,

--
Julien Grall

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

Re: [Xen-devel] Xen-unstable staging build broken by pvshim patches.

[Andrew Cooper]

On 13/08/2019 12:51, Sander Eikelenboom wrote:
> On 13/08/2019 13:21, Andrew Cooper wrote:
>> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>>> On 09/08/2019 00:44, Andrew Cooper wrote:
 On 08/08/2019 23:34, Sander Eikelenboom wrote:
> On 08/08/2019 23:14, Andrew Cooper wrote:
>> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>>> On 08/08/2019 23:05, Andrew Cooper wrote:
 On 08/08/2019 21:59, Sander Eikelenboom wrote:
> Hi Andrew,
>
> It seems the pvshim patches in xen-unstable staging break the build 
> on my machine.
> I cloned a fresh tree to be sure, haven't checked which of the two 
> commits causes it:
> 060f4eee0fb408b316548775ab921e16b7acd0e0 or 
> 32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3
>
> --
> Sander
>
>
>
> [ -d //usr/local/lib/xen/boot ] || 
> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install -d 
> -m0755 -p //usr/local/lib/xen/boot
> [ -d //usr/local/lib/debug/usr/local/lib/xen/boot ] || 
> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install -d 
> -m0755 -p //usr/local/lib/debug/usr/local/lib/xen/boot
> [ ! -e hvmloader/hvmloader ] || 
> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
> -m0644 -p hvmloader/hvmloader //usr/local/lib/xen/boot
> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
> -m0644 -p seabios-dir/out/bios.bin 
> //usr/local/lib/xen/boot/seabios.bin
> /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
> -m0644 -p xen-dir/xen-shim //usr/local/lib/xen/boot/xen-shim
> install: cannot stat 'xen-dir/xen-shim': No such file or directory
> make[4]: *** [Makefile:52: install] Error 1
> make[4]: Leaving directory '/usr/src/new/xen-unstable/tools/firmware'
> make[3]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:237: 
> subdir-install-firmware] Error 2
> make[3]: Leaving directory '/usr/src/new/xen-unstable/tools'
> make[2]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:232: 
> subdirs-install] Error 2
> make[2]: Leaving directory '/usr/src/new/xen-unstable/tools'
> make[1]: *** [Makefile:73: install] Error 2
> make[1]: Leaving directory '/usr/src/new/xen-unstable/tools'
> make: *** [Makefile:131: install-tools] Error 2
 That's weird.

 Do you have the full log?  The real failure was somewhere earlier where
 xen-shim didn't get started.

 ~Andrew

>>> Hmm if forgot and thus forgot to mention my build script disables some 
>>> stuff:
>>> ./configure --disable-qemu-traditional --disable-stubdom --disable-docs 
>>> --disable-rombios
>>>
>>> Could be that one of those doesn't work anymore.
>> The only interesting one would be --disable-rombios, which does make
>> changes in this area of the build, but everything I changed was inside
>> the xen-dir/ directory so shouldn't interact.>
>> ~Andrew
>>
> It indeed seems to be some interaction with --disable-rombios, with just
> a plain ./configure it builds fine.
> Logs when building with --disable-rombios are attached.
 Right.  So the build itself works, but the subsequent `make install` fails.

 And to confirm, a build of 8d54a6adf (the parent of my first shim
 commit) works entirely fine?

 ~Andrew

>>> Just rechecked, and yes that builds and installs fine (with 
>>> --disable-rombios).
>> Which base distro are you using?  I'm unable to reproduce any build
>> failures locally.
>>
>> ~Andrew
>>
> Debian 10 / Buster.

Do you have your full build script available, and is it built fully from
clean?

How beefy is your build machine?  From the logs it is clearly a parallel
build but I don't see an explicit -j in the logs.

I still cant reproduce this, even in a buster container.

~Andrew

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

Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support

[Julien Grall]

Hi Oleksandr,

On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

We need to have some abstract way to add new device to the IOMMU
based on the generic IOMMU DT binding [1] which can be used for
both DT (right now) and ACPI (in future).

For that reason we can borrow the idea used in Linux these days
called "iommu_fwspec". Having this in, it will be possible
to configure IOMMU master interfaces of the device (device IDs)
from a single common place and avoid keeping almost identifical look-up


s/identifical/identical/


implementations in each IOMMU driver.

There is no need to port the whole implementation of "iommu_fwspec"
to Xen, we could, probably, end up with a much simpler solution,
some "stripped down" version which fits our requirments.


s/requirments/requirements/



So, this patch adds the following:
1. A common structure "iommu_fwspec" to hold the the per-device
firmware data
2. New member "iommu_fwspec" of struct device
3. Functions/helpers to deal with "dev->iommu_fwspec"

It should be noted that in comparing with original "iommu_fwspec"
Xen's variant doesn't contain some fields, which are not really
needed at the moment (ops, flag) and "iommu_fwnode" field was replaced
by "iommu_dev" to avoid porting a lot of code (to support "fwnode_handle")
with little benefit.

Next patch in this series will make use of that support.

[1] https://www.kernel.org/doc/Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Oleksandr Tyshchenko 
---
  xen/drivers/passthrough/arm/Makefile   |  2 +-
  xen/drivers/passthrough/arm/iommu_fwspec.c | 91 ++
  xen/include/asm-arm/device.h   |  1 +
  xen/include/asm-arm/iommu.h|  2 +
  xen/include/asm-arm/iommu_fwspec.h | 65 +
  5 files changed, 160 insertions(+), 1 deletion(-)
  create mode 100644 xen/drivers/passthrough/arm/iommu_fwspec.c
  create mode 100644 xen/include/asm-arm/iommu_fwspec.h

diff --git a/xen/drivers/passthrough/arm/Makefile 
b/xen/drivers/passthrough/arm/Makefile
index 4abb87a..5fbad45 100644
--- a/xen/drivers/passthrough/arm/Makefile
+++ b/xen/drivers/passthrough/arm/Makefile
@@ -1,2 +1,2 @@
-obj-y += iommu.o iommu_helpers.o
+obj-y += iommu.o iommu_helpers.o iommu_fwspec.o
  obj-$(CONFIG_ARM_SMMU) += smmu.o
diff --git a/xen/drivers/passthrough/arm/iommu_fwspec.c 
b/xen/drivers/passthrough/arm/iommu_fwspec.c
new file mode 100644
index 000..3474192
--- /dev/null
+++ b/xen/drivers/passthrough/arm/iommu_fwspec.c
@@ -0,0 +1,91 @@
+/*
+ * xen/drivers/passthrough/arm/iommu_fwspec.c
+ *
+ * Contains functions to maintain per-device firmware data
+ *
+ * Based on Linux's iommu_fwspec support you can find at:
+ *drivers/iommu/iommu.c
+ *
+ * Copyright (C) 2019 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * 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
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ */
+
+#include 
+#include 


Please order the headers alphabetically.

NIT: Can you a newline between xen and asm headers?


+#include 
+#include 



+
+int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
+{
+struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+if ( fwspec )
+return 0;
+
+fwspec = xzalloc(struct iommu_fwspec);
+if ( !fwspec )
+return -ENOMEM;
+
+fwspec->iommu_dev = iommu_dev;
+dev_iommu_fwspec_set(dev, fwspec);
+
+return 0;
+}
+
+void iommu_fwspec_free(struct device *dev)
+{
+struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+
+if ( fwspec )


xfree is able to deal with NULL pointer, so the check is not necessary.


+{
+xfree(fwspec);
+dev_iommu_fwspec_set(dev, NULL);
+}
+}
+
+int iommu_fwspec_add_ids(struct device *dev, uint32_t *ids, int num_ids)


While I realize the prototype is coming from Linux, num_ids cannot be 
negative (the code below would not work properly). So the parameter 
should be unsigned.



+{
+struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
+size_t size;
+int i;


Any variable that can't be negative should be unsigned.


+
+if ( !fwspec )
+return -EINVAL;
+
+size = offsetof(struct iommu_fwspec, ids[fwspec->num_ids + num_ids]);
+if ( size > sizeof(*fwspec) )
+{
+fwspec = _xrealloc(fwspec, size, sizeof(void *));
+if ( !fwspec )
+return -ENOMEM;
+
+dev_iommu_fwspec_set(dev, fwspec);
+}
+
+for ( i = 0; i < num_ids; i++ )

Re: [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request

[Oleksandr]

On 12.08.19 22:46, Julien Grall wrote:

Hi Oleksandr,


Hi, Julien




On 8/12/19 1:01 PM, Oleksandr wrote:

On 12.08.19 14:11, Julien Grall wrote:

On 02/08/2019 17:39, Oleksandr Tyshchenko wrote:

From: Oleksandr Tyshchenko 

This patch adds minimal required support to General IOMMU framework
to be able to handle a case when IOMMU driver requesting deferred
probing for a device.

In order not to pull Linux's error code (-EPROBE_DEFER) to Xen
we have chosen -EAGAIN to be used for indicating that device
probing is deferred.

This is needed for the upcoming IPMMU driver which may request
deferred probing depending on what device will be probed the first
(there is some dependency between these devices, Root device must be
registered before Cache devices. If not the case, driver will deny
further Cache device probes until Root device is registered).
As we can't guarantee a fixed pre-defined order for the device nodes
in DT, we need to be ready for the situation where devices being
probed in "any" order.

Signed-off-by: Oleksandr Tyshchenko 
---
  xen/common/device_tree.c    |  1 +
  xen/drivers/passthrough/arm/iommu.c | 35 
++-

  xen/include/asm-arm/device.h    |  6 +-
  xen/include/xen/device_tree.h   |  1 +
  4 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index e107c6f..6f37448 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1774,6 +1774,7 @@ static unsigned long __init 
unflatten_dt_node(const void *fdt,

  /* By default the device is not protected */
  np->is_protected = false;
  INIT_LIST_HEAD(>domain_list);
+    INIT_LIST_HEAD(>deferred_probe);


I am not entirely happy to add a new list_head field per node just 
for the benefits of boot code. Could we re-use domain_list (with a 
comment in the code and appropriate ASSERT)?


Agree that only boot code uses deferred_probe field. I will consider 
re-using domain_list. Could you please clarify regarding ASSERT 
(where to put and what to check).


What I meant is adding an ASSERT to check that np->domain_list is at 
empty at least before trying to add in the list. This would help to 
debug any potential issue if we end up to use domain_list earlier in 
the future. I can't see why it would as iommu is called earlier, but 
who knows :).


Got it. Thank you for clarification.



+
  static const struct iommu_ops *iommu_ops;
    const struct iommu_ops *iommu_get_ops(void)
@@ -42,7 +48,7 @@ void __init iommu_set_ops(const struct iommu_ops 
*ops)

    int __init iommu_hardware_setup(void)
  {
-    struct dt_device_node *np;
+    struct dt_device_node *np, *tmp;
  int rc;
  unsigned int num_iommus = 0;
  @@ -51,6 +57,33 @@ int __init iommu_hardware_setup(void)
  rc = device_init(np, DEVICE_IOMMU, NULL);
  if ( !rc )
  num_iommus++;
+    else if (rc == -EAGAIN)
+    /*
+ * Driver requested deferred probing, so add this 
device to

+ * the deferred list for further processing.
+ */
+    list_add(>deferred_probe, _probe_list);
+    }
+
+    /*
+ * Process devices in the deferred list if at least one 
successfully

+ * probed device is present.
+ */


I think this can turn into an infinite loop if all device in 
deferred_probe_list still return -EDEFER_PROBE and num_iommus is a 
non-zero.


Agree.




A better condition would be to check that at least one IOMMU is 
added at each loop. If not, then we should bail with an error 
because it likely means something is buggy.


Sounds reasonable. Will do.


Just to clarify:

 >>> A better condition would be to check that at least one IOMMU is 
added at each loop.


Maybe, not only added (rc == 0), but driver didn't request deferred 
probe (rc != -EAGAIN).


I think adding an IOMMU is enough. If you return an error other than 
-EAGAIN here after deferring probing, then you are likely going to 
fail at the next loop. So better to stop early.


It makes sense.





I realize this not what the current code is doing (I know I wrote it 
;)). But I am not sure it is sane to continue if only part of the 
IOMMUs are initialized. Most likely you will see an error much later 
that may be not trivial to find out.


Imagine you want to passthrough you network card to a guest but the 
IOMMU initialization failed...


Oh, agree.

As I understand, the new strict logic would be the following:

If initialization for at least one IOMMU device failed (device_init 
returns an error other than -EAGAIN), we should stop and return an error 
to upper layer (even if num_iommus > 0). No matter whether it is during 
the first attempt or after deferring probe. We don't allow the "I/O 
virtualisation" to be enabled (iommu_enabled == true) with only part of 
the IOMMU devices being initialized. Is my understanding correct?





Cheers,

--
Julien Grall


--
Regards,

Oleksandr 

[Xen-devel] [linux-4.19 test] 140017: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 6 kernel-build fail REGR. vs. 129313

Tests which are failing intermittently (not blocking):
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail pass in 
139883
 test-arm64-arm64-examine 11 examine-serial/bootloader  fail pass in 139922

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-examine  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-cubietruck  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-arndale   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit1   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-pvshim12 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-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-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-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop 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
 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

version targeted for testing:
 linux893af1c79e42e53af0da22165b46eea135af0613
baseline version:
 linux84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d

Last test of basis   129313  2018-11-02 05:39:08 Z  284 days
Failing since129412  2018-11-04 14:10:15 Z  281 days  195 attempts
Testing same since   139883  2019-08-09 23:10:54 Z3 days4 attempts


2437 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64

[Xen-devel] [PATCH] x86/tss: Fix clang build following c/s 7888440625

[Andrew Cooper]

Clang-3.5 from Debian Jessie fails with:

  smpboot.c:829:29: error: statement expression not allowed at file scope
  BUILD_BUG_ON(sizeof(this_cpu(tss_page)) != PAGE_SIZE);
  ^
  /local/xen.git/xen/include/asm/percpu.h:14:7: note: expanded from macro
  'this_cpu'
  (*RELOC_HIDE(_cpu__##var, get_cpu_info()->per_cpu_offset))
^
  /local/xen.git/xen/include/xen/compiler.h:98:3: note: expanded from macro
  'RELOC_HIDE'
({ unsigned long __ptr;   \
^
  /local/xen.git/xen/include/xen/lib.h:26:53: note: expanded from macro
  'BUILD_BUG_ON'
  #define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
  ^
  /local/xen.git/xen/include/xen/lib.h:25:57: note: expanded from macro
  'BUILD_BUG_ON_ZERO'
  #define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); })
  ^
  1 error generated.
  /local/xen.git/xen/Rules.mk:202: recipe for target 'smpboot.o' failed

This is obviously a compiler bug because the BUILD_BUG_ON() is not at file
scope.  However, it can be worked around by using a local variable.

Spotted by Gitlab CI.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
---
 xen/arch/x86/smpboot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/smpboot.c b/xen/arch/x86/smpboot.c
index 5057109a77..85c81c247e 100644
--- a/xen/arch/x86/smpboot.c
+++ b/xen/arch/x86/smpboot.c
@@ -826,9 +826,11 @@ static int setup_cpu_root_pgt(unsigned int cpu)
 rc = clone_mapping(idt_tables[cpu], rpt);
 if ( !rc )
 {
-BUILD_BUG_ON(sizeof(this_cpu(tss_page)) != PAGE_SIZE);
+struct tss_page *this_tss = _cpu(tss_page, cpu);
 
-rc = clone_mapping(_cpu(tss_page, cpu).tss, rpt);
+BUILD_BUG_ON(sizeof(*this_tss) != PAGE_SIZE);
+
+rc = clone_mapping(_tss->tss, rpt);
 }
 if ( !rc )
 rc = clone_mapping((void *)per_cpu(stubs.addr, cpu), rpt);
-- 
2.11.0


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

[Xen-devel] [PATCH v5 17/35] OvmfPkg/XenPlatformPei: Reinit XenHypercallLib

[Anthony PERARD]

The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was
initialised before the HyperPage was ready. Now that XenPlatformPei has
initialised the HyperPage, reinitialise the XenHypercallLib.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v3:
- new patch split from XenHypercallLib: Enable it in PEIM.
- check for Lib initialisation failure.

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 1 +
 OvmfPkg/XenPlatformPei/Xen.c  | 9 +
 2 files changed, 10 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index 4d00206d09..0ef77db92c 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -59,6 +59,7 @@ [LibraryClasses]
   MtrrLib
   MemEncryptSevLib
   PcdLib
+  XenHypercallLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index b366139a0a..c67f4c9697 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 #include "Xen.h"
@@ -88,6 +89,7 @@ XenConnect (
   EFI_XEN_OVMF_INFO *Info;
   CHAR8 Sig[sizeof (Info->Signature) + 1];
   UINT32 *PVHResetVectorData;
+  RETURN_STATUS Status;
 
   AsmCpuid (XenLeaf + 2, , , NULL, NULL);
   mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -152,6 +154,13 @@ XenConnect (
 sizeof(mXenInfo)
 );
 
+  //
+  // Initialize the XenHypercall library, now that the XenInfo HOB is
+  // available
+  //
+  Status = XenHypercallLibInit ();
+  ASSERT_RETURN_ERROR (Status);
+
   return EFI_SUCCESS;
 }
 
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 21/35] OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h

[Anthony PERARD]

The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- expanded the "This" that was starting the commit message body.

 OvmfPkg/Include/IndustryStandard/Xen/memory.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/OvmfPkg/Include/IndustryStandard/Xen/memory.h 
b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
index 81e981331a..4a33a26d4e 100644
--- a/OvmfPkg/Include/IndustryStandard/Xen/memory.h
+++ b/OvmfPkg/Include/IndustryStandard/Xen/memory.h
@@ -65,6 +65,29 @@ struct xen_remove_from_physmap {
 typedef struct xen_remove_from_physmap xen_remove_from_physmap_t;
 DEFINE_XEN_GUEST_HANDLE(xen_remove_from_physmap_t);
 
+/*
+ * Returns the pseudo-physical memory map as it was when the domain
+ * was started (specified by XENMEM_set_memory_map).
+ * arg == addr of xen_memory_map_t.
+ */
+#define XENMEM_memory_map   9
+struct xen_memory_map {
+/*
+ * On call the number of entries which can be stored in buffer. On
+ * return the number of entries which have been stored in
+ * buffer.
+ */
+UINT32 nr_entries;
+
+/*
+ * Entries in the buffer are in the same format as returned by the
+ * BIOS INT 0x15 EAX=0xE820 call.
+ */
+XEN_GUEST_HANDLE(void) buffer;
+};
+typedef struct xen_memory_map xen_memory_map_t;
+DEFINE_XEN_GUEST_HANDLE(xen_memory_map_t);
+
 #endif /* __XEN_PUBLIC_MEMORY_H__ */
 
 /*
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 22/35] OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall

[Anthony PERARD]

When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall.  We keep the result cached to avoid
making a second hypercall which would give the same result.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v5:
- fix commit message, the hypercall *can* be made several time, but we
  still cache the result.

v3:
- fix commit message
- add 'm' prefix to the global variables
  and make them static

 OvmfPkg/XenPlatformPei/Xen.c | 46 +++-
 1 file changed, 45 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f26f0e56dd..72f6f37b46 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "Platform.h"
 #include "Xen.h"
@@ -40,6 +41,8 @@ EFI_XEN_INFO mXenInfo;
 // Only the E820 table is used by OVMF.
 //
 EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+STATIC EFI_E820_ENTRY64 mE820Entries[128];
+STATIC UINT32 mE820EntriesCount;
 
 /**
   Returns E820 map provided by Xen
@@ -55,6 +58,12 @@ XenGetE820Map (
   UINT32 *Count
   )
 {
+  INTN ReturnCode;
+  xen_memory_map_t Parameters;
+  UINTN LoopIndex;
+  UINTN Index;
+  EFI_E820_ENTRY64 TmpEntry;
+
   //
   // Get E820 produced by hvmloader
   //
@@ -66,7 +75,42 @@ XenGetE820Map (
 return EFI_SUCCESS;
   }
 
-  return EFI_NOT_FOUND;
+  //
+  // Otherwise, get the E820 table from the Xen hypervisor
+  //
+
+  if (mE820EntriesCount > 0) {
+*Entries = mE820Entries;
+*Count = mE820EntriesCount;
+return EFI_SUCCESS;
+  }
+
+  Parameters.nr_entries = 128;
+  set_xen_guest_handle (Parameters.buffer, mE820Entries);
+
+  // Returns a errno
+  ReturnCode = XenHypercallMemoryOp (XENMEM_memory_map, );
+  ASSERT (ReturnCode == 0);
+
+  mE820EntriesCount = Parameters.nr_entries;
+
+  //
+  // Sort E820 entries
+  //
+  for (LoopIndex = 1; LoopIndex < mE820EntriesCount; LoopIndex++) {
+for (Index = LoopIndex; Index < mE820EntriesCount; Index++) {
+  if (mE820Entries[Index - 1].BaseAddr > mE820Entries[Index].BaseAddr) {
+TmpEntry = mE820Entries[Index];
+mE820Entries[Index] = mE820Entries[Index - 1];
+mE820Entries[Index - 1] = TmpEntry;
+  }
+}
+  }
+
+  *Count = mE820EntriesCount;
+  *Entries = mE820Entries;
+
+  return EFI_SUCCESS;
 }
 
 /**
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 30/35] OvmfPkg/OvmfXen: Introduce XenTimerDxe

[Anthony PERARD]

"OvmfPkg/8254TimerDxe" is replaced with a Xen-specific
EFI_TIMER_ARCH_PROTOCOL implementation. Also remove
8259InterruptControllerDxe as it is not used anymore.

This Timer uses the local APIC timer as time source as it can work on
both a Xen PVH guest and an HVM one.

Based on the "OvmfPkg/8254TimerDxe" implementation.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v4:
- fix the commit message to reflect the fact that the original code as
  moved.
- Update Maintainers.txt

v3:
- rebased, SPDX, copyright

v2:
- Use InitializeApicTimer instead of WriteLocalApicReg
- rework comments (remove many that don't apply)
- remove unused includes, and libs
- have a macro to the timervector.
- cleanup, copyright
- rework calculation of TimerCount, value to be use by the APIC timer
- check for overflow of TimerPeriod, with the apic timer, the period can
  be up to about 42s on Xen (or even higher by changing the DivideValue).

 OvmfPkg/OvmfXen.dsc |   3 +-
 OvmfPkg/OvmfXen.fdf |   3 +-
 OvmfPkg/XenTimerDxe/XenTimerDxe.inf |  42 
 OvmfPkg/XenTimerDxe/XenTimerDxe.h   | 177 ++
 OvmfPkg/XenTimerDxe/XenTimerDxe.c   | 355 
 Maintainers.txt |   1 +
 6 files changed, 577 insertions(+), 4 deletions(-)
 create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.inf
 create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.h
 create mode 100644 OvmfPkg/XenTimerDxe/XenTimerDxe.c

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 477d8c76a1..54ac910d8e 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -547,10 +547,9 @@ [Components]
   MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 
   MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-  OvmfPkg/8259InterruptControllerDxe/8259.inf
+  OvmfPkg/XenTimerDxe/XenTimerDxe.inf
   UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
   UefiCpuPkg/CpuDxe/CpuDxe.inf
-  OvmfPkg/8254TimerDxe/8254Timer.inf
   OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
   OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
   MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 49997fee9b..fa0830a324 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -298,10 +298,9 @@ [FV.DXEFV]
 INF  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
 INF  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
 INF  MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
-INF  OvmfPkg/8259InterruptControllerDxe/8259.inf
+INF  OvmfPkg/XenTimerDxe/XenTimerDxe.inf
 INF  UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
 INF  UefiCpuPkg/CpuDxe/CpuDxe.inf
-INF  OvmfPkg/8254TimerDxe/8254Timer.inf
 INF  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
 INF  OvmfPkg/PciHotPlugInitDxe/PciHotPlugInit.inf
 INF  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
diff --git a/OvmfPkg/XenTimerDxe/XenTimerDxe.inf 
b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
new file mode 100644
index 00..add1d01bbf
--- /dev/null
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.inf
@@ -0,0 +1,42 @@
+## @file
+# Local APIC timer driver that provides Timer Arch protocol.
+#
+# Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
+# Copyright (c) 2019, Citrix Systems, Inc.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = XenTimerDxe
+  FILE_GUID  = 52fe8196-f9de-4d07-b22f-51f77a0e7c41
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= TimerDriverInitialize
+
+[Packages]
+  MdePkg/MdePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  UefiBootServicesTableLib
+  BaseLib
+  DebugLib
+  UefiDriverEntryPoint
+  LocalApicLib
+
+[Sources]
+  XenTimerDxe.h
+  XenTimerDxe.c
+
+[Protocols]
+  gEfiCpuArchProtocolGuid   ## CONSUMES
+  gEfiTimerArchProtocolGuid ## PRODUCES
+[Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock  ## CONSUMES
+[Depex]
+  gEfiCpuArchProtocolGuid
diff --git a/OvmfPkg/XenTimerDxe/XenTimerDxe.h 
b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
new file mode 100644
index 00..e0a3d95fd0
--- /dev/null
+++ b/OvmfPkg/XenTimerDxe/XenTimerDxe.h
@@ -0,0 +1,177 @@
+/** @file
+  Private data structures
+
+Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2019, Citrix Systems, Inc.
+
+SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef _TIMER_H_
+#define _TIMER_H_
+
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// The default timer tick duration is set to 10 ms = 10 100 ns units
+//
+#define DEFAULT_TIMER_TICK_DURATION 10
+
+//
+// The Timer Vector use for interrupt
+//
+#define 

[Xen-devel] [PATCH v5 33/35] OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables

[Anthony PERARD]

XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the
Grant Tables.

The call is only done if it is necessary, we simply detect if the
guest is PVH, as in this case there is currently no PCI bus, and no
PCI Xen platform device which would start the XenIoPciDxe and allocate
the space for the Grant Tables.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v5:
- add missing PcdLib as #include and in [LibraryClasses]

v4:
- Removed XenIoPvhDxeNotifyExitBoot() which was doing action that should
  not be done in an ExitBootServices notification.
  (InitializeXenIoPvhDxe() has been cleaned up following this.)
- Use new PcdXenGrantFrames.
- Some coding style fix
- Update Maintainers.txt

v3:
- downgrade type to DXE_DRIVER
- use SPDX
- rework InitializeXenIoPvhDxe, and handle errors properly.
- Free the reserved allocation in ExitBootServices even if the XenIo
  protocol could successfully been uninstalled.

v2:
- do allocation in EntryPoint like the other user of XenIoMmioLib.
- allocate memory instead of hardcoded addr.
- cleanup, add copyright
- detect if we are running in PVH mode

 OvmfPkg/OvmfXen.dsc |  2 ++
 OvmfPkg/OvmfXen.fdf |  1 +
 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf | 36 +++
 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c   | 54 +
 Maintainers.txt |  1 +
 5 files changed, 94 insertions(+)
 create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
 create mode 100644 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index e719a168f8..5e07b37279 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -195,6 +195,7 @@ [LibraryClasses]
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
   XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
+  XenIoMmioLib|OvmfPkg/Library/XenIoMmioLib/XenIoMmioLib.inf
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
@@ -583,6 +584,7 @@ [Components]
   NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
 !endif
   }
+  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 5c1a925d6a..517a492f14 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -309,6 +309,7 @@ [FV.DXEFV]
 INF  MdeModulePkg/Universal/Metronome/Metronome.inf
 INF  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
 
+INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf 
b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
new file mode 100644
index 00..1c27f8aae0
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
@@ -0,0 +1,36 @@
+## @file
+#  Driver for the XenIo protocol
+#
+#  Copyright (c) 2019, Citrix Systems, Inc.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION   = 0x00010005
+  BASE_NAME = XenIoPvhDxe
+  FILE_GUID = 7a567cc4-0e75-4d7a-a305-c3db109b53ad
+  MODULE_TYPE   = DXE_DRIVER
+  VERSION_STRING= 1.0
+  ENTRY_POINT   = InitializeXenIoPvhDxe
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[Sources]
+  XenIoPvhDxe.c
+
+[LibraryClasses]
+  MemoryAllocationLib
+  PcdLib
+  UefiDriverEntryPoint
+  XenIoMmioLib
+  XenPlatformLib
+
+[FixedPcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
+
+[Depex]
+  TRUE
diff --git a/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c 
b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
new file mode 100644
index 00..9264a85df1
--- /dev/null
+++ b/OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.c
@@ -0,0 +1,54 @@
+/** @file
+
+  Driver for the XenIo protocol
+
+  This driver simply allocate space for the grant tables.
+
+  Copyright (c) 2019, Citrix Systems, Inc.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+InitializeXenIoPvhDxe (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  VOID  *Allocation;
+  EFI_STATUSStatus;
+  EFI_HANDLEXenIoHandle;
+
+  Allocation = NULL;
+  XenIoHandle = NULL;
+
+  if (!XenPvhDetected ()) {
+return EFI_UNSUPPORTED;
+  }
+
+  Allocation = AllocateReservedPages (FixedPcdGet32 (PcdXenGrantFrames));
+  if (Allocation == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+

[Xen-devel] [PATCH v5 29/35] OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency

[Anthony PERARD]

PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib
implementation. It will also be used by XenTimerDxe. Override
PcdFSBClock to match Xen vLAPIC timer frequency.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- expand commit message body to be standalone

 OvmfPkg/OvmfXen.dsc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 22970eda5d..477d8c76a1 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -439,6 +439,9 @@ [PcdsFixedAtBuild]
   # Point to the MdeModulePkg/Application/UiApp/UiApp.inf
   gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
 
+  ## Xen vlapic's frequence is 100 MHz
+  gEfiMdePkgTokenSpaceGuid.PcdFSBClock|1
+
 

 #
 # Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 23/35] OvmfPkg/XenPlatformPei: Rework memory detection

[Anthony PERARD]

When running as a Xen PVH guest, there is no CMOS to read the memory
size from.  Rework GetSystemMemorySize(Below|Above)4gb() so they can
work without CMOS by reading the e820 table.

Rework XenPublishRamRegions to also care for the reserved and ACPI
entry in the e820 table. The region that was added by InitializeXen()
isn't needed as that same entry is in the e820 table provided by
hvmloader.

MTRR settings aren't modified anymore, on HVM it's already done by
hvmloader, on PVH it is supposed to have sane default. MTRR will need
to be done properly but keeping what's already been done by programs
that have run before OVMF will do for now.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v5:
- fix coding style
- fix typo in commit message
- Handle all possible cases of a E820 reserved range overlapping with the
  LAPIC range.

v4:
- some coding style
- Added AddReservedMemoryRangeHob, and using it.
- this patch now replace "OvmfPkg/XenPlatformPei: Reserve hvmloader's 
memory only when it has run"
  from v3.  hvmloader have added an entry in the e820 table, there is no
  need for a special case.
- now, everything that is in the e820 table is added to OVMF's memory
  map, no more skipping ACPI entries or hvmloader's reserved entries.
  Instead, we look for the local APIC region and avoid it if it is
  present in the e820.
- rework commit message

 OvmfPkg/XenPlatformPei/Platform.h  | 13 ++
 OvmfPkg/XenPlatformPei/MemDetect.c | 69 +++
 OvmfPkg/XenPlatformPei/Platform.c  | 11 +
 OvmfPkg/XenPlatformPei/Xen.c   | 75 +-
 4 files changed, 147 insertions(+), 21 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index db9a62572f..7661f4a8de 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -44,6 +44,13 @@ AddReservedMemoryBaseSizeHob (
   BOOLEAN Cacheable
   );
 
+VOID
+AddReservedMemoryRangeHob (
+  EFI_PHYSICAL_ADDRESSMemoryBase,
+  EFI_PHYSICAL_ADDRESSMemoryLimit,
+  BOOLEAN Cacheable
+  );
+
 VOID
 AddressWidthInitialization (
   VOID
@@ -114,6 +121,12 @@ XenPublishRamRegions (
   VOID
   );
 
+EFI_STATUS
+XenGetE820Map (
+  EFI_E820_ENTRY64 **Entries,
+  UINT32 *Count
+  );
+
 extern EFI_BOOT_MODE mBootMode;
 
 extern UINT8 mPhysMemAddressWidth;
diff --git a/OvmfPkg/XenPlatformPei/MemDetect.c 
b/OvmfPkg/XenPlatformPei/MemDetect.c
index cf95f9c474..1f81eee407 100644
--- a/OvmfPkg/XenPlatformPei/MemDetect.c
+++ b/OvmfPkg/XenPlatformPei/MemDetect.c
@@ -96,6 +96,45 @@ Q35TsegMbytesInitialization (
   mQ35TsegMbytes = ExtendedTsegMbytes;
 }
 
+STATIC
+UINT64
+GetHighestSystemMemoryAddress (
+  BOOLEAN   Below4gb
+  )
+{
+  EFI_E820_ENTRY64*E820Map;
+  UINT32  E820EntriesCount;
+  EFI_E820_ENTRY64*Entry;
+  EFI_STATUS  Status;
+  UINT32  Loop;
+  UINT64  HighestAddress;
+  UINT64  EntryEnd;
+
+  HighestAddress = 0;
+
+  Status = XenGetE820Map (, );
+  ASSERT_EFI_ERROR (Status);
+
+  for (Loop = 0; Loop < E820EntriesCount; Loop++) {
+Entry = E820Map + Loop;
+EntryEnd = Entry->BaseAddr + Entry->Length;
+
+if (Entry->Type == EfiAcpiAddressRangeMemory &&
+EntryEnd > HighestAddress) {
+
+  if (Below4gb && (EntryEnd <= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+HighestAddress = EntryEnd;
+  }
+}
+  }
+
+  //
+  // Round down the end address.
+  //
+  return HighestAddress & ~(UINT64)EFI_PAGE_MASK;
+}
 
 UINT32
 GetSystemMemorySizeBelow4gb (
@@ -105,6 +144,19 @@ GetSystemMemorySizeBelow4gb (
   UINT8 Cmos0x34;
   UINT8 Cmos0x35;
 
+  //
+  // In PVH case, there is no CMOS, we have to calculate the memory size
+  // from parsing the E820
+  //
+  if (XenPvhDetected ()) {
+UINT64  HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (TRUE);
+ASSERT (HighestAddress > 0 && HighestAddress <= BASE_4GB);
+
+return HighestAddress;
+  }
+
   //
   // CMOS 0x34/0x35 specifies the system memory above 16 MB.
   // * CMOS(0x35) is the high byte
@@ -129,6 +181,23 @@ GetSystemMemorySizeAbove4gb (
   UINT32 Size;
   UINTN  CmosIndex;
 
+  //
+  // In PVH case, there is no CMOS, we have to calculate the memory size
+  // from parsing the E820
+  //
+  if (XenPvhDetected ()) {
+UINT64  HighestAddress;
+
+HighestAddress = GetHighestSystemMemoryAddress (FALSE);
+ASSERT (HighestAddress == 0 || HighestAddress >= BASE_4GB);
+
+if (HighestAddress >= BASE_4GB) {
+  HighestAddress -= BASE_4GB;
+}
+
+return HighestAddress;
+  }
+
   //
   // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
   // * CMOS(0x5d) is the most significant size byte
diff --git 

[Xen-devel] [PATCH v5 12/35] OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct

[Anthony PERARD]

Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.

This patch import import arch-x86/hvm/start_info.h from xen.git.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- use SPDX
- use SIGNATURE_32
- fix coding style

 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |   3 +
 OvmfPkg/Include/Guid/XenInfo.h|   4 +
 .../Xen/arch-x86/hvm/start_info.h | 143 ++
 OvmfPkg/XenPlatformPei/Xen.c  |  25 +++
 4 files changed, 175 insertions(+)
 create mode 100644 
OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h

diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
index d1265c365a..4d00206d09 100644
--- a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -84,6 +84,9 @@ [Pcd]
   gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy
   gUefiCpuPkgTokenSpaceGuid.PcdCpuLocalApicBaseAddress
 
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
 [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
 
diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index b052d618fd..25743b3884 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -25,6 +25,10 @@ typedef struct {
   /// Hypervisor minor version.
   ///
   UINT16 VersionMinor;
+  ///
+  /// Pointer to the RSDP found in the hvm_start_info provided to a PVH guest
+  ///
+  VOID *RsdpPvh;
 } EFI_XEN_INFO;
 
 extern EFI_GUID gEfiXenInfoGuid;
diff --git a/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h 
b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
new file mode 100644
index 00..15708d6dd5
--- /dev/null
+++ b/OvmfPkg/Include/IndustryStandard/Xen/arch-x86/hvm/start_info.h
@@ -0,0 +1,143 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright (c) 2016, Citrix Systems, Inc.
+ */
+
+#ifndef __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+#define __XEN_PUBLIC_ARCH_X86_HVM_START_INFO_H__
+
+/*
+ * Start of day structure passed to PVH guests and to HVM guests in %ebx.
+ *
+ * NOTE: nothing will be loaded at physical address 0, so a 0 value in any
+ * of the address fields should be treated as not present.
+ *
+ *  0 ++
+ *| magic  | Contains the magic value XEN_HVM_START_MAGIC_VALUE
+ *|| ("xEn3" with the 0x80 bit of the "E" set).
+ *  4 ++
+ *| version| Version of this structure. Current version is 1. New
+ *|| versions are guaranteed to be backwards-compatible.
+ *  8 ++
+ *| flags  | SIF_xxx flags.
+ * 12 ++
+ *| nr_modules | Number of modules passed to the kernel.
+ * 16 ++
+ *| modlist_paddr  | Physical address of an array of modules
+ *|| (layout of the structure below).
+ * 24 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 32 ++
+ *| rsdp_paddr | Physical address of the RSDP ACPI data structure.
+ * 40 ++
+ *| memmap_paddr   | Physical address of the (optional) memory map. Only
+ *|| present in version 1 and newer of the structure.
+ * 48 ++
+ *| memmap_entries | Number of entries in the memory map table. Zero
+ *|| if there is no memory map being provided. Only
+ *|| present in version 1 and newer of the structure.
+ * 52 ++
+ *| reserved   | Version 1 and newer only.
+ * 56 ++
+ *
+ * The layout of each entry in the module structure is the following:
+ *
+ *  0 ++
+ *| paddr  | Physical address of the module.
+ *  8 ++
+ *| size   | Size of the module in bytes.
+ * 16 ++
+ *| cmdline_paddr  | Physical address of the command line,
+ *|| a zero-terminated ASCII string.
+ * 24 ++
+ *| reserved   |
+ * 32 ++
+ *
+ * The layout of each entry in the memory map table is as follows:
+ *
+ *  0 ++
+ *| addr   | Base address
+ *  8 ++
+ *| size   | Size of mapping in bytes
+ * 16 ++
+ *| type   | Type of mapping as defined between the hypervisor
+ *|| and guest. See XEN_HVM_MEMMAP_TYPE_* values below.
+ * 20 +|
+ *| reserved   |
+ * 24 ++
+ *
+ * The address and sizes are always a 64bit little endian unsigned integer.
+ *
+ * NB: Xen on x86 will always try to place all the data 

[Xen-devel] [PATCH v5 16/35] OvmfPkg/XenHypercallLib: Enable it in PEIM

[Anthony PERARD]

Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibInit() must be called once the XenInfo HOB is created
with the HyperPage setup.

Change the return value of XenHypercallLibInit so failure can be
detected when the call shouldn't fail, but still have the constructor
always succeed.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v3:
- only modify XenHypercallLib, and to the modification of XenPlatformPei
  in a separated patch.
- Allow XenHypercallLibInit to be called outside the library instead of
  creating a new function, but also return failure on failure,
  and have a new constructor that never fail.

 .../Library/XenHypercallLib/XenHypercallLib.inf  |  4 ++--
 OvmfPkg/Include/Library/XenHypercallLib.h| 12 
 .../Library/XenHypercallLib/X86XenHypercall.c|  8 +---
 OvmfPkg/Library/XenHypercallLib/XenHypercall.c   | 16 
 4 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf 
b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
index 1208f0057a..21ce5b4434 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
@@ -12,10 +12,10 @@ [Defines]
   FILE_GUID  = B5EE9A32-CA5A-49A8-82E3-ADA4CCB77C7C
   MODULE_TYPE= BASE
   VERSION_STRING = 1.0
-  CONSTRUCTOR= XenHypercallLibInit
+  CONSTRUCTOR= XenHypercallLibConstruct
 
 [Defines.IA32, Defines.X64]
-  LIBRARY_CLASS  = XenHypercallLib|DXE_DRIVER UEFI_DRIVER
+  LIBRARY_CLASS  = XenHypercallLib|PEIM DXE_DRIVER UEFI_DRIVER
 
 [Defines.ARM, Defines.AARCH64]
   LIBRARY_CLASS  = XenHypercallLib
diff --git a/OvmfPkg/Include/Library/XenHypercallLib.h 
b/OvmfPkg/Include/Library/XenHypercallLib.h
index c43822782b..c1491dd652 100644
--- a/OvmfPkg/Include/Library/XenHypercallLib.h
+++ b/OvmfPkg/Include/Library/XenHypercallLib.h
@@ -10,6 +10,18 @@
 #ifndef __XEN_HYPERCALL_LIB_H__
 #define __XEN_HYPERCALL_LIB_H__
 
+/**
+  To call when the gEfiXenInfoGuid HOB became available after the library init
+  function has already been executed.
+
+  This allow to make hypercall in the PEIM stage.
+**/
+RETURN_STATUS
+EFIAPI
+XenHypercallLibInit (
+  VOID
+  );
+
 /**
   Check if the Xen Hypercall library is able to make calls to the Xen
   hypervisor.
diff --git a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c 
b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
index 27083f924f..f779e46470 100644
--- a/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c
@@ -59,13 +59,7 @@ XenHypercallLibInit (
 
   GuidHob = GetFirstGuidHob ();
   if (GuidHob == NULL) {
-//
-// We don't fail library construction, since that has catastrophic
-// consequences for client modules (whereas those modules may easily be
-// running on a non-Xen platform). Instead, XenHypercallIsAvailable() above
-// will return FALSE.
-//
-return RETURN_SUCCESS;
+return RETURN_NOT_FOUND;
   }
   XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
   HyperPage = XenInfo->HyperPages;
diff --git a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c 
b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
index a2c41a2a69..d4fa802743 100644
--- a/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
+++ b/OvmfPkg/Library/XenHypercallLib/XenHypercall.c
@@ -15,6 +15,22 @@
 #include 
 #include 
 
+RETURN_STATUS
+EFIAPI
+XenHypercallLibConstruct (
+  VOID
+  )
+{
+  XenHypercallLibInit ();
+  //
+  // We don't fail library construction, since that has catastrophic
+  // consequences for client modules (whereas those modules may easily be
+  // running on a non-Xen platform). Instead, XenHypercallIsAvailable()
+  // will return FALSE.
+  //
+  return RETURN_SUCCESS;
+}
+
 UINT64
 EFIAPI
 XenHypercallHvmGetParam (
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 10/35] OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader

[Anthony PERARD]

EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.

Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- fix coding style
- fix commit message

 OvmfPkg/Include/Guid/XenInfo.h |  4 
 OvmfPkg/PlatformPei/Xen.c  |  3 ---
 OvmfPkg/XenPlatformPei/Xen.c   | 25 +++--
 3 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/Include/Guid/XenInfo.h b/OvmfPkg/Include/Guid/XenInfo.h
index 25d76a7828..b052d618fd 100644
--- a/OvmfPkg/Include/Guid/XenInfo.h
+++ b/OvmfPkg/Include/Guid/XenInfo.h
@@ -18,10 +18,6 @@ typedef struct {
   ///
   VOID *HyperPages;
   ///
-  /// Location of the hvm_info page.
-  ///
-  VOID *HvmInfo;
-  ///
   /// Hypervisor major version.
   ///
   UINT16 VersionMajor;
diff --git a/OvmfPkg/PlatformPei/Xen.c b/OvmfPkg/PlatformPei/Xen.c
index 89dc4143b2..3e15b32a73 100644
--- a/OvmfPkg/PlatformPei/Xen.c
+++ b/OvmfPkg/PlatformPei/Xen.c
@@ -98,9 +98,6 @@ XenConnect (
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
   mXenInfo.VersionMinor = (UINT16)(XenVersion & 0x);
 
-  /* TBD: Locate hvm_info and reserve it away. */
-  mXenInfo.HvmInfo = NULL;
-
   BuildGuidDataHob (
 ,
 ,
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index f4d0d1c73b..9962fe9fc7 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -33,6 +33,12 @@ STATIC UINT32 mXenLeaf = 0;
 
 EFI_XEN_INFO mXenInfo;
 
+//
+// Location of the firmware info struct setup by hvmloader.
+// Only the E820 table is used by OVMF.
+//
+EFI_XEN_OVMF_INFO *mXenHvmloaderInfo;
+
 /**
   Returns E820 map provided by Xen
 
@@ -78,6 +84,8 @@ XenConnect (
   UINT32 TransferReg;
   UINT32 TransferPages;
   UINT32 XenVersion;
+  EFI_XEN_OVMF_INFO *Info;
+  CHAR8 Sig[sizeof (Info->Signature) + 1];
 
   AsmCpuid (XenLeaf + 2, , , NULL, NULL);
   mXenInfo.HyperPages = AllocatePages (TransferPages);
@@ -97,8 +105,21 @@ XenConnect (
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
   mXenInfo.VersionMinor = (UINT16)(XenVersion & 0x);
 
-  /* TBD: Locate hvm_info and reserve it away. */
-  mXenInfo.HvmInfo = NULL;
+  //
+  // Check if there are information left by hvmloader
+  //
+
+  Info = (EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+  //
+  // Copy the signature, and make it null-terminated.
+  //
+  AsciiStrnCpyS (Sig, sizeof (Sig), (CHAR8 *) >Signature,
+sizeof (Info->Signature));
+  if (AsciiStrCmp (Sig, "XenHVMOVMF") == 0) {
+mXenHvmloaderInfo = Info;
+  } else {
+mXenHvmloaderInfo = NULL;
+  }
 
   BuildGuidDataHob (
 ,
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 28/35] OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH

[Anthony PERARD]

When running in a Xen PVH guest, there's nothing to do in
PciAcpiInitialization() because there isn't any PCI bus. When the Host
Bridge DID isn't recognised, simply continue. (The value of
PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v3:
- Instead of checking for a false value,
  XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, simply check if we are running xen
  when the HostBridge device ID isn't recognised.

 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index d5d5d20fd8..1eba304f09 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1208,6 +1208,12 @@ PciAcpiInitialization (
   PciWrite8 (PCI_LIB_ADDRESS (0, 0x1f, 0, 0x6b), 0x0b); // H
   break;
 default:
+  if (XenDetected ()) {
+//
+// There is no PCI bus in this case.
+//
+return;
+  }
   DEBUG ((EFI_D_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
 __FUNCTION__, mHostBridgeDevId));
   ASSERT (FALSE);
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 34/35] OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg

[Anthony PERARD]

Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- Update Maintainers.txt

v3:
- fix the commit message body

 ArmVirtPkg/ArmVirtXen.dsc   | 2 +-
 .../Library/XenRealTimeClockLib/XenRealTimeClockLib.inf | 0
 .../Library/XenRealTimeClockLib/XenRealTimeClockLib.c   | 0
 Maintainers.txt | 2 +-
 4 files changed, 2 insertions(+), 2 deletions(-)
 rename {ArmVirtPkg => 
OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf (100%)
 rename {ArmVirtPkg => 
OvmfPkg}/Library/XenRealTimeClockLib/XenRealTimeClockLib.c (100%)

diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 79304ee61d..1b42a9a813 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -27,7 +27,7 @@ [Defines]
 
 [LibraryClasses]
   
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
-  
RealTimeClockLib|ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
+  RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
 
   
ArmGenericTimerCounterLib|ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/XenArmGenericTimerVirtCounterLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf 
b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
diff --git a/ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c 
b/OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
similarity index 100%
rename from ArmVirtPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
rename to OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.c
diff --git a/Maintainers.txt b/Maintainers.txt
index 79defd13bf..919baccc56 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -114,7 +114,6 @@ R: Leif Lindholm 
 ArmVirtPkg: modules used on Xen
 F: ArmVirtPkg/ArmVirtXen.*
 F: ArmVirtPkg/Library/XenArmGenericTimerVirtCounterLib/
-F: ArmVirtPkg/Library/XenRealTimeClockLib/
 F: ArmVirtPkg/Library/XenVirtMemInfoLib/
 F: ArmVirtPkg/PrePi/
 F: ArmVirtPkg/XenAcpiPlatformDxe/
@@ -374,6 +373,7 @@ F: OvmfPkg/Library/XenConsoleSerialPortLib/
 F: OvmfPkg/Library/XenHypercallLib/
 F: OvmfPkg/Library/XenIoMmioLib/
 F: OvmfPkg/Library/XenPlatformLib/
+F: OvmfPkg/Library/XenRealTimeClockLib/
 F: OvmfPkg/OvmfXen.*
 F: OvmfPkg/OvmfXenElfHeaderGenerator.c
 F: OvmfPkg/PlatformPei/MemDetect.c
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 32/35] OvmfPkg: Introduce PcdXenGrantFrames

[Anthony PERARD]

Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
the same value to be used in a different module.

The reason for the number of page to be 4 doesn't exist anymore, so
simply remove the comment.

Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v5:
- add missing PcdLib to [LibraryClasses]

v4:
- new patch

 OvmfPkg/OvmfPkg.dec | 3 +++
 OvmfPkg/XenBusDxe/XenBusDxe.inf | 3 +++
 OvmfPkg/XenBusDxe/XenBusDxe.h   | 1 +
 OvmfPkg/XenBusDxe/GrantTable.c  | 3 +--
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 04d5e29272..d5fee805ef 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -225,6 +225,9 @@ [PcdsFixedAtBuild]
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|0x0|UINT32|0x17
   gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize|0x0|UINT32|0x32
 
+  ## Number of page frames to use for storing grant table entries.
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames|4|UINT32|0x33
+
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.inf b/OvmfPkg/XenBusDxe/XenBusDxe.inf
index 86e0fb8224..536b49fa8c 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.inf
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.inf
@@ -51,6 +51,7 @@ [LibraryClasses]
   XenHypercallLib
   SynchronizationLib
   PrintLib
+  PcdLib
 
 [Protocols]
   gEfiDriverBindingProtocolGuid
@@ -59,3 +60,5 @@ [Protocols]
   gXenBusProtocolGuid
   gXenIoProtocolGuid
 
+[FixedPcd]
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenGrantFrames
diff --git a/OvmfPkg/XenBusDxe/XenBusDxe.h b/OvmfPkg/XenBusDxe/XenBusDxe.h
index 8510361bca..b1dcc3549c 100644
--- a/OvmfPkg/XenBusDxe/XenBusDxe.h
+++ b/OvmfPkg/XenBusDxe/XenBusDxe.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 //
diff --git a/OvmfPkg/XenBusDxe/GrantTable.c b/OvmfPkg/XenBusDxe/GrantTable.c
index 6575e9b88c..1130404cd1 100644
--- a/OvmfPkg/XenBusDxe/GrantTable.c
+++ b/OvmfPkg/XenBusDxe/GrantTable.c
@@ -22,8 +22,7 @@
 
 #define NR_RESERVED_ENTRIES 8
 
-/* NR_GRANT_FRAMES must be less than or equal to that configured in Xen */
-#define NR_GRANT_FRAMES 4
+#define NR_GRANT_FRAMES (FixedPcdGet32 (PcdXenGrantFrames))
 #define NR_GRANT_ENTRIES (NR_GRANT_FRAMES * EFI_PAGE_SIZE / 
sizeof(grant_entry_v1_t))
 
 STATIC grant_entry_v1_t *GrantTable = NULL;
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 20/35] OvmfPkg/XenPlatformPei: Introduce XenPvhDetected

[Anthony PERARD]

XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v5:
- in XenPvhDetected, check mXenInfo.HyperPages instead of .VersionMajor

 OvmfPkg/XenPlatformPei/Platform.h |  5 +
 OvmfPkg/XenPlatformPei/Xen.c  | 13 +
 2 files changed, 18 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 4a80057bdc..db9a62572f 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -99,6 +99,11 @@ XenHvmloaderDetected (
   VOID
   );
 
+BOOLEAN
+XenPvhDetected (
+  VOID
+  );
+
 VOID
 AmdSevInitialize (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 29b42b746c..f26f0e56dd 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -214,6 +214,19 @@ XenHvmloaderDetected (
   return (mXenHvmloaderInfo != NULL);
 }
 
+BOOLEAN
+XenPvhDetected (
+  VOID
+  )
+{
+  //
+  // This function should only be used after XenConnect
+  //
+  ASSERT (mXenInfo.HyperPages != NULL);
+
+  return mXenHvmloaderInfo == NULL;
+}
+
 VOID
 XenPublishRamRegions (
   VOID
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 26/35] OvmfPkg/XenPlatformLib: Cache result for XenDetected

[Anthony PERARD]

We are going to replace XenDetected() implementation in
PlatformBootManagerLib by the one in XenPlatformLib.
PlatformBootManagerLib's implementation does cache the result of
GetFirstGuidHob(), so we do something similar in XenPlatformLib.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- fix coding style

v3:
- new patch

 .../Library/XenPlatformLib/XenPlatformLib.c   | 20 +++
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c 
b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
index 974a0e73f1..8f20ae2d45 100644
--- a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -25,14 +25,26 @@ XenGetInfoHOB (
   VOID
   )
 {
-  EFI_HOB_GUID_TYPE  *GuidHob;
+  EFI_HOB_GUID_TYPE   *GuidHob;
+  STATIC BOOLEAN  Cached = FALSE;
+  STATIC EFI_XEN_INFO *XenInfo;
+
+  //
+  // Return the cached result for the benefit of XenDetected that can be
+  // called many times.
+  //
+  if (Cached) {
+return XenInfo;
+  }
 
   GuidHob = GetFirstGuidHob ();
   if (GuidHob == NULL) {
-return NULL;
+XenInfo = NULL;
+  } else {
+XenInfo = (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
   }
-
-  return (EFI_XEN_INFO *) GET_GUID_HOB_DATA (GuidHob);
+  Cached = TRUE;
+  return XenInfo;
 }
 
 /**
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 18/35] OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected

[Anthony PERARD]

This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- Added one sentence in the commit message.

 OvmfPkg/XenPlatformPei/Platform.h | 5 +
 OvmfPkg/XenPlatformPei/Xen.c  | 7 +++
 2 files changed, 12 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 77427496c0..925df31f88 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -89,6 +89,11 @@ XenDetect (
   VOID
   );
 
+BOOLEAN
+XenHvmloaderDetected (
+  VOID
+  );
+
 VOID
 AmdSevInitialize (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c67f4c9697..2105304c41 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -199,6 +199,13 @@ XenDetect (
   return FALSE;
 }
 
+BOOLEAN
+XenHvmloaderDetected (
+  VOID
+  )
+{
+  return (mXenHvmloaderInfo != NULL);
+}
 
 VOID
 XenPublishRamRegions (
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 25/35] OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH

[Anthony PERARD]

When the device ID of the host bridge is unknown, check if we are
running as a PVH guest as there is no PCI bus in that case.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- Remove use of XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID, and simply don't set
  PcdOvmfHostBridgePciDevId.

v2:
- Use new XEN_PVH_PCI_HOST_BRIDGE_DEVICE_ID macro

 OvmfPkg/XenPlatformPei/Platform.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 2f42ca6ccd..717fd0ab1a 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -283,6 +283,12 @@ MiscInitialization (
   AcpiEnBit  = ICH9_ACPI_CNTL_ACPI_EN;
   break;
 default:
+  if (XenPvhDetected ()) {
+//
+// There is no PCI bus in this case
+//
+return;
+  }
   DEBUG ((DEBUG_ERROR, "%a: Unknown Host Bridge Device ID: 0x%04x\n",
 __FUNCTION__, mHostBridgeDevId));
   ASSERT (FALSE);
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 31/35] OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn

[Anthony PERARD]

On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.

That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.

Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.

Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v5:
- fix typos in commit message.

v4:
- instead of creating a new XEN_CONSOLE_DEVICE_PATH, use the existing
  VENDOR_UART_DEVICE_PATH. And explain why VENDOR_UART_DEVICE_PATH
  changed in the commit message.

v3:
- removed PciSioSerialDxe and IsaSerialDxe from OvmfXen, since they
  would not be used, maybe, to check.
- some coding style fix

- not changed: PciSioSerialDxe: even if we add SerialDxe, we still needs
  PciSioSerialDxe to have OVMF use the emulated serial port on HVM.

v2:
- Use MdeModulePkg/Universal/SerialDxe instead of something new.
- Have PlatformInitializeConsole() look for it by using the
  known-in-advance device path for the xen console in the
  PLATFORM_CONSOLE_CONNECT_ENTRY.

 OvmfPkg/OvmfXen.dsc   |  4 ++
 OvmfPkg/OvmfXen.fdf   |  1 +
 .../PlatformBootManagerLib.inf|  4 ++
 .../PlatformBootManagerLib/BdsPlatform.h  |  1 +
 .../PlatformBootManagerLib/BdsPlatform.c  |  3 +-
 .../PlatformBootManagerLib/PlatformData.c | 49 +--
 6 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 54ac910d8e..e719a168f8 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -586,6 +586,10 @@ [Components]
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
+
+  
SerialPortLib|OvmfPkg/Library/XenConsoleSerialPortLib/XenConsoleSerialPortLib.inf
+  }
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index fa0830a324..5c1a925d6a 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -312,6 +312,7 @@ [FV.DXEFV]
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
 
 INF  MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
 INF  
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 04d614cd49..f89cce1879 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -61,6 +61,10 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity   ## CONSUMES
+  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits ## CONSUMES
 
 [Pcd.IA32, Pcd.X64]
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
index 49a072b400..153e215101 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h
@@ -165,6 +165,7 @@ typedef struct {
 #define CONSOLE_IN  BIT1
 #define STD_ERROR   BIT2
 extern PLATFORM_CONSOLE_CONNECT_ENTRY  gPlatformConsole[];
+extern PLATFORM_CONSOLE_CONNECT_ENTRY  gXenPlatformConsole[];
 
 //
 // Platform BDS Functions
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 1eba304f09..70df6b841a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -398,7 +398,8 @@ PlatformBootManagerBeforeConsole (
   //
   EfiBootManagerDispatchDeferredImages ();
 
-  PlatformInitializeConsole (gPlatformConsole);
+  PlatformInitializeConsole (
+XenDetected() ? gXenPlatformConsole : gPlatformConsole);
   PcdStatus = PcdSet16S (PcdPlatformBootTimeOut,
 GetFrontPageTimeoutFromQemu ());
   ASSERT_RETURN_ERROR (PcdStatus);
diff --git 

[Xen-devel] [PATCH v5 19/35] OvmfPkg/XenPlatformPei: Setup HyperPages earlier

[Anthony PERARD]

We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.

Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.

While here, add some comments in XenConnect().

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---
 OvmfPkg/XenPlatformPei/Platform.h |  5 +
 OvmfPkg/XenPlatformPei/Platform.c |  2 ++
 OvmfPkg/XenPlatformPei/Xen.c  | 23 ---
 3 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Platform.h 
b/OvmfPkg/XenPlatformPei/Platform.h
index 925df31f88..4a80057bdc 100644
--- a/OvmfPkg/XenPlatformPei/Platform.h
+++ b/OvmfPkg/XenPlatformPei/Platform.h
@@ -79,6 +79,11 @@ InstallClearCacheCallback (
   VOID
   );
 
+EFI_STATUS
+XenConnect (
+  VOID
+  );
+
 EFI_STATUS
 InitializeXen (
   VOID
diff --git a/OvmfPkg/XenPlatformPei/Platform.c 
b/OvmfPkg/XenPlatformPei/Platform.c
index 5809eadb0b..6aaafc3ee9 100644
--- a/OvmfPkg/XenPlatformPei/Platform.c
+++ b/OvmfPkg/XenPlatformPei/Platform.c
@@ -416,6 +416,8 @@ InitializeXenPlatform (
 CpuDeadLoop ();
   }
 
+  XenConnect ();
+
   BootModeInitialization ();
   AddressWidthInitialization ();
 
diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 2105304c41..29b42b746c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -72,14 +72,11 @@ XenGetE820Map (
 /**
   Connects to the Hypervisor.
 
-  @param  XenLeaf CPUID index used to connect.
-
   @return EFI_STATUS
 
 **/
 EFI_STATUS
 XenConnect (
-  UINT32 XenLeaf
   )
 {
   UINT32 Index;
@@ -91,7 +88,13 @@ XenConnect (
   UINT32 *PVHResetVectorData;
   RETURN_STATUS Status;
 
-  AsmCpuid (XenLeaf + 2, , , NULL, NULL);
+  ASSERT (mXenLeaf != 0);
+
+  //
+  // Prepare HyperPages to be able to make hypercalls
+  //
+
+  AsmCpuid (mXenLeaf + 2, , , NULL, NULL);
   mXenInfo.HyperPages = AllocatePages (TransferPages);
   if (!mXenInfo.HyperPages) {
 return EFI_OUT_OF_RESOURCES;
@@ -103,7 +106,11 @@ XenConnect (
(Index << EFI_PAGE_SHIFT) + Index);
   }
 
-  AsmCpuid (XenLeaf + 1, , NULL, NULL, NULL);
+  //
+  // Find out the Xen version
+  //
+
+  AsmCpuid (mXenLeaf + 1, , NULL, NULL, NULL);
   DEBUG ((DEBUG_ERROR, "Detected Xen version %d.%d\n",
   XenVersion >> 16, XenVersion & 0x));
   mXenInfo.VersionMajor = (UINT16)(XenVersion >> 16);
@@ -262,12 +269,6 @@ InitializeXen (
 {
   RETURN_STATUS PcdStatus;
 
-  if (mXenLeaf == 0) {
-return EFI_NOT_FOUND;
-  }
-
-  XenConnect (mXenLeaf);
-
   //
   // Reserve away HVMLOADER reserved memory [0xFC00,0xFD00).
   // This needs to match HVMLOADER RESERVED_MEMBASE/RESERVED_MEMSIZE.
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 14/35] OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib

[Anthony PERARD]

This patch replace the XenDetected() function by the one in
XenPlatformLib.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- removed gEfiXenInfoGuid from Guids list.

v3:
- new patch, splited from the next patch
  (which was OvmfPkg/AcpiPlatformDxe: Use PVH RSDP if exist)

 OvmfPkg/OvmfPkgIa32.dsc |  1 +
 OvmfPkg/OvmfPkgIa32X64.dsc  |  1 +
 OvmfPkg/OvmfPkgX64.dsc  |  1 +
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  3 +--
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h  |  6 +-
 OvmfPkg/AcpiPlatformDxe/Xen.c   | 24 -
 6 files changed, 5 insertions(+), 31 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6ab7300186..66e944436a 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -200,6 +200,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index f163aa2671..51c2bfb44f 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fa98f16a3f..ba7a758844 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -205,6 +205,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
 !if $(TPM2_ENABLE) == TRUE
   Tpm2CommandLib|SecurityPkg/Library/Tpm2CommandLib/Tpm2CommandLib.inf
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index 24634eeae2..e486b8afa5 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -44,13 +44,13 @@ [LibraryClasses]
   DebugLib
   UefiBootServicesTableLib
   UefiDriverEntryPoint
-  HobLib
   QemuFwCfgLib
   QemuFwCfgS3Lib
   MemoryAllocationLib
   BaseLib
   DxeServicesTableLib
   OrderedCollectionLib
+  XenPlatformLib
 
 [Protocols]
   gEfiAcpiTableProtocolGuid # PROTOCOL ALWAYS_CONSUMED
@@ -58,7 +58,6 @@ [Protocols]
   gEfiPciIoProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
-  gEfiXenInfoGuid
   gRootBridgesConnectedEventGroupGuid
 
 [Pcd]
diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h 
b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
index 3037afcf18..9597e028e4 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -52,11 +53,6 @@ QemuInstallAcpiTable (
   OUT  UINTN *TableKey
   );
 
-BOOLEAN
-XenDetected (
-  VOID
-  );
-
 EFI_STATUS
 EFIAPI
 InstallXenTables (
diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index e4e47bf0e8..82794b933e 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -9,8 +9,6 @@
 **/ 
 
 #include "AcpiPlatform.h"
-#include 
-#include 
 #include 
 
 #define XEN_ACPI_PHYSICAL_ADDRESS 0x000EA020
@@ -18,28 +16,6 @@
 
 EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *XenAcpiRsdpStructurePtr = NULL;
 
-/**
-  This function detects if OVMF is running on Xen.
-
-**/
-BOOLEAN
-XenDetected (
-  VOID
-  )
-{
-  EFI_HOB_GUID_TYPE *GuidHob;
-
-  //
-  // See if a XenInfo HOB is available
-  //
-  GuidHob = GetFirstGuidHob ();
-  if (GuidHob == NULL) {
-return FALSE;
-  }
-
-  return TRUE;
-}
-
 /**
   Get the address of Xen ACPI Root System Description Pointer (RSDP)
   structure.
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 13/35] OvmfPkg/Library/XenPlatformLib: New library

[Anthony PERARD]

The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- fix top-level comment style
- Update Maintainers.txt

v3:
- use SPDX
- add XenPlatformLib.h to [LibraryClasses] in OvmfPkg.dec
- fix typos

 OvmfPkg/OvmfPkg.dec   |  4 ++
 OvmfPkg/OvmfXen.dsc   |  1 +
 .../Library/XenPlatformLib/XenPlatformLib.inf | 33 +
 OvmfPkg/Include/Library/XenPlatformLib.h  | 53 ++
 .../Library/XenPlatformLib/XenPlatformLib.c   | 69 +++
 Maintainers.txt   |  2 +
 6 files changed, 162 insertions(+)
 create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 create mode 100644 OvmfPkg/Include/Library/XenPlatformLib.h
 create mode 100644 OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c

diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index c2a2ebfb95..04d5e29272 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -70,6 +70,10 @@ [LibraryClasses]
   #
   XenIoMmioLib|Include/Library/XenIoMmioLib.h
 
+  ##  @libraryclass  Get information about Xen
+  #
+  XenPlatformLib|Include/Library/XenPlatformLib.h
+
 [Guids]
   gUefiOvmfPkgTokenSpaceGuid  = {0x93bb96af, 0xb9f2, 0x4eb8, {0x94, 
0x62, 0xe0, 0xba, 0x74, 0x56, 0x42, 0x36}}
   gEfiXenInfoGuid = {0xd3b46f3b, 0xd441, 0x1244, {0x9a, 
0x12, 0x0, 0x12, 0x27, 0x3f, 0xc1, 0x4d}}
diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index b40d39e003..22970eda5d 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -194,6 +194,7 @@ [LibraryClasses]
   SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
   
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
   XenHypercallLib|OvmfPkg/Library/XenHypercallLib/XenHypercallLib.inf
+  XenPlatformLib|OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf 
b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
new file mode 100644
index 00..32adb246d6
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.inf
@@ -0,0 +1,33 @@
+## @file
+#  Get information about Xen
+#
+#  This library simply allow to find out if OVMF is running under Xen and
+#  allow to get more information when it is the case.
+#
+#  Copyright (c) 2019, Citrix Systems, Inc.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = XenPlatformLib
+  FILE_GUID  = DB54DBB7-8142-4EE5-9364-78C824B582EB
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = XenPlatformLib
+
+[Sources]
+  XenPlatformLib.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  HobLib
+
+[Guids]
+  gEfiXenInfoGuid
diff --git a/OvmfPkg/Include/Library/XenPlatformLib.h 
b/OvmfPkg/Include/Library/XenPlatformLib.h
new file mode 100644
index 00..8b8c0d057f
--- /dev/null
+++ b/OvmfPkg/Include/Library/XenPlatformLib.h
@@ -0,0 +1,53 @@
+/** @file
+  Get information about Xen
+
+  This library simply allow to find out if OVMF is running under Xen and
+  allow to get more information when it is the case.
+
+  Copyright (c) 2019, Citrix Systems, Inc.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _XEN_PLATFORM_LIB_H_
+#define _XEN_PLATFORM_LIB_H_
+
+#include 
+
+/**
+  This function detects if OVMF is running on Xen.
+
+  @retval TRUEOVMF is running on Xen
+  @retval FALSE   Xen has not been detected
+**/
+BOOLEAN
+EFIAPI
+XenDetected (
+  VOID
+  );
+
+/**
+  This function detect if OVMF have started via the PVH entry point.
+
+  @retval TRUE  PVH entry point as been used
+  @retval FALSE OVMF have started via the HVM route
+**/
+BOOLEAN
+EFIAPI
+XenPvhDetected (
+  VOID
+  );
+
+/**
+  This function return a pointer to the XenInfo HOB.
+
+  @return  XenInfo pointer or NULL if not available
+**/
+EFI_XEN_INFO *
+EFIAPI
+XenGetInfoHOB (
+  VOID
+  );
+
+#endif
diff --git a/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c 
b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
new file mode 100644
index 00..974a0e73f1
--- /dev/null
+++ b/OvmfPkg/Library/XenPlatformLib/XenPlatformLib.c
@@ -0,0 +1,69 @@
+/** @file
+  Get information about Xen
+
+  This library simply allow to find out if OVMF is running under Xen and
+  allow to get more information when it is the case.
+
+  Copyright (c) 2019, Citrix Systems, 

[Xen-devel] [PATCH v5 24/35] OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux

[Anthony PERARD]

Linux panic if the VGA region isn't reserved.

When Linux is booted on EFI system, it expects the memory at 0xa to
_not_ be conventional memory. Otherwise a variable isn't initialised
properly and Linux panic when a virtual console/terminal is asked to be
created.

See for more detail:
https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- fix commit message

 OvmfPkg/XenPlatformPei/Xen.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index c4506def9a..c41fecdc48 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -294,6 +294,12 @@ XenPublishRamRegions (
   Status = XenGetE820Map (, );
   ASSERT_EFI_ERROR (Status);
 
+  AddMemoryBaseSizeHob (0, 0xA);
+  //
+  // Video memory + Legacy BIOS region, to allow Linux to boot.
+  //
+  AddReservedMemoryBaseSizeHob (0xA, BASE_1MB - 0xA, TRUE);
+
   LapicBase = PcdGet32 (PcdCpuLocalApicBaseAddress);
   LapicEnd = LapicBase + SIZE_1MB;
   AddIoMemoryRangeHob (LapicBase, LapicEnd);
@@ -312,6 +318,16 @@ XenPublishRamRegions (
 Base = ALIGN_VALUE (Entry->BaseAddr, (UINT64)EFI_PAGE_SIZE);
 End = (Entry->BaseAddr + Entry->Length) & ~(UINT64)EFI_PAGE_MASK;
 
+//
+// Ignore the first 1MB, this is handled before the loop.
+//
+if (Base < BASE_1MB) {
+  Base = BASE_1MB;
+}
+if (Base >= End) {
+  continue;
+}
+
 switch (Entry->Type) {
 case EfiAcpiAddressRangeMemory:
   AddMemoryRangeHob (Base, End);
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 15/35] OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist

[Anthony PERARD]

If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- fix coding style

v3:
- patch splited from the previous one
- Fix DEBUG format string, use %p for pointers.
  and use gEfiCallerBaseName to print module name

 OvmfPkg/AcpiPlatformDxe/Xen.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/OvmfPkg/AcpiPlatformDxe/Xen.c b/OvmfPkg/AcpiPlatformDxe/Xen.c
index 82794b933e..f80dfe1a57 100644
--- a/OvmfPkg/AcpiPlatformDxe/Xen.c
+++ b/OvmfPkg/AcpiPlatformDxe/Xen.c
@@ -36,10 +36,27 @@ GetXenAcpiRsdp (
   EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER   *RsdpStructurePtr;
   UINT8  *XenAcpiPtr;
   UINT8  Sum;
+  EFI_XEN_INFO   *XenInfo;
 
   //
   // Detect the RSDP structure
   //
+
+  //
+  // First look for PVH one
+  //
+  XenInfo = XenGetInfoHOB ();
+  ASSERT (XenInfo != NULL);
+  if (XenInfo->RsdpPvh != NULL) {
+DEBUG ((DEBUG_INFO, "%a: Use ACPI RSDP table at 0x%p\n",
+  gEfiCallerBaseName, XenInfo->RsdpPvh));
+*RsdpPtr = XenInfo->RsdpPvh;
+return EFI_SUCCESS;
+  }
+
+  //
+  // Otherwise, look for the HVM one
+  //
   for (XenAcpiPtr = (UINT8*)(UINTN) XEN_ACPI_PHYSICAL_ADDRESS;
XenAcpiPtr < (UINT8*)(UINTN) XEN_BIOS_PHYSICAL_END;
XenAcpiPtr += 0x10) {
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 11/35] OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820

[Anthony PERARD]

Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---
 OvmfPkg/XenPlatformPei/Xen.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/OvmfPkg/XenPlatformPei/Xen.c b/OvmfPkg/XenPlatformPei/Xen.c
index 9962fe9fc7..5c7d7ddc1c 100644
--- a/OvmfPkg/XenPlatformPei/Xen.c
+++ b/OvmfPkg/XenPlatformPei/Xen.c
@@ -53,18 +53,18 @@ XenGetE820Map (
   UINT32 *Count
   )
 {
-  EFI_XEN_OVMF_INFO *Info =
-(EFI_XEN_OVMF_INFO *)(UINTN) OVMF_INFO_PHYSICAL_ADDRESS;
+  //
+  // Get E820 produced by hvmloader
+  //
+  if (mXenHvmloaderInfo != NULL) {
+ASSERT (mXenHvmloaderInfo->E820 < MAX_ADDRESS);
+*Entries = (EFI_E820_ENTRY64 *)(UINTN) mXenHvmloaderInfo->E820;
+*Count = mXenHvmloaderInfo->E820EntriesCount;
 
-  if (AsciiStrCmp ((CHAR8 *) Info->Signature, "XenHVMOVMF")) {
-return EFI_NOT_FOUND;
+return EFI_SUCCESS;
   }
 
-  ASSERT (Info->E820 < MAX_ADDRESS);
-  *Entries = (EFI_E820_ENTRY64 *)(UINTN) Info->E820;
-  *Count = Info->E820EntriesCount;
-
-  return EFI_SUCCESS;
+  return EFI_NOT_FOUND;
 }
 
 /**
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 27/35] OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib

[Anthony PERARD]

Replace the XenDetected() implementation by the one from
XenPlatformLib.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
- removed gEfiXenInfoGuid from Guids list and the associated include of
  Guid/XenInfo.h

v3:
- new patch

 .../PlatformBootManagerLib.inf|  2 +-
 .../PlatformBootManagerLib/BdsPlatform.c  | 34 +--
 2 files changed, 2 insertions(+), 34 deletions(-)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 060a3ab4c5..04d614cd49 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -54,6 +54,7 @@ [LibraryClasses]
   UefiLib
   PlatformBmPrintScLib
   Tcg2PhysicalPresenceLib
+  XenPlatformLib
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent
@@ -73,7 +74,6 @@ [Protocols]
   gEfiFirmwareVolume2ProtocolGuid   # PROTOCOL SOMETIMES_CONSUMED
 
 [Guids]
-  gEfiXenInfoGuid
   gEfiEndOfDxeEventGroupGuid
   gRootBridgesConnectedEventGroupGuid
   gUefiShellFileGuid
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 797731a41c..d5d5d20fd8 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -7,11 +7,11 @@
 **/
 
 #include "BdsPlatform.h"
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 
 //
@@ -1225,38 +1225,6 @@ PciAcpiInitialization (
   IoOr16 ((PciRead32 (Pmba) & ~BIT0) + 4, BIT0);
 }
 
-/**
-  This function detects if OVMF is running on Xen.
-
-**/
-STATIC
-BOOLEAN
-XenDetected (
-  VOID
-  )
-{
-  EFI_HOB_GUID_TYPE *GuidHob;
-  STATIC INTN   FoundHob = -1;
-
-  if (FoundHob == 0) {
-return FALSE;
-  } else if (FoundHob == 1) {
-return TRUE;
-  }
-
-  //
-  // See if a XenInfo HOB is available
-  //
-  GuidHob = GetFirstGuidHob ();
-  if (GuidHob == NULL) {
-FoundHob = 0;
-return FALSE;
-  }
-
-  FoundHob = 1;
-  return TRUE;
-}
-
 EFI_STATUS
 EFIAPI
 ConnectRecursivelyIfPciMassStorage (
-- 
Anthony PERARD

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

[Xen-devel] [PATCH v5 35/35] OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg

[Anthony PERARD]

A Xen PVH guest doesn't have a RTC that OVMF would expect, so
PcatRealTimeClockRuntimeDxe fails to initialize and prevent the
firmware from finish to boot. To prevent that, we will use
XenRealTimeClockLib which simply always return the same time.
This will work on both Xen PVH and HVM guests.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Acked-by: Laszlo Ersek 
---

Notes:
v3:
- moved RealTimeClockLib|*/XenRealTimeClockLib.inf to the global
  [LibraryClasses]

 OvmfPkg/OvmfXen.dsc | 3 ++-
 OvmfPkg/OvmfXen.fdf | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 5e07b37279..5a31f75f05 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -199,6 +199,7 @@ [LibraryClasses]
 
   
Tcg2PhysicalPresenceLib|OvmfPkg/Library/Tcg2PhysicalPresenceLibNull/DxeTcg2PhysicalPresenceLib.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
+  RealTimeClockLib|OvmfPkg/Library/XenRealTimeClockLib/XenRealTimeClockLib.inf
 
 [LibraryClasses.common]
   BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
@@ -564,7 +565,7 @@ [Components]
   }
   MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
   MdeModulePkg/Universal/Metronome/Metronome.inf
-  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   MdeModulePkg/Universal/DriverHealthManagerDxe/DriverHealthManagerDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 517a492f14..e6e9e184ef 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -307,7 +307,7 @@ [FV.DXEFV]
 INF  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
 INF  MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystemRuntimeDxe.inf
 INF  MdeModulePkg/Universal/Metronome/Metronome.inf
-INF  PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
+INF  EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
 
 INF  OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
-- 
Anthony PERARD

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

Re: [Xen-devel] [SUSPECTED SPAM]Xen-unstable staging build broken by pvshim patches.

[Sander Eikelenboom]

On 13/08/2019 13:21, Andrew Cooper wrote:
> On 09/08/2019 00:28, Sander Eikelenboom wrote:
>> On 09/08/2019 00:44, Andrew Cooper wrote:
>>> On 08/08/2019 23:34, Sander Eikelenboom wrote:
 On 08/08/2019 23:14, Andrew Cooper wrote:
> On 08/08/2019 22:16, Sander Eikelenboom wrote:
>> On 08/08/2019 23:05, Andrew Cooper wrote:
>>> On 08/08/2019 21:59, Sander Eikelenboom wrote:
 Hi Andrew,

 It seems the pvshim patches in xen-unstable staging break the build on 
 my machine.
 I cloned a fresh tree to be sure, haven't checked which of the two 
 commits causes it:
 060f4eee0fb408b316548775ab921e16b7acd0e0 or 
 32b1d62887d01f85f0c1d2e0103f69f74e1f6fa3

 --
 Sander



 [ -d //usr/local/lib/xen/boot ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install -d 
 -m0755 -p //usr/local/lib/xen/boot
 [ -d //usr/local/lib/debug/usr/local/lib/xen/boot ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install -d 
 -m0755 -p //usr/local/lib/debug/usr/local/lib/xen/boot
 [ ! -e hvmloader/hvmloader ] || 
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p hvmloader/hvmloader //usr/local/lib/xen/boot
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p seabios-dir/out/bios.bin //usr/local/lib/xen/boot/seabios.bin
 /usr/src/new/xen-unstable/tools/firmware/../../tools/cross-install 
 -m0644 -p xen-dir/xen-shim //usr/local/lib/xen/boot/xen-shim
 install: cannot stat 'xen-dir/xen-shim': No such file or directory
 make[4]: *** [Makefile:52: install] Error 1
 make[4]: Leaving directory '/usr/src/new/xen-unstable/tools/firmware'
 make[3]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:237: 
 subdir-install-firmware] Error 2
 make[3]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make[2]: *** [/usr/src/new/xen-unstable/tools/../tools/Rules.mk:232: 
 subdirs-install] Error 2
 make[2]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make[1]: *** [Makefile:73: install] Error 2
 make[1]: Leaving directory '/usr/src/new/xen-unstable/tools'
 make: *** [Makefile:131: install-tools] Error 2
>>> That's weird.
>>>
>>> Do you have the full log?  The real failure was somewhere earlier where
>>> xen-shim didn't get started.
>>>
>>> ~Andrew
>>>
>> Hmm if forgot and thus forgot to mention my build script disables some 
>> stuff:
>> ./configure --disable-qemu-traditional --disable-stubdom --disable-docs 
>> --disable-rombios
>>
>> Could be that one of those doesn't work anymore.
> The only interesting one would be --disable-rombios, which does make
> changes in this area of the build, but everything I changed was inside
> the xen-dir/ directory so shouldn't interact.>
> ~Andrew
>
 It indeed seems to be some interaction with --disable-rombios, with just
 a plain ./configure it builds fine.
 Logs when building with --disable-rombios are attached.
>>> Right.  So the build itself works, but the subsequent `make install` fails.
>>>
>>> And to confirm, a build of 8d54a6adf (the parent of my first shim
>>> commit) works entirely fine?
>>>
>>> ~Andrew
>>>
>> Just rechecked, and yes that builds and installs fine (with 
>> --disable-rombios).
> 
> Which base distro are you using?  I'm unable to reproduce any build
> failures locally.
> 
> ~Andrew
> 

Debian 10 / Buster.

--
Sander

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

[Xen-devel] [PATCH v5 04/35] OvmfPkg: Introduce XenPlatformPei

[Anthony PERARD]

Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.

This new module will be adjusted to accommodate Xen PVH.

fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)

Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,

Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
  detected.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD 
Reviewed-by: Laszlo Ersek 
---

Notes:
v4:
  - replace the other EFI_D_ by DEBUG_.
  - Update Maintainers.txt
  - fix one trailing whitespace

v3:
  - fix coding style in new code
(use DEBUG_xxx, add ASSERT before CpuDeadLoop)
  - rebased, SPDX

 OvmfPkg/OvmfXen.dsc   |   2 +-
 OvmfPkg/OvmfXen.fdf   |   2 +-
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf |  96 +
 OvmfPkg/XenPlatformPei/Cmos.h |  52 +++
 OvmfPkg/XenPlatformPei/Platform.h | 108 ++
 OvmfPkg/XenPlatformPei/Xen.h  |  39 ++
 OvmfPkg/XenPlatformPei/AmdSev.c   |  64 
 OvmfPkg/XenPlatformPei/ClearCache.c   | 112 ++
 OvmfPkg/XenPlatformPei/Cmos.c |  60 +++
 OvmfPkg/XenPlatformPei/Fv.c   |  76 
 OvmfPkg/XenPlatformPei/MemDetect.c| 421 
 OvmfPkg/XenPlatformPei/Platform.c | 444 ++
 OvmfPkg/XenPlatformPei/Xen.c  | 219 +++
 Maintainers.txt   |   1 +
 14 files changed, 1694 insertions(+), 2 deletions(-)
 create mode 100644 OvmfPkg/XenPlatformPei/XenPlatformPei.inf
 create mode 100644 OvmfPkg/XenPlatformPei/Cmos.h
 create mode 100644 OvmfPkg/XenPlatformPei/Platform.h
 create mode 100644 OvmfPkg/XenPlatformPei/Xen.h
 create mode 100644 OvmfPkg/XenPlatformPei/AmdSev.c
 create mode 100644 OvmfPkg/XenPlatformPei/ClearCache.c
 create mode 100644 OvmfPkg/XenPlatformPei/Cmos.c
 create mode 100644 OvmfPkg/XenPlatformPei/Fv.c
 create mode 100644 OvmfPkg/XenPlatformPei/MemDetect.c
 create mode 100644 OvmfPkg/XenPlatformPei/Platform.c
 create mode 100644 OvmfPkg/XenPlatformPei/Xen.c

diff --git a/OvmfPkg/OvmfXen.dsc b/OvmfPkg/OvmfXen.dsc
index 1a0e59f0cc..7619a89382 100644
--- a/OvmfPkg/OvmfXen.dsc
+++ b/OvmfPkg/OvmfXen.dsc
@@ -523,7 +523,7 @@ [Components]
   }
   MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 
-  OvmfPkg/PlatformPei/PlatformPei.inf
+  OvmfPkg/XenPlatformPei/XenPlatformPei.inf
   UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
   UefiCpuPkg/CpuMpPei/CpuMpPei.inf
 
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 6fc8479aae..2ceff7baa2 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -152,7 +152,7 @@ [FV.PEIFV]
 INF  MdeModulePkg/Universal/PCD/Pei/Pcd.inf
 INF  
MdeModulePkg/Universal/ReportStatusCodeRouter/Pei/ReportStatusCodeRouterPei.inf
 INF  MdeModulePkg/Universal/StatusCodeHandler/Pei/StatusCodeHandlerPei.inf
-INF  OvmfPkg/PlatformPei/PlatformPei.inf
+INF  OvmfPkg/XenPlatformPei/XenPlatformPei.inf
 INF  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
 INF  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf
 INF  UefiCpuPkg/CpuMpPei/CpuMpPei.inf
diff --git a/OvmfPkg/XenPlatformPei/XenPlatformPei.inf 
b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
new file mode 100644
index 00..d1265c365a
--- /dev/null
+++ b/OvmfPkg/XenPlatformPei/XenPlatformPei.inf
@@ -0,0 +1,96 @@
+## @file
+#  Platform PEI driver
+#
+#  This module provides platform specific function to detect boot mode.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2019, Citrix Systems, Inc.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME   

[Xen-devel] [PATCH v5 00/35] Specific platform to run OVMF in Xen PVH and HVM guests

[Anthony PERARD]

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v5

Changes in v5:
- patch 23 got a rework of the lapic range skipping
- small fixups in patch 20, 22, 23, 31, 32, 33.
  see notes for detail.

Hi,

I've started to create a Xen specific platform, in OvmfPkg/XenOvmf.dsc
with the goal to make it work on both Xen HVM and Xen PVH.

The first few patches only create the platform and duplicate some code from
OvmfPkg and the later patches makes OVMF boot in a Xen PVH guest and can boot
a Linux guest.

After this patch series, I'd like to wait a bit before removing Xen support
from the OvmfPkg*.dsc, to allow time to switch to the new Xen only platform,
maybe 1 year.

To build and boot:

To build, simply run OvmfPkg/build.sh -p OvmfPkg/OvmfXen.dsc
Then use OVMF.fd as a kernel of a pvh guest config file (with xl/libxl).

Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.platform-xen-pvh-v5

Anthony PERARD (35):
  OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
  OvmfPkg: Create platform OvmfXen
  OvmfPkg: Introduce XenResetVector
  OvmfPkg: Introduce XenPlatformPei
  OvmfPkg/OvmfXen: Creating an ELF header
  OvmfPkg/XenResetVector: Add new entry point for Xen PVH
  OvmfPkg/XenResetVector: Saving start of day pointer for PVH guests
  OvmfPkg/XenResetVector: Allow jumpstart from either hvmloader or PVH
  OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPU
  OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloader
  OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820
  OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day struct
  OvmfPkg/Library/XenPlatformLib: New library
  OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib
  OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it exist
  OvmfPkg/XenHypercallLib: Enable it in PEIM
  OvmfPkg/XenPlatformPei: Reinit XenHypercallLib
  OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetected
  OvmfPkg/XenPlatformPei: Setup HyperPages earlier
  OvmfPkg/XenPlatformPei: Introduce XenPvhDetected
  OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.h
  OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercall
  OvmfPkg/XenPlatformPei: Rework memory detection
  OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot Linux
  OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVH
  OvmfPkg/XenPlatformLib: Cache result for XenDetected
  OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib
  OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen
PVH
  OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequency
  OvmfPkg/OvmfXen: Introduce XenTimerDxe
  OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
  OvmfPkg: Introduce PcdXenGrantFrames
  OvmfPkg: Introduce XenIoPvhDxe to initialize Grant Tables
  OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
  OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg

 OvmfPkg/OvmfPkg.dec   |  10 +
 ArmVirtPkg/ArmVirtXen.dsc |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc   |   1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   1 +
 OvmfPkg/OvmfPkgX64.dsc|   1 +
 OvmfPkg/{OvmfPkgX64.dsc => OvmfXen.dsc}   | 238 +---
 OvmfPkg/OvmfXen.fdf   | 539 ++
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf   |   3 +-
 .../PlatformBootManagerLib.inf|   6 +-
 .../Library/ResetSystemLib/ResetSystemLib.inf |   1 +
 .../XenHypercallLib/XenHypercallLib.inf   |   4 +-
 .../Library/XenPlatformLib/XenPlatformLib.inf |  33 ++
 .../XenRealTimeClockLib.inf   |   0
 OvmfPkg/XenBusDxe/XenBusDxe.inf   |   3 +
 OvmfPkg/XenIoPvhDxe/XenIoPvhDxe.inf   |  36 ++
 OvmfPkg/XenPlatformPei/XenPlatformPei.inf | 100 
 OvmfPkg/XenResetVector/XenResetVector.inf |  41 ++
 OvmfPkg/XenTimerDxe/XenTimerDxe.inf   |  42 ++
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h|   6 +-
 OvmfPkg/Include/Guid/XenInfo.h|   8 +-
 .../Xen/arch-x86/hvm/start_info.h | 143 +
 OvmfPkg/Include/IndustryStandard/Xen/memory.h |  23 +
 OvmfPkg/Include/Library/XenHypercallLib.h |  12 +
 OvmfPkg/Include/Library/XenPlatformLib.h  |  53 ++
 .../PlatformBootManagerLib/BdsPlatform.h  |   1 +
 OvmfPkg/XenBusDxe/XenBusDxe.h |   1 +
 OvmfPkg/XenPlatformPei/Cmos.h |  52 ++
 OvmfPkg/XenPlatformPei/Platform.h | 136 +
 OvmfPkg/XenPlatformPei/Xen.h  |  39 ++
 OvmfPkg/XenTimerDxe/XenTimerDxe.h | 177 ++
 OvmfPkg/AcpiPlatformDxe/Xen.c |  41 +-
 .../PlatformBootManagerLib/BdsPlatform.c  |  43 +-
 .../PlatformBootManagerLib/PlatformData.c |  49 +-
 .../Library/ResetSystemLib/ResetSystemLib.c   |   3 +-
 .../Library/XenHypercallLib/X86XenHypercall.c