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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
baseline version:
 ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a

Last test of basis   101392  2016-10-12 08:46:21 Z0 days
Testing same since   101402  2016-10-12 15:00:43 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Fu Siyuan 
  Giri P Mudusuru 
  Laszlo Ersek 
  Liming Gao 
  Ruiyu Ni 

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 :

+ branch=ovmf
+ revision=a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
+ branch=ovmf
+ revision=a12b214ef9e002b3b7a7f7845bb025a2a8597dcc
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' xa12b214ef9e002b3b7a7f7845bb025a2a8597dcc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

[Xen-devel] [xen-unstable test] 101396: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  6 xen-boot   fail pass in 101383
 test-armhf-armhf-xl-credit2   6 xen-boot   fail pass in 101383

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101383
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101383
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101383
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101383
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101383

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

version targeted for testing:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e
baseline version:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e

Last test of basis   101396  2016-10-12 11:16:02 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17087 days0 attempts

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

[Xen-devel] [linux-3.18 test] 101398: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore fail in 101389 pass in 
101398
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 101389 pass in 
101398
 test-amd64-i386-freebsd10-amd64  6 xen-bootfail pass in 101389

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail REGR. vs. 101000
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101000
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101000
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101000

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

version targeted for testing:
 linux3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430
baseline version:
 linuxa8e202812b52b88e2a33d52687b3b0260706231a

Last test of basis   101000  2016-09-18 07:47:20 Z   24 days
Testing same since   101389  2016-10-12 06:50:56 Z0 days2 attempts


People who touched revisions under test:
  Acked-by: Arnd Bergmann 
  Akshay Bhat 
  Al Viro 

Re: [Xen-devel] [PATCH 02/15] xen: Fix coding style warnings

[Emil Condrea]

On Tue, Oct 11, 2016 at 5:20 PM, Anthony PERARD
 wrote:
> On Tue, Oct 04, 2016 at 09:43:31AM +0300, Emil Condrea wrote:
>> Fixes:
>>  * WARNING: line over 80 characters
>>
>> Signed-off-by: Emil Condrea 
>> ---
>>  hw/block/xen_disk.c  |  3 ++-
>>  hw/char/xen_console.c|  6 --
>>  hw/display/xenfb.c   | 30 --
>>  hw/net/xen_nic.c | 12 
>>  hw/xen/xen_backend.c | 15 ++-
>>  include/hw/xen/xen_backend.h |  8 +---
>>  6 files changed, 49 insertions(+), 25 deletions(-)
>>
>> diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
>> index 5aa350a..24edeb2 100644
>> --- a/hw/block/xen_disk.c
>> +++ b/hw/block/xen_disk.c
>> @@ -1068,7 +1068,8 @@ static int blk_connect(struct XenDevice *xendev)
>>  blk_set_enable_write_cache(blkdev->blk, !writethrough);
>>  } else {
>>  /* setup via qemu cmdline -> already setup for us */
>> -xen_be_printf(>xendev, 2, "get configured bdrv (cmdline 
>> setup)\n");
>> +xen_be_printf(>xendev, 2,
>> + "get configured bdrv (cmdline setup)\n");
>
> Arguments are usually aligned with the first one, so there is one
> missing space.

I guess this is displayed wrongly in the email client as in mine but the source
of the email contains this patch http://pastebin.com/Sbk23h6m, which shows that
this line is aligned to the first parameter.

>
>>  blkdev->blk = blk_by_legacy_dinfo(blkdev->dinfo);
>>  if (blk_is_read_only(blkdev->blk) && !readonly) {
>>  xen_be_printf(>xendev, 0, "Unexpected read-only drive");
>> diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
>> index 4e35c82..399bb5d 100644
>> --- a/hw/char/xen_console.c
>> +++ b/hw/char/xen_console.c
>> @@ -156,7 +156,8 @@ static void xencons_send(struct XenConsole *con)
>>  if (len < 1) {
>>  if (!con->backlog) {
>>  con->backlog = 1;
>> -xen_be_printf(>xendev, 1, "backlog piling up, nobody 
>> listening?\n");
>> +xen_be_printf(>xendev, 1,
>> + "backlog piling up, nobody listening?\n");
>
> same here and other places.

same as above

>
>>  }
>>  } else {
>>  buffer_advance(>buffer, len);
>> @@ -247,7 +248,8 @@ static int con_initialise(struct XenDevice *xendev)
>>  }
>>  }
>>
>> -xen_be_printf(xendev, 1, "ring mfn %d, remote port %d, local port %d, 
>> limit %zd\n",
>> +xen_be_printf(xendev, 1,
>> + "ring mfn %d, remote port %d, local port %d, limit %zd\n",
>> con->ring_ref,
>> con->xendev.remote_port,
>> con->xendev.local_port,
>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>> index 545ee47..0aca6ae 100644
>> --- a/hw/xen/xen_backend.c
>> +++ b/hw/xen/xen_backend.c
>> @@ -205,7 +206,8 @@ int xenstore_read_fe_int(struct XenDevice *xendev, const 
>> char *node, int *ival)
>>  return xenstore_read_int(xendev->fe, node, ival);
>>  }
>>
>> -int xenstore_read_fe_uint64(struct XenDevice *xendev, const char *node, 
>> uint64_t *uval)
>> +int xenstore_read_fe_uint64(struct XenDevice *xendev, const char *node,
>> +uint64_t *uval)
>
> Same here, it would be better to align the second line with the first
> parameter.

This indeed should be fixed. I will send a new patch for it.

>
>>  {
>>  return xenstore_read_uint64(xendev->fe, node, uval);
>>  }
>
> --
> Anthony PERARD

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

Re: [Xen-devel] [PATCH 01/15] xen: Fix coding style errors

[Emil Condrea]

Actually I've split fixing coding style in 2 patches: one for errors and
one for warnings. In this patch some resolve the error
"code indent should never use tabs" but if on the same line there is a
warning about line exceeding 80 characters, it will be fixed in
"Fix coding style warnings" patch.

On Tue, Oct 11, 2016 at 4:56 PM, Anthony PERARD
 wrote:
> On Tue, Oct 04, 2016 at 09:43:30AM +0300, Emil Condrea wrote:
>> Fixes the following errors:
>>  * ERROR: line over 90 characters
>
> It's 80 ;), and there are a few more left in this patch.
>
>>  * ERROR: code indent should never use tabs
>>  * ERROR: space prohibited after that open square bracket '['
>>  * ERROR: do not initialise statics to 0 or NULL
>>  * ERROR: "(foo*)" should be "(foo *)"
>>
>> Signed-off-by: Emil Condrea 
>
> --
> Anthony PERARD

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

[Xen-devel] [PATCH V3] Xen/Keyhandler: Rework process of nonirq keyhandler

[Lan Tianyu]

Keyhandler may run for a long time in serial port driver's
timer handler on the large machine with a lot of physical
cpus(e,g dump_timerq()) when serial port driver works in
the poll mode(via the exception mechanism).

If a timer handler runs a long time, it will block nmi_timer_fn()
to feed NMI watchdog and cause Xen hypervisor panic. Inserting
process_pending_softirqs() in timer handler will not help. when timer
interrupt arrives, timer subsystem calls all expired timer handlers
before programming next timer interrupt. There is no timer interrupt
arriving to trigger timer softirq during run a timer handler.

This patch is to fix the issue to make nonirq keyhandler run in
tasklet when receive debug key from serial port.

Signed-off-by: Lan Tianyu 
---
 xen/common/keyhandler.c  |8 +---
 xen/common/sysctl.c  |2 +-
 xen/drivers/char/console.c   |2 +-
 xen/include/xen/keyhandler.h |4 +++-
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c
index 16de6e8..005ef99 100644
--- a/xen/common/keyhandler.c
+++ b/xen/common/keyhandler.c
@@ -75,19 +75,21 @@ static struct keyhandler {
 
 static void keypress_action(unsigned long unused)
 {
-handle_keypress(keypress_key, NULL);
+console_start_log_everything();
+key_table[keypress_key].fn(keypress_key);
+console_end_log_everything();
 }
 
 static DECLARE_TASKLET(keypress_tasklet, keypress_action, 0);
 
-void handle_keypress(unsigned char key, struct cpu_user_regs *regs)
+void handle_keypress(unsigned char key, struct cpu_user_regs *regs, bool 
force_tasklet)
 {
 struct keyhandler *h;
 
 if ( key >= ARRAY_SIZE(key_table) || !(h = _table[key])->fn )
 return;
 
-if ( !in_irq() || h->irq_callback )
+if ( h->irq_callback || !force_tasklet )
 {
 console_start_log_everything();
 h->irq_callback ? h->irq_fn(key, regs) : h->fn(key);
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 8aea6ef..1eb7bad 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -136,7 +136,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
u_sysctl)
 {
 if ( copy_from_guest_offset(, op->u.debug_keys.keys, i, 1) )
 goto out;
-handle_keypress(c, guest_cpu_user_regs());
+handle_keypress(c, guest_cpu_user_regs(), false);
 }
 ret = 0;
 copyback = 0;
diff --git a/xen/drivers/char/console.c b/xen/drivers/char/console.c
index 55ae31a..b0f74ce 100644
--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -347,7 +347,7 @@ static void switch_serial_input(void)
 static void __serial_rx(char c, struct cpu_user_regs *regs)
 {
 if ( xen_rx )
-return handle_keypress(c, regs);
+return handle_keypress(c, regs, !in_irq());
 
 /* Deliver input to guest buffer, unless it is already full. */
 if ( (serial_rx_prod-serial_rx_cons) != SERIAL_RX_SIZE )
diff --git a/xen/include/xen/keyhandler.h b/xen/include/xen/keyhandler.h
index 06c05c8..e9595bd 100644
--- a/xen/include/xen/keyhandler.h
+++ b/xen/include/xen/keyhandler.h
@@ -46,7 +46,9 @@ void register_irq_keyhandler(unsigned char key,
  bool_t diagnostic);
 
 /* Inject a keypress into the key-handling subsystem. */
-extern void handle_keypress(unsigned char key, struct cpu_user_regs *regs);
+extern void handle_keypress(unsigned char key,
+   struct cpu_user_regs *regs,
+   bool async);
 
 /* Scratch space is available for use of any keyhandler. */
 extern char keyhandler_scratch[1024];
-- 
1.7.1


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

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

[osstest service owner]

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101365
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101365
 test-amd64-amd64-xl-rtds  9 debian-install   fail  like 101365

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

version targeted for testing:
 qemuu6b39b06339ee59559b31f860d4af635b046322df
baseline version:
 qemuu627eae7d729277c84f8e0ac07a8caab39c92c38d

Last test of basis   101365  2016-10-11 02:21:11 Z1 days
Testing same since   101395  2016-10-12 10:15:00 Z0 days1 attempts


People who touched revisions under test:
  Eric Blake 
  Peter Maydell 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  blocked 
 test-amd64-i386-xl-xsm   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64  

Re: [Xen-devel] [PATCH 14/15] xen: Rename xen_be_del_xendev

[Xuquan (Quan Xu)]

On October 12, 2016 9:46 PM, Anthony PERARD < anthony.per...@citrix.com > wrote:
>On Tue, Oct 04, 2016 at 09:43:43AM +0300, Emil Condrea wrote:
>> Prepare xen_be_del_xendev to be shared with frontends:
>>  * xen_be_del_xendev -> xen_pv_del_xendev
>>
>> Signed-off-by: Emil Condrea 
>
>Acked-by: Anthony PERARD 
>

Reviewed-by: Quan Xu 

Quan

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

Re: [Xen-devel] [PATCH 13/15] xen: Rename xen_be_find_xendev

[Xuquan (Quan Xu)]

On October 12, 2016 9:42 PM, Anthony PERARD < anthony.per...@citrix.com > wrote:
>On Tue, Oct 04, 2016 at 09:43:42AM +0300, Emil Condrea wrote:
>> Prepare xen_be_find_xendev to be shared with frontends:
>>  * xen_be_find_xendev -> xen_pv_find_xendev
>>
>> Signed-off-by: Emil Condrea 
>
>Acked-by: Anthony PERARD 
>

Reviewed-by: Quan Xu 

Quan

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

Re: [Xen-devel] [PATCH 12/15] xen: Rename xen_be_evtchn_event

[Xuquan (Quan Xu)]

On October 12, 2016 9:41 PM, Anthony PERARD < anthony.per...@citrix.com > wrote:
>On Tue, Oct 04, 2016 at 09:43:41AM +0300, Emil Condrea wrote:
>> Prepare xen_be_evtchn_event to be shared with frontends:
>>  * xen_be_evtchn_event -> xen_pv_evtchn_event
>>
>> Signed-off-by: Emil Condrea 
>
>Acked-by: Anthony PERARD 
>

Reviewed-by: Quan Xu 

Quan

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

Re: [Xen-devel] [PATCH 11/15] xen: Rename xen_be_send_notify

[Xuquan (Quan Xu)]

On October 12, 2016 9:41 PM, Anthony PERARD < anthony.per...@citrix.com > wrote:
>On Tue, Oct 04, 2016 at 09:43:40AM +0300, Emil Condrea wrote:
>> Prepare xen_be_send_notify to be shared with frontends:
>>  * xen_be_send_notify -> xen_pv_send_notify
>>
>> Signed-off-by: Emil Condrea 
>
>Acked-by: Anthony PERARD 
>

Reviewed-by: Quan Xu 

Quan

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

Re: [Xen-devel] [PATCH 10/15] xen: Rename xen_be_unbind_evtchn

[Xuquan (Quan Xu)]

On October 12, 2016 9:37 PM, Anthony PERARD < anthony.per...@citrix.com > wrote:
>On Tue, Oct 04, 2016 at 09:43:39AM +0300, Emil Condrea wrote:
>> Prepare xen_be_unbind_evtchn to be shared with frontends:
>>  * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
>>
>> Signed-off-by: Emil Condrea 
>
>Acked-by: Anthony PERARD 
>

Reviewed-by: Quan Xu 

Quan

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

Re: [Xen-devel] [PATCH] xen-netback: fix type mismatch warning

[Paul Durrant]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: 12 October 2016 10:54
> To: Wei Liu ; Paul Durrant 
> Cc: Arnd Bergmann ; David S. Miller
> ; David Vrabel ; xen-
> de...@lists.xenproject.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] xen-netback: fix type mismatch warning
> 
> Wiht the latest rework of the xen-netback driver, we get a warning
> on ARM about the types passed into min():
> 
> drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
> include/linux/kernel.h:739:16: error: comparison of distinct pointer types
> lacks a cast [-Werror]
> 
> The reason is that XEN_PAGE_SIZE is not size_t here. There
> is no actual bug, and we can easily avoid the warning using the
> min_t() macro instead of min().
> 
> Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
> Signed-off-by: Arnd Bergmann 

LGTM

Acked-by: Paul Durrant 

> ---
>  drivers/net/xen-netback/rx.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
> index 8e9ade6ccf18..aeb150258c6c 100644
> --- a/drivers/net/xen-netback/rx.c
> +++ b/drivers/net/xen-netback/rx.c
> @@ -337,9 +337,9 @@ static void xenvif_rx_next_chunk(struct
> xenvif_queue *queue,
>   frag_data += pkt->frag_offset;
>   frag_len -= pkt->frag_offset;
> 
> - chunk_len = min(frag_len, XEN_PAGE_SIZE - offset);
> - chunk_len = min(chunk_len,
> - XEN_PAGE_SIZE -
>   xen_offset_in_page(frag_data));
> + chunk_len = min_t(size_t, frag_len, XEN_PAGE_SIZE - offset);
> + chunk_len = min_t(size_t, chunk_len, XEN_PAGE_SIZE -
> +  xen_offset_in_page(frag_data));
> 
>   pkt->frag_offset += chunk_len;
> 
> --
> 2.9.0


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

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

[Lan Tianyu]

On 2016年10月13日 00:03, Jan Beulich wrote:
 On 12.10.16 at 16:30,  wrote:
>>
>> Since the issue happens when handle_keypress() runs in a timer handler,
>> how about to name new parameter "intimer"? __serial_rx() is called in a 
>> timer handler or interrupt handler. Or do you have other suggestion?
> 
> I think "intimer" can be confusing (to be mixed up with timer interrupt).
> How about "force_tasklet"?

OK. I will update.
-- 
Best regards
Tianyu Lan

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

[Xen-devel] [xen-unstable baseline-only test] 67868: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  15 guest-start/debian.repeat fail REGR. vs. 67863

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 67863
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 67863
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  9 windows-installfail like 67863
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 67863
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  9 windows-installfail like 67863

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

version targeted for testing:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e
baseline version:
 xen  68dc7185cbffab34211c77339874f2ea517990fd

Last test of basis67863  2016-10-11 18:46:23 Z1 days
Testing same since67868  2016-10-12 11:17:21 Z0 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Igor Druzhinin 

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

[Xen-devel] [ovmf baseline-only test] 67869: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67869 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67869/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
baseline version:
 ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2

Last test of basis67867  2016-10-12 08:19:10 Z0 days
Testing same since67869  2016-10-12 15:49:42 Z0 days1 attempts


People who touched revisions under test:
  Bruce Cran 
  Daniil Egranov 
  Eric Dong 
  Laszlo Ersek 
  Laszlo Ersek 
  Ruiyu Ni 
  Ryan Harkin 
  Yonghong Zhu 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
Author: Daniil Egranov 
Date:   Thu Sep 22 17:33:01 2016 -0500

ArmPlatformPkg/ArmJunoPkg/Drivers/PciHostBridgeDxe: Fix for PCI Dual 
Address Cycle

The fix handles the PCI Dual Address Cycle Attribute case. It allows
drivers using PCI DAC run on Juno.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daniil Egranov 
Reviewed-by: Ard Biesheuvel 
Tested-by: Ryan Harkin 

commit 272142289dbb5e8203f94cba1cc06c96b77a6938
Author: Bruce Cran 
Date:   Mon Oct 10 09:43:24 2016 -0600

OvmfPkg: add NOOPT build target for source level debugging

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Yonghong Zhu 
Cc: Laszlo Ersek 
Signed-off-by: Bruce Cran 
Reviewed-by: Laszlo Ersek 
[ler...@redhat.com: beautify subject line]
Signed-off-by: Laszlo Ersek 

commit 0acd8df45f24a1d6c2b7635691ce4d3f994cfba8
Author: Eric Dong 
Date:   Tue Oct 11 16:00:21 2016 +0800

SecurityPkg OpalPasswordSmm: Fix S3 resume failure.

Changes includes:
1.Check SMM device list before update it to avoid duplicate creation.
2.Clean up the configuration buffer before use it in S3 resume phase.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eric Dong 
Reviewed-by: Feng Tian 

commit 19e3aa7a8a8dcd661e0c2c45d139c5a6bda57dbb
Author: Yonghong Zhu 
Date:   Sun Oct 9 09:30:06 2016 +0800

BaseTools: Extend FMP to support FV statement and FD statement

This patch extend the  to support  and
, just like the normal [Capsule] section format.
In order to fix the bug https://bugzilla.tianocore.org/show_bug.cgi?id=132

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
Reviewed-by: Liming Gao 

commit ac9f5a295c51a4c1b3a1e03ca0855b4c7a4e5d43
Author: Ruiyu Ni 
Date:   Tue Oct 11 13:43:28 2016 +0800

ArmVirtPkg: Remove unused BltLib reference

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Reviewed-by: Laszlo Ersek 
Cc: Ard Biesheuvel 

commit bd52d4ff80df16ab13b8567d59bbc98d785ee095
Author: Ruiyu Ni 
Date:   Tue Oct 11 13:42:24 2016 +0800

OvmfPkg: Remove unused BltLib reference

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Jordan Justen 

Re: [Xen-devel] PCIe devices that are hotplugged after MMIO has been setup fail due to _CRS not covering 64-bit area

[Konrad Rzeszutek Wilk]

On Wed, Sep 28, 2016 at 03:21:08AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 16:43,  wrote:
> > If the guest is booted with 'pci' we nicely expand the MMIO region below
> > 4GB and try to fit in the BARs in there. If that fails (not enough
> > space) we move it above the memory (64-bit). And throughout all of this
> > we also update the _CRS field to cover these ranges.
> > 
> > (Note, I need to check if the 64-bit area is also set, I think it is).
> > 
> > But the situation is different if we hot-plug a device that has too big
> > BAR to fit in the MMIO region. We move it in the 64-bit area but we
> > don't update the _CRS. Which means that Linux will complain (unless
> > booted with pci=nocrs)). Not sure about Windows but I would assume so
> > to.
> > 
> > I was wondering what would be a good way to solve this? I looked at some
> > Dell machines to see how they deal with hotplug PCIe devices and they
> > just declared all the memory in the _CRS (including RAM).
> > 
> > We could do a hybrid - during bootup make the _CRS region have entry from
> > end of RAM to .. end of memory?
> 
> End of physical address space you mean? Generally yes, but we
> need to be a little careful there: For one, on AMD we'd better not
> overlap with the HT area. And then there's this MTRR related
> comment next to the setting of pci_hi_mem_end (albeit both HT
> area start and end of PA space should be aligned well enough).
> 
> > Or perhaps add some extra logic between QEMU and ACPI AML to expand (or
> > perhaps modify the last _CRS entry) when PCIe devices are hotplugged?
> 
> While that would be the most flexible variant, I'd be afraid of this
> getting rather complicated. Or have you already got some
> reasonable layout of how this would look like?

I did this and while all the plumbing works great and I can see that
the pci_hi_len gets incremented by the size of the 64-bit BARS of the
new device (and also decremented if hot-unplugged) I hit a snag:

Linux evaluates this only once (actually twice, but only during bootup).

That is if I did the hotplug when the guest is in GRUB and boot
Linux is quite happy. But if I did it after Linux has booted the
PNP0A03 _CRS is not evaluated again.

The only way I can see it evaulating this is if a new bridge
is added and DMAR hotplug support ("Remapping Hardware Unit Hot Plug")
is exposed to the guest. See in Linux code acpi_pci_root_add and
if (hotadd && dmar_device_add(handle))

This means: 
- adding in QEMU bridge support for each new hotplugged device, 
- and Intel VT-d in the guest support.

That I think will take a bit of time to get right.

For right now let me jump with the "simpler" solution of just
hardcoding the end of physical address space and see how that works out.

> 
> Jan
> 

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit

[Boris Ostrovsky]

On 10/12/2016 05:27 AM, Wei Liu wrote:
> On Tue, Oct 11, 2016 at 08:31:31PM +0100, Juergen Schinker wrote:
>>  
>>> We're going to tag rc2 some time this week. Thanks for help testing Xen!
>>>
>>> Wei.
>>>
 J

 - On 11 Oct, 2016, at 09:37, Wei Liu wei.l...@citrix.com wrote:

> No, you can try to work around this issue by appending --disable-rombios
> to your ./configure invocation. You can test major functionalities of
> Xen just fine without rombios.
>
> Wei.
>> Now for the fun of it I tried the RELEASE-4.7 
>>
>> and it turns out it has no support for xz-decompression 
>>
> That's probably because you don't have libzx development package
> installed when building Xen.


Which would be a new requirement for building Xen. And it broke our
(pre-historic) build server that never had it installed.

-boris


>
>> so it can't decompress the kernel via pygrub
>>
>> what
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel



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

Re: [Xen-devel] regression: xl create does not work since 38cd0664a6bf

[Andrew Cooper]

On 12/10/2016 20:25, Kyle Huey wrote:
> Apologies if this has already been reported.

It is known, and has already been fixed in master by:

http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=031655daea9bb0f69ce54a32fea0eab319471d04

~Andrew

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

Re: [Xen-devel] [RFC PATCH 5/9] x86/HVM/SVM: Add AVIC initialization code

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:44AM -0500, Suravee Suthikulpanit wrote:
> Introduce AVIC base initialization code. This includes:
> * Setting up per-VM data structures.
> * Setting up per-vCPU data structure.
> * Initializing AVIC-related VMCB bit fields.
> 
> This patch also introduces a new Xen parameter (svm-avic),
> which can be used to enable/disable AVIC support.
> Currently, this svm-avic is disabled by default.

Oddly enough you didn't CC the SVM maintainer: Boris Ostrovsky on all
these patches.

Adding him here.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/arch/x86/hvm/svm/Makefile  |   1 +
>  xen/arch/x86/hvm/svm/avic.c| 217 
> +
>  xen/arch/x86/hvm/svm/svm.c |  17 ++-
>  xen/arch/x86/hvm/svm/vmcb.c|   3 +
>  xen/include/asm-x86/hvm/svm/avic.h |  40 +++
>  xen/include/asm-x86/hvm/svm/svm.h  |   2 +
>  xen/include/asm-x86/hvm/svm/vmcb.h |  10 ++
>  7 files changed, 289 insertions(+), 1 deletion(-)
>  create mode 100644 xen/arch/x86/hvm/svm/avic.c
>  create mode 100644 xen/include/asm-x86/hvm/svm/avic.h
> 
> diff --git a/xen/arch/x86/hvm/svm/Makefile b/xen/arch/x86/hvm/svm/Makefile
> index 760d295..e0e4a59 100644
> --- a/xen/arch/x86/hvm/svm/Makefile
> +++ b/xen/arch/x86/hvm/svm/Makefile
> @@ -1,4 +1,5 @@
>  obj-y += asid.o
> +obj-y += avic.o
>  obj-y += emulate.o
>  obj-bin-y += entry.o
>  obj-y += intr.o
> diff --git a/xen/arch/x86/hvm/svm/avic.c b/xen/arch/x86/hvm/svm/avic.c
> new file mode 100644
> index 000..70bac69
> --- /dev/null
> +++ b/xen/arch/x86/hvm/svm/avic.c
> @@ -0,0 +1,217 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Since this a new file could you kindly sort these? Also do you need a copyright
header at the top?

> +
> +/* NOTE: Current max index allowed for physical APIC ID table is 255 */
> +#define AVIC_PHY_APIC_ID_MAX0xFF
> +
> +#define AVIC_DOORBELL   0xc001011b
> +#define AVIC_HPA_MASK   ~((0xFFFULL << 52) || 0xFFF)
> +#define AVIC_APIC_BAR_MASK  0xFF000ULL
> +
> +bool_t svm_avic = 0;
> +boolean_param("svm-avic", svm_avic);

Why do you want to have it disabled by default?

Also you are missing an patch to the docs/misc/xen-command-line where you would
document what this parameter does.

> +
> +static struct svm_avic_phy_ait_entry *
> +avic_get_phy_ait_entry(struct vcpu *v, int index)

Could I convience you use 'const struct vcpu *v, unsigned int index' ?

> +{
> +struct svm_avic_phy_ait_entry *avic_phy_ait;
> +struct svm_domain *d = >domain->arch.hvm_domain.svm;
> +
> +if ( !d->avic_phy_ait_mfn )
> +return NULL;
> +
> +/**

This '**' is not the standard style. Could you use only one '*' please?

> +* Note: APIC ID = 0xff is used for broadcast.
> +*   APIC ID > 0xff is reserved.
> +*/
> +if ( index >= 0xff )
> +return NULL;
> +
> +avic_phy_ait = mfn_to_virt(d->avic_phy_ait_mfn);
> +
> +return _phy_ait[index];
> +}
> +
> +/***

Ditto
> + * AVIC APIs
> + */
> +int svm_avic_dom_init(struct domain *d)
> +{
> +int ret = 0;
> +struct page_info *pg;
> +unsigned long mfn;
> +
> +if ( !svm_avic )
> +return 0;
> +
> +/**
> + * Note:
> + * AVIC hardware walks the nested page table to check permissions,
> + * but does not use the SPA address specified in the leaf page
> + * table entry since it uses  address in the AVIC_BACKING_PAGE pointer
> + * field of the VMCB. Therefore, we set up a dummy page here _mfn(0).
> + */
> +if ( !d->arch.hvm_domain.svm.avic_access_page_done )
> +{
> +set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
> +   _mfn(0), PAGE_ORDER_4K,
> +   p2m_get_hostp2m(d)->default_access);
> +d->arch.hvm_domain.svm.avic_access_page_done = true;
> +}
> +
> +/* Init AVIC log APIC ID table */
> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> +{
> +dprintk(XENLOG_ERR, "alloc AVIC logical APIC ID table error: %d\n",

How about "%d: AVIC logical .. could not be allocated" ?
> +d->domain_id);
> +ret = -ENOMEM;
> +goto err_out;
> +}
> +mfn = page_to_mfn(pg);
> +clear_domain_page(_mfn(mfn));
> +d->arch.hvm_domain.svm.avic_log_ait_mfn = mfn;
> +
> +/* Init AVIC phy APIC ID table */
> +pg = alloc_domheap_page(d, MEMF_no_owner);
> +if ( !pg )
> +{
> +dprintk(XENLOG_ERR, "alloc AVIC physical APIC ID table error: %d\n",
> +d->domain_id);

Ditto.

You could also use gdprintk instead?

> +ret = -ENOMEM;
> +goto err_out;
> +}
> +mfn = page_to_mfn(pg);
> +clear_domain_page(_mfn(mfn));
> +

[Xen-devel] regression: xl create does not work since 38cd0664a6bf

[Kyle Huey]

Apologies if this has already been reported.

On x86, xl create no longer works since 38cd0664a6bf.  xl create gets
wedges attempting to acquire the domain-userdata-lock a second time.

strace output:

open("/var/lib/xen/userdata-l.0.----.domain-userdata-lock",
O_RDWR|O_CREAT, 0666) = 9
fcntl(9, F_GETFD)   = 0
fcntl(9, F_SETFD, FD_CLOEXEC)   = 0
flock(9, LOCK_EX)   = 0
fstat(9, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
stat("/var/lib/xen/userdata-l.0.----.domain-userdata-lock",
{st_mode=S_IFREG|0644, st_size=0, ...}) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffe5c183870) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffe5c183610) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0) = 0x7fbfb6014000
madvise(0x7fbfb6014000, 8192, MADV_DONTFORK) = 0
ioctl(5, _IOC(0, 0x50, 0x00, 0x30), 0x7ffe5c1825f0) = -1 ENOSYS
(Function not implemented)
madvise(0x7fbfb6014000, 8192, MADV_DOFORK) = 0
munmap(0x7fbfb6014000, 8192)= 0
open("/var/lib/xen/userdata-l.0.----.domain-userdata-lock",
O_RDWR|O_CREAT, 0666) = 10
fcntl(10, F_GETFD)  = 0
fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
flock(10, LOCK_EX

Stack from the first lock acquisition:

Breakpoint 1, libxl__lock_domain_userdata (gc=0x7fffd910, domid=0)
at libxl_internal.c:404
404fd = open(lockfile, O_RDWR|O_CREAT, 0666);
(gdb) bt
#0  libxl__lock_domain_userdata (gc=0x7fffd910, domid=0) at
libxl_internal.c:404
#1  0x77907696 in libxl_set_memory_target (ctx=0x639050,
domid=0, target_memkb=-8, relative=1,
enforce=0) at libxl.c:4182
#2  0x00411fa9 in freemem (domid=4294967295,
b_info=0x7fffe060) at xl_cmdimpl.c:2716
#3  0x00412dd7 in create_domain (dom_info=0x7fffe4b0) at
xl_cmdimpl.c:2998
#4  0x0041a373 in main_create (argc=1, argv=0x7fffe658) at
xl_cmdimpl.c:5530
#5  0x00408eda in main (argc=2, argv=0x7fffe650) at xl.c:364

Stack from the deadlock:

Breakpoint 1, libxl__lock_domain_userdata (gc=0x7fffd7b0, domid=0)
at libxl_internal.c:404
404fd = open(lockfile, O_RDWR|O_CREAT, 0666);
(gdb) bt
#0  libxl__lock_domain_userdata (gc=0x7fffd7b0, domid=0) at
libxl_internal.c:404
#1  0x7790fa4a in libxl_retrieve_domain_configuration
(ctx=0x639050, domid=0, d_config=0x7fffda00)
at libxl.c:6654
#2  0x779076d4 in libxl_set_memory_target (ctx=0x639050,
domid=0, target_memkb=-8, relative=1,
enforce=0) at libxl.c:4188
#3  0x00411fa9 in freemem (domid=4294967295,
b_info=0x7fffe060) at xl_cmdimpl.c:2716
#4  0x00412dd7 in create_domain (dom_info=0x7fffe4b0) at
xl_cmdimpl.c:2998
#5  0x0041a373 in main_create (argc=1, argv=0x7fffe658) at
xl_cmdimpl.c:5530
#6  0x00408eda in main (argc=2, argv=0x7fffe650) at xl.c:364

- Kyle

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

[Xen-devel] [PATCH RFC] xl_cmdimpl.c: Fix printf usage

[Ronald Rojas]

Change instances of printf, fprintf, and LOG where the specifier
used is '%d' to be '%u' for domid.

Signed-off-by: Ronald Rojas 
---
 tools/libxl/xl_cmdimpl.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index cb43c00..b154e36 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2674,7 +2674,7 @@ static int preserve_domain(uint32_t *r_domid, libxl_event 
*event,
 
 libxl_uuid_generate(_uuid);
 
-LOG("Preserving domain %d %s with suffix%s",
+LOG("Preserving domain %u %s with suffix%s",
 *r_domid, d_config->c_info.name, strtime);
 rc = libxl_domain_preserve(ctx, *r_domid, _config->c_info,
strtime, new_uuid);
@@ -2758,7 +2758,7 @@ static int domain_wait_event(uint32_t domid, libxl_event 
**event_r)
 for (;;) {
 ret = libxl_event_wait(ctx, event_r, LIBXL_EVENTMASK_ALL, 0,0);
 if (ret) {
-LOG("Domain %d, failed to get event, quitting (rc=%d)", domid, 
ret);
+LOG("Domain %u, failed to get event, quitting (rc=%d)", domid, 
ret);
 return ret;
 }
 if ((*event_r)->domid != domid) {
@@ -3108,7 +3108,7 @@ start:
 }
 need_daemon = 0;
 }
-LOG("Waiting for domain %s (domid %d) to die [pid %ld]",
+LOG("Waiting for domain %s (domid %u) to die [pid %ld]",
 d_config.c_info.name, domid, (long)getpid());
 
 ret = libxl_evenable_domain_death(ctx, domid, 0, );
@@ -3134,7 +3134,7 @@ start:
 switch (event->type) {
 
 case LIBXL_EVENT_TYPE_DOMAIN_SHUTDOWN:
-LOG("Domain %d has shut down, reason code %d 0x%x", domid,
+LOG("Domain %u has shut down, reason code %d 0x%x", domid,
 event->u.domain_shutdown.shutdown_reason,
 event->u.domain_shutdown.shutdown_reason);
 switch (handle_domain_death(, event, _config)) {
@@ -3198,7 +3198,7 @@ start:
 }
 
 case LIBXL_EVENT_TYPE_DOMAIN_DEATH:
-LOG("Domain %d has been destroyed.", domid);
+LOG("Domain %u has been destroyed.", domid);
 libxl_event_free(ctx, event);
 ret = 0;
 goto out;
@@ -3442,7 +3442,7 @@ static int set_memory_max(uint32_t domid, const char *mem)
 }
 
 if (libxl_domain_setmaxmem(ctx, domid, memorykb)) {
-fprintf(stderr, "cannot set domid %d static max memory to : %s\n", 
domid, mem);
+fprintf(stderr, "cannot set domid %u static max memory to : %s\n", 
domid, mem);
 return EXIT_FAILURE;
 }
 
@@ -3476,7 +3476,7 @@ static int set_memory_target(uint32_t domid, const char 
*mem)
 }
 
 if (libxl_set_memory_target(ctx, domid, memorykb, 0, /* enforce */ 1)) {
-fprintf(stderr, "cannot set domid %d dynamic max memory to : %s\n", 
domid, mem);
+fprintf(stderr, "cannot set domid %u dynamic max memory to : %s\n", 
domid, mem);
 return EXIT_FAILURE;
 }
 
@@ -4133,7 +4133,7 @@ static void shutdown_domain(uint32_t domid,
 {
 int rc;
 
-fprintf(stderr, "Shutting down domain %d\n", domid);
+fprintf(stderr, "Shutting down domain %u\n", domid);
 rc=libxl_domain_shutdown(ctx, domid);
 if (rc == ERROR_NOPARAVIRT) {
 if (fallback_trigger) {
@@ -4165,7 +4165,7 @@ static void reboot_domain(uint32_t domid, 
libxl_evgen_domain_death **deathw,
 {
 int rc;
 
-fprintf(stderr, "Rebooting domain %d\n", domid);
+fprintf(stderr, "Rebooting domain %u\n", domid);
 rc=libxl_domain_reboot(ctx, domid);
 if (rc == ERROR_NOPARAVIRT) {
 if (fallback_trigger) {
@@ -5625,7 +5625,7 @@ int main_config_update(int argc, char **argv)
 printf_info(default_output_format, -1, _config, stdout);
 
 if (!dryrun_only) {
-fprintf(stderr, "setting dom%d configuration\n", domid);
+fprintf(stderr, "setting dom%u configuration\n", domid);
 rc = libxl_userdata_store(ctx, domid, "xl",
config_data, config_len);
 if (rc) {
@@ -5951,7 +5951,7 @@ static int vcpuset(uint32_t domid, const char* nr_vcpus, 
int check_host)
 if (rc == ERROR_DOMAIN_NOTFOUND)
 fprintf(stderr, "Domain %u does not exist.\n", domid);
 else if (rc)
-fprintf(stderr, "libxl_set_vcpuonline failed domid=%d max_vcpus=%d," \
+fprintf(stderr, "libxl_set_vcpuonline failed domid=%u max_vcpus=%d," \
 " rc: %d\n", domid, max_vcpus, rc);
 
 libxl_bitmap_dispose();
@@ -7113,7 +7113,7 @@ int main_domid(int argc, char **argv)
 return EXIT_FAILURE;
 }
 
-printf("%d\n", domid);
+printf("%u\n", domid);
 
 return EXIT_SUCCESS;
 }
@@ -7138,7 +7138,7 @@ int main_domname(int argc, char **argv)
 
 domname = libxl_domid_to_name(ctx, domid);
 if (!domname) {
-fprintf(stderr, "Can't get domain name of domain id '%d', maybe this 

Re: [Xen-devel] [RFC PATCH 4/9] x86/SVM: Modify VMCB fields to add AVIC support

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:43AM -0500, Suravee Suthikulpanit wrote:
> Introduce AVIC-related VMCB fields.
> 
> Signed-off-by: Suravee Suthikulpanit 
> ---
>  xen/include/asm-x86/hvm/svm/vmcb.h | 23 +++
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/xen/include/asm-x86/hvm/svm/vmcb.h 
> b/xen/include/asm-x86/hvm/svm/vmcb.h
> index bad2382..768e9fb 100644
> --- a/xen/include/asm-x86/hvm/svm/vmcb.h
> +++ b/xen/include/asm-x86/hvm/svm/vmcb.h
> @@ -328,14 +328,15 @@ typedef union __packed
>  struct 
>  {
>  u64 tpr:  8;
> -u64 irq:  1;
> +u64 irq:  1; /* disabled for avic */
>  u64 rsvd0:7;
> -u64 prio: 4;
> -u64 ign_tpr:  1;
> +u64 prio: 4; /* disabled for avic */
> +u64 ign_tpr:  1; /* disabled for avic */
>  u64 rsvd1:3;
>  u64 intr_masking: 1;
> -u64 rsvd2:7;
> -u64 vector:   8;
> +u64 rsvd2:6;
> +u64 avic_enable:  1;
> +u64 vector:   8; /* disabled for avic */

Perhaps 'avic implicitly disables this' ?

>  u64 rsvd3:   24;
>  } fields;
>  } vintr_t;
> @@ -394,7 +395,8 @@ typedef union __packed
>  uint32_t cr2: 1;
>  /* debugctlmsr, last{branch,int}{to,from}ip */
>  uint32_t lbr: 1;
> -uint32_t resv: 21;
> +uint32_t avic: 1;
> +uint32_t resv: 20;
>  } fields;
>  } vmcbcleanbits_t;
>  
> @@ -428,7 +430,8 @@ struct __packed vmcb_struct {
>  u64 exitinfo2;  /* offset 0x80 */
>  eventinj_t  exitintinfo;/* offset 0x88 */
>  u64 _np_enable; /* offset 0x90 - cleanbit 4 */
> -u64 res08[2];
> +u64 avic_vapic_bar; /* offset 0x98 */
> +u64 res08;  /* offset 0xA0 */
>  eventinj_t  eventinj;   /* offset 0xA8 */
>  u64 _h_cr3; /* offset 0xB0 - cleanbit 4 */
>  lbrctrl_t lbr_control;  /* offset 0xB8 */
> @@ -437,7 +440,11 @@ struct __packed vmcb_struct {
>  u64 nextrip;/* offset 0xC8 */
>  u8  guest_ins_len;  /* offset 0xD0 */
>  u8  guest_ins[15];  /* offset 0xD1 */
> -u64 res10a[100];/* offset 0xE0 pad to save area */
> +u64 avic_bk_pg_pa;  /* offset 0xE0 */
> +u64 res09a; /* offset 0xE8 */
> +u64 avic_log_apic_id;   /* offset 0xF0 */
> +u64 avic_phy_apic_id;   /* offset 0xF8 */
> +u64 res09b[96]; /* offset 0x100 pad to save area */
>  

Otherwise:

Reviewed-by: Konrad Rzeszutek Wilk 

>  svm_segment_register_t es;  /* offset 1024 - cleanbit 8 */
>  svm_segment_register_t cs;  /* cleanbit 8 */
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH 3/9] x86/HVM: Call vlapic_destroy after vcpu_destroy

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:42AM -0500, Suravee Suthikulpanit wrote:
> Since vlapic_init() is called before vcpu_initialise().
> We should also follow the same order here.
> 
> Signed-off-by: Suravee Suthikulpanit 

Reviewed-by: Konrad Rzeszutek Wilk 

But it would also be good to CC the Intel VMX maintainers in case they
spot something in vmx_vcpu_destroy.

> ---
>  xen/arch/x86/hvm/hvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 7bad845..fb5bf6c 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -1606,10 +1606,10 @@ void hvm_vcpu_destroy(struct vcpu *v)
>  tasklet_kill(>arch.hvm_vcpu.assert_evtchn_irq_tasklet);
>  hvm_vcpu_cacheattr_destroy(v);
>  
> +hvm_funcs.vcpu_destroy(v);
> +
>  if ( is_hvm_vcpu(v) )
>  vlapic_destroy(v);
> -
> -hvm_funcs.vcpu_destroy(v);
>  }
>  
>  void hvm_vcpu_down(struct vcpu *v)
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [RFC PATCH 2/9] x86/vLAPIC: Declare vlapic_read_aligned() and vlapic_reg_write() as non-static

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:41AM -0500, Suravee Suthikulpanit wrote:
> Expose vlapic_read_aligned and vlapic_reg_write() to be used by AVIC.
> 
> Signed-off-by: Suravee Suthikulpanit 

Reviewed-by: Konrad Rzeszutek Wilk 

.. this was a hard patch to review :-)
> ---
>  xen/arch/x86/hvm/vlapic.c| 5 ++---
>  xen/include/asm-x86/hvm/vlapic.h | 4 
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
> index 1d5d287..0f52067 100644
> --- a/xen/arch/x86/hvm/vlapic.c
> +++ b/xen/arch/x86/hvm/vlapic.c
> @@ -562,7 +562,7 @@ static void vlapic_set_tdcr(struct vlapic *vlapic, 
> unsigned int val)
>  "timer_divisor: %d", vlapic->hw.timer_divisor);
>  }
>  
> -static uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int 
> offset)
> +uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset)
>  {
>  switch ( offset )
>  {
> @@ -680,8 +680,7 @@ static void vlapic_tdt_pt_cb(struct vcpu *v, void *data)
>  vcpu_vlapic(v)->hw.tdt_msr = 0;
>  }
>  
> -static void vlapic_reg_write(struct vcpu *v,
> - unsigned int offset, uint32_t val)
> +void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val)
>  {
>  struct vlapic *vlapic = vcpu_vlapic(v);
>  
> diff --git a/xen/include/asm-x86/hvm/vlapic.h 
> b/xen/include/asm-x86/hvm/vlapic.h
> index 4656293..48ab3a6 100644
> --- a/xen/include/asm-x86/hvm/vlapic.h
> +++ b/xen/include/asm-x86/hvm/vlapic.h
> @@ -132,6 +132,10 @@ void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, 
> uint32_t icr_high);
>  
>  int vlapic_apicv_write(struct vcpu *v, unsigned int offset);
>  
> +void vlapic_reg_write(struct vcpu *v, unsigned int offset, uint32_t val);
> +
> +uint32_t vlapic_read_aligned(struct vlapic *vlapic, unsigned int offset);
> +
>  struct vlapic *vlapic_lowest_prio(
>  struct domain *d, const struct vlapic *source,
>  int short_hand, uint32_t dest, bool_t dest_mode);
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

[Stefano Stabellini]

On Wed, 12 Oct 2016, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 02:47:18PM +0100, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote:
> > > On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> > > > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > > > > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> > > > > >  wrote:
> > > > > > > From: "Edgar E. Iglesias" 
> > > > > > >
> > > > > > > Disable the Cortex-a53-edac. Xen currently does not yet
> > > > > > > handle reads/writes to the implementation defined CPUMERRSR
> > > > > > > register.
> > > > > > >
> > > > > > > Signed-off-by: Edgar E. Iglesias 
> > > > > > 
> > > > > > This solution looks fine to me and everything boots on ZynqMP as
> > > > > > expected with this patch.
> > > > > > 
> > > > > > Acked-by: Alistair Francis 
> > > > > 
> > > > > Reviewed-by: Stefano Stabellini 
> > > > > 
> > > > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of
> > > > > why this change is needed. The patch just adds the troublesome
> > > > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
> > > > > device tree.
> > > > > 
> > > > 
> > > > Sure.
> > > 
> > > 
> > > Hi Wei,
> > > 
> > > Just a friendly reminder:
> > > This is still missing from master, staging and 4.8.0-rc2.
> > > 
> > 
> > I thought Stefano would do it. 
> > 
> > I will apply this shortly. Thanks for the heads-up.
> > 
> 
> Now applied.

Thanks Wei. They day I acked it, it was the day you asked not to commit,
then I forgot about it :-)

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  38ab99b26bf4298a33105ec66f3f6a3f7e05a326
baseline version:
 xen  71b8b46111219a2f83f4f9ae06ac5409744ea86e

Last test of basis   101376  2016-10-11 14:04:21 Z1 days
Testing same since   101403  2016-10-12 15:03:35 Z0 days1 attempts


People who touched revisions under test:
  Alistair Francis 
  Edgar E. Iglesias 
  Ian Jackson 
  Wei Liu 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=38ab99b26bf4298a33105ec66f3f6a3f7e05a326
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
38ab99b26bf4298a33105ec66f3f6a3f7e05a326
+ branch=xen-unstable-smoke
+ revision=38ab99b26bf4298a33105ec66f3f6a3f7e05a326
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' x38ab99b26bf4298a33105ec66f3f6a3f7e05a326 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 09:42:17AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 17:33,  wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >> >>> On 11.10.16 at 12:31,  wrote:
> >> > --- /dev/null
> >> > +++ b/xen/common/gcov/gcc_4_7.c
> >> > @@ -0,0 +1,205 @@
> >> > +/*
> >> > + *  This code provides functions to handle gcc's profiling data format
> >> > + *  introduced with gcc 4.7.
> >> > + *
> >> > + *  This file is based heavily on gcc_3_4.c file.
> >> > + *
> >> > + *  For a better understanding, refer to gcc source:
> >> > + *  gcc/gcov-io.h
> >> > + *  libgcc/libgcov.c
> >> > + *
> >> > + *  Uses gcc-internal data definitions.
> >> > + *
> >> > + *  Imported from Linux and modified for Xen by
> >> > + *Wei Liu 
> >> > + */
> >> > +
> >> > +#include 
> >> > +
> >> > +#include "gcov.h"
> >> > +
> >> > +#if GCC_VERSION < 40700
> >> > +#error "Wrong version of GCC used to compile gcov"
> >> > +#endif
> >> > +
> >> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> >> > +#define GCOV_COUNTERS   10
> >> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> >> > +#define GCOV_COUNTERS   9
> >> > +#else
> >> > +#define GCOV_COUNTERS   8
> >> > +#endif
> >> 
> >> I'm sorry for not having pointed this out on v2 (I had noticed it,
> >> but then didn't finish analyzing the situation), but I'm afraid this
> >> together with ...
> >> 
> >> > +struct gcov_info {
> >> > +unsigned int version;
> >> > +struct gcov_info *next;
> >> > +unsigned int stamp;
> >> > +const char *filename;
> >> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> >> > +unsigned int n_functions;
> >> > +struct gcov_fn_info **functions;
> >> > +};
> >> 
> >> ... this structure's trailing fields actually getting used by the code
> >> won't work well when changing compiler versions without cleaning
> >> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> >> #define-ing their GCOV_COUNTERS and then #include-ing this
> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
> >> development variant of 5.x) would use anything different from
> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> >> normally be necessary anymore with gcc 5+.
> >> 
> > 
> > I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
> > "y" part is __GNUC_PATCHLEVEL__.
> 
> No, I didn't. From 5.x onwards the information previously carried in
> __GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
> as previously you would not normally need to look at the former,
> with newer gcc you shouldn't need to look at the latter.
> 

I can't find relevant information in GCC cpp manual.

Specifically, I look at 4.9.4 and 5.4.0 doc:

https://gcc.gnu.org/onlinedocs/gcc-4.9.4/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

The sections about __GNUC_* macros are identical, their semantics stay
the same.

What did I miss?

> > I've broken down things into several files as well as provided
> > corresponding Kconfig options:
> > 
> >  gcc_4_7_base.c: the body of what is now gcc_4_7.c, better name is
> >  welcome
> 
> Why don't you keep it gcc_4_7.c, with its counter definition being
> conditional upon the symbol not already being defined?
> 

Fixed as discussed on IRC.

Wei.

> Jan
> 

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

Re: [Xen-devel] [RFC PATCH 1/9] x86/HVM: Introduce struct hvm_pi_ops

[Konrad Rzeszutek Wilk]

On Mon, Sep 19, 2016 at 12:52:40AM -0500, Suravee Suthikulpanit wrote:
> The current function pointers for managing hvm posted interrupt
> can be used also by SVM AVIC. Therefore, this patch introduces the
> struct hvm_pi_ops in the struct hvm_domain to hold them.
> 
> Signed-off-by: Suravee Suthikulpanit 

You seemed to have forgotten to CC the VMX maintainers:

INTEL(R) VT FOR X86 (VT-X)  
   
M:  Jun Nakajima    
   
M:  Kevin Tian    
   
S:  Supported   
?

Regardlesss of that, Reviewed-by: Konrad Rzeszutek Wilk 
> ---
>  xen/arch/x86/hvm/vmx/vmx.c | 32 +--
>  xen/include/asm-x86/hvm/domain.h   | 63 
> ++
>  xen/include/asm-x86/hvm/hvm.h  |  4 +--
>  xen/include/asm-x86/hvm/vmx/vmcs.h | 59 ---
>  4 files changed, 81 insertions(+), 77 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
> index 2759e6f..8620697 100644
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -204,12 +204,12 @@ void vmx_pi_hooks_assign(struct domain *d)
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
> -ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
> +ASSERT(!d->arch.hvm_domain.pi_ops.vcpu_block);
>  
> -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> -d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
> -d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> -d->arch.hvm_domain.vmx.pi_do_resume = vmx_pi_do_resume;
> +d->arch.hvm_domain.pi_ops.vcpu_block = vmx_vcpu_block;
> +d->arch.hvm_domain.pi_ops.pi_switch_from = vmx_pi_switch_from;
> +d->arch.hvm_domain.pi_ops.pi_switch_to = vmx_pi_switch_to;
> +d->arch.hvm_domain.pi_ops.pi_do_resume = vmx_pi_do_resume;
>  }
>  
>  /* This function is called when pcidevs_lock is held */
> @@ -218,12 +218,12 @@ void vmx_pi_hooks_deassign(struct domain *d)
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
> -ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
> +ASSERT(d->arch.hvm_domain.pi_ops.vcpu_block);
>  
> -d->arch.hvm_domain.vmx.vcpu_block = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
> -d->arch.hvm_domain.vmx.pi_do_resume = NULL;
> +d->arch.hvm_domain.pi_ops.vcpu_block = NULL;
> +d->arch.hvm_domain.pi_ops.pi_switch_from = NULL;
> +d->arch.hvm_domain.pi_ops.pi_switch_to = NULL;
> +d->arch.hvm_domain.pi_ops.pi_do_resume = NULL;
>  }
>  
>  static int vmx_domain_initialise(struct domain *d)
> @@ -901,8 +901,8 @@ static void vmx_ctxt_switch_from(struct vcpu *v)
>  vmx_restore_host_msrs();
>  vmx_save_dr(v);
>  
> -if ( v->domain->arch.hvm_domain.vmx.pi_switch_from )
> -v->domain->arch.hvm_domain.vmx.pi_switch_from(v);
> +if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_from )
> +v->domain->arch.hvm_domain.pi_ops.pi_switch_from(v);
>  }
>  
>  static void vmx_ctxt_switch_to(struct vcpu *v)
> @@ -916,8 +916,8 @@ static void vmx_ctxt_switch_to(struct vcpu *v)
>  vmx_restore_guest_msrs(v);
>  vmx_restore_dr(v);
>  
> -if ( v->domain->arch.hvm_domain.vmx.pi_switch_to )
> -v->domain->arch.hvm_domain.vmx.pi_switch_to(v);
> +if ( v->domain->arch.hvm_domain.pi_ops.pi_switch_to )
> +v->domain->arch.hvm_domain.pi_ops.pi_switch_to(v);
>  }
>  
>  
> @@ -3914,8 +3914,8 @@ void vmx_vmenter_helper(const struct cpu_user_regs 
> *regs)
>  struct hvm_vcpu_asid *p_asid;
>  bool_t need_flush;
>  
> -if ( curr->domain->arch.hvm_domain.vmx.pi_do_resume )
> -curr->domain->arch.hvm_domain.vmx.pi_do_resume(curr);
> +if ( curr->domain->arch.hvm_domain.pi_ops.pi_do_resume )
> +curr->domain->arch.hvm_domain.pi_ops.pi_do_resume(curr);
>  
>  if ( !cpu_has_vmx_vpid )
>  goto out;
> diff --git a/xen/include/asm-x86/hvm/domain.h 
> b/xen/include/asm-x86/hvm/domain.h
> index f34d784..779927b 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -72,6 +72,67 @@ struct hvm_ioreq_server {
>  bool_t bufioreq_atomic;
>  };
>  
> +struct hvm_pi_ops {
> +/*
> + * To handle posted interrupts correctly, we need to set the following
> + * state:
> + *
> + * * The PI notification vector (NV)
> + * * The PI notification destination processor (NDST)
> + * * The PI "suppress notification" bit (SN)
> + * * The vcpu pi "blocked" list
> + *
> + * If a VM is currently running, we want the PI delivered to the guest 
> vcpu
> + * on the proper pcpu (NDST = v->processor, SN clear).
> + *
> + * If 

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 04:17:57PM +0200, Martin Pohlack wrote:
> On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:
> > On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> > > > > > On 12.10.16 at 15:23,  wrote:
> > > > >  And then - how is all of this supposed to be working in conjucntion
> > > > > with live patching, where the patch may have been created by yet
> > > > > another compiler version?
> > > > 
> > > > Uh, I hope one does not create a livepatch patch with another compiler
> > > > version!
> > > > 
> > > > Let me put on the TODO to make livepatch-build-tools check gcc against
> > > > compile.h so that one does not try this.
> > > 
> > > What's wrong with mixing compiler versions in general?
> > 
> > Besides scaring me?
> > 
> > The one issue we had encountered was with compilers generating random named
> > symbols for the switch tables. Those end up being called "CSWTCH.XYZ"
> > where the XYZ depends on the position of the moon along with how many
> > goats you have sacrificied to the altar of GCC gods.
> > 
> > Older compilers don't neccessarily do it, newer ones do, and every time
> > you build an livepatch the naming is different. Frustrating.
> > 
> > It maybe that newer versions of GCC are more predictable about this
> > naming.
> > 
> > Maybe Martin can share some of his experience? CC-ing him.
> 
> There are a couple of naming conventions for internal symbols and also
> static symbols where you basically have to pray that gcc implementation does
> not change.  Interestingly, icc has some conventions that make those symbol
> names a bit more stable.
> 
> The tricky thing is matchmaking between the existing build and the new build
> to construct the binary diff and to match up symbols for which you want to
> provide replacement code.
> 
> We use a reproducible build environment to construct hotpatches for an
> existing build in the absolutely same environment (gcc version, lib
> versions, gas version, binutils etc.).  This sidesteps most of the problems.

I think the matchmaking process does not solve per say some tricky CSWTCH 
issues.

If a patch mucks with a switch statement (e.g. add a new case) we are pretty 
much
guaranteed to get in trouble. And really a change in any control structure may 
cause
gcc to take different code path, causing it to renumber CSWTCH. Or worst, 
renumber
it to the one that the hypervisor is using for some other switch statements.
I think the size of the symbol vs the one in the hypervisor is different
so one can check for this. Bad things happen if it is the same size, but bcmp
can come in handy there.

Are there any ways to make GCC be predictable or some patches
to make GCC be less random. Perhaps instead of XYZ it would use the function 
name..

P.S.
GCC scares me because the code comes in these big patches with not much 
explanation
on how it suppose to work. It probably is a piece of cake for folks who
have been marinating in compilers but for a newbie like me it is hardcore
black magic.

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Dan Williams]

On Wed, Oct 12, 2016 at 9:01 AM, Jan Beulich  wrote:
 On 12.10.16 at 17:42,  wrote:
>> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
>> On 12.10.16 at 16:58,  wrote:
 On 10/12/16 05:32 -0600, Jan Beulich wrote:
 On 12.10.16 at 12:33,  wrote:
>> The layout is shown as the following diagram.
>>
>> +---+---+---+--+--+
>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
>> |  by kernel|   Table   | Block | for Xen  |  |
>> +---+---+---+--+--+
>> \_ ___/
>>   V
>>  /dev/pmem0
>
>I have to admit that I dislike this, for not being OS-agnostic.
>Neither should there be any Xen-specific region, nor should the
>"whatever used by kernel" one be restricted to just Linux. What
>I could see is an OS-reserved area ahead of the partition table,
>the exact usage of which depends on which OS is currently
>running (and in the Xen case this might be both Xen _and_ the
>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>running under Xen, the Dom0 may not have a need for as much
>control data as it has when running on bare hardware, for it
>controlling less (if any) of the actual memory ranges when Xen
>is present.
>

 Isn't this OS-reserved area still not OS-agnostic, as it requires OS
 to know where the reserved area is?  Or do you mean it's not if it's
 defined by a protocol that is accepted by all OSes?
>>>
>>> The latter - we clearly won't get away without some agreement on
>>> where to retrieve position and size of this area. I was simply
>>> assuming that such a protocol already exists.
>>>
>>
>> No, we should not mix the struct page reservation that the Dom0 kernel
>> may actively use with the Xen reservation that the Dom0 kernel does
>> not consume.  Explain again what is wrong with the partition approach?
>
> Not sure what was unclear in my previous reply. I don't think there
> should be apriori knowledge of whether Xen is (going to be) used on
> a system, and even if it gets used, but just occasionally, it would
> (apart from the abstract considerations already given) be a waste
> of resources to set something aside that could be used for other
> purposes while Xen is not running. Static partitioning should only be
> needed for persistent data.
>

The reservation needs to be persistent / static even if the data is
volatile, as is the case with struct page, because we can't have the
size of the device change depending on use.  So, from the aspect of
wasting space while Xen is not in use, both partitions and the
intrinsic reservation approach suffer the same problem. Setting that
aside I don't want to mix 2 different use cases into the same
reservation.

The kernel needs to know about the struct page reservation because it
needs to manage the lifetime of page references vs the lifetime of the
device.  It does not have the same relationship with a Xen reservation
which is why I'm proposing they be managed separately.

Note that Toshi and Mike added DM for DAX.  This enabling ends up
writing DM metadata on the device without adding new reservation
mechanisms to the nvdimm core.  I'm struggling to see how the Xen use
case is materially different DM.  In the end it's an application
specific metadata space.

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

Re: [Xen-devel] [DOC v6] PV Calls protocol design

[Konrad Rzeszutek Wilk]

> > > ### Data ring
> > > 
> > > Data rings are used for sending and receiving data over a connected 
> > > socket. They
> > > are created upon a successful **accept** or **connect** command.
> > > 
> > > A data ring is composed of two pieces: the interface and the **in** and 
> > > **out**
> > > buffers. The interface, represented by `struct pvcalls_ring_intf` is 
> > > shared
> > > first and resides on the page whose grant reference is passed by 
> > > **accept** and
> > > **connect** as parameter. `struct pvcalls_ring_intf` contains the list of 
> > > grant
> > > references which constitute the **in** and **out** data buffers.
> > > 
> > >  Data ring interface
> > > 
> > > struct pvcalls_data_intf {
> > >   PVCALLS_RING_IDX in_cons, in_prod;
> > 
> > Do you want to add some spacing between them so that you don't
> > use the same cacheline?
> 
> Let me get this straight. in_cons and in_prod should be on the same
> cacheline.  Similarly out_cons and out_prod should be on the same
> cacheline, but on a different cacheline compared to in_cons and in_prod.
> 
> So I should add padding between the two pairs of indices. Something
> like:
> uint8_t pad[cache_line_size - 8];
> 
> Where cache_line_size is usually 64 bytes. So this would be:
> 
> uint8_t pad[56];
> 
> Is that right?

Sounds right. But pahole will for sure confirm :-) I was too lazy to copy this 
in code and see
what it gives you.
> 
> 
> > >   PVCALLS_RING_IDX out_cons, out_prod;
> > >   int32_t in_error, out_error;
> > > 
> > >   uint32_t ring_order;
> > >   grant_ref_t ref[];
> > > };
> > 
> > That does not look like it would be to the power of two? Perhaps
> > some padding?
> 
> I don't understand the suggestion about the padding here.

You pad[56] takes care of the issue I had.

..snipp.
> > > The binary layout of `struct pvcalls_data_intf` follows:
> > > 
> > > 0 4 8 12162024
> > > 28
> > > 
> > > +-+-+-+-+-+-+--+
> > > | in_cons | in_prod |out_cons |out_prod |in_error 
> > > |out_error|ring_order|
> > > 
> > > +-+-+-+-+-+-+--+
> > > 
> > > 283236404092 4096
> > > +-+-+-+//---+-+
> > > |  ref[0] |  ref[1] |  ref[2] | |  ref[N] |
> > > +-+-+-+//---+-+
> > 
> > Perhaps you can say:
> > 
> > **N.B** For one page, the N would be 2034.
> 
> I can do that but actually N would be (4096-28)/4 = 1017. Ring refs are
> 4 bytes each.

I somehow had uint16_t on my mind! Thanks for checking me!

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

Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Jan Beulich]

>>> On 12.10.16 at 17:35,  wrote:
> On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57,  wrote:
>> > +static void __init acpi_zap_table_signature(char *name)
>> > +{
>> > +struct acpi_table_header *table;
>> > +acpi_status status;
>> > +union {
>> > +char str[ACPI_NAME_SIZE];
>> > +uint32_t bits;
>> > +} signature;
>> > +char tmp;
>> > +int i;
>> > +
>> > +status = acpi_get_table(name, 0, );
>> > +if ( ACPI_SUCCESS(status) )
>> > +{
>> > +memcpy([0], >signature[0], ACPI_NAME_SIZE);
>> > +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
>> > +{
>> > +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
>> > +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
>> > +signature.str[i] = tmp;
>> > +}
>> > +write_atomic((uint32_t*)>signature[0], signature.bits);
>> > +}
>> > +}
>> 
>> Together with moving MADT elsewhere we should also move
>> XSDT/RSDT, at which point we can simply avoid copying the
>> pointers for tables we don't want Dom0 to see (and down the
>> road we also have the option of adding tables).
>> 
>> The downside to both approaches is that this once again is a
>> black-listing model, i.e. new structure types we may need to
>> also suppress will remain visible to Dom0 until a patched
>> hypervisor would become available.
> 
> Maybe we could do whitelisting instead? I can see that at least the 
> following tables should be available to Dom0 if present, but TBH, it's hard 
> to tell:

Taking an abstract perspective I agree with Andrew that we should
be whitelisting here. However, as you already see from the list you
provided (which afaict is far from complete wrt ACPI 6.1), this may
become cumbersome already initially, not to speak of down the road.

>> > +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
>> > +{
>> > +pfn = PFN_DOWN(acpi_gbl_root_table_list.tables[i].address);
>> > +nr_pages = DIV_ROUND_UP(acpi_gbl_root_table_list.tables[i].length,
>> > +PAGE_SIZE);
>> > +rc = modify_mmio_11(d, pfn, nr_pages, true);
>> > +if ( rc )
>> > +{
>> > +printk(
>> > +"Failed to map ACPI region %#lx - %#lx into Dom0 memory 
>> > map\n",
>> > +   pfn, pfn + nr_pages);
>> > +return rc;
>> > +}
>> > +}
>> > +
>> > +/*
>> > + * Special treatment for memory < 1MB:
>> > + *  - Copy the data in e820 regions marked as RAM (BDA, EBDA...).
>> 
>> Copy? What if some of it needs to get modified to interact with
>> firmware? I think you'd be better off mapping everything Xen
>> doesn't use into Dom0, and only mapping fresh RAM pages
>> over regions Xen does use (namely the trampoline).
> 
> Hm, that was my first approach (mapping the whole first MB into Dom0), but 
> sadly it doesn't seem to work because FreeBSD at least places the AP boot 
> trampoline there, and since APs are launched in 16b mode, the emulator 
> cannot handle executing memory from MMIO regions and crashes the domain. 
> That's why I had to map and copy data from RAM regions below 1MB. The BDA 
> it's all static data AFAICT, and the EBDA should reside in a reserved 
> region (or at least does on my systems).

I'm afraid there are systems where the EBDA is not marked reserved.
But maybe there are no current (64-bit capable) ones of that sort.

> Might it be possible to solve this by identity mapping the first 1MB, and 
> marking the RAM regions there as p2m_ram_rw? Or would that create even 
> further problems?

Hmm, not sure - the range below 1Mb is marked as MMIO in
frame_table[], so there would be a (benign?) conflict at least there.

>> > +io_apic = (struct acpi_madt_io_apic *)(madt + 1);
>> > +io_apic->header.type = ACPI_MADT_TYPE_IO_APIC;
>> > +io_apic->header.length = sizeof(*io_apic);
>> > +io_apic->id = 1;
>> > +io_apic->address = VIOAPIC_DEFAULT_BASE_ADDRESS;
>> 
>> I think you need to make as many IO-APICs available to Dom0 as
>> there are hardware ones.
> 
> Right, I've been wondering about this, and then I need to expand the IO APIC 
> emulation code so that Xen is able to emulate two IO-APICs.
> 
> Can I ask why do you think this is needed? If the number of pins in the 
> multiple IO APIC case doesn't exceed 48 (which is what the emulated IO APIC 
> provides), shouldn't this be enough?

The number of pins easily can be larger. And I think the mapping
code would end up simpler if there was a 1:1 relationship between
physical and virtual IO-APICs. I've just not checked one of my
larger (but older) systems - it has 5 IO-APICs with a total of 120 pins.

Jan

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

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

[Jan Beulich]

>>> On 12.10.16 at 16:30,  wrote:

> 
> On 10/12/2016 9:19 PM, Jan Beulich wrote:
> On 12.10.16 at 09:58,  wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
>>>  static void __serial_rx(char c, struct cpu_user_regs *regs)
>>>  {
>>>  if ( xen_rx )
>>> -return handle_keypress(c, regs);
>>> +return handle_keypress(c, regs, true);
>>
>> I think it would be nice to pass true here only when in polling mode,
>> unless you know or can deduce that the a similar problem also exists
>> in IRQ mode. Perhaps you could simply move the !in_irq() here?
> 
> That's a good idea. Thanks.
> 
>>(Of course the new function parameter would then want to be renamed.)
> 
> Since the issue happens when handle_keypress() runs in a timer handler,
> how about to name new parameter "intimer"? __serial_rx() is called in a 
> timer handler or interrupt handler. Or do you have other suggestion?

I think "intimer" can be confusing (to be mixed up with timer interrupt).
How about "force_tasklet"?

Jan


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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 12.10.16 at 17:42,  wrote:
> On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
> On 12.10.16 at 16:58,  wrote:
>>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>>> On 12.10.16 at 12:33,  wrote:
> The layout is shown as the following diagram.
>
> +---+---+---+--+--+
> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
> |  by kernel|   Table   | Block | for Xen  |  |
> +---+---+---+--+--+
> \_ ___/
>   V
>  /dev/pmem0

I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.

>>>
>>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
>>> to know where the reserved area is?  Or do you mean it's not if it's
>>> defined by a protocol that is accepted by all OSes?
>>
>> The latter - we clearly won't get away without some agreement on
>> where to retrieve position and size of this area. I was simply
>> assuming that such a protocol already exists.
>>
> 
> No, we should not mix the struct page reservation that the Dom0 kernel
> may actively use with the Xen reservation that the Dom0 kernel does
> not consume.  Explain again what is wrong with the partition approach?

Not sure what was unclear in my previous reply. I don't think there
should be apriori knowledge of whether Xen is (going to be) used on
a system, and even if it gets used, but just occasionally, it would
(apart from the abstract considerations already given) be a waste
of resources to set something aside that could be used for other
purposes while Xen is not running. Static partitioning should only be
needed for persistent data.

Jan


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

Re: [Xen-devel] [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne]

On Thu, Oct 06, 2016 at 09:40:50AM -0600, Jan Beulich wrote:
> >>> On 27.09.16 at 17:57,  wrote:
> > FWIW, I think that the current approach that I've used in order to craft the
> > MADT is not the best one, IMHO it would be better to place the MADT at the
> > end of the E820_ACPI region (expanding it's size one page), and modify the
> > XSDT/RSDT in order to point to it, that way we avoid shadowing any other
> > ACPI data that might be at the same page as the native MADT (and that needs
> > to be modified by Dom0).
> 
> I agree with the idea of placing MADT elsewhere, but I don't think you
> can rely on E820_ACPI to have room to grow into right after its end.

Right, I think picking some memory from a RAM region and marking it as 
E820_ACPI is the best approach.

> > @@ -50,6 +53,8 @@ static long __initdata dom0_max_nrpages = LONG_MAX;
> >  #define HVM_VM86_TSS_SIZE   128
> >  
> >  static unsigned int __initdata hvm_mem_stats[MAX_ORDER + 1];
> > +static unsigned int __initdata acpi_intr_overrrides = 0;
> > +static struct acpi_madt_interrupt_override __initdata *intsrcovr = NULL;
> 
> Pointless initializers.

Removed.

> > +static void __init acpi_zap_table_signature(char *name)
> > +{
> > +struct acpi_table_header *table;
> > +acpi_status status;
> > +union {
> > +char str[ACPI_NAME_SIZE];
> > +uint32_t bits;
> > +} signature;
> > +char tmp;
> > +int i;
> > +
> > +status = acpi_get_table(name, 0, );
> > +if ( ACPI_SUCCESS(status) )
> > +{
> > +memcpy([0], >signature[0], ACPI_NAME_SIZE);
> > +for ( i = 0; i < ACPI_NAME_SIZE / 2; i++ )
> > +{
> > +tmp = signature.str[ACPI_NAME_SIZE - i - 1];
> > +signature.str[ACPI_NAME_SIZE - i - 1] = signature.str[i];
> > +signature.str[i] = tmp;
> > +}
> > +write_atomic((uint32_t*)>signature[0], signature.bits);
> > +}
> > +}
> 
> Together with moving MADT elsewhere we should also move
> XSDT/RSDT, at which point we can simply avoid copying the
> pointers for tables we don't want Dom0 to see (and down the
> road we also have the option of adding tables).
> 
> The downside to both approaches is that this once again is a
> black-listing model, i.e. new structure types we may need to
> also suppress will remain visible to Dom0 until a patched
> hypervisor would become available.

Maybe we could do whitelisting instead? I can see that at least the 
following tables should be available to Dom0 if present, but TBH, it's hard 
to tell:

MADT, DSDT, FADT, SSDT, FACS, SBST, NFIT, MCFG, TCPA. Then ECDT, CPEP and 
RASF also seem fine to make available to Dom0, but I'm dubious.

But I agree that crafting a custom XSDT/RSDT is the best option here.
 
> > +   pfn, pfn + nr_pages);
> > +return rc;
> > +}
> > +}
> > +/*
> > + * Since most memory maps provided by hardware are wrong, make sure 
> > each
> > + * top-level table is properly mapped into Dom0.
> > + */
> 
> Please be more specific here - wrong in which way? Not all ACPI tables
> living in one of the two E820 type regions? But see also below.
> 
> In any event you need to be more careful here: Mapping ordinary RAM
> 1:1 into Dom0 can't end well. Also, once working with a cloned XSDT you
> won't need to cover tables here which have got hidden from Dom0.

I've found systems where some ACPI tables reside in memory holes or reserved 
regions. I don't think I've found a system where an ACPI table would reside 
in a RAM region, but I agree that it's worth adding a check here to make 
sure.

> > +for( i = 0; i < acpi_gbl_root_table_list.count; i++ )
> > +{
> > +pfn = PFN_DOWN(acpi_gbl_root_table_list.tables[i].address);
> > +nr_pages = DIV_ROUND_UP(acpi_gbl_root_table_list.tables[i].length,
> > +PAGE_SIZE);
> > +rc = modify_mmio_11(d, pfn, nr_pages, true);
> > +if ( rc )
> > +{
> > +printk(
> > +"Failed to map ACPI region %#lx - %#lx into Dom0 memory 
> > map\n",
> > +   pfn, pfn + nr_pages);
> > +return rc;
> > +}
> > +}
> > +
> > +/*
> > + * Special treatment for memory < 1MB:
> > + *  - Copy the data in e820 regions marked as RAM (BDA, EBDA...).
> 
> Copy? What if some of it needs to get modified to interact with
> firmware? I think you'd be better off mapping everything Xen
> doesn't use into Dom0, and only mapping fresh RAM pages
> over regions Xen does use (namely the trampoline).

Hm, that was my first approach (mapping the whole first MB into Dom0), but 
sadly it doesn't seem to work because FreeBSD at least places the AP boot 
trampoline there, and since APs are launched in 16b mode, the emulator 
cannot handle executing memory from MMIO regions and crashes the domain. 
That's why I had to map and copy data from RAM regions below 1MB. The BDA 
it's all static 

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 17:33,  wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> >>> On 11.10.16 at 12:31,  wrote:
>> > --- /dev/null
>> > +++ b/xen/common/gcov/gcc_4_7.c
>> > @@ -0,0 +1,205 @@
>> > +/*
>> > + *  This code provides functions to handle gcc's profiling data format
>> > + *  introduced with gcc 4.7.
>> > + *
>> > + *  This file is based heavily on gcc_3_4.c file.
>> > + *
>> > + *  For a better understanding, refer to gcc source:
>> > + *  gcc/gcov-io.h
>> > + *  libgcc/libgcov.c
>> > + *
>> > + *  Uses gcc-internal data definitions.
>> > + *
>> > + *  Imported from Linux and modified for Xen by
>> > + *Wei Liu 
>> > + */
>> > +
>> > +#include 
>> > +
>> > +#include "gcov.h"
>> > +
>> > +#if GCC_VERSION < 40700
>> > +#error "Wrong version of GCC used to compile gcov"
>> > +#endif
>> > +
>> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>> > +#define GCOV_COUNTERS   10
>> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>> > +#define GCOV_COUNTERS   9
>> > +#else
>> > +#define GCOV_COUNTERS   8
>> > +#endif
>> 
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>> 
>> > +struct gcov_info {
>> > +unsigned int version;
>> > +struct gcov_info *next;
>> > +unsigned int stamp;
>> > +const char *filename;
>> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>> > +unsigned int n_functions;
>> > +struct gcov_fn_info **functions;
>> > +};
>> 
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>> 
> 
> I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
> "y" part is __GNUC_PATCHLEVEL__.

No, I didn't. From 5.x onwards the information previously carried in
__GNUC_PATCHLEVEL__ is now in __GNUC_MINOR__. And as much
as previously you would not normally need to look at the former,
with newer gcc you shouldn't need to look at the latter.

> I've broken down things into several files as well as provided
> corresponding Kconfig options:
> 
>  gcc_4_7_base.c: the body of what is now gcc_4_7.c, better name is
>  welcome

Why don't you keep it gcc_4_7.c, with its counter definition being
conditional upon the symbol not already being defined?

Jan


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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Dan Williams]

On Wed, Oct 12, 2016 at 8:39 AM, Jan Beulich  wrote:
 On 12.10.16 at 16:58,  wrote:
>> On 10/12/16 05:32 -0600, Jan Beulich wrote:
>> On 12.10.16 at 12:33,  wrote:
 The layout is shown as the following diagram.

 +---+---+---+--+--+
 | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
 |  by kernel|   Table   | Block | for Xen  |  |
 +---+---+---+--+--+
 \_ ___/
   V
  /dev/pmem0
>>>
>>>I have to admit that I dislike this, for not being OS-agnostic.
>>>Neither should there be any Xen-specific region, nor should the
>>>"whatever used by kernel" one be restricted to just Linux. What
>>>I could see is an OS-reserved area ahead of the partition table,
>>>the exact usage of which depends on which OS is currently
>>>running (and in the Xen case this might be both Xen _and_ the
>>>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>>>running under Xen, the Dom0 may not have a need for as much
>>>control data as it has when running on bare hardware, for it
>>>controlling less (if any) of the actual memory ranges when Xen
>>>is present.
>>>
>>
>> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
>> to know where the reserved area is?  Or do you mean it's not if it's
>> defined by a protocol that is accepted by all OSes?
>
> The latter - we clearly won't get away without some agreement on
> where to retrieve position and size of this area. I was simply
> assuming that such a protocol already exists.
>

No, we should not mix the struct page reservation that the Dom0 kernel
may actively use with the Xen reservation that the Dom0 kernel does
not consume.  Explain again what is wrong with the partition approach?

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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Jan Beulich]

>>> On 12.10.16 at 16:58,  wrote:
> On 10/12/16 05:32 -0600, Jan Beulich wrote:
> On 12.10.16 at 12:33,  wrote:
>>> The layout is shown as the following diagram.
>>>
>>> +---+---+---+--+--+
>>> | whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
>>> |  by kernel|   Table   | Block | for Xen  |  |
>>> +---+---+---+--+--+
>>> \_ ___/
>>>   V
>>>  /dev/pmem0
>>
>>I have to admit that I dislike this, for not being OS-agnostic.
>>Neither should there be any Xen-specific region, nor should the
>>"whatever used by kernel" one be restricted to just Linux. What
>>I could see is an OS-reserved area ahead of the partition table,
>>the exact usage of which depends on which OS is currently
>>running (and in the Xen case this might be both Xen _and_ the
>>Dom0 kernel, arbitrated by a tbd protocol). After all, when
>>running under Xen, the Dom0 may not have a need for as much
>>control data as it has when running on bare hardware, for it
>>controlling less (if any) of the actual memory ranges when Xen
>>is present.
>>
> 
> Isn't this OS-reserved area still not OS-agnostic, as it requires OS
> to know where the reserved area is?  Or do you mean it's not if it's
> defined by a protocol that is accepted by all OSes?

The latter - we clearly won't get away without some agreement on
where to retrieve position and size of this area. I was simply
assuming that such a protocol already exists.

Jan


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

[Xen-devel] [ovmf baseline-only test] 67867: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 67867 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67867/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
baseline version:
 ovmf 4b8234d05400a852a42688fea14acc7ddeeebad4

Last test of basis67864  2016-10-12 02:19:44 Z0 days
Testing same since67867  2016-10-12 08:19:10 Z0 days1 attempts


People who touched revisions under test:
  Jiewen Yao 
  Michael D Kinney 

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.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

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

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


Push not applicable.


commit 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2
Author: Jiewen Yao 
Date:   Sat Oct 8 09:55:59 2016 +0800

FatPkg/FatPei: Use PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name.
The previous name - FvMain.Fv is hardcoded in FatPei.
It does not make sense to force the name.

Now a platform may use any recovery file name.

Tested-by: Michael D Kinney 

Cc: Ruiyu Ni 
Cc: Feng Tian 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Feng Tian 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Michael D Kinney 

commit 9753360756bc9d28f3b1cc59624e0b4fe3618870
Author: Jiewen Yao 
Date:   Sat Oct 8 09:55:20 2016 +0800

MdeModulePkg/CdExpressPei: Use PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name.
The previous name - FvMain.Fv is hardcoded in CdExpressPei.
It does not make sense to force the name.

Now a platform may use any recovery file name.

Cc: Feng Tian 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Feng Tian 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Michael D Kinney 

commit 08bec91eba7cc8c8a831592137503f23e7fb8f7a
Author: Jiewen Yao 
Date:   Sat Oct 8 09:54:33 2016 +0800

MdeModulePkg/dec: Add PcdRecoveryFileName PCD.

This PCD is used to indicated the recovery file name.
The previous name - FvMain.Fv is hardcoded in FatPei and CdExpressPei.
It does not make sense to force the name.

Now a platform may use any recovery file name.

Tested-by: Michael D Kinney 

Cc: Feng Tian 
Cc: Star Zeng 
Cc: Liming Gao 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 
Reviewed-by: Feng Tian 
Reviewed-by: Ruiyu Ni 
Reviewed-by: Michael D Kinney 

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31,  wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + *  This code provides functions to handle gcc's profiling data format
> > + *  introduced with gcc 4.7.
> > + *
> > + *  This file is based heavily on gcc_3_4.c file.
> > + *
> > + *  For a better understanding, refer to gcc source:
> > + *  gcc/gcov-io.h
> > + *  libgcc/libgcov.c
> > + *
> > + *  Uses gcc-internal data definitions.
> > + *
> > + *  Imported from Linux and modified for Xen by
> > + *Wei Liu 
> > + */
> > +
> > +#include 
> > +
> > +#include "gcov.h"
> > +
> > +#if GCC_VERSION < 40700
> > +#error "Wrong version of GCC used to compile gcov"
> > +#endif
> > +
> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> > +#define GCOV_COUNTERS   10
> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> > +#define GCOV_COUNTERS   9
> > +#else
> > +#define GCOV_COUNTERS   8
> > +#endif
> 
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
> 
> > +struct gcov_info {
> > +unsigned int version;
> > +struct gcov_info *next;
> > +unsigned int stamp;
> > +const char *filename;
> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> > +unsigned int n_functions;
> > +struct gcov_fn_info **functions;
> > +};
> 
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
> 

I think you misread here: __GNUC_MINOR__ is the "x" part of 5.x.y, the
"y" part is __GNUC_PATCHLEVEL__.

I've broken down things into several files as well as provided
corresponding Kconfig options:

 gcc_4_7_base.c: the body of what is now gcc_4_7.c, better name is
 welcome
 gcc_4_7.c:  gcov format in gcc version [4.7, 4,9), nr counters 8
 gcc_4_9.c:  gcov format in gcc version [4.9, 5.1), nr counters 9
 gcc_5_1.c:  gcov format in gcc version [5.1, ...), nr counters 10

Wei.

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

Re: [Xen-devel] [PATCH] x86: xen: move cpu_up functions out of ifdef

[Boris Ostrovsky]

On 10/12/2016 11:20 AM, Arnd Bergmann wrote:
> Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
> disabled, but are still being used:
>
> arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never 
> defined
> arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never 
> defined
> arch/x86/xen/enlighten.c:143:12: warning: ‘xen_cpu_dead’ used but never 
> defined
>
> Fixes: 4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Boris Ostrovsky 


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

[Xen-devel] [PATCH] x86: xen: move cpu_up functions out of ifdef

[Arnd Bergmann]

Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
disabled, but are still being used:

arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never 
defined
arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never 
defined
arch/x86/xen/enlighten.c:143:12: warning: ‘xen_cpu_dead’ used but never defined

Fixes: 4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
Signed-off-by: Arnd Bergmann 
---
 arch/x86/xen/enlighten.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index c0fdd57da7aa..bdd855685403 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1837,6 +1837,7 @@ static void __init init_hvm_pv_info(void)
 
xen_domain_type = XEN_HVM_DOMAIN;
 }
+#endif
 
 static int xen_cpu_up_prepare(unsigned int cpu)
 {
@@ -1887,6 +1888,7 @@ static int xen_cpu_up_online(unsigned int cpu)
return 0;
 }
 
+#ifdef CONFIG_XEN_PVHVM
 #ifdef CONFIG_KEXEC_CORE
 static void xen_hvm_shutdown(void)
 {
-- 
2.9.0


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

Re: [Xen-devel] [RFC KERNEL PATCH 0/2] Add Dom0 NVDIMM support for Xen

[Haozhong Zhang]

On 10/12/16 05:32 -0600, Jan Beulich wrote:

On 12.10.16 at 12:33,  wrote:

The layout is shown as the following diagram.

+---+---+---+--+--+
| whatever used | Partition | Super | Reserved | /dev/pmem0p1 |
|  by kernel|   Table   | Block | for Xen  |  |
+---+---+---+--+--+
\_ ___/
  V
 /dev/pmem0


I have to admit that I dislike this, for not being OS-agnostic.
Neither should there be any Xen-specific region, nor should the
"whatever used by kernel" one be restricted to just Linux. What
I could see is an OS-reserved area ahead of the partition table,
the exact usage of which depends on which OS is currently
running (and in the Xen case this might be both Xen _and_ the
Dom0 kernel, arbitrated by a tbd protocol). After all, when
running under Xen, the Dom0 may not have a need for as much
control data as it has when running on bare hardware, for it
controlling less (if any) of the actual memory ranges when Xen
is present.



Isn't this OS-reserved area still not OS-agnostic, as it requires OS
to know where the reserved area is?  Or do you mean it's not if it's
defined by a protocol that is accepted by all OSes?

Let me list another two methods just coming to my mind.

1. The first method extends the usage of the super block used by
  current Linux kernel to reserve space on pmem.

  Current Linux kernel places a super block of the following
  structure near the beginning of a pmem namespace.

   struct nd_pfn_sb {
   u8 signature[PFN_SIG_LEN];
   u8 uuid[16];
   u8 parent_uuid[16];
   __le32 flags;
   __le16 version_major;
   __le16 version_minor;
   __le64 dataoff; /* relative to namespace_base + start_pad */
   __le64 npfns;
   __le32 mode;
   /* minor-version-1 additions for section alignment */
   __le32 start_pad;
   __le32 end_trunc;
   /* minor-version-2 record the base alignment of the mapping */
   __le32 align;
   u8 padding[4000];
   __le64 checksum;
   }

   Two interesting fields here are 'dataoff' and 'mode':
   - 'dataoff' indicates the offset where the data area starts,
 ie. IIUC, the part that can be accessed via /dev/pmemN or
 /dev/daxN.
   - 'mode' indicates whether Linux puts struct page for this
 namespace in the ram (= PFN_MODE_RAM) or on the device (=
 PFN_MODE_PMEM).

   Currently for Linux, only 'mode' is customizable, while 'dataoff'
   is not. If mode == PFN_MODE_RAM, no reservation for struct page is
   made on the device, and dataoff starts almost immediately after
   the super block except a small reserved area in between for other
   structures and alignment. If mode == PFN_MODE_PMEM, the size of
   the reservation is decided by kernel, i.e. 64 bytes per struct
   page.

   I propose to make the size of the reserved area customizable,
   e.g. via ioctl and ndctl.
   - If mode == PFN_MODE_PMEM and
 * if the given reserved size is large enough to hold what an OS
   (not limited to Linux) wants to put in, then the OS just
   starts use it as desired;
 * if the given reserved size is not enough, then the OS reports
   error and may take other fallback actions.
   - If mode == PFN_MODE_RAM and
 * if the reserved size is zero, then it's the current way that
   Linux uses the device;
 * if the reserved size is non-zero, I would like to reserve this
   case for hypervisor (right now, namely Xen hypervisor)
   usage. That is, the OS should not use the reserved area. For
   Xen, we could add a function in xen driver in kernel to report
   the reserved area to hypervisor.

  I guess this might be the OS-agnostic way Jan expects, but Dan may
  object to.


2. Lay another pseudo device on the block device (e.g. /dev/pmemN)
  provided by the NVDIMM driver.

  This pseudo device can reserve the size according to user's
  requirement. The reservation information can be persistently
  recorded in a super block before the reserved area.

  This pseudo device also implements another pseudo block device to
  allow the non-reserved area be accessed as a block device (we can
  even implement it as DAX-capable).

  pseudo block device
/-^---\
+--+---+---+---+
|  whatever used   | Super |  reserved by  |   |
| by NVDIMM driver | Block | pseudo device |   |
+--+---+---+---+
\_ ___/
  V
 

[Xen-devel] [PATCH] xen-netback: fix type mismatch warning

[Arnd Bergmann]

Wiht the latest rework of the xen-netback driver, we get a warning
on ARM about the types passed into min():

drivers/net/xen-netback/rx.c: In function 'xenvif_rx_next_chunk':
include/linux/kernel.h:739:16: error: comparison of distinct pointer types 
lacks a cast [-Werror]

The reason is that XEN_PAGE_SIZE is not size_t here. There
is no actual bug, and we can easily avoid the warning using the
min_t() macro instead of min().

Fixes: eb1723a29b9a ("xen-netback: refactor guest rx")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/xen-netback/rx.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/xen-netback/rx.c b/drivers/net/xen-netback/rx.c
index 8e9ade6ccf18..aeb150258c6c 100644
--- a/drivers/net/xen-netback/rx.c
+++ b/drivers/net/xen-netback/rx.c
@@ -337,9 +337,9 @@ static void xenvif_rx_next_chunk(struct xenvif_queue *queue,
frag_data += pkt->frag_offset;
frag_len -= pkt->frag_offset;
 
-   chunk_len = min(frag_len, XEN_PAGE_SIZE - offset);
-   chunk_len = min(chunk_len,
-   XEN_PAGE_SIZE - xen_offset_in_page(frag_data));
+   chunk_len = min_t(size_t, frag_len, XEN_PAGE_SIZE - offset);
+   chunk_len = min_t(size_t, chunk_len, XEN_PAGE_SIZE -
+xen_offset_in_page(frag_data));
 
pkt->frag_offset += chunk_len;
 
-- 
2.9.0


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

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

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
baseline version:
 ovmf 46cd2cb6a7ba5b1fdaff1eb18a13dc399d6a7fe2

Last test of basis   101384  2016-10-12 02:17:41 Z0 days
Testing same since   101392  2016-10-12 08:46:21 Z0 days1 attempts


People who touched revisions under test:
  Bruce Cran 
  Daniil Egranov 
  Eric Dong 
  Laszlo Ersek 
  Laszlo Ersek 
  Ruiyu Ni 
  Ryan Harkin 
  Yonghong Zhu 

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 :

+ branch=ovmf
+ revision=50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf 
50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ branch=ovmf
+ revision=50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x50d4be4f4e3d5beb2c1aa58853b92e3cc1f4cb9a = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : 

[Xen-devel] [linux-4.1 test] 101390: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   3 host-install(3)broken REGR. vs. 101004

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl  15 guest-start/debian.repeatfail  like 101004
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat   fail like 101004
 test-armhf-armhf-xl-vhd   9 debian-di-installfail  like 101004
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail  like 101004
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 101004
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stopfail like 101004
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 101004
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 101004

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

version targeted for testing:
 linux91473db3a3257eacead8f4d84cf4bc96c447193f
baseline version:
 linux04cb720142764ebf3786eba1feb8fc4b6ef87fcf

Last test of basis   101004  2016-09-18 15:44:49 Z   23 days
Testing same since   101390  2016-10-12 06:51:19 Z0 days1 attempts


People who touched revisions under test:
  Akshay Bhat 
  Al Viro 
  Alan Stern 
  Andrew Morton 
  Anson Huang 
  Ard Biesheuvel 
  Ashish Samant 
  Balbir Singh 
  Benjamin Herrenschmidt 
  Boris Brezillon 
  Catalin Marinas 
  Chris Mason 
  Christoffer Dall 
  Clemens Gruber 
  Daniele Palmas 
  Dave Airlie 
  David S. Miller 
  Eric Biggers 
  Fabio Estevam 
  Felipe Balbi 

Re: [Xen-devel] [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping timer info on huge machine.

[Lan, Tianyu]

On 10/12/2016 7:08 PM, Ian Jackson wrote:

Wei Liu writes ("Re: [PATCH v2 0/2] Xen: Fix Xen hypervisor panic during dumping 
timer info on huge machine."):

On Wed, Oct 12, 2016 at 04:20:02PM +0800, Lan Tianyu wrote:

On 2016年10月12日 16:09, Jan Beulich wrote:

Also, any reason you send to the list twice (once @lists.xen.org,
and another time to @lists.xenproject.org)?


Sometime I found my patches wasn't able to arrive xen-devel and so
send to both xen.org and xenproject.org maillist. I will double check.


Both addresses should work. There are glitches from time to time though.
So do report to us if this happens again.


I don't think either address is likely to work differently or
separately to the other.  So please just send to one, and if it
doesn't work, please report it and we will try to fix it.


Ok. I get it.



Thanks,
Ian.



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

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

[Lan, Tianyu]

On 10/12/2016 9:19 PM, Jan Beulich wrote:

On 12.10.16 at 09:58,  wrote:

--- a/xen/drivers/char/console.c
+++ b/xen/drivers/char/console.c
@@ -347,7 +347,7 @@ static void switch_serial_input(void)
 static void __serial_rx(char c, struct cpu_user_regs *regs)
 {
 if ( xen_rx )
-return handle_keypress(c, regs);
+return handle_keypress(c, regs, true);


I think it would be nice to pass true here only when in polling mode,
unless you know or can deduce that the a similar problem also exists
in IRQ mode. Perhaps you could simply move the !in_irq() here?


That's a good idea. Thanks.


(Of course the new function parameter would then want to be renamed.)


Since the issue happens when handle_keypress() runs in a timer handler,
how about to name new parameter "intimer"? __serial_rx() is called in a 
timer handler or interrupt handler. Or do you have other suggestion?




Jan



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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Martin Pohlack]

On 12.10.2016 15:44, Konrad Rzeszutek Wilk wrote:

On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:

On 12.10.16 at 15:23,  wrote:

 And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler version?


Uh, I hope one does not create a livepatch patch with another compiler
version!

Let me put on the TODO to make livepatch-build-tools check gcc against
compile.h so that one does not try this.


What's wrong with mixing compiler versions in general?


Besides scaring me?

The one issue we had encountered was with compilers generating random named
symbols for the switch tables. Those end up being called "CSWTCH.XYZ"
where the XYZ depends on the position of the moon along with how many
goats you have sacrificied to the altar of GCC gods.

Older compilers don't neccessarily do it, newer ones do, and every time
you build an livepatch the naming is different. Frustrating.

It maybe that newer versions of GCC are more predictable about this
naming.

Maybe Martin can share some of his experience? CC-ing him.


There are a couple of naming conventions for internal symbols and also 
static symbols where you basically have to pray that gcc implementation 
does not change.  Interestingly, icc has some conventions that make 
those symbol names a bit more stable.


The tricky thing is matchmaking between the existing build and the new 
build to construct the binary diff and to match up symbols for which you 
want to provide replacement code.


We use a reproducible build environment to construct hotpatches for an 
existing build in the absolutely same environment (gcc version, lib 
versions, gas version, binutils etc.).  This sidesteps most of the problems.


Martin
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Ian Jackson]

Wei Liu writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit 
[and 1 more messages]"):
> FAOD, I consider this sub-thread for "what should we do for stable
> versions of Xen". This is orthogonal to whether we should upgrade our
> in-tree ipxe version. In other words, I plan to commence with the
> upgrade if there is no major issue is found next week.

Yes.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Wei Liu]

On Wed, Oct 12, 2016 at 12:00:56PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer 
> commit"):
> > That was eventually done.  I'm not sure exactly when the change was
> > made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?
> 
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer 
> commit"):
> > Just fyi I have run into an issue with -Wno-override-init use in Linux
> > 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
> > versions we permit to be used.
> 
> Well, that answers my question above.
> 
> I think the right approach is to:
> 
>  * Test -Wno-this-is-not-a-warning-option.  If gcc accepts it,
>add -Wno-something to disable the nonnull check·
> 
>  * Review the misleading indentations and if there are only a few, fix
>them in a downstream patch.  Or, if there are many, decide to
>tolerate them.
> 

FAOD, I consider this sub-thread for "what should we do for stable
versions of Xen". This is orthogonal to whether we should upgrade our
in-tree ipxe version. In other words, I plan to commence with the
upgrade if there is no major issue is found next week.

Wei.

> Ian.

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 15:44,  wrote:
> On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
>> >>> On 12.10.16 at 15:23,  wrote:
>> >>  And then - how is all of this supposed to be working in conjucntion
>> >> with live patching, where the patch may have been created by yet
>> >> another compiler version?
>> > 
>> > Uh, I hope one does not create a livepatch patch with another compiler 
>> > version!
>> > 
>> > Let me put on the TODO to make livepatch-build-tools check gcc against
>> > compile.h so that one does not try this.
>> 
>> What's wrong with mixing compiler versions in general?
> 
> Besides scaring me?

What is it that scares you?

> The one issue we had encountered was with compilers generating random named
> symbols for the switch tables. Those end up being called "CSWTCH.XYZ"
> where the XYZ depends on the position of the moon along with how many
> goats you have sacrificied to the altar of GCC gods.
> 
> Older compilers don't neccessarily do it, newer ones do, and every time
> you build an livepatch the naming is different. Frustrating.

But this would mean you don't just depend on gcc version, but even
on the specific build (as the numbering you refer to may change with
whatever patches a distro applies on top of the upstream tarball, as
well as perhaps with configure and build options).

Jan


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

Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer commit [and 1 more messages]

[Boris Ostrovsky]

On 10/12/2016 07:00 AM, Ian Jackson wrote:
> Ian Jackson writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer 
> commit"):
>> That was eventually done.  I'm not sure exactly when the change was
>> made.  Does gcc -Wno-foo work properly on all the gcc's we care about ?
> Jan Beulich writes ("Re: [Xen-devel] [PATCH for-4.8] ipxe: update to newer 
> commit"):
>> Just fyi I have run into an issue with -Wno-override-init use in Linux
>> 4.8 on gcc 4.1.x, so what you say doesn't appear to hold for all gcc
>> versions we permit to be used.
> Well, that answers my question above.
>
> I think the right approach is to:
>
>  * Test -Wno-this-is-not-a-warning-option.  If gcc accepts it,
>add -Wno-something to disable the nonnull check·

Back compatibility is in fact not a problem. These options would only be
passed on when gcc6+ is used

>
>  * Review the misleading indentations and if there are only a few, fix
>them in a downstream patch.  Or, if there are many, decide to
>tolerate them.

There are more warnings than just indentation and nonnull checks:
-Wno-nonnull-compare
-Wno-unused-const-variable
-Wno-misleading-indentation
-Wno-shift-negative-value
-Wno-array-bounds

(The last two flagged actual bugs that have been fixed upstream).

Some of the warnings can be addressed by backporting upstream patches
but there are a few for which backporting will involve much more code
movement than fixing the code ourselves.

-boris


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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

[Wei Liu]

On Wed, Oct 12, 2016 at 02:47:18PM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote:
> > On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> > > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > > > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> > > > >  wrote:
> > > > > > From: "Edgar E. Iglesias" 
> > > > > >
> > > > > > Disable the Cortex-a53-edac. Xen currently does not yet
> > > > > > handle reads/writes to the implementation defined CPUMERRSR
> > > > > > register.
> > > > > >
> > > > > > Signed-off-by: Edgar E. Iglesias 
> > > > > 
> > > > > This solution looks fine to me and everything boots on ZynqMP as
> > > > > expected with this patch.
> > > > > 
> > > > > Acked-by: Alistair Francis 
> > > > 
> > > > Reviewed-by: Stefano Stabellini 
> > > > 
> > > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of
> > > > why this change is needed. The patch just adds the troublesome
> > > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
> > > > device tree.
> > > > 
> > > 
> > > Sure.
> > 
> > 
> > Hi Wei,
> > 
> > Just a friendly reminder:
> > This is still missing from master, staging and 4.8.0-rc2.
> > 
> 
> I thought Stefano would do it. 
> 
> I will apply this shortly. Thanks for the heads-up.
> 

Now applied.

Wei.

> Wei.
> 
> > Best regards,
> > Edgar

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

Re: [Xen-devel] [PATCH v5 6/7] VT-d: Some cleanups

[Jan Beulich]

>>> On 11.10.16 at 02:57,  wrote:
> @@ -638,7 +638,8 @@ static int msi_msg_to_remap_entry(
>  GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, index,
>   iremap_entries, iremap_entry);
>  
> -memcpy(_ire, iremap_entry, sizeof(struct iremap_entry));
> +if ( iremap_entry->remap.p )
> +new_ire.remap.im = iremap_entry->remap.im;

This is certainly more of a change than what title and description
suggest. If you really mean it to be this way, it needs to be
explained in the description.

Jan


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

Re: [Xen-devel] [PATCH v5 5/7] VT-d: No need to set irq affinity for posted format IRTE

[Jan Beulich]

>>> On 11.10.16 at 02:57,  wrote:
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -547,6 +547,49 @@ static int remap_entry_to_msi_msg(
>  return 0;
>  }
>  
> +static bool_t pi_can_suppress_irte_update(struct iremap_entry *new,

bool (and true/false respectively) please.

And then the function name suggests that no modification gets done
here (and hence the first parameter could be const too), yet the
implementation does otherwise (and I don't understand why).

> +const struct iremap_entry *old)
> +{
> +bool_t ret = 1;
> +u16 fpd, sid, sq, svt;
> +
> +if ( !old->remap.p || !old->remap.im )
> +return 0;
> +
> +fpd = new->post.fpd;
> +sid = new->post.sid;
> +sq = new->post.sq;
> +svt = new->post.svt;
> +
> +*new = *old;
> +
> +if ( fpd != old->post.fpd )
> +{
> +new->post.fpd = fpd;
> +ret = 0;
> +}
> +
> +if ( sid != old->post.sid )
> +{
> +new->post.sid = sid;
> +ret = 0;
> +}
> +
> +if ( sq != old->post.sq )
> +{
> +new->post.sq = sq;
> +ret = 0;
> +}
> +
> +if ( svt != old->post.svt )
> +{
> +new->post.svt = svt;
> +ret = 0;
> +}

What's the selection of the fields based on? Namely, what about
vector, pda_l, and pda_h?

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[George Dunlap]

On 12/10/16 14:34, Andrew Cooper wrote:
> On 12/10/16 14:26, George Dunlap wrote:
>> On 12/10/16 14:24, George Dunlap wrote:
>>> On 12/10/16 14:06, Wei Liu wrote:
 On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
 On 11.10.16 at 12:31,  wrote:
>> --- /dev/null
>> +++ b/xen/common/gcov/gcc_4_7.c
>> @@ -0,0 +1,205 @@
>> +/*
>> + *  This code provides functions to handle gcc's profiling data format
>> + *  introduced with gcc 4.7.
>> + *
>> + *  This file is based heavily on gcc_3_4.c file.
>> + *
>> + *  For a better understanding, refer to gcc source:
>> + *  gcc/gcov-io.h
>> + *  libgcc/libgcov.c
>> + *
>> + *  Uses gcc-internal data definitions.
>> + *
>> + *  Imported from Linux and modified for Xen by
>> + *Wei Liu 
>> + */
>> +
>> +#include 
>> +
>> +#include "gcov.h"
>> +
>> +#if GCC_VERSION < 40700
>> +#error "Wrong version of GCC used to compile gcov"
>> +#endif
>> +
>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>> +#define GCOV_COUNTERS   10
>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>> +#define GCOV_COUNTERS   9
>> +#else
>> +#define GCOV_COUNTERS   8
>> +#endif
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
>
>> +struct gcov_info {
>> +unsigned int version;
>> +struct gcov_info *next;
>> +unsigned int stamp;
>> +const char *filename;
>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>> +unsigned int n_functions;
>> +struct gcov_fn_info **functions;
>> +};
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
>
 Right. I will do something about this. Thanks for catching this.

> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
>
 There is a version field in gcov_info, so we can compare that and reject
 incompatible version.

 We need to use hooks in livepatching to call the constructor /
 destructor when applying / reverting a live-patch.  We might need to be
 cautious about locks or whatever, but I'm sure it can be figured out.

 But I have no idea how useful it would be to use gcov and livepatching
 together.  For now the easiest thing to do is to

depends on !LIVEPATCH

 in Kconfig.
>>> Wouldn't it be just as easy, and more useful, to set a "has been
>>> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>>>
>>> I would expect most users to want to build a single hypervisor that can
>>> be used for both gcov testing and live patching (under different
>>> circumstances).
>> I mean software provider, not user, of course.  That's what I would want
>> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
>> guys want as well.
> 
> GCOV is majority invasive, both in terms of performance (every basic
> block needs to do a locked increment of a counter) and data size
> (metadata for all basic blocks).
> 
> No software vendor is ever going to have it enabled in a production
> scenario.

You're right, I wasn't thinking.

But also presumably you'd like to be able to minimize the difference
between the thing you're testing and the thing you ship; having to
disable LivePatch increases the delta slightly.

Anyway, I still think having them both Kconfig-ured is a good idea, but
not so much that I'd spend any more time arguing for it.

 -George

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

Re: [Xen-devel] [PATCH 12/15] xen: Rename xen_be_evtchn_event

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:41AM +0300, Emil Condrea wrote:
> Prepare xen_be_evtchn_event to be shared with frontends:
>  * xen_be_evtchn_event -> xen_pv_evtchn_event
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 09:46:51AM -0400, Konrad Rzeszutek Wilk wrote:
> On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> > [...]
> > > > 
> > > > Wouldn't it be just as easy, and more useful, to set a "has been
> > > > livepatched" flag, and return errors for all gcov hypercalls if its' 
> > > > set?
> > > > 
> > > > I would expect most users to want to build a single hypervisor that can
> > > > be used for both gcov testing and live patching (under different
> > > > circumstances).
> > > 
> > > I actually would welcome livepatching and gcov to see if the test-cases I 
> > > wrote
> > > cover most of the code.
> > > 
> > 
> > I don't follow. Gcov doesn't give you a call graph -- if that's what
> > you're after.
> 
> It gives me an idea which functions/branches have run (not the livepatch
> itself - just the infrastructure around adding a livepatch, doing ELF checks, 
> etc).
> 
> And more importantly - which ones haven't run and need some more test-cases.
> 

Right. Thanks for the explanation. That would indeed be useful.

Wei.

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 02:40:08PM +0100, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
> [...]
> > > 
> > > Wouldn't it be just as easy, and more useful, to set a "has been
> > > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> > > 
> > > I would expect most users to want to build a single hypervisor that can
> > > be used for both gcov testing and live patching (under different
> > > circumstances).
> > 
> > I actually would welcome livepatching and gcov to see if the test-cases I 
> > wrote
> > cover most of the code.
> > 
> 
> I don't follow. Gcov doesn't give you a call graph -- if that's what
> you're after.

It gives me an idea which functions/branches have run (not the livepatch
itself - just the infrastructure around adding a livepatch, doing ELF checks, 
etc).

And more importantly - which ones haven't run and need some more test-cases.

> 
> > Adding in checking livepatch (common/livepatch.c: prepare_payload) to 
> > examine
> > the .gcov_info and see if it matches the hypervisor one, is fine too.
> > 
> 
> This then involves a non-trivial amount of work to figure out all the
> corner cases. It's better to defer that to a later stage.

Sure thing. And the !LIVEPATCH is fine for now. I just need to get an idea
of what this would entail so it can get done.
> 
> Wei.
> 
> > > 
> > >  -George
> > > 

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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

[Wei Liu]

On Wed, Oct 12, 2016 at 03:23:43PM +0200, Edgar E. Iglesias wrote:
> On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> > On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> > > >  wrote:
> > > > > From: "Edgar E. Iglesias" 
> > > > >
> > > > > Disable the Cortex-a53-edac. Xen currently does not yet
> > > > > handle reads/writes to the implementation defined CPUMERRSR
> > > > > register.
> > > > >
> > > > > Signed-off-by: Edgar E. Iglesias 
> > > > 
> > > > This solution looks fine to me and everything boots on ZynqMP as
> > > > expected with this patch.
> > > > 
> > > > Acked-by: Alistair Francis 
> > > 
> > > Reviewed-by: Stefano Stabellini 
> > > 
> > > Wei, can we have this in 4.8? See the 0/1 email for an explanation of
> > > why this change is needed. The patch just adds the troublesome
> > > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
> > > device tree.
> > > 
> > 
> > Sure.
> 
> 
> Hi Wei,
> 
> Just a friendly reminder:
> This is still missing from master, staging and 4.8.0-rc2.
> 

I thought Stefano would do it. 

I will apply this shortly. Thanks for the heads-up.

Wei.

> Best regards,
> Edgar

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

Re: [Xen-devel] [PATCH 14/15] xen: Rename xen_be_del_xendev

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:43AM +0300, Emil Condrea wrote:
> Prepare xen_be_del_xendev to be shared with frontends:
>  * xen_be_del_xendev -> xen_pv_del_xendev
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2

[Wei Liu]

On Wed, Oct 12, 2016 at 02:29:51PM +0100, Juergen Schinker wrote:
> 
> that is the live kernel 
> Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux
> 

Oh, right. Sorry I missed that.

> 
> I have to boot a stable xen version to use my machine again which is 4.6
> 

Then there is probably a version mismatch between your tools and
hypervisor.

You can boot into the new hypervsior, use LD_PRELOAD and / or LD_PATH to
specify the new libraries and invoke the new xl via absolute path.

  LD_PRELOAD=/path/to/libraries /path/to/xl

But if you haven't tried this before, the easiest thing to do is to
uninstall 4.6 and install 4.8. But I understand that might not be
feasible for you.

Wei.

> I only use one machine - that's why i use Virtualization
> 
> I start every major app with its own ded VM and have Xorg on the host and 
> redirect ssh from the VM
> 
> J
> 
> 
> - On 12 Oct, 2016, at 13:17, Wei Liu wei.l...@citrix.com wrote:
> 
> > But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please
> > make sure all residuals from previous releases are gone.
> > 
> > Also please start a new thread when reporting issues. We have a template
> > for that in
> > 
> > https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions
> > 
> > Wei.

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

Re: [Xen-devel] [PATCH v5 4/7] VMX: Make sure PI is in proper state before install the hooks

[Jan Beulich]

>>> On 11.10.16 at 02:57,  wrote:
>  static void pi_desc_init(struct vcpu *v)
>  {
> -uint32_t dest;
> -
>  v->arch.hvm_vmx.pi_desc.nv = posted_intr_vector;
>  
> -dest = cpu_physical_id(v->processor);
> -
> -if ( x2apic_enabled )
> -v->arch.hvm_vmx.pi_desc.ndst = dest;
> -else
> -v->arch.hvm_vmx.pi_desc.ndst = MASK_INSR(dest, PI_xAPIC_NDST_MASK);
> +/*
> + * Mark NDST as invalid, then we can use this invalid value as a
> + * marker to whether update NDST or not in vmx_pi_hooks_assign().
> + */
> +v->arch.hvm_vmx.pi_desc.ndst = 0x;

I think I had at the same time asked to make this a #define, so the
two (currently) instance can be connected together.

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -211,14 +211,39 @@ static void vmx_pi_do_resume(struct vcpu *v)
>  /* This function is called when pcidevs_lock is held */
>  void vmx_pi_hooks_assign(struct domain *d)
>  {
> +struct vcpu *v;
> +
>  if ( !iommu_intpost || !has_hvm_container_domain(d) )
>  return;
>  
>  ASSERT(!d->arch.hvm_domain.vmx.vcpu_block);
>  
> -d->arch.hvm_domain.vmx.vcpu_block = vmx_vcpu_block;
> +/*
> + * We carefully handle the timing here:
> + * - Install the context switch first
> + * - Then set the NDST field
> + * - Install the block and resume hooks in the end
> + *
> + * This can make sure the PI (especially the NDST feild) is
> + * in proper state when we call vmx_vcpu_block().
> + */
>  d->arch.hvm_domain.vmx.pi_switch_from = vmx_pi_switch_from;
>  d->arch.hvm_domain.vmx.pi_switch_to = vmx_pi_switch_to;
> +
> +for_each_vcpu ( d, v )
> +{
> +unsigned int dest = cpu_physical_id(v->processor);
> +struct pi_desc *pi_desc = >arch.hvm_vmx.pi_desc;
> +
> +/*
> + * We don't need to update NDST if 'arch.hvm_domain.vmx.pi_switch_to'
> + * already gets called

I think you mean "got" or "has got". Also I think you'd better refer to
the actual VMX function instead of the hook pointer field.

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 07:31:52AM -0600, Jan Beulich wrote:
> >>> On 12.10.16 at 15:23,  wrote:
> >>  And then - how is all of this supposed to be working in conjucntion
> >> with live patching, where the patch may have been created by yet
> >> another compiler version?
> > 
> > Uh, I hope one does not create a livepatch patch with another compiler 
> > version!
> > 
> > Let me put on the TODO to make livepatch-build-tools check gcc against
> > compile.h so that one does not try this.
> 
> What's wrong with mixing compiler versions in general?

Besides scaring me?

The one issue we had encountered was with compilers generating random named
symbols for the switch tables. Those end up being called "CSWTCH.XYZ"
where the XYZ depends on the position of the moon along with how many
goats you have sacrificied to the altar of GCC gods.

Older compilers don't neccessarily do it, newer ones do, and every time
you build an livepatch the naming is different. Frustrating.

It maybe that newer versions of GCC are more predictable about this
naming.

Maybe Martin can share some of his experience? CC-ing him.

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Andrew Cooper]

On 12/10/16 14:41, George Dunlap wrote:
> On 12/10/16 14:34, Andrew Cooper wrote:
>> On 12/10/16 14:26, George Dunlap wrote:
>>> On 12/10/16 14:24, George Dunlap wrote:
 On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31,  wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + *  This code provides functions to handle gcc's profiling data format
>>> + *  introduced with gcc 4.7.
>>> + *
>>> + *  This file is based heavily on gcc_3_4.c file.
>>> + *
>>> + *  For a better understanding, refer to gcc source:
>>> + *  gcc/gcov-io.h
>>> + *  libgcc/libgcov.c
>>> + *
>>> + *  Uses gcc-internal data definitions.
>>> + *
>>> + *  Imported from Linux and modified for Xen by
>>> + *Wei Liu 
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#include "gcov.h"
>>> +
>>> +#if GCC_VERSION < 40700
>>> +#error "Wrong version of GCC used to compile gcov"
>>> +#endif
>>> +
>>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>>> +#define GCOV_COUNTERS   10
>>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>>> +#define GCOV_COUNTERS   9
>>> +#else
>>> +#define GCOV_COUNTERS   8
>>> +#endif
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>>
>>> +struct gcov_info {
>>> +unsigned int version;
>>> +struct gcov_info *next;
>>> +unsigned int stamp;
>>> +const char *filename;
>>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>>> +unsigned int n_functions;
>>> +struct gcov_fn_info **functions;
>>> +};
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>>
> Right. I will do something about this. Thanks for catching this.
>
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>>
> There is a version field in gcov_info, so we can compare that and reject
> incompatible version.
>
> We need to use hooks in livepatching to call the constructor /
> destructor when applying / reverting a live-patch.  We might need to be
> cautious about locks or whatever, but I'm sure it can be figured out.
>
> But I have no idea how useful it would be to use gcov and livepatching
> together.  For now the easiest thing to do is to
>
>depends on !LIVEPATCH
>
> in Kconfig.
 Wouldn't it be just as easy, and more useful, to set a "has been
 livepatched" flag, and return errors for all gcov hypercalls if its' set?

 I would expect most users to want to build a single hypervisor that can
 be used for both gcov testing and live patching (under different
 circumstances).
>>> I mean software provider, not user, of course.  That's what I would want
>>> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
>>> guys want as well.
>> GCOV is majority invasive, both in terms of performance (every basic
>> block needs to do a locked increment of a counter) and data size
>> (metadata for all basic blocks).
>>
>> No software vendor is ever going to have it enabled in a production
>> scenario.
> You're right, I wasn't thinking.
>
> But also presumably you'd like to be able to minimize the difference
> between the thing you're testing and the thing you ship; having to
> disable LivePatch increases the delta slightly.
>
> Anyway, I still think having them both Kconfig-ured is a good idea, but
> not so much that I'd spend any more time arguing for it.

It is a testing feature.  It would certainly be nice to get code
coverage of the livepatching parts, but that absolutely shouldn't block
making gcov usable in the first place.

It might be worth sticking a #TODO make GCOV worth with Livepatching in
the kconfig file (for anyone who stumbles across this dependency).

~Andrew

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

Re: [Xen-devel] [PATCH 13/15] xen: Rename xen_be_find_xendev

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:42AM +0300, Emil Condrea wrote:
> Prepare xen_be_find_xendev to be shared with frontends:
>  * xen_be_find_xendev -> xen_pv_find_xendev
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 11/15] xen: Rename xen_be_send_notify

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:40AM +0300, Emil Condrea wrote:
> Prepare xen_be_send_notify to be shared with frontends:
>  * xen_be_send_notify -> xen_pv_send_notify
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 09:29:04AM -0400, Konrad Rzeszutek Wilk wrote:
[...]
> > 
> > Wouldn't it be just as easy, and more useful, to set a "has been
> > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> > 
> > I would expect most users to want to build a single hypervisor that can
> > be used for both gcov testing and live patching (under different
> > circumstances).
> 
> I actually would welcome livepatching and gcov to see if the test-cases I 
> wrote
> cover most of the code.
> 

I don't follow. Gcov doesn't give you a call graph -- if that's what
you're after.

> Adding in checking livepatch (common/livepatch.c: prepare_payload) to examine
> the .gcov_info and see if it matches the hypervisor one, is fine too.
> 

This then involves a non-trivial amount of work to figure out all the
corner cases. It's better to defer that to a later stage.

Wei.

> > 
> >  -George
> > 

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

Re: [Xen-devel] [PATCH 10/15] xen: Rename xen_be_unbind_evtchn

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:39AM +0300, Emil Condrea wrote:
> Prepare xen_be_unbind_evtchn to be shared with frontends:
>  * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Andrew Cooper]

On 12/10/16 14:26, George Dunlap wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> On 12/10/16 14:06, Wei Liu wrote:
>>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>>> On 11.10.16 at 12:31,  wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + *  This code provides functions to handle gcc's profiling data format
> + *  introduced with gcc 4.7.
> + *
> + *  This file is based heavily on gcc_3_4.c file.
> + *
> + *  For a better understanding, refer to gcc source:
> + *  gcc/gcov-io.h
> + *  libgcc/libgcov.c
> + *
> + *  Uses gcc-internal data definitions.
> + *
> + *  Imported from Linux and modified for Xen by
> + *Wei Liu 
> + */
> +
> +#include 
> +
> +#include "gcov.h"
> +
> +#if GCC_VERSION < 40700
> +#error "Wrong version of GCC used to compile gcov"
> +#endif
> +
> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> +#define GCOV_COUNTERS   10
> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> +#define GCOV_COUNTERS   9
> +#else
> +#define GCOV_COUNTERS   8
> +#endif
 I'm sorry for not having pointed this out on v2 (I had noticed it,
 but then didn't finish analyzing the situation), but I'm afraid this
 together with ...

> +struct gcov_info {
> +unsigned int version;
> +struct gcov_info *next;
> +unsigned int stamp;
> +const char *filename;
> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> +unsigned int n_functions;
> +struct gcov_fn_info **functions;
> +};
 ... this structure's trailing fields actually getting used by the code
 won't work well when changing compiler versions without cleaning
 the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
 #define-ing their GCOV_COUNTERS and then #include-ing this
 shared source file. Plus btw, I don't think gcc 5.0.x (the
 development variant of 5.x) would use anything different from
 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
 normally be necessary anymore with gcc 5+.

>>> Right. I will do something about this. Thanks for catching this.
>>>
 And then - how is all of this supposed to be working in conjucntion
 with live patching, where the patch may have been created by yet
 another compiler version?

>>> There is a version field in gcov_info, so we can compare that and reject
>>> incompatible version.
>>>
>>> We need to use hooks in livepatching to call the constructor /
>>> destructor when applying / reverting a live-patch.  We might need to be
>>> cautious about locks or whatever, but I'm sure it can be figured out.
>>>
>>> But I have no idea how useful it would be to use gcov and livepatching
>>> together.  For now the easiest thing to do is to
>>>
>>>depends on !LIVEPATCH
>>>
>>> in Kconfig.
>> Wouldn't it be just as easy, and more useful, to set a "has been
>> livepatched" flag, and return errors for all gcov hypercalls if its' set?
>>
>> I would expect most users to want to build a single hypervisor that can
>> be used for both gcov testing and live patching (under different
>> circumstances).
> I mean software provider, not user, of course.  That's what I would want
> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
> guys want as well.

GCOV is majority invasive, both in terms of performance (every basic
block needs to do a locked increment of a counter) and data size
(metadata for all basic blocks).

No software vendor is ever going to have it enabled in a production
scenario.

~Andrew

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 15:26,  wrote:
> On 12/10/16 14:24, George Dunlap wrote:
>> I would expect most users to want to build a single hypervisor that can
>> be used for both gcov testing and live patching (under different
>> circumstances).
> 
> I mean software provider, not user, of course.  That's what I would want
> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
> guys want as well.

But gcov is explicitly a non-production feature, iirc.

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 02:26:26PM +0100, George Dunlap wrote:
[...]
> >>
> >> There is a version field in gcov_info, so we can compare that and reject
> >> incompatible version.
> >>
> >> We need to use hooks in livepatching to call the constructor /
> >> destructor when applying / reverting a live-patch.  We might need to be
> >> cautious about locks or whatever, but I'm sure it can be figured out.
> >>
> >> But I have no idea how useful it would be to use gcov and livepatching
> >> together.  For now the easiest thing to do is to
> >>
> >>depends on !LIVEPATCH
> >>
> >> in Kconfig.
> > 
> > Wouldn't it be just as easy, and more useful, to set a "has been
> > livepatched" flag, and return errors for all gcov hypercalls if its' set?
> > 
> > I would expect most users to want to build a single hypervisor that can
> > be used for both gcov testing and live patching (under different
> > circumstances).
> 
> I mean software provider, not user, of course.  That's what I would want
> for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
> guys want as well.
> 

The usefulness of such build is not as big as you might think I'm
afraid -- it wouldn't be useful until we figure out how to apply a
livepatch generated with gcov support built in.

Wei.

>  -George
> 

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 15:23,  wrote:
>>  And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
> 
> Uh, I hope one does not create a livepatch patch with another compiler 
> version!
> 
> Let me put on the TODO to make livepatch-build-tools check gcc against
> compile.h so that one does not try this.

What's wrong with mixing compiler versions in general?

Jan


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

Re: [Xen-devel] [PATCH 09/15] xen: Rename xen_be_printf to xen_pv_printf

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:38AM +0300, Emil Condrea wrote:
> Prepare xen_be_printf to be used by both backend and frontends:
>  * xen_be_printf -> xen_pv_printf
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 08/15] xen: Move xenstore cleanup and mkdir functions

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:37AM +0300, Emil Condrea wrote:
> The name of the functions moved to xen_pvdev.c:
>  * xenstore_cleanup_dir
>  * xen_config_cleanup
>  * xenstore_mkdir
> 
> Signed-off-by: Emil Condrea 

Acked-by: Anthony PERARD 

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH 04/15] xen: Create a new file xen_frontend.c

[Anthony PERARD]

On Tue, Oct 04, 2016 at 09:43:33AM +0300, Emil Condrea wrote:
> Its purpose is to store frontend related functions.
> 
> Signed-off-by: Quan Xu 
> Signed-off-by: Emil Condrea 

Looks good, once the comments on the previous patches are addressed,
same comments for patch 5, 6 and 7.

-- 
Anthony PERARD

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

Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2

[Juergen Schinker]

that is the live kernel 
Linux xen 4.7.0-1-amd64 #1 SMP Debian 4.7.5-1 (2016-09-26) x86_64 GNU/Linux


I have to boot a stable xen version to use my machine again which is 4.6

I only use one machine - that's why i use Virtualization

I start every major app with its own ded VM and have Xorg on the host and 
redirect ssh from the VM

J


- On 12 Oct, 2016, at 13:17, Wei Liu wei.l...@citrix.com wrote:

> But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please
> make sure all residuals from previous releases are gone.
> 
> Also please start a new thread when reporting issues. We have a template
> for that in
> 
> https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions
> 
> Wei.

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk]

On Wed, Oct 12, 2016 at 02:24:51PM +0100, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
> > On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> > On 11.10.16 at 12:31,  wrote:
> >>> --- /dev/null
> >>> +++ b/xen/common/gcov/gcc_4_7.c
> >>> @@ -0,0 +1,205 @@
> >>> +/*
> >>> + *  This code provides functions to handle gcc's profiling data format
> >>> + *  introduced with gcc 4.7.
> >>> + *
> >>> + *  This file is based heavily on gcc_3_4.c file.
> >>> + *
> >>> + *  For a better understanding, refer to gcc source:
> >>> + *  gcc/gcov-io.h
> >>> + *  libgcc/libgcov.c
> >>> + *
> >>> + *  Uses gcc-internal data definitions.
> >>> + *
> >>> + *  Imported from Linux and modified for Xen by
> >>> + *Wei Liu 
> >>> + */
> >>> +
> >>> +#include 
> >>> +
> >>> +#include "gcov.h"
> >>> +
> >>> +#if GCC_VERSION < 40700
> >>> +#error "Wrong version of GCC used to compile gcov"
> >>> +#endif
> >>> +
> >>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> >>> +#define GCOV_COUNTERS   10
> >>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> >>> +#define GCOV_COUNTERS   9
> >>> +#else
> >>> +#define GCOV_COUNTERS   8
> >>> +#endif
> >>
> >> I'm sorry for not having pointed this out on v2 (I had noticed it,
> >> but then didn't finish analyzing the situation), but I'm afraid this
> >> together with ...
> >>
> >>> +struct gcov_info {
> >>> +unsigned int version;
> >>> +struct gcov_info *next;
> >>> +unsigned int stamp;
> >>> +const char *filename;
> >>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> >>> +unsigned int n_functions;
> >>> +struct gcov_fn_info **functions;
> >>> +};
> >>
> >> ... this structure's trailing fields actually getting used by the code
> >> won't work well when changing compiler versions without cleaning
> >> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
> >> #define-ing their GCOV_COUNTERS and then #include-ing this
> >> shared source file. Plus btw, I don't think gcc 5.0.x (the
> >> development variant of 5.x) would use anything different from
> >> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> >> normally be necessary anymore with gcc 5+.
> >>
> > 
> > Right. I will do something about this. Thanks for catching this.
> > 
> >> And then - how is all of this supposed to be working in conjucntion
> >> with live patching, where the patch may have been created by yet
> >> another compiler version?
> >>
> > 
> > There is a version field in gcov_info, so we can compare that and reject
> > incompatible version.
> > 
> > We need to use hooks in livepatching to call the constructor /
> > destructor when applying / reverting a live-patch.  We might need to be
> > cautious about locks or whatever, but I'm sure it can be figured out.
> > 
> > But I have no idea how useful it would be to use gcov and livepatching
> > together.  For now the easiest thing to do is to
> > 
> >depends on !LIVEPATCH
> > 
> > in Kconfig.
> 
> Wouldn't it be just as easy, and more useful, to set a "has been
> livepatched" flag, and return errors for all gcov hypercalls if its' set?
> 
> I would expect most users to want to build a single hypervisor that can
> be used for both gcov testing and live patching (under different
> circumstances).

I actually would welcome livepatching and gcov to see if the test-cases I wrote
cover most of the code.

Adding in checking livepatch (common/livepatch.c: prepare_payload) to examine
the .gcov_info and see if it matches the hypervisor one, is fine too.

> 
>  -George
> 

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[George Dunlap]

On 12/10/16 14:24, George Dunlap wrote:
> On 12/10/16 14:06, Wei Liu wrote:
>> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
>> On 11.10.16 at 12:31,  wrote:
 --- /dev/null
 +++ b/xen/common/gcov/gcc_4_7.c
 @@ -0,0 +1,205 @@
 +/*
 + *  This code provides functions to handle gcc's profiling data format
 + *  introduced with gcc 4.7.
 + *
 + *  This file is based heavily on gcc_3_4.c file.
 + *
 + *  For a better understanding, refer to gcc source:
 + *  gcc/gcov-io.h
 + *  libgcc/libgcov.c
 + *
 + *  Uses gcc-internal data definitions.
 + *
 + *  Imported from Linux and modified for Xen by
 + *Wei Liu 
 + */
 +
 +#include 
 +
 +#include "gcov.h"
 +
 +#if GCC_VERSION < 40700
 +#error "Wrong version of GCC used to compile gcov"
 +#endif
 +
 +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
 +#define GCOV_COUNTERS   10
 +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
 +#define GCOV_COUNTERS   9
 +#else
 +#define GCOV_COUNTERS   8
 +#endif
>>>
>>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>>> but then didn't finish analyzing the situation), but I'm afraid this
>>> together with ...
>>>
 +struct gcov_info {
 +unsigned int version;
 +struct gcov_info *next;
 +unsigned int stamp;
 +const char *filename;
 +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
 +unsigned int n_functions;
 +struct gcov_fn_info **functions;
 +};
>>>
>>> ... this structure's trailing fields actually getting used by the code
>>> won't work well when changing compiler versions without cleaning
>>> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
>>> #define-ing their GCOV_COUNTERS and then #include-ing this
>>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>>> development variant of 5.x) would use anything different from
>>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>>> normally be necessary anymore with gcc 5+.
>>>
>>
>> Right. I will do something about this. Thanks for catching this.
>>
>>> And then - how is all of this supposed to be working in conjucntion
>>> with live patching, where the patch may have been created by yet
>>> another compiler version?
>>>
>>
>> There is a version field in gcov_info, so we can compare that and reject
>> incompatible version.
>>
>> We need to use hooks in livepatching to call the constructor /
>> destructor when applying / reverting a live-patch.  We might need to be
>> cautious about locks or whatever, but I'm sure it can be figured out.
>>
>> But I have no idea how useful it would be to use gcov and livepatching
>> together.  For now the easiest thing to do is to
>>
>>depends on !LIVEPATCH
>>
>> in Kconfig.
> 
> Wouldn't it be just as easy, and more useful, to set a "has been
> livepatched" flag, and return errors for all gcov hypercalls if its' set?
> 
> I would expect most users to want to build a single hypervisor that can
> be used for both gcov testing and live patching (under different
> circumstances).

I mean software provider, not user, of course.  That's what I would want
for CentOS, and I'm sure that's what the XenServer (and probably Oracle)
guys want as well.

 -George


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[George Dunlap]

On 12/10/16 14:06, Wei Liu wrote:
> On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> On 11.10.16 at 12:31,  wrote:
>>> --- /dev/null
>>> +++ b/xen/common/gcov/gcc_4_7.c
>>> @@ -0,0 +1,205 @@
>>> +/*
>>> + *  This code provides functions to handle gcc's profiling data format
>>> + *  introduced with gcc 4.7.
>>> + *
>>> + *  This file is based heavily on gcc_3_4.c file.
>>> + *
>>> + *  For a better understanding, refer to gcc source:
>>> + *  gcc/gcov-io.h
>>> + *  libgcc/libgcov.c
>>> + *
>>> + *  Uses gcc-internal data definitions.
>>> + *
>>> + *  Imported from Linux and modified for Xen by
>>> + *Wei Liu 
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#include "gcov.h"
>>> +
>>> +#if GCC_VERSION < 40700
>>> +#error "Wrong version of GCC used to compile gcov"
>>> +#endif
>>> +
>>> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
>>> +#define GCOV_COUNTERS   10
>>> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
>>> +#define GCOV_COUNTERS   9
>>> +#else
>>> +#define GCOV_COUNTERS   8
>>> +#endif
>>
>> I'm sorry for not having pointed this out on v2 (I had noticed it,
>> but then didn't finish analyzing the situation), but I'm afraid this
>> together with ...
>>
>>> +struct gcov_info {
>>> +unsigned int version;
>>> +struct gcov_info *next;
>>> +unsigned int stamp;
>>> +const char *filename;
>>> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
>>> +unsigned int n_functions;
>>> +struct gcov_fn_info **functions;
>>> +};
>>
>> ... this structure's trailing fields actually getting used by the code
>> won't work well when changing compiler versions without cleaning
>> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
>> #define-ing their GCOV_COUNTERS and then #include-ing this
>> shared source file. Plus btw, I don't think gcc 5.0.x (the
>> development variant of 5.x) would use anything different from
>> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
>> normally be necessary anymore with gcc 5+.
>>
> 
> Right. I will do something about this. Thanks for catching this.
> 
>> And then - how is all of this supposed to be working in conjucntion
>> with live patching, where the patch may have been created by yet
>> another compiler version?
>>
> 
> There is a version field in gcov_info, so we can compare that and reject
> incompatible version.
> 
> We need to use hooks in livepatching to call the constructor /
> destructor when applying / reverting a live-patch.  We might need to be
> cautious about locks or whatever, but I'm sure it can be figured out.
> 
> But I have no idea how useful it would be to use gcov and livepatching
> together.  For now the easiest thing to do is to
> 
>depends on !LIVEPATCH
> 
> in Kconfig.

Wouldn't it be just as easy, and more useful, to set a "has been
livepatched" flag, and return errors for all gcov hypercalls if its' set?

I would expect most users to want to build a single hypervisor that can
be used for both gcov testing and live patching (under different
circumstances).

 -George


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

Re: [Xen-devel] [PATCH v5 1/7] VMX: Statically assign two PI hooks

[Jan Beulich]

>>> On 11.10.16 at 02:57,  wrote:
> +/*
> + * In fact, we can remove this hooks inside itself if no new device is in the
> + * process of getting assigned and "from" hook is NULL. However, it is not
> + * straightforward to find a clear solution, so just leave it here.
> + */
>  static void vmx_pi_switch_to(struct vcpu *v)

I think this comment would better go next to where the NULL
assignment is (to be).

> @@ -221,9 +226,8 @@ void vmx_pi_hooks_deassign(struct domain *d)
>  ASSERT(d->arch.hvm_domain.vmx.vcpu_block);
>  
>  d->arch.hvm_domain.vmx.vcpu_block = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_from = NULL;
> -d->arch.hvm_domain.vmx.pi_switch_to = NULL;
>  d->arch.hvm_domain.vmx.pi_do_resume = NULL;
> +d->arch.hvm_domain.vmx.pi_switch_from = NULL;
>  }

Besides the discrepancy of description and implementation which
Kevin has already pointed out, I'd also like to ask to replace the
"statically" in title and description. "Statically" would mean the
hooks get installed unconditionally at domain creation time (or
even at build time). Instead I think you mean "keep two PI hooks
assigned" or "permanently assign two PI hooks".

Jan


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

Re: [Xen-devel] [PATCH v1 1/1] xen/arm: Disable the Cortex-a53-edac

[Edgar E. Iglesias]

On Fri, Oct 07, 2016 at 07:22:33PM +0100, Wei Liu wrote:
> On Fri, Oct 07, 2016 at 10:34:15AM -0700, Stefano Stabellini wrote:
> > On Fri, 7 Oct 2016, Alistair Francis wrote:
> > > On Thu, Oct 6, 2016 at 9:36 AM, Edgar E. Iglesias
> > >  wrote:
> > > > From: "Edgar E. Iglesias" 
> > > >
> > > > Disable the Cortex-a53-edac. Xen currently does not yet
> > > > handle reads/writes to the implementation defined CPUMERRSR
> > > > register.
> > > >
> > > > Signed-off-by: Edgar E. Iglesias 
> > > 
> > > This solution looks fine to me and everything boots on ZynqMP as
> > > expected with this patch.
> > > 
> > > Acked-by: Alistair Francis 
> > 
> > Reviewed-by: Stefano Stabellini 
> > 
> > Wei, can we have this in 4.8? See the 0/1 email for an explanation of
> > why this change is needed. The patch just adds the troublesome
> > cortex-a15-pmu to the "skip_matches" array to remove it from dom0's
> > device tree.
> > 
> 
> Sure.


Hi Wei,

Just a friendly reminder:
This is still missing from master, staging and 4.8.0-rc2.

Best regards,
Edgar

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Konrad Rzeszutek Wilk]

> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?

Uh, I hope one does not create a livepatch patch with another compiler version!

Let me put on the TODO to make livepatch-build-tools check gcc against
compile.h so that one does not try this.
> 
> Jan
> 

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

Re: [Xen-devel] [PATCH v2 1/2] Xen/Keyhandler: Rework process of nonirq keyhandler

[Jan Beulich]

>>> On 12.10.16 at 09:58,  wrote:
> --- a/xen/drivers/char/console.c
> +++ b/xen/drivers/char/console.c
> @@ -347,7 +347,7 @@ static void switch_serial_input(void)
>  static void __serial_rx(char c, struct cpu_user_regs *regs)
>  {
>  if ( xen_rx )
> -return handle_keypress(c, regs);
> +return handle_keypress(c, regs, true);

I think it would be nice to pass true here only when in polling mode,
unless you know or can deduce that the a similar problem also exists
in IRQ mode. Perhaps you could simply move the !in_irq() here? (Of
course the new function parameter would then want to be renamed.)

Jan


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

Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2

[Wei Liu]

On Wed, Oct 12, 2016 at 02:13:57PM +0100, Juergen Schinker wrote:
> I use systemd and openvswitch
> 
> 
> release: 4.7.0-1-amd64

But this shows 4.7.0-1. Maybe you didn't install Xen properly? Please
make sure all residuals from previous releases are gone.

Also please start a new thread when reporting issues. We have a template
for that in 

https://wiki.xenproject.org/wiki/Xen_4.8_RC_test_instructions

Wei.

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

Re: [Xen-devel] [BUG] ANNOUNCEMENT] Xen 4.8 RC2

[Juergen Schinker]

I use systemd and openvswitch


release: 4.7.0-1-amd64
version: #1 SMP Debian 4.7.5-1 (2016-09-26)
machine: x86_64
nr_cpus: 4
max_cpu_id : 3
nr_nodes   : 1
cores_per_socket   : 2
threads_per_core   : 2
cpu_mhz: 2312
hw_caps: 
bfebfbff:28100800::7f00:77bae3ff::0001:0281
virt_caps  : hvm hvm_directio
total_memory   : 32711
free_memory: 0
sharing_freed_memory   : 0
sharing_used_memory: 0
outstanding_claims : 0
free_cpus  : 0





 ii  gcc-6 6.2.0-5  

booting hypervizor  pass

creating VM  fail   version for 4.8 
toolkit hasn't been found amd hangs
booting VM   fail   hangs

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 12.10.16 at 15:06,  wrote:
> But I have no idea how useful it would be to use gcov and livepatching
> together.  For now the easiest thing to do is to
> 
>depends on !LIVEPATCH
> 
> in Kconfig.

I agree.

Jan


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

Re: [Xen-devel] [PATCH] x86/Intel: virtualize support for cpuid faulting

[Jan Beulich]

>>> On 12.10.16 at 06:07,  wrote:
> ---

In addition to what Andrew said: Please version your patch, and please
add a short summary of what changed compared to the previous version
here.

> @@ -2931,6 +2941,11 @@ static int vmx_msr_write_intercept(unsigned int msr, 
> uint64_t msr_content)
>   rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
>  goto gp_fault;
>  break;
> +case MSR_INTEL_MISC_FEATURES_ENABLES:

Blank line ahead of this one please.

> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2945,6 +2945,16 @@ static int emulate_privileged_op(struct cpu_user_regs 
> *regs)
>   rdmsr_safe(MSR_INTEL_PLATFORM_INFO, msr_content) )
>  goto fail;
>  break;
> +case MSR_INTEL_MISC_FEATURES_ENABLES:

Same here. Plus you need to re-base. The code you modify has
changed quite a bit.

> +if ( boot_cpu_data.x86_vendor != X86_VENDOR_INTEL ||
> + rdmsr_safe(MSR_INTEL_MISC_FEATURES_ENABLES, val) ||
> + msr_content & ~MSR_MISC_FEATURES_CPUID_FAULTING )

Please parenthesize the operands of &. Also I think the msr_content
check would better go ahead of the rdmsr_safe().

> +goto fail;
> +if ( msr_content == MSR_MISC_FEATURES_CPUID_FAULTING &&

Please use & instead of ==, so the line won't need to change once
further bits here get emulated.

Jan


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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Wei Liu]

On Wed, Oct 12, 2016 at 06:42:53AM -0600, Jan Beulich wrote:
> >>> On 11.10.16 at 12:31,  wrote:
> > --- /dev/null
> > +++ b/xen/common/gcov/gcc_4_7.c
> > @@ -0,0 +1,205 @@
> > +/*
> > + *  This code provides functions to handle gcc's profiling data format
> > + *  introduced with gcc 4.7.
> > + *
> > + *  This file is based heavily on gcc_3_4.c file.
> > + *
> > + *  For a better understanding, refer to gcc source:
> > + *  gcc/gcov-io.h
> > + *  libgcc/libgcov.c
> > + *
> > + *  Uses gcc-internal data definitions.
> > + *
> > + *  Imported from Linux and modified for Xen by
> > + *Wei Liu 
> > + */
> > +
> > +#include 
> > +
> > +#include "gcov.h"
> > +
> > +#if GCC_VERSION < 40700
> > +#error "Wrong version of GCC used to compile gcov"
> > +#endif
> > +
> > +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> > +#define GCOV_COUNTERS   10
> > +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> > +#define GCOV_COUNTERS   9
> > +#else
> > +#define GCOV_COUNTERS   8
> > +#endif
> 
> I'm sorry for not having pointed this out on v2 (I had noticed it,
> but then didn't finish analyzing the situation), but I'm afraid this
> together with ...
> 
> > +struct gcov_info {
> > +unsigned int version;
> > +struct gcov_info *next;
> > +unsigned int stamp;
> > +const char *filename;
> > +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> > +unsigned int n_functions;
> > +struct gcov_fn_info **functions;
> > +};
> 
> ... this structure's trailing fields actually getting used by the code
> won't work well when changing compiler versions without cleaning
> the tree.  I think instead you need thin gcc_5.c and gcc_4_9.c
> #define-ing their GCOV_COUNTERS and then #include-ing this
> shared source file. Plus btw, I don't think gcc 5.0.x (the
> development variant of 5.x) would use anything different from
> 5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
> normally be necessary anymore with gcc 5+.
> 

Right. I will do something about this. Thanks for catching this.

> And then - how is all of this supposed to be working in conjucntion
> with live patching, where the patch may have been created by yet
> another compiler version?
> 

There is a version field in gcov_info, so we can compare that and reject
incompatible version.

We need to use hooks in livepatching to call the constructor /
destructor when applying / reverting a live-patch.  We might need to be
cautious about locks or whatever, but I'm sure it can be figured out.

But I have no idea how useful it would be to use gcov and livepatching
together.  For now the easiest thing to do is to

   depends on !LIVEPATCH

in Kconfig.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Jan Beulich]

>>> On 12.10.16 at 14:51,  wrote:
> Hello Jan,
> 
> On 12/10/2016 12:45, Jan Beulich wrote:
> On 11.10.16 at 15:39,  wrote:
>>> On 06/10/16 13:21, Jan Beulich wrote:
>>> On 05.10.16 at 20:30,  wrote:
> On 30/09/2016 02:46, Jan Beulich wrote:
> On 29.09.16 at 23:42,  wrote:
>>> +#else
>>> +static void __init free_ebmalloc_unused_mem(void)
>>> +{
>>> +}
>>> +#endif
>>
>> Did you build test this for ARM? The function ought to be unused,
>> as ...
>>
>>> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
>>>  } *extra, *extra_head = NULL;
>>>  #endif
>>>
>>> +free_ebmalloc_unused_mem();
>>
>> ... the whole function here doesn't get built on ARM.
>>
>> Julien - we're still awaiting your input on general aspects here.
>
> efi_init_memory would need to be called during Xen boot on ARM. I am not
> sure where as I we don't yet have runtime support on ARM.
>
> Other than that, the patch looks good to me.

 But that wasn't the question. My goal is to have as little code
 inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
 as much of this new code as possible outside of such conditionals.
 So the question really is whether that alternative approach would
 be fine with you, or what problems you might see.
>>>
>>> I am not sure to get it. The current approach looks good to me, however,
>>> the implementation should not be exposed to ARM until all the TODOs
>>> mentioned by Daniel are fixed.
>>
>> Which is precisely the opposite of what I'm aiming at. Once again:
>> Don't you think it is desirable to keep the #ifndef CONFIG_ARM
>> instances to cover as little code as possible? Not all of the named
>> TODOs really need to be addressed in order to compile most of
>> what comprises this new allocator; in fact none of them really
>> needs addressing:
>> - if the size estimation turns out to low once ARM starts actually
>>   using this, let's just bump it (perhaps by making it a per-arch
>>   constant),
>> - if the section chosen needs to be different (which it really
>>   shouldn't be), let's simply adjust it,
> 
> If we keep the section in BSS, then we really need to move the 
> initialization of BSS earlier.

Right, but that should be simple enough. Or we do ...

> This TODO really needs to be fixed now otherwise it will be a nightmare 
> to debug later on.
> 
>> - as we've already figured there's no need for the stub
>>   free_ebmalloc_unused_mem() right now anyway.
> 
> But we would need to call free_ebmalloc_unused_mem from somewhere. The 
> idea to not expose the early memory allocator on ARM is avoid to have an 
> implementation with may not fully work on ARM because of known missing 
> pieces.
> 
>> And then (as another alternative) we have the option of ARM
>> simply defining EBMALLOC_SIZE to zero for the time being. That
>> would eliminate the need to actually call free_ebmalloc_unused_mem()
>> and turn the other two items into non-issues.

... this, which you didn't comment on at all.

Jan


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

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Julien Grall]

Hello Jan,

On 12/10/2016 12:45, Jan Beulich wrote:

On 11.10.16 at 15:39,  wrote:

On 06/10/16 13:21, Jan Beulich wrote:

On 05.10.16 at 20:30,  wrote:

On 30/09/2016 02:46, Jan Beulich wrote:

On 29.09.16 at 23:42,  wrote:

+#else
+static void __init free_ebmalloc_unused_mem(void)
+{
+}
+#endif


Did you build test this for ARM? The function ought to be unused,
as ...


@@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
 } *extra, *extra_head = NULL;
 #endif

+free_ebmalloc_unused_mem();


... the whole function here doesn't get built on ARM.

Julien - we're still awaiting your input on general aspects here.


efi_init_memory would need to be called during Xen boot on ARM. I am not
sure where as I we don't yet have runtime support on ARM.

Other than that, the patch looks good to me.


But that wasn't the question. My goal is to have as little code
inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
as much of this new code as possible outside of such conditionals.
So the question really is whether that alternative approach would
be fine with you, or what problems you might see.


I am not sure to get it. The current approach looks good to me, however,
the implementation should not be exposed to ARM until all the TODOs
mentioned by Daniel are fixed.


Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
  using this, let's just bump it (perhaps by making it a per-arch
  constant),
- if the section chosen needs to be different (which it really
  shouldn't be), let's simply adjust it,


If we keep the section in BSS, then we really need to move the 
initialization of BSS earlier.


This TODO really needs to be fixed now otherwise it will be a nightmare 
to debug later on.



- as we've already figured there's no need for the stub
  free_ebmalloc_unused_mem() right now anyway.


But we would need to call free_ebmalloc_unused_mem from somewhere. The 
idea to not expose the early memory allocator on ARM is avoid to have an 
implementation with may not fully work on ARM because of known missing 
pieces.



And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.


I would be happy to review any patches addressing the TODOs.


This, I'm sorry, gets me to raise another question: When is this
finally going to happen? Shared EFI code was introduced for 4.5,
and we're now looking to release 4.8 still with runtime support
unimplemented on ARM. How much longer is this going to take?


Xen is a community project, features are added by contributors when they 
need it. I personally don't have any bandwidth to work on EFI runtimes 
services at the moment (note that the item is in my TODO list as a low 
priority).


I welcome any contribution on EFI runtime support for ARM and will be 
happy to review any series.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3] gcov: add new interface and 3.4 and 4.7 format support

[Jan Beulich]

>>> On 11.10.16 at 12:31,  wrote:
> --- /dev/null
> +++ b/xen/common/gcov/gcc_4_7.c
> @@ -0,0 +1,205 @@
> +/*
> + *  This code provides functions to handle gcc's profiling data format
> + *  introduced with gcc 4.7.
> + *
> + *  This file is based heavily on gcc_3_4.c file.
> + *
> + *  For a better understanding, refer to gcc source:
> + *  gcc/gcov-io.h
> + *  libgcc/libgcov.c
> + *
> + *  Uses gcc-internal data definitions.
> + *
> + *  Imported from Linux and modified for Xen by
> + *Wei Liu 
> + */
> +
> +#include 
> +
> +#include "gcov.h"
> +
> +#if GCC_VERSION < 40700
> +#error "Wrong version of GCC used to compile gcov"
> +#endif
> +
> +#if (__GNUC__ > 5) || (__GNUC__ == 5 && __GNUC_MINOR__ >= 1)
> +#define GCOV_COUNTERS   10
> +#elif __GNUC__ == 4 && __GNUC_MINOR__ >= 9
> +#define GCOV_COUNTERS   9
> +#else
> +#define GCOV_COUNTERS   8
> +#endif

I'm sorry for not having pointed this out on v2 (I had noticed it,
but then didn't finish analyzing the situation), but I'm afraid this
together with ...

> +struct gcov_info {
> +unsigned int version;
> +struct gcov_info *next;
> +unsigned int stamp;
> +const char *filename;
> +void (*merge[GCOV_COUNTERS])(gcov_type *, unsigned int);
> +unsigned int n_functions;
> +struct gcov_fn_info **functions;
> +};

... this structure's trailing fields actually getting used by the code
won't work well when changing compiler versions without cleaning
the tree. I think instead you need thin gcc_5.c and gcc_4_9.c
#define-ing their GCOV_COUNTERS and then #include-ing this
shared source file. Plus btw, I don't think gcc 5.0.x (the
development variant of 5.x) would use anything different from
5.1.x or 5.2.x; in fact use of __GNUC_MINOR__ should not
normally be necessary anymore with gcc 5+.

And then - how is all of this supposed to be working in conjucntion
with live patching, where the patch may have been created by yet
another compiler version?

Jan


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

Re: [Xen-devel] [PATCH v2 17/30] xen/x86: setup PVHv2 Dom0 CPUs

[Jan Beulich]

>>> On 12.10.16 at 13:06,  wrote:
> On Thu, Oct 06, 2016 at 09:20:07AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57,  wrote:
>> > The logic used to setup the CPUID leaves is extremely simplistic (and
>> > probably wrong for hardware different than mine). I'm not sure what's the
>> > best way to deal with this, the code that currently sets the CPUID leaves
>> > for HVM guests lives in libxc, maybe moving it xen/common would be better?
>> 
>> Yeah, a pre-populated array of leaves certainly won't do.
> 
> This is what current HVM guests use, and TBH, I would prefer to don't 
> diverge from HVM. Would it make sense to leave this as-is, until all this 
> cpuid stuff is fixed? (IIRC Andrew is still working on this).

Leaving it as is makes little sense to me. What would make sense
is to make Andrew's work a prereq for this patch.

Jan


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

Re: [Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 11.10.16 at 16:06,  wrote:
> On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >>> On 27.09.16 at 17:57,  wrote:
>> > + * VM86 TSS. Note that after this not all e820 regions will be aligned
>> > + * to PAGE_SIZE.
>> > + */
>> > +for ( i = 1; i <= d->arch.nr_e820; i++ )
>> > +{
>> > +entry = >arch.e820[d->arch.nr_e820 - i];
>> > +if ( entry->type != E820_RAM ||
>> > + entry->size < PAGE_SIZE + HVM_VM86_TSS_SIZE )
>> > +continue;
>> > +
>> > +entry->size -= PAGE_SIZE + HVM_VM86_TSS_SIZE;
>> > +gaddr = entry->addr + entry->size;
>> > +break;
>> > +}
>> > +
>> > +if ( gaddr == 0 || gaddr < MB(1) )
>> > +{
>> > +printk("Unable to find memory to stash the identity map and 
>> > TSS\n");
>> > +return -ENOMEM;
>> 
>> One function up you panic() on error - please be consistent. Also for
>> one of the other patches I think we figured that the TSS isn't really
>> required, so please only warn in that case.
> 
> The allocation is done together for the ident PT and the TSS, and while 
> the TSS is not mandatory the identity page-table is (or else Dom0 kernel 
> won't boot at all on this kind of systems). In any case, it's almost 
> impossible for this allocation to fail (because Xen is not actually 
> allocating memory, just stealing a part of a RAM region that has already 
> been populated).

All fine, but I continue to think errors should be dealt with in a
consistent manner (no matter how [un]likely they are), and
warnings better get issued when there's any meaningful impact
due to whatever triggers the warning. Albeit - having looked at
the full patch again - it looks like I was wrong with naming this
"warning": Both here and further down you return an error if any
of the steps failed. The allocation being done in one go is fine to
be an error; failure of the mapping of the non-required TSS, otoh,
shouldn't cause the loading of Dom0 to fail (and I think that is
where I've been unsure the printk() is warranted).

Jan


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

Re: [Xen-devel] [PATCH v2 15/30] xen/x86: populate PVHv2 Dom0 physical memory map

[Jan Beulich]

>>> On 11.10.16 at 16:01,  wrote:
> On Tue, Oct 04, 2016 at 05:16:09AM -0600, Jan Beulich wrote:
>> >>> On 04.10.16 at 11:12,  wrote:
>> > On Fri, Sep 30, 2016 at 09:52:56AM -0600, Jan Beulich wrote:
>> >> >>> On 27.09.16 at 17:57,  wrote:
>> >> > @@ -336,7 +343,8 @@ static unsigned long __init compute_dom0_nr_pages(
>> >> >  avail -= dom0_paging_pages(d, nr_pages);
>> >> >  }
>> >> >  
>> >> > -if ( (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
>> >> > +if ( is_pv_domain(d) &&
>> >> > + (parms->p2m_base == UNSET_ADDR) && (dom0_nrpages <= 0) &&
>> >> 
>> >> Perhaps better to simply force parms->p2m_base to UNSET_ADDR
>> >> earlier on?
>> > 
>> > p2m_base is already unconditionally set to UNSET_ADDR for PVHv2 domains, 
>> > hence the added is_pv_domain check in order to make sure that PVHv2 guests 
>> > don't get into that branch, which AFAICT is only relevant to PV guests.
>> 
>> This reads contradictory: If it's set to UNSET_ADDR, why the extra
>> check?
> 
> On PVHv2 p2m_base == UNSET_ADDR already, so the extra check is to make sure 
> PVHv2 guests don't execute the code inside of the if condition, which is 
> for classic PV guests (note that the check is not against != UNSET_ADDR). Or 
> maybe I'm missing something?

No, I have to apologize - I read things the wrong way round.
Thanks for bearing with me.

>> >> > @@ -1657,15 +1679,238 @@ out:
>> >> >  return rc;
>> >> >  }
>> >> >  
>> >> > +/* Populate an HVM memory range using the biggest possible order. */
>> >> > +static void __init hvm_populate_memory_range(struct domain *d, 
>> >> > uint64_t start,
>> >> > + uint64_t size)
>> >> > +{
>> >> > +static unsigned int __initdata memflags = 
>> >> > MEMF_no_dma|MEMF_exact_node;
>> >> > +unsigned int order;
>> >> > +struct page_info *page;
>> >> > +int rc;
>> >> > +
>> >> > +ASSERT(IS_ALIGNED(size, PAGE_SIZE) && IS_ALIGNED(start, 
>> >> > PAGE_SIZE));
>> >> > +
>> >> > +order = MAX_ORDER;
>> >> > +while ( size != 0 )
>> >> > +{
>> >> > +order = min(get_order_from_bytes_floor(size), order);
>> >> > +page = alloc_domheap_pages(d, order, memflags);
>> >> > +if ( page == NULL )
>> >> > +{
>> >> > +if ( order == 0 && memflags )
>> >> > +{
>> >> > +/* Try again without any memflags. */
>> >> > +memflags = 0;
>> >> > +order = MAX_ORDER;
>> >> > +continue;
>> >> > +}
>> >> > +if ( order == 0 )
>> >> > +panic("Unable to allocate memory with order 0!\n");
>> >> > +order--;
>> >> > +continue;
>> >> > +}
>> >> 
>> >> Is it not possible to utilize alloc_chunk() here?
>> > 
>> > Not really, alloc_chunk will do a ceil calculation of the number of needed 
>> > pages, which means we end up allocating bigger chunks than needed and then 
>> > free them. I prefer this approach, since we always request the exact 
>> > memory 
>> > that's required, so there's no need to free leftover pages.
>> 
>> Hmm, in that case at least some of the shared logic would be nice to
>> get abstracted out.
> 
> TBH, I don't see much benefit in that, alloc_chunk works fine for PV guests 
> because Xen ends up walking the list of returned pages and mapping them one 
> to one. This is IMHO not what should be done for PVH guests, and instead the 
> caller needs to know the actual order of the allocated chunk, so it can pass 
> it to guest_physmap_add_page. ATM it's a very simple function that's clear, 
> if I start mixing up bits of alloc_chunk it's going to get more complex, and 
> I would like to avoid that, so that PVH Dom0 build doesn't end up like 
> current PV Dom0 build.

Hmm - I did say "abstract out", not "re-use". The way how memflags
get set and decreasing orders get tried in your code looks suspiciously
similar to what alloc_chunk() does.

>> > In the RFC series we also spoke about placing the MADT in a different 
>> > position that the native one, which would mean that we would end up 
>> > stealing 
>> > some space from a RAM region in order to place it, so that we wouldn't 
>> > have 
>> > to do this accounting.
>> 
>> Putting the new MADT at the same address as the old one won't work
>> anyway, again because possibly vCPU-s > pCPU-s.
> 
> Yes, although from my tests doing CPU over-allocation on HVM guests works 
> very badly.

Interesting. I didn't try recently, but I recall having tried a longer
while ago without seeing severe issues.

Jan

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

[Xen-devel] Outreachy golang bindings planning

[George Dunlap]

Hey Ronald,

My ultimate vision for the libxl golang project is to have the following:

- Golang bindings for all core libxl functionality
- A test program which exersises as much of that functionality as is
reasonable

The C libxl library has two components: parts that are written by hand
(such as libxl.h and libxl_*.c), and parts that are generated
programmatically by the IDL compiler (such as _libxl_types.h and
_libxl_types.c).  I think the end goal should be to extend the IDL to
generate at least the Golang types, and probably a lot of the "helper"
methods as well (such as ${TYPE}.String() or ${TYPE}.FromString()).

But before diving into the I think it makes sense to first implement a
core set of functionality by hand, to see what the shape of the library
looks like, then implement the type-generation part of the IDL.  Other
things we might do with the IDL, such as generation of utility methods,
we can add in at later points as well.

At the bottom of this mail, I've got all the libxl functions from
libxl.h sorted into what seems to me a useful order to start working on
things.

I list here the "headers".  This is a *lot* of functionality; I very
greatly doubt that it will be possible to get all of it implemented and
tested during the internship.  I'd much rather have a decent core set of
functionality with a really good testing than attempt to get all the
functions "implemented" in a way which nobody knows if it works.

If we can get the basic IDL working, and stuff implemented and
well-tested through "Secondary host operations", I think the internship
will have been a solid success.  If we get through "Devices: PCI", I
think it will have been a wild success. :-)

Thanks,
 -George

---
(Headers only)

# Libxl and host-related functionality

# Primary domain operations: Create / shutdown / destroy

(This will probably take a fairly large chunk of time to, as we run
across most of the design / architectural decisions with the bindings.
And at the end you'll only be able to start VMs with no devices!)

# Devices: Disk

# Devices: Network

(At this point, we have the core VM functionality.)

# Secondary domain operations: manipulate, suspend / resume / reset

# Secondary host operations

# More domain operations

# Advanced host config

# Devices: USB

# Devices: PCI

# Devices: VFB

# Devices: Channels

# Advanced domain config

# Devices: VKB

# Devices: VTPM

# PSR

# Flask

# Domain operations: Exec helper functions

# Miscellanious behavior

---
(Headers and functions)

# Libxl and host-related functionality

const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx);

int libxl_get_max_cpus(libxl_ctx *ctx);
int libxl_get_online_cpus(libxl_ctx *ctx);
int libxl_get_max_nodes(libxl_ctx *ctx);

int libxl_get_free_memory(libxl_ctx *ctx, uint64_t *memkb);

int libxl_get_physinfo(libxl_ctx *ctx, libxl_physinfo *physinfo);


# Primary domain operations: Create (with disk / network), shutdown /
destroy

int libxl_domain_create_new(libxl_ctx *ctx, libxl_domain_config *d_config,
uint32_t *domid,
const libxl_asyncop_how *ao_how,
const libxl_asyncprogress_how *aop_console_how)
LIBXL_EXTERNAL_CALLERS_ONLY;


int libxl_domain_pause(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_unpause(libxl_ctx *ctx, uint32_t domid);


int libxl_domain_shutdown(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_reboot(libxl_ctx *ctx, uint32_t domid);
int libxl_domain_destroy(libxl_ctx *ctx, uint32_t domid,
 const libxl_asyncop_how *ao_how)
 LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_domain_info(libxl_ctx*, libxl_dominfo *info_r,
  uint32_t domid);

libxl_dominfo * libxl_list_domain(libxl_ctx*, int *nb_domain_out);

libxl_vcpuinfo *libxl_list_vcpu(libxl_ctx *ctx, uint32_t domid,
int *nb_vcpu, int *nr_cpus_out);

int libxl_console_get_tty(libxl_ctx *ctx, uint32_t domid, int cons_num,
  libxl_console_type type, char **path);
int libxl_primary_console_get_tty(libxl_ctx *ctx, uint32_t domid_vm,
char **path);

# Devices: Disk

int libxl_device_disk_add(libxl_ctx *ctx, uint32_t domid,
  libxl_device_disk *disk,
  const libxl_asyncop_how *ao_how)
  LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_remove(libxl_ctx *ctx, uint32_t domid,
 libxl_device_disk *disk,
 const libxl_asyncop_how *ao_how)
 LIBXL_EXTERNAL_CALLERS_ONLY;
int libxl_device_disk_destroy(libxl_ctx *ctx, uint32_t domid,
  libxl_device_disk *disk,
  const libxl_asyncop_how *ao_how)
  LIBXL_EXTERNAL_CALLERS_ONLY;

libxl_device_disk *libxl_device_disk_list(libxl_ctx *ctx, uint32_t
domid, int *num);
int 

[Xen-devel] [linux-3.18 test] 101389: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-multivcpu 14 guest-saverestore   fail REGR. vs. 101000
 test-amd64-i386-pair  9 xen-boot/src_hostfail REGR. vs. 101000
 test-amd64-i386-pair 10 xen-boot/dst_hostfail REGR. vs. 101000
 test-amd64-i386-qemut-rhel6hvm-intel  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-freebsd10-i386  6 xen-boot   fail REGR. vs. 101000
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1  6 xen-boot fail REGR. vs. 101000
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 
101000

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

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

version targeted for testing:
 linux3cab355c2ff3a781b6ebe9d1a25bd4ebc1207430
baseline version:
 linuxa8e202812b52b88e2a33d52687b3b0260706231a

Last test of basis   101000  2016-09-18 07:47:20 Z   24 days
Testing same since   101389  2016-10-12 06:50:56 Z0 days1 attempts


People who touched revisions under test:
  Acked-by: Arnd Bergmann 
  Akshay Bhat 
  Al Viro 
  Alan Stern 
  Andrew Morton 
  Anson Huang 
  Ard Biesheuvel 

Re: [Xen-devel] [PATCH v9 06/13] efi: create new early memory allocator

[Jan Beulich]

>>> On 11.10.16 at 15:39,  wrote:
> Hello Jan,
> 
> On 06/10/16 13:21, Jan Beulich wrote:
> On 05.10.16 at 20:30,  wrote:
>>> On 30/09/2016 02:46, Jan Beulich wrote:
>>> On 29.09.16 at 23:42,  wrote:
> +#else
> +static void __init free_ebmalloc_unused_mem(void)
> +{
> +}
> +#endif

 Did you build test this for ARM? The function ought to be unused,
 as ...

> @@ -1251,6 +1301,8 @@ void __init efi_init_memory(void)
>  } *extra, *extra_head = NULL;
>  #endif
>
> +free_ebmalloc_unused_mem();

 ... the whole function here doesn't get built on ARM.

 Julien - we're still awaiting your input on general aspects here.
>>>
>>> efi_init_memory would need to be called during Xen boot on ARM. I am not
>>> sure where as I we don't yet have runtime support on ARM.
>>>
>>> Other than that, the patch looks good to me.
>>
>> But that wasn't the question. My goal is to have as little code
>> inside #ifndef CONFIG_ARM as possible, and hence I'd like to have
>> as much of this new code as possible outside of such conditionals.
>> So the question really is whether that alternative approach would
>> be fine with you, or what problems you might see.
> 
> I am not sure to get it. The current approach looks good to me, however, 
> the implementation should not be exposed to ARM until all the TODOs 
> mentioned by Daniel are fixed.

Which is precisely the opposite of what I'm aiming at. Once again:
Don't you think it is desirable to keep the #ifndef CONFIG_ARM
instances to cover as little code as possible? Not all of the named
TODOs really need to be addressed in order to compile most of
what comprises this new allocator; in fact none of them really
needs addressing:
- if the size estimation turns out to low once ARM starts actually
  using this, let's just bump it (perhaps by making it a per-arch
  constant),
- if the section chosen needs to be different (which it really
  shouldn't be), let's simply adjust it,
- as we've already figured there's no need for the stub
  free_ebmalloc_unused_mem() right now anyway.

And then (as another alternative) we have the option of ARM
simply defining EBMALLOC_SIZE to zero for the time being. That
would eliminate the need to actually call free_ebmalloc_unused_mem()
and turn the other two items into non-issues.

> I would be happy to review any patches addressing the TODOs.

This, I'm sorry, gets me to raise another question: When is this
finally going to happen? Shared EFI code was introduced for 4.5,
and we're now looking to release 4.8 still with runtime support
unimplemented on ARM. How much longer is this going to take?

Jan


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