[Xen-devel] [libvirt test] 145589: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 145511
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 145511
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 145511
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 145511

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7
baseline version:
 libvirt  db5d04991133b2bdff1fe26ebe2bd1069ac8b7a4

Last test of basis   145511  2020-01-03 04:18:44 Z2 days
Testing same since   145542  2020-01-04 04:18:55 Z1 days2 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Julio Faracco 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 343 lines long.)

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

Re: [Xen-devel] Xen crash on S3 resume on 4.13 and unstable if any CPU is re-offlined

[Jürgen Groß]

On 05.01.20 08:39, Marek Marczykowski-Górecki wrote:

On Sun, Jan 05, 2020 at 12:42:30AM +, Andrew Cooper wrote:

On 04/01/2020 15:30, Marek Marczykowski-Górecki wrote:

Hi,

I have a reliable crash on resume from S3. I can reproduce it on both
real hardware and nested within KVM, although call traces are different
between those platforms. In any case, it happens only if some CPU is to
be re-offlined after resume (smt=off and/or maxcpus=... options).

I think the crash from the real hardware gives more clues, but the one
from qemu may also be interesting, maybe it's even another bug?

The crash message (full console log attached):

(XEN) mce_intel.c:772: MCA Capability: firstbank 0, extended MCE MSR 0, BCAST, 
CMCI
(XEN) CPU0 CMCI LVT vector (0xf2) already installed
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) [ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:0
(XEN) RIP:e008:[] 
schedule.c#cpu_schedule_callback+0xea/0x1a1
(XEN) RFLAGS: 00010202   CONTEXT: hypervisor
(XEN) rax:    rbx: 82d080453348   rcx: 82d080584020
(XEN) rdx: 00339b66e000   rsi: 8005   rdi: 82d080453340
(XEN) rbp: 8300ca45fd68   rsp: 8300ca45fd68   r8:  0004
(XEN) r9:     r10:    r11: 8000
(XEN) r12: 82d080453340   r13: 82d080453200   r14: 8005
(XEN) r15: 8000   cr0: 8005003b   cr4: 000426e0
(XEN) cr3: ca44f000   cr2: 0008
(XEN) fsb: 79d5e4f9e740   gsb: 88813560   gss: 
(XEN) ds: 0018   es: 0010   fs: b800   gs: 0010   ss:    cs: e008
(XEN) Xen code around  
(schedule.c#cpu_schedule_callback+0xea/0x1a1):
(XEN)  48 8b 14 d1 48 8b 04 02 <48> 8b 48 08 48 85 c9 74 64 48 8b 05 b9 c3 32 00
(XEN) Xen stack trace from rsp=8300ca45fd68:
(XEN)8300ca45fdb0 82d080221289 8300ca45fdd8 0001
(XEN) ffef 8300ca45fe00 0001
(XEN)0200 8300ca45fdc8 82d080203476 0001
(XEN)8300ca45fdf0 82d080203550  0001
(XEN) 8300ca45fe20 82d080203999 8300ca45fef8
(XEN) 0003 000426e0 8300ca45fe58
(XEN)82d0802e4240 83042896c5f0 83041bb4d000 
(XEN) 83041bb73000 8300ca45fe78 82d08020828f
(XEN)83041bb4d1b8 82d080567210 8300ca45fe90 82d08023fd39
(XEN)82d080567200 8300ca45fec0 82d08024001a 
(XEN)82d080567210 82d08056d980 82d080584020 8300ca45fef0
(XEN)82d08027247a 83041bbb2000 83041bb4d000 83041bbb3000
(XEN) 8300ca45fd98 0003 820ae496
(XEN)0003  2003 822c6868
(XEN)0246 3403  
(XEN) 810010ea 2003 0010
(XEN)deadbeefdeadf00d 0100 810010ea e033
(XEN)0246 c900011abbe8 e02b 003b4a890045ffe0
(XEN)003b4ddf00098fa8 003b4e030001 003b499d0045ffe0 e010
(XEN)83041bbb2000  000426e0 
(XEN) Xen call trace:
(XEN)[] R schedule.c#cpu_schedule_callback+0xea/0x1a1
(XEN)[] F notifier_call_chain+0x6b/0x96
(XEN)[] F cpu.c#cpu_notifier_call_chain+0x1b/0x33
(XEN)[] F cpu_down+0x5e/0x15c
(XEN)[] F enable_nonboot_cpus+0x113/0x1fb
(XEN)[] F power.c#enter_state_helper+0x107/0x51b
(XEN)[] F 
domain.c#continue_hypercall_tasklet_handler+0x8b/0xb7
(XEN)[] F tasklet.c#do_tasklet_work+0x76/0xa9
(XEN)[] F do_tasklet+0x58/0x8a
(XEN)[] F domain.c#idle_loop+0x40/0x96
(XEN)
(XEN) Pagetable walk from 0008:
(XEN)  L4[0x000] = 00041bbff063 
(XEN)  L3[0x000] = 00041bbfe063 
(XEN)  L2[0x000] = 00041bbfd063 
(XEN)  L1[0x000] =  
(XEN)
(XEN) 
(XEN) Panic on CPU 0:
(XEN) FATAL PAGE FAULT
(XEN) [error_code=]
(XEN) Faulting linear address: 0008
(XEN) 

And the one from qemu:

(XEN) mce_intel.c:772: MCA Capability: firstbank 1, extended MCE MSR 0, SER
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs  ...
(XEN) Assertion 'c2rqd(ops, sched_unit_master(unit)) == svc->rqd' failed at 
sched_credit2.c:2137
(XEN) [ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]
(XEN) CPU:1
(XEN) RIP:e008:[] 
sched_credit2.c#csched2_unit_wake+0x174/0x176
(XEN) RFLAGS: 00010097   CONTEXT: hypervisor (d0v0)
(XEN) rax: 83013a7313e8   rbx: 83013a6bdf40   rcx: 

[Xen-devel] [PATCH] libxl: create backend/ xenstore dir for driver domains

[Marek Marczykowski-Górecki]

Cleaning up backend xenstore entries is a responsibility of the backend.
When backend lives outside of dom0, the domain needs proper permissions
to do it. Normally it is given permission to remove the device dir
itself, but not the dir containing it (named after frontend ID). After a
whole those empty leftover directories accumulate to the point xenstore
returning E2BIG on listing them.

Fix this by giving backend domain write access also to backend/
directory itself when c_info->driver_domain option is set. The code
removing relevant dir is already there (just lacked permissions to do so).

Note this also allows the backend domain to create new entries,
pretending to host backend devices it don't have. But since libxl uses
/libxl/ xenstore dir for this information (still outside of backend
domain control), this shouldn't be an issue.

Signed-off-by: Marek Marczykowski-Górecki 
---
 tools/libxl/libxl_create.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index a6d40b753e..38ca9b85a4 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -763,6 +763,13 @@ retry_transaction:
  */
 libxl__xs_mknod(gc, t, GCSPRINTF("%s/device-model", dom_path), rwperm,
 ARRAY_SIZE(rwperm));
+
+/*
+ * Create a local "backend" directory for each guest, writable by that
+ * guest, to allow it properly cleanup removed devices
+ */
+libxl__xs_mknod(gc, t, GCSPRINTF("%s/backend", dom_path), rwperm,
+ARRAY_SIZE(rwperm));
 }
 
 vm_list = libxl_list_vm(ctx, &nb_vm);
-- 
2.21.0


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

Re: [Xen-devel] Xen crash on S3 resume on 4.13 and unstable if any CPU is re-offlined

[Marek Marczykowski-Górecki]

On Sun, Jan 05, 2020 at 09:25:42AM +0100, Jürgen Groß wrote:
> On 05.01.20 08:39, Marek Marczykowski-Górecki wrote:
> > On Sun, Jan 05, 2020 at 12:42:30AM +, Andrew Cooper wrote:
> > > On 04/01/2020 15:30, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > > 
> > > > I have a reliable crash on resume from S3. I can reproduce it on both
> > > > real hardware and nested within KVM, although call traces are different
> > > > between those platforms. In any case, it happens only if some CPU is to
> > > > be re-offlined after resume (smt=off and/or maxcpus=... options).
> > > > 
> > > > I think the crash from the real hardware gives more clues, but the one
> > > > from qemu may also be interesting, maybe it's even another bug?
> > > > 
> > > > The crash message (full console log attached):
...
> > > > (XEN) Xen call trace:
> > > > (XEN)[] R 
> > > > schedule.c#cpu_schedule_callback+0xea/0x1a1
> > > > (XEN)[] F notifier_call_chain+0x6b/0x96
> > > > (XEN)[] F cpu.c#cpu_notifier_call_chain+0x1b/0x33
> > > > (XEN)[] F cpu_down+0x5e/0x15c
> > > > (XEN)[] F enable_nonboot_cpus+0x113/0x1fb
> > > > (XEN)[] F power.c#enter_state_helper+0x107/0x51b
> > > > (XEN)[] F 
> > > > domain.c#continue_hypercall_tasklet_handler+0x8b/0xb7
> > > > (XEN)[] F tasklet.c#do_tasklet_work+0x76/0xa9
> > > > (XEN)[] F do_tasklet+0x58/0x8a
> > > > (XEN)[] F domain.c#idle_loop+0x40/0x96
...
> > > > And the one from qemu:
> > > > 
> > > > (XEN) mce_intel.c:772: MCA Capability: firstbank 1, extended MCE MSR 0, 
> > > > SER
> > > > (XEN) Finishing wakeup from ACPI S3 state.
> > > > (XEN) Enabling non-boot CPUs  ...
> > > > (XEN) Assertion 'c2rqd(ops, sched_unit_master(unit)) == svc->rqd' 
> > > > failed at sched_credit2.c:2137
> > > > (XEN) [ Xen-4.14-unstable  x86_64  debug=y   Not tainted ]
> > > > (XEN) CPU:1
> > > > (XEN) RIP:e008:[] 
> > > > sched_credit2.c#csched2_unit_wake+0x174/0x176
> > > > (XEN) RFLAGS: 00010097   CONTEXT: hypervisor (d0v0)
> > > > (XEN) rax: 83013a7313e8   rbx: 83013a6bdf40   rcx: 
> > > > 0051
> > > > (XEN) rdx: 83013a731160   rsi: 83013a7310e0   rdi: 
> > > > 0003
> > > > (XEN) rbp: 83013a6f7d98   rsp: 83013a6f7d78   r8:  
> > > > deadbeefdeadf00d
> > > > (XEN) r9:  deadbeefdeadf00d   r10:    r11: 
> > > > 
> > > > (XEN) r12: 83013a6bc7e0   r13: 82d08043e720   r14: 
> > > > 0003
> > > > (XEN) r15: 0003c5ffecac   cr0: 80050033   cr4: 
> > > > 0660
> > > > (XEN) cr3: 4b005000   cr2: 
> > > > (XEN) fsb: 7751649f4740   gsb: 888134a0   gss: 
> > > > 
> > > > (XEN) ds:    es:    fs:    gs:    ss: e010   cs: e008
> > > > (XEN) Xen code around  
> > > > (sched_credit2.c#csched2_unit_wake+0x174/0x176):
> > > > (XEN)  ef e8 1e c1 ff ff eb a7 <0f> 0b 55 48 89 e5 41 57 41 56 41 55 41 
> > > > 54 53 48
> > > > (XEN) Xen stack trace from rsp=83013a6f7d78:
> > > > (XEN)83013a6a3000 83013a6bdf40 83013a6bdf40 
> > > > 83013a7313e8
> > > > (XEN)83013a6f7de8 82d0802391f8 0202 
> > > > 83013a7313e8
> > > > (XEN)83013a6c1018 0001  
> > > > 
> > > > (XEN)83013a6c1018 83013a6a3000 83013a6f7e58 
> > > > 82d08020906c
> > > > (XEN)82d08035d3d4 82d08035d3c8 82d08035d3d4 
> > > > 82d08035d3c8
> > > > (XEN)82d08035d3d4 82d08035d3c8 82d08035d3d4 
> > > > 83013a6f7ef8
> > > > (XEN)0180 83013a6aa000 deadbeefdeadf00d 
> > > > 0003
> > > > (XEN)83013a6f7ee8 82d0803570c7 0001 
> > > > 0001
> > > > (XEN) deadbeefdeadf00d deadbeefdeadf00d 
> > > > 82d08035d3c8
> > > > (XEN)82d08035d3d4 82d08035d3c8 82d08035d3d4 
> > > > 82d08035d3c8
> > > > (XEN)82d08035d3d4 83013a6aa000  
> > > > 
> > > > (XEN)  7cfec59080e7 
> > > > 82d08035d432
> > > > (XEN)00015120 0001  
> > > > 88813024a540
> > > > (XEN) 0001 0246 
> > > > 0014
> > > > (XEN)8880bf7db000 ea0004be4508 0018 
> > > > 8100130a
> > > > (XEN) 0001 0001 
> > > > 0100
> > > > (XEN)8100130a e033 0246 
> > > > c9c97c98
> > > > (XEN)e02b   
> > > > 
> > > > (XEN) e011 83013a6aa000 
> > > > 0030ba196000
> > > > (XEN)0660  00013a6e2000 
> > > > 0400
> > > > (XEN) Xen call trace:
> > > > (XEN)[] R 
> > > > sched_credi

[Xen-devel] [xen-unstable-coverity test] 145603: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 xen  7b3c5b70a32303b46d0d051e695f18d72cce5ed0
baseline version:
 xen  3a13ac3ad4d3ef399fe2c85fb09fcb7ab1cdd140

Last test of basis   145355  2019-12-29 09:18:38 Z7 days
Testing same since   145603  2020-01-05 09:19:44 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chad Dougherty 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Paul Durrant 
  Roger Pau Monne 
  Roger Pau Monné 
  Wei Liu 
  Wei Liu 

jobs:
 coverity-amd64   pass



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

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

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

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


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   3a13ac3ad4..7b3c5b70a3  7b3c5b70a32303b46d0d051e695f18d72cce5ed0 -> 
coverity-tested/smoke

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

Re: [Xen-devel] [PATCH v6 07/12] livepatch: Add per-function applied/reverted state tracking marker

[Andrew Cooper]

On 26/11/2019 10:07, Pawel Wieczorkiewicz wrote:
> @@ -1274,6 +1297,9 @@ static void livepatch_do_action(void)
>  else
>  rc = apply_payload(data);
>  
> +if ( !was_action_consistent(data, rc ? LIVEPATCH_FUNC_NOT_APPLIED : 
> LIVEPATCH_FUNC_APPLIED) )
> +panic("livepatch: partially applied payload '%s'!\n", 
> data->name);
> +
>  if ( rc == 0 )
>  apply_payload_tail(data);
>  break;
> @@ -1288,6 +1314,9 @@ static void livepatch_do_action(void)
>  else
>  rc = revert_payload(data);
>  
> +if ( !was_action_consistent(data, rc ? LIVEPATCH_FUNC_APPLIED : 
> LIVEPATCH_FUNC_NOT_APPLIED) )
> +panic("livepatch: partially reverted payload '%s'!\n", 
> data->name);
> +
>  if ( rc == 0 )
>  revert_payload_tail(data);
>  break;
> @@ -1309,6 +1338,9 @@ static void livepatch_do_action(void)
>  else
>  other->rc = revert_payload(other);
>  
> +if ( !was_action_consistent(other, rc ? LIVEPATCH_FUNC_APPLIED : 
> LIVEPATCH_FUNC_NOT_APPLIED) )
> +panic("livepatch: partially reverted payload '%s'!\n", 
> other->name);
> +
>  if ( other->rc == 0 )
>  revert_payload_tail(other);

Coverity highlights that this contains dead code.

The LIVEPATCH_ACTION_REPLACE case, unlike all others, uses other->rc,
which means the rc ? : check will always pass LIVEPATCH_FUNC_APPLIED
into was_action_consistent(), due to the rc = 0 at the head of the case
block.

If this were the only problem, switching rc to other->rc might be ok,
but there look to be other confusions in the surrounding code.  Would
you mind looking over the whole block of code for correct error handling?

For any resulting patch, the Coverity ID is 1457467

~Andrew

>  else
> @@ -1329,6 +1361,9 @@ static void livepatch_do_action(void)
>  else
>  rc = apply_payload(data);
>  
> +if ( !was_action_consistent(data, rc ? 
> LIVEPATCH_FUNC_NOT_APPLIED : LIVEPATCH_FUNC_APPLIED) )
> +panic("livepatch: partially applied payload '%s'!\n", 
> data->name);
> +
>  if ( rc == 0 )
>  apply_payload_tail(data);
>  }
>


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

[Xen-devel] [PATCH] xen/sched: fix resuming from S3 with smt=0

[Juergen Gross]

When resuming from S3 and smt=0 or maxcpus= are specified we must not
do anything in cpu_schedule_callback(). This is not true today for
taking down a cpu during resume.

If anything goes wrong during resume all the scheduler related error
handling is in cpupool.c, so we can just bail out early from
cpu_schedule_callback() when suspending or resuming.

This fixes commit 0763cd2687897b55e7 ("xen/sched: don't disable
scheduler on cpus during suspend").

Reported-by: Marek Marczykowski-Górecki 
Tested-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 xen/common/schedule.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index e70cc70a65..54a07ff9e8 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -2562,6 +2562,13 @@ static int cpu_schedule_callback(
 unsigned int cpu = (unsigned long)hcpu;
 int rc = 0;
 
+/*
+ * All scheduler related suspend/resume handling needed is done in
+ * cpupool.c.
+ */
+if ( system_state > SYS_STATE_active )
+return NOTIFY_DONE;
+
 rcu_read_lock(&sched_res_rculock);
 
 /*
@@ -2589,8 +2596,7 @@ static int cpu_schedule_callback(
 switch ( action )
 {
 case CPU_UP_PREPARE:
-if ( system_state != SYS_STATE_resume )
-rc = cpu_schedule_up(cpu);
+rc = cpu_schedule_up(cpu);
 break;
 case CPU_DOWN_PREPARE:
 rcu_read_lock(&domlist_read_lock);
@@ -2598,13 +2604,10 @@ static int cpu_schedule_callback(
 rcu_read_unlock(&domlist_read_lock);
 break;
 case CPU_DEAD:
-if ( system_state == SYS_STATE_suspend )
-break;
 sched_rm_cpu(cpu);
 break;
 case CPU_UP_CANCELED:
-if ( system_state != SYS_STATE_resume )
-cpu_schedule_down(cpu);
+cpu_schedule_down(cpu);
 break;
 default:
 break;
-- 
2.16.4


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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 145538

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail in 145538 blocked in 
145586
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 145538
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 145538
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 145538
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 145538
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 145538
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 145538
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 145538
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 145538
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 145538
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 145538
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  7b3c5b70a32303b46d0d051e695f18d72cce5ed0
baseline version:
 xen  7b3c5b70a32303b46d0d051e695f18d72cce5ed0

Last test of basis   145586  2020-01-05 01:51:38 Z0 days
Testing same since  (not found) 0 attempts

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

[Xen-devel] [libvirt bisection] complete build-arm64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-arm64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  810613a60efe3924c536b3663246900bc08910a5
  Bug not present: f6a750e678fb0ca3898cba08b6698f079008924c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145619/


  commit 810613a60efe3924c536b3663246900bc08910a5
  Author: Daniel P. Berrangé 
  Date:   Mon Dec 23 15:37:26 2019 +
  
  src: replace strptime()/timegm()/mktime() with GDateTime APIs set
  
  All places where we use strptime/timegm()/mktime() are handling
  conversion of dates in a format compatible with ISO 8601, so we
  can use the GDateTime APIs to simplify code.
  
  Reviewed-by: Fabiano Fidêncio 
  Signed-off-by: Daniel P. Berrangé 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-arm64-libvirt.libvirt-build 
--summary-out=tmp/145619.bisection-summary --basis-template=145511 
--blessings=real,real-bisect libvirt build-arm64-libvirt libvirt-build
Searching for failure / basis pass:
 145589 fail [host=laxton0] / 145511 [host=laxton1] 145212 [host=rochester0] 
145173 ok.
Failure / basis pass flights: 145589 / 145173
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7 
7d069378921bfa0d7c7198ea177aac0a2440016f 
317d3eeb963a515e15a63fa356d8ebcda7041a51 
b948a496150f4ae4f656c0f0ab672608723c80e6 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Basis pass 546e1c112d6a0f97404c9b43ccb070ae7b6af538 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
317d3eeb963a515e15a63fa356d8ebcda7041a51 
caa917491a4bfb295d2afad86e4c34fd48e1f7b5 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
0cd791c499bdc698d14a24050ec56d60b45732e0
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#546e1c112d6a0f97404c9b43ccb070ae7b6af538-fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7
 
https://git.savannah.gnu.org/git/gnulib.git/#1f6fb368c04919243e2c70f2aa514a5f88e95309-7d069378921bfa0d7c7198ea177aac0a2440016f
 
https://gitlab.com/keycodemap/keycodemapdb.git#317d3eeb963a515e15a63fa356d8ebcda7041a51-317d3eeb963a515e15a63fa356d8ebcda7041a51
 git://xenbits.xen.org/osstest/ovmf.git#caa917491a4bfb295d2afad86e4c34fd48e1f7b\
 5-b948a496150f4ae4f656c0f0ab672608723c80e6 
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21b5a4aeb020f2a5e2c6503f906a9349dd2f069
 
git://xenbits.xen.org/xen.git#0cd791c499bdc698d14a24050ec56d60b45732e0-7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to 
remove them.

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to 
remove them.

Loaded 35070 nodes in revision graph
Searching for test results:
 145173 pass 546e1c112d6a0f97404c9b43ccb070ae7b6af538 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
317d3eeb963a515e15a63fa356d8ebcda7041a51 
caa917491a4bfb295d2afad86e4c34fd48e1f7b5 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
0cd791c499bdc698d14a24050ec56d60b45732e0
 145181 [host=rochester0]
 145212 [host=rochester0]
 145511 [host=laxton1]

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 14 guest-saverestore  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 145573
 test-armhf-armhf-xl-rtds 12 guest-startfail pass in 145573

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 145573 REGR. vs. 
144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  18 guest-localmigrate/x10 fail in 145573 like 144861
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 145573 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 145573 never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144861
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144861
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-

Re: [Xen-devel] [PATCH] x86/shim: Short circuit control/hardware checks in PV_SHIM_EXCLUSIVE builds

[Wei Liu]

On Fri, Jan 03, 2020 at 08:07:42PM +, Andrew Cooper wrote:
> The net diffstat is:
>   add/remove: 0/13 grow/shrink: 25/129 up/down: 6297/-20469 (-14172)
> 
> With the following objects/functions removed entirely:
>   iommu_hwdom_none   1   -  -1
>   hwdom_max_order4   -  -4
>   extra_hwdom_irqs   4   -  -4
>   ctldom_max_order   4   -  -4
>   acpi_c1e_quirk43   - -43
>   hvm_pirq_eoi  62   - -62
>   max_order 94   - -94
>   conring_puts 104   --104
>   propagate_node   119   --119
>   mmio_ro_emulate_ops  224   --224
>   mmcfg_intercept_ops  224   --224
>   pci_cfg_ok   295   --295
>   p2m_lock 546   --546
> 
> And the following reduced to stubs:
>   arch_iommu_hwdom_init852   2-850
>   p2m_add_foreign  880  16-864
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v2 8/8] x86/hyperv: setup VP assist page

[Wei Liu]

On Fri, Jan 03, 2020 at 04:08:25PM +, Wei Liu wrote:
> 
> Preemptively split out set_vp_assist page which will be used in the resume
> path.

After going through TLFS's section on reenlightenment, I don't think
this is necessary.

Wei.

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

[Xen-devel] [PATCH v3 5/5] x86/hyperv: setup VP assist page

[Wei Liu]

VP assist page is rather important as we need to toggle some bits in it
for efficient nested virtualisation.

Signed-off-by: Wei Liu 
---
v3:
1. Use xenheap page
2. Drop set_vp_assist

v2:
1. Use HV_HYP_PAGE_SHIFT instead
---
 xen/arch/x86/guest/hyperv/hyperv.c | 21 +
 xen/include/asm-x86/guest/hyperv.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index e5f258c946..17488f8c40 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -29,6 +29,7 @@ struct ms_hyperv_info __read_mostly ms_hyperv;
 extern char hv_hypercall_page[];
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_arg);
 DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
+DEFINE_PER_CPU_READ_MOSTLY(void *, hv_vp_assist);
 
 static const struct hypervisor_ops ops;
 const struct hypervisor_ops *__init hyperv_probe(void)
@@ -101,15 +102,35 @@ static void setup_hypercall_pcpu_arg(void)
 this_cpu(hv_vp_index) = vp_index_msr;
 }
 
+static void setup_vp_assist(void)
+{
+void *mapping;
+uint64_t val;
+
+mapping = alloc_xenheap_page();
+if ( !mapping )
+panic("Failed to allocate vp_assist page for %u\n",
+  smp_processor_id());
+
+clear_page(mapping);
+
+this_cpu(hv_vp_assist) = mapping;
+val = (virt_to_mfn(mapping) << HV_HYP_PAGE_SHIFT)
+| HV_X64_MSR_VP_ASSIST_PAGE_ENABLE;
+wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, val);
+}
+
 static void __init setup(void)
 {
 setup_hypercall_page();
 setup_hypercall_pcpu_arg();
+setup_vp_assist();
 }
 
 static void ap_setup(void)
 {
 setup_hypercall_pcpu_arg();
+setup_vp_assist();
 }
 
 static const struct hypervisor_ops ops = {
diff --git a/xen/include/asm-x86/guest/hyperv.h 
b/xen/include/asm-x86/guest/hyperv.h
index bae06c8a3a..2ddfd53f8c 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -67,6 +67,7 @@ extern struct ms_hyperv_info ms_hyperv;
 
 DECLARE_PER_CPU(void *, hv_pcpu_input_arg);
 DECLARE_PER_CPU(unsigned int, hv_vp_index);
+DECLARE_PER_CPU(void *, hv_vp_assist);
 
 const struct hypervisor_ops *hyperv_probe(void);
 
-- 
2.20.1


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

[Xen-devel] [PATCH v3 4/5] x86/hyperv: retrieve vp_index from Hyper-V

[Wei Liu]

This will be useful when invoking hypercall that targets specific
vcpu(s).

Signed-off-by: Wei Liu 
---
v2:
1. Fold into setup_pcpu_arg function
---
 xen/arch/x86/guest/hyperv/hyperv.c | 5 +
 xen/include/asm-x86/guest/hyperv.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 7e046dfc04..e5f258c946 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -28,6 +28,7 @@ struct ms_hyperv_info __read_mostly ms_hyperv;
 
 extern char hv_hypercall_page[];
 DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_arg);
+DEFINE_PER_CPU_READ_MOSTLY(unsigned int, hv_vp_index);
 
 static const struct hypervisor_ops ops;
 const struct hypervisor_ops *__init hyperv_probe(void)
@@ -87,6 +88,7 @@ static void __init setup_hypercall_page(void)
 static void setup_hypercall_pcpu_arg(void)
 {
 void *mapping;
+uint64_t vp_index_msr;
 
 mapping = alloc_xenheap_page();
 if ( !mapping )
@@ -94,6 +96,9 @@ static void setup_hypercall_pcpu_arg(void)
   smp_processor_id());
 
 this_cpu(hv_pcpu_input_arg) = mapping;
+
+rdmsrl(HV_X64_MSR_VP_INDEX, vp_index_msr);
+this_cpu(hv_vp_index) = vp_index_msr;
 }
 
 static void __init setup(void)
diff --git a/xen/include/asm-x86/guest/hyperv.h 
b/xen/include/asm-x86/guest/hyperv.h
index 6cf2eab62f..bae06c8a3a 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -66,6 +66,7 @@ struct ms_hyperv_info {
 extern struct ms_hyperv_info ms_hyperv;
 
 DECLARE_PER_CPU(void *, hv_pcpu_input_arg);
+DECLARE_PER_CPU(unsigned int, hv_vp_index);
 
 const struct hypervisor_ops *hyperv_probe(void);
 
-- 
2.20.1


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

[Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

[Wei Liu]

Signed-off-by: Wei Liu 
---
v2:
1. Fix issue discovered by Michael
2. Use a statically allocated page as hypercall page
---
 xen/arch/x86/guest/hyperv/Makefile |  1 +
 xen/arch/x86/guest/hyperv/hypercall_page.S | 21 +
 xen/arch/x86/guest/hyperv/hyperv.c | 27 +++---
 3 files changed, 46 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/guest/hyperv/hypercall_page.S

diff --git a/xen/arch/x86/guest/hyperv/Makefile 
b/xen/arch/x86/guest/hyperv/Makefile
index 68170109a9..1a8887d2f4 100644
--- a/xen/arch/x86/guest/hyperv/Makefile
+++ b/xen/arch/x86/guest/hyperv/Makefile
@@ -1 +1,2 @@
+obj-y += hypercall_page.o
 obj-y += hyperv.o
diff --git a/xen/arch/x86/guest/hyperv/hypercall_page.S 
b/xen/arch/x86/guest/hyperv/hypercall_page.S
new file mode 100644
index 00..6d6ab913be
--- /dev/null
+++ b/xen/arch/x86/guest/hyperv/hypercall_page.S
@@ -0,0 +1,21 @@
+#include 
+#include 
+
+.section ".text.page_aligned", "ax", @progbits
+.p2align PAGE_SHIFT
+GLOBAL(hv_hypercall_page)
+/* Return -1 for "not yet ready" state */
+mov -1, %rax
+ret
+1:
+/* Fill the rest with `ret` */
+.fill PAGE_SIZE - (1b - hv_hypercall_page), 1, 0xc3
+.type hv_hypercall_page, STT_OBJECT
+.size hv_hypercall_page, PAGE_SIZE
+
+/*
+ * Local variables:
+ * tab-width: 8
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 8d38313d7a..381be2a68c 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -19,16 +19,16 @@
  * Copyright (c) 2019 Microsoft.
  */
 #include 
+#include 
 
 #include 
 #include 
 
 struct ms_hyperv_info __read_mostly ms_hyperv;
 
-static const struct hypervisor_ops ops = {
-.name = "Hyper-V",
-};
+extern char hv_hypercall_page[];
 
+static const struct hypervisor_ops ops;
 const struct hypervisor_ops *__init hyperv_probe(void)
 {
 uint32_t eax, ebx, ecx, edx;
@@ -72,6 +72,27 @@ const struct hypervisor_ops *__init hyperv_probe(void)
 return &ops;
 }
 
+static void __init setup_hypercall_page(void)
+{
+union hv_x64_msr_hypercall_contents hypercall_msr;
+
+rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+hypercall_msr.enable = 1;
+hypercall_msr.guest_physical_address =
+__pa(hv_hypercall_page) >> HV_HYP_PAGE_SHIFT;
+wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
+}
+
+static void __init setup(void)
+{
+setup_hypercall_page();
+}
+
+static const struct hypervisor_ops ops = {
+.name = "Hyper-V",
+.setup = setup,
+};
+
 /*
  * Local variables:
  * mode: C
-- 
2.20.1


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

[Xen-devel] [PATCH v3 0/5] More Hyper-V infrastructure

[Wei Liu]

This patch sereis implements several important functionalities to run
Xen on top of Hyper-V.

See individual patches for more details.

Wei.

Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: Roger Pau Monné 
Cc: Michael Kelley 
Cc: Paul Durrant 

Wei Liu (5):
  x86/hyperv: setup hypercall page
  x86/hyperv: provide Hyper-V hypercall functions
  x86/hyperv: provide percpu hypercall input page
  x86/hyperv: retrieve vp_index from Hyper-V
  x86/hyperv: setup VP assist page

 xen/arch/x86/guest/hyperv/Makefile |  1 +
 xen/arch/x86/guest/hyperv/hypercall_page.S | 21 +
 xen/arch/x86/guest/hyperv/hyperv.c | 73 -
 xen/include/asm-x86/guest/hyperv-hcall.h   | 95 ++
 xen/include/asm-x86/guest/hyperv.h |  6 ++
 5 files changed, 193 insertions(+), 3 deletions(-)
 create mode 100644 xen/arch/x86/guest/hyperv/hypercall_page.S
 create mode 100644 xen/include/asm-x86/guest/hyperv-hcall.h

-- 
2.20.1


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

[Xen-devel] [PATCH v3 3/5] x86/hyperv: provide percpu hypercall input page

[Wei Liu]

Hyper-V's input / output argument must be 8 bytes aligned an not cross
page boundary. The easiest way to satisfy those requirements is to use
percpu page.

For the foreseeable future we only need to provide input for TLB
and APIC hypercalls, so skip setting up an output page.

We will also need to provide an ap_setup hook for secondary cpus to
setup its own input page.

Signed-off-by: Wei Liu 
---
v3:
1. Use xenheap page instead
2. Drop page tracking structure
3. Drop Paul's review tag
---
 xen/arch/x86/guest/hyperv/hyperv.c | 20 
 xen/include/asm-x86/guest/hyperv.h |  4 
 2 files changed, 24 insertions(+)

diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
b/xen/arch/x86/guest/hyperv/hyperv.c
index 381be2a68c..7e046dfc04 100644
--- a/xen/arch/x86/guest/hyperv/hyperv.c
+++ b/xen/arch/x86/guest/hyperv/hyperv.c
@@ -27,6 +27,7 @@
 struct ms_hyperv_info __read_mostly ms_hyperv;
 
 extern char hv_hypercall_page[];
+DEFINE_PER_CPU_READ_MOSTLY(void *, hv_pcpu_input_arg);
 
 static const struct hypervisor_ops ops;
 const struct hypervisor_ops *__init hyperv_probe(void)
@@ -83,14 +84,33 @@ static void __init setup_hypercall_page(void)
 wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
 }
 
+static void setup_hypercall_pcpu_arg(void)
+{
+void *mapping;
+
+mapping = alloc_xenheap_page();
+if ( !mapping )
+panic("Failed to allocate hypercall input page for %u\n",
+  smp_processor_id());
+
+this_cpu(hv_pcpu_input_arg) = mapping;
+}
+
 static void __init setup(void)
 {
 setup_hypercall_page();
+setup_hypercall_pcpu_arg();
+}
+
+static void ap_setup(void)
+{
+setup_hypercall_pcpu_arg();
 }
 
 static const struct hypervisor_ops ops = {
 .name = "Hyper-V",
 .setup = setup,
+.ap_setup = ap_setup,
 };
 
 /*
diff --git a/xen/include/asm-x86/guest/hyperv.h 
b/xen/include/asm-x86/guest/hyperv.h
index c7a7f32bd5..6cf2eab62f 100644
--- a/xen/include/asm-x86/guest/hyperv.h
+++ b/xen/include/asm-x86/guest/hyperv.h
@@ -51,6 +51,8 @@ static inline uint64_t hv_scale_tsc(uint64_t tsc, uint64_t 
scale,
 
 #ifdef CONFIG_HYPERV_GUEST
 
+#include 
+
 #include 
 
 struct ms_hyperv_info {
@@ -63,6 +65,8 @@ struct ms_hyperv_info {
 };
 extern struct ms_hyperv_info ms_hyperv;
 
+DECLARE_PER_CPU(void *, hv_pcpu_input_arg);
+
 const struct hypervisor_ops *hyperv_probe(void);
 
 #else
-- 
2.20.1


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

[Xen-devel] [PATCH v3 2/5] x86/hyperv: provide Hyper-V hypercall functions

[Wei Liu]

These functions will be used later to make hypercalls to Hyper-V.

I couldn't find reference in TLFS that Hyper-V clobbers flags and
r9-r11, but Linux's commit message says it does. Err on the safe side.

Signed-off-by: Wei Liu 
---
v3:
1. Name the file hyperv-hcall.h

v2:
1. Use direct call
---
 xen/include/asm-x86/guest/hyperv-hcall.h | 95 
 1 file changed, 95 insertions(+)
 create mode 100644 xen/include/asm-x86/guest/hyperv-hcall.h

diff --git a/xen/include/asm-x86/guest/hyperv-hcall.h 
b/xen/include/asm-x86/guest/hyperv-hcall.h
new file mode 100644
index 00..4b87dcfe64
--- /dev/null
+++ b/xen/include/asm-x86/guest/hyperv-hcall.h
@@ -0,0 +1,95 @@
+/**
+ * asm-x86/guest/hyperv-hcall.h
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms and conditions of the GNU General Public
+ * License, version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this program; If not, see .
+ *
+ * Copyright (c) 2019 Microsoft.
+ */
+
+#ifndef __X86_HYPERV_HCALL_H__
+#define __X86_HYPERV_HCALL_H__
+
+#include 
+
+#include 
+#include 
+#include 
+
+static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input, 
paddr_t output)
+{
+uint64_t status;
+
+asm volatile ("mov %[output], %%r8\n"
+  "call hv_hypercall_page"
+  : "=a" (status), "+c" (control),
+"+d" (input) ASM_CALL_CONSTRAINT
+  : [output] "rm" (output)
+  : "cc", "memory", "r8", "r9", "r10", "r11");
+
+return status;
+}
+
+static inline uint64_t hv_do_fast_hypercall(uint16_t code,
+uint64_t input1, uint64_t input2)
+{
+uint64_t status;
+uint64_t control = (uint64_t)code | HV_HYPERCALL_FAST_BIT;
+
+asm volatile ("mov %[input2], %%r8\n"
+  "call hv_hypercall_page"
+  : "=a" (status), "+c" (control),
+"+d" (input1) ASM_CALL_CONSTRAINT
+  : [input2] "rm" (input2)
+  : "cc", "r8", "r9", "r10", "r11");
+
+return status;
+}
+
+static inline uint64_t hv_do_rep_hypercall(uint16_t code, uint16_t rep_count,
+   uint16_t varhead_size,
+   paddr_t input, paddr_t output)
+{
+uint64_t control = code;
+uint64_t status;
+uint16_t rep_comp;
+
+control |= (uint64_t)varhead_size << HV_HYPERCALL_VARHEAD_OFFSET;
+control |= (uint64_t)rep_count << HV_HYPERCALL_REP_COMP_OFFSET;
+
+do {
+status = hv_do_hypercall(control, input, output);
+if ( (status & HV_HYPERCALL_RESULT_MASK) != HV_STATUS_SUCCESS )
+break;
+
+rep_comp = (status & HV_HYPERCALL_REP_COMP_MASK) >>
+HV_HYPERCALL_REP_COMP_OFFSET;
+
+control &= ~HV_HYPERCALL_REP_START_MASK;
+control |= (uint64_t)rep_comp << HV_HYPERCALL_REP_COMP_OFFSET;
+
+} while ( rep_comp < rep_count );
+
+return status;
+}
+
+#endif /* __X86_HYPERV_HCALL_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.20.1


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

Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

[Andrew Cooper]

On 05/01/2020 16:47, Wei Liu wrote:
> diff --git a/xen/arch/x86/guest/hyperv/Makefile 
> b/xen/arch/x86/guest/hyperv/Makefile
> index 68170109a9..1a8887d2f4 100644
> --- a/xen/arch/x86/guest/hyperv/Makefile
> +++ b/xen/arch/x86/guest/hyperv/Makefile
> @@ -1 +1,2 @@
> +obj-y += hypercall_page.o
>  obj-y += hyperv.o
> diff --git a/xen/arch/x86/guest/hyperv/hypercall_page.S 
> b/xen/arch/x86/guest/hyperv/hypercall_page.S
> new file mode 100644
> index 00..6d6ab913be
> --- /dev/null
> +++ b/xen/arch/x86/guest/hyperv/hypercall_page.S
> @@ -0,0 +1,21 @@
> +#include 
> +#include 
> +
> +.section ".text.page_aligned", "ax", @progbits
> +.p2align PAGE_SHIFT
> +GLOBAL(hv_hypercall_page)
> +/* Return -1 for "not yet ready" state */
> +mov -1, %rax
> +ret
> +1:
> +/* Fill the rest with `ret` */
> +.fill PAGE_SIZE - (1b - hv_hypercall_page), 1, 0xc3

If you want to fill with rets, you can do this more simply with:

    .p2lign PAGE_SHIFT, 0xc3

which will do the size calculation for you.

That said, I retract my statement about wanting this in the middle of
.text.  (Sorry.  See below.)

> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
> b/xen/arch/x86/guest/hyperv/hyperv.c
> index 8d38313d7a..381be2a68c 100644
> --- a/xen/arch/x86/guest/hyperv/hyperv.c
> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> @@ -72,6 +72,27 @@ const struct hypervisor_ops *__init hyperv_probe(void)
>  return &ops;
>  }
>  
> +static void __init setup_hypercall_page(void)
> +{
> +union hv_x64_msr_hypercall_contents hypercall_msr;
> +
> +rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> +hypercall_msr.enable = 1;
> +hypercall_msr.guest_physical_address =
> +__pa(hv_hypercall_page) >> HV_HYP_PAGE_SHIFT;
> +wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> +}
> +
> +static void __init setup(void)
> +{
> +setup_hypercall_page();
> +}

The TLFS says that writing enable will fail until the OS identity is
set, which AFACIT, isn't done anywhere in the series.  The whole
sequence is described in "3.13 Establishing the Hypercall Interface"

The locked bit is probably a good idea, but one aspect missing here is
the check to see whether the hypercall page is already enabled, which I
expect is for a kexec crash scenario.

However, the most important point is the one which describes the #GP
properties of the guest trying to modify the page.  This can only be
achieved with an EPT/NPT mapping lacking the W permission, which will
shatter host superpages.   Therefore, putting it in .text is going to be
rather poor, perf wise.

I also note that Xen's implementation of the Viridian hypercall page
doesn't conform to these properties, and wants fixing.  It is going to
need a new kind identification of the page (probably a new p2m type)
which injects #GP if we ever see an EPT_VIOLATION/NPT_FAULT against it.

As for suggestions here, I'm struggling to find any memory map details
exposed in the Viridian interface, and therefore which gfn is best to
choose.  I have a sinking feeling that the answer is ACPI...

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/5] x86/hyperv: provide Hyper-V hypercall functions

[Andrew Cooper]

> +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input, 
> paddr_t output)
> +{
> +uint64_t status;
> +
> +asm volatile ("mov %[output], %%r8\n"
> +  "call hv_hypercall_page"
> +  : "=a" (status), "+c" (control),
> +"+d" (input) ASM_CALL_CONSTRAINT
> +  : [output] "rm" (output)
> +  : "cc", "memory", "r8", "r9", "r10", "r11");

I think you want:

register unsigned long r8 asm("r8") = output;

and "+r" (r8) as an output constraint.

In particular, that doesn't force the compiler to put output into a
register other than r8 (or worse, spill it to the stack) to have the
opaque blob of asm move it back into r8.  What it will do in practice is
cause the compiler to construct output directly in r8.

As for the other clobbers, I can't find anything at all in the spec
which even mentions those registers.  There will be a decent improvement
to code generation if we don't force them to be spilled around a hypercall.

However, HyperV will(may?) modify %xmm{0..5} in some cases, and this
will corrupt the current vcpu's FPU context.  Care will need to be taken
to spill these if necessary.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/5] x86/hyperv: provide Hyper-V hypercall functions

[Wei Liu]

On Sun, Jan 05, 2020 at 07:08:28PM +, Andrew Cooper wrote:
> 
> > +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input, 
> > paddr_t output)
> > +{
> > +uint64_t status;
> > +
> > +asm volatile ("mov %[output], %%r8\n"
> > +  "call hv_hypercall_page"
> > +  : "=a" (status), "+c" (control),
> > +"+d" (input) ASM_CALL_CONSTRAINT
> > +  : [output] "rm" (output)
> > +  : "cc", "memory", "r8", "r9", "r10", "r11");
> 
> I think you want:
> 
> register unsigned long r8 asm("r8") = output;
> 
> and "+r" (r8) as an output constraint.

Although it is named `output`, it is really just an input parameter from
Hyper-V's PoV. It contains the address of the page Hyper-V should write
its output to.

> 
> In particular, that doesn't force the compiler to put output into a
> register other than r8 (or worse, spill it to the stack) to have the
> opaque blob of asm move it back into r8.  What it will do in practice is
> cause the compiler to construct output directly in r8.
> 
> As for the other clobbers, I can't find anything at all in the spec
> which even mentions those registers.  There will be a decent improvement
> to code generation if we don't force them to be spilled around a hypercall.
> 

Neither can I. But Linux's commit says that's needed, so I chose to err
on the safe side.

I'm fine with dropping r9-r11.

> However, HyperV will(may?) modify %xmm{0..5} in some cases, and this
> will corrupt the current vcpu's FPU context.  Care will need to be taken
> to spill these if necessary.
> 

The hypercalls we care about (TLB, APIC etc) don't use that ABI as far
as I can tell. At the very least Linux, which uses the same set of
hypercalls, doesn't need to save / restore XMM registers around the
calls.

Wei.

> ~Andrew

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

Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

[Wei Liu]

On Sun, Jan 05, 2020 at 05:37:44PM +, Andrew Cooper wrote:
> On 05/01/2020 16:47, Wei Liu wrote:
> > diff --git a/xen/arch/x86/guest/hyperv/Makefile 
> > b/xen/arch/x86/guest/hyperv/Makefile
> > index 68170109a9..1a8887d2f4 100644
> > --- a/xen/arch/x86/guest/hyperv/Makefile
> > +++ b/xen/arch/x86/guest/hyperv/Makefile
> > @@ -1 +1,2 @@
> > +obj-y += hypercall_page.o
> >  obj-y += hyperv.o
> > diff --git a/xen/arch/x86/guest/hyperv/hypercall_page.S 
> > b/xen/arch/x86/guest/hyperv/hypercall_page.S
> > new file mode 100644
> > index 00..6d6ab913be
> > --- /dev/null
> > +++ b/xen/arch/x86/guest/hyperv/hypercall_page.S
> > @@ -0,0 +1,21 @@
> > +#include 
> > +#include 
> > +
> > +.section ".text.page_aligned", "ax", @progbits
> > +.p2align PAGE_SHIFT
> > +GLOBAL(hv_hypercall_page)
> > +/* Return -1 for "not yet ready" state */
> > +mov -1, %rax
> > +ret
> > +1:
> > +/* Fill the rest with `ret` */
> > +.fill PAGE_SIZE - (1b - hv_hypercall_page), 1, 0xc3
> 
> If you want to fill with rets, you can do this more simply with:
> 
>     .p2lign PAGE_SHIFT, 0xc3
> 
> which will do the size calculation for you.
> 
> That said, I retract my statement about wanting this in the middle of
> .text.  (Sorry.  See below.)
> 
> > diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
> > b/xen/arch/x86/guest/hyperv/hyperv.c
> > index 8d38313d7a..381be2a68c 100644
> > --- a/xen/arch/x86/guest/hyperv/hyperv.c
> > +++ b/xen/arch/x86/guest/hyperv/hyperv.c
> > @@ -72,6 +72,27 @@ const struct hypervisor_ops *__init hyperv_probe(void)
> >  return &ops;
> >  }
> >  
> > +static void __init setup_hypercall_page(void)
> > +{
> > +union hv_x64_msr_hypercall_contents hypercall_msr;
> > +
> > +rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > +hypercall_msr.enable = 1;
> > +hypercall_msr.guest_physical_address =
> > +__pa(hv_hypercall_page) >> HV_HYP_PAGE_SHIFT;
> > +wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
> > +}
> > +
> > +static void __init setup(void)
> > +{
> > +setup_hypercall_page();
> > +}
> 
> The TLFS says that writing enable will fail until the OS identity is
> set, which AFACIT, isn't done anywhere in the series.  The whole
> sequence is described in "3.13 Establishing the Hypercall Interface"

Good catch. I will make up an identity number for Xen. I will also
follow the sequence strictly.

> 
> The locked bit is probably a good idea, but one aspect missing here is
> the check to see whether the hypercall page is already enabled, which I
> expect is for a kexec crash scenario.
> 
> However, the most important point is the one which describes the #GP
> properties of the guest trying to modify the page.  This can only be
> achieved with an EPT/NPT mapping lacking the W permission, which will
> shatter host superpages.   Therefore, putting it in .text is going to be
> rather poor, perf wise.
> 
> I also note that Xen's implementation of the Viridian hypercall page
> doesn't conform to these properties, and wants fixing.  It is going to
> need a new kind identification of the page (probably a new p2m type)
> which injects #GP if we ever see an EPT_VIOLATION/NPT_FAULT against it.
> 
> As for suggestions here, I'm struggling to find any memory map details
> exposed in the Viridian interface, and therefore which gfn is best to
> choose.  I have a sinking feeling that the answer is ACPI...

TLFS only says "go find one suitable page yourself" without further
hints.

Since we're still quite far away from a functioning system, finding a
most suitable page isn't my top priority at this point. If there is a
simple way to extrapolate suitable information from ACPI, that would be
great. If it requires writing a set of functionalities, than that will
need to wait till later.

Wei.

> 
> ~Andrew

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

Re: [Xen-devel] [PATCH v3 1/5] x86/hyperv: setup hypercall page

[Andrew Cooper]

On 05/01/2020 21:45, Wei Liu wrote:
> On Sun, Jan 05, 2020 at 05:37:44PM +, Andrew Cooper wrote:
>> On 05/01/2020 16:47, Wei Liu wrote:
>>> diff --git a/xen/arch/x86/guest/hyperv/Makefile 
>>> b/xen/arch/x86/guest/hyperv/Makefile
>>> index 68170109a9..1a8887d2f4 100644
>>> --- a/xen/arch/x86/guest/hyperv/Makefile
>>> +++ b/xen/arch/x86/guest/hyperv/Makefile
>>> @@ -1 +1,2 @@
>>> +obj-y += hypercall_page.o
>>>  obj-y += hyperv.o
>>> diff --git a/xen/arch/x86/guest/hyperv/hypercall_page.S 
>>> b/xen/arch/x86/guest/hyperv/hypercall_page.S
>>> new file mode 100644
>>> index 00..6d6ab913be
>>> --- /dev/null
>>> +++ b/xen/arch/x86/guest/hyperv/hypercall_page.S
>>> @@ -0,0 +1,21 @@
>>> +#include 
>>> +#include 
>>> +
>>> +.section ".text.page_aligned", "ax", @progbits
>>> +.p2align PAGE_SHIFT
>>> +GLOBAL(hv_hypercall_page)
>>> +/* Return -1 for "not yet ready" state */
>>> +mov -1, %rax
>>> +ret
>>> +1:
>>> +/* Fill the rest with `ret` */
>>> +.fill PAGE_SIZE - (1b - hv_hypercall_page), 1, 0xc3
>> If you want to fill with rets, you can do this more simply with:
>>
>>     .p2lign PAGE_SHIFT, 0xc3
>>
>> which will do the size calculation for you.
>>
>> That said, I retract my statement about wanting this in the middle of
>> .text.  (Sorry.  See below.)
>>
>>> diff --git a/xen/arch/x86/guest/hyperv/hyperv.c 
>>> b/xen/arch/x86/guest/hyperv/hyperv.c
>>> index 8d38313d7a..381be2a68c 100644
>>> --- a/xen/arch/x86/guest/hyperv/hyperv.c
>>> +++ b/xen/arch/x86/guest/hyperv/hyperv.c
>>> @@ -72,6 +72,27 @@ const struct hypervisor_ops *__init hyperv_probe(void)
>>>  return &ops;
>>>  }
>>>  
>>> +static void __init setup_hypercall_page(void)
>>> +{
>>> +union hv_x64_msr_hypercall_contents hypercall_msr;
>>> +
>>> +rdmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>>> +hypercall_msr.enable = 1;
>>> +hypercall_msr.guest_physical_address =
>>> +__pa(hv_hypercall_page) >> HV_HYP_PAGE_SHIFT;
>>> +wrmsrl(HV_X64_MSR_HYPERCALL, hypercall_msr.as_uint64);
>>> +}
>>> +
>>> +static void __init setup(void)
>>> +{
>>> +setup_hypercall_page();
>>> +}
>> The TLFS says that writing enable will fail until the OS identity is
>> set, which AFACIT, isn't done anywhere in the series.  The whole
>> sequence is described in "3.13 Establishing the Hypercall Interface"
> Good catch. I will make up an identity number for Xen. I will also
> follow the sequence strictly.
>
>> The locked bit is probably a good idea, but one aspect missing here is
>> the check to see whether the hypercall page is already enabled, which I
>> expect is for a kexec crash scenario.
>>
>> However, the most important point is the one which describes the #GP
>> properties of the guest trying to modify the page.  This can only be
>> achieved with an EPT/NPT mapping lacking the W permission, which will
>> shatter host superpages.   Therefore, putting it in .text is going to be
>> rather poor, perf wise.
>>
>> I also note that Xen's implementation of the Viridian hypercall page
>> doesn't conform to these properties, and wants fixing.  It is going to
>> need a new kind identification of the page (probably a new p2m type)
>> which injects #GP if we ever see an EPT_VIOLATION/NPT_FAULT against it.
>>
>> As for suggestions here, I'm struggling to find any memory map details
>> exposed in the Viridian interface, and therefore which gfn is best to
>> choose.  I have a sinking feeling that the answer is ACPI...
> TLFS only says "go find one suitable page yourself" without further
> hints.
>
> Since we're still quite far away from a functioning system, finding a
> most suitable page isn't my top priority at this point. If there is a
> simple way to extrapolate suitable information from ACPI, that would be
> great. If it requires writing a set of functionalities, than that will
> need to wait till later.

To cope with the "one is already established and it is already locked"
case, the only option is to have a fixmap entry which can be set
dynamically.  The problem is that the fixmap region is marked NX and 64G
away from .text.

Possibly the least bad option is to have some build-time space (so 0 or
4k depending on CONFIG_HYPERV) between the per-cpu stubs and
XEN_VIRT_END, which operates like the fixmap, but ends up as X/RO mappings.

That way, the virtual address ends up in a useful position (wrt using
direct call instructions) irrespective of where the gfn is/ends up.  As
for guessing, a good start is probably MAXPHYSADDR.

~Andrew

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

Re: [Xen-devel] [PATCH v3 2/5] x86/hyperv: provide Hyper-V hypercall functions

[Andrew Cooper]

On 05/01/2020 21:22, Wei Liu wrote:
> On Sun, Jan 05, 2020 at 07:08:28PM +, Andrew Cooper wrote:
>>> +static inline uint64_t hv_do_hypercall(uint64_t control, paddr_t input, 
>>> paddr_t output)
>>> +{
>>> +uint64_t status;
>>> +
>>> +asm volatile ("mov %[output], %%r8\n"
>>> +  "call hv_hypercall_page"
>>> +  : "=a" (status), "+c" (control),
>>> +"+d" (input) ASM_CALL_CONSTRAINT
>>> +  : [output] "rm" (output)
>>> +  : "cc", "memory", "r8", "r9", "r10", "r11");
>> I think you want:
>>
>> register unsigned long r8 asm("r8") = output;
>>
>> and "+r" (r8) as an output constraint.
> Although it is named `output`, it is really just an input parameter from
> Hyper-V's PoV.

Yes, but it is also clobbered.

This is an awkward corner case of gnu inline assembly.

It is not permitted to have a clobber list overlap with any input/output
operations, and because r8 doesn't have a unique letter, you can't do
the usual trick of "=r8" (discard) : "r8" (input).

The only available option is to mark it as read and written (which is
"+r" in the output list), and not use the C variable r8 at any point later.


Having looked through the spec a bit more, is this a wise API to have in
the first place?  input and output (perhaps better named input_addr and
output_addr) are fixed per CPU, and control is semantically linked to
the hypercall and its particular ABI.

I suppose the answer ultimately depends on what the callers look like.

>
>> In particular, that doesn't force the compiler to put output into a
>> register other than r8 (or worse, spill it to the stack) to have the
>> opaque blob of asm move it back into r8.  What it will do in practice is
>> cause the compiler to construct output directly in r8.
>>
>> As for the other clobbers, I can't find anything at all in the spec
>> which even mentions those registers.  There will be a decent improvement
>> to code generation if we don't force them to be spilled around a hypercall.
>>
> Neither can I. But Linux's commit says that's needed, so I chose to err
> on the safe side.

That's dull.  Is there any qualifying information?

>> However, HyperV will(may?) modify %xmm{0..5} in some cases, and this
>> will corrupt the current vcpu's FPU context.  Care will need to be taken
>> to spill these if necessary.
>>
> The hypercalls we care about (TLB, APIC etc) don't use that ABI as far
> as I can tell. At the very least Linux, which uses the same set of
> hypercalls, doesn't need to save / restore XMM registers around the
> calls.

Ok - it looks to be fine until we need to use a hypercall which uses the
fast extended ABI, which is the first to introduce the use of the %xmm
registers.

~Andrew

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

[Xen-devel] [libvirt bisection] complete build-amd64-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job build-amd64-libvirt
testid libvirt-build

Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  libvirt git://libvirt.org/libvirt.git
  Bug introduced:  810613a60efe3924c536b3663246900bc08910a5
  Bug not present: f6a750e678fb0ca3898cba08b6698f079008924c
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/145644/


  commit 810613a60efe3924c536b3663246900bc08910a5
  Author: Daniel P. Berrangé 
  Date:   Mon Dec 23 15:37:26 2019 +
  
  src: replace strptime()/timegm()/mktime() with GDateTime APIs set
  
  All places where we use strptime/timegm()/mktime() are handling
  conversion of dates in a format compatible with ISO 8601, so we
  can use the GDateTime APIs to simplify code.
  
  Reviewed-by: Fabiano Fidêncio 
  Signed-off-by: Daniel P. Berrangé 


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


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/libvirt/build-amd64-libvirt.libvirt-build 
--summary-out=tmp/145644.bisection-summary --basis-template=145511 
--blessings=real,real-bisect libvirt build-amd64-libvirt libvirt-build
Searching for failure / basis pass:
 145589 fail [host=godello1] / 145511 [host=huxelrebe1] 145212 [host=godello0] 
145173 [host=godello0] 145133 ok.
Failure / basis pass flights: 145589 / 145133
(tree with no url: minios)
Tree: libvirt git://libvirt.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: seabios git://xenbits.xen.org/osstest/seabios.git
Tree: xen git://xenbits.xen.org/xen.git
Latest fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7 
7d069378921bfa0d7c7198ea177aac0a2440016f 
317d3eeb963a515e15a63fa356d8ebcda7041a51 
b948a496150f4ae4f656c0f0ab672608723c80e6 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
7b3c5b70a32303b46d0d051e695f18d72cce5ed0
Basis pass dfff16a7c261f8d28e3abe60a47165f845fa952f 
1f6fb368c04919243e2c70f2aa514a5f88e95309 
317d3eeb963a515e15a63fa356d8ebcda7041a51 
ec8c74e8bcc66a43ff766254e68b0504f68e024f 
d0d8ad39ecb51cd7497cd524484fe09f50876798 
933ebad2470a169504799a1d95b8e410bd9847ef 
f21b5a4aeb020f2a5e2c6503f906a9349dd2f069 
0cd791c499bdc698d14a24050ec56d60b45732e0
Generating revisions with ./adhoc-revtuple-generator  
git://libvirt.org/libvirt.git#dfff16a7c261f8d28e3abe60a47165f845fa952f-fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7
 
https://git.savannah.gnu.org/git/gnulib.git/#1f6fb368c04919243e2c70f2aa514a5f88e95309-7d069378921bfa0d7c7198ea177aac0a2440016f
 
https://gitlab.com/keycodemap/keycodemapdb.git#317d3eeb963a515e15a63fa356d8ebcda7041a51-317d3eeb963a515e15a63fa356d8ebcda7041a51
 git://xenbits.xen.org/osstest/ovmf.git#ec8c74e8bcc66a43ff766254e68b0504f68e024\
 f-b948a496150f4ae4f656c0f0ab672608723c80e6 
git://xenbits.xen.org/qemu-xen-traditional.git#d0d8ad39ecb51cd7497cd524484fe09f50876798-d0d8ad39ecb51cd7497cd524484fe09f50876798
 
git://xenbits.xen.org/qemu-xen.git#933ebad2470a169504799a1d95b8e410bd9847ef-933ebad2470a169504799a1d95b8e410bd9847ef
 
git://xenbits.xen.org/osstest/seabios.git#f21b5a4aeb020f2a5e2c6503f906a9349dd2f069-f21b5a4aeb020f2a5e2c6503f906a9349dd2f069
 
git://xenbits.xen.org/xen.git#0cd791c499bdc698d14a24050ec56d60b45732e0-7b3c5b70a32303b4\
 6d0d051e695f18d72cce5ed0
Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to 
remove them.

Auto packing the repository in background for optimum performance.
See "git help gc" for manual housekeeping.
error: The last gc run reported the following. Please correct the root cause
and remove gc.log.
Automatic cleanup will not be performed until the file is removed.

warning: There are too many unreachable loose objects; run 'git prune' to 
remove them.

Loaded 35061 nodes in revision graph
Searching for test res

Re: [Xen-devel] [BUG] panic: "IO-APIC + timer doesn't work" - several people have reproduced

[Aaron Janse]

On Fri, Jan 3, 2020, at 4:51 AM, Jan Beulich wrote:
> On 31.12.2019 08:52,  Aaron Janse  wrote:
> > I'd like to note that Ubuntu, unlike Qubes, doesn't need to try
> > any `MP-BIOS bug` fallbacks.
> 
> "Doesn't need to try" is supposed to mean what? That it gets past
> the timer interrupt initialization, meaning if it crashes another
> way, it's a different problem? Or instead meaning it works
> (contrary to information found elsewhere), suggesting there's a
> Qubes side change involved?

I originally thought that the problem was the timer specifically, but
based on what you and Andrew Cooper have said, it sounds like the root
cause is somewhere else.

Andrew Cooper wrote:
> (Irrespective, I'm pretty sure this is a Grub2+EFI issue failing to pass
> the ACPI tables to Xen, and this eventual panic is just cascade fallout.)

I tried to get Xen working via legacy boot, but I haven't been able to get
my laptop to boot anything but UEFI. The BIOS even states "UEFI only."

> Did you try disabling use of the IOMMU ("iommu=0" on the Xen
> command line)?

Unfortunately, Qubes requires iommu. Setting "iommu=0" results in a panic:

```
Couldn't enable IOMMU and iommu=required/force
```

I also (unsuccessfully) tried iommu=no-igfx and iommu=soft (both resulted
in the timer panic).

I couldn't find anywhere to disable the flag (even though it would break
Qubes, at least the flag could help minimize the scope of the cause of the
timer crash).

I installed Xen on Arch Linux in order to test this flag, but I'm having
the same problem I had on Ubuntu: booting to Xen hangs on loading
initramfs. [1]

> If this is as common a problem as you say, it's hard to believe
> this has never worked on any of these systems. Hence it would be
> helpful to know starting from which version this has been
> regressed.

That makes sense. I've tried to reproduce the problem on both Arch and
Ubuntu (both hang, and I'm not sure why or how to debug that). Because
Qubes is the only OS I've been able to boot verbose Xen from, I installed
a 2016 release to try out. However, I couldn't get past a hang showing
the Dell logo. I had this same issue on NixOS, described by someone else
with the same laptop on the NixOS Discourse [4]. The solution for NixOS
was to use a newer version of the distro.

If I can get past the boot hang on Ubuntu or Arch, I'd be happy to go about
bisecting the issue, comparing Ubuntu/Arch vs Qubes, compiling with new
printf statements, etc.

As a side note, the XPS 7390 2-in-1 user was able to get Xen to boot
using the acpi=noirq flag [2]. My understanding is that needing this flag
indicates that something's still wrong [3].

[1] https://lists.xenproject.org/archives/html/xen-users/2019-12/msg00031.html
[2] https://www.reddit.com/r/Qubes/comments/edqrab/qubes_and_ice_lake/fcresld/
[3] http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#acpi
[4] 
https://discourse.nixos.org/t/nixos-stable-wont-boot-from-usb-on-xps-7390/4776

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 14 guest-saverestore  fail REGR. vs. 144861
 test-amd64-i386-freebsd10-amd64 14 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 13 guest-saverestore fail REGR. vs. 
144861
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm 13 guest-saverestore fail REGR. 
vs. 144861
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 13 guest-saverestore fail 
REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ovmf-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-win7-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-amd64-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail REGR. vs. 144861
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
144861

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-rtds 16 guest-localmigrate fail pass in 145573

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 144861

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-rtds  18 guest-localmigrate/x10 fail in 145573 like 144861
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 144861
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 144861
 test-arm64-arm64-xl-seattle  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-seattle  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-thunderx 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-arm64-arm64-xl-

Re: [Xen-devel] [PATCH v4 4/7] Add Communication Guide

[Jürgen Groß]

On 30.12.19 20:32, Lars Kurth wrote:

From: Lars Kurth 

This document is a portal page that lays out our gold standard,
best practices for some common situations and mechanisms to help
resolve issues that can have a negative effect on our community.

Detail is covered in subsequent documents

Changes since v3
- Also changes the TODO in code-of-conduct.md which had been lost
   in v2

Changes since v2 (introduced in v2)
- Make lines break at 80 characters

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
  code-of-conduct.md |  4 +--
  communication-guide.md | 67 ++
  2 files changed, 69 insertions(+), 2 deletions(-)
  create mode 100644 communication-guide.md

diff --git a/code-of-conduct.md b/code-of-conduct.md
index 7c29a4f..a6080cd 100644
--- a/code-of-conduct.md
+++ b/code-of-conduct.md
@@ -14,7 +14,7 @@ personal appearance, race, religion, or sexual identity and 
orientation.
  We believe that a Code of Conduct can help create a harassment-free 
environment,
  but is not sufficient to create a welcoming environment on its own: guidance 
on
  creating a welcoming environment, how to communicate in an effective and
-friendly way, etc. can be found [here][guidance].
+friendly way, etc. can be found [here][guidance]].
  
  Examples of unacceptable behavior by participants include:
  
@@ -85,7 +85,7 @@ version 1.4, available at

  https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
  
  [homepage]: https://www.contributor-covenant.org

-[guidance]: TODO-INSERT-URL
+[guidance]: communication-guide.md
  
  For answers to common questions about this code of conduct, see

  https://www.contributor-covenant.org/faq
diff --git a/communication-guide.md b/communication-guide.md
new file mode 100644
index 000..153b100
--- /dev/null
+++ b/communication-guide.md
@@ -0,0 +1,67 @@
+# Communication Guide
+
+We believe that our [Code of Conduct](code-of-conduct.md) can help create a
+harassment-free environment, but is not sufficient to create a welcoming
+environment on its own. We can all make mistakes: when we do, we take
+responsibility for them and try to improve.
+
+This document lays out our gold standard, best practices for some common
+situations and mechanisms to help resolve issues that can have a
+negative effect on our community.
+
+## Goal
+
+We want a productive, welcoming and agile community that can welcome new
+ideas in a complex technical field which is able to reflect on and improve how
+we work.
+
+## Communication & Handling Differences in Opinions
+
+Examples of behavior that contributes to creating a positive environment
+include:
+* Use welcoming and inclusive language
+* Keep discussions technical and actionable
+* Be respectful of differing viewpoints and experiences
+* Be aware of your own and counterpart’s communication style and culture
+* Gracefully accept constructive criticism
+* Focus on what is best for the community
+* Show empathy towards other community members
+* Resolve differences in opinion effectively
+
+## Getting Help
+
+When developing code collaboratively, technical discussion and disagreements
+are unavoidable. Our contributors come from different countries and cultures,
+are driven by different goals and take pride in their work and in their point
+of view. This invariably can lead to lengthy and unproductive debate,
+followed by indecision, sometimes this can impact working relationships
+or lead to other issues that can have a negative effect on our community.
+
+To minimize such issue, we provide a 3-stage process
+* Self-help as outlined in this document
+* Ability to ask for an independent opinion or help in private
+* Mediation between parties which disagree. In this case a neutral community
+  member assists the disputing parties resolve the issues or will work with the
+  parties such that they can improve future interactions.
+
+If you need and independent opinion or help, feel free to contact


s/and/an/


+mediat...@xenproject.org. The team behind mediation@ is made up of the
+same community members as those listed in the Conduct Team: see
+[Code of Conduct](code-of-conduct.md). In addition, team members are obligated
+to maintain confidentiality with regard discussions that take place. If you
+have concerns about any of the members of the mediation@ alias, you are
+welcome to contact precisely the team member(s) of your choice. In this case,
+please make certain that you highlight the nature of a request by making sure
+that either help or mediation is mentioned in the e-mail subject or body.
+
+## Specific Topics and Best Practice
+
+* [Code Review Guide](code-review-guide.md):
+  Essential reading for code reviewers and contributors
+* [Communication Best Practice](communication-practice.md):
+  This guide covers communica

Re: [Xen-devel] [PATCH v4 5/7] Add Code Review Guide

[Jürgen Groß]

On 30.12.19 20:32, Lars Kurth wrote:

From: Lars Kurth 

This document highlights what reviewers such as maintainers and committers look
for when reviewing code. It sets expectations for code authors and provides
a framework for code reviewers.

Changes since v3
* Added example under *Workflow from a Reviewer's Perspective* section
* Fixed typos in text introduced in v2

Changes since v2 (introduced in v2)
* Extend introduction
* Add "Code Review Workflow" covering
   - "Workflow from a Reviewer's Perspective"
   - "Workflow from an Author's Perspective"
   - "Problematic Patch Reviews"
* Wrap to 80 characters
* Replace inline links with reference links to make
   wrapping easier

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
  code-review-guide.md | 313 +++
  1 file changed, 313 insertions(+)
  create mode 100644 code-review-guide.md

diff --git a/code-review-guide.md b/code-review-guide.md
new file mode 100644
index 000..b2c08d2
--- /dev/null
+++ b/code-review-guide.md
@@ -0,0 +1,313 @@
+# Code Review Guide
+
+This document highlights what reviewers such as maintainers and committers look
+for when reviewing your code. It sets expectations for code authors and 
provides
+a framework for code reviewers.
+
+Before we start, it is important to remember that the primary purpose of a


duplicate "a"


+a code review is to identify any bugs or potential bugs in the code. Most code
+reviews are relatively straight-forward and do not require re-writing the
+submitted code substantially.
+
+The document provides advice on how to structure larger patch series and
+provides  pointers on code author's and reviewer's workflows.
+
+Sometimes it happens that a submitted patch series made wrong assumptions or 
has
+a flawed design or architecture. This can be frustrating for contributors and
+code  reviewers. Note that this document does contain [a section](#problems)
+that provides  suggestions on how to minimize the impact for most stake-holders
+and also on how to avoid such situations.
+
+This document does **not cover** the following topics:
+* [Communication Best Practice][1]
+* [Resolving Disagreement][2]
+* [Patch Submission Workflow][3]
+* [Managing Patch Submission with Git][4]
+
+## What we look for in Code Reviews
+
+When performing a code review, reviewers typically look for the following 
things
+
+### Is the change necessary to accomplish the goals?
+
+* Is it clear what the goals are?
+* Do we need to make a change, or can the goals be met with existing
+  functionality?
+
+### Architecture / Interface
+
+* Is this the best way to solve the problem?
+* Is this the right part of the code to modify?
+* Is this the right level of abstraction?
+* Is the interface general enough? Too general? Forward compatible?
+
+### Functionality
+
+* Does it do what it’s trying to do?
+* Is it doing it in the most efficient way?
+* Does it handle all the corner / error cases correctly?
+
+### Maintainability / Robustness
+
+* Is the code clear? Appropriately commented?
+* Does it duplicate another piece of code?
+* Does the code make hidden assumptions?
+* Does it introduce sections which need to be kept **in sync** with other
+  sections?
+* Are there other **traps** someone modifying this code might fall into?
+
+**Note:** Sometimes you will work in areas which have identified 
maintainability
+and/or robustness issues. In such cases, maintainers may ask you to make
+additional changes, such that your submitted code does not make things worse or
+point you to other patches are already being worked on.
+
+### System properties
+
+In some areas of the code, system properties such as
+* Code size
+* Performance
+* Scalability
+* Latency
+* Complexity
+* &c
+are also important during code reviews.
+
+### Style
+
+* Comments, carriage returns, **snuggly braces**, &c
+* See [CODING_STYLE][5] and [tools/libxl/CODING_STYLE][6]
+* No extraneous whitespace changes
+
+### Documentation and testing
+
+* If there is pre-existing documentation in the tree, such as man pages, design
+  documents, etc. a contributor may be asked to update the documentation
+  alongside the change. Documentation is typically present in the [docs][7]
+  folder.
+* When adding new features that have an impact on the end-user,
+  a contributor should include an update to the [SUPPORT.md][8] file.
+  Typically, more complex features require several patch series before it is
+  ready to be advertised in SUPPORT.md
+* When adding new features, a contributor may be asked to provide tests or
+  ensure that existing tests pass
+
+ Testing for the Xen Project Hypervisor
+
+Tests are typically located in one of the following directories
+* **Unit tests**: [tools/tests][9] or [xen/test][A]
+  Unit testing is hard for a system like Xen and typica

Re: [Xen-devel] [PATCH v4 6/7] Add guide on Communication Best Practice

[Jürgen Groß]

On 30.12.19 20:32, Lars Kurth wrote:

From: Lars Kurth 

This guide covers the bulk on Best Practice related to code review
It primarily focusses on code review interactions
It also covers how to deal with Misunderstandings and Cultural
Differences

Changes since v3
* Fixed typo

Changes since v2 (added in v2)
* Fix typos
* Extended "Verbose vs. terse"
* Added "Clarity over Verbosity"
* Broke "Identify the severity of an issue or disagreement" into two chapters
   - "Identify the severity and optionality of review comments" and made
 clarifications
   - "Identify the severity of a disagreement"
   - Expanded "Prioritize significant flaws"
* Added "Reviewers: Take account of previous reviewer(s) comments"
* Added prefixes such as "Reviewers:" where appropriate
* Fixed lien wrapping to 80 characters
* Replaced inline links with reference links

Signed-off-by: Lars Kurth 
---
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
  communication-practice.md | 504 ++
  1 file changed, 504 insertions(+)
  create mode 100644 communication-practice.md

diff --git a/communication-practice.md b/communication-practice.md
new file mode 100644
index 000..438b73a
--- /dev/null
+++ b/communication-practice.md
@@ -0,0 +1,504 @@
+# Communication Best Practice
+
+This guide provides communication Best Practice that helps you in
+* Using welcoming and inclusive language
+* Keeping discussions technical and actionable
+* Being respectful of differing viewpoints and experiences
+* Being aware of your own and counterpart’s communication style and culture
+* Show empathy towards other community members
+
+## Code reviews for **reviewers** and **patch authors**
+
+Before embarking on a code review, it is important to remember that
+* A poorly executed code review can hurt the contributors feeling, even when a
+  reviewer did not intend to do so. Feeling defensive is a normal reaction to
+  a critique or feedback. A reviewer should be aware of how the pitch, tone,
+  or sentiment of their comments could be interpreted by the contributor. The
+  same applies to responses of an author to the reviewer.
+* When reviewing someone's code, you are ultimately looking for issues. A good
+  code reviewer is able to mentally separate finding issues from articulating
+  code review comments in a constructive and positive manner: depending on your
+  personality this can be **difficult** and you may need to develop a technique
+  that works for you.
+* As software engineers we like to be proud of the solutions we came up with.
+  This can make it easy to take another people’s criticism personally. Always
+  remember that it is the code that is being reviewed, not you as a person.
+* When you receive code review feedback, please be aware that we have reviewers
+  from different backgrounds, communication styles and cultures. Although we


add "are"


+  all trying to create a productive, welcoming and agile environment, we do
+  not always succeed.



Juergen

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

Re: [Xen-devel] [PATCH v4 7/7] Added Resolving Disagreement

[Jürgen Groß]

On 30.12.19 20:32, Lars Kurth wrote:

From: Lars Kurth 

This guide provides Best Practice on identifying and resolving
common classes of disagreement

Changes since v3
* Fixed broken http link (typo)

Changes since v2 (added in v2)
* Fix typos
* Add section: "Issue: Multiple ways to solve a problem"
* Changed line wrapping to 80 characters
* Replaced inline style links with reference style links

Signed-off-by: Lars Kurth 
--
Cc: minios-de...@lists.xenproject.org
Cc: xen-...@lists.xenproject.org
Cc: win-pv-de...@lists.xenproject.org
Cc: mirageos-de...@lists.xenproject.org
Cc: committ...@xenproject.org
---
  resolving-disagreement.md | 188 ++
  1 file changed, 188 insertions(+)
  create mode 100644 resolving-disagreement.md

diff --git a/resolving-disagreement.md b/resolving-disagreement.md
new file mode 100644
index 000..fb3b134
--- /dev/null
+++ b/resolving-disagreement.md
@@ -0,0 +1,188 @@
+# Resolving Disagreement
+
+This guide provides Best Practice on resolving disagreement, such as
+* Gracefully accept constructive criticism
+* Focus on what is best for the community
+* Resolve differences in opinion effectively
+
+## Theory: Paul Graham's hierarchy of disagreement
+
+Paul Graham proposed a **disagreement hierarchy** in a 2008 essay
+**[How to Disagree][1]**, putting types of arguments into a seven-point
+hierarchy and observing that *moving up the disagreement hierarchy makes people
+less mean, and will make most of them happier*. Graham also suggested that the
+hierarchy can be thought of as a pyramid, as the highest forms of disagreement
+are rarer.
+
+| ![Graham's Hierarchy of Disagreement][2]|
+| *A representation of Graham's hierarchy of disagreement from [Loudacris][3]
+  modified by [Rocket000][4]* |
+
+In the context of the Xen Project we strive to **only use the top half** of the
+hierarchy. **Name-calling** and **Ad hominem** arguments are not acceptable
+within the Xen Project.
+
+## Issue: Scope creep
+
+One thing which occasionally happens during code review is that a code reviewer
+asks or appears to ask the author of a patch to implement additional
+functionalities.
+
+This could take for example the form of
+> Do you think it would be useful for the code to do XXX?
+> I can imagine a user wanting to do YYY (and XXX would enable this)
+
+That potentially adds additional work for the code author, which they may not
+have the time to perform. It is good practice for authors to consider such a
+request in terms of
+* Usefulness to the user
+* Code churn, complexity or impact on other system properties
+* Extra time to implement and report back to the reviewer
+
+If you believe that the impact/cost is too high, report back to the reviewer.
+To resolve this, it is advisable to
+* Report your findings
+* And then check whether this was merely an interesting suggestion, or 
something
+  the reviewer feels more strongly about
+
+In the latter case, there are typically several common outcomes
+* The **author and reviewer agree** that the suggestion should be implemented
+* The **author and reviewer agree** that it may make sense to defer
+  implementation
+* The **author and reviewer agree** that it makes no sense to implement the
+  suggestion
+
+The author of a patch would typically suggest their preferred outcome, for
+example
+> I am not sure it is worth to implement XXX
+> Do you think this could be done as a separate patch in future?
+
+In cases, where no agreement can be found, the best approach would be to get an
+independent opinion from another maintainer or the project's leadership team.
+
+## Issue: [Bikeshedding][5]
+
+Occasionally discussions about unimportant but easy-to-grasp issues can lead to
+prolonged and unproductive discussions. The best way to approach this is to
+try and **anticipate** bikeshedding and highlight it as such upfront. However,
+the format of a code review does not always lend itself well to this approach,
+except for highlighting it in the cover letter of a patch series.
+
+However, typically Bikeshedding issues are fairly easy to recognize in a code
+review, as you will very quickly get different reviewers providing differing
+opinions. In this case it is best for the author or a reviewer to call out the
+potential bikeshedding issue using something like
+
+> Looks we have a bikeshedding issue here
+> I think we should call a quick vote to settle the issue
+
+Our governance provides the mechanisms of [informal votes][6] or
+[lazy voting][7] which lend themselves well to resolve such issues.
+
+## Issue: Small functional issues
+
+The most common area of disagreements which happen in code reviews, are
+differing opinions on whether small functional issues in a patch series have to
+be resolved or not before the code is ready to be submitted. Such disagreements
+are typically caused by different expectations related to the le

[Xen-devel] [libvirt test] 145656: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-libvirt   6 libvirt-buildfail REGR. vs. 145511
 build-amd64-libvirt   6 libvirt-buildfail REGR. vs. 145511
 build-i386-libvirt6 libvirt-buildfail REGR. vs. 145511
 build-armhf-libvirt   6 libvirt-buildfail REGR. vs. 145511

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a

version targeted for testing:
 libvirt  fe1f2bfbe3ca8944df37c6b77f813eaab572a2f7
baseline version:
 libvirt  db5d04991133b2bdff1fe26ebe2bd1069ac8b7a4

Last test of basis   145511  2020-01-03 04:18:44 Z3 days
Testing same since   145542  2020-01-04 04:18:55 Z2 days3 attempts


People who touched revisions under test:
  Daniel P. Berrangé 
  Julio Faracco 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-arm64-libvirt  fail
 build-armhf-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-libvirt-xsm blocked 
 test-arm64-arm64-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  blocked 
 test-amd64-amd64-libvirt blocked 
 test-arm64-arm64-libvirt blocked 
 test-armhf-armhf-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-libvirt-pairblocked 
 test-amd64-i386-libvirt-pair blocked 
 test-arm64-arm64-libvirt-qcow2   blocked 
 test-armhf-armhf-libvirt-raw blocked 
 test-amd64-amd64-libvirt-vhd blocked 



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

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

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

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


Not pushing.

(No revision log; it would be 343 lines long.)

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